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

[Timothy Miller]

On 1/2/07, Patrick McNamara <wpmcnamara at yahoo.com> wrote:

> The problem here is the timing of the individual bus signals.  Assume
> you are sampling at 330MHz.  That gives you 10 samples per PCI clock on
> a 33MHz bus.  Each of the data and address lines may have slightly
> different setup times.  It is quite possible that you will get a change
> in your sample data in a majority of your sample windows, especially if
> you are stepping the bus.  You will get a lot a repetition on a fairly
> idle bus, but where it counts, at the beginning of the bus setup when
> you need to make sure you have the timing right, you will get a lot a
> change and need to be able to transfer a lot of data quickly.
>
> In the worst case you probably need to be able to transfer around 112
> bits per sample window:  32 bits or so for a time stamp and 80 or so for
> PCI bus data.  That assumes that all bits change in a single sample
> period.  Thats 3.5 32bit words that need to go between the two FPGAs in
> a single 330MHz clock cycle.  Ouch.

Ok, let's ponder this...

I'm inspired by the Itanium instruction set.  We have 40 bits to play
with and 32<n<64 signals that can change.  That means we can encode 6
single-bit changes plus something else in the remaining 4 bits every
cycle.  Since n<64, we can use unassigned codes to indicate things
like timestamp advancing, no change, etc.

We may be able to take advantage of the fact that recently changed
signals are extremely unlikely to change again.  If things change too
fast, the effect will be that we report that a signal changed 2.5ns
later than it actually did.

Will this do us any good?

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