The Free Model Foundation, a not-for-profit corporation, was formed by myself and 3 other engineers, who were working at TRW Inc. at the time. Our motivation was brought about by the lack of easily available board-level VHDL simulation models. Our goals were and are to encourage the use of standards-based board-level simulation by posting our findings, utilities, and simulation models to the public domain. "We" in this paper refers to the FMF, either working on our own, or previously working for TRW Inc.
This paper discusses a few topics in the use of VHDL/VITAL for board-level simulation. These include advantages of standards-based vs. proprietary tools; technical issues with VITAL board-level simulation models tackled by the FMF, and the work of the FMF to provide a resource and repository for public domain board-level simulation models.
With the advent and maturing of the VITAL standard, we chose it as the simulation model standard for our board-level component models. Verilog was not an attractive option in the Defense Contractor environment, since our ASIC and FPGA work was done in VHDL. Trying it anyhow (in the late 1994 time frame), we experienced considerable problems using Verilog in a heterogeneous, multi-library environment. This paper does not intend to ignite any religious wars by discussing Verilog vs. VHDL any further - the FMF supports the use of standards in general, including Verilog (we have some activity in supporting the IBIS standard as well) - but our experiences and our needs have so far been in VHDL.
The VITAL standard was written primarily to solve the problem of developing consistent ASIC libraries with VHDL. The use of VITAL for board-level models pushed the standard in some ways that required finding solutions. There are difficulties writing models for ECL parts that have differential inputs and/or clocks. Modeling passive components proved to be no problem except for the interesting case of the bi-directional resistor model. Due to the verbose style of VITAL and its deficiencies in support for "sizeability" we chose to represent most of our sizeable models as single-bit and let the CAD tool's netlist generator expand the sized model into multiple instantiations. (While size or bit width of the model may be passed into the model as a VHDL generic, it's difficult to propagate that "size" generic through the entire model: many VITAL timing check procedures aren't overloaded for vectored parameters, for one example.) 1
VITAL as a standard for board-level simulation facilitates a complete top-down design methodology, if VHDL is the language used for other levels of simulation. In an idealized design flow, system engineers do behavioral, conceptual analyses and generate simulatable specifications, design engineers plug their increasingly complex RTL and (later) gate-level representations of the same design into the same test benches the system engineers used, and at the end, the whole thing goes "on-the-shelf" and becomes a reusable archive for the next generation design that interfaces or extends the one completed. This is idealized, but realizable if the discipline exists within an organization to pioneer and establish the flow.
The FMF technology independent libraries use SGML-based timing files that are parsed by a "C" software program developed by the FMF, "mk_sdf". The program writes out an SDF file for the design according to the timing selections made by the designer. The typical way that is done is for the designer to attach a property to the component on a schematic that specifies the exact Timing Model to be used. This can be done automatically by selecting approved parts from a catalog that has the properties already attached to the parts.
The format of the timing file, "FTML", is based on SGML (Standard Generalized Markup Language). 2 For each generic simulation model, there is one FTML file but that file may contain scores of entries for different electronic parts that utilize that same simulation model. Inside the <TIMING> section of an FTML file, the timing data for the model is listed in the form of a chunk of an SDF file's "DELAY" entry. The only difference between FTML syntax and the snippet of SDF text within the <TIMING> tags, is parentheses may be omitted, and the SDF keywords TIMING, DELAY, ABSOLUTE, and TIMINGCHECK may be omitted (mk_sdf automatically adds these to the SDF file).
This jumble of packages causes problems when a design flow combines an RTL level synthesis design with a board design where VITAL is used. Unless the VITAL packages and models using them are compiled with the Synopsys versions of IEEE 1164 packages, the board design will not simulate with the RTL or synthesis design. But it doesn't make a lot of sense for large, board-level libraries to be compiled with a package tailored for synthesis - especially if the design environment using the board level libraries is large enough to include non-users of Synopsys. Those would include users of other synthesis tools, users who explicitly call (perhaps in test benches) the bona fide IEEE std_logic_1164 conversion functions that are given in NUMBERIC_STD that do not match those from Synopsys, or users who integrate other models which are compiled with the bona fide IEEE version of the packages.
In short, the existence of non-standard IEEE packages is a big headache that must be managed in a multi-library, mixed synthesis and non-synthesis environment. The preference of the FMF is to support the use of the bona fide IEEE packages, std_logic_1164 and numeric_std (which are the standard), and recognize that, when simulating a Synopsys-synthesized ASIC or FPGA with a board, either the board must be compiled using the Synopsys packages or the chip and test benches must be recompiled using the bona fide IEEE packages.
Well, they ought to. The model creation work would represent a small investment for a large IC vendor, but is a big job for the CAD staff of the typical systems design house. CAD vendors have traditionally supplied many digital libraries but have never been very keen on the task - the quality of most CAD vendors' libraries speaks for itself. The reasons usually given for IC vendors not supplying their own model libraries are summarized (and debunked) as follows:
It gives away IP to competitors.
Not so. Information in the behavioral model just reflects in useful form what is already in the data sheet.
IC vendors would be liable for inaccuracies in the models, or if not liable, harassed.
They're not liable for inaccuracies in the data sheets, and ought to appreciate feedback regarding any inaccuracies - misrepresentations of the product could sour customers on the vendor. The same reasons ought to be valid for models provided as "simulatable data sheets".
That can be changed. The vendors should be pressured to provide the model. An expectation of receiving support in the form of simulatable data sheets needs to be developed among designers.
Of course, the large, expensive models to create, such as Pentium processors and DSP chips, would still be significant IP for IP houses to market and sell: where the line should be drawn between these and the smaller-scale models still needed for simulation is up to the market to determine.
Perhaps when one IC vendor does supply its own models, markets that as a sales differentiator, and gets positive results from doing so, then the paradigm will begin to shift.
In some respects, these high-speed boards are reminiscent of the boards done 10 to 15 years ago during the "Golden Age" of TTL design. Back then, boards were loaded with lots of 7400 series ICs. Today, it's more ASICs and special purpose glue-logic (bus interface ICs, transceivers), but to do board simulation, they all must be modeled. Since it's impossible for the FMF alone to develop a comprehensive set of simulation models that would cover all categories of designs, we open our site as a repository of models developed and donated by others. Donated models can be of any shape and form - we'll categorize them as best we can - the only criteria are all models become public domain subject to the GNU "copyleft" agreement which is used in all our models, and the models must be posted in unencrypted source code.
Intel Corporation has donated many memory models. These models are not written in conformance to any particular standard (VITAL support of memory modeling is still in the works), but we are glad to post them and disseminate the information to whomever might find them useful, either designers using Intel parts, or those wishing to adapt them to do their own memory modeling.
In addition to the high-speed models, the FMF has also posted many discrete models, including a fairly sophisticated attempt to model the bi-directional resistor model in VHDL. There are several utility packages: one having constants and tables useful for ECL modeling, another having VITAL state tables for modeling most types of flip-flops and latches. Utilizing the flip-flop package would be particularly useful to modelers - the work done in reducing the pessimism of the flip-flops (making them a lot more like real flip-flops in a design) is often overlooked by a casual model writer. The mk_sdf program described in this paper is posted in source code. Of course, it was written and tested utilizing the GNU gcc "C" compiler.
We have been at work on a VITAL Modeling Style Guide for some time, and the beginnings of one have been posted. The key indicator of our "style", however, is the models themselves. The format used for the models has been developed over more than 2 years of working with VITAL and we think it is sufficiently advanced to be emulated and copied.
The Free Model Foundation has tried to spark interest in pursuing this approach by researching the methodology of using VITAL for board level simulation, and posting a growing number of source code models to the public domain. The FMF web site serves as a repository for simulation models contributed by designers who wish to contribute to alleviating the problem of a lack of easily available, standards-based board-level simulation models.
A paradigm shift to IC vendors providing the simulation models for their off-the-shelf components would be good thing for encouraging board-level and system level simulation. Board simulation models, for the most part, are proprietary to the CAD vendors' tools, and don't fit well into the ideal of a top-down design and verification environment. If a way could be found to encourage better availability of models, some of the stumbling blocks to this environment would be removed.
IEEE VITAL Standard ASIC Modeling Specification
Vreeland, R.E., "Tricks and Techniques for Writing VITAL 3.0 Compliant ECL Models", Cadence International User's Group, Mentor User's Group, both Fall 1995
Vreeland, R.E., "Board Level Component Modeling Using VITAL", Proceedings of the Spring 1997 VIUF
High Performance ECL Data, ECLinPS and ECLinPS Lite, Motorola Inc.