ISSUE 307

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 307
Category errata
Synopsis 27.19 what happenes with escaped identifiers
State open
Class errata-ptf
Arrival-DateMar 21 2003
Originator Stephen Williams <steve@icarus.com>
Release 2001b
Environment
Description
Section 27.19 does not discuss what to do with:

- strings containing names which should be escaped, but
are not.
- strings containing names which do not need to be
escaped, but are.

In addition, there is no explanation anywhere about what
is returned when an application asks for the name of an
identifier. When should names be escaped?
Fix
Add a paragraph to section 27.19, something like this:

The name argument shall be interpeted the same way that
names are interpeted within the HDL. Identifiers which
need to be escaped must be escaped in the string pointed
to by name. Identifiers which do not need to be escaped
can be escaped without any effect.

Add a section 26.3.5:

26.3.5 Object name properties

The properties vpiName, vpiFullName and vpiDefName return
the names of identifiers from the HDL. These names will
be escaped only when it is necessary to escape them,
regardless of how they are specified within the HDL.
Audit-Trail

From: Stephen Williams <steve@icarus.com>
To: chas@cadence.com
Cc: ptf-bugs@boyd.com
Subject: Re: pending/307: 27.19 what happenes with escaped identifiers
Date: Mon, 24 Mar 2003 14:44:25 -0800

> - strings containing names which should be escaped, but
> are not.
> - strings containing names which do not need to be
> escaped, but are.

Hmm, the vpiName property of an object returns a string that is
the non-hierarchical name of the object. In principle, there is
no need at all for that name to include escape characters. For
example:

wire \foo.bar ;
vpi_get_str(vpiName, obj) --> "foo.bar"

There is nothing ambiguous in that, the string "foo.bar" is the
name of the object, no confusion.

I propose that vpiName not ever include the escape characters,
they are a part of the data entry details, and not part of the
name itself. The C programmer need not guess or cope with the
escape sequences, because the string is not otherwise structured.

Things get decidedly more icky with vpiFullName. In this case,
the simulator should indeed add the escape characters because
the C code is expected to possibly parse the hierarchical name.
The C code in this case may need to know that a '.' in the string
has been escaped.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."



From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: ptf-bugs@boyd.com
Cc:
Subject: errata/307:
27.19 what happenes with escaped identifiers
Date: Tue, 15 Apr 2003 12:31:11 +0300

This is a multi-part message in MIME format.
--------------C304A6C35FF78BACC3D93AF7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael.Rohleder@motorola.com wrote:

> Thanks. As a matter of fact, my wishlist would be to have two functions, one
> providing the name without escaped identifiers, a second where escaped
> identifiers are preserved.

--------------C304A6C35FF78BACC3D93AF7
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from zuk14exr01.mot.com ([10.128.132.48]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
id 1R9B72YR; Tue, 15 Apr 2003 11:10:21 +0300
Received: from zwg18exm01.corp.mot.com (zwg18exm01.sps.mot.com [10.170.73.30])
by zuk14exr01.mot.com (Motorola/8.11.6) with ESMTP id h3FEKjV03218
for <Shalom.Bresticker@motorola.com>; Tue, 15 Apr 2003 09:20:45 -0500
Received: from motorola.com (10.170.70.169 [10.170.70.169]) by zwg18exm01.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
id W97YSNWH; Tue, 15 Apr 2003 10:10:15 +0200
Message-ID: <3E9BBE5F.BEB2B9B5@motorola.com>
Date: Tue, 15 Apr 2003 10:10:07 +0200
From: Michael Rohleder<Michael.Rohleder@motorola.com>
Reply-To: Michael.Rohleder@motorola.com
Organization: Motorola Semiconductor Products Sector
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Shalom Bresticker<Shalom.Bresticker@motorola.com>
Subject: Re: [Fwd: ISSUE 307]
References: <3E9BA740.1686E026@motorola.com>
Content-Type: multipart/mixed;
boundary="------------0E59DA1EAAED64A88DF7D5E2"

This is a multi-part message in MIME format.
--------------0E59DA1EAAED64A88DF7D5E2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks,

as a matter of fact, my wishlist would be to have two functions, one
providing the name without escaped identifiers, a second where escaped
identifiers are preserved.


-Michael


Shalom Bresticker wrote:




--

Shalom Bresticker
Shalom.Bresticker@motorola.com

Design & Reuse Methodology Tel: +972 9
9522268

Motorola Semiconductor Israel, Ltd. Fax: +972 9
9522890

POB 2208, Herzlia 46120, ISRAEL Cell: +972 50
441478






_____


Subject: ISSUE 307
Date: Mon, 14 Apr 2003 17:52:23 +0300
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>

http://www.boyd.com/1364_btf/report/full_pr/307.html
<http://www.boyd.com/1364_btf/report/full_pr/307.html>



--

Shalom Bresticker
Shalom.Bresticker@motorola.com

Design & Reuse Methodology Tel: +972 9
9522268

Motorola Semiconductor Israel, Ltd. Fax: +972 9
9522890

POB 2208, Herzlia 46120, ISRAEL Cell: +972 50
441478








_____


ISSUE 307

Add <http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=propose&pr=307>
Proposal Add
<http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=analyze&pr=307>
Analysis Edit
<http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=changeclass&pr=307>
Class, Environment, or Release
Number 307
Category errata
Synopsis 27.19 what happenes with escaped identifiers
State open
Class errata-ptf
Arrival-Date Mar 21 2003
Originator Stephen Williams <steve@icarus.com>
Release 2001b
Environment
Description
Section 27.19 does not discuss what to do with:


- strings containing names which should be escaped, but
are not.
- strings containing names which do not need to be
escaped, but are.


In addition, there is no explanation anywhere about what
is returned when an application asks for the name of an
identifier. When should names be escaped?
Fix
Add a paragraph to section 27.19, something like this:


The name argument shall be interpeted the same way that
names are interpeted within the HDL. Identifiers which
need to be escaped must be escaped in the string pointed
to by name. Identifiers which do not need to be escaped
can be escaped without any effect.


Add a section 26.3.5:


26.3.5 Object name properties


The properties vpiName, vpiFullName and vpiDefName return
the names of identifiers from the HDL. These names will
be escaped only when it is necessary to escape them,
regardless of how they are specified within the HDL.
Audit-Trail
From: Stephen Williams <steve@icarus.com>
To: chas@cadence.com
Cc: ptf-bugs@boyd.com
Subject: Re: pending/307: 27.19 what happenes with escaped identifiers
Date: Mon, 24 Mar 2003 14:44:25 -0800


> - strings containing names which should be escaped, but
> are not.
> - strings containing names which do not need to be
> escaped, but are.


Hmm, the vpiName property of an object returns a string that is
the non-hierarchical name of the object. In principle, there is
no need at all for that name to include escape characters. For
example:


wire \foo.bar ;
vpi_get_str(vpiName, obj) --> "foo.bar"


There is nothing ambiguous in that, the string "foo.bar" is the
name of the object, no confusion.


I propose that vpiName not ever include the escape characters,
they are a part of the data entry details, and not part of the
name itself. The C programmer need not guess or cope with the
escape sequences, because the string is not otherwise structured.


Things get decidedly more icky with vpiFullName. In this case,
the simulator should indeed add the escape characters because
the C code is expected to possibly parse the hierarchical name.
The C code in this case may need to know that a '.' in the string
has been escaped.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com <http://www.picturel.com> And lines to code
before I sleep."



Hosted by Boyd Technology <http://www.boydtechinc.com>


--


NOTE: The content of this message may contain personal views
which are not neccessarily the views of Motorola, unless
specifically stated.


___________________________________________________
| |
_ | Michael Rohleder Tel: +49-89-92103-259 | _
/ )| Software Technologist Fax: +49-89-92103-680 |( \
/ / | Motorola, Semiconductor Products, System Design | \ \
_( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
(((\ \>|_/ > < \_|</ /)))
(\\\\ \_/ / mailto:Michael.Rohleder@motorola.com
<mailto:Michael.Rohleder@motorola.com> \ \_/ ////)
\ /_______________________________________________\ /
\ _/ \_ /
/ / \ \


The information contained in this email has been classified as:
Motorola General Business Information (x)
Motorola Internal Use Only ( )
Motorola Confidential Proprietary ( )



*** This note may contain Motorola Confidential Proprietary or
Motorola Internal Use Only Information and is intended to be
reviewed by only the individual or organization named above.
If you are not the intended recipient or an authorized
representative
of the intended recipient, you are hereby notified that any review,
dissemination or copying of this email and its attachments, if any,
or the information contained herein is prohibited. If you have
received
this email in error, please immediately notify the sender by
return email and delete this email from your system.
Thank you! ***



--------------0E59DA1EAAED64A88DF7D5E2
Content-Type: text/x-vcard; charset=us-ascii;
name="michael.rohleder.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Michael Rohleder
Content-Disposition: attachment;
filename="michael.rohleder.vcf"

begin:vcard
n:Rohleder;Michael
tel;fax:++49-89-92103-680
tel;work:++49-89-92103-259
x-mozilla-html:FALSE
org:Motorola Semiconductor Products Sector;System Design Methodology
version:2.1
email;internet:Michael.Rohleder@motorola.com
title:Software Technologist
adr;quoted-printable:;;Motorola=0D=0ASemiconductor Products Sector=0D=0ASchatzbogen 7=0D=0AD-81829 Muenchen=0D=0A =0D=0A;Munich;;D-81829;Germany
fn:Michael Rohleder
end:vcard

--------------0E59DA1EAAED64A88DF7D5E2--

--------------C304A6C35FF78BACC3D93AF7--

Unformatted




Hosted by Boyd Technology