Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17245 Discussions

TimeQuest & source-synchronous center-aligned input

Altera_Forum
Honored Contributor II
1,510 Views

Hi, 

 

I need to constrain a source-synchronous center-aligned input and I've been reading some Altera documentation, as well as Rysc's guide. However I am still not sure if I am doing the right thing. 

 

My data is center aligned, with the tSH 10 ns and the tH 10 ns, as seen here (http://imageshack.us/photo/my-images/705/rxtiming.png/). 

 

I must latch the data with the incoming clock (no PLL shifted clock possible). 

 

This is what I do: 

 

create_clock -name rxclk1 -period 40 [get_ports {rx_clk_1}]# clock pin 

create_generated_clock -name virtual_rxclk1 -source [get_ports {rx_clk_1}] -divide_by 1 -multiply_by 1 -phase 90 

set_input_delay -clock { virtual_rxclk1 } -max 10 [get_ports {rx_data_1[*] rx_dv_1}] 

set_input_delay -clock { virtual_rxclk1 } -min -10 [get_ports {rx_data_1[*] rx_dv_1}] 

 

Am I doing the right thing?
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
752 Views

Yes, it looks correct.

0 Kudos
Altera_Forum
Honored Contributor II
752 Views

These are confusing, so please verify that I'm reading it right. I assume the screenshot is of the transmitter, and it's Tsu and Th is saying what spec it can provide to the receiver. Is this SDR(single data rate or DDR)? I'm assuming SDR from the set_input_delay constraints(you only have 2, where DDR would have 4 assignments, basically two more with -add_delay -clock_fall). But if it's SDR, I don't know why it's only doing a 90 degree phase-shift. It's generally either 0 degrees(meaning it can't phase-shift) or 180 degrees. 

Being center-aligned, I would say the virtual clock is phase-shifted 180 degrees. That will give you a setup relationship of 20ns and hold relationship of 20ns. Your external delays of +/-10ns cut into that, leaving 10ns for the FPGA's setup analysis(i.e. a 10ns Tsu) and -10ns for hold timing(i.e. a 10ns Th).  

And looking at it more, it can't be DDR since that would be a 20ns data rate, and if 10ns Tsu and 10ns Th would use the entire data period. Let me know if that doesn't make sense.
0 Kudos
Altera_Forum
Honored Contributor II
752 Views

Hi, 

 

that would be the specification of a MII PHY from the FPGA point of view (as taken from PHY's datasheet - that' the incoming clock/data alignment). 

 

180° makes sense, I don't remember exactly why I used 90°.... I guess because most of the Altera AN use 90° shift with PLLs...
0 Kudos
Altera_Forum
Honored Contributor II
752 Views

I've mainly done rgmii, which is DDR. 

90 degrees centers the clock in the data eye for DDR, but 180 degrees does it for SDR. Be sure to look at the launch/latch edges for setup and hold make sure they make sense.
0 Kudos
Altera_Forum
Honored Contributor II
752 Views

So these constraints should be now correct, right? 

 

create_clock -name rxclk1 -period 40 [get_ports {rx_clk_1}]# clock pin 

create_generated_clock -name virtual_rxclk1 -source [get_ports {rx_clk_1}] -divide_by 1 -multiply_by 1 -phase 180 

set_input_delay -clock { virtual_rxclk1 } -max 10 [get_ports {rx_data_1[*] rx_dv_1}] 

set_input_delay -clock { virtual_rxclk1 } -min -10 [get_ports {rx_data_1[*] rx_dv_1}] 

 

Thanks again for the help!
0 Kudos
Reply