FT 32: PATHNAME INSTANCENAME issue roll-up
Discussion from vhdl-200x reflector unless otherwise noted
===============================================================================
===============================================================================
===============================================================================
4/5/2004, Peter Ashenden, Issue with VHDL name attributes
Folks,
The VHPI team proposes to specify a property, called vhpiFullNameP, that
provides a string representation of the path name to an item in a VHDL
model. The proposal is to define the property in terms of the 'path_name
predefined attribute.
An issue is that there is a deficiency in the definition of 'path_name (and
also 'instance_name) in the 1076-2002 LRM. We revised the definition of
declarative regions to specify that an architecture body declarative region
is logically nested within the entity declaration declarative region. This
allows you, among other things, to declare architecture e of e without
breaking the scope rules.
It also allows you to declare an object x in entity e and a second object x
in a corresponding architecture, say a. The architecture's x hides the
entity's x, but you can get at the entity's x within the architecture using
an expanded name (e.x). However, both x's have the same 'path_name
attribute. If e(a) is instantiated with label c in architecture top_a of
top_e, then
e.x'path_name = ":top_e:c:x"
e.a.x'path_name = ":top_e:c:x"
e.x'instance_name = ":top_e(top_a):c@e(a):x"
e.a.x'instance_name = ":top_e(top_a):c@e(a):x"
I believe this is an oversight. When we added the rule covering the
declarative region of an architecture body, we overlooked the implication
for these attibutes.
I propose to correct this oversight in the P1076b amendment specifying the
VHPI. That will allow us to specify the vhpiFullNameP property in terms of
the 'path_name attribute correctly.
My proposed correction is to treat the entity and architecture as separate
elements in the path names. This corresponds properly to the nesting of
declarative regions. The changes in Clause 14.1 are as follows:
In the description of the 'instance_name attribute:
- Change the BNF rules for full_path_instance_element to
full_path_instance_element ::=
[ component_instantiation_label @ ]
entity_simple_name
| architecture_simple_name
| block_label
| generate_label
| process_label
| loop_label
| subprogram_simple_name signature
- In the fourth paragraph after the BNF rules, insert "architecture body, "
after the words "component instantiation, ".
- Replace the fifth paragraph after the BNF rules with
A full path instance element in the form of an architecture simple name
must be immediately preceded by a full path instance element in the form
that includes an entity simple name. In that case, the architecture
simple name must denote an architecture associated with the entity
declaration designated by the entity simple name. A full path
instance element in the form that includes an entity simple name must
also include the component instantiation label (and the commercial at
following it) unless the entity simple name denotes the entity
declartion of the root design entity.
In the description of the 'path_name attribute:
- Change the BNF rules for path_instance_element to
path_instance_element ::=
component_instantiation_label
| entity_simple_name
| architecture_simple_name
| block_label
| generate_label
| process_label
| subprogram_simple_name signature
- In the third paragraph after the BNF rules, insert "architecture body, "
after the words "component instantiation, ".
In the Examples declaration of entity e, change the values shown in comments
as follows:
-- e'instance_name = ":e:"
-- g'instance_name = ":e:g"
-- p'instance_name = ":e:p"
In the Examples declaration of architecture a of e, add the following
comments to the end of the first line of the architecture body:
-- a'path_name = ":e:a:"
-- a'instance_name = ":e:a:"
Also in the Examples declaration of architecture a of e, change the values
shown in comments as follows:
-- S'PATH_NAME = ":e:a:s"
-- S'INSTANCE_NAME = ":e:a:s"
-- Proc1'PATH_NAME = ":e:a:proc1[natural,integer]:"
-- Proc1'INSTANCE_NAME = ":e:a:proc1[natural,integer]:"
-- C'PATH_NAME = ":e:a:proc1[natural,integer]:c"
-- C'INSTANCE_NAME = ":e:a:proc1[natural,integer]:c"
-- max'PATH_NAME = ":e:a:proc1[natural,integer]:max"
-- max'INSTANCE_NAME = ":e:a:proc1[natural,integer]:max"
-- T'PATH_NAME = ":e:a:p1:t"
-- T'INSTANCE_NAME = ":e:a:p1:t"
.
.
.
-- T'PATH_NAME = ":e:a::t"
-- T'INSTANCE_NAME = ":e:a::t"
Change the Examples declaration of architecture bottomarch of bottom to:
architecture BottomArch of Bottom is
signal SBottom : INTEGER;
begin
ProcessBottom : process
variable V : INTEGER;
begin
if GBottom = 4 then
assert V'Simple_Name = "v"
and V'Path_Name = ":top:top:b1:b2:g1(4):b3:l1:processbottom:v"
and V'Instance_Name =
":top:top:b1:b2:g1(4):b3:l1@bottom:bottomarch:processbottom:v";
assert GBottom'Simple_Name = "gbottom"
and GBottom'Path_Name = ":top:top:b1:b2:g1(4):b3:l1:gbottom"
and GBottom'Instance_Name =
":top:top:b1:b2:g1(4):b3:l1@bottom:bottomarch:gbottom";
elsif GBottom = -1 then
assert V'Simple_Name = "v"
and V'Path_Name = ":top:top:l2:processbottom:v"
and V'Instance_Name =
":top:top:l2@bottom:bottomarch:processbottom:v";
assert GBottom'Simple_Name = "gbottom"
and GBottom'Path_Name = "top:top:l2:gbottom"
and GBottom'Instance_Name =
":top:top:l2@bottom:bottomarch:gbottom";
end if;
wait;
end process ProcessBottom;
end architecture BottomArch;
Change the Examples declaration of architecture Top of Top to:
architecture Top of Top is
component BComp is
generic (GComp : INTEGER)
port (PComp : INTEGER);
end component BComp;
signal S : INTEGER;
begin
B1 : block
signal S : INTEGER;
begin
B2 : block
signal S : INTEGER;
begin
G1 : for I in 1 to 10 generate
B3 : block
signal S : INTEGER;
for L1 : BComp use entity Work.Bottom(BottomArch)
generic map (GBottom => GComp)
port map (PBottom => PComp);
begin
L1 : BComp generic map (I) port map (S);
P1 : process
variable V : INTEGER;
begin
if I = 7 then
assert V'Simple_Name = "v"
and V'Path_Name = ":top:top:b1:b2:g1(7):b3:p1:v"
and V'Instance_Name=":top:top:b1:b2:g1(7):b3:p1:v";
assert P1'Simple_Name = "p1"
and P1'Path_Name = ":top:top:b1:b2:g1(7):b3:p1:"
and P1'Instance_Name = ":top:top:b1:b2:g1(7):b3:p1:";
assert S'Simple_Name = "s"
and S'Path_Name = ":top:top:b1:b2:g1(7):b3:s"
and S'Instance_Name = ":top:top:b1:b2:g1(7):b3:s";
assert B1.S'Simple_Name = "s"
and B1.S'Path_Name = ":top:top:b1:s"
and B1.S'Instance_Name = ":top:top:b1:s";
end if;
wait;
end process P1;
end block B3;
end generate;
end block B2;
end block B1;
L2 : BComp generic map (-1) port map (S);
end architecture Top;
In proposing these changes, I note that the values of the attributes will be
different from those produced under earlier versions of the standard.
However, if the usage model for these attribute values is just to display
them as part of informational messages or to use them for navigation in an
interactive tool, the validity of existing models would not be affected.
Correcting the description of the attributes will enable simplification of
definition of the vhpiFullNameP property and will ensure that the property
and the attributes are mutually consistent. VHPI programs will make use of
the property for more than just information display, so it is important that
the property's description is done correctly and consistently from the
outset, as future changes to the description will affect backward
compatibility for VHPI programs.
As an incident further correction, the third sentence of Note 9 at the end
of Clause 14.1 is no longer correct, since signatures were added to path
instance elements and full path instance elements. I propose to delete the
sentence.
VHPI Task Team: Comments? Could you please discuss and eventually approve
(or otherwise)?
Steve, I'm posting this to the VHDL-200x list for information because it's
not simply a matter of definition of VHPI functionality. Rather, it's
correction of base functionality in order to facilitate VHPI definition.
Hence, I would argue that it's still in scope for the P1076b amendment.
Would you care to comment?
Of course, comments for all quarters welcome. Thanks.
Cheers,
PA
===============================================================================
===============================================================================
===============================================================================
4/6/2004, John Ries, Re: Issue with VHDL name attributes
All,
I have to disagree with the proposal.
Adding addition scopes to the pathname raises several issues.
1) Compatibility
2) Cross module references
The statement
"In proposing these changes, I note that the values of the attributes will be
different from those produced under earlier versions of the standard. However,
if the usage model for these attribute values is just to display them as part
of informational messages or to use them for navigation in an interactive tool,
the validity of existing models would not be affected."
Cross module references would need to support the new pathname form. This raise the
question does the old form of pathnames work if it is unambiguous? Does the VHPI
look up by name support the old form with the same restrictions?
3) There is still a fundamental problem with the architecture being a scope
inside of the entity. If you have X declared in the architecture and in the entity
and the entity and architecture have the same name, say E, you can't access the entity's X.
Because E.X refers to the architecture's X. If E. referred to objects in the
entity's scope, selected names to everything in an architecture would have to be
E.E.. This would break compatibility with older designs.
I had thought Chuck Swart had raised an issue making the architecture a nested scope in 2002 for
just this reason. To put words in Chuck's mouth he thought the only reason for adding the
nested scope was to clean up the problem of having an architecture named the same as the entity.
The 2002 change seems to raise as many issues as it fixes.
On the procedural scope, I think that it is good for VHPI team should identitfy issues like this
and propose solutions. I don't think that they should be actually changing the LRM to
implement these solutions. Ideally they would raise the issue, propose a solution, the
ISAC would comment and it would be folded into the VHDL-200x fast track changes.
Regards,
John
===============================================================================
===============================================================================
===============================================================================
4/7/2004, Peter Ashenden, Re: Issue with VHDL name attributes
John,
>> I have to disagree with the proposal.
>> Adding addition scopes to the pathname raises several issues.
>>
>> 1) Compatibility
Yes, that needs to be considered. What is broken by the change? (See below
for an answer.)
>> 2) Cross module references
>> ...
>> Cross module references would need to support the new
>> pathname form. This raise the
>> question does the old form of pathnames work if it is
>> unambiguous? Does the VHPI
>> look up by name support the old form with the same restrictions?
The problem is that the old form *is* ambiguous. Does a path name of the
form ":e:x" refer to an item x declared in entity e or in some architecture
of e? If both the entity and an architecture declare x, ":e:x" is the path
name for both items. If you plan to use path names for XMRs, the old form
doesn't give you a way to distinguish between the two items.
Regarding VHPI lookup by name: I don't know what prototype implmentations
do, but since I'm specifying it in the LRM, I need to ensure completeness of
definition. If the path_name attribute remains unchanged, it cannot serve
as the basis for the vhpiFullNameP property. I'd have to repeat a lot fo
the definitional work to specify something that is unambiguous and that can
eb used for lookup by name. Presumably that could then be used for XMRs
instead of the broken path names. All up, I think it would be better to fix
the problem as part of standardization than to have a collection of
inconsistent and partly broken approaches.
>> 3) There is still a fundamental problem with the architecture
>> being a scope
>> inside of the entity. If you have X declared in the
>> architecture and in the entity
>> and the entity and architecture have the same name, say
>> E, you can't access the entity's X.
>> Because E.X refers to the architecture's X. If E.
>> referred to objects in the
>> entity's scope, selected names to everything in an
>> architecture would have to be
>> E.E.. This would break compatibility with older designs.
>>
>> I had thought Chuck Swart had raised an issue making the
>> architecture a nested scope in 2002 for just this reason. To
>> put words in Chuck's mouth he thought the only reason for
>> adding the nested scope was to clean up the problem of having
>> an architecture named the same as the entity. The 2002 change
>> seems to raise as many issues as it fixes.
The problem addressed in the 2002 rev was that application of scope rules to
entity an architecture names was ill specified, and so different
implementations did different things. It wasn't clear that an architecture
name could be the same as the entity name; it depended on which bits of the
LRM you read. Some examples (non-normative) in the LRM had the architecture
name the same as the entity name, suggesting that the intent was to allow
it. Hence, it seemed appropriate to fix the application of scope rules to
those names and to names of design units in library and root regions in the
way that we did. Since the LRM was inconsistent/incomplete, whichever way
we fixed it was bound to break someone's interpretation.
Returning to the issue of referring to X declared in E from within
architecture E of E that also declares X: you can refer to WORK.E.X.
Looking at a more complete example, consider the following VHDL model:
entity E is
signal S1 : bit; -- first object
signal S2 : bit; -- second object
end entity E;
architecture E of E is
signal S1 : bit; -- third object
signal S3 : bit; -- fourth object
begin
...
end architecture E;
Within the entity, you can refer
- to the first object as WORK.E.S1, E.S1, S1
- to the second object as WORK.E.S2, E.S2, S2
Within the architecture, you can refer to
- to the first object as WORK.E.S1
- to the second object as WORK.E.S2, S2
- to the third object as WORK.E.E.S1, E.S1, S1
- to the fourth object as WORK.E.E.S3, E.S3, S3
Under the pre-2002 rules, you couldn't have two items of the same name, one
in the entity and the other in the architecture, since the two declarative
parts formed a discontinguous single declarative region.
Under the pre-2002 rules, if you have entity E declaring X and architecture
A declaring Y:
- within the entity you could refer to X as WORK.E.X, E.X or X
- within the architecture you could refer to X as WORK.E.X, E.X or X
and to Y as WORK.E.Y, A.Y or Y.
All of these are still valid under the 2002 rules except for referring to
WORK.E.Y in the architecture. Under the old rules you could not in the
architecture refer to Y as WORK.A.Y, but under the new rules you can refer
to it as WORK.E.A.Y or E.A.Y.
Under the pre-2002 rules, if you have entity E declaring X and architecture
E declaring Y:
- within the entity you could refer to X as WORK.E.X, E.X or X
- within the architecture you could refer to X as WORK.E.X or X
but not as E.X
- within the architecture you could refer to Y as WORK.E.Y, E.Y or Y
All of these are still valid under the 2002 rules except for referring to
WORK.E.Y in the architecture. Under the new rules you can refer to it as
WORK.E.E.Y.
So the only incompatibility is with a pre-2002 model that, within an
architecture, refers to an item Y declared in the architecture as WORK.E.Y,
where E is the entity name. Given the unlikelyhood of that, the benefit of
fixing the scope and visibility issues seemed like a good choice.
>> On the procedural scope, I think that it is good for VHPI
>> team should identitfy issues like this and propose solutions.
>> I don't think that they should be actually changing the LRM
>> to implement these solutions. Ideally they would raise the
>> issue, propose a solution, the ISAC would comment and it
>> would be folded into the VHDL-200x fast track changes.
I certainly seek ISAC comment - and have got it! The procedural question
here is that without the proposed change, defining an aspect of VHPI is made
more difficult and internal inconsistency is introduced. We could just
suffer that for now and revise the VHPI definition when the path name
attribute is eventually fixed by FT, but I think it would simplify life for
all concerned to address it now.
Cheers,
PA
===============================================================================
===============================================================================
===============================================================================
4/7/2004, Brian Griffin, Re: Issue with VHDL name attributes
--flame on
Time-out. I'd like to back up a bit. I have serious reservations about this
whole architecture scoping business. How can you possible inject a new scope
level here at all with out seriously breaking all existing vhdl models? I just
don't understand this. The entity architecture comprise a single scope.
Period. End of discussion. To even pretend otherwise is a significant,
fundamental change in the language that can do nothing but invalidate all
existing implementations. The only real problem here is an architecture that
has the same name as it's entity, which in my book is just plain stupid and
should be disallowed by all implementation. If it was disallowed, there
would be no ambiguity and no naming problems. Even if it's allowed, the
penalty is loss of access; too bad!
Please, please, please, don't make architectures a new scope, or even pretend to!
--flame off
-Brian
===============================================================================
===============================================================================
===============================================================================
4/7/2004, Peter Ashenden, Re: Issue with VHDL name attributes
Brian and others,
The change to the scoping of architecture bodies was done during the
VHDL-2002 revision. It occurred as part of LCS-3, addressing the
larger question of scope and visibility of design unit names. Due
process was followed: the change was analyzed and approved by the
working group, ballotted and approved by the sponsor ballot body,
and approved by the IEEE Standards Board (RevCom). So in the language
as it is currently defined, an architecture body is logically nested
within an entity declarative region.
As I pointed out in my proposal, the definition of the 'path_name and
'instance_name attributes was not revised to mirror the changes from
LCS-3. I believe this was an oversight, as I do not recall nor have
record of any discussion of implication of LCS-3 on the attributes.
Hence my proposal to correct the oversight.
Regards,
PA
===============================================================================
===============================================================================
===============================================================================
4/8/2004, Alex Zamfirescu, Re: Issue with VHDL name attributes
Dear HDL Experts:
I share the opinion that no additional scope is needed for
architectures. I looked at this when I proposed a fix for an
ISAC issue related to visibility of entity ports in the architecture
some time ago. As far as I know that was the only issue and it was
fixed. This new one about the same name can be solved in many
other ways:
1. Forbid same name
2. Omit arch name if same
3. Consider that arch name is omitted if same
4. Create a nested scope outside the architecture scope
just for its name
In any case do not create a nested scope inside the entity
scope.
Thanks,
Alex Z
===============================================================================
===============================================================================
===============================================================================
4/8/2004, Brian Griffin, Re: Issue with VHDL name attributes
Hi Peter and the rest of the VHDL community,
I humbly apologize to the community for falling asleep here and missing
this issue when it was originally "analyzed" and approved. Had I been
paying attention, I would have voiced my opposition to the change at
that time. Also, given this change in the language, the proposed
'path changes are perfectly reasonable. But, the fundamental fact
remains that this change is bad and just plain wrong because of the
ramifications through out the design and development process. Not only
did the "analysis" fail to address 'path, but did anyone consider the
impact on SDF, C API's, and other interactions of any and all kinds
with simulators such as cross probing? What the VHPI is attempting to
address here has already been addressed from the very beginning by all
tools that touch anything VHDL. To think that this LRM change has no
impact on these tools and the design flow is naive. Ignoring these
issues, even though they are not formally part of the language was
unfortunate, but it's not too late to take corrective action. This
change should be rescinded and the ISAC should re-evaluate the issues
in LCS-3 in a manor and language that clarifies the ambiguities,
identifies the limitations and, most importantly, does not drastically
change the external view of a design.
-Brian
===============================================================================
===============================================================================
===============================================================================
4/8/2004, John Shields, Re: Issue with VHDL name attributes
I've been on vacation and I just read through this thread. I'd like to
clarify a statement that Peter made regarding how we defined the fullname
property in VHPI. It is not true that its definition is tied intrinsically
to pathname. Indeed, we have a property for both pathname and instance_name
that are guaranteed to produce the same name as the attribute, but the
fullName property allowed us some important flexibility.
VHPI recognized this problem with ambiguity in the pre-defined name
attributes early ('pathname, 'instance_name). We decided that the
information model would have a fullName property that was similar to, but
independent of the 'pathname attribute. What we wanted to achieve was
consistency between the behavior of lookup_by_name and access to name
information. An application could retrieve the fullname of an object and
have some assurance that the object could also be looked up by that name.
An independent property allows us to deal with ambiguity in the definition
of 'pathname without causing backward compatibility problems or coordinating
standard revision. It allows us to deal with inherent ambiguity arising
from unlabelled processes by defining automatically generated names, a
concept that can be extended to form a canonical name for all instance
objects in the future, if desired (an example is the name of an arbitrary,
unlabeled statement).
One more bit of philosophy regarding ambiguity. VHPI does indeed say that
if a name is an ambiguous reference, then lookup will fail. The case being
discussed is one of pathological ambiguity and I think there are others
where library name and entity name are the same. I think this particular
one with 'pathname can be solved, but not without causing some backward
compatibility issues. It is inherent in changing a disjoint scope into a
nested scope.
I looked at Peter's proposal briefly and I don't like it. It doesn't pass
my common sense test. For an object x in the root instance whose entity and
architecture are both named top, we have :top:top:x. Most people would say
that :x or at worst :top:x should be the name, achieving a compact but
unambiguous reference for reasonable cases. If someone insists on forming a
case that has pathological ambiguity in it, I personally feel they should
reap the just reward of ambiguous references. All leaf level instances in a
pathname will now require the entity or architecture name to refer to the
appropriate scope as well. I trust the intermediate scopes between the root
and the leaf scope remain sufficiently unambiguous to not require the
architecture scope in each component of the path. It is hard to review
Peter's changes specified as incr changes in that email, so I may be missing
something.
As to VHPI thinking, we currently define fullname to be formed by the
concatenation of the simple names of the scopes from the root instance to
the object and the name of the object, using the appropriate
separator(i.e.,':' ). If entity and architecture have the same name for
some instance, it does not matter. The fullname will refer to the instance
by its label. We have not properly accounted for the
LRM revision defining 2 separate, nested scopes per 2002 LRM. We consider
them a single but disjoint scope. Therefore, as it stands today, we would
treat the situation of having 2 objects named 'x' in each scope as an
ambiguous reference and not possible to find either by lookup. We have to
fix this in some manner.
We could extend the definition to account for each scope, which would
effectively require a qualifier to distinguish whether we are referring to
the entity scope or architecture scope for a given instance. In most cases,
this would be overkill. We could leave the current specification and
specify that the lookup will search the entity scope followed by the
architecture scope or vice versa.This does not ignore the separate nested
scope issue, but treats it regularly to get the expected result in normal
cases and hides an object in the ambiguous cases. Finally, we can allow the
object name to be either its simple name or an extended name, where the
extended name serves to disambiguate. The extended name is either the
entity or architecture name followed by the simple name, with an different
separator (i.e., '.'). An object x in both the
entity and arch of the root instance could then be refered to with:
:e:x - today's definition and ambiguous or, given search rules, unambiguous
:e:e.x - possible extension to qualify the simple name of x in the entity
:e:a.x - " " " arch
I have not thought through all the cases but we do not want ambiguity caused
by a component of the fullname referring to an instance label or entity/arch
name. I can label an instance and name an entity or architecture with the
same name, no? I also do not want a burdensome canonical name that is
always unique and never convenient. This will cause user interface
conventions in tools that avoid the problem. I appreciate the need to fix
the VHDL attributes and encourage vhdl-200x to address this now rather than
later. I think VHPI will want to reserve the right to disambiguate,
simplify, and auto generate names to achieve a building block for good
application UIs. As such, 'pathname will remain a strong guideline for
vhpiFullName property, but not its foundation. Of course, IMHO, at this
point in time.
Regards, John Shields
===============================================================================
===============================================================================
===============================================================================
4/8/2004 #2, John Shields, Re: Issue with VHDL name attributes
Hi,
I’ve replied separately concerning the issues with VHPI name
properties and their relationship to ‘pathname, and this new
nested scoping issue. I also think the change to nest these scopes was
ill considered and should be reverted. I would appreciate some
clarification on the original problem that it was meant to solve.
I am specifically referring to the question of what problems are caused
by having the arch decl scope be regarded as an extension of the
entity decl scope? Does this cause a problem with separate compilation
in some way? Are there specific cases of name resolution problems
that are ambiguously specified?
In general, I am adverse to solving pathological problems in a manner
that penalizes normal, reasonable use. The discussion of how to fix
‘pathname to conform to the nested scope model of E and A decl regions is
a good example of that.
Thanks, John Shields
===============================================================================
===============================================================================
===============================================================================
4/20/2004, John Shields, 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
===============================================================================
===============================================================================
===============================================================================
4/20/2004, Steve Bailey, Re: vhpi names and psl names
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
===============================================================================
===============================================================================
===============================================================================
4/21/2004, John Shields, Re: 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
===============================================================================
===============================================================================
===============================================================================
4/21/2004, Erich Marschner, Re: vhpi names and psl names
John,
I would like to endorse your comments about the need for an
interoperability standard. The reason this issue (of pathname
syntax) came up in PSL is precisely because we must define
syntax that will work with both VHDL and Verilog (as well as
other languages). Differences in the pathname syntax for the
two languages made that task more complex. The fact that mixed
language designs are quite common today was also a major
consideration of ours, yet the current language definitions
do not address this at all. I'm sure the PSL user community
would be happy to adopt a standard pathname syntax that enables
better interoperability between VHDL and Verilog, and that the
PSL standardization committee will be happy to make whatever
changes are required in PSL to support such a standard, assuming
only that they do not cause problems in other areas of PSL.
Regards,
Erich
===============================================================================
===============================================================================
===============================================================================
4/21/2004, Steve Bailey, Re: vhpi names and psl names
Hi John,
The urgency is that VHPI, hierarchical referencing and PSL "incorporation-
by-reference" will be done for the next revision. Instead of perpetuating
ad hoc, somewhat but not quite standardized naming conventions, it would
be good to straighten it out now and then use it in the next revision and
future revisions.
Consistency with other languages (such as Verilog) can be added to the
requirements/objectives list.
-Steve Bailey
===============================================================================
===============================================================================
===============================================================================
4/30/2004, Peter Ashenden, Revision of path name proposal doc
FT 32, current proposal
===============================================================================
===============================================================================
===============================================================================
5/5/2004, Erich Marschner, Re:revision of path name proposal doc
Hi Peter,
Feedback on the document:
1. Introduction
A key use of pathnames is not listed here. Users specify pathnames
from outside an HDL design in order to specify the objects to which
commands apply. This usage includes wildcard specifications, so the
user can specify groups of objects with one or a few pathnames.
While this is technically outside the language, it could be argued
that this nonetheless is worth defining as part of the language,
just as the printed form of a pathname is in some sense also outside
the language.
2.5 PSL names
Pathnames appear in PSL in the context of a verification unit, which
can be 'bound' to either a module (i.e., design entity) or an instance
within the design hierarchy. In the general case, we may be dealing
with a mixed language design, so PSL pathnames need to allow for a
mixture of VHDL and Verilog names.
Pathnames only appear in the PSL grammar in one place: as the
module/design entity or instance name to which a verification
unit is 'bound' (i.e., the portion of the design in the context
of which the PSL is interpreted). This pathname appears within
parentheses, as in these Verilog-oriented examples:
vunit (modulename) {
...
}
or
vunit (top.i1.i2.i3) {
...
}
In a VHDL context, PSL v1.1 now allows a vunit to specify the
design unit to which it is bound using the syntax for "entity_aspect"
in VHDL - i.e., an /entity/_Name optionally followed by a
parenthesized /architecture/_Name. So the following examples will
be accepted in PSL v1.1:
vunit (E) { -- bound to (every architecture of) entity E
...
}
vunit (E(A)) { -- bound to architecture A of entity E
...
}
For an instance pathname, the PSL v1.1 LRM is not very specific,
but it basically says that, following an initial module/design
entity specification, there may be a sequence of (VHDL or Verilog)
instance names. So the following would all be acceptable:
vunit (e.a.b.c.d) ...
(where e is an entity and a,b,c,d are all labels on
subordinate component/entity instances)
vunit (e(a).b.c.d) ...
(where e is an entity, a is an architecture of
e, and b,c,d are labels on instances under a)
Note that a pathname always starts with a 'module name', i.e.,
an entity_aspect for a VHDL design entity, or a module_name for
a Verilog module. (I'll use 'module' from now on to mean either
of these, as appropriate for a given context.) This may be the
name of the topmost module in the design (which is not
instantiated elsewhere) or a module that is instantiated one or
more times at various places and levels within the design.
Following is the syntax for PSL pathnames (called
"Hierarchical_HDL_Name" in the syntax):
Hierarchical_HDL_Name ::=
HDL_MOD_NAME { Path_Separator /instance/_Name }
Flavor Macro HDL_MOD_NAME =
SystemVerilog: /module/_Name
/ Verilog: /module/_Name
/ VHDL: entity_aspect
/ GDL: /module/_Name
Path_Separator ::=
'.' | '/'
(In case it is not evident, /text/ in the BNF represents
italicized text, i.e., comments that carry semantic
information but can be ignored when building a parser.)
The "Flavor Macro" here is like a BNF production, except
that it requires a consistent selection based on the
underlying HDL context - so in VHDL, HDL_MOD_NAME must
go to entity_aspect, and in other languages it must go to
a single Name that denotes a 'module' in whatever language
is involved.
Note that the syntax allows both '.' and '/' to be used as
separators in a pathname, and also allows them to be
intermixed in the same pathname.
One limitation of PSL today is that it does not deal with
blocks (including generate statements) nested within an
architecture - or rather, the PSL LRM does not acknowledge
the possibility that labels in a pathname might refer to
blocks rather than instances. In incorporating PSL into
VHDL 200x, we might consider clarifying this (which
clarification should eventually be merged back into some
future PSL v1.x LRM).
Another limitation is the fact that PSL doesn't consider
library logical names.
3.3 Wildcard path names
What you've outlined here addresses PSL requirements quite
well. Note that PSL only requires pathnames that end in
(designations of) declarative regions. A vunit is bound to
(all instances of) a design entity (or, if/when we extend it,
blocks within a design entity). Pathnames that identify
objects, processes, etc. are not of any use to PSL. It might
be worth giving a name (in the VHDL LRM) to a pathname that
designates a declarative region, so that we can say that
form of pathname is required as the "Hierarchical_HDL_Name"
in a PSL verification unit.
4. Concrete syntax.
Item 3: I definitely prefer a consistent syntax for
specifying secondary unit names that qualify primary
unit names. The 'entity_aspect' production is the oldest
occurrence of this, and for that reason it is arguably
better than using ':', especially given the conflict
with ':' elsewhere.
Note also that using "primaryname ( secondaryname )"
for design entities is consistent with the syntax for
referring to generated blocks - e.g., a.b(3).c, where
b is the label on a generate statement in a, and (3)
is the value of the for generate index for the block
of interest. Here, the generate index value 3 is
analogous to a secondary unit qualifier, where the
generate statement label b is analogous to a primary
unit name. I suppose a similar comment could be made
about names that involve signatures.
Item 5: Choice of separator
You say "The PSL committee currently uses '.' for
wildcard names (a form of design hierarchy name) in
order to avoid conflict with the use of ':' for
ranges in Verilog." This is essentially correct,
but the proper term is "Hierarchical HDL Name",
not "wildcard name".
Item 7. Choice of form for subprogram activation indicators
This is not an issue for PSL.
Item 8. Choice of syntax for subelements, etc.
PSL allows VHDL expressions to appear as the primitive
elements of a PSL declaration - e.g., for a signal S of
a type that is an array of records, I might write
assert never S(i).j'stable(1 ms);
However, this is entirely handled within the context of
VHDL expression syntax, so whatever choices are made
here will propagate to PSL as well. It is only the
pathname (i.e., "Hierarchical HDL Name) in a verification unit
that we need to address specially.
If you have any questions about the above, please email me or
call me at 410-750-6995.
Regards,
Erich
===============================================================================
===============================================================================
===============================================================================
2/14/2004, Francoise Martinolle, _[vhdl-200x-ft]_ FW: 'PATHNAME 'INSTANCENAME attribute specifications
Jim and other vhdl200x-ft,
The VHPI LRM was sent to a few experts for review.
We have received some of the review comments for VHPI.
One review comment was an objection against specifying the names of
implicit labels. The reviewer said that this should be fixed im VHDL 200x.
We feel that VHPI outght to provide unambiguous names for lookup capabilities,
hence VHPI specified a standard way of naming implicit labels where it
matters (loops, process, generates).
I would like to know if enhancing 'pathname and 'instancename has been considered
by vhdl 200x.
Below is the problem and action requested as well as the VHPI task force
response:
Problem:
The rules for implicit labels over specify what is required for a
reasonable VHPI functionality. It is important to support unique name
lookup but it is not necessary to impose the same convention on all
tools. If that is truly desired, then the change should be made to
define those conventions as part of the base language and correct the
underlying name attributes `PATHNAME and `INSTANCENAME.
Action:
Require tool providers to generate unique labels where statement
labels are optional but affect name properties and lookup as defined
in this section. Only require that handle-by-name work consistently
with names of objects returned by this tool. Alternatively, make the
fix to the base language to define implicit labels such that objects
will have unique names reflected in pre-defined name attributes.
REVIEWER'S COMMENTS
Accept: We will ask the vhdl 200x-ft to fix the 'PATHNAME and
'INSTANCENAME attribute specifications to be unambiguous for the cases
where it matters. However if the vhdl200x rejects the enhancement of
these attributes, there is merit in VHPI having these names
unambiguous for tool interoperability.
===============================================================================
===============================================================================
===============================================================================
2/14/2004, John Shields, _private email_ Re: Disambiguate 'pathname and 'instancename
Hi Jim,
My priority has been to resolve and close the VHPI issues and
complete this effort and that is still the case. I would be
happy to help with this, but it would be a lower priority for me.
I haven't heard much reaction to the problem in the VHDL community,
so I don't know what is likely to be acceptable. Erich and Peter may
have an opinion. I think the key to getting some traction is defining
what the requirements for a good solution are. For example:
How important is backward compatibility for the current pathname
and instance name attributes? They do not serve PSL and VHPI very
well, but changing definitions will affect some legacy design
simulation output. The VHPI approach was to define new name
properties in the information model that served the role of
unambiguous hierarchical reference by name to objects as well as
provide procedural access to the legacy attributes. There has been
some objection in the review and recommendation to simply fix the
existing attributes and use them. It is not strident and we are
asking the vhdl-200x group whether changing the existing attributes
has any likelihood of being accepted. I think nobody really knows.
How important is language interoperability? While VHPI has some
clear boundaries on dealing with interoperability of Verilog and
VHDL information models(i.e., an explicit non-goal), we tried to
avoid conflict and anticipate issues. VPI and VHPI can reasonably
co-exist. On the other hand, we did not model the VHDL information
model to account for a mixed language design, ( e.g., there is
only one root instance in the VHDL design hierarchy.) PSL clearly
has the need to address multiple language bindings and the name
attrbiute shortcomings are a bigger issue for Erich. I don't recall
the details, but defining the name syntax to be interoperable was a
requirement and changing the path separator from : to / was part
of the proposal.
How important is it to align all the needs into one common
solution vs. proliferate name attributes? We can have legacy,
VHPI, and PSL name properties defined straightforwardly with separate
definitions. We can try to create one set of new attributes and
leave the legacy attributes alone for a future lrm rev to deprecate.
We can aim to fix the current definitions and leave it to the
vendors to provide lrm version specific behavior in products.
My point is that I am happy to help, but I would like to take good aim.
Regards, John
===============================================================================
===============================================================================
===============================================================================
Let me know if there are any I missed