GPIBではバスの登場人物としては３者おり、情報を送るトーカ（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で見るとこんな感じ。
こっちの方がまだリソースに余裕があるように見える。
ということで、合成も成功したので検証に戻る。また、ピンアサインも決まったので基板の方の作業も再開する。
0 件のコメント:
コメントを投稿