Subject: Re: Proposal for rewriting Section 8.3.2
From: Steve Grout (grouts@flash.net)
Date: Mon Oct 29 2001 - 22:28:00 PST
Gentlemen - I have been listening to this discussion
about X and Z, and am concerned that the focus is largely
on X and Z from a digital POV, and not about propagating analog
signal values and port drives into a digital portion of
the design. Ernst earlier pointed at the VHDL work in
this area. It strikes me that, in a real circuit, the behavior
of a port drive changing from some driven analog (non-X and
non-Z) value to a Z is a fairly specific analog circuit behavior.
Shouldn't our changes support that?
I also believe we should be more specific than to leave
either X or Z to be 'vendor specific' (maybe I missed some
email fragment on that?). In digital, leaving it defined
that way was maybe not that bad (maybe even somewhat
necessary consider legacy simulator engines); in analog,
I would urge a more concise central definition that then
has some vendor support issues regarding that definition
across a variety of specific simulator implementation.
Hope this helps...
Regards,
--Steve Grout
Srikanth Chandrasekaran wrote:
>
> 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
-- --Steve Grout Design Verification, CAD Methodology/R&D, Manager, Individual Contributor - Design Verification, CAD System, Database, Flows, Tools, Integration, and Support for both Digital and Analog/Mixed-Signal Design Teams. 101 Kenneil Court Apex, NC 27502 Phone: 919-303-5066 email: grouts@flash.net http://www.flash.net/~sgrout/Personal/resume2001.pdf (or doc,rtf,txt)
This archive was generated by hypermail 2b28 : Mon Oct 29 2001 - 22:29:51 PST