The signals are not all guaranteed to be stable on any given clock
cycle
-- read up on "stepping the PCI data/address lines". Effectively, the
reflections of the signals on the bus are used to allow weaker bus
drivers on the PCI device. In this case it takes a number of clock
cycles for all the data/address lines to stabilize. During this
multi-clock transition time the signals will be in indeterminant
states
which the capture may interpret as high or low.
Essentially an infinite buffer (the hard drive) is on the
tracer machine, so we might as well store the signals there.
<snip>
I doubt we can can compress even a mildly active PCI bus enough to
transfer it over a 1Mb or similar serial link in real time.
I was thinking about possibly using SCSI, ATA, or SATA in this case.
It is still too difficult to implement IMO now that I read about
stepping.
Thinking about it, perhaps we are going about this the wrong way.
From
what it sounds like, we have generally settled on some sort of serial
UART interface. So, lets focus on getting a state capture implemented
on the card first. We capture on the PCI bus clock just like a normal
PCI card does. Lets start with a 32 bit 33MHz bus. That gives us 59
signals (if I counted correctly) to watch. We have 40 signals for
interconnect. Take out eight for control signals and use 32 for data.
If we transfer 96 bits between the two FPGAs per sample, we can
have all
59 signals plus a 37 bit sample clock. This gives us room for
(2^37)-1
samples or about an 1h 9m worth of wall clock time. We would run
out of
memory well before that. Assuming no compression, that would be
12TB of
data. Now, take out the clock. Since we capture every clock
cycle, the
system doesn't need to track the clock count with the samples, it
can be
inferred. This drops us to 64 bits per PCI clock. Uncompressed we
could store about 8.1sec worth of PCI traffic, but all the compression
can be done on the big FPGA to allow for longer captures. We can
certainly handle 66MHz transfers between the to FPGAs.
...
I was just writing almost this exact thing when I recieved this mail ;-)
I counted 61, but I think I might have counted the 64-bit enables.
The only other thing that I could think of is possibly trying to find
a way
to reduce the tranfer time to two cycles (or one DDR) between the two
chips
per sample, but that would require very limited storage time (< 1 sec).
The last idea I had was to allow selective capture of different
lines, and use the
extra sample space to do 20x oversampling on the other lines (330 Mhz
DDR?
I don't know how this would be possible, hence my rejection of the
idea), but
it is not a feature that we should worry about at this point.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
