ISSUE 635

Number

635

Category

errata

Synopsis

2005D4/12.5: overly restrictive hierref limitation

State

lrmdraft

Class

errata-simple

Arrival-Date

Nov 18 2004

Originator

"Warmke, Doug" <doug_warmke@mentorg.com>

Release

2005_D3

Description

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4CDEE.992F8360
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello BTF,
=20
In Section 12.4 of 1364-2005_D3, it is stated that automatic tasks and
functions
do not form branches of hierarchy, and that they can not be referenced
using
hierarchical reference syntax.
=20
This is in contraction to sections 10.2.1 and 10.3.1, which state that
automatic
tasks and functions can be invoked through their hierarchical names.
(Thus
implying that they must be at the least "leaf nodes" in the hierarchical
tree)
=20
Furthermore, the automatic keyword can be applied to variables in scopes
other than tasks and functions. These automatic variables should not be
accessed by hierarchical reference syntax, but currently there is
nothing
in the LRM restricting such access.
=20
Finally, SystemVerilog makes use of the "static" keyword to give
certain items in automatic tasks and functions static lifetimes.
=20
We propose the following change in Section 12 of 1364-2005_D3.
This will get rid of the contradictions in 10.2.1 and 10.3.1, and it
paves
the way for hierarchical access to static items in automatic tasks and
functions in SystemVerilog.
=20

MODIFY Section 12.4 as follows.

=20

At the top of the name hierarchy are the names of one or more root
modules of which no instances have been

created. This root or these parallel root modules make up one or more
hierarchies in a design description or

description. Inside any module, each module instance (including an
arrayed or generated instance), task definition,

function definition, and named begin-end or fork-join block shall define
a new branch of the

hierarchy. Named blocks within named blocks and within tasks and
functions shall create new branches.

Automatic tasks and functions are exceptions, and do not create visible
branches that can be referenced (see

10.2.1and 10.3.1). It shall be an error to access automatic items using
hierarchical reference syntax.
=20
Thanks and regards,
Doug

------_=_NextPart_001_01C4CDEE.992F8360
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR>

Hello=20
BTF,

In Section 12.4 of 1364-2005_D3, it is =
stated that=20
automatic tasks and functions

do not form branches of hierarchy, and =
that they=20
can not be referenced using

hierarchical reference =
syntax.

This is in contraction to sections =
10.2.1 and=20
10.3.1, which state that automatic

tasks and functions can be invoked =
through their=20
hierarchical names. (Thus

implying that they must be at the least =
"leaf=20
nodes" in the hierarchical tree)

Furthermore, the automatic keyword can =
be applied=20
to variables in scopes

other than tasks and functions. =
These=20
automatic variables should not be

accessed by hierarchical reference =
syntax, but=20
currently there is nothing

in the LRM restricting such =
access.

Finally, SystemVerilog makes use of the =
"static"=20
keyword to give

certain items in automatic tasks and =
functions=20
static lifetimes.

We propose the following change in =
Section 12 of=20
1364-2005_D3.

This will get rid of the contradictions =
in 10.2.1=20
and 10.3.1, and it paves

the way for hierarchical access to =
static items in=20
automatic tasks and

functions in =
SystemVerilog.

MODIFY =
Section 12.4 as=20
follows.

<SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times =
New Roman'"><?xml:namespace=20
prefix =3D o ns =3D "urn:schemas-microsoft-com:office:office" =
/><o:p><FONT=20
size=3D2> </o:p>

<SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times =
New Roman'"><FONT=20
size=3D2>At the top of the name hierarchy are the names of one or more =
root=20
modules of which no instances have been<o:p></o:p>

<SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times =
New Roman'"><FONT=20
size=3D2>created. This root or these parallel root modules make up one =
or more=20
hierarchies in a design description =
or<o:p></o:p>

<FONT=20
size=3D2><SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times =
New Roman'">function=20
definition, and named <SPAN=20
style=3D"FONT-FAMILY: Courier; mso-fareast-font-family: 'Times New =
Roman'; mso-bidi-font-family: Courier">begin-end=20
<SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times =
New Roman'">or=20
<SPAN=20
style=3D"FONT-FAMILY: Courier; mso-fareast-font-family: 'Times New =
Roman'; mso-bidi-font-family: Courier">fork-join=20
<SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times =
New Roman'">block=20
shall define a new branch of the<o:p></o:p>

<SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times =
New Roman'"><FONT=20
size=3D2>hierarchy. Named blocks within named blocks and within tasks =
and=20
functions shall create new branches.<o:p></o:p>

<SPAN=20
class=3D1delete><STRIKE>Automatic =
tasks and=20
functions are exceptions, and do not create visible branches that can be =

referenced (see<o:p></o:p></STRIKE>

<STRIKE><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: TimesNewRoman; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA">10.2.1and=20
10.3.1).<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: TimesNewRoman; TEXT-DECORATION: =
none; mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times =
New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA; text-line-through: none"><SPAN=20
style=3D"TEXT-DECORATION: none; text-line-through: none">=20
</STRIKE><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: TimesNewRoman; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
color=3D#0000ff>It shall be an error to access automatic items using =
hierarchical=20
reference syntax.

<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: TimesNewRoman; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
color=3D#0000ff>

------_=_NextPart_001_01C4CDEE.992F8360--

Fix

In 1364-2005/D4, 12.5 ("Hierarchical names"):

DELETE the sentence:

"Automatic tasks and functions are exceptions, and do not
create visible branches that can be referenced (see 10.2.1
and 10.3.1)."

CHANGE the sentence

"Unnamed generate blocks are also exceptions."

TO

"Unnamed generate blocks are exceptions."

Audit-Trail

Analyzed by doug_warmke@mentor.com on Thu Nov 18 20:17:45 2004
The HTML email proposal didn't work out well.
Here is an ASCII text version:

In Section 12.4, REPLACE this sentence:
Automatic tasks and functions are exceptions, and do not create visible branches that can be referenced (see 10.2.1 and 10.3.1).

WITH this sentence:
It shall be an error to access automatic items using hierarchical reference syntax.

From: Shalom.Bresticker@freescale.com
To: "Warmke, Doug" <doug_warmke@mentorg.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/635: - overly restrictive hierref limitation
Date: Tue, 23 Nov 2004 12:37:43 +0200 (IST)

Doug,

You proposed:

> In Section 12.4, REPLACE this sentence:
> Automatic tasks and functions are exceptions, and do not create visible branches that can be
> referenced (see 10.2.1 and 10.3.1).
>
> WITH this sentence:
> It shall be an error to access automatic items using hierarchical reference syntax.

You correctly point out that 10.2.1 and 10.3.1 say that automatic tasks and
functions can be invoked hierarchically. They also say that
"Automatic function(task) items can not be accessed by hierarchical references."

12.5 in D4 (12.4 in D3) currently says,
"A design description contains one or more top-level modules (see 12.1.1). Each such module forms the top of a name hierarchy. This root or these parallel root modules make up one or more hierarchies in a design description or description. Inside any module, each module instance (including an arrayed instance), generate block instance, task definition, function definition, and named begin-end or fork-join block shall define a new branch of the hierarchy. Named blocks within named blocks and within tasks and functions shall create new branches. Automatic tasks and functions are exceptions, and do not create visible branches that can be referenced (see 10.2.1and 10.3.1). Unnamed generate blocks are also exceptions. They create branches that are visible only from within the block and within any hierarchy instantiated by the block. See 12.4.3 for a discussion of unnamed generate blocks."

It also says, 2 paragraphs afterward,
"Objects declared in automatic tasks and functions are exceptions, and cannot be accessed by hierarchical name references."

I think it would be simpler to simply delete from the first quoted paragraph the sentence,
"Automatic tasks and functions are exceptions, and do not create visible branches that can be referenced (see 10.2.1and 10.3.1)."
and then change "also exceptions" in the next sentence to simply "exceptions".
That still leaves the sentence 2 paragraphs down about items in automatic tasks and functions.

You also said,
> Furthermore, the automatic keyword can be applied to variables in scopes
> other than tasks and functions.

This is not true in 1364. The BNF allows the automatic keyword only on tasks and functions.
You apparently mean SystemVerilog.
The place for the restriction you want is in 1800, not in 1364.

Still, you did point out a reasonable source of confusion in 12.4/12.5.

Thanks,
Shalom

On Thu, 18 Nov 2004, Warmke, Doug wrote:

> Hello BTF,
>
> In Section 12.4 of 1364-2005_D3, it is stated that automatic tasks and
> functions
> do not form branches of hierarchy, and that they can not be referenced
> using
> hierarchical reference syntax.
>
> This is in contraction to sections 10.2.1 and 10.3.1, which state that
> automatic
> tasks and functions can be invoked through their hierarchical names.
> (Thus
> implying that they must be at the least "leaf nodes" in the hierarchical
> tree)
>
> Furthermore, the automatic keyword can be applied to variables in scopes
> other than tasks and functions. These automatic variables should not be
> accessed by hierarchical reference syntax, but currently there is
> nothing
> in the LRM restricting such access.
>
> Finally, SystemVerilog makes use of the "static" keyword to give
> certain items in automatic tasks and functions static lifetimes.
>
> We propose the following change in Section 12 of 1364-2005_D3.
> This will get rid of the contradictions in 10.2.1 and 10.3.1, and it
> paves
> the way for hierarchical access to static items in automatic tasks and
> functions in SystemVerilog.

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary

From: "Warmke, Doug" <doug_warmke@mentorg.com>
To: <Shalom.Bresticker@freescale.com>, <etf-bugs@boyd.com>
Cc:
Subject: RE: errata/635: - overly restrictive hierref limitation
Date: Tue, 23 Nov 2004 08:44:05 -0800

Shalom,

Thanks for considering and analyzing this issue.
Your solution is good enough for 1364 and it's
fine with me.

However, do we want to take an approach in which we
leave 1364 perfectly accurate w.r.t. Verilog-2005,
but also remove anything that is contradictory or
ambiguous when looking at 1800+1364? My feeling is
that this project will be undertaken sooner or later.
My original proposal was trying to do some of it sooner.

If we go the route of looking forward to 1800, I think
that we should stick with my original proposal. And
in addition, we should remove the sentence you pointed
out two paragraphs later:

Objects declared in automatic tasks and functions are
exceptions, and cannot be accessed by hierarchical name
references.

The reason is that in 1800, there can be both static and
automatic objects automatic tasks and functions. This sentence
presumes that the only way an item can be automatic is to be
declared inside an automatic task or function. (Also not
true in SV).

The restriction in my proposal about "automatic items" takes
care of what this sentence addresses, plus it takes care of all
other kinds of automatic items in SV.

Anyways, I'll go along with whatever the 1364 WG wants to do.
Just thought I'd point out that we have the opportunity to
converge a little bit between 1364 and 1800 here.

Regards,
Doug

> -----Original Message-----
> From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On
> Behalf Of Shalom.Bresticker@freescale.com
> Sent: Tuesday, November 23, 2004 2:30 AM
> To: etf-bugs@boyd.com
> Subject: Re: errata/635: - overly restrictive hierref limitation
>
> The following reply was made to PR errata/635; it has been
> noted by GNATS.
>
> From: Shalom.Bresticker@freescale.com
> To: "Warmke, Doug" <doug_warmke@mentorg.com>
> Cc: etf-bugs@boyd.com
> Subject: Re: errata/635: - overly restrictive hierref limitation
> Date: Tue, 23 Nov 2004 12:37:43 +0200 (IST)
>
> Doug,
>
> You proposed:
>
> > In Section 12.4, REPLACE this sentence:
> > Automatic tasks and functions are exceptions, and do not
> create visible branches that can be
> > referenced (see 10.2.1 and 10.3.1).
> >
> > WITH this sentence:
> > It shall be an error to access automatic items using
> hierarchical reference syntax.
>
> You correctly point out that 10.2.1 and 10.3.1 say that
> automatic tasks and
> functions can be invoked hierarchically. They also say that
> "Automatic function(task) items can not be accessed by
> hierarchical references."
>
> 12.5 in D4 (12.4 in D3) currently says,
> "A design description contains one or more top-level modules
> (see 12.1.1). Each such module forms the top of a name
> hierarchy. This root or these parallel root modules make up
> one or more hierarchies in a design description or
> description. Inside any module, each module instance
> (including an arrayed instance), generate block instance,
> task definition, function definition, and named begin-end or
> fork-join block shall define a new branch of the hierarchy.
> Named blocks within named blocks and within tasks and
> functions shall create new branches. Automatic tasks and
> functions are exceptions, and do not create visible branches
> that can be referenced (see 10.2.1and 10.3.1). Unnamed
> generate blocks are also exceptions. They create branches
> that are visible only from within the block and within any
> hierarchy instantiated by the block. See 12.4.3 for a
> discussion of unnamed generate blocks."
>
> It also says, 2 paragraphs afterward,
> "Objects declared in automatic tasks and functions are
> exceptions, and cannot be accessed by hierarchical name references."
>
> I think it would be simpler to simply delete from the first
> quoted paragraph the sentence,
> "Automatic tasks and functions are exceptions, and do not
> create visible branches that can be referenced (see 10.2.1and
> 10.3.1)."
> and then change "also exceptions" in the next sentence to
> simply "exceptions".
> That still leaves the sentence 2 paragraphs down about items
> in automatic tasks and functions.
>
> You also said,
> > Furthermore, the automatic keyword can be applied to
> variables in scopes
> > other than tasks and functions.
>
> This is not true in 1364. The BNF allows the automatic
> keyword only on tasks and functions.
> You apparently mean SystemVerilog.
> The place for the restriction you want is in 1800, not in 1364.
>
> Still, you did point out a reasonable source of confusion in
> 12.4/12.5.
>
> Thanks,
> Shalom
>
>
> On Thu, 18 Nov 2004, Warmke, Doug wrote:
>
> > Hello BTF,
> >
> > In Section 12.4 of 1364-2005_D3, it is stated that
> automatic tasks and
> > functions
> > do not form branches of hierarchy, and that they can not
> be referenced
> > using
> > hierarchical reference syntax.
> >
> > This is in contraction to sections 10.2.1 and 10.3.1,
> which state that
> > automatic
> > tasks and functions can be invoked through their
> hierarchical names.
> > (Thus
> > implying that they must be at the least "leaf nodes" in
> the hierarchical
> > tree)
> >
> > Furthermore, the automatic keyword can be applied to
> variables in scopes
> > other than tasks and functions. These automatic variables
> should not be
> > accessed by hierarchical reference syntax, but currently there is
> > nothing
> > in the LRM restricting such access.
> >
> > Finally, SystemVerilog makes use of the "static" keyword to give
> > certain items in automatic tasks and functions static lifetimes.
> >
> > We propose the following change in Section 12 of 1364-2005_D3.
> > This will get rid of the contradictions in 10.2.1 and
> 10.3.1, and it
> > paves
> > the way for hierarchical access to static items in
> automatic tasks and
> > functions in SystemVerilog.
>
> --
> Shalom Bresticker Shalom.Bresticker
> @freescale.com
> Design & Verification Methodology Tel:
> +972 9 9522268
> Freescale Semiconductor Israel, Ltd. Fax:
> +972 9 9522890
> POB 2208, Herzlia 46120, ISRAEL Cell:
> +972 50 5441478
>
> [ ]Freescale Internal Use Only [ ]Freescale
> Confidential Proprietary
>
>
>

Fix replaced by Shalom.Bresticker@freescale.com on Wed Nov 24 05:23:06 2004
Two alternate proposals:

In 1364-2005/D4, 12.5 ("Hierarchical names"):

PROPOSAL A (Doug Warmke):

REPLACE this sentence:

"Automatic tasks and functions are exceptions, and do not
create visible branches that can be referenced (see 10.2.1
and 10.3.1)."

WITH this sentence:

"It shall be an error to access automatic items using
hierarchical reference syntax."

PROPOSAL B (Shalom Bresticker):

DELETE the sentence:

"Automatic tasks and functions are exceptions, and do not
create visible branches that can be referenced (see 10.2.1
and 10.3.1)."

CHANGE the sentence

"Unnamed generate blocks are also exceptions."

TO

"Unnamed generate blocks are exceptions."

Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 29 09:41:52 2004
In 1364-2005/D4, 12.5 ("Hierarchical names"):

DELETE the sentence:

"Automatic tasks and functions are exceptions, and do not
create visible branches that can be referenced (see 10.2.1
and 10.3.1)."

CHANGE the sentence

"Unnamed generate blocks are also exceptions."

TO

"Unnamed generate blocks are exceptions."

Unformatted