- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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|clk0Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.. : )- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think you want to select the Normal Compensation mode.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
this is very strange. the megawizard generated pll has normal compensation set for my clock..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
rysc and jimbo: many many thanks!

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page