Language Change Specification for Selected Names for Types

LCS Number: LCS-2016-028 History
Version: 2 {07-Feb-2017}
1 {22-Dec-2016}
Date: 07-Feb-2017
Status: Request for Comments and/or Edits
Author: Jim Lewis
Email: Main.JimLewis
Source Doc: Selected Names for Types
Summary: Selected Names for Types

Voting Results: Cast your votes here


  1. Jim Lewis - 07-Feb-2017 ver 2
  2. Torsten Meissner - 2016-12-27 ver 1
  3. Lieven Lemiengre - 2017-01-27 ver 1
  4. Patrick Lehmann - 2017-03-14 ver 2



  1. Martin Zabel - 2017-01-30 any version - I have no experience with external names.
  2. Brent Hayhoe - 2017-02-16 Version 2 - Abstain due to lack of personal time for review.
  3. Martin Thompson - 2017-02-17 Version 2
  4. Mark Zwolinski - 2017-02-27 I see what's intended, and it would be good to make this possible, but I'm unconvinced that this is the right way to do it.
  5. Lars Asplund - 2017-03-23 I think this feature is driven by a use case that should be solved by other means. For example, by moving the state type to a package.

Revision Notes

Revision 2:

  • Replaced entity_path_name with architecture_path_name
  • Changed edits in 8.3
  • Changed edits in 12.2

Style Notes

[Author Comment: author comments are shown in green]

Text changes are shown in red

Deleted text is shown in red font with a strike thru

Reviewing Notes

Goal: Make a type or subtype declared in an entity or architecture visible.

Issue: The type must be known at compile time. Issue: What if the selected architecture is not part of the elaborated design?

Approach: Define Architecture path Remove restrictions on expanded names to an architecture body. Specify Expanded name to types and subtypes. Make other references illegal. Now there is a compilation dependency on a 2ndary unit.

Issue: what if the selected architecture is not part of the elaborated design? This should not be a problem for anything that needs to use the type. Ultimately though, one use model for the LCS is to make a type visible that can be eventually used as part of an external name reference to a signal of that type. It is erroneous if the two types are not declared in the same architecture.

Alternative: External Names
Currently external names focus on path of an elaborated path. This would have to be a new sort of external name that used a library path that is available at compile time. Essentially this would be an external name that uses the path of an expanded name.


1) What about subtypes ?

2) The notation is ambiguous: entity and architecture have separate scope, so it is possible to have a declaration in an entity and a declaration in an architecture with the same name.

3) Types declared in entities are not elaborated, so referencing them will result in an error when used. We could fix that for locally static types, but certainly not for the others. Think about:

  entity e is
    generic (len : natural);
    type my_vect is array (1 .. len) of bit;
  end e;

-- Tristan Gingold - 2016-12-23

1) Added. Thanks.

2) The notation is intended to allow either an entity_path_name which is entity_name(architecture_name) or a simple name which can be an entity_name. Is this ambiguous? Can you suggest corrections to make this clear and unambiguous?

3) What can I do with a reference to an unelaborated type? What I am looking to do here is to access the enumerated type of a statemachine that is defined in the RTL design architecture. This requires the type to be static. If the type is unelaborated, then I do not have access to the type values.

Can I do anything useful and appropriated with an unelaborated type? I would need a use model to address this. For now, for generic types are not so interesting as I can find their type information elsewhere in the design hierarchy.

Like external names, this is a ugly method to get at something. It is intended to be used in a testbench where we are probing into a design.

-- Jim Lewis - 2016-12-23

For 2): An entity_path_name denotes in fact an architecture, so this is confusing. The word 'or' for the added sentence in 8.3 is also confusing, maybe 'respectively' is better.

For 3): We could make an exception for enumerated types, but ideally such types must be declared in a package.

-- Tristan Gingold - 2016-12-23

for 2) The architecture has to be identified if we are reaching into a compiled architecture - which generally we are. We may reach into an entity - I would consider this rare as most forget that there is both a declarative and a statement part there - although these are rarely used.

for 3) I don't need an exception. Beyond referencing the type, I need compile time access to values of the type. I agree that if someone is using type generics, that other mechanisms are available to them. Hence, I would suggest that we forbid access to type generics.

-- Jim Lewis - 2016-12-23

With separate compilation & compilation order this feature could be less useful than you think. It may still be more interesting to move shared types to a separate package visible by all. But I don't see any technical reasons why this proposal can't be implemented, so I vote yes.

-- Lieven Lemiengre - 2017-01-27

@LL The target application is for a testbench to be able to reference an RTL statemachine. Unfortunately cannot do the signal access without knowing the enumeration values of the type. Often the verification team is not permitted to modify the RTL code. Other than for the testbench, there is no reason to put the state into a package. This allows methodologies like OSVVM to collect state coverage on the statemachine.

-- Jim Lewis - 2017-01-30

Revision 2.

  • Addressed Tristan's issues.

-- Jim Lewis - 2017-02-07

I promised Jim that I would think about my abstention vote again. I'm still unconvinced and I'm even less certain that this problem is solvable. But I do accept that it would be very useful to be able to access enumerated types, typically the states in a state machine, from the testbench.

1. It's not clear to me that the values of the type are accessible this way. Even if they are accessible after elaboration, would they be accessible at compile time? 2. There's no proposal to make signals of the type visible. So, the testbench might know the possible states, but not know what state the system is actually in. Is that really helpful?

So, I'm sticking with my abstention because although I don't see a technical problem in doing this, I question whether there's any value to it.

-- Mark Zwolinski - 2017-02-28

@MarkZ.2, VHDL-2008 gives us external names to signals. So if we have the type, we can get at the state value.

-- Jim Lewis - 2017-03-02

Topic revision: r1 - 2017-07-22 - 20:37:40 - JimLewis
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback