Constraining SOPC Builder designs using TimeQuest

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

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

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

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?

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?

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