Timing Violations workaround strategy

--- Quote Start ---

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 ?

--- Quote End ---

For an SDR interface try first same phase and if you get into trouble then play with the phase.

Here is TimeQuest results with no phase shift between 2 PLL-derived clocks:

• 1st clcok clocks all Qsys modules (including SDRAM controller)

• 2nd clock clocks external SDRAM chip

Here is screenshot from 3 Qsys reports (hope that it will be published immediately, without n-hours pending/approving):

• Report Clocks

• Report Timing SETUP "to clock" u0|pll|altera_pll_i|general
• Report Timing HOLD "to clock" clk_ext_sdram

Surprisingly, in the "Report Clocks" there are only 1 PLL-generated clock, whereas I set 2 PLL outputs in Qsys

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

You better run TimeQuest GUI and check all failing paths and io paths.

Your setup report seems about internal paths [launch and latch are divclk] but your hold report is io path which shows some negative slack.

You need to check setup for io paths as well. Both inputs and output io paths need to be reported.

If io paths are failing you can use some phase shift to help it out [you can experiment on that].

For internal paths on 150MHz that is a design issue and basically 150MHz should not be a problem in many fpgas. But it is not clear why this failure occurs.

--- Quote Start ---

You better run TimeQuest GUI and check all failing paths and io paths.

--- Quote End ---

It's the case, I generated these reports in TimeQuest GUI.

I've just run failing paths - 200 violations (I suppose it's maximum that can be displayed, probably there are more ...)

--- Quote Start ---

Your setup report seems about internal paths [launch and latch are divclk] but your hold report is io path which shows some negative slack.

You need to check setup for io paths as well. Both inputs and output io paths need to be reported.

--- Quote End ---

Ok, I did it - there are no violations in "Report All I/O Timings"

--- Quote Start ---

If io paths are failing you can use some phase shift to help it out [you can experiment on that].

For internal paths on 150MHz that is a design issue and basically 150MHz should not be a problem in many fpgas. But it is not clear why this failure occurs.

--- Quote End ---

Do you mean here "Report All I/O Timings" ?

I would have thought that io failed hold time based on my reading in your second report as it is launch by divclk but latch by clk_ext_sdram.

So how could io report pass with no failure. Obviously I am mis-reading your reports. You are in a position to identify if io paths are ok. If so no need fr phase shift and your focus should be on the design. issues like using fitter settings, pipelining if available...I know it is qsys generated stuff but you can manipulate settings.

Ok, I'll try to "decorticate" Qsys-generated staff ... not sure it will be simple, taking into account that I'm not quite comfortable with TimeQuest.

--- Quote Start ---

I would have thought that io failed hold time based on my reading in your second report ...

--- Quote End ---

Do you mean my 2nd message on this thread ?

The design was modified since that moment ... e.g. 2 PLL outputs became in phase.

--- Quote Start ---

Do you mean my 2nd message on this thread ?

The design was modified since that moment ... e.g. 2 PLL outputs became in phase.

--- Quote End ---

I meant this last post from you:

Report Timing HOLD "to clock" clk_ext_sdram

It could be the clk_ext_sdram is latching e.g. m_dq to sdram_dq internally then sending it to sdram. But I thought you have defined clk_ext_sdram as generated output clock.

Looking at the path for the clock going out to SDRAM and data coming back. Let's start with the case where you use the same clock to launch and latch the data, so there is a 0ns hold relationship and 7.5ns setup. Let's say the external delay -max and -min are both 0ns. If you compile and your setup slack is 1ns and your hold slack is 3ns. To think of what's going on, let's say the clock skew is 0 inside the FPGA. (This is weird, as the clock feeds the latch register, but it doesn't feed an actual launch register. Let's just say it's the output register). Anyway, by having 1ns of setup slack, it means the clock got out through the output buffer and came back in through the data input buffer and to the register in 6.5ns. So your max data delay is 6.5ns.

By having 3ns of hold slack, we're saying this same delay in the Fast Timing Model was 3ns.

Of course, your external delay is not 0ns. Let's say the SDRAM's TCO has a max of 8ns and min of 4ns. So if you change the external delays to this, with the same fit, you would end up with setup slack of -7ns and hold slack of 7ns.

So we're missing timing by a lot. You could add a multicycle setup of 2 and multicycle hold of 1, so that your now trying to latch on the next falling edge at time 15ns, e.g. when a clock edge comes in at time 0ns, it will go out of the FPGA to the SDRAM, have data come back, and you'll latch that at time 15ns. You will also have a positive hold relationship of 7.5ns, meaning that whole delay must be greater than 7.5ns.

Since your FPGA delay was 6ns and you added 8ns for the external delay, the total is 14ns and your actually making setup. But your fastest delay is 7ns and you need it to be 7.5ns. THis is where it gets tricky, as the fitter can turn up delay chains/routing to try and meet hold. But let's say it adds 0.75ns of delay and now it's meeting hold in the Fast Corner. As a general rule of thumb, I say the slow corner is 2x the Fast Corner, so this would add 1.5ns of delay to the slowest delay, e.g the FPGA data path becomes 6+1.5=7.5ns and then with the 8ns external delay you're now failing setup rlationship 15ns.

This is just an example, but you do need to figure out the external delays because I don't know if you're in the right ballpark of whether this is feasible, as 150MHz is pretty fast for SDRAM interface.

Now, it may be that you don't read on every cycle, e.g. it may be every other cycle at best. In that case, your setup relatinoship could be 15ns but your hold could be 0ns, in which case the fitter would never need to add delay to meet hold timing, as it would automatically meet the hold.

Ryan, first thank you for explanation.

Nevertheless, I remains a little bit confused.

Primary question - "What to start with ?"

timequest generates multitude of different reports ... What report to start with ?

I passed trough all selected those with timing violations.

Here below the short resume of timing violations output by TimeQuest:

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

There are 3 "sections", where I've found timing violations:

1. Summary (Setup), where violations are related to the clock ...divclk. Time report "To clock" followed divclk and revealed 10 violations

2. Summary (Hold), where violations are related to the clock clk_ext_sdram. Time report "To clock" followed clk_ext_sdram and also revealed 10 violations

3. Report failing path - revealed 200 violations, realted to ...divclk for both launch and latch clocks and nodes are internal, i.e. no external ports

What section should I explore ... and apply thze consideration you exposed in your previous post ?

Thanks.

I'm using a SDRAM at 100 MHz clock whit the SDRAM controller in QSYS (altera_avalon_new_sdram_controller). For calculation the shift between the controller clock and the external clock I used the Embedded Peripherals IP User Guide (UG-01085 2016.12.19, page 2-10).

In the .sdc I defined a setup multicycle for shifting the window:

set_multicycle_path -from [get_clocks SOPC|sys_pll|clk_100] -to [get_clocks virt_100MHz_clk] -setup 2

These clock groups must related in timequest, do not use set_clock_groups -asynchronous/ -exclusive.

Here you is a good guidance for this toic:

http://retroramblings.net/?p=515

regards

Jens