排他的論理和（exclusive OR） その２

排他的論理和の話をもう少し。
今回は主にアセンブラで使われる手法です。

A=Bの時、

A XOR B = 0

となりました。

つまり、

A XOR A = 0

です。

あるレジスタAXを０でクリアしたい場合、素直に記述すると

MOV AX, 0

となりますが、排他的論理和を使うと

XOR AX, AX

のように書くことができます。

何が嬉しいのかというと、まず"0"というリテラルを記憶しておく容量を節約できます。
あと、CPUによっては後者のほうが実行速度が速くなるかもしれません。
アセンブラの仕様にもよるので一概には言えないかもしれませんが、まあそんな感じです。

排他的論理和のもうひとつ重要な特徴が
同じ値で２回演算すると元の値に戻るということです。
つまり、

(A XOR B) XOR B = A

となります。

この特徴を利用すると、値の交換を行う際に一時的な値の退避場所が不要になります。

ある２つの値xとyを交換するとき、一般的な方法は次のようになります。

１．tempにyの値を代入

２．yにxの値を代入

３．xにtempの値を代入

この場合、xとy以外に一時的に値を退避しておくための記憶場所が必要になります。

しかし排他的論理和を使うと次の手順で値の交換をすることができます。

１．xにx XOR yの演算結果を代入

２．yにx XOR yの演算結果を代入

３．xにx XOR yの演算結果を代入

つまり、次のような記述で値の交換が可能です。

XOR AX, BX
XOR BX, AX
XOR AX, BX

はじめて見ると不思議かも知れませんが、
じっくりを追っかけていけば理解できると思います。

DoxygenがVHDLをサポート

Doxygen開始支援VHDL了

Gary的Digital Design日誌から。

中国語を読めるわけではありませんが見たままですね。

DoxygenでVHDLがサポートされるようになったとのこと。

なぜ、Verilog HDLよりも先に…

試していないのでどんな感じかはわかりません。
最近VHDLを使ってないので。

VHDL使いの方は一度試してみては？

排他的論理和（exclusive OR） その１

ある２つのデータAとBが一致すること
つまり、

A = B

を確認する回路をVerilog HDLで記述するにはどう書けばよいでしょうか？

assign equal = (A==B) ? 1'b1 : 1'b0;

こんな記述が一番妥当なところでしょうか。

ではもう少し具体的にどのような回路で構成されているか
わかるように記述するとどう書きますか？

A - B = 0

なので、次のように書けそうです。
（リダクション演算子については前回を参照）

assign equal = ~|(A - B);

しかし、データの比較のためにわざわざ減算器が登場するのも。。。

そこで、排他的論理和（exclusive OR）です。
ややこしい名前なので普通は"XOR"や"EOR"などと略します。

学生の頃、数学で習ったと思いますがXORの真理値表は次のとおりです。

真理値表

入力A	入力B	出力
0	0	0
0	1	1
1	0	1
1	1	0

0と0及び1と1の場合は0でそれ以外は1です。
つまり、２つが一致していれば0となり、異なれば1となります。

XORを使えば、

A XOR B = 0

となるので、次のような記述で２つのデータが一致しているかどうかを判断できます。

assign equal = ~|(A ^ B);

A ^ Bの演算結果は対応する各ビット毎のXORの結果となります。
つまり、C = A ^ Bとすると

C[0] = A[0] ^ B[0]
C[0] = A[1] ^ B[1]
…
C[i] = A[i] ^ B[i]

です。

ちなみに上記の３つの記述をXilinx ISEで論理合成にかけた結果、次のようになりました。
比較対照のA,Bはそれぞれ32bitとしています。
ターゲットデバイスは"xc3s1200e-4fg320"です。

【通常の比較】
Number of Slices: 8
Number of 4 input LUTs: 16

【減算による比較】
Number of Slices: 20
Number of 4 input LUTs: 40

【XORによる比較】
Number of Slices: 8
Number of 4 input LUTs: 16

普通に書くと、XORによる比較器が生成されるようですね。

高校生の頃だったと思いますが、数学の授業で初めて排他的論理和を習ったとき
名前もややこしいせいか、なんでわざわざこんな演算が必要なのだろうと感じましたが
この仕事をはじめてやっと、その意味がわかるようになりました。

別の仕事やってたらもう一生見なかったかもしれない。

リダクション演算子

Verilog HDLのリダクション演算子。

それほど頻繁に使うわけではないけれでも便利なもの。

たとえば次のように書くと（dataは複数ビットのバス）。

assign all_on = &data; // AND

assign bit_on = |data; // OR

assign parity = ^data; // XOR

all_onはdataの全てのビットが1の場合のみ1。

bit_onはdataのいずれかのビットが1でれば1。全てのビットが0の場合のみ0。

parityはdata中に奇数個の1がある場合は1。偶数個の1があある場合は0となる。

つまりそれぞれこんな感じ

all_on = data[0];
for (i=1; i < DATA_WIDTH; i=i+1) 
  all_on = all_on & data[i];  

bit_on = data[0]; 
for (i=1; i < DATA_WIDTH; i=i+1) 
  bit_on = bit_on | data[i];  

parity = data[0]; 
for (i=1; i < DATA_WIDTH; i=i+1) 
  parity = parity ^ data[i];

ビット幅を気にする必要がないので楽ですよね。

アサーションを使いましょう

と言いつつ、私も実際の業務で積極的に使っているわけではないので自分にも向けて。

アサーションとは、デザインが実行されている間、常に成立すると期待されている条件や動作を宣言することです。

たとえば、

このデザインでは仕様上、入力よりも出力のほうがスループットが高いので
デザイン中のFIFOのFullフラグが立つことは決して無い。

という場合は、「Fullフラグは常に偽である」と宣言します。
これがアサーション。

もちろん、コード中にこのコメントを挿入しても何の効力もないので
（コードを読んだ人間が設計者の意図を読み取れるというメリットはあるが）
何かしら効力のある方法でアサーションを使わなければなりません。

アサーションを記述する方法としては、PSLやSVA（SystemVerilog Assertion）などがあると思いますが、シンプルなアサーションであれば普通のVerilog HDLでも記述できます。

先の例だと、コード中にこんな具合に記述してやるだけです。

`ifdef SIMULATION

always @(posedge CLK) begin
if (FIFO_FULL!=0)
$display("Assertion failed! FIFO full flag should be always 0.");
end

`endif

それほど手間ではないでしょう？

一度記述しておけば、シミュレーションを行うたびにいつもアサーションがデザインを監視してくれるのです。

また、アサーションはデザインの内部で監視しているので、デザインの外で出力をチェックするよりも、バグの原因に近い場所で問題を発見できます。

さらにアサーションの後段の部分に対しては、アサーションでチェックされている部分については常に保障されていることになります。
アサーションを用いず、出力をチェックする場合は、問題が発生した時にデザイン全てを疑わなければならないかもしれませんが、アサーションを記述しておくことで、少なくともそのアサーション周辺やそれらに関連する部分は正しく動作しているということがわかります。

少しの手間が必要ですが、アサーションがあなたのデザインを守ってくれるんです。

シミュレーションだけでなく、アサーションはフォーマル検証にも使用されます。
この場合、フォーマル検証が使えるEDAが必要ですが
テストベンチを書かずにバグを発見することができます。
数学的な手法を用いて、あるデザインにおいて宣言したアサーションが常に成立するかどうかを検証するのです。
あまり大きなデザインには不向きかもしれませんが、動的な検証手法では見つけにくいバグを発見することができるようです。

いきなりOVLなどの検証ライブラリを使用したり、高価なEDAを購入することは難しいという方は、まずは簡単なVerilog HDLでの記述からはじめてはいかがでしょうか？

検証環境を評価するツール

米Certessの検証環境評価ツール「Certitude」、欧米市場に続き日本でも本格的な利用が始まる～ベルギーのVCから100万ドルを追加調達

EDA EXPRESSより。

デザインを検証する環境を作っているときに、
「さて、この検証環境自体はどう検証するべきか？」
と思ったことはないでしょうか？

そういったことが心配な場合にこのツールは役に立つかもしれませんね。

個人的にはデザインと検証環境ともにバグがあるばあいでも
通常結果はNGになり、結果がOKになるのは仕様を誤認している場合ぐらいだと思うので
今までこういったものに必要性を感じたことはあまりありません。

ただ、意図的にバグを組み込んでそれを検証できるかどうかを確認するという発想は面白いですね。

費用対効果のほうがどれほどあるかはわかりませんが。。。

「OVM」、オープンソースとして一般配布を開始

ケイデンスとメンターによるOVMの一般配布が開始されました。

ケイデンスとメンターによるSystemVerilogベースの検証メソドロジ「OVM」、オープンソースとして一般配布を開始

次のサイトからダウンロードできます。

OVM World

AVMと違って、OVMはSystemVerilogのみのようです。

検証メソトロジー関係は興味があるので本やドキュメントなどは少し目を通していますが、まだ実際に現場で使ったことがないので、このようなものをどうやって使えばより検証の効率が上がるのかということはまだ具体的にイメージできていません。

メンターは『AVM Cookbook』のようなものを出してくれないのかな。
クラスのリファレンスやExampleコードなどはありましたが、それだけではまだ自分にとっては厳しいところです。

日本でもすでにVMMやAVMなどを使われているところはいくつかあるんですかね？

ちなみに↓こちらの記事によると
XSTでSystemVerilogサポート（たーぼ のハードウェア設計記録）

FPGAの設計環境も今年からSystemVerilogがサポートされるようになりそうです。

今年から本格的にSystemVerilogを採用するところが増えてきそうですね。

自分も勉強しなきゃ。

DWM JAN.2008 特集１ アルゴリズムのハードウェア化手法

あけましておめでとうございます。

せっかくなので久しぶりに少し書いてみます。
といっても、記事の感想程度ですが。

デザインウェーブマガジン 2008年１月号の特集１
『アルゴリズムのハードウェア化手法』

結構良い内容でした。

現在のシステムLSI設計を上流工程の視点からこのように具体的に書かれているものは珍しい。
ソフトをハード化する上でのメリット・デメリットも詳しく載っていて、ソフト・ハード協調設計をやる上でも有益な情報が多いと思う。

調べてみると記事を書いた森岡澄夫さんは
↓こちらの本の著者でもあるようだ。
HDLによる高性能ディジタル回路設計

実はこれ、自分が就職してから２年目ぐらいのころに結構お世話になった本。
特にモジュール間のインタフェース設計などはこの本で勉強しました。

LSI設計・検証関係の本は日本人の著者のものではあまりおすすめな物が少ないのですが、
この本はLSI設計エンジニア２・３年目ぐらいで初心者から中級者へのステップアップにはちょうど良いのでは思います。