Version 4.0 of the VHSIC Hardware Design Language was approved by Accellera and passed to the IEEE to begin its formal standards balloting process earlier this year.
The article previews some of the key additions and extensions that form part of VHDL in the following areas:
- Property Specification Language
- Intellectual Property Protection
- Hierarchical names
- Extensions to generics
- Fixed and floating point support
- Productivity enhancements
Among the ‘edgy’ questions pitched to John Cooley for his annual Troublemaker’s Panel at DVCon was one aimed specifically at Accellera vice-chair Dennis Brophy: “Is VHDL dead?” It made me smile. Since July 2005, I have chaired the VHDL Technical Subcommittee (TSC) that has been quietly and diligently working on extensions to VHDL 1076. Indeed, a further irony behind the timing of the question was that DVCon would indeed provide a clear answer. We used the show to announce that Accellera had just approved VHDL 4.0 and was transferring it to the IEEE to begin its balloting process.
So without further ado, let’s look at what is new in this Mark Twain of standards—certainly, reports—or, if you prefer the alternative misquotation, rumors—of its demise have been greatly exaggerated.
Property Specification Language
Property Specification Language (PSL) has been integrated into VHDL 4.0. Rather than redefine the simple subset of PSL, the VHDL TSC chose to incorporate that syntax by reference to IEEE Standard 1850-2005. VHDL 4.0 shows users where PSL declarations and statements may be applied and points them to the PSL documentation.
PSL directives are considered concurrent statements so they may appear in VHDL concurrent regions. PSL property and sequence declarations can be placed in various VHDL declarative regions.
In addition, the PSL verification unit (vunit) is considered a design unit in VHDL and may be compiled just like an entity or architecture. By allowing the use of vunits or incorporating PSL inline, VHDL 4.0 thus gives users a flexible way to apply properties in their design methodologies.
Intellectual Property Protection
Intellectual Property (IP) Protection leverages a donation from Cadence Design Systems that has also been shared with the Verilog standards group.
The VHDL TSC standardized a rich set of tool directives that specify what to protect and how. Using these mechanisms, an IP provider specifies the region to be protected and uses a compliant tool to encrypt and encode it.
The IP provider can deliver ciphered source code to the IP user. A simple example would be to protect the architecture while leaving the entity visible. This would permit the IP user to see the interface, and therefore, how to connect to the design, but not the implementation.
The IP user can ‘compile’ the ciphered source using a compliant tool which decodes, decrypts, and, most importantly, hides the protected region. Thus the user can still see the behavior of the interface, but not the behavior of any internal signals. A greatly simplified view of this is shown in Figure 1. Envelopes, digests, view ports and other directives add to the available protection mechanisms.
Figure 1. Below 180nm, systematic feature-related yield loss becomes a critical issue. Source: Accellera
The VHDL TSC chose not to standardize a single protection protocol, but to allow the market to determine how sophisticated a protocol should be for any IP provider/tool vendor/IP user relationship. However, VHDL 4.0 does provide an informative section on various ways to apply those mechanisms to ensure a good quality protection scheme.
VHDL 4.0 introduces ‘external’ names to support PSL and address requirements common to testbenches that require access to information not available on the interface of the design such as internal signals. These external or hierarchical names are used like any other signal, variable, or constant name in VHDL. They are identified by surrounding the object’s class, pathname, and type by double angle brackets. For example:
<<signal .over.the.rainbow.bluebird :
bit_vector(0 to 3)>>
The pathname may be relative or absolute. VHDL compilers will accept the name and the name will be checked for existence when the design is elaborated.
Extensions to generics
VHDL 4.0 extends generics to packages and subprograms to further facilitate code reuse.
Packages and subprograms can now be written in a more abstract form with generics being used to tailor their behavior. When the generic package or subprogram is ‘instantiated,’ the generics provide the specific information to generate a particular behavior.
Also, two new kinds of generics have been introduced called ‘type’ and ‘subprogram’ to allow more flexibility in creating abstract specifications. This addition allows the user to pass a type name or a subprogram name into some VHDL as a parameter.
Fixed and floating point support
VHDL 4.0 adds standard packages for fixed and floating point support, and they are the first to leverage generic packages. The packages ‘fixed_pkg’ and ‘float_pkg’ are instances of the generic packages ‘fixed_generic_pkg’ and ‘float_generic_pkg’.
Fixed_pkg defines the types ‘u_fixed’ and ‘s_fixed’ that represent unsigned and signed fixed numbers.
The package also defines logical and arithmetic operators and various subprograms to process those types. A vector for a fixed point number uses a ‘downto’ range with a positive upper bound and a negative lower bound. The elements from the upper bound down to 0 represent the integer portion of the number while elements from -1 down to the lower bound hold the fractional portion of the number. Signed numbers are represented in two’s complement form. For example:
signal d : u_fixed(5 downto -3);
— an unsigned fixed number
has the shape
Similarly, float_pkg defines the type ‘float’ to represent floating point numbers. Like fixed_pkg, float_pkg defines logical and arithmetic operators and various subprograms to process objects of type float.
Float_pkg then goes a step further, implementing the algorithms for the logical and arithmetic operators according to IEEE standards 754 and 854.
Again, a vector for a floating point value uses a ‘downto’ range with a positive upper bound and a negative lower bound. The mantissa is stored in a sign/magnitude format with the sign in the left most bit and the mantissa in the right (negative indices) part of the vector. The exponent is stored in the bits in between. For example:
signal f : float(5 downto -7)
has the shape
S EEEEE MMMMMMM
The IEEE standards 754 and 854 define how to interpret the vector.
VHDL 4.0 adds the construct ‘process (all)’ to address a simulation/synthesis mismatch risk. Many synthesis tools assume that all the signals referenced by a ‘combinational’ process appear in the process sensitivity list. However, it was possible for a sensitivity list to be incomplete and exhibit a different behavior in simulation than the gate level synthesis result would indicate.
To allow a user to easily manage the synthesis requirement that the sensitivity list be ‘complete’, VHDL 4.0 permits the keyword ‘all’ in a process sensitivity list. In short, this means that every signal read by that process appears in the sensitivity list.
All of the logical operators now have a unary form in VHDL 4.0. For example, if ‘data’ is a bit_vector, the expression ‘and data’ will perform the ‘and’ function on the bits of data returning a ‘1’ if all of the elements of data are a ‘1’.
In addition, all of the dyadic logical operators have an array/scalar form. That is, one operand may be a one-dimensional array while the other operand is a scalar. The expression ‘enable and data’ will return the value of data when enable is a ‘1’ and a vector of ‘0’s if enable is a ‘0’.
VHDL 4.0 adds a condition operator (‘??’) and a set of ‘matching’ relational operators. The condition operator is a unary operator that returns ‘true’ or ‘false’ depending on the value of the operand. For example, a ‘std_logic’ operand that has the value ‘1’ or ‘H’ will return true. Furthermore, the condition operator is applied where the syntax requires a Boolean expression. This makes conditions easier to write permitting statements like:
if a and b and c then
if a = ‘1’ and b = ‘1’ and c = ‘1’ then
The matching relational operators provide a measure of ‘don’t care’ processing. In particular, the ‘?=’ operator can be used to compare std_logic_vectors that may contain ‘-’ values. So, if a vector ‘d’ has the value ‘0100’ and appears in the expression
d ?= 0—
the expression will return true.
Case statements and selected signal assignments are similarly enhanced. By putting the ‘?’ symbol after the keywords ‘case’ and ‘select’, the matching equivalence operator is used to compare the case expression with each of the case choices. For example, a matching case statement looks like this:
case? ctl is
when “1—”=> z <= a and b;
when “01–”=> z <= a or b;
when “001-”=> z <= a xor b;
when “0000” => z <= not a;
when others <= ‘X’;
Those are only a few of the updates that VHDL 4.0 brings to the table. There are also new routines for text input and output, extensions to bit string literals, the ability to use expressions in port maps, the ability to read out mode ports, new ways of specifying unconstrained arrays, and so on.
VHDL 4.0 has been delivered by Accellera so that the next step is to take VHDL 4.0 through the IEEE ballot process. Accellera has already committed funds to support the editor retained by the VHDL TSC for the editorial work required by the process. In addition, the VHDL TSC will participate in any negative ballot resolutions required. By the time this article appears, the first round of balloting may be well under way.
Looking forward, what should VHDL 5.0 contain? We could go to our backlog of 137 requirements that we still have. Among the items on that list are interfaces, object orientation and interoperability. We could also solicit new input from VHDL users.
But the bottom line is that the VHDL TSC is a member-funded organization and will go where the members’ funds take us. It is not enough for a single user to say “I want.” We have managed to strike a balance between individual technical contributions, the principle of unanimous consent, and entity-based dispute resolution to move the language forward.
Where we go from here is up to you.
1370 Trancas Street #163
T: 1 707 251 9977