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
9 years ago
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.
Altera_Forum
Honored Contributor
9 years ago
your failure reported (as per your previous post) violations from sdram_dq to za_data. So where is this path?
Altera_Forum
Honored Contributor
9 years ago
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
Altera_Forum
Honored Contributor
9 years ago
--- 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.
Altera_Forum
Honored Contributor
9 years ago
--- 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...
Altera_Forum
Honored Contributor
9 years ago
--- 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 ?
Altera_Forum
Honored Contributor
9 years ago
From your sdc commands I assume your sdram IF is not DDR. Hence why reduce available clock period by half?
Altera_Forum
Honored Contributor
9 years ago
--- 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"
Altera_Forum
Honored Contributor
9 years ago
SDRAM interface
Altera_Forum
Honored Contributor
9 years ago
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 ?

Forum Discussion

Timing Violations workaround strategy

39 Replies

Recent Discussions

Quartus 26.1 type inheritance bug.

Questa-ModelSim UI scaling problems in Linux

DisplayPort Sink (Quartus 18.1) – horizontal pixel offset.

QPP 26.1.0 Tools->Generate Simulator Setup Script produces no output

Questa - license problem