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.
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.
_______________________________________________
Open-graphics mailing list
[EMAIL PROTECTED]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
