Re: Forward compatibility of Verilog generate regions

From: Gordon Vreugdenhil (gvreugde@comcast.net)
Date: Thu Jul 29 2004 - 17:42:47 PDT

  • Next message: Brad Pierce: "RE: errata/607: function returning signed integer/real/time/realtime"

    A few notes on this:
      1) As Shalom notes, the new style creates a scope for the
         body of an unnamed generate-if. This resolves issues
         in the old form about something like the following:

         generate
             if (p)
                reg x;
             if (p)
                wire x;
         endgenerate

         In the old form this would cause an elaboration time
         conflict since both "x" declarations would be
         "promoted" to the parent scope. This causes weird
         issues in various cases (ie. consider if we had
         a genvar named "x" - is there a conflict?)

         The above is legal in the new style and uses the
         "external names" to distinguish between the "x"s
         for purposes of vpi and/or sdf, etc.

      2) There is now the concept of "directly nested
         conditions". In the old form it was not clear
         whether the following was legal:

         generate
            if (p) begin:b
                reg x;
            end
            else if (p2) begin:b
                wire x;
            end
         endgenerate

         The question was whether the "b"s conflict at
         analysis time. The new LRM gives clear answers
         on this (they don't conflict).

         Also, consider:

         reg b;
         generate
            if (p) begin:b
                reg x;
            end
            else if (p2) begin:b
                wire x;
            end
         endgenerate

         Again, this is arguably legal in the old version
         (the reason why is left as an exercise for the
         reader), and is legal no matter what the values
         are for p and p2. This is not legal in the new
         form. I don't know what all existing tools would
         do.

      3) Related to (2), it is now clear that you can't
         "split" a loop. For example:
             generate
                for (g=0; g<5; g=g+1) begin : b
                  reg x;
                end
                for (g=5; g<10; g=g+1) begin : b
                  reg x;
                end

         is arguably legal in the old style. It no longer
         is legal since each name "b" is now conceptually
         a new name for an array of instance blocks.

      4) Hierarchical references are not permitted to enter
         an unnamed block. So, in the example in (1),
         one can't have a hierarchical reference to either
         "x" from the Verilog source.

      5) The behavior of defparam hierarchical references
         has been changed a bit. It isn't clear what the
         old LRM required so I'm not concernd about that
         too much.

    I think that is likely the big issues. Steven, anything
    else to add?

    Gord.

    Shalom.Bresticker@freescale.com wrote:
    > I think that if you use an unnamed generate block, then in the new style,
    > it will create a new scope, but not in the old style.
    >
    > Shalom
    >
    >
    > On Thu, 29 Jul 2004, Brad Pierce wrote:
    >
    >
    >>Is it correct that tools that fully support old-style Verilog generate
    >>regions are forward compatible with new-style Verilog generate regions?
    >>
    >>That is, if one always uses the generate/endgenerate brackets and conforms
    >>to the syntax restrictions of the new-style generate, will a tool that
    >>is fully compliant with old-style generate be able to parse it, and will
    >>the results be the same?
    >>
    >>If not, what are the differences?
    >>
    >>It would be good to document a subset of new-style generate that is
    >>guaranteed to work on tools that fully and perfectly implement the
    >>original 2001 standard.
    >
    >

    This archive was generated by hypermail 2.1.4 : Thu Jul 29 2004 - 17:38:37 PDT and
    sponsored by Boyd Technology, Inc.