sharing constants across modules/testbenches

[Jason Zheng]

I'm just throwing this question out for a good discussion:

What's the best/preferred way to share constants/symbols across Verilog
modules? I'm current managing meaningful constants using c-style header
files and `define macros. But I can see that as the number of symbols
scale up, c-style header files can become hard to manage.

~jz

 

[Ajeetha]

Look at SystemVerilog packages and parameters declared inside those
packages (nothing new for VHDL guys), wonderful for such purpose!

HTH
Ajeetha, CVC
www.noveldv.com

Jason Zheng wrote:

I'm just throwing this question out for a good discussion:

What's the best/preferred way to share constants/symbols across Verilog
modules? I'm current managing meaningful constants using c-style header
files and `define macros. But I can see that as the number of symbols
scale up, c-style header files can become hard to manage.

~jz

 

[Jason Zheng]

If I understood correctly, the parameters for packages are global
constants within the package. Can they be exported in any way? Verilog
doesn't have packages, therefore it can't be helped. I'm just wondering
if anyone has a clever work-around in managing constants with Verilog.

~jz

Ajeetha wrote:

Look at SystemVerilog packages and parameters declared inside those
packages (nothing new for VHDL guys), wonderful for such purpose!

HTH
Ajeetha, CVC
www.noveldv.com

Jason Zheng wrote:
I'm just throwing this question out for a good discussion:

What's the best/preferred way to share constants/symbols across Verilog
modules? I'm current managing meaningful constants using c-style header
files and `define macros. But I can see that as the number of symbols
scale up, c-style header files can become hard to manage.

~jz

 

[Jonathan Bromley]

On Wed, 07 Jun 2006 11:00:37 -0700, Jason Zheng <jxzheng@gmail.com>
wrote:

Verilog
doesn't have packages, therefore it can't be helped. I'm just wondering
if anyone has a clever work-around in managing constants with Verilog.

I don't think so. For synthesis, you're stuffed; either `include the
constant definitions, or push parameter values down through the
design hierarchy, or use the dreaded `define.

For simulation, though, it's easy enough to fake-up packages
by defining a little module that contains only parameter declarations.
Then you can either instantiate that module wherever you need it,
or else you can leave it lying around at the top of the simulation
and refer to its contents using cross-module reference. For
example:

module Consts(); // just a container for system-wide constants
parameter MyConst = 5;
endmodule // Consts

module UsesConsts(...);
...
assign SomeWire = Consts.MyConst + 3;
...
endmodule // UsesConsts

module Top();
// instantiate the lower level module
UsesConsts UserInstance (...);
// DON'T instantiate the Consts module
endmodule // Top

Now, you compile the whole mess. The compiler correctly recognises
that Top and Consts are never instantiated and therefore are top level
modules. When you run the sim, you make sure that it simulates
both Top and Consts together. Then the reference to Consts.MyConst
in module UsesConsts will resolve as required to the parameter
declared in the "floating" top-level module Consts.

Hope this helps
--
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.bromley@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.