about data arrival time

[orangepeace]

Hi all,

    In ug903, it gives an equaiton just below:

Data Arrival Time (setup) = source clock launch edge time
+ source clock path delay
+ datapath delay
+ setup time

But when I use Vivado to analyze my simple design, I find the data arrival time is just like below. Pls note the highlight part.

The set up time is -0.029. I mean it is negative. So The equation above becomes minus setup time instead of add setup time. Can anyone explain it to me?  Thanks.

[orangepeace]

And I use xc7a200t-1I. In datasheet, I find the setup time is below which is not 0.029. I don't know why.

[avrumw]

The information in UG903 is correct - the setup time is added to the data arrival time. In this case, however, the actual setup time happens to be a negative number.

The setup/hold times specify the data window where the data must be valid in order for the flip-flop to capture the data input. One normally thinks of this window being "around" the clock edge - starting before, and ending after the clock. These would be positive setup and positive hold times. However, if this required window moves slightly to the right - so that the entire window is slightly after the clock edge, then the setup time becomes negative, and the hold time gets larger.  This would be the case when the propagation from the flip-flop data pin to the "heart" of the flip-flop (the actual capture part) is longer than the propagation from the clock pin to the heart of the flip-flop.

As for trying to correlate it to the numbers in the datasheet - you can't.

Vivado and ISE use entirely different timing models for the components inside the FPGA.

In ISE, the timing engine (and a lot of other things) are slice based. All timing is defined from slice input and output pins. For example, the Tilo (that we all know an love) is from the slice A/B/C/D inputs to the slice outputs, going only through the LUT itself. The Tdick is from the slice input referenced to the clock input at the slice. There are different measurements and symbols for

  - input through lut to output

  - input through lut through carry to out

  - input through lut through mux to out

  - input to mux to out

  - ...

  - input to FF

  - input through lut to FF

  - input through lut through mux to FF

  - ...

In Vivado, the timing engine (among other things) is Basic ELement (BEL) based. Instead of having timing extracted for all combinations of arcs through the slice, the timing is extracted independently for each element of the slice. You can see this in your timing report - you have

  - Prop_fdce_c_q - the clock to Q of a slice FF

  - Prop_lut2_I0_O - the propagation of a LUT from the I0 input to the output

  - Setup_fdce_C_D - the setup time of a slice FF of the D input relative to the clock (this is negative)

  - there are also propagation times for the wide MUX elements and the 4 bit fast carry block

This makes timing reports much more understandable...

For the 7 series devices, you can use either Vivado or ISE. In the datasheet, however, they are only showing the ISE extracted numbers, not the ones extracted for Vivado. The numbers (and symbols) in the datasheet will correspond to those reported in a timing report from ISE, but not from Vivado.

Avrum

[orangepeace]

Hi Avrum,

  "These would be positive setup and positive hold times".  So what factors are used to determine the setup and hold time? Setup_fdce_C_D is constant value for the same device, right? That means"setup time" in the below equation is

constant value and determined by the device not the design, right?

Data Arrival Time (setup) = source clock launch edge time
+ source clock path delay
+ datapath delay
+ setup time

Thanks

Rgds

[avrumw]

The setup and hold times of the flip flop are not dependent on the user design - they are fixed based on the timing performance of the underlying cells.

They will definitely vary by speed grade, and probably by family member (Artix vs. Kintex, Virtex), and maybe even by sub-family or device (but probably not).

They will also be different based on the resource used - IOB FFs will have different characteristics than slice FFs, and probably the flip-flop/latches (the four primary FFs in the slice) will be different from the flip-flops (the FFs on the O5 output of the LUT). Also the FFs in the DSP cells and block RAMs will be different as well.

It is possible (but I doubt it) that the different FFs within the slice (the A/B/C/D FFs) will differ slightly from eachother.

Ultimately, the tool knows which FF it is using, and knows the appropriate SU/H value for that FF.

Avrum

[orangepeace]

Hi Avrum,

   Thanks for your support. But still I have a question. I find the setup time value in synthesis timing report is different from its in implementation timing report just like below. Pls note the red highlight. The left side is the synthesis timing report and the right one is the implementation timing report. In addition, the blue highlight which indicate the c_reg status, what's the different between the mark?

Thanks

Rgds

Orange

[graces]

---

@orangepeace wrote:

Hi Avrum,

   Thanks for your support. But still I have a question. I find the setup time value in synthesis timing report is different from its in implementation timing report just like below. Pls note the red highlight. The left side is the synthesis timing report and the right one is the implementation timing report. In addition, the blue highlight which indicate the c_reg status, what's the different between the mark?

Thanks

Rgds

Orange

---

Here's the representation of various netlist icons.

The primitive instance with placement constraints assigned display a yellow rectangle with a blue stripe.

[orangepeace]

Why the setup in synthesis is different from that in implementation? Pls note the highlight with red. It's said it's only depend on the device.

Thanks

Rgds