set_input_delay And set_output_delay .SDC Constraints

Thank you for your patience!

I think I have something fundamentally wrong.

Let's assume that there are two registers.One is the Input Register, and the other is a simple register somewhere in the design.

Now, when I set the output_delay to 26 ns, I imagine that the Input Register and the other register get clocked differently.

To me, the input register gets its clock pulse at 26, 26 + 37 , 26 + 2*37 ,..........., 26 + n*37......

And the other register is clocked at 37, 37 + 37, 37 + 37.

So, when I think like this, I imagine that whatever combinational logic is inserted between the register that gets clocked at 26, 26 + 37....(Input Register)

and the other register which gets clocked at (37, 37 + 37), has only 37 - 26 = 11 ns to settle.If instead we used back to back registers to just crossover from the input domain to the simple register domain, we'd have the complete 37ns between clock pulses?

--- Quote Start ---

Will the IO register(the one that has to read the value at the input pins) latch this value at t >= 26 ns?

--- Quote End ---

That is what input path timing pass/fail will tell you. If it passes or fails a second register after io is not going to do any good because that path is a new path that the tool takes care of. So you don't need to visualise what happens at that path, leave it to the tool.if any path in your entire design fails the tool will tell you.

--- Quote Start ---

This scheme is only for the input/output from the FPGA.

--- Quote End ---

Such scheme is not needed specifically for io. each io needs just one register. a second register can be added (back to back) but is not going to do much for timing. It is not the user responsibility to look after delay figures for internal paths. (only exceptionally one might do chip planning for some difficult paths).

back to back registers have very short routing, pass timing, do nothing apart from latency matching or random effect on overall routing.

I understand the register------>comb------>register part.But, kindly answer me this :

1) Let's say that at t = 0, we have a rising edge on the clock.

2) The external device outputs data at 26ns (TCO max).

3) Question :

Will the IO register(the one that has to read the value at the input pins) latch this value at t >= 26 ns?

If so, this value becomes available in the FPGA at t >= 26ns or (26/37) of the clk period? Would it not be better to add another register(cascade/series) that stores the value at the next rising edge? Doing so would use up one clock cycle though.

This scheme is only for the input/output from the FPGA.

Thank you!

--- Quote Start ---

Hello again!

I was wondering that since my design depends on detecting a pattern initiated when the external device outputs an 8'hFF, if I would not be better off using an additional register (in addition to the IO Register). I figure that if I use a comparator on the IO Register, it would only have 37ns - (26ns + TCO of IO Register) before the next positive clock edge, but if I use one extra register, it would give me nicely aligned data and a complete 37 ns while only increasing the latency by 1. Similarly, when outputting to an external device, one could add a simple register before the Final Fast Output register. In short, is it not better to have something like the following?

For Input :

Input Pins ---------------> IO Register ---------------> Register----------->Design

For Output :

Design------------> Register--------------> IO Register------------> Output Pins

I realize that all this may sound extremely repetitive, but it would go a long way in deepening my understanding if you confirm this.

P.S. (I just have a hard time wrapping my head around how the IO registers get sampled after the TCOmax of the external device).

Thank you!

--- Quote End ---

you are a bit off track on fpga timing strategy.

The io timing is your responsibility as a user. Beyond that inside fpga the tool takes responsibility of any register chain timing.

Your design will eventually needs register-comb-register chains and that will be managed by tool (and easily for 27MHz).

You are free to use such chains as required for your tasks. The depth of comb section is better kept short so that you achieve timing readily.

Hello again!

I was wondering that since my design depends on detecting a pattern initiated when the external device outputs an 8'hFF, if I would not be better off using an additional register (in addition to the IO Register). I figure that if I use a comparator on the IO Register, it would only have 37ns - (26ns + TCO of IO Register) before the next positive clock edge, but if I use one extra register, it would give me nicely aligned data and a complete 37 ns while only increasing the latency by 1. Similarly, when outputting to an external device, one could add a simple register before the Final Fast Output register. In short, is it not better to have something like the following?

For Input :

Input Pins ---------------> IO Register ---------------> Register----------->Design

For Output :

Design------------> Register--------------> IO Register------------> Output Pins

I realize that all this may sound extremely repetitive, but it would go a long way in deepening my understanding if you confirm this.

P.S. (I just have a hard time wrapping my head around how the IO registers get sampled after the TCOmax of the external device).

Thank you!

yes launching external device data on rising edge looks better in your case.

data and clock board delays are unique to your design. if both are equal, same material and thickness then you can ignore it. After all such delays are in picoseconds and if you are not sure you may just add extra margin on your sdc figures to further limit the sampling window e.g. 9/26 instead of 10/25

The theory goes too far to max/min of board delays but this only practically is worth checking in very fast paths.

Thank you so much!I am especially thankful for the last reply and configuring the IO registers as this was something I didn't even care to ask(and didn't know).

The device is configured via I2C to output data on either rising or falling edge.Initially, I thought that outputting data on the negative edge and sampling it on the positive edge would leave out one half clock cycle for set up time, but this seems to have been wrong.I can configure the device to output data on the rising edge and set min_delay to 10 and max_delay to 25.This should do the trick?

Now, I don't have values for board delay or clock skew.What do you recommend I do to incorporate this uncertainty as well?

Let's assume that board delay = b ns and that clock skew = +-c ns.

Then,

input_delay_min = 10ns + b - c.

input_delay_max = 25ns + b + c.

If the above equations are right, what values do I select for b or c? I apologize if this is something only I can know because I don't have any information about these parameters.

you are right about the meaning of these commands. You inform timequest what offset is coming of data relative to its clock edge launch.

so you are directly describing what the diagram is implying.

Then you are sampling data on the opposite edge. The fitter seems unable to manage that. By mis-informing the tool that it is relative to rise edge it managed that. You must enter the figures relative to falling edge i.e. 10/25. Or if you wish modify them to become relative to rise edge by adding 37/2 = 28.5/(43.5-37) i.e. 6.5/28.5 and so min/max offset also reversed.

It is obvious that the tool is happier if your figures of 10/25 were relative to rise edge but they are not. so either you sample on falling edge at fpga or use pll to invert the clock so you sample it on rising edge. The tool will be aware of that and should pass