prepared by F. Bouchard
As long as the hardware circuits and components were not very complex themselves (i.e. they could be easily modelled by one person or at most a very small group of co-workers), modelling rules were implicit, given by the style of the unique developer or by the ``modelling culture'' of the company. Therefore, the very few components of a project were quite well interoperable because the modelling style was coherent between the different elements.
When the circuits have become more and more complex, implying models not manageable by a small group of co-workers, the modelling projects started implicating various teams in companies and even various companies. At that time, people started talking explicitly about notions like portability, consistency, interoperability, compatibility [Dub91], and, given the effort provided for one project, about
reusability. That way appeared the need for well-defined modelling rules, and even more, well-defined modelling guidelines, understood as methodologies for using a set of modelling rules defined for special purposes. Indeed, a model, which is a representation of a system in a form order than the one in which the system exists, is usually intended for one purpose. Therefore, it is lacking some details of the real system and may not be used for other purposes. Consequently, a model must be associated with its context, and so must be the corresponding modelling rules. Some of the different contexts for an electronic system may concern its usage -or application- domain (like synthesis, simulation, test...), its abstraction level, or its complexity level.
Now, with the large experience gathered over years with respect to modelling rules, the situation in the standardization domain is very dynamic, as we shall see along this paper. But still, we can find in the VHDL community two categories of modellers: the ones who develop their own guidelines exactly fitting their own needs; and the ones who try and exploit existing guidelines.
Among the existing and available guidelines, there are real standards, approved by international organizations [VITAL, EIA]. There are also de facto standards, like OMI coding standard [OMI], and other modelling guidelines originally developed by big corporations for themselves (e.g. the US Navy [TIREP], the European Space Agency [ESA94, ESA96]). These corporations impose their rules to all their partners (contractors, providers...) and even externally, they try to get them widely shared. Accompanying standards are available as well. They are not strictly speaking modelling guidelines, they rather extend or, on the contrary, restrict VHDL modelling for special purposes (e.g. for synthesis [IEEESynth], test [WAVES], analog modelling [VHDLA]). Some actions relevant for VHDL modellers, like OMF, VSI, Pinnacles, etc. have been launched, concerning interoperability of component models and data in a very broad sense.
In this dynamic scenario of modelling guidelines, we try in section 2 to classify some of them, according to their general recognition, we try to clarify their application domain and to comment on their utility. The survey of private guidelines is far from being exhaustive, we have chosen a few significant examples from this large list of individual experiences. In section 3, a selection of a few main guidelines is more detailed. In the conclusion, a table summarizes our classification.
Besides, more technical and specialized organizations concentrate on the development of standards and usually submit them to the above organizations for actual standardization. Among these de facto standard making bodies, we can mention IEEE (Institute of Electrical and Electronics Engineers), EIA (Electronic Industries Association), SI2 (Silicon Integration Initiative, formerly CFI), ECSI (European CAD Standardization Initiative), OVI (Open Verilog International), or VI (VHDL International).
All modelling guidelines owned by one of the above organizations will be qualified here as ``standards'', although this is a language misuse for the category of de facto standard making bodies. Therefore, our so-called standards are, for instance: VITAL [VITAL] (VHDL Initiative Towards ASIC Libraries) also known as IEEE 1076.4; EIA-567A [EIA] (the VHDL Model Component and Hardware Interface Standard); WAVES [WAVES] (Waveform and Vector Exchange Standard) also known as IEEE 1029.1; IEEE 1164 [IEEESLP] (the Multi-Value Logic standard embodied in the Std_Logic_1164 package); and IEEE 1076.3 [IEEESynth] (the Standard VHDL Synthesis packages).
Next section defines what is qualified as ``de facto standard'' in this paper.
In this category, we can find the general VHDL Modelling Guidelines [ESA94] and the more specialized guidelines for VHDL Board Level Simulation [ESA96] proposed by ESA/ESTEC, the European Space Agency; OMI 326: VHDL Coding Standard developed within OMI project (Open Microprocessor systems Initiative) [OMI]; and a VHDL Modeling Guide produced by TIREP project (Technology Independent Representation of Electronic Products) [TIREP], a cooperative effort of a few divisions of the US Navy.
More specialized experiments may concern finite state machine (FSM) modelling [Cyp95], protocol modelling [Pir96], timing checks modelling [Liu91]; as well as modelling targeted for FPGAs [Gsc96], for performance modelling [Ros94], for synthesis [Deb93, Ram93, Ele94], for testbenches [Han95, Unk95, Arm95], for efficient simulation [Lev91, Hue91, Mas95, Mad96], or for standard cells [Zin90, Blü92].
Since the purpose of this paper is to concentrate mainly on standards useful for a wide audience, we do not detail these individual experiences.
For the above reasons, the effort of standardization in this area is quite active. An IEEE working group has done a hard job on IEEE 1076.3, the recent standard VHDL synthesis packages [IEEESynth]. The European VHDL Synthesis Working Group (EVSWG) has tried to define a tool-independent synthesis subset, called Level-0 [Vil95]. And currently, the Synthesis Interoperability Working Group, launched by the CAD Industry Council, is actively working on a standard RTL synthesis subset called Level-1, based on Synopsys' subset which appears to be the synthesis subset the most widely used in the synthesis community.
Besides, many modelling guidelines deal with synthesis, especially OMI 326 VHDL Coding Standard [OMI] when it defines rules for the RTL usage; Ben Cohen's book [Coh95] where synthesis rules are emphasized; some aspects of SAVE environment [Mas95], of J. Bergeron's guidelines [Ber], and of Madisetti's tips [Mad96]; and the set of rules proposed by A. Debreil and Ph. Oddo [Deb93] for synchronous designs. Usually, the constraints imposed by synthesis concern types or other VHDL features which are not supported; restrictions on constant definition or on delay specifications; specific process structures with much attention paid on clocks; explicit reset functions; etc.
Standards like VITAL [VITAL], EIA-567A [EIA] or the Std_Logic_1164 package [IEEESLP, Bil91] are the result of consensus between many participants. On the other hand, ESA VHDL Modelling Guidelines [ESA94, ESA96], which are fully devoted to simulation at different levels of abstraction, have been elaborated out from ESA experiences.
The IEEE Std_Logic_1164 package contains definitions for useful electronic types (not only `0' and `1' but also high-impedance states, unknowns and a ``don't care'' state), basic conversion functions between the complete std_logic type and subsets of it, overloaded logical operators, and much more. This standard is widely used for modelling component interfaces and it guarantees that those components easily interoperate in the same environment without any additional interface which would need to convert types. It is required for all modelling guidelines presented here in all application domains, not only for simulation.
VHDL simulation at a so-called low level, i.e. logic gate level, has long been prohibitive because too slow. VITAL exactly addresses this issue by defining a strict structure for ASIC cell models using packages whose procedures and functions are accelerated by VHDL simulator kernels.
EIA-567A also provides guidelines and packages with predefined types, procedures and functions, but for descriptions at specification level and hardware-component level, and including not only the component functionality but also pin characteristics, timing constraints or operating point conditions. EIA-567A is the basis of TIREP [TIREP] VHDL Modeling Guide.
OMI 326 [OMI] reserves a large place to simulation aspects, as well as Ben Cohen in his book [Coh95].
Apart from these standards or de facto standards, majority of the individual experiences listed in section 2.1.3 deal with simulation. Some of them relate experiments made in a precise domain in order to compare and demonstrate the value of VHDL features or styles over other ones functionally equivalent but for which simulation performances show significant differences.
At system level, Voss et al. [Vos95] show the linear effect of signal sizes on execution times, as well as the great negative influence of the use of file inputs and outputs for large models and the use of bus resolution functions. Liu et al. [Liu91] have studied the different ways of handling timing constraint checks: concurrent assertion statement, process statement, and procedure call statement, and they have experimented that the latter gives the best compromise between memory size and execution time. P. Ashenden [Ash94] has compared two styles for the description of recursive hardware structures: a repetitive component instantiation vs. a recursive style. This one proves to be the best one in most cases.
The other experiences rather give general tips for speeding up simulations [Lev91, Hue91, Mas95, Mad96], tips that can also be found in more complete guidelines [ESA94, ESA96]. All agree to advice the use of variables instead of signals whenever possible. The cost of process activation is also high enough to pay attention to the sensitivity list: it must contain only the signals that may modify the outputs. VHDL programmers have learnt from software engineering that subprogram inlining is more efficient for simulation [Dav92] (but often less readable!); that conditional structures must be ordered according to execution probabilities; and that loop invariant statements must be factorized. Logic types should be converted to numeric types for faster operations. Scalar variables are also preferable to arrays or records. Much more tips are provided in those papers.
On the other hand, some guidelines handle testbenches a bit more separately [ESA94, ESA96], and WAVES [WAVES] is a standard mostly used for VHDL model verification [Han95, Unk95], although it was not primarily developed for this task.
WAVES, which is a subset of VHDL, is very useful to build portable -between design and test communities- testbenches by using an unambiguous way to represent the stimulus and response information. Moreover, a test set obtained this way can be easily transported to electronic test. Bad simulation efficiency may be the main drawback unless specific tools are used or unless existing tools integrate WAVES in their kernels.
For instance, current synthesis technology presents limitations which make it unable to support full VHDL, and synthesis tools have their own constraints concerning their VHDL entry. Especially, some types are not supported (e.g. files, accesses), as well as other VHDL features like aliases or deferred constants. Packages -[IEEESynth], Synopsys- are developed to guarantee the use of the right types and help the modeller with predefined functions and procedures.
The same happens for verification tools. They are usually unable to handle types other than boolean types. As for WAVES, it provides packages containing code for all the functions, procedures and data types to be used in a WAVES test environment.
Advantages of the object-oriented approach like:
In [Joy91], the usefulness of parameterizing hardware specifications by types and/or by functions is highlighted and an extension of the VHDL generic mechanism is proposed.
VITAL has been adopted as an IEEE standard in 1995 and is now known as VITAL'95 or VITAL3.0 or IEEE 1076.4-1995.
VITAL provides modelling guidelines (specifications) and two acceleratable packages:
Level 1 includes Level 0 and moreover, provides a stricter modelling style, using VITAL acceleratable packages, necessary for developing standard performant libraries. It can be noticed that functionality is separated from timing. Level 1 allows two different styles for propagation delay modelling: pin-to-pin delay and distributed delay. The latter is associated to structural modelling styles.
Some tool vendors announce 10 to 30 times acceleration of VITAL models over VHDL non-VITAL models, but in practice, it seems that 5 to 8 times acceleration is more realistic [Nay95]. A complete VITAL tutorial is available on VITAL Web site [VITAL].
The main sections to which the rules and recommendations are classified concern general principles like:
The section on code layout is oriented towards readability and maintainability: identifiers naming, commenting style, headers for all possible VHDL units, statement layout, etc.
The general VHDL usage section contains rules and recommendations shared by the following two sections on behavioural and RTL modelling. It deals with types to be used -mainly based on the IEEE Standard Logic 1164 for logic types- and other general VHDL issues, like package use, mandatory configuration declarations, use and location of constants, assertion relevance, and clear distinction between qualified expressions and type conversion.
Next section covers abstract behavioural modelling as well as testbench modelling, i.e. it covers in fact non-synthesizable modelling. The main concerns of this section are process partitioning, performance modelling and model portability. For that, some additional requirements on types and on naming conventions are given. Event and signal handling is discussed, and a typical process structure is recommended. Some VHDL features are prohibited or must be avoided: user-defined attributes, guarded blocks, bus and buffer ports, disconnect, next and exit statements.
The section on modelling for an RTL usage is strongly related to synthesis, and sequential synchronous designs are assumed for all rules and recommendations found for this domain. The rules try to be as independent as possible of a particular synthesis tool, since each tool has its own requirements. Once again, rules and recommendations concerning types and naming conventions are added to the ones for a general usage. Especially, it must be noted that aliases, deferred constants, file and access types, and block statements used for hierarchy descriptions, are not supported by synthesis. Many VHDL objects and structural elements are analysed from a synthesis point of view. Specific architecture structures, and process structures within, are required.
The requirements applicable to all kinds of VHDL models are based on the common sense and concern names, comments (including headers), types, files, signals, ports, assertions, subprograms, processes, entities, architectures, component declarations, configurations, packages (IEEE Standard Logic 1164), design libraries... Moreover, it is suggested not to use some VHDL constructs, especially the unusual ones, for the sake of readability and of avoiding tool bugs due to different interpretations. The constructs to be avoided include the guarded expressions, signals and assignments (bus, disconnect, guarded, register); the linkage mode for interface declarations; the buffer mode for the port clause of models' top level entity declarations; VHDL-93 reserved words (group, impure, inertial, literal, postponed, pure, reject, rol, ror, shared, sla, sll, sra, srl, unaffected, xnor); and a few others. Guidelines are added for model verification which must be performed using VHDL testbenches. Finally, two formats for the files organization are suggested for the delivery of models.
The section on component simulation provides guidelines for models used for the verification of the required structure, functionality and timing of a component being designed, before sending it to actual manufacturing. Therefore, these models are on the gate level or on the register transfer level (RTL), and need not be synthesizable. For these models, the emphasis is put on accuracy rather than on simulation speed. The rules found in this section concern again naming conventions, types, and also model interfaces with much use of the IEEE Standard Logic 1164 as well as VITAL Level 0.
At a higher level, board-level simulation is meant by the verification of complete boards containing several components. The internal structure of each component need not be known, since all components are seen from an external point of view. Therefore, the lowest level of description for such component models is the RTL. Here, the emphasis is put on simulation speed. Consequently, all costly VHDL features have to be minimized: processes, signals, resolved signals; and high abstraction level features are recommended like numeric types. Subsections deal with naming conventions, model interface, handling of unknown values, timing (VITAL recommended, and the possibility for the selection of simulation conditions chosen among Worst Case, Typical Case and Best Case), and verification. The document ``VHDL Models for Board-level Simulation'' [ESA96] complements this section. It contains mostly recommendations and useful tips for modelling for board-level simulation, but also for the verification of the developed models. There is also an interesting part on the modelling and verification of full board designs, and finally this additional document specifies requirements on model documentation.
As for system-level simulation, related models are intended to provide the functionality of elements with a simulation speed allowing the performance of trade-offs. Therefore, majority of guidelines applicable to models for board-level simulation are also applicable here.
Last section is about testbenches which are separate VHDL units that are intended for the verification of a developed model or package. A testbench models in fact the environment of a component or package under development. Its root entity shall neither have port nor generic clauses. For maintainability concerns, testbenches must allow automated verification.
At the end of the document, appendices show common errors to avoid, and many VHDL code examples. A non-standard simulation package for the selection of simulation conditions is also provided until an internationally recognized one exists.
EIA-567A introduces the notion of Electronic Data Sheet (EDS). An EDS is a set of 6 VHDL packages: three of them are non-modifiable standard EIA-567A packages, and the other ones are associated design packages. Each pair of packages (a standard one with its associated one) defines a specific view of the component: an electrical view defining pin electrical characteristics, a timing view defining pin timing at a particular operating point, and a physical view defining the physical packaging characteristics of the component.
An additional package, Timing_pack, which is used to implement timing checks and propagation delays, is available but is not part of the EIA-567A standard.
The modelling and simulation conventions provided for the component models include the use of the IEEE Standard Logic 1164 package.
The main characteristic -and advantage- of EIA-567A is to well separate the strictly functional core from the Electronic Data Sheet views. Thus, the functional core can be synthesized many times while the EDS is not modified, which makes technology-independent models, reusable models.
TIREP proposes a methodology to perform this task in a fast and cost-effective way, based on VHDL and other standards in order to obtain paperless design specifications. It has been a joint effort of the Naval Research Laboratory (NRL), the Naval Surface Warfare Center (NSWC), and the Naval Air Warfare Center, Aircraft Division (NAWC-AD).
VHDL was chosen for its portability and its large set of accompanying standards. The ones used as a base of TIREP are:
Some military documents have also been used, like MIL-STD-1389 (Design Requirements for Standard Electronic Modules), MIL-M-28787 (General Specification for Standard Electronic Modules), the Army Handbook (The Documentation of Digital Electronic Systems with VHDL).
The additional modelling conventions provided in the frame of TIREP are recommendations mainly concerning:
The technical solutions of VSI will enable straightforward mixing of required components from different sources (called Intellectual Property providers). At a high level, this standard will define, for instance, IP protection of HL specifications (including ones in VHDL, and Verilog), and/or will propose solutions for on-chip busses, data sheets and instruction-level models. At a low level, it will guarantee among others the conformity of: timing, power, and/or netlists.
A component fulfilling VSI specifications -called then Virtual Component- will have to adhere to multiple Virtual Component Guidelines. Depending on the nature of the component (hardware, software, or firmware) various sets of guidelines will be applicable (system design, logic design, test, etc.). The importance of high-level behavioural models is underlined. Behavioural models will have to be provided in the emerging OMF standard format.
The Open Model Forum's (OMF) charter [OMF, Hob95] is to define an open procedural interface between models and simulators that enables interoperability of models (VHDL, Verilog, ANSI C) across different simulators. Further, it provides legal, and technical solutions (binary code of models is used) for protection of IP. Its relevance for model developers is obvious since it allows mixing of models written in different languages for different simulators. OMF in general, neither imposes any restriction, nor any guideline on the way models are written.
The mission of Electronic Component Information Exchange (ECIX) project (former Pinnacles [PIN, Cot97]) is to provide an information interchange standard enabling the creation of Electronic Databooks. EDBs, an electronic replacement of data books and data sheets indispensable for every engineer, constitute an assembly of information about components including textual data, graphical data used traditionally in databooks and datasheets (e.g.waveforms), and other sorts of data, like behavioural and/or functional models in, e.g. VHDL, Verilog, SPICE, IBIS, special CAD files, and also audio and video. This SGML-based standard will dramatically increase the reusability of technical data by providing component information through on-line services in an immediately processable standardized electronic form. Modeling guidelines are relevant for EDBs, in the sense that models attached to an Electronic Data Book will be written in a standard HDL, using a standardized set of modelling guidelines. Pinnacles does not predefine the guidelines set which should be used.
RASSP (Rapid-prototyping of Application Specific Signal Processors) Programme has made interesting contributions to VHDL modelling. The reader is referred to RASSP page on Web and especially to VHDL Modelling Terminology and Taxonomy document [RASSP].
In the ``standard'' column, we find already approved standards (by standardization organizations or by de facto standard making bodies), and elements which are close to the end of the standardization process (VHDL-AMS).
The ``full VHDL'' column should be in fact understood as ``almost full VHDL'', since we have shown in sections 2.2.2 and 2.3.1 that the concerned guidelines advice not to use some unusual VHDL features. However, these restrictions are not important enough to talk about subsets of VHDL.
[Ash94] A Comparison of Recursive and Repetitive Models of Recursive Hardware Structures - P. Ashenden - proceedings of VIUF Spring'94 Conf. - Oakland, CA - May 1-4, 1994
[Beo96] Participation in the definition of Needs & Requirements and Analysis of existing proposals in the definition of Object Oriented Extensions to VHDL, Ver. 1.0 - P. Beolet, J.-M. Bergé, A. M. Tagant, C. Le Maire - Report of the WG on Object-oriented Extensions to VHDL, gopher://gopher.vhdl.org:70/1/vi/oovhdl/rqmts-v1.0
[Ber] Guidelines for Writing VHDL Models in a Team Environment - J. Bergeron, http://rassp.scra.org/vhdl/guidelines.html
[Bil91] Interoperability of VHDL Models - W. Billowitch - Proc. EURO-VHDL'91 - Stockholm, S - Sept. 8-11, 1991
[Blü92] A Methodology for the Development of High Quality Standard-Cell Models in VHDL - M. Blüml, B. Kierdorf, M. Lenzen, A. Pawlak - Proc. VHDL-Forum, Spring'92 - Santander, Spain - April 1992
[Cab95] Object-Orientation Applied to VHDL Descriptions - D. Cabanis, S. Medhat - Proc. VIUF Spring'95 - San Diego, CA - April 2-6, 1995
[Ced94] VHDL Board-Level Modeling to Expedite Redesign - L. J. Ceder, Ch. Rogers, L. Kitcoff, D. Broadhead, L. Skidmore, J. Miles, G. Hout, E. Woods, D. York, P. Everitt - Proc. ASNE Conference 1994, http://kraken.nwscc.sea06.navy.mil/Tirep/Papers/1/Asne94.htm
[CEN97] VHDL Modelling Guidelines - Simulation and Documentation Aspects - CENELEC TC217/WG2 Report 2.14, 2nd draft - Feb. 23, 1997, ftp://ftp.estec.esa.nl:/pub/vhdl/tmp/cenelec2.14.ps.gz
[Coh95] VHDL Coding Styles and Methodologies... an In-Depth Tutorial - B. Cohen - Kluwer Academic Publ. - 1995, http://rassp.scra.org/vhdl/models/other/errinj.vhd
[Cot97] ECIX - Electronic Component Information Exchange - Don Cottrell - these Proceedings, http://www.si2.org/ecix/
[Cyp95] Practical State Machine Design Using VHDL - Applications Staff, Cypress Semiconductor Corp. - Integrated System Design magazine - Feb. 1995
[Dav92] Subprogram Inlining: A Study of its Effects on Program Execution Time - J. W. Davidson, A. M. Holler - IEEE Trans. on Software Engineering, vol. 18, #2 - Feb. 1992
[Deb93] Synchronous Designs in VHDL - A. Debreil, Ph. Oddo - Proc. EURO-VHDL'93 - Hamburg, Germany- Sept. 20-24, 1993
[DID] DI-EGDS-80811 VHSIC Hardware Description Language (VHDL) Documentation - Department of Defense - Washington, DC - May 11, 1989,http://www.vhdl.org/vi/vug_bbs/rbbs/DID11MAY.TXT
[Dub91] Standard Component Modeling in VHDL - J-L. Dubois, F. Liu, A. Pawlak - Proc. ASIM'91 - Hagen, Germany - Sept. 1991
[Dun94] Object-Oriented Extensions to VHDL - D. Dunlop - Proc. VIUF Fall 1994 Conf. - McLean, VA - Nov. 13-16, 1994
[EIA] EIA-567A. VHDL Hardware Component Modeling and Interface Standard - Electronic Industries Association - Washington, DC - Aug. 1994,http://www.fp.fmv.se/vhdl/vhdl.html
[Ele94] Synthesis of VHDL Concurrent Processes - P. Eles, K. Kuchcinski, Z. Peng, M. Minea - Proc. EURO-VHDL'94 - Grenoble, France - Sept. 19-23, 1994
[ESA94] VHDL Modelling Guidelines - P. Sinander - ESA/ESTEC Report ASIC/001 - Sept. 1994, ftp://ftp.estec.esa.nl/pub/vhdl/doc/ModelGuide.ps
[ESA96] VHDL Models for Board-level Simulation - S. Habinc - ESA/ESTEC Report WSM/SH/010 - Feb. 1996, ftp://ftp.estec.esa.nl/pub/vhdl/doc/BoardLevel.ps
[Gsc96] A VHDL Design Methodology for FPGA Efficiency - M. Gschwind, V. Salapura - Proc. ED&TC'96 - Paris, France - March 1996
[Han95] Using WAVES for VHDL Model Verification - J. P. Hanna - Proc. VIUF Spring'95 - San Diego, CA - April 2-6, 1995
[Hob95] Model Availability, Portability and Accuracy, An IC Vendor's Perspective, Efforts and Vision for the Future - W. Hobbs - Workshop on Libraries, Component Modeling and Quality Assurance - Nantes, F - April 26-27, 1995, http://si2.org/OMF/mapa.htm
[Hue91] VHDL Experiments on Performance - M. Hueber, S. Lasserre, A. de Monteville - Proc. EURO-VHDL'91 - Stockholm, Sweden - Sept. 8-11, 1991
[IEEESLP] IEEE Std 1164-1991. IEEE Standard Logic Package - The Institute of Electrical and Electronic Engineers - New Yrok, NY - Oct. 1991,http://www.vhdl.org/libutil/utilities/gen_functions/IEEE1164
[IEEESynth] IEEE Std 1076.3-1996. IEEE Standard VHDL Synthesis Packages - The Institute of Electrical and Electronic Engineers - New York, NY - 1996, http://www.vhdl.org/vhdlsynth/vhdlsynth.html
[Joy91] Fully generic description of hardware in VHDL - J.J. Joyce, J. P. Van Tassel - Proc. CHDL'91 - Marseille, France - April 22-24, 1991
[Lev91] Writing High Performance VHDL Models - O. Levia - Proc. EURO-VHDL'91 - Stockholm, Sweden - Sept. 8-11, 1991
[Liu91] Timing Constraint Checks in VHDL - a comparative study - F. Liu, A. Pawlak - Proc. EURO-VHDL'91 - Stockholm, Sweden - Sept. 8-11, 1991
[Mad96] VHDL Simulations - Tips for Speeding - V. Madisetti, http://rassp.scra.org/public/tb/gt/vhdl-tips.txt
[Mas95] Static Analysis of VHDL Code: Simulation Efficiency and Complexity - M. Mastretti, M. Sturlesi, S. Tomasello - Proc. VIUF Spring'95 Conf. - San Diego, CA - April 2-6, 1995
[Mil93] Proposed Object Oriented Programming (OOP) Enhancements to the Very High Speed Integrated Circuits (VHSIC) Description Language (VHDL) - M. Mills - Report WL-TR-93-5025, Wright Laboratory - Aug. 1993
[Nay95] Issues in Efficient Modeling and Acceleration of VITAL Models - S. Nayak, A. Roy - Proc. Workshop on Libraries, Component Modelling, and Quality Assurance - Nantes, France - April 26-27, 1995
[OMF] Open Model Interface, Draft Ver. 0.3 - Open Model Forum Techn. Team - June 1995, http://www.si2.org/OMF
[OMI] OMI 326: VHDL Coding Standard - H. Sahm, C. Mayer, S. Späth, J. Pleickhardt - OMI Report, Rev A-0-7 - Jul. 1995, http://www.omimo.be/public/data/_indstan.htm#OMI326
[PIN] Pinnacles Component Information Standard 12, PCIS Tutorial - Pinnacles Group - Nov. 1995, http://www.si2.org./ecix/conference_fodder/toledo/
[Pir96] Analysis of Different Protocol Description Styles in VHDL for High-Level Synthesis - L. Pirmez, M. Rahmouni, P. Kission, A. Pedroza, A. Mesquita, A. Jerraya - Proc. EUROVHDL'96 - Geneva, CH - Sept. 16-20, 1996
[Ram93] Synthesis of Functions and Procedures in Behavioral VHDL - L. Ramachandran, S. Narayan, F. Vahid, D. D. Gajski - Proc. EURO-VHDL'93 - Hamburg, Germany - Sept. 20-24, 1993
[Ram94] Object Orienting VHDL for Component Modeling - C. R. Ramesh - Proc. VIUF Fall 1994 Conference - McLean, VA - Nov. 13-16, 1994
[RASSP] http://rassp.scra.org/documents/taxonomy/taxonomy.html
[Ros94] Performance Modeling with VHDL - F. Rose, T. Steeves, T. Carpenter - Proc. 1st Annual RASSP Conf. - Arlington, VA - Aug. 1994, http://rassp.scra.org/
[Sch96] Applying Object-oriented Techniques to Hardware Modelling - A case Study - G. Schumacher, W. Nebel, W. Putzke, M. Wilmes - Proc. VHDL User Forum Europe, Sig-VHDL Spring'96 Working Conference - Dresden, Germany - May 5-8, 1996
[Tic85] RCS - A system for version control - F. W. Tichy - Software Practice & Experience, Vol. 15 - Jul. 1985
[TIREP] A VHDL Modeling Guide - Technical Report of the TIREP project - Naval Research Laboratory (NRL), the Naval Surface Warfare Center (NSWC) and the Naval Air Warfare Center, Aircraft Division (NAWC-AD) - May 1994, http://kraken.nwscc.sea06.navy.mil/Tirep/Guide.htm
[Unk95] Development of a WAVES Compatible Testbench for Board-Level Test - C. R. Unkle, W. G. Swavely, J. Nagy - Proc. VIUF Spring'95 - San Diego, CA - April 2-6, 1995
[VHDL] IEEE Std 1076-1987 (-1993). IEEE Standard VHDL Language Reference Manual - The Institute of Electrical and Electronic Engineers - New York, NY - 1988 (1994)
[VHDLA] VHDL-AMS: Analog and Mixed Signal Extensions for VHDL - Language proposal - IEEE DASC 1076.1 WG, http://vhdl.org/vi/analog/wwwpages/home.html
[Vil95] Level-0 VHDL Synthesis Syntax and Semantics - E. Villar - Techn. Rep. ESPRIT 8370 ESIP Proj. - Dec. 1995, http://vhdl.vhdl.org/vi/pub/vhdlsynth/siwg
[Vis] OO-VHDL Language Reference - Vista Technologies - RASSP Technical Report, TR-1.2.11.1.3-01
[VITAL] IEEE 1076.4. Std VITAL ASIC Modeling Specification - The Institute of Electrical and Electronic Engineers - New York, NY - 1995 - http://vhdl.vhdl.org/vi/vital/ - Tutorial, http://vhdl.vhdl.org/vi/vital/wwwpages/steves/
[Vos95] The Analysis of Modeling Styles for System Level VHDL Simulations - A. P. Voss, R. H. Klenke, J. H. Aylor - Proc. VIUF Fall'95 Conf. - Boston, MA - Oct. 15-18, 1995
[VSI] http://www.vsi.org/
[WAVES] IEEE Std 1029.1-1991. Waveform and Vector Exchange Specification - IEEE Design Automation Standards Subcommittee - New York, NY - 1991, http://www.vhdl.org/vi/waves/
[Wil94] A Proposal for Minimally Extending VHDL to Achieve Data Encapsulation, Late Binding and Multiple Inheritance - J. C. Willis, R. Newshutz, S. A. Bailey - Proc. VIUF Fall 1994 Conf. - McLean, VA - Nov. 13-16, 1994
[Zin90] Modeling Techniques - R. Zinszner - Proc. EURO-VHDL'90 - Marseille, France - 1990
[Zip92] An Object-Oriented Extension of VHDL - R. Zippelius, K. D. Muller-Glaser - Proc. VHDL Forum for Europe, Spring 1992 - Santander, Spain - April 26-28, 1992