where to include parameters file

[Paul Huntley]

Hi,

Trying to figure the best way to include global parameters for a large
design. We are using 'include <parameter_file_name>.

We note that if this line resides after the module statement, then the
scope of the parameters is local to that module, as expected.

However, if that line is *before* the module statement, then the scope
of the parameters is that module, and any module instantiated therein,
as well.

We further note that our compiler (VCS) requires a plusarg, +sysver for
this second method to compile.

My question, is this a synthesizable technique to flow parameters down
through the hierarchy, or is it a SystemVerilog construct only, and
therefore not synthesizable?

Appreciate any thoughts or discussion on the topic...thanks in advance.

Regards,

Paul Huntley
San Jose, CA
paulh@lunarcoons.com

 

[Ajeetha]

Paul,
The scope outside module is also known as "$root" in
SystemVerilog. It is a SV construct and hence your synthesizer needs to
support it. I'm told that DC supports it, which synthesis tool do you
use?

BTW - which VCS do you use? +sysvcs was old option, now it is
-sverilog.

HTH
Ajeetha, CVC
www.noveldv.com
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
h**p://www.systemverilog.us/
* SystemVerilog Assertions Handbook
* Using PSL/Sugar
Paul Huntley wrote:

Hi,

Trying to figure the best way to include global parameters for a large
design. We are using 'include <parameter_file_name>.

We note that if this line resides after the module statement, then the
scope of the parameters is local to that module, as expected.

However, if that line is *before* the module statement, then the scope
of the parameters is that module, and any module instantiated therein,
as well.

We further note that our compiler (VCS) requires a plusarg, +sysver for
this second method to compile.

My question, is this a synthesizable technique to flow parameters down
through the hierarchy, or is it a SystemVerilog construct only, and
therefore not synthesizable?

Appreciate any thoughts or discussion on the topic...thanks in advance.

Regards,

Paul Huntley
San Jose, CA
paulh@lunarcoons.com

 

[Petter Gustad]

"Paul Huntley" <paulh@lunarcoons.com> writes:

Trying to figure the best way to include global parameters for a large
design. We are using 'include <parameter_file_name>.

Do you mean `define and friends when you are taking about global
parameters? Put the parameter file early in the argument list in your
vcs driver script. That way you don't have to use include.

For my latest designs my ASIC vendor wanted a single file containing
all the HDL. That would have been a hassle if the files contained lots
of include statements.


Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Petter Gustad]

"Paul Huntley" <paulh@lunarcoons.com> writes:

My question, is this a synthesizable technique to flow parameters
down through the hierarchy, or is it a SystemVerilog construct only,
and therefore not synthesizable?

Reading you message again I get the impression that you are including
a file containing parameter statements. defparam/module instance
parameter value assignment is the common method for overriding the
parameter settings.


Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

Ajeetha wrote:

The scope outside module is also known as "$root" in
SystemVerilog. It is a SV construct and hence your synthesizer needs to
support it.

It used to be known as $root, in the Accellera standard, and was a
single global scope. In the IEEE 1800 standard, it is known as $unit,
and is restricted to a single "compilation unit". There can be multiple
$unit scopes in your design, depending on how you compile it. This
change was intended to support separate compilation use models.

There is still a vestige of $root in the IEEE standard. It can be used
in a hierarchical name to refer to a hiearchical path starting at the
top level. It can no longer be used to refer to names declared outside
of modules. Instead, $unit must be used for that.

 

[Ajeetha]

Thanks for correcting me.

Regards
Ajeetha, CVC
www.noveldv.com

 

[Rob Dekker]

An LRM question on $root and $unit.

$root in 3.1 became $unit in 1800.
Confusing, but OK.

So what did $root become 1800 ?

LRM: "$root is added to unambiguously refer to a top-level instance or to an instance path starting from the root of the
instantiation tree".
This is ultimately confusing.

Verilog can a top-level module, but what is a 'top-level instance' ?
Is it an instance within the top-level module ?
Also, there can be multiple top-level modules, so how do we know which one is intended ?
And isn't the $unit by definition a top-level module (because it is not instantiated anywhere) ?
If so, isn't $root the same as $unit ?

Thanks

Rob


<sharp@cadence.com> wrote in message news:1155779639.834456.78180@b28g2000cwb.googlegroups.com...

Ajeetha wrote:

The scope outside module is also known as "$root" in
SystemVerilog. It is a SV construct and hence your synthesizer needs to
support it.

It used to be known as $root, in the Accellera standard, and was a
single global scope. In the IEEE 1800 standard, it is known as $unit,
and is restricted to a single "compilation unit". There can be multiple
$unit scopes in your design, depending on how you compile it. This
change was intended to support separate compilation use models.

There is still a vestige of $root in the IEEE standard. It can be used
in a hierarchical name to refer to a hiearchical path starting at the
top level. It can no longer be used to refer to names declared outside
of modules. Instead, $unit must be used for that.

 

Rob Dekker wrote:

LRM: "$root is added to unambiguously refer to a top-level instance or to an instance path starting from the root of the
instantiation tree".
This is ultimately confusing.

Verilog can a top-level module, but what is a 'top-level instance' ?

A different term for the same thing. A top-level module is actually an
instance of that module, so it is also a top-level instance. But in
SystemVerilog, a top-level instance might be an instance of a program
instead, so the term is broader than top-level module.

Is it an instance within the top-level module ?
Also, there can be multiple top-level modules, so how do we know which one is intended ?

Because its name will appear after the dot after the $root. The $root
does not replace the module name; it precedes it. The $root at the
start of the name just means that the hierarchical path starts at the
root of the design. It is an absolute hierarchical path, not a
relative path.

And isn't the $unit by definition a top-level module (because it is not instantiated anywhere) ?

Actually, $unit is treated more like a package than a top-level module.

If so, isn't $root the same as $unit ?

In the 3.1 standard, $root was regarded as the scope above the
top-level instances. All declarations outside of any modules lived in
that scope. You could refer to those declarations with a hierarchical
name of $root.name, and you could also refer down into the module
hierarchy with a hierarchical name of $root.topmodname.name.

In the 1800 standard, these two things were split apart, apparently to
assist with separate compilation. The desire was to be able to have
multiple distinct scopes for declarations outside of any module, one
for each separate compilation unit. So these were called $unit, which
can only be used to refer to objects outside of modules but in the same
compilation unit. You cannot refer to objects outside of modules but
in a different compilation unit. The syntax used with $unit is the
package reference syntax, which is $unit::name.

Unlike the declarations in $unit, top-level module names are global
across the entire design, independent of compilation units. They must
remain global for backward compatibility with Verilog, and because it
would otherwise be impossible for two top-level modules in different
compilation units to interact. So $root still survives to refer down
into the module hierarchy, with a name that unambiguously starts at the
top.

The purpose of $unit seems to be to have declarations shared between
modules, without making them global across the design and risking name
collisions during integration of parts of a design. This functionality
is probably better served by the use of explicit packages instead of
$unit.

 

[Rob Dekker]

Thanks for your explantion.
It makes sense, that $unit looks in the compilation unit scope, and $root looks in the root scope of modules.
I was confused mostly by the inconsistent terminology used in the LRM on this.

There are more such confusing, ambiguous, incomplete or contradictory statements and descriptions in the LRM,
and I wonder how all of us as implementors can come to a common understanding of how IEEE 1800 should actually work in all its
details...

Rob

<sharp@cadence.com> wrote in message news:1156829158.983829.165890@75g2000cwc.googlegroups.com...

Rob Dekker wrote:

LRM: "$root is added to unambiguously refer to a top-level instance or to an instance path starting from the root of the
instantiation tree".
This is ultimately confusing.

Verilog can a top-level module, but what is a 'top-level instance' ?

A different term for the same thing. A top-level module is actually an
instance of that module, so it is also a top-level instance. But in
SystemVerilog, a top-level instance might be an instance of a program
instead, so the term is broader than top-level module.

Is it an instance within the top-level module ?
Also, there can be multiple top-level modules, so how do we know which one is intended ?

Because its name will appear after the dot after the $root. The $root
does not replace the module name; it precedes it. The $root at the
start of the name just means that the hierarchical path starts at the
root of the design. It is an absolute hierarchical path, not a
relative path.

And isn't the $unit by definition a top-level module (because it is not instantiated anywhere) ?

Actually, $unit is treated more like a package than a top-level module.

If so, isn't $root the same as $unit ?

In the 3.1 standard, $root was regarded as the scope above the
top-level instances. All declarations outside of any modules lived in
that scope. You could refer to those declarations with a hierarchical
name of $root.name, and you could also refer down into the module
hierarchy with a hierarchical name of $root.topmodname.name.

In the 1800 standard, these two things were split apart, apparently to
assist with separate compilation. The desire was to be able to have
multiple distinct scopes for declarations outside of any module, one
for each separate compilation unit. So these were called $unit, which
can only be used to refer to objects outside of modules but in the same
compilation unit. You cannot refer to objects outside of modules but
in a different compilation unit. The syntax used with $unit is the
package reference syntax, which is $unit::name.

Unlike the declarations in $unit, top-level module names are global
across the entire design, independent of compilation units. They must
remain global for backward compatibility with Verilog, and because it
would otherwise be impossible for two top-level modules in different
compilation units to interact. So $root still survives to refer down
into the module hierarchy, with a name that unambiguously starts at the
top.

The purpose of $unit seems to be to have declarations shared between
modules, without making them global across the design and risking name
collisions during integration of parts of a design. This functionality
is probably better served by the use of explicit packages instead of
$unit.

 

Rob Dekker wrote:

There are more such confusing, ambiguous, incomplete or contradictory statements and descriptions in the LRM,
and I wonder how all of us as implementors can come to a common understanding of how IEEE 1800 should actually work in all its
details...

I agree with your concerns...