Status Quo and Moving Forward with Bundles

Ernst Christen, Mentor Graphics

The Status Quo

Since its first version in 1987, VHDL has supported design entities with ports declared as signals. Technically these formal ports are known as interface signals, and their collection is declared in what is called a port list. In the nearly 30 years since this first release, two extensions have been made to the original design:

• In its first release in 1999, VHDL-AMS extended the port list to also include interface quantities and interface terminals.
• In the 2008 revision, the VHDL port list was enhanced in two ways, both of which will be adopted by VHDL-AMS in its current revision:
  • Support for generic types for ports, i.e. design entities whose port types are not known at analysis time; their definition is part of the instantiation of the design entity.
  • Support for partially constrained types. The index range of an unconstrained dimension is determined during elaboration in the same way it’s been done for unconstrained arrays.

Since before the year 2000 several ideas have been presented to improve the management of port lists. In many cases the presentation consists of a proposal for new syntax to be added to the language, illustrated by one or two examples. What is frequently missing is a description of the problem that is being addressed, from which requirements can be derived. Currently there are about 10 such proposals, so there is no surprise that there are overlaps and conflicts between the different syntax extensions. It is therefore necessary to look for common ground and build on it to design something new that addresses the problems designers and verification engineers are facing today.

Problem Analysis

Based on my reading of the different proposals, the problem to be solved seems to present itself as follows.

Complex designs consist of design entities with large port lists. Working with these design entities is tedious and error prone because the engineer is required to repeat the members of a port list over and over again: in the entity declaration, in a component declaration, in each instantiation statement for the design entity, in configuration declarations, and for the actual declaration of the signals at the root of each net. It’s tedious because of the repetitive work, and error prone because of managing the port associations and the corresponding modes in many places.

To get some relief, designers have attempted to use record types to bundle several ports into one. This functional perspective of the interface between components (instead of the implementation perspective that enumerates each signal) has the benefit of reducing the repetition, but according to the VHDL definitions it suffers from two problems, based on the fact that each of these functional views has to be declared as a signal of the chosen record type:

• All elements of the record signal must have the same mode
• A driver for an element of the record signal in one design entity makes the whole record signal a source in the instantiating design unit. If some subelement of the record signal is driven elsewhere, the record type must be a resolved type. Before the 2008 revision of VHDL this required the definition of a resolution function for the record type. The 2008 revision of VHDL brought some relief as it supports the definition of resolution functions at the level of the elements of a composite type, but the use of this facility gets complicated very quickly.

In particular the requirement that all elements of a record signal (more generally, a composite signal) must have the same mode has limited this approach because it doesn’t allow a designer to manage ports entirely from a functional perspective; it is necessary to partition a functional bundle based on the modes at a port, and this partitioning has to be done differently for different port lists. We conclude that using signals of a record type to manage interface bundles is inadequate with the current semantics of VHDL

Additional interest has been expressed in in some proposals, in particular those coming from the OO side, to encapsulate behavior at an interface. Discussions in the Working Group have indicated that this aspect has lower priority than managing interface bundles.

Proposed Ideas

The different proposals have been enumerated and summarized in a number of places already. Here I would like to present the ideas expressed in each proposal, as I understand them, in three categories. Each seems to address part of the larger problem, but none is complete.

Bundling Ports

Every single proposal deals with the bundling aspect for ports, either explicitly by proposing some syntax and/or semantics, or by implicitly assuming a particular approach for the bundling to occur. There are two main ideas:

• Using a signal of a record type to describe a bundle. The elements of a bundle have a type and possibly a mode. The bundle is declared as a signal of this record type, which implies that all elements of the bundle are signals themselves. In other words, the bundle is homogeneous. Most proposals are based on this approach, either explicitly or implicitly.
• Creating a new concept, similar to a SystemVerilog interface, to describe a bundle. The declaration of the elements of a bundle includes their object class, making a bundle heterogeneous. This approach is proposed initially in IR2067 - Logical link interface abstraction and extended in Interfaces: Heterogeneous Interfaces in VHDL.

It has been pointed out that supporting objects of different kinds in a bundle (shared variables for VHDL, quantities and terminals for VHDL-AMS) requires heterogeneous bundles.

Managing Modes

It is useful here to distinguish between the problem space and the space of proposed solutions. I believe the different proposals address three main issues related to modes:

• The elements of a bundle should be able to have different modes, but the declaration of a signal port in VHDL today only allows a single mode to be declared for the bundle. This issue is the main thrust of Interfaces: Records with Directional Subtypes.
• It should be possible to resolve the elements of a bundle individually, but the fact remains that in VHDL a composite signal is a single source. This issue is prominent in the following proposals: Interface Construct and Port Mode Configurations, Simple Record Form of Bundle Usage, Interfaces: Add "Bus" mode for bidirectional port signals.
• Syntactic shorthands to quickly derive a bundle with one collection of modes from an existing bundle, e.g. a complement. Related proposals are: Interfaces: Attributes for Interfaces.

The solution side can be divided into two categories:

• Static modes. These modes are explicitly declared and are known at analysis time of a design entity. Besides the currently available modes in, out, inout, buffer, linkage, new modes proposed to address the resolution aspects may also be present.Static modes are included in most proposals.
• Dynamic modes. The idea is to declare a collection of symbolic modes that are intended to be logically complementary. The actual mode of a port is determined during elaboration based on drivers and receivers on the net. The following proposals include dynamic modes: Interfaces: Add "Bus" mode for bidirectional port signals, Options for using generics with Bundles.

Behavior at an Interface

This aspect has been touched upon in the different proposals based on extending VHDL with OO functionality. (They need to be listed)

Proposal to Move Forward

I believe to move forward we have to extract the basic ideas expressed in the different proposals and leave the syntax behind. We then have to reconcile these ideas into a collection of requirements that complement the requirements list we already have. After we have an agreement on what the requirements truly are we can move ahead and explore the solution space, which is bounded by some basic principles in VHDL that are hard to change, such as visibility rules, strong typing, and more.

Some preliminary work has been done:

• An overview of SystemVerilog Interfaces, driven by the suggestion that the VHDL capability be aligned with that functionality to facilitate implementation and interoperability between languages.
• A preliminary analysis of the issues arising from extending VHDL with the concept of a bundle.
• A preliminary attempt at extracting the basic ideas of the different proposals to identify the problem space. This is the section on Proposed Ideas above.

I propose the following steps to move forward:

1. Complete the description of the problem space.by extracting from each proposal what problem it is trying to solve
2. Derive a comprehensive set of requirements that address the issues identified in the problem space
3. Work towards a bundle concept that addresses the requirements.

-- ErnstChristen - 2015-07-09