escaped identifier vs regular names ?

[m]

Hi,
Do escaped identifiers define a different name space than nonescaped
identifiers ? The spec only mentions that a keyword cannot be escaped
but for regular identifiers it says "\cpu3 " is the same as "cpu3".
The issue is that my synthesizer generates output like:

buf u0 (.out(\OUT[3] ), .in(in[3]));
buf u1(.out(OUT[3]), .in(\OUT[3] ));

so it's using "\OUT[3] " as a distinct name which is not the same as
an index into bus OUT. This confuses the hell out of a verilog to
spice converter I am using for LVS. Is this use kosher ? Any comments
would be appreciated. Also if anyone knows how to convince Buildgates
not to generate output like this, that would be helpful too.

Thanks ahead.

 

[Chris F Clark]

Escaped identifiers are not in a separate namespace from normal
identifiers. However, all non-whitepsace special characters are part
of the itentifier name after a \, upto the terminating whitespace
character. Technically, (if I recall correctly) the standard requires
the terminating whitespace character to be a space character, but I
wouldn't want to try using a newline or tab character in an escaped
identifier, as there are too many ways that a space character might
invisibly get inserted there.

Thus, in your code, the text "\OUT[3] " is talking about an identifier
with brackets in the name, and not an identifier with a bit select.
The escaped name with a bit select would look like "\OUT [3]". Notice
the different placement of the space character.

And, yes, many Verilog tools create escaped names of this form. The
idea is to turn a name which is a bit select of a 1 bit net from a
vector, into a scalar net with "roughly" the same name (so that the
tool doesn't have to invent some unique garbage name). And, it is not
an index into the bus (vector net) out. It is a separate and distinct
net. It probably is connected via a port to the desired bit on the
bus, but it doesn't have to be--actually, in your example, it is
connected to the desired net by the buffer u1. Note, if the escaped
name was the same as the indexed vector, "\OUT[3] " was the same as
"OUT[3]", then the buffer u1 would connect its inputs and outputs to
the same net.

If your Verilog to Spice converter cannot deal with these form of
escape names, it isn't really handling the entire Verilog language.
Of course, that wouldn't be surprising as many tools deal with subsets
of the language and claim to process "Verilog". (The tool I work on
does the same (supports only a subset, but one which does include that
escape name rule), but it's for internal only use, so its deficiencies
are our problem, not yours.)

You probably could write an Perl script (or Emacs macro, etc.) that
makes the escaped names into truly unique names. That could help you
cover over the deficiency of your converter.

Of course, the other possibility is that the converter is handling the
names properly, and you are confused--thinking that the two nets
should be the same, when they aren't. That would be an easy mistake
to make too. There are more than a few parts of Verilog where the
correct interpretation isn't the "obvious" one and one has to read the
rules carefully a couple of times before catching the subtle points of
what is really written. After 5 years of working on a Verilog
implementation, there are still parts that I don't understand. And,
Verilog isn't the worst language in that regard.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

 

[Rob Dekker]

"mk" <kal*@dspia.*comdelete> wrote in message news:6psng1lontamt782ruej62k5im6v39unr3@4ax.com...

Hi,
Do escaped identifiers define a different name space than nonescaped
identifiers ? The spec only mentions that a keyword cannot be escaped
but for regular identifiers it says "\cpu3 " is the same as "cpu3".
The issue is that my synthesizer generates output like:

buf u0 (.out(\OUT[3] ), .in(in[3]));
buf u1(.out(OUT[3]), .in(\OUT[3] ));

so it's using "\OUT[3] " as a distinct name which is not the same as
an index into bus OUT. This confuses the hell out of a verilog to
spice converter I am using for LVS. Is this use kosher ? Any comments
would be appreciated. Also if anyone knows how to convince Buildgates
not to generate output like this, that would be helpful too.

The escaped name might be confusing to a poor Verilog tool, but it is legal Verilog, and should be parsed appropriately.

But there is a real problem with these statements.
They instantiate a Verilog 'buf' gate, which is a built-in function.
These 'buf's cannot use named (.<portname>(<actual&gt) association.
The idea is that 'buf' has unnamed ports.
Every tool I tried gives errors like this :

escapetest.v(10): ERROR: name-based port connection not allowed in gate-instantiation

or

escapetest.v(10): near ".": syntax error, unexpected '.', expecting "'{"

or

Error-[SE] Syntax error
"escapetest.v", 10: token is '.'
buf u0 (.out(\OUT[3] ), .in(in[3]));
^

I doubt that BuildGates outputs this exactly, but if they do, it is a clear bug in their gate-level writer.

Thanks ahead.

 

[m]

On 24 Aug 2005 11:13:09 -0400, Chris F Clark
<cfc@shell01.TheWorld.com> wrote:

" is talking about an identifier
with brackets in the name, and not an identifier with a bit select.

This makes sense and is what I assumed.

Note, if the escaped
name was the same as the indexed vector, "\OUT[3] " was the same as
"OUT[3]", then the buffer u1 would connect its inputs and outputs to
the same net.

Actually this is exactly what the conversion tool I am using is doing
and it is causing LVS errors as the netlist becomes bogus with the
buffer's output connected to its input.

Of course, the other possibility is that the converter is handling the
names properly, and you are confused--thinking that the two nets
should be the same, when they aren't.

As I mentioned it looked like to converter was doing something wrong
and I updated the nets by hand to remove the brackets and after that
everything went well. Finally clean LVS.

Thanks.