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

From: Bailey, Stephen <SBailey@model.com>
Date: Tue Apr 20 2004 - 23:02:39 PDT

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 Tue Apr 20 23:02:43 2004

This archive was generated by hypermail 2.1.8 : Tue Apr 20 2004 - 23:03:15 PDT