2013年11月23日土曜日

Communication Box 9 (GPIB IPの作成 3)

GPIBではバスの登場人物としては3者おり、情報を送るトーカ(Talker) とそれを受けるリスナ(Listener)、そして全体の進行を制御するコントローラだ。  バスに繋がっている各装置が勝手にトーカやリスナとして振る舞える訳ではなくて、コントローラからその役割を与えられる必要がある。もちろん、各装置が与えられる役割を実行する能力があることが前提であるが、コントローラがバスをコマンドモードにしてアドレスnの装置にTAnコマンドを送信してトーカに指定し、アドレスmの装置にLAmコマンドを送信してリスナに指定する。(リスナは複数指定できる)  その後バスがデータモードに切り替わると、指定されたトーカとリスナが通信を始める。  他にも通信を行わせる装置がある場合は現在の通信の完了を待ち、トーカとリスナの役割を振りなおす。 この「通信の完了を待つ」、つまり、通信完了を検出する手段としてGPIBには EOI という信号が用意されている。トーカは送信する最終バイトのタイミングでEOIをLにすることで、通信の完了を通知する訳である。 ところが、装置によってはEOIではなくデータの値で通信の完了を通知する装置もあるらしい。この最終データのことをデリミタと呼び、アスキーコードの CR や CRとLF が使われるようである。 この他、値ではなくてデータ数で終了を判定する場合もあるようだ。 … と言ったようなことが岡村廸夫氏の本「標準ディジタル・バス(IEEE-488)とその応用」に書いてあった。

今作成しているGPIB IPがコントローラの場合、EOIの検出ができるがCRやCR,LF、データ数の検出は出来ないので、出来るように変更した。

検出はリスナモジュール内で行う。


デリミタモードの為のレジスタが必要になるが、デリミタはトーカによって変わる可能性があるので、このフィールドは頻繁にソフトウェアから変更される可能性がある。既存のレジスタの空いてるフィールドに割り当てるのは、ちょっとバランスが悪いというかプログラムが煩雑(リードして更新したいフィールドを設定内容に変更して書き戻す)になるので、専用のレジスタを新設することにした。

データ数は最大1024バイトまで計数できるようにした。

この変更で必要な機能はほぼ実装できのではないかと思う。後はシミュレーションで動作検証を行うことになるが、その前に、communication boxのRTLに統合して合成し回路規模を見てみることにした。もしも、FPGAに入りきらなかったら機能の削減を考えなくてはならない。

communication boxのRTLとしては全てのモジュールが揃ったことになるので、まず、信号のピンアサインを行った。


そして、合成した。結果はリソースの使用率69%なので問題無し。


タイミングもOK


Physical Viewはこんな感じ


Floorplannerで見るとこんな感じ。
こっちの方がまだリソースに余裕があるように見える。


ということで、合成も成功したので検証に戻る。また、ピンアサインも決まったので基板の方の作業も再開する。


2013年11月17日日曜日

Communication Box 8 (GPIB IPの作成 2)

一応、GPIB IPのコーディングは終わって、シミュレーションを開始した。
最新のレジスタ仕様を以下に示す。
コントローラがバスに送るメッセージ用のFIFOを追加した他、レジスタ名がRCV、RX、TX等統一感のない命名の仕方をしてしまっていたので修正した。また、シリアルポール用のステータスデータ用にLINEレジスタ内に8bitのフィールドを設けていたが、規格によればデータは複数バイトも可とあるので、LINEレジスタは止めてトーカ用データFIFOを使うことにした。





各モジュールのRTLは以下の様になった。

・トーカモジュール
今回、このIPは50MHzのクロックで動作させようと考えているがGPIB バスのデータセットアップ等のタイミングは200ns以上と50MHzに比べると遅い。これに対応するため、前回は10MHz相当のイネーブル信号を作り、それに同期してトーカやリスナモジュールを動作させようと考えていたのだが、その方式は止めてセットアップ時間確保用のカウンタ c_setup を実装してタイミングを作ることにした。

・リスナモジュール


・レジスタ、コントローラモジュール
トーカ、リスナモジュールが物理層のプロトコルを担当しているとすると、このモジュールはデータリンク層を担当すると言えるかも知れない。個人的な趣味としては上位から読み書きされるレジスタ部と制御部は別モジュールにしたいところだが、GPIBの場合、そういう組み方だと作り辛いと感じる。そのため、現状こうなっている。








いつもの様にテストベンチを作ってシミュレーションを始めた。
テストベンチでは、GPIB IPとSN75160B、SN75161Bのモデルの組を1単位(STATION)として、これが4つGPIBバスに接続されている環境を作った。

以下は、LINEレジスタからのユニラインメッセ時と、マルチラインメッセージを確認している。ここではSTATION 1をコントローラとして動作させている。

各IPにアドレスを設定した後、コントローラ(STATION1)のLINEレジスタからIFC、REN等のユニラインメッセージ(またはコマンド)を発生させ、次にUNT、LA、SDC等のマルチラインメッセージを送信している。マルチラインメッセージではLA(リスナ指定)でSTATION2~4を順番に指定しているが、規格上バス上には複数のリスナが存在できIPの動作もそうなっていて問題ない。一方、トーカは1つしか存在できないが、波形では自局がトーカであることを示すtlk_enが順に1になっていて同時に1になっていないでのこれも問題ない。リスナ、トーカの設定を解除するメッセージSDC, DCLに対する動作も規格どおりで問題ない。

上記のテストベクタを以下に示す。

write_to_register ... 等はverilogのタスクで以下の様に記述している。



次はシリアルポールの動作を見てみた。
ベクタは以下のとおり

以下が結果

黄色い縦線の左側はアドレス設定やポーリングデータの設定等の準備部分であり、右側がシリアルーリングを実行している部分である。その部分を拡大したのが以下である。

STATION2~4にそれぞれ、2、3、5バイトのポーリングデータを設定しているが、ちゃんと全数転送されているので、問題なさそうである。


2013年11月10日日曜日

Communication Box 7 GPIB IPの作成

GPIB IPの作成に取りかかっている。
作成にあたり、IEEEのサイトでIEEE 488.1の規格書を購入しようと思ったのだが、IEEE-488.1 1987の価格が$111.00、最新のIEEE-488.1 2003に至っては$309.0もするので断念した。仕方がないので、以下の書籍を参考にして作成を進めている。

現状の全体的なモジュール構成は以下のとおりである。

外部仕様(レジスタ仕様)はまだ完全に固まってはいないが、以下のように考えている。UART同様、今回は割り込み機能は不要なのだが、これも検討しておくことにした。また、今回はコンピュータ側(コントローラ側)の機能があれば十分だが、将来装置側でも使いたくなるかもしれないので、そういう使い方もできるように仕様を考えた。



コーディングは下位層のgpib_tlkとgpib_lsnは一応終わって、現在は上位側のgpib_ctlに取りかかっているところだ。(60%位かな。) が、思いのほかややこしいバス規格のため、考え違いをしている可能性も排除できない。まぁ、実装してシミュレーションして実機で動かしてみれば判るんだろうけど。
gpib_tlk  (トーカモジュール)

gpib_lsn (リスナーモジュール)

 トーカモジュールはバスコントローラとしてのメッセージ送信もこのモジュールを介するので、上位からの送信要求があれば送信処理を行う。バスコントローラからTAでトーカ指定を受けていない状態で通常データの送信は出来ないが、その判断は上位モジュール及びソフトウェアが行う。
 リスナーモジュールはバスコントローラからLAでリスナ指定を受けていない場合は、通常データの受信は行わない(無視する)が、メッセージは常に受信する。また、上位モジュールは通常データとメッセージ用に別々のFIFOを持つので、受信データ(リスナーモジュールから上位モジュールへ渡すデータ)と同時にその属性情報もrx_typで渡している。

SRQに対するpollingはserial pollingとparallel pollingの両方を実装しようかなと考えているが、参考資料によるとparallel pollingはあまり使われないようなのでserial pollingだけにするかも知れない。


GTX1050Ti と Tesla m2050 No.2 (BNN-PYNQのtrainingをやってみた)

BNN-PYNQのtraining(学習)をやってみた。  手順は https://github.com/Xilinx/BNN-PYNQ/tree/master/bnn/src/training に記載されており、特に判りづらい点はなかった。 ・ mnist.py 実行...