Constraining SOPC Builder designs using TimeQuest

[Altera_Forum]

This document discusses how to constrain designs based upon SOPC Builder using the TimeQuest timing analzer. The constraints discussed in this document are associated with specifying clocks, I/O timing and false paths.

[Altera_Forum]

Thanks for the tutorial! 

 Do you happen to still have the complete demo-design with the tested SDC file(s)? I am one of those who never had timing issues with their small/medium designs before, but now have...  I am especially interested in properly constraining SDRAM/SRAM with Timequest - I followed your tutorial closely but for some reason my design fails all setup requirements for my SDRAM/SRAM input paths by a slack of about -5ns. This is @60MHz on a CycloneII quite much. Additionally there are setup violations for the ssram_clk_pin and sdram_clk_pin nodes - is this supposed to be not analyzed by a falsepath setting?  Snippets from my SDC file (my SDRAM has the same characteristics as used in the tutorial):  # ************************************************************** # Create Clock # ************************************************************** # both clock inputs are from the same crystal # feeds PLL for system clock and SDRAM create_clock -name {INCLK0} -period 30.518 # feeds PLL for SSRAM create_clock -name {INCLK1} -period 30.518 # ************************************************************** # Create Generated Clock # ************************************************************** derive_pll_clocks create_generated_clock -name {sdram_clk_pin} -source {clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk} -offset 0.500 create_generated_clock -name {ssram_clk_pin} -source {clkgen1|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk} -offset 0.500 derive_pll_c # ************************************************************** # Set Input Delay # ************************************************************** set_input_delay -max -clock sdram_clk_pin 6.100 }] set_input_delay -min -clock sdram_clk_pin 2.900 }] . . # ************************************************************** # Set Output Delay # ************************************************************** set_output_delay -max -clock sdram_clk_pin 2.600 }] set_output_delay -min -clock sdram_clk_pin -0.400 }] . .   TOP failing paths:   slack From Node To Node Launch Clock Latch Clock -5.750 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.750 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.739 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.739 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.732 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.732 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.730 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.730 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.730 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.725 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.725 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.722 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.722 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.720 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.714 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.714 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.712 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.709 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.706 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.706 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.705 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.705 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.702 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.702 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.702 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.702 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.702 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.701 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.701 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.701 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.690 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk -5.680 DRAM_DB sdctrl:\sdc:sdc|r.hrdata sdram_clk_pin clkgen0|\alt:v|sdclk_pll|\nosd:altpll0|pll|clk   Thanks for any hints or answers - and yes, I probably shouldn't follow blindly tutorials, but actually read the QII handbook to get my constraints right...

[Altera_Forum]

If you are seeing setup violation and no hold violations on your SSRAM and/or SDRAM timing then it would suggest that the PLL used to offset the clocks to these devices is not set up correctly.

[Altera_Forum]

Thanks for the hint! 

 I couldn't get back earlier, but now I should have tuned the PLL phaseshift correctly and I get no violations in the slow model. The fast model on the other hand has hold violations of about -2ns on all data (inout) lines and I seem to have no margin to get rid of this -2ns slack. All timing optimizations are already turned on. Well I better get started with the documentation...

[Altera_Forum]

The two related clocks (clk_a and clk_b) are created at page 4 of the document attached to the 1st post. 

These clocks have periods of 10 and 20 ns respectively as shown at the picture.   --- Quote Start ---  These can be assigned with the following commands: create_clock –period 10 –waveform {0 5} [get_ports {clk_a}] create_clock –period 10 –waveform {3 13} [get_ports {clk_b}]  --- Quote End ---   Is it correct?

[Altera_Forum]

This is an amazing resource! Timing constraints is probably the least understood aspect of FPGA development... and the most likely to get you banging your head against a wall asking god why nothing's working. And this document is the best, most clear explanation that I've found. (Which is to say: Altera, why don't you have any good docs on TimeQuest ?!?!) I also love the sheer style and organization. 

 However, I'm pretty sure page 9 is all wrong. I.e., using datasheet timing data to constrain an external interface. First of all, it is the max output delay (ie input setup time) that is negative, not the min output delay (the hold time). Reason for this is simple. The max output delay should be a large number, just like the max input delay. However, "setup time" is usually quoted as time _to_ the clock edge (eg 2ns) not from it (eg 18ns). So you have to negate it. Hold time, meanwhile, is quote _from_ the clock edge just like other delays.   The SDC should look like this:  create_generated_clock -name sdram_clk_pin -source $sdram_clk -offset 0.5 [get_ports {sdram_clk}] set_input_delay -clock sdram_clk_pin -max [expr 5.5 + 0.6] <ports> set_input_delay -clock sdram_clk_pin -min [expr 2.5 + 0.4] <ports> set_output_delay -clock sdram_clk_pin -max [expr -2.0 - 0.6] <ports> set_output_delay -clock sdram_clk_pin -min [expr 1.0 - 0.4] <ports>

[Altera_Forum]

I've been thinking a bit more about this and realized the stuff about board delay is off too. 

 Quartus II already compensates for pcb delay! Both in the clock and in the signals. It uses either capacitive load or a board model to calculate pcb delay and include it along with logic and fabric delay when meeting timing. (Of course you have to fill in all the data correctly first.) However it does this half-assedly. Literally. It only does this on the output pins, not the input puts.  If relying on Quartus's internal simulation and not using third-party SI tools, then the section of the SDC file should look like this. Note that neither the clock nor the output_delay is explicitly corrected while input_delay is corrected only for the trip back.  create_generated_clock -name sdram_clk_at_the_sdram -source $sdram_clk set_output_delay -clock sdram_clk_at_the_sdram -max <ports> set_output_delay -clock sdram_clk_at_the_sdram -min <ports> set_input_delay -clock sdram_clk_at_the_sdram -max <ports> set_input_delay -clock sdram_clk_at_the_sdram -min <ports>   If you ARE using third-party SI tools, set capacitive load for each pin to zero (and disable all the resistors and capacitors in the board model) to turn off Quartus' corrections. Then plug your precise board delay figures (or your conservative estimates) into the following. Keep in mind what the meaning of "longest" and "shortest" is. It could be you're putting several different signals in one command. But even a single signal will take a different time on a low-to-high transition than a high-to-low (not counting general randomness). Also remember that a signal hasn't transitioned until the voltage reaches the appropriate threshold. If you're jerry-rigging 3.3v TTL to 5v TTL, for example, then you have to keep this in mind when using your SI tools.  create_generated_clock -name sdram_clk_at_the_fpga_pin -source $sdram_clk set_output_delay -clock sdram_clk_at_the_fpga_pin -max <ports># sometimes the signal lags behind the clock. the max is lowered. set_output_delay -clock sdram_clk_at_the_fpga_pin -min <ports># sometimes it speeds ahead. the min is raised. set_input_delay -clock sdram_clk_at_the_fpga_pin - max <ports> set_input_delay -clock sdram_clk_at_the_fpga_pin -min <ports>  Note that you still have to create_generated_clock. Even with the pcb delay compensations turned off, it still calculates the fabric delay of the clock getting to that pin. If you use "zero delay buffer" and a dedicated PLL out then you can probably do without it. But I'm not sure you even need a zero delay buffer if you build your SDC file like this.

[Altera_Forum]

Oh, and the .doc should explain what exactly pcb delay is. It's not just the time that electricity takes to go through a wire, like a wave spreading down a canal. It's the time to actually send enough electrons into all the capacitors that are connected to that wire. If you load up a lot of components onto the same tristate bridge or if you turn the driving current way down, you will have a big pcb delay. That's what the "pin capacitive load" means. 

 But modeling the load as just one big capacitor isn't too accurate (well, it's still a hell lot better than nothing!). Use Advanced I/O Timing to simulate terminations if you're at all using them. Yet for all its additions Advanced I/O still assumes that the far-end load is just a capacitor. If you read DDR2 datasheets, for example, they'll often not tell you the capacitive load at all and instead print a warning that it's not so simple and that you should go use an IBIS file (which essentially replaces a single number with a graph). Third-party SI tools aren't that hard to use. HyperLynx in particular has a very easy interface.  But if you're not tight in your timing budget, don't get anal about things. Just insert safe guesstimates. If you don't even want to specify an Advanced I/O Timing model or dig through datasheets, you don't really have to. You don't need to spend the time to do that, but you DO have to follow template# 2 and insert appropriate guesstimates.

[Altera_Forum]

Oh, one more thing. Template# 2 assumes that the target is pipelined. Ie, you give it a command on one clock cycle, you get the response on the next. If the target works more like a combinational circuit, use this: 

 set_input_delay -clock sdram_clk_at_the_fpga_pin - max <ports> set_input_delay -clock sdram_clk_at_the_fpga_pin -min <ports>

[Altera_Forum]

--- Quote Start ---  The two related clocks (clk_a and clk_b) are created at page 4 of the document attached to the 1st post. These clocks have periods of 10 and 20 ns respectively as shown at the picture.  Is it correct?  --- Quote End ---    The waveforms show 10 ns and 20 ns period but the example SDC commands do not reflect this. The correct SDC commands are:  create_clock –period 10 –waveform {0 5} [get_ports {clk_a}] create_clock –period 20 –waveform {3 13} [get_ports {clk_b}]

[Altera_Forum]

--- Quote Start ---  This is an amazing resource! Timing constraints is probably the least understood aspect of FPGA development... and the most likely to get you banging your head against a wall asking god why nothing's working. And this document is the best, most clear explanation that I've found. (Which is to say: Altera, why don't you have any good docs on TimeQuest ?!?!) I also love the sheer style and organization.  However, I'm pretty sure page 9 is all wrong. I.e., using datasheet timing data to constrain an external interface. First of all, it is the max output delay (ie input setup time) that is negative, not the min output delay (the hold time). Reason for this is simple. The max output delay should be a large number, just like the max input delay. However, "setup time" is usually quoted as time _to_ the clock edge (eg 2ns) not from it (eg 18ns). So you have to negate it. Hold time, meanwhile, is quote _from_ the clock edge just like other delays.   The SDC should look like this:  create_generated_clock -name sdram_clk_pin -source $sdram_clk -offset 0.5 [get_ports {sdram_clk}] set_input_delay -clock sdram_clk_pin -max [expr 5.5 + 0.6] <ports> set_input_delay -clock sdram_clk_pin -min [expr 2.5 + 0.4] <ports> set_output_delay -clock sdram_clk_pin -max [expr -2.0 - 0.6] <ports> set_output_delay -clock sdram_clk_pin -min [expr 1.0 - 0.4] <ports>  --- Quote End ---    I have done some experimentation and believe that it IS the minimum output delay that should be negated. This is something I was told when I first start using TimeQuest. I am not sure why but I have given up trying to understand this long ago and now I just accept it.   For my experiment I implemented a D type FF in Quartus and ran TimeQuest with the following commands:  create_clock -period 20 [get_ports {clk}] set_output_delay -clock clk -min -1.0 [get_ports {q}]  You can see from the diagram attached that the effect of the output delay is to push the data required time out to the right which equates to a hold time of a device whose input is conected to the output of my FPGA.   There is a typo in the doc though as the example:  set_output_delay -clock sdram_clk_pin -min [expr 1 – (1.0 + 0.4)] <ports>  should read  set_output_delay -clock sdram_clk_pin -min [expr 0 – (1.0 + 0.4)] <ports>

[Altera_Forum]

Hmm. And what happens when min is positive? What about also setting a max (both positive and negative)?

[Altera_Forum]

Here is an updated version of the document that has some corrections based upon some of the comments in this thread. See the version history at the end for a list of changes.

[Altera_Forum]

That's great. I haven't looked at it yet, but could you edit your first post and put the file up at the top of the thread?

[Altera_Forum]

--- Quote Start ---  I've been thinking a bit more about this and realized the stuff about board delay is off too.  Quartus II already compensates for pcb delay! Both in the clock and in the signals. It uses either capacitive load or a board model to calculate pcb delay and include it along with logic and fabric delay when meeting timing.  --- Quote End ---      --- Quote Start ---  Oh, and the .doc should explain what exactly pcb delay is. It's not just the time that electricity takes to go through a wire, like a wave spreading down a canal. It's the time to actually send enough electrons into all the capacitors that are connected to that wire. If you load up a lot of components onto the same tristate bridge or if you turn the driving current way down, you will have a big pcb delay. That's what the "pin capacitive load" means.  --- Quote End ---     From the document attached to this thread:    --- Quote Start ---  There will also be some board delay due to the PCB track between the FPGA and SDRAM that will have be included by the user by use of the -offset option...  The mapping of external memory timing to FPGA I/O delays is noted in the table below. This also shows whether the minimum or maximum PCB routing delay should be used, which must be added to the FPGA delay constraints.  --- Quote End ---      alex_dubinsky is correct that Quartus calculates the output timing effect of the user-entered loading on output signals in combination with the drive strength. However, input and output timing constraints must account for the board trace delay. It takes time for data signals and clocks to propagate down a distance of board trace separate from the edge-rate effect of charging and discharging the transmission line or receiving-device input capacitance. The loading that Quartus accounts for does not account for the time for signals to propagate down the board trace. This board-delay timing effect of etch length must be included in the calculation of set_input_delay and set_output_delay values.  In system-synchronous interfaces (same system clock going to both the transmitting and receiving devices), the absolute delay for the board trace length in the data signals and the relative board delays for the driving and receiving device clocks (causing a clock skew) affects both setup and hold timing for I/O.  In source-synchronous interfaces (transmitting device drives both clock and data to receiving device) including DDR memory interfaces, designs commonly match the board trace lengths so that the absolute delay cancels out. The I/O constraints still need to account for the data-to-clock skew that can be caused by the potential mismatch in board trace lengths before the board layout is done or actual mismatch after the final trace lengths are known. Memory-interface MegaCore MegaWizards prompt for the absolute board delays or the trace-length mismatch so that the MegaCore-generated timing constraints can account for them.

[Altera_Forum]

--- Quote Start ---  I have done some experimentation and believe that it IS the minimum output delay that should be negated. This is something I was told when I first start using TimeQuest. I am not sure why but I have given up trying to understand this long ago and now I just accept it.  --- Quote End ---     I think in terms of tsu/th/tco/min tco and have not developed an intuitive sense of how set_input_delay and set_output_delay min and max work. After figuring it out once to satisfy myself that references that I use are correct, I just rely on those references.  A particular reference that helps me is in the Quartus handbook, Volume 3, Section II, Chapter 8 (in the QII 8.0 handbook), Table 8-4. This table says that minimum tco and set_output_delay are related by "set_output_delay -min <latch &#8722; launch &#8722; minimum tCO requirement>", which has the negation Graham mentioned. For hold timing using set_input_delay -min and set_output_delay -min, <latch - launch> is typically zero (same clock signal for launch and latch, no multicycle exceptions). That makes the set_output_delay -min value reduce to the negative of min tco.

[Altera_Forum]

I'm looking through the updated document Graham posted. I'll freely admit this is my first time using TimeQuest, and it's been more than 8 years since I had to do timing analysis (was working on other technology for a long time). The document is helping clear up a lot of misconceptions I had after viewing the Altera online training. 

 Can someone help me walk through the section on constraining RAM interfaces? I'm working on a platform based on the Arrow LPRP, which uses Micron Cellular RAM MT45W4MW16BCGB (and the Arrow SOPC builder components for the device).   Primarily, I'm lost by the explanation of how worst case timing is pulled from the datasheet - should I be looking for the lowest value in "access time" & "hold time" and the highest values in "setup time"?   Thanks, --Mickey

[Altera_Forum]

Very good documentation. Many thanks. 

 However, I have some questions.    (1) From Altera TimeQuest seminar, max output delay = (PCB) max data delay + (external device) tSU - min (PCB) clock delay. It is different from the "max output delay" in the document. The same is for min output delay and max/min input delay.   (2) From the document, slow asychronous I/Os such as PIO, uart, and SPI can be ignored by setting them to false paths within Quartus-II but outside of SOPC builder. Should the timing within the SOPC builder such as avalon fabric/bus be considered? Does the SOPC look after them automatically once they are set to false paths externally? The same question is for any new components in HDL.    (3) The clocks for a dual port on-chip ram can be considered independently. However, the clocks are used somewhere else in the design. In those places, they are pure multiple clocks. How can you handle that?

[Altera_Forum]

Hi, i'm trying to constrain my sdram controllers according to this post, but still have a few things that aren't clear.  

 1.) When assigning SDRAM pins to fast input and fast output registers. What do you do for the data lines that are bidirectional? Do you only set these to fast input or fast output or both?  2.) My design has a 50Mhz off chip oscillator feeding an internal pll and out of the pll is an 80Mhz clock that goes straight out a pin to an SDRAM and also internally the 80M clk drives my sdram controllers. I'm using a cyclone III. Should I break it up and use 2 clocks, 1 for the sdram clock pin, and one to drive my sdram controllers? Or will following this thread get me working with the single 80Mhz clock running everything?

[Altera_Forum]

Very useful stuff for me. One question if anyone is still paying attention to this years old thread. 

 On page 9 of the document where it is explaining constraining SDRAM it gives the following snippet:    --- Quote Start ---   The set_input_delay and set_output_delay commands can be used to set the I/O constraints. In the examples below, a common PCB routing delay of 0.5 ns ± 0.1 ns is used resulting in 0.4 ns or 0.6 ns being added to the timing information from the SRAM data sheet.  set_input_delay -clock sdram_clk_pin -max [expr 5.5 + 0.6] <ports> set_input_delay -clock sdram_clk_pin -min [expr 2.5 + 0.4] <ports> set_output_delay -clock sdram_clk_pin -max [expr 2.0 + 0.6] <ports> set_output_delay -clock sdram_clk_pin -min [expr -1.0 + 0.4)] <ports> In each of these commands, <ports> should be a list of I/O ports for the relevant constraints as shown in the example below: set_output_delay -clock sdram_clk_pin -max [expr 2.0 + 1.2]  [get_ports {cas_n ras_n cs_n we_n addr[*]}]   --- Quote End ---    I noticed that all of the memory access signals are included in the get_ports except for the data lines. Was that intentional or an error? Don't you need to specify the delay for the data lines as well in relation to the clock as well for when you are writing to the SDRAM?  Thanks,  David