On Wednesday 03 January 2007 03:07, Patrick McNamara wrote: > > Timothy Miller wrote: > >> On 1/2/07, tonyb <[EMAIL PROTECTED]> wrote: > >>> "Standard" lossless compression will reduce the amount of data by > >>> less than a factor of four. It would still take over an hour to > >>> move the data over the serial line. > >> > >> That all depends on the nature of the data. How compressible is a > >> file filled with nothing but NUL characters? > > There are two methods for doing compressed captures that I can think > of right off hand. Both are value change formats but each would > yield smaller results in different situations. > > First is to do bit wise capture. At the start of the capture, save > the value of all the bits to be watched. From that point, each time > a bit flips, save the time offset. > > The other option is to do a "bus capture" each time an bits on the > bus change. You need to save all the bits you are watching plus the > time stamp. > > Neither of the above methods really compress the datastream from the > card to the display system, they just let us transfer more > information with less bytes.
Which is compression. Another way to say this is that we use RLE-compression between the capture and the on-board storage, rather than between the storage and the output. This is nice memory-wise, but it does complicate seeking to a specific time, since there's no 1:1 correspondence between time and bit position anymore. > If we can do all the capture in the > XP10, the Spartan-3 would give us plenty of real estate to put a > moderately powerful cpu core. If we use any type of value change or > "pre-compressed" format, I don't think RLE compression will buy us > much of anything since the data would effectively already be RLE > compressed at capture time. Perhaps some sort of Huffman encoding. > We could generate the encoding table on the fly at capture time and > have the CPU core compress on the fly using the encoding table at > transmission time. That's one option. Perhaps a simple predictive scheme could be used as well. Essentially, what you propose above is a predictive scheme where we predict the next value as the same as the current value, and only store something when the prediction is wrong. We could watch the last n values instead, and see if we can get a more accurate prediction from that. Perhaps repetitive wave forms could be compressed more efficiently this way. > Another option might be to make a daughter board with the appropriate > drivers and termination for a simple SCSI bus. Even a simple SCSI-1 > bus would allow for a full download in less than a minute, > uncompressed. Download to what though? Does that readily connect to a SCSI controller in the debugging workstation? Will that workstation have a SCSI controller? Lourens
pgps0935HNzYF.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
