This appendix describes the steps used to implement a design with the Xilinx tools with a specific focus on how constraints are entered at each stage of design processing. It also describes the more common constraints you can apply to your designs to control the timing and layout of FPGAs or CPLDs. For a complete listing of all supported constraints, refer to the Libraries Guide. For a more complete description of timing constraints, refer to the Development System Reference Guide. This appendix includes the following sections.
The Xilinx tools allow you to control the implementation of your design by entering constraints. You can enter constraints during the design and implementation phases of the design flow. The following figure illustrates where constraints entry fits in the overall design flow.
Figure H.1 Entering Design Constraints |  |
During the design phase, you can enter constraints as follows.
You can apply location and timing constraints to your design. Use location constraints to control the mapping and positioning of the logic elements in the target device. The most common location constraints are pad constraints. Pad constraints are used to lock the pins of your design to specific I/O locations so that the pin placement is consistent from revision to revision. Use timing constraints to specify how fast a path must be to meet your speed requirements. You can use timing constraints for the placement and routing of your design.
Constraints entered directly in your input design are known as design constraints, and are eventually placed in your design netlist. If you want the constraints separated from your input design files, or if you want to modify your constraints without re-synthesizing your design, you can create a User Constraints File (UCF) in the Constraints Editor. This file is read by NGDBuild during the translation of your design, and is combined with an EDIF or XNF netlist into an NGD file. If a UCF file exists with the same name as the top-level netlist, it is automatically read. Otherwise, you must specify a file name for User Constraints in the Options dialog box.
The Constraints Editor is a new graphical tool in the Xilinx Development System that allows you to enter timing constraints and pin location constraints. You can enter constraints in the graphical interface without understanding UCF file syntax. The Constraints Editor passes these constraints to the implementation tools through a UCF file.
The Constraints Editor accepts the following input files.
By default, when the NGD file is opened, an existing UCF file with the same base name as the NGD file is used. Alternatively, you can specify the name of the UCF file.
The Constraints Editor writes out a valid UCF file and a valid NGD file.These files are processed by the Map program, which generates a PCF (Physical Constraints File).
The process of implementing a design with the Xilinx tools starts by constructing a logical design file (NGD) that represents the design created by the NGDBuild application. The NGD file contains all of the design's logic structures (gates) and constraints. NGDBuild controls the translation and merging of all of the related logic design files. All design files are translated from industry standard netlists to intermediate NGO files by XNF2NGD or EDIF2NGD netlist translation programs.
The following sections summarize the functions of user constraints files.
The Netlist Constraints File was developed as an alternative means for third party vendors to provide the Xilinx tools with design constraints. Historically, these constraints are in the design netlist and are annotated to the equivalent elements within the designs NGO file. In the current release of the Xilinx software, translating a logic design netlist to a NGO file includes annotating constraints present in the NCF file to the NGO design elements. The NCF file is local in scope and therefore must have the same root name as the netlist being translated. In addition, the local scope of the netlist allow entries within the NCF file to refer to specific nets or symbols without prefixing the entire hierarchical path of the net or symbol.
The “Entering Design Constraints” figure illustrates the Synopsys workstation design flow which utilizes a NCF file. The program DC2NCF converts the Synopsys constraints into NCF syntax. Refer to the Synopsys (XSI) Interface /Tutorial Guide for detailed information on using this flow.
Whether or not an NGO is written to disk for a LogiBlox component is dependent on the specific design creation technology being used. Many synthesis flows require that an NGO file be written to disk during component specification, while the typical schematic flow provides for on-the-fly compilation of NGO files.
The User Constraints File (UCF) provides a convenient mechanism for constraining a logical design without returning to the design entry tools. The process of building the complete logical design representation (NGD files) is performed by NGDBuild. In developing this complete design database, NGDBuild annotates design constraints in the UCF file. The syntax for the UCF is identical to the syntax for the NCF.
One main difference between the NCF and the UCF is how objects in the files are identified. A constraint applied with the UCF file must specify the complete hierarchical path name for the constrained instance or net, while an NCF constraint must only reference the specific net or symbol within the associated netlist. The difference in hierarchical path name requirements arises from the scope of the design files themselves; NCF files have a local scope and can therefore tolerate local references, while UCF files have a global scope and therefore require full hierarchical path names.
Another difference is the UCF can override NCF constraints. Because the NCF is considered an alternative mechanism for design creation tools to pass constraints to the Xilinx implementation tools, no conflicts should occur. In contrast, the UCF annotation includes a resolution mechanism to allow UCF constraints to write over constraints in the NCF. UCF constraints are more important because they occur later in the design flow, and provide a mechanism for establishing or modifying logical design constraints without requiring the user to re-enter a schematic or synthesis tool.
Versions prior to M1.2 required the -uc switch to identify a UCF which needs to be annotated to the design. Versions M1.2 and later allow UCF file annotation to be performed by default if the UCF file has the same base name as the input.
The NCD, or physical representation of the design, describes the design in terms of FPGA resources. The layout and timing analysis tools work with the NCD representation. The Physical Constraints File (PCF) contains the constraints as they relate to the NCD. Layout and timing constraints are written in terms of the physical design's components (COMPs), fractions of COMPs (BELs) and collections of COMPs (macros). Because of this different design viewpoint, the PCF syntax is not necessarily the same as the logical design constraints files (UCF/NCF). Furthermore, because the PCF file is written for use by the physical implementation tools, logical names may no longer be similarly represented in the physical design.
If you modify the PCF file, enter your constraints after the “SCHEMATIC END;” line. Otherwise, your constraints are overwritten every time MAP is executed using that PCF file.
Xilinx constraints are case sensitive because EDIF is a case-sensitive format. You should specify the net names and instance names exactly as they are in your schematic or code. Also, be consistent when using TNMs and other user-defined names in your constraints file; always use the same case throughout. For site names (such as “CLB_R2C8” or “P2”), use upper-case letters only.
The following sections summarize the functions of timing constraints. The PERIOD and OFFSET constraints are preferred for Xilinx designs.
The following schematic example illustrates the use of the PERIOD constraint referenced to timegroups CLK2_GRP and CLK3. This example is for multiple clock designs. Use FROM:TO to constrain data paths between the two clock domains.
Figure H.2 PERIOD Example | |
Following is the corresponding UCF file.
# UCF PERIOD style Timespecs
NET CLK2 TNM = CLK2_GRP ;
NET CLK3 TNM = CLK3 ;
TIMESPEC TS03 = PERIOD CLK2_GRP 50 ;
TIMESPEC TS04 = PERIOD CLK3 TS03 * 2 ;
In addition, the example also shows how constraints and nets may be given the same name because they occupy separate name-spaces. Also, it shows the constraint syntax whereby one Timespec is defined relative to another (the value of TS04 is declared to be two times that of TS03).
The PERIOD constraint covers all timing paths which start or end at a register, latch, or synchronous RAM which is clocked by the referenced net. The only exception to this rule are paths to output pads which are not covered by the PERIOD constraint. (Input pads, which are the source of a “pad-to-setup” timing path for one of the specified synchronous elements, are covered by the PERIOD constraint.)
The TIMESPEC form of the PERIOD constraint allows flexibility in group definitions and allows you to define clock timing relative to another TIMESPEC. The flexibility of the TIMESPEC form of the PERIOD constraint arises from being able to modify the contents of the TIMEGRP once the design has been mapped. By adding or removing objects from the TIMGRP, which are listed in the PCF file, the paths which are covered by the PERIOD constraint may be altered.
If the flexibility of the TIMESPEC form is not required, the NET form of the PERIOD constraint may be used. The syntax for the NET form of the PERIOD constraint is simpler than the TIMESPEC form, while continuing to provide the same path coverage. The following example illustrates the syntax of the NET form of the PERIOD constraint.
# NET form of the PERIOD timing
# constraints (no TSIdentifier)
NET CLK PERIOD = 40 ;
This is the recommendation of using PERIOD on a single clock design in which data does not pass between the clock domains.
PERIOD includes clock skew in the path analysis.
Offsets are used to define the timing relationship between an external clock and its associated data-in or data-out-pin. Using this option allows you to:
The three types of offset specifications are global, specific, and group. Because the global and group OFFSET constraints are not associated with a single data net or component, these two types can also be entered on a TIMESPEC symbol in the design netlist with Tsid. See the timing constraints chapter in the Development System Reference Guide for details.
In the following example, the OFFSET constraint is applied to a net connecting with a PAD (see “Using OFFSET Constraints” figure). It defines the delay of a signal relative to a clock, and is only valid for registered data paths. The OFFSET constraint specifies the signal delay external to the chip, allowing the implementation tools to automatically adjust relevant internal delays (CLK buffer and distribution delays) to accommodate the external delay specified with this constraint.
# Net form of the OFFSET timing constraint
NET ADD0_IN OFFSET = IN 14 AFTER CLK_IN;
In analyzing OFFSET paths, the Xilinx timing tools adjust the PERIOD associated with the constrained synchronous element based on both the timing specified in the OFFSET constraint and the delay of the referenced clock signal.
In the following figure, assume a delay of 8 ns for the signal CLK to arrive at the CLB, a 5 ns setup time for ADD0, and a 14 ns OFFSET delay for the signal ADD0. Assume a period of 40 ns is specified. The Xilinx tools allocate 29 ns for the signal ADD0 to arrive at the CLB input pin (40ns - 14ns + 8ns - 5ns = 29ns).
Figure H.3 Using OFFSET Constraints | |
This same timing constraint may be applied using the FROM PADS TO FFS timing constraint. However, using a FROM TO methodology would require you to know the intrinsic CLK net delay, and you would have to adjust the value assigned to the FROM TO Timespec. The internal CLK net delay is implicit in the OFFSET/PERIOD constraint. Furthermore, migrating the design to another speed grade or device will require modification of the FROM TO Timespec to accommodate the new intrinsic CLK net delay. It should be noted that an alternative solution is to use the flip-flop in the IOB of certain FPGA architectures (XC4000E/EX, for instance), as the clock-to-setup time is specified in the Programmable Logic Data Book.
Relative Timespecs can only be applied to similar Timespecs. For example, a PERIOD Timespec may be defined in terms of another PERIOD Timespec, but not a FROM TO Timespec.
When using the From:To constraint, the path(s) that are constrained are specified by declaring the start point and end point, which must be a pad, flip-flop, latch, RAM, or user-specified sync point (see TPSYNC). To group a set of endpoints together, you may attach a TNM attribute to the object being an instance or macro (or to a net that is an input to the object). With a macro the TNM traverses the hierarchy to tag all relevant objects. A TIMEGRP is a mechanism for combining two or more sets of TNMs or other TIMEGRPs together, or alternatively, to create a new group by pattern matching (grouping a set of objects that all have output nets that begin with a given string).
TNMs are used by the current Xilinx tools in the same way as the XACTstep 5.2 tools - identification of a group of design objects which are to be referenced within a Timespec. If a TNM is placed on a net, the tools determine TNM membership by tracing forward from the specified net to all the valid endpoints of the net. Refer to the Development System Reference Guide for more information on this subject.
The following schematic shows an example of TNM, TIMESPEC, and TIMEGRP statements.
Figure H.4 Example TNM, TIMESPEC, and TIMEGRP | |
Following is the UCF file that corresponds to the preceding figure:
# This is a comment line
# UCF FROM : TO style Timespecs NET DATA_EN TNM = PIPEA ;
TIMEGRP BUSPADS = PADS(BUS*) ;
TIMESPEC TS01 = FROM BUSPADS TO PIPEA 20 ;# Spaces or colons (:) may be used as field separators TIMESPEC TS02 = FROM FFS TO RAMS 15 ;The first line of the previous example illustrates the application of the TNM (Timing Name) PIPEA to the net named DATA_EN. The second line illustrates the TIMEGRP design object formed using a pattern matching mechanism in conjunction with the pre-defined TIMEGRP “PADS”. In this example, the TIMEGRP named BUSPADS will include only those PADs with names that start with BUS.
Each of the user-defined Timegroups is then used to define the object space constrained by the timing specification (Timespec) named TS01. This timing specification states that all paths from each member of the BUSPADS group to each member of the PIPEA group needs to have a path delay that does not exceed 20 nanoseconds (ns are the default units for time). The TIMESPEC TS02 constraint illustrates a similar type of timing constraint using the predefined groups FFS and RAMS.
All From:To Timespecs must be relative to a Timegroup. The previous example illustrates that Timegroups may be defined by the user either explicitly (TIMEGRPs) or implicitly (TNMs), or they may be predefined groups (PADS, LATCHES, FFS, RAMS).
There is an additional keyword that can be added to the From:To spec that allows the user to narrow the set of paths that are covered. By using the From Thru To form, you may constrain only those paths that go through a certain set of nets, defined by the TPTHRU keyword, as shown in the following example.
# UCF FROM:TO Timespec using THRU
NET $1I6/thisnet TPTHRU=these ;
NET $1I6/thatnet TPTHRU=these ;
TIMEGRP sflops=FFS(DATA*) ;
TIMEGRP dflops=FFS(OUTREG*) ;
TIMESPEC TS23=FROM:sflops:THRU:these:TO:dflops:20 ;
Here, only those paths that go from the Q pin of the sflops through the nets $1I6/thisnet and $1I6/thatnet and on to the D pin of dflops will be controlled by TS23.
In the XACT 5.x/6.x methodology, only flip-flops, RAMs, latches and pads could be identified as a startpoint or endpoint for a timing specification. However, in the Xilinx toolset, you can now define any node as a source or destination for a Timespec with the TPSYNC keyword. TPSYNC is attached to a set of nets, pins, or instances in the design.
For instance, suppose a design has a PAD ENABLE_BUS that must arrive at the enable pin of several different tristate buffers in less than a specified time. With the current Xilinx tools, you can now define the tristate buffer as an endpoint for a timing spec.
The following figure illustrates TPSYNC.
Figure H.5 TPSYNC Example | |
Following is the corresponding UCF file.
# TPSYNC example; pad to a 3-state buffer enable pin
# Note TPSYNC attached to 3-state buffer's output NETNET BUS3STATE TPSYNC=bus3;
TIMESPEC TSNewSpc3=FROM:PAD(ENABLE_BUS):TO:bus3:20ns;In the NET statement shown previously, the TPSYNC is attached to the output net of a tristate buffer called BUS3STATE. If a TPSYNC is attached to a net, then the source of the net is considered to be the endpoint (in this case, the tristate buffer itself). The subsequent TIMESPEC statement can use the TPSYNC name just as it uses a TNM name.
The next TPSYNC example shows how you may use the keyword PIN instead of NET if you wish to attach an attribute to a pin.
# Note TPSYNC attached to 3-state buffer's enable PINPIN $1I6/BUSMACRO1/TRIBUF34.T TPSYNC=bus1;
TIMESPEC TSNewSpc1=FROM PAD(ENABLE_BUS) TO bus1 20ns;In this example, the instance name of the tristate buffer is given followed by the pin name of the enable (.T). If a TPSYNC is attached to a primitive input pin, then the primitive's input is considered the startpoint or endpoint for a timing specification. If it is attached to a output pin, then the output of the primitive is used.
The last TPSYNC example shows how you may use the keyword INST if you wish to attach an attribute to a instance.
# Note TPSYNC attached to 3-state buffer INSTANCE (UCF # file)INST $1I6/BUSMACRO2/BUFFER_2 TPSYNC=bus2;
TIMESPEC TSNewSpc2=FROM:PAD(ENABLE_BUS):TO:bus2:20ns;If a TPSYNC is attached to an instance, then the output of the instance is considered the startpoint or endpoint for a timing specification.
When a Timespec is declared that includes paths where the timing is not important, the tools may create a less optimal route since there is more competition for routing resources. This problem can be alleviated by using a TIG (timing ignore) attribute on the non-critical nets. TIG will cause all paths that fan out from the net or pin where it is applied to be ignored for purposes of timing analysis.
#TIG example (UCF file)
NET $1I456/slow_net TIG=TS01, TS04 ;
The previous syntax indicates that $1I456/slow_net should not have the Timespec TS01 or TS04 applied to it.
On the other hand, the following syntax indicates that the layout tools should ignore paths through the $1I456/slow_net net for all known Timespecs.
#Global TIG example NET $1I456/slow_net TIG;Skew is the difference between the minimum and maximum of the maximum load delays on a net. You can control the maximum allowable skew on a net by attaching the MAXSKEW attribute directly to the net.
#MAXSKEW example NET $1I345/net_a MAXSKEW=3 ;The above indicates that 3 ns is the maximum skew allowed on $1I345/net_a. For a detailed example of how MAXSKEW works, see the Development System Reference Guide.
A user may assign a precedence to Timespecs only within a certain class of constraints. For example, you may specify a priority for a particular FROM TO specification to be greater than another, but may not specify a FROM TO constraint to have priority over a TIG constraint.
The following example illustrates the explicit assignment of priorities between two same-class timing constraints, the lowest number having the highest priority.
# Priority UCF Example
TIMESPEC TS01 = FROM GROUPA TO GROUPB 40 PRIORITY 4; TIMESPEC TS02 = FROM GROUP1 TO GROUP2 35 PRIORITY 2;
The following two subsections describe the order of precedence for constraint files and timing constraints.
Layout constraints also have an inherent precedence which is based on the type of constraint and the site description provided to the tools. If two constraints are of the same priority and cover the same path, then the last constraint in the constraint file will override any other constraints that overlap (unlike in XACT 5.x/6.x, where the “tightest” specification would be used).
Within constraint sources, the following priorities apply.
Layout constraints also have an inherent precedence which is based on the type of constraint and the site description provided to the tools. If two constraints are of the same priority and cover the same path, then the last constraint in the constraint file will override any other constraints that overlap.
The mapping constraints in the following example illustrate some of the capabilities for controlling the implementation process for a design. The OPTIMIZE attribute is attached to the block of logic associated with the instance GLUE. All the combinatorial logic in the GLUE block is optimized for speed (minimizing levels of logic) while other aspects of the design are processed by the default mapping algorithms (assuming the design based optimization switches are not issued).
# Mapping Constraint INST GLUE OPTIMIZE = SPEED ;# Layout Constraint
# LOC a pin NET IOBLOCK/DATA0_IN LOC = P12 ;# Reserve a pin (Pin 24 should be unused) CONFIG PROHIBIT = P24 ;The layout constraint in the previous example illustrates the use of a full hierarchical path name for the net named DATA0_IN in the application of the I/O location constraint. In this example, IOBLOCK is a hierarchical boundary which contains the net DATA0_IN. Location constraints applied to “Pad nets” are used to constrain the location of the PAD itself, in this case to site P12.
If the design contains a PAD, the constraint could have been just as easily applied to it directly (some design flows do not provide explicit I/O pads in the design netlist).
The previous section described how to constrain your design's timing. The following sections summarize the available constraints.
Xilinx recommends defining design requirements at the highest level of abstraction first, and then fine tuning the timing requirements using more specific TIMESPECs as necessary. This methodology is recommended for the following reasons.
The “Timing Symbols and Default Values” table lists the block delay symbols and their description. There is a one-to-many correspondence between these symbol names and data book symbol names. For those symbols listed as having a default value of disabled, no timing analysis will be performed on paths which have segments composed of symbol path. As an example, paths which have a set/reset to output path will not be analyzed. Any of the block delays (Symbol) listed in the table may be explicitly enabled or disabled using the PCF.
The following gives an example of the PCF syntax which would be used to enable the path tracing for all paths which contain RAM data to out paths. Note that this PCF directive is placed in the user section of the PCF.
SCHEMATIC END;
// This is a PCF Comment line
// Enable RAM data to out path tracing
ENABLE = ram_d_o;
| Symbol | Default | Description |
|---|---|---|
| reg_sr_q | Disabled | Set/Reset to output propagation delay. |
| lat_d_q | Disabled | Data to output transparent latch delay. |
| ram_d_o | Disabled | RAM data to output propagation delay. |
| ram_we_o | Enabled | Ram write enable to output propagation delay. |
| tbuf_t_o | Enabled | TBUF tri-state to output propagation delay. |
| tbuf_i_o | Enabled | TBUF input to output propagation delay. |
| io_pad_I | Enabled | IO pad to input propagation delay. |
| io_t_pad | Enabled | IO tri-state to pad propagation delay. |
| io_o_I | Enabled | IO output to input propagation delay. Disabled for tri-stated IOBs. |
| io_o_pad | Enabled | IO output to pad propagation delay. |
For further explanation and examples of each of the constraints, see the Libraries Guide.
| Origin of Constraint | ||
|---|---|---|
| Constraint | Schematic | UCF* |
| BASE | Y | N |
| BLKNM | Y | Y |
| BUFG | Y | Y |
| CLKDV_DIVIDE | Y | Y |
| COLLAPSE | Y | Y |
| COMPGRP | N | N |
| CONFIG*** | Y | N |
| DECODE | Y | Y |
| DIVIDE1_BY DIVIDE2_BY | Y | N |
| DOUBLE | Y | N |
| DRIVE | Y | Y |
| DROP_SPEC | N | Y |
| DUTY_CYCLE_CORRECTION | Y | Y |
| EQUATE_F EQUATE_G | Y | N |
| FAST | Y | Y |
| FILE | Y | N |
| FREQUENCY | N | N |
| HBLKNM | Y | Y |
| HU_SET | Y | Y |
| INIT | Y | N |
| INIT_0x | Y | N |
| INREG | Y | Y |
| IOB | Y | Y |
| KEEP | Y | Y |
| LOC | Y | Y |
| LOCATE | N | N |
| LOCK | N | N |
| MAP | Y | Y |
| MAXDELAY | Y | Y |
| MAXSKEW | Y | Y |
| MEDDELAY | Y | Y |
| NODELAY | Y | Y |
| NOREDUCE | Y | Y |
| OFFSET | N | Y |
| OPTIMIZE | Y | Y |
| OPT_EFFORT | Y | Y |
| OUTREG | Y | Y |
| PATH | N | N |
| PART | Y | Y |
| PENALIZE TILDE | N | N |
| PERIOD | Y | Y |
| PIN | N | N |
| PRIORITIZE | N | N |
| PROHIBIT | Y | Y |
| PWR_MODE | Y | Y |
| RLOC | Y | Y |
| RLOC_ORIGIN | Y | Y |
| RLOC_RANGE | Y | Y |
| S(ave) Net Flag Attributes | Y | Y |
| SITEGRP | N | N |
| SLOW | Y | Y |
| STARTUP_WAIT | Y | Y |
| TEMPERATURE | Y | Y |
| TIG | Y | Y |
| Timegroup Attributes | Y | Y |
| TNM | Y | Y |
| TNM_NET | Y | Y |
| TPSYNC | Y | Y |
| TPTHRU | Y | Y |
| TSidentifier | Y | Y |
| U_SET | Y | Y |
| USE_RLOC | Y | Y |
| VOLTAGE | Y | Y |
| WIREAND | Y | Y |
| XBLKNUM | Y | Y |
| *The UCF and NCF files use the same constraints with the exception of the INIT constraint, which can only be used in NCF files. | ||
| ** Use cautiously - while constraint is available, there are differences between the UCF/NCF and PCF syntax. | ||
| *** The CONFIG attribute configures internal options of an XC3000 CLB or IOB. Do not confuse this attribute with the CONFIG primitive, which is a table containing PROHIBIT and PART attributes. | ||
The following sections summarize the functions of timespecs.
The PERIOD spec covers all timing paths that start or end at a register, latch, or synchronous RAM which are clocked by the reference net (excluding pad destinations). Also covered is the setup requirement of the synchronous element relative to other elements (ex. flip flops, pads, etc...).
The default unit for time is nanoseconds.
NET clk20MHz PERIOD = 50 ;
NET clk50mhz TNM = clk50mhz ;
TIMESPEC TS01 = PERIOD clk50mhz 20 ;
FROM TO style timespecs can be used to constrain paths between time groups.
The RAMS, FFS, PADS, and LATCHES keywords are predefined time groups used to specify all elements of each type in a design.
TIMESPEC TS02 = FROM PADS TO FFS 36 ;
TIMESPEC TS03 = FROM FFS TO PADS 36 ns ;
TIMESPEC TS04 = FROM PADS TO PADS 66 ;
TIMESPEC TS05 = FROM PADS TO RAMS 36 ;
TIMESPEC TS06 = FROM RAMS TO PADS 35.5 ;
To automatically include clock buffer/routing delay in your “PADS TO synchronous element or synchronous element TO PADS timing specifications, use OFFSET constraints instead of FROM TO constraints.
If you can ignore timing of paths, use Timing Ignore (TIG).
The “*” character is a wild-card that can be used for bus names. A “?” character can be used to wild-card one character.
If you have multi-cycle FF to FF paths, you can create a time group using either the TIMEGRP or TNM statements.
WARNINGMany VHDL/verilog synthesizers do not predictably name flip flop Q output nets. Most synthesizers do assign predictable instance names to flip flops, however.
TIMEGRP slowffs = FFS(inst_path/ff_q_output_net1* inst_path/ff_q_output_net2*);
INST inst_path/ff_instance_name1_reg* TNM = slowffs ;
INST inst_path/ff_instance_name2_reg* TNM = slowffs ;
If a FF clock-enable is used on all flip flops of a multi-cycle path, you can attach TNM to the clock enable net.
TNM attached to a net “forward traces” to any FF, LATCH, RAM, or PAD attached to the net.
NET ff_clock_enable_net TNM = slowffs ;
Example of using “slowffs” timegroup, in a FROM:TO timespec, with either of the three timegroup methods previously shown.
TIMESPEC TS10 = FROM slowffs TO FFS 100 ;
MEDDELAY/NODELAY can be attached to a CLB FF that is pushed into an IOB by the “map -pr i” option.
Refer to the Libraries Guide for additional timespec features.
In the XSI HDL methodology, whenever large blocks of RAM/ROM are needed, LogiBLOX RAM/ROM modules are instantiated in the HDL code. With LogiBLOX RAM/ROM modules instantiated in the HDL code, timing and/or placement constraints on these RAM/ROM modules, and the RAM/ROM primitives that comprise these modules, can be specified in a .ucf file. To create timing and/or placement constraints for RAM/ROM LogiBLOX modules, knowledge of how many primitives will be used and how the primitives, and/or how the RAM/ROM LogiBLOX modules are named is needed.
When a RAM/ROM is specified with LogiBLOX, the RAM/ROM depth and width are specified. If the RAM/ROM depth is divisible by 32, then 32x1 primitives are used. If the RAM/ROM depth is not divisible by 32, then 16x1 primitives are used instead. In the case of dual-port RAMs, 16x1 primitives are always used. Based on whether 32x1 or 16x1 primitives are used, the number of RAM/ROM can be calculated.
For example, if a RAM48x4 was required for a design, RAM16x1 primitives would be used. Based on the width, there would be four banks of RAM16x1s. Based on the depth, each bank would have three RAM16x1s.
Using the example of a RAM48x4, the RAM primitives inside the LogiBLOX would be named as follows.
MEM0_0 MEM1_0 MEM2_0 MEM3_0
MEM0_1 MEM1_1 MEM2_1 MEM3_1
MEM0_2 MEM1_2 MEM2_2 MEM3_2
Each primitive in a LogiBLOX RAM/ROM module has a instance name of MEMx_y, where y represents the primitive position in the bank of memory, and where x represents the bit position of the RAM/ROM output.
For the next two items, refer to the Verilog/VHDL examples included at the end of this section. The Verilog/VHDL example instantiates a RAM32x2S, which is in the bottom of the hierarchy. The RAM32x2S was made with LogiBLOX. The next two items are written within the context of the Verilog examples, but also apply to the VHDL examples as well. Note, the runscripts included were designed for FPGA Compiler. If you want to use Design Compiler, remove the replace_fpga step.
LogiBLOX RAM/ROM modules in the FPGA/Design Compiler flow are constrained via a .ucf file. LogiBLOX RAM/ROM modules instantiated in the HDL code can be referenced by the full-hierarchical instance name. If a LogiBLOX RAM/ROM module is at the top-level of the HDL code, then the instance name of the LogiBLOX RAM/ROM module is just the instantiated instance name.
In the case of a LogiBLOX RAM/ROM, which is instantiated within the hierarchy of the design, the instance name of the LogiBLOX RAM/ROM module is the concatenation of all instances which contain the LogiBLOX RAM/ROM. For FPGA/Design Compiler, the concatenated instance names are separated by a “/”. In the example, the RAM32X1S is named memory. The module memory is instantiated in Verilog module inside with an instance name U0. The module inside is instantiated in the top-level module test. Therefore, the RAM32X1S can be referenced in a .ucf file as U0/U0. For example, to attach a TNM to this block of RAM, the following line could be used in the .ucf file.
INST U0/U0 TNM=block1;
Since U0/U0 is composed of two primitives, a timegroup called block1 would be created; block1 TNM could be used throughout the .ucf file as a Timespec end/start point, and/or or U0/U0 could have a LOC area constraint applied to it. If the RAM32X1S has been instantiated in the top-level file, and the instance name used in the instantiation was U0, then this block of RAM could just be referenced by U0.
If FPGA Express is the tool being used, then the concatenated instance names are separated by a “_” instead.
INST U0_U0 TNM=block1;
Sometimes its necessary to apply constraints to the primitives that compose the LogiBLOX RAM/ROM module. For example, if you choose a floorplanning strategy to implement your design, it may be necessary to apply LOC constraints to one or more primitives inside a LogiBLOX RAM/ROM module.
Consider the previous RAM32x2S example, suppose that the each of the RAM primitives had to be constrained to a particular CLB location. Based on the rules for determining the MEMx_y instance names, using the previous example, each of RAM primitives could be referenced by concatenating the full-hierarchical name to each of the MEMx_y names. The RAM32x2S created by LogiBLOX would have primitives named MEM0_0 and MEM1_0. So, for FPGA/Design Compiler, CLB constraints in a .ucf file for each of these two items would be:
INST U0/U0/MEM0_0 LOC=CLB_R10C10;
INST U0/U0/MEM0_1 LOC=CLB_R11C11;
For FPGA Express, the CLB constraints would be:
INST U0_U0/MEM0_0 LOC=CLB_R10C10;
INST U0_U0/MEM0_1 LOC=CLB_R11C11;
This section includes FPGA/Design Compiler and Express Verilog Examples.
module test(DATA,DATAOUT,ADDR,C,ENB);input [1:0] DATA;
output [1:0] DATAOUT;
input [4:0] ADDR;
input C;
input ENB;
wire [1:0] dataoutreg;
reg [1:0] datareg;
reg [1:0] DATAOUT;<
reg [4:0] addrreg;inside U0 (.MDATA(datareg),.MDATAOUT(dataoutreg),.MADDR(addrreg),.C(C),.WE(ENB));always@(posedge C) datareg = DATA;always@(posedge C) DATAOUT = dataoutreg;always@(posedge C) addrreg = ADDR; endmodulemodule inside(MDATA,MDATAOUT,MADDR,C,WE);
input [1:0] MDATA;
output [10] MDATAOUT;
input [4:0] MADDR;
input C;
input WE;
memory U0 ( .A(MADDR), .DO(MDATAOUT), .DI(MDATA), .WR_EN(WE), .WR_CLK(C));
endmodule
module memory(A, DO, DI, WR_EN, WR_CLK);
input [4:0] A;
output [1:0] DO;
input [1:0] DI;
input WR_EN;
input WR_CLK;
endmodule
TOP=test part = “4028expg299-3”
read -f verilog “guts.v”
read -f verilog “inside.v”
read -f verilog “test.v”
current_design TOP
remove_constraint -all
set_port_is_pad “*”
insert_pads
compile
write -format db -hierarchy -output TOP + “_compiled.db”
replace_fpga
set_attribute TOP “part” -type string part
write -format db -hierarchy -output TOP + “.db”
ungroup -all -flatten
write_script > TOP + “.dc” sh dc2ncf test.dc
remove_design guts
write -f xnf -h -o TOP + “.sxnf
INST “U0/U0” TNM = usermem;
TIMESPEC TS_6= FROM : FFS :TO: usermem: 50;
INST “U0/U0/mem0_0” LOC=CLB_R7C2;
INST “U0_U0” TNM = usermem;
TIMESPEC TS_6= FROM : FFS :TO: usermem: 50;
INST “U0_U0/mem0_0” LOC=CLB_R7C2;
This section includes FPGA/Design Compiler and Express VHDL Examples.
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_UNSIGNED.all;entity test is
port( DATA: in STD_LOGIC_VECTOR(1 downto 0);
DATAOUT: out STD_LOGIC_VECTOR(1 downto 0);
ADDR: in STD_LOGIC_VECTOR(4 downto 0);
C, ENB: in STD_LOGIC);
end test;architecture details of test is
signal dataoutreg,datareg: STD_LOGIC_VECTOR(1 downto 0);
signal addrreg: STD_LOGIC_VECTOR(4 downto 0);component inside
port(MDATA: in STD_LOGIC_VECTOR(1 downto 0);
MDATAOUT: out STD_LOGIC_VECTOR(1 downto 0);
MADDR: in STD_LOGIC_VECTOR(4 downto 0);
C,WE: in STD_LOGIC);
end component;begin
U0: inside port map(MDATA=>datareg.,MDATAOUT=>dataoutreg.,MADDR=>addrreg,C=>C,WE=>ENB); process( C )
begin
if(Cevent and C=1) then
datareg <= DATA;
end if;<
end process; process( C )
begin
if(Cevent and C=1) then
DATAOUT <= dataoutreg;
end if;
end process; process( C )
begin
if(Cevent and C=1) then
addrreg <= ADDR;
end if;
end process;end details;entity inside is
port(
MDATA: in STD_LOGIC_VECTOR(1 downto 0);
MDATAOUT: out STD_LOGIC_VECTOR(1 downto 0);
MADDR: in STD_LOGIC_VECTOR(4 downto 0);
C,WE: in STD_LOGIC);
end inside;
architecture details of inside is component memory
port(
A: in STD_LOGIC_VECTOR(4 downto 0);
DO: out STD_LOGIC_VECTOR(1 downto 0);
DI: in STD_LOGIC_VECTOR(1 downto 0);
WR_EN,WR_CLK: in STD_LOGIC);
end component;
begin
U0: memory port map(A=>MADDR,DO=>MDATAOUT,
DI=>MDATA,WR_EN=>WE,WR_CLK=>C);
end details;
TOP=test part = “4028expg299-3”
analyze -f vhdl “guts.vhd”
analyze -f vhdl “inside.vhd”
analyze -f vhdl “test.vhd”
elaborate TOP
current_design TOP
remove_constraint -all
set_port_is_pad “*”
insert_pads
compile
write -format db -hierarchy -output TOP + “_compiled.db”
replace_fpga
set_attribute TOP “part” -type string part
write -format db -hierarchy -output TOP + “.db”
ungroup -all -flatten
write_script > TOP + “.dc” sh dc2ncf test.dc
remove_design guts
write -f xnf -h -o TOP + “.sxnf”INST “U0/U0” TNM = usermem;
TIMESPEC TS_6= FROM : FFS :TO: usermem 50;
INST “U0/U0/mem0_0” LOC=CLB_R7C2;
INST “U0_U0” TNM = usermem;
TIMESPEC TS_6= FROM : FFS :TO: usermem: 50;
INST “U0_U0/mem0_0” LOC=CLB_R7C2;
