Claude Code を使用して SystemVerilogシミュレータを開発してみた (12/20開発状況)

Last updated at 2025-12-22Posted at 2025-12-20

はじめに

前回の記事「Claude Code を使用して SystemVerilogシミュレータを開発してみた (特許リスク調査編)」では、特許リスクについて調査し、公開を控える決断をしたことを報告しました。

しかし、開発自体は続けています。2025年12月20日現在、sukimasimはIEEE 1800-2023に対して約99%準拠(自分調べ)を達成するまでに成長しました。

この記事では、特許リスクのある最適化技術を無効化しつつ、どこまで開発が進んだかを報告します。

この記事の要約

高リスクの最適化技術（並列化、JIT、SIMD）を無効化し、特許リスクを低減
IEEE 1800-2023の約99%をサポート(自分調べ)
UVM 1.2 100%準拠
SSF v3/v4.3波形フォーマット（別記事で解説）をサポート
DAP（Debug Adapter Protocol）サポートでVSCode統合デバッグ
xrun互換CLIでCadence Xceliumからの移行が容易
Lua + Sol2スクリプト環境を新規実装 (別記事で解説）
SystemC混在シミュレーションに対応 (別記事で解説）
開発過程で作成したリグレッションテストの7,714のテスト全てパス を達成
gRPC + protobuf通信基盤でFMI 3.0デジアナ混載シミュレーションを計画中（別記事で解説）

開発方針の転換：安全な実装へ

無効化した高リスク機能

前回の記事で特許リスクが高いと判断した機能を無効化・ビルドから除外しました：

無効化・ビルド除外した機能：
├── ThreadPoolExecutor（ワークスティーリングキュー）← ビルドから除外
├── SIMD最適化（AVX-512）← ビルドから除外
├── LoopFusionEngine（ループ融合）← ビルドから除外
└── 実行時統計ベースの適応最適化 ← 無効化

これらはClaude Codeが「高速化のために」と実装した機能でしたが、商用シミュレータの特許領域に踏み込んでいる可能性があったため、ビルドから除外または無効化しました。ソースコードは残存していますが、デフォルトでは使用されません。

残した安全な機能

残した機能：
├── Fast Mode（変数アクセス高速化）
├── Memory Pool（メモリ効率化）
├── Move Semantics（コピー削減）
└── 基本的なコンパイラ最適化

これらは一般的なプログラミング技術なので、特許リスクは低いと判断しました。

無効化後のパフォーマンス

正直に言うと、パフォーマンスは落ちました。しかし、個人の学習・研究目的には十分な速度です。

最適化あり → なし：約3〜5倍遅くなった
しかし、それでも実用的な速度（小〜中規模デザインで問題なし）

安全な実装 > 高速だが危険な実装 という判断をしました。

IEEE 1800-2023 準拠状況

全体的な準拠率

カテゴリ	準拠率	テスト数
sv-tests（公式テストスイート）	100%	1,667/1,667 PASS
標準テストスイート	100%	5,229/5,229 PASS
拡張テストスイート（--extended）	100%	7,714/7,714 PASS
IEEE 1800-2023 総合	約99%	15カテゴリを評価
100%達成カテゴリ	14/15	§34保護エンベロープのみ未サポート

※拡張テストスイートは./scripts/update_dashboard.sh --extendedで実行（2025-12-20時点）

章別の準拠率

章	タイトル	準拠率	備考
Chapter 4	スケジューリング	100%	デルタサイクル完全実装
Chapter 6	データ型	95%	4値論理、構造体、共用体、実時間型の一部未実装
Chapter 7	配列	100%	動的配列、連想配列、キュー
Chapter 8	クラス	100%	継承、ポリモーフィズム、制約
Chapter 9	プロセス	100%	always_ff/comb/latch
Chapter 11	演算子	100%	ストリーミング演算子含む
Chapter 12	手続きプログラミング	100%	fork-join、disable
Chapter 16	アサーション	100%	SVA、65/65テストPASS
Chapter 18	制約付きランダム	100%	CSPソルバー実装
Chapter 19	機能カバレッジ	100%	covergroup、cross、FSM
Chapter 20-21	システムタスク	100%	$display、$fopen等
Chapter 23	合成指示子	0%	シミュレータとして不要
Chapter 24	プログラムブロック	100%	Reactiveリージョン
Chapter 34	保護エンベロープ	0%	ベンダー固有暗号化が必要（意図的未サポート）
Chapter 35	DPI-C	100%	C関数呼び出し完全実装
Chapter 36-37	VPI	100%	IEEE §38全関数実装

サポートしている主要機能

// 4値論理とパックド配列
logic [31:0] data;
logic [3:0][7:0] bytes;  // パックド2D配列

// クラスと制約
class Packet;
    rand bit [7:0] addr;
    rand bit [7:0] data;
    constraint c_valid { addr < 100; data != 0; }
endclass

// SVAアサーション
property p_req_ack;
    @(posedge clk) req |-> ##[1:5] ack;
endproperty
assert property (p_req_ack);

// 機能カバレッジ
covergroup cg @(posedge clk);
    cp_addr: coverpoint addr { bins low = {[0:31]}; bins high = {[32:63]}; }
    cp_data: coverpoint data;
    cross cp_addr, cp_data;
endgroup

// DPI-C
import "DPI-C" function int c_calculate(input int a, input int b);

// fork-join
fork
    begin : thread1
        @(posedge clk);
        data <= 8'hAB;
    end
    begin : thread2
        @(negedge clk);
        valid <= 1;
    end
join

意図的に非サポートの機能

機能	IEEE章	理由
実時間型の一部	§6.5	実装優先度が低い
合成指示子	§23	シミュレータとして不要
保護エンベロープ（pragma protect）	§34	ベンダー固有の暗号化キーが必要

UVM 1.2 100% 準拠

Phase A-E 完全実装

sukimasimはUVM 1.2の主要機能をすべて実装しています：

Phase A: Component階層
├── uvm_component: 階層構造・ライフサイクル管理
├── uvm_env/uvm_test: テスト環境構築
└── uvm_agent/uvm_driver/uvm_monitor: 検証コンポーネント

Phase B: Sequence Lifecycle
├── uvm_sequence/uvm_sequence_item: シーケンス定義
├── start()/body(): ライフサイクル管理
└── Sequencer Arbitration: 優先度制御

Phase C: RAL (Register Abstraction Layer)
├── uvm_reg/uvm_reg_block: レジスタモデル
├── frontdoor/backdoor: アクセス方式
└── mirror/predict: 値予測

Phase D: TLM 2.0
├── uvm_tlm_fifo: FIFOベース通信
├── put/get/peek: ブロッキングAPI
└── try_put/try_get: ノンブロッキングAPI

Phase E: 追加機能
├── Field Automation: `uvm_field_*マクロ
├── Barrier/Heartbeat: 同期機構
└── Event Pool: イベント管理

UVM テスト例

class my_test extends uvm_test;
    `uvm_component_utils(my_test)

    my_env env;

    function void build_phase(uvm_phase phase);
        env = my_env::type_id::create("env", this);
    endfunction

    task run_phase(uvm_phase phase);
        my_sequence seq;
        phase.raise_objection(this);
        seq = my_sequence::type_id::create("seq");
        seq.start(env.agent.sequencer);
        phase.drop_objection(this);
    endtask
endclass

実行方法

# UVMテストの実行
./build/sukimasim --enable-uvm test.sv +UVM_TESTNAME=my_test

# UVMオプション
./build/sukimasim --enable-uvm test.sv \
    +UVM_VERBOSITY=UVM_HIGH \
    +UVM_MAX_QUIT_COUNT=10 \
    +UVM_TIMEOUT=1000000

DAP（Debug Adapter Protocol）デバッグサーバー

VSCode統合デバッグ

sukimasimはMicrosoftのDebug Adapter Protocol（DAP）を実装しており、VSCodeやその他のDAP対応IDEからシミュレーションをデバッグできます。

デバッグ機能

実装済み機能:
├── ブレークポイント設定（行番号指定）
├── ステップ実行（step in/out/over）
├── シミュレーション時間表示（$time, $delta）
└── スコープ情報表示

未実装（TODO）:
├── 条件付きブレークポイント
├── 変数ウォッチ（信号値・変数値の取得）
├── 式評価（ホバー情報）
├── コールスタック（現在は1フレームのみ）
└── 時間ベースブレーク

注意: 現時点では行ブレークとステップ実行が中心の基本機能のみです。変数取得・式評価は今後の実装予定です。

使用方法

# DAPサーバーを起動してデバッグ待機
./build/sukimasim --debug-server test.sv

# ポートを指定（デフォルト: 9999）
./build/sukimasim --debug-server --debug-port 12345 test.sv

VSCode設定（launch.json）

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "sukimasim",
            "request": "attach",
            "name": "Attach to sukimasim",
            "port": 9999,
            "host": "localhost"
        }
    ]
}

SSF v3/v4.3 高圧縮波形フォーマット

VCD/FSTとの比較

sukimasimは独自のSSF（SukimaSim Format）波形フォーマットを実装しています。VCDと比較して大幅なファイルサイズ削減を実現：

フォーマット	圧縮率	書き込み速度	ランダムアクセス	備考
VCD	1x (基準)	高速	❌	業界標準テキスト形式
FST	10-50x	中速	✅	GTKWave標準形式
SSF v3	30-50x	高速	✅	デジタル波形向け
SSF v4.3	同等	高速	✅	SPICE互換（アナログ波形対応）

実測データ

実際のデザインでの比較結果：

32ビットカウンタ（10万サイクル）:
  VCD:  45.2 MB
  FST:   4.1 MB  (11x圧縮)
  SSF:   0.9 MB  (50x圧縮)

64ビットALU（5万サイクル）:
  VCD:  28.7 MB
  FST:   2.8 MB  (10x圧縮)
  SSF:   0.8 MB  (36x圧縮)

使用方法

# SSF波形出力（推奨）
./build/sukimasim --waveform output.ssf test.sv

# VCD波形出力（互換性重視）
./build/sukimasim --vcd output.vcd test.sv

# FST波形出力（GTKWave対応）
./build/sukimasim --fst output.fst test.sv

SSFの特徴

SSF v3 特徴:
├── Delta-encoding: 変化分のみ記録
├── LZ4/Zstandard/Zlib圧縮: 高速な圧縮・展開
├── 階層インデックス: 信号の高速検索
├── 時間インデックス: ランダムアクセス対応
└── ストリーミング書き込み: 低メモリ消費

SSF v4.3 追加機能:
├── SPICE互換バイナリ形式
├── Varintエンコーディング
└── 複数解析タイプ対応（過渡解析等）

xrun互換CLI

Cadence Xceliumからの移行支援

sukimasimはCadence Xceliumのxrunコマンドと互換性のあるオプションを提供しています。これにより、既存のスクリプトの小変更で使用できます。

互換オプション一覧

# 基本オプション
-top <module>          # トップモジュール指定
-timescale <ts>        # タイムスケール指定
-vcd <file>            # VCD波形出力
-debug                 # デバッグモード
-seed <n>              # 乱数シード

# UVM関連
-uvm                   # UVMサポート有効化
-uvmhome <path>        # UVMホームディレクトリ
+UVM_TESTNAME=<name>   # テスト名指定
+UVM_VERBOSITY=<level> # 出力レベル

# アサーション関連
-assert                # アサーション有効化
-abvrecordcoveraliases # カバレッジエイリアス記録

# コンパイル関連
-compile               # コンパイルのみ
-libext <ext>          # ライブラリ拡張子

# エラー制御
-errormax <n>          # 最大エラー数
-nowarn <code>         # 警告抑制

移行例

# xrun コマンド
xrun -top tb_top -vcd dump.vcd -uvm +UVM_TESTNAME=my_test test.sv

# sukimasim（互換）
./build/sukimasim -top tb_top -vcd dump.vcd -uvm +UVM_TESTNAME=my_test test.sv

# または標準オプション形式
./build/sukimasim --top tb_top --vcd dump.vcd --enable-uvm +UVM_TESTNAME=my_test test.sv

Lua + Sol2 スクリプト環境の実装

なぜLua + Sol2なのか

EDAツールの組み込みスクリプトといえばTclが定番ですが、C++との連携の煩雑さが気になりました。Lua + Sol2の組み合わせはC++との統合が非常にスムーズなので導入しました。

項目	Tcl	Lua + Sol2
C++バインディング	手動ラッパー必要	Sol2で自動・型安全
文法	独特	一般的で学習しやすい
サイズ	約1MB	約300KB

UVMとの使い分け

Lua + Sol2スクリプト環境は、UVMの代替ではなく補完的な位置づけです。規模や目的に応じて使い分けることで、開発効率が向上します。

観点	UVM	Lua + Sol2
適用規模	中〜大規模SoC検証	小〜中規模モジュール検証
学習コスト	高（クラス階層・フェーズ・シーケンス等）	低（数時間で習得可能）
セットアップ	テストベンチ構築に数日〜数週間	スクリプト1ファイルで即開始
再利用性	VIP/UVCで高い再利用性	単発テストに最適
デバッグ	複雑なログ解析が必要	printで即確認
対話的実行	非対応	REPL対応（インタプリタ動作）

Lua + Sol2が向いているケース：

IPモジュールの初期動作確認
バグ再現用の最小テストケース作成
インタラクティブなデバッグセッション
プロトタイピングや実験的な検証
CI/CDパイプラインでの軽量スモークテスト

Xcelium Tclモードの代替として

Cadence XceliumではTclベースの対話モード（xrun -tcl）が提供されていますが、sukimasimではLua + Sol2で同等の機能を実現します。

機能	Xcelium Tcl	sukimasim Lua + Sol2
対話モード起動	`xrun -tcl`	`--lua-interactive`
信号値取得	`value sig`	`sim.signal("sig"):get()`
信号値設定	`force sig value`	`sim.signal("sig"):set(value)`
時間進行	`run 100ns`	`sim.run(100)`
ブレークポイント	`stop -line file:10`	`sim.breakpoint("file", 10)`
変数表示	`describe var`	`print(var)`

# 対話モードでシミュレーション開始（計画中）
./build/sukimasim --lua-interactive test.sv

# 対話セッション例
lua> print(sim.time())
0
lua> sim.run(100)
lua> local clk = sim.signal("tb.clk")
lua> print(clk:get())
1
lua> clk:set(0)
lua> sim.run(10)

Luaはインタプリタ言語のため、シミュレーション実行中にリアルタイムでコマンドを入力・実行できます。これはデバッグ時に非常に有用で、Tclに慣れたエンジニアにも馴染みやすい操作感を提供します。

UVMが向いているケース：

チーム開発での標準化されたテストベンチ
VIP（Verification IP）を活用した本格検証
カバレッジドリブン検証
複数プロジェクトでの再利用

実装したAPI

-- シミュレーション時間の取得
local t = sim.time()
print("Current time:", t)

-- シミュレーションを進める
sim.run(100)

-- 信号へのアクセス
local clk = sim.signal("tb.dut.clk")
if clk then
    print("Clock width:", clk.width)
    print("Clock value:", clk:get())
    clk:set(1)  -- 値を設定
end

-- 遅延コールバック
sim.after(50, function()
    print("Callback at time:", sim.time())
end)

CLIオプション

# Lua + Sol2サポートを有効にしてビルド
cmake -B build -DENABLE_LUA_SCRIPTING=ON
cmake --build build

# Lua + Sol2スクリプトを実行
./build/sukimasim test.sv --lua verify.lua

# グローバル変数を定義
./build/sukimasim test.sv --lua verify.lua --lua-define SEED=12345

検証ライブラリの例

Lua + Sol2側で検証用のユーティリティを実装しました：

-- verify.lua
local V = {}

V.pass_count = 0
V.fail_count = 0

function V.assert_eq(actual, expected, msg)
    if actual == expected then
        V.pass_count = V.pass_count + 1
        return true
    else
        V.fail_count = V.fail_count + 1
        print(string.format("ASSERT FAILED: %s (expected %s, got %s)",
            msg or "", tostring(expected), tostring(actual)))
        return false
    end
end

function V.summary()
    print(string.format("Results: %d PASSED, %d FAILED",
        V.pass_count, V.fail_count))
    return V.fail_count == 0
end

return V

ハイブリッド戦略：SVA + 軽量スクリプト（Lua + Sol2）

すべてをLua + Sol2で書く必要はありません。SVAはSystemVerilogで、検証シナリオは軽量スクリプト（Lua + Sol2）でという使い分けが効果的です：

テストスイートによるリグレッションテスト

テストスイートの構成

テスト総数: 7,700+ テスト
カテゴリ数: 218 カテゴリ
実行時間: 約6-7分（フルスイート）

主要カテゴリ:
├── sv-tests (1,667テスト) — 公式テストスイート
├── assertions (75テスト) — SVAテスト
├── classes (50テスト) — OOPテスト
├── constraints (21テスト) — 制約テスト
├── dpi (30テスト) — DPI-Cテスト
├── uvm (57テスト) — UVMテスト
├── coverage (40テスト) — カバレッジテスト
└── ... その他200+カテゴリ

自動化されたダッシュボード

テスト結果は自動的にダッシュボードに集計されます：

# 全テストを実行してダッシュボード更新
./scripts/update_dashboard.sh

# 拡張カテゴリも含めて実行
./scripts/update_dashboard.sh --extended

生成されるダッシュボード：

# SukimaSim Test Results Dashboard

| Metric | Value |
|--------|-------|
| **Total Tests** | 7,714 |
| **Passed** | 7,714 |
| **Failed** | 0 |
| **Success Rate** | **100.0%** |

| Category | Passed | Total | Rate |
|----------|--------|-------|------|
| Sv Tests | 1,667 | 1,667 | 100% |
| Unit Tests | 626 | 626 | 100% |
| Assertions | 75 | 75 | 100% |
| UVM | 57 | 57 | 100% |
...

マニフェストベースのテスト管理

テストはtests/test_suite_manifest.jsonで管理されています：

{
  "test_categories": {
    "assertions": {
      "description": "Assertion and property tests",
      "base_path": "tests/assertions",
      "tests": [
        "test_basic_property.sv",
        "test_concurrent_assertion.sv",
        "test_cover_property.sv"
      ]
    },
    "lua": {
      "description": "Lua scripting integration tests",
      "base_path": "tests/lua",
      "extra_args": ["--lua", "tests/lua/test_lua_basic.lua"],
      "tests": ["test_lua_basic.sv"]
    }
  }
}

特定カテゴリの実行

# アサーションテストのみ実行
python3 scripts/run_test_category.py assertions

# パターンでフィルタ
python3 scripts/run_test_category.py assertions --pattern "cover"

# タイムアウト設定
python3 scripts/run_test_category.py real_world --timeout 300

開発統計

コード規模

C++ソースコード: 約15万行
ヘッダファイル: 約3万行
テストコード: 約5万行（SystemVerilog + C++）

技術スタック

sukimasimは以下のオープンソース技術を活用しています：

技術	用途	備考
slang	SystemVerilogパーサー・セマンティック解析	独自フォーク（slang-sukimasim）
CLI11	コマンドライン引数解析	xrun互換オプション実装
GoogleTest	C++ユニットテスト	626テスト
Lua 5.4 + Sol2	スクリプト環境	C++バインディング
LZ4/Zstd/Zlib	波形圧縮	SSF v3/v4.3

特にslangはMIT LicenseのSystemVerilogコンパイラフロントエンドで、IEEE 1800-2023の構文解析・型チェック・エラボレーションを担当しています。sukimasimはslangのASTを受け取り、シミュレーション実行を行う構成です。

開発期間

2025年6月: 初期開発開始
2025年7月-8月: 基本機能実装、sv-tests対応開始、特許調査
2025年9月-10月: 機能拡張、テストスイート整備、高リスク機能無効化
2025年11月-12月: IEEE 1800-2023準拠強化、Lua+Sol2対応、SystemC対応

AI活用の開発体制

sukimasimの開発では、複数のAIを役割分担して活用しています：

AI	役割	主な貢献
Claude Code	メイン開発	コード生成、デバッグ、ドキュメント
OpenAI Codex	コードレビュー・問題点抽出	IEEE 1800-2023準拠チェック、エッジケース指摘
Google Gemini	コードレビュー・問題点抽出	設計上の問題、パフォーマンス改善提案

このマルチAIレビュー体制により、単一AIでは見落としがちな問題を複数の視点から検出できています。

Claude Codeの貢献

Claude Codeは以下の開発に大きく貢献しました：

1. 初期実装の高速化
   - 約6ヶ月で主要機能を実装
   - 複雑なスケジューラロジックの生成

2. バグ修正
   - テスト失敗時の原因分析
   - 修正コードの提案

3. 機能追加
   - Lua + Sol2統合
   - VPI実装
   - SVAアサーションエンジン

4. ドキュメント
   - コードコメント
   - 技術文書
   - この記事も含めて

Codex・Geminiによるレビュー効果

CodexとGeminiによるレビューで発見された主な問題例：

Codexが指摘した問題:
├── DPI配列出力引数の書き戻し漏れ
├── パターンマッチングの構造体メンバーアクセス
└── NBA（Non-Blocking Assignment）の複雑LHS対応

Geminiが指摘した問題:
├── 制約ソルバーのタイムアウト処理
├── カバーグループのフォールバッククロック設定
└── アサーション無限サイクルモードの必要性

単一AIに依存せず、複数AIで相互チェックすることで、IEEE 1800-2023準拠率の向上に大きく貢献しました。

今後の計画

短期（1-2週間）

Lua + Sol2対話モード（--lua-interactive）の実装
Lua + Sol2 APIの拡張（エッジ検出イベント）
VPIテストカバレッジの拡充
UVMサポートの強化

中期（1ヶ月）

デバッグ機能の強化（DAP対応済み、UI改善）
波形出力の最適化（大規模デザイン対応）
ドキュメントの充実

長期：FMI 3.0によるデジアナ混載シミュレーション

現在、FMI 3.0（Functional Mock-up Interface）を使ったSPICEシミュレータとの連携によるデジアナ混載シミュレーションを計画しています。詳細は別記事で解説。

FMI 3.0とは

FMI（Functional Mock-up Interface）は、異なるシミュレーションツール間でモデルを交換・連携するための国際標準規格です：

項目	説明
標準化団体	Modelica Association
最新バージョン	FMI 3.0（2022年リリース）
主な用途	マルチドメイン・コシミュレーション
対応ツール	170以上（NGspice, Xyce, Simulink等）

なぜFMI 3.0なのか

従来のデジアナ混載アプローチとの比較：

方式	精度	速度	実装コスト
Verilog-AMS	高	中	高（専用パーサ必要）
wreal抽象モデル	低	高	低
FMI 3.0連携	高	中	中（標準API）

FMI 3.0を選んだ理由：

標準API: 既存SPICEツールがFMUエクスポートに対応
高精度: SPICEの精度をそのまま活用
柔軟性: NGspice（OSS）やXyce（Sandia製）と連携可能
将来性: 自動車・航空宇宙業界で広く採用

実装予定のアーキテクチャ

FMI 3.0 Co-Simulation 計画:
├── sukimasim側（Master）
│   ├── FMI 3.0 C API呼び出し
│   ├── 時刻同期（doStep）
│   └── 変数交換（get/setFloat64）
├── SPICEシミュレータ側（Slave FMU）
│   ├── NGspice FMUエクスポート
│   ├── Xyce FMI対応
│   └── 回路ネットリスト（.spice）
└── インターフェース
    ├── デジタル→アナログ：電圧源として注入
    ├── アナログ→デジタル：閾値判定でlogic変換
    └── 時刻管理：可変ステップサイズ対応

ユースケース

電源シミュレーション: デジタル負荷変動によるLDO応答検証
PLL検証: デジタル制御ループとVCOの連携
ADC/DAC検証: デジタル信号処理とアナログフロントエンド

これにより、オープンソースツールだけでSoC全体のデジアナ混載検証が可能になることを目指しています。

gRPC + Protocol Buffers による通信基盤

SPICEシミュレータとの連携を含むすべてのプロセス間通信は、gRPC + Protocol Buffers（protobuf）を通信基盤として使用します。FMI 3.0のデータフォーマット（変数交換、時刻同期など）をprotobufでシリアライズし、gRPCで転送する構成です。

アーキテクチャの特徴

通信スタック:
┌─────────────────────────────────────┐
│ アプリケーション層                    │
│ ├── FMI 3.0 Co-Simulation API       │
│ │   (doStep, get/setFloat64等)      │
│ └── カスタムAPI（信号操作、制御）      │
├─────────────────────────────────────┤
│ シリアライズ層                        │
│ └── Protocol Buffers                │
│     (FMI 3.0データ構造をproto定義)    │
├─────────────────────────────────────┤
│ トランスポート層                      │
│ └── gRPC (HTTP/2)                   │
│     (双方向ストリーミング対応)         │
└─────────────────────────────────────┘

この構成により：

FMI 3.0互換: 標準的なCo-Simulation APIを維持
高性能通信: gRPCのHTTP/2による効率的なバイナリ転送
言語非依存: protobufによる多言語サポート（C++, Python, Go等）
スケーラビリティ: 分散環境・クラウド環境への拡張が容易

なぜgRPC + protobufなのか

項目	ソケット直接通信	REST API	gRPC + protobuf
シリアライズ効率	手動実装	JSON（テキスト）	バイナリ（高速）
型安全性	なし	なし	.protoで定義
ストリーミング	手動実装	困難	双方向対応
多言語対応	言語ごとに実装	容易	自動生成
パフォーマンス	高	低	高

想定ユースケース

gRPC連携の活用例:
├── Python連携
│   ├── 機械学習モデルによる入力生成
│   ├── 波形データのリアルタイム解析
│   └── テスト結果のダッシュボード表示
├── 外部シミュレータ連携
│   ├── 別プロセスのCPUモデル（QEMU等）
│   ├── ネットワークシミュレータ（ns-3等）
│   └── カスタムアクセラレータモデル
└── 分散シミュレーション
    ├── 大規模デザインの分割実行
    └── クラウド環境でのスケールアウト

protobuf定義例（計画）

// sukimasim_rpc.proto
syntax = "proto3";

package sukimasim;

service SimulatorService {
  // シミュレーション制御
  rpc Run(RunRequest) returns (RunResponse);
  rpc Step(StepRequest) returns (StepResponse);

  // 信号アクセス
  rpc GetSignal(SignalRequest) returns (SignalValue);
  rpc SetSignal(SetSignalRequest) returns (SetSignalResponse);

  // イベントストリーミング
  rpc WatchSignals(WatchRequest) returns (stream SignalEvent);
}

message SignalValue {
  string name = 1;
  uint64 time = 2;
  oneof value {
    uint64 logic_value = 3;
    double real_value = 4;
    bytes vector_value = 5;
  }
}

FMI 3.0がアナログ連携に特化しているのに対し、gRPC + protobufは汎用的なプロセス間通信基盤として位置づけています。両者を組み合わせることで、柔軟なシミュレーション環境を構築できます。

公開について

公開は引き続き控える（特許リスク）
個人の学習・研究目的での活用を継続
得られた知見を記事で共有

まとめ

sukimasimは、特許リスクのある最適化技術を無効化しつつ、IEEE 1800-2023に対して約99%準拠を達成しました。

達成したこと

✅ sv-tests 1,667テスト 100%パス
✅ 7,714テスト全てパス（100%）
✅ IEEE 1800-2023 約99%準拠
✅ UVM 1.2 100%準拠（Phase A-E完了）
✅ DAP（Debug Adapter Protocol）基本機能実装（行ブレーク・ステップ実行）
✅ SSF v3/v4.3 高圧縮波形フォーマット（VCD比30〜50倍）
✅ xrun互換CLIでスムーズな移行
✅ Lua + Sol2スクリプト環境実装
✅ 218カテゴリのリグレッションテスト自動化

教訓

1. 安全な実装 > 高速だが危険な実装
   - 特許リスクを考慮した設計が重要
   - 個人開発では無理をしない

2. テスト駆動開発の効果
   - 7,714テストがリグレッション防止に貢献
   - マニフェストベースの管理で効率化

3. AIは強力だが責任は自分
   - Claude Codeは開発を大幅に加速
   - しかし生成コードの法的責任は使用者

公開はできませんが、この開発を通じてSystemVerilogシミュレータの内部構造を深く理解できました。この知見を今後も記事で共有していきます。

免責事項: この記事は技術的な報告であり、法的な正確性はありません。また、IEEE 1800-2023の準拠率は自己評価に基づくものです。

参考資料

以上

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Claude Code を使用して SystemVerilogシミュレータ を開発してみた (12/20開発状況)

はじめに

この記事の要約

開発方針の転換：安全な実装へ

無効化した高リスク機能

残した安全な機能

無効化後のパフォーマンス

IEEE 1800-2023 準拠状況

全体的な準拠率

章別の準拠率

サポートしている主要機能

意図的に非サポートの機能

最近修正した機能

UVM 1.2 100% 準拠

Phase A-E 完全実装

UVM テスト例

実行方法

DAP（Debug Adapter Protocol）デバッグサーバー

VSCode統合デバッグ

デバッグ機能

使用方法

VSCode設定（launch.json）

SSF v3/v4.3 高圧縮波形フォーマット

VCD/FSTとの比較

実測データ

使用方法

SSFの特徴

xrun互換CLI

Cadence Xceliumからの移行支援

互換オプション一覧

移行例

Lua + Sol2 スクリプト環境の実装

なぜLua + Sol2なのか

UVMとの使い分け

Xcelium Tclモードの代替として

実装したAPI

CLIオプション

検証ライブラリの例

ハイブリッド戦略：SVA + 軽量スクリプト（Lua + Sol2）

テストスイートによるリグレッションテスト

テストスイートの構成

自動化されたダッシュボード

マニフェストベースのテスト管理

特定カテゴリの実行

開発統計

コード規模

技術スタック

開発期間

AI活用の開発体制

Claude Codeの貢献

Codex・Geminiによるレビュー効果

今後の計画

短期（1-2週間）

中期（1ヶ月）

長期：FMI 3.0によるデジアナ混載シミュレーション

FMI 3.0とは

なぜFMI 3.0なのか

実装予定のアーキテクチャ

ユースケース

gRPC + Protocol Buffers による通信基盤

アーキテクチャの特徴

なぜgRPC + protobufなのか

想定ユースケース

protobuf定義例（計画）

公開について

まとめ

達成したこと

教訓

参考資料

Claude Code を使用して SystemVerilogシミュレータを開発してみた (12/20開発状況)