Define Parameter Domains

In Odatix, a parameter domain defines a set of parameters for a given hardware architecture. The goal is to streamline the implementation of parameter combinations. This way, users do not have to manually create a configuration file for each parameter combination. This is particularly useful when dealing with a large set of parameters.

Note

This functionality requires Odatix 3.4+

Important

Before defining a parameter domain, make sure you have already defined your architecture folder in odatix_userconfig/architectures.

File Structure

To define parameter domains, users must create dedicated sub-folders for each parameter domain inside their architecture directory in odatix_userconfig/architectures/. Each sub folder must contain a parameter domain definition file _settings.yml and parameter files. This is similar to how the main paramater domain work (see Add your own design)

Example of file structure:

odatix_userconfig/architectures/AsteRISC/
├── Baseline
│   ├── _settings.yml             # 'Baseline' parameter domain settings
│   ├── E.txt                     # 'Baseline' parameter domain architecture configuration
│   └── I.txt                     # 'Baseline' parameter domain architecture configuration
├── DMEM
│   ├── _settings.yml             # 'DMEM' parameter domain settings
│   ├── 256.txt                   # 'DMEM' parameter domain architecture configuration
│   ├── 512.txt                   # 'DMEM' parameter domain architecture configuration
│   ├── 1024.txt                  # 'DMEM' parameter domain architecture configuration
│   ├── 2048.txt                  # 'DMEM' parameter domain architecture configuration
│   └── 4096.txt                  # 'DMEM' parameter domain architecture configuration
├── IMEM
│   ├── _settings.yml             # 'IMEM' parameter domain settings
│   ├── 256.txt                   # 'IMEM' parameter domain architecture configuration
│   ├── 512.txt                   # 'IMEM' parameter domain architecture configuration
│   ├── 1024.txt                  # 'IMEM' parameter domain architecture configuration
│   ├── 2048.txt                  # 'IMEM' parameter domain architecture configuration
│   └── 4096.txt                  # 'IMEM' parameter domain architecture configuration
├── Mul
│   ├── _settings.yml             # 'Mul' parameter domain settings
│   ├── Basic.txt                 # 'Mul' parameter domain architecture configuration
│   ├── Fast.txt                  # 'Mul' parameter domain architecture configuration
│   ├── Off.txt                   # 'Mul' parameter domain architecture configuration
│   └── Single_cycle.txt          # 'Mul' parameter domain architecture configuration
├── _settings.yml                 # Main architecture settings
├── M0000.txt                     # Main architecture configuration
├── M0001.txt                     # Main architecture configuration
├── M0008.txt                     # Main architecture configuration
├── M0016.txt                     # Main architecture configuration
├── M0024.txt                     # Main architecture configuration
├── ...
└── M0111.txt                     # Main architecture configuration

Each subfolder corresponds to a different parameter domain (e.g., DMEM, IMEM, Mul). Inside each, different values for that parameter are specified in paramter files (e.g., 1024.txt, 2048.txt) and a parameter domain definition file _settings.yml defines how the parameter files should be used within the rtl sources files.

YAML Definition

Users must also provide a YAML file that specifies the configuration settings. These files contain parameters that control architecture variations, including parameter delimiters, parameter files, and target files.

A basic parameter domain settings file only contains delimiters for replacement in the top-level file. Any delimiter can be used, as long as it complies with the syntax of the HDL in use.

Example: Verilog Module with Parameters

top_level.sv
 1module top_level #(
 2  // <imem>
 3  parameter p_imem_depth_pw2  = 14,
 4  // </imem>
 5  // <dmem>
 6  parameter p_dmem_depth_pw2  = 13,
 7  // </dmem>
 8
 9  // <baseline>
10  parameter p_ext_rve         = 0,
11  // </baseline>
12
13  // <mul>
14  parameter p_ext_rvm         = 0,
15  parameter p_mul_fast        = 0,
16  parameter p_mul_1_cycle     = 0,
17  // </mul>
18
19  // <main>
20  //...
21  // </main>
22) (

Example: YAML settings file for a parameter domain

baseline/_settings.yml
1start_delimiter: "  // <baseline>"
2stop_delimiter: "  // </baseline>"

Important

If parameter replacements are needed in a different file from the top-level module, specify it with param_target_file:

other_domain/_settings.yml
1start_delimiter: "// start"
2stop_delimiter: "// end"
3param_target_file: "src/main/scala/counter.scala"

Warning

With RTL generation (HLS or Chisel for example), param_target_file is mandatory. Indeed, the destination file is not the top-level (which is not generated yet at the time of replacement)

Dynamic Configuration Generation

Parameter domains can also dynamically generate configurations.

For example, DMEM can generate multiple configurations for different memory sizes:

DMEM/_settings.yml
 1start_delimiter: "  // <dmem>"
 2stop_delimiter: "  // </dmem>"
 3param_target_file: "top.v"
 4
 5generate_configurations: Yes
 6generate_configurations_settings:
 7  template: "\n  parameter p_dmem_depth_pw2  = $mem_depth,\n"
 8  name: "${mem_depth_pw2}"
 9  variables:
10    mem_depth:
11      type: range
12      settings:
13        from: 8
14        to: 12
15    mem_depth_pw2:
16      type: function
17      settings:
18        op: 2^$mem_depth

This generates multiple parameter values dynamically, allowing automated exploration of different memory configurations.

Run jobs with your parameter domains

Once the parameter domains are defined, specify different architecture configurations in the YAML configuration file. Parameter domains are separated by a +.

Example YAML file:

odatix_userconfig/fmax_synthesis_settings.yml
 1architectures:
 2  - AsteRISC/M0000 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Off
 3  - AsteRISC/M0001 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Off
 4  - AsteRISC/M0008 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Off
 5  - AsteRISC/M0016 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Off
 6  - AsteRISC/M0024 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Off
 7
 8  - AsteRISC/M0000 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Fast
 9  - AsteRISC/M0001 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Fast
10  - AsteRISC/M0008 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Fast
11  - AsteRISC/M0024 + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Fast

Each line describes a design variant, where different parameter domains are combined dynamically.

You can also use wildcard to run all matching architecture configurations:

  • On main architecture configurations:

odatix_userconfig/fmax_synthesis_settings.yml
1architectures:
2  - AsteRISC/* + DMEM/1024 + IMEM/1024 + Baseline/I + Mul/Off

  • On any parameter domain:

odatix_userconfig/fmax_synthesis_settings.yml
1architectures:
2  - AsteRISC/M0000 + DMEM/* + IMEM/* + Baseline/* + Mul/*

  • On both:

odatix_userconfig/fmax_synthesis_settings.yml
1architectures:
2  - AsteRISC/* + DMEM/* + IMEM/* + Baseline/* + Mul/*

Tip

Parameter domains can be used for any type of job, including:

  • Fmax synthesis

  • Custom frequency synthesis

  • Simulations

—

See Also