Subject: RE: [sv-bc] RE: [sv-ec] Question: logic & reg - what is the difference?
From: Jay Lawrence (lawrence@cadence.com)
Date: Mon Jun 09 2003 - 09:24:14 PDT
Hey Stu,
If you allow 'reg' as a type name you allow things like:
struct {
integer I;
real r;
reg [7:0] char;
} struct_t;
The immediate thought most folks (including many in Cadence who reviewed
the SV LRM) think of next is doing.
struct {
integer I;
real r;
wire [7:0] char;
} struct_t;
Putting a wire inside a struct would be bizarre.
This is because reg is both a 4-state data type and an object kind
(variable).
What we have proposed (and was discussed in sv-ec occasionally) was
making the declaration of a reg be something like:
<reg_decl> ::=
[ reg ] type-name object-list |
reg [ logic ] object-list
So that 'reg' becomes the generic term for a variable declaration rather
than the 4-state type indication. An object of a 4-state type would
always be of the 'logic' type, but could be either a wire or reg (net or
variable).
This is really already done today in some sense. The declaration of
'integer' could be expressed as
typedef logic [31:0] integer; // 31 is vendor dependant
Then the following 2 declarations are identical and backward compatible
with 1364.
reg integer I;
integer I; // reg is the default for object declarations
To repeat struct above you get:
struct {
integer I;
real r;
logic [7:0] foo;
} struct_t;
Integer, real, and logic are the names of types, not declaring an
object. Then you can do
reg struct_t rs;
wire struct_t ws;
To get registers and wires that have the "shape"/topology of the data
structure.
Reg/wire define the simulation semantics of the object.
Types define the topology of the value that object can hold.
By carefully defining the defaults you can add this concept easily to
Verilog and be completely backward compatible.
It also goes way beyond SystemVerilog because all of a sudden you can
have types like 'integer', 'real', and 'struct_t' on a wire to allow
composite interconnect.
Your specific questions were:
> Can you explain the difference between "reg as an object declaration"
and "logic as a type"?
I hope I've answered that one above.
> How does the difference affect tools?
The separation of the objects simulation semantics and the value they
hold actually greatly simplifies the language definition and therefore
implementation. Verilog 2001 did a great deal of cleanup as you know in
this area by removing the term 'reg' and using 'variable' instead, and
similarly with 'wire' and 'net'. This just extends that cleanup.
> the PLI
New PLI methods to query the 'kind' (variable/wire) and 'type' (real,
logic, bool/bit, ...) of an object would be necessary. These will be
necessary for SystemVerilog anyway for variable types, they would now
have to work on nets as well. A forthcoming donation to IEEE from
Cadence has a complete data model for this addition.
> the user writing SystemVerilog code?
Having wires with types is extremely powerful. I can now define a packet
structure that I manipulate in a variable, but can have a port of that
type, and a wire on the outside of that type. In SystemVerilog if I want
a multiply driven bus to have wire resolution semantics, I must declare
a port of a given width and actually break my variable up into pieces
and do continuous assignments to the individual parts of the wire.
With types on wires I can write the following:
typedef packed struct {
[7:0] src;
[7:0] dest;
[63:0] payload;
} packet_t
module gen_packet (output reg packet_t packet, input clk);
...
always @(posedge clk)
begin
packet.src = 8'b1;
packet.dest = 8'b0;
packet.payload = 64'bz;
end
endmodule
module use_packet;
wire packet_t p;
wire clk;
gen_packet g (.packet(p), .clk());
endmodule
(FYI, details on the wire resolution semantics are given in our IEEE
proposal)
Because of the lack of types on wires in SystemVerilog you would need:
- separate declaration of the port with some width (i.e. output
packet_port[79:0] )
- a separate declaration of the variable 'packet'
- a set of continuous assignments from the 'packet' to the port
assign packet_port[79:72] = packet.src;
assign packet_port[71:64] = packet.dest;
assign packet_port[63:0] = packet.payload;
Note that anywhere you use the packet you would need to similarly unpack
it from the wire communicating between the modules.
If the shape of the packet changes you need to go to every place that it
is used and change the port declaration, the wire that does the
interconnect, and the assignments. If you allow type same type on the
wire and variable, then you just change the type declaration.
Hope this helps,
Jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
> Sent: Monday, June 09, 2003 11:17 AM
> To: Jay Lawrence; Clifford E. Cummings; sv-ec@eda.org; sv-bc@eda.org
> Subject: RE: [sv-bc] RE: [sv-ec] Question: logic & reg - what
> is the difference?
>
>
> Jay,
>
> I hate to show off my ignorance, but for the sake of a
> Verilog user, and
> not one who writes tools or parsers, can you explain the
> difference between
> "reg as an object declaration" and "logic as a type"? How does the
> difference affect tools, the PLI, and most importantly the
> user writing
> SystemVerilog code?
>
> Stu
>
> At 12:48 PM 6/5/2003, Jay Lawrence wrote:
>
> >We did resolve that the new rules for continuous assignments being
> >allowed to variables applied to ALL variables. This
> simplification made
> >logic and reg identical. We even had a straw vote on
> eliminating logic
> >because it was now redundant. We then paused in our rush to judgement
> >because logic can be declared inside other things (like a struct) and
> >maybe we wanted to use 'logic' as purely a name for a type and leave
> >'reg' as the declaration of an object.
> >
> >Jay
> >
> >P.s. The "data type donation" to IEEE does exactly this. It
> leaves reg
> >as an object declaration and logic as a type.
> >
> >===================================
> >Jay Lawrence
> >Senior Architect
> >Functional Verification
> >Cadence Design Systems, Inc.
> >(978) 262-6294
> >lawrence@cadence.com
> >===================================
> >
> > > -----Original Message-----
> > > From: Clifford E. Cummings [mailto:cliffc@sunburst-design.com]
> > > Sent: Thursday, June 05, 2003 6:49 AM
> > > To: sv-ec@eda.org; sv-bc@eda.org
> > > Subject: [sv-bc] RE: [sv-ec] Question: logic & reg - what is
> > > the difference?
> > >
> > >
> > > At 07:02 PM 6/4/03 -0700, Andy Tsay wrote:
> > > >Hi,
> > > >
> > > >It seems the only difference is:
> > > >a logic object can be used for both continuous and
> > > >procedural assignment, but a reg object can only be in
> > > >a procedural assignment.
> > > >
> > > >A logic object can be used as output of a gate, but a
> > > >reg object cannot.
> > >
> > > This is what I thought too, but this is not what it says in
> > > section 5.6.
> > >
> > >
> > > >-- Andy
> > > >
> > > >
> > > >--- "David W. Smith" <david.smith@synopsys.com> wrote:
> > > > > Cliff,
> > > > >
> > > > > I seem to remember the meeting, and the vote, where
> > > > > it was decided that
> > > > > logic and reg where the same thing. I think you were
> > > > > there. It appears that
> > > > > some text in the LRM may not have been caught when
> > > > > BC made the change.
> > > > >
> > > > > Since this was all done in the BC I will forward it
> > > > > to BC for comment.
> > >
> > > Thanks, David. I was at the face-to-face meeting in San Jose and a
> > > follow-on phone meeting when we discussed logic and some
> > > potential behavior
> > > surrounding regs but I did not remember this change. I was
> > > wondering if the
> > > EC had "enhanced" the definition of regs. It is beginning to
> > > look like a
> > > significant bug in the spec (especially if ModelTech is
> > > reading what I am
> > > reading and attempting to implement the bug).
> > >
> > > Regards - Cliff
> > >
> > > > >
> > > > > Regards
> > > > > David
> > > > >
> > > > > David W. Smith
> > > > > Synopsys Scientist
> > > > >
> > > > > Synopsys, Inc.
> > > > > Synopsys Technology Park
> > > > > 2025 NW Cornelius Pass Road
> > > > > Hillsboro, OR 97124
> > > > >
> > > > > Voice: 503.547.6467
> > > > > Main: 503.547.6000
> > > > > FAX: 503.547.6906
> > > > > Email: david.smith@synopsys.com
> > > > > http://www.synopsys.com
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: owner-sv-ec@eda.org
> > > > > [mailto:owner-sv-ec@eda.org] On Behalf Of Clifford
> > > > > E. Cummings
> > > > > Sent: Wednesday, June 04, 2003 3:37 PM
> > > > > To: sv-ec@eda.org
> > > > > Subject: [sv-ec] Question: logic & reg - what is the
> > > > > difference?
> > > > >
> > > > >
> > > > > Hi, all -
> > > > >
> > > > > I was talking to the ModelSim developers and we ran
> > > > > into this question:
> > > > >
> > > > > Are logic and reg the same thing? Did I miss this
> > > > > proposal and vote?
> > > > >
> > > > > According to table 3.1, logic has "different use
> > > > > rules from reg."
> > > > >
> > > > > Section 5.6 - 3rd paragraph
> > > > >
> > > > > In SystemVerilog, all variables (including reg?) can
> > > > > now be written either
> > > > > by one continuous assignment, or by one or more
> > > > > procedural statements,
> > > > > including procedural continuous assignments. It
> > > > > shall be an error to have
> > > > > multiple continuous assignments or a mixture of
> > > > > procedural and continuous
> > > > > assignments writing to the same variable. All data
> > > > > types can write through
> > > > > a port.
> > > > >
> > > > > So now what is the difference between a logic and a
> > > > > reg?
> > > > >
> > > > > Is logic 100% redundant with reg? Both must be
> > > > > declared.
> > > > >
> > > > > Regards - Cliff
> > > > > ----------------------------------------------------
> > > > > 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, Synthesis
> > > > > and Verification Training
> > > > >
> > > > >
> > >
> > > ----------------------------------------------------
> > > 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, Synthesis and Verification Training
> > >
> > >
> > >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland Sutherland HDL Inc.
> stuart@sutherland-hdl.com 22805 SW 92nd Place
> phone: 503-692-0898 Tualatin, OR 97062
> www.sutherland-hdl.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
This archive was generated by hypermail 2b28 : Mon Jun 09 2003 - 09:28:22 PDT