article
VITAL : VHDL Initiative Toward ASIC Libraries
prepared by P. Bakowski
This page provides some initial infromation about the emergence and use of VITAL (VHDL Initiative Toward ASIC Libraries). Exercises
VITAL tutorial (external)
Przemyslaw Bakowski(a), Frédérique Bouchard(a), Jean-Paul Caïsso(b), Frédéric Igier(b)
(a) IRESTE, La Chantrerie, CP 3003, F-44087 NANTES Cedex 03, France
(b) MATRA MHS, La Chantrerie, CP 3008, F-44087 NANTES Cedex 03, France
Abstract
This paper presents the evolution of an emerging VHDL modelling methodology, called VITAL, which aims at writing accurate and portable VHDL models for ASIC gate libraries. We also provide here a comparison of VITAL performances to classical simulations.
As shown by its name, VHDL (VHSIC Hardware Description Language) started as a hardware description language for VHSIC (Very High Speed Integrated Circuits) at the end of the eighties. Nowadays, VHDL is also widely used for ASIC design. It was promoted as an IEEE standard in 1987 and is now recognized to be very adequate for VLSI (Very Large Scale Integration) modelling and simulation. Thus, hardware system designers and ASIC designers are now able to speak the same language!
VHDL is endowed with wide capabilities as it is well adapted to multi-level design. However, the lowest levels in an ASIC Top-Down design methodology are not based on VHDL yet (Figure 1).
Therefore, there is still a gap to be filled, which is encouraged by growing needs. The main demand is for sign-off quality. In ASIC design, sign-off simulation is defined [Lev94] as a kind of contract between the designer and the silicon vendor. Due to high fabrication costs in time and money a vendor requires that a design be simulated on a sign-off or golden simulator before fabrication begins so as to ensure the correctness of the design and especially of timing relationships. As a matter of fact, a great accuracy in timing is demanded by sub-micron technologies given that timing characteristics which were neglected up to now (e.g. falling and rising edges delays, interconnection delays) are not negligible anymore. Such an accuracy requires a uniform back-annotation mechanism.
The second sign-off requirement concerns simulation performance: simulators have to face the increasing complexity and size of ASIC designs. Moreover, concrete modelling guidelines are necessary for efficient simulations.
Naturally, traditional requirements for models, such as interoperability [Bil91], portability or exchangeability [BKLP92] remain.
All the above needs, added to those of the re-use of components, the sharing of libraries, the mixed-level validation as well as the reapplication of test stimuli, justify the use of the same language at all design stages (Figure 2).
As a candidate for this unique language, VHDL encounters some obstacles. In fact, VHDL is too flexible and thus allows various modelling styles, which keeps EDA tools from performance optimization, and various styles of timing representation, which forces ASIC vendors to support multiple VHDL libraries. Moreover, VHDL's `software-look' has traditionally consigned it to the specification level. Finally, limitations are also due to some language constructs that are too rich and not specific enough for ASIC design and simulation [Lev94] (e.g. the general VHDL signal structure, contrary to ASIC modelling which only requires the detection of an event on a signal and the capacity to determine the transition type).
On the other hand, VHDL is a standard language that offers the possibility for use at different levels in a design cycle, allows both concurrent and sequential flows and enables the modelling of parameterized cells (through GENERIC parameters). All these reasons have encouraged the use of VHDL as a description language for sign-off libraries and simulation by launching the VITAL initiative (VHDL Initiative Toward ASIC Libraries).
VITAL is an industry-based, informal consortium, whose objective is to "accelerate the development of sign-off quality ASIC macrocell simulation libraries written in VHDL by leveraging existing methodologies of model development".
VITAL was born from three studies. The first one was a survey conducted among ASIC designers and vendors and CAE tool vendors, and was reported in a technical requirement document [VITALTechReq].
The second study concerns existing modelling techniques as claimed through the objective. The bases of an efficient modelling technique have been formulated by Coelho [Coe88]: unification of logic systems for type declaration of ports in order to ensure interoperability; unification of error identification and handling in order to ensure consistency; naming rules; use of generic parameters in `cooperating' models. Then several proposals of VHDL modelling techniques were developed worldwide [Coe89, Zin90, Nav91, Mor91, DLP91, BKLP92, CH93, EIA, etc.]. Further research has been concentrated on specific aspects. For instance, among different back-annotation styles, the most efficient technique is the use of a standard delay file [BQ93]. Another study was conducted for validation check modelling [LP91] showing that the best trade-off between memory size, execution time and consistency was found for procedure calls which were compared to assertion statements and processes.
Thirdly, VITAL investigated existing gate libraries, and tried especially to benefit from Verilog experience (standard description of timing, many predefined features, user-defined primitives, etc.).
Eventually, VITAL aims at providing:
The next section deals with the evolution of VITAL specification from birth till now. Some simulation results are provided in Section III, comparing VITAL performances to classical performances. Finally, we conclude on VITAL prospect.
This section presents the history of VITAL strategies. Since VITAL's first release in February 1993 [VITAL], some fundamental concepts have remained:
During the evolution of VITAL specification, two styles of architecture representations have been investigated: initially, a concurrent style, and currently a sequential style.
The modelling needs that have to be answered are [Ber94]:
When VITAL specification v2.0 was released (May 1993) [VITAL], the timing and primitives packages were not available yet. VITAL primitives were announced to be in the form of VHDL components, i.e. with an entity declaration and its architecture body. Meanwhile, VITAL specification v2.0 was recommending:
The major contradiction implied by this release was related to the way of linking primitives in a model without using global signals.
The general philosophy concerning the model interface was tending towards:
Therefore, all timing information was put in a package attached to the model. Timing values were collected in an array that could then be applied to the model as a single generic parameter. This technique allowed the reduction of the generic parameters to this array including all timing values, and a few model control switches, hence, providing the same number of generic parameters for every model. However, this strategy affected the efficiency of models.
This transition was done by the availability of VITAL packages: VITAL_Timing package v0.903 and VITAL_Primitives v0.301. The primitives were provided in the form of procedures comprising the functionality and timing aspects, and functions handling only functionality. This new strategy for primitives has remained in following versions.
Unfortunately, the primitives were not usable in this `first' version. For instance, we could not use primitives in the form of procedures for combinational cells since local delays applying to each primitive were not available. We could not use either of these primitives in the form of functions for we would have lost timing path information. As for sequential primitives, some of them did not suit our needs exactly. The addition of a combinational part to the primitives in order to get the required functionality would return to the problems encountered for combinational models.
Therefore, we first modelled our cells like VITAL primitives. First, an evaluation of delay schedules was performed by the VITAL predefined InvPath() or BufPath(), depending on whether the inputs were inverting or not. Then, for combinational cells, the functionality was applied for output and scheduled times, and the VITAL procedure GetSchedDelay() handled these new scheduled times. For sequential cells, timing checks were performed through calls to VITAL predefined procedures or functions. Then the VITAL function SelectCondition() selected the relevant line of the state table and a CASE statement indicated the action to be taken along with the updating of scheduled times. Finally, the VITAL procedure GlitchOnEvent() assigned the output, detected and handled hazards for both combinational and sequential models.
Since VITAL specification v2.1e [VITAL], a new general strategy has been adopted. There are now two levels in VITAL compliance.
Level 0 corresponds to the model interface specification. It satisfies the minimum requirements for ASIC modelling, such as [Ber94]:
Level 0 indicates that all functionality and timing information exists in the architecture.
Level 1 corresponds to the model architecture specification. It is a definition of a standard modelling methodology using VITAL packages necessary for making standard, acceleratable libraries.
VITAL_Timing package provides routines applying to interconnection delay modelling, timing violation checking and Pin-to-Pin delay handling.
VITAL_Primitives package provides a standard set of acceleratable routines: simple basic logic cells (AND, OR, NAND, NOR, XNOR, buffers, inverters, multiplexers, decoders) and user-defined primitives (VitalTruthTable() and VitalStateTable()) using a predefined type VitalTableSymbolType modelling levels and edges of signals.
Level 1 takes into account the two different styles used to model propagation delays. For a `distributed delay' style, the architecture body contains two separate blocks. One is used to implement the input port delays (including interconnection delays) and is referenced as WIRE_DELAY block. The other block, usually called VITAL_Netlist, contains all concurrent calls to VITAL functional primitives composing the cell. All timing aspects are included in these primitives.
For a `pin-to-pin delay' style, the architecture is shown on Figure 3. The three sequential parts inside VITALBehaviour process are optional, but at least one has to exist. The timing checks part reports errors and warnings and generates a violation flag used by the functional part. This second part handles no timing, it produces zero delay outputs and states. Then, the pin-to-pin delays part selects the appropriate delay values to be assigned to the outputs by using VITAL delay selection procedures. This third part can also handle hazards and generate warnings and `X' on outputs.
Below is the structure of a VITAL Level 1-compliant architecture using a pin-to-pin delay style:
VITAL specification is not complete yet and issues are regularly raised.
For instance, several minor issues concern some missing features (e.g. RAM/ROM), or the request for overloading some VITAL timing procedures.
Moreover, a few critical issues have also been detected. In particular, the simulation results can be different depending on whether a Pin-to-Pin Delay model or a Distributed Delay model is chosen. As a matter of fact, we have seen in Section II.2 that VITAL primitives used in a Distributed Delay model take into account the port states as well as the functionality to select the right propagation delay, whereas only the port states are considered in a Pin-to-Pin Delay model.
We present here results obtained by simulating circuits comprising either of the three following VITAL models: an AOI22 computing O <- not ((A and B) or (C and D)) and representing the combinational category of models; a sequential model called SFFRSB which means a Scanpath D Flip-Flop with active high Reset and active low Set; and a tristate buffer called TRISTA.
Tests have been made in order to find out whether our goal can be reached, namely, simulating a Sea of Gates network of more than 100,000 gates in a reasonable time. Up to now, the circuits we were developing were no larger than about 70,000 gates.
Before having any functionality, a Sea of Gates chip is an array of basic frames. Each frame is composed of PMOS and NMOS transistors. The interconnections between these transistors transform a basic frame into a basic gate. All the components of a chip are built up from associating these basic gates. As different components are not necessarily composed of the same number of basic gates, we consider the basic gate as the measurement unit for circuit sizes.
We ran all simulations on a SPARC 20 Workstation (128 Mbytes memory, 400 Mbytes swap). VHDL simulations with accelerated VITAL packages used QuickVHDL simulator v8.4_3.4.3 from Mentor Graphics. Classical simulations run for comparisons used QuickSim II simulator v8.2_6.1 also from Mentor Graphics. VITAL packages used are VITAL_Timing and VITAL_Primitives v3.0.0.1. The simulation times provided here as `total' correspond to the time taken by the complete simulation command, i.e. including the time for loading the circuit, the time for simulation itself and the time for storing the values.
We tested an array of ten rows of AOI22 models, equivalent to an array of 100,040 basic gates. Simulations presented in Table 1 were run on 2 ns. The typical delay times used were: propagation delay for a rising edge tplh = 0.47 ns, propagation delay for a falling edge tphl = 0.24 ns. All our models also have the possibility to be run in unit delay (tplh = tphl = 0.1 ns and no timing checks).
Table 2 provides results obtained for an array of SFFRSB models. We ran simulations on 8 ns with a clock period of 4 ns, i.e. on two clock rising edges. For this circuit, we could easily find out the limit of the number of simulatable VITAL SFFRSB models. This limit corresponds to a number of 384,000 basic gates which is almost four times our goal.
The two tables above show better performances for VITAL Level 1 simulations (shown by VHDL simulations with typical times) if we look at the time taken by the total simulation command. This is not right when we compare only the time taken by only the simulation, i.e. without loading and storing. On VHDL side, Table 1 and Table 2 show that calls to procedures (for timing checks and handling of propagation delays) are costly. On the classical side, it seems that all delay calculations are done during the loading of the circuit, then simulation itself is very fast.
QuickVHDL and QuickSim both are event-driven simulators, which explains that in general (with typical times) simulation times for a circuit with combinational gates (Table 1) which generate a tremendous number of events are much greater than for a circuit composed of sequential gates activated only on clock edges (Table 2).
We then tried to investigate the influence of the topology of circuits (Table 3). We ran simulations on 8010 ns. The experiments indicate that topology does not affect VITAL simulations as VHDL is only dependent on the number of events. As for classical simulations, the influence of topology is obvious: classical simulation is very much dependent on the number of inputs and outputs of circuits. In the parallel circuit, for which inputs of SFFRSB models have been grouped together in order to reduce the number of inputs for the circuit, most of the time is spent storing the I/O's. If we group together fewer inputs, having 2,000 inputs for the circuit instead of 20, total simulation times reach almost 8 hours. This important time may also be due to a great number of page faults during memory access as the structural models composing the parallel circuit have no links between each other.
For the VHDL TRISTA model, using the `distributed-delay' modelling style, we could not simulate arrays larger than 76,830 basic gates, which is far below our goal, but no real circuit is exclusively composed of tristate buffers. Table 4 provides VITAL simulation times for 2 ns run time.
Considering `total' simulation times (Table 1 to Table 4), VITAL seems to be very competitive in most cases.
This is even more convincing when we use a faster simulator: for the largest circuits of Table 1 and Table 2 with typical times, we could reach a total simulation time of about 5 minutes.
However, the results do not reflect real VITAL conditions: we could not use back-annotation for these first experiments due to remaining problems with SDF mapping. Therefore, we have to investigate to what extent this can slow down simulation.
Although VITAL is not completely stable yet, which prevents simulators from running at their highest capacities, the first results seem to ensure an encouraging future for the place taken by VITAL modelling in ASIC design flows. This justifies VITAL as currently being on the way to IEEE standardization and that it is considered the best candidate to be the base-standard of OMF (Open Model Forum) which aims at becoming a broader standard for discrete-event digital simulation of fault-free electronics networks.
The challenge now is to use VITAL as a spring-board towards modelling more complex components, which amounts to extending VITAL applications to all areas of the design cube presented by Ecker and Hofmeister [EH92] (Figure 4).
For instance, we could define a `virtual' VITAL model of a processor in the sense that it would have a VITAL interface, and a VHDL RTL layer and a core described in the C-language for simulation speed reasons.
VITAL is also giving birth to strong needs of tool kits. Automatic generators of VITAL models are necessary to build complete libraries. For complex component modelling, interfaces between different layers (e.g. VHDL/C) must be developed. Moreover, the generation of state tables for complex models will need graphical tools to describe simplified state tables which will then be completed by other tools according to default states. These latter tools should be able to take a priori or a posteriori decisions for `missing' states corresponding to special cases.
[Ber94] V. Berman. ASIC Design in VHDL: Building Efficient VITAL Libraries, Tutorial, VHDL-Forum Spring'94, April 1994.
[Bil91] W. D. Billowitch. Interoperability of VHDL Models.,Proc. of EURO-VHDL'91, pp 128-132, 1991.
[BKLP92] M. Blüml, B. Kierdorf, M. Lenzen, A. Pawlak. A Methodology for the Development of High Quality Standard-Cell Models in VHDL. Proc. of VHDL-Forum Spring'92, pp 17-26, 1992.
[BQ93] C. Berthet, C. Quellier. An Efficient and Portable VHDL Library for ASIC Design. Proc. of EURO-ASIC'93, pp 2-10, 1993.
[CH93] J-P. Caïsso, J-L. Hallé, A Universal Structural VHDL Library for ASIC Simulations Proceedings of the VHDL-Forum for CAD in Europe, pp. 185-190, Innsbruck, March 1993
[Coe88] D. R. Coelho. VHDL: A Call for Standards. Proc. of the 25th Design Automation Conference, 1988.
[Coe89] D. R. Coelho. The VHDL Handbook. Kluwer Academic Publishers, 1989.
[DLP91] J.-L. Dubois, F. Liu, A. Pawlak. Standard Component Modeling in VHDL. Proc. of the ASIM'91, Hagen, September 1991.
[EH92] W. Ecker, M. Hofmeister. The Design Cube - A Model for VHDL Designflow Representation. Proc. of EURO-VHDL'92, pp 752-757, 1992.
[EIA] Electronic Industries Association. Commercial Component Model Specification. Revision J, May 1989 and June 1992.
[Lev94] O. Levia. ASIC Sign-Off Simulation in VHDL & VITAL. Proc. VHDL-Forum Spring'94, Tremezzo, April 1994.
[LP91] F. Liu, A. Pawlak. Timing Constraint Checks in VHDL - A Comparative Study. Proc. of EURO-VHDL'91, pp 39-45, 1991.
[Mor91] G. Moretti. Modeling of Standard Component Libraries. `Applications of VHDL to Circuit Design'. Kluwer Academic Publishers, 1991.
[Nav91] Z. Navabi. Behavioral Level Modeling of Gate Level Loading Effects. Proc. of the CHDL, Marseille, April 1991.
[VITAL] VITAL: VHDL Initiative Toward ASIC Libraries, Model Development Specification, Version 1.0 Feb. 1993, Version 2.0 May 1993, Version 2.1e Dec. 1993, Version 2.2b Mar. 1994
[VITALTechReq] VITAL: VHDL Initiative Toward ASIC Libraries, Technical Requirements Document, Version 1.0 Oct. 1992
[Zin90] R. Zinszner. Modeling Techniques. First European Conference on VHDL Methods, Marseille, 1990.
Exercises