RE: [sv-bc] SV-BC #110 - 2-State Divide by 0 question

SV-BC,

Steven's approach is sensible, easy to understand,
and easy to describe.

However, I'm still concerned that we will be doing
SV users a disservice by calculating obviously incorrect
results for 2-state arithmetic.

I sympathize with Matt's position, but in this case the
problem is that we are being asked to provide a mathematically
wrong answer. This seems like an exceptional situation that
requires exceptional treatment. It's not at all similar to
the debate we're having on unique if and case violations.

In the C programming world, divide-by-0 is an undefined
operation which typically results in a crash-causing signal.
Don't we expect users of 2-state types to expect C-like
semantics when programming with these C-like types?
Many folks will probably have this intuitive expectation.
BTW, when such an error occurs in a C program, it is usually
easy to diagnose and fix the coding flaw.

As a user I like tools that "protect me from myself".
Having to write an assertion before every division
operation in my code is not an attractive option
when it's very easy for the tool to do this for
me automatically.

I do suppose simulators could provide options by which
users can declare that all divide-by-zero operations
should result in a fatal runtime error.

Anyways, I can go along with Steven's proposal.
And I think it would be good if the proposal were
extended to disallow assignment of divide-by-0 results
to 2-state objects. But if I'm a lone voice in the
forest here, I will be happy to stop arguing the point.

Regards,
Doug

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Steven Sharp
> Sent: Tuesday, November 23, 2004 5:56 PM
> To: cliffc@sunburst-design.com; sv-bc@eda.org; Rich, Dave
> Subject: RE: [sv-bc] SV-BC #110 - 2-State Divide by 0 question
>
>
> >I looked at this a while ago and found that there is no easy way to
> >define a 2-state division that is backward compatible with
> Verilog. For
> >example
>
> I had come to the same conclusion and was trying to find a way to
> express it.
>
>
> >I think it may be useful to use context determination rules
> similar to
> >those used for width or signed determination.
> >
> >'100/0' in the example above should return 1'bx because it
> is being used
> >in the context of a 4-state assignment.
> >
> >'B/0' would be a 2-state division because it is a self-determined
> >expression.
>
> I came up with a somewhat different solution that gives the
> same result
> in almost all situations, and is simpler. In Dave's terms,
> you just treat
> them all as 4-state contexts. Then there is no need for any
> new rules.
>
> Except possibly for this division (and modulo) situation, the
> result of a
> 2-state and a 4-state calculation with 2-state inputs should
> always be the
> same. So you can define all expressions as being calculated
> with 4-state
> semantics. If you have a mix of 2-state and 4-state
> operands, you get the
> right result automatically. An optimizer is free to throw
> away any extra
> 4-state work that isn't needed. With all 2-state operands,
> the optimized
> 4-state calculation should be identical to a 2-state calculation.
>
> So division by zero would always give the 4-state result of
> X, which would
> then be treated as a 4-state value by the rest of the
> calculation. If the
> result was then assigned to a 2-state object, the value would
> be converted
> from 4-state to 2-state.
>
>
> >I would like to use the same rules for determining the
> result of an out
> >of range array reference. Currently, the spec says to return
> the default
> >un-initialized value. I think designers would rather see it return 'x
> >when used in a 4-state context.
>
> This makes sense too (except I would treat them all as
> 4-state contexts).
>
>
> Steven Sharp
> sharp@cadence.com
>
>
Received on Tue Nov 23 23:40:08 2004