From: Clifford E. Cummings (cliffc@europa.com)
Date: Fri May 02 1997 - 08:14:46 PDT
I do not favor this proposal for most of the reasons that Mac has mentioned.
In my mind:
1. multiple assignments to a wire implies multiple drivers on that wire.
2. multiple assignments to a reg implies one driver that is being modified
from one or more behavioral blocks. If this one behavioral-driver source is
intended to drive a net that is driven by other drivers, it needs to be
driven through a buffer that isolates the behavioral changes from a
multiple-driver net. An easy way (not the only way) to accomplished this is
through continuous assignment.
3. an inout port is a net with multiple drivers; hence, it should not be
directly driven from a behavioral block.
Just my opinion.
Regards - Cliff Cummings
<p>Subject: BTF - B10 - Behavioral assignment to wire
Behavioral Task Force - Enhancement Request
Assigned Enhancement Request Number: B10
Enhancement Name (Description): Behavioral assignment to wire
Date Submitted: 970319
Requestor: adamk@cyrix.com (Adam Krolnik)
Status: RO
Is enhancement intended to be synthesizable?: Yes
2. Behavioral assignment to wire.
It is unfortunate that to write to an inout wire, you need an assign
statement. E.g. It's unfortunate to have 'rA'. Can this be fixed?
module test(a);
inout a;
wire a;
reg rA;
assign a = rA;
initial begin
rA = 1'bz;
end
From: mac@silicon-sorcery.com
Date: Wed, 19 Mar 97 14:22:50 PST
This is a proposal which I will vote against. Wires and registers are
different things; and the biggest problem with allowing behavioral
code to write to a wire is that it leaves no way to undo or override
the assignment.
With the world as it is, image the code said
module foo()
wire a;
assign a = f; // A
test t1(a,b,c); //B
endmodule
module test(a,b,c);
inout a;
input [31:0] b,c;
wire a;
reg rA;
assign a = rA;
initial begin
rA = 1'b0; // 1
end
always @(b) begin
if (b[7]) rA = 1'b1; // 2
else if (c[3]&b[6]) rA = 1'bx; // 3
else rA = 1'bz; // 4
end
It is clear that statements 2,3 & 4 override statement 1, and if
executed, each would update the value of the driver of a which is
named rA. There is another driver of a, which is the assign statement
labeled A; and whenever either driver of a changes, normal resolution
operation takes place to determine the "resolved value" of a.
If instead one could assign to a with behavioral statements, we are
left with no clear way to determine when a behavioral assignment is
obsoleted:
module test(a,b,c);
inout a;
input [31:0] b,c;
wire a;
initial begin
a = 1'b0; // 1
end
always @(b) begin
if (b[7]) r = 1'b1; // 2
else if (c[3]&b[6]) a = 1'bx; // 3
else a = 1'bz; // 4
end
How many drivers does a have? presumably you have at least one other,
else you would not make the signal an inout.
First, recognize that you must have some other driver of a, otherwise,
you would not need or want to use a inout as the declaration type.
Given that there is more than one driver for a, the simulator shall
construct a resolution tree to determine the value of the net a, based
on all the drivers. If we changed the language as you propose, we
would need a way of determining when a particular register write is no
longer active.
Certainly causing the write to go inactive at the end of the initial
block would be unacceptable.
If you say "all behavioral assigns are merged into one psuedo driver"
then how about behavioral assigns to wire a that are in other modules,
potentially across the hiearchy, through many renamings by various
ports?
If you say, hey, I won't ever have any other assignments to a from
else where, then I say, why make it an inout?
If what you want is to simply tie off a bus to z, then make it an
output:
module test(a);
output a;
assign a = 1'bz;
endmodule
I don't see a convincing need for this; please (for my edification)
provide stronger justification.
[Reading through this again, perhaps what you REALLY want is the
ability to pass around registers by reference? Of course the
hierarchical reference exists, which is messy for other than use of a
global variable.]
From: Adam Krolnik <adamk@cyrix.com>
Date: Fri, 21 Mar 97 09:20:37 +0600
Rather than requiring the writer to declare an extra variable to assign it's
value to the inout port, why can't the simulator make it's own intermediate
variable for this purpose? It would be used by any behavioral writes to the
inout port. The suggestion is put forth as a simplification to writing code.
From: mac@silicon-sorcery.com
Date: Fri, 21 Mar 97 09:59:26 PST
Ok, the only sane way I could imagine implementing this is to
add one additional driver to every wire. This driver is initialized to
width 'bz, and any and all behavioral writes (or pli writes to wires,
another proposal) update this implied register.
I am still fairly negative on the concept, as it has some
fairly wide implications:
1) One would need a way to read the current value of this
implied driver (for $showdrivers, as well as in straight
verilog).
2) Races abound for multiple behavioral (and/or pli)
statements updating the one implied driver of a wire in the
same clock cycle. Note such races don't exist today, as
each behavioral writer across the hierarchy updates their
own local driver.
3) It unnecessarily removes the distinction between wires and
registers.
//********************************************************************//
// Cliff Cummings E-mail: cliffc@europa.com //
// Sunburst Design Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training / On-Site Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:40 PDT
and
sponsored by Boyd Technology, Inc.