[sv-ac] Replacement proposal to bind


Subject: [sv-ac] Replacement proposal to bind
From: Adam Krolnik (krolnik@lsil.com)
Date: Fri Mar 07 2003 - 09:58:38 PST


Good morning;

I would like to raise an issue to drop the bind functionality.
I would also like to raise an issue to support 'extend' functionality.

[Or we can defer something like this until SV 3.2...]

Reasons against 'bind':

1. Limited functionality.
    Currently bind will only accept a program block. This excludes
    the possiblity to use just an assert or cover directive, templates
    or instantiations or anything else that would be interesting to
    place in a module. The statement only allows one element to
    be put into a module.

2. Limited extensibility.
    This feature is not easily enhanced (in future SV revisions) to allow
    for other constructs of the language to be used.

3. It does not match any of the other language constructs we are considering
    and including into SystemVerilog.

4. Features added and supported are difficult to deprecate.
    If it is later deemed that this feature is too simplistic, it still needs
    to be supported even as a better feature is added.

5. In the program block - draft3 states program code in a program block operates
    like its within an initial block. We would have to say assert directives and
    properties in a program block are allowed to use always/initial.

6. Inclusion of a program block in a module can be accomplished by `including

Proposal for extension of a module.

   'extend' <module> ';'

    non_port_module_item

    'endmodule'

Benefits of extension.

1. Allowance for varied elements.
    This construct is not limited to a single element. Instead it allows
    any standard module elements (except ports.)

2. Extensible.
    The functionality of this construct could be limited to a subset of
    the 'non_port_module_item' for simplicity and then in a later revision
    additional elements could be included. Tools could decide to support
    additional elements if they desired.

3. Simplicity
    The model of this construct is that of an include file in a module.
    E.g.

    extend modA;

    <stuff>
    endmodule

    Is modeled like:

    module modA;
    ...

    `include <file_containing stuff>
    endmodule

    Contents are noted as coming from the other file/line.
    Contents must not conflict with existing (previously defined) construct.
    Contents must be reference existing constructs or define their own.

4. Subset possible.

    For simplicity, on this revision I would support a definition that
    would allow only these elements:

       property directives
       property declarations
       sequence declarations
       template declarations
       template instantiations
       program blocks

    This would allow one the ability to add assertions to a module without
    having to modify the exact module file itself.

Finally, I would also support deferring bind or extend functionality to another
    revision.One could always make an include file with this other code to be pulled in.

    Thanks.

     Adam Krolnik
     Verification Mgr.
     LSI Logic Corp.
     Plano TX. 75074



This archive was generated by hypermail 2b28 : Fri Mar 07 2003 - 10:00:51 PST