simulations/<sim>/_settings.yml

A simulation is a directory under sim_path (default odatix_userconfig/simulations/) holding a testbench and everything needed to run it. The whole directory is copied into each job’s work directory, next to the RTL of the configuration under test.

odatix_userconfig/simulations/TB_Example_Counter_GHDL/
├── _settings.yml    # this page — optional
├── _metrics.yml     # what to extract — optional
├── Makefile         # the default entry point: "make sim"
└── tb/              # testbench sources

_settings.yml is optional. Without it, the architecture’s own settings are used and Odatix runs make sim from the simulation’s Makefile.

What the simulation runs

Task entries take exactly the same keys as a workflow’s: name, commands, dependencies, path, platforms. Execution always starts at the task named main.

tasks:
  - name: analyze
    commands:
      - ghdl -a --workdir=obj rtl/* tb/*

  - name: main
    dependencies:
      - analyze
    commands:
      - ghdl -e --workdir=obj tb_counter
      - ghdl -r --workdir=obj tb_counter --stop-time=500ns | tee log/sim.log

Placeholders available in commands

${rtl_dir}, ${log_dir} and ${odatix_dir} are the former names of ${rtl_path}, ${log_path} and ${odatix_path}. They still work, but the new ones match the variables of the EDA tools and are what the editors offer.

Progress reporting

progress:
  file: "log/progress.log"
  regex: "(.*): ([0-9]+)%(.*)"

The value feeds the progress bar of the Job Monitor.

Architectures

A testbench is written for a design, or for a handful of designs sharing an interface. Which ones they are is the architectures block, and an architecture with nothing to change is written as its bare name:

architectures:
  - Example_Cordic_sv
  - Example_Cordic_vhdl

Listing an architecture is an indication, not a restriction. Running the simulation on one it does not list works exactly as before, and only prints a warning:

[simulation_handler.py] warning: "Example_Counter_vhdl" is not one of the architectures "TB_Example_Cordic_GHDL" runs on

An empty list, or no key at all, means the simulation lists nothing: the run warns about no architecture, and the GUI offers none until you add one.

An architecture that needs something done differently holds it under its name:

architectures:
  - Example_Cordic_sv:
      param_domains:
        width:
          param_target_file: "tb/tb_cordic.sv"
      metrics_file: "_metrics_sv.yml"

  - Example_Cordic_vhdl:
      param_domains:
        width:
          param_target_file: "tb/tb_cordic.vhdl"

Names accept wildcards, "*" standing for every architecture, and every entry matching the design under test applies, in the order they are written — so a specific architecture placed after a wildcard refines it instead of being shadowed by it:

architectures:
  - "*":
      param_domains:
        width:
          param_target_file: "tb/tb_cordic.sv"
  - Example_Cordic_vhdl:
      param_domains:
        width:
          param_target_file: "tb/tb_cordic.vhdl"

Parameters

A simulation inherits the design’s parameter replacement: every parameter domain of the configuration is spliced into the design before the testbench runs. param_domains adjusts that for one architecture — the testbench often needs the same value the design got, but in a file of its own.

Every key is optional: what is not listed is inherited from the domain’s own settings in the architecture. Domain names match the directories under the architecture (width/, iterations/, …).

architectures:
  - Example_Cordic_sv:
      param_domains:
        width:
          param_target_file: "tb/tb_cordic.sv"   # same value, applied to the testbench
        iterations:
          use_parameters: No                     # testbench does not care about this one

Simulation-only domains

A name that matches no domain of the architecture declares a replacement of the simulation’s own. Use it for values only the testbench cares about — a run length, a seed, a verbosity level. param_file, start_delimiter and stop_delimiter are then required, since there is nothing to inherit them from.

architectures:
  - Example_Counter_vhdl:
      param_domains:
        sim_config:
          param_file:        "sim_params.txt"
          param_target_file: "tb/tb_counter.vhdl"
          start_delimiter:   "-- <sim>"
          stop_delimiter:    "-- </sim>"

Invariant domains

Declaring one has two effects: only one value of that domain is simulated instead of all of them, and the result carries no such dimension — so a synthesis result borrowing a metric from this simulation gets it whatever the value of that domain.

invariant_domains: [MEM]          # let Odatix pick which value runs

invariant_domains:
  MEM: 1024I_1024D                # run this one

See Derived metrics for why this matters when simulation and synthesis figures are combined.

_metrics.yml

Optional, and identical in format to a workflow’s — see Metrics files. It declares what to extract from each run; results land in results/results_simulation.yml. A simulation with no _metrics.yml exports nothing, which is fine for a testbench that only has to pass.

An architecture whose runs report something else names its own file with metrics_file, which then replaces _metrics.yml for that architecture alone.

metrics:
  Cycles:
    type: regex
    settings:
      file: log/sim.log
      pattern: "Total cycles: ([0-9]+)"
      group_id: 1
    format: "%.0f"
    unit: cycles

In the GUI

RTL Architectures → Simulations edits this file, with the same task editor as workflows, and the metrics editor for _metrics.yml. See The Odatix GUI.

Run Jobs → Simulations shows only the architectures a simulation lists. The cross next to an architecture takes it out of the list, and the dropdown at the bottom of the simulation card puts one back. Both are edits like any other: the Save button turns orange, and architectures is written to this file when you press it.

Each card of the Parameter Domains section of the Simulation Editor carries an Architecture field holding the architecture the override applies to — wildcards included, and * for every architecture. Two cards with the same domain name but a different architecture are two independent overrides. Editing them never touches what else an architecture entry holds, so a metrics_file set by hand survives.

See also

• Feature: Simulation & validation — what this file is for.
• Tutorial: Simulate your own RTL.
• Workflow settings — the task graph format in full.
• Run settings files — mapping a simulation to configurations.