External Names and Unspecified Types

Is your capability/feature request related to a problem?

It is really not clear if this should be an issue or a bug report.
The BNF for LCS, http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/TopLCS2016_028a, was implemented in 2019. The text based restrictions were not.

As a proposal, this is what is intended

How do we reference a state machine signal whose type is an enumerated type defined in the same architecture?

Hence the objective is to create an external name to the State signal shown in the code below. The issue is that RingStateType is not known outside of block1.

entity block1 is
 port ( ... ) ; 
end entity block1 ; 
architecture rtl of block1 is 
  type RingStateType is (S0, S1, S2, S3) ; 
  signal State : RingStateType ; 
  

Allow an unspecified type to be used with an external signal name.

architecture test_sequencer of testbench is
  alias Ring_State is <<signal .Testbench.U_RTL_TOP.Block1.Statet : (<>) >>;

  constant S0_BIN    : CovBinType := GenBin("S0", Ring_State'subtype'pos(Ring_State'subtype'value("S0") ) ) ; 
  constant S1_BIN    : CovBinType := GenBin("S1", Ring_State'subtype'pos(Ring_State'subtype'value("S1") ) ) ; 
end package body TbPkg ; 

begin

Describe alternatives you've considered

Other potential solutions were explored here, but failed to come to fruition. http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ExternalNameTypes

LCS

The LCS for this change is at:
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/TopLCS2016_028a

LCS BNF Implemented in 2019

2019 BNF allows unspecified types to be used with external names.

external_name ::=
    external_constant_name
    | external_signal_name
    | external_variable_name

external_constant_name ::=
    << constant external_pathname : interface_type_indication >>

external_signal_name ::=
    << signal external_pathname : interface_type_indication >>

external_variable_name ::=
<< variable external_pathname : interface_type_indication >>

-- From 6.5.2
interface_type_indication ::=
    subtype_indication | unspecified_type_indication

Portion of LCS Not Implemented in 2019

Note: This is from the LCS text, however, it has been updated for the terminology used in the 2019 standard (ie: anonymous types became unspecified types).

If the interface type indication is an unspecified type indication, the subtype is determined during elaboration of the external name. Only predefined operators and attributes that are appropriate for the unspecified type class shall be used. It is an error if subtype of the object denoted by the external name is not a member of the type class of the unspecified type.

LCS further steps

We probably need to look at the steps by which an external name is elaborated and consider if any additional steps are required to effect this change.