lowRISC / lowRISC/dvsim

Let a use_cfgs entry pin its own tool

Open
#253 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
13
Forks
21
Avg merge
1d 11h
Merged PRs (30d)
8

Description

Part of lowRISC/dvplan#129.

Running a simulation regression under Xcelium and a formal regression under VC Formal in one invocation is a requirement for the bundle work, and it cannot be expressed today.

`tool` is the one key a config cannot set for itself once the command line gives it, by way of `_CMDLINE_FIELDS` in `flow/hjson.py`. Scalar merging is first-non-default-wins and raises on a genuine conflict, so a config setting `tool: vcformal` while importing OpenTitan's `common_formal_cfg.hjson`, which pins `tool: jaspergold`, fails to load with a conflicting-value error. The only way to select VC Formal is `--tool vcformal` on the command line, which applies to every config in the invocation.

## Scope

- Let a `use_cfgs` entry carry a `tool`, seeded into that child's `initial_values`. Because `arg_keys` is computed from the keys present in `initial_values`, a seeded value wins over every imported file, which is exactly the mechanism `--tool` already uses. No changes needed in any OpenTitan or Mocha config.
- `create_instance` and `_load_child_cfg` in `flow/base.py` take the per-child overrides, and the factory closure in `flow/factory.py` applies them.
- `--tool` on the command line keeps overriding everything, since that is what it is for.
- Reject an override for a key other than `tool` for now, so this does not quietly become a general-purpose per-child config channel. That belongs with #36.

## Done when

- A primary config with one child pinned to `xcelium` and another pinned to `vcformal` loads, and each child's scratch path and tool config come from its own tool.
- A test covers the load, since the failure mode today is a `RuntimeError` from config merging and is easy to reintroduce.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing create_instance and _load_child_cfg in flow/base.py through the factory closure in flow/factory.py, then inspect _CMDLINE_FIELDS in flow/hjson.py. Add the per-child tool handling while preserving command-line precedence and rejecting other override keys, then add a load regression test showing separate xcelium and vcformal children use their own tool settings and scratch paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
build-system
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.