Synopsys Library Compiler

[Ronald Frison]

Usels" commend to check if "library.lib" is in your synopsys directory. This file contains logical descriptions and timing information for a set of logic gates (cells).The first time you use Synopsys, you probably won't have a cell library yet, so you should use this library as-is. The library file contains definitions for an inverter, nand2, nand3, nand4, nor2, nor3, aoi12, aoi22, oai12, oai22, and d-flip-flop.When you create a cell library in Cadence later on, you will need to modify the Synopsys library file to match your cells.If your cells differ from those in the library file, you may need to change cell names, pin names, and /or logical descriptions in the library file to match; this shouldn't be much of a problem if you pay attention to the Synopsys library file when laying out your cells in Cadence.Timing information is a more advanced subject, so you shouldn't change the given values, although you may want to experiment with changing the reported delays to match those of your cells if time allows.

Synopsys takes a Verilog behavioral-level design and a predefined groupof logic gates and produces a gate-level Verilog netlist. Synopsysrequires a library file which describes the logic gates available for synthesis operations. Copy the library file to your Synopsys directory by typing:

This file contains logical descriptions and timing information for a setof logic gates (cells). The first time you use Synopsys, you probablywon't have a cell library yet, so you should use this library as-is. The library file contains definitions for an inverter, nand2, nand3, nand4,nor2, nor3, aoi12, aoi22, oai12, oai22, and d-flip-flop. When youcreate a cell library in Cadence later on, you will need to modify the Synopsyslibrary file to match your cells. If your cells differ from thosein the library file, you may need to change cell names, pin names, and /orlogical descriptions in the library file to match; this shouldn't be muchof a problem if you pay attention to the Synopsys library file when layingout your cells in Cadence. Timing information is a more advanced subject,so you shouldn't change the given values, although you may want to experimentwith changing the reported delays to match those of your cells if time allows.

You should now see a compiled version of library.lib in your Synopsys directory as library.db. Open the .synopsys_dc.setupfile with your favorite text editor, and make sure the target_libraryline looks as follows:

Save and close the file. Now copy your Verilog behavioral-leveldesign into your Synopsys directory. It may be of help to remove thetest module at this time: you can move it to a separate file to use later. You are ready to run Synopsys Design Vision.

Once the Synopsys Design Vision window appears, open your design by selecting File->Read from the menu bar. In the Read Filedialog box, select your Verilog file, select format as 'verilog' and click OK.

Close orminimize the report window that pops up. An icon for your design shouldnow appear in the main window. Select the design by clicking on it. Then push into it hierarchically by clicking on the downward arrow on theleft toolbar, or double-clicking on the design icon itself.

Now you are ready to map the design. SelectDesign->Compile Design from the menu bar and click OK in the window thatpops up. The report window will provide a transcript of the mappingsession as Synopsys converts your behavioral-level design into a gate-levelnetlist.

To obtain an estimate of the number of cells that are required to build the state machine, click on "Design->Report Cells". A window will pop-up describing the list of cells to be used in the state machine.

To create a Verilog gate-level netlist for your design, select "File->Save As". Specify the filename as your original verilog file withthe addition of "_map.v" (i.e.: original: fsm.v ... output: fsm_map.v) and select "Verilog" as the file format from the drop-down menu. ClickOK.

It is important to save your work, as Synopsys may not remind you when exiting. Select File->Save As from the menu bar. By clicking OK in the resulting Save As dialog box, Synopsys saves yourwork as a database format file named after your input Verilog file withthe ".db" extension.

The resulting Verilog file is a gate-level netlist of your design. It describes the circuit as a network of devices with names and pins asspecified by the Synopsys library. The netlist is not yet complete,however, as we need to add module descriptions for each of the devices aswell. If you used the Synopsys library file without making any changes,you should be able to use the following file without modification. Otherwise, you may need to apply changes as you did with the library file. The following file is a header that is to be used with the Verilog netlist and contains module descriptions for the logic gates that Synopsysconstructed the netlist with. Copy the file to your Synopsys directoryby typing:

Your gate-level Verilog netlist is now ready for verification. You should be able to simulate your mapped verilog code using the same testbench circuit used to simulate your behavioral code. You should be able to reattach your test module with minor modifications andverify the functionality of the netlist as compared to the behavioral-level design. Remember to remove the test module when importing your Verilog netlist into Cadence or Silicon Ensemble later on.

This section describes the procedure for compiling a complete CPLD design based on VHDL or HDL. If you are preparing a VHDL/HDL-based module for inclusion in a schematic-based design, refer to the section "Compiling Behavioral Modules for Schematics" later in this chapter.

The Synopsys compiler synthesizes your source design and creates an EDIF 2.0.0 netlist file composed of logic primitives that is used by the Xilinx CPLD fitter to implement your design in a CPLD. All compiler commands are executed from within the Synopsys dc_shell environment.

If your source file contains initial signal values (which are used only for functional simulation) they will cause warnings that can be safely ignored; these initial signal values are not used during synthesis. Actual register initial states are set using attributes, as described in Chapter 2.

When you compile your design, the Synopsys synthesizer uses the components in the Xilinx XC9000 technology library to create an actual logic implementation of your design. The library used during compilation is defined by the dc_shell target_library variable, typically specified in your .synopsys_dc.setup file.

The mapping effort parameter is optional. However, it is recommended that you set it to LOW to save compilation time. The synthesizer does not perform any speed or area optimization for CPLD designs; this optimization is performed after compilation by the CPLD fitter.

Before writing the netlist, you should flatten the hierarchy of your design. Any attribute or timing constraints attached to objects in any hierarchy levels below the top would be lost unless the design is flattened. Enter the following command to flatten your design:

If you specified any timing constraints for your design (in dc_shell), you must write them to a dc_shell script file so they can be read by the Xilinx software. Enter the write_script command and redirect its output to a file as follows:

This is the end of the required processing in dc_shell. Before exiting you may wish to save the design database in Synopsys db format by executing the write command. You can exit dc_shell by entering the following Synopsys command:

If you specified any timing constraints for your design and wrote a dc_shell script file as in Step 9, you must translate the script file into a Xilinx constraint file (.ncf) that can be read by the fitter. Enter the dc2ncf command at the Unix prompt as follows:

None of the Synopsys timing or area analysis reports are useful at this time because the CPLD technology libraries do not contain timing or area estimation data. The Xilinx fitter provides a Static Timing Report which shows the calculated worst case timing for each logic path in your design.

When you generate the component from a Windows 64 host machine, you can also build the component libraries and run the simulation on a different operating system. If your target and host are not the same, you must port and build the shared libraries or HDL simulator projects manually. You cannot port a DPI component generated on a Linux machine to any other operating system.

When your target machine uses the same operating system as your host, you can select an installed compiler or request that the tools find a compiler automatically. If you want to generate a simulator project, or if you have no other compilers installed, select an HDL simulator for the same operating system as the host. However, if your target operating system is different from the host, you must select a target simulator and operating system.

Open your model, and on the Apps tab, click HDL Verifier. Select DPI Component Generation on the left pane, and on the HDL Verifier tab, click C Code Settings. The Configuration Parameters dialog opens on the Code Generation pane. Then, under Build process, select a target Toolchain. This option specifies the target simulator and operating system where you run simulations. The supported cross-product toolchains are:

After generating the component, use the packNGo (MATLAB Coder) function to package the generated files and any required dependencies before copying them to the target machine.load('subsystem_build/buildInfo.mat')packNGo(buildInfo, 'minimalHeaders', false)Where subsystem is the name of the Simulink subsystem used for DPI generation. The result is a zip file named subsystem.zip.

Copy the generated subsystem.zip file from the host machine to the target machine. The .zip file is located in the same folder as your model. The ModelSim .do file or the Xcelium, VCS, or Vivado .sh file is included in the .zip file.

3a8082e126