GHDL: generics leak between configurations when `ghdl.sim_flags` is set

オープン 初心者向け
  • 何か問題がありますか？
#1,223 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@prds-code がすでに取り組んでいます。

2026年9月23日 から。

  • #1224 @prds-code による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
領域
testing

調査の方向性

vunit/sim_if/ghdl.py の GHDLInterface._get_command() から始め、ghdl.sim_flags に実行フラグ、ジェネリック、アサーションレベルがどのように追加されるかを調べてください。提供されている tb_generic_leak.vhd と run.py の例を -p1 -v で実行し、漏れを再現してください。設定が以前のシミュレーションのジェネリックフラグを引き継がなくなり、両方の設定で期待値が報告されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Description

With GHDL, a configuration can be simulated with generics set by another configuration. When ghdl.sim_flags is set, every simulation appends its -g<name>=<value> flags to one list shared by all configurations of the test bench. GHDL uses the last -g for each generic. So a configuration inherits any generic set by an earlier simulation that it doesn't set itself.

Which configurations are affected depends on the order in which they are simulated. Serial runs fail deterministically when a configuration that sets a generic runs before one that relies on its default. Parallel runs fail intermittently, and a test can pass while simulating the wrong configuration.

Reproduction

tb_generic_leak.vhd:

library vunit_lib;
context vunit_lib.vunit_context;

entity tb_generic_leak is
  generic (
    runner_cfg : string;
    a : integer := 0;
    b : integer := 0
  );
end entity;

architecture tb of tb_generic_leak is
begin
  main : process
  begin
    test_runner_setup(runner, runner_cfg);
    info("a = " & integer'image(a) & ", b = " & integer'image(b));
    test_runner_cleanup(runner);
  end process;
end architecture;

run.py:

from pathlib import Path
from vunit import VUnit

vu = VUnit.from_argv()
vu.add_vhdl_builtins()
lib = vu.add_library("lib")
lib.add_source_files(Path(__file__).parent / "tb_generic_leak.vhd")

vu.set_sim_option("ghdl.sim_flags", ["--ieee-asserts=disable"])

tb = lib.test_bench("tb_generic_leak")
# Configurations are simulated in the order they are added when running serially
tb.add_config(name="sets_b", generics=dict(b=1))
tb.add_config(name="sets_a", generics=dict(a=1))  # b is expected to keep its default (0)

vu.main()

Run it with python run.py -p1 -v:

sets_b: INFO - a = 0, b = 1
sets_a: INFO - a = 1, b = 1   <- expected b = 0

The output is correct in either of these cases:

  • The set_sim_option("ghdl.sim_flags", ...) call is left out, because .get(..., []) then returns a new list each time.
  • The call is moved after the add_config() calls, because each existing configuration then gets its own copy of the list. Only configurations added after the option is set share the default configuration's list.

Cause

In vunit/sim_if/ghdl.py, GHDLInterface._get_command() does this:

sim = config.sim_options.get("ghdl.sim_flags", [])
sim += hooks.get_flags(self, "run_flags")
for name, value in config.generics.items():
    sim += [f"-g{name!s}={value!s}"]
sim += [f"--assert-level={config.vhdl_assert_stop_level!s}"]

sim is the list object stored in sim_options, so += extends it in place. That list can be shared between configurations:

  • set_sim_option() copies the value once into each configuration that exists at that point, including the default configuration.
  • Configuration.copy(), used by add_config() and in IndependentSimTestCase._simulate(), makes only a shallow copy of sim_options. So configurations added after the option is set share the default configuration's list.

The shared list therefore grows by one set of -g flags per simulation. Instrumenting _get_command() on a 16-test project showed the same list object for every configuration, and its length went 2 -> 12 -> 24 -> …

Fix

Copying the list before extending it worked in my case, but maybe there is a better/more general fix.

-        sim = config.sim_options.get("ghdl.sim_flags", [])
+        sim = list(config.sim_options.get("ghdl.sim_flags", []))

Environment

  • VUnit 5.0.0.dev12 (master at af474320)
主要言語
VHDL
スター
850
フォーク
305
平均マージ
2日 13分
マージ済み PR（30日）
9

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

VUnit/vunit のほかの issue

VUnit/vunit の issue をすべて見る

似ている issue

Testing & QA の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。