Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST

Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | Question in verilog testbench


There are 4 messages in this thread.

You are currently looking at messages 0 to 4.

Question in verilog testbench - Frank - 2010-03-07 04:56:00

Hi, all

I have a question in the testbench written by verilog. Why we always
define the inputs of MUT as reg and outputs of MUT as wire, just the
opposite with the in/output definition in verilog modules.
So more clearly, what are the basic issues that I should know when I
have to decide the type of a variable(reg or wire)?

Thanks
Frank
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.



Re: Question in verilog testbench - Jon Beniston - 2010-03-07 05:30:00

You need to set the type according to how it will
be assigned a value.
reg if written to in an always or initial block, wire otherwise.

Cheers,
Jon

Re: Question in verilog testbench - Jonathan Bromley - 2010-03-07 05:39:00

On Sun, 7 Mar 2010 01:56:22 -0800 (PST), Frank
wrote:

[We really must write this up as a FAQ.....]

>I have a question in the testbench written by verilog. Why we always
>define the inputs of MUT as reg and outputs of MUT as wire,

Not "always".  The MUT (DUT) outputs must be connected to wires,
but the inputs can be connected either to reg or to wire - it's
your choice.

>opposite with the in/output definition in verilog modules.

It is sometimes that way, but don't worry about it.  That
is not the basic problem.  See below.

>So more clearly, what are the basic issues that I should know when I
>have to decide the type of a variable(reg or wire)?

The rules are extremely simple:

****************************************************************
*  If an object is given its value by assignment in procedural *
*  code, then that object must be a variable (reg).            *
*                                                              *
*  If an object is given its value by any other method, then   *
*  that object must be a net (wire).                           *
****************************************************************

However, it is often difficult to get this exactly right
in practice.  

First there is the problem of definition.  In my wording
of the rules, above, what do I mean by "assignment in 
procedural code"?
- The thing on the left-hand side of an assignment (= or <=)
  in the body of an always, initial, task or function;
- anything that is passed to a task's inout or output
  argument.

"Given its value by any other method" means any of these:
- it is connected to an output or inout port of a module instance;
- it is connected to an output or inout port of a UDP or
  primitive instance;
- it is the left-hand side of a continuous assignment ("assign")
  statement at the top level of a module;
- it is an input or inout port of a module.

As a result of the rules.....

- Inside a module, any inout or input ports must be a net (wire)
  because it gets its value from whatever you connect to the 
  port when you instance the module.
- Inside a module, an output port can be either a net (wire)
  or a variable (reg); the choice depends on how that thing 
  gets its value within the module's code.  The value of the 
  thing is passed out through
  the port to the wire you connect on the outside.
- When you create an instance of a module, you must connect
  wires to all its output and inout ports because those wires
  get their value by connection, not by procedural assignment.
- When you create an instance of a module, you are free to connect
  either a wire or a reg to its input port.  The choice depends
  on how that thing gets its value in your outer module.

Hope this helps.  Note that the rules are slightly different in
SystemVerilog, but it's a good idea to learn the Verilog basics!
-- 
Jonathan Bromley

Re: Question in verilog testbench - Frank - 2010-03-07 08:43:00

On Mar 7, 6:39=A0pm, Jonathan Bromley
<jonathan.brom...@MYCOMPANY.com>
wrote:
> On Sun, 7 Mar 2010 01:56:22 -0800 (PST), Frank wrote:
>
> [We really must write this up as a FAQ.....]
>
thank you, that really helps:)

______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.