New Genesis2 & GUI version (r10497) with three, long awaited for, features
Ofer Shacham
Config File Via Perl Script
XML config files are the official and formal representation of the design. However, it is sometimes useful to have an easy method of overriding a parameter value here and there. For these purpose, it is often convenient to be able to write a short script that manipulates those values. Genesis2 accept those scripts using the -cfg command line flag as described here. Note that parameters values that are configured through the configuration file will override definitions by the XML file. Also note that parameters values that are configured through the config file will not override parameters that were already bound using the generate statement in the .vp files, since that assignment has higher priority. For a complete explanation of parameters override priorities see here.
Configuration files are any simple Perl script which uses one of two predefined functions:
- configure($path_to_param, $override_value) is the main function to enable overriding parameters. Example:
my $path = 'top.dut.inst'; my $path_to_prm = $path.'Width'; configure($path_to_prm, 32); my $path_to_prm = $path.'Size'; configure($path_to_prm, 4); my $path_to_prm = $path.'RAM'; configure($path_to_prm, [0x1, 0x2, 0x3, 0x4]);
- include($another_filename) is a productivity construct to enable you to break the config file into smaller portions. Include inlines the other file into the current file. Example:
In Cache.cfg:
-------------
die unless defined $path;
foreach $cache ('cache1', 'cache2', 'cache3', 'cache4'){
configure($path . '.' . $cache . '.' . 'Width', 32);
}
In Main.cfg:
------------
my $path = 'top.dut.tile';
include('Cache.cfg');Confused by the various ways to control parameters?
Genesis2, as an extension of SystemVerilog for creating Generators, puts a lot of emphasis on late binding of parameters, even those that are buried deep in the design hierarchy. The following are the various ways to bind / override parameter values. Note the distinct (and unambiguous) order.
- A parameter value is assigned by default to the value given in the parameter definition in the module (.vp file) using the parameter method.
- Parameters that were declared with one value (val1), can be overwritten by the external XML input file with a different value (val2), as described here
- Parameters that where declared with val1, which may or may not been overridden with val2 from the XML file, can be further overridden with val3 from a Perl configuration file as described here
- Parameters that where declared with val1, which may or may not been overridden with val2 from the XML file, and may or may not been further overridden with val3 from a Perl configuration file can be even further overridden from the command line with the command line directive -parameter top.dut.param=val4 as described here
- Finally, parameters can also be added or overwritten at instantiation time (this is similar to Verilog 2001)
The rationale is that this enables the designer to give default values to parameters. It enables changing those values later from external configuration files (for example by picking them using an optimizer). But it also enables forcing of the parameter values by the instantiating module if compatibility is required (for example interface bit-widths).
The strongest parameter binding is when the declaration of the parameter in its module as described in (1), also annotates it with Force=>1. That makes it an immutable parameter for any of the methods enumerated above.
- Note that these are the only ways to set parameters values
- Note that parameters behave as constants -- When you assign/get a parameter value, the value is being copied (deep copy if the parameter is a reference to a data structure).
- Note that you can use constants to communicate values to parent modules (not just to sub-instances) -- Once a parameter is defined, it can be read from anywhere in the hierarchy using the instance object (e.g., //; my $param_from_someone_else = $someone_else_instance->get_param('param_name');).
- Note that XML config files are the official and formal representation of the design -- Any external tool that need to read the design generation state, should be directed to the output XML file.
