Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)

pll clock network delay

Altera_Forum
Honored Contributor II
1,929 Views

I am getting the following clock delays in timing analysis: Roughly 4 ns  

in routing clock from PLL to clock input of altsyncram.  

I am looking for suggestions on what I am doing wrong here. 

How do I get the delay to 0. This path doesn't meet timing for me. 

 

0 1 PLL_L3 altpll_component|auto_generated|pll1|clk[1] 

0 RE 4 PLL_L3 PLL 

1.224 RE 1 PLL_BUFFER_X0_Y81_N0_I1 PLLBUF 

0 RE 1 CLKBUF_IN_X0_Y81_N5_I0 CLKBUF_IN 

0 FF IC 1 CLKCTRL_G2 clk~clkctrl|inclk 

0.207 FF CELL 2461 CLKCTRL_G2 clk~clkctrl|outclk 

0 RE 1 CLKCTRL_G2 TITAN_CLKBUF 

0.001 RE 1 CLKBUF_OUT_X0_Y81_N5_I0 CLKBUF_OUT 

1.443 RE 15 GLOBAL_CLOCK_X0_Y81_N0_I2 GLOBAL_CLOCK 

0.172 RE 22 SPINE_CLOCK_X190_Y122_N0_I11 SPINE_CLOCK 

0.153 RE 1 SCLK_TO_ROWCLK_BUF_X190_Y122_N0_I66 SCLK_TO_ROWCLK_BUF 

0.043 RE 2 SCLK_TO_ROWCLK_BUF_X190_Y122_N0_I68 SCLK_TO_ROWCLK_BUF 

0.2 RE 1 LAB_CLK_X191_Y122_N0_I0 LAB_CLK 

0.144 RE 1 BLK_CLK_BUF_X216_Y122_N0_I0 BLK_CLK_BUF 

0 FF IC 1 M9K_X216_Y122_N0 mem|auto_generated|ram_block1a0|clk0
0 Kudos
13 Replies
Altera_Forum
Honored Contributor II
1,189 Views

You can't actually bring the delay down. FPGA's have pretty long clock distribution networks and that's what you're seeing. 

But the skew is short, which what matters most. 

 

What's the path like?  

Internal or it involves I/O?  

Is it in the same clock or different clocks?
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

Hi, Many thanks. The clock constraint is about 7ns and I am missing by 17ns 

its going from altsyncram to output (single clock) 

Is there any switch I can give to quartus 

 

The rest of the path (which is the data path) looks like this (about 7 levels of combo lcells) 

 

0.181 RE 1 LOCAL_INTERCONNECT_X167_Y90_N0_I6 

0 RR IC 1 MLABCELL_X167_Y90_N10 

0.307 RR CELL 1 MLABCELL_X167_Y90_N10 

0 RE 1 MLABCELL_X167_Y90_N10 

0.119 RE 1 LOCAL_LINE_X167_Y90_N0_I5 

0 RR IC 1 MLABCELL_X167_Y90_N30 

0.307 RR CELL 1 MLABCELL_X167_Y90_N30 

-0.001 RE 1 MLABCELL_X167_Y90_N30 

0.04 RE 1 LE_BUFFER_X167_Y90_N0_I31 

0.113 RE 1 R4_X163_Y90_N0_I62 

0.14 RE 1 R4_X159_Y90_N0_I61 

0 RE 1 R20_C12_INTERCONNECT_DRIVER_X159_Y90_N0_I3 

0.227 RE 1 R20_X140_Y90_N0_I1 

0.133 RE 1 R4_X136_Y90_N0_I66 

0.185 RE 1 LOCAL_INTERCONNECT_X138_Y90_N0_I49 

-0.001 RR IC 1 MLABCELL_X138_Y90_N12 

0.307 RR CELL 1 MLABCELL_X138_Y90_N12 

0 RE 1 MLABCELL_X138_Y90_N12 

0.097 RE 1 LOCAL_LINE_X138_Y90_N0_I6 

0 RR IC 1 MLABCELL_X138_Y90_N16 

0.169 RR CELL 1 MLABCELL_X138_Y90_N16 

0 RE 1 MLABCELL_X138_Y90_N16 

0.105 RE 1 LOCAL_LINE_X138_Y90_N0_I8 

0 RR IC 1 MLABCELL_X138_Y90_N32 

0.079 RR CELL 1 MLABCELL_X138_Y90_N32 

0 RE 1 MLABCELL_X138_Y90_N32 

0.099 RE 1 LOCAL_LINE_X138_Y90_N0_I16 

0 RR IC 1 MLABCELL_X138_Y90_N36 

0.079 RR CELL 1 MLABCELL_X138_Y90_N36 

-0.001 RE 1 MLABCELL_X138_Y90_N36 

0.026 RE 1 LE_BUFFER_X138_Y90_N0_I36 

0.187 RE 1 R4_X135_Y90_N0_I65 

0 RE 1 R20_C12_INTERCONNECT_DRIVER_X135_Y90_N0_I3 

0.264 RE 1 C12_X135_Y91_N0_I0 

0.21 RE 1 C4_X135_Y98_N0_I35 

0.123 RE 1 R4_X132_Y101_N0_I50 

0.206 RE 1 LOCAL_INTERCONNECT_X135_Y101_N0_I22 

0 RR IC 1 MLABCELL_X135_Y101_N4 

0.231 RR CELL 1 MLABCELL_X135_Y101_N4 

-0.001 RE 1 MLABCELL_X135_Y101_N4 

0.026 RE 1 LE_BUFFER_X135_Y101_N0_I4 

0.168 RE 1 R4_X136_Y101_N0_I0 

0 RE 1 R20_C12_INTERCONNECT_DRIVER_X138_Y101_N0_I1 

0.277 RE 1 R20_X139_Y101_N0_I0 

0 RE 1 R20_C12_INTERCONNECT_DRIVER_X158_Y101_N0_I2 

0.311 RE 1 R20_X159_Y101_N0_I0 

0 RE 1 R20_C12_INTERCONNECT_DRIVER_X178_Y101_N0_I2 

0.279 RE 1 C12_X178_Y102_N0_I0 

0 RE 1 R20_C12_INTERCONNECT_DRIVER_X178_Y113_N0_I2 

0.291 RE 1 R20_X179_Y113_N0_I0 

0 RE 1 R20_C12_INTERCONNECT_DRIVER_X198_Y113_N0_I2 

0.288 RE 1 R20_X199_Y113_N0_I0 

0.334 RE 1 C4_X218_Y114_N0_I15 

0.117 RE 1 R4_X219_Y116_N0_I15 

0.173 RE 1 LOCAL_INTERCONNECT_X219_Y116_N0_I61 

0 RE 1 BLOCK_INPUT_MUX_X219_Y116_N0_I47 

0 RR IC 1 IOOBUF_X219_Y116_N113 

3.134 RR CELL 1 IOOBUF_X219_Y116_N113 

0 RR CELL 0 PIN_N5
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

Your output constrain it set based on which clock? 

 

That said, if you have a 7 ns period and you're missing it by 17.. well, I guess you have change your design a bit. 

Maybe make it so that the output is fed directly from a register?
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

Yikes. Turn off -show_routing and it's easier to read.  

The PLL is driving a global. You're not going to get much faster than that. (A regional is faster, but only if you're shaving off 1ns or so). The reason a PLL makes your output time faster is by compensating the clock, which should show up as a negative number. 

What's the clock period?  

The general recommendation is to register the output. 7 levels of comb logic won't have a very good Tco. Which you already know.. : )
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

Hi: I was under the impression that using a PLL gets rid of the clock network delay. 

Is this not correct? 

My design only has a single clock. In addition with only 7 levels of logic from RAM I think 

I should be able to do better than these numbers?
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

The PLL can compensate the clock network delay, in such way that the clock delivered to the FFs is actually in phase to the clock at the input pins, which may give you better I/O timing. 

 

You need to select the proper compensation mode. But best case, it will only shave ~4ns and you're missing by 17...
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

Hi, many thanks. I will take what I get and work grouping the rest of the logic. 

I was exactly referring to the compensation. How do I accomplish this.
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

I think you want to select the Normal Compensation mode.

0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

this is very strange. the megawizard generated pll has normal compensation set for my clock..

0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

Then the clock generated by the PLL is probably already 4 ns ahead of the PLL's input clock, in order to compensate the 4 ns delay through the network. 

 

But the 4 ns delay is always there and always shows up in the report.
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

The text you pasted started at: 

altpll_component|auto_generated|pll1|clk[1] 

Before that, in the timing report, there should be a line item called COMP. In an example I'm looking at, it's a -4ns delay. This is basically the PLL compensating for the clock tree delay by sending a clock out 4ns before the clock coming into the device. (It doesn't actually shift it back, it shifts it forward enough to look like a -4ns shift, but because it's a clock, you can't tell the difference). This is why I asked about the period. For example, if it were 10ns, then if you did a -10ns shift with your PLL, it may look like your timing got better, but you'd be back at where you started. But if it were a 40ns clock, then you could do a -10ns shift and should be fine.
0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

Normal compensation mode is the default for the PLL, and as someone pointed out, it compensates for the delay from the *input clock* to the internal registers. The important thing is that being on a global buffer with high drive, the skew is low between registers, which helps meeting timing for internal register-to-register paths. For I/O timing, you may want to do something different. For source synchronous input timing, you can try Source Synchronous compensation mode, which will maintain the relationship between the input data and the input clock. For output timing, you can try manually adding offset to the output clock in the PLL to adjust your clock skew (with the external capture clock).

0 Kudos
Altera_Forum
Honored Contributor II
1,189 Views

rysc and jimbo: many many thanks!

0 Kudos
Reply