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

SDC: forwarding clock with 90 degree offset

Altera_Forum
Honored Contributor II
2,110 Views

I am trying to setup a DDR source synchronous output interface in which the data/clock are center aligned. The obvious solution was to launch my data using a 0 degree clock, and forward the clock using a 90-degree phase offset version of the same clock. This way, the data is setup before the forwarded clock is sent out. 

 

I'm trying to constrain this interface to ensure the data meets the setup and hold time at the receiving device: 

 

create_clock -name CLK_ddr_ck -period $DDR_CLK_PERIOD [get_ports ddr_ck] 

 

set_output_delay -clock CLK_ddr_ck $tIS -max [get_ports $command_ports] 

set_output_delay -clock CLK_ddr_ck -$tIH -min [get_ports $command_ports] 

set_output_delay -clock CLK_ddr_ck $tIS -max [get_ports $command_ports] -clock_fall -add_delay 

set_output_delay -clock CLK_ddr_ck -$tIH -min [get_ports $command_ports] -clock_fall -add_delay 

 

I thought the tools would be smart enough to automatically determine that the ddr_ck pin is being output with a 90-degree offset, and the command_ports are being sent out via a 0-degree offset clock. But I'm not meeting timing.  

 

When I look at the time-quest analyzer, it says in the text that it is analyzing the correct launch/latch clock: pll1|clk[0] is the launch and CLK_ddr_ck is the latch, but the diagram shows that the launch and latch clock don't have a 90-degree offset. 

 

How do I inform the tool of my particular scenario?
0 Kudos
9 Replies
Altera_Forum
Honored Contributor II
916 Views

You need to put a generated clock on the port the clock is going out, something like: 

create_generated_clock -name ddr_clk_out -source {pll_90deg|outclk1} [get_ports ddr_clk_out] 

The tricky part is the -source. It should be the name of the PLL output that creates this clock. I recommend taking the existing design and run Report Clocks. Then look for that PLL output and see what it's target column is, as this is where the generated clock for the PLL is applied(the PLL output is constrained from derive_pll_clocks). This target will be the source of your generated clock. 

 

Use this generated clock as the -clock option in your set_output_delays. Now TQ knows how the clock leaves the chip and should see the 90 degree phase shift.
0 Kudos
Altera_Forum
Honored Contributor II
916 Views

ah okay. Thanks again. Looks like I was forgetting the -source field. So I guess one complaint I have in general about SDC is using the hard coded paths "pll_90deg|outclk1" which doesn't lend itself to portability, and plus I usually don't know the hard coded paths until I perform the build and zoom into the RTL aligned. I wish upon wishes I could just tell the tools "this is what I need to happen at the pins....does it?" Oh well maybe someday.

0 Kudos
Altera_Forum
Honored Contributor II
916 Views

I agree it's hard but in this particular case it is explicitly meant to be something physical in your design to show how it's hooked up. It doesn't have to be the PLL output, as it could be any point from that PLL to the output. For example, I think you could use the input of the IOCELL buffer as the -source, and it would trace back to the PLL and work fine. 

The idea is that if you have some level of hierarchy you're working on, let's say it's just the source-synch interface, you could say the generated clock on the output port is based on the input pin of your hierarchy. Then, when that hierarchy is stitched into a fuller design, it will go back and find the clock driving it, and is independent of what you hook it up today, i.e. it could be any PLL of any architecture, it could be a clock out of a transceiver, it could be a input port, etc. 

TimeQuest currently doesn't preserve the pin name on each hierarchy, so this flow doesn't work, but I've heard rumors that behavior may change, which would allow you to do what you want.
0 Kudos
Altera_Forum
Honored Contributor II
916 Views

So now I need to make the clock bi-directional. In some states, the FPGA is the source of the clock/data and everything in this thread is the same (using the 90 degree offset, using "create_generated_clock", etc). In other states, an external device is providing the clock/data, so the input timing is no longer relative to my internal 90 degree clock, but rather relative to the external clock directly. Should I have 2 "create_generated_clock" commands to separate the two modes, or just a single "create_generated_clock" that both input/output constraints refer to? I'm worried that the tools may try to relate the input timing to my 90 degree clock.

0 Kudos
Altera_Forum
Honored Contributor II
916 Views

It looks like the timing analyzer diagram doesn't "agree" with my desired scenario (output clock center aligned with outgoing data). 

 

It shows "Data Required" for setup transitions to the right of the clock. Shouldn't this be to the left since I want center aligned? 

 

See attached image. 

 

Was this not the correct constraint: 

 

create_generated_clock -name CLK_forwarded_DDRClk -source { inst5|altpll_component|auto_generated|pll1|clk[3] } [get_ports ddr_ck] 

set_output_delay -clock CLK_forwarded_DDRClk $tIS -max [get_ports $command_ports] 

set_output_delay -clock CLK_forwarded_DDRClk -$tIH -min [get_ports $command_ports]
0 Kudos
Altera_Forum
Honored Contributor II
916 Views

Your ideal latch clock is 2.5ns after the launch clock, and "center-aligned" to the latch clock, so the constraint looks good. Now when we get actual into the actual delays inside the device, the latch clock takes 3.292ns to get out, while the data delay takes over 5ns to get out. Why are they so different? You'll have to go to the Data Path tab and look at the details there. (Be sure to run report_timing with -detail full_path). For source-synch, the data arrival should start at time 0ns and take Xns to get out. The Data Required should start at time 2.5ns and also take ~Xns to get out. (Due to on-die varition, the delays will be different, but closer than what you're seeing.) I'm also concerned your external delay requirement is so large. At 3.5ns, it's actually larger than the setup relationship, so even if your clock and data did match, it would fail timing.

0 Kudos
Altera_Forum
Honored Contributor II
916 Views

You are correct in that it shouldn't be 3.5 ns. My mistake. And per your description, I now realize that I should look at the dotted-lines in TimeQuest to view the output pin analysis. It actually looks like what I need. Great! For your question on why the clock output delay and data output delay are so different....Beats me. As far as I know, I'm registering my outputs before sending them to pins. 

 

Looking at the report, it claims the data moves from DDIOOutCell to IOOBUF to PIN. The IOOBUF has an Incr amoutn of 4.449. 

Looking at the required path, it claims Pin to IOIBUF, to PLL, to CLKCTRL, to DDIOOUTCELL, to IOOBUF, to PIN.
0 Kudos
Altera_Forum
Honored Contributor II
916 Views

The reasons I can think of that might make it different. 

- Logic on data path. (unlikely) 

- IO registers not used. (pretty unlikely) 

- Different globals used for the clock driving the data versus the clock. (I've sen this more than once) 

- The IO delay chains are cranked up on the output path, or they have different I/O standards, one of which is much slower. If your data output is 4.449ns, what is the clock? In the fitter report, look at the IO Delay Chain Summary and see if the output chain is cranked up. This is usually due to I/O constraints that cause it to add delays. You would need to look at the hold analysis for this path too.
0 Kudos
Altera_Forum
Honored Contributor II
916 Views

I'm meeting timing now, I think the constraints are correct, and the interface is operating without any issues. Thanks again for the help!

0 Kudos
Reply