On Wednesday 03 January 2007 16:41, Timothy Miller wrote: > On 1/2/07, Patrick McNamara <[EMAIL PROTECTED]> 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?
I don't know anything about the Itanium instruction set, but I do have an idea that seems like it's in the same direction. Sampling We need to monitor n 1-bit inputs and send them over a 40-bit bus. For each input, take one n-bit shift register and on each cycle, push the current value XOR the previous value into that register. Every n cycles, do the following: 1) compress the contents of the shift register down to 40 bits (assuming n > 40), and send it in parallel across the 40-bit bus. 2) reset the previous value buffer register to 0 Stagger the starts of the monitoring of each of the inputs by one cycle, so that the shift registers are read out in a round-robin fashion. At cycle t, you get the previous n values of input 1, at cycle t+1 you get the (then) previous n values of input 2, and so on. Compression and sending We have n bits each time, and we want 40. The first bit is the actual value of the input at that time, the rest are 0 if the bit is the same as the previous bit, 1 if it's different. So we can reconstruct the entire sample from this. If the signal doesn't change too often, it will be mostly zeroes. We could compress this by encoding a sequence of m zeros followed by a 1 with the number m. That would require a ceil(ln(n)) bit field, 7 bits for 80 values in the worst case. The first bit should be stored directly, so that there's room for (40 - 1) / 7 = 5 fields left. Sampling a 33MHz bus at 330MHz means a constantly changing signal changes every ten samples, which is 8 changes for 80 samples, so we lose three of every eight of them. For 64 values it could just barely work, with six 6-bit fields. For 32-bit plus 16 control signals, we need four or probably five 6-bit fields, that would work. Still, only two glitches would be enough to saturate it again, so if something goes wrong timing-wise then you're back in "something's wrong but we're not sure exactly what"-land pretty quickly. Perhaps some sort of Huffman encoding works better. The longer each sequence of zeroes is, the smaller the other sequences will be, so a variable field size would probably help. Lourens
pgpQLNV1Pfuoq.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)
