木曜日, 6月 28, 2007

blocking代入とnonblocking代入

verilogのblocking代入とnonblocking代入は論理合成対象のRTL記述であれば
順序回路にはnonblocking、組み合わせ回路にはblockingと憶えておけば特に問題はありません。

しかし、シミュレーション記述の場合はその違いをちゃんと理解しておかないと思わぬところで痛い目にあうかもしれません。

ちなみになぜblocking,nonblockingというかご存知でしょうか?

blocking代入はその名のとおり、その代入文が完了するまでステートメントをブロックします。

対して、nonblocking代入の場合は代入のスケジューリングのみが行なわれて、遅延0で次の処理に移ります。


したがって、次のようなコードの場合(blk_nblk.v)、



a,b,cへの代入が行なわれるのはそれぞれ時刻20,50(=20+30),60(=20+30+10)となりますが
x,y,zへの代入が行なわれるのはそれぞれ時刻20,30,10となります。

この結果がどうなるのかというと、

# (a,b,c) = ( 5, 15, 10)
# (x,y,z) = ( 5, 10, 5)


どうですか?
予想と一致していたでしょうか?

特に注意するのはnonblockingの場合ですが、yとzへの代入はそれぞれ時刻30及び10に行なわれますが代入されるxの値は、式が評価された時刻(つまり時刻0)のものが使用されます。

ややこしいですね。

ちなみに波形はこんな感じになります。


水曜日, 6月 27, 2007

アサーションベース設計 原書2版

アサーションベース設計 原書2版

アサーションの有用性や適用方法などについて。
機能カバレッジについてもふれられています。

使用してあるのは、OVLやPSL,SystemVerilogなのでEDAツールに依存しない形で解説されています。

一見固そうですが意外と読みやすかったです。

はじめのほうにHPやIntelなど有名な企業での成功事例が載っているので、同僚や上司を説得するには良いかもしれません。

大規模化を続けるLSIの機能検証はもはやブラックボックスでは成り立ちません。

アサーションやカバレッジを利用して、設計担当者も設計・コーディングの段階から積極的に検証に協力していきましょう。

火曜日, 6月 26, 2007

[OVLチェッカー] ovl_never

ovl_neverは評価式が常に真ではないことを保証します。

ovl_never check_overflow (clock, reset, enable, (count>9), fire);

このように書くと、countの値が10以上になったときにassertionがfailとなり、メッセージが出力されます。

また、assertionがfailとなったサイクルでは、fire[0]が真(1)にセットされます。
これはその他のチェッカーも同様です。

デフォルトでは、評価式(test_expr)が0で無い場合(1,x,z)にassertionがfailとなりますが
`OVL_XCHECK_OFFがセットされていると、評価式が1のときのみfailとなります。

月曜日, 6月 25, 2007

v2html

v2html - verilog to html converter -

その名のとおり、verilogソースをHTMLに変換してくれるPerlスクリプトです。

キーワードを色分けしてくれるだけでなく、階層構造や信号を追っていけるので他人のコードを解析したり、レビューの時などに使えそうですね。

WindowsのActive Perlでも使えるようです。

自分はcygwin上でやってみましたが、特に問題なく使えてます。
一応、スクリプトの1行目のパスがPerlのある場所と一致しているかどうか確認してください。

こんな感じになります。

日曜日, 6月 24, 2007

OpenSPARC

今まで知らなかったのですが、SunがSPARCのRTLを公開しているんですね。

OpenSPARC


ちょっとビックリしました。

ソースはこちらで見れますが、Verilog HDLです。

広大すぎて、これをまともに見ようとするとそれなりの覚悟が必要。

しかしこれほどのものが公開されてるなんて。

こういった流れで、ハードウェアもオープンな方向に向かってくれるといいですね。

土曜日, 6月 23, 2007

OVLの導入方法

↓こちらにOVLの導入方法を簡単にまとめてみました。

OVL(Open Verification Library)

参考まで。

木曜日, 6月 21, 2007

アサーションとカバレッジ

OVL v2.0では、各チェッカーにassertion(assumption)機能だけでなくカバレッジ機能が追加されているものがあります。

しかし、カバレッジ機能についてはまだ十分ではないようです。

チェッカーのアサーション機能はその規定に違反したときに起動して、違反があったことを通知しますがその機能を利用して、シミュレーションがカバレッジポイントを通過したかどうかを確認することもできます。

例えばovl_neverを使って、カバレッジポイントを通過したときに真となる式をtest_expr入力に入れておけば、シミュレーション中にカバレッジポイントを通過した時点でチェッカーが起動して、通知してくれます。

このとき、severity_levelパラメータはOVL_INFOとしておき、msg入力にカバレッジポイントであるということを明記しておきましょう。

例えばこんな感じですね。
ovl_never
#(.severity_level(`OVL_INFO), .property_type(/*default*/),
.msg("Coverage point: Count Max."), .coverage_level(`OVL_COVER_NONE),
.clock_edge(/*default*/),.reset_polarity(`OVL_ACTIVE_HIGH),
.gating_type(/*default*/) )
cov_cnt_max_inst (.clock(ICLK), .reset(IRST), .enable(1'b1),
.test_expr((COUT==4'd9)), .fire(OFIRE));

水曜日, 6月 20, 2007

[OVL パラメータ] gating_type

OVLチェッカーのパラメータ、gating_type について。

gating_typeenable入力に対する振る舞いを指定します。

設定値は以下の3つ。

OVL_GATE_NONE
enable
入力は無視されます。

OVL_GATE_CLOCK
enable入力がFALSEの時、チェッカーは動作を停止します。
具体的には、チェッカーへのクロック供給が停止します。
したがって、内部の状態は保持されます。

OVL_GATE_RESET
enable入力がFALSEの時、チェッカーはリセットされます。

火曜日, 6月 19, 2007

assertionとassumption

assertionはその処理が正しく行なわれることをあらわす概念で、あるモジュールにassertionが設定されているとき、そのモジュール内での処理においてassertionの規定に違反しないことが期待される。

assumptionは仮定・想定の意味で、あるモジュールにassumptionが設定されているとき、そのモジュールに対する入力がassumptionの規定に違反しないことが期待される。

つまり、assertion/assumptionが設定されている場合、assumptionに違反しない入力に対してassertionに違反しない動作をする必要がある。

OVLではproperty_type`OVL_ASSERTを設定することでassertionを示し、`OVL_ASSUMEを設定することでassumptionを示す。

月曜日, 6月 18, 2007

OVL v2.0

OVLは2007年5月からv2.0になりました。

Mentor社発行の『Verification Horizons』によれば、

  • 合成可能なイネーブル入力とファイヤー出力付き ovl_[checker_name] モジュール
  • アービタ、FIFO用などの新規の18個のアサーション
  • クロックエッジ、リセット及びイネーブルゲートの極性をプログラム可能
  • グローバルデフォルト制御用の新規のマクロ
  • 主要なOVLのVHDLでの提供

などが新しい要素のようです。

また、チェッカーの名前が以前の'assert_[checker_name]'から
新しく、'ovl_[checker_name]'に変更されています。

旧来からある33のOVLアサーションについては'ovl_[checker_name]'と'assert_[checker_name]'(機能は旧来のまま)の両方が使えるらしいですが、新規のデザインには'ovl_[checker_name]'アサーションの使用を推奨とのことです。

アサーションモジュールにイネーブル入力とファイヤー出力が付いたので、それらをつなぎ合わせてより複雑な条件のアサーションを構成したり、また、合成可能なのでFPGAでのプロトタイピング時などにアサーションを組み込んだまま実装することで、エミュレーション時にアサーションをモニタすることも可能になるということのようですね。

日曜日, 6月 17, 2007

抽象化 おまけ

抽象化でコードはより人間の使う言葉に近づくことを説明した。
が、残念ながらその言語はどうしても"英語"になってしまうだろう。

プログラミング言語が高級になるにつれて
英語ができないものは不利になっていくことを最近特に感じる。

英語がわからないとコードを読めなくなる。

ただでさえ、情報量は英語の方が圧倒的に多いのに。

これは日本人の技術者にとって非常にやばい方向へ向かってるのかもしれない。
「エンジニアの必須スキルとして、まず英語」というのが冗談ではなくなりそうだ。

情報処理技術者試験の科目にも入れたほうがいいかもね。

土曜日, 6月 16, 2007

抽象化 その2

Verilogではparameterを使って、固定値をパラメータ化することできる。

パラメータ化による利点の一つは、再利用性を高めることができることだがもうひとつの大きな利点は数値を抽象化できることだ。

次のような仕様があったとする。

2ビットの入力signalについて、
2'b00を赤、2'b01を黄色、2'b10を青と定義する。
また、2ビットの出力ctrlについて、
2'b11を停止、2'b10を注意、2'b01を進行と定義する。
signalが赤の時、 ctrlは停止を出力、
signalが黄色の時、ctrlは注意を出力、
signalが青の時、 ctrlは進行を出力をすること。

この仕様に対して、次のようなコードを書いたとしよう。
case (signal)
2'b00: ctrl = 2'b11;
2'b01: ctrl = 2'b10;
2'b10: ctrl = 2'b01;
default: ctrl = 2'b11;
endcase

一応これでも仕様を十分満足できる。
が、一度仕様を読んでこのコードを見てもそれが正しいかどうか理解するのに少し苦労するだろう。

次の場合はどうだろうか。

parameter Red = 2'b00;

parameter Yellow = 2'b01;
parameter Blue = 2'b10;

parameter Stop = 2'b11;
parameter Caution = 2'b10;
parameter Go = 2'b01;

・・・

case
(signal)
Red: ctrl = Stop;
Yellow: ctrl = Caution;
Blue: ctrl = Go;
defautl: ctrl = Stop;
endcase

パラメータの定義の部分は少し注意が必要だがコードの本体の部分を理解するのはこちらの方がずいぶん楽だろう。
具体的な数値がすでになくなっているので抽象度が上がり人間の言葉に近くなっているからだ。

このように、同じ機能を実現するコードでも
抽象化することによって、ミスを減少したり、メンテナンス性向上させることができる。

ハードウェアではより低レベルでの効率化のため、各ビットに意味をもたせる場合が多くそのため、現在でもまだあまり抽象化されていないコードをよく見かけることがある。
例えば、先のsignalの定義で言えばbit1を見るだけでそれが青かどうか判断できるため、次のコードの方が良いと思う人も多いかもしれない。

if
(signal[1]) ctrl = 2'b01;
else begin
if (signal[0]) ctrl = 2'b10;
else ctrl = 2'b11;
end

しかし、EDAツールやチップの性能が向上してきている現在では、よりメンテナンス性の良い方法を選択した方が今後はよりしあわせになれるのではないだろうか?

抽象化 その1

コンピュータは全てのことを0と1だけで表現している。
いわゆる2進数というヤツ。

でも、いくらスーパーなエンジニアでも0と1だけで全てを把握するのは無理なので
16進数をつかったりして表現する。

0と1が8個並んでいるよりも、0~Fまでの値が2個並んでいる方がよほど楽だ。

最も、普通の人なら0~9までの数字が3個並んでいる方が理解しやすいが
人間の適応能力というのは大したもので、我々の業界では
32や64、256などの数字(16進数でそれぞれ0x20,0x40,0x100)を
「キリが良い」と感じてしまう重大な職業病が蔓延している。

16進数の方が2進数よりも扱いやすいのは、
まず第1に頭の中で処理をする数字の量が減ること
そしてもうひとつは値をある程度『記号』として意味をもたせることができるからだろう。

これも1つの抽象化だ。

抽象化は設計や検証のさまざまな場面で恩恵を与えてくれる。
なぜなら、抽象化されたものの方が人間が理解しやすいからである。

例えば次の2進数の数値をあなたは1週間後に憶えていられるだろうか?

1100101011111110.b

何の意味もない値を憶えておくことはかなり困難だ。
では、次の16進数の値ならどうだろう?

0xCAFE

これなら1週間後どころか1年、もしかすると一生憶えているかもしれない。
上の2つの数値は同じ値である。つまり、

1100101011111110.b = 0xCAFE

かなり極端な例だが、抽象化することで同じ値でもかなり扱いやすくなる。

ミスを減らしたり、理解を深めたり
この抽象化という概念はさまざまな場所であなたの味方になってくれる。

金曜日, 6月 15, 2007

ALDECのウェブセミナー

ALDECのサイトでOVLのウェブセミナーを公開しています。

ALDEC Verification Methodology Seminars (AVMS)

OVL以外にもいろいろとあります。

日本語版もあればうれしいのですが残念ながら英語のみです。

LSIの分野も設計に関する情報は少しづつ日本語でも手に入れられるようになってきましたが検証方面に関してはほとんどありませんね。

自分も英語は得意なほうじゃないので悲しいです。

日本にも有力なEDAベンダーが出てくればなぁ。

結局大元は向こうに握られてる感じですよね。