HDL Design Entry

This section describes the basic process of entering HDL designs. In addition to this chapter, the HDL design entry techniques in this section apply to the “Mixed Designs with VHDL on Top” chapter and “Mixed Designs with Schematic on Top” chapter.

Overview of HDL Design Entry

Use a text editor, pld_da, System Architect, Renior, or other HDL entry tool that is compatible with your synthesizer to create synthesizable VHDL or Verilog. Pld_da can be better than a plain text editor for editing your source. With pld_da you can submit the source to be compiled as you edit it (see the mentor Design Architect User's Guide for details). When performing HDL design entry, observe the following requirements:

The synthesizers must create EDIF or XNF that is compatible with Xilinx implementation tools.
Xilinx-specific properties and timing constraints cannot be added in a VHDL or Verilog description, but synthesizers do have the capability of adding them to the output EDIF or XNF via constraint setting options. These constraint settings must be consistent with the current Xilinx implementation tools requirements. Otherwise, implementation can be controlled within the implementation tools themselves or with a UCF (user constraint file) file.

As an optional part of the Xilinx HDL design entry flow, you can instantiate LogiBLOX modules in your VHDL or Verilog designs and simulate the HDL output from LogiBLOX in your HDL simulators. When using LogiBLOX modules in HDL design entry, observe the following requirements:

Create the NGO from LogiBLOX for later use in the implementation tool. LogiBLOX NGO files must be placed in your top level directory or you must modify the macro search path in the Xilinx Design Manager to include the location of NGO files. Pld_edif2sim or pld_xnf2sim do not have the macro search path functionality. You must have the LogiBLOX NGO files in the same directory as your top-level EDIF or XNF.
Your synthesizer must not read-in or synthesize the HDL description of the LogiBLOX modules. These descriptions are for simulation only. The modules must be treated as black boxes by the synthesizer.

HDL Design Entry Stages

HDL design entry has two stages as shown in “HDL (Verilog/VHDL) Design Entry and Synthesis” figure. The first stage is the Register Transfer Level (RTL). At this level, the design behavior is described in a high-level, non-technology-specific manner. Instantiation of specific components is the exception. An example would be RAMs or LogiBLOX modules. This design entry step is generally followed by a functional simulation.

Figure 4.2 HDL (Verilog/VHDL) Design Entry and Synthesis

During design entry, you may check out the syntax correctness of your code by compiling it for your synthesizer and/or ModelSim without doing either the synthesis or simulation.

You may find the syntax checkers are different. The synthesizer may check for certain constructs it cannot synthesize like textio in VHDL, but these constructs may be perfectly good for simulating functionality as you develop the circuit. Many synthesizers have pragma or meta comments that allow you to keep this code in your HDL description but tell the synthesizer to ignore it.

Also there may be significant differences in how thoroughly the compilers check the code against the VHDL and Verilog IEEE-standards or even how they interpret certain sections.

It is good practice to do occasional compiles for both the synthesis tool and ModelSim as you develop large sections of your HDL code.

Once the RTL simulation is correct, the second stage of design entry is to submit the RTL code to a synthesizer where the general functionality is synthesized and mapped to gates in a specific technology. At this point you have the option of performing a second functional simulation of the post-synthesis gate level description. However, this step is not necessary since no additional timing information is available before place and route.

Once you are satisfied with the behavior of the circuit, you can send the gate level output of the synthesizer to the implementation tool as either an XNF or EDIF file.

Stage 1: RTL Behavioral Code Development

The first stage of HDL design entry is developing an RTL behavioral description. Code created at the RTL entry is generally non-technology specific. Two exceptions worth noting are:

Coding style favoring one technology strengths over another.
Instantiating technology specific components.

Your coding style should take into account your targeted technology's architecture specifics to achieve the best performance or smallest size for your design.

For example, a style that infers latches unintentionally or even on purpose would be just fine for a XC5200 or XC4000EX part but would be a trouble spot with an XC3000. It is a problem for the XC3000 because it would be implemented as cross-coupled logic creating a host of timing analysis issues. In a XC4000 it would take up valuable resources since each latch could be implemented as a SRAM cell, taking up a whole function generator. Synthesizers may vary in how they implement latches in technologies that do not have explicit latches. Some may use cross-coupled logic as in the XC4000E. Others may use a RAM cell.

Another RTL coding style problem might be describing the functionality in a manner that infers lots of MUXES. A better choice in some technologies would be to infer internal tri-states and use the high-performance tri-state lines.

Some synthesizers may not have a means of inferring or targeting high performance technology components like wide-edge decoders, I/O muxes, or latches. In that case you may need to instantiate these components to get your best chip performance.

In summary, observe the following RTL coding guidelines:

Avoid using latches in technologies without specific architecture components to support them like the XC5200 and XC4000EX have.
Infer tri-state buses instead of muxes for technologies with good internal tri-state structures.
Instantiate high performance architecture features if your synthesizer cannot infer them.

Stage 2: Synthesis

The second stage of HDL design entry is synthesis of the RTL behavioral description down to technology specific gates. Specific synthesis design entry steps for Xilinx parts are highly dependent on which synthesizer you use. Generally you can break synthesis design entry into the following steps:

Tailor your RTL code for both the synthesizer and the Xilinx technology's capabilities. For example, if your synthesizer can insert the STARTUP component, you need not instantiate it.

When you simulate in ModelSim with an instantiated startup block, you get a warning because the startup module does not have a simulation module. You may ignore this warning since the startup block is only used to direct the implementation tool and does not change the logical functionality of the circuit. The waring looks something like this:

# ** Warning: Component startupblk is not bound.
Guide the synthesis process with timing and/or size requirements.
Guide the output process to select XNF or EDIF outputs to insert I/O buffers, global buffers, STARTUP blocks, and to output timing constraints either within the netlist itself or to a separate file readable by Xilinx implementation tools. Make sure the timing constraint style is the correct one for the current version of Xilinx implementation tools.

You should read your synthesizer manual for specific details, especially the sections about targeting Xilinx devices. Be aware that any one of these three steps can greatly affect the quality of synthesis and/or implementation results.

LogiBLOX Design Entry

Some synthesizers are not capable of using Xilinx carry chains properly and tend to infer inefficient structures for adders, counters, etc. Other synthesizers are able to infer incrementors or decrementors, but do not use efficient logic for the control logic of the loadable counter.

To guarantee optimal synthesis for certain modules in a Xilinx technology, you may use the LogiBLOX module generator and instantiate the resulting module in your HDL code.

You may invoke the stand-alone Graphic User Interface of LogiBLOX in the tool window of pld_dmgr by clicking on the pld_logiblox icon. This is not the same Graphic User Interface you get in the Design Architect Schematic Palette. The stand-alone version is for VHDL or Verilog models only. Another way to invoke the stand-alone GUI is from the Design Architect pop-up menu in the Session Window.

LogiBLOX requires two outputs for proper implementation in a HDL design.

The first output is the HDL behavior description for simulating either VHDL or Verilog. These HDL descriptions only support HDL functional simulations. You should not send them to the synthesizer for synthesis. The entities can be used for component instantiation purposes, but the architectures should be treated as black-boxes within the synthesizer. The following is an example of a LogiBLOX component declaration and instantiation in VHDL:

---------------------------------------------------- -- Component Declaration ---------------------------------------------------- component RAM16X1 PORT( A: IN std_logic_vector(3 DOWNTO 0); DI: IN std_logic_vector(15 DOWNTO 0); WR_EN: IN std_logic; DO: OUT std_logic_vector(15 DOWNTO 0)); end component; ---------------------------------------------------- -- Component Instantiation ---------------------------------------------------- instance_name : RAM16X1 port map (A => , DI => , WR_EN => , DO => );

The second output is the NGO file. The implementation tools use this file to pull the LogiBLOX module into the top-level design. Since these NGO files are technology specific, you should generate a new NGO file each time you select a new Xilinx architecture. The HDL behavioral descriptions do not change.

Unified Library Instantiated Components

If you prefer, you may instantiate Unified Library components into the RTL design. The components you use should be primitives supported in the Xilinx family being targeted and also present in the synthesis tool's target library. For more information on Unified Library components, see the Development System User Guide.