Re: Generate proposal

From: Shalom.Bresticker@motorola.com
Date: Tue Jan 13 2004 - 00:04:05 PST

  • Next message: Karen Pieper: "Minutes of the 1/12/04 meeting"

    Let me clarify.

    The 1364-2001 LRM is not clear enough and therefore liable to misinterpretation.

    In 1364-2001, there is a distinction between named generate blocks and
    unnamed generate blocks.

    A named generate block created a new scope.
    For example, see Example 5 at the end of 12.1.3.2.
    The comment lines at the end of the example describe instance names such as
    B1[0].N1.

    It is true that some people have (mis-)interpreted this as meaning that
    this is all one single identifier and not a hierarchical identifier. However,
    that would violate the Verilog syntax that identifiers can not have special
    characters such as [] and period. In Verilog, that would need to be escaped.

    In discussions both within the ETF and within our sub-group, we (unanimously?)
    agreed that an array of hierarchical scopes is created, where the base name of
    the array is B1 and 0 is an index into the array. It is similar to a module
    instance array.

    This is also how the tools we examined have implemented it.
    (Both simulators and synthesis tools.)

    Where there is a real difference between our proposal and the 2001 LRM is in
    unnamed generated blocks. For example, in Example 6 in 12.1.3.3, there is a
    generated instance u1 within an unnamed generate block.

    In this case, according to the 2001 LRM, you are correct that u1 exists in the
    outer module scope. In our proposal, the unnamed generate block will create a
    new scope genblk1, and the (hierarchical) instance name will be genblk1.u1.

    This issue was discussed at length within the sub-group. The consensus was that
    the 2001 LRM approach creates big implementation headaches, whereas adding a
    scope greatly simplies it. The big debate was whether to allow unnamed generate
    blocks at all or to require that all generate blocks be named. The decision was
    to allow unnamed generate blocks, but they will create scopes just like named
    generate blocks, but with implicit names, except that they will not be
    accessible via hierarchical references.

    Now the proposal comes to the ETF for discussion and voting.

    You can of course decide that you do not like the proposal.
    As I wrote, the 2001 LRM is open to more than one interpretation.
    But we are not voting now on the interpretation of 2001 as it exists,
    but on how we want it to be from now on.

    Regards,
    Shalom

    On Mon, 12 Jan 2004, Krishna Garlapati wrote:

    > I beg to differ. I consider all the stuff within generates are blowed
    > off post
    > elaboration. The logic that is "created" due to this does not reside in
    > a generate
    > scope (there is nothing like this post elaboration) but in the scope of
    > the containing module.
    >
    >
    > Shalom.Bresticker@motorola.com wrote:
    >
    > >No, the scope of a generate block is real, not virtual.
    > >It is as real as the scope of a module instance, named block, task, or function.
    > >
    > >
    > >On Fri, 9 Jan 2004, Krishna Garlapati wrote:
    > >
    > >>>First of all, this is consistent with everything similar in Verilog.
    > >>>You cannot declare an object with the same name as a named behavioral
    > >>>sequential or parallel block, or a module instance, in the same scope.
    > >>>For example, it is illegal to declare
    > >>>
    > >>>
    > >>But isn't it true that the scope of a generate is virtual anyway ??
    > >> From your mention of the $dumpvars
    > >>task, I assume that simulators can treat a generate block like any
    > >>scope in Verilog. Isn't that
    > >>contradictory to the spirit of a generate which only exists until
    > >>elaboration ?? The same argument
    > >>can be made with respect to structures. I also should add here that I
    > >>don't know how simulators handle the $dumpvars.
    > >>
    > >>I have no problem with this restriction, but thought it is non-issue
    > >>since we are not dealing with real scopes here. 

    -- 
Shalom Bresticker                         Shalom.Bresticker@motorola.com
Design, Verification & Reuse Methodology             Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd.                  Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 441478

    This archive was generated by hypermail 2.1.4 : Mon Jan 12 2004 - 23:56:54 PST and
    sponsored by Boyd Technology, Inc.