The following table illustrates which architectures can be used with each option.
| Options | Architectures |
|---|---|
| -b | Spartan, xc4000e/l |
| -c | Spartan, SpartanXL, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -cm | Spartan, SpartanXL, virtex, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -d | xc3000a/l, xc3100a/l |
| -f | Spartan, SpartanXL, virtex, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -fp | Spartan, SpartanXL, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -gf | Spartan, SpartanXL, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -gm | Spartan, SpartanXL, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -ir | Spartan, SpartanXL, virtex, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -k | Spartan, SpartanXL, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -l | Spartan, SpartanXL, virtex, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -o | All architectures |
| -oe | Spartan, SpartanXL, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -os | Spartan, SpartanXL, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -p | Spartan, SpartanXL, virtex, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
| -pr | Spartan, SpartanXL, virtex, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv |
| -r | Spartan, SpartanXL, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv |
| -u | Spartan, SpartanXL, virtex, xc3000a/l, xc3100/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 |
The following subsections describe each command line option and its effect on the behavior of MAP.
The -b option replaces GCLKs and ACLKs (primary and secondary clocks) with a generic clock buffer (CKBUF) prior to mapping. This option is useful when you are mapping an XNF netlist created in the Synopsys environment where all clocks are mapped to BUFGP (primary clock buffers) and secondary clocks are not used. The -b option gives MAP the greatest amount of latitude in choosing the clock assignments.
MAP does not override the LOC= constraint.
-c [packfactor]
The -c option determines the degree to which CLBs are packed when the design is mapped. The valid range of values for the packfactor is 0-100.
The packfactor values ranging from 1 to 100 roughly specify the percentage of CLBs available in a target device for packing your design's logic.
A packfactor of 100 means that all CLBs in a target part are available for design logic. A packfactor of 100 results in minimum packing density, while a packfactor of 1 represents maximum packing density. Specifying a lower packfactor results in a denser design, but the design may then be more difficult to place and route.
The -c 0 option specifies that only *related* logic (that is, logic having signals in common) should be packed into a single CLB. Specifying -c 0 yields the least densely packed design.
For values of -c from 1 to 100, MAP merges unrelated logic into the same CLB only if the design requires more resources than are available in the target device (an "overmapped" design). If there are more resources available in the target device than are needed by your design, the number of CLBs utilized when -c 100 is specified may equal the number required when -c 0 is specified.
The -c 1 setting should only used to determine the maximum density (minimum area) to which a design can be packed; it should almost never be used in the actual implementation of a design. Designs packed to this maximum density generally have longer run times, severe routing congestion problems in PAR, and poor design performance.
The default packfactor (the value if you do not specify a -c option, or enter a -c option without a packfactor) is 97% for the XC4000E architecture and 100% for all other XC4000 architectures.
Processing a design with the -c 0 option is a good way to get a first estimate of the number of CLBs required by your design.
This option does not apply to Virtex.
-cm {area | speed | balanced}
The -cm option specifies the criteria used during the “cover” phase of MAP. In the “cover” phase, MAP assigns the logic to CLB function generators (LUTs).
The default setting for the -cm option is area (cover for minimum number of LUTs).
If you specify this option, MAP can use the DI (Direct Input) pin of each CLB in the device for the XC3000A, XC3000L, XC3100A and XC3100L architectures. If you use this pin, the setup time requirement for each CLB flip-flop is reduced, but the DI pin has a hold time requirement (which none of the other CLB logic input pins has). Using the DI pin results in a denser design, but the design may then be more difficult to place and route. Even if you specify the -d option, MAP tries to minimize the use of the DI pin.
-f command_file
The -f option executes the command line arguments in the specified command_file. For more information on the -f option, see the “-f Option” section of the “Introduction” chapter.
-fp filename.mfp
The -fp option requires the specification of an existing MFP file created by the Floorplanner. The MFP file is essentially used as a guide file for mapping.
The MFP file is created in the Floorplanner from a previously mapped NCD file. If you use the -fp option, you cannot use the guide file option (-gf).
The -fp option can be used with the XC4000/E/L, XC4000EX/XL/XLA/XV, Spartan, and SpartanXL architectures.
For more information about the Floorplanner, see the Floorplanner Reference/User Guide.
-gf guidefile
The -gf option specifies the name of an existing NCD file (from a previous MAP run) to be used as a guide for the current MAP run. For a description of guided mapping, see the “Guided Mapping” section.
This option does not apply to Virtex.
-gm {exact | leverage}
The -gm option specifies the form of guided mapping to be used.
In the EXACT mode the mapping in the guide file is followed exactly. In the LEVERAGE mode, the guide design is used as a starting point for mapping but, in cases where the guided design tools cannot find matches between net and block names in the input and guide designs, or your constraints rule out any matches, the logic is not guided.
For a description of guided mapping, see the “Guided Mapping” section.
This option does not apply to Virtex.
If you enter the -ir option, MAP uses RLOC constraints to group logic within CLBs, but does not use the constraints to generate RPMs (Relationally Placed Macros) controlling the relative placement of CLBs. Stated another way, the RLOCs are not used to control the relative placement of the CLBs with respect to each other.
For the XC4000 and Spartan architectures, the -ir option has an additional behavior; the RLOC constraint that cannot be met is ignored and the mapper will continue processing the design. A warning is generated for each RLOC that is ignored. The resulting mapped design is a valid design.
This option does not apply to the XC3000 architecture.
If the -k option is specified, logic functions of five inputs are mapped into a single CLB (if possible). To perform this mapping, all three of the function generators in the CLB may be used.
By mapping 5-input functions into single CLBs, the -k option may produce a mapping with fewer levels of logic, thus eliminating a number of CLB-to-CLB delays. On the other hand, using the -k option may prevent logic from being packed into CLBs in a way that minimizes CLB utilization.
This option does not apply to Virtex or the XC3000 architecture.
If you do not specify the -l option, MAP can perform logic replication, a logic optimization in which the program takes a single driver driving multiple loads and maps it as multiple components, each driving a single load (see the following figure). Logic replication results in a mapping that often makes it easier to meet your timing requirements, since some delays can be eliminated on critical nets.
This option does not apply to the XC3000 and XC5200 architectures.
Figure 6.2 Logic Replication (-l Option) |  |
-o outfile[.ncd]
Specifies the name of the output NCD file for the design. The .ncd extension is optional. The output file name and its location are determined in this way.
If the output file already exists, it is overwritten with the new NCD file. You do not receive a warning when the file is overwritten.
-oe {normal | high}
The -oe option specifies the effort MAP uses when performing logic optimization. In the high setting, MAP exerts a greater effort to optimize combinatorial logic, but the mapping takes longer to complete. The high setting must be used if the input to the MAP is not optimized, for example, a design created in XABEL.
For the -oe option to apply, the -os (logic optimization style) option must be enabled; that is, -os must have a setting other than none.
If logic optimization is specified by the -os option, the default setting for the -oe option is normal.
See the following “-os (Logic Optimization Style)” section for guidelines on when to use logic optimization.
This option does not apply to Virtex.
-os {area | speed | balanced}
Logic optimization in the context of MAP refers to FPGA-specific 4-input lookup optimization by the OPTIX optimizer.
The -os option specifies what type of logic optimization MAP performs.
The default setting for the -os option disables logic optimization - no optimization is performed. You may want to avoid performing logic optimization in the following cases.
After combinatorial logic optimization has been performed, you lose the correlation between signal names in the NCD file and signal names in the original design. User signal names are not preserved within optimized combinatorial networks. This affects back-annotation and also results in a reduction in the amount of guided mapping and guided placement and routing that can be performed. However, signals connected to pads or to the outputs of tbufs, flip-flops, latches, and RAMS are preserved for back-annotation.
This option does not apply to Virtex.
-p part
Specifies the Xilinx part number for the device. The syntax for the -p option is described in the “Part Numbers in Commands” section of the “Introduction” chapter. Examples of part entries are XC4003E-PC84, and XC4028EX-HQ240-3.
If you do not specify a part number using the -p option, MAP selects the part specified in the input NGD file. If the information in the input NGD file does not specify a complete device and package, you must enter a device and package specification using the -p option. MAP supplies a default speed value, if necessary.
The architecture you specify with the -p option must match the architecture specified within the input NGD file.
You may have chosen this architecture when you ran NGDBuild or during an earlier step in the design entry process (for example, you may have specified the architecture as an attribute within a schematic, or specified it as an option to a netlist reader). If the architecture does not match, you have to run NGDBuild again and specify the desired architecture.
You can only enter a part number or device name from a device library you have installed on your system. For example, if you have not installed the 4006E device library, you cannot create a design using the 4006E-PC84 part.
-pr {i | o | b}
When MAP runs without the -pr option, MAP can only place flip-flops or latches within an I/O cell if your design entry method specifies that these components are to be placed within I/O cells. For example, if you create a schematic using IFDX (Input D Flip-Flop) or OFDX (Output D Flip-Flop) design elements, the physical components corresponding to these design elements must be placed in I/O cells. The -pr option specifies that flip-flops or latches may be packed into input registers (i selection), output registers (o selection), or both (b selection) even if the components have not been specified in this way. This option does not apply to the XC5000 architecture.
The -r option disables register ordering. If you specify this option, register bit names are ignored when registers are mapped, and the bits are not mapped in any special order. If you do not specify this option, MAP looks at the register bit names for similarities and tries to map register bits in an ordered manner (called “register ordering”). For a description of register ordering, see the “Register Ordering” section.
This option does not apply to Virtex or the XC5200 architecture.
If -u is specified, MAP maps unused components and nets in the input design and includes them as part of the output design. If -u is not specified, MAP eliminates unused components and nets from the design before mapping.
The -u option is helpful if you want to run a preliminary mapping on an unfinished design, possibly to see how many components the mapped design uses. By specifying -u, you are assured that all of the design's logic (even logic that is part of incomplete nets) is mapped.
