Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: Prefix top-level TB parameters #152

Merged
merged 2 commits into from
Jan 29, 2021
Merged

test: Prefix top-level TB parameters #152

merged 2 commits into from
Jan 29, 2021

Conversation

andreaskurth
Copy link
Contributor

We use the -G simulator option to define the value of the top-level TB
parameters, and this option apparently overwrites the value of all
parameters in the hierarchy of the TB. To prevent collisions with
parameters below the top-level TB, we now prefix all top-level TB
parameters with Tb or TB_.

@zarubaf
Copy link
Contributor

zarubaf commented Jan 19, 2021

Just in case you didn’t know -g (lower case) should not override all parameters but just set the top-level ones. So technically that should solve that issue.

@andreaskurth
Copy link
Contributor Author

Just in case you didn’t know -g (lower case) should not override all parameters but just set the top-level ones. So technically that should solve that issue.

Are you sure? The help message says "Specify generic/parameter default value".

@WRoenninger
Copy link
Collaborator

Have been using the -g and Tb prefixing for my last few testbenches. When I recall correctly had some issues with recursive module instantiations with the -g option.

@zarubaf
Copy link
Contributor

zarubaf commented Jan 19, 2021

Pretty sure, yes. I think that is just an unfortunate naming of the help option. But basically that is what you want to achieve, (re-)setting the default parameter. I have no experience with the option and recursive instantiations :-)

@WRoenninger
Copy link
Collaborator

Was using recursiveness with the tc_sram from tech_cells_generic, to break down the sram unto a supported macro size. Had there the same issue with the provided sim script as it is also using -G there.

@andreaskurth
Copy link
Contributor Author

Alright, let's find out and solve this once and for all. Here's a simple experiment to determine the proper way of setting a parameter in the top-level module without affecting parameters with the same name in other modules:

my_module.sv

module my_module #(
  parameter int unsigned MyParam = 32'hdefa0172,
  parameter int unsigned MyOtherParam = 32'hdefa0173
);
  initial begin
    $display("%m.MyParam = 32'h%0x", MyParam);
    $display("%m.MyOtherParam = 32'h%0x", MyOtherParam);
  end
endmodule

my_toplevel.sv

module my_toplevel #(
  parameter int unsigned MyParam = 32'hdefa0170,
  parameter int unsigned MyOtherParam = 32'hdefa0171
);
  initial begin
    $display("%m.MyParam = 32'h%0x", MyParam);
    $display("%m.MyOtherParam = 32'h%0x", MyOtherParam);
  end

  my_module #(
    .MyParam (32'h17)
  ) some_module ();
endmodule

Invocation

Without arguments

$ vsim -c -do 'run -a; exit' my_toplevel
# my_toplevel.MyParam = 32'hdefa0170
# my_toplevel.MyOtherParam = 32'hdefa0171
# my_toplevel.some_module.MyParam = 32'h17
# my_toplevel.some_module.MyOtherParam = 32'hdefa0173

No surprises here. The parameters that are not assigned by an instantiation retain their default value, and the value of MyParam is properly passed to the some_module instance.

Using -g to set value of parameter not passed in instantiation

$ vsim -c -g MyParam="32'h42" -do 'run -a; exit' my_toplevel
# my_toplevel.MyParam = 32'h42
# my_toplevel.MyOtherParam = 32'hdefa0171
# my_toplevel.some_module.MyParam = 32'h17
# my_toplevel.some_module.MyOtherParam = 32'hdefa0173

No surprises here. The -g option sets MyParam of the top-level module to 32'h42, but for the some_module instance MyParam is not affected.

Using -g to set value of parameter also passed in instantiation

$ vsim -c -g MyOtherParam="32'h42" -do 'run -a; exit' my_toplevel
# my_toplevel.MyParam = 32'hdefa0170
# my_toplevel.MyOtherParam = 32'h42
# my_toplevel.some_module.MyParam = 32'h17
# my_toplevel.some_module.MyOtherParam = 32'h42

This might come unexpected. -g MyOtherParam not only sets the (default) value of MyOtherParam for the top-level module, but also for the some_module instance, where the parameter is not assigned at instantiation.

With -G

$ vsim -c -G MyParam="32'h42" -do 'run -a; exit' my_toplevel
# my_toplevel.MyParam = 32'h42
# my_toplevel.MyOtherParam = 32'hdefa0171
# my_toplevel.some_module.MyParam = 32'h42
# my_toplevel.some_module.MyOtherParam = 32'hdefa0173
$ vsim -c -G MyOtherParam="32'h42" -do 'run -a; exit' my_toplevel
# my_toplevel.MyParam = 32'hdefa0170
# my_toplevel.MyOtherParam = 32'h42
# my_toplevel.some_module.MyParam = 32'h17
# my_toplevel.some_module.MyOtherParam = 32'h42

No surprise in either case, I would say. -G overrides the value of all parameters with a given name, regardless of whether that parameter is assigned at instantiation or not.

Verdict

It seems there is no argument to vsim that sets the value of a parameter only for the top-level module. vsim -h | grep -i param only lists -g and -G (and a logging option). 👎

The next best thing we can do is to use -g, prefix all TB parameters with Tb, and prohibit any non-testbench module to have a parameter starting with Tb. (These rules do not prevent problems with nested TBs, but I think that is currently not a use case for us.) What a complicated way to meet a need that I consider pretty basic for simulating parametrized RTL designs.

andreaskurth added a commit that referenced this pull request Jan 29, 2021
As there is no way to set the value of a parameter only for the
top-level module in `vsim` (see #152), we have to prefix all top-level
parameters to prevent collisions with parameters in lower hierarchy
levels.
andreaskurth added a commit that referenced this pull request Jan 29, 2021
`-g` sets the default value of a parameter, while `-G` overrides the
value of the parameter even when it would be assigned a different value
at instantiation.  See #152 for a detailed discussion.
andreaskurth added a commit that referenced this pull request Jan 29, 2021
As there is no way to set the value of a parameter only for the
top-level module in `vsim` (see #152), we have to prefix all top-level
parameters to prevent collisions with parameters in lower hierarchy
levels.
andreaskurth added a commit that referenced this pull request Jan 29, 2021
`-g` sets the default value of a parameter, while `-G` overrides the
value of the parameter even when it would be assigned a different value
at instantiation.  See #152 for a detailed discussion.
As there is no way to set the value of a parameter only for the
top-level module in `vsim` (see #152), we have to prefix all top-level
parameters to prevent collisions with parameters in lower hierarchy
levels.
`-g` sets the default value of a parameter, while `-G` overrides the
value of the parameter even when it would be assigned a different value
at instantiation.  See #152 for a detailed discussion.
@andreaskurth andreaskurth merged commit 4535693 into master Jan 29, 2021
@andreaskurth andreaskurth deleted the prefix-tb-params branch November 11, 2021 09:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants