At times, the px_rd_count or px_wr_count of the MCB jumps abnormally. Specifically, when empty is asserted, the px_rd_count jumps from 0x0 to 0x40 for one cycle, and when empty is deasserted, the count value jumps to 0x0.
Is this jump expected? What causes it?
Note: This Answer Record is a part of the Xilinx MIG Solution Center (Xilinx Answer 34243). The Xilinx MIG Solution Center is available to address all questions related to MIG.
Whether you are starting a new design with MIG or troubleshooting a problem, use the MIG Solution Center to guide you to the right information.
This is expected behavior. There is a CDC issue on the write side of the MCB read FIFO. The FIFO is 64 bits deep and there are 65 Gray code bits to prevent a pointer collision on the write side.
When the pointer rolls over, the pointer will jump from 1100000 to 0000000. When the clock edges are close, the highest bit (bit 6) has a chance to be sampled as 0, but bit 5 will still be sampled as 1 on the read side0100000(binary 63). The other case is 1000000(binary 127).
The counter value is a subtract of read/write pointers. If 0100000 is sampled, the counter value is one less than what is expected. When 1000000 is sampled, it gives 64 more than what is expected.
This sample occurs when the user interface is driven by an asynchronous clock to the MCB clock and cannot be avoided. Hence the jump in counter value is +64 or -2 different to what is expected.
Similar behavior can be seen for Write-FIFO sporadically at high temperature. ChipScope-Analysis has shown that the pX_wr_count jumps when the FIFO becomes full. In some cases this happened for a single clock from 0x40 to 0x00.
The timing of occurrence is regardless of the counter value of full or empty. If this jump is not desirable, one of the following can be used:
For more information on the MCB User Interface signals, please see:
(Xilinx Answer 43322) MIG Spartan-6 MCB - User Interface - Signals and Parameter Descriptions