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

[Timothy Miller]

On 1/1/07, Dieter <netbsd at sopwith.solgatos.com> wrote:
> > > This is a good idea.  But what I meant was to use some very simple
> > > compression in the hardware in order to shorten the length of time
> > > necessary to download the entire trace over serial line.
> >
> > 115200 bps is ~ 14 k/s.  At that speed, a full 256Mb ram dump would
> > take approximately 5.2 hours.
>
> > Compression's a good idea.
>
> Do we have an idea of how compressable the data is likely to be?

Take what I say with a grain of salt, but I would think it would be
VERY compressible.  Idle time would completely collapse, and a lot of
signals stay constant.  It would be a lot like a VCD (value change
dump) file.

> Suddenly a faster interface (Ethernet, Firewire, USB2, ...) looks
> attractive.

Not to the hardware designers.  :)

> Or...  assuming the case that the board under test locked up the machine,
> would it be possible to protect this RAM from being cleared on reboot,
> and then upload it to the test computer via PCI?

Egad.  We can supply external power, but I'm not sure if that would
send power to the host computer when it's off, causing trouble.

> Or...  could the OGD ship the data out the DVI?  Then we just need a
> custom DVI-to-something (DVI-to-Ethernet?) adapter.  Although... such
> an adapter is probably... non-trivial.  Probably easier to attach
> the desired interface directly to the board.

Absolutely none of this is trivial.  I think that either way find a
way to compress it (only for a full dump), or we give up on being able
to dump it to disk (which would be really bad).

I say we produce the best solution we can for the moment and then look
into improving it.

Oh, and one other thing... we can let the user select sections of the
trace to store to disk.  If they already know where in time the
problem is, they can just do a few thousand clocks before and after.

-- 
Timothy Miller
http://www.cse.ohio-state.edu/~millerti