task tskBlah;
input a;
input b;
integer a;
integer b;
begin
do something with a and b;
end
endtask
In my past experience, I have always been under the impression that a
and b are effectively declared as single-bit vectors by the input
line regardless of the integer declaration. But the simulators have
proved me wrong. A and B are indeed recognized as full width
integers within the body of this task. Can any Verilog language guru
comment on this? Can you do the same with module declarations?
~Zheng
> In my past experience, I have always been under the impression that a
> and b are effectively declared as single-bit vectors by the input
> line regardless of the integer declaration. But the simulators have
> proved me wrong. A and B are indeed recognized as full width
> integers within the body of this task.
I think the simulator got it right.
In vhdl, I could declare an integer range from -0 to +0
but I can't imagine why.
-- Mike Treseler
I think you are confusing reg with integer. A reg is a single bit unless
you explicitly declare it with a range, i.e. reg [3:0] foo instead of
just reg foo. An integer is always a full width integer.
I don't think he is confusing anything. I was also surprised by his
result.
His code was:
task tskBlah;
input a;
input b;
integer a;
integer b;
....
I would have expected the lines "input a" and "input b" to have
declared a and b
to be one bit values. Then it looks like the two "integer" lines re-
declare them
to be wider. I tried this on my simulator and get similar results as
the OP.
I looked through my old Verilog XL manuals and a newer Verilog 2005
draft and saw
no explanation for this.
I would normally have coded this as "input integer a"
John Providenza
>task tskBlah;
> input a;
> input b;
>
> integer a;
> integer b;
>
> begin
> do something with a and b;
> end
>endtask
> A and B are indeed recognized as full width
>integers within the body of this task.
Indeed so. Similarly for "time", "real".
> Can you do the same with module declarations?
Yes, I think so, but I long ago gave up on V-95 style
module port lists because they're so hard to follow.
Ports are different, though. A task's input argument
is a local variable of the task that happens to be
copied from the actual argument when the task is
invoked (enabled). A port of a module specifies
the relationship between whatever you connect to
the port when you instantiate the module (the hiconn)
and whatever the port is attached to inside the
module (the loconn). Neither of these things needs
to have the same name as the port, although the
usual default is for the port and the loconn to
have the same name.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
>Ports are different, though.
Too right. I failed to mention the obvious point:
you can't have an input or inout port of integer type,
because integer is a species of variable but input/inout
ports must necessarily be nets. I'm not sure whether
you're allowed an integer output port, but it would
be fairly useless because you would need to connect
a net to it when instantiating the module, and (again)
you can't have integer nets.
My (lame) excuse for forgetting this is that I've
spent too much time recently working with SystemVerilog.
SystemVerilog changes the rules quite dramatically
and it IS possible to have integer input ports on
an SV module.
Apologies if I misled anyone.