Constrain SDR and DDR interface on the same interface

[Altera_Forum]

Hello, 

 I have an IC that is outputting a databus with a center aligned clock. Depending on its mode, it is outputting in single data rate (up to 200MHz) or in dual data rate (up to 100MHz).  I find it difficult to constrain this. What I have now:  - First I created a clock with the SDR frequency and a second one with the DDR frequency on the same port (with the create_clock -add option). I also specified the waveform (180° shifted for SDR and 90° for DDR). The logic uses this clock, no PLL is used. - Then I created the same clock but virtual (no port assignment) and not shifted (data aligned).  So far so good. But when I want to apply set_input_delay on the databus once with the SDR virtual clock and once with the DDR virtual clock, I get following warnings from Quartus : Warning (332054): Assignment set_input_delay is accepted but has some problems at Project.sdc(211): Set_input_delay/set_output_delay has replaced one or more delays on port "DATA[5]". Please use -add_delay option.  I don't want to -add_delay because it's either this mode or the other mode. Or do I misunderstand this option?  Hmm while I'm typing this, it occurs to me. Should I constraint the rising edge with the SDR clock and the falling edge with the DDR clock? I just tried this and TimeQuest accepts it only if I use the -add_delay option. I'm still not sure if this is correct.  I've been reading the TimeQuest chapter from the Handbook, the TimeQuest Cookbook, the SDC reference, Application Note 433 and Rysc's TimeQuest User Guide (thanks Rysc, it has been very helpful!) but as a novice I'm still not sure how to handle my case. I hope on some feedback here ;).  Thanks! JBC

[Altera_Forum]

The set_input_delay basically says there is an external register driving that input port. The -add_delay option says there is another register driving that port, so they are basically mutually exclusive. (It will analyze as if SDR drives it AND DDR drives it). Note that 200MHz SDR and 100MHz DDR have data coming in that looks the same, so you would really be fine just constraining one. But for completeness, I think it will be something like so 

 create_clock -period 5.0 -name sdr_ext_clk -waveform {2.5 5.0} ;# Adding shift to show it's "center-aligned" create_clock -period 10.0 -name ddr_ext_clk -waveform {2.5 7.5} ;# Adding shift to show it's "center-aligned"  set_input_delay -clock sdr_ext_clk -max 1.0 [get_ports {ddr_in[*]}] set_input_delay -clock sdr_ext_clk -min -1.0 [get_ports {ddr_in[*]}]  set_input_delay -clock ddr_ext_clk -max 1.0 [get_ports {ddr_in[*]}] -add_delay set_input_delay -clock ddr_ext_clk -min -1.0 [get_ports {ddr_in[*]}] -add_delay set_input_delay -clock ddr_ext_clk -max 1.0 [get_ports {ddr_in[*]}] -clock_fall -add_delay set_input_delay -clock ddr_ext_clk -min -1.0 [get_ports {ddr_in[*]}] -clock_fall -add_delay  That's just off the top of my head so not 100%. Some notes: - I've seen some users have -add_delay on all I/O assignments. In the above case, I would have added it to the SDR input delay assignments. Basically, it doesn't hurt anything if you do this. - I'm pretending the data comes in with a skew of +/-1ns - Saying the data coming in is center-aligned can be done in multiple ways and you get the same results. For example, I could have not used the -waveform option in either clock, and instead when I put a create_clock on the clock coming into the FPGA, I could have put a -waveform {2.5# #} on that, which would say the clock coming into the FPGA has been phase shifted. If you draw out the waveforms you'll see they end up with the same relationships. Finally, I could have not used a -waveform at all, and instead increased the external delays by 2.5ns, i.e. a max of 3.5 and -min of 1.5. They should all give the same slacks, and really depends on how the user wants to describe their circuit. (Personally, I think shifting the clock coming into the FPGA makes the most sense, since that's how the external device center-aligns the clock, it shifts it before sending it to the FPGA. The reason I don't always do that is now any internal paths fed by that clock have that shift. So if it's a 10ns clock, then when looking at an internal path it will have a launch edge at 2.5ns and latch at 12.5ns. The shift gets cancelled out and has no effect on slack, but can be confusing if you're not watching out for it.)

[Altera_Forum]

I already drew the waveforms as recommended in your user guide and indeed noted that the relationships are the same. However you should see the datasheet of this IC which has some contradictory information and also lacking a lot of it. That being said, it could be that the SDR clock goes up to 135 MHz (I will see this when I have the PCB in my hands). So thank you for still explaining the global case. 

 Your assignments show that I am going the right direction. However I was using virtual non-shifted clocks for the set_input_delay. Does this make any difference? Does the -waveform option imply that the data on ddr_in[*] is center-aligned? I mean without the -waveform option, the clock and the data change at 0ns and with the -waveform option the clock change at 2.5ns and the data at 0ns. I hope I'm not confusing you, but it are small questions like these that make it difficult for me to fully understand how TimeQuest is working.  Once again thanks for your help Rysc! Not only for this reply but also for other of your posts and your user guide!

[Altera_Forum]

This is looking good in TimeQuest :). 

 Another small question: I get some hold violations on the paths from the FPGA pins to the first register where I clock the data on the falling edge. These hold violations are for the SDR clock and thus can be safely ignored. I was wondering how to specify these paths as false paths but only for the SDR clock. Something like this?  set_false_path -from [get_ports {ddr_in[*]}] -fall_to sdr_ext_clk

[Altera_Forum]

So physically you have DDR registers in the FPGA, and when in SDR mode you ignore the data on the falling edge register? Then that is fine. 

There are two main things that go into the requirement, the setup relationship and the -max external delay. So when I said there were three things to do the same thing, let's look at them for SDR 200MHz. 1) I say the external virtual clock is shifted 2.5ns and the clock driving the FPGA is not shifted. The setup relationship will come from a launch at 2.5ns and latch at 5ns, so 2.5ns. If the external -max delay is 1ns, then another 1ns is chewed up. (So basically the data can't be 1.5ns longer than the clock in the FPGA). 2) Now let's say we don't phase-shift the external clock but phase-shift the clock coming into the FPGA by 2.5ns. The launch will be at 0ns, the latch at 2.5ns, and again we have a 2.5ns setup relationship. 1ns of that is used up externally, and we have the same requirement on the FPGA. 3) Now let's say we don't phase shift anything. The launch is at 0ns and latch is at 5ns, for a 5ns setup relationship, but our external delay has been increased to 3.5ns, once again leaving 1.5ns for the FPGA to work with.  So all three of these are the same.  You mention that you're not using -waveform on the external virtual clock or the clock coming into the FPGA? If so, the setup relationship is 5ns and hold is 0ns. Let's pretend the external delays are 0ns for a moment. This is basically edge-aligned. For the FPGA to meet timing, it would need to add 2.5ns to the data path in order to get the most slack for setup and hold analysis. For example, if it added 2.5ns, it would have 2.5ns of setup slack and 2.5ns of hold slack. So this is edge-aligned. To make it say it's center-aligned, you can do one of the three things I mentioned.

[Altera_Forum]

The falling edge registers are indeed ignored in SDR mode. 

 I was wrong in my post, I do use the -waveform but on the clock coming into the FPGA. Thus using option 2.  Thanks for making things clear to me!