Genesis2 File Types - StanfordVLSI/Genesis2 GitHub Wiki
These are the user's files. That is, when you come to write a hardware module that you want Genesis2 to elaborate, you should write it in a file named base_module_name.vp (or base_module_name.svp if you like the SystemVerilog suffix notation better). For example, if the module name is onehotmux, it should be placed in a file named onehotmux.vp.
Included files should be named whatever.vph. In fact, this requirement is not real and whatever.anything or even whatever would work. However, for nice coding style, and for xemacs verilog mode to work nicely, the whatever.vph is recommended.
New Feature -- Special File Extensions For SystemVerilog C and TCL :
- Use file.svp and file.svph for SystemVerilog files and headers
- Use file.cp or file.cph for C files and headers (for High Level Synthesis)
- Use file.tclp or file.tclph for TCL files and headers
Genesis2 generates intermediate Perl module files (Given the file filename1.vp, Genesis2 would generate filename1.pm). These files are generated into a newly created folder named 'genesis_work'. Typically there is no reason to look at these files, except for extreme cases for debugging of parsing errors that had abscured error messages.
Note that Genesis2 works in two stages: First all the .pm files are generated. These files are, in fact, a complete object oriented program in Perl, where each module represents a module generator. Then, after all the Perl modules are created, Genesis2 executes the newly created Perl program that in turn generates Verilog.
The final type of file of interest is the generated verilog file. This code should consist of only verilog, and will eventually be fed to VCS/dc_shell/other tools.
- Note: For every somemodule.vp input file, there may be more than one verilog file generated. If somemodule is instantiated in different places using different parameters, each different instance would be uniquified. The resulting verilog files would be named somemodule_unq0.v, somemodule_unq1.v, etc.
The XML input program has a very simple structure. Yet, one has to remember that XML is best if read/written by machine and not human. The absolutly best way to get started is to let Genesis2 run with the -hierarchy outfile.xml flag set. This will create a "small_" output xml representation which can serve as a template for creating the input XML program. It will also generate a complete output xml representation which is a superset of the input xml representation, with much more information, and can also serve as a program template (when used as input, Genesis ignores the extra meta-information). The "small_" version is more useful for human manipulation, but when GUI or optimization tools are added to the flow, the latter version is usually preferred. See Genesis2SchemaXSD for a complete XML schema!
Having said that, the following is a description of the input XML schema:
- There are a few reserved element names: HierarchyTop, BaseModuleName, SynonymFor, InstanceName, Parameters, ImmutableParameters, ParameterItem, Name, Val, Doc, Range, List, Min, Max, Step, Opt, SubInstances, SubInstanceItem, UniqueModuleName, CloneOf, HashType, HashItem, Key, ArrayType, ArrayItem, InstancePath. Avoid using these key words in any context other than the one explained here or in the output xml representation section.
- HierarchyTop: There is a single root element which represents the top module of the design (since the top module is never instantiated, it is referred to by HierarchyTop and not by an instance name). A minimal (but legal) input XML structure would contain the following text:
<HierarchyTop></hierarchytop>
- General tree structure: For each module instance in the hierarchy (including HierarchyTop) the following recursive structure can be used. It must have an InstanceName element (except for the HierarchyTop), and it can optionally have Parameters and SubInstances elements. Omitting the Parameters or the SubInstances element is ok. However, omitting the InstanceName will result in an error!
- Example of top level:
<HierarchyTop>
<Parameters>
</parameters>
<SubInstances>
</subinstances>
</hierarchytop>
- Example for internal node
<SubInstances>
<SubInstanceItem>
<InstanceName>someInstanceName</instancename>
<Parameters>
</parameters>
<SubInstances>
</subinstances>
</subinstanceitem>
...
...
</subinstances>
- SubInstances: (Optional) A list of zero or more SubInstanceItem elements that represent the sub-instances in the current hierarchy level. The same rules apply recursively for each of these elements. Note that if an instance is encountered during elaboration, but the corresponding SubInstanceItem is missing from the XML tree, it will be assumed that that instance uses the default parameters or the instantiation line parameters, as noted in the .vp files. If a SubInstanceItem element that does not correspond to any instance in the design is encountered, than it is simply ignored.
<SubInstances>
<SubInstanceItem>
<InstanceName>someInstanceName_A</instancename>
...
</subinstanceitem>
<SubInstanceItem>
<InstanceName>someInstanceName_B</instancename>
...
</subinstanceitem>
...
...
</subinstances>
- Parameters: (Optional) A list of zero or more ParameterItem. Note that if a ParameterItem is missing from the list, it is assumed that its value is not overwritten by XML. If ParameterItem exists for a parameter that is not defined in the .vp file, it is simply ignored. Of course, two ParameterItem elements carrying the same Name will produce an error. Each myValue of a parameter myParam would be written as:
<Parameters>
<ParameterItem>
<Name>myParam</name>
<Val>>myValue</val>
</parameteritem>
...
...
</parameters>
- For Parameters, note that more complicated data structures are also supported. Simply replace the Val element with the HashType to show that a parameter is a hash rather than a string/scalar or with the ArrayType to show that a parameter is an array rather than a string/scalar. Array of hashes and hash of arrays (or any recursive combination) is also supported. Finally, an InstancePath element can be used to express that a parameter represents a reference to a particular instance in the design hierarchy (i.e., it is a pointer to another object).
- Each ArrayType contains a list of zero or more ArrayItem elements. An empty array is an ArrayType with no internal ArrayItem. Each ArrayItem must contain a Val OR HashType OR ArrayType OR InstancePath element. (see example next)
- Each HashType contains a list of zero or more HashItem elements. An empty hash is a HashType with no internal HashItem. Each HashItem must contain a Key element AND a Val OR HashType OR ArrayType OR InstancePath element. Of course, two HashItem elements carrying the same Key will produce an error. (see example next)
- InstancePath is a string that represents a complete path such as "top.dut.unit1"
<Parameters>
<ParameterItem>
<Name>myArrayParam</name>
<ArrayType>
<ArrayItem>
<Val>1</val>
</arrayitem>
<ArrayItem>
<Val>2</val>
</arrayitem>
<ArrayItem>
<Val>3</val>
</arrayitem>
...
...
</arraytype>
</parameteritem>
<ParameterItem>
<Name>myHashParam</name>
<HashType>
<HashItem>
<Key>somekey</key>
<Val>someval<Val>
</hashitem>
<HashItem>
<Key>anotherkey</key>
<Val>anotherval</val>
</hashitem>
...
...
</hashtype>
</parameteritem>
<ParameterItem>
<Name>myRefToAnotherInstance</name>
<InstancePath>name_of_top_module.name_of_sub_instance_1</instancepath>
</parameteritem>
</parameters>
- Example of full hierarchical XML program input example:
<HierarchyTop>
<Parameters>
<ParameterItem>
<Name>some_param_name_1</name>
<Val>>12</val>
</parameteritem>
<ParameterItem>
<Name>some_param_name_2</name>
<Val>>15</val>
<ParameterItem>
</parameters>
<SubInstances>
<SubInstanceItem>
<InstanceName>name_of_sub_instance_1</instancename>
<Parameters>
<ParameterItem>
<Name>some_param_name_1</name>
<Val>5</val>
</parameteritem>
<ParameterItem>
<Name>some_param_name_2</name>
<Val>3</val>
</parameteritem>
<ParameterItem>
<Name>my_empty_array</name>
<ArrayType></arraytype>
</parameteritem>
<ParameterItem>
<Name>my_empty_hash</name>
<HashType></hashtype>
</parameteritem>
<ParameterItem>
<Name>some_array_param_name</name>
<ArrayType>
<ArrayItem>
<Val>element_1</val>
</arrayitem>
<ArrayItem>
<Val>element_2</val>
</arrayitem>
</arraytype>
</parameteritem>
<ParameterItem>
<Name>some_hash_param_name</name>
<HashType>
<HashItem>
<Key>some_key_1</key>
<Val>val_1</val>
</hashitem>
<HashItem>
<Key>some_key_2</key>
<Val>val_2</val>
</hashitem>
</hashtype>
</parameteritem>
</parameters>
</subinstanceitem>
<SubInstanceItem>
<InstanceName>name_of_sub_instance_2</instancename>
<Parameters>
<ParameterItem>
<Name>some_param_name_1</name>
<Val>73</val>
</parameteritem>
<ParameterItem>
<Name>some_param_name_1</name>
<Val>45</val>
</parameteritem>
<ParameterItem>
<Name>some_instance_ref</name>
<InstancePath>
name_of_top_module.name_of_sub_instance_1
</instancepath>
</parameteritem>
</parameters>
<SubInstances>
<SubInstanceItem>
<InstanceName>name_of_sub_sub_instance_1</instancename>
<Parameters>
<ParameterItem>
<Name>some_param_name_1</name>
<Val>1</val>
</parameteritem>
<ParameterItem>
<Name>some_param_name_2</name>
<Val>2</val>
</parameteritem>
</parameters>
<SubInstances>
</subinstances>
</subinstanceitem>
</subinstances>
</subinstanceitem>
</subinstances>
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. Many configuration scripts may be applied one after the other to cover different aspects of the configuration. If a parameter value binding is overridden, a warning is issued. Note that parameters values that are configured through the configuration file will NOT override definitions by the XML file (actually XML definitions override the Perl configuration scripts). Also note that parameter 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.
Basic configuration files are any simple Perl script which uses the following 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'); - exists_configuration('path.to.param') quarries weather 'param' exists in path 'path.to.param'. It returns 1 if exists and 0 otherwise. Exists here means that that parameter configuration was previously defined through the configuration scripts. Since configuration scripts are executed long before the design is elaborated, it does check the existence of the parameter in the actual design. See get_configuration (next) for an example.
-
get_configuration('path.to.param') returns the value of a previously configured parameter. Note that 'previously configured' means it was previously configured via the configuration script. If the parameter was not previously configured, an error will be thrown (because parameters can be defined to have an 'undef' value, the only way to check if a parameter was previously configured is through the exists_configuration function as described above).
if( exists_configuration('top.bus.SlaveList') ){ my $sl = get_configuration('top.bus.SlaveList'); --- Some code that manipulates the $sl list --- configure('top.bus.SlaveList', $sl); # <- override previous configuration with new configuration }else{ --- Some code that defines a new list --- configure('top.bus.SlaveList', $sl); } - remove_configuration('path.to.param') removes an existing parameter from the configuration database.
-
get_top_name() returns the name of the top module, as set using the command line "-top TopModuleName" flag.
my $top = get_top_name(); configure("$top.ParamName", 17); -
get_synthtop_path returns the path from the top module to the synthesis top.
my $synthpath = get_synthtop_path(); configure("$synthpath.ParamName", 19); - print_configuration outputs a (very :) pretty printout of all existing configurations to the screen (to stderr). Try it, it's beautiful...
- error("error message") print the error message as well as the line number and file, then exits with error code 7
It is sometimes desireable to create project-specific API. For example, create a few high level functions that can configure many internal parameters. Doing that with Genesis2 is super simple: Simply create your favorite package that holds the project specific configuration functions (e.g. CMP_Builder.pm), and from your configuration script use Perl's 'use' mechanism to call it. To allow CMP_Builder access to the same configuration methods as described above in Genesis2#Basic_Config_Files, CMP_Builder must use the predefined Genesis2 base package 'Genesis2::UserConfigBase'. Example:
CMP_Builder.pm:
----------------
use Exporter;
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK);
@ISA = qw(Exporter);
@EXPORT = qw(create_cache add_core);
@EXPORT_OK = qw();
$VERSION = '1.0';
use Genesis2::UserConfigBase;
sub add_core {
my $coreList = [];
if (exists_configuration('top.cmp.CoreList'){
$coreList = get_configuration('top.cmp.CoreList');
}
push (@$coreList, {coreType=>RISC, coreArch=>64});
configure('top.cmp.CoreList', $coreList);
}
sub create_cache{
...
}
4core.cfg:
-----------
use CMP_Builder;
add_core();
add_core();
add_core();
add_core();
create_cache();
...
Genesis2 produces some additional outputs, on top of the Verilog files: A log file (using the -log name.log flag), a dependent list (using the -depend depend_file_name flag), a product list (using the -product product_file_name flag), and an xml hierarchy representation of the design (using the -hierarchy hierarchy_file_name flag).
By default, Genesis2 produces a log file called genesis.log. The name can be modified using the -log filename switch. On top of capturing all messages from Genesis2, the log file includes both Genesis2's release information and the complete command used for that run.
List of the source .vp files and included .vph files that were used by Genesis2
This very important list is a list of the generated verilog (.v or .sv) files. This list is convenient, for example for use as input to downstream tools such as VCS, or for use in makefiles. Note that the list is arranged in reverse hierarchical order which means the lowest level modules are listed first, and the top module last. The reason for this reversed order is so that it can be used for compilation by downstream tools.
Genesis2 produces three lists: one for all files generated (for validation/simulation); one for synthesis subset; and one with testbench only (for gate level simulation). The synthesis subset is determined by the -synthtop flag as described here. The name of the 'product' list of generated files is set by the -product command line flag and defaults to genesis_vlog.vf. The name of the 'for-synthesis' product list is set by taking the name of the 'product' list, and adding .synth. between the file name and its suffix. The name of the 'verif-only' product list is set by taking the name of the 'complete' list, and adding .verif. between the file name and its suffix. For example, for the default 'product' file name genesis_vlog.vf, the 'for-synthesis' file name would be genesis_vlog.synth.vf and the 'verif-only' file is genesis_vlog.verif.vf'.
The XML hierarchy output representation is almost identical to the input XML program. It also has a very simple structure, but it adds more information about source and target modules and files. In addition to providing useful feedback to the designer, the hierarchical XML was designed to be used as a template for the XML input program.
- See Genesis2SchemaXSD page for a complete schema description.
- See the -hierarchy switch, in the Invoking Genesis in Generate Mode section for invoking this feature
-
General tree structure: For each module instance in the hierarchy (including HierarchyTop) the following recursive structure is used. It has a BaseModuleName, SynonymFor, InstanceName, ImmutableParameters, Parameters, SubInstances, UniqueModuleName
- BaseModuleName: The name of the template module before uniquification
- SynonymFor: If the base module (or template) is just a synonym for some other base module (created by using the synonym function), the field SynonymFor appears in addition to the BaseModuleName. The SynonymFor value is the base module name for which this module is synonym. If module ModuleC is synonym to ModuleB which is in turn synonym to ModuleA, than the value of SynonymFor is the basis of the chain---ModuleA.
- InstanceName: The name of the instance that was generated
- ImmutableParameters: A list of zero or more ParameterItem elements. ImmutableParameters has the exact same structure as that of the Parameters element. However, while Parameters can be altered and re-fed into Genesis2 using the input xml program to create new RTL, ImmutableParameters are parameters that where already assigned a value, either using ''parameter(Name=>'prm', Val=>..., Force=>1)'' call or at instantiation using the generate(TemplateName, InstanceName, prm=>val) call.
-
Parameters: A list of zero or more ParameterItem elements. In addition to the Name and Val fields as described for the input xml schema, the output XML schema also has a Doc and a Range elements, but only for simple Val parameters (i.e., simple parameters that are numbers or strings but not arrays or hashes or pointers).
- Doc: A documentation or description of a parameter.
-
Range: An allowed range for a parameter value. The Range element support two mutually exclusive options:
- List: A list of allowed values. Or,
- Min and/or Max and/or Step: At least on of Min or Max element and optionally a Step element.
- Opt: This field may only show up if a Range field was used. It is optional however. Allowed values are {Yes, No, Try} when it shows in the Parameters list. Allowed values are {No, NotRightNow} when it shows in the ImmutableParameters list.
- SubInstances: A list of SubInstanceItem elements that represent the sub-instances in the current hierarchy level. See more in the input xml schema section.
- UniqueModuleName: The name of the generated module after uniquification
- CloneOf: If the instance is a clone of another instance, the field CloneOf appears instead of the fields Parameters, ImmutableParameters and SubInstances. CloneOf would then have a sub-element, InstancePath, that holds the a text path to the original instance (e.g., top.dut.subinst.subsubinst).
Tools need the complete XML (hierarchy_out.xml), but for humans it is quite annoying... right? So Genesis produces both the hierarchy_out.xml (for tools) and small_hierarchy_out.xml (for more human tools). The "small_" version, still contains the entire hierarchy, but only prints tweakable parameters (i.e. skips ImmutableParameters) and also skips other meta data that most humans don't care about (thus probably half the size or less).
The result is a minimalistic XML file that conforms with the input xml structure. Refer to the input xml program section for the basic structure of the XML tree.
The "tiny_" version of the XML (e.g., tiny_hierarchy_out.xml) is an even more minimalistic structure than the "small_" file. It contains only information about parameters and nothing else, but it contains only information about parameters whose value, during the last round of generation, was set from the input xml. That is, it contains only parameters that are not at their default value. In most cases, this is equivalent to the input XML file, unless the input actually contained unused parameters (eg for modules that no longer exist in this round of generation).
The result is a minimalistic XML file that conforms with the input xml structure. Refer to the input xml program section for the basic structure of the XML tree.
Next is an example of a complete XML hierarchy. In this example, the top level instantiate 2 Wallace trees. In addition, it instantiate two clones of those Wallace trees (only for the purpose of this example). In addition, (again, for the example only) each Wallace module has numerous parameter definitions of various kinds.
<HierarchyTop>
<BaseModuleName>top</BaseModuleName>
<ImmutableParameters></ImmutableParameters>
<InstanceName>top</InstanceName>
<Parameters>
<ParameterItem>
<ArrayType>
<ArrayItem>
<Val>32</Val>
</ArrayItem>
<ArrayItem>
<Val>64</Val>
</ArrayItem>
</ArrayType>
<Doc></Doc>
<Name>WALLACES_WIDTHS</Name>
</ParameterItem>
</Parameters>
<SubInstances>
<SubInstanceItem>
<BaseModuleName>wallace</BaseModuleName>
<ImmutableParameters>
<ParameterItem>
<Doc>This is the bit width of the partial products</Doc>
<Name>N</Name>
<Range>
<List>8</List>
<List>16</List>
<List>32</List>
<List>64</List>
</Range>
<Val>32</Val>
</ParameterItem>
</ImmutableParameters>
<InstanceName>wallace_32</InstanceName>
<Parameters>
<ParameterItem>
<Name>COND</Name>
<Doc>the value can be true or false</Doc>
<Range>
<List>false</List>
<List>true</List>
</Range>
<Val>false</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMin</Name>
<Doc></Doc>
<Range>
<Min>106</Min>
</Range>
<Val>107</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMax</Name>
<Doc></Doc>
<Range>
<Max>210</Max>
</Range>
<Val>200</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMinStep</Name>
<Doc></Doc>
<Range>
<Min>300</Min>
<Step>3</Step>
</Range>
<Val>309</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMaxStep</Name>
<Doc></Doc>
<Range>
<Max>410</Max>
<Step>2</Step>
</Range>
<Val>404</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMinMax</Name>
<Doc></Doc>
<Range>
<Max>510</Max>
<Min>500</Min>
</Range>
<Val>505</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMinMaxStep</Name>
<Doc></Doc>
<Range>
<Max>630</Max>
<Min>610</Min>
<Step>2</Step>
</Range>
<Val>622</Val>
</ParameterItem>
<ParameterItem>
<Name>ParamExamplePointerToMe</Name>
<Doc></Doc>
<InstancePath>top.wallace_32</InstancePath>
</ParameterItem>
<ParameterItem>
<Name>ParamHash</Name>
<Doc></Doc>
<HashType>
<HashItem>
<Key>alma</Key>
<Val>4</Val>
</HashItem>
<HashItem>
<Key>neta</Key>
<Val>2</Val>
</HashItem>
<HashItem>
<Key>ofer</Key>
<Val>1</Val>
</HashItem>
<HashItem>
<Key>ori</Key>
<Val>3</Val>
</HashItem>
</HashType>
</ParameterItem>
<ParameterItem>
<Name>ParamComplexStruct</Name>
<Doc></Doc>
<ArrayType>
<ArrayItem>
<Val>value</Val>
</ArrayItem>
<ArrayItem>
<ArrayType>
<ArrayItem>
<Val>1</Val>
</ArrayItem>
<ArrayItem>
<Val>2</Val>
</ArrayItem>
<ArrayItem>
<Val>3</Val>
</ArrayItem>
<ArrayItem>
<Val>4</Val>
</ArrayItem>
</ArrayType>
</ArrayItem>
<ArrayItem>
<HashType>
<HashItem>
<Key>a</Key>
<Val>1</Val>
</HashItem>
<HashItem>
<Key>b</Key>
<Val>2</Val>
</HashItem>
<HashItem>
<Key>c</Key>
<Val>3</Val>
</HashItem>
<HashItem>
<ArrayType>
<ArrayItem>
<Val>a</Val>
</ArrayItem>
<ArrayItem>
<Val>b</Val>
</ArrayItem>
<ArrayItem>
<Val>c</Val>
</ArrayItem>
<ArrayItem>
<Val>x</Val>
</ArrayItem>
</ArrayType>
<Key>d</Key>
</HashItem>
</HashType>
</ArrayItem>
</ArrayType>
</ParameterItem>
</Parameters>
<SubInstances></SubInstances>
<UniqueModuleName>wallace_unq1</UniqueModuleName>
</SubInstanceItem>
<SubInstanceItem>
<BaseModuleName>wallace</BaseModuleName>
<CloneOf>
<InstancePath>top.wallace_32</InstancePath>
</CloneOf>
<InstanceName>clone_of_wallce_32</InstanceName>
<UniqueModuleName>wallace_unq1</UniqueModuleName>
</SubInstanceItem>
<SubInstanceItem>
<BaseModuleName>wallace</BaseModuleName>
<ImmutableParameters>
<ParameterItem>
<Doc>This is the bit width of the partial products</Doc>
<Name>N</Name>
<Range>
<List>8</List>
<List>16</List>
<List>32</List>
<List>64</List>
</Range>
<Val>64</Val>
</ParameterItem>
</ImmutableParameters>
<InstanceName>wallace_64</InstanceName>
<Parameters>
<ParameterItem>
<Name>COND</Name>
<Doc>the value can be true or false</Doc>
<Range>
<List>false</List>
<List>true</List>
</Range>
<Val>false</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMin</Name>
<Doc></Doc>
<Range>
<Min>106</Min>
</Range>
<Val>107</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMax</Name>
<Doc></Doc>
<Range>
<Max>210</Max>
</Range>
<Val>200</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMinStep</Name>
<Doc></Doc>
<Range>
<Min>300</Min>
<Step>3</Step>
</Range>
<Val>309</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMaxStep</Name>
<Doc></Doc>
<Range>
<Max>410</Max>
<Step>2</Step>
</Range>
<Val>404</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMinMax</Name>
<Doc></Doc>
<Range>
<Max>510</Max>
<Min>500</Min>
</Range>
<Val>505</Val>
</ParameterItem>
<ParameterItem>
<Name>ParWithMinMaxStep</Name>
<Doc></Doc>
<Range>
<Max>630</Max>
<Min>610</Min>
<Step>2</Step>
</Range>
<Val>622</Val>
</ParameterItem>
<ParameterItem>
<Name>ParamExamplePointerToMe</Name>
<Doc></Doc>
<InstancePath>top.wallace_64</InstancePath>
</ParameterItem>
<ParameterItem>
<Name>ParamHash</Name>
<Doc></Doc>
<HashType>
<HashItem>
<Key>alma</Key>
<Val>4</Val>
</HashItem>
<HashItem>
<Key>neta</Key>
<Val>2</Val>
</HashItem>
<HashItem>
<Key>ofer</Key>
<Val>1</Val>
</HashItem>
<HashItem>
<Key>ori</Key>
<Val>3</Val>
</HashItem>
</HashType>
</ParameterItem>
<ParameterItem>
<Name>ParamComplexStruct</Name>
<Doc></Doc>
<ArrayType>
<ArrayItem>
<Val>value</Val>
</ArrayItem>
<ArrayItem>
<ArrayType>
<ArrayItem>
<Val>1</Val>
</ArrayItem>
<ArrayItem>
<Val>2</Val>
</ArrayItem>
<ArrayItem>
<Val>3</Val>
</ArrayItem>
<ArrayItem>
<Val>4</Val>
</ArrayItem>
</ArrayType>
</ArrayItem>
<ArrayItem>
<HashType>
<HashItem>
<Key>a</Key>
<Val>1</Val>
</HashItem>
<HashItem>
<Key>b</Key>
<Val>2</Val>
</HashItem>
<HashItem>
<Key>c</Key>
<Val>3</Val>
</HashItem>
<HashItem>
<ArrayType>
<ArrayItem>
<Val>a</Val>
</ArrayItem>
<ArrayItem>
<Val>b</Val>
</ArrayItem>
<ArrayItem>
<Val>c</Val>
</ArrayItem>
<ArrayItem>
<Val>x</Val>
</ArrayItem>
</ArrayType>
<Key>d</Key>
</HashItem>
</HashType>
</ArrayItem>
</ArrayType>
</ParameterItem>
</Parameters>
<SubInstances></SubInstances>
<UniqueModuleName>wallace_unq2</UniqueModuleName>
</SubInstanceItem>
<SubInstanceItem>
<BaseModuleName>wallace</BaseModuleName>
<CloneOf>
<InstancePath>top.wallace_64</InstancePath>
</CloneOf>
<InstanceName>clone_of_wallce_64</InstanceName>
<UniqueModuleName>wallace_unq2</UniqueModuleName>
</SubInstanceItem>
</SubInstances>
<UniqueModuleName>top</UniqueModuleName>
</HierarchyTop>This file contains commands to clean all files generated by Genesis2. To use it simply source it:
&gt;&gt; source genesis_clean.cmd