夏休み自由研究サポート企画（音の実験）

昨日、夏休み自由研究サポート企画（音の実験）を行った。今年の中学生は反応が薄かった。女子中学生3人、男子中学生1人（うちの息子）だったが、ボイスチェンジャーで”われわれは宇宙人だ”をボイスチェンジしても、あまりうけなくて、張り合いがなかった。
はじめに正弦波の周期や周波数の説明をしたので、難しかったのだろうか？　例年はボイスチェンジャーをやってもらうと、大受けするのだけど？
とにかく、これで夏休みのイベントは終了したので、お仕事のほうをがんばらなければいけないが、来週は家族でお出かけの予定が入っている。

ハリー･ポッターと不死鳥の騎士団を見てきました

今日は、ラジオの自由研究サポートを午前中にした。なんかぽつぽつとノイズが入ってAMが聞きづらいそうだ。家の中だけなのか、外もそうなのか調べてみたらとアドバイスした。その他、電離層などを説明。
午後5時30分からハリー･ポッターと不死鳥の騎士団を見た。当たり前だが、原本からでは、相当省略されていた。でも、それなりに楽しめた。次回作も見ることにしよう。そういえば7巻、英語で出たのだった。日本語訳を待つことにする。

昔、通っていた大学

今度の土日の夏休み自由研究サポート企画に準備で忙しいので、PIC-Xマスタ・モジュールはお休み状態になっている。それでも少しずつ作っているのだが。。。
私の担当の音の実験は、主に音声の波形を見てみる実験だ。

思えば、もう30年近く前の大学4年生のときの卒論テーマが、音声認識、合成だった。古い建物の実験室で、Z80を使ったパーソナルコンピュータを自作するところから研究（といえるかどうかわからないが。。。)が始まったのだった。（当時はまともなパソコンがMZ80くらいしかなかった）その卒論の学生は4人一緒のチームとしてやっていた。フーリエ変換、FFTやLPC、PARCOR、ADPCMなどを勉強しながら、パソコンの筺体作りから始まったのだった。アルミパネル加工やLアングル切断などの工作を当時、スーパーハードと呼んでいた。
その後エブレンの上にラッピングピンのあるボードで、CPUボード、CRTインターフェース、SRAMメモリ(48Kbyte)、IOボート、AD/DA変換ボードなどを作成した。IOはトグルスイッチ、紙テープのリーダ、ライタとカセットインターフェースだった。そういえば紙テープライタのインターフェースを作ったとき（わたしではない）ドライブ用のダーリントントランジスタがぽんぽん飛んでしまったっけ。。。なぜかというと、ソレノイドに逆電圧阻止用のダイオードが入ってなかったのだった。
私の担当は、CRTインターフェースとカセットテープインターフェース。CRTインターフェースはキャラクタモードとビットマップモードが切り替えで、ビットマップモードは波形を表示するのに使っていた。こちらは大きなトラブルもなく、回路図完成後に3日徹夜で製作した。でも、カセットインターフェースは完成しなかった。規格はサッポロシティスタンダードだった。カンサスシティスタンダードよりもビットレートが速かったためだ。なぜ完成しなかったというと、シリアル通信用のICのクロックをX1倍のクロックを入れて、使ってしまったからだ。これでは、いったん受かってもどこかでクロックの同期が外れてしまう。非同期通信のモードではなく同期通信のモードを使ってしまった。当時は、そんなこともわからずに無駄な時間をすごしてしまった。OPアンプでウインドウ・コンパレータまで組んでがんばったのだが、基本的なところが間違っていたので、だめだった。なぜだめかわかったのは卒業後だった。今の方たちには、そのような無為な時間をすごしてもらいたくない。”シリアルインターフェース（RS-232C)の説明”には、そのような思いも詰まっている。
結局、卒論は音声の解析はそこそこに、パソコンを作ってマルチタスクモニタを作りましたということで終わってしまった。

なぜ、こんなことを思い出したかというと、私の後の2年間通っていた大学は移転してしまって、校舎が取り壊しになってしまった。最近、その大学から定期的にアクセスがあるようなのだ。T工学科のM先生、お元気だろうか？そろそろ、定年退官なのだろうか？
ご存知ならば教えてください。後で新しい校舎に行ってみたいと思っている。

PCI-Xマスタ･モジュールの難しさ

PCI-Xマスタ･モジュールは、あまり進んでいない。夏休み自由研究サーポート企画があって、そっちに時間がとられているのもあるが、ターゲットだけならば簡単だが、マスタも入れるとなるとXilinxのFPGAのIOB特有の問題が出てきてしまう。
AD (アドレス・データ）はなるべくIOBのFFにマップしようと思っているし、そうでないと、タイミング的にも厳しい。また、絶対にひげが出ないようにするために、またIOBのFFに入れるために、ADの出力バッファ制御入力はFF出力からドライブするようにしている。ADの出力論理も同様だ。ターゲットの時に、このようになるように最適化してあるが、ここにマスタの出力を追加する必要がある。IOBに出力バッファが2つあって、ターゲット用、マスタ用に使えるのならば簡単なのだが、(Virtex2-proです）そうではないので、マスタの論理を追加する必要がある。しかもFF出力ではなくて、その一つ前の組み合わせ回路出力をターゲットとマスタを合わせて、IOBのFFで受けるようにする必要があるのだ。クリティカルパスの問題も気になるし、その辺が難しい。その前にFFで受けられれば良いのだが、PCI-Xの仕様的にそれは許されない。
ADはターゲットもマスタ・アクセスもRead, Writeがあるので、そのような問題が発生する。
FRAME#, IRDY#, DEVSEL#, TRDY#, STOP#などは、ドライブするモジュールがターゲット、マスタで一意に決まるので、そのような問題はない。
その辺は前のPCIが参考になるはずなのだが、もうまったく忘れちゃっているので、最初から考えたほうが速そう。前も確か苦労したと記憶している。

夏休みですね～

うちの子供たちも夏休みだが、このブログも夏休みということで自由研究や貯金箱の検索ワードでのヒットが増えているようだ。
夏休み自由研究サポート企画は今度の土日だが、私の担当の音の実験は、昨年に加えて、新しい企画を用意している。
来てくれた人のお楽しみということで。。。でも、どれだけうけるかはわからないが。。。
うちの娘の自由研究は、後で一緒にゆっくりやろうと思っている。いろいろな場所に行くことになるだろうと思う。内容は秘密。。。うまく、まとまると良いのだが。。。

というわけで、PCI-Xマスタ・モジュールが進まない。少しずつ、やっているんだけど。メインのステートマシンはできた。。。

お神輿、後片付け

7月21、22日とも小学生低学年のお神輿について、誘導などをしていた。なにぶんにも小学校１，２，３年生なので、中学生や、小学校高学年と一緒にお神輿をもんでいると、ばててしまうようだ。しょうがないので、疲れてお神輿が落ちてくると、持ち上げてサポートしていた。おかげで、今も腕がいたい。
まあ、無事に終わってよかった。
今日は午前中休暇を取って、お神輿を収納して、後片付け。午後から仕事に行ったが体が疲れているので、能率が上がらない。早く疲れを取って、がんばらねば。。。

お神輿（内もみ）

今日は小中学生お神輿、内もみをした。内もみは午前中に町内をお神輿をもんで歩いて、お払いをしておひねりをもらうのだ。お払いをして、お金をもらうのは中学3年生だ。うちの娘はお盆もち。おひねりを入れるお盆を持つ係りだ。お払いは同じ中学3年生の男の子。
画像は内もみの小学校高学年用のお神輿だ。雨が降っていたので、ビニールをかぶせてある。



夜は5時からお神輿を担ぐ、小学生は20時まで、中学生は21時までだ。大人のお神輿も出てにぎやかになる。
ほかの地区も6つの地区の中学生のお神輿も来て、同じあたりでもむので、けんかになりそうになる。それをとめるのが大変なのだ。。。
思えば、私が中学3年生のときに、ほかのお神輿と喧嘩になって、お神輿の胴体を破損させてしまった。今思い返しても悪い思い出だ。当時は棒も長く、喧嘩棒もついていて、一発触発の事態が、たくさんあったのだが、今は大人がついていて、喧嘩になりそうだったら止めるのだ。中学生みんな力あるし、とめるのが本当に大変。。。

お神輿準備

今日は（昨日か？)小中学生のお神輿の準備に夜中の12時までかかってしまった。うちの地区には小学生低学年、小学生高学年、中学生の3台の神輿がある。それの電飾の飾れ付けとかをやったのだ。最近のこの地区のお神輿は青色LEDやパトライトなどがついていて、ど派手だ。バッテリも中学生用は2台積んでいる。
明日は朝の6時30分から準備なのだが、内もみと言って、お神輿をもんで、各家々を回って、お払いをして、お賽銭をもらって歩くのだ。夜はまたお神輿がある。明日は夜だけだが、つらい週末になりそうだ。（疲れるから）

２５３０００アクセス

今日、２５３０００アクセスになりました。皆さんありがとうございました。
PCI-Xマスタは時間がかかりそうですが、とりあえずホストPCのメモリをマスタ・アクセスで1発読んでみて、スプリット・トランザクションになるかどうか見てみようと思っています。

PCI-Xバス・ターゲット・モジュールのテスト（終了）

PCI-Xバス・ターゲット・モジュールは Single Data Phase Disconnection を組み込んで、バックエンドがビジーの場合はリトライを返すことにした。スプリット・トランザクションを実装しないですんだので、大分簡単になった。
大体、ホストPCのプロセッサがPCI-Xボードにアクセスするときには、DWORDアクセスになるようだ。連続的に書いたり、読んだりしたら Writeの方はバーストになるかもしれないが、Read はDWORDアクセスのみかもしれない。よって、ターゲット・アクセスはとりあえず DWORD アクセスのみでスループットは求めないこととする。
下の図は、テスト回路で3回リトライを繰り返した後で正常に Write した時のChipScope波形だ。(クロックは133MHz)


下の図は、テスト回路で3回リトライを繰り返した後で正常に Read した時のChipScope波形だ。(クロックは133MHz)


このモジュールをインプリメントするうえで面倒なことがある。それは”PCI-Xバスへの出力信号のHDL記述”で制御信号をテーブルのように書いて、人間がわかりやすいようにしたのだが、自分で名前を指定していないので、論理合成で生成されるトライステート・バッファのイネーブルを制御するFFのインスタンス名がまちまちになることだ。制御信号の論理を変更した際にインスタンス名が変わってしまい、いちいち UCF で IOB=TURE; を変更している。これが面倒。インスタンス名を決められれば良いのだが、今のところその方法はわからない。

これでターゲットのテストは終了したので、明日からはマスタ・モジュールに移る。こっちはスプリット・トランザクションの実装方法を含めて、難易度が高い。

ラジオの自由研究

中学生の夏休み自由研究サポート企画で、中波ラジオをテーマにしたいという中学生が来るようだ。
中波ラジオなので、とりあえず、周波数、周期について教えて、AM変調波形をオシロで見せて、検波、フィルタして元の戻した波形を見せて、軽く原理を説明しようと思っている。
その後は、ラジオを作ってもらって、コイルアンテナの指向性による感度の違いを説明。アンテナの違いによる感度の違いも確認してもらったほうが良いかな？
もし、夜に外国の電波が混信するのが気になるのだったら、電離層を実感してもらうために、AMワイヤレスマイクとラジオを衝立で仕切って、上に反射板を置いたときにラジオが受けられるのを確認してもらえば良いかな？
その他の中学生夏休み自由研究サポート企画では、音の波形を見せる企画を担当している。

PCI-Xターゲット・モジュールは、休み中にSingle Data Phase Disconnection とリトライに対応させたつもりだった。シミュレーションは大丈夫そうだったので、実機に入れたら、認識しなくなってしまった。正常に応答は返しているように見えるが、どこが悪いのかは調査中。

洗濯機が来ました

先週の木曜日に洗濯機が壊れて、急遽、洗濯機を購入しました。
購入した洗濯機を昨日持ってきてくれることになったですが、台風で持ってこられるかどうか心配しました。でも、風雨はまったく問題なく、持ってきてもらって無事に設置してもらいました。あーよかった。これで洗濯ができます。といっても、奥さんの担当ですが。。。
洗濯機を購入する際には、実際に使用する奥さんが選びました。（私は口出ししない）斜めドラムに憧れがあったらししく。ナショナルの斜めドラムの機種を選びました。安い縦型の3倍の金額で痛いですが、これで機嫌よく洗濯してくれれば安いもんかな？と思ったしだいです。
実際に来てみて、洗濯するのを見てみると、やはり良いみたいですね。洗濯物が絡まないで、ワイシャツなどもピシッとしているように見えます。
一番良かったのが、今までの洗濯機、乾燥機、2台とも廃棄したことで、圧迫感がなくなったことです。今までは洗濯機の上に乾燥機があって、窓をふさいでいたので明るくもなりました。

ISE9.2iの SmartCompile (Partition) を試してみる

ISE WebPACK 9.2iをインストールしてみたが、新機能を見ると”SmartCompile (パーティションおよび SmartGuide) テクノロジを改善し、デザイン パフォーマンスを向上 ”とある。
以前書いた”Partitionの設定”で Partition を試してみたが、その時にはスパルタン３EスターターキットのLCD表示回路を使用した。DDR-SDRAMコントローラでもやってみたが、Partition の設定方法でエラーが出てしまった。前回はエラーが出たということであきらめてしまったが、今回はなぜエラーが出たのか？　Partition を使う上で注意することは何なのか？を検証してみたいと思う。
検証回路はVerilog2001版DDR SDRAMコントローラーだ。ダウンロードして試してみたい方は”Verilog2001版DDR SDRAMコントローラーのModelSimシミュレーションまとめ１”からダウンロードしてください。
まずはPartitionを設定する。”Partitionの設定”を参考にしながら、contrller_inst, read_data_module_inst, write_data_inst, addr_fifo_inst, wrdata_fifo_inst, rddata_fifo_inst, Test_LCD4HexDisp_instに Partition を設定し、DDRtestにフォーカスを戻してインプリメントしてみた。


そうするとエラーが出て、インプリメントができなかった。原因は何かと言うと write_data_module.v で FDDRRSE を使用している。FDDRRSE はIOBのDDRレジスタのことなので階層をキープできないということのようだ。
そこで write_data_module.v の Partition をはずしてしまうことにした。右クリックから Delete Partition を選んで Partition をはずす。それでもう一度インプリメント。そうしたらエラー(”FATAL_ERROR:Pack:pkibaphysmgr.c:1001:1.38.2.3 - Exception: Unable to find block”）になってしまった。


次に、上のモジュール ddr_sdram_cont_inst(ddr_sdram_cont.v) に Partition を設定した。そして、インプリメントしたところ、正常にインプリメントできた。だが、FDDRRSEの扱いから考えて、read_data_module.v のIOBにマップされる予定の入力用FFももしかしたらIOBに入っていないのでは？と考えてFPGA Editorで見てみた。(sd_dq<0>)


そうすると、思った通り、IOBの入力用FFにマップされていない。そこで、read_data_module_inst (read_data_module.v) も Delete Partition して、インプリメント。もう一度見てみたところ、やはりIOBに入力用FFがマップされた。


これらのことから考えると、IOBリソースを使いたい記述を書いたHDLファイルは Partition を解除するか、IOBリソースを使いたい記述を最上位の階層においておかなければいけないのだろう。
ただ、下の階層を Partition したときに上の階層も Partition しないと FATAL_ERROR になるのはどうしてだろう。マニュアルで要確認。

ISEヘルプによると
”デザイン階層の任意のレベルにある HDL、回路図、または EDIF ソース インスタンスをパーティションとして設定できます。 下位ソース インスタンスをパーティションとして設定すると、最上位モジュールも自動的にパーティションとなります。”
だそうなので、ちょっとおかしいような気もしますね？　バグ？

注：まだ、インプリメントしたものを実機にダウンロードして動作するかどうかはテストしていません。

2007/07/16：追記
どうもFPGA Editorで見たIOBリソースがおかしいので、もう一度 Partition を全部はずして、普通にインプリメントしてみた。そうしたやはりIOBの入力用FFの下は空になっていた。そういえばクロックの立ち上がりエッジで取るデータは使わないで捨ているのだった。


となると Partitionを使うと最適化が不完全になる可能性がありそうだ。（これは悪い場合もあるし、ノードが残っていて波形を観測できてラッキーという場合もある。）もう少し調査が必要なようだ。

2007/07/25：windyさんに教えてもらって、もう一度 Partition をやり直してみた。以前にエラーの出た条件と同じだったが、問題なくインプリメントできた。上のようなFATAL_ERROR が出たら、Cleanup Project Files を実行して、Project を初期化したほうが良いようだ。
windyさん、教えていただいて、ありがとうございました。

PCI-Xバス・モジュールのテスト（続き４)

今日もあまりできなかったが、Configuration Writeの波形を確認した。問題なさそうだった。
まだ、Single Data Phase Disconnection は実装していないが、Memory Writeコマンドにも応答するはずなので、やってみることにした。バイト・カウントが0以外、4以下でないとデッドロックするかもしれないが、とりあえず単発でホストCPUからのWriteだったら大丈夫だろうということでやってみた。


最初の信号がIDESL、その次がFRAME#, 次がIRDY#, DEVSEL#, TRDY#だ。やはり、FRAME#が 0 になったときにIDSELが 1 になっている。pcix_c_be_b_cが 7 なので、Memory Writeコマンド。次のpcix_c_be_b_cが 0 , pcix_ad_inが 00000004 なので、ホストのFunction Number 0, Device Number 0, Bus Number 0 つまりオール0だ。バイト・カウントが 4 なのでワード・アクセスだ。これだと破綻せずにうまく書き込むことができる。書き込んだデータが 00008000 。

ISE WebPACK9.2i

今日、ISE WebPACK9.2iが出たみたいです。
XilinxのダウンロードセンターからISE WebPACKをダウンロードしたら、WebPACK_SFD_92i.zipがダウンロードできました。表示は9.1iになっていましたが、ダウンロードできるのはどうやら9.2iの様です。

PCI-Xバス・モジュールのテスト（続き３)

今日は、ほかの仕事が入ってしまい、あまりPCI-Xバス・モジュールのデバックができなかった。
一応、PCI-Xコマンド・レジスタのEnable Relaxed Ordering.ビットを 1 にしてやってみたが、そのビットが1になっている他は変化がなかった。PCI-Xステータス・レジスタを読んでいるのは確認できたのだが、そのアクセスが、大分遅かった。BIOSで読んでいるのではなく、Linuxが読んでいるような感じだった。
大体これで良いのだろう。。。
Configuration Writeはベースアドレスレジスタに書けているので大丈夫だと思うが、やはり一応 ChipScope で見ておこうと思う。

今度はMemory Writeコマンドを実装してテストの予定。とりあえず、Single Data Phase Disconnection でやってみようと思っている。

夏休みの鎌倉、江ノ島旅行

去年、小学6年生だった息子は、鎌倉、江ノ島に修学旅行に行くはずだったが、病院に入院していたため行けなかった。
そこで、今年の夏休みに1泊くらいで鎌倉、江ノ島に家族5人で行ってみようと思っている。もう大分計画が遅いが、今から宿泊予約ができそうで、安くて良さそうな宿を知っている方があったら教えてください。

PCI-Xバス・モジュールのテスト（続き２)

これがPCI-Xのコンフィギュレーション・リードのChipScope波形だ。


Xカーソルの位置を見ると、framex_1dが 0 になった時にidsel_1dが 1 になっているので、コンフィギュレーション・アクセスだ。そのときのpcix_ad_inは 00041000 なので、コンフィギュレーション・アドレス 0 番地で、Function Number 0x04, Device Number 0x02, Bus Number 0 だ。pcix_c_be_b_cは 0xA なので、コンフィギュレーション・リード。

”PCI-Xコマンド・ステータスレジスタにアクセスが行っているかどうかが、まだ不明だ。”と書いたが、やはり Capabilities Pointer（0x34）にアクセスしていなかった。これはなぜかと調べていると、PCIステータスレジスタ(0x06)の bit4 (Capabilities List ビット）に 1 を立てていないためだった。これを立てるとCapabilities Pointer（0x34）にアクセスしに行くようになって、続いてPCI-Xコマンド・レジスタにアクセスに行くようになった。しかし、まだPCI-Xコマンド・レジスタの値は変更されていない。もう一度調べてみると、PCI-Xコマンド・レジスタのEnable Relaxed Ordering.ビットのデフォルトは 1 だが、これを 0 にしていたので書かなかったのかもしれない。これをもう一度変更して要調査。

”PCI-Xステータ・レジスタのFunction Number, Device Number, Bus Numberのフィールドの値がおかしい”件はDWORDリードアクセス時にも、framex_1dが 0 になった時にidsel_1dが 1 になっているためだった。これでコンフィグレーション・アクセスを判別していたのだが、DWORDリードアクセス時にもそうなるとすると、PCI-Xのコマンドもデコードしなくてはだめだ。修正後OKだった。



まだ、なぞがある。メモリ領域へのターゲット・ライトはどれでやるのか？
Memory Writeコマンドだと思うが、なぜDWORDリードはあって、DWORDライトはないのだろうか？

パソコンのチップセットはインテル® 3000です。

PCI-Xバス・モジュールのテスト（続き1)

PCI-Xバス・モジュールのテストの続きだ。
ChipScopeで見ると応答しないはずのところで応答しているようだと言うのがあったが、PCIコマンド・レジスタのビット1（メモリ領域イネーブルビット）が１のときにヒット判定をしなくてはいけないのを忘れていた。（I/O領域はうちのボードにはありません)　これでこの問題は修正された（と思う)。
PCI-Xコマンド・ステータスレジスタにアクセスが行っているかどうかが、まだ不明だ。0x34のポインタ値が入っていないので、修正したが、まだPCI-Xコマンドレジスタが0なので、アクセスに行っていないかもしれない。（PCI2.2からリスト方式で0xFFまでの任意の位置にレジスタを増やせる)
あとまだ、PCI-Xステータ・レジスタのFunction Number, Device Number, Bus Numberのフィールドの値がおかしい。。。

キーボード

たーぼのハードウェア設計記録さんの入力デバイスでキーボードの話があった。東プレのキーボードを使っていらっしゃるようだ。
私は古い富士通のパソコンのキーボードを使っている。FMV-KB321 1998-2 REV02Aと書かれている。FMV-KB321は年代によってキータッチが違っているようで、このキーボードが一番のお気に入り。
私はすごく軽いキータッチのキーボードが好きだ。と言うのも2年前の夏の蒸すときにキー入力をやりすぎて、左の人差し指のつめがはがれてきてしまったからだ。湿って滑りにくくなった指でメカニカルキーボードの重いタッチを好んでいたため、なってしまったようだ。医者にいったらなりやすいつめだと言われてしまった。
それ以来、軽いキータッチを好むようになった。去年、秋葉原のヨドバシに行って、ずらり並んだキーボードを片っ端から押してみて、一番キータッチの軽いロジテックのワイヤレスを買ってみたが、やはり今のキーボードに戻ってしまった。（東プレのキーボードも押してみたが、私には重かった）
このキーボードが壊れた時を考えて、良さそうなキーボードを探しておかないと。。。

PCI-Xバス・モジュールのテスト

昨日、PCI-Xバス・モジュールをインプリメントして、ボードにダウンロード。Linuxホストを立ち上げたら、一発で認識。やったーーー！！！
でも何か落とし穴がありそう。。。早速、ChipScopeを入れて波形を観測。やはりおかしい。アクセスが2つ出ている。原因を追究。そうか、PCIと違って信号がFFでラッチされているからステートマシンが狂った。。。
回避策をとったら、今度はPCIバスのエラーがホストで表示されて立ち上がらなくなった。ということは、規格上大丈夫だと思っていた、あのタイミングがだめだったと言うことか？　え、ほんとに。。。
それじゃわかりました。こうゆう風に回避！！！　やった、大丈夫。。。無事にLinuxがあがりました。"lspci -v"で見てもデバイスが見えるし、ドライバをinsmodすればモニタも立ち上がった。
でもChipScopeで見ると応答しないはずのところで応答しているようだ。
とりあえず止めにして、何とはなしに考えていると、原因がわかりました！！！　やってみよう。

(2007/07/08:追記　某誌のM氏風に書いてみたつもりです）
今デバックしているのは、PCI-Xのコンフィギュレーション・アクセス、ターゲット・アクセスを検証するためのテストモジュールです。

PCI-Xバスへの出力信号のHDL記述

前のPCI回路ではDEVSEL#などの制御信号の出力記述は、なるべく簡単化するように、DEVSEL#出力専用のステートマシンを作って、PCIターゲットのステートマシンがデコード・チェック・ステートだったら '0' に遷移というように書いていた。また、組み合わせ回路出力ではなく、必ずFF出力になるように書いていた。こんな感じ。


ハイ・インピーダンスにするためのトライステートバッファのイネーブルも必ずステートマシンのFF出力から入力できるように書いてあった。このように書くと、ステート数としては少ないが、一目見てわかりづらく間違いやすいし、他を修正したときに、影響があるのに気がつかないでバグになることが多かった。
そこで今回は論理合成ツールを信じてテーブルのように書いてみることにした。こんな感じ。

    process(clk, reset) begin
        if reset='1' then
            devselx <= 'Z';
        elsif clk'event and clk='1' then
            case mcs is
                when idle =>
                    devselx <= 'Z';
                when attribute_state =>
                    devselx <= 'Z';
                when Decode_check =>
                    if mydev='1' and tgt_busy='0' then
                        devselx <= '0';
                    end if; 
                when write_wait =>
                    devselx <= '0';
                when write_data =>
                    devselx <= '1'; -- データ転送したら非アクティブ
                when read_data_wait =>
                when read_data => 
                    devselx <= '1'; -- データ転送したら非アクティブ
                when tgt_discon_retry =>
                    devselx <= '1'; -- リトライ
                when turn_around =>
                    devselx <= 'Z';
                when bus_busy =>
                    devselx <= 'Z';
            end case;
        end if;
    end process;

そして、Synplify Proで合成し、RTL回路図を表示すると下のようになる。


上図を見ると、トライステートバッファへの入力、イネーブル入力ともにFF出力になっているのでOKだが、入力を見るとFF出力から、そのFFの入力の組み合わせ回路へフィードバックされている。これではIOBの構造上、IOB内のFFにアサインすることができない。
実際にインプリメントしてFPGA Editorで見てみると、やはりネットが２つに分かれている。（左端のピンクの矢印)


やはりフィードバックしているようだ。これだとIOBにはいらない。
IOBの中をのぞいてみるとこのようになっている。


緑の四角で囲ったのが、トライステートバッファの入力用のFFなどだ。
もう1つのトラーステートバッファのイネーブル入力はどうかと言うと、SynplifyのRTL回路図ではフィードバックがあるが、インプリメント後の下の図を見るとネットが１本だけある。


さらに、アサインされているスライスを見るとFFだけを使用している。（緑の四角の中）


これだとIOB内のFFにアサインすることができるかもしれない。
Constraints EditorでIOBをTRUEにするとトライステートバッファのイネーブル用のFFだけがIOBに入った。(”IOBの入力用FFを活用する”参照）


緑の矢印がそうだ。
PCI-X 133MHzのセットアップ時間は1.2ns、出力時間は3.8nsなので、なるべくIOBのFFにアサインしたいと思っている。
今はVirtex2pro VP30-6でセットアップ時間、出力時間のマージンはTiming Analyzerで見る限りはあまり余裕が無い。セットアップ時間がオーバーしていたが、出力時間が比較的マージンがあったので、+0.7ns程度DCMでフェーズシフトしてタイミングを満足させている。

PCI-Xターゲット・モジュールのシミュレーション

PCI-Xターゲット・モジュールのシミュレーションが大体仕上がった。下の図はPCI-Xのコンフィギュレーション・アクセスのReadとWriteの時のシミュレーション波形だ。本当は４クロック前からホスト側が AD をドライブしているはずだが、それは省略してある。


c_be_b の "AA" がコンフィギュレーション・リードを表している。次の "F0"のところがアトリビュート。その2クロック後で DEVSEL をアサートしている。つまり Decode C だ。その１クロック後で AD にデータを出力している。
次のトランザクションは c_be_b が "BB" なのでコンフィギュレーション・ライトだ。
とりあえず、ターゲットとコンフィギュレーションは実装できたので、次はインプリメントして確かめてみよう。

2007年6月のアクセス数

FPGAの部屋のブログも、ここで書き始めてから約2年が過ぎました。皆さん見ていただいてありがとうございます。私もいろいろな情報をいただいて感謝しています。これからもよろしくお願いします。
さて、2007年6月のアクセス数は24,906アクセスだった。毎月でこぼこはあるがこんなもののようだ。だいぶ、自分で検索してみている分があるので、下駄を履いているかもしれないけども。。。



しばらくはPCI-Xねたが多くなると思う。テスト環境ができてきたのでシミュレーションをして、Okだったら、インプリメントしてチップスコープで波形を観測する予定だ。結構、わたしにとってPCI-Xは、なぞの部分があるので、その辺を解明する予定。ただ単にトランザクションをするだけでいいならば簡単？なのだが、レイテンシの短縮とスループットを確保しようと思うとチューニングが必要になると思っている。