On 9/4/07, Patrick McNamara <[EMAIL PROTECTED]> wrote: > > Interesting. We only have 24 BRAMs on the device, and need some for > > buffers, > > but I think that this might work. > Also consider that the FPGA version only needs to be a proof of > concept. If we only allow for two contexts, but get them working, then > with the ASIC where we may not be as constrained on real estate then we > can expand.
This is dangerous thinking. Yes, when going to the ASIC, we'll have to do a fair amount of retargetting, but we shouldn't change anything higher-level. The main point of the FPGA is to fully test a design so that we're vastly less likely to produce a terribly flawed ASIC. You don't want to get something we can't sell. I've been through this before, and it ain't pretty. > > Hmm, that is a pretty big problem. Even just ignoring the context switch, > > we are not going to ever need a multiply for PCI, right? > Not sure. I'm not even sure we have to have a multiply to do the VGA > conversion routines, mainly because I haven't sat down to think real > hard about what is necessary. The actual question is "Do we need > variable multiplication?" If all the multiplication we need to do is by > a fix amount, say the line number times screen width, then using a > multiply instruction is probably slower than using shifts and adds. One of the advantages to our approach is that the physical resolution can be different from what the VGA legacy stuff thinks it is. Since we're translating from VGA text/pixels to pixels in our format (24-bit TC), we can make the display whatever we want. But that means the width is variable. Note: Consider using look-up tables in the scratch memory for some of the multiplies. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
