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