Re: Parameters of Parameters

lingwitt <lingwitt@xxxxxxxxx> writes:

On May 1, 3:38 am, Jonathan Bromley <jonathan.brom...@xxxxxxxxxxxxx>
wrote:
On 30 Apr 2007 17:16:05 -0700,

lingwitt <lingw...@xxxxxxxxx> 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

....

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

It seems that there is a basic misunderstanding of the "intent"/
"purpose" of parameters in Verilog. Parameters are not mechanisms for
doing calculations of constants, although parameters do allow
expressions in their definitions to make their intended use simpler.
Parameters are simply a way of writing generic (parameterizable)
modules that can be instantiated to take on a limited number of
predefined shapes. One uses parameters to get shape information into
a cell, not out-of-it.

Now, it may seem counter-intuitive to you that the tool should
allow/require the design to be micro-managed at that level, but my
experience is that the hardware designers prefer it that way (their
managers certainly do), at least if you are working like I am with a
group assembling devices consisting of billions of transistors made up
of numerous identical parts and using current validation techniques
which only give statistical certainty of correctness. To make up for
that satistical uncertainty, you want certainty that one of those
parts doesn't "query it's environment" and instantiate itself in some
non-standard way (unless *YOU* have specifically told it to do so).
That way as your statistical testing approaches 100%, your chance of
the circuit working also apporaches 100% (and you can know in advance,
which parts are non-standard and need a different kind of testing).

That said, Verilog is a modelling language (and was so before it was a
design language). If latency is something you want to model and to
calculate, model it as Jonathan suggests. That's the intent of the
language. You can model anything you want and get the answers. You
can then use those answers to design your system. Note that that is a
two-stage (or iterative process). You can build your model to check
that you haven't laid out something that breaks your latency rules,
but you don't want to build something that attempts to fix your design
for you. It simply should report that the latency criteria have not
been met, but the designer (and not the device) should then determine
how to resolve the problem.

As a result, Verilog is probably not that language to describe a
series of self-assembling autonomous parts that self-configure
themselves into a solution. Instead it builds nice static models of
things that we have carefully described so that we can validate those
models perform as expected, because we don't trust ourselves not to
have made errors, errors that can uncovered by testing.

If you want to build some kind of self-configuring collection, use
another language (e.g. Perl)* and have it generate the Verilog that
desibes the configured system. That way, your configured system still
has the static properties that make it susceptible to normal
validation techniques and one doesn't have to worry that two different
validation runs will somehow coax the system into two different
configurations and thus can be considered statistcally independent
from the model. In addition, you have your programmable system the
adjusts auto-magically to your changing desires. It just doesn't do
so within the Verilog. But, if your desires change, you can simply
rerun the generation tool and get out new Verilog customized to those
desires, and then you can run your validation suite to give you
confidence that it works as expected.

*: You can also use generate statements in Verilog to achieve the same
effect. However, in any of the cases, you want the system configuring
itself based upon a specification. That specification is always
imposed from the "outside" which makes it inherently top-down at some
level.
.

Relevant Pages

  • Re: Verilog vs VHDL
    ... One thing I notice is that people who have had exposure to software development seem to prefer VHDL ... taught myself Verilog during my retirement, I vastly prefer Verilog to what I've seen of VHDL. ... I was overjoyed when the C programming language came along because it maps very well to the computer architectures of most machines and allowed me to use a high level language instead of assembly language even when doing bit-twiddling things such as device drivers. ... The transition from C to Verilog was almost totally painless once I figured out this new concept of "wires";-) because of the similarity between the two languages - at least as far as the low level operators and general design philosophy of the languages go. ...
    (comp.arch.fpga)
  • Re: Parameters of Parameters
    ... design ramifications can be specified ... Then it's unsurprising that verilog fails here. ... Verilog is only a validation language. ... That way, your configured system still ...
    (comp.lang.verilog)
  • Re: Verilog vs VHDL
    ... Verilog to what I've seen of VHDL. ... You are a Verilog novice and don't know VHDL. ... C programming language came along because it maps very well to the ... the low level operators and general design philosophy of the languages go. ...
    (comp.arch.fpga)
  • Re: Choice of Language for FPGA programming
    ... design entry language. ... My advocacy of VHDL over Verilog for RTL design, ...
    (comp.arch.fpga)
  • Re: Choice of Language for FPGA programming
    ... VHDL is a demonstrably superior language ... very much easier than VHDL. ... to SystemVerilog for RTL design. ... VHDL on all the usage scenarios that Verilog lacked. ...
    (comp.arch.fpga)