Constrain SDR and DDR interface on the same interface

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.)

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!

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

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.

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!