On 5/1/05, Jack Carroll <[EMAIL PROTECTED]> wrote: > 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.
I'm working on that right now, although the work schedule has a number of other things higher priority. I'll see if I can squeeze in some more time on the register set earlier. We're working on a schedule to share, so we can discuss that. > > 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.) We're picking a footprint that works across multiple models, fortunately. > 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)
