[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 14:32:26 2004