On 8/21/05, Jack Carroll <[EMAIL PROTECTED]> wrote: > On Sun, Aug 21, 2005 at 12:02:48AM -0400, Timothy Miller wrote: > > Hey, this is cool. There are two approaches we could use for this. > > One is to design hardware that can decompress (even if some of the > > state stuff is stored in block-ram as a sort of program) it. That > > could REALLY help. The other would be to have the host CPU pull data > > from the PROM, decompress, and write it back to the FPGA. The latter > > would only be practical on platforms that can POST the device with a > > boot ROM. > > > Let me play Devil's Advocate here. > > 1. Serial EEPROM space is cheap. Dirt cheap. And the production quantity > of the Unity development board is expected to be small, so piece parts cost > won't be multiplied by a lot of units. But developer time is a limited > resource right now. > This is an argument for favoring simplicity over parts cost, even if it > means putting two or three of the largest available serial EEPROMS into the > SPI chain to make room for multiple firmware variants.
Or users of different platforms can flash the PROM with the BIOS for their own platform, which is an equally valid solution, if slightly less convenient in rare cases. > > 2. Relying on the host computer to uncompress firmware before the board can > boot adds complexity in multiple places, and creates the risk of deadlock > situations. If the development board becomes unable to serve as the only > operator display device in the computer, that could become a very onerous > restriction, and limit the board's ability to emulate the final product. I didn't like it either. Plus, if you were to stick the x86 version into a SPARC, it would still work once the kernel driver came up. Still, it's a neat idea to consider the compression. I wonder if we could apply it to something in the ASIC, like compressing static textures, as long as that doesn't violate someone's patent. It's hard work to keep my mind from wanderng away from the practical into all sorts of "neat ideas" that could come up. But, alas, I have a mission here. :) _______________________________________________ Open-graphics mailing list [EMAIL PROTECTED] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
