Actually, I think it's a great idea, what you suggest. I'm working on a rewrite of the software model that includes more hardware-oriented stuff, like actual register numbers, etc. I want to make it look more like the chip will, rather than merely document the math.
Also, there is some amount of flexibility with the hardware/software schedules, because the FPGA version will be available for people to run on the 3S4000 version of the prototype board, so when they find problems, we can make updates to the hardware. As for testing the prototype board, we'll do the minimum verilog coding necessary to make a test harness... something that tests memory and video and PCI. On 4/30/05, Patrick McNamara <[EMAIL PROTECTED]> wrote: > We have a chicken and egg problem. Those writing the software need > hardware to develop against, and those developing the hardware are going > to need software ready with the first spin of silicon (or in our case, > the first FPGA model). So here is the question. Is it worth our effort > to build a complete software simulation of the card? I'm thinking about > something like adding a simulation of our card to BOCHs. A lot of work > has already be done on simulating some of the 3d pipeline. Should we > continue that and expand it to the whole card? I've been pondering it > and see some definite benefits. > > *Provides a double check of our specs. If you can't write a software > model from the specs, chances are pretty good you can do hardware from > them either. > *Allows the driver folks to get a jump start. It won't be much good to > have a working ASIC and no drivers. > *Opens up the development effort to folks who can't/won't afford the > cost of the development board. > *Allows the BIOS folks to get a head start. It would be really cool to > be able to at least get text mode output at delivery from the board > house on the first spin of the development boards. > *Contributes to the BOCHS effort. Provides BOCHS with a real and > complete implementation of a real piece of video hardware, including 3d. > *There are others, I'm sure... > > There is always a flip side. TANSTAAFL. The biggest drawback is > probably the effort involved. It may draw resources away from more > useful tasks. Another being maintenance. We would have to keep the > software simulator in sync with the various revs of the RTL. And, there > are others I'm sure. > > So, I'll open the floor to debate and step back to watch now... :) > > Patrick M > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
