Re: [vhdl-200x] Start at path names analysis and proposal

Peter,

I read the proposal and I wanted provide some corrections to the VHPI
specification you
summarized. You will also see some other emails on these topics on the vhpi
- pilot
reflector in response or corrections to your section 17.3 of the VHPI LRM.

The name a protected type region is defined in VHPI to exactly be the name
of the variable which caused the instantiation of protected type region.

The signature string name for enumeration literals and overloaded
subprograms is a separate property in VHPI vhpiSignatureNameP. I think that
this is what was decided at the offsite in march. The vhpiNameP or full
name properties of such overloaded objects does not contain the signature
string. The intent of the signatureName property is to be used with
vhpi_handle_by_name and provide the possibility for vhpi_handle_by_name to
disambiguate between overloaded objects.

The vhpiFullNameP of a dynamically elaborated subprogram was changed at the
offsite to instead of providing the frame level (call depth) to denote the
subpcall, to be formed as the concatenation of the vhpiName of all the
subprograms on the call chain.
For example if subpcall bar is called from the concurrent procedure call
foo which has an explicit label P1. the full name would be (assuming the
eqprocess P1 is at the root instance)
:P1:bar
instead of :P1[1]

Originally I proprosed the old syntax, At the offsite we decided to change
this to use the vhpiname property for all the subprogram on the call chain.
There is a consequence which must be noted: I think that with the new
format, the fullname is more detailed in terms of which subpcall is
dynamically elaborated. Instead a frame level could identify any first
level sub program call inside the process. Using the fullname with
handle_by_name would not return a handle to bar inside P1 if bar is not
currently executing while using :P1[1] with handle_by_name could return a
handle to whatever subprogram call inside P1 is currently executing.

Anyway, I wanted to provide these precision, note that we are discussing
this at the moment again and we could reverse our decision if there is a
reason to do so.

Francoise
        '

At 10:01 AM 4/19/2004 +0930, Peter Ashenden wrote:
>Folks,
>
>Further to the discussion in the telecon last week, attached is a start at a
>document analyzing requirements for path names. Before I go any further,
>I'd appreciate comments on the approach. Is this where we want to head with
>this? Also, could Steve and Erich please advise on the missing bits that
>I've tagged with your names? Thanks.
>
>Cheers,
>
>PA
>
>--
>Dr. Peter J. Ashenden peter@ashenden.com.au
>Ashenden Designs Pty. Ltd. www.ashenden.com.au
>PO Box 640 Ph: +61 8 8339 7532
>Stirling, SA 5152 Fax: +61 8 8339 2616
>Australia Mobile: +61 414 70 9106
Received on Tue Apr 20 13:06:22 2004