Passing strings to modules in Verilog

[Edward Heim - T/B]

Hi All

I am trying to pass a string to a module without success.

I assign a string value to a register in a top level module
(Using a $display statement, I can see that I have done this
correctly). The name of the register is in the port list
of a module instantiated in my top level module. When I
try to read the string within the instantiated module I
find the value hasn't been passed.

Can anyone help?

I noticed another mail titled "Passing strings to tasks??"
but there was no text attached to this mail. Is this the
same issue?

Best Regards Edward Heim

[Daryl Stewart]

I think you have a race-hazard, not a string-specific problem.
It's not perfectly clear what you're doing without an example, but I
guess it's something like this:

-----

module top();

reg [8*10:1] stringvar;
reg bitvar;

reader a(stringvar, bitvar);

initial begin
stringvar="Starting";
bitvar=0;
$display("\tAt %t top has: %s and %b",$time,stringvar,bitvar);
#1
stringvar="next value";
bitvar=1;
$display("\tAt %t top has: %s and %b",$time,stringvar,bitvar);
end // initial begin

initial #3 $finish;

endmodule // top

module reader(s, b);
input s;
input b;

wire [8*10:1] s;
wire b;

always begin
$display("At %t reader has: %s and %b",$time,s,b);
#0
$display("Then: %s and %b",s,b);
#1 $display();

end // always begin
endmodule // reader

/*
No errors in compilation
Top-level modules:
top

At 0 reader has: and z
At 0 top has: Starting and 0
Then: Starting and 0
At 1 top has: next value and 1

At 1 reader has: Starting and 0
Then: next value and 1

At 2 reader has: next value and 1
Then: next value and 1
Exiting VeriWell for SPARC at time 3

*/
-----

If you look at the output for time=1, top reports the values "next
value" and 1, then reader reports the old values, "Starting" and 0. This
is because the ports are simulated as seperate assign statements.
eg in top they'd look like
assign a.s = Stringvar;
assign a.b = Bitvar;
After the top-level variables stringvar and bitvar change, the
continuous assignments are ready to update the wires' values, but the
non-deterministic interleaving of threads allows the reader to execute
first. After a delta (#0) delay though, the continuous assignments have
commited and the reader accesses the correct values.

So in summary, you're describing hardware with a race hazard...

--
Daryl Stewart
RA to EPSRC Verilog Formal Equivalence Project
http://www.cl.cam.ac.uk:80/users/djs1002/verilog.project/