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.
As long as the LZW patent doesn't affect this, we should be golden. On the other hand, if we program the FPGA serially, the compression would save more space than time, although space savings just means we have more space for boot code for more platforms and stuff. We'll hang on to this and see how much room we have left in the Lattice, and if we do, we can wedge it in there. Nice. :) On 8/20/05, Ray Heasman <[EMAIL PROTECTED]> wrote: > Hi Timothy, > > On Sat, 2005-08-20 at 14:24 -0400, Timothy Miller wrote: > > > Anyway, just thought I'd check in and let you know what's up. I've got a > > > pretty good model going for the flash interface and I wanted to check > > > some of > > > my assumptions before going any further. The IOs look like this: > > Sorry for butting in late here, but I have been busy with other things > (SIGGRAPH amongst other things). I have attached two pieces of C code. > > One compresses a file using a simple method (a sort of dumb LZ-ish thing > I made up, but I am sure is nothing new). I specifically wrote it for > compressing FPGA images, and it gets anything from 3:1 to 11:1 > compression on Virtex-4 images, depending on gate density. I ended up > using it for ARM and TI DSP object code too, where it gets about 2.5:1 > compression. Maximum compression on a repeated string is 128:1. It is > trivially modifiable to detect the end of a stream, so you don't need > length fields. > > Decompression is _very_ simple, and requires a 256-byte buffer (you can > decrease that if you want to, at the expense of losing some compression > on long strings). It should be a breeze to implement in hardware if > required. > > I thought this could help the OGP project in two ways: > > 1) It could be used to speed up FPGA boot, because you can read less > data from a slow flash, and decompress it in the Lattice chip before > writing it to the FPGA - you can run the sync serial interface to the > FPGA awfully fast. > > 2) It could be used to save space in the flash, allowing more images, or > BIOS images, or whatever. > > When loading CPU code, I have generally just written an assembler > decompression stub that you simply concatenate onto the beginning of the > image. This meant I could do CPU boots using a tiny CPLD and a ROM (when > a CPU couldn't just read an image itself). > > Feel free to use or not use this as you please. I figured it was easier > to just give you the code than ask if you wanted it. :-) > > Keep well, > Ray > > > > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
