On May 15, 2008, at 9:54 , Vinayak Nagpal wrote:
Any transmission line effects external to the FPGA may cause clock glitches etc but those should not affect the results because the clock to all blocks should glitch together.
If the DCM loses and regains lock, then all bets are off on the integrity of the internal clock network. I learned this the hard way when developing the ATA DDC. Here is what I learned so that hopefully others will learn it the easy way...
During the ibob FPGA startup with two ADC boards, the PPC startup software resets the ADCs repeatedly until their output clocks are in- phase with each other. During these ADC resets, the DCMs lose and regain lock. According to the v2pro user guide, this can cause the DCM output clocks to "exhibit glitches, spikes, or other spurious movement." It turns out that these "glitches, spikes, or other spurious movement" put the Xilinx FIR filters I had used into a a bad/ invalid state and the output did not match simulation. I suspected that during this startup period some parts of the filters were clocking ahead to the next state while other parts were not.
I tested this theory by setting up pairs of free-running counters whose outputs were fed into "!=" comparison blocks. The outputs of these comparison blocks went to the "set" pins of a bank of set/reset FFs. If the counters were ever mismatched, the SR FFs would output a '1' forever. These FFs were concatenated into a 32 bit word and fed into a sw register. In simulation, of course, these FFs never went to one because the counters always output the same value. In the ibob, however, the sw register never read back as all zeros. It had a different value virtually every time I reconfigured the ibob.
I then setup a really long counter that took about 10 seconds for the msb to go high. I used the rising edge of the msb to trigger a SR FF and used this signal (which I called "clock_ok") to enable the bank of counters. After doing this, the sw register did read back all zeros all the time.
Since the Xilinx FIR blocks do (or at least did) not have a reset port to put the filter back to a known good state, I used my clock_ok signal as the FIR filters' "data_valid" input. This is essentially a clock_enable for the whole filter. Disabling the filters during the hostile startup clock environment solved the problem and the design worked perfectly (well, at least it matched simulation, it still had a few "real" bugs :-)).
Most CASPER blocks have a reset port or essentially use a sync signal as a reset. Thus they self-correct if they get into a bad/invalid state during the hostile startup clock environment.
Glenn, it sounds like you are syncing things up with a sync pulse, so this doesn't seem likely to be your problem, but if you are generating multiple sync pulses "in parallel", how are you syncing the sync pulses?
Dave
