SystemVerilog アサーション (SVA) 入門（改訂版）

Last updated at 2025-02-07Posted at 2025-02-07

1. はじめに

以前、SystemVerilog アサーション (SVA) 入門という記事を書いたときは、カバレッジツールなどの話題を詰め込みすぎて全体が散漫となってしまいました。
そこで本記事では、SVA（SystemVerilog Assertions）によりフォーカスし、入門から応用までを体系的にまとめ直しています。

筆者は普段はソフトウェア開発やモデルベース開発＆検証の業務を中心にしていますが、仕事で時々半導体（ASIC など）の検証にも携わる ことがあります。
モデルベース開発や高位合成の一環で SystemC を利用し、システムレベルやトランザクションレベルの検証を行う場面も多いです。
しかし、SystemC は高レベルのアーキテクチャ検証やアルゴリズム検証に向いている一方で、RTL レベルの詳細なタイミング検証やカバレッジ測定はあまり得意ではありません。
そうした低レイヤーの挙動や大規模設計の網羅的な検証には、やはり SystemVerilog と SVA (SystemVerilog Assertions) が欠かせないというのが業界の一般的な認識です。

特にハードウェア検証を考慮すると、SystemC だけでは完結しきれず、SystemVerilog と混在した環境での検証フローが必要になる場面が多いです。
その際に非常に役立つのが、SystemVerilog で提供される SVA (SystemVerilog Assertions) です。
SVA を使いこなせば、時相的（タイミング的）な動作チェックや機能的カバレッジを一元的に管理できるため、半導体の検証に携わるエンジニアにとって必須レベル といえるでしょう。

本記事では、そんな SVA について

どんなときに役立つのか
基本的な書き方
実際に使う際のポイント

を初学者向けにわかりやすく整理しました。

「SystemC/SystemVerilog はなんとなく検証で使っているけど、もっと厳密な検証が必要…」
「波形でチェックしてたけど、何か自動化できる方法はないの？」
こういった疑問をお持ちの方にも読んでいただける内容を目指しています。

2. なぜアサーションが必要か

2.1 テストベンチだけでは不十分

RTL のシミュレーションでテストベンチから刺激を与え、出力波形をチェックする手法は従来からありましたが、設計が大規模化・複雑化すると、すべてのタイミングや内部信号を波形で完全に把握するのは困難です。
波形レビューだけに頼ると、一瞬のタイミング違反や複雑なプロトコル制約を見落とす可能性が高まります。

2.2 仕様を“コード”で明示するアサーション

そこで登場するのが SystemVerilog Assertions (SVA) です。
たとえば仕様書にある

「リセットがアクティブの間は開始信号を上げてはいけない」
「valid が立っているときは次クロックで ready も必ず立つ」

といった時相的・論理的な仕様を、SystemVerilog の構文で直接表現できます。
アサーション違反が検出されると即座にエラーを報告してくれるので、波形の人力チェックに頼らない自動検証が可能です。
これにより、検証の効率化と品質向上が期待できます。

3. SVA の基本要素と構文

SVA には大きく 3 つの要素があります。

assert property
- 設計が必ず満たすべきルールを記述し、違反時にエラーとして報告
assume property
- 入力や外部環境が守るべき制約を記述し、主にフォーマル検証などで活用
cover property
- 時相的な条件やシーケンスが実際に発生したかどうかを観測し、カバレッジを記録

3.1 `property` と `sequence`

SVA では時系列パターンを記述するために sequence を定義し、それを property としてまとめます。
assert property / assume property / cover property などで使用するイメージです。

sequence req_ack_seq;
  req ##[1:3] ack; // req が立ってから1～3サイクル以内に ack が立つ
endsequence

property req_ack_property;
  @(posedge clk) disable iff (rst) req_ack_seq;
endproperty

assert property (req_ack_property);

sequence で「req → (1～3 サイクル) → ack」の時間的関係を定義
property で「リセット中は評価を無効化し、クロック立ち上がりごとにこの sequence をチェック」
assert property で「守られなければエラー」として検証

SVA 全体イメージ図

まず仕様書から時相的要件を抽出し、sequence として書き起こす。
それを property にまとめ、assert/assume/cover で機能を指定。
実際にツールで実行し、結果を再度仕様書と照合するイメージです。

3.2 `disable iff` の詳細な使い方

disable iff は、特定の条件が真の間はプロパティ評価を無効化する構文です。
よくある例として、リセット期間中はアサーション評価をしないようにしたい場合に使います。

property p_check;
  @(posedge clk) disable iff (reset) (...実際のチェック...);
endproperty

assert property (p_check);

reset がアクティブな間、property の評価は行わず無効化される
リセット解除後から再びアサーションが動作する

また、テストベンチ専用のフラグを用意し、あるテストケースだけアサーションを有効化したい場合にも利用できます。

property p_testcase_enable;
  @(posedge clk) disable iff (!test_enable) ( ...condition... );
endproperty

assume property (p_testcase_enable);

4. `assert property`：仕様通り動いているかをチェック

4.1 基本構文

assert property (@(posedge clk) disable iff (!reset) <sequence or condition>);

@(posedge clk): クロック立ち上がり時に評価
disable iff (!reset): リセットがアクティブなときは無効化
<sequence or condition>: 時相的パターンやブール式

4.2 実例：リセットとスタートの競合

property no_reset_and_start;
  @(posedge clk) disable iff (!rst_n)
    !(start && rst_n == 0); // リセット中にstartを立ててはいけない
endproperty

assert property (no_reset_and_start)
  else $error("Reset and start are asserted simultaneously!");

リセット(アクティブ Low)期間中に start を立てないというルール
違反が起これば $error が発行される
波形で見落としがちな微妙なタイミング制約も自動検出

5. `assume property`：入力・環境の制約

フォーマル検証でとくに役立つのが assume property です。
たとえば、

「入力 in_data は 0～255 の範囲」
「リセットがアサート中でもクロックは止まらない」

といった設計外部の前提をツールに伝えられます。

property valid_range;
  @(posedge clk) disable iff (!rst_n)
    (in_data < 256);
endproperty

assume property (valid_range);

in_data が 256 以上になるケースを除外 → 検証効率の向上
シミュレーションでもテストベンチがこの制約を破ったらテストベンチの不備として検出できる

6. `cover property`：発生確認（機能カバレッジ）

cover property は、指定した時相的イベントやシーケンスが実際に発生したかを検出し、カバレッジレポートを記録します。
とくに設計内部のシーケンスをウォッチしたいときに便利です。

sequence start_to_done;
  start ##[1:10] done;
endsequence

cover property (@(posedge clk) disable iff (!rst_n) start_to_done)
  else $display("start->done sequence occurred!");

start が立ってから 1～10 サイクル以内に done が立ったシナリオが発生したかを観測
シミュレーション終了後に「cover property がヒットしたか」がレポートされる
設計の重要なシナリオが本当に起きたかを簡易的に把握

7. 仕様をアサーション（SVA）へ落とし込むには

7.1 自然言語の“仕様”から SVA への変換

仕様書は多くの場合、自然言語（日本語/英語）やフローチャートで書かれています。
ここからアサーションを作るには、以下のステップが典型的です。

キーとなる信号や状態を洗い出す
- 例：「start が立ったら busy 状態になる」「busy の間は done が立たない」など
時相的要件を抽出
- 例：「N サイクル以内に応答がある」「リセット解除後にフラグが立ち上がるまでのサイクル数」など
複数の property に分割
- 1 行の仕様文に複数条件が含まれる場合は細かく分けるとデバッグが容易

7.2 アサーションと仕様の対応を整理

設計者・仕様策定者と検証担当が、アサーション文書を見ながら「どの仕様項目に対応するか」を突き合わせる
「ここはカバレッジテストでカバーする」「ここはフォーマルで証明」など、他の手法との役割分担も明確にする

注意: 「仕様に書いてあるすべてのルールがアサーションで表現されているか」や「アサーションで拡大解釈されていないか」を丁寧にレビューする必要がある。

8. アサーションと仕様が一致しているかのチェック方法

8.1 最終的には“人的レビュー”が必要

現在、「アサーションと自然言語仕様の完全一致」を自動的に検証するツールはほとんどありません。
したがって、

コードレビュー
- 「仕様書 3.2 節→ assert property x でカバーしています」など、項目ごとに対応を確認
相互レビュー (複数人)
- 「このリセット直後はどうなる？」など、異なる視点からバグを探す

8.2 トレーサビリティマトリクスの活用

以下のような表で「仕様書項目」と「SVA property」を紐づけると、対応状況が明確になります。

仕様書項目	SVAファイル / property名	内容	担当/レビュー日
3.2.1 リセット時のstart禁止	`reset_no_start`	リセット中に start=1 にならない	設計者A / 検証者B, 2025/01/10
3.2.2 start→busy 遷移	`start_to_busy`	start で busy フラグを上げる	設計者A / 検証者C, 2025/01/10

8.3 フォーマル検証＋アサーションのカバレッジ

一部のフォーマルツールは「常に真 / 常に偽で評価されるアサーション」を警告する機能を持つ
ただし、仕様との完全一致を自動チェックするわけではないので、レビューとの併用が必須

9. アサーションをどこに書く？

9.1 テストベンチ側に書くメリット

UVM など検証環境で一括管理できる
RTL コードを汚さず、検証者が自由にアサーションを追加しやすい
DUT が複数階層でも、テストベンチ側で階層的にアサーションを配置しやすい

9.2 RTL 内部に書くメリット

仕様や設計と一体で管理できるため、設計者の意図をそのまま反映しやすい
「このレジスタはこう動くべき」という強い仕様をRTL内に埋め込むと、メンテナンス性も高まる
ただし、プロジェクト方針やコーディング規約との兼ね合いも考慮する必要がある

10. 実行とレポートの流れ

10.1 シミュレーション

Cadence Xcelium / Synopsys VCS / Siemens EDA Questa など、主要シミュレータは SVA に対応
アサーション違反が起きると即座にログを出力 → デバッグ効率向上
波形ビューア上でも、違反時刻にジャンプして原因を素早く追える

10.2 カバレッジレポート

cover property で観測したシーケンスの発生状況を確認
構造的カバレッジ（ステートメント / ブランチ / トグルなど）と組み合わせて未達成部分を把握
UVM の covergroup やシーケンスカバレッジと併用すると、機能的カバレッジを補完可能

10.3 フォーマル検証（オプション）

assume で入力制約を与えた状態で、assert が常に成立するかツールが証明
違反があればカウンター例（反例）を自動生成してくれる
設計規模が大きいと計算負荷が高くなるが、深いバグを早期に発見できる利点がある

10.4 構造的カバレッジ vs. カバープロパティ

構造的カバレッジ
- RTL コードの行・ブランチ・トグル・FSM 等をどれだけ実行したか
- 「ソース上の未到達箇所はないか」を確認する指標
カバープロパティ (cover property)
- 時相的シナリオが 一度でも起きたか を確認
- 機能や仕様観点で「重要なケースを試したか」を補足する指標

11. SVA をライブラリ化する手法

続いて、SVA をライブラリ化（再利用） するための方法とメリットについて解説します。
大規模プロジェクトや複数プロジェクト間で、よく使うアサーションやシーケンスを再利用できるようにすると、検証効率や保守性が格段に向上します。

11.1 ライブラリ化のメリット

共通のプロパティやシーケンスを使い回せる
- FIFO のオーバーフロー/アンダーフロー検証、ハンドシェイクプロトコル（req → ack など）のチェックは多くの設計で共通する
- 毎回ゼロから書かずに、標準のライブラリをインクルードするだけで使えるようになる
品質の高いアサーションがどのプロジェクトでも利用可能
- 信頼性・レビュー済みのアサーションをチーム全体で共有することで、バグ検出が早まり、プロジェクト間の品質のばらつきを減らす
メンテナンスが容易
- バグ修正や最適化をライブラリ側で行えば、利用者はライブラリ更新のみで済む
- 全プロジェクトで一元的に改善効果を得られる

11.2 具体的な手法

11.2.1 プロパティファイルの作成

ライブラリ用ファイル（例：sva_common_lib.sv など）を用意し、そこに共通で使いたい sequence や property をまとめる
プロジェクトの各検証環境や RTL で、include "sva_common_lib.sv" として読み込むだけで利用できる

例：FIFO 用のアサーションライブラリ

// sva_fifo_lib.sv

// FIFO overflow check
property p_fifo_no_overflow (write, full);
  @(posedge clk) write && full |-> $error("FIFO Overflow!");
endproperty

// FIFO underflow check
property p_fifo_no_underflow (read, empty);
  @(posedge clk) read && empty |-> $error("FIFO Underflow!");
endproperty

必要に応じて assert property (p_fifo_no_overflow(wreq, full)); などを記述するだけで再利用可能

11.2.2 パラメータ付きプロパティ

FIFO の深さやタイミング幅が設計によって異なる場合、パラメータを導入して柔軟性を高める
たとえば、遅延クロック数やデータビット幅などをパラメータ化しておくと、様々な設計で流用しやすい

property p_fifo_no_overflow #(parameter CHECK_LEVEL=1) (write, full);
  @(posedge clk) (CHECK_LEVEL > 0) && write && full |-> $error("FIFO Overflow!");
endproperty

呼び出し側で #(CHECK_LEVEL=2) のように指定でき、バリデーションルールを切り替えられる

11.2.3 モジュール化・パッケージ化

シンプルな場合は include ベースで十分だが、SystemVerilog では package 機能を用いてプロパティやシーケンスをまとめる方法もある
パッケージ名空間を使えば、同名プロパティの衝突を避けつつ明示的に参照できる

package sva_common_pkg;
  property handshake_p(req, ack);
    @(posedge clk) req |-> ack;
  endproperty
endpackage

// 使用例
import sva_common_pkg::*;
...
assert property (handshake_p(request, acknowledge));

大規模チームや複数プロジェクトでパッケージを共有し、バージョン管理（Git 等）に乗せておくことで、一元的にメンテナンスできる

11.3 運用上の注意点

利用ガイドラインを作る
- どのライブラリファイルに何があるのか、パラメータの意味は何か、などをドキュメント化
- 適当に使うと「ライブラリの中身がよくわからない」「間違った使い方で検証結果を誤解」などが起きがち
バージョン管理の整合性
- 設計とライブラリのバージョンを合わせないと、思わぬ不具合や警告が出る場合がある
- ライブラリを更新する場合は、影響範囲を確認しながら慎重に進める
プロパティの過度な一般化は避ける
- 汎用性を高めようとして複雑なパラメータを入れすぎると逆に使いづらい
- よく使うパターンを中心に、適度なパラメータ化に留めるのがおすすめ
プラットフォーム・ツールの制限を確認
- 一部の古いシミュレータではパッケージや高度な SystemVerilog 構文を十分サポートしないケースもある
- チーム全体が最新バージョンのツールを使えるか、事前に確認する

11.4 まとめ

SVA をライブラリ化すると、共通のアサーションやシーケンスを簡単に再利用でき、プロジェクト間の品質を均一化できる
一度作り込んだ高品質なプロパティを、複数の設計で使い回すことで検証工数とリスクを大幅に削減できる
パラメータ化やパッケージ化など工夫しながら、チーム全体・複数プロジェクトで標準アサーションを育てていくのが理想

12. よくある質問（FAQ）

ここでは、SVA を使用するうえで頻出の質問と回答をまとめます。

Q1. アサーションを書いたらシミュレーションが重くなりませんか？

A.
多少は重くなりますが、最新シミュレータは最適化が進んでおり、数百～数千行レベルなら大きな問題なく動作します。
むしろ、波形レビューで延々とバグを探す工数が削減されるメリットのほうが大きいです。

Q2. すでにテストベンチでチェックしてるのに、アサーションが必要ですか？

A.
UVM などのテストベンチは主に外部インターフェイスからの動作検証が中心ですが、SVA は内部タイミングやプロトコルの細かい制約を自動監視してくれます。
一瞬だけ破たんするようなバグにも即座に気づけるため、品質が大きく向上します。

Q3. RTL に書く vs テストベンチ側に書く、どちらが正解？

検証者主体で管理したいルール → テストベンチ側
設計の根幹仕様そのもの → RTL 内

というケースが多いです。プロジェクト方針やチーム規約に合わせて最適化してください。

Q4. SVA と PSL (Property Specification Language) の違いは？

SVA: SystemVerilog の言語仕様に含まれる
PSL: VHDL / Verilog / SystemC 等、複数 HDL に対応する独立言語

VHDL メインの環境では PSL を使う場合もありますが、近年は SystemVerilog が主流なので、SVA が選ばれやすいです。

Q5. SystemC のテスト環境だけで検証するのは難しいのでしょうか？

A.
SystemC は高位合成やアーキテクチャ検証には強いですが、大規模 RTL レベルの網羅的検証を完結させるには機能不足があります。
最終的には、SystemVerilog + SVA で詳細検証するフローが実績豊富です。

Q6. フォーマル検証だけで十分ですか？シミュレーションは不要？

A.
フォーマルは全パス網羅的にチェックできるため強力ですが、設計規模が大きいと解析が爆発的に増えがちです。
また、ソフトウェア連携や外部 I/O などはシミュレーションで確認するのが一般的なので、フォーマル + シミュレーションが現実的です。

Q7. アサーションのカバレッジ（cover property）だけで機能カバレッジは十分でしょうか？

A.
cover property は時相的シナリオの発生を検知する便利な仕組みですが、
レジスタ設定や入力パターンなど広範囲の組み合わせを見るなら、covergroup や UVM シーケンスカバレッジも必要です。
それぞれ得意分野が異なるので、目的に応じて併用しましょう。

Q8. Assertions はゲートレベルシミュレーション (GLS) でも使えますか？

A.
ゲートレベル (GLS) は合成最適化により信号名が変化し、アサーションと合わなくなる可能性が高いです。
大半のプロジェクトでは RTL シミュレーションでしっかりアサーション検証を行い、GLS では最低限のチェックのみ行うことが多いです。

Q9. SVA でランダムに発生するようなレアバグは見つけやすいですか？

A.
はい、アサーションで監視しておけば、タイミングがごく短いバグでも検出されます。
ただし、ランダム入力や外部環境の設定が不十分だと発生自体が再現できないので、テストベンチ設計も大事です。

Q10. disable iff を使わずにリセット周りをカバーする方法はありますか？

A.
disable iff はシンプルに「リセット中は評価しない」などを書ける便利な構文です。
使わずに実装する場合はシーケンス側で条件分岐を記述する必要があり、少し冗長になることもあります。

Q11. SVA はエミュレータやプロトタイピング環境でも活用できますか？

A.
エミュレータや FPGA プロトタイプでは、アサーション評価によるオーバーヘッドが大きい場合が多く、フル機能でのサポートは限られがちです。
一般的には、シミュレーションやフォーマル検証でアサーションを活用し、エミュレータは大規模システム動作を高速に検証する用途で使われます。

Q12. アサーションを書いたけど、全然違反が出ません。考えられる原因は？

テストベンチの刺激が不足
- 実際にはバグシナリオに到達していないかもしれません。
アサーションが常に真 (true) になるような書き方
- フォーマルで“vacuous pass”が発生していないかチェックするとよいです。
disable iff の条件が常に有効
- リセットや有効フラグが切れておらず、実質的にプロパティが評価されていない可能性があります。

13. 用語集

以下の表は、SVA やその周辺検証で頻出する用語をまとめたものです。

用語	解説
アサーション (Assertion)	設計が満たすべき仕様やルールをコード化したもの。違反するとエラーを報告。
アサンプション (Assumption)	入力や外部環境に関する前提条件をコード化したもの。主にフォーマル検証で「入力がこの制約を破らない」と仮定する際に使用される。
カバー (Cover)	特定の条件やシーケンスが「一度でも起きたか」を観測・記録する仕組み。機能カバレッジの一部。
`disable iff`	指定条件が真の間、プロパティ評価を無効化する構文。リセットや検証フラグなどでアサーションの有効範囲を切り替えるときに便利。
sequence / property	sequence: 「A 信号後に B 信号」が起こるなど、時相的なパターンを定義 property: sequence や論理式をまとめた定義。assert/assume/cover で使われる
フォーマル検証 (Formal Verification)	設計全体を網羅的に探索し、アサーション違反が起こるかどうかを数学的に証明する手法。大規模になるほど解析に時間・リソースがかかる。
シミュレーション (Simulation)	時間軸に沿って波形刺激を与え、設計動作を可視化して検証する。Directed テストやランダムテストなどさまざまな手法と組み合わせて実施。
カバレッジ (Coverage)	「検証がどこまで進んだか」を示す指標。構造的カバレッジ（ステートメント/ブランチ/トグルなど）と機能的カバレッジ（cover property, covergroup など）がある。
UVM (Universal Verification Methodology)	SystemVerilog を使った検証フレームワーク。クラスベースでテストベンチを構築し、ランダムテストやシーケンスカバレッジなどもサポート。
covergroup	SystemVerilog の機能カバレッジ機構。レジスタ値や入力パターンの組み合わせをカウントし、アサーションの cover property と併用することで幅広い機能検証を実現。
SVA (SystemVerilog Assertions)	本記事の中心テーマ。SystemVerilog 言語仕様に含まれるアサーション機能。設計仕様の表現や入力制約、カバレッジ計測まで幅広くサポート。

14. まとめ

SystemVerilog Assertions (SVA) は、設計の仕様やルールをコード化し、自動的にチェックするための強力な仕組み。
assert property / assume property / cover property の 3 つを使いこなすだけで、広範な検証と網羅的なシナリオチェックが可能になる。
構造的カバレッジ（ステートメント、ブランチ、トグル）と組み合わせれば、網羅度と正しい動作の保証の両方を強化。
SystemC 等の高位レベルでカバーしきれない RTL レベルの複雑な動作を確実にしたいなら、SVA はほぼ必須。

何より重要なのは、「アサーションが本当に仕様を表しているか」をレビューやトレーサビリティマトリクスで管理すること。
アサーションを書くだけで自動的に安心とはいきません。仕様との照合や検証計画の見直しをこまめに行うのが質の高い検証への近道です。

15. LLM を使って仕様→アサーション化・整合性チェックを試みる

近年の LLM (Large Language Model) 例: ChatGPT, GPT-4 などでは、自然言語の仕様書からアサーションコードのひな形を生成してくれたり、
文章同士の対応関係をざっくり示してくれたりと、検証フローを支援できる可能性があります。
ただし、以下の点に注意が必要です。

15.1 メリット

アサーションコードの初期雛形を高速生成
- 「リセット後 N サイクル以内に ack が上がる」などを自動変換できるかもしれない
文章同士の対応チェック支援
- 「仕様の段落 x.y に関連するアサーションは何か」などをテキストマッチ的に検索
コードレビュー支援
- 小さなスペルミスや論理ミスを拾ってくれる場合がある

15.2 デメリット・注意点

専門的な仕様解釈は苦手
- 非同期リセットやクロックドメインなどのハードウェア特有の要件を正確に扱うのは難しい
ハルシネーションのリスク
- LLM が勝手に根拠のないルールを付け足す場合がある。最終的に人間のレビューが必須
セキュリティ・機密情報の流出リスク
- 社内秘の仕様を外部 LLM に入力すると情報漏洩の可能性があるため、プライベート環境や注意深い運用が必要

15.3 活用例のイメージ

仕様書を分割・箇条書き化 → LLM に提示
SVA で書いてほしい要件を指示 → 自動生成されたコードを受け取る
レビュー＆修正 → 実際にコンパイル・シミュレーション
結果を確認しながら 仕様書との対応を整合していく

15.4 まとめ

LLM はあくまで「自動補助」ツール。最終的な仕様合致性は人間による検証が不可欠
特に複数クロックドメインや非同期リセットのある ASIC/FPGA 設計などは、LLM が自動生成したアサーションをそのまま使うのは危険
うまく組み合わせれば、文書化や初期コード作成の工数は削減できる可能性あり

16. 追加テーブル：SVA 活用フローまとめ

以下の表は、SVA を活用した検証フローをざっくりまとめたものです。

フロー段階	内容	ポイント
1. 仕様書分析	仕様書から時相的要件やルールを抜き出す	自然言語のままでは曖昧な点を明確化する
2. sequence の定義	「A が起きてから B が起きるまで何サイクル」など時系列パターンを記述	繰り返し (##[1:3] など)や条件分岐を正確に書く
3. property 化	sequence を含むプロパティ (assert / assume / cover 用) を作成	リセット中の無効化や disable iff の扱いを検討
4. アサーション配置	テストベンチ側 or RTL 内にアサーションを配置し、どの範囲を検証するか決定	クリティカルな仕様 → RTL 内部、環境制約 → TB 側など分担
5. シミュレーション / フォーマル検証	実際にアサーションを評価し、違反やカバレッジを確認	違反が起きたタイミングのデバッグ、フォーマルなら反例パスを分析
6. 結果レビュー & 仕様再調整	カバレッジ不足・アサーション漏れなどを洗い出す	トレーサビリティマトリクスで仕様項目との対応関係を最終チェック
7. (オプション) LLM や他ツールの活用	アサーションコード作成やコメント生成などを支援させる	機密漏洩やハルシネーションに注意

17. 参考文献・リンク

SystemVerilog Assertions and Functional Coverage: Guide to Language, Methodology and Applications – Ashok B. Mehta
SystemVerilog for Verification: A Guide to Learning the Testbench Language Features – Chris Spear, Greg Tumbush
SystemVerilog for Design: A Guide to Using SystemVerilog for Hardware Design and Modeling (Third Edition) – Stuart Sutherland, Simon Davidmann, Peter Flake
Assertion-Based Design (Second Edition) – Harry D. Foster, Adam C. Krolnik, David J. Lacey
IEEE 1800: SystemVerilog Language Reference Manual – IEEE

以上

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