On Sun, May 01, 2005 at 01:48:51PM -0500, Patrick McNamara wrote:
> So my thoughts are as follows. We have a distinct need which can be
> reasonably met but either project. I don't care which we use. My
> approach would be to simply write our hardware simulator as a completely
> separate library module and when it reaches significant enough
> complexity and completeness we wrap it in the necessary translation code
> to hook in to either or both projects.
I didn't really understand what you said here. But from experience
on the one similar project I worked on, and a lot of experience in seeing
board designs through to completion, let me toss out a couple of thoughts.
1. Step 1 should be to document the register model of the target chip,
which is also the register model of the FPGA emulation, and freeze it. This
allows the hardware and software teams to decouple, so they can work
independently at their own pace. The first draft of the register model spec
gives each contingent something to check its design approaches against, to
see where refinements should be made from each side. Until everybody agrees
on this interface spec, detailed implementation work is likely to be wasted,
because the target is moving. This spec isn't done until all register
addresses and bit assignments are frozen, and everybody signs off.
2. Simultaneously with the binary interface, the hardware team can work out
the design of the analog back end and other supporting electronics, and
define the electrical and logical interface between it and the FPGA.
3. With the interfaces to both sides of the FPGA frozen, the Verilog code
can all be written, and synthesized to determine the size and number of
FPGAs required for implementation. (I got a big surprise here, when I took
my project leader's word for it, and designed the PCB to mount the FPGA he
chose. The logic didn't fit, and I had to do the board over to use a bigger
FPGA.)
4. With the complete electronic design stable except maybe for component
values which don't affect footprint, the time is ripe to fill in the cooling
system, mounting hardware, and other hardware items.
5. Only after the complete schematic, parts list, mechanical design, and
layout requirements document are stable can board layout begin. Breaking
discipline here is an absolute guarantee that a lot of money will be wasted
and any semblance of a schedule will go out the window.
6. Meanwhile, with the binary interface frozen at step 1, the driver team
can go to work simultaneously on the driver and a software emulation of the
binary interface, to allow driver code to be tested before the FPGA board is
ready. There might be ways in the tool chain to drive a Verilog simulation
with C software, but I sort of suspect that for a dispersed volunteer team
without a lot of money for expensive synthesis tools, it would be more
expedient to drive a C emulation of the board until a real board is
available.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
