Subject: RE: Reminder: LRM Committee Call
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Tue Apr 09 2002 - 10:00:13 PDT
[
For V++ readers this is part of a discussion on what to do
with 'X' & 'Z' when cast to 'real'. Using NaN (Not-a-Number)
rather than zero makes it easy/efficient to handle, but may
clash with standard Verilog, so I'm looking for feedback from
the digital community.
Note: IEEE FP hardware handles NaN automatically and therefore
makes run-time arithmetic a lot faster by eliminating the need
for seperate X/Z testing when doing FP arithmetic.
]
> From owner-verilog-ams@eda.org Mon Apr 8 22:02:33 2002
>
> 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.
If a bit in the 'bitstoreal' pattern is X/Z then it's actual value (1/0)
is unknown and is being taken as 0 arbitrarily. If any unknown bit was
given the bit value from NaN instead a large percentage of partially
unknown patterns would then be read as NaN - which will propagate through
FP arithmetic in a manner similar to 'X' in logic calculation.
> 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.
I would consider that extremely unwise, Xs and Zs should propagate as
far as possible. [System]Verilog should adopt the use of NaN so that
invalid values do not turn into valid values unnecessarily.
> 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.
The only thing being redefined is the bit pattern for unknown bits in a real.
> 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.
They should only see NaN if their model is broken - which is less expensive
than non-working Silicon.
> 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.
SystemVerilog has new data types and semantics, making the X/Z/NaN stuff
work the same everywhere is trivial, and users are unlikely to run into
it often. The manuals are regularly rehashed anyway, and digital and
analog designers generally avoid each others code :-)
Regards,
Kev.
> 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 : Tue Apr 09 2002 - 10:03:34 PDT