Constraining a design with "pass through" signals

Hello,

I have 2 input signals to my FPGA:

1. IN_CLOCK a 50MHz frequency clock signal with a 50% duty cycle.
2. IN_CONTROL synchronous to the IN_CLOCK and changes 4ns after the positive edge of IN_CLOCK.

The design requirement is to pass these signals through the FPGA without any logic or registers involved and maintain the same timing relation.


I'm trying to constrain my design - this is what I did so far:

Because IN_CONTROL is valid 4 ns after the edge of IN_CLOCK and my goal is to maintain the same ratio for the output - I figured out that 20ns - 4ns = 16ns is the correct number

Is it correct?

shaiko said:

Because IN_CONTROL is valid 4 ns after the edge of IN_CLOCK and my goal is to maintain the same ratio for the output - I figured out that 20ns - 4ns = 16ns is the correct number

Is it correct?

Click to expand...

I don't think so since there is no relationship in the FPGA design between IN_CLOCK and IN_CONTROL. The tools should probably generate a warning saying that the constraints you listed were ignored.

Kevin Jennings

So, what would you do to keep the same timing relationship between the signals?

The design requirement is to pass these signals through the FPGA without any logic or registers involved and maintain the same timing relation.

Click to expand...

IN this scenario, I wouldn't put any constraints in the SDC file.

So, what would you do to keep the same timing relationship between the signals?

Click to expand...

If you are not doing anything with the signals then why do you want to meddle with it unnecessarily?

If you are not doing anything with the signals then why do you want to meddle with it unnecessarily

Click to expand...

Because another device still has to work with these signals and I don't want to mess up their timing...

This is the problem at hand:
We have 2 signals, one of them is a clock and another is synchronous to that clock with a measured hold time of 4ns.
These signals travel inside our FPGA to output pins.

How would you ensure that the relation at the output remain 4ns ?

Because another device still has to work with these signals and I don't want to mess up their timing

Click to expand...

Is it not possible to put the constraint when you are doing SDC for the "another device"?

Is it not possible to put the constraint when you are doing SDC for the "another device"?

Click to expand...

I never said that the other device is an FPGA or that I have access to programming it.

@dpaul, the concern is that the dealy through the FPGA will not be well matched. For example, when the IO are in different IO banks that span the FPGA. Even after this, there can be issues with these delays changing when design congestion causes some of the ideal paths to be used for logic that actually has constraints.

@shaiko, You can use set_max_delay and set_min_delay. You may also want to create an empty design and create a dirt constraint for the resulting path.

shaiko, You can use set_max_delay and set_min_delay. You may also want to create an empty design and create a dirt constraint for the resulting path.

Click to expand...

Thanks.
Why what I wrote in #1 isn't good?

Because you don't have a clock. You have a signal that you've named "clock", but it isn't used as a clock anywhere in the FPGA.

Can you please post an example of how to keep the 4ns relation between the signals using the "set_max_delay" and "set_min_delay" constrains ?

In Synopsys, set_data_check is provided to constrain combinational circuits. Don't know if it's available in your tool.

I'm not entirely sure as I've never had this issue.

I mean, you can't do it. I mean you can, but with more delay.

As a combinatorial circuit, you could have variable delay with a skew based on tool-selected paths. Over PVT, these could give potentially significant delay.

But 50MHz is 10% or lower of FPGA max rates. This means the IO can be resampled and regenerated. However this means latency additions.

shaiko said:

So, what would you do to keep the same timing relationship between the signals?

Click to expand...

My first choice would be have the board route the clock and data to both the FPGA for input and whatever the other device is that needs to receive the signals. That is the best way to preserve whatever timing relationship that currently exists.

I'm assuming that the FPGA has some actual need for these inputs other than to buffer and re-drive. If not, they should be removed from the FPGA.

If the board routing is not an option and the FPGA needs the signals, then I would put the two inputs and the two outputs (i.e. all four pins), right next to each other on the FPGA. That gives the tools the best option for routing things to have nearly identical delays, even without constraints. To put a check on it, you will need to add a min/max propagation delay constraint to both sets of signals. You may need to do some trial and error to home in on the exact delay numbers since the absolute delay is not important, only the relative delay between the two. But again, if you put the signals on adjacent I/O pins, the router will almost have to use the most straightforward path to get there.

Kevin Jennings

My first choice would be have the board route the clock and data to both the FPGA for input and whatever the other device is that needs to receive the signals. That is the best way to preserve whatever timing relationship that currently exists.

Click to expand...

Impossible.

If the board routing is not an option and the FPGA needs the signals, then I would put the two inputs and the two outputs (i.e. all four pins), right next to each other on the FPGA. That gives the tools the best option for routing things to have nearly identical delays, even without constraints.

Click to expand...

Also out of the question. The board is manufactured and isn't going to change.

you will need to add a min/max propagation delay constraint to both sets of signals

Click to expand...

Can you please post an example ?

@shaiko, you will need to test out what min/max delay settings are possible. The issue is that you are routing through an FPGA, and likely through multiple silicon devices. These delays will have more variation than the routing on the metal layers of the device. As a result, over temperature the delays could change. If one signal is routed through both. As a result the 4ns might need to be 3-5ns or 4-7ns or etc for differences. For this reason, I suggest a blank design that you can use to quickly get results.

I think the syntax is just set_min_delay -from <pin1> -to <pin2> 1; set_max_delay -from <pin1> -to <pin2> -datapath_only 100; And then from there you would increase min delay and decrease max delay until they were close. datapath_only might not be required as it seems like it should be implied.

Xilinx doesn't provide much documentation on these, but there is one example: http://forums.xilinx.com/t5/Implementation/Trying-to-understand-delays-in-Vivado/td-p/475616

This seems to indicate that this might not be possible to do without regenerating the signals.


Unless you are using a dev-board, this should have never happened. It would have taken maybe a day to examine if this was possible and come up with a mitigation plan if not.

Unless you are using a dev-board, this should have never happened. It would have taken maybe a day to examine if this was possible and come up with a mitigation plan if not.

Click to expand...

I always prefer to solve board design problems at the board level instead of trying to work around it in silicon. It feels like trying to pick up an SMD resistor with chopsticks instead of tweezers.
Unfortunately it isn't possible in this case. The scope of the solution must remain in the FPGA.

shaiko said:

I always prefer to solve board design problems at the board level instead of trying to work around it in silicon. It feels like trying to pick up an SMD resistor with chopsticks instead of tweezers.
Unfortunately it isn't possible in this case. The scope of the solution must remain in the FPGA.

Click to expand...

The powers that be at your company need to understand one fact...

FPGA firmware isn't the same as soft firmware.

What you are asking for is physically impossible to do across PVT on any FPGA device. The best you can hope for is what Tricky suggested by placing the input/output pins next to each other on pins that have similarly matched package delays. Anything beyond that starts dealing with more and more of the on-die variation and PVT issues.

About the only thing you can do is attempt to guarantee that the one output shows up after the other with at least 4 ns of offset. In normal operation it will likely be much more than 4 ns as you'll have to deal with the PVT variations in the delays.

Maybe something like
set_min_delay 1 -from [get_port {pin_name_in1}] -to [get_ports [pin_name_out1}]
set_max_delay 2 -from [get_port {pin_name_in1}] -to [get_ports [pin_name_out1}]

set_min_delay 2 -from [get_port {pin_name_in2}] -to [get_ports [pin_name_out2}]
set_max_delay 3 -from [get_port {pin_name_in2}] -to [get_ports [pin_name_out2}]

where you want to guarantee that the pin1 in/out pairs arrive earlier than the pin2 output, though admittedly I'm not sure this will actually be applied to the design correctly (I never have had to do something like this).

If there is are external setup hold constraints between the signals that is being matched then, I would use set_input_delay and set_output_delay with a virtual clock along with the set_min/max_delay to constraint the entire path based on the required arrival at the destination. That might get you there but I wouldn't be surprised if you make more than one of these that you won't have timing issues on the real hardware.