Step-by-step Instructions from VHDL

  1. Enter your VHDL modules as .vhd files. At this point in your project you will learn a lot by looking at sample VHDL code in this tutorial (sample LFSR counter) or elsewhere.

  2. (Recommended) Perform preliminary simulations of your VHDL modules. At this stage you might also want to develop a way of testing your modules, whether simply by a ViewSim .cmd command file with test vectors, or by a separate VHDL "test bench" module.

  3. Prepare your directory for using Synopsys. You don't really have to do anything, but it is a good idea to create a directory called WORK for Synopsys to store compiled modules in, and create a .synopsys file. (Include the command define_design_lib WORK -path ./WORK )

  4. Run Synopsys design_analyzer. All menu commands actually generate commands that you can view by choosing Setup->Command Window. The commands of steps 5-10 can be put into a dc_shell script such as lfsr.dcsh for (1) process repeatability, (2) automated processing (type dc_shell -f design.dcsh), and (3) hardcopy record of variables and commands used to generate your design.

  5. We'll assume your project consists of only one VHDL file for now. Select File->Read, VHDL format, and enter the .vhd filename, or enter the command read -format vhdl design.vhd.

  6. Apply the port_is_pad attribute to all the ports of the top level VHDL module. This is done by choosing Attributes->Optimization Directives->Design, and applying the Port is Pad option. You can alternately enter the command set_port_is_pad "*".

  7. Choose Tools->FPGA Compiler->Insert Pads, or enter the command insert_pads. This causes Synopsys to add a Xilinx IOB for each port.

  8. Enter the command compile -ungroup_all -boundary_optimization. At this point Synopsys will synthesize the necessary logic for the Xilinx CLBs and IOBs. This combination of options is actually not available from Design Analyzer menus, and must be entered as a command.

  9. Choose File->Write, Format DB, Save Hierarchy (write -format db -hierarchy -output design.db).

  10. Choose File->Write, Format EDIF, Save Hierarchy (write -format edif -hierarchy -output design.sedif). This is the end of the section of commands that should be automated in a dc_shell script.

  11. Create a CST constraint file input to APR or PPR if you need to specify I/O pad placements as in lfsr.cst.

  12. Open the XDM environment and select the family and part (such as XC3000, 3042, -50).

  13. Run XMAKE from XDM. Choose design.sedif as the schematic input to the XMAKE process, and select Make Bitstream as the output goal. This causes the following chain of events assuming all goes well. You can examine the file design.mak for details on what tools are being run.

    WHAT XMAKE DOES FOR THE XC3000 FAMILY FROM SYNOPSYS (It is not crucial that you know these details, in fact they tend to change a lot with new Xilinx software releases.)

    1. SYN2XNF produces an XNF file from the Synopsys output in the SEDIF file.
    2. XNFMERGE flattens the hierarchy of XNF files into an XFF file.
    3. XNFPREP removes unused logic and performs a design rule check on the XFF file, producing an XTF file.
    4. XNFMAP translates the XTF file into a MAP file.
    5. MAP2LCA translates the MAP file into an LCA file.
    6. APR automatically places and routes the LCA file.
    7. MAKEBITS extracts the programming information from the routed LCA file and writes it to a BIT file.

    WHAT XMAKE DOES FOR THE XC4000 FAMILY FROM SYNOPSYS

    If you used XBLOX components in your schematic, XMAKE runs the appropiate XBLOX program to produce an XG file before the XNFPREP stage. Also, PPR is run to partition, place, and route the LCA file instead of APR.

  14. If the steps to this point have been successful, you can either simulate the design or download it to the FPGA and try it out.


Created by Scott E. Harrington, Duke Electrical Engineering