Free Model Foundry
Acuson designs and manufactures high-end medical ultrasonic imaging machines. Like many companies in Silicon Valley, it has traditionally been a verilog house. Verilog was originally used for ASIC design and verification. More recently, it has been used for FPGA synthesis. It has worked fine in these applications. We intend to continue using it as a front end to synthesis and as a sign-off simulator for ASIC vendors.
Eventually Verilog found its way into board-level simulations. Here difficulties were encountered. The first problem was in netlisting. Because Verilog is used primarily for chip design where a single library is used, the netlister did not handle multiple libraries well and was famous for spewing out error messages that were totally unrelated to the actual errors.
Although the netlister has since improved, other problems still remain with using verilog at the board level. The most critical is model availability. There are very few source level models available for commercial components in verilog. In contrast, there are free, unencrypted models available in VHDL for at least 1900 part numbers. More are being published every week. Also, while Verilog works fine for simulating 1's and 0's, board level simulation needs to work well with signal strengths that are modified by resistors used for terminations and pull-ups or pull-downs. Board level simulation must also handle components that are open-collector or open-emitter, or that have differential inputs.
For these and other reasons, it was decided to migrate Acuson to VHDL for board-level simulation. The Free Model Foundation had already done a great deal of work on techniques of modeling commercial components so, we chose to use their modeling and simulation methodology. However, all those ASICs and FPGAs are stilling going to be done in verilog. So, a mixed HDL simulation environment is required. In this environment most component models are in VHDL while ASIC and FPGA models are usually in verilog. The test bench may be in which ever language the engineer prefers.
It was also recognized that if we stayed in a single language environment, whatever language we chose, some model, critical to our ability to simulate a design, would likely be available only in the other language.
A primary goal of the transition is to make the overall design and simulation cycle easier and faster. We tested different mixed language simulators and determined that a single kernel simulator was required. Non-single kernel tools were biased in favor of the language in which the design was netlisted. They offered limited visibility into that part of the simulation that was taking place in the other language. The only single kernel simulator available at the time was ModelSim from Model Technologies. Since that time, Cadence has released their long awaited Affirma NCsim simulator, also known as "ncsim". This paper will discuss how either simulator can be used with the Cadence schematic capture tool, Concept.
An advantage of HDL simulation is that it is standards based. As other CAE vendors release single kernel simulators, Acuson will have the option of considering them. I anticipate that simulators should be fairly interchangeable in our simulation flow. Minor adjustments to the libraries may be required.
The heart of every CAE process is its libraries. This is particularly true in the board design and simulation process. Acuson uses the Concept schematic capture system from Cadence as a front end to Cadence's Allegro PCB design tool. Acuson's libraries have been optimized for mixed HDL simulation. They are built on an extension of the library structure designed at TRW in 1995 for VHDL (Leapfrog) only simulation.
A key feature of the Acuson library is the separation of functionality from timing. This allows for technology independence and significantly reduces the total number of parts (and models) in the library. While part types come in multiple speed grades or technologies, and in many packages, they require only a single model. The saving varies with part family - for the 7400 series, the savings can be huge; for more specialized components, it may be minimal.
Within each component group there are two new directories, src and Timingmodels. The src directory contains the model VHDL or verilog source code. The Timingmodels directory has the timing files for each model. Each timing file can hold timing information for any number of variations of a part type.
In figure 1, the std02 uses a verilog model. Within the entity, vhdl_behavioral and verilog directories there are links named vhdl.vhd. They all point back to the model source in the src directory. These links are required for the netlister, VHDLLink, to work. The reason the verilog directory exists is because the architecture of the VHDL model is named "verilog". A part modeled in VHDL would not have the verilog or module directories.
The body file is the schematic symbol and the chips_prt file maps the symbol to the physical pin numbers of the part. A single chips_prt file can handle all the different packages the part can be purchased in.
At Acuson, after the librarian creates the component directory with the body files and chips_prt file, a perl script called chp2vh is run. It creates the entity and vhdl_behavioral directories, a dummy VHDL model, a vhdl_map template, and the two links. For parts modeled in VHDL, the dummy model is then replaced with a functional model and the map file edited accordingly.
When the VHDL model is compiled with ncvhdl, the compiled versions of the model go into the entity and vhdl_behavioral directories. If the part is verilog based, the VHDL architecture will be named "verilog" and a verilog directory will be created by the compiler. This directory will also contain compiled VHDL and a link back to the source code.
The symbol.ppt file is what is called a physical part table. It allows various properties to be associated with a symbol when it is placed on the schematic. These properties then determine the foot print that will be used in layout, the timing that will be used in simulation, and other things as determined by the librarian.
There is a new directory named work. The work directory contains the ModelSim compiled VHDL and verilog models for the entire library. The compiled code is no longer stored in the part directory. The verilog and module directories are not needed and all parts have the same directory structure whether they use VHDL or verilog models.
Including verilog models in the simulation is transparent to the user but adds several additional steps for the librarian. The steps outlined below are those required for Cadence's new Affirma NCsim product. They will be contrasted with the procedures used in a mixed Cadence/ModelTech environment.
After adding the verilog model to the src directory in the library, the first step is to compile it. The command is "ncvlog src/std02.v". This will compile the verilog model and place the results in std02/module.
The next step is to create the VHDL shell. This will be a dummy VHDL model that has an entity with a port list but an empty architecture. We can create this model by running the ncshell command "ncshell -import verilog -into vhdl -mode event stnd.std02". The shell is required for netlisting the design in VHDL. It will replace any dummy model that may have been created by chp2vh (described below).
The map file, vhdl_map links the VHDL entity to the Concept symbol. A template for the map file is generated by running a perl script named chp2vh. The file must then be manually edited to be sure it matches the VHDL entity created by ncshell. Because we are netlisting in VHDL and using a single kernel simulator, we want to avoid any references to verilog.
The verilog model gets compiled into the work directory for the library it resides in. The ModelSim command is "vlog <filename>". VHDL models, if they exist in the library, may be compiled into the same directory. No new directories are created under the part.
The dummy model must have an interface (entity) that maps directly to the verilog module. ModelSim has a utility called "vgencomp" that reads the compiled verilog model and outputs a corresponding VHDL component declaration. This component declaration is then used to correct the VHDL entity for the dummy model.
Since we changed the entity in the dummy model to match the verilog module interface, we now must edit the vhdl_map template to match the new entity. This looks like a great opportunity for another perl script. At the moment, it is being done manually.
It is important in the ModelSim flow that the dummy VHDL model is either never compiled or always overwritten by compiling the verilog model afterwards. Otherwise, assuming it compiles successfully, the simulation will use it instead of the verilog. Since the dummy model has no behavior, it will simulate as an open circuit but will not necessarily give any error messages.
It is assumed at this point that the libraries are in place and are pre-compiled for the user. This would normally be done by the librarian, however, the user may be responsible for setting up any verilog FPGA or ASIC models in the design as described above. Acuson's component libraries are technology independent and utilize FMF simulation models. This reduces the effort required for library development and maintenance.
Schematics are drawn in Concept as they would be for any board design with some caveats to be discussed below. The schematics may be either hierarchical or flat. Because Acuson uses FMF technology independent libraries, components must be added to the schematics using the component browser set to physical mode. Selecting parts this way causes properties to be added to the schematics that are later used to select the correct timing and physical package for each component.
Having produced a VHDL netlist, the next step is to compile it. Using the Cadence simulator the command would be "ncvhdl <filename>". For Acuson, using the ModelTech simulator the command is "vcom <filename>". Before the netlist can be compiled the first time, a work directory must be established to receive the compilation results. In Cadence this is done by editing two files called cds.lib and hdl.var. For ModelTech it is done with the command "vlib work".
Each model has an associated timing file that describes the internal delays of a component with any required timing constraints. Some of the benefits of external timing files are discussed below in the Models section.
SDF generation produces a file in Standard Delay Format that may be used by the simulator to provide accurate timing for the simulation. Initial simulation runs may not require timing and can skip this step. Without SDF annotation, FMF models default to unit delays (1 ns).
The SDF tool is called mk_sdf and may be obtained as a Solaris binary or as C source code from the Free Model Foundation (at no cost). It uses a command file named mk_sdf.cmd which should reside in the working directory. Figure 4 shows a sample mk_sdf.cmd file.
When using NCsim, the sdf file from mk_sdf must be compiled before it can be used. The command is "ncsdfc <sdf_file_name>". Then a sdf command file must be created to specify sdf related commands to the elaborator. This file may be as simple as a single line naming the compiled sdf file.
The Cadence NCsim simulator has a separate elaboration step. If timing backannotation is being done, the SDF file is read at this time. The command is "ncelab -SDF_CMD_FLIE <cmd file> mydesign". The cmd file specifies the name of a file of SDF annotation commands. SDF backannotation may be omitted by running "ncelab mydesign" instead. This will result in all models being simulated with 1 nanosecond delays.
The ModelSim simulator does not have a separate elaboration step. Elaboration is always done when the simulator is started. The simulator is invoked from the command line with arguments for SDF backannotation and name of the SDF file and the design name: "vsim -sdfmax vhdllink_bat.sdf mydesign". If timing is not required, the "-sdfmax vhdllink_bat.sdf" argument may be omitted for unit delay simulation. Or, multiple SDF files may be read to include interconnect delays from Allegro, timing files for ASICs and FPGAs, etc.
After satisfactory simulation results are obtained, the design goes to PCB layout. If timing margins were determined to be tight, anticipated interconnect delays based on manhattan distances between pins may be computed and backannotated through SDF to check if timing constraints are likely to be met by the proposed layout.
Subsequent to layout and routing of the PCB, signal integrity analysis may be performed. The same physical parts tables that selected the correct timing file for simulation also provided the name of the signal integrity model to be used in the Cadence signal integrity tool, SigNoise. SigNoise is capable of computing values for various physical effects such as crosstalk and noise margins. It can also compute accurate interconnect delays based on the characteristics of a driver's output buffer, receiver thresholds, propagation delays calculated for the board stackup, and transmission line analysis of the traces.
Accurate interconnect delays, including transmission line effects, can be extracted from Allegro with the command "a2sdf -s <boardname> <outputfilename>". Allegro versions 13.0 and earlier produce a file that can only be read in Logic WorkBench. It should be possible to write a script that reads this file and the namemap files to produce a usable SDF file.
Once the interconnect SDF file is generated, a final full timing simulation can be run. It would be more efficient at this point to run a static timing analyzer. Unfortunately there do not seem to be any good candidate tools on the market. All the data needed appears to be in the SDF files but the few static timing analyzers available read only proprietary model formats. Perhaps this is a market opportunity for someone.
While the design and simulation process described above should be relatively easy and straight forward, it is possible to make it difficult. Below are some techniques and caveats to keep in mind to avoid unnecessary complications.
Some people like to run busses into hierarchical blocks but not connect all bits of the bus inside the block. The netlister may have difficulties with this. Either connect to the block only the number of bits actually used or, attach a flag body to each unconnected net inside the block.
Sometimes, an engineer will create a bus for which some bits are inputs to a block and other bits are outputs from the block. Doing this will successfully prevent netlisting. All bits on a bus must go in the same direction.
The netlister occasionally has difficulties determining the correct mode of a port on a hierarchical body. Sometimes it assigns INOUT and other times it gives up and assigns UNDEFINED. A port mode of UNDEFINED will prevent compilation of the netlist. Usually port mode can be forced to the correct value by attaching the appropriate version of a flag body to the net inside the block.
The Free Model Foundation is a not-for-profit corporation. Its goal is to improve the availability and usability or simulation models of off-the-shelf electronic components. It is working to accomplish this goal by helping the component vendors understand the benefits of providing such models. It provides services to the component vendors to assist them with technical issues. If staffing is a problem for the vendor, FMF can help them find out sourcing arrangements for model creation.
Board-level simulation is not as widely practised as it should be. The principle deterrents are model availability and simulator ease of use. The advent of mixed language simulators improves the practicality of board-level simulation by expanding the base of models that may be used.
The Free Model Foundation is working to alleviate the model shortage by helping vendors provide open source HDL models. A large but insufficient number of models are now freely available. With the support of the user community, this can be vastly expanded.
The acceptance of board-level in general, and mixed language simulation in particular, will be dependent on the ability of the tool vendors and the CAE support staffs to hide the underlying complexity. Engineers must have an easy, intuitive path to simulation or they will resist the transition from bread boards and iterative prototypes.