Parameters of Parameters

[Jonathan Bromley]

On 30 Apr 2007 17:16:05 -0700,
lingwitt <lingwitt@gmail.com> wrote:

I require going from the leaf up.

In that case, drive a constant value out through a
regular port of the lower-level module. Synthesis
will strip it away, so it costs you nothing. Or, if
this is simulation-only code, provide a function in
the lower-level module that reports the relevant value,
and call it from above.

Historically the rules for parameter visibility in
Verilog have been hard to understand, but the only
sensible way to deal with parameters is strictly
top-down in the same way that VHDL does it. And
your complaint about circularity being easy to see
is just not true - particularly when combined with
generates and/or arrays of instances, the relationships
among parameter values can easily become extremely
obscure unless you adhere to strict top-down propagation.
Surely you would expect the module instance tree to be
strictly acyclic? The relationships among parameters
should be likewise.

At first glance, it always seems frustrating that
parent modules cannot use parameters/generics to
enquire about their children's characteristics.
If you follow through the repercussions of that,
though, I think you'll agree that other approaches
make more sense.
--
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.

 

[lingwitt]

On May 1, 3:38 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On 30 Apr 2007 17:16:05 -0700,

lingwitt <lingw...@gmail.com> wrote:
I require going from the leaf up.

In that case, drive a constant value out through a
regular port of the lower-level module. Synthesis
will strip it away, so it costs you nothing.

This is basically a hack for achieving what parameters
should allow:

(1) constants
(2) no cost

Interesting proposition none the less.

Historically the rules for parameter visibility in
Verilog have been hard to understand, but the only
sensible way to deal with parameters is strictly
top-down in the same way that VHDL does it. And
your complaint about circularity being easy to see
is just not true - particularly when combined with
generates and/or arrays of instances, the relationships
among parameter values can easily become extremely
obscure unless you adhere to strict top-down propagation.

Could you give a quick example?
I can't quite picture it.

Surely you would expect the module instance tree to be
strictly acyclic? The relationships among parameters
should be likewise.

I'm not sure how the module tree could ever end up being
cyclic unless someone explicitly tried; similarly with
the parameters.

In any case, hardware description languages
are meant to model real hardware and its design.

Lower-level modules are designed with certain
characteristics that must be taken into account
when such modules are used in higher-level modules.

You are basically saying that there is no good
way to model that!

Why should a designer micromanage characteristics
like latency, when such details could be easily
abstracted away without logic? Latency is actually
a perfect example:

Several modules may have a latency
of one. The next higher-level modules
are made from several of these lower-
level modules at a time, so that they
have a latency of, say, 3. Then another
set of higher-level modules is constr-
ucted from those, and so on.

Each higher-level module should act as
a black box; its specification provides
a latency.

What if a new lower-power design changes
the latency of the lowest-level module?

All the higher-level modules should handle
the change automatically. Why should a human
need to figure that kind of stuff out?

Basically, the lack of proper modeling tools
has created in the hardware community a culture
of workarounds. For instance, Most IP that can
have configurations with different latencies
provide signals that assert the readiness of
the output, even though the latency after
manufacture is not variable.

At first glance, it always seems frustrating that
parent modules cannot use parameters/generics to
enquire about their children's characteristics.
If you follow through the repercussions of that,
though, I think you'll agree that other approaches
make more sense.

You advocate an approach that favors the tool
rather than the human.