OFFSET OUT Constraint

[vjose1]

I have a CLK_10 (10 MHz)clock from an external oscillator to the FPGA IO Pin. This goes into the DCM module which generates a CLK_80(80 MHz). I use the CLK_80 clock to SPI module . The SPI module generates  the following signals

1) SPI_CS       ( oputput )

2) SPI_CLK     ( oputput )

3) SPI_MISO   ( Input     )

4) SPI_MOSI   ( oputput )

The SPI interface works at 20 MHz. Can I use the OFFSET contraints as described to make sure that the delay from the FF to IO pads.

INST "ENC_SI"  TNM = ENC28J_OUTPUT;

INST "ENC_CS"  TNM = ENC28J_OUTPUT;

INST "ENC_SCK" TNM = ENC28J_OUTPUT;

INST "ENC_SO"  TNM = ENC28J_INPUT;

#All the signals leading to the SPI Interface will not have a delay of #more than 20ns before it reaches the I/O PADS of the FPGA

TIMEGRP "ENC28J_OUTPUT" OFFSET = OUT 20 ns AFTER "CLK_10M" RISING;

TIMEGRP "ENC28J_INPUT" OFFSET  = IN 20 ns VALID 30ns  BEFORE "CLK_10M" RISING;

Would appreciate your help on this.

With regards

Vintu

[hj]

Please do not create duplicate post.

Already,You have created this post.

http://forums.xilinx.com/t5/Timing-Analysis/FROM-TO-Timing-Constraint/m-p/389743

[vjose1]

Hi ,

Please read it carefully. I am not duplicating the same question. I am trying to figure out if offset out and in constraint can be used for the same purpose.

With regards

Vintu

[avrumw]

Vintu,

This has already been answered in my previous post on this interface.

The interface needs to be correct by design. You guarantee the setup and hold time requirements by allowing the appropriate number of 80MHz clocks between edges, and you guarantee the skew by forcing all FFs into IOBs.

Constraints cannot and will not help you on this interface. Constraints only deal with propagation delays, and cannot account for time that comes from things happening on different clock cycles - they simply don't work that way. Furthermore, OFFSET OUT constraints only work from the clock input (the thing connected to the oscillator on your board) to the outputs; which is completely irrelevent in this interface.

Avrum

[vjose1]

Hi,

Thanks for the precise information. I tried both the methods as mentioned in your previous reply. When I use the IOB attribute for the SPI Interface, the tool is giving me lot of timing errors. Thats the reason I went for the offset out constraint.

What I think should happen when I use the OFFSET in and out contstraint is that . It makes sure that the delay(routing delay ) from the IO pad to the FF is kept to the max value given in the OFFSET constraints. Since I am generating the SPI Interface signals using the 80 MHz clock.

1 20MHz clock cycle = 4 80 MHz clock cycle

In case of output to the SPI Interface the data is stable 2 clock cycles (80MHz) before the actual SPI clock edge leaves the FPGA(the implementation part). Similarly the Data coming from the SPI Interface to the FPGA is also ready 2 clock cycles (80 MHz) and the FPGA captures the incoming data on the rising edge of the SPI_CLK. So my whole idea is to make sure that there is min routing delay between IO PAD's and the FF . I do not mind having a bit of a delay from the IOB to FF.

Do let me know if my udnderstanding is right on this. If my idea is not correct do let me know other alternative suggestions.

With regards

Vintu

[avrumw]

Vintu,

You should use the IOB property. If you are getting internal timing failures (i.e. FF to FF), then the problem is that the I/Os are far away from the logic that is generating them (you should be able to see this by investigating the paths). If that is the case, then the simplest solution is to pipeline all the signals going to and from the pads an additional time. This is SPI - I doubt the total latency is an issue, and it should be easy to pipeline.

I don't know how many ways I can say this. The tools CANNOT CANNOT CANNOT understand delays associated with multiple clock periods. The tools are doing STATIC timing analysis; it is only based on the structure of your design, not the functionality of your design. If you have a state machine that has one output signal changing 3 clock cycles after another, this doesn't mean anything to static timing analysis. Static timing analysis can only understand the propagation delay from a clocked element to another clocked element (or output).

For an offset out, the ONLY valid format is a constraint from the input clock pin to the output data pin. It is measured as pure propagation

IBUFG -> (clock network, maybe including MMCM/DCM/PLL) -> flip-flop clocking output -> OBUF

nothing else. You can put a constraint on this to "limit" your path from the flip-flop clocking the output to the OBUF. But, as I say, its irrelevent what the value is - you really only care about the skew, which is something that connot be directly constrained. The only thing you could do is constrain it to "something larger than what makes it fail" - since the delay is constrained, the skew is at least somewhat constrained. But, again, the best way is to use the IOB FFs.

As for using FROM:TOs, I have never seen anyone use a FROM:TO on an output pad, and, even if it did work, it would do exactly the same thing as the OFFSET OUT - it is a static timing path; clock cycle delays don't mean a thing to it.

Avrum

[vjose1]

Hi ,

Thanks a lot for your answer. I clearly understand your point . But I still have  a question on the comment you have made on the FROM :TO constraint.

I am attaching  a pic along with this mail. The pic describes the SPI Interface w.r.t FF's inside the FPGA. It has 3 signals

80 MHz clock

(Two signals generated from 80 MHz clock )

SPI_CLK

SPI_DATA_IN

Please let me know if I am right on this (w.r.t FROM TO CONSTRAINT)

 Do let me know if this is correct.

With regards

Vintu