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? -- Timothy Miller http://www.cse.ohio-state.edu/~millerti _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
