[sv-bc] 2037 updated with VERY FRIENDLY amendments

All five "VERY FRIENDLY" amendments are addressed and have been uploaded 
to mantis.

The VERY FRIENDLY amendments are:
1 hierarchical references cannot include generate scopes or arrays of 
instances
2 The BNF needs to be added
3 names that bind into the parent of the configured instance shall be 
names that are legal in a bind statement
4 names shall be resolved starting in the parent scope of the instance
5 only localparams shall be permitted

-- 
==========================================================
Don Mills
mills@lcdm-eng.com
www.lcdm-eng.com
==========================================================


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

NOTES and Questions are in GREEN

Mantis item 2037

 

 

32.4.3  Setting parameters in configurations

 

Configurations can be used to override parameters declared within a design, or to apply or override parameter values for specific instantiations of a design.  When a common value is desired for overriding a number of parameters in a configuration, a localparam can be declared in the configuration. 

 

The following is a list of detailed restrictions regarding setting parameters from a configuration:

-- A localparam declared in a configuration must be assigned a value and shall only be set to a literal value.

-- Index expressions in a hierarchical name shall only refer to literals or localparams of the configuration.

-- Parameters shall be resolved starting in the parent scope of the instance.

-- Parameters that bind into the parent of the configured instance shall be identifiers that are legal in a bind statement.

-- Hierarchical references cannot include scopes of generate or array of instances.

-- A hierarchical identifier in a parameter override shall be resolved starting in the context of the configured instance.  If a hierarchical identifier is used, it must be the only term in the expression, e.g., a.b.c + 7 is invalid.

-- A parameter override in a configuration shall not refer to a constant function other than a built-in constant system function.

-- A parameter override from a configuration shall take precedence over a defparam statement when both are referencing the same parameter at the same level of hierarchy.  In all other conditions, defparam statements work as defined.

-- Configurations may not use positional parameter notation to override parameters.

-- The parameter to be overridden shall not be depended on other parameters.

 

The following two code sample modules are used by examples in this subclause.  Note that module top includes an instantiation of adder and does not include any direct parameter modifications. 

 

  module adder #(parameter   ID  = “id”,

                              W     = 8,

                             D     = 512)(...);

    ...

    $display(“ID = %s,  W = %d,  D = %d”, ID, W, D);

    ...

  endmodule:adder

Example 1

 

  module top (...);

    parameter WIDTH = 16;

    adder a1 (...);

  endmodule

Example 2

 

The code above, without any parameter overrides on adder a1, will print:

ID = id, W=8, D = 512

 

A configuration can be used to override a parameter in a module and apply that overridden parameter to instantiations within that module.  The configuration in Example 3 overrides the default value of parameter WIDTH in module top shown in Example 2.  Example 3 then uses parameter WIDTH to override the parameter for the instantiation of adder.  The code for adder is found in Example 1.

 

  config cfgl;

    design rtlLib.top;

    instance top use #(.WIDTH(32));

    instance top.a1 use #(.W(top.WIDTH));

  endconfig

Example 3

 

Using configuration cfg1 above, the $display in adder will print:

ID = id, W=32, D = 512

 

A localparam can be used in a configuration to represent a value sent to multiple instances.

 

  module top4 ();

    parameter WIDTH = 16;

    adder a1 #(.ID(“a1”))(...);

    adder a2 #(.ID(“a2”))(...);

    adder a3 #(.ID(“a3”))(...);

    adder a4 #(.ID(“a4”))(...);

  endmodule

 

  config cfg2;

    localparam S = 24

    design rtlLib.top4;

    instance top4.a1 use #(.W(S));

    instance top4.a2 use #(.W(S));

  endconfig

Example 4

 

With cfg2 configuring module top4.a1, the $display in adder will print:

ID = a1, W=24, D = 512

ID = a2, W=24, D = 512

ID = a3, W=8, D = 512

ID = a4, W=8, D = 512

Note that in this example, the override of adder port ID in top4 is maintained.

 

A parameter override with empty parentheses will set the parameter back to its default as defined in its module.

 

  module top5 (...);

    parameter WIDTH = 64, DEPTH = 1024, ID = “FOO”;

    adder a1 #(.ID(ID), .W(WIDTH), .D(DEPTH))(...);

  endmodule

Example 5

 

Using the code above, the $display in adder will print:

ID = FOO, W=64, D = 1024

 

  config cfg3;

    design rtlLib.top5;

    instance top5.a1 use #(.W()); // set only parameter W

    // back to it’s default

  endconfig

Example 6

 

When the above configuration cfg3 configures module top5.a1, the $display in adder will print:

ID = FOO, W=8, D = 1024 

Only parameter W is configured to use its default value.

 

All the parameters can be reset to their default values, meaning their initial values prior to any parameter overrides.  This is shown in the following configuration, which uses the module top from Example 2.

 

  config cfg4;

    design rtlLib.top;

    instance top.a1 use #();  // set all parameters in

                   //instance a1 back to their defaults

  endconfig

Example 7

 

This configuration of  top.a1 will print:

ID = id, W=8, D = 512

 

When both a configuration and a defparam statement are modifying the same parameter at the same hierarchal level, the configuration will take precedence.  The following code adds a level of hierarchy which includes defparam statements.

 

  module test;

    ...

    top8 t(...);

    defparam t.WIDTH = 64;

    defparam t.a1.W = 16;

    ...

  endmodule;

 

  module top8 (...);

    parameter WIDTH = 32;

    adder a1 #(.ID(“a1”)) (...);

    adder a2 #(.ID(“a2”),.W(WIDTH))(...);

  endmodule

 

  module adder #(parameter   ID  = “id”,

                              W     = 8,

                             D     = 512)(...);

    ...

    $display(“ID = %s,  W = %d,  D = %d”, ID, W, D);

    ...

  endmodule

 

 

  config cfg6;

    design rtlLib.test;

    instance test.t    use #(.WIDTH(48));

  endconfig

Example 8

 

With cfg6 configuring module top8.a1, the $display in adder will print:

ID = a1, W=16, D = 512

ID = a2, W=48, D = 512

 

 

 

 

 

 

 

 

 

 

 

 

 

THE BNF Changes for A.1.5 and 32.4.1.  The red highlighting came from D4:

 

config_declaration ::= // from A.1.5

config config_identifier ;

    { local_parameter_declaration }

                    design_statement

    { config_rule_statement }

endconfig [ : config_identifier ]

design_statement ::= design { [ library_identifier . ] cell_identifier } ;

config_rule_statement ::=

default_clause liblist_clause ;

| inst_clause liblist_clause ;

| inst_clause use_clause ;

| cell_clause liblist_clause ;

| cell_clause use_clause ;

default_clause ::= default

inst_clause ::= instance inst_name

inst_name ::= topmodule_identifier { . instance_identifier }

cell_clause ::= cell [ library_identifier . ] cell_identifier

liblist_clause ::= liblist {library_identifier}

use_clause ::= use  [ library_identifier . ] cell_identifier [ : config ]

  |  use  named_parameter_assignment { , named_parameter_assignment } [ : config ]

  |  use  [ library_identifier . ] cell_identifier  named_parameter_assignment

    { , named_parameter_assignment }  [ : config ]