Re: Why do bit-lengths have to be computable at compilation time?

From: Gordon Vreugdenhil (gvreugde@comcast.net)
Date: Mon May 31 2004 - 20:34:02 PDT

  • Next message: Shalom.Bresticker@freescale.com: "Re: Why do bit-lengths have to be computable at compilation time?"

    Shalom, I am certainly not qualified to give an authoritative
    answer since I haven't participated in Verilog implementation
    for nearlythe length of time as other contributors here.
    However, I'll still throw in my 2 cents...

     From a hardware perspective, the fixed sizes make sense;
    synthesizable constructs must have static topological
    features, only the values can vary. As Verilog has evolved,
    there has been a gradual introduction of additional
    non-synthesizable constructs for testbench and other purposes.
    Personally, I would prefer a stronger demarcation between
    "hardware" Verilog and "software" Verilog since the simuluators
    can, in general, be more aggressive in the "hardware" domain.

    Second, the more static information in a design, the faster
    it is to simulate. With a more dynamic model including
    slices, unconstrained arrays, dynamic repetition, etc. one
    invariably pays a performance penalty. As a trivial
    example, if I know that a bit vector is N bits, I may not
    have to add dynamic test and/or iteration code that runs
    at simulation time. Branches and loops to handle
    overly generalized vector operations can be unbelievably
    expensive, and newer architectures are making such
    problems even worse.

    Verilog is in many ways worse than C in this regard. Many
    of the semantics don't map nicely to underlying machine
    instruction sets, there are often additional levels of
    unknowns which impede effective optimization, and the
    scale of realistic designs makes effective memory and
    cache optimization difficult. More dynamic structures
    will simply add to the difficulty. Obviously such things
    can be implemented - most enhancement requests do not
    actually entail solving uncomputable problems - however
    there is often a price to be paid.

    So, I guess my personal message is "be careful what you
    wish for...".

    Gord.

    Shalom.Bresticker@freescale.com wrote:
    > This question comes up repeatedly, most recently in a discussion on
    > comp.lang.verilog with respect to parameterized functions.
    >
    > Paul Graham wrote in http://www.eda.org/vlog-pp/hm/0572.html:
    >
    > "NC-VHDL handles constructs whose length is uncomputable at compilation time
    > (variable-length slices and aggregates). Since NC-VHDL is also a native
    > code compiled simulator, there must be another reason. Probably the same
    > reason that verilog disallows all other variable-length constructs -- they
    > don't correspond to real hardware."
    >
    > So can someone give a convincing explanation why Verilog does require
    > pre-computable lengths?
    >
    > Maybe we've gotten that explanation in the past and I am just senile,
    > but I don't remember, so please humor me.
    >
    > And then the next question is, even though that has been the situation
    > in the past, does it have to be that way in the future?
    >

    This archive was generated by hypermail 2.1.4 : Mon May 31 2004 - 20:12:50 PDT and
    sponsored by Boyd Technology, Inc.