[Open-graphics] A really good immediate use for OGD1: PCI bus analyzer

[Lourens Veen]

On Wednesday 03 January 2007 03:07, Patrick McNamara wrote:
> > Timothy Miller wrote:
> >> On 1/2/07, tonyb <tonyb at abcc.linuxceptional.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.duskglow.com/open-graphics/attachments/20070103/161d4872/attachment.bin