Running the Standard Modular Design Flow

Use the standard Modular Design flow for most designs. This flow requires that all modules are implemented and published to the PIMs directory before they are assembled together. After you are comfortable running this flow, you can also run it sequentially, using the Sequential Modular Design Flow. For more information, see "Running the Sequential Modular Design Flows".

Entering the Design

Create your top-level and module designs with a text-based tool using Verilog or VHDL. Use the following guidelines when creating your code.

General Coding Guidelines

In creating HDL code for both the top-level design and individual modules, it is extremely important to follow good coding practices. Following are general guidelines:

Ensure that your design is fully synchronous

Use realistic timing requirements (period constraints for entire design)

Top-Level Design Coding Guidelines

The top-level design must include all global logic, including I/Os, all design modules instantiated as “black boxes,” and the signals that connect modules to each other and to I/O ports. Each module must be instantiated as a “black box,” with only ports and port directions. Following are “good” coding practices specific to the top-level design:

Note: Top-level logic should be kept to a minimum.

Declare all design level ports at the top-level

Use meaningful signal names to connect to module ports or between modules

Note: Using the same name for the signal and its associated port aids in simulation, because top-level signal names are used during back-annotated simulation.

Include a minimum number of modules

In addition to these practices, you must do the following when creating the top-level design:

Instantiate each module as a “black box”

Include “black box” definitions of the lower-level modules in the top-level file to determine port direction and bus width

VHDL Notes

Synthesis requires component declarations for all instantiated components in the HDL code. The component can be declared in the code or in a library package included in the HDL.

Verilog Notes

Synthesis requires declarations for user modules only, not library primitives. If user modules are defined and described in the same project, module declarations are unnecessary. For example, module declarations are unnecessary if your synthesis tool produces multiple EDIF netlists from a single project. However, if a user module is described in a different project, or if it is a CORE Generator module, then a module declaration is required. All port directions must be declared with explicit statements in the module definition.

Infer the following resources:

All I/O registers

3-state buffers that drive the same net or bus

Note: If bidirectional signals are outputs of a lower-level module, declare them in the HDL code as inout signal types in both the top-level component declaration and the module-level port map.

Note: You cannot include a module inside of another module though you can use multiple netlists to generate a module. In addition, multiple instantiations of the same module are not directly supported. Each module instantiation must have a separate module definition, even if module instantiations will use the same port definitions and functions.

Module Coding Guidelines

Unlike top-level design entry, design entry for individual modules can occur after the Initial Budgeting phase and even at the same time as another module’s Active Module Implementation phase.

In creating HDL code for the individual modules, adhere to the following recommendations to make your design implementation go smoothly:

Write individual modules as independent designs

Self-contained modules with minimal dependence on outside resources are implemented optimally. Following are examples of how to achieve independence:

Use the minimum number of ports on each module

Do not design modules to be dependent on chip resources with specific locations

For example, a module should not require that a BRAM be located in the column adjacent to the module.

Include minimal global logic

Examples of global logic are I/O pins leading onto or off of the chip, DLLs, or global clock resources.

Define ports exactly as they appear in the top-level design

Ports are connections in and out of a module that are connected to a wire or signals in the top-level design.

Code any 3-state logic that involves nets found outside of the module in the top-level HDL.

Synthesizing Designs

Synthesize HDL files as described in the documentation for your synthesis tool. You must create a separate netlist file for each of the modules and for the top-level design. Synthesis of a Modular Design requires the following special considerations:

Each module in the design must have a unique netlist.

Most synthesis tools generate only one netlist for each project. To meet the “separate netlist” requirement of Modular Design, you must synthesize lower-level modules separately from the top-level design, and sometimes create a separate project for each module as well as for the top-level design. This will prohibit the synthesis tool from ‘optimizing’ logic across module boundaries.

Note: For more information on specific Synthesis Tools, see the "Vendor Specific Notes for Synthesis" section of this chapter.

In each module design, disable settings that insert I/O pads.

In the top-level design, enable settings that insert I/O pads.

In the top-level design, the names of lower-level modules must be identical to their file names.

If these names do not match, NGDBuild cannot match the module names specified in the top-level netlist to the module netlists.

In the top-level design, synthesize all lower-level modules as black boxes.

Black box instantiation may require the use of a synthesis tool directive. If lower-level modules are not synthesized as black boxes, NGDBuild outputs an error during the Initial Budgeting phase.

Running Initial Budgeting

During the Initial Budgeting phase, the team leader assigns top-level constraints to the design. Both the top-level timing constraints and the area constraints for each module must be defined. Following are steps for running the Initial Budgeting phase:

Change directories to your top-level design directory inside your “implementation” directory.

Translate your top-level netlist file into a Xilinx file format using the following command. You can use either an EDIF netlist or an NGC netlist from XST. If you use an NGC file as your top-level design, be sure to specify the .ngc extension as part of your design name.

ngdbuild -modular initial design_name

Module files must not be included in the top-level directory. At this point, the modules instantiated in the top-level design must be represented as unexpanded blocks in the resulting NGD file. The design_name.bld should be consulted to make sure that only the modules expected are listed as being unexpanded.

Apply top-level constraints, such as clock periods, using the Constraints Editor. Use the following command to invoke the Constraints Editor:

constraints_editor design_name.ngd

Note: If a clock net in the top-level design does not have a clock load, the clock does not automatically appear in the Constraints Editor. You can manually add clocks using the Specify button found under the Global tab.

Refer to the Constraints Editor online help for details about commands and settings. Also refer to the Constraints Guide for information on constraints.

Select File

Save to save your UCF file and then close the Constraints Editor.

Use the following command to invoke the Floorplanner to create module sizes, locations and to position all module ports:

floorplanner design_name.ngd

Select File

Read Constraints to read in the UCF file you modified in the Constraints Editor.

Apply location constraints, including constraints for the following:

Top-level I/O ports

In the Design Hierarchy window, expand the Primitives icon. Drag the port to the Floorplan window.

Top-level logic, such as global buffers, 3-state buffers, flip-flops, and look-up tables

In the Design Hierarchy window, expand the Primitives icon. Drag the primitive to the Floorplan window.

Note: BUFTs require some special considerations. See "Initial Budgeting Phase" for details.

“Pseudo logic” that represents module ports

Before assigning area constraints for each module, make sure that automatic floorplanning is enabled. Select Floorplan Distribute Options. In the Distribution Options dialog box, make sure Autofloorplan as needed is selected. When you assign an area constraint for a module, the Floorplanner positions the pseudo logic automatically.

To reposition a port manually, select the port in the Floorplan window and drag it to its desired location. For best results, place the ports just outside the defined area for the module.

Manually positioned ports are marked as unavailable for automatic floorplanning. To revert back to automatic floorplanning, delete the manually placed ports from the floorplanned design. The ports are automatically positioned the next time you resize or move an assigned area, assuming the Autofloorplan as needed option is selected in the Distribution Options dialog box. If this option is not selected, you can select the All Ports option in the Distribution Options dialog box and click the Floorplan button to place the ports automatically.

Refer to the Floorplanner online help for details about commands and settings.

Select File

Write Constraints to write out the UCF file.

Close the Floorplanner and save the FNF file.

Implementing an Active Module

During this phase, the team members implement the top-level design with only the “active” module expanded. “Active” refers to the module on which you are working. The full suite of Xilinx implementation tools is available for this phase. You can use any MAP or PAR command line options as well as the Constraints Editor and Floorplanner.

Note: PAR’s re-entrant routing feature is not supported. If you use FPGA Editor, be sure to leave area constraints and placement information from previous steps intact.

You must perform the following steps for each module. Team members can implement their modules in parallel.

Note: You should not use NCD files from previous software releases with Modular Design in this release. You must generate new NCD files with the current release of the software.

Copy the following files to the local module directory in which you will implement the module:

Note: Xilinx recommends keeping a separate directory for the files you synthesize and the files you implement.

Synthesized module netlist file (for example, module_name.edf or module_name.ngc)

UCF the team leader created in the Initial Budgeting phase (from the top-level directory in the “implementation” directory). Rename this file from design_name.ucf to module _name.ucf.

Note: Copying the UCF ensures that each module is implemented with a consistent set of timing and placement constraints. It also allows you to add module-specific constraints to the local copy of the UCF as needed.

Change directories to the local module directory.

Run NGDBuild in active module mode as follows:

ngdbuild -uc module_name.ucf -modular module
-active module_name top_level_design_directory_path/design_name.[ngo|ngc]

The output NGD file is named after the top-level design and contains implementation information for both the top-level design and the individual module.

If necessary, create module-level timing constraints using the Constraints Editor as follows:

Use the following command to invoke the Constraints Editor:

constraints_editor design_name.ngd

In the New dialog box, select the module_name.ucf file and click OK.

Modify the constraints. Do not modify the timing or placement constraints entered in the original top-level UCF.

Note: If you define an OFFSET constraint relative to a module port, a TPSYNC constraint is automatically created for that port net. The path from the synchronous element within the module to the module port is analyzed to create offset timing. Offset timing does not include the clock delay to the synchronous element within the module.

Select File

Save to save your UCF file and then close the Constraints Editor.

Refer to the Constraints Editor online help for details about commands and settings. Also refer to the Constraints Guide for information on constraints.

Annotate the constraints from the local UCF file to the module using the following command. The –uc option ensures that the constraints from the local UCF file are annotated.

ngdbuild -uc module_name.ucf -modular module
-active module_name top_level_directory_path/design_name.ngo

Map the module using the following command. In this step, you are mapping the logic of the design with only the active module expanded.

map design_name.ngd

No modular design specific command line options are required, because all of the modular design information is encoded in the input NGD file.

Place and route the module using the following command. In this step, you are placing and routing the logic of the design with only the active module expanded.

par -w design_name.ncd design_name_routed.ncd

The “_routed” syntax ensures that you do not overwrite your mapped design. The –w option ensures that any previous versions of design_name_routed.ncd are overwritten. However, you can use any syntax you prefer. No modular design specific command line options are required, because all the modular design information is encoded in the input NCD file.

If the area specified for the module cannot contain the physical logic for the module because it is sized incorrectly, you must regenerate the UCF file generated during the Initial Budgeting phase, and you must run the entire Initial Budgeting phase again. This would then imply that new UCF files will need to be copied to each module and that each module needs to be reimplemented.

Run TRACE on the implemented design to check the timing report (TWR or TWX file) for timing issues. Verify that your top-level timing constraints are met.

trce design_name_routed.ncd

Note: By default, a summary report is generated. You can also choose to generate an error or verbose report. See "TRACE" chapter for details.

If necessary, use the Floorplanner to reposition logic as follows:

Note: The Floorplanner should only be used if the module implementation is unsatisfactory; for example, if it does not meet timing constraints.

Use the following command to invoke the Floorplanner:

floorplanner design_name.ncd

Reposition the logic. Use the MFP flow so that only the mapper needs to be rerun.

Map, place, and route your design again, as described in steps 6 and 7.

Note: When mapping your design, you must use the MAP –fp option to ensure that your updated MFP file is used.

Publish the implemented module file to the centrally located PIMs directory set up by the team leader:

pimcreate pim_directory_path -ncd design_name_routed.ncd

This command creates the appropriate module directory inside the PIMs directory that you specify. It then copies the local, implemented module files, including the NGO, NGM, and NCD files to the module directory inside the PIMs directory and renames the NCD and NGM files to module_name.ncd and module_name.ngm. The –ncd option specifies the fully routed NCD file that should be published.

Note: You can simulate the module after running MAP or PAR as described in "Simulating an Active Module".

Assembling the Modules

This is the final phase of Modular Design, in which the team leader assembles the previously implemented modules into one design. Physically implemented modules located in the PIMs directory are used as well as the top-level design file in the top-level directory to accomplish this as described in the following steps:

Change directories to your top-level design directory in your “implementation” directory.

To incorporate all of the logic for each module into the top-level design, run NGDBuild as follows:

ngdbuild -modular assemble -pimpath pim_directory_path design_name.ngo

Ngdbuild generates an NGD file from the top-level UCF file, the top-level design’s NGO file, and each PIM’s NGO file.

Note: Because you are using all of the PIMs published to the PIMs directory, you do not need to specify the –use_pim option. If you want to use only some of the PIMs in the PIMs directory, do not run the standard Modular Design flow. Instead, see "Running the Sequential Modular Design Flows".

Map the logic of the full design as follows:

map design_name.ngd

No modular design specific command line options are required, because all of the modular design information is encoded in the input NGD file. MAP uses the NCD and NGM files from each of the module directories inside the PIMs directory to accurately recreate the module logic.

Place and route the logic of the full design as follows:

par -w design_name.ncd design_name_routed.ncd

No modular design specific command line options are required, because all the modular design information is encoded in the input NCD file. PAR uses the NCD file from each of the module directories inside the PIMs directory to accurately reimplement the module logic.

Run TRACE on the implemented design to check the timing report (TWR or TWX file) for timing issues. Verify that your top-level timing constraints are met.

trce design_name_routed.ncd

Note: By default, a summary report is generated. You can also choose to generate an error or verbose report. See "TRACE" chapter for details.

If desired, simulate the design by creating a netlist that can be simulated using NetGen or a third-party simulator. For more information, see "Simulating an Active Module".

Simulating an Active Module

In addition to simulating the final design, you can simulate the active module (design_name.ncd) after running MAP or PAR. Following are the two simulation methods available during the Active Module Implementation phase. Each has its advantages and disadvantages.

Simulation with the top-level design as context

With this method, you back-annotate and completely simulate the top-level design.

Advantage: The logic in the top-level design is included in the simulation.

Disadvantage: Inactive modules are undefined and signals connected to module ports are left dangling. As a result, you must probe and stimulate these signals to obtain meaningful simulation results.

Note: If you use VHDL, internal signals cannot be driven from the testbench, but some simulation tools allow access to these signals through a GUI or command line tool.

Independent module simulation

With this method, you simulate the module independent of the design context. The simulation netlist contains only module-level logic and ports and can be instantiated in a testbench that exercises just the module.

Advantage: You can see exactly how the module behaves, independent of the top-level design. You do not need to provide stimuli for dangling signals as you do when simulating with the top-level design as context. In addition, you can use module-level testbench files with the resulting timing simulation netlist.

Disadvantage: Because port loads and drivers are unknown, you must ignore delay and timing values of module ports until you can perform a complete design simulation. In addition, all ports and internal signal names appear in the back-annotated netlist in terms of the top-level netlist. The ports are named after the top-level signals to which they connect, and the internal signals are preceded with the instance name.

Running Simulation with Top-Level Design as Context

This section describes running simulation using the NetGen program. For additional information on using NetGen, see "NetGen" chapter.

To run this type of simulation, do the following:

Run NetGen as follows:

netgen -sim -ofmt [verilog or vhdl] design_name.ncd

Note: Using an NGM file is optional but recommended. It provides valuable information, such as a record of the design hierarchy including internal signal and instance names, that may not be preserved in the NCD file.

Use a simulator to simulate the netlist.

Running Independent Module Simulation

To run this type of simulation, do the following:

Run NetGen as follows:

netgen -sim -ofmt [verilog or vhdl]-module design_name.ncd

Use a simulator to simulate the netlist.