Ultra96toPMODのBOM

弊社作成のUltra96toPMODボードですが、BoMを掲載していなかったので、掲載します。

Online-shopの開設

併せてオンラインショップを開設しました。

前のブログ 次のブログ

PL部UARTのPCへの出力

以前Space Invadersのゲーム実行中のVRAM画面の吸出しを実施しました。過去記事ではこれ等が相当します。これは、メモリダンプモジュールをBSVにより設計し、UARTの送信機能を用いてUART/USB変換ボードを経由してPCとUSBで接続し、PC上のPuttyでメモリダンプ情報を取得するというものです。

ところが、再度実行しようとしたところ、どうしてもUARTの出力の取得ができませんでした。前回は比較的簡単にできてしまったので、記事にはpin設定であるxdcの詳細は書いていませんでした。単にUART_TXに接続するとのみと書いており、端子番号は今は定かではありません。

こうなると基本から調べなければならないので、まずUltra96V2の回路図を見ると、なんとPS部からの接続となっているようです。

UART/USB変換ボードのJ1の2 pinにUART_TXが接続されていますが、これはPS_MIO0のUART1_TXであり、PLからはPIN配置でエラーになるため、PS部であるBank 500のU4端子に接続することはできません。図605.2にUltra96-V2ハードウェアユーザーズガイドの抜粋を示しますが、やはりBank 500(PS部)のU4端子となっています。

従って、最後の手段としてボード上に配線をハンダ付けし無理やりJ1に出力することを考えます。

まず図605.3はPL部UART_TXの引き出しを示す回路図です。

このUART_TXを次のxdcによりG6端子に割り当てます。これはPL部の出力(Bank 26)です。

set_property PACKAGE_PIN G6 [get_ports {UART_TX}]

最後にUART_TXを割り着けた端子G6とJ1の2 pinの間に配線をハンダ付けし、ショートしてやります。レベル的に本来はTrのD側ではなくS側に接続すべきですが、3.3Vにpull upされているため、これでもVOHは満足しているようです。

このようにすることで921,600bpsにより、VRAM内容の送信がうまく動作しました。が、以前設定だけでできた理由は不明のままです。

PCへの出力結果の確認

以下に、得られたlogファイルを画像に変換するフィルタを再掲します。

log2ppm.c

#include <stdio.h>
void main() {
      char line[4096];
      char ch;
      printf("P3\n256 256\n255\n");
      for(int y = 0; y <= 255; y++) {
            fgets(line, sizeof(line), stdin);
            for(int x = 0; x <= 255; x++) {
                  ch = line[x] - 0x30;
                  if ((ch & 0x4) != 0) printf("255 ");    // R
                  else printf("0 ");
                  if ((ch & 0x2) != 0) printf("255 ");    // G
                  else printf("0 ");
                  if ((ch & 0x1) != 0) printf("255 ");    // B
                  else printf("0 ");
            }
            printf("\n");
      }
}

以下のコマンドによりフィルタを作成します。

$ gcc -O log2ppm.c -o log2ppm

これを下記のようにフィルターとして実行し、ログデータを画像ファイルに変換します。

$ ./log2ppm <putty.log >putty.ppm

生成されたppm図形を図605.4に示します。

前のブログ 次のブログ

画面の縦横の入れ替えの変更

過去記事において、本来VRAMの読み出しアドレスのxとyを入れ替えるつもりが、たまたまwrite側のアドレスマルチプレクサが目につき、それを流用しました。が、動作的な欠点が目立ちました。具体的には、画面書き換えの途中で切り替えると、縦図形と横図形が混在したり、初期画面を動的に準備する負担が大きくなっていました。

これを本来のread側アドレスマルチプレクサに変更します。ただし、write側マルチプレクサに追加してread側マルチプレクサの増設が必要になります。

write側アドレスマルチプレクサは名前をWriteMuxに変更しましたが、元の単なるセレクタに戻しました。新たにReadMuxモジュールを設置し、読み出し側アドレスのxとyを入れ替えます。実際にはyはx(a[7:0])をそのまま用い、xはy(a[15:8])を256から引いたものを用います。

$$ \begin{eqnarray} \left\{ \begin{array}{l} x&\Leftarrow&256-y \\ y&\Leftarrow&x \end{array} \right. \end{eqnarray} $$

図561.1に改造後のブロック図を示します。

以下にBSVソースを示します。処理はwrite側で実施した入れ替えとほとんど同様です。

ReadMux.bsv:

// アドレス型の定義
typedef Bit#(16) Addr_t;

// マルチプレクサのインタフェース定義
interface ReadMux_ifc;
   (* prefix="" *)
   // 出力アドレスを生成するメソッド
   method Addr_t outp(Bool sel, Addr_t a);
endinterface

// マルチプレクサの実装
(* synthesize, always_ready = "outp", no_default_clock, no_default_reset *)
module mkReadMux(ReadMux_ifc);

   // 出力アドレスを生成するメソッド
   method Addr_t outp(Bool sel, Addr_t a);
      // xa: aの下位8ビット
      Bit#(8) xa = a[7:0];
      // yax: aの上位8ビットから算出
      Int#(10) yax = 256 - signExtend(unpack(a[15:8]));
      // ya: yaxを8ビットにトリミング
      Bit#(8) ya = truncate(pack(yax));

      // selがTrueなら加工したアドレスを返す
      if (sel) return {xa, ya};
      // selがFalseなら元のアドレスをそのまま返す
      else return a; 
   endmethod

endmodule

この変更により、ボード上のdip swを切り替えることで、リアルタイムに画面の縦横変換ができるようになりました。

前のブログ 次のブログ

完成したゲームのオープニングからのゲーム開始画面です。動画変換フレームレートの関係で、ゼロの点滅がハッキリと再生されませんが、実際にはきれいに点滅しています。

実行のシーケンス

• 得点表(Score Advance Table)アニメーション表示
• Fボタンを押す
• "PUSH ONLY 1PLAYER BUTTON"を表示、CREDIT=01
• Sボタンを押す
• "PLAY PLAYER<1>"を表示、CREDIT=00、SCORE<1>をゼロにし、規定回数点滅
• ゲームスタート

前のブログ 次のブログ

Y字リプレースアニメーションのソース

Y字リプレースアニメーションのソースを示します。Y字リプレースアニメーションもFボタンにより中断するため、各所でFボタンを見ています。

function Stmt replaceY;
   return (seq
      // from right to left
      for (i <= 228; i >= 142; i <= i - 2) seq
         copyArea((pack(i)[1] == 1'b1) ? 68 : 84 , 32, i, 67, 10, 8);
         wait_timer(`TICK_WAIT3);
         if (fbutton) break;
      endseq // for
      if (fbutton) break;
      // from left to right
      for (i <= 136; i <= 226; i <= i + 2) seq
         copyArea((pack(i)[1] == 1'b1) ? 75 : 91 , 107, i, 67, 16, 8);
         wait_timer(`TICK_WAIT3);
         if (fbutton) break;
      endseq // for
      eraseArea(226, 67, 16, 8);
      wait_timer(`TICK_WAIT32);
      if (fbutton) break;
      // from right to left
      for (i <= 226; i >= 136; i <= i - 2) seq
         copyArea((pack(i)[1] == 1'b1) ? 77 : 93 , 117, i, 67, 16, 8);
         wait_timer(`TICK_WAIT3);
         if (fbutton) break;
      endseq // for
      wait_timer(`TICK_WAIT32);
      if (fbutton) break;
      eraseArea(141, 67, 9, 8);
      wait_timer(`TICK_WAIT32);
      if (fbutton) break;
   endseq);
endfunction

これだけでなく、タイマールーチンの中でもFボタンによる中断を見ていますが、ちょっとやり過ぎのようです。実際には多少間引いても体感に影響しないと思います。

前のブログ 次のブログ

オープニングアニメーションのソース

オープニングアニメーションのソースを示します。オープニングアニメーションはFボタン(コイン投入の模擬)により中断するため、各所でFボタンを見ています。

function Stmt openingAnimation;
   return (seq
      // Opening Animation
      foa <= True;
      eraseArea( 0, 41, 255, 199); // erase screen
      eraseArea(25,242, 5, 7); // erase zanki
      stringS1; // PLAY ...
      if (fbutton) break;
      wait_timer(`TICK_WAIT64);
      if (fbutton) break;
      stringS2; // *SCORE ...
      if (fbutton) break;
      wait_timer(`TICK_WAIT32);
      if (fbutton) break;
      stringS3; // =? MYSTERY ...
      if (fbutton) break;
      wait_timer(`TICK_WAIT64);
       if (fbutton) break;
      replaceY; // ^ -> Y
      if (fbutton) break;
      wait_timer(`TICK_WAIT64);
      if (fbutton) break;
      foa <= False;
   endseq);
endfunction

前のブログ 次のブログ

オープニングアニメーションの追加

テスト用のソースを示します。コンパイル時間短縮のため、ゲーム部分をカットしています。

// メインフロー
Stmt main = seq
   while (True) seq
      while (!fbutton) seq
         openingAnimation; // Fボタンによりブレーク
      endseq // while
      openingDisplay;      // 表示のみ、ボタンを待たない
      await(sbutton);        // Sボタンによりブレーク
      openingDisplay2;    // タイマーによりブレーク
      // game start
   endseq // while
endseq;

// CREDIT 01, "PUSH ONLY 1PLAYER BUTTON"
function Stmt openingDisplay;
   return (seq
      eraseArea( 0, 41, 255, 199); // erase screen
      stringS5; // PUSH ONLY ...
      copyArea(10, 162, 217, 241, 5, 7); // CREDIT 00->01
   endseq);
endfunction

// CREDIT 00, "PLAY PLAYER<1>, 00000"
function Stmt openingDisplay2;
   return (seq
      eraseArea( 0, 41, 255, 199); // erase screen
      stringS6; // PLAY PLAYER<1>
      copyArea(2, 162, 217, 241, 5, 7); // CREDIT 01->00
      for (i <= 1; i < 15; i <= i + 1) seq
         // erase zero
         eraseArea(40, 25, 37, 7);
         wait_timer(`TICK_WAIT4); // wait 66.66msec
         stringS7; // 00000
         wait_timer(`TICK_WAIT4); // wait 66.66msec
      endseq // for
   endseq);
endfunction

前のブログ 次のブログ

オープニングアニメーションの追加

この動画の最初の部分を参考にして、オープニングアニメーションを作成します。

1. インベーダの種類や点数の紹介、と同時に逆さYを引っ張って行き正立Yに入れ替えます。アニメーションがメインなので、これをopeningAnimationシーケンスと呼び、同名の関数により実行します。Fボタンによりコイン投入を模擬します。 図513.1　openingAnimation画面
2. コインを投入すると、"PUSH ONLY 1PLAYER BUTTON"と表示され、CREDITが+1されます。アニメーションは無いため、これをopeningDisplayシーケンスと呼び、同名の関数により実行します。Sボタンを待ちます。 図513.2　openingDisplay画面
3. Sボタンを押すと、"PLAY PLAYER<1>"と表示され、CREDITが-1されます。同時に得点が"00000"となり、点滅します。これをopeningDisplay2シーケンスと呼び、同名の関数により実行します。 図513.3　openingDisplay画面1 図513.4　openingDisplay画面2
4. ゼロ点滅を規定回数実行すると自動的にゲームを開始します。

図513.5にSボタンとFボタンの配置を示します。

前のブログ 次のブログ

テストベンチ

テストベンチは変わりません。

Tb.bsv

import StmtFSM::*;
import Uart::*;

(* synthesize *)
module mkTb();
      Uart_ifc uart <- mkUart();

      Stmt s = seq
            delay(8);
            uart.load(8'h55);
            uart.load(8'haa);
            uart.load(8'hc3);
            uart.load(8'h3c);
            await(uart.done());
            $finish;
      endseq;
      
      mkAutoFSM(s);

endmodule
 

Bsimシミュレーション

Bsimシミュレーションのコマンドは次のとおりです。

$ bsc -u -sim Tb.bsv; bsc -sim -e mkTb -o Tb.exec; ./Tb.exec -V bsim.vcd; gtkwave -A bsim.vcd

以下にBsimシミュレーション結果を示します。意外なことに明示的にdone信号を書いたにも関わらず、シミュレーションのダンプの中にdone信号がありませんでした。

テストベンチ内でレジスタにuart.doneを格納するようにしたら、インタフェースにuart.doneが現れました。awaitで使用するくらいでは削除され、レジスタに取って初めて残すようです。

Verilogシミュレーション

Verilogシミュレーションにおいては、モジュール(mkUart.v)、それをドライブするテストベンチ(mkTb.v)の上位に最上位(top.v)を配備します。これはクロックやリセットを供給するモジュールですが、Bsimの場合はシステムから暗黙にクロックやリセットが供給される一方、Verilogでは供給されないためです。

top.v

`timescale 1ns/1ns
module top();
      /*AUTOREGINPUT*/
      // Beginning of automatic reg inputs (for undeclared instantiated-module inputs)
      reg      CLK;        // To mkTb_inst of mkTb.v
      reg      RST_N;        // To mkTb_inst of mkTb.v
      // End of automatics
      /*AUTOWIRE*/
      mkTb mkTb_inst(/*AUTOINST*/
      // Inputs
      .CLK    (CLK),
      .RST_N    (RST_N));

      initial begin
            RST_N = 1'b0;
            #10;
            RST_N = 1'b1;
      end
      initial begin
            CLK = 1'b0;
            forever begin
        #5 CLK = ~CLK;
            end
      end
      initial begin
            $dumpfile("verilog.vcd");
            $dumpvars;
      end
endmodule // top

Verilogシミュレーションのコマンドは次のとおりです。

$ bsc -u -verilog Tb.bsv; iverilog top.v mkTb.v mkUart.v -o ./mkTb.exev; ./mkTb.exev; gtkwave -A verilog.gtkw

Verilogシミュレーションのほうには当然ですが、uart.done信号が存在します。

前のブログ 次のブログ

UARTの改良点

過去記事においてUARTを設計しましたが、見直したところ改良点が見つかりました。 改良点はdoneフラグの生成です。実はハンドシェークは自動的にenableとreadyの2線で行われるので、doneが無くても良いのですが、test benchで終了を知りたい場合には必要です。

Uart.bsv

import StmtFSM::*;

interface Uart_ifc;
      method Bit#(1) read();
      method Action load(Bit#(8) newdata);
      method Bool done();
endinterface

(* synthesize, always_ready="read, done" *)
module mkUart(Uart_ifc);
      Reg#(Bit#(8)) data <- mkRegU;
      Reg#(Bit#(1)) odata <- mkReg(1'h1); // stop bit

      Stmt s= seq
            odata <= 1'h0; // start bit
            repeat (8) action
                  odata <= data[0];
                  data <= (data >> 1);
            endaction
            odata <= 1'h1; // stop bit
      endseq;

      FSM fsm <- mkFSM(s);

      method Bit#(1) read();
            return odata;
      endmethod
      method Bool done();
            return fsm.done();
      endmethod
      method Action load(Bit#(8) newdata);
            action
                  data <= newdata;
                  fsm.start();
            endaction
      endmethod
endmodule

この記述のように、従来設けてあったレジスタのdoneフラグを削除し、ステートマシンのdoneを上位に返すことで実現します。さらに、インタフェースのreadとdoneは常にreadyであるため、それらのready信号は不要なので削除しています。

前のブログ 次のブログ