P1076 Web>Vhdl2019CollectedRequirements>MultipleDesignHierarchies (2020-02-17, JimLewis)EditAttach

Multiple Design Hierarchies

Multiple Design Hierarchies

Proposal Details

Discussed on: 2016_MeetingJune2
- Need clear explanation of use model and someone to work on it.
Who Updates:main.CliffordWalinsky
Date Proposed:2014-06-25
Date Last Updated:2014-06-25
Priority:
Complexity:
Focus:

Current Situation

With the ability to describe external objects, it is now possible to create designs with multiple hierarchical design roots. We can refer to these designs as multi-hierarchies. They are a set of disjoint trees of design elements. The most obvious application for use of multi-hierarchies is for creation of entities that monitor the activities of designs under test. Without this new facility, it is necessary to create a single new entity that encompasses the entire design, with an architecture declaration that instantiates both the design under test and the monitor. This proposal effectively eliminates the need to create this additional entity.

Requirement

Currently, the LRM describes elaboration as an algorithmic process that proceeds from the root of a design hierarchy downward toward leaf elements. It will be necessary to revise the LRM to refer to multi-hierarchies whereever there is a reference to the design hierarchy. Elaboration will proceed in some well-defined order (most convenient would be left-to-right) through the set of hierarchies comprising the multi-hierarchy.

Implementation details

A multi-hierarchy has been described as a set of design hierarchies. Most commonly, we anticipate that there will be a hierarchy rooted at a design under test ( dut) and a monitor. Extending this idea, it may be that a designer will wish to monitor and compare the activities of several architectural variants of dut. For example, the beh architecture of dut would be a behavioral/RTL description, while the str architecture of dut would constitute a structural description. The multi-hierarchy of the full design would need to be specified as dut( beh), dut( str), monitor. Within monitor, external references to the two architectures of dut need to be differentiated by architecture. Unfortunately, the current syntax of external references does not permit this kind of differentiation. Without an extension to the syntax, it would be necessary to create a unique entity that instantiates a single architecture of dut, thereby providing a unique name to a particular entity/architecture combination.

Arguments FOR

This proposal eliminates the need for a designer to create a single entity that combines all design hierarchies, even when they do not communicate explicitly through ports and signals.

Arguments AGAINST

This proposal may be seen as encouraging the development of designs that communicate largely through external references, rather than through the established communication channels of ports.

General Comments

... . Within monitor, external references to the two architectures of dut need to be differentiated by architecture. Unfortunately, the current syntax of external references does not permit this kind of differentiation. Without an extension to the syntax, it would be necessary to create a unique entity that instantiates a single architecture of dut, thereby providing a unique name to a particular entity/architecture combination.

See 14.2 Elaboration of a design hierarchy, paragraph 8:

Similarly, the means by which top-level interface objects are associated with the external environment of the hierarchy are also defined by an implementation supporting top-level interface objects.

Today that means is implementation defined under the theory of multiple design hierarchies. There doesn't appear to be anything stopping a vendor from coming up with a method or mechansim for independent or interconnected (temporally or by stimulus/response) multiple design hierarchies. Imagine if you will external names which are implementation defined.

You could also note that potentially labelled monitor, dut(beh) and dut(str) are all under the same design hierarchy, that of the test bench enclosing their collective design specification.

You're otherwise in effect adding differentiation of top level elements of that hierarchy which sounds like the domain of configuration as well (14.2 para 3):

A design hierarchy is defined either by a design entity or by a configuration.

You could note that this is a verification issue that's dependent on the use of external names. You could perhaps just as easily define an alias involving top level labels (the distinguishing element of otherwise identical hierarchical net paths, you don't need to involved the selected architecture name) as a new class of external_name (say hierarchy_name).

What also comes to mind is a test bench of test benches, where a 'monitor' associated with individual design hiearchies and thier 'monitors' needs to communicate with those sub monitors. Perhaps this speaks to the need for a separate primary unit for verification wherein to which the use of external names could be constrained.

-- DavidKoontz - 2014-06-25

Supporters

Add your signature here to indicate your support for the proposal

main.CliffordWalinsky

Opponents

Add your signature here to indicate your opposition to the proposal *

Topic revision: r4 - 2020-02-17 - 15:34:35 - JimLewis

P1076