Nimbus ASM Models & Synopsys Synthesis

Using the Synopsys® Logic Synthesis Tools with Nimbus®

James P. Davis, Ph.D.

Draft: 11 February 2004

Nimbus is a tool set that allows the capture of digital systems models as a collection of concurrent Algorithmic State Machine (ASM) models. Nimbus provides a design editor, compiler, cycle-based simulator, and model translator to both synthesizable VHDL and Verilog HDL. The technology is industry-proven, having been embodied in tools from another vendor for over a decade, and having been used by such companies as 3-Com, Alcatel, Sony, Hitachi and Ricoh. Our use of this technology is as a design capture and architecture exploration medium, as well as a means to clearly communicate design intent. As such, it is used as the method of teaching digital systems design practice in CSCE 491 and CSCE 611 courses here at USC.

The purpose of this tutorial is to illustrate the use of Nimbus® with the Synopsys® Design Analyzer® and FPGA Compiler II® tool sets. The Design Analyzer is an older tool set, which primarily is used in logic synthesis and analysis of circuit results for ASIC applications. The FPGA Compiler (FC2) is used for the specific needs of synthesizing circuits on FPGA devices. It is the purpose of this tutorial to give you, the student, a representative understanding of how to use Nimbus with Synopsys tools for the purpose of completing design and architecture analysis assignments and projects.

1. Preparing your design for HDL Generation in Nimbus

In my lecture notes, you should now know how to use Nimbus to create a design, compile and check the design, and run the cycle-based ASM model simulator. Now we pick up the story with generating the VHDL model code from Nimbus, so that we can input it into Synopsys logic synthesis tools.

Figure 1. The Nimbus display of 3 threads of the UART model.

We start with the ASM model created in the laboratory assignment--the UART model. This model represents one-half of the full-duplex serial communications system existing between a PC host and a remote peripheral controller. We use the UART model because it is so representative of serial communications systems, from RS-232 to Bluetooth and "WIFI" wireless communications protocols.

We will take this model and translate it into VHDL, which we select as our input medium for getting into the Synopsys tool chain.

Figure 2. Updating the UART model's signal data types in the Nimbus Bus Table.

Before we can get started, we'll simplify this model a bit. You will need to bring up Nimbus, load the UART model you have created in an earlier laboratory, and edit the Type field for each signal/bus defined in the design. Specifically, we need to change all the buses from MVL9 to Binary. You do this by double-clicking (left mouse) on the bus in the Tree View (left hand side of the Nimbus screen). This opens the Bus Modification dialog box. Change the check box from "MVL9" to "Binary", then click the "Modify" button at the bottom of the dialog box. Then click the "Next" box, which brings up the properties for the next bus in the Bus Table. Repeat this process for all buses; you know you're done when the "Next" button is grayed out, and the selection available is to "Close" the dialog box.

2. Generating HDL output from Nimbus®

Once we have checked our design and compiled it into an internal model within Nimbus, we may choose the simulate the design using the Nimbus cycle-based simulator. Assuming we have done this, and have effectively debugged and verified our cycle-level design behavior, we want to carry our design into silicon. We do this by translating the internal Nimbus model into a standard HDL (hardware description language) such as VHDL or Verilog HDL, and take that design representation and pass it into downstream tools that will generate actual circuits.

Figure 3. The Nimbus selection of Target Environment.

To generate a target HDL model description, we first select the target language and the tool environment that we will be using downstream in the design process. In our example, we will be using the FPGA Compiler II® from Synopsys®, a tool set that takes a a set of HDL source files, converts them into a Boolean representation of the circuit's functions, minimizes these functions (according to specialized directives that we can modify), then maps the minimized design onto a targeted VLSI device library (that we also specify).

Here, we specify the use of "Synopsys VHDL - Synthesis" by selecting the "Target HDL" option from the "Options" pulldown menu in Nimbus. We select the entry, as shown in Fig. 3, and click "OK".

Figure 4. The Nimbus selection of Target HDL Code Translation Style.

Sometimes, we want to modify the HDL coding style that is to be output and fed into downstream design tools, which we can do by selecting from a set of properties, as shown in Fig. 4. This dialog box is accessed by the "Translation Style" menu option in the "Options" menu. For now, we will leave the default options alone. We will generate: (1) a "flat" VHDL code style (where we have a single entity-architecture pair for the entire ASM model, and all concurrent threads are represented as a set of concurrent VHDL processes in the file); (2) an "enumerated" binary encoding of the state machine (meaning that the VHDL code will reflect a style of using the state registers where the number of state registers is 2**n, where n is the number of states defined in a given ASM thread); and (3) we'll leave the state register output lines internal to the design (meaning, we don't need to use the state machine "present state" lines to control other design modules defined outside of our ASM model).

Figure 5. The Nimbus naming of UART VHDL Output File.

Next, we need to specify the file name for the VHDL output file that will be generated by Nimbus for our ASM model. This is done (after compiling the ASM model with no errors) by selecting the "Tool" pulldown menu, and clicking the "Translate HDL" menu option. Once we select, this option, we get the dialog box shown in Fig 5. You specify the target file name (a default is provided, using the Design Information entered under the "Options" menu for your ASM design file). You can rename this file, or change the directory where the file will be written. For now, leave this to be the default file name and directory (which should be the one in which you started-up Nimbus).

Figure 6. Viewing the Generated VHDL Code in Text Window.

Nimbus will generate the target VHDL (or Verilog HDL) design representation. You can open and examine this VHDL code source file using your text editor or the "cat" and "more" Unix commands. You'll see a code listing like that one shown in Fig 6. for the UART example model. Now that we have the HDL code output generated from Nimbus, we can now take that design representation and read it into Synopsys.

3. Reading in Design Files into Synopsys®

The Synopsys FPGA Compiler II tool set provides capabilities to target a design to a particular VLSI device technology. It does this by compiling the HDL program source code into another representation (capturing the Boolean expressions for the individual gate-level operations of the circuit), minimizing this Boolean representation (similar to the manual techniques we use for small combinational and synchronous sequential logic circuits), and mapping this minimized design onto a set of library elements for the individual circuit components (AND, OR gates, etc.).

Figure 7. The FPGA Compiler selection of VHDL Files to Read.

To run the FPGA Compiler II in the USC environment, you must do the following: (1) run the C-shell script as: source /usr/local/etc/synopsys.csh, which sets up the appropriate Unix environment variables, and other settings, and (2) type the command line fc2& to execute the program from your Unix shell. Once it comes up, you get a "desktop" window, and a dialog box "wizard" that steps you through the circuit creation process.

The first task, as shown in Fig 7., is to read in the HDL code source files. There are two files: (1) the UART.vhdl file you created from Nimbus, and (2) a VHDL design library that maps the Nimbus macro-functions to VHDL primitives. This file is the Nimbus_bit.vhdl file, which you will pull down off the course web page. We must first read in the library file, then read in the design file. In this case, we have only these two files to read in; for a larger design, we could have many files to read into the tools.

As each file is read in and compiled by Synopsys, status messages are displayed. If we had errors in the files, we would get information about line numbers and the offending error description (much like what you get back from a C compiler). In our case, the design and library should compile correctly upon being read in. The dialog box is shown above, which is accessed in Synopsys through the "wizard" or, if you are using the tool without the "wizard", access is recommended by starting the "wizard" from the "File" menu.

4. Selecting Target Device Library in Synopsys®

Once the design modules are read and compiled in FPGA Compiler, we need to select a target device library that we will use for implementing our design. We will specify the Xilinx Virtex-II series FPGA part. You access this by using the pulldown menus in the "wizard", as shown in Fig. 8, below. Note the options: Vendor = "Xilinx", Family = "VIRTEX2", Device = "2V6000BF957" and Speed Grade = "-4". You will need to make these option selections.

Figure 8. The FPGA Compiler selection of Target Device Library (Xilinx Virtex-II®).

Once you have selected these part options, click the "Run" button at the bottom of the dialog box. The logic synthesis process will commence. It takes some time to complete. This is a small design, so it should only take a few minutes. Larger designs, or using different settings, will take longer to generate a circuit.

5. Setting Up Output Options in Synopsys®

Once the circuit synthesis process is complete, we need to output our design results. We need to specify the directory location, and some other options, as shown in Fig 9, below. For now, we won't use any of these, except to specify where we want to write the generated design information.

Figure 9. The FPGA Compiler selection of Design Output Options.

Now, we have completed the process of creating a circuit-level design representation from our ASM models created in Nimbus, synthesized using Synopsys. Next, we can interact with our created design modules, by viewing the schematic representations, by generating reports, and by exporting our design "netlist" to an EDIF file (for later place and route using the Xilinx Layout tools).

6. Interacting with Design Modules in Synopsys®

The desktop view of the design modules shows the design source (left side) and the resultant chip models (right side) created as a result of synthesis.

Figure 10. The FPGA Compiler Desktop and Design Treeview.

You can select either the individual module or the design as a whole in the right pane of the window with your left mouse. Clicking with the right mouse on the selected module or design brings up appropriate menus for each. We can view the schematics and generate reports from these menu options.

7. Viewing Schematics in Synopsys®

In the FPGA Compiler treeview window for the Chips, right mouse select the design, and then select the option to "View Schematic". This will bring up a number of windows, some containing detailed information about the properties of the synthesized chip circuits. You may close these, as we are only interested in the graphical schematic view at present. Your schematic will appear something like this one.

Figure 11. The UART Schematic Display in FPGA Compiler.

One thing to NOTE: if you are doing a design using Nimbus, and you get top a schematic that has nothing but the input ports assigned, this likely means that you have not specified any output buses in your Nimbus design file. Synopsys will optimize out all of the design logic, because it rightfully concludes that this is extraneous, since it doesn't result in any circuit output. So, make the change to your .nim file in Nimbus by modifying one or more of your signals in the Bus Table to be of mode "Internal Output" or "Output". The appropriate mode selection depends on whether the affected bus is used elsewhere in the design or not. If it is, then select the mode to be "Internal Output"; otherwise, select "Output".

Figure 12. Zoom-in of The UART Schematic Display in FPGA Compiler.

As you are looking at your design in the Schematic Viewer, you can use the right mouse to zoom in or out of the design schematic. By clicking the right mouse button, you can zoom in and examine the structure and components of specific areas of the circuit. In today's design culture, most designers don't spend much time looking at schematics. However, I believe that there is much that can be gained about the understanding of a circuit's behavior by exploring and examining the kind of gate-level logic structures that are synthesized. This is because most "old-timer" designers started out with gate-level schematic capture as the means to specify the logic of a digital design.

Today's emphasis is on using programming languages (such as VHDL and Verilog, and even C) as the means for specifying design intent. The problem is that someone still needs to understand the circuit structure and related it to behavior--particularly now that Deep Submicron (DSM) CMOS silicon technologies and design techniques require that understanding.

By looking at how the synthesis tool optimizes your logic and maps your design to the selected target ASIC or FPGA device technology, you can develop a keen sense of anticipating the behavior of your circuit, and in gaining insight into appropriate strategies for trading off design constraints (area, delay, clocking frequency, power, energy, etc.).

Figure 13. Push-into Register Block of The UART in FPGA Compiler.

As we push deeper into the blocks mapped to the target Xilinx Virtex-II® library, we can see that the individual registers specified in the Nimbus design description are mapped to resource structures that exist on the Xilinx Virtex® device. Note that the output of the circuit synthesis pass is a best representation of the circuit topology without regard to where specific components of the circuit will be placed with respect to specific device resources, nor how these resource units are routed together to form the circuit paths specified in your high-level ASM models (such as basic assignment statements associated with individual states in the ASM model). This strict association to the actual device resources will be made during the placement and routing activities performed during Layout. We'll pick up the story of circuit layout in another installment.

8. Generating Reports in Synopsys®

To generate a report from FPGA Compiler-II, you left-mouse click on the "chip" icon (right side of Treeview), then right-mouse click to pull up a menu. Select the menu option "Chip Report", which will bring up a dialog box. Specify a file name and directory into which the report will be written, as shown below.

Figure 14. Generating a Report from FPGA Compiler.

Once the report file has been written, you can view the report by either opening it in a text window, using the Unix "cat" or "more" commands in a command window, or printing it. The output report contains information about the mapping of your design to the selected FPGA device. In this case, we have mapped our UART design to the Xilinx Virtex-II device family, and specified one earlier. The performance characteristics are now printed in the report as a result of mapping and optimizing the design to this device type.

Figure 15. Viewing a Report from FPGA Compiler.

As shown in the figure above, there is information regarding the timing of the design as mapped to the device. We used the FPGA Compiler's default option to optimize for area, so we can look at the area utilization (i.e., what types of resources and how many) have been consumed by our design. The first concern is whether the design actually fits on the selected device, and whether there are enough remaining resources for use if other modules are to be mapped to this same device. From the report, we can see the degree of resource utilization.

Also of concern is the timing of our design. We had defined a default clock frequency of 100 MHz (default used for this particular Xilinx part). What we want to know is (1) can our design run reliably at this clock speed, and (2) how much slack, or tolerance, do we have in our design. (There are more issues concerning timing analysis, which are beyond the scope of our treatment at this point.)

We will restrict ourselves to looking at the global timing effects, namely, whether our design runs "comfortably" within the specified clock frequency, and where we might have timing problems because the delay in some part of the design is excessively long. Remember, back in our ASM model we created in Nimbus, we had specified individual data path operations using macro-function assignments, which can be a nested combination of several functions that are executed in series. We find out here whether these data path macro-function operations will complete with an acceptable delay value, so as to insure that our design operates robustly on this type of Xilinx device.

This is part of the analysis that we will be doing wit out designs, as part of iterating from the high-level design descriptions using ASM modeling and the post-synthesis analysis of the design once mapped to a given device library.

There will be more to come on this topic, once we consider the actual placement and routing of the circuit onto the device. Note that this output report from Synopsys' FPGA Compiler-II represents a "best estimate" of what we might expect. But we won't know the actual timing and area characteristics until we layout the design (i.e., place the design components and route them together using the FPGA's resources) on the chip.