MY PLAN TO VERIFY THE CLOCKING WIZARD WAS NOT WELL RESEARCHED
I simply connected the three clock outputs as well as the clock on the FPGA board to an external connector on the board, to which I hooked my oscilloscope. The results appeared to match the simulation output - at least for some of them - with the clocks half the speed I expected and the 200MHz clock the worst of all.
The flaw here was that I was trying to observe relatively high speed signals on an output connector (the Digilent PMOD) that is not well suited for this. Further, I didn't instantiate any clock buffers to keep the signal quality high.
PLAN B QUICKLY IMPLEMENTED AND THE RESULTS ARE POSITIVE
I then set up counters that would increment at the rate of the three generated clocks. These were all released as soon as the clock module reported a lock on the PLL that produces the frequencies. A fourth counter incremented using the FPGA boards internal clock, also released when the clock module achieved lock.
Since we are dealing with multiple clock domains, I implemented a chain of four stages to pass through the counters from the generated clocks so that I had a high quality counter value in the test logic. The test logic would count up to 100 to trigger the test. At 100, I checked that the three counters had reasonable values consistent with the target frequencies. The 200 MHz counter should be approaching 200, the 167 MHz counter nearing 167 and the final counter heading towards 100.
There are a few cycles lost due to the chain of flipflops that achieve the clock domain crossing for the counters, which is why the results that lit up the LEDs were a few counts less than the target number. For example, the 200 MHz counter would probably hit 198 or 200 at the same time as my test, but the chain of four stages in the domain crossing meant that the value I would test would be about 192 to 194 most likely. My test was tightened to look for > 192 and < 195 with consistent success.
No comments:
Post a Comment