690 likes | 703 Views
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.
E N D
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 .PCF Static Timing Estimates PAR BITGEN Layout of Physical Design Routes Physical Design Generates configuration file .NCD .BIT
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 • 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? • 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
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) Using PERIOD and OFFSET 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 • 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#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 • 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 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 • 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 • 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.
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 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 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 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
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 • 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 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 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) 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) • 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 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) Using FROM:TO and other constraints
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
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 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 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 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 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 • 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 • 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 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 • 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 • 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) • 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 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 • 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 • 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) 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) • 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.
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) • 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) • 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) • 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
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) • 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 • 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)