Subject: RE: Reminder: LRM Committee Call
From: Martin O'Leary (oleary@cadence.com)
Date: Mon Apr 08 2002 - 21:59:37 PDT
Kevin,
I get the same result with XL and it is interesting to know that NaN does
propagate through.
However I think this is besides the point. My first point is that for a real
variable to become NaN when it is assigned to an expression containing X,Zs
is a violation of Verilog Standard. My second point is that even
if this behavior only occurred in the analog block, the language
would be more inconsistent and complex than necessary.
Note that in Verilog, when a real variable is assigned to an expression
containing X,Zs, the result is that the real variable is set to 0.
In the Verilog-AMS LRM, it is currently an error if a real variable is
assigned to an expression containing Xs, Zs in an analog block. If we
are to relax this situation, it is wiser that we should be consistent
with what Verilog does and set the real variable to 0 rather than NaN.
Similarly going forward if an integer variable assigned to an expression
containing X,Zs in the analog block, the integer variable should contain X,Zs.
This would go a long way towards unifying the expression language in
analog and digital blocks. This would make Verilog-AMS easier for existing
Verilog users to learn and make it easier to define many of the
semantics of expressions in analog block (the LRM would just refer to the
appropriate sections in the Verilog-D LRM rather than redefining!). Users
could cut-and-paste code from digital blocks to analog blocks without
having to worry about different behaviors in the expressions between digital
and analog blocks.
Doing anything different in the analog block will only give
rise to confusion as users familiar with Verilog will find
NaN result somewhat unexpected. There are a lot of Verilog users out there
- there are not that many Verilog-AMS/Verilog-A users, we need to make the language
easy for Verilog users to learn.
Having real variable is assigned to an expression containing X,Zs become
NaN would mean that if manuals or books about Verilog-AMS, they will
contain the phrase like "except in the analog block" which doesn't give
the impression of a consistent lanuage.
It also means that users will have to remember yet another quirk and
exception about this "mysterious" analog block.
That said, I can see that NaN would be useful for other purposes in the
language and so would be a helpful addition.
Thanks,
--Martin
> -----Original Message-----
> From: Kevin Cameron x3251 [mailto:Kevin.Cameron@nsc.com]
> Sent: Monday, April 08, 2002 7:06 PM
> To: Martin O'Leary
> Cc: Srikanth Chandrasekaran; Verilog-AMS Committee
> Subject: Re: Reminder: LRM Committee Call
>
>
> Martin O'Leary wrote:
> >
> > (XZ example for conf call.)
> >
> > // nan.v
> >
> > module foo;
> >
> > real r;
> > integer i;
> >
> > initial begin
> > i = 1'bX;
> > r = 1'bX;
> > $strobe("r =",r);
> > $strobe("i =",i);
> > end
> >
> > endmodule
> >
> > This gives the following output;
> >
> > i = X
> > r =0
>
> - same with VCS, but this also works:
>
> module foo;
>
> real r;
> integer i;
>
> initial begin
> i = 1'bX;
> r = $bitstoreal(64'hFFFFFFFFFFFFFFFF);
> $strobe("r =",r);
> $strobe("i =",i);
> end
>
> endmodule
>
> >>> gives
>
> i = X
> r =-NaN
>
>
> - i.e. you can propagate NaN through Verilog-D.
>
> Kev.
>
>
> --
> National Semiconductor
> 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>
This archive was generated by hypermail 2b28 : Mon Apr 08 2002 - 22:01:17 PDT