Class types are a foundation feature for both data structures and randomization. Briefly, a class type encapsulates data and provides operations, called methods, to access and update the data. An object is an instance of a class type. A subclass can inherit data and operations from a superclass, and in doing so, can override the implementation of inherited operations. References to objects can be polymorphic, meaning that they can refer to an object of a nominated class or of any subclass. When a method is invoked via a polymorphic reference, the overriding method of the referenced object’s specific class is executed. This is referred to as dynamic dispatch.

The object-oriented features under development involve basing class type on protected types, since the latter already provide encapsulation of data and methods. We can view a protected type as a class type without inheritance or dynamic dispatch. A side benefit of this approach is that it simplifies the prototyping of data structures and communication protocols using the existing language. For example, if we are to use object-oriented features for verification, we need to implement a number of data structures, including lists, FIFOs, mailboxes, transaction interfaces, scoreboards, and memories. We can already build many of these data structures using protected types. However, the class extension increases their parameterizability, and hence, reusability.

type BoundedFIFO  is protected class
  procedure put ( e : in  element_type );  --  methods
  procedure get ( e : out element_type );
end protected class BoundedFIFO;

type BoundedFIFO is protected class body

  constant size : positive := 20;
  type element_array is array (0 to size-1) of element_type;

  variable elements : element_array;
  variable head, tail : natural range 0 to size-1 := 0;
  variable count : natural range 0 to size := 0;

  procedure put ( e : in element_type ) is
  begin

     if count = size then wait until count > size; end if ;
     elements(head) := e;
     head := (head + 1) mod size; count := count + 1;
  end procedure put;

  procedure get ( e : out element_type ) is . . .

end protected class body BoundedFIFO;

Among the other features included in the class proposal, beyond the basic object-oriented features, is provision for objects of class types to be included as subprogram parameters and ports of components and entities. Moreover, the proposal adopts Java-like interface definitions and multiple inheritance. An interface (as in the Java sense) specifies methods that a class must implement. A given class may implement more than one interface, as well as inheriting from a superclass. The interface feature provides a very powerful abstraction mechanism, as the following example illustrates.

type putable is interface
  procedure put (e : in element_type) ;
  procedure try_put (e : in element_type; ok : out boolean);
end interface putable;

type getable is interface
  procedure get (e : out element_type);
  procedure try_get (e : out element_type; ok : out boolean);
end interface getable;

type mailboxPCType is protected class implements putable, getable
   impure function flag_up return boolean;
   procedure put(e : in element_type);
   procedure try_put (e : in element_type; ok : out boolean);
   procedure get     (e : out element_type);
   procedure try_get (e : out element_type; ok : out boolean);
end protected class mailboxPCType;

entity tlm  is
end entity tlm;

architecture structural of tlm is

  component producer is
     port ( shared variable data_source : inout putable );
  end component producer;
  component consumer is
     port ( shared variable data_sink : inout getable );
  end component consumer;

  shared variable MailBox : mailboxPCType;

begin

  u_producer : producer port map ( data_source => MailBox );
  u_consumer : consumer port map ( data_sink   => MailBox );

end architecture tlm;

One problem in verifying a design with a large verification space and numerous configurable features is how to write enough test cases to adequately test all of the features. For some designs, using the algorithmic features of the VHDL is sufficient to generate the test cases. For other designs, randomization is more appropriate. The randomization proposal under consideration by the VHDL-TC introduces three forms of randomization: basic randomization, class-based randomization, and procedural randomization. These features are similar to those of SystemVerilog; however, their syntax is consistent with other VHDL constructs.

The intent of basic randomization is to provide individual random values. Basic randomization is implemented in a predefined class providing function methods RandReal, Randlnt, RandSlv, RandUnsigned, and RandSigned. Since these functions are encapsulated in a class, the seed is also stored in the class and does not need to be passed as a parameter in a procedure call. Each of the functions has parameters that allow the result to be scaled to a particular range of values.

In class-based randomization, related objects are included as data members of a class. Within the class, relationships are written between the class members. During randomization (using a built-in method), class members are randomized taking these relationships into account. In this manner, meaningful values can be generated to specify a transaction or a sequence of transactions.

type TxPacketCType is class

  rand variable BurstLen   : integer;  -- Public Variables
  rand variable BurstDelay : integer;

  constraint BurstPkt is (
     BurstLen in (1 to 10);
     BurstDelay in (1 to 6) when BurstLen <= 3 else
     BurstDelay in (3 to 10);
  );
end class TxPacketCType;

TxProc : process
  variable TxPacket : TxPacketCTType;
  variable RV : Randclass;
begin
  . . .
  TxOuterLoop: loop

    TxPacket.randomize;

    for i in 1 to TxPacket.BurstLen loop
       DataSent := RV.RandSlv(0, 255, DataSent'length);
       Scoreboard.PutExpectedData(DataSent);
       WriteToFifo(DataSent);
    end loop ;

    wait for TxPacket.BurstDelay * tperiod_Clk - tpd;
    wait until Clk = '1';

  end loop TxOuterLoop;
  . . .
end process TxProc;

Procedural randomization is a proposed enhancement to VHDL’s sequential constructs. A RandCase feature provides random choice among statements, and a sequence feature allows randomly or deterministically ordered sequences of statements to be executed.

I0  := 1; I1 := 1; I2 := 1;
for i in 1 to 3 loop

  randcase is
     with I0 =>
        CpuWrite(CpuRec, DMA_WORD_COUNT, DmaWcIn);
        I0 := 0; -- modify weight

     with I1  =>
        CpuWrite(CpuRec, DMA_ADDR_HI, DmaAddrHiIn);
        I1 := 0; --  modify weight

     with I2   =>
        CpuWrite(CpuRec, DMA_ADDR_LO,  DmaAddrLoIn);
        I2 := 0; -- modify weight

  end randcase ;

end loop;
CpuWrite(CpuRec, DMA_CTRL, START_DMA  or DmaCycle);

Functional coverage is intended to supplement other forms of coverage. Tool based code coverage provides information about what parts of a design are exercised during a simulation. However, it cannot test whether an aspect of the specification for the design is actually implemented. Functional coverage features, on the other hand, allow us to measure the occurrence of difference categories of data values during a simulation. We can thus determine whether processing of categories of interest has been exercised. To measure functional coverage, we specify a bin (a value or range of values) for each category of a data object. During simulation, for each bin, the tool records the number of transactions that produce values in the bin. We can analyze the result to identify bins for which no transactions occurred, and adjust our stimulus generation or randomization constraints accordingly.

The VHDL-TC plans to incorporate functional coverage features into a future extension of VHDL. The details of language features are yet to be determined.

One question that comes up frequently is, why update VHDL? Instead, why not adopt SystemVerilog as the verification language? The answer is much simpler than one would expect. From a language perspective, VHDL already includes many system-level modeling features, such as records, access types (pointers), and protected types. Many of these features can be enhanced with relatively little impact on the language, and new features can be added in a way that integrates cleanly with existing features. From a project perspective, organizations using VHDL already have significant experience using the language. If a verification engineer is needed for a project, the organization has a pool of people familiar with VHDL. A person from that pool can build on their existing knowledge of VHDL, provided the language includes the necessary verification features. If they were to adopt SystemVerilog, they would not only have to learn a language that is quite idiomatically different, but they would also have to manage a multilingual design/verification environment. Both of these issues would adversely affect their productivity.

Standards development is a volunteer-run effort, and depends on your participation. As you become an experienced VHDL design and/or verification engineer, it is both your right and responsibility to participate. You can participate by submitting enhancement requests, participating in the standards groups, helping with funding, and helping with vendor support.

One person can make a difference. No matter how hard the VHDL-TC works, without your ideas, the group may overlook the changes you desire. You can submit your enhancement requests using the web page at http://www.eda.org/vasg.

VHDL standards are co-developed by IEEE and Accellera. Currently most of the new technical development is done by the Accellera VHDL-TC. The IEEE VHDL Analysis and Standardization Group (VASG) resolves issues with the current IEEE VHDL standard and conducts balloting for new IEEE versions of the standard. For more information about the Accellera VHDL-TC, see http://www.accellera.org/vhdl, and for more information about the IEEE VASG, see http://www.eda.org/vasg.

Volunteers run these standards groups, and members tend to work on what interests them personally. For a request to become a proposal and then a language feature, someone has to champion it. The best way to make this happen is to participate. Participation is open to anyone who has the background and is willing to invest the time. You can join the technical subcommittees, participate in email reflectors, attend teleconferences, attend in-person meetings, and actively participate in all discussions. Most technical decisions are held at a level where everyone can contribute. When decisions have conflicting choices, the issue is put to a member vote. To have a member vote in the Accellera VHDL-TC, your company must join Accellera. To have a member vote in the IEEE VASG, you need to join the parent group, IEEE Design Automation Standards Committee (DASC, see http://www.dasc.org) and maintain an active history of voting participation.

While much of the work is volunteer based, the task of integrating the language change proposals and editing the standard is a time-intensive task and is undertaken by a paid technical editor. This person is a VHDL expert with deep language design knowledge. Currently, this position is funded through Accellera. If your company is able, please encourage them to become an Accellera member and help fund future revisions of the VHDL standard.

Finally, ongoing evolution of VHDL requires vendor support. Part of achieving this is to understand why vendors implement standards. For an EDA vendor, supporting a standard is a business decision. In general, this means they support the features their customers request. Hence, you can influence the process by learning the new features and making the vendors aware of the ones that are important to you. The person with the most power is the person who funds your tool licenses. Make sure they are aware of what you need and make sure to forward your requests through them.