Source-Synchronous I/F and sdc commmands

[Altera_Forum]

Hi All, 

I am having problems setting up my sdc constraints for a source-synchronous interface that i have.   I have looked through Rysc's TQ User Guide (excellent piece of work !) and Altera's equivalent and whilst they both have examples that are similar to my situation, there are subtle differences and I just can't seem to get my head around producing sdc commands for my situation - which is as follows.   -- I have a 125MHz clock that originates from a dedicated clock-pin   -- 10-bit data is read from a fifo into a register (both clocked using the 125MHz clock)   -- The clock and registered data are then sent of-chip. o The registered data is placed in an I/O cell. o The clock is fed through an ALTDDIO_OUT cell with the 'l' and 'h' inputs connected to '1' and '0' respectively so as to invert the clock on the way out, hence, producing a centre-aligned clock for the data. -- The data is registered into an I/O cell at the receiving end of the link using centre-aligned clock.     The real problem i'm having is getting my head around how to specify all the relationships in sdc commands.   I might also add that this is the first sdc file i have ever had to produce so am new to it, hence the penny hasn't quite dropped yet.   Any and all help is very much appreciated   Johnnyman

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

If the external device requires the Tse = 1.2ns and Th = 0.2ns, How to constrain the set_output_delay -min -max. By the way How can i get the Rysc's TQ User Guide? Thanks

[Altera_Forum]

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

[Altera_Forum]

Thanks, I am going to submit a new post