Your VITAL News Source A lot has been happening on the VITAL front, and here's an update. By Steven E. Schulz

I've had numerous requests to write yet another column on the VHDL Initiative Towards ASIC Libraries (VITAL) to focus on the flurry of recent IEEE activity and eradicate a few common technical misconceptions. VITAL is a worldwide open standards effort to enable signoff-quality, high-performance ASIC libraries in a VHDL environment that leverages from existing standards and ASIC cell practices.

This is my third column dedicated to this topic over the last two years, so if VITAL is all new to you, then perhaps now is a good time to dust off those old ASIC & EDA issues you've been saving. See the EDA Platform columns of August 1993 ("VITAL 101," p. 43), and May 1994 ("VITAL 102, an Update," p. 42).

VITAL v2.2b: The Market Responds VITAL v2.2b, which achieved a 95 percent approval in last April's member balloting, was quickly transferred to the IEEE Timing Methodology working group (PAR 1076.4) last June. The approval of v2.2b also sent a green light for initial VITAL-based product development. This benefited VITAL through ongoing strong momentum, and allowed ASIC library development to begin in earnest, helping to shape the technical focus for the IEEE revision. As of this writing, five VHDL simulators have already implemented VITAL Level 1 acceleration, and at least four more are under development. Three automatic VITAL library generators have been released (not including ASIC suppliers' internal VITAL generators). Furthermore, several leading FPGA development toolsets now support VITAL, providing new levels of performance and timing accuracy. Several consulting groups now offer VITAL tutorials and library development courses, which have been in demand internationally. The 2.2b version has already been used for final signoff simulation of several ATM networking chips using libraries from Orbit Semiconductor (Sunnyvale, CA). Other ASIC suppliers who have released signoff-quality ASIC libraries under v2.2b include Texas Instruments (Dallas, TX) and Hewlett-Packard (Palo Alto, CA).

VITAL v3.0: An IEEE Standard Even more momentum is building for the IEEE revision (v3.0). The technical action group under 1076.4 has had the greatest intensity, working at a fast pace to prioritize, design, and implement issue requests (IRs) as formally submitted on the VITAL Internet server. Over 100 IRs have been documented, prioritized, and analyzed. Approximately 65 IRs are planned for inclusion in v3.0. The proposed changes are captured in a new IEEE format VITAL specification, which is being distributed to the 1076.4 balloting constituency in anticipation of an April '95 ballot. Assuming passage in May and completion of negative ballot resolution, IEEE's review committee could grant VITAL official IEEE status as early as September. All are welcome to review the current status of any IR, read meeting minutes, or look at example files on the Internet server (see below).

V3.0: tech talk Now let's summarize what's different from v2.2b in the proposed IEEE version. The most significant changes focus on three areas: negative constraints, Level 1 architecture specification, and standard developing format (SDF) mapping and back-annotation.

Negative time sequential constraints pose a difficult challenge for ASIC cell modelers. In v3.0, a standard algorithm for converting negative specified time to positive time has been defined, along with the methodology for its usage within ASIC cells. While modeling of negative hold was possible in v2.2b, VITAL now has a clearly defined modeling style that supports negative setup as well. Several new generic prefixes have been added to support internally delayed clocks and signals, along with a means of back-annotating them at elaboration, and several new delay procedures have also been added. One side-benefit anticipated is enhanced simulation performance as a result of simplified violation checking.

Rules for mapping SDF constructs into VITAL generics have received much attention. The v3.0 specification fully supports all conditional delay constructs, improves the consistency of the naming rules, and removes ambiguities discovered from v2.2b. Furthermore, additional tool constraints are documented to ensure that SDF back-annotation into VITAL models will deliver consistent results across all simulators.

The VITAL Level 1 architecture is now defined using formal language grammar and simpler, more direct rules for usage of VITAL procedures. In addition, several upward-compatible changes in the Level 1 structure are included to better support new features requested by cell modelers. The most significant change is that the single process constraint is relaxed for describing functionality in v3.0. It is more straightforward to represent certain classes of cells as collections of two or more tables rather than as a single monolithic table. In some cases, access to internal signals is best supported this way, and some may find that translation from existing Verilog user-defined primitives is simpler. The tradeoff is in generally more complex timing checks. For those cells described easily using a single compact table, a single process is still the preferred choice. Strict usage rules help VHDL compilers and simulators to recognize the code structure for maximal acceleration. Other changes to Level 1 include permitting (at most) one driver per internal signal to avoid the possibility of glitches; a new VITAL primitive that explicitly resolves internal wired-or signals (enabling faster simulation); and optionality on each process section.

Other new features that many modelers will appreciate:

* Ability to specify unique propagation delays to/from X as well as 0, 1, or Z.

* New "PassPulse" option in "GlitchDetect" routines to support transport delay mode.

* New recovery/removal check that asserts messages specific to asynchronous signal violations.

* More type overloading in VITAL procedures that reduces the need for calling "VitalExtendToFill-
Delay."

* Consistent use of severity levels on standard messages from VITAL routines.

VITAL Mythology It has been quite gratifying to see so many hundreds of people learning about VITAL and developing products that use it. However, even more have only heard about VITAL through word of mouth, and have formed erroneous conclusions based on misconceptions. I've addressed a few popular myths below, in hopes of replacing them with facts.

Myth: "If you are not an ASIC cell developer, VITAL won't affect you."

Fact: VITAL can provide key benefits for anyone who uses VHDL simulation. For example, accelerated primitives and timing check routines may be used in user-written models to gain an order of magnitude speedup in VHDL simulation, and VITAL-based libraries are designed to be portable across multiple toolsets, reducing the library availability problem, easing design reuse, and exchange with external design groups.

Myth: "VITAL doesn't support slope-dependent delays."

Fact: VITAL's architecture is flexible, relying on external delay calculation to supply all back-annotated data for the design simulation. If your ASIC supplier uses slope-dependent delays and outputs SDF, VITAL can support it, too.

Myth: "VITAL's performance can never approach that of a gate-level simulator."

Fact: VITAL can be just as fast as any gate simulator, and for the very same technical reasons. Of course, VITAL doesn't determine this performance: that's up to each implementation. Yet VITAL's architecture and modeling guidelines were designed to permit the same "tight" optimizations used in gate algorithms. VITAL acceleration is nothing more than placing constraints on the flexibility of VHDL within a defined scope. VHDL can simulate it all, but the portion recognized by simulators as VITAL-compliant can immediately execute subroutines as efficient as any other gate simulator's subroutines. Results are now available indicating that several released VHDL simulators out-perform Verilog-XL at several ASIC suppliers' sites.

Myth: "VITAL doesn't support minimum/typical/maximum delay modes."

Fact: Since any given simulation run only uses one of these sets of values, VHDL generics do not require duplication for different delay modes. All modes are supported in VITAL, based on the choice of SDF file used, and/or the tool's mapping scheme from SDF.

Where to go from here If you are new to VITAL, I encourage you to take a closer look on VITAL's Internet server, which may be accessed in several ways. Use ftp or gopher to vhdl.org under /vi/vital , or if you are on the Web, use the URL: gopher://gopher.vhdl.org/11/vi/vital. The IEEE 1076.4 working group uses this server to maintain all VHDL packages, IRs, example models, and meeting minutes.

Steven E. Schulz is a contributing editor of Integrated System Design.

integrated system design  March 1995