2 1i constraints
Download
1 / 69

2.1i Constraints - PowerPoint PPT Presentation


  • 206 Views
  • Uploaded on

2.1i Constraints. Understanding Timing and Placement Constraints. M1 Design Flow. UCF. XNF/EDIF netlist. User Constraints File. NGDBUILD. Flatten Hierarchical Design. .NGD. MAP. Logical to Physical translation Group LUTs and FFs into CLBs. Optional: Reports block delays. TRCE. .NCD.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '2.1i Constraints' - uzuri


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
2 1i constraints

2.1i Constraints

Understanding Timing and Placement Constraints


M1 design flow
M1 Design Flow

UCF

XNF/EDIF netlist

User Constraints File

NGDBUILD

Flatten Hierarchical Design

.NGD

MAP

Logical to Physical translation

Group LUTs and FFs into CLBs

Optional: Reports block delays

TRCE

.NCD

.PCF

Static Timing Estimates

PAR

BITGEN

Layout of Physical Design

Routes Physical Design

Generates configuration file

.NCD

.BIT


What needs constraining

X

Y

Z<0:9>

Pin 2 Pin Speed

What Needs Constraining?

  • Internal clock speed for one or more clocks

  • I/O speed

  • Logic using multi-cycle clocks

  • Pin to Pin timing

  • Pin Locations & Logic Locations

Clk & CE Speed

I/O Speed

I/O Speed

Pin Locations

D

Q

D

Q

OUT1

1 Level of Logic

CLK

Logic Locations

2 Levels of Logic

OUT2

Pin Locations


Types of constraints supported
Types of constraints supported

  • Timing Constraints

    • Specify delay along logic paths

    • Allows both “quick and dirty” and “highly detailed” timing control

  • Location Constraints

    • Specify location of components on FPGA

    • Specify mapping constraints

INST FLOP1 BLKNM=ABC

INST MY_FMAP BLKNM=ABC

INST FLOP2 BLKNM=ABC


Where do constraints go
Where do Constraints go?

  • Timing constraints may be applied to a Schematic using the TIMESPEC symbol (FROM:TO’s)

  • They can be added to HDL source code if your compiler supports them

  • They can be input in a separate file called a .UCF (User Constraints File)

  • Some constraints must be placed in the PCF (Physical Constraints File). Normally, the PCF should be avoided by users.

TIMESPEC


Brief review of constraint flow

DRC

PAR

TRCE

EPIC

Brief Review of Constraint Flow

LOGICAL DOMAIN

User netlist

and logical constraints

UCF

XNF/EDIF netlist

User Constraints File

NGDBUILD

DESIGN

TRANSLATION

MAP

Mapped design

and physical

constraints

PHYSICAL

DOMAIN

.NCD

.PCF

NGDANNO


Timing constraints i

Timing Constraints (I)

Using PERIOD and OFFSET constraints


Period constraints
Period Constraints

PERIOD

  • PERIOD is the duration of the clock and can be configured to have different duty cycles

  • Derived clocks can be defined as a function of another clock (*,/)

  • PERIOD is preferred over FROM:TO constraints; The tools will have a faster runtime. PERIOD should cover most of design.

  • Period only covers from Sync. Elements to other Sync. Elements, like Flip flops to flip flops.


The period constraint
The Period Constraint

  • Period : This constraint covers all timing paths which start and end at a FF, Latch or synchronous RAM which is clocked by the referenced net. (Every synchronous element is effectively identified by forward propagation.)

  • It does not cover paths to output pads, but does cover input pads.

  • UCF Example:

    • Using “simple” method:

      NET A_CLK PERIOD=40 : LOW 15;……(LOW is optional; Specifies duty cycle)

    • Using TIMEGROUP/TNMs

      NET A_CLK TNM = A_CLK_GRP; …...(make a group)

      TIMESPEC TS_CLK = PERIOD A_CLK_GRP 40; …..(apply PERIOD to the group)

FLOP

LATCH

D

Q

D

Q

OUT1

G

PERIOD=30

CLK

RAM

OUT2

Path controlled by PERIOD

Forward propagation path


Period path tracing

Period#1

Period#2

Period Path Tracing

  • PERIOD analyzes the following:

    • Synchronous element to synchronous element data path calculations

    • Automatically deals with inverted clock pins

    • Deals with non 50% clock duty cycles

    • Synchronous element to PAD, PAD to PAD,and PAD to Synchronous element NOT included

  • Clock Network to Clock Network uses Target Clock as Time Constraint

Period#2 will control this path


Period and two phase clocks
Period and Two-Phase Clocks

  • The allowed path delay will automatically be reduced if a two-phase clock is detected

    • If PERIOD does not have a “HIGH” or “LOW” keyword to define duty-cycle, then allowed path delay will be cut in half

Single-Phase Maximum

Two-Phase Maximum

45ns is the maximum allowed PERIOD declared in the UCF

=====================================================================

Timing constraint: NET "clock" PERIOD = 45 nS HIGH 50.000 % ;

2 items analyzed, 0 timing errors detected.

Minimum period is 8.586ns.

---------------------------------------------------------------------

Slack: 18.207ns path qneg_buf to qneg_buf relative to

22.500ns delay constraint (two-phase clock)

Path qneg_buf to qneg_buf contains 2 levels of logic:

Path starting from Comp: CLB_R1C7.K (from clock_buf)

To Delay type Delay(ns) Physical Resource

Logical Resource(s)

------------------------------------------------- --------

CLB_R1C7.XQ Tcko 1.830R qneg_buf

CLB_R1C7.C2 net (fanout=2) 0.543R qpos_buf

CLB_R1C7.K Thh1ck 1.920R qneg_buf

-------------------------------------------------

Total (3.750ns logic, 0.543ns route) 4.293ns (to clock_buf)

TRCE cut the spec in half (45ns/2=22.5ns) for this path

“Two-phase clock” is indicated here

This indicates the magnitude of the path delay between

flops. There is no “adjustment” to this figure.

This indicates that the worst-case period for this

ENTIRE spec is 8.586ns (4.293ns x 2). If there had been a

single-phase path in this PERIOD spec that was 9ns, it would

have been reported as the worst-case value, if it were 8ns, it

would not.

This is the remaining slack (45ns/2 - 4.293ns = 18.207ns).


Period and ram
Period and RAM

  • PERIOD will trace THROUGH the Address pins of all RAM, and TO the D/WE pins of Sync RAM (THROUGH WE of Async)

Sync RAM

WE

D

WCLK

ADDRESS

ASync RAM

WE

ADDRESS


Period examples
Period Examples

  • By net

    • NET CLK50 PERIOD = 20 ns ;

    • NET CLK20 PERIOD = 50 HIGH 20 ;

  • By group: (See TNM/TIMEGRP Section for details)

    • NET CLK50 TNM = CLK50_GRP ;

    • NET CLK25 TNM = CLK25_GRP ;

    • TIMESPEC TS_CLK_FULL = PERIOD CLK50_GRP20;

    • TIMESPEC TS_CLK_HALF = PERIOD CLK25_GRP

      TS_CLK_FULL * 2 ;

      (Note M1.5 - must use signal after global buffer for TNM groups)

TNM=CLK50_GRP

BUFG


I o timing offset
I/O Timing: Offset

  • OFFSET allows the user to specify external data and clock relationships for the timing on paths to and from the I/Os. The software determines the internal requirements (OFFSET IN AFTER, OFFSET OUT BEFORE).

  • Optionally, OFFSET allows the user to specify the internal delay (OFFSET IN BEFORE, OFFSET OUT AFTER).

  • OFFSET was originally added to support Synopsys set_input_delay and set_output_delay constraints

  • For clocks using global resources, the clock delay is used in the equation

  • Note: The path from the pad to a FF in an IOB is not constrained by offset. This is considered a fixed delay and is not reported.


2 1i constraints

Specify I/O timing

  • OFFSET allows the user to specify EXTERNAL data and clock

  • relationships for the timing on paths to and from the IO’s.

  • It enables the user to inform the system of external setup and

  • clock-to-out delays with respect to a clock. The system can then

  • determine the internal timing requirements without the need for

  • PADS:TO:FFS or FFS:TO:PADS constraints.

Internal delays determined

by the tools

OFFSET OUT

OFFSET IN

d2

d3

d4

d1

DEV1

DEV2

FPGA

CLK


The offset in before constraint
The OFFSET IN - ‘BEFORE’ constraint

NET Din OFFSET = IN 20nS BEFORE CLK

FPGA

UPSTREAM DEVICE

Din

CLK

CLK

This says, Data will be valid here, 20nS BEFORE the clock arrives here.

In other words: “The Data to be registered in the FPGA will be available on the FPGA’s input Pad 20ns BEFORE

the clock pulse is seen by the FPGA’s clock pad.”

Therefore, the M1 tools will calculate: Maximum_Allowable_Internal_P2S_Delay = OFFSET + internal_CLK_delay.

Data registered

in FPGA on

this edge.

The tools can automatically

calculate and control internal

data and clock delays to meet

TsuFF

20ns

Data Out

of DEV1 on

this edge.

Valid

Tbufg

Designer must ensure that

T(clock_period) - 20ns = ext-delay

TsuFF

Internal

delay

Valid


The offset in after constraint
The OFFSET IN - ‘AFTER’ constraint

NET CLK PERIOD = 45nS;

NET Din OFFSET = IN 16nS AFTER CLK;

FPGA

UPSTREAM DEVICE

Din

CLK

CLK

This says, Data will be valid here, 16nS AFTER the clock arrives here!…..

In other words: “The Data to be registered in the FPGA will be available on the FPGA’s input Pad 16ns AFTER the clock

pulse is seen by the Upstream Device.” For the purposes of the OFFSET constraint syntax, assume no skew on CLK

between the chips. A PERIOD constraint is required to indicate when the subsequent clock pulse will be seen by the FPGA

to clock in the Data (Maximum_Allowable_Internal_P2S_Delay = PERIOD - OFFSET + internal_CLK_delay).

For this example, the max. P2S delay

would be calculated by M1 as :

45ns-16ns+3ns = 32ns.

(Assuming internal CLK delay is 3ns.)

16ns

Data registered

in FPGA on

this edge.

Data Out

of DEV1 on

this edge.

Valid


The offset out after constraint
The OFFSET OUT - ‘AFTER’ constraint

NET Din OFFSET = OUT 22nS AFTER CLK

FPGA

DOWNSTREAM DEVICE

This says, Data will be valid here, 22nS AFTER the clock arrives here!…..

In other words: “The Data to be registered in the Downstream Device will be available on the FPGA’s output Pad 22ns AFTER

the clock pulse is seen by the FPGA.” (Maximum_Allowable_Internal_Dout_Delay = OFFSET - internal_CLK_delay).

Designer must ensure that

T(clock_period) - 22ns = ext-delay

ext-delay = sufficient time for

external delays involved with

meeting DEV2 setup time.

22ns

Data clocked

into DEV2 on

this edge.

Data Out

of FPGA on

this edge.

Valid


The offset out before constraint

Valid

The OFFSET OUT - ‘BEFORE’ constraint

NET CLK PERIOD = 45nS;

NET Din OFFSET = OUT 25nS BEFORE CLK;

d4

FPGA

DEV2

This says, Data will be valid here, 25nS BEFORE the clock arrives here!…..

In other words: “The Data to be registered in the Downstream Device will be available on the FPGA’s output Pad 25ns BEFORE

the clock pulse is seen by the Downstream Device.” For the purposes of the OFFSET constraint syntax, assume no skew on

CLK between the chips. A PERIOD constraint is required to indicate when the initial clock pulse was seen by the FPGA

to clock out the Data (Maximum_Allowable_Internal_C2P_Delay = PERIOD - OFFSET - internal_CLK_delay).

For this example, the max. C2P delay

would be calculated by M1 as :

45ns-25ns-3ns = 17ns.

(Assuming internal CLK delay is 3ns.)

Data Into

DEV2 on

this edge.

25ns

Data Out

of FPGA on

this edge.


Offset constraints in 2 1i
OFFSET Constraints in 2.1i

  • Global: All inputs/outputs are offset relative to a clock. For example, OFFSET = IN 20ns BEFORE clk1 indicates that all inputs will have data present at the pad at least 20ns before the triggering edge of clk1 arrives at the pad.

  • Net-Specific: A specific input/output is offset relative to a clock. For example: NET DATA_IN OFFSET = IN 20ns BEFORE clk1 indicates that DATA_IN will have data present at the pad at least 20ns before the triggering edge of clk1 arrives at the pad.


Clock register groups in offset
Clock Register Groups in OFFSET

  • Clock register time groups allows the user to define a specific set of registers to which an OFFSET constraint applies based on a clock edge. Consider the following example.

NET CLK PERIOD = 45nS;

OFFSET = IN 10 BEFORE CLK TIMEGRP AB;

OFFSET = IN 20 BEFORE CLK TIMEGRP C;

DATA

C

B

A

CLK

You can define time groups for the registers A,B, and C, even though these registers have the same data and clock source. TIMEGRP AB = RISING FFS; TIMEGRP C = FALLING FFS; This allows the user to perform two different timing analysis for the registers.


Data path groups in offset
Data Path Groups in OFFSET

  • Data Path Groups allow the user to define a specific set of input pads to which an OFFSET constraint applies. Consider the following example.

You can also add a clock register time group.

TIMEGRP BEF = FFS(Out*); TIMEGRP DATA_GROUP OFFSET = IN 10 BEFORE CLK BEF;

This restricts the constraint to registers B, E, and F.

TIMEGRP DATA_GRP = PADS(DATA*);

NET CLK PERIOD = 45nS;

TIMEGRP DATA_GRP OFFSET = IN 10 BEFORE CLK;

Data1

A

B

Out1

Data2

E

Out2

Data3

F

C

Out3

Input

G

D

Result


Offset examples 1
OFFSET Examples (1)

Determined by tools

Determined by tools

14ns

40ns

25ns

  • The following two UCF files are equivalent:

    NET CLOCK PERIOD=40;

    ##External (shown in diagram)

    NET ADD0_IN OFFSET = IN 14 AFTER CLOCK;

    NET ADD0_OUT OFFSET = OUT 25 BEFORE CLOCK;

    NET CLOCK PERIOD=40;

    ##Internal (not shown in diagram):

    NET ADD0_IN OFFSET = IN 26 BEFORE CLOCK;

    NET ADD0_OUT OFFSET = OUT 15 AFTER CLOCK;

D

Q

Q

D

Q

D

D

Q

CLOCK

Downstream

Device

Upstream

Device

XILINX DEVICE


Offset examples 2
OFFSET Examples (2)

  • Wildcard Grouping Specification (UCF only)

    • NET ADDR_<*> OFFSET = IN 15 AFTER clk50;

    • NET ADDR_<*> OFFSET = OUT 35 BEFORE clk50;

  • Global Control (PCF only)

    • OFFSET = IN 35 ns BEFORE COMP “clk50” ;

    • OFFSET = OUT 30 ns AFTER COMP “clk50” ;


Synopsys support for period and offset
Synopsys Support for PERIOD and OFFSET

  • Synopsys supports this type of system level timing analysis in the .dc

  • scripting file.

  • 1) create_clock -period 125 -waveform {0 62.5} find(port,"CLK")

  • 2) set_input_delay 125 -clock "CLK" find(port,"NOTRST")

  • 3) set_output_delay 125 -clock "CLK" find(port,"GAG<0>")

  • 1) TIMESPEC TS_CLK = PERIOD : "CLK": 125 : HIGH : 62.5;

  • 2) NET "CLK" TNM = "CLK";

  • 3) NET "NOTRST" OFFSET = IN : 125 : AFTER : "CLK";

  • 4) NET "GAG<0>" OFFSET = OUT : 125 : BEFORE : "CLK";

.dc file

.ncf file


Timing constraints ii

Timing Constraints (II)

Using FROM:TO and other constraints


Timing path keywords
Timing Path Keywords

  • Timing constraints are applied to logic paths

  • Logic paths typically start and stop at pads, registers, latches, and RAM

  • The tool recognizes the following keywords to define endpoints or time groups:

    PADS All I/O pads

    FFS All flip-flops

    LATCHES All latches

    RAMS All RAM elements

  • Keywords can be used globally, and to create design sub-groups


Basic global timing constraints using the from to syntax

TS_P2P

Basic Global Timing Constraints( using the FROM-TO Syntax)

UCF TIMESPEC command using default keywords:

TIMESPEC TS_C2S=FROM:FFS:TO:FFS:30;

TIMESPEC TS_P2S=FROM:PADS:TO:FFS:25;

TIMESPEC TS_P2P=FROM:PADS:TO:PADS:26;

TIMESPEC TS_C2P=FROM:FFS:TO:PADS:9;

TS_P2S

TS_C2S

TS_C2P

D

Q

D

Q

OUT1

CLK

OUT2


Basic global timing constraints using the from to syntax1
Basic Global Timing Constraints( using the FROM-TO Syntax)

TIMESPEC TS_F2F=FROM:FFS:TO:FFS:30;

  • The word TIMESPEC defines the type of specification

  • The Spec’s name must start with “TS” any alpha-numeric after TS is fine. Recommendation: Make the name something you will remember later.

  • FROM: designates the origin of the path

  • TO: designates the destination of the path

  • 30; in ns by default, is the specification. You can use MHz, or even another time spec like TS_C2S/2 or TS_C2S*2


Using tnm to create groups
Using TNM to create Groups

NET clock TNM=clk_group;

  • Any Keyword element can be made into a ‘group’ for timing purposes

  • In this example the net ‘clock’ is traced forward to the two flip-flop (FFS).

  • These flip-flops are ‘timing-named’ (TNM) with the name ‘clk_group’.

  • They can now be referenced by this TNM in TIMESPECs

D

Q

D

Q

OUT1

CLOCK

OUT2


Using tnm to create groups1
Using TNM to create Groups.

NET clock TNM=clk_group;

  • These timing groups can overlap, meaning a FFS, LATCHES, RAMS, or PADS can belong to multiple groups if necessary to describe your design’s timing

  • Time constraints are case sensitive (TNM=abc  TNM=ABC)

  • Groups are ideal for identifying groups of logic that work at different speeds…….(multi-cycle paths and other slow exceptions).


Using tnm net to create groups
Using TNM_NET to create Groups

NET clock TNM_NET=clk_group;

  • TNM_NET is equivalent to TNM on a net except for pad nets.

  • When placing a TNM on a pad net the TNM would locate itself on the pad and not trace forward through the buffer to the next synchronous element. TNM_NET was created for this purpose. If you place a TNM_NET on a pad net, it will trace through the buffer to the next synchronous element.

  • TNM_NET is extremely useful for synthesis designs. The only meaningful net names are the ones directly connected to pads.

  • TNM_NET can be used in UCF or NCF only.


Multi cycle delays grouping by net name
Multi-Cycle Delays Grouping by net name

  • Using pattern matching on register’s output net names to create groups. Good for schematics.

    TIMESPEC TS_MYBUS = FROM:FFS(DATA0<*>):TO:FFS(MY_REG*):TS_CLK*2;

MY_REG_0

D

Q

reg0

TS_MYBUS

MY_REG_1

D

Q

reg1

DATA0

MY_REG_2

D

Q

reg2

CNT16

MY_REG_3

D

Q

reg3


Multi cycle delays grouping by instance name
Multi-Cycle Delays Grouping by instance name

  • Using INST to create groups. INST pattern matches on the symbol name. Good for Synthesis.

    INST CNT16/* TNM=CNT25;

    INST reg* TNM=MYREG;

    TIMESPEC TS_MYBUS= FROM:CNT25:TO:MYREG:TS_CLK*2;

MY_REG_0

D

Q

reg0

TS_MYBUS

MY_REG_1

D

Q

reg1

DATA0

MY_REG_2

D

Q

CNT16

reg2

MY_REG_3

D

Q

reg3


Slow exceptions
Slow Exceptions

  • Slow Exceptions are FROM:TOs that define a different delay for portion of the design. The majority of the design has PERIOD.

  • Preferred methodology; PAR and TRCE will execute faster.

Example 1: Using FROM:TO’s only -- OK, but not best method

60 ns

30 ns

OUT

IN

D

Q

D

Q

D

Q

FROM:flop1:TO:flop2:30

FROM:flop2:TO:flop3:60

CLK

Example 2: Using PERIOD with a FROM:TO Slow Exception -- BEST

60 ns

30 ns

OUT

IN

D

Q

D

Q

D

Q

FROM:flop2:TO:flop3:60

NET CLK PERIOD=30

CLK


Slow exceptions multi cycle delays with clock enables
Slow Exceptions: Multi-Cycle Delays with Clock Enables

  • Forward trace on the clock enable to create a slow exception

    NET “CLK_EN” TNM=SLOW;

    NET “CLK” TNM = FAST;

    TIMESPEC TS01=PERIOD FAST 30;

    TIMESPEC TS02=FROM:SLOW:TO:SLOW:TS01*2;

60 ns

30 ns

OUT

IN

D

Q

D

Q

D

Q

CE

CE

TNM=FAST

CLK

TNM=FAST

TNM=SLOW

TNM=FAST

TNM=SLOW

CLK_EN

Timespecs applying to elements with more than one TNM will be resolved

with a priority system…….discussed later.


Specific delays from one group to another
Specific Delays from one group to another

  • Qualifying predefined groups to create path-specific constraints:

    TIMESPEC TS_FIFOS = FROM:RAMS(FIFORAM<*>):TO:FFS(MY_REG*):25;

    Note: The pattern matching is on the output signal of the FFS/RAMS, not the symbol name. Use INST to pattern match on the symbol name.

MY_REG_0

D

Q

reg0

MY_REG_1

D

Q

reg1

FIFORAM

MY_REG_2

MYFIFO

D

Q

reg2

MY_REG_3

D

Q

reg3


Specific delays going through specific logic tpthru
Specific Delays going through specific logic (TPTHRU)

  • Forces the path through specific logic.

  • The TPTHRU attribute is attached to net / instance / macro in top blob. NET $3M17/ON_THE_WAY TPTHRU = ABC;

    TIMESPEC TS_FIFOS=FROM:RAMS(FIFORAM<*>):THRU:ABC TO:FFS(MY_REG*):25;

MY_REG_0

D

Q

FIFORAM

TPTHRU=abc

reg0

MYFIFO

MY_REG_1

D

Q

reg1

MY_REG_2

D

Q

reg2


Specific delays excluding logic
Specific DelaysExcluding Logic

  • You can create subgroups based on names with “EXCEPT”

  • Example:

    Assume this design has several data busses that all start with “DATA”. Use the EXCEPT command to create a group with all the pads except the data pads.

    • TIMEGROUP CTRL_PADS = PADS: EXCEPT (DATA*);

    • TIMEGROUP DATAPINS = PADS(DATA*);

    • TIMESPEC TS_IO1=FROM:CTRL_PADS:TO:FFS:20;

    • TIMESPEC TS_IO2=FROM:FFS:TO:CTRL_PADS:20;

    • TIMESPEC TS_IO3=FROM:CTRL_PADS:TO:CTRL_PADS:30;

    • TIMESPEC TS_IODATA=FROM:DATAPINS:TO:FFS:15;


Constraining between rising falling clock edges
Constraining Between Rising & Falling Clock Edges

  • Define clock groups, the (“*”) covers all FFS in your design

    • TIMEGRP RFFS = RISING FFS (“*”);

    • TIMEGRP FFFS = FALLING FFS (“*”);

  • Define timing constraints

    • TIMESPEC TS_R2F=FROM:RFFS:TO:FFFS:30;

    • TIMESPEC TS_F2R=FROM:FFFS:TO:RFFS:30;

  • Remember, the PERIOD constraint will automatically account for two-phase clocks.

D

Q

D

Q

OUT1


Constraining between multiple clock domains
Constraining Between Multiple Clock Domains

  • Define clock groups

    • NET CLK_A TNM=A_GRP;

    • NET CLK_B TNM=B_GRP;

  • Define timing constraints

    • TIMESPEC TS_CLKA=PERIOD A_GRP 20;

    • TIMESPEC TS_CLKB=PERIOD B_GRP TS_CLKA*2;

    • TIMESPEC TS_CLKA2B=FROM:A_GRP:TO:B_GRP:20;

D

Q

D

Q

D

Q

OUT1

D

Q

CLK_A

CLK_B


Creating new synchronous points tpsync
Creating new synchronous points (TPSYNC)

Allows definition of synchronous points that are notFFS, RAMS, PADS or LATCHES.

  • Commonly used with three-state buffers.

  • Example: NET $3M17/BLUE TPSYNC = BLUE_S; TIMESPEC TS_1A=FROM:FFS:TO:BLUE_S :15 ;

$3M17/BLUE

RAM/

FFS/

PADS/

LATCH

comb_b

D

Q

TS_1A


Ignoring paths tig
Ignoring Paths (TIG)

  • Never changing input signal

    NET CHIP_MODE TIG;

  • Ignore a signal for a specific timespec

    NET SLOW_SIG TIG=TS_01;

  • Ignore false paths between registers

    TIMESPEC TS_TIG1=FROM:FFS(REGA*):TO:FFS(REGB*):TIG;

    Note: May have to use INST to create groups for synthesis designs.


Controlling false paths tpthru

Status Registers

Control Register

Control_Enable

Status_Enable

DATA_BUS(7:0)

Controlling False Paths (TPTHRU)

  • Design has bi-directional bus with sets of registers in different blocks. There is a false path from control registers through the TBUF to the status registers.

    NET DATA_BUS<*> TPTHRU = DATABUS;

    TIMESPEC TS_TIG=FROM:FFS:THRU:DATABUS:TO:FFS:TIG;

TIG!


Timing constraint priority 1
Timing Constraint Priority (1)

  • It is legal to constrain the same paths more than once

    • Known as a constraint conflict

    • Multiple sources constraining the same path

      • UCF and schematic could constrain same path

    • Multiple constraints on one net within one source

  • Resolution of conflicting constraints from multiple sources:

    • Lowest Priority - input netlist or .ncf file

      - .ucf file

    • Highest Priority - .pcf file (usually from MAP)

      Note: this priority only applies to timespecs with identical TSidentfiers(e.g. TS_03 =…)


Timing constraint priority 2
Timing Constraint Priority (2)

  • Within a particular source:

    • Highest Priority Timing ignores (TIG)

      FROM:THRU:TO specsSource and destination defined by user Source or destination defined by user Source and destination are pre-defined groups

      FROM:TO specsSource and destination defined by user Source or destination defined by user Source and destination are pre-defined groupsOFFSET specs

      Specific data IOB

      Time group of data IOBs

      All data IOBs

      PERIOD specs

    • Lowest Priority “Allpaths” type specs (.pcf only)


Timing constraint priority 3
Timing Constraint Priority (3)

  • Same path constrained with different FROM:TO statements

    • Highest Priority - Source and destination defined by user

      - Source or destination defined by user

    • Lowest Priority - Source and destination are pre-defined groups

  • You can explicitly assign priorities

    • Syntax

      • (SOME_NORMAL_TIMESPEC) : PRIORITY : integer

    • Low numbers specify high priority (1 thru about 2 million)

    • To match timespec the priority scheme in XACT 6.0, use priority set to the time allowed in the timespec.

      • If the time constraint is 10, set the priority to 10


2 1i constraints
SKEW

  • SKEW is the difference in the arrival time of the clock pulse between a source and destination register (or other synchronous element)

  • Some Positive skew can be beneficial; it will decrease the required setup time:

  • Too much Positive skew can create a race condition, hold-time violation:

If the clock pulse arrives at the source reg first followed by the dest reg, then it is “positive skew”; if it arrives at the dest followed by the source, then it is “negative skew”.

D

Q

D

Q

Clock @ Source Register

Clock @ Destination Register

Clock skew

Clock @ Source Register

B

A

Clock @ Destination Register

Clock skew

Data “A” arrives at the destination, but it could be overridden by

Data “B”, which is meant for the next pulse at the destination reg.


Skew ii
SKEW (II)

  • Negative skew is usually undesirable; it will increase the required setup time:

  • If you use the global clock resources, then there should be no danger of hold-time violations for internal paths

  • TRACE can check for race conditions; set env.variable XILINX_DORACECHECK to activate this (same environment variable will activate skew-checking).

Clock @ Source Register

Clock @ Destination Register

Clock skew


Maxskew limiting skew
MAXSKEW: Limiting SKEW

  • Signal SKEW may also be constrained using the MAXSKEW constraint

    • NET $1I3245/$SIG_6 MAXSKEW=3;

    • I.e. specifies a maximum of 3ns difference between the source of net $1I3245/$SIG_6 and all its destinations is permissible

  • May use to control skew of logic driven clocks (or any clock using non-global resources)

  • Cannot constrain skew of global nets (Makes no sense as skew is fixed)


Reporting skew in trace
Reporting SKEW in TRACE

  • 2.1i TRACE will automatically account for clock skew on PERIOD constraints. Use the -skew switch or environment variable. XILINX_DOSKEWCHECK=1 (or XILINX_DORACECHECK).

  • Avoid using environment variable with PAR if there are IBUF clocks. PAR’s timing score may oscillate.

  • If you use the -skew switch with TRACE, remember that the timing score may be different than the score given by PAR (it could be better or worse).


Prorating constraints
Prorating Constraints

  • The tools will allow the user to prorate timing delay characteristics based on known environmental parameters. This is available only in the XC4000XL family.

  • Voltage: Allows the user to specify the operating voltage.

    UCF syntax: VOLTAGE = value [units]

  • Temperature: Allows the user to specify the operating temperature.

    UCF syntax: TEMPERATURE = value [C|F|K] Celsius is the default.


Placement other constraints

Placement & Other Constraints

Using LOC, BLKNM, and other physical constraints


Pin location constraints
Pin Location Constraints

  • “LOC” constraint used to locate pins:

    • From a Schematic attach the attribute “LOC=P12” to the pins you wish to lock down

    • I/O constraint based on net name in the .UCF file

      NET IOBLOCK/DATA0_IN LOC=P12;

    • I/O constraint based on the instance name in the .UCF file

      INST IOBLOCK/DATA_IN_PAD LOC=P12;

  • 2.1i produces a .PAD file. Design Manager provides a utility to translate the .PAD file to a .UCF file that contains the pin assignments. In the Design Manager, select the ‘Design’ menu, click on ‘Lock Pins’. This will generate the ucf file. However, the utility will always assume the I/O net name is the same as the IOB name in the NCD (not necessarily true if you use a BLKNM on the I/O. See solution #3534.


Other location constraints
Other Location Constraints

  • “LOC” constraint used to locate:

    • BUFTs, FFs, MAPs, CLBs, PADs, WANDs, decoders, global buffer

    • single components (e.g. CLBs)

      INST U45 LOC=CLB_R1C5;

    • ranges of components (but not IOs)

      INST U46 LOC=CLB_R2C2:CLB_R4C6;

    • multiple sites for single component

      INST U50 LOC=CLB_R1C1; CLB_R2C1;

    • I/O constraint based on net name

      NET IOBLOCK/DATA0_IN LOC=P12;


Prohibit location constraints
Prohibit Location Constraints

  • “PROHIBIT” Disallows the use of these sites within PAR:

    • CLBs, PADs, BUFTs, decoders, global buffer, function blocks/macrocells

    • single components (e.g. CLBs)

      CONFIG PROHIBIT=CLB_R1C5;

    • ranges of components (but not IOs)

      CONFIG PROHIBIT=CLB_R2C2:CLB_R4C6;

    • I/O constraint based on net name

      CONFIG PROHIBIT=P12;

Note: CONFIG PROHIBIT has specific limits depending upon the device. Please reference the “Libraries Guide” for these limits.


Mapping constraints
Mapping Constraints

  • Force logic into the same CLB.

    • Sometimes MAP doesn’t make the best decisions. This allows the user to map logic together.

  • Syntax

    INST state_reg_1 BLKNM=STATE1;

    INST state_reg_2 BLKNM=STATE1;

    INST my_FMAP_logic BLKNM=STATE1; #Can constrain FMAPs but not gates

  • This will force my_FMAP, state_reg_1, state_reg_2, and into the same CLB (“STATE1”).

Note: The remaining resources are still

up for grabs by MAP (in this case, one

of the FG’s is still available).


Implementation constraints
Implementation Constraints

  • Physical implementation may be controlled in the UCF file, such as:

    • FAST : Set Faster IO Slew rate

      • e.g. INST $1I87/OBUF FAST

    • PART : Define Part-type to be used

      • e.g. CONFIG PART=4005E-PQ160C-5;

    • BUFG : Force signal to onto global net (CPLD only)

      • e.g. INST clkgen/fastclk BUFG;

    • INIT : Define initial RAM/ROM Contents (primitives only)

      • e.g. INST $1I3245/ROM2 INIT = 5555;

  • Such Physical constraints may be Architecture dependent


Conclusion

Conclusion

Overview of Constraints


Basic constraints file
Basic constraints file

  • Most generic timing constraints for fastest PAR runtime

    NET CLK1 PERIOD = 40;

    NET OUT* OFFSET = OUT 13 AFTER CLK1;

    TIMESPEC TS01 = FROM PADS TO PADS 40;


More specific constraints file
More specific constraints file

  • Clocks

    NET CLK TNM=CLK;

    NET CLK2 TNM=CLK2;

    TIMESPEC TS_CLK01=PERIOD CLK40;

    TIMESPEC TS_CLK02=PERIOD CLK2 50;

  • Ignore paths between 2 async clocks

    TIMESPEC TS_TIG1=FROM:CLK:TO:CLK2:TIG;

    TIMESPEC TS_TIG2=FROM:CLK2:TO:CLK:TIG;

  • Generic path to outputs

    TIMESPEC TS_IO1=FROM:FFS:TO:PADS:20;

  • Two cycle path to slow outputs

    TIMESPEC TS_IO2=FROM:FFS:TO:PADS(SLOW*):TS_IO1*2;


More specific constraints file cont
More specific constraints file (cont.)

  • Offset for late input signal

    NET LATE_INPUT OFFSET=IN:30:AFTER:CLK;

  • Ignore static input signal

    NET CHIP_MODE TIG;

  • Static control registers

    INST CONTROL_BLOCK/CTRL_REG* TNM=CTRL_REG;

    TIMESPEC TS_CLK03 = FROM:CTRL_REG:TO:FFS=TS_CLK01*2;

  • Fast OBUF attached to component

    INST RAM_CS FAST;

  • Prohibit Pins

    CONFIG PROHIBIT = P6;


Issues to be aware of
ISSUES to be aware of

  • The .ucf file will be copied into the new revision directory as <design_name>.ucf, where the <design_name> is the name of the input netlist.

  • The design Manager can only use <design_name>.ucf for implementation in the Revision.

  • If the ucf file has errors, the ucf in the Revision directory needs to be modified, and NOT the original.


Issues to be aware of ii
ISSUES to be aware of (II)

  • TNM and PERIOD constraint cannot forward-trace through IBUF. TNM cannot forward-trace through BUFG either.

  • Use the “-u” switch with TRCE to report unconstrained paths (or Report Paths Not Covered In Timing Constraints for TA)

  • The -u will not necessarily contain every unconstrained path ( the static carry logic path in earlier schematic; STARTUP path). It essentially shows all “constrainable” unconstrained paths, such as paths that could have been reported with FROM:TO/PERIOD/OFFSET constraints.

Must apply to output net (of IBUF/BUFG) or use TNM_NET.

IBUF

TNM=;

PERIOD

BUFG

TNM=xxx


Issues to be aware of iii
ISSUES to be aware of (III)

  • Timing report often does not show 100% coverage of connections

Definition: A “connection” is a source/driver pairing. The following has 13

connections (paths internal to IOB/CLB are not connections):

4

5

6

7

Function

Generator

D

Q

D

Q

3

2

OUT1

8

1

CLOCK

9

OUT2

11

Function

Generator

TIG

10

STARTUP

12

OUT2

13

Function

Generator

CY4

Examine-CI

Not covered by usual set of

timespecs (can use MAXDELAY

on net to constrain)

CY4

Static signal driving LUT;

not covered by usual set of

timespecs (exotic case)

Force-1

Removed from analysis


Summary
Summary

  • All Constraints accessible from single constraints file

  • All Xilinx features may be constrained from constraints file

  • Full TimeSpec support provided from Constraints file

  • Improved TimeSpec capability provided

  • Refer to Chapter 12 (Attributes, Constraints and Carry Logic) of the Xilinx Libraries Guide for a full list of all supported constraints and examples of syntax


2 1i constraints

Documentation

  • Constraints Guide: Quick Start Guide appendix H.

  • Using Timing Constraints: Developmental System Reference Guide chapter 6.

  • Timing Analyzer: Timing Analyzer Reference/User Guide.

  • TRCE: Developmental System Reference Guide chapter 11.

  • Refer to Chapter 12 (Attributes, Constraints and Carry Logic) of the Xilinx Libraries Guide for a full list of all supported constraints and examples of syntax