Re: [vhdl-200x] vhpi names and psl names

Hi Steve,

Good comments. I think you are right to say that an emphasis on
improved naming conventions for VHDL
is the better target. The point that I wish to reiterate is our
recommendation that this be promoted to an
effort for language interoperability standards that can be embraced by
Verilog, VHDL, and PSL. We think it
would better serve all concerned to do that, with the adoption of it in
VHDL achieving the effect of a canonical
naming convention that you desire, but the consensus achieved being
more valuable. In the interim, leaving
PSL as it stands and changing nothing in VHDL (or VHPI), makes sense.
Perhaps I do not understand your sense
of urgency to change it now for vhdl-200x FT.

In short, we are concerned that the result we achieve by improving
naming conventions for VHDL will not be
broad enough without an interoperability aim. For that, you have to
invite others to the table in the Verilog and
PSL community, too. This should go up to DASC for consideration.

Regards, John

On Tuesday, April 20, 2004, at 11:02 PM, Bailey, Stephen wrote:

> All,
>  
> I thank John and the VHPI committee for being flexible and desiring to
> stay with conventions (where applicable).
>  
> -- Start quote 1
>
> We agreed without dissent that changing VHDL pathname syntax is not a
> good thing to do for backward compatibility,
>
> and would create a lot of dissent in the VHDL community.  The choice
> for VHPI should be alignment with
>
> VHDL conventions.  We think the discussion should be about changing
> VHDL conventions with the intent
>
> of deprecating the old stuff vs. keeping the current conventions.
>
> -- End quote 1
>
>  
>
> In the telecon last week, there was minimal discussion about changing
> existing 'path_name behavior as it was quickly decided it can be left
> as is.  If we come up with a canonical naming convention that differs
> from using ":" or in any other way with 'path_name results, a new
> attribute can be added that produces the new canonical form while
> retaining the existing attributes.  The same is true for
> 'instance_name.
>
>  
>
> -- Start quote 2
>
> We talked about PSL needs and, despite appreciating the problem they
> faced, we felt they made a mistake
>
> in choosing to perturb the VHDL pathname syntax for the VHDL flavor of
> PSL.  It is a political statement to
>
> make, and sensitive at that, but PSL may find that it’s alignment with
> Verilog syntax may not be of great benefit.
>
> VHDL will embrace PSL and the Verilog community seems committed to a
> different strategy for assertions
>
> than PSL.
>
> -- End quote 2
>
>  
>
> I strongly caution all to avoid the pitfall of considering PSL as a
> VHDL-only solution.  The PSL designers have worked hard to be language
> neutral.  This characteristic of PSL is a MAJOR competitive advantage
> over SystemVerilog Assertions (SVA).  Mixed HDL designs are very
> common.  We on the VHDL side should not look at PSL as our captive
> assertion/property specification capability.  While the PSL group, in
> general, and Erich, specifically, have done a good job of taking VHDL
> requirements into consideration, it is not VHDL-specific and should
> never be.
>
>  
>
> Furthermore, the greater the PSL use in the Verilog community, the
> better it is for PSL.  I personally know many Verilog users that have
> expressed interest in PSL.  Since we plan to incorporate PSL as VHDL's
> ABV capability, it is also beneficial for VHDL -- more R&D into
> building better tools and more verification IP using PSL as the PSL
> market is bigger.  (And, in my opinion, it is also beneficial for the
> Verilog community as I believe PSL is superior to SVA.)
>
>  
>
> To the technical issue with PSL and vunit instance binding:  There is
> no VHDL standard for names in this regard.  'Path_name and
> 'Instance_name formats are specific to the attributes and not more
> generally codified in the LRM.  I believe a survey of vendor tools and
> what they accept for a path/instance name would reveal that there is
> either no standard or that if there is, it doesn't use ":" as the path
> separator character.  This is relevant in that the path/instance name
> use in this context is as an input and not as an output which is much
> closer to the need that exists for VHPI and PSL instance binding. 
> 'path_name and 'instance_name are outputs that are not processed by
> VHDL as input in any way.
>
>  
>
> The bottom line is that if we are going to define a canonical naming
> convention for VHDL, we should do so now.  If there are good reasons
> to deviate from the 'path_name and 'instance_name formats, then we
> should do so.  The reasons to consider are:
>
>  
>
> - Consistency with the rest of VHDL (note: ":" is not used in names
> anywhere else in VHDL but "." is used for selected names and
> parenthesis are used for indexed/slice names and entity(arch)
> pairings.)
>
>  
>
> - Compability/convenience for PSL
>
> - Greater consistency with vendor tools (if there is a consensus in
> how vendor tools treat path names)
>
> - Since it is an input, ease of user typing.
>
>  
>
> Finally, the proposal is not for VHPI to change away from VHDL
> conventions.  The proposal is for a VHDL canonical naming convention. 
> It is assumed that VHPI would then comply with that canonical naming
> convention and, in fact, would likely be one of the first language
> enhancements to exploit it.  I believe you and the VHPI committee
> understand this, but your email could be easily misunderstood
> especially by those who did not attend last week's telecon.  But, let
> me know if your recollection of the meeting is different from mine as
> I need to post the minutes and want them to be correct.
>
>  
>
> -Steve Bailey
>
> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org]On
> Behalf Of John J. Shields
> Sent: Tuesday, April 20, 2004 3:32 PM
> To: vhdl-200x@eda.org
> Subject: [vhdl-200x] vhpi names and psl names
>
> Hi All,
>
>  
>
> I wanted to note some preliminary conclusions the VHPI task force came
> to in our discussion about
>
> the PSL name syntax, vhpiFullName syntax, pathname interoperability in
> general.
>
>  
>
> The discussion of syntax acknowledged that one could, in theory,
> choose a different hierarchical
>
> separator.  There are complications similar to that which PSL had. One
> has deal with the formulation
>
> of canonical names that refer to instances of components, record
> fields, array slices, etc.   Finding information
>
> by name in the instantiated and uninstantiated information model is a
> central feature of VHPI.  It has broad
>
> extensibility for pattern matching searches that return collections of
> objects in the future. 
>
> We agreed without dissent that changing VHDL pathname syntax is not a
> good thing to do for backward compatibility,
>
> and would create a lot of dissent in the VHDL community.  The choice
> for VHPI should be alignment with
>
> VHDL conventions.  We think the discussion should be about changing
> VHDL conventions with the intent
>
> of deprecating the old stuff vs. keeping the current conventions. 
>
>  
>
> We talked about PSL needs and, despite appreciating the problem they
> faced, we felt they made a mistake
>
> in choosing to perturb the VHDL pathname syntax for the VHDL flavor of
> PSL.  It is a political statement to
>
> make, and sensitive at that, but PSL may find that it’s alignment with
> Verilog syntax may not be of great benefit.
>
> VHDL will embrace PSL and the Verilog community seems committed to a
> different strategy for assertions
>
> than PSL. We think PSL made a mistake in its binding, unless the VHDL
> community would accept a
>
> change in separators in a uniform, but not backward compatible way.
> …which we believe would be a hard
>
> sell.  It would be convenient to suggest that PSL should change its
> decision about VHDL binding. It seems that
>
> it is not too late to do so, but we aren’t very informed here.  We
> leave it to PSL and VHDL-200X to persue.
>
>  
>
> What we think is acceptable to say is let PSL have its unique syntax
> for now.  Extending VHPI for PSL’s sake
>
> would ultimately be useful, but it is premature to do that in the
> first release of VHPI.  We can address that when we analyze
>
> the adopted VHDL changes assertions based on PSL.
>
>  
>
> Beyond that, we recommend a couple of avenues for consensus.  First,
> it seems it is time for a standardization effort
>
> to define language interoperability conventions for VHDL and Verilog. 
> This is the place to establish the framework for a  
>
> language neutral syntax for PSL, which may lead to changes in their
> specification.  Second, we should float
>
> proposals to the VHDL community for changing either PSL or VHDL syntax
> for pathnames and gauge the
>
> reaction.
>
>  
>
> Regardless, at this point, we feel it is a mistake for VHPI to change
> its conventions away from the VHDL language
>
> conventions in place unless and until there is broader consensus.  We
> could end up with VHPI conventions that
>
> are not accepted, PSL usage as is anyway, and more confusion in the
> user interfaces of applications based on VHPI.
>
>  
>
> Regards, John
>
>  
>
Received on Wed Apr 21 12:22:46 2004