Communication Box 16 （GPIB IPの作成 10）

段々と完成度が上がってきた。

左側の黄色いターミナルは内部の電源電圧（+5.0V, +3.3V, クランプ用電源）のモニタ用として付けたが、+5.0Vや+3.3Vは軽い負荷（～100mA～)ならここから電源を取ることもできる。

治具を作って、PIO部の動作確認をしている。

Communication Box 15 （GPIB IPの作成 9）

漸くハンダ付け作業が終わった。

COM(UART)の1～4はレベルコンバータICからFPGA基板までが離れていて、ここを単線で密着して配線するとクロストークが起きそうな気がしたのでシールド線を使って配線した。

FPGA基板側の電源はUSBコネクタから供給され、下の基板（ユニバーサル基板）はDCアダプタから供給することになるが、FPGA基板の電源ON/OFF状態と下の基板の状態を合わせるために電磁リレーで連動させるようにした。

殆どの部品をはんだ面側に実装したので、部品面側はすっきりしている。

以下のようなプログラムで、COMポートの簡単な動作確認をしてみた。

各COMポートとPCのCOMポートをクロスケーブルで接続し、PC側のターミナルソフト（minicom）で、文字列が受信できるか確認した。

COM1

COM2

COM3 ... コネクタをCOM2からCOM3へ繋ぎ変えた直後にスクリーンショットを取ったため、前半はCOM2の文字列が表示されている。（以下、COM4, 5も同様）

COM4

COM5

Communication Box 14 （GPIB IPの作成 8）

ふぅー、、、
何とか8割位は終わった。

GPIBの回路は右側の領域に実装しようと考えていたが、中央部の方が配線しやすかったので中央部に変更した。その結果右側の領域が空いたので、電源部もこの基板に実装出来そうだ。

RS232C部


GPIB部
クランプ用ダイオードは以下のように実装した。


。

部品面側


ケースに組み込んでみた


あと、もう少しで出来上がる。

Communication Box 13 （GPIB IPの作成 7）

漸く基板の実装作業を再開した。
基板は元々この筐体で使われていた物を使うつもりでいたのだが、その基板はランドが２～３個単位でパターンで繋がっているタイプのもので今回の用途では少々使い辛い。そこで、パターンをカットして一個一個独立したランドにしようとしたのだが、これが結構大変な作業のため断念して別のユニバーサル基板を使うことにした。

代わりの基板

この基板のはんだ面側は銅テープを貼ってベタグランドにする。これは電源（GND）の配線作業を省力化する為だ。

部品面側

FPGA基板の一部のコネクタがインチ座標にのっていない件は、以下のように一部を傾けることで何とか実装できている。


GPIB関係はFPGA基板の右側の領域を使うが、まだ実装していない。先に、RS232C (COM)の実装を行っている。RS232ドライバはTSSOPタイプを使うが、これを部品面側に実装すると、FPGA基板の配線を部品面側に上げてドライバに接続し、その先をまた、はんだ面側に通してコネクタに接続することになり面倒である。そこで、ドライバははんだ面側に実装している。


0.65mmピッチへのハンダ付け、、、中々シビレる作業だ。
この3連休中に終えられるかな。。。

Communication Box 12 （GPIB IPの作成 6）

GPIB IPの実機動作はこれからだが、日曜日の段階で別アーキテクチャでCOM I/F部の動作確認は出来たので、ここらで最初の snapshot を公開することとした。

いつもの通り、

< http://www.hi-ho.ne.jp/bravo-fpga/ >

に置いた。

ブレードPC

ヤフオクにクラウド型Webセキュリティシステムという名称の、見た目がブレードサーバーっぽい品が出品されていた。（この品の出品者は湘南の方にあるリサイクル企業で、以前このブログに書いた測定器っぽい装置もこの出品者のものだった。）　スペックの説明は無かったのだが、掲載されている写真を見て、何か惹かれるものを感じたので入札してみたところ、オークション開始価格の￥1,000で落札できた。この製品は純正の化粧箱（梱包箱）と付属品もちゃんと付属していた。オークションに出品される品でこれほど揃っているケースは珍しいんじゃないだろうか？

以下が入手した物（実際はこれが別のダンボールで包まれていた）


蓋を開けると、


付属品、


本体、

筐体の蓋を開けてみると、

HDDは外されているが、メモリは実装されていた。

CPUはヒートシンクに隠れて何が実装されているか不明なので、ディスプレイを接続して電源を入れてみた。

BIOSのSETUP画面

なんと、CPUはXeon (2.4GHz、4コア）だった。

メモリは16384MB ・・・ 私の認識が間違ってなければ 16GB !!!   しかも、このDIMMはECC付きのDDR3 SDRAMのRDIMMだ。  これが￥1,000（送料除く）で購入できた訳だ。。。すごくない？

まぁ、ちゃんと動作しなければタダのゴミでしかないが。。。

HDDを接続して動かしてみようとしたが、ファンというよりかはブロワーの音が尋常じゃない五月蝿さで、このまま使用するのは無理がある。しかし、付属していたUSERS MANUALを読むと、マザーボードの寸法はATXらしく、普通のPCのケースにも実装可能なようだ。そこで、現在は使用していないPCの筐体にマザーボードを組み込んで見たら問題なく収まった。

後はCPUクーラを調達する必要がある。近所のリサイクルショップで使えそうなジャンク品を￥100で購入してきたのだが、残念ながら上手く取り付けできなかった。仕方がないので分解してFANの部分だけを既存のヒートシンクに取り付けた。

で、HDDを接続し、電源をONにして起動したところ正常に立ち上がり、OSのインストールも問題なくできた。と言う事で、ハードウェアは問題なさそうである。

ISEで去年の今頃取り組んでいたDFT IPのRTLの合成をやって見た。

全く問題ない。ヒートシンクも熱くない。

合成に要した時間をDetailed ReportsのGeneratedの時間で見ると、Synthesis ReportからPost-PAR Static Timing Reportまでが9分20秒である。

比較のために、現在メインで使用しているPCでも合成してみた。

このマシンのCPUはAMD-FXでクロックは最大4.8GHzだ。

合成結果は以下の通り、

処理時間は殆ど同じだった。

現在メインで使用しているマシンと性能的に遜色の無いものが￥1,000（送料除く）で買えるなんて・・・しかも、メモリがECC付きだったりして信頼性はおそらくこっちの方が高い。

私の認識が正しければ￥1,000とは100円玉10枚と同じ価値の筈だ。今時、缶コーヒー10本も買えないが、その価格でこれだけの性能のマシンが買えてしまう。何ともすごい時代である。

Communication Box 11 （GPIB IPの作成 5）

Communication Boxのアーキテクチャは以下のような構成で考えているが、意外とFPGAのリソースに余裕があるので、自作CPU（ZUMI32）入りの別版を試してみた。


試したアーキテクチャはこれ。


クロックが50MHzの条件ではタイミングがMetしなかったので、40MHzに下げた結果、Metした。


リソース使用率（SLICE使用率）は、なんと 100% になった。これまで、FPGAのリソースを100%まで使い切った記憶が無いので少し感動した。今回使用しているFPGA(MachXO2）はI2CとSPIのハードマクロを内蔵しているが、現状使用していない。これらを使うようにすれば使用率は少し減る可能性はある。

Physical viewerで見るとこんな感じだ。

Floorplan viewerではこんな感じ。。。スゲー

zumi32（CPU）IMEM（命令メモリ）にプログラムをダウンロードして実行させてみた。

以前、zumi32用gccの移植をやった時に作成したLEDを左右に光らせるプログラムを、今回のアーキテクチャ用に変更して試した。

以下が動かした様子

これだけでは味気ないので、割り込みに合わせてCOM1に文字列を出力するようにしてみた。

以下が動かした様子...どうもデジカメの操作が不得手でピントがボケまくってしまった。

COM1の出力はFT232RLを介してPC上のminicomというターミナルソフトで受信し表示している。

それなりに動いている。  \(^_^)/

Communication Box 10 （GPIB IPの作成 4）

漸く、一通りの検証（simulation）が終わった。

例えば、デリミタが標準のEOIの場合はこんな感じだ。
（コントローラ、トーカ、リスナが別デバイスの場合）


ベクタはこんな感じ。

コントローラ


トーカ


リスナ


デリミタがCRの場合


デリミタがデータ数の場合
（このベクタでは256に設定している。）


上記は、コントローラ、トーカ、リスナはそれぞれ別のデバイスとしていた。
これに対し、以下はコントローラがリスナまたはトーカでもある場合。

トーカ


リスナ



次は、パラレルポールの動作である。

パラレルポールを使う場合、コントローラは予めPPEコマンドで各装置にステータスを出す信号線を設定する必要がある。


このベクタでは、station_2, 3,  4にそれぞれbit 1,2,4の信号線を割り当て、SRQ（service request）はstation_2が発生するというシナリオでシミュレーションを行う。以下の縦線で挟まっている部分がコントローラがパラレルポールを行っている部分で、DIOのbit 2のみが0になっている。つまり、station_2のみが信号線を0にドライブしている。コントローラ側のプログラムはDIOの0になっているbitを探して、そこを割り当てている装置に対してシリアルポールを行う。以下ではstation_2に対してシリアルポールしているので期待通りの動作である。


こんな感じで検証を行ったが、一つ一つ波形で見ていくのは大変なので、可能なものはなるべくOVAちっくにシミュレーションベクタ内でチェックするようにした。例えば、チェックの結果が良の場合は以下のようにGOODのメッセージを表示し、エラーの場合はERRORメッセージを表示する。

ベクタはこんな感じで書いている。


また、今回は仕様が若干複雑なので、念のためCoveredでコードカバレッジを計測しながら検証作業を進めた。Covered（http://covered.sourceforge.net/）はTrevor Williams氏が開発し、GPLで公開しているコードカバレッジツールだ。

私は通常、プロジェクトのディレクトリ階層を以下のような構造にしている。

sim/がシミュレーション関係のディレクトリで、上層のsim/は単体検証用、implement_X下のは各インプリメンテーションの全体検証用である。テストベンチはtbench下に、ベクタはvect下にそれぞれ配置され、シミュレーションの実行はsim_execで行う。このディレクトリにはシミュレーション実行のためのスクリプト（do_sim）があり、do_sim {オプション}  ベクタ名のような感じで実行する。

このスクリプトでcoveredを実行してコードカバレッジも計測できるようにしてある。

例えば、以下のように実行する。


do_sim -cov ... を実行するとsim_execディレクトリ下にcov/というディレクトリが作られ、そこにカバレッジデータが格納される。


カバレッジデータはベクタ単位のデータのため、最後にこれらをマージしてレポート化する必要がある。これは手操作で行う。　covered merge -o all.cdd cov/* がマージのためのコマンドであり、この場合、all.cddにマージした結果が出力される。

今回のテストベンチではGPIB IPを4つインスタンスしており、コントローラ、リスナ、トーカといった動作は、ほぼ固定して検証を行った。そのため、一つのインスタンスのカバレッジを見るだけでは不十分であり、全インスタンスのカバレッジを見る必要がある。上図で2_xxx、3_xxx、4_xxx とあるのはそれぞれ、station_2、station_3、station_4のカバレッジデータである。

次に、all.cddからレポートを作成する。


そうして得られたレポートが以下である。

・ラインカバレッジ。

3箇所カバーされていない箇所があるが、これはcase文のdefault記述の部分で通常ここがヒットすることは無い。したがって、ラインカバレッジとしては100%と考えても問題ないだろう。

・トグルカバレッジ。

見れていないのは殆どがデータレジスタ等の任意のビットなので、値が振れていないということなんだろうが、振る舞いに関わる箇所ではなくて、ペイロードの中身の部分なので現状でもとくに問題ないかなと思う。

・組み合わせ回路のカバレッジ。

これも、現状でもとくに問題ないレベルだと思う。

ここに至までに、仕様追加やバグ修正等もあったので、問題なく合成できるかを確認した。
リソースの使用率は70%になった。前回は69%だったので若干増加している。


タイミングはMetしている。