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

> From - Tue Dec 14 18:12:09 PST 2004
>
> Hi, Kev -
>
> You have good points and I hope you have looked at the Data Types proposal
> from an AMS viewpoint so that you can keep us honest.
>
> What concerns me from your email is that I am obviously still not getting
> my point across. I do not want any semantic changes. I want a relatively
> simple syntax change.

Using .* in instantiation was also a simple syntax change, but then we had
to add forward declarations for modules to make it work properly for
incremental compile.

> 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. Any attempt to make continuous assignments (or any other
> driver assignment) to a wire that is also assigned within a procedural
> block shall be an error (just the same as if you had tried to declare reg
> y; and wire y; with corresponding assignments in Verilog-2001).

I can see your point, but I'd rather do it differently. I don't see why
I can't have it do the same as VHDL and just have any process that writes
to a wire (rather than a reg) create it's own implicit driver - that way
I can do continuous assigns and behavioral assigns in the same module, which
makes the semantics more consistent if I manually inline sub-modules (or
translate VHDL :-). Your enhanced examples (below) would work the same.

I would also like to be able to declare drivers seperate from wires, so that
I can pass references to drivers around instead of just references to wires,
and also have multiple drivers (of different types) for one wire available
to a single process. In particular - for mixed signal - it's nice to be able
to have different processes in the same module view a wire differentently,
which requires pushing the type declaration for the wire driver/receiver
down into the (behavioral) process rather than having it at the module level.

>
> The only complexity that I see from this proposal is that vendors will not
> know if a wire declaration uses variable-assignment semantics or
> net-assignment semantics until first usage is found in the module. I
> believe this is minor, but it solves one of the most nagging complaints
> that exists in Verilog today, and it also facilitates coding (it is also
> real easy to teach!)

The AMS stuff generally ignores types/directions on wires and just looks
at the usage for simulation, so I don't have a problem with that.

I just think sorting out how the reg-wire stuff and user-defined types
on wires works should probably be tackled together with AMS at one time
rather than attempting incremental changes that may lead in the wrong
direction.

Kev.

>
> Example:
>
> module myand3 (output y, input a, b, c);
> assign y = a & b & c;
> endmodule
>
> for whatever reason, I decide I want the functionality to be placed in an
> always block:
>
> module myand3 (output reg y, input a, b, c); // had to add reg to the
> ANSI-style port - WHY??
> always @*
> y = a & b & c;
> endmodule
>
> with the enhancment:
>
> module myand3 (output y, input a, b, c); // no need to declare reg y
> always @*
> y = a & b & c;
> endmodule
>
> This is a very simple example. From here, the
>
> At 10:31 AM 12/14/2004, Kevin Cameron wrote:
>
> >IMO it would be a bad idea to change how this stuff works without
> >considering the impact on mixed signal extensions. If you want to propose
> >different syntax/semantics for reg/wire, try including the use of drivers
> >(and receivers) of different types (other than logic) in the same module
> >and how resolution will work.
> >
> > From the perspective of low-level gate and transistor modeling VHDL is
> > badly broken, I wouldn't like to see the same semantics turn up in Verilog.
> >
> >Kev.
>
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> Phone: 503-641-8446 / FAX: 503-641-8486
> cliffc@sunburst-design.com / www.sunburst-design.com
> Expert Verilog, SystemVerilog, Synthesis and Verification Training
>
>
>
Received on Wed Dec 15 01:35:48 2004