IEEE 1800 - 2023 (SystemVerilog) 改善点ダイジェスト(Design and Verification LANDSCAPE 2023-Vol2)

特別無償開催
目次
はじめに
SystemVerilogは2005年にIEEE標準としてリリースされ、従来のVerilogに比べて、設計、アサーション、テストベンチのすべての領域において、大幅な機能追加がされている。IEEE SA(Standards Association)は採用や活用が活発であり、多くのユーザに影響する標準規格については、数年ごとの見直し、改版を推奨しており、SystemVerilogは2005年の初版リリースに続き、2009年、2012年、2017年と改版され、現在2023年版のリリースに向けて改版作業が進められている。本稿ではIEEE標準化活動の概要とIEEE 1800 - 2023におけるハイライトを紹介し、将来の設計や検証がどのようになるかを展望する。
Verilog / SystemVerilog標準化の歴史
まずVerilogおよびSystemVerilogの標準化の歴史について見てみる。Verilogは言語としては1985年に商用言語として開発されたが、当時はVHDLがIEEE標準の言語として採用が広がる状況にあり、IEEE 1364という標準で1995年に公開された。それ以降の標準化の歴史を図1.に示す。
図1. IEEE 1364 (Verilog) およびIEEE 1800 (SystemVerilog)標準化の流れ
この図にあるようにIEEE 1364は2005年版を最後に標準化は終了している。IEEE 1800の2009年以降はVerilogとの互換性が保たれており、その意味ではVerilogは完全にSystemVerilogに移行していると言える。
P1800 2023 Working Groupの活動
SystemVerilogの次期改訂を行うプロジェクトとして、P1800 2023 Working Groupが2019年末に発足した。このPはProposedの頭文字をとったもので、2023年版としてWorking Groupがプロポーザルをまとめ、それをIEEE SAが承認するというプロセスになっている。
Working GroupにはAccellera Systems Initiative、ARM、Cadence、Infineon、Intel、JEITA、Marvell、Nvidia、Qualcomm、Siemens、Sigasi、Synopsys、TI、Verificといった企業や団体がエンティティとして参加しており、投票は1エンティティ1票という仕組みで議論を進めている。
図2. IEEE iMeet(左)とAccellera Mantis(右)
会議では米国はもとよりヨーロッパやイスラエル、日本からも参加するため、Webツールの活用が必須である。図2.の左はIEEEが持つプロジェクト管理ツールであるiMeet、右はAccelleraが持つエラッタやエンハンスメント要求をトラッキングするMantisというツールで、2004年以降、3500にも及ぶSystemVerilogに関する課題や改善要件が登録されている。議論のカテゴリーは以下の3つに分類される。
- Enhancement - 言語の機能を拡張して実現する新機能
- 完全に新しい機能、もしくはすでにいくつかのツールで実装されている機能の標準化
- 他の言語においてユースモデルが広く知られている機能の実装
- Errata - 現行のLRMにおける明白な誤り
- 小さな誤植や編集上の誤り
- LRM内にある異なるセクション間での矛盾
- LRMの現行の表記や言葉使いの明らかな誤り(LRMの本来の意図をツールがすでに正しく実装している場合もある)
- Clarification - 言葉不足や誤解を招く表現によりLRMに曖昧さがある場合の対応
- 説明の加筆、あるいは曖昧さを解消する表現の修正
- 通常はツールが本来の意図と大きく異なる振舞いをしていない限り、ツール実装の変更は不要
IEEE 1800 Std. 2023のハイライト
2023年版では数多くのエンハンスメントが盛り込まれ、よりエラッタが少なく、より明瞭な言語規格へと改善されているが、本稿では紙面の都合から以下7項目に挙げるエンハンスメントについて解説する。項目の名称は参照しやすいよう、Mantisに記載されているとおりの英語表記とする。
- Extending coverpoints (Mantis 4703)
- Unpacked array mapping function (Mantis 7610)
- `ifdef Boolean combination of identifiers (Mantis 1084)
- Add support for multiline strings (Mantis 7308)
- Real number modeling (Mantis 7295 and 7669)
- Chaining of method calls (Mantis 2735)
- Adding static ref arguments (Mantis 2583)
Extending coverpoints (Mantis 4703)
これは機能カバレッジの改善であり、P1800 2023 Working Groupが設立された最も大きな動機と言っても良い。これまでのcovergroupはclassのようにコンストラクタを用いてインスタンス化するにも関わらず、新規メンバの追加や、ベースクラスの既存メンバのオーバーライドなど、拡張することができない。2023版ではcovergroupを拡張したクラスで、新たなcoverpointを追加し、元のベースクラスにある既存coverpointとのクロスを取ることが可能になる。また既存のcoverpointのbin構造の置換えや、完全な削除も可能になる。
図3. covergroupのクラス定義(左)とクラス拡張(右)
Unpacked Array map function (Mantis 7610)
SystemVerilogでは配列を全体として扱うことができるものの、比較演算子や代入演算子には制限があり、要素のタイプが同じアンパックドアレイにしか適用することができない。Pythonなどの言語では配列のmapファンクションやメソッドがあり、配列の各要素を新しいタイプにキャストすることができる。また各要素に対して任意の演算を実行することができる。
図4. withを用いたmapメソッドによるキャストと演算
図4.にあるようにmap()メソッドをwith()式と共に使うことで各要素を処理することができる。map()にはこの記述のようにaやbなど明示的な変数を指定し、それをwith()内で参照することも、あるいはmap()に何も指定せず、with()内で暗黙の変数であるitemを参照することもできる。そして最終的に各要素がwith()式で得られたタイプを持つ新たな配列を作ることができる。
`ifdef Boolean combination of identifiers (Mantis 1084)
これはプリプロセッサのifdefで簡単な論理式や条件式、例えばブーリアンのAND (&&) やOR (||) を表現したいというエンハンスメント要求で、かなり以前からあったリクエストである。LRMにおける多くの曖昧さに対応していたことで、対応に時間を要した経緯がある。
図5. ifdefにおける論理式の表現
図5.において左の2つの記述は、これまでのifdefの機能によって簡単な論理条件式を実現している。一番左は論理アンド条件をネスティングで実現し、左から2番目は論理オア条件を実現している。一番右の記述は2023年版で可能となる記述スタイルであり、A && Bや A || B といった論理表現を ifdef の中で用いることができる。
Support for multiline strings (Mantis 7308)
これは文字列リテラルにおいて複数行にわたる文字列をサポートするというものである。
図6. 複数行にわたる文字列リテラルの記述例
図6.にあるように”””~”””で囲まれた部分をまとめて文字列xに代入している。この中にもあるようにシングルクォートやダブルクォートも、エスケープ指定なく使用することができる。最後に”””が来るまでは改行を含め、どのような文字も扱うことができる。情報量が豊富なメッセージや自己文書化されたメッセージが容易に書け、かつソースコード内でも読みやすく、メンテナンスしやすくなる。
このエンハンスメントにより古くからMantisに登録されている以下の要求も同時に解決されている。
- Multi-line string literals in a text macro (Mantis 1397)
- Special characters in strings (Mantis 1507)
- "Printable" characters (Mantis 7562)
Real number modeling issues (Mantis 7295 and 7669)
SystemVerilogは、デジタル論理設計や検証言語というコンセプトのもとに開発されている。ほとんどの構成要素や演算子においては、式が離散的な積分値やブール値に分解されることが期待される。制約やアサーション、カバーグループはそのような計算式に依存する。一方で実数を使用すると、(0.1 + 0.2) == 0.3 といった式が真とは評価されない事象が生じる。これは浮動小数点の値が2進数のシステムでは正確に表現できないからである。ランダム生成やカバレッジ制約などに実数を使う場合にも注意が必要である。例えば [1.0:3.0] :/ Weight のような記述をしてしまうと、1.0から3.0の範囲に無限に存在する実数要素が重みづけの対象となってしまう。
図7. 実数を用いた機能カバレッジの記述例
図7.はcoverpointを取得する際のbin設定だが、real_intervalという実数値のインターバルを設定することで、binの生成を離散的に制御している。
Chaining of method calls (Mantis 2735)
ファンクション結果、主にその結果がクラスへのハンドルである場合に、その結果を中間的な変数として利用するか、あるいは実行結果のメンバとして利用するかを選択する手段が可用となる。まずは以下の図8.に示すコード記述例を見ていただきたい。
図8. 変数扱いと実行結果扱いの区別
最初にA_tをクラス定義し、memberを123とする。次に、A_tのタイプのファンクションをFとして定義する。initial beginに続く$display文が2つあるが、最初の$displayではtop.F.memberという階層参照が表示される。スタティック変数で初期化されていないため、0が表示される。続く2つめの$displayでは、F()としてファンクション呼出しをしているので、その戻り値としてclass A_tのmemberが返る。
この背景にあるのは、IEEE 1364 - Verilogに対するバックワード互換性の保持である。Verilogではファンクション内部で宣言されたスタティックな変数に対して、そのファンクションの外部から階層参照することができないが、階層参照ではなく、引数が存在しなくてもF()とファンクションを呼出すことで、区別している。
Adding static ref arguments (Mantis 2583)
時間を消費するtaskのref引数は、そのtaskが実行される期間(ライフタイム)中、taskに渡される実引数とtask内で定義された仮引数との間で、値の更新を追跡している。対照的に、実際の入力引数はtaskが呼び出された時点のみ、その値を渡す。task内のコードは実際の引数の宣言については知ることもないため、ref引数を実装することで、単純に引数の値を渡す場合よりも多くの制限が課せられる。
制限の1つは、実引数と仮引数のタイプが一致する必要があるということである。別の制限は、taskの実引数のライフタイム期間がautomaticであると想定しなければならないことである。その結果、automaticのライフタイムで宣言された変数に対して実行できない他の制限もいくつかある。
参照によって渡される引数は、
- ノンブロッキング代入のターゲットにすることはできない
- forceステートメントの左辺、または右辺に参照を持つことはできない
- fork ~ join_any/join_noneのプロセス内からは参照できない
図9. ref引数へのstaticクオリファイヤ指定
このエンハンスメントにより、仮引数のrefにstaticクオリファイヤが指定できるようになる。これによりtaskまたはfunctionの実引数にstaticなライフタイムが保証される。そして実引数としてautomaticのライフタイムを持つ変数を渡すとエラーとなる。
まとめ
P1800 2023のWorking Groupが策定する言語仕様には本稿で紹介した項目以外にも数多くのエンハンスメントやエラッタの改修が含まれる。この言語仕様はプロポーザルとして2023年12月中にはIEEE承認され、実際には2024年のある時点でリリースされる見込みである。このWorking Groupには多くの主要EDAベンダが参加しており、ツール実装の実現可能性も見極めながら標準化が進められているため、2023年版がリリースされてからユーザが手元で使えるようになるまでには、それほど時間を要しないと期待できる。
参考文献
[1] IEEE Standard for SystemVerilog - IEEE Std 1800-2017
[2] Accellera, "Accellera Mantis Database," https://accellera.mantishub.io/my_view_page.php.
DVCon US 2023 paper, "What’s Next for SystemVerilog in the Upcoming IEEE 1800 standard"
-
「Design and Verification Landscape」技術情報メールニュース
-
PALTEKでは本ブログ「Design and Verification Landscape」シリーズの技術情報をメールで年に3-4回発信しています。
ご登録いただいた方には、最新の情報をメールニュースとしてお届けします。
ご希望の方はこちらのフォームよりご登録ください。※競合製品取り扱い企業様の申込については、お断りする場合がありますので予めご了承ください。
このブログのシリーズ一覧は下記になります。是非あわせてお読みください。