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

Timing Violations workaround strategy

Altera_Forum
Honored Contributor II
9,357 Views

Hello, 

 

Probably I didn't properly define timing constraints ... TimeQuest reported quite a lot of timing violations. 

In this connection I have one question - does exist some straightforward approach on working around "timing violations" ? 

For example on the image below there are 2 screenshots form TimeQuest: 

  • top screenshot - results of "Report Top Failing Paths" 

  • bottom screenshot - "Peport Timing" for the path, highlighted in yellow on the top screenshot 

 

 

So, in order to workaround timing violations on SDRAM data bus (blue cadre on the top screenshot) should I proceed with set_multicycle_path, e.g.: 

 

set_multicycle_path -setup -to [get_pins {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data 

[*]}] 2 

set_multicycle_path -hold -to [get_pins {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data 

[*]}}] 1 

 

or there are other solutions ? 

 

Thanks in advance. 

 

https://alteraforum.com/forum/attachment.php?attachmentid=13535&stc=1
0 Kudos
39 Replies
Altera_Forum
Honored Contributor II
1,900 Views

Multi cycle path is only an option if it really is a true multicycle path. Eg. From register to register that use the same periodic enable. 

 

If multi cycle is not an option, the easiest fix is modifying the code to increase the pipelining the design.
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

 

--- Quote Start ---  

Multi cycle path is only an option if it really is a true multicycle path. Eg. From register to register that use the same periodic enable. 

 

If multi cycle is not an option, the easiest fix is modifying the code to increase the pipelining the design. 

--- Quote End ---  

 

 

Can I make a conclusion from the left part of the bottom screenshot (i.e. waveform) that the only option is multicycle: lookeng at the image we can state that shifting forward latch edge by 1 cycle should resolve the problem, isn't it ? 

Concerning modifying the code, the code is very simple: it consists of instantiating of Qsys module (I put it below) ... or you mean modify Qsys ? 

By the way, I've tried multicycle option with following commands in .SDC file: 

set_multicycle_path -setup -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 2 

set_multicycle_path -hold -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 1 

 

Unfortunately they wasn't taken into account. Here is fragment of TimeQuest output: 

Ignored set_multicycle_path at SDC1.sdc(30): Argument <to> is a collection that is not of clk, kpr, reg, port, pin, cell or partition type 

set_multicycle_path -setup -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 2 

Ignored set_multicycle_path at SDC1.sdc(31): Argument <to> is a collection that is not of clk, kpr, reg, port, pin, cell or partition type 

set_multicycle_path -hold -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 1 

 

Here is top module: 

module nios_led2_top (input clk,  

input [9:0] sw, 

input [3:0] key, 

output[4:0] led_H, led_L, 

output [6:0] hex3, hex2 , hex1, hex0, 

 

output [12:0] sdram_addr, 

inout [15:0] sdram_dq, 

output [1:0] sdram_bank,  

output sdram_cas_n, sdram_ras_n, sdram_cke, sdram_cs_n, sdram_clk, 

output sdram_dqmh, sdram_dqml, sdram_we_n); 

 

wire [31:0] sseg; 

assign hex3 = sseg[31:24]; 

assign hex2 = sseg[22:16]; 

assign hex1 = sseg[14:8]; 

assign hex0 = sseg[6:0]; 

 

nios_led2_sdram u0 ( 

.btn_export (key), 

.clk_clk (clk), 

.led_h_export (led_H), 

.led_l_export (led_L), 

.reset_reset_n (1'b1), 

.sdram_wire_addr (sdram_addr), 

.sdram_wire_ba (sdram_bank), 

.sdram_wire_cas_n (sdram_cas_n), 

.sdram_wire_cke (sdram_cke), 

.sdram_wire_cs_n (sdram_cs_n), 

.sdram_wire_dq (sdram_dq), 

.sdram_wire_dqm ({sdram_dqmh, sdram_dqml}), 

.sdram_wire_ras_n (sdram_ras_n), 

.sdram_wire_we_n (sdram_we_n), 

.sseg_export (sseg), 

.switch_export (sw), 

.clk_sdram_clk (sdram_clk) 

); 

 

 

// nios_led2_nopll u0 ( 

// .btn_export (key), // btn.export 

// .clk_clk (clk), // clk.clk 

// .led_h_export (led_H), // led_h.export 

// .led_l_export (led_L), // led_l.export 

// .reset_reset_n (1'b1), // reset.reset_n 

// .sseg_export (sseg), // sseg.export 

// .switch_export (sw) // switch.export 

// ); 

 

endmodule
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

 

--- Quote Start ---  

Probably I didn't properly define timing constraints ... TimeQuest reported quite a lot of timing violations. 

--- Quote End ---  

 

 

1. Check if there are any ignored constrains.  

2. Check if there are any unconstrained paths.  

3. Check clock transfers and make sure that there are no invalid clock transfers analysed.  

 

 

--- Quote Start ---  

Does exist some straightforward approach on working around "timing violations" ? 

--- Quote End ---  

 

 

It depends what causes those timing violations.  

Violations between unrelated clocks or paths - usually can be solved by setting clock groups or setting false path between unrelated paths.  

Violations in register-to-register level - usually caused by bad coding style, go back to your VHDL/Verilog code and fix it.  

Violations in I/O - can be solved by using PLL and clock phase shift, clock inversion ect.
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

First, short remark concerning forum policy ... quite frequently a posted message doesn't appear immediately, but is retained for approval. 

And this approval can be as long as ... 24h. I asked for this issue to forum administration, but still didn't receive any answer. 

It occurred once more time yesterday: I answered to Tricky, but my message is still "in approval". 

 

Well let's return to subject ... 

 

--- Quote Start ---  

1. Check if there are any ignored constrains. 

--- Quote End ---  

 

Yes, there are 2 ignored constraints (as I've already exposed yesterday in my non-posted message). 

Trying to resolve the violations issues on sdram data bus (blue cadre on the screenshot in 1st message), 

I was thinking (probably wrongly) that the best solution here is to introduce multicycles, i.e. "open the window", using terminology of the ryan scoville's timequest user guide (at least as I understood it). 

Looking at the Waveform diagram in "Timing Report" for SDRAM data [6] (left part of bottom screenshot in the 1st message), one can believe that problem can be fixed by shifting forward the "latch edge". 

That is what I tried to do with the following commands: 

 

set_multicycle_path -setup -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 2 

set_multicycle_path -hold -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 1 

 

And these commands were ignored by TimeQuest parser. 

 

 

--- Quote Start ---  

2. Check if there are any unconstrained paths. 

--- Quote End ---  

 

No, after applying your suggestions (in another thread), there is no more unconstrained paths 

 

 

--- Quote Start ---  

3. Check clock transfers and make sure that there are no invalid clock transfers analysed. 

--- Quote End ---  

 

At 1st glance NO ... at least there is nothing "in red" 

 

 

--- Quote Start ---  

 

Violations between unrelated clocks or paths - usually can be solved by setting clock groups or setting false path between unrelated paths.  

Violations in register-to-register level - usually caused by bad coding style, go back to your VHDL/Verilog code and fix it.  

Violations in I/O - can be solved by using PLL and clock phase shift, clock inversion ect. 

--- Quote End ---  

 

 

In my simple case there are only a few clocks: external clock, 2 PLL generated clocks and JTAG clock - altera_reserved_tck

Concerning coding style - actually there is no code, only Qsys module instantiation. 

So, perhaps, my case correspond to "Violations in I/O" ? 

Here I have 2 questions: 

  1. The PLL module in Qsys has 2 ouput and one of them is phase-shifted. This phase shift isn't reflected in .SDC file ... I beleived that TimeQuest can handle this shift without .SDC modification (again probably I'm wrong) 

  2. So even in this case multicycles can't be considered as "reliable remedy" 

 

Thanks once more.
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

 

--- Quote Start ---  

The PLL module in Qsys has 2 ouput and one of them is phase-shifted. This phase shift isn't reflected in .SDC file ... I beleived that TimeQuest can handle this shift without .SDC modification (again probably I'm wrong) 

--- Quote End ---  

 

 

Yes, if you use derive_pll_clocks coammand PLL clocks are created automaticaly with correct parameters. You can check that in "Report Clocks".  

 

 

--- Quote Start ---  

So even in this case multicycles can't be considered as "reliable remedy" 

--- Quote End ---  

 

 

With multicycle exception you are only telling for TimeQuest how your design works. For example: 

  • for paths requiring more than one cycle for data to propagate you should apply multicycle path exception to "open the Window".  

 

[LIST] 

In some cases when TimeQuest does not properly detect launch and latch edges multicycle exception is used to properly define launch and latch edges ("shifting the window" for phase-shifted clocks).  

[/LIST] 

 

Multicycle exception can solve timing violations caused by incorrect timing analysis (wrong launch and lath edge relationship ect.), but multicycles can't be considered as remedy for any REAL timing violation. If you apply multicycle exception but your design does not work like that timing analysis will be incorrect. 

 

Provide clock report, clock transfer report, and detailed failing path report
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

Can you give more details? At first I assumed this was a regular input constraint, since the From Node appears to be a pin and the clock is external. But the Launch Clock path at the bottom starts at Pin AF14 and goes through the FPGA, where usually an external clock "just exists" and has no dependency on the delays inside the FPGA.  

Second, the clock appears to be phase-shifted from each other, where the latch clock's falling edge occurs shortly after the launch edge. This results in a 3.5ns setup relationship but the clock period is probably closer to 7ns or something like that. Where does this clock relationship come from? (I don't just mean "I put a phase-shift on the PLL", but in laymen's terms, just describe the interface, e.g. what the clock rates are, what the external delays relationships are, etc.) 

The reason a multicycle is unlikely to work is that the hold time gets pushed out too. In this case it would be 3.5ns. So in the fast corner the data delay would be 3.5ns, and as a quick rule of thumb I assume the slow corner is 2x the fast corner, meaning the delay would be at least 7ns. Actually, this might meet the new setup, but it's somewhat tight. So it might be possible. 

There are no recipes or formulas that work all the time. They key is understanding what analysis you're doing and how it relates to the hardware. If that doesn't make sense, you can never be sure about any solution. Anyway, please provide more info about what's going on.
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

First, thank you for feedback Ryan. 

My case seems to be quite simple ... instantiation of one Qsys module. 

The Qsys module consists of (please have a look at Qsys screenshot below): 

  1. CPU 

  2. PLL, that generates 2 clocks (1st – for all internal blocks, including CPU, 2nd – for external SDRAM) 

  3. SDRAM controller, connected to external SDRAM 

  4. GPIOs (buttons, switches, LEDs, 7-segment LEDs) 

  5. 2 timers 

 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13584 https://www.alteraforum.com/forum/attachment.php?attachmentid=13584  

 

And here is Qsys instantiation: 

module nios_led2_top (input clk, input sw, input key, output led, output hex3, hex2 , hex1, hex0, output sdram_addr, inout sdram_dq, output sdram_bank, output sdram_cas_n, sdram_ras_n, sdram_cke, sdram_cs_n, sdram_clk, output sdram_dqmh, sdram_dqml, sdram_we_n); wire sseg; assign hex3 = sseg; assign hex2 = sseg; assign hex1 = sseg; assign hex0 = sseg; nios_led2_sdram_10leds u0 ( .btn_export (key), .clk_clk (clk), .led_export (led), .reset_reset_n (1'b1), .sdram_wire_addr (sdram_addr), .sdram_wire_ba (sdram_bank), .sdram_wire_cas_n (sdram_cas_n), .sdram_wire_cke (sdram_cke), .sdram_wire_cs_n (sdram_cs_n), .sdram_wire_dq (sdram_dq), .sdram_wire_dqm ({sdram_dqmh, sdram_dqml}), .sdram_wire_ras_n (sdram_ras_n), .sdram_wire_we_n (sdram_we_n), .sseg_export (sseg), .switch_export (sw), .clk_sdram_clk (sdram_clk) ); endmodule  

 

The frequency of two PLL-generated clocks is 3 times input frequency (which is 50MHz). One of the clocks (that which clocks external SDRAM) is shifted -3.5ns in regard to another. I'm not sure if it's the optimal solution … this configuration I've adopted from a reference design of my board. 

 

Here is the content of the .sdc file: 

create_clock -name clk -period 20 create_clock -name {altera_reserved_tck} -period 40 {altera_reserved_tck} derive_pll_clocks derive_clock_uncertainty set_input_delay -clock altera_reserved_tck -clock_fall 3 set_input_delay -clock altera_reserved_tck -clock_fall 3 set_output_delay -clock altera_reserved_tck 3 create_generated_clock -name clk_ext_sdram -source .gpll~PLL_OUTPUT_COUNTER|divclk}] set_false_path -to # Constraint SDRAM DATA for input set_input_delay -clock clk_ext_sdram -max 0 ] set_input_delay -clock clk_ext_sdram -min 0 ] # Constraint SDRAM DATA for output set_output_delay -clock clk_ext_sdram -max 0 ] set_output_delay -clock clk_ext_sdram -min 0 ] # Constraint DRAM ADDRESS for output set_output_delay -clock clk_ext_sdram -max 0 ] set_output_delay -clock clk_ext_sdram -min 0 ] # Constraint SDRAM Controlss for output set_output_delay -clock clk_ext_sdram -max 0 sdram_dqm* sdram_cas_n sdram_ras_n sdram_cke sdram_cs_n sdram_we_n}] set_output_delay -clock clk_ext_sdram -min 0 sdram_dqm* sdram_cas_n sdram_ras_n sdram_cke sdram_cs_n sdram_we_n}] set_multicycle_path -setup -to }] 2 set_multicycle_path -hold -to }] 1 set_false_path -from set_false_path -from set_false_path -from * -to set_false_path -from * -to  

 

In this constraint file I derived PLL clocks and used one of them to constraint SDRAM data, address and control signals (e.g. cs_n, cke, etc.). Doubtless, the constraints I imposed are erroneous … as Timing Analysis reported a lot of violations. These violations I've tried to repair with help of multicycles (again, perhaps, it's not the best solution for such issues). Anyway these multicycles constraints were ignored. 

 

Is it possible, just looking at the constraint file (and taking into count the information from Qsys) do the first estimation what is wrong with constraints ? Perhaps, correcting some basic errors can avoid the majority of timing violations. And then (after repairing big blunders) pass to timing analysis using TimeQuest reports?
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

So the clock you're using for the input constraint is the clock you're sending out. I assume the clock goes out and data comes back in. So the -max and -min values would represent the max and min external roundtrip delay from clock going out to data coming back in. I would plug those values in, as they're going to be large and their variation will determine if this is possible. After that's done, you will probably have to change the phase-shift, and most likely will need a multicycle since the data will be coming back more than one clock cycle after it was sent. I am worried about min/max variatino being too large, but we'll see. 

Does the SDRAM read data at full rate, e.g. every clock that goes out you expect new data to come back, or is it slower?
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

 

--- Quote Start ---  

So the clock you're using for the input constraint is the clock you're sending out. 

--- Quote End ---  

 

For gpios I use false_path, as timing is non relevant for buttons, switches, LEDs. 

Input/output contraints I applied only for sdram interface 

Yes, I use clock that goes out for input constraints (sdram data) and also for output constraints (all sdram signals - data/address/controls). 

This clock is derived from pll and its frequency is 150 MHz (3 times input external frequency). It's also -3.5ns shifted. 

There is also another PLL-derived clock that clocks SDRAM controller. It's frequency is also 150MHz, but as opposed to the first one, it isn't shifted. 

The SDRAM controller is responsible for generating all SDRAM interface signals - data, address, control signals. 

As I've already mentioned previously I'm not sure that it's the optimal solution, I've just picked it from reference design. 

So, let's resume: 

  • clock, used for input/output constraints is 150MHz, and has shift -3.5ns  

  • input/output signals are formed in SDRAM controller that is clocked by the 150MHz 0-shifted clock 

 

 

 

 

--- Quote Start ---  

I assume the clock goes out and data comes back in. 

--- Quote End ---  

 

For clock - Yes, it goes out. For data - both directions ... i.e. data goes out and data comes in. It's cpu nios ii, that communicates with sdram and certainly necessitate data transfer in both directions (that's why I applied 2 types of constraints for sdram data bus - set_input_delay and setup_output_delay

 

 

--- Quote Start ---  

So the -max and -min values would represent the max and min external roundtrip delay from clock going out to data coming back in. I would plug those values in, as they're going to be large and their variation will determine if this is possible. 

--- Quote End ---  

 

Here I didn't properly understand what you mean. Could you, please, develop a little more this issue. 

Concerning these -max and -min values ... they are made up from (1) track delays and (2) external device setup. So, ideally, one can set these values at once ... (1) by examining board layout and calculating track delay (rough estimation - using simplified electromagnetic formulas, or fine estimation, using electromagnetic simulators (e.g. mentor graphics hyperlynx, ansys electromagnetics, cst studio, etc.) and (2) examining external device datasheet ? 

 

 

--- Quote Start ---  

After that's done, you will probably have to change the phase-shift, and most likely will need a multicycle since the data will be coming back more than one clock cycle after it was sent. I am worried about min/max variatino being too large, but we'll see. 

--- Quote End ---  

 

You mean change phase-shift in PLL settings for 2nd output ? ... and apply multicycle constraints to all sdram interface (i.e. data/address/controls) ? 

But, Ok, it will become perhaps more clear once I understand the previous point. 

 

 

--- Quote Start ---  

Does the SDRAM read data at full rate, e.g. every clock that goes out you expect new data to come back, or is it slower? 

--- Quote End ---  

 

I don't think so. Since it's cpu nios ii, that handles data transfer from/to sdram, there are probably "silent" periods, when there are no data transfer at all, e.g. CPU process the data that are already in CPU internal registers. 

 

Thanks once more.
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

Though I can't see your design details but my feeling is that your problem has nothing to do with io paths but is rather internal immediately before/after io. 

You can check io paths report in Timequest. 

Your io sdc constraints of zero all over are the best ever for any design as it gives full clock period room but certainly that doesn't mean they are right but are very relaxing and unlikely to fail. 

so in short I think you are looking to associate io sdc constraints with reported failures but I don't see any connection. You better identify what paths are failing.
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

The basic design details (e.g. Qsys screenshot, top-level Qsys wrapping (i.e. Qsys instantiation in the top module), constraints) I've mentioned in yesterday message. 

Perhaps you are interested in the properties of other Qsys components (e.g. CPU) ... because in my previous mail only PLL properties are displayed. 

Today, about 3 hours ago, I've posted new message with more details on my design and answers to Ryan questions. 

But actually this message is pending for approving ... I hope it comes in 2 ... 3 hours. 

 

 

--- Quote Start ---  

my feeling is that your problem has nothing to do with io paths but is rather internal immediately before/after io. 

--- Quote End ---  

 

You mean metastability issues ? I've just checked "io paths report": 16 violations on SDRAM data bus. 

In order to have more chances for this message to be posted immediately (i.e. avoid pending-approving), I don't attach TimeQuest screenshot. 

If my guess is correct (i.e. you mean metastability), how to apprehend from this TimeQuest report, that these violations are caused by metastability, but not by some other issues ? 

 

 

--- Quote Start ---  

You better identify what paths are failing. 

--- Quote End ---  

 

The 16 SDRAM data signals fail to pass TimeQuest analysis.
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

your failure reported (as per your previous post) violations from sdram_dq to za_data. So where is this path?

0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

The failed paths (if inputs to fpga) are clocked out by clk_ext_sdram according to sdc but are latched on divclk. This has resulted in a setup relationship of 3.5 instead of 6.667 and is the root cause of problem. Why not latch input with same clock as sdram clock

0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

 

--- Quote Start ---  

The failed paths (if inputs to fpga) are clocked out by clk_ext_sdram according to sdc but are latched on divclk. This has resulted in a setup relationship of 3.5 instead of 6.667 and is the root cause of problem. Why not latch input with same clock as sdram clock 

--- Quote End ---  

 

 

You mean why external sdram memory chip isn't clocked with the same clock as internal sdram controller ? This clocking schema I've picked from a reference design that was in support board package. By the way there was no any constraints on SDRAM interface I/O in the .sdc file.
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

 

--- Quote Start ---  

You mean why external sdram memory chip isn't clocked with the same clock as internal sdram controller ? This clocking schema I've picked from a reference design that was in support board package. By the way there was no any constraints on SDRAM interface I/O in the .sdc file. 

--- Quote End ---  

 

 

You are sending a clock to sdram chip as you have done (isn't it the clk_ext_sdram as named in your sdc). That is ok 

 

I am referring to your sdc constrains of set_input_delay/set_output_delay for sdram_dq. 

You are telling Timequest that sdram_dq data is clocked out from sdram chip on clk_ext_sdram. That is ok 

But you are latching it on divclk: is it also 150MHz and then why have you changed its phase. 

 

Although this clock of clk_ext_sdram is opposte data input but that is a trivial issue for now...
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

 

--- Quote Start ---  

But you are latching it on divclk: is it also 150MHz and then why have you changed its phase. 

Although this clock of clk_ext_sdram is opposte data input but that is a trivial issue for now... 

--- Quote End ---  

 

Yes, data that comes into FPGA (SDRAM controller IP to be precise) is latched by u0|pll|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk (which is PLL-derived clock with 0 phase shift). 

And the data launch clock is PLL-derived clock with -3.5ns phase shift, so the launch clock is about half-period "advanced" with respect to latch clock and respectively the latch clocks is half-period delayed with respect to launch clock. Correct ? 

Probably this half-period shift is intended to account for board propagation delay ? 

 

Anyway, if I properly understood, you propose to remove phase shift in launch clock. Correct ?
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

From your sdc commands I assume your sdram IF is not DDR. Hence why reduce available clock period by half?

0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

 

--- Quote Start ---  

From your sdc commands I assume your sdram IF is not DDR 

--- Quote End ---  

 

Sorry, I didn't understand, what is "sdram IF"
0 Kudos
Altera_Forum
Honored Contributor II
1,900 Views

SDRAM interface

0 Kudos
Altera_Forum
Honored Contributor II
1,750 Views

No, according to SDRAM datasheet, it's clocked on positive edge. So, you propose to remove phase shift on u0|pll|altera_pll_i|general[1].gpll~PLL_OUTPUT_COUNTER|divclk and consequently on clk_ext_sdram ?

0 Kudos
Reply