[vhdl-200x-ft] Re: Review of FT-32

Erich,

I do like your inside and outside view concepts to discuss the problem, 
but both concepts are relevant to VHPI.   The outside view that you 
ascribe to VHPI is the context in which full names are defined.  While 
the context of a full name is the elaborated design, VHPI does support 
an inside view of the elaborated design as well.  One can obtain a 
handle by name by starting from a context handle which represents a 
region in the elaborated design and use a relative name.  The goal is 
the same, too, namely to minimally qualify the name of the object of 
interest.  VHPI's definition of naming objects along the path serves to 
define a fully qualified name and minimally qualified names relative a 
context. 

I don't quibble about the syntax for now.  A '.' separator serves as 
well as '/' or ':' and each has some history and alignment with other 
syntax.  I'd prefer the '.', but I care much more about getting the 
semantics right and letting the syntax satisfy all the sensibilities in 
a democratic way. I'll get to the leading prefix character in a minute.

You propose expanding the role of expanded names.  I limited my proposal 
to the current language definition, VHPI needs, and PSL needs (as best I 
understand them. ) I'm pretty sure I met the needs, but that is why I 
asked for some review.  Given that you propose a broader solution to the 
hierarchical name references in the language, that should be considered 
on its merits, too.
The issue of expanding the role of expanded names to support out of 
scope references is a fine idea.  This strategy was considered and 
rejected by the fast track committee as not being a "fast track" 
concept.  It had some difficult issues related to the VHDL model of 
elaboration and execution semantics.  Not unreasonable or unsolvable, 
just a larger problem than they aspired to tackling (as I understand the 
history, anyway).  I prefer it to the subprogram model of making 
hierarchical references ala signal spy.  But it is those difficult 
issues that need to be worked out.  One way to fast track it, IMHO, is 
to limit its use in the language to PSL vunits, table the signal spy 
addition, and work on the details for broader language enhancement using 
the Accellera process.  Another way is to arrive at consensus quickly on 
the difficult issues ; I'm OK with that but I just don't anticpate it.

I want to try to clarify something regarding the information models in 
VHPI and the description you offered about refering to compiled design 
units in a library
and objects in the elaborated design.  The elaborated design information 
model in VHPI encompasses the design hierarchy and the set of elaborated 
packages.  They can be refered to cleanly with the same syntax.  If we 
adopt the '.' prefix, '.' separator, it will be the same as your 
expanded name syntax. (I realize you have more flexiblity for wildcard 
references, etc.)   Why didn't we do that? First, keeping within the 
context of the elaborated design, there is slightly more ambiguity, one 
might say, pathological ambiguity.  It is possible to name the entity 
name of the root of the design the same name as a logical library name.  
If so, ".foo.bar" may refer to an object bar in the root or an 
elaborated package named bar.  Because the name spaces are separate, we 
disambiguated fullnames with a prefix character.  We used  "@" for 
library references. 
 
There is, however, a missed requirement in your solution with respect to 
the needs of VHPI.  There is  the uninstantiated information model.  It 
takes a view of libraries of compiled design units.  It is strongly 
related, obviously, to the elaborated model  and shares many  common 
definition of  objects and properties.   It is possible to refer to an 
uninstantiated package in a library or an eleborated package in the 
design and formally they are different.  How do you disambiguate such 
references?  Well we debated various approaches including factoring  the 
API, creating a unique pre-defined context handle, and using syntax.  
Our design uses syntax.  Since I explained the syntax considerations ad 
nauseum in my proposal I won't do it again, but that is what led to the 
'@' and accomodating PSL restrictions as an additional requirement is 
what led to '!' and '@'.

So, in summary, I like what you propose.  I see it as bringing new 
language features that are desired and potentially better for the 
language than the subprogram approach.  I see it as complimentary to the 
solution as I proposed as easy enough to unify, once the dust settles on 
your proposal.

Regards, John