Re: [sv-dc] SV-DC presentation on wreal (alternative)

My preferred approach is to just drop the domain (digital or analog)
from the disciplines or ignore it, then use the access functions in the
digital context.

The code example in the presentation -

  module buf1(in, en, out);
    input in, en; output out;
    wreal in, out;
    real outval;
    always @(in,en) begin
      if (!en) outval=`wrealZState;
      else if (in === `wrealXState) outval=0;
      else outval=in;
    end
    assign out=outval;
  endmodule;

Then becomes -

  module buf1(in, en, out);
    input in, en; output out;
    electrical in, out; // could use a more
                        // specific discipline here
    always @(in,en) begin
      if (!en) out = 1`bZ;
      else if (in === 1`bX) V(out) = 0;
      else V(out) = V(in);
    end
  endmodule;

- which is clearer in intent.

The semantics of "V(out)" can be the same as wreal i.e. single
unresolved driver. If you want to have multiple drivers it could support
that too by going with the the result being X unless they match.

If you use I(out) you would get a summing resolution.

Extra connect rules are not required.

'buf1' is then port-compatible with other versions, so you can switch to
a full analog version

You can make it simpler again by automatically interpreting 1'bX as NaN
(not-a-number). NaN usually has hardware support so that it propagates
correctly through arithmetic. It would also be understood by PLI/DPI code.

The reason that this is not how it was done in the first place is
probably because (~ 15 years ago) whoever was responsible for the parser
for the digital parts didn't want to add discipline support and probably
had wreal implemented already. Which is no reason for wreal to persist
as-is.

Kev.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.