Hi All, I am having problems setting up my sdc constraints for a source-synchronous interface that i have. The design is described as follows. --- The FPGA provide a reference clk(125Mhz) to a SERDES chip. --- The SERDES chip ouputs a clk(62.5Mhz) and a databus(10-bit) to the FPGA. --- The 10-bit data should be sampled at both the rising edge and falling edge of the 62.5Mhz clk in the FPGA. My question is how to constraint set_input_delay in my design. I upload the SERDES chip datasheet with this post. Any and all help is very much appreciated Harris

Haven't looked at the .zip, but does is the clock/data edge aligned or center-aligned coming from the AMCC chip? If it's edge-aligned, are you using a PLL to phase-shift the clock 90 degrees? (Constraints can change based on how it's implemented, naturally, so asking before writing out a quick example).

Thanks for your response. Your answer is helpful for me. Would you please explain what condition the edge aligned will be applied and what condition the center-aligned aligned will be applied? Thanks Harris

If edge aligned: create_clock -period 16.0 -name ssync_clk [get_ports ssync_clk_in] derive_pll_clocks derive_clock_uncertainty create_clock -period 16.0 -name ssync_ext set_input_delay -clock ssync_ext -max 2.0 [get_ports {ssync_data[*]} set_input_delay -clock ssync_ext -min -2.0 [get_ports {ssync_data[*]} set_input_delay -clock ssync_ext -max 2.0 [get_ports {ssync_data[*]} -clock_fall -add_delay set_input_delay -clock ssync_ext -min -2.0 [get_ports {ssync_data[*]} -clock_fall -add_delay That assumes the PLL is shifting the clock 90 degrees to center it on the data. (It doesn't have to do that, but things get trickier). I put in delays of 2.0 and -2.0. Basically that says the upstream chip and board delays will skew the data by +/-2.0ns in relation to the clock. You need to change those to the correct value. # ################# If the upstream device sends its data center-aligned, then change the virtual clock to be: create_clock -period 16.0 -waveform {4.0 12.0} -name ssync_ext All that says is the clock is phase-shifted 90 degrees externally, so the clock is coming centered on the data eye. Your PLL shouldn't do a phase-shift now. (Oh, and when creating the PLL, make sure it is in source-synchronous compensation mode. At these speeds it probably doesn't matter, as you can make timing anyway, but it's good practice)

FYI, I always create a .tcl script called TQ_analysis that does something like: report_timing -setup -npaths 100 -detail full_path -from [get_clocks ssync_ext] -panel_name "ssync_inputs||setup" report_timing -hold -npaths 100 -detail full_path -from [get_clocks ssync_ext] -panel_name "ssync_inputs||hold" I add this to the project directory and access it from the Scripts pull-down menu in TQ. It analyzes setup and hold on these input paths. You should see a 4ns setup relationship and a -4ns hold relationship. That means the transfer can handle +/-4ns of skew on the data. You'll then see 2ns iExt delays, whcih says +/-2ns of that relationship is chewed up by our external delays, leaving 2ns of skew for the FPGA. Again, you'll have to change the external values. (Also, I've typed everything but not run it, so there probably will be typos)

Rysc, Thanks for your reply. I think I need some time to understand and try it. Harris

How to constrain a source-synchronous desing?

26 Replies

Altera_Forum
Honored Contributor
15 years ago
I don't see where in the example it says set_output_delay is the same thing as the traditional Tco? If it did say that, it's certainly wrong. The output delay is external delay to an external register, clocked by -clock. I don't even think of set_output_delay and set_input_delay as "constraints". They describe a circuit outside the FPGA. Once that circuit is drawn, we can determine the setup/hold relationships between the launch and latch clocks, the delays outside the FPGA, and finally the delays inside the FPGA to determine if it met timing.
(And I don't like "-reference_pin". It's easy enough to put a generated clock assignment on the output port being referenced, which allows the user to do many things with that generated clock. The -reference_pin can only be used in one manner.)
Altera_Forum
Honored Contributor
15 years ago
Harris,

I edited your sdc as follows, it performs better:

create_clock -period 8 -name clk derive_pll_clocks create_generated_clock -name clk_out -source }] set_output_delay -clock clk_out -max 1.2 set_output_delay -clock clk_out -min -.2
Rysc: Thanks for your response.

The whole system (input device,fpga,output device) must be viewed as one single rtl chain. In general, each launching register is used to fulfil timing of latching register.

The part of the rtl chain inside input device (except if it is another fpga or similarly configurable) does not have that versatility of fpga so the fpga is used to latch its data correctly.

The output device may be an advanced DAC that can latch correctly to any input automatically tracking the timing. Or it could be another FPGA. In these cases, no worry. Otherwise the fpga is used to ouput such that the device's fixed latching will work.

The fpga's tool to do that is by inserting delays between io register and pins to reconfigure its own tSU/tH for inputs and its tCO for outputs. Thus the fpga is a device with user configurable tSU/tH/tCO unlike most ASICs.

If you look at the diagram in the link, you will see a cloud between io register and the output data pin. This where delay is meant right inside FPGA.

Motreover, the statement clearly says: latency of data with respect to clk out
Altera_Forum
Honored Contributor
15 years ago
Do you mean, "In the circuit in Figure 2, the latency from the clk_in port to the clk_out port is included by the -reference_pin option"? It's basically saying the Tco to the -reference_pin is used, but the set_output_delay is still describing the delays outside the FPGA, and is not a directly replacement of Tco to the output. Only the -reference_pin option does this. This is another reason I don't like -reference_pin in that it's confusing. Does it include PLL phase-shifts or not? (I really don't know, but a generated clock will).
Altera_Forum
Honored Contributor
15 years ago
Either figure has a cloud of delay.
The statement itself is saying about set_output_delay:An output delay constraint on the data_out port, relative to the generated clock on the clk_out port.
I am not sure about reference pin issues but I don't see any reason to use it just to help remove one statement.
Altera_Forum
Honored Contributor
15 years ago
Harris and Rysc :

Using Harris mini-project I did some work on TimeQuest with regard to actual implementation of set_output_delay figures and realised that the equations are correct directly for tSU/tH but not for tCO.
The tCO is computed indirectly from tSU/tH as entered in the equations mentioned in this thread.
Thus the final example that I posted its link is misleading or out of date or badly worded.

Regarding skew: I found lowest data skew when I set all ten output registers to fast io
Altera_Forum
Honored Contributor
15 years ago
Rysc and Kaz,
I'm very grateful to you for your help.
I think I have got the result that I wanted.
Thanks.
Harris

Forum Discussion

How to constrain a source-synchronous desing?

26 Replies

Recent Discussions

USB-BlasterII mounts as "USB-Blaster variant"

Duplicate_hierarchy_depth / duplicate_register

Quartus messages web search goes to Intel

how to reduce clock skew between synchronous clock

Quartus - Users getting license Notification with new license applied