set_input_delay And set_output_delay .SDC Constraints

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

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

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.

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

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 End ---

Each register has its own tCO. In your case the external device has tCO max of 26ns and assuming it stays so at fpga pins.

The fpga registers have their own tCO and a fast io register is expected to have its tCO short enough (that is why we say fast io register).

The clock period is 37 ns for all paths clocked by that clock but the window available for sampling is much less on any path because it starts from max tCO moment and ends at tSU restrictions.

The tCO at any register should be as short as possible without hitting back on tH of previous latch edge, and shouldn't be as long as to hit tSU of next latch edge.

The fitter ensures tCO doesn't hit tH as clock is designed always faster than data(this is done at silicon level i.e. fast clock networks).

The tSU will be safe from violation as long as the clock is not too fast or data delay is not too much.

Long combinatorial sections mean more data delay and may violate tSU so either break it up into thinner sections or lower the clock rate.

In short "enter input constraints and check timing of rtl chains in your design and if you run into trouble then you start to help the tool" by pipelining ...etc.

I found this guide by Ryan Scotville and it seems to have done the trick.With your posts here and that guide, I think I now have an understanding of how this works.I realize that the only requirement on the input register is that its setup time should be less than the TCO max of the device and that its hold time must be less than the TCO min. However, I have one final problem that I've run into.While trying to constrain the output side, (which too is at 27Mhz, I seem to have a rather strange result). Please view the attached diagrams. The setup time -minimum value is 0.5 ns.The hold time -minimum value is 0.5 ns, but the Hold Time is described wrt to the falling edge of the clock(Data at output gets latched on the rising edge of the clock).I tried to implement this constraint by setting the minimum output delay to (18.5ns + 0.5ns), but the constraints fail.I have seen you post elsewhere that the min delay should be set to -tH, but that seems to be the case when tS and tH are wrt to the same edge.

Is this the correct way to constraint what is given in the diagram?

https://alteraforum.com/forum/attachment.php?attachmentid=13451&stc=1

https://alteraforum.com/forum/attachment.php?attachmentid=13452&stc=1

--- Quote Start ---

I realize that the only requirement on the input register is that its setup time should be less than the TCO max of the device and that its hold time must be less than the TCO min. However,

--- Quote End ---

The wording is not right as tCO is relative to launch edge while tSU or tH are relative to latch edge. But I get what you think. The early margin of invalid window must be further from tH point and late margin must be before tSU point.

--- Quote Start ---

I have one final problem that I've run into.While trying to constrain the output side, (which too is at 27Mhz, I seem to have a rather strange result). Please view the attached diagrams. The setup time -minimum value is 0.5 ns.The hold time -minimum value is 0.5 ns, but the Hold Time is described wrt to the falling edge of the clock(Data at output gets latched on the rising edge of the clock).I tried to implement this constraint by setting the minimum output delay to (18.5ns + 0.5ns), but the constraints fail.I have seen you post elsewhere that the min delay should be set to -tH, but that seems to be the case when tS and tH are wrt to the same edge.

Is this the correct way to constraint what is given in the diagram?

--- Quote End ---

You are showing two clocks; clock and its inversion and then you state that it is relative to falling edge.

if your fpga launches on rising edge then you need to adjust figures or launch on falling edge to make life a bit easier or use falling_clock if available in command

to adjust the figures I will assume that with respect to rising edge of device tSU = 18.5 - 0.5 = 18 & tH = 18.5 + 0.5 = 19

Then comes the entry of sdc commands. I feel both are negative now as they are behind presumed rising latch edge (or could be made positive relative to next latch) but I am not sure and you need to see what the tool does and how it interprets your entries, look at results such as output registers tCO(frm datasheet) or io path waveforms.

Whether it fails timing or not is a different issue. The starting point is enter the constraints correctly.

I think I might know what's happening here.The two clocks are shown because of the I2C configurable latching(rising edge or falling edge for single latching mechanism).The diagram here shows dual latching (on both rising and falling edges), it basically latches twice per clock cycle, which is why the tS and tH are labelled as they are.I think the diagram just says that in the 1 ns around any edge(0.5 ns for setup and 0.5 ns for hold), the data should remain constant if the dual latching mechanism is used.

And yet again thank you for your patience and help! :)

--- Quote Start ---

But even if this is right, it still doesn't explain why timing fails if I increase the output_delay_min beyond -3ns(like -4,-5 e.t.c).

--- Quote End ---

sorry but can you explain what you mean by "if this is right".