systemverilog from zero to one...本チュートリアルの概要 systemverilog from zero to one,...

Document Revision: 1.0, 2018.12.07

篠塚一也

アートグラフィックス

2018.12.11

www.artgraphics.co.jp

SystemVerilog from Zero to One （検証の基礎からUVM適用までの実践知識を習得）

Artgraphics

SystemVerilog from Zero to One, Copyright 2018 © Artgraphics. All rights reserved. 1

JEVeC DAY 2018 チュートリアル資料

http://www.artgraphics.co.jp/

本チュートリアルの概要


• 本チュートリアルでは、SystemVerilogによる検証の基礎知識を総括します。その上で、検証作業に要求される実践知識をUVMを例にとり解説します。

• SystemVerilogが持つ検証機能としては、ファンクショナル・カバレッジ、アサーション、ランダム・スティミュラスの生成機能等を概説し、検証技術習得への準備をします。

• Verilog HDLの知識が無い方には、 SystemVerilogがどの様な言語であるかという概要になります。

• SystemVerilogを学ぶ過程にある方は、 SystemVerilogの持つ機能、特徴、及び、検証に使用する際の注意事項等を習得する事が出来ます。

• 既にSystemVerilogの経験を持つ方は、UVM等の検証ライブラリーを使用する際に必要となる実践知識を習得する事が出来ます。

• 原則として、予備知識を仮定しませんがUVMの一部は高度な知識（例えば、VMM、TLM等）を必要とします。

• このチュートリアルは、SystemVerilogの最新仕様（IEEE Std 1800-2017）、及び、UVM 1.2 をベースにしています。

目次


章概要章概要

１ SystemVerilogの特徴１０ファンクションナル・カバレッジ

２データタイプ１１アサーション

３アレイの操作１２インターフェース

４クラス１３パッケージ

５プログラミング機能１４プログラム

６タスクとファンクション１５便利なシステム・タスクとファンクション

７クロッキング・ブロック１６ UVM概要

８プロセス交信機能１７ UVMの検証への適用

９ランダム・スティムラスの生成１８付録

SystemVerilogが備える特徴的な機能を紹介しVerilog HDLとの差異を明確にします。その差異を通じてSystemVerilogが言語として目指す役割を解説します。

第１章

SystemVerilogの特徴


SystemVerilogはVerilogのsuperset


Verilog

bit, byte,

shortint, int,

longint

logic enum, struct,

union, class,

package,

program

interface,

modport,

clocking

block

mailbox,

semaphore

assertions

functional

coverage

constrained

random

value

generation

dynamic arrays,

associative

arrays, queues,

multi-

dimensional

arrays

SystemVerilog

SystemVerilogの代表的な機能を羅列しました。この他にも、SystemVerilogには重要な機能があります。

SystemVerilog

(IEEE Std 1800-2017)


• SystemVerilogはハードウェア設計、仕様、及び検証を統一的に記述する為の言語です。単なる検証言語ではありません。

• デザインを検証する為には仕様との比較が必要になります。その仕様が検証に使用される言語と同じ言語で記述されていれば、効率的に、且つ、正確に検証を行う事が出来ます。

• 例えば、 SystemVerilogではmodule内で仕様を検証する事が出来ます。この機能はアサーション（assertions）と呼ばれます。以下は、requestが出たら、必ず、acknowledgeされなければならない仕様を記述しています。

Hello, World!


Verilog で簡単に出来る。

SystemVerilog でしか出来ない。

仕様をイベント制御にも使用する事が出来ます。

即ち、仕様を実行する事が出来ます。

便利な初期値設定

（リテラルの拡張）


• SystemVerilogは、’0、’1、’x、’z 等を導入しました。これらのリテラルは可変長で、長さは左辺の長さで決定されます。

• （‘）はtickとも呼ばれます。

可変長リテラル機能

’0 全てのビット位置に0を設定します。

’1 全てのビット位置に1を設定します。

’x、又は、’X 全てのビット位置にxを設定します。

’z、又は、’Z 全てのビット位置にzを設定します。

2-State Types


• Verilogと異なり、2-stateタイプが追加されました。

• これらのタイプを持つ信号は0で初期化されます。

two-state型意味

bit 1ビットの型で値0、又は、1を表現する。符号なしです。

byte 8ビット型でC/C++のcharに相当する。符号付きの8ビット整数です。

shortint 16ビットの符号付きの整数を意味します。C/C++のshort

に相当します。

int 32ビットの符号付きの整数を意味します。

longint 64ビットの符号付きの整数を意味します。C/C++のlong

longに相当します。

2-State Types

（例）


• 2-stateタイプの変数は0で初期化されるので、0で初期化をする必要がありません。従って、時刻0でイベントが起こる事を避ける事が出来ます。

• 一般に、2-stateタイプの変数は4-stateの変数より実行が速くなります。

• forループ等のループ制御変数は、2-stateタイプの変数で十分です。シミュレーション実行速度が向上します。

clkの初期化は不必要。

4-State Types


• 従来のタイプに加えてlogic型が追加されました。

• SystemVerilogでは、regタイプを使用しない事が推奨されています。

4-state型意味

logic 4値を持つ1ビットの型で値0、1、x、又は、z

を表現します。符号なしです。

reg logicと同じ意味を持ちます。

regを使用をしない様にlogic型が導入されました。

integer 4値を持つ32ビットの符号付き整数です。

time 4値を持つ64ビットの符号なしの整数を意味します。

Static and Automatic Variables


• Verilog HDLでは、全ての変数はstaticです。即ち、同じ名称を持つ変数は唯一つしか存在しません。この為、recursiveコール等の処理を記述する事は困難を伴いました。

• SystemVerilogでは、全ての変数に対して、static、又は、automaticの属性を定義する事が出来ます。

• Automatic変数は、使用されているスコープ内の使用されているタイミングで異なる値を取る事が出来ます。即ち、複数のコピーが作られます。


（recursiveコールの例）


• Automatic属性を使用すると、recursiveコールの記述が容易になります。

• ファンクションに対して、automaticと宣言すると、全てのローカル変数はautomaticとなります。

• 下記のファンクション factorial は n! を求める手順を記述しています。Automatic属性を使用しないと、正しい結果は得られません。尚、SystemVerilogでは、return 文を使用する事が出来ます。


（初期化処理に関する注意）


• Static変数は一度だけ初期化され、automatic変数は毎回初期化されます。

• 下記のファンクション count_unknown() は val 内のビット x、又は、zの数をカウントしています。変数 count はstaticである為、一度だけ0に設定されます。従って、二回目以降は、count_unknown() は正しい結果を戻しません。

Verilog HDLの問題点

（変数の初期化順序）


• Verilog HDLにはタイミングに関して曖昧な機能が多々あり、SystemVerilogはそれらを解決しています。

• 例えば、Verilog HDLでは、宣言時に指定した変数の初期化（inline initialization）はシミュレーションの開始と同時に行われます。時刻0で変数の初期化処理を記述すると、予測しない状況が発生します。

• 下記の例に於いて、 Verilog HDLでは６行目の文が２行目の文の後に実行される保証はありません（non-deterministic）。

• SystemVerilogでは、変数の宣言時に指定した初期化処理はシミュレーション開始前に行われる為、上記の例は正しく動作します。即ち、６行目の文が実行する前に、２行目の文が実行します。


(変数の初期化は時刻0でイベントを誘発)


• Verilog HDLでは、イベント待ちの変数にinline initializationが指定されていると、正しい結果を生成するとは限りません。

• Verilog HDLでは、３行目の初期化処理と１０行目のイベント待ちが同時に

実行する為、実行順序により結果が異なります。実行する都度、異なる結果が得られる可能性が高いです。また、異なるシミュレータでは異なる結果を生成します。


（イベント制御機能）


• イベント待ち（@ev）はエッジ・センシティブですが、evには値が無いので状態は残りません。この為、@ev待ちのプロセスがイベント解除をする時期を見逃してしまう可能性があります。

Verilog で次の様な記述をすると何れのinitialプロシージャが先に実行しても、@ev1、又は、@ev2のどちらかが解除されません。

新たに追加されたイベント制御機能

(triggered()メソッド)


• SystemVerilogでは、@ev1、及び、@ev2の代わりに、triggered()を使用し

ます。この関数は状態を保存している為、イベントが発生した事を確実に捉える事が出来ます。

• メソッドtriggered()はエッジ・センシティブな状態をレベル・センシティブな状態に変換をします。

次の記述で何れのイベント待ちも正しく解除されます。

豊富なデータタイプ


• SystemVerilogは豊富なデータタイプを持ちます。2-stateタイプの他に、例えば、package、interface、class、enum、struct、union、string、mailbox、semaphore、program等があります。

• Automatic属性が追加されました。タスク、ファンクション、及び、変数にautomatic属性を付加する事が出来ます。

• typedef文により、ユーザ独自のデータタイプを定義する事が出来ます。

• Verilog HDLと異なり、変数を２次元以上のアレイとして定義する事が出来ます。

• アレイのサイズを実行時に決定する事も出来ます。これらの例としては、dynamic arrays、queues、associative arraysがあります。

• アレイの要素を操作する為のメソッドが多く存在します。

• SystemVerilogではアレイの初期化も容易です（アレイ・リテラル、associativeアレイ・リテラル、キュー・リテラル）。

アレイの初期化例


fork/join

（実践で必要とする重要な機能）


• 並列処理を記述する際に使用する機能が追加されました。Verilog HDLにはfork/joinしかありませんでした。

• SystemVerilogには、fork-join、fork-join_any、fork-join_noneの三種類があります。forkブロック内の文は同時に実行します。ブロック内の文は子プロ

セス（スレッド）として実行します。対のキーワードにより機能が以下の様に異なります。

対のキーワード意味

join 全ての子プロセスが終了するまで、親プロセスは待ち状態に入ります。

join_any 何れか一つの子プロセスが終了するまで、親プロセスは待ち状態に入ります。

join_none 全ての子プロセスを生成しますが、親プロセスは実行を継続します。生成された子プロセスは、親プロセスがブロックするか終了するまで実行を開始しません。

fork/join

（例）


@10 value=1

@20 value=2

@30 value=3

@30 main completed.

fork/join_any

（例）


@10 value=1

@10 main completed.

@20 value=2

@30 value=3

fork/join_none

（例）


@ 0 main completed.

@ 0 value=1

@20 value=2

@30 value=3

プログラミング機能


• Verilog HDLに対して、SystemVerilogは多くの機能を追加しました。例えば、

値を戻さないファンクションを記述する事が出来ます。

タスク、及び、ファンクションの引数に標準値を設定する事が出来ます。

Always文には幾つかの種類が追加されました。

便利なforeach文が追加されました。

プロシージャのループ内で、continue、及び、break文を使用出来ます。

Return文により、処理を途中で終了する事が出来ます。

Do while文があります。

Unique-if、及び、unique-case文が追加されました。

SystemVerilogは、便利な演算子（++、--、+=、等）を備えています。

等等。

ランダム・スティムラス生成機能

（Constrained Random Tests）


• 近年のテスト法は、CRT（Constrained Random Tests）をベースしています。CRTは、制約を満たすテスト・データをランダムに生成します。

• CRTは、膨大な検証空間を効率よく処理する為の効果的な方法です。従来の手作業によるデータ生成（directed tests）は、CRTがカバー出来ない特殊な集合を検査する為に使用されます。

• SystemVerilogは、直感的で、使い易いCRT機能を備えています。乱数を発生すべきデータ項目にrand、又は、randc修飾子を添えるだけで乱数を発生

する事が出来ます。また、制約は、通常の式を用いて設定する事が出来ます。

• 次ページには、CRTの使用例が示されています。

ランダムスティムラス生成機能

（使用例）


ファンクショナル・カバレッジ


• CRTによりテスト・データを生成すると、テスト結果を自動的に集計しなければなりません。SystemVerilogのファンクションナル・カバレッジは、カバレッジ集計機能です。下記はカバレッジ計算の一例です（[3]）。

アサーション


• アサーションはシステムの動作（即ち、仕様）を記述する為の手段です。主として、アサーションはデザインの検証に使用されます。

• Verilogでもアサーションを記述する事は可能ですが、極めて複雑な処理に

なります。記述のデバッグに殆どの時間が費やされて、検証の為の時間が不足するという本末転倒の状況に陥るのが常です。

• SystemVerilogアサーションでは、システムの動作を簡単に記述する事が出来る為、検証自体の作業に専念する事が出来ます。

Verilogによるアサーション


• SystemVerilogで一行で済む記述が、Verilogでは以下の様に複雑な処理になります。

Garbage Collection


• SystemVerilogでは動的にメモリーを割り当てる事が出来ます。Javaと同様に、SystemVerilogではメモリーの解放が自動的に行なわれます。ユーザはメモリー・リークによるメモリーの損失を心配する必要はありません。

• 動的に割り当てられたメモリーは、参照元が存在しなくなった後の適当な時期に解放されます。実際の解放時期はシミュレータの実装法により異なります。

Garbage Collection

（例）


headerは automatic に確保されています。headerにクラス header_t のインスタンス

が割り当てられますが、タスクcheck()が終了すると、割り

当てられたメモリーが解放される対象となります。

packetは static に確保されている為、packetに割り当て

られたメモリーはシミュレーションが終了する迄保持されます。

この章のまとめ


• この章では、SystemVerilogはハードウェアの仕様を記述する機能を持つ事を解説しました。

• SystemVerilogでは多くのデータタイプが追加され、検証コードを効率良く記述する事が出来ます。特に、2-stateタイプはシミュレーションのパーフォーマンスを向上させる効果があります。

• また、 SystemVerilogはシミュレーションのセマンティックスを明確にしている事を例を通じて解説しました。これにより、どのベンダーのシミュレータも同じ結果を生成する事になります。シミュレーション結果の一貫性は、極めて重要な意義を齎します。

• シミュレーション結果の一貫性なしでは、UVMの様な検証ライブラリーの存在が全く意味を持ちません。

• SystemVerilogではプログラミング機能が拡張され、より効率的に検証コードを記述する事が出来る様になりました。

• 近年の検証手法に要求されるランダム・スティムラスの生成、及び、ファンクションナル・カバレッジ機能がSystemVerilogに備えられています。

SystemVerilogは多くのデータタイプを持ちますが、この章ではstring、enum、struct、union等のデータタイプを中心に解説します。

第２章

データタイプ


String Types

（実践で必要とするデータタイプ）


• String型の変数には以下の様な演算を適用する事が出来ます。特に、文字列の結合オペレータ｛｝は非常に便利なオペレータです。Stringはクラスとして実現されています。従って、methodsが定義されています。

演算子意味

str1 == str2 二つの文字列が等しければ1になります。等しくない時には0と評価されます。

str1 != str2 str1 == str2の否定形です。

str1 < str2

str1 <= str2

str1 > str2

str1 >= str2

二つの文字列を辞書引き順序で比較し、正しければ１を戻し、偽の場合には0を戻します。

{str1,str2,…,strn} 文字列を結合します。

{multiplier{str}} 文字列を指定した回数繰り返します。

str[index] indexで指定した文字（byte型）を戻します。indexは0

からN-1の範囲でなければなりません。ここで、Nは文字列の長さを示します。

str.method(…) string型に定義されているmethodを実行します。

String Type’s Methods

（その１）


method 意味

function int len(); str.len()は文字列strの長さを戻します。空文字列の長さは0です。

function void putc(int i, byte c); str.putc(i,c)はstr[i]=cと同じです。

function byte getc(int i); x=str.getc(i)はx=str[i]と同じです。

function string toupper(); str.toupper()は大文字に変換した文字列を戻します。str

の内容は変わりません。

function string tolower(); str.tolower()は子文字に変換した文字列を戻します。str

の内容は変わりません。

function int compare(string s); str.compare(s)はC/C++のstrcmp(str,s)と同じです。

function int icompare(string s); str.icompare(s)はC/C++のstricmp(str,c)と同じです。

function string substr(int i, int j); str.substr(i,j)はインデックスiからjまでの部分文字列を戻します。

function integer atoi();

function integer atohex();

function integer atooct();

function integer atobin();

str.atoi()は整数を表現している文字列が表す10進整数を戻します。例えば、strが”123”であれば、str.atoi()は123を戻します。

atohex()は16進数、atooct()は8進数、atobin()は2進数です。

String Type’s Methods

（その２）


• Stringはクラスですが、newメソッドが定義されていないので、newオペレータでオブジェクトを作る事は出来ません。

method 意味

function real atoreal(); str.atoreal()はstrが表現する実数を戻します。例えば、strが ”3.14” であれば、str.atoreal()は3.14

を戻します。

function void itoa(integer i);

function void hextoa(integer i);

function void octtoa(integer i);

function void bintoa(integer i);

function void realtoa(real r);

integer iを文字列に変換してstrに設定します。

他のfunctionも同様です。

String 使用例

（演算子==、toupper()、文字列の結合）


• 文字列の結合機能は実践で頻繁に使用される便利な機能です。

IEEE Std 1800-2017

$sformatと$sformatf

（文字列を操作する際の便利な機能）


• 通常は、$sformat()タスクよりも、$sformatf() 関数を多く使用します。$sformatf() 関数を $display() システム・タスクと一緒に使うと便利です。

関数機能

$sformat ( output_var , format_string

[ , list_of_arguments ] ) ;

$sformatはタスクです。$displayシス

テム・タスクと同じです。但し、出力をoutput_varにセットします。

string

$sformatf(format_string[,list_of_arguments ] )

$sformatfは文字列を戻すファンクションです。$sformatと同じ機能を持ちますが、出力を戻します。

$sformatf

（使用例）


• エラー・メッセージの書式を作る為に、make_message内で $sformatf が使われています。エラー・メッセージの書式を変更する場合、make_message

に変更を加えるだけで済みます。メッセージを出力する個々のコードには影響しません。

Enumデータタイプ


• Enumデータ・タイプは関連する値を持つコンスタントを定義する命令です。値を明示的に設定する事が出来ますが、自動的に設定させる事も出来ます。

• C++のenum機能と類似していますが、異なる点もあります。例えば、enum

データ・タイプにintegral type（logic、bit、byte、shortint, int等々）を指定する事が出来ます。

• また、enumデータ・タイプには標準的なmethodsが定義されています。タイプが省略されると、int型が仮定されます。

Enum変数を操作する関数

（Enum Methods）


• enumには便利なmethodが定義されています。

method 意味

function enum first(); 最初のenumラベルを戻します。

function enum last(); 最後のenumラベルを戻します。

function enum next( int unsigned N = 1 ); 現在よりN個先のラベルを戻します。最後のラベルの次は最初に戻ります。

function enum prev( int unsigned N = 1 ); 現在よりN個前のラベルを戻します。最

初のラベルに行くと最後のラベルに戻ります。

function int num(); Enumに定義されているラベル数を戻します。

function string name(); 現在のenumラベル名を戻します。

Enum変数を操作する関数

（使用例）


GREEN=1

YELLOW=3

RED=10

Structデータタイプ


• Structureは幾つかのメンバーを一つのグループとして纏めたデータ・タイプ

です。各メンバーは異なるデータ・タイプを持つ事が出来ます。メンバーを個別に参照、又は、操作する事が出来ます。グループ全体として参照する事も出来ます。

• Structureにはpacked structureとunpacked structureがあります。unpacked structureがdefaultで、修飾子unpackedを省きます。

• packed structureではメンバー全体が連続したメモリーに配置されます。従って、structure全体を一つの数値として操作する事が出来ます。

• unpacked structureの場合には、メンバーが連続したメモリーに配置される保証はありません。


（unpacked structの使用例）



（packed structの使用例）


63 16 8 0

a（32ビット） b（16ビット） c（8ビット） d（8ビット）

Structの最初のメンバーはMSBに位置し、最後のメンバーはLSBに配置されます。

Unionデータタイプ


• Unionは一つのオブジェクトを異なる名称で参照する事が出来るデータ・タイプです。structuresと同様に、packed unionの概念があります。structuresとの違いは、メンバーが同じ領域を共有する事にあります。

• 領域を共有する事が目的である為、各メンバーのデータ・タイプは異なります。一見、メモリー使用量の削減効果を持つ様に思えますが、実質的には実行上のオーバーヘッドが大きいという短所を持っています。特別な目的を持たないのであれば、unionは使用を避けるべきデータ・タイプの一つであると思えます。

• 因みに、Javaはunionデータタイプの機能を備えていません。

Typedef


• ユーザ固有のデータタイプを定義する事が出来ます。

• この機能を利用すると、まだ存在しないデータ・タイプを暫定的に定義する事が出来ます。相互に参照しあう二つのデータ・タイプを定義する際には、この機能が必要になります。この機能をforward typedef宣言と呼びます。C++

のforward declarationに相当します。

Forward Declaration

（実践で必要となる技術）


Forward declarationの例。

未定義のクラスProducerを参照する事が出来ます。



• この章では、string型、及び、メンバーを持つデータタイプを解説しました。

• Stringは頻繁に使用されるデータタイプの一つです。 Stringに定義されてい

るオペレータ、及び、メソッドは実行効率の尊重と利便性を考慮した機能です。これらの機能なしでは簡潔なコードを書く事は出来ません。実践には必須の機能です。

• Enumも同様に実践で必須の機能です。特に、enumメソッドは、記憶しておくと努力が報われる時が多々あります。

• Struct、及び、unionデータタイプは、使用する機会は限られていると思いま

す。必要性が発生した時に、詳しく学習すれば良いと思います。現時点では、struct、及び、unionの概略を理解するだけで十分だと思います。寧ろ、後章で解説するクラスが必要になります。

この章ではアレイの種類とアレイを操作する為のメソッドを解説します。また、アレイの初期化機能についても触れます。これらの機能についての知識は簡潔なコードを書く為に必要です。

Queues、及び、associativeアレイは非常に大切な概念である為、詳しく解説します。UVMのソース・コードを解析する際には、必要な知識となります。

第３章

アレイの操作


アレイ


• Verilogと異なり、多次元のアレイを定義する事が出来ます。

• アレイには、キュー、associative arrayもあります。

• sarray[] はダイナミック・アレイの例です。

• price[string] アレイはassociative arrayの例です。

• foods[$]、及び、data[$] はキューの例です。

アレイ・リテラル

キュー・リテラル

packed アレイとunpackedアレイ

（packed and unpacked arrays)


• SystemVerilogでは、名称の前に位置する次元定義をpacked array、名称の後に位置する次元定義をunpacked arrayと呼びます。例えば、

• の定義に於いて、[1:0][7:0]はpacked array、[20]はunpacked arrayです。この場合のpacked arrayは二次元ですが、一次元のpacked arrayはvectorとも呼ばれます。

Packed アレイ

（packed arrays)


• Packed arraysはvectorを階層的に操作する為の宣言手段です。Packed

arraysのビットは連続領域にとられる事が保障されています。例えば、

• に於いて、bytesは2バイトの領域を確保しています。bytes[2]とbytes[1]は物理的に連続した領域に存在します。

• 全体をbytesとして参照する事が出来ます。最上位のビットをbytes[2][7]、最下位のビットをbytes[1][0]として参照する事が出来ます。

• bytes[2]はビット位置としてbytes[1]よりも高位の位置にあります。

bytes

bytes[2] bytes[1]

[7] [6] [5] [4] [3] [2] [1] [0] [7] [6] [5] [4] [3] [2] [1] [0]

Unpacked アレイ

（unpacked arrays)


• Unpacked arraysはpacked arraysと異なり不連続なアレイです。即ち、アレ

イの要素が連続した場所に存在する保障はありません。連続していない為に、unpackedと呼ばれます。例えば、

• に於いて、nameは4バイトの大きさを持っています。name[0]、name[1]、name[2]、name[3]の様に参照する事が出来ますが、それらのバイトは連続していません。

• Unpacked arraysはサイズを指定するだけで宣言を済ませる事が出来ます。例えば、次の二つの宣言は同じです。

• 即ち、unpacked arrayの宣言に於いて、[N]は[0:N-1]と同じ効果を持ちます。packed arraysに対してこの記法を使用する事は出来ません。

name[3] name[2] name[1] name[0]

Unpacked アレイとイベント制御


• Unpacked アレイは不連続である為、アレイ全体でイベント制御をする事は出来ません。例えば、次の例は、コンパイル時にエラーとなります。

• 次の様に、個別にアレイ要素を指定しなければなりません。

コンパイル時にエラーとなる。

アレイの種類と領域定義


記述例領域の定義

string names[10]; アレイnamesに領域が割り当てられます。

アレイのサイズは10です。

process jobs[]; アレイjobsに領域が割り当てられていません。アレイのサイズは0です。使用する前に、領域を割り当てる必要があります。例えば、次の様に領域を定義します。

jobs = new[10];

int days[string]; アレイdaysに領域が割り当てられています。

但し、アレイのサイズは0です。

byte operators[$]; キューoperatorsに領域が割り当てられています。

但し、キューのサイズは0です。

アレイの走査

（foreach文の使用例）


• SystemVerilogにforeach文が追加されました。For文でループ処理を記述するよりも効率良く処理をする事が出来ます。

• 下記の例に於いて、ループ制御変数 i は自動的に確保されます。この変数

は、ローカルに確保され、しかも、automaticです。

January=31

February=28

March=31

...

ダイナミック・アレイ（dynamic arrays）


• SystemVerilogではアレイの大きさを実行時に決定する事が出来ます。この様なアレイをdynamic arraysと呼びます。unpacked arraysにのみ適用される概念です。

• newオペレータを使用してアレイに領域を割り当てなければなりません。

• 割り当てを行う前のdynamic arraysのサイズは0です。領域を割り当てずにアレイを使用すると、一般的には、異常終了します。

ダイナミック・アレイ

（使用例）


• ダイナミック・アレイの割り当てには、newオペレータを使用します。

アレイのコピー（array assignments）（便利な機能）


• fixed arrayをdynamic arrayにコピーする事が出来ます。

• アレイの大きさが0のダイナミック・アレイに対してもコピーする事が出来ます。

ここで、コピーとはダイナミック・アレイに領域を割り当てて、アレイ要素のコピーを行うという意味です。ダイナミック・アレイに既に領域が割り当てられている場合には、deleteメソッドが最初に適用された状態になります。

アレイのコピー

（使用例）


• アレイ同士を=オペレータで結合すればコピーが完了します。

キュー

（キューは検索結果のストレージとして重要）


• Queuesは伸縮自在なアレイです。データ構造のstacks、及び、queuesとして使用する事が出来ます。

• ダイナミック・アレイと異なり、宣言した時点でキューが有効になります。即ち、要素数が0のキューが作成されます。

• Queuesでは、アレイと同じ様に整数型インデックスにより要素にアクセスします。最初の要素はインデックスが0です。最後の要素のアクセスにはインデックス $ を使用します。

• Queuesを空にする為に、{}を使用する事が出来ます。

• Queuesにはアレイと同様の演算を適用する事が出来ます。アレイと異なる点は、queuesは伸縮自在である事です。キュー qに対してq[a:b]もキューです。

キュー

（使用例）


• 下記の例が示す様に、キューの初期化を簡単に行なえます。

• キューの要素の参照を通常のアレイ要素と全く同じ様に行なえます。

キュー・リテラルは

‘{1,2,3}ではありません。

キューを空にしています。

キューをアレイの様に使用している。

キューを操作する関数

（queue methods）


メソッド意味

function int size(); Queueの要素数を戻します。

function void insert(input integer

index, input element_t item);

指定した位置（index）に要素を挿入します。位置が正しくない場合、何も挿入されません。

function void delete( [input integer

index] );

indexが指定された場合、そのindex位置にある要素を削除します。

indexが省略された場合、queueの全ての要素を削除します。

function element_t pop_front(); Queueの先頭の要素を削除して戻します。

function element_t pop_back(); Queueの最後の要素を削除して戻します。

function void push_front(input

element_t item);

Queueの先頭に要素を挿入します。

function void push_back(input

element_t item);

Queueの最後に要素を追加します。

キューを操作する関数

（使用例）


• 操作関数を以下の様に簡単に使う事ができます。

Associativeアレイ


• 必要なアレイのサイズが算出可能で、且つ、使用するアレイのインデックスが連続している場合には、dynamic arraysは便利な手段です。その条件を満たさない場合には、associative arraysを使用する方が効率が良くなります。

• Associative arraysは、検索キーが与えられると対応するデータを戻すマップです。

• ダイナミック・アレイと異なり、宣言した時点でアレイが有効になります。即ち、要素数が0のassociative arrayが作成されます。従って、newオペレータで領域を割り当てる必要はありません。index_typeとして使用できる形式が幾つか存在します。そして、キーには自然な順序が付けられています。

Associativeアレイのインデックス・タイプ


[index_type] 意味

[*] Wildcard indexタイプと呼ばれ、任意の整数式をインデックスとして使用する事が出来ます。但し、four stateの値をインデックスとして使用する事は出来ません。

[string] インデックスはstringタイプです。空文字列もキーとして許されます。辞書引き順序が使用されます。

[class] クラス・オブジェクトをインデックスとします。オブジェクトはC++

でいうポインターに相当するので、インデックスとしてナル（null）も許されます。キーの順序は定まっていますが、実装す

るシミュレータにより異なります。一般的には、オブジェクトのアドレスがキーになっていると考えて良いと思います。

[integer]

[int]

[shortint]

[byte]

[longint]等

整数系のインデックスを使用します。但し、four stateの値をインデックスとして使用する事は出来ません。

Associativeアレイの要素の登録

（間違い易い機能）


• Associativeアレイの要素が存在しない時、次の何れかが発生します。

アレイ要素がLHSとして使用されている場合には、要素が自動的に割り当てられます。

アレイ要素がLHSとして使用されていない場合には、要素は割り当てられません。

• SystemVerilogのassociative arraysの特徴は、キーで示すアレイ要素が存在しない場合の条件を指定できる便利さにあります。

Associativeアレイの要素の登録

(使用例)


• priceはstring型をキーに持つassociative arrayです。定義に於いて標準値を100に設定しています。もしキーで示すデータが存在しない場合には整数値100をデータとしてpriceに登録します。

• 最初はprice.size==0である為、price[key]は存在しません。定義により、price[key]の要素が作られ、price[key]==100となります。price[key]++の実行後に、price[key]は101になります。詰まり、price[“bread”]==101です。

• その後、price[key] += 20によりprice[“bread”]==121となります。

Associative アレイの関数


method 意味

function int num();

function int size();

アレイに登録されている要素数を戻します。

function void delete( [input index] ); indexが指定されれば、indexをキーに持つ要素を削除します。その要素が存在しない場合、何も実行されません。

indexが省略された場合、アレイの要素を全て抹消します。

function int exists( input index ); 指定したindexを持つ要素が存在するかチェックします。存在すれば1を戻し、存在しなければ0を戻します。

function int first( ref index ); アレイの最初のキーをindexにセットします。

アレイが空の場合、0を戻します。空でない時には、1を戻します。

function int last( ref index ); アレイの最後のキーをindexにセットします。

アレイが空の場合、0を戻します。空でない時には、1を戻します。

function int next( ref index ); 指定された indexよりも次に大きいキーが存在すればindexにセットして1を戻します。存在しない場合、0を戻します。indexに変化はありません。

function int prev( ref index ); 指定されたindexより一つ手前のキーが存在すればindex

にセットして1を戻します。存在しない場合、0を戻します。indexに変化はありません。

Associative アレイの関数

（使用例）


• １４行目から１７行目の記述が重要です。

• 因みに、foreach文を使用するともっと簡単になります。

Associative アレイへのアクセス

（foreach文で簡単に処理する方法）


• Foreach文を使用するとアレイの全要素を簡単の取り出す事が出来ます。

• インデックスwordはstringタイプとして自動的に確保されます。

Associativeアレイ・リテラル

（ Associativeアレイの初期化機能）


• Associative arraysの初期化にはアレイ・リテラル ‘{...} を使用します。

• 初期化には、キーとデータ値の対をコロン（:）で区切って指定します。ここでは指定をしていませんが、default値も与える事が出来ます。

アレイ検索関数（array locator methods)


• Array locator methodsはqueuesを含む全てのunpacked arraysに適用す

る事が出来ます。これらのメソッドはアレイの要素を与えられた条件で検索します。

• 検索結果はリストとしてqueueに記録されます。検索結果は要素のリスト、又は、要素へのインデックスのリストになります。

• 検索条件をwith を使用して記述します。

method 意味

find() 検索条件を満たす全ての要素を戻します。

find_index() 検索条件を満たす要素へのインデックスのリストを戻します。

find_first() 検索条件を満たす最初の要素を戻します。

find_first_index() 検索条件を満たす最初の要素のインデックスを戻します。

find_last() 検索条件を満たす最後の要素を戻します。

find_last_index() 検索条件を満たす最後の要素のインデックスを戻します。

アレイ検索関数

（使用例）


アレイ検索関数（array locator methods)


• 以下のmethodsに対しては、検索条件を省略する事が出来ます。

method 意味

min() 最小値を戻します。

max() 最大値を戻します。

unique() 重複の無い要素のリストを戻します。

unique_index() 重複の無い要素のインデックスのリストを戻します。

アレイ検索関数

（使用例）


アレイ要素の順序を操作する関数

（array ordering methods


• これらのmethodsはアレイ要素の順序を入れ替える機能を持っています。アレイ自身に適用されて内容が更新されます。

• 但し、associative arraysに適用する事は出来ません。

method 意味

reverse() アレイ要素の順序を逆に並べ替えます。with条件を指定する事は出来ません。

sort() 要素を上昇順に並べ替えます。with条件を指定する事が出来ます。

rsort() 要素を下降順に並べ替えます。with条件を指定する事が出来ます。

shuffle() 要素をランダムな順に並べ替えます。with条件を指定する事は出来ません。

アレイ要素の順序を操作する関数

（使用例）


アレイを計算する関数

（array reduction methods）


• その名が示す通り、アレイの複数の要素から一つの値を導き出す機能です。with clauseを指定する事が出来ますが、withは値を作る為に使用されます。integral typesの全てのunpacked arraysに適用する事が出来ます。

• 戻される値のタイプは、原則として、アレイ要素と同じタイプです。

method 意味

sum() アレイ要素の和を戻します。with条件を指定する事が出来ます。

product() アレイ要素の積を戻します。with条件を指定する事が出来ます。

and() アレイ要素のビット毎のAND（&）を戻します。with

条件を指定する事が出来ます。

or() アレイ要素のビット毎のOR（|）を戻します。with条件を指定する事が出来ます。

xor() アレイ要素のビット毎のXOR（＾）を戻します。with

条件を指定する事が出来ます。


（細心の注意が必要な例）


• 代表的な例としてsum()を示しています。他の関数も同様です。

• １０行目以外は容易に理解する事が出来ます。この行は３より大きい要素の和を求めています。然し、withクロースは複雑な計算式になっています。

• １０行目で、data.sum with (item>3) とすると、r == 2 となってしまいます。


（間違い易い例）


• 前の例が示す様にarray reduction methodsを使用する際には注意が必要です。注意が必要な例をもう一つ紹介します。

• 1+1+1==3であるにも関わらず、state.sumは1とプリントされます。

state.sumのタイプはstateの要素のタイプbitと同じです。従って、1ビットのタイプです。この為、state.sumが１となっています。

• この問題を避ける為には、ビット長を拡張する必要があります。その為に、3’b0+state.sumとすると正しい結果を得ます。

state.sumの説明補足


• 前例に於いて、シミュレータは充分なビット長を用いてstate.sumを計算します。例えば、この場合は32ビットで計算します。従って、state.sumには3が正しく求まっています。

• 問題は、$display()文にあります。この文は、コンパイル時にビット長を決定しなければなりませんが、state.sumの値のビット長をコンパイル時に知る事が出来ません。

• 唯一のヒントはstate.sumの定義です。定義によると、array reduction methodsが戻す値のタイプは、アレイ要素と同じタイプです。即ち、１ビットです。

• 故に、 $display()文は、state.sumは１ビットであると判断しています。

• 一方、3’b0+state.sumは、$display()文にビット長が３ビットであるヒントを与えています。

• １ビットとvectorは、本質的に異なります。



• アレイは必ず使用する機能です。特に、ダイナミック・アレイは必須の機能です。

• ダイナミック・アレイを使用する際には、必ず、領域をnewオペレータで割り当てる必要があります。

• アレイのサイズが未知で、アレイのインデックスがスパースである場合には、associative arraysを使用するのが得策です。

• 実践では、クラス・オブジェクトをキーにしたassociative arraysが頻繁に利用されます。 associative arraysの使い方をマスターして下さい。

• SystemVerilogではJavaと同等にガーベッジ・コレクションが自動的に働きま

す。メモリー・リークの心配が無いので、積極的にダイナミック・アレイを使用する事を薦めます。

クラスは関連する要素を同じグループに纏め、それらの要素を操作する機能を提供する便利なデータタイプです。検証作業には欠かせないツールです。

UVMの様な検証パッケージを使用する為には、クラスに関する知識を完全にマスターする事が必要です。

第４章

クラス (Classes)


Class


• クラスはデータ・タイプの一つで、データとサブルーティン（functions、及びtasks）から構成されます。クラスでは、データをプロパーティ（properties）、サブルーティンをメソッド（methods）と呼びます。

• クラスにはnewと呼ばれる特別なメソッドがあり、コンストラクタと呼びます。コンストラクタはクラスのインスタンス（つまり、オブジェクト）を創成します。

• SystemVerilogのクラスの概念はC++のそれよりJavaのクラスに似ています。

• 例えば、サブクラスを定義する為には、Javaと同様にextendsを使用します。ダイナミックに割り当てたメモリーの解放は、Javaと同様に自動的に行なわれます。

• クラスのメソッドには重要な属性virtualがあります。これは、クラス・インヘリタンス（継承）に従って、対応するメソッドが呼び出される機能です。

Class

（定義例）


クラスのコンストラクタ


• クラスにはコンストラクタの定義が必要です。指定を省略するとコンパイラーが自動的に定義します。

• クラスのコンストラクタは function newで始まらなければなりません。

• クラスのコンストラクタには virtual を付ける事は出来ません。

クラス・オブジェクトとメンバーへのアクセス


• クラスはデータ・タイプです。オブジェクトはクラスのインスタンスです。クラス・タイプを持つ変数を定義して、次の様に変数にオブジェクトを割り当てます。

• SystemVerilogではこの変数をオブジェクト・ハンドルと呼びます。オブジェクトを割り当てていないハンドルにはナル（null）が割り当てられます。ナルのハンドルでプロパーティやメソッドにアクセスすると、一般的には、異常終了すると考えた方が安全です。

• SystemVerilogでは、プロパーティ及びメソッドへのアクセスにはハンドルとドット（.）を使用します。C/C++の様な記法（->）は出来ません。

• Staticなメンバーへのアクセスは、スコープ・オペレータを使用する事が出来ます。

クラス・インヘリタンス

（クラスで最も重要な概念）


• 既に定義済みのクラスを使用して、新しいクラスを定義する事が出来ます。新しいクラスはサブクラスと呼ばれます。基のクラスをベース・クラスと言います。

• Javaと同様に、キーワード extends を使用してサブクラスを定義します。

• 既存のクラスをベースにして新しいクラスを定義する場合には、コンストラクタの最初の命令はsuper.new()でなければなりません。

• サブクラスでは、ベース・クラスの local メンバー以外のメンバーを自由に使用する事が出来ます。

クラス・インヘリタンス

（使用例）


• コンストラクタの最初の命令は super.new(name,a,d) になっています。

• Virtual メソッド print の内容を書き換えています。

• クラスには、自分自身を参照する為の特別なハンドル this があります。

this ハンドル

ベース・クラスにメンバーを追加。

タイプ指定のコンストラクタ呼び出し


• newコンストラクタのクラス・タイプは左辺の変数のクラス・タイプにより決定されます。例えば下記の場合、newのクラス・タイプはsample_tです。

• newの前にクラス・スコープを指定する事によりコンストラクタを変える事が出来ます。

• 例えば、tr2のタイプはsimple_transactionですが、サブクラスdelayed_simple_transactionのコンストラクタを呼んでいます。この為、tr2

は実際にはdelayed_simple_transactionのインスタンスを指しています。

StaticとAutomaticプロパーティ

（必須の知識）


• クラスに定義したメンバーは、原則として、automaticです。従って、クラス・イ

ンスタンス毎に存在します。しかも、メソッドが呼ばれると引数、及び、メソッド内の変数はスタック上に確保されます。言い換えると、以前の状態は保存されていません。

• 同じクラス・タイプのインスタンス全てに共通なメンバーを定義する為には、staticという修飾子を使用します。プロパーティ、及び、メソッドに対してこの修飾子を適用する事が出来ます。

• staticメンバーは唯一つしか存在しないという性質から、クラス・スコープを使用してstaticメンバーへのアクセスをする事が出来ます。クラスのインスタンスを作る必要はありません。

クラス・ハンドルのアレイ

（C++との差異）


• クラス・オブジェクトのアレイを確保する事は出来ませんが、クラス・オブジェクトへのポインターのアレイを確保する事は可能です。

• 下記の例では、アレイ・サイズは10と決定していますが、クラスへのハンドルは定義されていません。C++と異なり、コンストラクタは自動的に呼ばれません。従って、アレイの初期化を明示的に行なう必要があります。

クラス・ハンドルのアレイを初期化する。

クラスのコピー

（shallow copy）


• クラス・ハンドルをコピーする事が出来ます。コピーすると、二つのハンドルが同じクラス・オブジェクトを参照する事になります。クラス・オブジェクトを創成する事にはなりません。

s1とs2は同じクラス・オブジェクト参照しています。

s3はs1と異なるクラス・オブジェクトを指しますが、メンバーの値は同じです。

s3はs1の内容をコピーして作られました。このコピーは、所謂、shallow

copyです。即ち、recursiveにはコピーされません。

Virtual Methods

（実践で必要となる重要な技術）


• C++でいうvirtual functionsと同じ概念です。ベース・クラスにvirtualメソッドvmを定義すると、継承されたサブクラスのオブジェクトに一致するメソッドvm

を呼び出します。

• 言い換えると、クラス・ハンドルがベース・クラスのタイプでも、ハンドルが継承されたクラスのインスタンスを示していれば、継承されたクラスのvmを呼び出します。

• 尚、Javaにも対応する概念がありますが、 Javaではキーワードvirtualを使用しません。この点は、JavaとSystemVerilogの言語上の差異です。

Virtual Methodsの使用例

（この技術の習得はMUSTです）


• base_t::print()はvirtualです。サブクラスtr_tではbase_t::print()を再定義しています。メソッドprint_class()が両方のクラスに定義されていますが、これらは無関係です。

アブストラクト・クラスと

ピュア・バーチャル・メソッド


• クラスを継承する事により、クラスの定義をより詳細に定義して行きます。その際、ベース・クラスの決めたルール（メソッドの使用法）に従う事が原則となっています。

• 極端なベース・クラスの場合、ルールだけを定義する事が出来ます。この様なクラスをアブストラクト・クラスと言います。

• アブストラクト・クラスは未完成である為、インスタンスを作る事は出来ません。メソッドの定義は署名（signatures）だけから構成する様にします。その場合、修飾子pureを用います。

• サブクラスはprintの定義をしなければなりません。具体的な定義をしない場合、サブクラスもアブストクラスになり、インスタンスを作成する事は出来ません。

• UVMを理解するには、アブストラクト・クラスの概念を理解しなければなりません。

クラススコープ・オペレータ

（class scope resolution operator ::）


• クラスのパラメータ、データタイプ、staticメンバーにアクセスする場合にはこのオペレータを使用します。

• ビルトイン・クラスを使用する場合には、クラススコープ・オペレータは必須となります。例えば、下記の例に於いて、processオブジェクトを作る事は出来ない為、process:: は必須のオペレータです。

クラススコープ・オペレータ

メンバーへのアクセス制限

（local and protected）


• クラス・メンバーへのアクセスを制限する為に、local、及び、protectedを使用する事が出来ます。local属性は、メンバーへのアクセスを同じクラスのタイプにだけ許します。protected属性はサブクラスのみがアクセスできる様に制限します。

パラメータによる汎用クラスの定義

（UVMを理解する為には必須の知識）


• クラスの定義にタイプ・パラメータを付加する事により、汎用的なクラスを定義する事が出来ます。C++、及び、Javaに同様の概念があります。

• 例えば、整数をキーにする辞書と文字列をキーにする辞書は同じ機能を持ちます。異なる点は、キーのデータ・タイプが異なるだけです。

• この様な場合、キーをパラメータKEY、データのデータ・タイプをパラメータDATATYPEとしてクラスを定義します。そして、クラス内では、KEYとDATATYPEを使用して論理を記述します。

• 使用する側は、クラスのインスタンスを作る時に、KEYとDATATYPEに実際のデータ・タイプを指定します。


（その１）


抽象的なタイプを使用して、汎用的な辞書を定義する。

タイプには標準値を定義して置くと親切、且つ、便利です。


（その２）


• パラメータ化したクラスを使用する為には、具体的なタイプを指定する必要があります。

mapに対して具体的なタイプを指定する。

クラス・ハンドルの初期化

（間違い易い例：その１）


• クラス・ハンドルの宣言時にハンドルの初期化をする事が出来ますが、実行順序に依存する可能性がある為、注意が必要です。

• 例として、下記の様なクラス定義を考えます。

Virtual interfaceを使用しています。

クラス sample_t はインターフェース simple_if に依存します。

クラス・ハンドルの初期化

（間違い易い例：その２）


• 先ず、クラス・ハンドルを宣言時に初期化をする例を示します。結果は正しくありません。

• 次に、クラス・ハンドルの宣言と初期化を別に行う記述を示します。正しい結果を得ます。



• クラスを定義する場合、コンストラクタを必ず定義する習慣を身に着ける事が大切です。結局のところ、newオペレータを呼ばなければクラスのインスタンスを作る事は出来ません。

• Virtualメソッドは重要な概念であると共に、注意が必要です。メソッド内で、ベース・クラスのvirtual メソッドも呼ばなければならないかは重要な判断になります。成すべき機能の分担を明確に定義する必要があります。

• パラメータ化したクラスを定義する場合、先ずパラメータを持たないクラスで開発を済ませ、その後、パラメータ化する方法は効率が良いと考えられます。

• クラスの全てのメンバーは、原則として、automaticである事を記憶して置いて下さい。

プログラムを記述する為の基本的な機能、及び、プロシージャinitial及びalwaysを解説します。また、同期を取る為のタイミング機能についても解説します。

並列プロセスを生成する為のforkブロックの使い方に関する重要な注意にも触れます。

第５章

プログラミング機能 (Procedural Programming Statements)


initialプロシージャ


• initialプロシージャはシミュレーションの開始時に一度だけ実行するプロシージャで、変数の初期化等をする為に使用します。

• initialプロシージャで記述された初期化は信号の値の変化によるイベントを起こします。例えば、上記の記述の _reset = 0 により @(negedge _reset)

のイベントが時刻 0 で発生します。

alwaysプロシージャ


• alwaysプロシージャは繰り返し実行する命令群のブロックです。SystemVerilogには、以下のプロシージャがあります。

汎用always

always_comb

always_latch

always_ff

汎用alwaysプロシージャ


• alwaysプロシージャは単純なループです。C/C++で記述すると次の様になります。

• 従って、alwaysプロシージャは何らかのタイミング制御命令を含まなければなりません。最も良く使われるalwaysプロシージャの形式は以下の様になります。

• SystemVerilogでは実行中のプロセスがタイミング制御に遭遇してブロック

すると、他のプロセス（あるいはスレッド）に実行権が譲渡されます。たとえ遅延が0のタイミング制御（#0）でもこの状況が起こります。逆に、この現象を利用して効果的な並列処理の制御を記述する事が出来ます。

タイミング制御の効果的使用法

（#0）


• 例えば、以下のforループで三つのテストケースをスレッドとして同時に実行

する目的ですが、それらのスレッドは即時には実行を開始しません。生成した親プロセスがブロックして初めて、子プロセスの実行が開始します。

• forループ・ブロックを終了すると、タイミング制御（#0）で親プロセスがブロッ

クし、三つのテストケースの実行が開始します。三つの子プロセスの実行を開始させる為に、故意に #0 を使用しています。

• テストケースに、それぞれ、0、1、2を割り当てる為にforkブロックの入り口で

j の値をkに保存しています。三つのforkブロックは独自のkを保有します。

always_combプロシージャ


• 組み合わせ回路を記述する為のブロックです。Verilogにはない構造的ブロックです。

• Verilogで組み合わせ回路を記述する場合、回路が依存する全ての信号をセンシティビティ・リスト（@(...)）としてalwaysプロシージャに記述しなければ

なりません。センシティビティ・リストに指定された信号が変化した時のみ組み合わせ回路が動作する為、不完全なセンシティビティ・リストの指定は正しくないシミュレーション結果に繋がります。

• SystemVerilog のalways_combプロシージャはセンシティビティ・リストを自

動生成する機能を持っています。例えば、以下の記述はセンシティビティ・リスト @(a,b) を自動生成します。

always_latchプロシージャ


• always_latchプロシージャはalways_combと似ています。違いは、always_latchはラッチ回路を記述する為のプロシージャです。即ち、プロ

シージャがラッチの記述になり得ない場合、コンパイル時に警告が発行されます。

• 例えば、次の記述は警告の対象になります。

always_ffプロシージャ


• このプロシージャは論理合成可能なシーケンシャル回路を記述する為に考案された機能です。

• プロシージャの先頭でイベント制御し、制御信号をposedge又はnegedgeで

制御しなければなりません。また、ブロッキング・タイミング制御命令を使用する事が出来ません。

• 例えば、次の記述は正しいシーケンシャル回路です。

finalプロシージャ


• シミュレーションの実行が終了した時点で制御を受けるプロシージャです。シミュレーションは終了している為、時間を消費する命令をfinalプロシージャに記述する事は出来ません。

• 通常は、シミュレーション結果を総括する情報をプリントする命令を記述します。

Forkブロック関する注意

（細心の注意が必要なケース）


• ブロック内で生成された子プロセスは親プロセスがブロックするまで実行を開始しません。この為、変数の参照には特別な注意が必要です（[1],[3]）。

• 次の例には、forループの内部にfork-join_noneがあり、ループ制御変数i

の値をプリントしています。iの値が１２３とプリントされる事を期待している

コーディングですが、予想に反して結果は４４４になります。

• fork-join_noneにより$writeのプロセスが生成されますが、親プロセスがブロックするまで、子プロセスは開始しません。forループが終了した時に親プロセスはブロックしますが、この時にはi==4となっています。従って、三つの

$writeのプロセスは4をプリントします。

Forkブロック関する注意

（正しい記述法）


• forkブロック内の子プロセスは親プロセスと異なるタイミングで実行する為、現在の実行環境を保存しておく必要があります。

• 実行環境を保存する為に、新たな変数をautomaticで確保して、以下の様に定義します。こうすると、123とプリントされます。

• fork文が実行する時、iの値がkに保存されます。kはautomaticである為、ループ回数だけkが確保されます。即ち、三つの子プロセスは独自のkを保

有する事になります。それらは、順に1、2、3です。

イベント制御（event control）


• ネットや変数の値の変化に同期して実行制御を行う方法がイベント制御です。良く知られているイベントとしては、posedge、negedge、及び、edgeがあります。これらは、エッジ・センシティブ・イベント制御（edge-sensitive event

control）と呼ばれます。指定したイベントが起こるまで実行をブロックします。

• 例えば、次の様にしてイベント制御を行います。

イベント意味

posedge 0から他の値への変化。或いは、x、又は、zから1への変化。

negedge 1から他の値への変化。或いは、x、又は、zから0への変化。

edge posedge、又は、negedgeのイベント。

レベル・センシティブ・イベント制御


• ある条件が満たされるまで実行待ちをする制御がレベル・センシティブ・イベント制御です。通常、wait文を使用します。関連する命令としては、wait fork、及び、wait_orderがあります。

• 例えば、次の記述は、キューに要素が入れられるのを待っています。

• wait文が実行した時、もしq.size() == 0であれば、q.size() > 0になるまで、待ち状態に入ります。一方、wait文が実行した時にq.size() > 0 であれば、実行は継続し、 index = q.pop_front を実行します。

wait fork文


• この文は、現在のプロセスが直接生成した全ての子プロセスが終了するのを待ちます。但し、子プロセスが生成した孫プロセスは除外されます。

• 最初のforkで作られた子プロセスprint(3)が最も遅く実行を終了します。親プロセスはその後に実行を再開します

disable fork文


• この文は、現在のプロセスが生成した全てのプロセスの実行を中止します。

• 下記の例では、メイン・プロセスは三つの子プロセスを生成しています。然し、その中の一つの子プロセスが終了すると、他の子プロセスを終了します。従って、print(2)、及び、print(3) の実行はキャンセルされます。

ユーザ固有のプロセス制御

（やや難易度が高い機能）


• SystemVerilogでは、プロセスはビルトイン・クラスです。即ち、processとい

うクラスが存在します。そのクラス・オブジェクトをタスクの引数としてパスする事により、詳細なプロセス制御を実現する事が出来ます。processクラスは以下に様に定義されています。

Processに定義されているメソッド


メソッド意味

self() この呼び出しを行っているプロセスのオブジェクトを戻します。

process p = process::self();

の様にして使用します。newオペレータでprocessオブジェクトを作る事が出来ないので、このself()関数はプロセスを取得する為の唯一の方法です。

status() プロセスの状態を戻します。

FINISHED：プロセスは正常に終了。

RUNNING：プロセスは現在実行中。

WAITING：プロセスは待ち状態に入っている。

SUSPENDED：一時的に中断されて、実行再開を待っている。

KILLED：強制的に終了された。

kill() プロセスを終了します。全ての子プロセスも終了します。

await() 他のプロセスの終了を待ちます。自分自身の終了を待つ事は出来ません。従って、p.await()；の様に使用しなければなりません。ここでp!=process::self()です。

suspend() 自分自身又は他のプロセスを中断します。既に中断しているプロセスに対しては何の効果もありません。

resume() 中断しているプロセスの実行を再開します。

Processに定義されているメソッド

（使用例）


if文


• if文の一般形式は以下の様になっています（[1]）。unique_priorityが拡張機能です。

• unique_priorityは、条件の一致、又は、不一致に関する状態を制限する為のキーワードです。

conditional_statement ::=

[ unique_priority ] if ( cond_predicate ) statement_or_null

{ else if ( cond_predicate ) statement_or_null }

[ else statement_or_null ]

unique_priority ::= unique | unique0 | priority

全ての条件を列挙（fully specified)


• unique-ifとpriority-ifに於いてelseクローズが存在しない場合、条件を満たさない状態が発生すると実行時にエラーの対象となります。但し、unique0では、エラーが出ません。unique0の0はOFFに相当し、メッセージをsuppress

する意味です。例えば、

• もしaが1、3、4、5、又は、6であると、条件を満たすif-else-ifが存在しない為、実行時にエラー・メッセージが発行されます。priority-ifも同様です。RTL 論理合成の分野では、full caseと呼ばれる機能です。

unique-if、unique0-if文


• if-else-ifの条件にはオーバーラップが無い事を宣言する命令です。詰まり、

条件は排他的である為、条件判定は順序に依存しない事を意味します。この為、条件判定を並列的に処理する事が出来ます。当然、条件のオーバーラップが発生するとエラーになります。但し、unique0-ifはエラー・メッセージを出しません。例えば、

• の記述は、最初のif条件と二番目のelse-if条件が同時に成立する為、エラー・メッセージを発行させます。論理合成の分野では、parallel caseと呼ばれる機能です。unique宣言をする事により論理の最適化につながります。

priority-if文


• if-else-ifの条件は記述した順に評価されなければならない事を指定する命令です。この制御は、論理の最適化処理に影響します。

0 or 1

2

#-E D:/Users/TestData/UniqueIf_N001.sv (L14) Nomatch violation: test

実行結果

case文


• シンタックスは以下の様になっています（[1]）。

case_statement ::=

[ unique_priority ] case_keyword ( case_expression )

case_item { case_item } endcase

| [ unique_priority ] case_keyword (case_expression )matches

case_pattern_item { case_pattern_item } endcase

| [ unique_priority ] case ( case_expression ) inside

case_inside_item { case_inside_item } endcase

unique_priority ::= unique | unique0 | priority

case_keyword ::= case | casez | casex

unique-case、unique0-case文


• if-else-if文と同様にunique、及び、unique0を使用する事が出来ます。意味も同様です。即ち、

case-selectionで書かれた条件は排他的である事。

全ての条件が列挙されている事。

違反した場合、unique-case文ではエラーが出ます。

• 論理合成の様なアプリケーションでは、この宣言は論理の最適化に役立ちます。

unique-caseの例


• key==6の場合、二つの条件を満たす為、unique-caseに違反します。

priority-case文


• if-else-if文の場合と同様です。全ての条件が列挙されている事。そして、条件は上から順に検索される事です。もしcaseの条件を満たすcase_itemが存在しない場合、priority-caseへの違反のメッセージが出ます。例えば、次の例で、a=4、5、6、又は、7の場合、違反となります。

insideオペレータとif文


• insideオペレータはif文で使用する事が出来ます。

insideオペレータとcase文


• insideオペレータはcase文で使用する事が出来ます。１６行目を参照。

for文


• SystemVerilogではforループを制御する変数を定義する事が出来ます。定義した変数は、automaticの属性を持ちループ内でのみ使用する事が出来ます。

foreach文


• foreachループは、全てのアレイに適用する事が出来る便利なループ制御文

です。アレイ名称とループ制御変数名を指定するだけでループ処理を記述する事が出来ます。ループ制御変数は、コンパイラーが自動的に確保します。制御変数は、automaticでread onlyです。シンタックスは以下の通りです。

• 確保されるループ制御変数のタイプはアレイの宣言タイプにより決定されます。

foreach ( ps_or_hierarchical_array_identifier [ loop_variables ] )

statement

loop_variables ::= [ index_variable_identifier ]

{ , [ index_variable_identifier ] }

foreach文の例


• １３行目で確保されるループ制御変数 i はstring型です。

City Area Code

-------------------------------

Berkeley 510

Los Angeles 213

New York 212

San Francisco 415

San Jose 408

実行結果

repeat文


• 指定した回数だけループを実行する命令です。回数を正しく評価できない場合、ループは実行しません。シンタックスは以下の様になります（[1]）。

• 例えば、次の様に使用します。

repeat ( expression ) statement_or_null

do-while文


• SystemVeilogではdo-while文を使用する事ができます。シンタックスは以下の様になっています（[1]）。

• statement_or_null を実行し、expressionが真（true）である限りdoブロックを繰り返します。

do statement_or_null while ( expression ) ;

do-while文の例


• enumに定義されているラベルを順に取り出してプリントしています。少なくとも一つのラベルが存在する事を仮定した処理になっています。enumのラベ

ルを初めから順に取り出すと、最後のラベルの次は最初のラベルに戻ります。その特性を利用してループ処理を記述しています。

forever文


• 無限に実行を繰り返します。シンタックスは以下の通りです（[1]）。

• タイミング制御文が使用されないと、単純なループを繰り返します。結果として、シミュレーションは進展しません。必ず、タイミング制御文が使用されなければなりません。例えば、次の様に使用します。

forever statement_or_null

return文


• SystemVerilogではC/C++と同様にreturn文を使用する事が出来ます。

break文


• この文はループから抜け出す為に使用します。forループ以外にも使用する事が出来ます。次の例ではbreak文をforeachループで使用しています。

continue文


• この文はループの終わりにジャンプして次のループを継続する命令です。即ち、この文以降の命令をスキップする機能を持ちます。forループ以外にも使用する事が出来ます。次の例ではcontinue文をforeachループで使用しています。

インクリメント及びデクリメント演算子

（++、--)


• C/C++と同じ様に++、及び、--を使用する事が出来ます。これらのオペレータは複合命令を実行しますが、命令はブロッキングとして実行します。

• これらのオペレータをassociative arrayに適用する場合には注意を必要とします。例えば、a[key]++ の操作で、a[key] が存在しない場合、要素a[key]

が自動的にアレイに登録されます。初期値は、予めassociative arrayで定められた値になります。登録後、a[key]++ が実行します。

冪乗


• SystemVerilogでは、冪乗の記法を使用する事が出来ます。𝑥𝑦を求める為には、x**yと記述します。例えば、

• とすると、x==8となります。

比較演算子（equality operators)


• === の場合には、x及びzを含んで完全に一致する事を要求します。従って、結果は0、又は、1の何れかです。一方、== はfour state値を含む場合には比較できないので、結果はxとなります。

演算子意味

a === b 一致すれば1、そうでなければ0を戻します。比較はx、及び、zを含んで行われます。判定結果がxになる事はありません。

a !==b a===b の否定形です。一致しなければ1、そうでなければ0を戻します。比較はx、及び、zを含んで行われます。

a == b 一致すれば1、そうでなければ0を戻します。但し、a、又は、bの何れかがx、又は、zの値を含む場合には、比較結果はxとなります。

a != b a == bの否定形です。一致しなければ1、そうでなければ0を戻します。但し、a、又は、bの何れかがx、又は、zの値を含む場合には、比較結果はxとなります。

ワイルドカード比較演算子

（wildcard equality operators)


• ワイルド・カードは、0、1、x、及び、zの何れにもマッチします。

• a ==? b に於いて ? がb側に付いているので、b に現れる ? (つまり、x、及び、z)を don’t careとして扱うという意味です。

• a に現れるx、及び、zはwildcardではありません。

• 例えば、4’b0101 ==? 4’b010zは真です。然し、4’b010z ==? 4’b0101はunknown （x）です。

演算子意味

a ==? b a == bと同じです。但し、bに含まれるx、又は、zはワイルドカードとして扱われます。

a !=? b a ==? b の否定形です。a != bと同じです。但し、bに含まれるx、又は、zはワイルドカードとして扱われます。

結合演算子

（concatenation operators)


• 結合演算子は{ }の形式を持つ演算子で値を連結します。{}の中に記述する式はビット長が定まっていなければなりません。例えば、{ a, 1’b0 }は正しい記述ですが、{ a, ‘1 }は正しくありません。

• このオペレータはアレイ結合としても使われる事があります。アレイの初期化には、{1,2,a[1:2],4}の様な使い方が出来ます。或いは、文字列の結合にも使われます。

insideオペレータ

（set membership operator)


• SystemVerilogには式の値が集合の中に含まれるかを調べる機能があります。insideオペレータは、式の値が集合に含まれれば1を戻します。含まれなければ0を戻します。但し、式の値が集合に含まれず、しかも、途中の比較でxが得られた場合、結果はxとなります。

• 整数型の比較にはワイルドカード比較演算子 ==? が使用されます。inside

オペレータの左辺は式で、右辺は{}の中に式、又は、区間をカンマで区切って書きます。右辺はopen range listと呼ばれます。


（使用例）


ビット・ストリーム・オペレータ

（<<、>>)


• ビット位置を反転する、又は、バイト・スワップ等の操作を簡単に行なえるオペレータです。右辺に使用されたときはpack操作になり、左辺に使用された時はunpackの操作となります。使い方は、次の様になります（[1]）。

• stream_operatorは <<、又は、>>です。

• >> は左から右へビットを取り出します。<< はその逆方向です。slice_sizeは一度に取り出すビット数を示します。標準値は1です。

• 例えば、{ << { 4’b1110 } } は、右から1ビットずつ取り出すので、4’b0111 になります。一方、 { << 2 { 4’b1110 } } は、右から2ビットずつ取り出すので、4’b1011となります。

• オペレータ >> は左からビットを順に取り出す為に、>> ではslice_sizeを指定する必要はありません。

streaming_concatenation ::=

{ stream_operator [ slice_size ] stream_concatenation }

stream_operator ::= >> | <<

ビット・ストリーム・オペレータ

（使用例）


パートセレクト

（part-select)


• 連続した複数ビットにアクセスする為には次の様にパートセレクトを使用します。

• msb_expr及びlsb_exprは何れもコンスタントの式でなければなりません。従って、この形式のパートセレクトはコンパイル時に決定します。

• コンスタントではない式を使用してパートセレクトを構成する事も出来ます。その方法は、インデックス付きパートセレクト（indexed part-select）と呼ばれます。インデックス付きパートセレクトは以下の様な使用法になります。

• base_exprは整数型の式ですが、widthは正の整数（定数）でなければなりません。up_vectはビット位置base_exprから上方向にwidthビット数アクセスします。down_vectはビット位置base_exprから下方向にwidthビットだけアクセスします。

vect[msb_expr:lsb_expr]

up_vect[base_expr +: width]

down_vect[base_expr -: width]

インデックス付きパートセレクト

（使用例）


タグ付きメンバーの操作


• 設定した値と参照する値の正当性をチェックをする為の機能です。タグの付いたユニオンのメンバーは以下のシンタックスに従い操作します。

• この式でメンバー（member_identifier）に値を設定すると、タグはメンバー名称となります。他のメンバー名を参照するとタグに関するエラーとなります。

tagged member_identifier [ expression ]

タグ付きメンバーの操作

（使用例）




• プログラミングをする為の基本的な機能を紹介しました。

• イベント制御は必ず使用する大切な機能です。エッジ・センシティブ制御とレベル・センシティブ制御の差を理解する事は本質的です。検証分野では、実行速度として両者の差が歴然として現れます。

• Forkブロックは並列処理を書く為の基本手段ですが、前述した様に、細心の注意が必要です。 Forkブロックではautomatic変数を使用する事は基本です。また、ブロックをシンプルに記述する事が肝心です。

タスク及びファンクションは共通処理を一つのグループに纏める為の手段です。

両者の基本的な差は、シミュレーション時間を消費するか否かです。消費する場合にはタスクを使用し、消費しなければファンクションを使用します。

第６章

タスクとファンクション (Tasks and Functions)


ポート・リスト


• タスク及びファンクションにはポート・リストを指定する事が出来ます。ポート・リストはポートのリストですが、一定のルールが適用されます。

• 最初のポートの方向が省略されると、input が仮定されます。

• 最初のポートにデータ・タイプが指定されていない場合、データ・タイプはlogicになります。

• ポートの方向が指定されていてデータ・タイプの指定が無い場合、データ・タイプはlogicになります。

• それ以外の場合は、直前のポートのデータ・タイプを仮定します。

ポート・リスト

（例）


• 以下の記述で、ポート a、及び、bのデータ・タイプは logic です。また、bの方向は input です。

• ポートの方向、及び、タイプを省略する事が出来る為、将来、ポートを追加、又は、挿入する場合には注意が必要です。間違った指定をしても、コンパイル・エラーの対象にならない場合があります。

ファンクションの制限

（重要）


• ファンクションには以下の制限が適用されます。

ファンクションはシミュレーション時間を消費せずに戻らなければなりません。具体的には、遅延（#、##）、fork-join、fork-join_any、wait、wait_order、expect等を使用する事は出来ません。

ファンクションからタスクを呼び出す事は出来ません。

• 最初の制限によると、一見、ファンクションではタイミング制御をする事が出来ない様に思えますが、それは誤解です。制限にはfork-join_noneが含まれていません。fork-join_noneは時間を消費しないのでファンクション内で自由に使用する事が出来ます。

値を戻さないファンクション


• ファンクションは式の値を計算をする事が本来の機能ですが、SystemVerilogはその機能を一般化しました。即ち、 SystemVerilogでは値

を戻さないファンクションを定義する事が出来ます。例えば、以下の様に定義します。

• この機能により、ファンクションをタスクの様に使用する事が出来ます。従って、ファンクションからタスクを呼び出す事が出来ないという制限が多少緩和されています。

値を戻さないファンクション

（使用例）


void functionをタスクの様に使用。

void function

引数に標準値を指定する方法


• タスク、及び、ファンクションに引数がある時、多くの場合、引数には標準的な値が考慮されています。

• 標準値以外を指定する場合が少なければ、タスク、及び、ファンクションを呼ぶ際に値を設定せずに済ませる様に設計するのが常です。SystemVerilog

では、それが可能です。

• 下記の例に於いて、checkの呼び出しで left に対して値が指定されていなければ、left には0が仮定されます。同様に、right に対して値が指定されなければ -1 が仮定されます。必須なパラメータはアレイ名称だけです。

サブルーティンの呼び出し

（名称に依るバインディング）


• サブルーティンを呼び出す際、名称でバインドする事が出来ます。

• 例えば、以下の様に呼び出す事が出来ます。この方法に依れば、サブルーティンcheck()のポート・リストにポートの順序変更が発生しても、正しく動作します。

引数としてのアレイ

（その１）


• アレイを引数に指定する事が出来ます。値でパスする場合、タスク、及び、ファンクションが呼ばれると、アレイのコピーが行われます。

• 引数としてダイナミック・アレイを指定すると、実引数として、固定サイズのアレイ、ダイナミック・アレイ、及び、キューを指定する事が出来ます。

• 引数としてダイナミック・アレイを使用すると適用能力が高まります。

引数としてのアレイ

（その２）


• この例では、固定サイズのアレイ、ダイナミック・アレイ、キューをダイナミックアレイに引き渡しています。

ダイナミック・アレイで受けている。アレイaへのコピーが発生する。

ファンクション内でタイミング制御を行う方法


• fork-join_noneを使用するとfunction内でもタイミング制御をする事が出来ます。

C/C++とのインターフェース


• SystemVerilogは、他の言語とのインターフェース（DPI）機能を備えています。ここでは、C/C++とのインターフェースを前提として、使用法を解説します。

• C/C++で定義されたルーティンを使用する為には、import文を使用します。SystemVerilogで定義したルーティンをC/C++で使用する様にする為には、export文を使用します。何れの場合も、使用する前に宣言しなければなりません。

import及びexportの例


• 以下の様にルーティンを宣言します。

• importの場合には、この宣言があれば、ルーティンを使用する事が出来ます。exportの場合には、ルーティンの実体をSystemVerilogで定義しなければなりません。



• この章は、検証作業で必要になるタスク、及び、ファンクションの要点を纏めました。特に、ポートに標準値を設定する機能と、呼び出し時に名称でバインドする機能は実践で役立ちます。

• 値を戻さないファンクションを記述する事が出来る機能はファンクションの適用範囲を拡大させます。実際問題として、タスクの必要性は殆ど無くなります。

クロッキング・ブロックは、クロックに同期して変化する信号のタイミング（skew）を設定する構文です。タイミングを設定すると、クロックのイベントに同期して、指定したタイミングで信号値が変化します。クロッキング・ブロックにより、個々の信号の変化を管理する必要は無くなります。

本章では、クロッキング・ブロックの基本機能を紹介します。

第７章

クロッキングブロック


クロッキング・ブロック（clocking blocks)


• クロッキング・ブロックは、クロックに同期して変化する信号のタイミング（skew）を設定する構文です。

• クロッキング・ブロックはキーワードclockingとendclockingを使用して記述します。clockingの前に、default、又は、globalを付ける事も出来ます。例えば、シンタックスは以下の様になります（[1]）。

• clocking_eventにはクロッキングが動作するイベントを指定します。例えば、@(posedge clk)の様に指定をします。

• イベントには、posedge、negedge、及び、edgeを使用する事が出来ます。edgeはDDR (Double Data Rate)の意味です。

clocking_declaration ::=

[ default ] clocking [ clocking_identifier ] clocking_event ;

{ clocking_item }

endclocking [ : clocking_identifier ]

| global clocking [ clocking_identifier ] clocking_event ;

endclocking [ : clocking_identifier ]

default clocking


• defaultを付加すると標準クロッキング（default clocking）となります。

• クロッキング・イベントが必要なSystemVerilog機能に於いてクロッキングの指定を省略すると、標準クロッキングが採用されます。

• 例えば、アサーションのsequenceやpropertyでdefault clockingを使用します。default clockingを定義すると、sequenceやpropertyの記述からクロッ

キング・イベントを省略する事が出来る為、より抽象度の高い記述をする事が出来ます。

最も簡単なクロッキング・ブロック

（重要な知識）


• 最も簡単なクロッキング・ブロックは以下の様になります。

• 実は、これだけでも意味があります。@(posedge clk)の代わりに、簡単に

@(cb) と書く事が出来ます。タイピング負荷が軽減します。

• 更に、クロッキング・ブロック内のposedgeをnegedgeに変えるだけで

@(cb) は @(negedge clk)に変わります。

• クロッキング・ブロック名称を随所で使用する為、一般に、クロッキング・ブロック名称を出来るだけ短く定義する事が勧められています。

クロッキング・スキュー（clocking skew）（その１）


• クロッキング・ブロックでは信号に方向（input、output、inout）を指定する事が出来ます。ここで、inoutはinput及びoutputを意味します。

• スキューは、クロックのイベントからどれだけの時間間隔で信号値のサンプリングが行われるか、又は、値が設定されるかを意味します。

• input信号に対して、時間間隔は負の値として理解されます。即ち、クロッキング・イベントが起こる前にinput信号のサンプリングが行われます。output

信号のスキューはクロッキング・イベントの後の時間間隔を意味します。

クロック・イベント

input skew

output skew

クロッキング・スキュー（clocking skew）（その２）


• 例えば、次の様に指定する事が出来ます。

• defaultを使用して、全ての信号に対して同時にスキューをしています。この指定によると、@(posedge clk) のイベントが起こると、次の @(negede

clk)でoutput信号に値が設定されます。逆に言えば、@(posedge clk) のイベントが起こった時、output信号の値は直前の@(negede clk)で設定された値を示しています。

クロッキング・スキュー（clocking skew）（その３）


• クロッキング信号を個別に指定する為には、以下の様に記述します。

• ローカル・ポートだけでなく外部から信号値を取り入れる事もできます。

• スキューを指定する場合、定数でなければなりません。

クロッキング・スキュー（clocking skew）（その４）


@12: b=1

@32: b=0

@72: b=1

実行結果

サイクル・ディレー（cycle delay)


• サイクル・ディレーはクロッキング・イベントが指定回数起こるのを待つ制御です。例えば、

• は、3クロック・サイクル後に a = b を実行します。ここで、サイクル・ディレーは標準クロッキング（default clocking）で定めます。

• アサーションでもサイクル・ディレーを使用します。この場合は、クロッキング・イベント（leading clock）がproperty、又は、sequenceで指定されます。例えば、

• に於いて、クロック・サイクル ##2 はproperty p_abの @(posedge clk)により決定されます。

サイクル・ディレー（cycle delay)

（使用例）




• クロッキング・ブロックは、簡単に使える便利な機能です。検証作業には欠かせない重要な手段です。

並列して実行しているプロセス間で同期を取る手段として、event、mailbox、及び、semaphoreがあります。この章では、それらの持つ機能を解説します。

プロセス間交信機能は実践で要求される重要な知識です。

第８章

プロセス間交信機能 (Interprocess Synchronization and Communication)


セマフォ（semaphores）


• セマフォは、複数のプロセスが共有する資源にアクセスする為の排他制御機能です。セマフォはSystemVerilogのクラスとして実現されています。従って、クラス・ハンドルを定義して、ハンドルにnewオペレータを使用してオブジェクトを割り当てる手順を取ります。例えば、次の様にして使用します。

• 概念的には、セマフォは一定数のキーを保有するバケットです。利用可能なキーが存在する限り共有資源にアクセスする事が出来ます。キーが存在しない場合、キーが利用可能になるまでプロセスは待たなければなりません。

• セマフォはロック機能を有するだけのシンプル性があります。共有するデータに関しての情報は一切必要ありません。セマフォから継承（extends）して新たなクラスを定義する事も可能です。継承により、メソッドgetを独自に定義する事が出来ます。

セマフォのメソッド


method 意味

function new(int keyCount = 0 ); 指定した数のキーを持つセマフォを作成します。バケットは指定されたキーの数で初期化されます。

put()で戻すキーの数がget()したキーの数よりも多い場合、キーの数がkeyCountを超える現象が起こります。

function void put(int keyCount = 1); 指定した数のキーをセマフォに戻します。戻すキー数の標準値は1です。もし、利用可能なキーを待って

いるプロセスに十分な数のキーを戻す場合には、その待ち状態のプロセスの実行が再開します。

task get(int keyCount = 1); 指定した数のキーを取得します。指定数のキーが存在すれば呼び出しているプロセスの実行は継続します。もし、指定数のキーが存在しない場合には、呼び出しているプロセスの実行がブロックされ、キーの取得が可能になるまで待ち状態になります。

function int try_get(int keyCount = 1); 指定した数のキーを取得します。但し、呼び出しているプロセスをブロックしません。もし、指定数のキーが存在すれば正の整数を戻します。

もし、指定数のキーが存在しない場合には0を戻します。

セマフォのメソッド

（使用例）


次の様な結果を得ます。

メール・ボックス（mailboxes）


• メール・ボックスはproducerとconsumerをもつFIFOリストです。FIFOリストは限られたサイズ、又は、無限のサイズを持つ様に定義する事が出来ます。

• FIFOリストがフルの時は、producerはデータを書き込む事は出来ません。FIFOリストが空の場合、 consumerは待たなければなりません。

• セマフォと同様に、メール・ボックスもSystemVerilogのクラスとして実現されています。ハンドルにnewオペレータを使用してオブジェクトを割り当てる手順を取ります。例えば、次の様にして使用します。

• producerが書き込んだデータの型と、consumerが取り出すデータの型が一致しない場合、取り出しが正しく行えない可能性があります。

producer consumer

mailbox

(FIFO)

メール・ボックスのメソッド


method 意味

function new(int bound = 0); メール・ボックスを割り当てます。boundが0であるとメール・ボックスは無限のサイズを持ち、producerは決してブロックしません。boundが0でない場合、メール・ボックスは有限のサイズとなります。

function int num(); メール・ボックスに存在するメッセージ数を戻します。戻す値は、次のget、又は、putまで有効な一時的な値です。

task put( singular message); メッセージをメール・ボックス（FIFO）に書き込みます。メール・ボックスがフルの場合、書き込むプロセスは、メール・ボックスに空きが出来るまで待ち状態に入ります。

function int try_put( singular message); メッセージをメール・ボックス（FIFO）に書き込みます。但し、ブロックしません。

メール・ボックスに空きがある場合、メッセージを書き込み、正の整数を戻します。

メール・ボックスがフルの場合、0を戻します。

task get( ref singular message ); メール・ボックスから1メッセージを取り出します。

メール・ボックスが空の場合、取り出すプロセスは、メールが届くまで待ち状態になります。

function int try_get( ref singular message ); メール・ボックスから1メッセージを取り出します。但し、ブロックしません。

メール・ボックスが空の場合、0を戻します。

メッセージを正しく取得できれば正の整数を戻します。正しく取り出せない場合は、負の整数を戻します。

task peek( ref singular message ); メール・ボックスから1メッセージをコピーします。

メール・ボックスが空の場合、コピーするプロセスは、メールが届くまで待ち状態になります。

function int try_peek( ref singular message ); メール・ボックスから1メッセージをコピーします。但し、ブロックしません。

メール・ボックスが空の場合、0を戻します。

メッセージを正しくコピーできれば正の整数を戻します。正しくコピー出来ない場合は、負の整数を戻します。

メール・ボックスのメソッド

（使用例）


右の様な結果を得ます。

パラメータ化したメール・ボックス（parameterized mailboxes）


• メール・ボックスのデータに関するproducer/consumerのデータ型不一致は

実行時の問題を引き起こします。これを避ける為に、メール・ボックスにタイプを付加する事が出来ます。

• この形式のメール・ボックスを使用すると、メール・ボックスの型がコンパイル時に明確になる為、producer/consumer のデータ型の一致をコンパイル時に確認する事が出来ます。

• 但し、エラーを検出する能力は使用するコンパイラーに依存します。

パラメータ化したメール・ボックス

（使用例）


• コンパイル時にデータ型の不一致を検出する事が出来ます。

名称付きイベント（named events)


• eventデータ型を持つ変数は名称付きイベントとなります。名称を使用してイベントの操作を行います。

• イベントが発生するまで、実行をブロックする事が出来ます。イベント待ちは以下のシンタックスを使用します。

• イベント待ちのプロセスをどこかで解除しなければなりません。イベントの解除（trigger）には次のシンタックスを使用します。

• イベント制御を使用した例を多く示してあるので、ここでは例を省略します。

• 重要な機能として、triggeredメソッドがあります。第１章を参照して下さい。

@ hierarchical_event_identifier

-> hierarchical_event_identifier ;

引数としてのイベント・オブジェクト

（比較的知られていない機能）


• SystemVerilogではタスク、又は、ファンクションの呼び出しでイベント・オブジェクトをパラメータとして引き渡す事が出来ます。

• 例えば、次の様な記述をする事が可能です。

• 実践で遭遇するイベント解除は複雑になる傾向があり、タスクに纏め上げる必要が出て来ます。イベント・オブジェクトをパスする機能を記憶しておくと役に立つ時が出て来ます。

• 尚、タスクだけでなくファンクション内でも、イベント解除（->ev）をする事が

出来ます。

引数としてのイベント・オブジェクト

（使用例）


下の様な結果を得ます。

wait_order文


• 指定した順序にイベントが発生するまで、呼び出しているプロセスをブロックします。イベントの発生が指定した順序に従わない場合、実行時にエラーとなります。シンタックスは以下の様になります。

• action_blockに文を書く事が出来ます。action_blockには条件を満たした場合、及び、満たさない場合の状況に対応した処理を書きます。

• 順序に従って起きたイベントが再び起きてもエラーにはなりません。

wait_order ( hierarchical_identifier { , hierarchical_identifier } )

action_block

wait_order文

（使用例）


下の様な結果を得ます。

イベント資源の解放


• イベント・ハンドルにnullを設定するとハンドルとイベント制御の関連を切断し

ます。もし、イベントの解除を待っている対象が無い場合、イベントで使用されている資源が解放されます。例えば、以下の様にして使用します。

• 但し、@evで待っているプロセスが存在すると、イベント待ち状態にあるプロセスは決して終了しません。

• nullイベントに対してイベント待ちをすると、結果がどの様になるか分かりません。例えば、次の様な場合、結果の予測が付きません。

イベント資源の解放

（使用例）


ev1のイベント待ちが解除されずにシミュレーションが終了します。

別名（alias）とイベントの比較


• イベント・ハンドルに代入文を適用する事でイベントの別名を定義する事が出来ます。例えば、以下の様にすると、ev1とev2が同じイベントとなります。

• イベント変数同士の比較にオペレータ == 及び、!= を使えます。例えば、以下の様にして比較する事が出来ます。

別名（alias）とイベントの比較

（使用例）





• プロセス間交信機能として、event、semaphore、mailboxの要点を解説しま

した。これらの制御機能は、幅広い応用面を持っています。この章で示した例は、典型的な例だけです。実践では、他の機能と組み合わせて有効なプロセス同期機能に仕上げる必要があります。

• UVMでは、ここで紹介したevent、semaphore、mailboxを使用しています。UVMのソース・コードを勉強すると、プロセス間交信機能を理解する助けになると思います。

SystemVerilogには、効率よく、且つ、効果的にランダム・スティムラスを生成する機能があります。制約を付けてランダム・スティムラスを生成する事により、目的に即したテスト・データを確実に準備する事が出来ます。

現代の検証手法では、ランダム・スティムラスを生成する方法はトランザクション生成の中心的な役割を担っています。この章で紹介する機能は実践で必要になります。

第９章

ランダム・スティムラスの生成（Constrained Random Value Generation）


ランダム・スティムラスの生成

（その１）


• 生成の仕方は直接的で明確です。テスト・データに乱数発生の情報を付加するだけで準備が終了します。後は、乱数を発生すべきタイミングを選び乱数を発生させます。例えば、次の様にしてパケットを準備します。

• クラスには乱数を発生する関数randomize()が定義されているので、次の様にして乱数を発生する事が出来ます。

• 関数randomize()はaddr及びdataに自動的に乱数を割り当てます。一方、stateには乱数発生情報が付加されていない為、乱数は割り当てられません。

制約によるランダム・スティムラスの生成

（その２）


• 前例では制約を付けていない為、意味のないテスト・データが生成される可能性があります。そこで、次の様にして制約を追加する事が出来ます。

• この制約によりaddrは常に4の倍数となる様に乱数が割り当てられます。

• dataは32ビットなので、制約なしで乱数を発生させても余り意味がありませ

ん。然し、どの様な制約を定義するかはテスト・ケースに依存する可能性があります。この様な状況に於いては、クラスの特性を利用する方法が得策です。即ち、クラスの継承をして制約を追加します。

制約によるランダム・スティムラスの生成

（その３）


• クラスの継承は以下の様になります。

• クラスの継承なので、small_packet_tには制約boundary_conditionも有効になっています。実は、もう少し一般的にする事が出来ます。small以外に、medium、及び、largeに備える事で応用が広くなります。例えば、次の様にします。

ランダム変数（random variables）


• ランダム変数はrand、又は、randcの修飾子を付けて宣言します。これらの修飾子をアレイ変数にも適用する事が出来ます。

• ランダム変数はrandomize()関数により乱数が割り当てられます。

• ダイナミック・アレイをランダム変数に指定すると、アレイ・サイズもランダムに決定されます。アレイ・サイズに制約を設定しないと膨大なアレイが生成されて、殆どシミュレーションが終了しない状況に陥ります。必ず、アレイ・サイズに制約を設定する事が必要です。

rand と randc


• randは単純に乱数を割り当てる為の宣言です。例えば、次の様に設定すると、sizeには0から255の間の数がランダムに割り当てられます。bit型は符号なしである事に注意して下さい。

• randcはrandom-cyclicの意味の修飾子です。詰まり、ランダムに順列を作ります。例えば、次の様に定義すると、

• randomizerは初期の順列、例えば、

• を作り、randomize()の呼び出しに対して値を順に引き渡します。最後の2を渡すと、次にrandomize()が呼ばれると、また新たな順列を作成して、同様の事を繰り返します。

0312

rand と randc

（使用例）



最初の順列は2013です。

二番目の順列は1302です。

制約（constraints）


• 単に乱数を発生するだけでは意味のあるテスト・データを作成する事は出来ません。制約を付ける事が必要になります。但し、複雑過ぎる制約を与えると、制約ソルバーに負担がかかりシミュレーションのパフォーマンスが低下します。検証目的に即した適切な制約を設定する事が大切です。

• 制約のシンタックスは以下様になっています。

• キーワードconstraintの後に制約名称（constraint_identifier）を記します。そして、{} の中に制約を列挙します。

• ここで、制約名称は必須です。乱数発生機能を一時的にオフにしたりする制御にこの名称を使用する事が出来ます。

[ static ] constraint constraint_identifier constraint_block

constraint_block ::= { { constraint_block_item } }



• このオペレータは以前にも出てきましたが、ここでは乱数発生の制約として使用します。insideオペレータの左辺に式を書き、右辺に値域を {} の中に記述します。{} の中には個別に値を書くか、又は、区間を指定して値を指定します。例えば、{ 1, 2, [10:20] }の様に指定します。左辺が右辺を満たす事が制約となります。

• 特徴的なのは、値域として変数を指定する事が出来る事です。例えば、以下の様に値のリストを定義する事が出来ます。

• 但し、定数の値域と異なり、制約ソルバーにはより難易度の高い問題となる事を理解しておく必要があります。即ち、a、及び、bに関して適切な制約を与えないと、ソルバーが制約問題を解けない可能性もあります。


（使用例：constant）




（使用例：non-constant）




（アレイを使用した簡略指定法）


• アレイを使用すると、値域に値を指定する事を避ける事が出来ます。非常に便利な記述方式です。

• 下記の様に、insideオペレターの右辺が簡略化されます。

distオペレータ

（その１）


• 乱数が出現する頻度を制御する為のオペレータです。insideオペレータでは、

指定されている値は平等に選択される可能性があります。時として、ある数は他の数よりも多く出現して欲しい場合があります。その様な状況に於いて使用するオペレータです。

• distオペレータはinsideオペレータと殆ど同じシンタックスです。違いは、値の

後に重みを定義する部分にあります。シンタックスを示すと以下の様になります。

• 例えば、次の様にして制約を記述します。

dist_item ::= value_range [ dist_weight ]

dist_weight ::=

:= expression

| :/ expression

distオペレータ

（その２）


• := は重さ（weight）を割り当てます。区間に属する値にそれぞれ同じ重さが

割り当てられます。一行目の[1:3]のそれぞれ1~3には重さ20が割り当てられます。従って、a==0には割合10/70が割り当てられます。a==1には割合20/70が割り当てられます。

• :/ は重さを分配します。0 :/ 20 は一つの数字に重さ20を割り当てます。

[1:3] :/ 30は三つの数全体に重さ30を割り当てます。従って、b==0には割合20/50が割り当てられます。また、b==1には割合10/50が割り当てられます。

値割合値割合

a == 0 10/70 b == 0 20/50

a == 1 20/70 b == 1 10/50

a == 2 20/70 b == 2 10/50

a == 3 20/70 b == 3 10/50

distオペレータ

（その３）


値割合値割合

a == 0 40/220 b == 0 40/100

a == 1 60/220 b == 1 20/100

a == 2 60/220 b == 2 20/100

a == 3 60/220 b == 3 20/100

uniqueオペレータ


• 同じ値を割り当てられない様にする為の制約です。正式なシンタックスは以下の様になります。

• 具体的には、次の様に使用します。

• この場合、a、b、cには異なった値が設定される様に乱数を割り当てます。

uniqueness_constraint ::= unique { open_range_list }

uniqueオペレータ

（使用例）



implication（->）


• ある条件が成立した場合に満たすべき制約を与える為のオペレータです。正式なシンタックスは以下の様になっています。

• expressionが真であれば、右側の制約を満たさなければなりません。但し、expressionが偽の場合には、右側の制約はdon’t careになります。

• 具体的には、次の様に使用します。

• これは、もし a == bであれば、c > 100でなければならない事を意味します。但し、a != bの場合には、cに関する制約はありません。

expression –> constraint_set

implication（->）（使用例）



foreach


• アレイ要素に乱数を発生する時、foreach文を使用してアレイ要素に制約を定義する事が出来ます。正式なシンタックスは以下の様になっています。

• ビヘイビア記述で使用するforeach文と同じ様な構造を持っています。例えば、次の様に使用します。

• この場合、全てのアレイ要素は4の倍数に設定されます。

foreach ( ps_or_hierarchical_array_identifier [ loop_variables ] )

constraint_set

loop_variables ::= [ index_variable_identifier ]

{ , [ index_variable_identifier ] }

foreach

（使用例）


この例では、ar[0] < ar[1] < … < ar[n]となる様にアレイarに値を設定します。

foreach

（使用例解説）


• ダイナミック・アレイに関する例です。制約C1でアレイ・サイズを決定しています。非常に大切な制約です。

• 制約C2でアレイ要素の制約をしています。制約C2はアレイ要素を上昇順にソートする様に制限をしています。

• 実行結果は以下の様になります。

foreach

（array of fixed size）


foreach

（array of fixed size）


• アレイ・サイズが固定されている例を示しました。実行結果は以下の様になります。

乱数決定順序（solve a before b）


• ランダム変数同士に依存関係がある場合には、乱数決定順序を規定する事が出来ます。一般に、依存関係がある場合、順序規定が必要になります。規定をしないと、ソルバーが問題を解く事が出来ない場合が生じます。正式なシンタックスは以下の様になっています。

• 例えば、次の様にして使用します

solve solve_before_list before solve_before_list ;

solve_before_list ::= solve_before_primary { , solve_before_primary }

solve_before_primary ::= [ implicit_class_handle . | class_scope ]

hierarchical_identifier select

乱数決定順序

（使用例）


• この例では、変数dは変数sに依存しています。もし、同時に値を決定しようとするとdに関する制約を解けない場合が存在します。解けたとしても、多大の

計算時間が必要です。効率良い乱数発生をする為には、決定順序を規定する方法は効果的です。

乱数発生関数


• クラスで使用する事が出来る乱数発生に関するメソッドには以下の関数があります。

関数意味

virtual function int randomize(); 乱数発生に成功すると1を戻します。失敗すると0を戻します。

function void pre_randomize(); randomize を呼び出すと、最初にpre_randomizeが呼び出されます。ここで初期値設定等をする事が出来ます。virtual関数ではありませんが、virtual関数の様に動作します。

function void post_randomize(); randomizeが乱数発生を終了すると自動的に

この関数を呼び出します。ここで後処理をする事が出来ます。virtual関数ではありませんが、virtual関数の様に動作します。

乱数発生関数

（使用例）


• pre_randomize()は呼ばれた試行回数をプリントし、post_randomize()は発生した乱数をプリントします。

実行時に制約を定義する方法

（in-line constraints）


• 制約を実行時に定義（追加）する事が出来ます。その為には、withクローズを使用します。withクローズ内ではクラスのメンバーを直接参照す事が出来ます。

• ここで、 withクローズはクラス外で使用されます。それにも拘わらず、クラス内のメンバーを直接参照する事が出来る強力な機能です。


（使用例）


• １８行目がin-line制約です。クラス内の制約の他に、この制約が課されます。


（使用例の実行結果）


• 前半では、 a+b+c==32の制約だけですが、後半では (a < b) && (b < c) の制約を追加しています。

• クラスの外からメンバーを直接参照できるのは強力な機能です。実行結果は以下の様になります。

ランダム変数の制御


• rand_modeメソッドを使用してランダム変数をactive、又は、inactiveにする事が出来ます。

• メソッドは以下の様に定義されています。

メソッド意味

task object[.random_variable]::

rand_mode( bit on_off );

ランダム変数を active、又は、inactiveにします。1を指定するとactiveになります。

.random_variableを省略すると全ての変数に適用されます。

function int object.random_variable::

rand_mode(); ランダム変数の状態を戻します。activeであれば1をinactiveであれば0を戻します。

ランダム変数の制御

（使用例）


制約の制御


• ランダム変数の制御と同様に制約をactive、又は、inactiveにする事が出来ます。

メソッド意味

task object[.constraint_identifier]::

constraint_mode( bit on_off );

制約をactive、又は、inactiveにします。1を指定するとactiveになります。

.constraint_identifierを省略すると全ての変数に適用されます。

function int

object.constraint_identifier::

constraint_mode();

制約の状態を戻します。activeであれば1をinactiveであれば0を戻します。

制約の制御

（使用例）


randomize関数によるランダム変数の制御


• rand_modeメソッドを使わずにランダム変数をactive、又は、inactiveにする制御をする事が出来ます。

• randomizeを呼ぶ出す際に、引数として与えた変数だけがランダム変数となります。下記の例を参照して下さい。


（使用例）


std::randomize()


• クラスを用いずに乱数を発生する事が出来ます。

• std::randomize()関数の引数として与えると、乱数が割り当てられます。

• 制約条件をwithクローズで指定する事が出来ます。

std::randomize()

（使用例）



システム関数とメソッド


• 以下の様な関数があります。単に乱数を発生するだけであれば、クラスを定義せずに以下の関数を呼ぶ事が出来ます。乱数に制約が無い場合にはこれらの方法を利用する方が得策です。

メソッド意味

function int unsigned $urandom

[ (int seed ) ] ;

32ビットの符号無し整数をランダムに生成します。seedを与える事も出来ます。

function int unsigned $urandom_range

( int unsigned maxval,

int unsigned minval = 0 );

指定した範囲内の整数にある乱数を発生します。もしmaxval < minval

であれば、両者はスワップされます。例えば、$urandom_range(2,10)と

$urandomrange(10,2)は同じです。

function void srandom( int seed ); 乱数発生器のシードを定義します。

function string get_randstate(); 乱数発生器の状態を戻します。

function void set_randstate

( string state );

乱数発生器の状態をセットします。

システム関数とメソッド

（使用例）


• $urandom()は単に乱数を生成するだけです。一般に、大きな整数が割り当てられます。$urandom_range() 関数を使用して、16と32の間の整数を発生しています。以下の結果を得ます。

ストラクチャ


• クラスのメンバーにストラクチャが定義されていて、ストラクチャのメンバーにrand/randc修飾子が付いていると、ストラクチャのメンバーに乱数が割り当てられます。

ストラクチャ

（使用例）


ストラクチャ




条件の否定 !(expression inside { set })


• inside オペレータは便利なオペレータですが、時には、その否定形が必要な事があります。

• 例えば、2でも4でも8でも10でも20でもない正の二桁以内の整数を求める時、条件式は複雑になります。この様な時、insideオペレータに否定形を使う事が出来ます。この場合、次の様になります。

条件の否定 !(expression inside { set })

（使用例）


• aは6、11、又は、12の何れかです。実行結果は以下の様になります。

キューに乱数を発生


• キューに対しても乱数を発生する事が出来ます。但し、キューのサイズに関する制約が必要です。

• キューは伸縮自在なアレイである事を思い出せば、キューに乱数を発生する事が出来る事を理解出来ます。

キューに乱数を発生

（使用例）



チェッカーとしての制約

（in-line constraint checker)


• クラスにランダム変数が定義されていなければ、randomize() 関数は乱数を

生成しませんが、制約のチェックは必ず行われます。この機能を利用するとデータの無矛盾性を達成する事が出来ます。


（その１）



（その２）


• この例のクラスのメンバーにはランダム変数はありませんが、制約を与えています。

• aは4の倍数で、bは1から5の間の整数でなければなりません。randomize

関数を呼ぶと制約を満たすかチェックする事が出来ます。実行結果は以下の様になります。


（ランダム変数を含む場合）


• クラスがランダム変数を含む場合でも制約をチェッカーとして利用する事が出来ます。

• この必要性は度々起こります。例えば、randomize() を呼び出して乱数を割

り当てた後に、一部のランダム変数の値を変更したとします。新しい値の状態が制約を満たしている事を確認しなければなりません。どの様にしたら確認できるのでしょうか？尚、randomize()を再び呼ぶと新たな乱数が発生してしまいます。

• 解答はrandomize(null)と呼び出す事です。パラメータとしてnullを渡すと、randomizer はランダム変数をノンランダム変数として扱います。これにより、制約チェッカーとしての機能だけを遂行します。


（ランダム変数を含む場合の使用例）



制約をテストケース毎に指定する方法


• 制約をクラスの外部に定義する事が出来ます。この機能を使用する事により、制約条件がテストケース毎に異なる場合に効率良く作業を進める事が出来ます。

• 手順は以下の様になります。

制約名称だけを与えた空の制約を宣言する。

クラスの外部で制約の内容を定義する。


（その１）



（その２）


• クラス内に制約setup_sizeが宣言されていますが、内容が定義されていません。その内容はテストベンチtestで定義されています。


randcase


• SystemVerilogは、case文をランダム化した機能randcase文を持っています。この文はランダムにcase-itemを選択して実行します。一般形式は以下の様になっています。

• expressionは0以上の整数値を示す式で、case-itemが選択される重み（weight）を定義します。全てのcase-itemの重みの和でcase-itemの重みを割った値がそのcase-itemが選択される確率となります。例えば、

• 最初のcase-itemが選択される確率は 3/8=0.375となります。重みが0のcase-itemは決して実行されません。expressionは定数でなくても構いません。

randcase randcase_item { randcase_item } endcase

randcase_item ::= expression : statement_or_null

randcase

（使用例）




• 現代の検証手法は、CRT (Constrained Random Tests)をベースしています。この章では、CRTに必要な殆どの機能を解説しました。

• クラスに定義した制約はサブクラスでも有効です。段階的に制約を定義する事により、効果的な検証を行なう事が出来ます。

• アレイをランダマイズする時には、アレイ・サイズが過大にならない様に制約を定義する事が必要です。

• キューはアレイの一種なので、キューをランダマイズする事が出来ます。

ファンクショナル・カバレッジは仕様のどれだけの部分が検査されたかを示す指標です。デザインを検証する意味ではなく、寧ろ、検査者、又は、検査計画の進捗度を示します。ゴールは、勿論、100%のカバレッジです。

この章では、ファンクショナル・カバレッジの基本的な機能を解説します。

第１０章

ファンクショナル・カバレッジ (Functional Coverage)


ファンクショナル・カバレッジ


• ファンクショナル・カバレッジは仕様を基にして確認をします。確認を漏れなく、重複が無い様に進める必要があります。例えば、

• に於いて、portには乱数が割り当てられます。検査でportが0から7の全ての値をとればカバレッジは100%となりますが、一部の値を取らない場合、乱数発生に制約を追加して取り得る値を拡張しなければなりません。

• 従って、乱数を発生した場合、実際に発生した値を計測する必要があります。ファンクショナル・カバレッジはその計測機能を備えています。

• SystemVerilogファンクショナル・カバレッジでは、信号値だけでなく信号の値の遷移（transitions）の計測も行う事ができます。

• SystemVerilogでは、ファンクショナル・カバレッジの仕様をソース・コード中に記述する事が出来ます。しかも、記述されたカバレッジ仕様はシミュレータにより実行されます。

カバレッジ・モデルの定義（covergroup)


• SystemVeriog covergroupはカバレッジ仕様を定義する為の構文です。実際には、クラスと同じ様にデータ・タイプです。covergroupには以下の機能を含む事が出来ます.

カバレッジ情報を取得するタイミングを示すクロック・イベント

カバー・ポイント

クロス・カバレッジ

カバレッジ・オプション

• covergroupを、package、module、program、interface、checker、及び、classの中で使用する事が出来ます。

• classの中にcovergroupを定義する方法が最も一般的です。しかも、それは最も便利な方法です。

カバレッジ・モデルの定義

（その１）


• 例えば、次の様にしてcovergroupを定義します。

• この例では、portのカバレッジ、及び、dataとportの対のカバレッジを収集しています。クラス内にcovergroupを定義すると、その名称を持つ変数（この例では cov）が自動的に確保されます。コンストラクタnewでcovにオブジェクトを割り当てています。covergroupを使用する為には、必ず、オブジェクトを割り当てなければなりません。

カバレッジ・モデルの定義

（その２）


• data、及び、portにはrand/randcが付いていないので、テストベンチ内で、そ

れらに値を割り当てる事を前提としています。そして、その際に、カバレッジ情報を収集します。

• portがcoverpointとして指定されているので、portがとる値の頻度がシミュ

レータにより計測されます。頻度の計算にビンが使用されます。クロス・カバレッジ（dataXport）も同様です。dataとportの値の対の出現頻度が計測されます。

covergroupへの引数


• covergroupの定義に引数を添える事が出来ます。これにより、covergroup

は汎用化します。例えば、次の様に引数を指定します。

• covをnewする時に、low、及び、highに対して値をパスしなければなりません。例えば、new(0,100)の様にして使用します。

サンプリングのタイミング指定


• covergroupの定義にサンプリングのタイミング指定する事が出来ます。例えば、次の様に指定します。

• イベント@swが起こる時にカバレッジ情報が収集されます。従って、テストベンチでは特別なサンプリング動作を記述する必要はありません。

• 同じシミュレーション時刻Tに於いてイベントが複数回起こる場合、複数回カバレッジの計算が行われます。時刻Tに於いて複数回イベントが起こっても唯一回のカバレッジ計算で済ませる為には、covergroupのtype_option.strobeに1を設定しなければなりません。このオプションの標準値は0になっています。

サンプリング関数

（built-in）関数


• covergroupの定義にサンプリングのタイミングを指定しない場合、テストベン

チでサンプリングを明確に記述しなければなりません。次の様にサンプリングはsample()を呼び出して行います。

• ここで使用しているsampleはビルトイン（built-in）関数でパラメータを引き渡すことが出来ません。パラメータを引き渡す為には、sampleを定義し直す必要があります。

サンプリング関数

（ユーザ指定）


• 例えば、次の様にしてsample関数を定義します。

• この機能により、covergroupでアクセスする事が出来ない変数のカバレッジを収集する事が出来ます。

簡単なカバレッジ例


• クラス外でportのカバレッジを計測しています。例を示す目的なので、意味の

ない記述になっています。シミュレーションが終了するとカバレッジ情報がデータベースに記録されます。ファイル形式はベンダーにより異なります。

クラス内のcovergroup


• クラス内にcovergroupを定義すると以下の利点があります。

covergroupの名称を持つハンドルが自動的に確保される。

簡単にクラス・プロパーティのカバレッジを収集する事が出来る。

• クラス内に定義されたcovergroupは embedded covergroupと呼ばれます。

• ハンドルにcovergroupのインスタンスを割り当てる為には、コンストラクタ内で行います。それ以外の場所で割り当てる事は出来ません。


（その１）


• クラス内にcovergroup cgを定義しているので、コンパイラーが自動的にハンドルcgを確保します。コンストラクタは、ハンドルにcovergroupのインスタンスを割り当てなければなりません。


（その２）


• この例では、プロパーティswの値が変化するイベントが発生すると自動的にa、及び、bのカバレッジを収集します。テストベンチでcg.sample()を呼び出す必要はありません。

• プロパーティa、及び、bはそれぞれ16個の値を取り得る為、カバレッジは共に2/16となります。

• シミュレーション時刻0に於いて2回イベントが起こり2回カバレッジ計算が行われている事に注意して下さい。

• この例と異なり、同じシミュレーション時刻には唯一回のカバレッジ計算で済ませる為には、次の様にします。

同じ時刻で重複計測を避ける方法


• type_option.strobeをONにしています。この設定により、シミュレーション時刻Tの最後に一回だけカバレッジ計算をします。

複数のcovergroupsを定義する方法


• 同じクラス内に複数のcovergroupを定義する事も出来ます。次の例を参考にして下さい。

カバー・ポイントの定義（coverage points)

（その１）


• カバレッジの基本はカバー・ポイントです。カバー・ポイントの定義は、やや複雑なシンタックスを持ちます。細かいシンタックスには触れずに代表的なカバー・ポイントの定義法をマスターする事を目的とします。先ず、全体的なシンタックスは以下の様になります。

• 簡単に言えば、coverpoint文でカバー・ポイントを定義します。カバー・ポイントには名称（cover_point_identifier）を定義する事が出来ます。省略すると変数名称がカバー・ポイント名称になります。

• カバレッジの収集を制御する為には、iff ( expression )を指定します。条件が成立する時のみカバレッジが収集されます。

[ [ data_type_or_implicit ] cover_point_identifier : ]

coverpoint expression [ iff ( expression ) ] bins_or_empty

カバー・ポイントの定義（coverage points)

（その２）


• bins_or_emptyでカバレッジのビンを定義します。

• ビンはカバレッジを計算する為のグルーピングを意味します。例えば、32ビッ

トの整数型変数のカバレッジを求める際、全ての整数値のカバレッジを求める事は意味が無いと同時に不可能です。寧ろ、32ビットの整数値を大、中、

小のグループに分けてカバレッジを求める方が効率的です。ビンはその様なグルーピングを可能にします。

• ビンの定義が省略されるとシミュレータは自動的にビンを定義します。それらのビンをauto binsと言います。autoビンの数をカバレッジ・オプションauto_bin_maxで制御する事が出来ます。

ビンの定義

（固定数のビン）


• 固定数のビンを定義する為には、例えば、以下の様にします。

• 各ビンに値を一様に分配します。与えられた値の数は13個です。ビンは、value[0]、value[1]、value[2]、value[3]の4個になります。13/4個の数を順にvalue[0]から割当てます。余った値を最後のビンに入れます。この宣言により、4つのビンが以下の様に定義されます。

• 例えば、aが値2を取ると、value[0]の計測値は1だけ加算されます。

value[0] ::= { 1, 2, 3 }

value[1] ::= { 4, 5, 6 }

value[2] ::= { 7, 8, 9 }

value[3] ::= { 10, 1, 4, 7 }

ビンの定義

（各値に対してビンを確保する方法）


• それぞれの値に対してビンを定義するには以下の様にします。

• この宣言により、10個のビンが以下の様に定義されます。

value[0] ::= { 1 }

value[1] ::= { 2 }

...

value[9] ::= { 10 }

ビンの定義

（唯一つのビン）


• 複数の値に対して唯一つのビンを定義する為には以下の様にします。

ビンの定義

(autoビン)


• ビンの定義を省略するとシミュレータが自動的にビンを定義します。各値に対して一つのビンを割り当てる様にビンを定義します。

• 例えば、3ビットの変数に対しては、8個のビンが割り当てられます。ビン数の最大値はauto_bin_max（標準値は64）を超えない様に定義されます。例えば、32ビットの変数に対しては64個のビンが定義されます。

• 次の記述ではビンの指定が無いので、autoビンが割り当てられます。変数a

は4ビットなので、auto[0]からauto[15]までの16個のビンが作成されます。

ビンの定義

(defaultビン)


• 定義したビンに属しない値を受け取る為のビンです。このビンはカバレッジ計算の対象外になります。以下の様にして定義します。

• aが4、6、又は、7であるとビンothersに割り当てられます。

ビンの定義

(illegal_bins)


• 信号値としてあり得ない値が出現した場合の計測をillegal_bins文で指定し

ます。このビンに記録された値はカバレッジから除外されます。更に、実行時のエラー・メッセージの対象になります。即ち、ilegal_binsに集計される値が出現した場合、エラー・メッセージが発行されます。

• 例えば、次の様に定義します。

ビンの定義

(ignore_bins)


• カバレッジの対象外の値をこの文で指定します。このビンに登録される値はカバレッジから除外されます。エラー・メッセージも発行されません。

• 例えば、次の様に定義します.

カバー・ポイントの使用

（例－１）



（例－１の解説）


• 変数aのカバレッジを計算する例です。aは3ビットなので、8個の値を取り得ます。従って8個のビンが必要ですが、ここではビン数を4に制限しています。それらのビンは、[0:1]、[2:3]、[4:5]、[6:7] に対応します。

• 区間[0:1]はignore_binsにより削除されます。区間[4:5]、及び、[6:7]はignore_binsの一部を含みますが値4、及び、7を計測し得る為、これらの区間は有効です。

• 実際にaがとる値は、2、4、及び、7ですが有効な区間の全てで値が収集されているので100%カバレッジを実現しています。


（例－１の計測例）



（例－２）



（例－２の解説）


• interface内のcovergroupの例です。

• クロック・イベントに同期してカバレッジを計測しています。covergroupのイン

スタンスが生成されない限りカバレッジ情報は収集されません。従って、次の命令は本質的に必要です。


（例－２の計測例）


信号値の遷移（transitions)

（その１）


• 信号値の状態の変化を=>で記します。例えば,

• は連続する二つのサンプリングで信号値がvalue1からvalue2に変化する事を意味します。変化する状態を幾つか連続する事が出来ます。

• の様に変遷を記述する事が出来ます。変遷のリストを両辺に指定する事が出来ます。例えば、

• は、以下の指定と同等です。

value => value2

value1 => value2 => value3 => value4 => value5

1,2 => 3,4

(1=>3), (1=>4), (2=>3), (2=>4)

信号値の遷移（transitions)

（その２）


• 繰り返し記号[*m]も使えます。例えば、1 [*5] は

• と同じです。アサーションと同様にgotoオペレータ[->m]が存在します。

• 例えば、1 [->3] は

• と同じです。ここで、...には値1が現れない事とします。同様に、不連続な繰り返し[=m]も存在します。1 [=3] => 2 は

• と同じです。

1 => 1 => 1 => 1 => 1

...=>1...=>1...=>1

...=>1...=>1...=>1...=>2

信号値の遷移のビン定義


• 信号値の遷移をビンの定義に指定する事が出来ます。例えば、次の様に信号値の変化をビンに定義する事が出来ます。

• single_binには以下の遷移が含まれます。

• array_binは次の様に定義されます。

4=>5=>6, 7=>11, 8=>11, 9=>11, 10=>11, 7=>12, 8=>12, 9=>12, 10=>12

array_bin[4=>5=>6], array_bin[7=>11], ...,array_bin[10=>12]


（使用例）



（計測例）


クロス・カバレッジ（cross coverage)

（その１）


• クロス・カバレッジはカバー・ポイントの組のカバレッジです。組になるカバー・ポイントの数に制限はありません。組である為、ビンの数は大きくなる傾向があります。例えば、

• では、カバー・ポイントa及びbのビン数はそれぞれ8ですが、クロス・カバレッジaBYbのビン数は64になります。

クロス・カバレッジ（cross coverage)

（その２）


• クロス・カバレッジのシンタックスは多少複雑ですが、一般形式は以下の様になります。

• cross_bodyでクロス・カバレッジの定義をします。定義を省略すると、可能な全ての組み合わせの対が構成されます。cross_bodyのシンタックスは複雑ですが、簡単な定義法もあります。

• binsofを使用すると比較的簡単にビンを定義する事が出来ます。binsofのシンタックスは以下の様になっています。

[ cross_identifier : ]

cross list_of_cross_items [ iff ( expression ) ] cross_body

cross_body ::= { { cross_body_item ; } } | ;

select_condition ::=

binsof ( bins_expression ) [ intersect { covergroup_range_list } ]

binsofの定義例

（その１）


• 例えば、次の様に定義します。

• クロス・プロダクトx1は次の4つのビンから構成されます。

<i[0],j[0]>

<i[0],j[1]>

<i[1],j[0]>

<i[1],j[1]>

binsofの定義例

（その２）


• ビンi_tenはi==10を含むiのビンから次の様に構成されます。

• この他に自動的にビンを定義するので、x2は次の3つのビンから構成されます。

<i[0],j[0]>

<i[0],j[1]>

i_ten

<i[1],j[0]>

<i[1],j[1]>

binsofの使用例




• CRT（ランダム・スティムラスの生成）を採用する場合、検証でカバーされた空間を自動的に計測する必要があります。

• その為には、ファンクショナル・カバレッジの知識が必要になります。

アサーションはシステムの動作（即ち、仕様）を記述する為の手段です。主として、アサーションはデザインの検証に使用されます。その他、functional coverage、又は、入力となるスティムラスの検証にも使用されます。

SystemVerilogアサーションの特徴は、仕様とデザインの不一致があれば、デザインの何処に問題があるかを容易に特定する事が出来る事です。

第１１章

アサーション (Assertions)


SystemVerilogアサーション

（SystemVerilog Assertions：SVA）


• アサーションではシーケンス（sequences）、及び、プロパーティ（properties）

を用いて仕様を記述します。但し、それらの記述自身では起動しない為、assert、cover、assume等のアサーション文を使用して検証を行ないます。検証とは、仕様とデザインが一致する事を確認する作業です。

• 検証者は仕様と合否処理（pass_statementとfail_statement）を記述します。

その他の全ての検証タスクはシミュレータが担当します。デザインをシミュレーションし、（仕様 != デザイン）となる状況が発生するとfail_statementが実行します。

検証 ∷= （仕様 == デザイン） ? pass_statement : fail_statement;

アサーションの種類


• アサーションには、即時実行型（immediate）と並列型（concurrent）の二種類があります。

• 即時実行型アサーションは、通常の実行文と同じ様に動作し、即時に実行が終了します。従って、時間を消費する概念がありません（non-temporal）。次の例は、即時実行型アサーションを示しています。

• この例では、クラスpacket_tのメンバーに乱数が正しく割り当てられているかを確認しています。メンバーには制約が課されている為、全ての制約を満たす様に乱数を発生する事が成功するとは限りません。その為、assert文を使用して確認をしています。乱数発生が不成功の場合、$fatal()タスクでエラーを報告します。

即時実行型アサーション

（immediate assertions)


• 即時実行型（immediate）アサーションは、実行した時点の式の評価結果を判定するif-then-else命令です。then句はpass statementと呼ばれ、else句はfail statementと呼ばれます。何れも省略する事が出来ます。評価結果の値が1’b1の時パスしthen句が実行します。それ以外の値を取る場合は、失敗（fail）となりelse句が実行します。

• 即時実行型アサーションにはassert、assume、coverの三種類があります。それぞれのシンタックスは以下の様になっています（[1]）。

• action_blockは、前述した様に省略可能なthen-elseです。 assert文は指定した式が成立する事を要求します。成立しない場合は、仕様に違反すると解釈されます。違反が起きて、assert文にelseクローズが指定されていない場合、$errorが呼び出されます。

assert ( expression ) action_block

assume ( expression ) action_block

cover ( expression ) statement_or_null

action_block ::=

statement_or_null

| [ statement ] else statement_or_null

即時実行型アサーション

（使用例）


• 即時実行型アサーションの例を示す為に interface を使用します。このinterfaceの役目は、入力信号の正当性を確認する事です。その目的で immediate assert文を使用します。interfaceを以下の様に定義します。

• @(posedge clk)のイベントが起こる度に、set及びresetの正当性チェックが行われます。

• 即時実行型アサーションの機能は比較的自明なので、以降では並列型アサーションを主として解説します。

並列型アサーション

(concurrent assertions)


• 並列型アサーションは、通常のシミュレーションと並行して実行します。記述した検証条件が成立、又は、不成立するまで検証が続行します。

• 実行はクロックと同期して開始、又は、再開します。従って、一つのアサーション記述に対して複数のインスタンスが同時に進行している可能性がある為、並列型アサーションはマルチ・スレッドとなります.

• 並列型アサーションはクロック・サイクルをベースにする為、サイクル・ディレー（## オペレータ）を使用して動作を記述します。

• 並列型アサーションでは、クロックの他に大切な概念があります。それは、アサーションで使用する信号の値です。アサーションでは、どの様なタイミングで信号値を取得するかが重要になります。この信号値はサンプル値（sampled values）と呼ばれ、SystemVerilogはサンプル値を厳密に定義しています。

• 並列型アサーションの評価はobserved regionで行われます。

concurrent assertionsの例


• 次の例は並列型アサーションの一例です。この例では、default clocking を使用しています。

• サイクル・ディレーは @(cb) 、即ち、@(posedge clk) により決定されます。@(cb)のイベントが起こるタイミングでサンプル値が取得されて、次の条件が満たされる事を確認します。

• req==1’b1であれば、1~3クロック・サイクルの間にack==1’b1が成立しなければなりません。成立しない場合、エラー・メッセージがプリントされます。

並列型アサーションのシンタックス（[1]）


concurrent_assertion_item ::=

[ block_identifier : ] concurrent_assertion_statement

concurrent_assertion_statement ::=

assert_property_statement

| assume_property_statement

| cover_property_statement

| cover_sequence_statement

| restrict_property_statemen

assert_property_statement::=

assert property ( property_spec ) action_block

assume_property_statement::=

assume property ( property_spec ) action_block

cover_property_statement::=

cover property ( property_spec ) statement_or_null

cover_sequence_statement::=

cover sequence ( [clocking_event ]

[ disable iff ( expression_or_dist ) ]

sequence_expr ) statement_or_null

restrict_property_statement::=

restrict property ( property_spec ) ;

action_block ::=

statement_or_null

| [ statement ] else statement_or_null

assert文


• この文はpropertyが成立する事を要求します。propertyが評価されて真（1’b1）であればaction_blockのthen句（pass statement）が実行されます。もし、propertyが評価されて偽（1’b0）であれば、action_blockのelse句（fail

statement）が実行されます。else句を省略し、且つ、propertyが偽と評価されると$errorが実行されます。

• action_blockで記述される命令はreactive region で実行されます。observed regionではありませんので注意して下さい。

assume、cover、restrict


• assumeの目的は、フォーマル解析ツールへの前提条件を提供する事です。シミュレータに対しては、propertyが成り立つ事を意味します。

• cover文はcover sequenceとcover propertyの二種類があります。cover

sequenceはsequenceのカバレッジを収集します。一方、cover propertyはpropertyのカバレッジを求めます。

sequence coverageの場合には、一つの評価に対しての全てのmatchが報告されます。一方、property coverageの場合には、評価試行に対してcoverage countが多くて一回だけ加算されます。

• restrict文はフォーマル解析ツールの為の機能です。

• 以降では、主としてassert、及び、coverを解説します

アサーションはマルチ・スレッド


• アサーションの条件式をPとします。クロック・イベントが起こる時刻Tに於いてPのインスタンスp1が評価されますが、p1の評価は、一般に、時刻Tで終了しません。後続のクロック・イベントでもp1の評価が続行されます。即ち、時刻Tで発生したPのインスタンスの評価は幾つかのクロック・イベントで評価されて結論が出ます。一方、Tの次のクロック・イベントでも、Pの別のインスタンスp2が発生します。従って、アサーションの条件式が唯一つであっても、

その複数個のインスタンスが同時に進行します。それぞれのインスタンスはスレッドとして実行する為、アサーションはマルチ・スレッドになります。

アサーションはマルチ・スレッド

（図解）


• 下図は、@(posedge clk) a ##2 b が成立する二つのスレッドが同時に進行

している事を示しています。それらのスレッドの実行時間間隔がオーバーラップしている為、マルチ・スレッドの状況が発生しています。

clk

@(posedge clk) a ##2 b

a

b

thread 1

thread 2

サンプリング（sampling)


• アサーションの評価に使用されるサンプル値は、例外はありますが、preponed regionに於ける信号値を意味します。

• preponed regionは時刻Tのシミュレーション・タイム・スロットの最初の領域です。サンプル値は、時刻Tのシミュレーションを開始する直前の信号値を意味します。preponed regionの反意語はpostponed regionです。これは、時刻Tのシミュレーション・タイム・スロットの最後の領域です。

• 例外は、automatic変数、又は、ローカル変数等です。これらの変数の値は評価する時点の値を参照します。preponed regionの値ではありません。例えば、forループで確保した制御変数は現在の値を参照します。サンプル値

の概念は、アサーションを理解するにつれて次第に明らかになります。現時点では、この程度の理解で十分だと思います。

アサーション・クロック


• アサーションはクロックをベースにして条件を評価します。サンプル値はクロック・イベントが発生した時に取得されます。

data

T

時刻Tに於けるdataのサンプル値は1’b1です。1’b0ではありません。

simulation time step

ブーリアン式（boolean expressions)


• アサーションの条件式の評価結果はbooleanで、通常の式の評価と同じです。即ち、結果が0、x、又は、zであれば、偽（false）となり、それ以外であれば、真（true）となります。

アサーションの式


• アサーションの条件式（即ち、検証すべき仕様）はプロパーティ（properties）で記述されます。

• プロパーティはシーケンスから組み立てられます。シーケンスはシーケンス・オペレータとブーリアン式から構成されます。極端な場合、ブーリアン式はプロパーティになりますが、ブーリアン式は時間を含まない（non-temporal）為、並列型アサーションを使用する理由はありません。

• 意味のあるアサーションにはシーケンス・オペレータが必要になります。単なるブーリアン式であれば、即時実行型アサーション（immediate assertions）で済む場合が多いです。

• シーケンス（及びプロパーティ）は複数のクロック・イベントを経過して評価を終了します。評価終了時に真となれば、仕様とデザインが一致（match）する事と判断されます。途中で評価が偽となれば、仕様とデザインが一致しないと判定されます。本チュートリアルでは、この判定結果をマッチ、及び、マッチしないと表現します。或いは、pass、及び、failとも表現します。

implication オペレータ

（implication operators)


• implication operatorsはプロパーティのオペレータですが、非常に重要なオ

ペレータである為、ここで解説します。アサーションを記述する際、絶対と言える程頻繁に使用されるオペレータです。このオペレータ無しでは、適切な例さえ記述する事が出来ません。

• implicationオペレータには二種類あります。それらは、|-> と|=> で微妙な

違いがあります。何れも if の意味を持ちます。

• オペレータの左辺（antecedent）が真であれば、右辺（consequent）を評価

します。左辺が偽の場合、右辺には関心が無い為、全体はマッチする事になります。但し、その場合のマッチは本来の意味のマッチとは意味が異なる為、この様なマッチをvacuous pass（真偽判定不能なパス、又は、意味のないパス）と呼びます。

implication オペレータ（|->)


• プロパーティex1に於いて、aが真であると、s1の評価が始まります。s1に於いて、cが真であると1クロック・サイクル後にbの評価をします。bが真であると、ex1の評価は終了して、マッチすると結論されます。

• 上記の例に於いて、aが真であると、ディレーを置かずに、s1の評価が始まります。これが |-> オペレータの意味です。

implication オペレータ（|=>)


• 一方、次の様に書くと事情が若干異なります。

• このオペレータは、aが真であると、1クロック・サイクル後に右辺s1の評価を開始します。即ち、以下の記述と同等です。

• オペレータ（|=>）をオペレータ（|->）で表現する事が出来る為、一般的には、オペレータ（|->）を好む傾向があります。

vacuous passの抑止


• implication operatorを使用するとvacuous passが多く出現し、ログ・ファイルが複雑になります。余計なvacuous passを抑止する為には、cover

property文を使用する事が出来ます。


（使用例）



（使用例の解説）


• この例を実行すると以下の様な結果を得ます。

• 4つのパスが報告されていますが、この中にはvacuous passが含まれます。

• 次ページの図に依れば、３件のvacuousパスがあります。

passed @10

passed @50

passed @50

failed @90

passed @90

アサーション・スレッド図


• 緑の▽は真のパス、赤の▽はfail、黄色の▽はvacuous passです。青の△

はスレッドの開始を意味します。緑色の線分はスレッドの活動区間を示します。数字はスレッド番号を示します。

vacuous passの抑止する例


• 以下の様に変更するとvacuous passのレポートを抑止する事が出来ます。

• cover propertyはvacuous passを無視するのでログ・ファイルにはvacuous

passはプリントされません。以下の様な結果を得ます。

passed @50

failed @90

シーケンス（sequences)


• 簡単に言えば、シーケンスはブーリアン式をサイクル・ディレー（## オペレータ）で結合した正則表現です。結合の仕方には多くの方法があり、シーケンス演算子が使われます。

• シーケンスは、キーワードsequenceで始まり、キーワードendsequenceで終了します。それらのキーワードの間に、シーケンス名、引数、及び、シーケンスの内容を記述します。シーケンスを以下のスコープに定義する事が出来ます。

module

interface

program

clocking block

package

$unit

checker

generate block

• シーケンスには引数を定義する事が出来ます。

シーケンス式


• シーケンス式のシンタックスは以下の様に纏められます（[1]）。

• シンタックスが示す様に、cycle_delay_rangeがシーケンス式を結合します

sequence_expr ::=

cycle_delay_range sequence_expr

{ cycle_delay_range sequence_expr }

| sequence_expr cycle_delay_range sequence_expr

{ cycle_delay_range sequence_expr }

...

cycle_delay_range ::=

## constant_primary

| ## [ cycle_delay_const_range_expression ]

| ##[*]

| ##[+]

cycle_delay_const_range_expression ::=

constant_expression : constant_expression

| constant_expression : $

cycle_delay_range


• cycle_delay_rangeの定義には以下の注意が適用されます。

$：無制限、即ち無限大を意味します。

##constant_primary：指定したサイクル・ディレーを持つ事を意味します。例えば、##2は「2サイクル・ディレー後」を意味します。

##[*] ：##[0:$]と同じ意味を持ちます。

##[+] ： ##[1:$] と同じ意味を持ちます。

##[m:n] の様に指定する場合には、0 ≤m≤nでなければなりません。これは、「mからnサイクル・ディレーの間に」を意味します。

• 特別な場合として、##0 はサイクル・ディレーを置かない事を意味します。例えば、a及びbをブーリアンとすると、 a ##0 b は a && b と同等です。

クロッキング・イベント


• アサーションにはクロッキング・イベントの定義が必要です。例えば、次のシーケンスcheck_req_ackはサイクル・ディーを指定していますが、クロックの定義がありません。従って、このままではシーケンスcheck_req_ackを使用する事が出来ません。

• シーケンスcheck_req_ackを使用する側でクロックの定義をしなければなりません。以下の様に、使用する側でクロック・イベントを定義するのが一般的です。

• この様なクロック・イベントをleading clock eventと呼びます。

default clocking block


• クロック・イベントの指定を省略する為には、default clocking blockを使用します。

• この場合、@(cb) が起こる都度check_req_ackを起動します。尚、クロック・

イベントに関するチェックはコンパイル時に行われます。即ち、コンパイラーがleading clock eventの存在を確認します。

• 上記の例で分かる様に、default clocking blockを使用するとシーケンス、及

び、プロパーティからクロック・イベントの記述を取り除く事が出来ます。結果として、クロック・イベントに依存しないアサーションを記述する事が出来る様になります。即ち、汎用化されたアサーション記述が得られる事になります。

サンプル値を参照する為の関数

（sampled value system functions)


• シーケンスを記述する際、サンプル値の適切な変化を知る事が大切です。

• システム関数、$rose、及び、$fellはアサーションのパフォーマンスに通じる

非常に大切な関数です。これらの関数は、レベル・センシティブな記述をエッジ・センシティブな記述に変換する重要な関数です。

関数意味

$sampled( expression ) サンプル値を戻します。

$rose ( expression

[, [clocking_event] ] )

expressionのLSBが1に変化したら真（true）を戻します。それ以外は、偽（false）を戻します。

$fell ( expression


expressionのLSBが0に変化したら真（true）を戻します。それ以外は、偽（false）を戻します。

$stable ( expression


expressionの値に変化が無ければ真（true）を戻します。それ以外は、偽（false）を戻します。

$changed ( expression

[ , [ clocking_event ] ] )

expressionの値が変化すれば真（true）を戻します。それ以外は、偽（false）を戻します。

$past ( expression1

[, [number_of_ticks ]

[, [expression2 ]

[, [clocking_event]]] ] )

expressionで示す信号の過去の値を戻します。

number_of_ticks：遡るクロック数。標準値は1。

expression2：クロックgating。標準値は1’b1。

clocking_event：クロックイベント。

レベル・センシティブとエッジ・センシティブ


• オペレータ |->、及び、|=> を使用する時は、関数 $rose、及び、$fellが有効に働きます。例えば、antecedentがレベル・センシティブな記述

• の場合、z == 1’b1であり限り、右辺（consequent）を評価します。極端な場合、シミュレーション終了時まで、z == 1’b1であると、クロック・イベントが起こる度に右辺の計算を行う事になり実行効率が良くありません。

• 検証すべき仕様にも依存しますが、zの信号値が1’b1、又は、1’b0 に変化した時にのみ、右辺が成り立つ事を確認すれば良い場合が多いです。その様な仕様の場合には、antecedentがエッジ・センシティブな記述になる様にするとシミュレーションの実行速度が向上します。例えば、以下の様に $rose() 関数を使用してantecedentをエッジ・センシティブに変換をします。

• この記述はレベル・センシティブな記述より遥かに実行効率が良いアサーションとなります。殆どのクロッキング・エッジでvacuous passが発生しますが、右辺（consequent）の評価は行われない為、シミュレータに対する負荷が軽減されます。

$roseの使用例


$roseの使用例

（実行結果の解説）


• この例では、エッジ・センシティブな関数 $roseをantecedentに使用しています。歴然とした差が出てきます。

• スレッド・ダイアグラムに依ると、30nsのみ右辺の評価をしています。他の

@(posedge clk) イベント時には、vacuous passとなっています。

メソッドtriggered


• triggeredメソッドを使用すると、他のシーケンスがマッチしたか否かを調べる事が出来ます。このメソッドは、マッチしていれば、真（1’b1）を戻し、そうでなければ偽（1’b0）を戻します。パラメータを指定する事も出来ます。例えば、以下の様に使用します。

• ここで、s1とs2は独立したシーケンスです。シーケンスs1はシーケンスs2とは無関係に実行しています。

• @(posedge clk) が発生した時、a==1’b1であれば、1クロック・サイクル後に、s1はマッチしなければなりません。s1が何時開始されるかは問題ではありません。


（使用例）



（実行例の確認）


• ダイアグラムで確認するのが一番分かり易いです。


（実行例の解説）


• 上半分がex2、下半分がex1のアクティビティです。

• がスレッド8として30nsで開始し、70nsでex1.triggeredを呼んでいます。この時、ex1（スレッド7）がマッチしています。従って、スレッド8は1サイクル後にf

を調べます。90nsにf==1’b1なので、スレッド8はパスします。ダイアグラムで8.7はスレッドの関係を示しています。

• 同様な解析をすると90nsでスレッド11が失敗している事が分かります。理由は90nsに於いてex1（スレッド16）がマッチしていないからです。

シーケンスの操作

（sequence operations)


• シーケンスに使用できる主なオペレータを紹介します。多くのオペレータはサイクル・ディレーの記述法を簡略化する為に存在します。例えば、 sig[*5] は

• と同じです。即ち、この簡略表現法は正則表現と言えます。オペレータは次の表の様に纏められます。

sig ##1 sig ##1 sig ##1 sig ##1 sig

シーケンスのオペレータ


オペレータ意味

[*m]

[*m:n]

連続したクロックでの繰り返しを意味します。例えば、a[*3] は、1クロックのディレーをおいてaが三回繰り返す事を意味します。即ち, a[*3] は

a ##1 a ##1 a

と同じです。

[=m]

[=m:n]

不連続のクロックでの繰り返しを意味します。

[->m]

[->m:n]

gotoオペレータと呼ばれます。

不連続のクロックでの繰り返しを意味します。[=] オペレータに類似していますが、直後のオペランドに対する制約をします。

##m

##[m:n]

クロック・ディレーを意味します。

sig throughout seq seqを評価している間、sigは真でなければなりません。sigは信号又は信号の式です。シーケンスを指定する事は出来ません。

seq1 within seq2 seq1はseq2に含まれる事を意味します。

seq1 intersect seq2 andと同じですが、両オペランドは同時に終了しなければなりません。

seq1 and seq2 両オペランドがマッチすれば全体としてマッチします。更に、両オペランドは同時に開始しなければなりません。

seq1 or seq2 どちらかがマッチすれば、全体としてマッチします。

first_match 複数のマッチが存在する時、最も早く終了するマッチを採択し、他のマッチを破棄します。

##m


• ##mはm回のクロッキンッグ・エッジ（クロック・サイクル）のディレーを置く意味です。例えば、クロッキング・エッジが @(posedge clk)であるとすると、##2は2回 @(posege clk) が起こるまで待つ事を意味します。

• 次のシーケンスは、現在のクロッキング・エッジにおいて、a==1’b1で、2クロック・サイクル後にb==1’b1である条件を記述しています。この条件が満たされると、このシーケンスはマッチする事になります。

• このオペレータの使用法は、これまでの例を参照して下さい。

##[m:n]


• このオペレータは、mからnクロック・サイクルのディレーを置く意味です。

• 例えば、次のシーケンスは、request==1’b1が来たら、1 から 3クロック・サイクルの間でgrant==1’b1にならなければならない事を意味します。

• 1 から 3クロック・サイクル間でgrant==1’b1になった時点で評価は終了します。たとえ1 から 3クロック・サイクルの間、grant ==1’b1であっても、passするのは最初の一回です。三回ではありません。

##[m:n]

（使用例）


##[m:n]

（実行例）


• 実行すると以下の結果を得ます。

@50: PASS

@110: FAIL

[*m]


• このオペレータはユーナリーで、 b[*m] の様にして使います。例えば、b[*2]

は b ##1 b を意味します。

• b[*m] がマッチする為には、bは連続したクロックの間、常に真でなければな

りません。そして、オペレーションは最後のマッチをした後に終了します。尚、bが偽であれば、その時点でオペレーションは終了しfailとなります。

• オペランドbはブーリアン式です。シーケンスを指定する事は出来ません。また、mは次の条件を満たさなければなりません。

m ≥ 0

m != $

[*m]

（使用例）


[*m]

（実行例）



@40: PASS

@80: FAIL

[*m:n]


• [*m]と同様にユーナリー・オペレータです。

• b[*m:n] がマッチする為には、連続したクロック・エッジの間でbは常に真でなければなりません。そして、(b==1’b1)となる数は最少m回、最大n回である

事が条件です。その条件を満たす最初のクロックでオペレーションは終了します。それ以上は繰り返しません。

[*m:n]

（使用例）


[*m:n]

（実行例）



@50: FAIL

@150: PASS

[=m]


• b[=m]は、必ずしも連続しないクロック・エッジにおいてbは、丁度m回真である事が求められます。例えば、b[=2] を正則表現的で書くと

• という事になります。ここで、bはb==1’b1を意味します。...にはb==1’b1があってはなりません。例えば、b[=2] ##1 cは、

• となります。二番目のbが真の後、三番目のb==1’b1が来る前にcが真になる条件を意味しています。尚、cはbの直後とは限りません。従って、b[=2]

##1 c は次の意味ではありません。

...b...b...

...b...b...c

...b...bc （実は、これはgotoです。）

[=m]

（使用例）


[=m]

（実行例）


• これを実行すると以下の様な結果を得ます。

@130: PASS

@250: FAIL

[=m:n]


• b[=m:n] は必ずしも連続ではないクロック・エッジにおいてbはmからn回真となる事を求めています。

• 区間を指定するので、単独で使用するとオペレータの意味はありません。必ず、他のオペランドが後に続く必要があります。

• 例えば、b[=2:3] ##1 cを正則表現的に書くと

• となります。即ち、bが2から3回真になっている間にcが真になる事が必要です。次の様な状態はマッチしません

...b...b...c 、又は、 ...b...b...b...c

bbbbc

b...b...b...b...c

[=m:n]

（使用例）


[=m:n]

（実行例）



@110: PASS

@250: FAIL

[->m]


• non-consecutive goto オペレータとも呼ばれます。後続のオペランドが無ければ [=m] と同じです。後続のオペランドがあると[=m]とは異なります。

• b [->2] ##1 cを正則表現的に書くと、

• となります。即ち、bが丁度2回真になった直後のクロック・イベントで

c==1’b1 が成立する条件を記述しています。

...b...bc

[->m]

（使用例）


[->m]

（実行例）



@110: PASS

@190: FAIL

[->m:n]


• [->m]に対して区間となっている違いがありますが、意味的には理解し易いと思います。

[->m:n]

（使用例）


[->m:n]

（実行例）



@110: PASS

@250: FAIL

sig throughout seq


• シーケンスseqを評価中はsigが常に真でなければならない条件を記述します。

• sigは信号又は信号の式で、シーケンスを指定する事は出来ません。

sig

seq

T1 T2

sigはT1からT2の間、真（true）でなければならない。 seqはT1からT2の間でマッチしなければならない。

sig throughout seq

（使用例）


sig throughout seq

（実行例）



@70: PASS

@170: FAIL

seq1 within seq2


• この機能は、sig throughout seqをシーケンスに拡張したバージョンと考える事が出来ます。throughout オペレータの左辺はブーリアン式に限られていましたが、withinの両辺にはシーケンスを指定する事が出来ます。

• この命令では、両方のシーケンスseq1、及び、seq2がマッチしなければなりません。更に、次の条件が満たされなければなりません。

seq1はseq2と同時、又は、後に評価を開始する。

seq2の評価終了より遅くない時期にseq1の評価が終了する。

seq1

seq2

T1 T2

seq1はseq2がマッチする間にマッチしなければならない。即ち、seq1はT1からT2の間でマッチしなければならない。 seq1の終了時刻とseq2の終了時刻が一致しても良い。

seq1 within seq2

（使用例）


seq1 within seq2

（実行例）



@90: PASS

@170: FAIL

seq1 and seq2


• バイナリー演算子 and は両オペランドがマッチする場合の条件を記述する

為に使用します。両オペランドの終了時刻は異なっても構いませんが、開始時刻は一致しなければなりません。

• 一方のシーケンスがマッチした場合、他方のシーケンスが終了する迄待ちます。従って、オペレータの終了時刻は、遅くマッチするシーケンスの終了時刻となります。

seq1

seq2

T1

seq1とseq2は同時に開始しなければならない。 seq1とseq2の両方がマッチしなければならない。

T2

seq1 and seq2

（使用例）


seq1 and seq2

（実行例）



@70: PASS

@150: FAIL

seq1 or seq2


• seq1、又は、seq2の何れかのシーケンスがマッチすれば全体としてマッチした事になります。何れかがマッチしたらオペレーションは終了します。

• 下図に於いて、seq1がマッチすれば、時刻T2で seq1 or seq2 はマッチした事になります。もし、seq1がマッチしない場合、seq2の評価はT2以降も続きます。

seq1

seq2

T1

seq1又はseq2の何れかががマッチしなければならない。何れかがマッチすると終了。

T2

seq1 or seq2

（使用例）


seq1 or seq2

（実行例）



@50: PASS

@130: FAIL

seq1 intersect seq2


• andオペレータと似ていますが、両方のシーケンスが同時に終了しなければ

ない条件が付加されます。即ち、両方のシーケンスは同時に開始し、同時に終了し、同時にマッチしなければなりません。

seq1

seq2

T1 T2

seq1とseq2は同時に開始しなければならない。 seq1とseq2は同時に終了しなければならない seq1とseq2の両方がマッチしなければならない。

seq1 intersect seq2

（使用例）


seq1 intersect seq2

（実行例）



@90: PASS

@190: FAIL

プロパーティ（properties)


• プロパーティはシーケンスから構築される検証仕様です。以下のスコープ内に、プロパーティを定義する事が出来ます。

module

interface

program,

clocking block

package

$unit

generate block

checker

• プロパーティの定義はキーワードpropertyで始まり、キーワードendpropertyで終了します。それらのキーワードの間に、プロパーティ名称、引数、及び、仕様を記述します。

プロパーティ（properties)

Syntax


• プロパーティはimplication の様なオペレータを使用して複雑な検証仕様を

記述する機能です。その際、シーケンスはビルディング・ブロックとして使われます。プロパーティの定義は次のシンタックスに従います（[1]）。

property_declaration ::=

property property_identifier [ ( [ property_port_list ] ) ] ;

{ assertion_variable_declaration }

property_spec [ ; ]

endproperty [ : property_identifier ]

property_port_list ::=

property_port_item {, property_port_item}

property_port_item ::=

{ attribute_instance }

[ local [ property_lvar_port_direction ] ]

property_formal_type

formal_port_identifier {variable_dimension}

[ = property_actual_arg ]

property_lvar_port_direction ::= input

property_formal_type ::=

sequence_formal_type

| property

property_spec ::=

[clocking_event ]

[ disable iff ( expression_or_dist ) ] property_expr

property_expr


• property_exprには多くのプロパーティ演算子（property operators）を使用する事が出来ます。implication operators（|->、及び、|=>）はその例です。以前の例を使用すると、プロパーティの例を次の様に書く事が出来ます。

シーケンスとプロパーティ


• SystemVerilogのマニュアルでは、両者の違いを明確に定義していません。その為、両者の違いに関して、初心者が混乱する原因となっています。

• 明確な違いは、オペレータにあります。プロパーティ演算子を使う場合には、プロパーティを使用します。それ以外の場合には、シーケンスで充分です。例えば、以下の場合にはsequenceで充分です。

• プロパーティはシーケンスを結合して式を構築します。次の様な場合にはpropertyが必要です。

シーケンスは一般的な機能


• シーケンスはアサーション以外にも使用される一般的な機能です。この為、プロパーティとシーケンスが分離されている訳です。例えば、シーケンスを次の様に使用する事が出来ます。

• この例に於いて、シーケンスabcがマッチすると、$display文が実行します。

マッチするまでは、イベント制御が実行をブロックします。一言でいえば、シーケンスは複数のクロック・サイクルに渡るイベント制御です。

プロパーティ演算子（property operators)

概要


• 全ての演算子を解説するのは入門書としての範囲を超えるので、代表的な演算子のみを解説します。

• 接頭辞 s_ を持つ演算子があります。それらは、strongプロパーティを持つオペレータで、シミュレーション実行中に必ず結論を出す機能です。即ち、後続のクロック・イベントが存在しなければ、failと結論します。例えば、

• に於いて、always bを評価中に次のクロック・イベントが存在しない（シミュレーションの終了）場合、p はパスします。これに対して、

• は事情が異なります。@(posedge clk) が発生した際、 a==1’b1であり、次の3~5クロック・サイクルの間 b==1’b1であれば、s_pはパスします。然し、パスする前にシミュレーションが終了するとs_pはfailします。

プロパーティ演算子

（代表的な演算子）


オペレータ意味

#-#

#=#

followed-byオペレータと呼ばれます。シーケンス・オペレータ|->及び|=>に対応しています。

followed-byオペレータにはvacuous passがありません。即ち、両辺がパスする時のみ全体がパスします。

#-# にはオーバーラップがあります。左辺がパスした時刻に右辺の評価を開始します。

#=# は左辺がパスすると1クロック・サイクル後に右辺の評価を開始します。

always property_expr property_exprが常に成立すればパスします。

s_always [ constant_range ]

property_expr

property_exprがシミュレーション実行中に常に成立すればパスします。

nexttime property_expr もし次のクロックが存在すれば、その時の式の評価が真（true）であればパスします。次のクロックが存在しない場合もパスします。

nexttime [constant_expression]

property_expr

constant_expressionで示すクロック後に式が真（true）と評価されればパスします。クロックが存在しない場合、評価の結論を出せない為、パスとなります。

s_nexttime property_expr 次のクロックが存在して式が真と評価されればパスします。それ以外は、failになります。

s_nexttime [constant_expression]

property_expr

constant_expressionで示すクロック後に式が真（true）と評価されればパスします。クロックが存在しなければ、failになります。

property_expr1 until

property_expr2

property_expr2が真になる迄、property_expr1は常に真である事が求められます。property_expr2が真になる時点ではproperty_expr1は真でなくても良い。

property_expr1 s_until

property_expr2

untilと意味は同じです。但し、property_expr2が真になるクロックが存在しなくてはなりません。

strong untilの場合、property_expr2が成立する状況が必要です。

#=#

(followed-by operator)


• このオペレータは次の様なシンタックスを持ちます（[1]）。左辺（antecedent）はシーケンス式ですが、右辺（consequent）はプロパーティ式です。

• 左辺がマッチすると、１クロック・サイクル後に右辺の評価が開始します。

sequence_expr #=# property_expr

#=#

(使用例)


#=#

(実行例)


• request信号が連続して三回trueになり、1クロック・サイクル後にgrantがtrueになればパスします。それ以外は、failになります。結果が示す様にvacuous passはありません。

@10: FAIL

@90: PASS

@90: FAIL

@90: FAIL

@90: FAIL

@110: FAIL

@130: FAIL

#-#とalways


• これらの演算子は、次の様なシンタックスを持ちます（[1]）。followed-byオペレータ（#-#）の左辺はシーケンス式で、右辺はプロパーティ式です。左辺がマッチすると、サイクル・ディレーを置かずに右辺の評価を開始します。

• 次の例は興味深い例です。例はfollowed-by #-# オペレータとalwaysオペレータを使用しています。例では、

• が成り立つ事を要求しています。常に成り立つか否かは結論が出ません。たとえ、シミュレーションが終了しても上記の条件が常に成立するかどうかを立証する事は出来ません。確実に言える事は、「シミュレーション実行中に条件が成立しない状況が発生しなかった」という事です。詰まり、反例が見つからなかったという事です。その意味で、この種のalwaysはweak alwaysと呼ばれます。以下の例では、failしなかった場合PASSとプリントされていますがweakの意味でのpassとして理解して下さい。絶対的に正しい意味でのpassではありません。

sequence_expr #-# property_expr

always property_expr

#-#とalways

（使用例）


#-#とalways

（実行例）


• 実行結果は以下の様になります。ダイアグラムではパスがvacuous passとして解釈されています。

@130: PASS

@130: PASS

@130: PASS

s_always [constant_range]


• この演算子は、次の様なシンタックスを持ちます（[1]）。必ず、区間を指定しなければなりません。

• 指定した区間（constant_range）ではproperty_exprが常に成立しなければなりません。評価中にシミュレーションが終了した場合、failとなります。詰まり、必ず結論が出ます。

• 有限の区間を指定しなければなりません。即ち、区間に $ を含む事は出来ません。

s_always [ constant_range ] property_expr


（使用例）



（実行例）


• この例では、s_alwaysを使用します。strongプロパーティなので条件が絶対的に成り立たなければなりません。s_alwaysの評価中にシミュレーションが終了する場合、結論はfailとなります。実行結果は以下の様になります。

@ 50: FAIL

@ 90: PASS

@110: PASS

@110: FAIL

@110: FAIL

@110: FAIL

nexttime


• この演算子は、次の様なシンタックスを持ちます（[1]）。区間の指定は無い為、次のクロック・エッジに関して式が成立しなければなりません。

• もし次のクロックが存在し、その時の式の評価が真（true）であればパスします。後続のクロックが存在しない場合もパスします。

• クロックが存在しない場合、結果がパスするのでこの形式はweak nexttime

と呼ばれます。

nexttime property_expr

nexttime

（使用例）


nexttime

（実行例）


• 実行結果は以下の様になります。時刻100のパスは、時間切れの意味でのパスです。

@ 30: PASS

@ 50: PASS

@ 70: PASS

@ 90: FAIL

@100: PASS



• この演算子は、次の様なシンタックスを持ちます（[1]）。

• constant_expressionで示すクロック後に式が真（true）と評価されればパス

します。クロックが存在しない場合、評価の結論を出せない為、パスとなります。

nexttime [ constant_expression ] property_expr


（使用例）



（実行例）



@ 50: PASS

@ 70: PASS

@ 90: FAIL

@100: PASS

@100: PASS

s_nexttime



• 次のクロックが存在して、且つ、その時に式が真と評価されればパスします。それ以外は、failになります。

s_nexttime property_expr

s_nexttime

（使用例）


s_nexttime

（実行例）



@ 30: PASS

@ 50: PASS

@ 70: PASS

@ 90: FAIL

@100: FAIL




• constant_expressionで示すクロック後に式が真（true）と評価されればパスします。クロックが存在しなければ、failになります。

s_nexttime [ constant_expression ] property_expr


（使用例）



（実行例）



@ 50: PASS

@ 70: PASS

@ 90: FAIL

@100: FAIL

@100: FAIL

マルチ・クロック（Multiclock)


• 殆どのシステムがマルチ・クロックで動作する為、マルチ・クロックを用いたシーケンスの記述法を知っておく必要があります。

• マルチ・クロックの重要な点は、二つのクロックのクロッキング・エッジのタイミングにあります。エッジが決して重ならない場合には、理解は容易になります。エッジが重なる可能性がある場合には、マルチ・クロックに関して注意が必要になります。

• マルチ・クロックのシーケンスはシーケンスをサイクル・ディレー・オペレータ（##）で結合する事により実現します。但し、使用する事が出来るオペレータは、##1、又は、##0 だけです。これらのオペレータの意味は特殊であり、従来の意味のサイクル・ディレーとは異なります。


##1


• 連続する二つのクロックのエッジが重なる場合、##1は次のクロック・エッジ迄のディレーを置きます。例えば、次の様なシーケンスが与えられたとします。

• 最初のシーケンスがマッチすると二番目（clk2）のシーケンスの評価が開始されます。最初のシーケンスがマッチする時刻を T1 とします。二番目のシーケンスの評価は T1 よりも真に後の最初の @(posedge clk2) に開始します。この開始時刻を T2 とします。すると、

• です。この定義が示す様に、##1 は clk1のクロック・サイクルではありません。また、一般に、clk2のクロック・サイクルとも一致しません。然し、##1 はクロックclk2を参照します。

T1 < T2


##0


• オペレータ ##0 は、最初のシーケンスがマッチした後の最初のクロッキン

グ・エッジを意味します。このオペレータでは、最初のシーケンスがマッチした時に、新しいクロックの最初のクロッキング・エッジが同時に起こる事も許されます。例えば、次の様なシーケンスが与えられたとします。

• 最初のシーケンスがマッチすると二番目（clk2）のシーケンスの評価が開始されます。最初のシーケンスがマッチする時刻を T3 とします。二番目のシーケンスの評価は T3 以降の最初の @(posedge clk2) に開始します。この開始時刻を T4 とします。すると、

• です。もし、@(posedge clk1) と@(posedge clk2) が同時に起これば、最

初のシーケンスがマッチした後、ディレーを置かずに二番目のシーケンスの評価が開始します。clk1とclk2のクロッキング・エッジが同時に起こらない場合には、##0は ##1 と全く同じ効果を持ちます。

T3 ≤ T4

マルチ・クロック

（使用例）


マルチ・クロック

（実行例）


• 実行結果は以下の様になります。最初の pass が @40 に起こっています。これは、 @(posedge clk2)のクロッキング・エッジを意味します。

failed @10

passed @40

passed @60

passed @80

passed @100



• 検証するための基本的な手段としてプロパーティ、及び、シーケンスを紹介しました。

• プロパーティはシーケンスを組み合わせて検証仕様を組みたてる手段です。一方、シーケンスは仕様を組み立てる為のビルディング・ブロックです。

• 仕様を記述し易い様にする為、シーケンスは正則表現の機能を備えています。

• アサーションはこれらの検証仕様が遵守されている事を確認する機能です。

• 現在のアサーション機能ではマルチ・クロック・システムの検証をする事が出来ます。

SystemVerilogのインターフェースはモジュール間の接続を簡素化する為に作られました。機能的には、インターフェースはモジュール・ポートを一般化した概念ですが、実際の機能はそれ以上の効果を齎します。大規模なプロジェクトには必須の概念です。

UVMを使用する場合には、interfaceを理解しなければなりません。

第１２章

インターフェース (Interfaces)


インタフェース（interfaces）


• インターフェースは、モジュールと同じ様にインスタンスを作る事が出来ます。そして、インターフェースのインスタンスをポートして使用し、モジュール間の接続に使用します。

• インターフェースは複数の信号から構成されます。しかも、それらの信号の向き（input、inout、 output等）を参照するモジュール毎に変える事が出来ます。この機能はmodportにより実現されます。

• モジュール間の接続変更はインターフェース内の定義変更だけで済みます。それぞれのモジュールのポート・リストを変更する必要はありません。

• インターフェースにはinitial、及び、alwaysプロシージャを記述する事が出来

ます。信号値の初期化、及び、プロトコルのチェック等を容易に行なう事が出来ます。

インタフェース（interfaces）（定義例）


インタフェース（interfaces）（使用例）


インターフェースのインスタンスを作成する。

インターフェースをポートに指定している。

modport


• インターフェースには多くの信号が定義されていますが、一般に、一つのモジュールは一部の信号にしかアクセスしません。その様な場合、modportを使用して信号へのアクセスを制限します。例えば、次の様にmodportを使用します。

• testでは、modport TESTに定義されているポート以外を見る事は出来ません。

パラメータ化したインターフェース

（parameterized interfaces)


• インターフェースにパラメータを追加する事で汎用化する事が出来ます。例えば、simple_ifにパラメータを追加すると以下の様になります。

• インターフェースのインスタンスを作る際にビット幅を指定する事が出来ます。

virtual インターフェース

（UVMで使用される重要な概念）


• virtualインターフェースはインターフェースのインスタンスを示す変数です。いわば、インターフェース・オブジェクトへのポインターです。このポインターをクラスのハンドルと同じ様に使用する事が出来ます。クラス内にはインターフェースを定義する事は出来ませんが、クラスはvirtualインターフェースを持つ事が出来ます。

• virtualインターフェースはnullで初期化される為、使用するまでにインターフェースのインスタンスで初期化しなければなりません。通常は、コンストラクタnewでvirtualインターフェースの初期化をします。例えば、以下の様にします。

• 但し、UVMを使用する場合には、 virtualインターフェースをコンストラクタで初期化する方法は正しくありません。

virtual インターフェース

（使用例）




• この章はinterfaceの持つ主要な機能を紹介しました。Modportはポートの方向の参照法を変える機能だけでなく、余計なinformationを隠す意味で重要な役割を果たします。

• 接続するポート数が多い場合、ポートをinterfaceに纏める事により、ポート・リストの維持が簡略化されます。

• Virtual interfaceは、module以外でinterfaceを使用する為の重要な手段です。

パッケージは共有するリゾース（パラメータ、データ・タイプ、タスク、ファンクション等）のコンテイナーです。構文としては一番外側に位置します。即ち、他のスコープにパッケージを含む事は出来ません。

パッケージはライブラリー開発等で使用される重要な機能です。

第１３章

パッケージ (Packages)


パッケージ（packages）


• パッケージにはタスク、及び、ファンクションを含む事が出来ますが、initialやalways等のプロシージャを含む事は出来ません。

• パッケージを個別のファイルに定義した場合、他のファイルでパッケージを参照する為には`include文を使用します。例えば、次の様にファイルを引用します。

• パッケージ内に定義されているリゾースを参照する為には、パッケージ名称にスコープ・オペレータ（::）を適用します。例えば、パッケージPkgに定義されているパラメータPIをモジュール内で参照する為には、

• の様にして参照します。スコープ・オペレータの使用を省略する為には、パッケージをimportしなければなりません。

パッケージのimport


• importする際、個別に名称を指定する事が出来ます。例えば、

• の様にしてimportする事が出来ます。importした名称は、モジュール test 内で Pkg:: を付けずに使用する事が出来ます。

• 個別にimportする代わりに、パッケージの全てのメンバーを同時にimportする為には ::* を使用します。例えば、次の様にして使用します。

パッケージ

（定義例）


パッケージ

（参照する例）


モジュール・ヘッダでimportする方法


• パッケージをモジュール内で参照する場合には、モジュール内でパッケージをimportしますが、それが不可能な場合があります。例えば、

• に於いて、color_eがモジュール・ヘッダで参照されています。このままではコンパイル・エラーになるので、例えば、次の様にします。

• これで、この問題は解決するのですが、また新たな問題が発生します。他のモジュールにもenumタイプcolor_eが見えてしまいます。モジュールm1だけに見える様にするには、次の様にします。

stdパッケージ


• SystemVerilogにはビルトイン・パッケージが定義されています。例えば、mailboxやsemaphoreはビルトイン・パッケージに定義されています。

• ビルトイン・パッケージに定義されているデータ・タイプを使用する際には、スコープstd::を使用する事が出来ます。例えば、

• の様にして使用します。名称の矛盾が無ければ、std::を省略する事が出来ます。

stdパッケージに定義されているクラス及び

メソッド


クラス又はメソッド機能

class semaphore;

function new(int keyCount = 0);

function void put(int keyCount = 1);

task get(int keyCount = 1);

function int try_get(int keyCount = 1);

endclass

排他制御用のクラスです。

通常のクラスと同じ様に使用する事ができます。

class mailbox

#(type T = dynamic_singular_type) ;

function new(int bound = 0);

function int num();

task put( T message);

function int try_put( T message);

task get( ref T message );

function int try_get( ref T message );

task peek( ref T message );

function int try_peek( ref T message );

endclass

FIFOリストを実現する為のクラスです。

通常のクラスと同じ様に使用する事ができます。

function int randomize( ... )

[ with constraint_block ];

乱数発生関数です。

class process;

enum state { FINISHED, RUNNING,

WAITING, SUSPENDED, KILLED };

static function process self();

function state status();

function void kill();

task await();

function void suspend();

function void resume();

endclass

プロセスはクラスとして実現されています。

コンストラクタnewが定義されていない事に注意して下さい。

stdパッケージ

（std::randomizeの使用例）


stdパッケージ

（processクラスの使用例）




• この章はパッケージの概念、定義法及び使用法を解説しました。これらの知識は、外部で開発されたライブラリーを使用する際に必要となる知識です。

• 特に、UVMを使用する場合には、パッケージの概念を理解して置く必要があります。

テストベンチの要素としてのprogramの解説をします。 Program

に記述された機能はreactive regionで実行します。テストベンチとして使用する場合には、細心の注意が必要です。

第１４章

プログラム（Programs）


programs


• プログラムはテストベンチの要素でありデザインを記述する為の機能ではありません。モジュールと同じ様な機能を持ちますが、以下の点で大きく異なります。

プログラムはデザイン階層を持つ事が出来ません。例えば、モジュールのインスタンスをプログラム内に置く事は出来ません。

プログラム内ではalwaysプロシージャを使用する事は出来ません。

プログラムのロジックはreactive regionで実行します。

プログラム内の全てのinitialプロシージャの実行が終了するとそのプログラムは終了します。

• この為、UVM等では、programを使用する事は出来ません。

program

（使用例）


テストベンチ

プログラムの制御


• プログラムを終了する為には、$exitタスクを使用する事が出来ます。$exitを呼び出すと全てのinitialプロシージャを終了させます。

• プログラムはテストそれ自身です。即ち、プログラム内の全てのinitialプロシージャが終了すると、シミュレーションは終了します。

• プログラムのロジックはreactive regionで実行します。従って、クロック・ジェネレータ等の機能をプログラム内で書く事は出来ません。Active regionで動作すべき機能はトップ・モジュールで行う必要があります。

Reactive Regionの効果

（その１）


• programのロジックがreactive regionで実行する事の意義を明確にしたいと思います。Interface及びトップ・モジュールを以下の様に定義します。


（その２）


• dutとtestは以下の様になっています。

• トップ・モジュールでrequest信号に1又は0をクロック・イベント毎にセットしています。ノンブロッキング（<=）なので、クロック・イベントが起きた時には、未だ値がセットされていません。従って、dutは常にrequest==0を見ています。

• 一方、testはprogramである為、reactive regionで実行します。このregion

では、INTF.request <= 1が実行した後に命令が実行するので、testは常にrequest==1を見ます。


（その３）



@10: dut.intf.request=0

@10: test.intf.request=1







• この章では、programとmoduleの差異を明確にしました。

• 特に、 programが動作する際の特異性を示し、programをテストベンチとして使用する際の注意を喚起しました。

• UVMを使用する際には、 programを使用しない事を薦めます。

頻繁に使用するシステム関数を纏めました。

第１５章

便利なシステム・タスクとファンクション



（その１）


関数機能

$countbits ( expression ,

control_bit { , control_bit } )

指定したビット（0、1、x、z）の出現数を戻します。例えば、

$countbits (expression, '1)はexpressionに含まれるビット1の数を戻します。

$countbits (expression, '1,’0)はexpressionに含まれるビット1、又は、0の数を戻します。

$countbits (expression, 'x,’z)はexpressionに含まれるビットx、又は、zの数を戻します。

$countones ( expression ) $countbits(expression,'1)と同じです。

$onehot ( expression ) $countbits(expression,'1)==1であれば trueを戻し、そうでなければfalseを戻します。

$onehot0 ( expression ) $countbits(expression,'1)<=1であれば trueを戻し、そうでなければfalseを戻します。

$isunknown ( expression ) $countbits(expression,'x,'z)!=0であればtrueを戻し、そうでなければfalseを戻します。


（その２）


関数機能

$typename ( expression ) | $typename ( data_type ) 値の示す型を文字列として戻します。

$bits ( expression ) | $bits ( data_type ) 値を表現する為に必要なビット数を戻します。例えば、

byte v; に対して、$bits(v)は8を戻します。

$isunbounded ( constant_expression ) 値が$であれば1を戻します。例えば、

parameter P = $; に対して、$isunbounded(P)は1を戻します。

array_query_function ::=

array_dimension_function ( array_identifier

[ , dimension_expression ] )

| array_dimension_function ( data_type

[ , dimension_expression ] )

| array_dimensions_function

( array_identifier )

| array_dimensions_function ( data_type )

array_dimensions_function ::=

$dimensions

| $unpacked_dimensions

array_dimension_function ::=

$left

| $right

| $low

| $high

| $increment

| $size

dimension_expression ::= expression

$dimensioonsは全ての次元数を戻します。

$unpacked_dimensionsはunpackedアレイの次元数を戻します。

$leftは次元の左側を戻します。

$rightは次元の右側を戻します。

$incrementは$left>=$rightであれば1を戻します。そうでなければ、-1を戻します。

$lowは次元の小さい方を戻します。即ち、$incremenが－1であれば、$leftを、$incremenが1であれば、$rightを戻します。

$highは次元の大きい方を戻します。

$sizeは$high-$low+1と同じです。


（その３）


関数機能

integer $rtoi ( real_val ) 実数値をintegerに変換します。但し、少数部分を切り捨てます。

real $itor ( int_val ) integer型を実数型に変換します。

[63:0] $realtobits ( real_val ) 実数値を64ビットのvectorに変換します。

real $bitstoreal ( bit_val ) $realtobitsで変換されたビットvectorを実数値に戻します。

[31:0] $shortrealtobits ( shortreal_val ) shortreal型の値を32ビットのvectorに変換します。

shortreal $bitstoshortreal ( bit_val ) $shortrealtobitsで変換された32ビットのvectorをshortreal型の値に戻します。


（その４）


関数機能

severity_message_task ::=

fatal_message_task

| nonfatal_message_task

fatal_message_task ::=

$fatal [ ( finish_number

[ , list_of_arguments ] ) ] ;

nonfatal_message_task ::=

severity_task [ ( [ list_of_arguments ] ) ] ;

severity_task ::= $error | $warning | $info

finish_number ::= 0 | 1 | 2

$fatalはシミュレーションを終了します。

list_of_argumentsは定数、又は、プリント書式です。


（その５）


関数機能

$sformat ( output_var , format_string

[ , list_of_arguments ] ) ;

$sformatはタスクです。$displayシステム・タスクと同じです。但し、出力をoutput_varにセットします。

string $sformatf(format_string

[,list_of_arguments ] )

$sformatfは文字列を戻すファンクションです。$sformatと同じ機能を持ちますが、出力を戻します。



• この章で紹介したタスク、及び、ファンクションは広く使用されます。使用法を完全に理解する事が必要です。

• これらのタスク、及び、ファンクションに対してコード・スニペットを準備しておくと備忘録になります。

この章では、UVMとは何かを説明します。本章により、UVMの構造が自然と明らかになります。

UVMを使用する為の技術は次の章で解説します。

第１６章

UVM概要 (Universal Verification Methodology)


UVMとは何か?


• UVM (Universal Verification Methodology)とは、検証分野で推奨されてい

る技術、ルール、慣習、規律等をコードとして具体化し、検証技術の再利用性と生産性向上をさせる為のSystemVerilogのクラス・ライブラリーです。

• UVMはAccellera Systems Initiativeにより開発されました。

• UVMはSystemVerilogをベースにして記述されているので、SystemVerilog

をサポートしている検証ツールの環境で使用する事が出来ます。

• ＵＶＭは、検証分野で推奨されている技術、ルール、慣習、規律等をベースにしている方法論である為、その開発の背景を最初に理解しなければなりません。

検証技術のトレンド（VMM）


• 近年の検証技術では階層的にテストベンチを記述する手法（layered

testbench）が採用されています。階層のレイヤー（layer）には以下の様な種類があります（[3]）。詳細は、関連する文献を参照して下さい。

• これらの層で機能する要素を纏めると次の様になります。

レイヤー検証目的及び機能

test layer テストベンチのトップ・レベルのレイヤーです。テストを生成して下位の層に送ります。

scenario layer シナリオに沿ってトランザクションのシーケンスを生成します。

functional layer 高位のレベルのコマンドを処理するレイヤーです。例えば、DMA

read/write等のコマンドを受け取ると、個々のbus read/write等のコマンドに分解してcommand layerに送ります。

command layer トランザクション・レベルのコマンドをシグナル・レベルの値に変換をしてsignal layerに送ります。DriverはDUTをドライブします。

signal layer

（DUT） DUTからのレスポンスは上位の層に送られます。アサーション等の結果も上位の層に戻されます。

テストベンチとレイヤーの関係（[3]）


• このlayered testbenchを良く考察するとUVM のメソドロジー・クラスの名称に対応している事が分かります。言い換えると、UVMは検証技術のトレンドに沿って開発されている事を確認する事が出来ます。

TEST

SCENARIO

FUNCTIONAL

COMMAND

SIGNAL

Test Case

Generator

Agent Scoreboard Checker

Driver Assertions Monitor

DUT

Fu

nctio

na

l Co

vera

ge

Environment

代表的なUVMクラス


• UVMには多くのクラスが定義されていますが、ユーザが直接使用するのはその内の一部のクラスで、メソドロジー・クラス（methodology class）と呼ばれます。

UVMクラス種別

uvm_sequence_item トランザクション関連

uvm_sequence トランザクション関連

uvm_driver メソドロジー・クラス

uvm_sequencer メソドロジー・クラス

uvm_env メソドロジー・クラス

uvm_agent メソドロジー・クラス

uvm_test メソドロジー・クラス

uvm_monitor メソドロジー・クラス

uvm_scoreboard メソドロジー・クラス

UVMテストベンチの構造（[2]）


DUT

UVM Agent

UVM Agent

UVM Environment

UVM Environment

UVM Sequencer

UVM Scoreboard

UVM Testbench

Sequences

Config

UVM Test

UVM Environment

エージェント（uvm_agentのサブクラス）


• シーケンサー、ドライバー、及び、モニターはエージェントとして纏められます。

monitor

collector

vif

sequencer

driver

vif

interface

Agent is_active=UVM_ACTIVE

DUT

エンバイロンメント（uvm_envのサブクラス)


• エンバイロンメントはシーケンサー、スコアボード、エージェント、及び、下位のエンバイロンメント（uvm_envのサブクラス）から構成されます。

agent (master)

monitor

UVM Environment

config

agent (master)

agent (slave)

agent (slave)

TLM (Transaction-Level Modeling)


• UVMはTLMを採用し、シグナル・レベルよりも高位の記述法を用いて検証タスクを表現します。このアプローチはシステムの動作を考察する際の自然な方法です。

• トランザクションは二つのコンポーネント間の通信をモデルする為に必要な情報を意味します。トランザクションには、その情報を操作する為のメソッドが定義されます。

• UVMではトランザクションはオブジェクトであり、UVMコンポーネントがトランザクションを操作します。その内の特別なコンポーネントとしてドライバー（uvm_driverのサブクラス）が存在します。ドライバーはトランザクションをシグナル・レベルに変換してDUTを操作する役目を持ちます。

• DUT側のシグナルの変化を検知する役目を持つUVMコンポーネントも必要になります。そのコンポーネントは、一般的には、コレクター（collector）と呼ばれます。

• ドライバーとコレクターの存在により、UVMではトランザクション・レベルでシステムを記述する事が出来る様になります。尚、UVMコンポーネントとDUT間のデータ授受にはSystemVerilogのvirtual interfaceが使用されます。

Virtual Interface

（SystemVerilogの機能）


• DUTとのデータ授受はvirtual interfaceを介して行われます。virtual

interfaceはinterfaceのインスタンスへのポインターです。

• interfaceのインスタンスはテストベンチ（トップ・モジュール）で作られます。そのインスタンスがDUTと関連するコンポーネントのvirtual interfaceに引き渡

さなれればなりません。その割り当てをハード・コーディングすると検証技術の再利用性に反する為、実行時にvirtual interfaceの情報を設定します。その際、前述したコンポーネント・インスタンスの階層構造が使用されます。

uvm_object


• UVMはSystemVerilogクラスとUVMマクロから構成されます。UVMには多くのクラスが定義されていますが、特別なクラスとしてuvm_objectが存在します。このクラスはアブストラクト・クラスで他の全てのUVMクラスのベース・クラスになっています。

• uvm_objectクラスでは他の全てのクラスに共通する属性、及び、手順を宣

言しています。具体的な手順の内容はサブクラスで行います。手順としては、例えば、print及びcopyがあります。

• uvm_objectクラスから二つの重要なサブクラスが定義されています。それらは、uvm_sequence_itemとuvm_componentです。前者は、トランザクショ

ンを定義する為に使用します。一方、後者はテストベンチを構築する為に使用します。全てのメソドロジー・クラスはuvm_componentのサブクラスです。

UVMコンポーネント

（uvm_componentのサブクラス）


• UVMコンポーネントはシミュレーションの対象となるので、デザインにおけるmoduleの様な役目を果たします。即ち、UVMにおいて、コンポーネントは自然にコンポーネント・インスタンスの階層構造を構成します。

• 階層のトップには、uvm_topと呼ばれるインスタンスが存在します。UVMは

その階層構造を使用してダイナミックなシミュレーションを制御します。例えば、階層構造を使用して、テストベンチの構成をシミュレーション開始直前に変える事が出来ます。この機能により、一度のコンパイルで複数のテスト・ケースを実行する事が出来ます。

• 階層構造は、シミュレーション開始直前に決定し、一度シミュレーションが開始（コンポーネントのタスクrun_phase() の実行を開始した時点）するとコンポーネント・インスタンスの階層構造は変化しません。

ドライバー（uvm_driverのサブクラス）


• 実行エントリーであるドライバーはDUTを制御します。

• DUTはシグナル・レベルで動作する為、ドライバーはトランザクション・レベルからシグナル・レベルへの変換を行い、DUTをドライブします。

• ドライバーはトランザクションをシーケンサー（uvm_sequencerのサブクラス）から受け取ります。

• ユーザはこれらのドライバー機能を実際に定義する必要があります。ユーザはメソドロジー・クラスから継承したサブクラスの内部に、これらの変換手順、及び、制御処理を定義します。

モニター（uvm_monitorのサブクラス)


• モニターはDUTの信号変化を監視する機能を持ちます。

• モニター（実際にはコレクターが担当）はDUTの信号値をトランザクションに

変換して、他のコンポーネントに引き渡します。それらのコンポーネントの一つとしてスコアボード（uvm_scoreboardのサブクラス）が存在します。

• スコアボードはDUTの出力が期待する結果と一致するか否かのテストを行います。その他、カバレッジ情報等も収集します。

• ユーザはメソドロジー・クラスから継承したサブクラスの内部に、これらの変換、及び、チェック手順を定義します。

UVMを使用する為に必要な手順


① UVMクラス・ライブラリーを`includeする。

② uvm_pkgをimportする。

④ run_test()を呼び出しテストを実行する。

③ テストすべき内容を定義する。

uvm_pkg


• UVMの全てのクラスはパッケージuvm_pkgに定義されています。このパッケージをimportする事により、UVMを使用する事が出来る様になります。

UVMマクロ


• マクロには大きく分けて二種類あります。実マクロと補助マクロです。実マクロは、実行命令に展開されるマクロで比較的分かり易いマクロです。補助マクロは、他の機能への情報を生成する為のマクロで、理解し難いマクロです。補助マクロには注意をする必要があります。例えば、次の例は実マクロです。

• このマクロはメッセージをプリントする命令を生成します。この機能は容易に想像する事が出来ると思います。一方、次の例には補助マクロが使用されています。

データ・オブジェクトに対する補助マクロ


• これらの補助マクロはsimple_itemクラスのメンバー名（UVMではfield名と呼ぶ）をUVMに知らせる機能を持っています。このマクロを与えないと、UVMはsimple_itemのメンバーを把握する事が出来ません。

• 例えば、マクロ定義が無いとsimple_itemのオブジェクトをプリントしても、これらのメンバーはプリントされません。

• クラスのメンバーを定義した場合、必ず補助マクロの定義が必要になります。一方、`uvm_fieldマクロが存在しない場合には、次の様に書きます

コンポーネントに対する補助マクロ


• 以上の例はデータ・オブジェクトに適用されるルールです。コンポーネントの場合には、多少異なるUVMマクロを使用しなければなりません。例えば、コンポーネントに対しては、次の様にUVMマクロを使用しなければなりません。

• 一方、`uvm_fieldマクロが存在しない場合には、次の様に書きます。

コンポーネントのfieldマクロに関する注意

（非常に重要）


• fieldがコンポーネントである場合には、fieldマクロを定義する必要はありません。例えば、次の例に於いて、master及びslaveがfieldとして存在しますが、fieldマクロを定義する必要がありません。

• 何故なら、コンポーネントの階層が自動的に作られる為、UVMにはmaster

及びslaveの存在が自明であるからです。上記のbuild_phase()で階層を構築しています。

run_test()

（重要な概念）


• ユーザが準備したトップ・モジュールからrun_test()を呼び出すと、UVMが実行権を得て、シミュレーション終了時まで実行制御権を持ち続けます。

• メソドロジー・クラスを使用してユーザが記述したUVMコンポーネントはUVM

により呼び出し制御を受けます。ユーザ側に実行制御権はありません。

• ユーザのUVMコンポーネントに制御が渡るタイミングは予め決定されていて、シミュレーション・フェーズ（simulation phases）と呼ばれています。

シミュレーション・フェーズ

（virtual function又はvirtual task）


• コンポーネントは実行エントリーですが、実行制御を受けるタイミングはUVM

により決定されています。そのタイミングはフェーズ（phases）と呼ばれ、以下の様に分類されます。以下のフェーズは記述されている順にUVMから実行制御を受けます。

フェーズ機能

build_phase コンポーネントの階層を構築するフェーズです。従って、階層のトップから順に呼ばれて行きます。通常、チャイルド・コンポーネントをこのフェーズで作成します。

connect_phase コンポーネント間の接続を完成するフェーズです。例えば、TLMポートの接続を定義します。

end_of_elaboration_phase 全ての接続が終了するとこのフェーズに制御が移ります。通常は、コンフィギュレーションをプリントする等の処理を記述します。

start_of_simulation_phase シミュレーションが開始する直前にこのフェーズが呼ばれます。初期化処理等を行う事が出来ます。

run_phase シミュレーションを行う為のフェーズです。

extract_phase シミュレーションが終了すると、このフェーズに制御が移ります。シミュレーション結果を抽出する為の処理を記述する事が出来ます。

check_phase 抽出したシミュレーション結果をチェックする為の処理を記述します。

report_phase シミュレーション結果のレポートを出力する処理を記述します。

シミュレーション・フェーズの定義


• 全てのフェーズはvirtualメソッドとして定義されています。ユーザは必要なフェーズだけを記述すれば良い事になっています。

• run_phase() は時間を消費するシミュレーション・フェーズである為、taskとして定義されていますが、その他のフェーズはfunctionとして定義されています。

• 通常、コンストラクタとbuild_phase() の定義は必須となります。

シミュレーション・フェーズの記述例




• 近年の検証技術のトレンドを観察すると、自ずから、UVMの構造が明らかになります。

• 検証分野で推奨されている技術、ルール、慣習、規律等をコードとして集大成したSystemVerilog検証ライブラリーUVMを使用する事により、検証作業の生産性を向上する事が出来る事は確実です。

本章では、UVMを使用する際に必要となる知識、及び、ガイドラインを解説します。実践で必ず役に立つ知識を纏めました。

第１７章

UVMの検証への適用 (Verification Using UVM)


ソース・コードの準備

（その１）


• UVMを使用するファイルの先頭で、次の様にファイルを`includeして下さい。UVMを使用する時には、これらのファイルは不可欠です。

• 実際にUVMを使用するスコープの先頭で uvm_pkgをimportして下さい。uvm_pkgをグローバルにimportすると名称に関する矛盾が発生する可能性があります。以上を纏めると以下の様になります。

ソース・コードの準備

（その２）


• UVMのシミュレーションを実行する為には、run_test()を呼び出す事が必要です。この他、UVMをコンパイルする為には、ìnclude用のディレクトリを設定する必要があります。設定法はツールにより異なる為、ベンダー提供のマニュアルを参照して下さい。

• 前頁の my_pkg.sv ファイルはパッケージ my_pkg を定義したファイルです。このファイルは、検証コンポーネントをìncludeする文を含みます。

• パッケージ内にはクラスの定義を含まず、クラスの定義を含むファイルをìncludeする方法が得策です。

uvm_objectとuvm_component


• 既に述べた様に、uvm_objectクラスが他の全てのUVMクラスのベース・クラスになっています。uvm_objectクラスから定義された重要なクラスとして、uvm_sequence_itemとuvm_componentがあります。前者はデータ（トランザクション）を記述する為に使用します。後者は、シミュレーションのエンティティ（コンポーネント）を記述する為に使用します。

• トランザクションはシミュレーションの対象ではありません。従って、トランザクションにはシミュレーション・フェーズが定義されていません。

• コンポーネントは、moduleと同様に階層を構築します。階層はシミュレーション実行開始直前に決定します。通常は、コンポーネントのbuild_phase()、及び、connect_phase()で階層を定義します。コンストラクタではコンポーネント・インスタンスを作らないのが一般的です。

• 特別な場合を除き、コンストラクタではコンポーネント・インスタンスを作るべきではありません。コンストラクタが実行する時点では、コンフィギュレーションが固定されていないのが普通です。

コンストラクタ


• UVMでは、コンストラクタに対して一般的なルールがあります。データ・オブ

ジェクトでは、名称に対して標準値を設定します。例えば、次の様に名称の標準値を定義します。

• 一方、コンポーネントは階層を構築する為、親コンポーネントの指定が必要になります。また、インスタンス名称には標準値を設定しません。同じ階層レベル内には、ユニークなインスタンス名称が必要な為、この様な配慮が必要になります。例えば、次の様に定義します。

ファクトリ（factory)


• オブジェクト、及び、コンポーネントのインスタンスを作る場合、newオペレータを使用する代わりに、factoryメソッドを使用する事が推奨されています。例えば、コンポーネントのインスタンスを作る場合、newを使用せずに以下の様にします。

• この様にインスタンスを作ると、ソース・コードを修正せずにmasterにmaster_compのサブクラスを割り当てる事が可能になります。検証技術の再利用性を高める為には、ファクトリ技術を適用する必要があります。

• 簡単に言えば、コンストラクタはvirtual functionになり得ない為、コンストラクタを恰もvirtual functionになる様にする仕組みが、ファクトリです。

シミュレーション・フェーズ

（simulation phases)


• コンポーネントは実行エントリーであり、実行する内容の記述を含まなければなりません。フェーズの種類を既に紹介しました。実践では、特別な処理が必要なフェーズのみ記述します。

• 多くの場合、build_phase() とrun_phase() の記述は必要になります。コンポーネントの階層が構築されると以下のメソッドは重宝になります。

メソッド機能

get_parent() 呼び出しているコンポーネントの親コンポーネントへのハンドルを戻します。親が存在しない場合には、ナルが戻されます。

get_full_name() 階層から構成されたインスタンス名を戻します。

get_child(string name) 指定した名称を持つチャイルド・コンポーネントを戻します。

get_parent(), get_child(), get_full_name(),

get_name()の使用例


コンフィギュレーションの設定変更


• コンフィギュレーションを実行時に変更する事を可能にする為には、uvm_config_db#(type)クラスを使用しなければなりません。このクラスを使用する事により、ソース・コードを修正せずに、コンポーネントの構成を変える事が出来ます。

• 例えば、ソース・コード中ではコンポーネント内のdata_sizeが2と定義されていても、テストベンチでdata_size を8に変更する事が出来ます。但し、この変更情報をbuild_phase() が実行する前に指定しなければなりません。build_phase()では、テストベンチで指定した情報が使用されるので、階層構造が指定した状態に変更されます。

• 具体的には、build_phase() でsuper.build_phase(phase)を呼び出すとapply_config_settings()が呼ばれてdata_sizeに変更値（この場合には8）が設定されます。この様に、super.build_phase(phase)は必須な呼び出しとなります。テストベンチでは、uvm_config_db#(int)::set()メソッドを使用して変更値を設定します。そして、この変更が有効になる為には、`uvm_fieldマクロが正しく設定されていなければなりません。


（使用例：その１）


これらの設定を

変更します。


（使用例：その２）


• テストベンチでは、次の様にdata_size、及び、header_nameに新しい値を設定します。

• この様に設定すると、次の様な結果を得ます。


（使用例：その３）


---------------------------------------------

Name Type Size Value

---------------------------------------------

test my_comp - @280

header_name string 10 data[0..7]

data_size integral 32 'h8

data da(integral) 8 -

[0] integral 32 'h0

[1] integral 32 'h1

[2] integral 32 'h2

[3] integral 32 'h3

[4] integral 32 'h4

[5] integral 32 'h5

[6] integral 32 'h6

[7] integral 32 'h7

---------------------------------------------

uvm_config_db#(type) に関する注意

（重要）


• typeに関して厳密です。即ち、設定するプロパーティのタイプと完全に一致しなければなりません。例えば、もしdata_sizeがint型ではなくbyte型であれば、uvm_config_db#(byte)::set()を使用しなければなりません。

• 型の不一致は設定変更の失敗を導く為、UVMはより寛大なクラスを提供しています。例えば、uvm_config_int::set()を使用すると、整数型の全てのプロパーティに対して設定変更をする事が出来ます。詳細に関しては、UVMのマニュアルを参照して下さい。

TLM

(Transaction-Level Modeling)


• トランザクションはRTLより高位のレベルでのデータ処理に適用されます。UVMではTLM（Transaction-Level Modeling）を使用します。SystemCのTLM 1.0に対応していますが、それよりも高速に動作します。

• SystemCのTLM 1.0と異なり、UVM TLMではトランザクションをポインターで引き渡します。従って、処理の高速化を実現しています。一方、consumer

がトランザクションに変更を加えるとその変更がproducer側に反映されてしまうという欠点があります。consumerがトランザクションに変更を与える場合には、トランザクションのコピーを作らなければなりません。

• トランザクションは二つのコンポーネント間の通信をモデルする為に必要な情報を意味します。UVMでは、uvm_sequence_itemクラス、又は、そのサブクラスからトランザクションを定義しなければなりません。

コンポーネント間の通信


• 通信にはTLM-portとTLM-exportが使用されます。TLM-portはトランザクションを操作する為の方法を定義します。一方、TLM-exportではトランザクションを処理する為に必要な実処理を記述します。

• ここではブロッキング・メソッドを使用して説明をします。ノンブロッキングの方法も殆ど同様にして行えます。通信は、producer、及び、consumerの関係になります。

• producer、及び、consumerは一対一の関係にあり、producerに対してconsumerが必ず存在しなければなりません。然し、producerを定義する時点ではconsumerに関する知識は一切必要ありません。言い換えると、producerが使用するプロトコルに従うコンポーネントがあればproducerと通信を行なえる事になります。即ち、producerコンポーネントの再利用が可能となります。同様の事がconsumer側にも言えます。

• producerとconsumerの接続を親コンポーネントが決定します。親コンポーネントはコンストラクタ、又は、build_phase() でproducer、及び、consumerのインスタンスを作成します。そして、connect_phase() でproducerとconsumerの関係を確立します。

ブロッキングput


• producerコンポーネントはTLM-portを使用してトランザクションを引き渡す操作を行います。一方、consumerコンポーネントはTLM-exportを使用して

トランザクションを受け取り、トランザクションを処理する手順を記述します。この関係をUVMでは以下の様に記します。

• 例えば、producerの記述は次の様になります

producer consumer port

export

Producerの例


• producerは相手方のコンポーネントに関する知識を持たずに記述している事に注意して下さい。

Consumerの例


• consumerではトランザクションに対するput()の実処理を記述します。

• producerは、単に、トランザクションをパスするだけですが、トランザクションを受け取るコンポーネントはトランザクションに関する実処理を定義しなければなりません。ユーザはタスクconsumer::put()の内容を定義しなければなりません。

• producerと同様に、consumerは相手方のproducerに関する知識を持たずに記述している事に注意して下さい。

親コンポーネントの例


• 親コンポーネントは、producerとconsumerの接続を次の様にして確立します。

• 親コンポーネントは、producer、及び、consumerのインスタンスを作り、connect_phase()に於いてTLM-portとTLM-exportの接続を完了します。この接続により、producerがput_port.put(tr)を呼ぶと、consumerのタスクput(tr)が呼び出される様になります。

ブロッキングget


• putの逆はgetになります。この場合には、次の様な関係になります。

• putの場合と同様の概念なので詳細を省略します。

get_producer get_consumer

get_export

get_port

get_producerの例


get_consumerの例


get親コンポーネントの例


uvm_tlm_fifo


• 上記のputの手順では、consumerはproducerがput()を呼び出している時のみアクティブになっています。一般の実処理では、producer、及び、consumerは独立したプロセスとして実行します。その場合、producerが送

信したトランザクションを損失しない為の処理、又は、トランザクションが存在しない場合のconsumer側の処理を考慮する必要があります。UVMでは、それらの問題を解決する為にFIFOキュー（uvm_tlm_fifo）を準備しています。

• FIFOキューにより、producer、及び、consumerは独立したプロセスで動作

する事が可能になります。しかも、トランザクションの損失等の問題はありません。両者の関係は以下の様になります。

• 図から容易に分かる様に、producer、及び、consumerはそれぞれ、put()、及び、get()を呼び出すだけで済みます。

tlm_fifo get_consumer producer

FIFOキュー


• FIFOキューにトランザクションが存在すれば、get()は直ぐに戻りますが、FIFOが空であれば、get()はブロックします。同様に、FIFOに空きがあれば、put()は直ぐに完了しますが、FIFOがフルであれば、put()はブロックします。これらの一連の制御をuvm_tlm_fifoが行います。FIFOのサイズを無制限に設定しておくと、常にput()は直ぐに完了します。

• producer、FIFO、consumerの関係の確立は親コンポーネントで行います。前述した方法で行って下さい。

FIFOキューを確立する例


analysis portsとexports


• モニターはpassive エントリーで、DUTの信号に変化があるとその信号値をトランザクションに変換し、他のコンポーネントに知らせます（broadcast）。知らせる相手（subscribers）は不特定多数である為、一対一の関係ではありません。従って、TLM-port、及び、TLM-exportの概念を適用する事が出来ません。

• UVMでは、１対Nの関係を確立する為に、analysis-ports、及び、analysis-

exportsの機能を持っています。そして、FIFOキューを使用する場合には、uvm_tlm_fifoの代わりにuvm_tlm_analysis_fifoを使用します。

tlm_analysis_fifo get_consumer_ap

producer

sub1 sub2

get_consumer_apの例


• analysis_portはvoid function write()を定義しています。このfunctionを使用してトランザクションのbroadcastを行います。

サブスクライバ―（subscriber）の定義例


• broadcastする為には、トランザクションを準備しなければなりません。前記の例では、タスクmake_transaction()に於いて処理をする事を意味していま

す。ユーザ自身で内容を記述して下さい。トランザクションの準備を終えると、write()を呼び出してトランザクションを送信します。

• トランザクションを受け取る側のサブスクライバ―（subscriber）を次の様に定義します。

• サブスクライバ―ではwrite()ファンクションの実装をしなければなりません。

analysis portsとexportsの接続


• analysis-portsの接続は親コンポーネント（my_env）で行います。

UVMシミュレーション


• UVMを知り始めた際に、最も分かり難い概念の一つとしてraise_objection()

とdrop_objection()があります。簡単に言えば、これらのメソッドを呼び出さないと、UVMはシミュレーションを実行しません。それ故、これらのメソッドを何れかのコンポーネントで呼び出さなければなりません。

• テストベンチからタスクrun_test()を呼び出すとシミュレーションが開始しますが、上記のメソッドが呼び出されていなければ、時刻0でシミュレーションが終了してしまいます。即ち、各phaseメソッドの一部しか実行しません。イベント待ち、及び、ディレー制御をしている命令は無効になります。

raise_objectionとdrop_objection


• UVMコンポーネントを正しく記述してもシミュレーションは実行しません。厳密に言えば、シミュレーションは時刻0で終了してしまいます。

• シミュレーションをする為には、UVMに実行すべき内容がある事を知らせな

ければなりません。そして、実行が終了したらその旨通知しなければなりません。

• raise_objection() はUVMに実行すべき内容がある事を知らせます。一方、drop_objection() は実行すべき内容が完了した事をUVMに知らせます。全ての内容が完了した時点でUVMは run_phaseを終了して、次のphase（通常は、extract_phase）に進みます。

• 全てのraise_objection() をdropしても直ぐには終了しません。UVMではdrain time等の概念をサポートしています。詳細に関してはUVMのマニュアルを参照して下さい。

raise_objection


• raise_objection() メソッドの使用法は以下の様になっています。

• コンポーネントのインスタンス（obj）のobjectionカウントをcountだけインクリメントします。コンポーネント階層で上位にあるインスタンスのobjectionカウントも一斉にインクリメントされます。

• 従って、何処かのインスタンスがraise_objection() を呼び出せば、UVMシミュレーションは進行します。

• obj==nullの場合には、uvm_topが仮定されます。

drop_objection


• drop_objection() メソッドの使用法は以下の様になっています.

• このメソッドはraise_objection() と正反対の動作をします。コンポーネントのインスタンス（obj）のobjectionカウントをcountだけ減少します。コンポーネント階層で上位にあるインスタンスのobjectionカウントも一斉に減少されます。

• obj==nullの場合には、uvm_topが仮定されます。

• インスタンスのobjectionカウントが0の場合、drop_objection() を適用するとエラーになるので注意して下さい。

raise_objectionとdrop_objection

（使用例）


クラスの記述法

（その１）


• クラス内に宣言されている内容は仕様書の役割を果たす重要な情報となります。その様な情報を見易くする為に、メソッドの実装をクラス外に定義する事が勧められます。例えば、クラスの定義を次の様にします。

• １０～１２行目の実装をクラスの外に定義します（次ページを参照）。

クラスの記述法

（その２）


• 実装情報は何処に存在しても構いませんが、クラスの定義と同じファイルに実装するのが望ましと言われています。

トランザクションの定義

（その１）


• トランザクションはDUTをドライブする為に必要なシグナル・レベルのデータを生成する為に使用する高レベルなデータ・アイテムです。

• トランザクションはuvm_sequence_item、又は、そのサブクラスを使用して作ります。手順を纏めると以下の様になります。

uvm_sequence_item、又は、そのサブクラスからトランザクションを定義する。

トランザクションに必要なフィールドを定義する。

必要に応じて制御フィールド（knobs）を定義する。

UVMマクロを定義する。

コンストラクタを定義する。


（その２）


• クラスのプロパーティに対してUVMフィールド・マクロを定義する必要があります。制御フィールド（knobs）に対しては、不必要な処理を省く為に、フィールド・マクロ・フラグ（UVM_NOCOMPARE、UVM_NOPACK等）の指定をする必要があります。以下では、制約の実装をクラス外で行います。


（その３）


• simple_itemのメンバー（fields）は整数型である為、乱数を発生すると広い範囲の値を取り得ます。然し、それらの全ての値の組み合わせを使用して検証する事は不可能であると共に意味がありません。論理的に意味のある様にデータを発生させる必要があります。

• その為には、データ発生に制約を設ける必要があります。制約を設定した例を示します。この制約はクラス外で行っています。

• delay_kindは、論理的に意味のあるdelayを発生する為に導入された項目です。従って、直接DUTに引き渡される値ではありません。UVMではこの様な制御項目をノブ（knob）と呼んでいます。

サブクラスによる制約


• トランザクションのプロパーティに関する制約はテスト・ケースに依存する場合があります。その様な場合、テスト・ケース特有のトランザクションを定義する事が望ましいと思えます。

• SystemVerilogでは、サブクラスを定義する事により目的を達成する事が出来ます。以下の例を参考にして下さい。

ドライバーの定義

（その１）


• ドライバーはシーケンサーからトランザクションを取得し、シグナル・レベルに変換してDUTをドライブします。ドライバーはvirtual interfaceを使用してDUTに送る信号を作ります。

• interfaceにはDUTのポートが接続されているので、virtual interfaceでその信号値を変更すると、DUTにその変化が反映されてDUTが反応します。

• ドライバーを定義する手順を纏めると以下の様になります。

uvm_driver、又は、そのサブクラスからドライバーを定義する。uvm_driver

はトランザクションの型（REQ）、及び、シーケンサーに戻すトランザクションの型（RSP）を指定して定義します。

virtual interfaceを宣言する。


タスクrun_phaseにトランザクションの操作手順を定義する。


（その２）


• uvm_driverには、以下の様な重要なプロパーティが定義されているので、ドライバーの記述で自由に使用する事が出来ます。

req：REQ型のメンバーでトランザクションを指定する際に使用する。

rsp：RSP型のメンバーでレスポンスを指定する際に使用する。

seq_item_port：TLM-portです。

• seq_item_portは、uvm_driverのコンストラクタで作成されます。seq_item_portは以下の様に定義されています。

• ドライバーはシーケンサーからトランザクションを受け取りますが、TLM-port

を使用しているので相手のシーケンサーを意識する必要はありません。TLM-portのプロトコルに従い、データをget_next_item()を呼ぶだけで済みます。


（その３）


• 具体的には以下の様にします。


（その４）


• トランザクションがDUTをドライブする為には、virtual interfaceが必要です。simple_driver::build_phase()では、simple_driverのインスタンスに割り当てられているvirtual interfaceのアドレスをvifに取得しています。


（その５）


• タスクdrive_item()では、virtual interfaceを使用してDUTシグナルを操作します。

• その際、interfaceを使用するので、non-blockingで処理を記述するのが一般的です。blockingで記述すると、DUTシグナルを操作する度にDUTに割り込みがかかる可能性があります。

Interfaceの割り当て


• interfaceのインスタンスはトップ・モジュール内に作られます。従って、通常は、トップ・モジュールがinterfaceのインスタンスをsimple_driverのインスタンスにあるプロパーティ名称 “vif” に割り当てます。

• 以下に、interfaceのインスタンスを割り当てる記述例を示します。コンポーネントの階層構造を正しく指定しなければなりません。

シーケンサーの定義

（その１）


• シーケンサーはドライバーからget_next_tem()が呼ばれるとデータを作り乱

数を設定した後、ドライバーに戻します。実際には、データの準備をシーケンスが行います。シーケンサーを定義する手順は以下の様になります。

uvm_sequencer、又は、そのサブクラスからシーケンサーを定義する。


コンストラクタを定義する。

• シーケンス、及び、トランザクションはオブジェクトでありコンポーネントではありません。一方、シーケンサーはコンポーネントです。

• 従って、シーケンサーはコンポーネント・インスタンスの階層構造に含まれて実行エントリーになります。実際問題として、シーケンサーのrun_phase()は重要な働きをします。通常、このフェーズに関してdefault_sequenceの設定が行われます。

シーケンサーの定義

（その２）


• シーケンサーには、以下の様な重要なプロパーティが定義されています。

• このプロパーティをトランザクションの送信に使用する事が出来ます。シーケンサーの定義例を示します。

• 通常は、この程度の簡単な定義で済みます。ベース・クラスのuvm_sequencer、uvm_sequencer_param_base、uvm_sequencer_base等が複雑な処理を担当しています。

シーケンサーとドライバーの

基本的なハンドシェーク（その１）


• 基本的なハンドシェークはget_next_item()とitem_done()を用いて行います。

• ドライバーがget_next_item()を呼ぶとデータが戻されるまでドライバーは待ち状態に入ります。

• データの準備が完了すると、get_next_item()が終了し、ドライバーの実行が再開します。

• ドライバーはデータの処理を終了すると、そのデータに関する処理を終了した旨をitem_done()により知らせます。

• ドライバーの処理は、一般的に、以下の様になります（次ページ参照）。

シーケンサーとドライバーの

基本的なハンドシェーク（その２）


• run_phase()ではんどシェークを行ないますが、以下の様にタスクを使用すると処理が明瞭になります。

• ここで、get_next_item()タスクはブロッキングですが、その他のタスクとしてノンブロッキングtry_next_item()を使用する事が出来ます。

モニター


• モニターはDUTのレスポンスの変化を検知して他のコンポーネントに知らせる（broadcast）役割を果たします。

• DUTのレスポンスはシグナル・レベルである為、モニターにはシグナル・レベ

ルの情報をトランザクション・レベルに変換する機能が必要になります。その機能を持つコンポーネントは、一般的に、コレクター（collector）と呼ばれます。

• コレクターはvirtual interface（下図では、vifとして参照）を使用してDUTの信号変化を取得します。

monitor collector uvm_analysis_imp

uvm_analysis_port

vif uvm_analysis_port

コレクターの定義

（その１）


• コレクターはvirtual interfaceを使用してDUTの信号変化を探ります。従って、コレクター内のプロパーティvifにinterfaceへのポインターを設定しなければなりません。

• この例では、connect_phase()でvirtual interfaceの設定を行っています。文字列をベースとしたインスタンス名称を使用してvifにinterfaceのポインターを取得します。インスタンス名と実際のinterfaceインスタンスの対応はトップ・レベルのモジュールが行います。

• 実装例は次ページを参照下さい。

コレクターの定義

（その２）


モニターの定義

（その１）


• モニターはコレクターからトランザクションを受け取り、チェック、及び、カバレッジの収集を行い、トランザクションが準備されている事を他のコンポーネントに知らせます（broadcast）。

• コレクターのお陰でモニターはトランザクション処理に専念する事が出来ます。

• モニターをuvm_monitor、又は、そのサブクラスを使用して定義します。uvm_monitorには特別なプロパーティが定義されていないので、使用するプロパーティをユーザが定義しなければなりません。

• 簡単な例を紹介します。broadcastする為のanalysis portとしてitem_collected_portを定義しています。また、コレクターからトランザクションを受け取る為のanalysis exportとしてcoll_mon_exportを定義しています。詳細は、次ページを参照して下さい。


（その２）



（その３）


• コレクターがトランザクションの準備を終了するとsimple_monitor::write()を呼びます。

• このモニターのwrite()ファンクションがトランザクションを受け取ると、チェック、

及び、カバレッジ計算を行います。そして、コレクターから取得したトランザクションを他のコンポーネントにbroadcastします。

• スコアボード等のコンポーネントは、このトランザクションを受け取ります。

Agent

（その１）


• 通常、ドライバー、シーケンサー、モニター（コレクターを含む）は一組として一緒に使用されます。この為、UVMではこれらのコンポーネントを含む為のコンテイナーを提供しています。そのコンポーネントがuvm_agentです。

• uvm_agentはトポロジーの柔軟性を高める為に、コンフィギュレーション・パラメータを装備しています。代表的なパラメータとしてis_activeプロパーティがあります。is_activeは重要なプロパーティで以下の様な意味を持ちます。

is_active 機能

UVM_ACTIVE このモードでは、agentはデバイスをエミュレーションしてDUTをドライブします。また、チェック、及び、カバレッジをする為にモニター（コレクターを含む）も使用します。

UVM_PASSIVE このモードでは、シーケンサー、及び、ドライバーを装備しません。モニター（コレクターを含む）のみ装備します。

Agent

（その２）


• is_activeはuvm_agentクラスに定義されていますが、uvm_agent内にUVM

フィールド・マクロで指定されていません。従って、is_activeに対して、UVM

マクロを指定しなければなりません。概して、agentの定義は以下の程度で済みます。

Agent

（その３）


• is_activeの定義内容に従って、トポロジーを変える様にagentの定義をしなければなりません。

Environment

（その１）


• EnvironmentクラスはUVCのトップ・レベル・コンテイナーです（[4]）。

• Environmentは、幾つかのagents、及び、Environment専用のモニターを含みます。その他、Environmentトポロジーの柔軟性を高める為にコンフィギュレーション・パラメータも保有します。

• 以下のsimple_envの例では、モニター、master、slaveのコンフィギュレー

ションに柔軟性が持たされています。実際の値は、他のコンポーネント（例えば、テストベンチ）がそれぞれのコンポーネントを作る直前に（例えば、build_phase()において）設定します。

Environment

（その２）


• テストベンチでコンフィギュレーションを決定する例を示します。以下の例に於いて、super.build_phase(phase)を呼ぶとコンポーネントが配置されてし

まうので、その前にコンフィギュレーションを決定している事に注意して下さい。

• uvm_config_db#(type)::set()を使用する際には特別な注意が必要です。マ

ニュアルを熟読して理解を深めてから使用して下さい。uvm_config_db#(type)::get()に関しても同様です。

Environment

（その３）


• simple_envのbuild_phase()が開始する前に、num_masters、及び、num_slavesの値が設定されています。

Environment

（その４）


シナリオの作成


• シナリオの作成はシーケンスの作成に尽きます。シーケンスが実行する事により有意義なトランザクションが作成されます。恐らく、シーケンスはシーケンサーと伴にUVMの機能の中で理解し難い概念の一つだと思います。UVMのUser’s Guideを熟読してから設計を始めて下さい。シーケンスを定義する手順は以下の様になります。

uvm_sequence、又は、そのサブクラスからシーケンスを定義します。その際、トランザクションのタイプ（REQ）、及び、ドライバーがシーケンサーに戻すレスポンスのタイプ（RSP）を指定します。

シーケンスに対して、ùvm_object_utilsマクロを定義します。シーケンスは、コンポーネントではないので、ùvm_component_utilsマクロを使用する事は出来ません。

必要に応じて、ùvm_declare_p_sequencerマクロを使用してシーケンサーへのポインターを宣言して下さい。

シーケンスにタスクbody()を定義します。

シーケンス

（その１）


• uvm_sequenceはプロパーティとしてreq（REQ型）、及び、rsp（RSP型）を

以下の様に確保するので、ユーザが定義したシーケンス内ではそれらを自由に使用する事が出来ます。

• 次に簡単なシーケンスの例を紹介します。次ページを参照して下さい。

シーケンス

（その２）


• １３行目でプロパーティ req を使用しています（）。

• タスクbody()は、トランザクションをcount数だけ作成します。各トランザクショ

ンの準備が出来るとシーケンサーに知らせ、ドライバーにトランザクションが送信されます。この操作がcount回繰り返します。

シーケンス

（その３）


• `uvm_doマクロは複雑で、トランザクションの生成、トランザクションの乱数発

生、シーケンサーとの通信を行う命令を展開します。このマクロの他に、`uvm_do_withマクロを使用する事が出来ます。こちらのマクロは、実行時に乱数発生制約条件（inline constraints）を指定する場合に使用します。

• countの値は、simple_sequenceのオブジェクトが作成された後、simple_sequence::randomize()が呼び出されて決定します。一般的には、シーケンサーがsimple_sequenceのオブジェクトを作成します。

シーケンサー、シーケンス、ドライバー


• トランザクションを取得する際の流れを次の様に纏める事が出来ます（[4]）。

ドライバーはseq_item_port.get_next_item(req)を呼び出し、データの要求を発行します。すると、TLMのseq_item_port.get_next_item(req)はsequencer.get_next_item(req)を呼び出します。

シーケンサーは、設定されているシーケンスを選択します。

シーケンスのインスタンスが作成され、そのインスタンスに対してrandomize()が呼び出されます。そして、シーケンスのbody()が開始します。タスクbody()でデータが準備されると、シーケンサーにその知らされます。

シーケンサーはドライバーにデータを送信し、ドライバーがitem_done()を発行するのを待ちます。

ドライバーはDUTにデータを送ります。そして、seq_item_port.item_done()

を呼びデータの処理が終了した事をシーケンサーに知らせます。

• 上記の処理は繰り返します。

シーケンスの開始


• シーケンサーはシーケンスを実行する様に設定されていません。ユーザは、シーケンスのインスタンスを作り、start()タスクを呼び出してシーケンスを開始する事が出来ます。最も一般的な方法は、シーケンサーのrun_phaseにdefault_sequenceを設定する事です。

• run-timeのフェーズが開始すると、シーケンサーはそのフェーズにシーケン

スが設定されているかを確認します。設定されていれば、そのシーケンスを開始します。

• 通常は、テストベンチに於いてdefault_sequenceを設定します。処理の詳細は、uvm_sequence_base:: start_default_sequence()をお読み下さい。

• 次に、default_sequenceの設定例を示します。この例はUVMの次のファイルに定義されています。

examples/integrated/ubus/examples¥test_lib.sv

default_sequenceの設定（[2]）


• テストベンチで以下の様に設定します。

• シーケンサーのrun_phase()が実行する時には、default_sequenceの設定

が完了しているので、シーケンサーにはどのシーケンスを実行すれば良いか分かっています。従って、ドライバー、シーケンサー、シーケンスの関係が確立します。

ベース・テスト


• テストは、一般に、複数ありますが多くの共通処理を含みます。その為、共通処理をベース・クラスとして構成しておきます。テストを構成する為には、メソドロジー・クラスuvm_testを使用します。

• 例えば、ベース・クラスは下記の様になります。

テスト


• テスト・コンポーネントの目的は、具体的なテスト項目を指定する事です。テスト項目はシーケンスで規定しているので、シーケンスを指定する事がテストの役割となります。即ち、シーケンサーにdefault_sequenceを割り当てる作業になります。

テストの選択


• UVMにはrun_test()というタスクがあります。run_test()は準備したテストを実行する為の機能です。run_test()にテスト名を指定する事が出来ますが、

実行時にテスト名を指定する方法が一般的です。この方法を使用すると、一回のコンパイルで複数のテストを実行する事が出来ます。

• シミュレーションを実行する時、コマンド・ラインでテスト名を指定する方法は以下の様になります。ここで、svsimはツールにより異なります。ベンダー提供のマニュアルを参照して下さい。

svsim +UVM_TESTNAME=test_rmw

UVMプリンター


• クラスのメンバーをプリントする為には、print()メソッドを使用します。このメソッドが正しく動作する為には、`uvm_fieldマクロを設定する必要があります。UVMは次の三種類のプリンターを定義しています。

プリンター機能

uvm_default_table_printer 表形式にプリントします。最も複雑なプリント処理となります。

uvm_default_tree_printer 各行に名称と値の対をプリントします。

uvm_default_line_printer 名称と値の対を一行にプリントします。

UVMプリンター

（使用例）


UVMプリンター

（使用例）


• 以下の例では、三種類のプリンターを使用しています。

• 次の様にして標準プリンターを定義する事が出来ます。

uvm_default_table_printer


------------------------------------

Name Type Size Value

------------------------------------

my_obj my_obj - @272

request integral 8 'hf0

grant integral 8 'h1

data sa(integral) 8 -

[0] integral 32 'h1

[1] integral 32 'h2

[2] integral 32 'h3

[3] integral 32 'h4

[4] integral 32 'h5

[5] integral 32 'h6

[6] integral 32 'h7

[7] integral 32 'h8

------------------------------------

uvm_default_tree_printer


my_obj: (my_obj@272) {

request: 'hf0

grant: 'h1

data: {

[0]: 'h1

[1]: 'h2

[2]: 'h3

[3]: 'h4

[4]: 'h5

[5]: 'h6

[6]: 'h7

[7]: 'h8

}

}

uvm_default_line_printer


my_obj: (my_obj@272) { request: 'hf0 grant: 'h1 data: { [0]: 'h1 ... [7]: 'h8 } }

programブロック

（重要な制限）


• SystemVerilogにはprogramというコンストラクトがありますが、UVMでは使用すべきではありません。

• program内の論理はreactive regionで実行するのに対して、UVMはactive

regionで実行します。従って、タイミング制御が正しく行われません。



• この章では、UVMを使用する為の手順を詳細に解説しました。

• これらの知識があれば、UVMを試す事が出来ます。もし、不明な点があれば、文献（[2],[7]）を参照して下さい。

• これまでの知識があれば、文献[2]を完全に理解する事が出来ます。

この章では、多くの章の内容に関連する知識を纏めて紹介します。

論理合成に関する制約については、文献（[8]）に依存する所が多々あります。

第１８章

付録


シミュレーション領域（[1]）（simulation regions）


Preponed

Active

Inactive

NBA

Observed

Reactive

Postponed

Re-inactive

Re-NBA

直前のtime slot

次のtime slot

a = b;

#0 a = b;

q <= d;

Assertions

Programのblocking

assignments

Reactive の #0 a = b；

Reactive の q <= d;

参考の為に、各regionには代表的な実行命令が添えられています。

完全な、regions図は文献[1]を参照して下さい。

SystemVerilogと論理合成

（その１）


• SystemVerilogに追加された多くの機能は検証をターゲットにしています。設計作業で使用される事を前提としていません。

• RTL設計を前提にして追加された機能は確かに存在します。例えば、always_ff、always_comb、always_latch、unique/priority if、unique/priority case等。然し、これらの機能が設計作業の効率向上に繋がる効果は限られていると思います。

• 但し、enum等の機能は論理の最適化に影響する度合いは極めて高いと考えられます。ベンダー提供のマニュアルを熟読する事が必要です。

• 一般に、論理合成はモジュール毎に行われます。それ故、モジュール外に定義されている変数、及び、ルーティンが参照されると、モジュール内にコピーされて合成されます。コピーする動作が不可能な場合、合成不可能である旨のメッセージが発行されます。

• 例えば、複数のモジュールで共有する変数は合成不可能です。何故なら、参照している各モジュールが独自にコピーをすると共有変数の役割をしないからです。

SystemVerilogと論理合成

（その２）


• コピーする動作が意味を持つ為には、変数、及び、ルーティンはautomatic

でなければなりません。 Automatic属性を持つコンストラクトは、使用される度に fresh copyが作られます。即ち、論理合成のコピー動作を正当化します。

• モジュール内に定義されている変数でも論理合成可能とは限りません。データ構造の複雑性には関係が無く、寧ろ、ハードウェアの特性からの制限に従います。

• 例えば、可変長の資源は合成可能ではありません。伸縮自由なハードウェアを実現する事は出来ません。一例は、string型の変数です。 string型の変数には10文字でも、2000文字でも割り当てる事が出来る為、合成可能ではありません。但し、const 属性を付加すれば、別の話になります。

• 同様に、可変長のアレイは合成可能ではありません。

論理合成の制約：パッケージ

（その１）


• パッケージ内で、以下の機能は合成可能です。

parameter、及び、localparam文。

const文

typedef文

automaticなタスク、及び、ファンクション

import文

論理合成の制約：パッケージ

（その２）


• パッケージ内で定義されたタスク、及び、ファンクションをモジュール内で参照すると、それらのルーティンはモジュール内にコピーが作られてから合成されます。

• パッケージ内の合成可能なルーティンはautomatic変数のみ含む事が出来ます。

• パッケージに含まれるグローバル変数は合成可能ではありません。

論理合成の制約：2-stateタイプ


• 2-stateタイプ（bit、byte、shortint、int、longint）は合成可能です。但し、それらは、4-stateタイプと同じ様に合成されます。詰まり、2-stateタイプの利点は考慮されません。

• シミュレーションでは、 2-stateタイプは0に初期化されますが、論理合成はそ

の様な初期化をしません。従って、合成後のネットリストのシミュレーション結果と元のRTL記述のシミュレーション結果は、一般には、一致しません。

• real、及び、shortrealは合成可能ではありません。

• stringタイプは合成可能ではありません。このタイプは可変長である為、合成が出来ません。

論理合成の制約：4-stateタイプ


• 4-stateタイプのin-line initializationは合成可能ではありません。例えば、次の初期化は合成可能ではありません。

• 但し、const修飾子が付いている場合には、合成可能です。

論理合成の制約：タスクとファンクション


• タスク、及び、ファンクション内でのstatic変数への初期化は合成可能ではありません。

• 一般に、static変数の初期化は合成可能ではありません。一方、automatic

変数の初期化（in-line initialization）は合成可能です。

論理合成の制約：オペレータ

（その１）


• 一般に、システム・タスク、及び、システム・ファンクションは合成可能ではありません。

• ++、及び、--オペレータは単独で使用されると、一般的には、合成可能です。

例えば、以下のforループは合成可能です。

• 然し、計算式の一部に使用される場合、例えば、a[index++]等は、一般

的には、合成可能ではありません。

• index += 100; 等の複合演算子は合成可能です。但し、右辺は簡単な

定数式に限られる場合が多いです。

• ==?オペレータは、右辺が定数であれば、合成可能です。

• insideオペレータは、右辺が定数であれば、合成可能です。

論理合成の制約：オペレータ

（その２）


• 階層的な名称参照（例えば、alu.result等）は合成可能ではありません。

論理合成の制約：structuresとunions


• Structuresは合成可能です。

• Packed unionsは合成可能ですが、unpacked unionsは合成可能ではありません。

• タグ付きpacked unionsは、合成可能か否かは不明です。ベンダーのマニュアルを参照して下さい。


• クラスは合成可能ではありません。

論理合成の制約：クラス

論理合成の制約：アレイ


• Unpacked及び、packedアレイの何れも合成可能です。一般に、多次元アレイも合成可能です。

• 但し、ダイナミック・アレイ、キュー、associativeアレイなどは、合成可能ではありません。基本的に、可変長オブジェクトは合成可能ではありません。ハードウェアは伸縮しません。

• アレイに関する代入文も合成可能です。

• タスク、及び、ファンクションの引数として指定したアレイも合成可能です。モジュールのポートしてアレイを指定しても合成可能です。

• アレイに関するquery関数（$dimensions、$left、$right、＄low、$high、$size、$increment等）は合成可能です。但し、アレイはfixedサイズを持ち、 query関数の引数はコンパイル時定数でなければなりません。

• システム関数$bitsは合成可能です。但し、引数としてサイズが変化するアレイ（キュー、associativeアレイ等）は許されません。

論理合成の制約：プロシージャ


• always_comb、always_latch、always_ffは合成可能です。これらの文は、合成を念頭に置いた機能です。

• alwaysは合成可能ですが、合成ルールが適用されます。

• initial、及び、finalプロシージャは合成可能ではありません。

論理合成の制約：文


• While文及びdo-while文は合成可能ですが、記述内容に制限が与えられます。

• 外部からdisableする機能は合成可能ではありません。

• break、continue、及び、return文は合成可能です。

• If文、及び、case文は合成可能です。但し、合成ルールが適用されます。

• unique-ifとpriority-ifは論理合成のfull caseに対応します。

• unique-ifは論理合成のparallel caseに対応します。

• unique-caseとpriority-caseは論理合成のfull caseに対応します。

• unique-caseは論理合成のparallel caseに対応します

論理合成の制約：モジュール


• refタイプのポートは合成可能ではありません。

• Genericなinterfaceポートは合成可能です。

• interfaceをポートに指定すると、通常、interfaceの信号をモジュール内に展開して合成します。

• modportを使用したモジュールは合成可能です。通常、modportのポートはモジュール内に展開されて合成されます。

参考文献


[1] IEEE Std 1800-2017: IEEE Standard for SystemVerilog – Unified Hardware Design, Specification and Verification Language.

[2] Universal Verification Methodology (UVM) 1.2 User’s Guide, Accellera, October 8, 2015.

[3] Chris Spear: SystemVerilog for Verification, 2nd Edition, Springer 2008.

[4] Kathleen A. Meade and Sharon Rosenberg: A Practical Guide to Adopting the Universal Verification Methodology (UVM), 2nd Edition Cadence Design Systems, Inc. 2013.

[5] Ashok B. Mehta: SystemVerilog Assertions and Functional Coverage, Springer 2014.

[6] Ben Cohen, Srinivasan Venkataramanan, Ajeetha Kumari, and Lisa Piper: SystemVerilog Assertions Handbook, 4 th Edition, VhdlCohen Publishing, 2016.

[7] UVM 1.2 Class Reference, Accellera.

[8] Stuart Sutherland, Simon Davidmann, and Peter Flake: SystemVerilog for Design, 2nd Edition, Springer 2006.

systemverilog from zero to one...本チュートリアルの概要 systemverilog from zero to one,...

Documents