Timing Violations workaround strategy

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:

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.

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

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.

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?

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?

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

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.