FPGA Central

Hi,

I'm wondering if I may be not using tasks correctly? I have some code
that is suppose to toggle certain signals at certain times to meet
timing specs for my device that I'm testing. I'm using modelsim 6.2
as the simulator.


`timescale 1ns/1ns
module flash_tb;
reg clk;
reg [7:0] io;
reg cle, ale, cebar, rebar, webar, wpbar, rbbar, dut_failure;
reg [7:0] cmd;

// cut some stuff out
task cmdlatch;
inout cle, cebar, webar, ale;
inout [7:0] io;
input [7:0] cmd;
begin
cle = 1; cebar = 0; webar = 1; ale = 0;
#10 begin
cle = 1; cebar = 0; webar = 0; ale = 0;
end
#5 begin
cle = 1; cebar = 0; webar = 0; ale = 0; io = cmd;
end
#20 begin
cle = 1; cebar = 0; webar = 1; ale = 0; io = cmd;
end
#10 begin
cle = 0; cebar = 1; webar = 1; ale = 1; io = 4'hz;
end
end
endtask
//cut some stuff out

initial begin
//initialize regs
cmdlatch(cle, cebar, webar, ale, io, cmd);


so in modelsim I'm expecting the waveforms to toggle, but instead the
signals are stuck on low. I also tried using "<=" inside the task,
but the situation does not change. Any help would be appreciated.
Thanks in advance.

Kevin

"CupOfWater" <[email protected]> wrote in message
news:[email protected] om...
> Hi,
>
> I'm wondering if I may be not using tasks correctly? I have some code
> that is suppose to toggle certain signals at certain times to meet
> timing specs for my device that I'm testing. I'm using modelsim 6.2
> as the simulator.
>
> task cmdlatch;
> inout cle, cebar, webar, ale;
> inout [7:0] io;
> input [7:0] cmd;
> begin
> cle = 1; cebar = 0; webar = 1; ale = 0;
> #10 begin
> cle = 1; cebar = 0; webar = 0; ale = 0;
> end
[... more stuff ...]

> so in modelsim I'm expecting the waveforms to toggle, but instead the
> signals are stuck on low. I also tried using "<=" inside the task,
> but the situation does not change. Any help would be appreciated.

This is a standard Verilog "gotcha", and it's particularly painful
for people migrating from VHDL where procedures can have signal-class
parameters.

In Verilog, task arguments are copied IN to the task at the moment
of task call ("enabling", in the bizarre Verilog jargon) and copied
OUT to the actual arguments at the moment when the task exits.
Any assignments to the formal arguments during the life of the
task will have NO effect on the registers that you passed as
actual arguments in the task call.

The correct approach is to pass in to the task only those
arguments that will affect the way it works, and have it
work directly on registers declared within the enclosing
module...

module GoodTask;

reg [7:0] Data;

task driveData;
input [7:0] value;
begin
Data = 8'bz;
#10 Data = value; // Manipulates the module-level Data reg
#10 Data = 8'bz;
#10;
end
endtask

initial begin
driveData(8'd5); // Wiggles Data successfully
driveData(8'd200);
end

endtask

module BadTask;

reg [7:0] Data;

task driveData;
input [7:0] value;
inout [7:0] Signal;
begin // Inout argument is copied in to Signal here
Signal = 8'bz; //
#10 signal = value; // Manipulates only the local reg Signal
#10 Signal = 8'bz; //
#10;
end // Copies 8'bz back to the argument
endtask

initial begin
driveData(8'd5, Data); // Doesn't wiggle Data
end

endtask


If you want a task like this to be able to work on many different
signals, the correct approach is:

package it in a module;
give the module a port for the signals your task will manipulate;
make the task operate on the module's ports;
wire up an instance of the module to each signal;
use hierarchical names to call in to the task
from the module that instantiated the task's wrapper module.

Hierarchical names are generally
not synthesisable but are very useful for test benches.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: [email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

"Jonathan Bromley" <[email protected]> wrote in
message news:[email protected]...

> module GoodTask;
[snip module contents]
> endtask

Whoops, that should probably have been "endmodule".

--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: [email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Hi,

[email protected] (CupOfWater) wrote in message news:<[email protected]. com>...
> Thanks! That solved my problems. However, I have another
> question....
>
> I have a module that has inout ports and output ports. What is the
> correct way to hook that up and to be able to observe the signals?
> When I try to do:
>

If you use inouts, think about Output Enables/direction control as
well, then you can solve most of these issues.

> // say io in m0 is a inout port
> my_module m0(.io(io_status));
> reg [7:0] io_reg;
> wire [7:0] io_status;
> io_reg = io_status; //illegal!

Will be OK inside a procedural block, always and/or initial.

>
> I need some way to update the local register io_reg io everytime
> io_status is updated,

always @(io_status)
io_reg = io_status;

> and I need io_status to be updated whenever
> io_reg is updated (since io is an inout port). Also, when I try to
> input something through the io port, I'd like to do:
>

assign io_status = (io_en_n == 1'b1) ? inp_data : 'bz;

where inp_data is your data to DUT, io_en_n is Output enable, active
low.


HTH,
Ajeetha
http://www.noveldv.com