Hold Violation inside ram_block - what is going on?

[Altera_Forum]

Hello, 

 In my design I have a DCFIFO, which I use to get data across two clock domains. The clocks are the same frequency (143.25MHz), but may be out of phase, and there may be jitter with there being a PLL between them.  When I build my design, it fails to meet timing, but I cannot understand what the problem is. An example from the report is below. There are 40 of these, all from similar nodes from the block rams (*~PORT_B_WRITE_ENABLE_REG) to the data out nets (q_b [*]).   can anyone say what this path is, and what i should be doing about it?   I cannot find the node ~PORT_B_WRITE_ENABLE_REG in the RTL Viewer, Technology Viewer, or Chip Planner. As far as I can tell it is inside the ram_block. There are 'write enable' registers for port A, but not for port B (which is only read), so I can't see where this path is or what it is doing.    # Error Type Slack Constraint Route Delay Logic Delay Clk Uncert. Clk Skew Path Type   1 hold -0.03 0.0 0.0 0.025 0.00 0.065 StaPath   Source *dcfifo*|fifo_ram|ram_block9a40~PORT_B_WRITE_ENABLE_REG          Destination *dcfifo*|fifo_ram|q_b[52]          Site Type FanOut Time Comp/BEL       M20K_X197_Y66_N0 uTco 20 0.00 *dcfifo*|fifo_ram|ram_block9a40~PORT_B_WRITE_ENABLE_REG       M20K_X197_Y66_N0 CELL 1 0.035 *dcfifo*|fifo_ram|q_b[52]        I have specified a false path between the two clock domains (although Quartus found and specified this on its own first). I have also added the false path between the delayed write ptr registers explicitly, as described in the DCFIFO documentation, even though in my version of Quartus it is not needed. Neither makes any difference.  Sj

[Altera_Forum]

Sebastion, 

 I am seeing the somewhat the same thing. I have inferred a Simple Dual Port RAM. Writes on Port A, Reads on Port B. Only one clock in this area of logic (200 MHz). TimeQuest flags a setup error between PORT_B_WRITE_ENABLE_REG and logic latching the RAM's output data. I have looked at the instantiation in Technology Viewer and Port B does not use a Write Enable (register is grayed out).  I'm tempted to just ignore this (or declare it a False Path) and treat it as a disconnect between Quartus and TimeQuest.  Did you ever find a reason for this behavior?

[Altera_Forum]

Hi mmeyers, 

 My issue is now resolved, unfortunately I cannot say for sure if I solved it. One thing I did was to split the very wide FIFO into a number of smaller FIFOs. This was because the output of the FIFO was being routed over a very large area by necessity (it was driving a set of transceivers which are far from eachother) and splitting into multiple FIFOs allowed different memory blocks closer to each transceiver to be utilised. I can't remember though if it met timing right after this, or after upgrading Quartus which I also did.  I can say though that it is not a false positive. I ran my (failed) design anyway and it worked - but only when the chip was within a limited range of temperatures. Outside this I would get data corruption.  Good luck (and please post back if you find the actual cause, I would really like to know what it is!)