Modular Design Implementation

Modular Design implementation includes the three phases described in this section. After the final phase is complete, you can use the implemented design to generate a bitstream.

Initial Budgeting Phase

In this phase, the team leader positions the top-level logic for the design. Properly positioning the logic in this phase is critical. Repositioning top-level logic later in the design process requires that you rerun each phase of the Modular Design flow, which is time consuming. Following are the objectives of the Initial Budgeting phase:

Position global logic

Size and position each module on the target chip

Position the input and output ports for each module

Budget initial timing constraints

The first step in this phase is to run NGDBuild in initial budgeting mode. Ngdbuild generates an NGD file with all of the instantiated modules represented as unexpanded blocks. This NGD file cannot be mapped but can be used with the Constraints Editor, PACE, or Floorplanner. Using the Constraints Editor, you assign timing constraints to the top-level design. Using Floorplanner, you assign pin location constraints for the design.

You must position all top-level logic during this phase. This ensures that the remainder of the logic for the design is optimally positioned during the Active Module Implementation phase. Location constraints must be assigned for the following elements:

Top-level I/O ports

These are the top-level ports of the design that are mapped into IOB components. In a typical design, these IOB locations are already well defined because of board layout requirements. PACE can position the I/O ports for the design on the targeted device.

Top-level logic

This is logic positioned at the top-level of a design, such as global buffers, 3-state buffers, flip-flops, and look-up tables. There should only a small amount of top-level logic.

When positioning BUFTs, follow these rules:

If more than one BUFT is driving the same net, position the BUFTs in the same row

If BUFTs are driving different nets, position each in a different row

If there are multiple 3-state nets and each 3-state net is driven by multiple BUFTs, position one BUFT for each 3-state net

Note: All top-level TBUFs must be located with the LOC constraint to a TBUF site during the Initial Budgeting phase. This is necessary to avoid contention between the 3-state signals. For additional information on this topic, please refer to Answer Record #12437 at http://www.xilinx.com/support.

Each module

Estimate how many resources each module will take to generate a rectangular bounding region that will contain the module. Next, position each module bounding region accordingly. Xilinx recommends that you allow space between modules so you can position the module ports.

“Pseudo logic” that represents module ports

When two modules are connected at this stage in the design flow, they are not connected directly. Instead, each of the modules has a module port that is connected to pseudo logic. This pseudo logic is either a “pseudo load” or a “pseudo driver.” A pseudo load is a temporary load for the module output, because its actual load is located in an unexpanded module. A pseudo driver is a temporary driver for a module, because its actual driver is located in an unexpanded module.

The following figure shows the relationship between the modules and pseudo logic during the Initial Budgeting phase:

The following figure shows a detailed view of the pseudo logic shown in the preceding figure. In the figure, the output port for unexpanded Module A is connected to a pseudo load, and the input port for Module B is connected to a pseudo driver.

The term “pseudo logic” is used, because it is logic that is temporarily inserted to facilitate the relative placement of the connected logic within a module. In the final assembled design, the pseudo logic does not appear, instead the actual logic is directly connected.

Note: Pseudo logic is only created on a net that connects two modules. If a net connects a module to top-level logic, pseudo logic is unnecessary because the top-level logic constrains the module logic.

Active Module Implementation Phase

In this phase, team members implement the top-level design with one module expanded at a time. This must be done separately for each module and takes place in the individual module directories, rather than at the top-level directory. Active Module Implementation can be done in parallel, that is each team member can implement his or her module at the same time.

To accomplish this, you run NGDBuild in active module mode. NGDBuild reads the top-level design, the module netlist, and the top-level UCF file as input. Ngdbuild generates the top-level design as an NGD file (design_name.ngd) with just the specified active module expanded. At this point, you can use the Constraints Editor to apply any additional local timing constraints for the active module. You can then map, place, and route the NGD file.

After a module is fully placed and routed and meets the desired timing constraints, it is published back to the team leader for inclusion in the final design. A published module is called a physically implemented module (PIM).

The pimcreate utility automatically copies the module’s NGO, NCD, and NGM files to the appropriate directory in preparation for the Final Assembly phase. It also renames the files design_name.ncd and design_name.ngm to module_name.ncd and module_name.ngm as needed for later phases of Modular Design.

The following figure shows the flow through the Active Module Implementation phase:

Final Assembly Phase

In this phase, the team leader assembles the modules into one design by running NGDBuild in final assembly mode. Ngdbuild reads in the top-level NGO file, the top-level UCF file, and all of the PIMs to create a fully expanded design file that you can map, place, and route. During this phase, the place and route tools copy the placement and routing information from each PIM. This preserves the exact timing performance from the Active Module Implementation phase for each module in the design.

Automatic trimming of unconnected output ports occurs during the Final Assembly phase to remove any loadless signals in the design. Trimming cleans up the design, which may result in modest performance and efficiency improvements.