[sv-bc] Re: [P1800] Re: DataTypes - Please vote no

>Whatever a Verilog-2001 engineer previously declared to be a reg, I would
>like to now have the option to declare the same variables as wires. Wires
>assigned in an always block should have the exact same behavior as regs in
>Verilog-2001.

And how would the "data types on nets" proposal impact this? As far as I
can see, the two are independent changes. The only interaction is that
if you want to be able to use your proposed solution for anything other
than simple logic vectors, you will need to be able to declare nets of
other data types. The "data types on nets" proposal would only help your
proposed solution.

I think your proposal needs to be able to stand on its own technical merits,
not passed because it was attached as a rider to an unrelated proposal.

And there are technical issues with your proposal:

>with the enhancment:
>
>module myand3 (output y, input a, b, c); // no need to declare reg y
> always @*
> y = a & b & c;
>endmodule

What if you change "output y" to "inout y"? What do you expect to
happen and why? Is that the most useful thing that could happen?
What if you had declared y as an output, but were actually using it
as an inout? If the port was being collapsed, that would work when
y was a net, but changing it to a reg would change the behavior.
Wouldn't that change in behavior be unexpected and cause problems?

Personally, I think it would be more useful if this created an implicit
driver on y for the always process. This would allow for multiple
drivers on y, and make it behave much more like a continuous assignment.
In the simple case, it would work the same way as what you have
suggested. But it would allow arbitrary port directions, with correct
behavior, and no change in port behavior when you changed how you drove y.

There are clearly alternatives to what you have proposed, possibly better
ones. This has not gone through the kind of technical review that the
"data types on nets" proposal has been through.

Steven Sharp
sharp@cadence.com
Received on Tue Dec 14 18:52:32 2004