Subject: Re: Proposal for rewriting Section 8.3.2
From: Srikanth Chandrasekaran (schandra@asc.corp.mot.com)
Date: Mon Oct 29 2001 - 20:29:17 PST
Hi Kevin,
Please see comments inserted.
Kevin Cameron x3251 wrote:
> > Example:
> > input net[1:2];
> > analog begin
> > case(net[1])
> > 1'b1: $strobe("net[1] = 1");
> > 1'b0: $strobe("net[1] = 0");
> > 1'bz: $strobe("net[1] = z");
> > 1'bx: $strobe("net[1] = x");
> > net[2]:$strobe("net[1] == net[2]");
>
> I don't think you can have a variable as a case target, can you?
>
case_item ::=
expression { , expression } : statement_or_null
| default [ : ] statement_or_null
According to the syntax for the case statement (section 6.5), the use of
variables is allowed in the case item's expression. However analog case
statement has a restriction.
> > Let us know if you have any issues with this proposal.
>
> "vendor specific" is a bad idea. There is a standing proposal to introduce
> NaN, it was intended that arithmetic involving Xs and Zs would return NaN
> in a continuous context which would propagate much the same way as X
> propagates
> in a digital context, and that assigning it to a branch would be (runtime)
> illegal.
The first occurrence of "vendor specific" was inserted because of the
lack of detail in table within section 8.3.1 where the LRM should state
what the implicit conversion should do when x and z bits are
encountered. These "vendor specific" statements in the proposal state
what is implied by the LRM for clarity sake. Is it a bad idea to
explicitly state "vendor specific" when we already allow vendor specific
features implicitly in the LRM by leaving some of the issues open?
The LRM in its current form is not symmetrical when it comes to access
opposite context nets and probe data. Specifically, in the analog
context a digital net access returns only 50% of the value range (x and
z are not supported) while in the digitial context a analog probe access
returns 100% of it value range (entire real value range is supported).
This is a serious problem. This proposal is attempts to provide a
symmetrical mechanism to the user. I have not seen another proposal that
provides the user with the ability to handle and process x and z states
within the analog context.
Regards,
Sri
-- Srikanth Chandrasekaran Global Software Group, EDA SBU Motorola Australia. Phone: +61-8-8168 3592 Fax: x3501 email: schandra@asc.corp.mot.com
This archive was generated by hypermail 2b28 : Mon Oct 29 2001 - 20:30:05 PST