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

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 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

--- 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.

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: 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) So even in this case multicycles can't be considered as "reliable remedy" Thanks once more.

--- 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

Timing Violations workaround strategy | Altera Community

39 Replies

Altera_Forum
Honored Contributor
8 years ago
Hi Jens,

A couple of questions:
Did you apply multicycle constraint at once ... or after running TimeQuest (and analyzing results) at least one time ?
What is virt_100mhz_clk? Is it external clock or PLL-generated clock ?
Did you try to workaround timing violations by tuning the phase shift between "sdram clock" and "sdram controller clock" ?

Thanks

P.S. I've just run timing analysis without multi-cycle constraint, but applying phase shift between 2 PLL-generated clocks (according to approach from embedded peripherals ip user guide, pp. 2-10 ... 2-14).
Also I applied input and output constraints calculating them according to "demystifying timing constraints" from your link.
Here is the content of my .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}] # Constraint SDRAM DATA for input set_input_delay -clock clk_ext_sdram -max 6.4 ] set_input_delay -clock clk_ext_sdram -min 1.0 ] # Constraint SDRAM DATA for output set_output_delay -clock clk_ext_sdram -max 1.5 set_output_delay -clock clk_ext_sdram -min -0.8 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

The 1st location where I consult timing violations is "Report all I/O Timings".
There are 16 timing HOLD violations (related to SDRAM data) and 55 SETUP violations (related to all (at 1st glance) SDRAM ports).
Surprisingly launch clock and latch clock are the same. Any comments.
Thanks.

Here is screenshot for HOLD violations.
https://alteraforum.com/forum/attachment.php?attachmentid=13664&stc=1
Altera_Forum
Honored Contributor
8 years ago
Hi Pavel,

1. Yes at once becaus the fitter is using timing constraints.
2. It's the virtual clock for the I/O timing analysis (see Quartus II Handbook, QII5V3 2015.05.04. p. 7-14 or the TimeQuest User guide from Ryan Scoville, http://www.alterawiki.com/wiki/timequest_user_guide)
3. No, I use the shift calculated according the Embedded Peripherals IP User Guide

Do you drive the internal sdram_controller with the same clock as the external SDRAM device? The external clocks should be shifted. In your screenshot the launch clock should be the external shifted clock and the latch clock is the internal clock. The multicycle -setup constraint is used to tell Timequest what is the right latch edge.
Altera_Forum
Honored Contributor
8 years ago
Hi Jens,

1. yes at once becaus the fitter is using timing constraints.
Well ... this is probably a critical point that I fail to understand: after all timing relations e.g. clock/clock, clock/interface signal are influenced by routing.
Here I mean that fitter can be quite "smart" and will route all tracks so that NONE adjusting with PLL clock shifting or multicycle is necessary.
But this can be known AFTER fitting is run at least one time. Or I missed something ?

2. it's the virtual clock for the i/o timing analysis (see quartus ii handbook, qii5v3 2015.05.04. p. 7-14 or the timequest user guide from ryan scoville, http://www.alterawiki.com/wiki/timequest_user_guide)
In these two sources virtual clock is created because it's external (i.e. generated OUTSIDE FPGA) whereas on my board both "SDRAM clock" and "SDRAM controller clock" are generated INSIDE FPGA.
Is it also your case ?

3. no, i use the shift calculated according the embedded peripherals ip user guide
Ok, but I meant something other. It seems that in the "Embedded Peripherals IP User Guide" this shift is used to setup phase shift between 2 clocks, generated by PLL and it's the ONLY remedy against timing violations ... because they don't mention multicyling. My question was about eventual possibility to use ONLY phase shift for timing violation workaround (without any multicycling). Did you try this ?

do you drive the internal sdram_controller with the same clock as the external sdram device? the external clocks should be shifted.
No, they are driven by 2 clocks. These 2 clocks are PLL-generated and shifted one relative to other according to "Embedded Peripherals IP User Guide" procedure.

in your screenshot the launch clock should be the external shifted clock and the latch clock is the internal clock.
That is strange because clk_ext_sdram is actually u0...divclk.

the multicycle -setup constraint is used to tell timequest what is the right latch edge.
I considered that timequest is quite "smart" and capable to deduct it itself.
After all, multicycle option isn't mandatory, how TimeQuest manage this if there is no multicycling.

Thanks once more.
Altera_Forum
Honored Contributor
8 years ago
1. If you look at the fitter messages you can see something like this:
"Info (332104): Reading SDC File: 'project_timing.sdc'"
I think fitter use constraints for controlling desing optimization.

2. The virtual clock is just used outside the FPGA. No internal logic is driven from this clock but it's from the PLL inside.

3. Yes I do. Sometimes it works. But if you want closure timing than you have to use the rigth constraints.

Jens
Altera_Forum
Honored Contributor
8 years ago
1. Sure, it does. But once again, when you are starting to work with your design and didn't run TimeQuest, how can you know beforehand that multicycle constraint is necessary for this particular design ?
At the beginning you have no any information how your design will be fit, isn't it ?
I perceive applying timing constraint as "iterative" process: when starting with design the timing constraints should be as relaxed as possible ... only the mandatory ones (e.g. create_clock, etc.)
Then, running TimeQuest and analyzing results, you apply additional constraints (e.g. multicycling) if necessary to get finally your design without timing violations.
But applying multicycling "at once", without any feedback from TimeQuest ... frankly speaking I don't understand.

2. So, on your board the SDRAM chip is clocked by an external clock, and NOT by one, coming from FPGA ?

3. So, first you try to resolve timing issues using shift between two PLL-generated clocks and when this shift isn't sufficient, you use multicycling. Correct ?
Here I didn't understand one thing: if you use (like me) two PLL-generated clocks (one - for SDRAM chip, other - for SDRAM controller), what is usage of virtual clock ? What it clocks exactly ?
Altera_Forum
Honored Contributor
8 years ago
Pavel, you are rigth constrain timing is an iterative process.
No the SDRAM is clocked from the FPGA. As I wrote the clock does not drive any internal logic but it comes from an internal PLL.
This virtual clock is used to constrain the I/O timing like:

set_output_delay -max $SDRAM_MAX_OUT_DELAY -clock virt_100MHz_clk [get_ports SD_DATA*]

Jens
Altera_Forum
Honored Contributor
8 years ago
--- Quote Start ---
Pavel, you are rigth constrain timing is an iterative process
--- Quote End ---

So, you confirm that when you start working on your project (i.e. design is accomplished in Quartus/Qsys, but isn't compiled yet), you have no any idea how how design will be fit during compilation.
Consequently you can't apply any "hard" constraints (e.g. multicycling), but only the very basic ones (i.e. creating clocks), isn't it ?
That's why I was surprised when you said that you apply "multicycling" constraint "at once" (i.e. without preliminary compilation or TimeQuest run).
Or I misunderstood your approach ?

--- Quote Start ---
No the SDRAM is clocked from the FPGA. As I wrote the clock does not drive any internal logic but it comes from an internal PLL.
--- Quote End ---

If you have no any additional clocks on your board (except basic clock), what sense to create virtual clock ?
In all manuals virtual clock is created to "emulate" some external clock.

--- Quote Start ---
This virtual clock is used to constrain the I/O timing like:

set_output_delay -max $SDRAM_MAX_OUT_DELAY -clock virt_100MHz_clk [get_ports SD_DATA*]
--- Quote End ---

Why not use PLL-generated clock for this ?
Altera_Forum
Honored Contributor
8 years ago
I use all timing constraints in every synthesis run (not just for timing analysis with Timequest). Finding the right ones it's an iterative process. Before you can run Timequest you have to do a complete fit. First I assign basic constraints (base clocks, virtual clocks, I/O delays, derive_pll_clocks, derive_clock_uncertainty, set_clock_groups)

The virtual clocks are for I/O timing analysis, please refer TimeQuest Timing Analyzer Cookbook (MNL-01035 2016.2.25, page 9)

Jens
Altera_Forum
Honored Contributor
8 years ago
For internal paths on 150MHz that is a design issue and basically 150MHz should not be a problem in many fpgas.

Forum Discussion

Timing Violations workaround strategy

39 Replies

Recent Discussions

Is Quartus Prime Pro 22.4 Compatible with Stratix 10 NX Series Device?

Timing analysis - long combinational path

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer

Duplicate_hierarchy_depth / duplicate_register

Automatically added negative node for TDS output doesn't work with Agilex 5