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

From: Shalom.Bresticker@freescale.com
Date: Tue Jun 01 2004 - 01:28:42 PDT

  • Next message: Steven Sharp: "Re: Why do bit-lengths have to be computable at compilation time?"

    Thanks.
      
    Your answer is about what I would have expected.
      
    I suspect SystemVerilog passed the complexity barrier a long time ago.
    It would be interesting to see the effects of using SV 3.1 and 3.1a
    constructs on simulation speed and memory.
      
    The other side of the coin is the convenience for the user.
    Sometimes the price to pay for fixed sizes is very large from the point
    of view of the code writer, making his code much larger and much more
    awkward.
      
    A lot of these cases are computable at compile-time though, due to
    constant arguments or loop-unrolling, for example.
     
    Also, we have always had 'good practice' guidelines, which tell you
    that coding style A is faster or takes less memory than style B.

    Although in Verilog, those guidelines have been less important over the
    last few years, both due to synthesizable subsets which restrict
    coding style and due to advancements in simulator technology which
    have reduced the effects of coding style.

    In writing for synthesis, too, certain coding styles give you
    better results than others, although again synthesis tools have
    become smarter over the last few years, but it is still very important.

    So the fact that using variable sizes could make simulations
    slower and use more memory is not necessarily a good enough reason
    not to allow them. The advantages could be greater than the cost.

    Shalom

    On Mon, 31 May 2004, Gordon Vreugdenhil wrote:

    > 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                         Shalom.Bresticker @freescale.com
Design & Reuse Methodology                            Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                  Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                      Cell: +972 50 5441478

    [ ]Freescale Internal Use Only
[ ]Freescale Confidential Proprietary

    This archive was generated by hypermail 2.1.4 : Tue Jun 01 2004 - 01:08:40 PDT and
    sponsored by Boyd Technology, Inc.