Hello Altera Experts!I am using Quartus Standard 24.1..I'm building a 10-bit parallel output interface to drive a DAC. I'm using the oddr (ALTDDIO_OUT) registers so that all bits output simultaneously. 9 of the 10 bits are aligned, while one has an additional delay of about 2 nsec.I created two 10-bit buses (to drive two DACs), and the strange thing is that bit (3) is always delayed on both buses.I'm attaching the project, hoping some experts can help me.The ddr registers are correctly instantiated, but in the timing analysis, the bit(3) coming out of the fpga is delayed compared to all the others:TIMING ON BUS_A:TIMING ON BUS_B: REGULAR DELAY:BIG DELAY:The only difference I see is that the "slow" pins are both also Vrefs (pin 105 and pin 80):Could this be the reason?regards,LUCA.

The routing delay difference due to different type of pin assigned. The bit fpga_dac_CHA[3] using this type of pin: While other bits using these type of pin: Different pin type will have different internal routing delay and this is fix one which cannot be changed. So if change bit fpga_dac_CHA[3] and fpga_dac_CHB[3] pins to for example PIN_115 and PIN_120. The timing will be similar for all bits:

CYCLONE IVE ODDR delay mismatch | Altera Community

15 Replies

ShengN_altera
Super Contributor
25 days ago
I compile the attached design and timing pass as below:
GOMEZ_IT
Occasional Contributor
23 days ago
Hi Sheng. Can you share the timing analisys from Pll1/clk0 clock to clk_dac_a or clk_dac_b clocks?
- ShengN_altera
  Super Contributor
  23 days ago
  Here is the timing:
  
  There's no problem as well.
GOMEZ_IT
Occasional Contributor
23 days ago
If you look at the first 2 lines you will notice that the 'data delay' value is about 1 nanosecond greater than all the other lines. Using the ODDRs I expected differences on the order of 100-200 picoseconds between all the pins. This is what I can't understand.
- ShengN_altera
  Super Contributor
  23 days ago
  The timing slack is positive for all paths meaning the design meets timing requirements. The difference you are seeing in the Data Delay column does not indicate a functional problem. This variation is related to the physical routing inside the FPGA.
  
  Quartus always attempts to use the shortest and fastest routing resources first. In your case, the majority of the DAC output signals were able to use these optimal routes, resulting in very closely matched delays. For the first two channels, however, those preferred routing paths were no longer available due to normal placement and congestion conditions. As a result, Quartus selected alternative routing tracks, which are slightly longer and therefore contributed to the additional ~1 ns of data delay.
  
  This behavior is expected and common when multiple high‑speed output signals originate from the same clock source but fan out across different I/O locations. The additional delay on the first two lines is due to longer routing, best routing path had been used up. But you can rest assure about the functional because all paths are positive slacks and timing is fully met.
GOMEZ_IT
Occasional Contributor
23 days ago
Do you think it is possible to force Quartus to use the same type of routing (the fast one) used on all the other pins? I am aware that at the moment the timing is being exceeded, but right now if I wanted to increase the clock frequency I would have limitations precisely due to those 2 "slower" pins.
- sstrell
  Super Contributor
  22 days ago
  Try cross-probing from the timing analysis report to the Chip Planner (right-click the path and go to Locate Path). This might help identify why the internal routing is longer for these 2 paths.
- ShengN_altera
  Super Contributor
  22 days ago
  The routing delay difference due to different type of pin assigned.
  
  The bit fpga_dac_CHA[3] using this type of pin:
  
  While other bits using these type of pin:
  
  Different pin type will have different internal routing delay and this is fix one which cannot be changed.
  
  So if change bit fpga_dac_CHA[3] and fpga_dac_CHB[3] pins to for example PIN_115 and PIN_120. The timing will be similar for all bits:
cblixt1
New Contributor
20 days ago
That's right, the OP's original assumption was correct. Different types of dual-purpose pins have different propagation delay. I can't see this clearly stated in any documentation, but it definitely seems so. For the types above, identified by pin number, the varying part is as follows:
105: 4.393 ns
103: 3.281 ns
110: 3.128 ns
So if you want to do a source-synchronous interface with as little data skew as possible, make sure all your data bits are driven from the same type of I/Os. At least avoid the VREF ones.
On a side note, the slack mentioned above seems to refer to the falling edge of the launch clock to the rising edge of the latch clock. I think that is a false path, the data is only meant to change on rising edges. So the slack is actually better by 5 ns, but if you really need to run as fast a possible you need to reduce that data skew.
GOMEZ_IT
Occasional Contributor
20 days ago
Thank you ShengN and thank you cblixt1.
So my suspicion about the Vref pins is confirmed.
cblixt1: regarding the false path issue, I have some doubts:
The oddr register that I am using is capable of launching the data on both the rising and falling edges of the clock. The dac_clk, instead, latches only on the rising edge. The values on the D inputs of the oddr register are updated (by other logic not currently present) only on the rising edge.
I can't understand which false paths are correct to insert in this situation..
- cblixt1
  New Contributor
  20 days ago
  I added this
  set_false_path \ -fall_from [get_clocks {PLL1|altpll_component|auto_generated|pll1|clk[0]}] \ -rise_to [get_clocks {clk_dac_a}]
  into your sdc file, and that seemed to do the trick. The Timing Analyzer now says
- ShengN_altera
  Super Contributor
  17 days ago
  Hi GOMEZ_IT
  
  Do you have further question?
GOMEZ_IT
Occasional Contributor
17 days ago
I'm still unsure about the false path issue. I can't figure out why I should disable the path between the falling edge of launch-clk and the rise edge of latch-clk. The launch-clk for oddrs could also be the falling one, since it's a ddr.
- cblixt1
  New Contributor
  17 days ago
  Yes, but you are using the DDR flipflops just to minimize the skew. You are not planning to output DDR data, you will supply the same indata for both edges. Quartus doesn't know this, so you have to tell it using this constraint.
- ShengN_altera
  Super Contributor
  16 days ago
  I believe cblixt1 is talking about the source synchronous constraint. You may refer to this link https://docs.altera.com/v/u/docs/653688/an-433-constraining-and-analyzing-source-synchronous-interfaces

Forum Discussion

CYCLONE IVE ODDR delay mismatch

15 Replies

Recent Discussions

memory infer

Request: Questa Intel FPGA Starter Edition License for Quartus Prime 25.1 (Windows 11)

Timing analysis - long combinational path

Questa unable to checkout a viewer license

Error(23098) when using IPM_IOPLL on Agliex 7