toolbox

Test-Driving the Newest Version of Modelsim PE/Plus A casual evaluation of the version 4.7 shows a capable mixed-language tool simulator. by Tets Maniwa

This is the first in a series of informal EDA tool evaluations that will appear occasionally.

Modelsim PE/Plus V4.7, formerly called V-System, is the latest release of a versatile and capable simulator from Model Technology, Inc. (Beaverton, Ore.). It performs Verilog, VHDL, and mixed Verilog and VHDL simulation. Available for both NT and Unix workstations as well as Windows 95 PCs, it shares the same basic interfaces as the single-language versions and incorporates features from Mentor Graphics' Quick HDL Lite product. Its new features include the ability to independently open and close windows to conserve memory, to add signals from the data flow window, and to view log files from previous runs, plus on-line documentation on the CD-RM.

Overall, the tool offers several useful features. The ability to mix Verilog and VHDL is one of the best, as more designers work with design reuse and imported cores in the "other" language. The main interface lets the user determine the interactions--buttons, menus, or command line--while providing clear results of the design information. As a single-user tool, it's worth considering for evaluation.

For the evaluation, I used a Compaq 5100 Professional Workstation. The machine, which has a 300-MHz Pentium II, 512 Mbytes of RAM, and a 4-Gbyte hard disk drive, offers operating and performance characteristics that are significantly different from the average PC. (It was used in the EDA platform benchmark published in March. Other hardware characteristics are described there.)

In addition to the simulator, the package includes other useful software components that help with the design task. Probably the most useful are the precompiled VHDL packages that reduce the time and effort required to set up and perform some fairly basic functions. These are arithmetic.std_logic_arith, ieee.numeric_extra, ieee.numeric_signed, ieee.numeric_unsigned, ieee.std_logic_1164_extensions, ieeepure.vital_primitives, ieeepure.vital_timing, synopsys.arithmetic, synopsys.attributes, and synopsys.types.

Modelsim Plus is easy to load. It's done through the ubiquitous autoloading CD-ROM. From all I could tell, there were no incompatibilities or other problems with the installation. The caveat is that I had almost nothing else on the workstation when I loaded the tool. The Compaq workstation easily digested the files and was ready to run in a matter of a few minutes. I also loaded the software on a more conventional PC, just to check the differences. The Compaq workstation is definitely much faster than a 200 MHz Pentium with 32 Mbytes of RAM, but the small file sizes don't create a situation where the amount of RAM or the processor performance is a significant factor.

I started the evaluation by using Model Technology's introduction and tutorial materials, which included a book on the simulator and another book on the distinct implementation of the languages. The books and the tool work well and help to overcome the difficulties of starting up a new simulator. The tutorial has examples of circuits in all possible combinations of the two HDLs.

The examples show the differences between Verilog and VHDL as design languages and also demonstrate how to mix the two languages. One important detail for those who are used to Verilog as an interpreted language is the explanation of the compilation and order of files for simulation for the VHDL and Verilog portions.

Overall, the starting information was useful and easy to understand. I'd advise anyone starting out in HDL design to begin with a single language and become familiar with it before attempting mixed-language design, as the opportunities for developing a major disaster with the mixed languages are rampant.

GUI
I liked the overall user interface. One nice feature is the ability to use any combination of pull-down menus, radio buttons, or command line interface in moving and setting up circuits in the simulator. The basic operating modes don't require any changes, and the command line interface is always available even if another window is active. In addition, the log file displays the command line changes from all input sources, so you can see how changes to the operating environment are initiated by other controls. This feature is useful as a learning tool and also as a way to keep track of the changes in the operating environment for those more accustomed to a command line interface.

The GUI has customizable windows for all of the main functions. The nine possible windows are Source, Transcript, Attributes, Signals, Structure, Dataflow, Variables, Wave, and Process. They display the inputs and outputs of the simulation process and enable you to determine fairly easily where you are in the design, and you can change the data displays to provide the level of detail appropriate to the task at hand. The views display the structures and hierarchy of the design while the simulation is running, a feature that aids debugging.

After learning the user interface, I loaded some small files to see how the simulator operated. First I loaded known good designs with structures that make simulators work. The files were all fairly small, up to a few hundred lines of code. One block has multiple feedback paths and asynchronous inputs to stress the simulator algorithms, since the multiple feedback paths may not resolve if the input sequences get out of order. Another circuit is a DRAM controller that generates RAS and CAS signals to drive a black box memory bank. The simulator operated the circuits properly and processed some difficult problems. Developing and debugging the test benches took at least as long as the circuit design, an experience that is fairly common on design projects. However, my lack of current experience in doing HDL design probably slowed down the process.

Next, I loaded known bad designs to see if the tool could find the problems. The first is a datapath with known metastability problems. The second is an early version of the memory controller with incorrect gates and an inverted signal on the input of a register. This set of simulations was also a check on the the simulator's debugging capabilities to see how easily I could trace the known bugs and to see whether any other bugs existed, either in the design or in the tool.

Modelsim didn't find anything unusual in the known good or bad test samples. The bad circuits failed at the same places. Except for some operator head space errors, the files and directories worked well on the NT workstation. Since some of the circuits were parts of other designs, I was rudely reminded that simulations need to be initialized before running or the Xs propagate throughout the design very quickly, creating very large error and change files.

Editing and compiled code
The tool has the necessary functions easily accessible--forcing a signal to a state and on-line editing of the source file for debugging, for example. The source editing function allows on-line changes to the running code but doesn't save the changes in the source. I would have liked to see an integrated editor in addition to the on-line source editor. The compiler error messages indicate line numbers for the source code errors, but one of the editors I used doesn't show the line numbers, so I had to count lines to fix errors in the source files. In addition, when you've made a large number of changes in the compiled source code for debugging or optimization, you really need an easy way to save the changes in the off-line files. My preference may, however, reflect more my bad design habits and lack of recent design experience than any shortcomings of the tools. I don't like to work my way through log files and change dumps to see the modifications to the source I made in the design, and then save the changes in another piece of software.

The source files for simulation can be created in any type of application. I used Word and an emacs subset called notgnu to generate the various code pieces for this evaluation. The only strict requirement was the need to identify the proper extensions--".v" or ".vhd"--to get the system to recognize the file as belonging to the application. (Identifying the extension for the first instance of each file type is a normal requirement of NT and other versions of Windows.) Designs and file identification need some forethought to ensure that all the applications and design information will work as intended. The ability to link multiple files together to form a design is limited by the ability to track and compile the VHDL files in the proper sequence, especially when the possible names for the files proliferate.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  September 1998