Offset constraint (offset in and offset out)

Series Catalogue

Timing Closure: Basic concepts

Setup time and hold time

Offset constraint (offset in and offset out)
1. The offset constraint defines the relative relationship between the external clock pad and the input and output pad associated with it. This is a basic timing constraint. Offset defines the relationship between the outside and cannot be used on the internal signal.

The offset constraint is relatively simple to write, such as

OFFSET = {in| Out} Offset_time [units] {before| After} Clk_name [Timegrp group_name];

• Offset_time: The difference between the capture clock edge and the data start time, the default unit is NS, can be defined as NS, PS, etc.
• before| After: Similar to the original intention
• Clk_name: Enter the hierarchical full name of clock pad net

How much Offset_time writes depends on the relative relationship between the data, and it is also important to understand how XST analyzes the timing relationship. 2. OFFSET in Analysis

The following equation is a relationship that needs to be satisfied with the timing requirements pointed out in UG612, which may not be very clear, but it is easy to understand with example analysis. The requirement for the following is Toffset_in_before-(tdata + Tsetup-tclock) > 0, which in fact corresponds to slack greater than 0. Specific statements are as follows (set-up time and hold time requirements, respectively)

Tdata + tsetup-tclock <= toffset_in_before

where

Tsetup = intrinsic Flip Flop setup time

Tclock = Total Clock path delay to the Flip Flop

Tdata = Total Data path delay from the Flip Flop

Toffset_in_before = Overall Setup Requirement

Tclock-tdata + thold <= toffset_in_before_valid

where

Thold = intrinsic Flip Flop hold Time

Tclock = Total Clock path delay to the Flip Flop

Tdata = Total Data path delay from the Flip Flop

Toffset_in_before_valid = Overall Hold Requirement

The requirements for hold time are also mentioned in the documentation, and the setup and retention times are described above. UG612 here is a big pit, and after giving this formula, we never discuss hold time again. The previous WP327 (WP327 partial content error, UG612 correction)

The OFFSET in requirement value was used as a setup time requirement of the FPGA during the setup time analysis. The VALID keyword is used in conjunction with the requirement to create a hold-time requirement during a hold-time analysi S. The VALID keyword specifies the duration of the incoming Data VALID window, and the timing analysis tools perform a HOL D-time analysis. By default, the VALID value was equal to the OFFSET time requirement, which specifies a zero hold-time requirement. See Figure 6. "

This section describes how hold time is handled. If the valid time of the data is specified, the requirement of hold times is deterministic, which allows for a specific analysis, and if not, the requirement of hold-time is considered to be 0 by default.

3.OFFSET in Example

Simple Example

Slack: -0.191ns (Requirement-(data Path-clock path-clock arrival + uncertainty))

Source:reset (PAD)

DESTINATION:MY_ODDRA_ODDR_INST/FF0 (FF)

Destination CLOCK:CLOCK0_DDR_BUFG rising at 0.000ns

Requirement:3.000ns

Data Path Delay:2.784ns (Levels of Logic = 1)

Clock Path Delay: -0.168ns (Levels of Logic = 3)

Clock Uncertainty:0.239ns

The above example first tells us that the offset_in constraint is 3ns, which means that the input data is valid on the front 3ns of the sampling clock. Then the correct sampling on the trigger depends on: the trigger sampling clock is delayed by-0.168, so much ahead of the -0.168ns;data path delay is 2.784, so the data delay 2.784, the source, the end of the target clock relationship is 0, unchanged, the uncertainty has a bad effect, there are

Slack = 3 + (-0.168) -2.784-0.239 +0;

phase-shifted Example

Slack:2.309ns (Requirement-(data Path-clock path-clock arrival + uncertainty))

Source:reset (PAD)

DESTINATION:MY_ODDRA_ODDR_INST/FF0 (FF)

Destination CLOCK:CLOCK90_BUFG rising at 2.500ns

Requirement:3.000ns

Data Path Delay:2.784ns (Levels of Logic = 1)

Clock Path Delay: -0.168ns (Levels of Logic = 3)

Clock Uncertainty:0.239ns

The parsing process is similar, but we note that at the time of definition, the relative value is clock, but the clock sampled by the trigger is Clk90 (Destination). This means that we have a clock arrival time, and this value is 2.5ns. The rest is the same as the above example.

So back to the previous equation Toffset_in_before-(tdata + Tsetup-tclock) > 0; requirement in the analysis report is actually toffset_in_before,data path including tdata And Tsetup,tclock are actually clock arrival and clock path delay. This formula does not take into account the clock uncertainty.

Before concluding this section, it is also important to mention a very strange concept that does not know why it exists. It was not specifically stated that, for the offset in constraint, the notation is probably

OFFSET = in 3ns before clock;

It is natural to adopt before because we have been analyzing the settling time, and the settling time is precisely before the sampling edge. OFFSET in can also be written so that (don't understand why this is the way it should be)

OFFSET = in 2 ns after Clock_pad

At this point, the corresponding conditions to be met are

Tdata + tsetup-tclock <= tperiod-toffset_in_after

where

Tsetup = intrinsic Flip Flop setup time

Tclock = Total Clock path delay to the Flip Flop

Tdata = Total Data path delay from the Flip Flop

Tperiod = single Cycle PERIOD requirement

Toffset_in_after = Overall Setup Requirement

4. OFFSET Out Analysis

The OFFSET out constraint is the relative relationship between the clock and the data of the FPGA-to-downstream device, which can be used to represent. The specific constraints require that the data received by the downstream device will arrive within the length of the clock along. Then, according to this picture you can draw clock to out = Clock_delay + clock_to_out + data_delay + clock_arrival. This is because the clock path of the trigger inside the FPGA is delayed, and the FPGA trigger output delays the clock_delay+clock_to_out time due to trigger time, while the data has a delay. Another, the figure is given is a situation, in this case clock_arrival = 0, the final result also need to add clock_arrival.

According to this relative relation, we can draw the relation that the FPGA time series needs to satisfy

TQ + tdata2out + tclock <= toffset_out_after

where

TQ = intrinsic Flip Flop Clock to Out

Tclock = Total Clock path delay to the Flip Flop

tdata2out = Total Data path delay from the Flip Flop

Toffset_out_after = Overall Clock to Out requirement

The specific analysis is similar to offset in, which is not repeated here, and gives a few examples.

Example Analysis

Simple Example

Slack: -0.865ns (Requirement-(clock arrival + clock path + data path + uncertainty))
Source:outd_7 (FF)
Destination:outd<7> (PAD)
Source CLOCK:CLOCK3_STD_BUFG Rising at 0.000ns
Requirement:3.000ns
Data Path Delay:3.405ns (Levels of Logic = 1)
Clock Path Delay:0.280ns (Levels of Logic = 3)
Clock Uncertainty:0.180ns

Offset constraint (offset in and offset out)