It's important to know the RCB, read completion boundary to decode the completion TLPs for read request.
The RCB configuration is written in the Link Control Register, bit 3. The bit is 1'b0 if the RCB of root complex is 64 bytes, and 1'b1 for 128 bytes.
FYI, the bit appears on cfg_lcommand[3] on Xilinx's Endpoint Block Plus.
土曜の夕方からずっと胃腸炎で寝込んでいたわけですが、その間にも夢に PCI Express の transaction layer interface (Xilinx のやつ) の波形が出てきたりして、だいぶそっち方面でも病的だった。
昨日は死んだように眠っていたので、ほとんど何もしなかったんだけど、今日は布団の中で上半身起こして、わりとごりごりやって、RTL の波形ではかなりいい感じになった。少なくとも、Handshake はちゃんとできている感じ。
あとは、ヘッダをちゃんと作るとか、上位のモジュールとやりとりするための信号をいくつか作り込めばあとは、いま動いている PIO なインタフェイスとくっつける作業かな..
/* -----\/----- EXCLUDED -----\/-----
#(2*STEP)
trn_tdst_rdy_n <= 1;
#(1*STEP)
trn_tdst_rdy_n <= 0;
-----/\----- EXCLUDED -----/\----- */
While I'm writing a DMAC on my Virtex-5 PCIe card, I've found that the "MAX_PAYLOAD_SIZE" register has only 3 bits, while the size will be between 128 and 4096. And here's the answer:
3'b000 128B
3'b001 256B
3'b010 512B
3'b011 1024B
3'b100 2048B
3'b101 4096B
3'b110 Reserved
3'b111 Reserved
(from Xilinx application note XAPP1052 documentation).
and now I can continue!
授業の関係で、SPARTAN-3AN の評価キットでいろいろ作業中。
とりあえず、以前にも書いた VGA controller を、学生向けに簡単な記述で書き直してみたり。でも、まだなんか微妙に動かない。なんとなく原因はわかっているんだけどね。
Ethernet 動かせるかなー、とか考えていたら、FPGA 始めましたというページを発見。すごいなこの人...
昨日と今日の奮闘により、ちゃんと双方向通信ができるようになり、ホストからキーボードにコマンドを送れるようになった。つまり、Caps Lock とかの LED を操作したり、パリティエラーを検出した場合の再送要求ができたり、ということだ。
めでたい。
そういうわけで、なんだかすごくはまって1週間くらいかかりましたが、無事に PS/2 キーボードから入力がとれるようになりました。わほーい。
なんか、原因はよくわかりませんが、どうやら俺の書き方が XST のお気に召さなくて、FSM の合成がうまくできなかった模様で、state の持たせ方を変えたら直ったよ。ごく普通の one-hot state register だったんだけどなぁ...
どうも、Design Wave Magazine が休刊になる、という話だ。
青春だったのになあ。
中学生の頃、Design Wave というのはまだトラ技の別冊付録で、「FPGA とか CPLD っていうのはすごいデバイスだ! 74LS とかいらなくなるのかね？」とか、「回路書くのに HDL というのがあるのかー、すげーなー!! (でも CAD もそれを動かすためのコンピュータも高いよなあ)」とか、読みながらそんなことを考えてたわけです。
で、大学で研究室に入って、(まさかそんなことになるとは思っていなかったのだが) 自分が FPGA ボードとかを作るようになるころには月刊化されており、けっこう買っていて、とても勉強になった。博士を出てからは今年の夏までずっと生物系の研究室にいたので、しばらく買ってなかったが。
思えば月刊化されてからいままで、というのはプログラマブル・デバイスが急激に普及したり、高位言語からの合成が実用化され始めたり、いろいろな転換期だったような気がする。
売れないから休刊、というよりは、ひとつの時代と役目がおわったのかな。
ありがとうございました。
今日はこまごまとした用事がいくつかあったものの、わりと作業に時間をつぎ込める感じのスケジュールだったので、昼過ぎからわりと集中して実装。何度か変なバグを作って苦戦したものの、夜7時くらいに画面が映るようになり、8時半には完璧に動くようになった。やほーい。
何に使おうかな。とりあえず UART 作りたいな。
昨夜作りかけたディスプレイコントローラだが、ちょこちょこっとデバッグして、画面が映るようになった。しかし、VGA の解像度に充分な容量のメモリは (DRAM が動かない限り) ないので、いまのところ適当なパターンを作る回路が仕込んであり、スイッチでそれを切り替えて遊べる、みたいな感じ。
で、テキスト VRAM みたいなのがあって、文字を表示できたらいいかなー、と思ったので、現状のパターン発生回路の出力にテキストをスーパーインポーズできるような仕掛けを作ることにした。フォントを作っちゃえばあとはなんとかなるだろ、と思うのだが、甘いかな。とりあえず、テキストに簡単な属性がつけられるといいなー、と思って、本棚から何年ぶりかで「PC-9800シリーズ テクニカルデータブック」を引っ張り出してみた。テキストVRAMの属性ビットのところをみると、
- R
- G
- B
- VL (Vertical Line)
- UL (Under Line)
- RV (Reverse)
- BL (Blink)
- ST_ (Secret)
だそうだ。Secret は実装しなくてもいいか。UL は 4 pixel 右にずれる仕様で、つまり、VL と合わせると罫線としても使えるようになっている。いまさらだけど、98 かっこいいな!
で、XC3S700AN の Block RAM は 20 個ある、というのを前提に仕様を整理してみることにする。
CG (Character Generator) に必要なメモリは、1文字 8x16 で 16bytes. カタカナだけの 8bit コードを全部サポートすると、4kB 必要になるが、ASCII だけの 7bit コードなら、2kB だから、BlockRAM ひとつにちょうど収まる (こう考えてみると、CG というのはけっこう大きな ROM が必要で、ましてや漢字をサポートするというのは、16x16 だとしても 32bytes/character なわけで、ひと昔前ならば一大事業だと思う)。
VRAM のほうは、1文字 8bit で、80x25 でちょうど 2kB. これだと 640x400 しか使い切れない (NEC の気持ちがわかった気がするぞ!)。キャラクタの高さを 16 ドットにすると、80x30 まで入るわけで、これだと 2400bytes 必要であり、352バイトはみ出してしまうが、さすがにこれだけのために BlockRAM をもうひとつ使うのはなんかもったいないので、attribute を 4bit に圧縮して、BlockRAM の後半をこれに使うことにした。RGB + UL でいいかな。
VRAM のアドレッシングは、VGA コントローラから現在の X 座標と Y 座標の値が出てくるので、X (8 pixels/character) は下の 3 bit を切り捨てて、Y (16 pixels / character) は下の 4bit を切り捨ててやれば、キャラクタ座標になるわけだ。しかし、ここからアドレスに変換するところが実に問題で、80 を掛ける、というのはけっこうしんどい。そこで、text + attribute で、一行あたり 120 bytes だから、128bytes / line を割り当てることにした。こうすると、4kB のメモリには 32 行分乗ることになり、30行の画面には充分である。結局のところ、アドレス計算は、
assign TEXT_A[11:0] = {VGA_Y[9:4], VGA_X[9:3]};
みたいな感じでできる。Attribute のほうは、2 桁分が 1 バイトで読めてくるので、そこはちょっと工夫が必要だが、たいしたことはない。
CG は、アドレスの上位 7 ビットが文字コードで、下位 4 ビットが Y 軸。
これが終わったら、とりあえず文字の表示とかが FPGA 単体でできるようになるわけなので、学生の教育用に UART と Ethernet の MAC くらいは作りたいが、Ethernet MAC は大変そうだなあ。
