[sv-dc] A few examples...

Here are a few examples of scenarios where we want to make sure
that the nettype connection rules are tight enough to allow for
future definition of automatic determination of conversions.

    package pkg;
      function automatic real SumReal_fn(const ref r[]);
          real s = 0;
          foreach (s[i]) r += r[i];
          return s;
      endfunction

      nettype real SumReal with SumReal_fn;
    endpackage

    module child(input pkg::SumReal w);
      always @(w) begin
          $display("w is %g", w);
      end
    endmodule

    module top;
       wire w = 1;
       real r = 2.0;
       integer i = 5;

       child c1(1'b1);
       child c2(3.5);
       child c3(w);
       child c4(r);
       child c5(i);
    endmodule

If we adopt as "assignment compatible" rule, then all of these connections
become legal and directly propagate the value as though the value
were assigned to a real. So the c1 an c3 instances would have a
1.0, c2 would have a 3.5, c4 a 2.0, and c5 a 5.0.

My suggestion in the meeting is that it might be reasonable to
assume that an actual with a matching datatype (i.e. as exists
c2 and c4) would be intentional -- ie that the value provided
meets the semantic assumptions of the domain of the SumReal
nettype. However, I think that for c1, c3 and c5, it is much more
likely that at some point we'll want to be able to "intercept"
such connections (similar to connect module rules in AMS) and
give the user the ability to express automatic conversions for
connections to the given nettype.

So, my suggestion is to retain the stronger rules for now (i.e. require
a matching datatype for any connection). Then if the user wants
to just have the "assignment" conversion occur, they would
need to do a cast, for example:

       child c1(real'(1'b1));
       child c3(real'(w));

Once we figure out what we might want for conversion rules, we
can determine if we can relax this approach. But until we get there,
I think that we should keep things very tight so that we don't run
the risk of introducing compatibility issues in the future.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.