Altera_Forum
Honored Contributor
11 years agoHold Violation inside ram_block - what is going on?
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