Source-Synchronous I/F and sdc commmands

Complement my guide, and you automatically get help. :)

You're inverting the clock going off chip by inverting the inputs of the clock's altddio_out. Quartus/TimeQuest does not recognize this inversion, so when you put a create_generated_clock assignment on the output clock, you will have to add the -invert option.

You don't state if you're using a PLL. It doesn't matter much, but the constraints our slightly different. Basicall you will have:

1) create_clock on clock coming in.

2) derive_pll_clocks if using PLL.

3) create_generated_clock on output port sending clock going off chip. The -source will either be the output of the PLL or the input clock port(1). This will have a -invert option.

4) Two set_output_delay constraints on the data going out. The -clock will be the clock created in 3).

What this creates is a center-aligned clock going off-chip with the data. When you run report_timing -setup and report_timing -hold on the data output ports, you should see the setup relationship being half the clock period, and the hold relationship being a negative half clock cycle.

So let's say the clock rate is 10ns. Your setup will be 5ns and hold will be -5ns. From here you can change your set_output_delay constraints to cut into that. For example, if you increase the -max value to 2ns and the -min value to -2ns, that basically means there is +/-2ns of skew outside the FPGA, so the FPGA can skew the data by +/-3ns and still make timing.

Often the hardest part is this last part, because data sheets may not represent their numbers as skew, but as setup and hold, but they work quite similarly. If you made it this far, post what you have and what your analysis is.

WOW thanks for such a quick response !

This has, and still is, a very steep learning curve, but here's what i've found.

I set the constraints as you said, as follows

1)# the clock input to the device

create_clock -name src_clk -period 125MHz [get_ports src_clk]

2)# the clock output (inversion of input)

create_generated_clock -name inv_src_clk_out -invert -source [get_ports src_clk]

3)# set relationship between the clock going out and the data going out

set_output_delay -min 0.0 -clock [get_clocks inv_src_clk_out] [get_ports data_out]

set_output_delay -max 0.0 -clock [get_clocks inv_src_clk_out] [get_ports data_out]

which didn't meet timing and produced the following

(i've attached a txt version of this post as I couldn't get the diagram to display properly)

______

launch __| |_______

:

_______

latch _________|

:

: :

data arriv _________:_____:_______

_______________X________

: :

: :

: :

data reqd _________:_____:__

_________X_____:___

: :

: :

Relationship 4ns

Clock Delay : 3.249

Data Delay : 3.229

Data Arrival : 6.478

Data Reqd : 4

some clock uncertainty

Slack : -2.498

One thing i'm not sure about is that this 'model' does not take into account the delay of the clock through

the ALTDDIO cell which i've checked as being 5.075 ns (report -from src_clk -to inv_src_clk_out -through altddio cell)

Questions:

1) what happened to using virtual clocks ?

2) would i be correct in assuming that if this delay is added to the relationship somehow, this would then shift the

latch clock to the right by 5.075 ns giving me a new setup of 2.557 ns and meeting timing

3) do my set_output_delay commands need modifying as i'm not 100% sure i understand what they are doing.

TIA

Johnnyman

Just taking a quick look, one thing that jumps out is the create_generated_clock assignment doesn't seem to be applied to anything. You say what the -source is, i.e. where the clock comes from, but it needs to be applied to the output port. Something like:

create_generated_clock -name inv_src_clk_out -invert -source [get_ports src_clk] [get_ports clk_out]

Basically I just added the [get_ports clk_out]. Without that, it's a virtual generated clock, i.e. it exists outside of the FPGA. (I almost wish it would have errored out, but there are cases where people use virtual generated clocks). Anyway, once you add that, you're telling TQ where the generated clock exists, i.e. at the output port. It will use the delays all the way back to the source clock. When you do

report_timing -setup -detail full_path -npaths 100 -to [get_ports data_out] -panel_name "s: * -> data_out"

you will see the data required path starts at the clock coming in and traces all the way to the clock coming out.

1) For a source synchronous output, there is no virtual clock. Virtual clocks are when there is a board level clock that drives the FPGA and the external device. (I admittedly need to add a long write-up on source-synchronous interfaces).

3) You need to change the values from 0.0. Basically you need to account for board skew and requirements of the receiving device. Right now you have a 4ns setup and -4ns hold. That means the data could be skewed by +/-4ns and still meet timing. You're basically giving the entire data window to the FPGA to play with, but really some of it will be lost at the board level, some at the external device. Put down the external device specs and I might be able to help.

In general, you might want to start a new post. Since this one is from last March, nobody is going to see it. (I got an email because I had replied to it).

go to www.alterawiki.com and click on Popular Pages on the left. It should be about the 3rd one down. It covers this, but basically:

-max should be 2ns and -min should be -0.2.

(For the setup check, the data needs to get there before the latching clock. If you say the external delay is 2ns, then the FPGA's delay must be -2ns compared to the clock. Likewise on hold, the data must get there after the latch clock. If there's a -0.2ns delay, then the FPGA's delay must be +0.2ns to still be later than the clock.)