Honored Contributor
Honored ContributorThe following equations can be used for either a system-synchronous clock (same clock on the board going to both the FPGA and the SDRAM) or a source-synchronous clock (FPGA output driving clock to the SDRAM). For a source-synchronous clock, the board clock skew is simply the board delay from FPGA clock output to SDRAM clock input.
--- Quote Start --- output delay max = board delay (max) - board clock skew (min) + tsu (external device) output delay min = board delay (min) - board clock skew (max) - th (external device) --- Quote End --- As Rysc said, -reference_pin is used for a source-synchronous interface where FPGA output device pin sclk_p drives the SDRAM clock. If that's how your design is set up and if the board data delay and board clock delay between the FPGA and SDRAM are exactly matched, then the above equations reduce to what you're using: --- Quote Start --- output delay max = + tsu (external device) output delay min = - th (external device) --- Quote End --- --- Quote Start --- Why does the clock delay not play a part, seeing as the clock is external to both the FPGA and the RAM? --- Quote End --- Your question makes me (and Rysc) wonder if you have a system-synchronous setup. If that's the case, use the top equations above to account for your board delays and get rid of the -reference_pin arguments. The rest of this post is for a source-synchronous interface. If clk_133 is the clock setting on the FPGA clock input device pin, then to use clk_133 as the clock with -reference_pin requires there to be no keeper (register or port) between your FPGA clock input device pin and the sclk_p clock output device pin. Combinational logic in the clock path is OK with -reference_pin. You probably wouldn't be able to analyze timing at all if you violated this -reference_pin restriction, so I assume you have no register in this clock path. I'm mentioning it anyway for the benefit of others reading this. From check_timing on-line help: --- Quote Start --- The reference_pin check verifies that reference pins specified in set_input_delay and set_output_delay using the -reference_pin option are valid. A reference_pin is valid if the -clock option specified in the same set_input_delay/set_output_delay command matches the clock that is in the direct fanin of the reference_pin. Being in the direct fanin of the reference_pin means that there must be no keepers between the clock and the reference_pin. --- Quote End --- --- Quote Start --- Is it common practice to invert the launch clock (and delay it) to achieve setup times? --- Quote End --- You adjust the clocks as needed. Usually that's done with an adjustment to the FPGA output clock, which is the latch clock. When a 180-degree shift happens to work well, then yes, it is common simply to do an inversion for that regardless of whether a PLL is used. --- Quote Start --- This generally means you're sending a clock off chip alongside the data(the clock is sclk_p and the data is md_p*). In this scenario, much of the clock delay inside the FPGA cancels itself out. For example, if the clock tree is 2.7ns, it takes ~2.7ns to get to the data output register and ~2.7ns to get the clock to the port where it leaves the chip. These cancel each other out in the timing analysis(so if they were 100ns delays, you could still meet timing). --- Quote End --- This works best if you drive both data outputs and the clock output with I/O cell registers. You can use DDIO registers in the sclk_p I/O cell to drive the clock. Driving the clock with the DDIO registers and also driving the data outputs with I/O cell registers will align the clock output to the data outputs for 0-degree and 180-degree alignments. For this method, tie one of the sclk_p DDIO register inputs to a hard high and the other register input to a hard low. Swap the high and low between the registers to change between 0-degree and 180-degree alignments. The sclk_p frequency will be the frequency of the clock for these DDIO registers. You can use the DDIO registers with -reference_pin because the path that actually matters goes through a mux in the I/O cell that selects between the two registers; the clock output path is the combinational path through the mux select line, not a path through the DDIO registers. Even if you just need single-data-rate registers to drive the data, use DDIO registers for the data too so that their tco will better match the tco of the DDIO registers for sclk_p. For each single-data-rate output driven by DDIO registers, connect both register inputs to the single signal that you would normally connect to the input of a single I/O cell register. With the altddio_out megafunction, each bit of data connects to both datain_h[*] and datain_l[*] inputs of the megafunction.