ぎっくり腰

今日、職場に行こうとして、あぐらの状態から立ち上がろうとしたら、腰に衝撃が走って、まっすぐ立てなくなってしまった。まるで、腰の曲がったおじいさんのようになってしまった。
とりあえず、午前中休みにして、整形外科に行ってきたが、やはり、ぎっくり腰のようだ。とりあえず、コルセットをもらって、マッサージ、暖めなどのリハビリをし、痛み止めなどの薬をもらって、とりあえず帰ってきた。
待ち行列に入っている仕事があるので、午後は行きたいのだが、どうなるだろうか？　何とかいけるかな？

思えば、最初にぎっくり腰をやったのは、30代の時だった。テニスをやっていたので、強い風の日に風下で打ち返していたので、腰が重くなり、2,3日後エアコンで冷えすぎていたせいもあって、靴下を履いたときに終わってしまった。
そのときは、夜にビールを飲んで寝たら、次の日に起きたら歩けなくなっていて、2日くらいずっと寝たきりだったので、今回のほうがましだ。

追記：結局、午後も仕事にいけませんでした。50mも歩けないのでは仕方がありません。腰がまっすぐになりません。でも、今は夜ですが、少し良くなってきたようです。月曜日には仕事が山積みです。行けるように努力しないといけません。明日もリハビリに行ってきます。

”Virtex-5 LX および LXT FPGA デザイン”トレーニング

昨日、”【 無償キャンペーン実施中！】ザイリンクス トレーニングコースのご案内”というメールがXilinXから来た。
そのメールによると

<<< 無償キャンペーン実施中！！>>>
受講料：42,000円 (3TC) のところ Virtex-4 FPGA の設計経験者
の方に限り、無償にて受講いただけます。

とのこと。Virtex4に実際ダウンロードして動かしたことはないが、Virtex4のお勉強で、インプリメントしているので、設計経験者だろうという強引な論理の元に申し込んだ。
コースの概要はこれ。
コーススケジュールはここ。
9月27日は予定があるので、10月30日に申し込んだ。
2ヵ月後で先が長いけど、今から楽しみだ。

PCI-Xのスプリット完了（１Kbyte)

昨日は、ホストパソコンのメモリ1Kbyteをバースト・リード (マスタ･アクセスでPCI-X Memory Read Block) してみた。今まで同様に、スプリット応答(TAG番号0）が返ってくる。スプリット完了トランザクションでデータが帰ってくる前、または途中で、次の1Kbyteのバースト・リードコマンドを発行して、スプリット応答(TAG番号1）で返された場合、512byteごとに分割されて転送されてしまった。
TAG番号0のリードデータが、最初のスプリット完了トランザクションでターゲット・ライトされるが、512byte転送したところで、次のTAG番号1のリードデータのスプリット完了トランザクションが始まってしまう。TAG番号1のリードデータのスプリット完了トランザクションが512byte分終了したところで、次に、TAG番号0のリードデータの残りの512byteが転送された。


上図のXカーソルのトランザクションはTAG番号1だが、その後ろのOカーソルのトランザクションはTAG番号0。
このチップセットでは、512byteごとに、順番が入れ替わってしまう可能性があるため、512byteごとにリードしないとだめなようだ。
PCI-Xの仕様書を見ると、複数スプリット応答していると、帰す順番は任意だと書いてある。順番を守る必要があるならば、一度スプリット完了のトランザクションが終わってから、リードを発行しろ、と書いてある。

覚書
BIOSがPCI-Xコマンド・レジスタに書き込んでいるか？ No.
BIOSがPCI-Xコマンド・レジスタを読み出しているか？ No.　(PCI-X Capability ID(0x07)とNext Capability(0x00, 終了）のみリード)
BIOSがPCI-Xステータス・レジスタを読み出しているか？ Yes.

グーグルマップをブログに貼る

最近、グーグルマップをWebページに貼れるということで話題になっているようだが、私もやってみた。グーグルマップの使い方のグーグルマップをサイトで使うのページを参考に、良く行く公園の茨城県県西総合公園のグーグルマップを貼ってみた。


拡大地図を表示

この場で拡大縮小できて、非常に便利。。。これは良い。
以前のブログに書いた那珂川の石にも貼り付けてみた。

カスピ海ヨーグルトメーカー

土曜日、日曜日と息子の自由研究をやっていた。やっと終わった。よかった～。

8月の最初に、いつも作っていたカスピ海ヨーグルトがくさくなってだめになってしまった。種ヨーグルトを分けてもらおうと、いろいろ知人に聞いてみたが、誰も作っていなかった。それじゃー、ということで、ネットでカスピ海ヨーグルト菌を探していると、カスピラボというカスピ海ヨーグルトメーカーがみつかった。
これは、冬に保温するだけでなく、夏には冷却して27℃に保つという。常温で作っているときには、いつも、夏は出来が悪かったので、冷却してくれると良いなと思って、高かったけど購入した。
最近は、2日に一回は1リットル分、作っている。子供たちもカスピ海ヨーグルトメーカーで作ると出来がいいので、毎朝食べている。
とろとろしていて、糸を引く感じのヨーグルトになるので、滑らかでおいしい。普通はできたヨーグルトを種にして、また作るが、2ヶ月ごと種菌から作ったほうが良いそうだ。確かに、だんだん粘りがなくなるので、そうかもしれない。
これに、自家製ブルーベリージャムやリンゴジャムを入れて食べるとまたおいしいのだ。

チップセットのPCI-Xスプリット完了トランザクション

PCI-Xマスタ・アクセスで、512byteをバースト読み出ししてみた。そうすると、例によってスプリット応答が返ってきた。
チップセットからのスプリット完了トランザクションはADB(Allowable Disconnect Boundary, 128byte) ごとにイニシエータが中断した。
この辺が疑問だったのだ。512byte分を全部、チップセットにバッファリングしてから一気に出すのか？　それともイニシエータ中断しながら、出すのかが疑問だった。スループットを捨てて、レイテンシを取っているようだ。レイテンシは約1usec。当然、以前の32byteの時の750nsに比べて伸びている。128byteのデータをキャッシュして出しているか、それとも送れる見込みができてからスプリット完了トランザクションを出しているからなのだろう。何しろPCI-XはPCIと違って、128byteごとにしかトランザクションを中断できない。
最初のスプリット完了トランザクションはアトリビュート･フェーズで、512byte分のバイト･カウントを通知している。中断した後の2つ目以降のスプリット完了トランザクションは、当然バイト・カウントを適合させている。（次は512(0x200) - 128(0x80) = 384(0x180)ということ）

注：PCIでは、例えばホストパソコンのメモリをリードするときに、規定時間以内でリード・データが用意できないとリトライをしていた。リード・データが用意できない間は、何度でもリトライを繰り返してしまうために、パスの使用効率が落ちてしまった。PCI-Xはそれを避けるために、なるべくリトライを使わずに、リードを要求するトランザクションにちょっと待ってて後で返事するよ（スプリット応答）と言って、後でデータを要求元にライトする（スプリット完了トランザクション)ようにした。

次は、Maximum Outstanding Split Transactionsがいくつかを探る。

Xcell Journal - 61

Xilinxから Xcell Journal - 61 のお知らせメールが来た。
Web上で見えるということでクリックしてみてみたら、本当に雑誌を見ているように見える。なかなか良い。PHPでできているようだ。
NTX bookというリーダーを使っているようだ。ズームやページめくりの機能があって面白い。Xilinxは Xcell Journal の送付をやめて、これで代替することにしたのだろうか？　それとも後で雑誌は送ってくるの？

PCI Express and FPGAs という記事を斜め読みしたが、Virtex5 PCI Express ハード・エンドポイント X8 のレイテンシは、20から25クロック・サイクルだそうだ。X8 だとインターフェースを250MHz, 64bit幅と、125MHz, 128bit幅から選べるようなので、それぞれレイテンシは80ns～100ns, 160ns～200nsになるようだ。
多いのか？　少ないのか？　よくわからないが、125MHzバスを使用すると、データをリードしようとして、FPGAからパケットを送るのに200ns, パケットが到着して、メモリコントローラを動作させ、メモリからデータを読んで、リードデータをPCI Expressのパケットとして送って、FPGAでパケットを受け取るのにまた200ns。うーむ、やはり、なんか、PCI-Xに比べてレイテンシが大きい気がする？

USBひんやりクッション

shirouの現実touhi[wp]さんの空調ベッドで、USBひんやりクッションを知った。長く座っているとお尻が蒸れて困っていたので、購入した。（詳しい説明はこちら）
USBから電源を取ってファンをまわして、座布団にたくさん開いた小さな穴から空気を出して、お尻を乾かす仕組みだ。
使っていると、結構振動がくる。長く使っていると、痔持ちにはお尻が危ない感じになる。蒸れたときに、ちょっとつけて、消すという使い方がよさそうだ。
欠点を書いたが、お尻が蒸れているときにつけると快適。まだ、新しいので、ビニールのにおいがする。（私はこれが苦手、新車もにおいがいや）

PS/2キーボードをキャラクタ・ディスプレイ･コントローラにつなぐ

28万アクセス突破しました。皆さん、ありがとうございます。

スパルタン3スタータ･キットを使って、PS/2キーボードをキャラクタ・ディスプレイ･コントローラにつなごうとしていた。キーボードのキーを押したときに、ディスプレイにそのキーの文字を１個、表示するようにしたかった。
PS/2キーボード・インターフェースはすでに、ほかの人が作ったものがあったので、それをキャラクタ・ディスプレイ･コントローラにつないだ。
そうすると押したキーコード以外に、空白ともう1つキーコードが入ってしまった。
これは、スパルタン3スタータ･キットのユーザーズマニュアルによると、キーを押したときに、キーコードが出て、キーを放したときに"F0"というキー･アップ･コードを出し、その後同じキーコードを出すそうだ。
まともに表示するには、キー･アップ･コードとキーを放したときにキーコードを無視する必要があるようだ。
後、気になったのがクロックだ。スパルタン3スタータ･キットのユーザーズマニュアルによると、PS/2インターフェースはクロックとデータで構成されていて、クロックのエッジでデータの有効をあらわす。どちらの信号もオープン･ドレインで、クロックエッジからデータのセットアップ時間、ホールド時間が最低5usと長い。
（スパルタン3スタータ･キットのユーザーズマニュアル28ページのテーブルと図を引用させていただきます)


現在は50MHzのクロックを25MHzにして、PS/2のデータとクロックをサンプルしているので、特にオープン･ドレインの立ち上がりでのサンプル間隔として、40nsは少し短い気がする。
従って、1us間隔くらいでサンプルのイネーブルを追加しようと思っている。今でも（25MHzでサンプルしても）ちゃんとキーコードは見えるが、いろいろとオープン･ドレインの立ち上がりの鈍さには泣かされてきているので信用ができない。（小さい抵抗をつければ立ち上がりは速くなるけどね。。。オシロで見てみるという話もあるが。。。）
一応、1usサンプル間隔に変更して、２つのコードを無視するように改造して、キーボード入力ができるようになった。（といっても、押したキーを表示するだけだが。。。）
まだ、シフトに対応していないので、小文字は出ないし、（シフトキーもコードが出るようだ。）Enterキーを押しても改行するわけでもない。どの程度サポートするかは検討中。

なお、PS/2キーボードに関しては、日曜デジタルさんの”PS/2に挑戦”が詳しい。

追記：25MHzクロックで直接PS/2のデータ、クロックをサンプルしても問題ないようです。クロックで直接サンプルした方がテストベンチ書きやすいから、こっちのほうがいいかな？
キーボードからの波形はどんな波形が来ているのか、オシロで見てみたい。

人間ドック

今日は人間ドックだった。
いつもドックは胃の内視鏡をやっている。内視鏡をやると、いつも具合が悪くなっていたが、今年の医者は内視鏡がうまかったようで、割と大丈夫だった。
去年は、大丈夫そうでも、１口水を飲んだら気持ちが悪くなって、３時間くらい寝ていたが、今年は、水とバナナを食べられた。それでも、調子が悪くて寝ていたが、お昼も食べられたし、良かった。

最近、FPGAの話題がないが、家の中の気温が今、32.5度なのだ。エアコンはあまり好きじゃないので、勉強する気が起きない。なので、今は夏休み。

本棚の製作

最近、FGPAFPGAの話題が少なくて申し訳ない。
最近、漫画の本などが増えてしまって、本棚が足りなくなって困っている。それで、今日はお手軽な1X4材で本棚を作った。結構木工も好きなのだ。
1X4材の2438mmの板を縦の木材に使い、棚板は600mmにホームセンターで切ってもらった。1X4材だと幅が足りないので、２枚を180mmの1X4材でつないでいる。
つまり、この本棚は2438mmの1X4材が４枚、600mmの棚板が22枚、180mmの連結のための板が８枚でできている。
木ねじは木割れしにくい木ねじがあったので、それを使った。この木ねじを使うと下穴を開けなくても木が割れないので重宝する。
午前中に木材を購入して、午後いっぱいでできた。お手軽である。ただし、電動ねじ回しは必須である。

那珂川の石

今日は午前7時に家を出て、那珂川の上流（あまり上流じゃないかもしれないが)、中流、下流（あまり下流じゃないかもしれないが）の3点で石を見てきた。
行ったのは、奥さんと一番下の娘、一応じゅうけんきゅうのつもり。
栃木県まで2時間30分くらいかけて到着。那珂川の水はきれいだった。やはり石は大きいのが多い。岩か？
なお、川にどこから降りられるのかのリサーチが難しかったので、基本的にやなを目指している。やなのある場所ならば、川に絶対降りられるはず。。。それにおいしい鮎もいただけるという寸法だ。といっても、私は鮎はあまり好きじゃないのだが。。。


栃木県太田原市寒井の余一やなだ。


拡大地図を表示

石の観察、採集をする。花崗岩、安山岩、せん緑岩などを見つける。
次に、30数Km下って、那須烏山市の舟戸観光やなへ。行ってみたら休業だった。食事ができずに残念。


拡大地図を表示

でも、川原には下りて観察した。ここもいいところ。水遊びをしていた人もいた。水もきれい。結構人がいる。以前の場所でもいたが、鮎つりをしている人も結構いる。
ここでも石を観察。やはり、石は前よりは小さくなっていた。


ここで、飯食べられなかったので、次の目的地に向かう途中の一ッ石観光ヤナで昼食。ほかの二人は鮎の塩焼きだったが、私はうな丼を注文。やけに皮がぱりぱりしていると思ったら、うなぎも泳いでいるのを料理するようだ。（下ごしらえはしてあったのかもしれないが。。。)
これから御前山に向けて出発。


拡大地図を表示

御前山では、道の駅に行ったら、みんな川原でキャンプや水遊びをしていた。うちらも混ざって、川に入ったが、ここでも水はきれいだった。石も観察、採集したが、やはり小さいのが多くなっている。


これで、石のじゆうけんきゅうは終了。
本当は大洗の河口まで行けたら良かったが、目的は石なので、この辺で終了。
水戸に向かって、高速で家に帰った。総計250km位走った。疲れました。

ちなみに、じゅうけんきゅうはキーワードヒットしないように、わざとひらがなにしてあります。

2007/08/18:　今日、石のじゅうけんきゅうのポスターが完成しました。よかった～。。。これで1つ肩の荷が下りた。

化石のクリーニング

今日は一番下の娘と一緒に茨城県自然博物館に行ってきた。
ホームページを見ると１年間のパスがあって、値段も安いので、これを購入。大人で大体２回行くと元。子供はさらに安い。
いつもの展示物を見た。いつ見てもそれなりに楽しめる。
速めに食事をしてから、自然発見工房へ行って、化石クリーニングに娘と一緒に参加してきた。娘は石が好きなのだ。
化石クリーニングは、栃木県の那須塩原に木の葉の化石などが出る場所があるそうで、そこの石を使って、たがねとハンマーで石を割り、化石を探す作業だ。大体３０万年前のものだそうだ。
砂岩というのか、細かい粘土が堆積したような石で、結構軽く、横に割れやすい。たがねで３,４回たたくと割れて、化石があれば化石が出てくる。体験者１人にボランティアの方が１人ついて、割り方などを指導してくれた。
１０回位割ったころだろうか？　結構、はっきりした葉の化石が出てきた。やはり、何か出てくると面白くなる。
小さい葉が出てきたが、割れ方が中途半端で、尖ったたがねで掘り出した。結構、力加減が難しい。夢中になってしまった。結構、こういうの向いているかもしれない。。。夢中になるとわれを忘れてしまう。
それやこれやで、結構化石が見つかった。娘は小さい葉１個だったそうだ。下の写真は、発見した化石。一番はっきりした化石はどうやらイヌブナの葉らしい


明日は那珂川の石の自由研究へ行く予定。

変なコメントが来るのでコメントを承認制にしました

変なコメントが来るのでコメントを承認制にしました。
コメントは未承認ですと出るかもしれませんが、正常なコメントは承認しますので、どんどんコメントお願いします。

2007/08/16: 禁止IPリストと禁止ワードを設定したら、変なコメントが収まったようなので、コメントを承認なしに戻します。
禁止IPリストは、なんちゃらかんちゃら.dti.ne.jpが２つ、禁止ワードはダルビッシュととてもかけない言葉です。
.dti.ne.jpの方でコメント書けませんという方は、メールでご相談ください。

PCI-Xマスタ･モジュールのテスト２

PCI-Xマスタ･モジュールのテストで、ホストからのリードは64ビット幅で要求しても、そのスプリット完了のデータ転送は32ビット幅になってしまうという現象で悩んでいた。
mixiで聞いたり、FPGA Information Ltd.のFPGA BBSで聞いたりしてみた。FPGA BBSでは、くりさんにお世話になりました。
その結果、PCI-Xターゲット･モジュールをバースト転送に対応させて、転送長を変更してやってみた。
そうしたところ、このチップセットは、転送長が8バイトでは、REQ64#をアサートしても、スプリット完了のデータ転送は32ビット幅でした。しかし、転送長を16バイトにしてみたところ、スプリット完了のデータ転送は、チップセットがREQ64#をアサートして64ビット幅のデータ転送になった。
下の図のピンクの部分が転送長８バイトでPCI-Xマスタ・リードを発行したところだ。ホスト（チップセット）からは、スプリット応答が帰ってきている。緑色の部分は関係ないPCI-Xターゲット転送だ。
青色の部分がスプリット完了のデータ転送だ。req64x_1d (REQ64#) が０にアサートされていないので、64ビット幅のデータ転送ではなく、32ビット幅のデータ転送だ。32ビット幅なので2クロックで8バイトをデータ転送している。


次に、転送長を16バイトにしてPCI-Xマスタ・リードをやってみた。ピンクの矢印のreq64x_1d (REQ64#) が０にアサートされているので、64ビット幅のデータ転送だ。こちらから ack64x_1d (ACK64#) を０にアサートして応答している。その結果、16バイトが2クロックでデータ転送できた。


よかった。これで先に進むことができる。

迎え盆

今日も暑かった～。
午前中買い物へ行って、マクドナルドで久しぶりに昼食。奥さんの実家に直行した。お盆迎え前だが、仏様にお供えをして、線香をあげてきた。奥さんの実家は親の兄弟が多いので、昨日は15人以上来る予定だそうだ。早めに行って、うちも迎え盆があるので早く帰ろうという予定だ。
うちに帰って、4時過ぎに迎えにお墓に行く。（歩いて5分ほど）皆さん、迎えに来ている。しかし、墓石がいっぱいあるせいか？日が照っていると暑い。オーブンでこんがり焼かれているようだ。
線香に火をつけて、お墓に供える。墓石に水をかける。ろうそくに火をつけて、盆提灯の中に入れて、歩いて帰ってきた。
家に帰ったら、水を張った洗面器が用意してあって、その上に盆提灯を持っていく。これは、ご先祖様が家に帰ってくる前に足を洗うという儀式だそうだ。家の仏壇にろうそくを移し、その火で線香を供える。
その後は、買ってきたおすしで宴会だった。みんな一堂に会するのは久しぶりなので楽しかった。

ディズニーシーに行ってきました

昨日は地区の子ども会の旅行でディズニーシーに行ってきました。行ったのは３人で、私、奥さん、一番下の娘です。７時に観光バスで出発。８時４４分に到着しました。下りは渋滞でしたが、逆に上りはすいすい。お盆のころはねらい目かも？
ついたらとにかく暑い暑い。。。暑かったです。


はじめにアラビアンコーストに行って、マジックランプシアターを見る。本物の人間がやるマジック・コミカルショーと３Ｄ映像がリンクしているのが面白い。


シンドバッド・ストリーブック・ヴォヤッジに入る。イッツ・ア・スモールワールドのディズニーシー版？
その後、マーメードラグーンへ。ここはエアコンが効いていて涼しい。体力が温存される。
小さい乗り物を１度乗り、マーメードラグーンシアターへ。これは３度目がだが、アリエル役の人が目が回らないか心配に、何人かで担当しているのだろう。


インデージョーンズのFAST PASSを取ってあったので、ロストリーバーデルタに行く。ここのユカタン･ベースキャンプ･グリルがお気に入りなので、ここで昼食。スモークポークがおいしい。スモークチキンは奥さんが食べたが、これもおいしかった。でも、いつも思うのだが、ケチャップが薄味だともっと良いのだが。。。ハンバーグもおいしかった。ハンバーグのソースはちょうど良い味。写真はスモークポーク。例によって、食い意地が張って、食べる前に写真を取れなかった。食いかけで本当に失礼します。


その後、インデージョーンズ乗りました。私は落ちる系（フリーフォール系)のアトラクションがまったくだめなので、これにも乗っていなかったのだが、落ちないとの言葉を信じて乗りました。落ちませんでした。良かった。楽しかったです。


次は、ポートディスカバリーに行って、アクアトピアに乗る。これは少し水が張ったところを乗り物で行くのだが、次にどっちに行くのかの予測できない行動をする。私はこれが好きだ。娘も気に入って、もう一度乗った。
後は、海底２万マイル、蒸気船、電車など乗って楽しかったです。


いろいろ楽しんで、６時ころバスへ。


８時ころ帰宅しました。一日疲れた～。。。
今日はお盆です。迎え盆に行く予定です。

made in ☆ 秋葉原

”自分を探す旅の足跡(ZERO3と一緒)”さんの”めいどさんも電子回路設計”からmade in ☆ 秋葉原を知った。
メイドさんが電子部品の説明をしている。なかなか面白い。

バーベキュー

今日は、高校時代の友人に家でバーベキューをやった。
ウッドデッキ完成祝いだそうだが、久しぶりに楽しかった。うちでは奥さんは仕事だったので、私と子供3人で行ったのだった。
夕方には、自転車で一番下の娘と地区の危険箇所巡回へ行ってきた。水田用の用水路などの4箇所の危険箇所を見回った。
明日は、地区の子ども会の旅行でディズニーシーへ行く予定。ものすごく暑いんだろうな？　行く気がうせてきた。。。

PCI-Xマスタ･モジュールのテスト

PCI-Xマスタ･モジュールをやっとインプリメントして、テストしてみた。
PCI-Xのマスタ･リードを Memory Read Block コマンドで転送長を８バイト、REQ64#を0にアサートして、64ビットアクセスとしてアクセスした。そうするとホストはスプリット応答で返した。
やはり、ホストへのリードはスプリット転送になるようだ。
約750ns後にスプリット完了のためのトランザクションがホストから来た。まだスプリット完了に対応していないので無視してしまったが、これから対応したい。
疑問な点は、スプリット完了のときに、ホストがREQ64#をアサートしていなかったことだ。もしかして32ビット転送？
スプリット応答の時には ACK64# をアサートしていたんだけど。。。どうなんだろう。至急調査予定。

2007/08/10 : ホストからのリードは64ビット幅で要求しても、そのスプリット完了のデータ転送は32ビット幅になるようです。このチップセットでは。これではスループットが予定の半分。。。

キーボードが壊れた

家で使っていた古い富士通のキーボード、FMV-KB321, 1998-02 REV 02Aが一番下の娘にヤクルトをこぼされて壊れてしまった。
至急代替品を探しているが、Yahooオクにも REV 01A はあるが REV 02A がない。私も REV 01A は3台持っているが、少し硬い。
REV 02A がほしい。至急、探さなければ。。。

ＦＦをIOBに入れるためのVHDLの書き方(Synplify Pro編）

以前、PCI-Xバスへの出力信号のHDL記述で、わかりやすくVHDLコードを書く方法を模索したが、もっと賢いというか、確実なやり方がわかったので紹介する。
FRAME#とREQ64#は、64ビットアクセスしかしない場合は、同じ波形でよい。でも、FRAME#をREQ64#につないでしまうとIOBにFFが入らない。そこでFRAME#をREQ64#を同じに書いてある。
でもこれだと、論理合成の段階でFRAME#をREQ64#につながれてしまって、クロックからの出力時間を満足できない。
ソースはこれ。(Xilinx ISE 9.103i, Synplify Pro 8.5)

    -- FRAME#, REQ64#
    process(reset, clk) begin
        if reset='1' then
            framex <= 'Z';
            req64x <= 'Z';
        elsif clk'event and clk='1' then
            case mcs is
                when idle =>
                    if request='1' and gntx_1d='0' and framex_1d/='0' and irdyx_1d/='0' then -- requestされて、GNT#がアサートされて、バスがアイドルの時にスタート
                        framex <= '0';
                        req64x <= '0';
                    end if;
                when addr_cmd_assert =>
                    framex <= '0';
                    req64x <= '0';
                when attribute_phase =>
                    framex <= '0';
                    req64x <= '0';
                when wait_transaction =>
                    framex <= '0';
                    req64x <= '0';
                when m_trans_data =>
                    if (trans_complete='1') or (latency_timer_disconnect='1') then -- トランザクションが終了したか、もしくは、レイテンシ・タイマーがタイムアウトして、GNT#がアサートされていない状態でADBの境界のときは終了
                        framex <= '1'; -- 正常な状態
                        req64x <= '1';
                    elsif devsel_timeout='1' then -- DEVSEL#のデコードタイミングがタイムアウト
                        framex <= '1';
                        req64x <= '1';
                    elsif devselx_1d='1' and stopx_1d='0' then -- Target Abort(TRDY#='1'), Single Data Phase Disconnect(TRDY#='0')
                        framex <= '1';
                        req64x <= '1';
                    end if;
                when turn_around => -- 正常終了
                    if request='1' and gntx_1d='0' then -- 正常終了後にリクエストが来ているので、もう1度
                        framex <= '0';
                        req64x <= '0';
                    else
                        framex <= 'Z';
                        req64x <= 'Z';
                    end if;
                when stop_target => -- 異常終了
                    framex <= 'Z';
                    req64x <= 'Z';
                when drive_bus => -- バス・パーキング
                    framex <= 'Z';
                    req64x <= 'Z';
            end case;
        end if;
    end process;
    framex_out <= framex;
    req64x_out <= req64x;

こうするとSynplify Pro 8.5で論理合成した後のRTL図は下のようになる。


ISE9.103iでインプリメントしてFRAME#とREQ64#を見るとこうなる。


1つのロジックエレメントから2つの入出力パッドに出ているので、これではタイミングを満足しない。実際のタイミング解析の結果はこれ。

* COMP "pcix_req64_b" OFFSET = OUT 3.8 ns A | MAXDELAY| -1.014ns| 4.814ns| 1| 1014
FTER COMP "pcix_clk" | | | | |
------------------------------------------------------------------------------------------------------
* COMP "pcix_frame_b" OFFSET = OUT 3.8 ns A | MAXDELAY| -0.825ns| 4.625ns| 1| 825
FTER COMP "pcix_clk" | | | |

syn_keep や syn_preserve, syn_maxfan も試してみたがだめだった。
FRAME#とREQ64#の論理が同じなので、いろいろ試してみたが、フィードバックループができてしまった。IOBのFFにはフィードバックのパスがないので、フィードバックがあるとIOBに入れることができない。これは論理合成で対処しなくてだめなようだ。
Synplifyのマニュアルを見ていたら syn_useioff というそのもののディレクテブがあったので、これを使用して、IOB出力用FF記述とIOBトライステート・バッファ・イネーブル用FFの記述に分けてみた。（分けないとだめだった）（たぶんXSTにもあると思う）

XSTではIOB制約だそうだ。
attribute iob: string;
attribute iob of {component_name|entity_name|label_name}:{component|entity|label} is "(true|false|auto)";

ソースは下。

attribute syn_useioff : boolean;
attribute syn_useioff of framex : signal is true;
attribute syn_useioff of req64x : signal is true;
attribute syn_useioff of framex_enable : signal is true;
attribute syn_useioff of req64x_enable : signal is true;

......

    -- FRAME#, REQ64#
    process(reset, clk) begin
        if reset='1' then
            framex <= '-';
            req64x <= '-';
        elsif clk'event and clk='1' then
            case mcs is
                when idle =>
                    if request='1' and gntx_1d='0' and framex_1d/='0' and irdyx_1d/='0' then -- requestされて、GNT#がアサートされて、バスがアイドルの時にスタート
                        framex <= '0';
                        req64x <= '0';
                    end if;
                when addr_cmd_assert =>
                    framex <= '0';
                    req64x <= '0';
                when attribute_phase =>
                    framex <= '0';
                    req64x <= '0';
                when wait_transaction =>
                    framex <= '0';
                    req64x <= '0';
                when m_trans_data =>
                    if (trans_complete='1') or (latency_timer_disconnect='1') then -- トランザクションが終了したか、もしくは、レイテンシ・タイマーがタイムアウトして、GNT#がアサートされていない状態でADBの境界のときは終了
                        framex <= '1'; -- 正常な状態
                        req64x <= '1';
                    elsif devsel_timeout='1' then -- DEVSEL#のデコードタイミングがタイムアウト
                        framex <= '1';
                        req64x <= '1';
                    elsif devselx_1d='1' and stopx_1d='0' then -- Target Abort(TRDY#='1'), Single Data Phase Disconnect(TRDY#='0')
                        framex <= '1';
                        req64x <= '1';
                    end if;
                when turn_around => -- 正常終了
                    if request='1' and gntx_1d='0' then -- 正常終了後にリクエストが来ているので、もう1度
                        framex <= '0';
                        req64x <= '0';
                    else
                        framex <= '-';
                        req64x <= '-';
                    end if;
                when stop_target => -- 異常終了
                    framex <= '-';
                    req64x <= '-';
                when drive_bus => -- バス・パーキング
                    framex <= '-';
                    req64x <= '-';
            end case;
        end if;
    end process;
    
    process(reset, clk) begin
        if reset='1' then
            framex_enable <= '0';
            req64x_enable <= '0';
        elsif clk'event and clk='1' then
            case mcs is
                when idle =>
                    if request='1' and gntx_1d='0' and framex_1d/='0' and irdyx_1d/='0' then -- requestされて、GNT#がアサートされて、バスがアイドルの時にスタート
                        framex_enable <= '1';
                        req64x_enable <= '1';
                    end if;
                when addr_cmd_assert =>
                    framex_enable <= '1';
                    req64x_enable <= '1';
                when attribute_phase =>
                    framex_enable <= '1';
                    req64x_enable <= '1';
                when wait_transaction =>
                    framex_enable <= '1';
                    req64x_enable <= '1';
                when m_trans_data =>
                    if (trans_complete='1') or (latency_timer_disconnect='1') then -- トランザクションが終了したか、もしくは、レイテンシ・タイマーがタイムアウトして、GNT#がアサートされていない状態でADBの境界のときは終了
                        framex_enable <= '1'; -- 正常な状態
                        req64x_enable <= '1';
                    elsif devsel_timeout='1' then -- DEVSEL#のデコードタイミングがタイムアウト
                        framex_enable <= '1';
                        req64x_enable <= '1';
                    elsif devselx_1d='1' and stopx_1d='0' then -- Target Abort(TRDY#='1'), Single Data Phase Disconnect(TRDY#='0')
                        framex_enable <= '1';
                        req64x_enable <= '1';
                    end if;
                when turn_around => -- 正常終了
                    if request='1' and gntx_1d='0' then -- 正常終了後にリクエストが来ているので、もう1度
                        framex_enable <= '1';
                        req64x_enable <= '1';
                    else
                        framex_enable <= '0';
                        req64x_enable <= '0';
                    end if;
                when stop_target => -- 異常終了
                    framex_enable <= '0';
                    req64x_enable <= '0';
                when drive_bus => -- バス・パーキング
                    framex_enable <= '0';
                    req64x_enable <= '0';
            end case;
        end if;
    end process;
    framex_out <= framex when framex_enable='1' else 'Z';
    req64x_out <= req64x when req64x_enable='1' else 'Z';

こうするとSynplify Pro 8.5で論理合成してRTL図を見ると下のようになった。


これでインプリメントすると下のようにタイミング制約の範囲に入った。

COMP "pcix_frame_b" OFFSET = OUT 3.8 ns A | MAXDELAY| 0.725ns| 3.075ns| 0| 0
FTER COMP "pcix_clk" | | | | |
------------------------------------------------------------------------------------------------------
COMP "pcix_req64_b" OFFSET = OUT 3.8 ns A | MAXDELAY| 0.752ns| 3.048ns| 0| 0
FTER COMP "pcix_clk" | | | | |

更にFPGA EditorでFRAME#のパッドを見ると、IOBにFFがしっかり入っている。


これでOKとなったが、まだ他の入出力で最終段のFFがIOBに入っていないものがある。今のところ原因は不明だ。

PCI-Xマスタ･モジュールのシミュレーション

どこかのBBSで書いてありましたが、”どこかの暇人”とは私のことでしょうか？　まあ、主に自分のためですけどね。（自意識過剰かな？)

それはさておき、PCI-Xマスタ･モジュールのシミュレーションが大体できた。


pcix_req_bを 0 にアサートして、アービタがpcix_gnt_bをアサートして、バスがアイドルだったらトランザクションが開始。pcix_frame_bが 0 にアサートする。その後、pcix_irdy_bを 0 にアサートする。pcix_devsel_bが 0 にアサートされたらターゲットが応答。pcix_trdy_bをターゲットが 0 にアサートしたら1つ転送。今回は転送数がカーソルの位置でわかるとおり8バイト境界に位置合わせされた8バイトなので、64bit1つで終了。
次はインプリメントだが、問題が発生。経緯は次回に。

江ノ島・鎌倉旅行(2日目）

江ノ島・鎌倉旅行の2日目(8月3日）だ。まずは泊まったホテル。JR東日本のグループみたい。料金は前払いでスイカでも払えました。(カードで払ったけど)


今日はホテルに荷物を預けて、横須賀線で鎌倉へ。さらに江ノ電で極楽寺駅で下車。極楽寺に向かう。今回の旅行の目的は息子が病気でいけなかった修学旅行の足跡をたどることだ。
極楽寺を見てから、長谷寺まで徒歩で移動。途中で長谷寺までの道を外人さんに聞かれる。うちらもわからず人に聞いていたので、それを説明。その外人さんは車で移動していたのだが、乗せていってもらえばよかった。
長谷寺到着。暑い～。下の娘に線香を買ってあげて(50円）線香をあげた。長谷観音、宝物殿などを見る。大人1人300円なり。極楽寺は無料だった。


長谷寺からの眺めがすばらしかった。海が良く見えた。


長谷寺を出てから高徳院へ徒歩で移動。鎌倉の大仏様を見に行く。(200円）とても暑い。途中、鎌倉ジェラートのお店で休憩。


鎌倉の大仏様の体内にも入った。(20円）ここから銭洗い弁天まで1.9Kmを歩いた。ここで携帯のナビを活用して道案内。使えました。けれどもGPSを常時使うモードにすると電池の消費が激しく、銭洗い弁天に行くまでに電池切れ。。。時々確認モードにしないと使えない。。。
行く途中の森のレストランで食事。見逃しそうな小さなお店だった。なかなかフレンドリーなおじさんがお出迎え。私はハンバーグランチを頼んだがソースが絶品においしかった。パスタはいまいちだったとの奥さんの弁。とにかく暑かったので、オアシスのようで助かった。


ここからすぐの銭洗い弁天へ。また銭を洗う。


次に銭洗い弁天の上の源氏山公園に。源氏山公園はたいしたことはなかった。
森のレストランのおじさんから源氏山公園からハイキングコースで寿福寺に抜けると近いと聞いたので、そちらに向かう。途中に頼朝像があった。この辺は人がいなくてさびしいくらい。


さらに歩いていくと、本当草ぼうぼうの山道になってきた。不安になって、その辺で草刈している人に聞いたら、大丈夫とのこと。カップルが来たので、一緒に連れて行ってもらった。
途中、人一人やっと通れるようなところもあったが無事に通過。結構険しいところにも民家があった。普段に平地に住んでいるうちらには驚きだった。
途中、道を聞きながら寿福寺に到着した。


寿福寺は参道だけで境内には入れなかった。(無料）ここから鶴岡八幡宮を目指して歩く。鶴岡八幡宮に到着。(無料）



雪洞祭りの準備をしているようだった。鎌倉は学生時代に来たことがあるので、長谷寺、鎌倉大仏、鶴岡八幡宮には来た事があった。鶴岡八幡宮は相変わらず豪華だった。
ここから小町通りをお土産を見ながら、鎌倉駅に向かった。石ころやがあって、下の娘に石を買い、息子にテクタイトという隕石を購入。職場のお見上げも鳩サブレーを購入した。
鎌倉から横須賀線で大船へ。ホテルで荷物を受け取って、東海道本線で東京。山手線で秋葉原。つくばエキスプレスで研究学園まで帰ってきた。600円を払って車を出して帰宅。
暑かったので、夕食はそば、うどんだった。これにて家族旅行終了。とにかく今日は暑かった。今度は石を拾いに那珂川辺りに行く予定。

江ノ島・鎌倉旅行(1日目)

昨日、一昨日と江ノ島・鎌倉に家族旅行に行ってきました。
8月2日は、朝、つくばエキスプレスで研究学園駅からお出かけ、車は1日300円の駐車場においていきました。
秋葉原から東海道線で大船へ、今日宿泊するホテルメッツかまくら大船へ荷物を預けていきました。
湘南モノレールで大船から湘南江の島駅へ。モノレールは、何か遊園地の乗り物みたい。ぐにゃぐにゃ連結部分が曲がります。カーブが多いんですね。これだと普通の線路よりモノレールのほうが良いのでしょう？家との間が近いです。江ノ電みたい。
湘南江の島駅を降りて、江ノ島の方角がよくわからないので、早速携帯のナビタイムを起動。そのためにソフトバンクの最高機能携帯を買ったのだった。でも周囲が明るすぎて液晶が良く見えない！！！　ちぇ～、透過型の液晶にしてくれれば良いのに。。。結局、みんなの行くほうに、行ってみることにした。
おなかがすいてきたので、道沿いの食堂に入る。生シラスが有名みたいなので早速注文。さっぱり、おいしいです。ねぎとしょうがで食べましたが、とてもおいしい。娘の食べたアジもとても新鮮でおいしかったそうです。江ノ島では海産物がお勧め。
商店街を歩いていくと、模型やさんがありました。木の模型やブリキの模型をリーズナブルな値段で売っていました。息子に帆船の模型を買ってあげました。630円でした。安い。私も大きいヨットの模型がとてもほしかったんですが、飾るところがないのであきらめました。
その後、商店街を歩いて江ノ島水族館へ。


いろいろな魚を見たが、クラゲがいっぱいいた。相模湾大水槽のいわしが良かった。いわしの大群が、ファインディング・ニモのようにいろいろな形をとるのが面白くて見とれてしまった。


水族館を出て、江ノ島アイランドスパへ。
外にあるスパからの眺めが最高だった。2Fの外のプールからは湾内？が一望できる。ずっと眺めていた。
プールがお湯ではなくて温水プールだったら最高だったのだが、温水プールもあると良かった。のんびり時を過ごす。こういうところも良い。（プールとWebページには書いてあったが水温が高い）


スパを出た後で、江ノ島神社の参道を歩いていくと、いろいろなお店があった。おなかがすいていたので、シラスパンやシラス薩摩揚げ、せんべい、ハマグリやサザエの串焼きなどを食した。おいしかった。


江ノ島神社に登ったが、最初の階段を登ったところでばててしまった。銭洗い弁天のように、硬貨を洗うところがあったので子供が洗った。ご利益があると良いのだが。
疲れたので、山を降りてきたら、とても眺めが良かった。登ってよかった。


江ノ島の下に下りて、夕食を食べることにした。るるぶを見て、どこがいいかを物色。上の娘が海産物が良いということで、すぐそばのシラス料理専門店、とびっちょで食べた。釜揚げシラス丼を食べたが、釜揚げシラスに生卵の黄身をかけて食べるどんぶりだった。これが絶品においしかった。一日シラス尽くしの食事だったが満足。また食べたい。
湘南モノレールで大船のホテルまで戻って、宿泊。一日目終了。とても楽しかった。

PCI-Xマスタ･モジュール

PCI-Xマスタ･モジュールがだいぶできてきた。バースト転送には、まだ対応していないが、対応できるようには作っているつもり。とりあえず、1発だけマスタ･アクセスをやってみよう。でもまだ、PCI-Xのシミュレーション･モデルがうまくいっていない。PCIバスのシミュレーション･モデルを修正しながら使っているが、まだPCI-Xに対応しきっていないのだ。
PCI-Xマスタ･モジュールは、すべて64ビット幅のアクセスの予定だ。Memory WriteコマンドとMemory Read Blockコマンドを使う予定。64ビットに満たないWriteの場合はバイト･イネーブルを調節する。64ビットに満たないReadの場合は、読んできたデータの一部を使うようにするつもり。
現在、シミュレーションをしているので、これが完了したらインプリメントして確かめてみる。