How to constrain a source-synchronous desing?

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

My design outputs a 125Mhz Clk and 10-bit data to the downstream device.

The 125Mhz clock is inverted from a dedicated clock-pin.

The 10-bit data is launched at the rising edge of the original clock.

The downstream device requires a setup = 1.2ns and hold = 0.2ns.

My constrain command is as follows:

create_clock -period 8 -name clk [get_ports {clk_in}]

derive_pll_clocks

create_generated_clock -name clk_out -source [get_ports {clk}] -invert [get_ports {clk_out}]

set_output_delay -clock { clk_out } -max 2.0 [get_ports {da_t*}]

set_output_delay -clock { clk_out } -min -0.2 [get_ports {da_t*}]

The TQ report some SETUP SLACK.

If anybody can explain that for me?

Any and all help is very much appreciated

Harris

My undrstanding of output delays setting in TQ is:

Max = tSU + max data delay – min clk delay

Min = - tH + min data delay – max clk delay

Thus in your case it should be (ignoring board delays if clk delay = data delay):

max = 1.2

min = - .2

That gives a valid window of (your period - 1.2 - .2 = 6.6 ns) centred at 3.4ns from clk edge

When you say there is some setup slack, I assume you mean "negative slack", i.e. it's failing?

You have a 5ns setup relationship(10ns clk period with launch at 5ns and latch at 10ns), and an external delay of 2.0(I'm not sure how it went from 1.2 Tsu to 2.0, but that may be board delay, clock skew, margin, etc.). Anyway, that ends up with 3ns for the FPGA, which it should be able to meet pretty easily, since the clock and data delays shuld match.

Can you look at the data path going out(Data Arrival) and clock path going out(Data Required) and see if there is something physically different? The one thing I see commonly is that users use the dedicated PLL clock output, rather than just a regular I/O. That path doesn't use a global(would show up as type CLKCTRL in your data required path). Maybe post the timing report here.

--- Quote Start ---

You have a 5ns setup relationship(10ns clk period with launch at 5ns and latch at 10ns), and

--- Quote End ---

Can't understand what you say at all.

tSU is 1.2ns, tH is .2ns, clk period is 8ns, its SDR interface I presume. I don't know from where you got your figures to overwrite my posts.