上位モジュールの最適化

メモリダンプアルゴリズムが疑似コードにより記述できたので、最適化を実施します。以下のような処理が3回出てくるので、nibbleOutという関数にまとめます。

     lower += (lower >= 10) ? (-10 + "a") : "0";

この共通化を実施した全体の動作を疑似コードにより示します。

疑似コード

int x, y, address;
byte byteData, checksum;

address = 0;
for (y=0 to 255) {
      checksum = 0;
      for (x = 0 to 255) {
            data = memory[address++];
            checksum += data;
            nibbleOut(data);
      }
      nibbleOut(checksum>>4);
      nibbleOut(checksum);
      uart.load(LF);
}

function nibbleOut(nibble) {
      byteData = nibble + (nibble >= 10) ? (- 10 + "a") : "0";
      uart.load(byteData);
}

前のブログ 次のブログ

上位モジュールの設計

1バイトの送信はうまく行ったようなので、上位モジュールMemoryDumpを設計します。概略仕様を以下に示します。

• 1ワードが4bitで構成されるメモリをダンプします。
• メモリのアドレス0からの内容を65536ワード送信します。
• 256行×256列で送信し、1行毎にチェックサムを送信します。
• 1バイトのバイナリは表示可能な2バイトのアスキーコードに変換します。
• 行末は改行します。

メモリ空間は64Kバイトあります。以下にアルゴリズムをC likeの疑似コードにより示します。

疑似コード

int x, y, address;
byte data, checksum, upper, lower;

address = 0;
for (y=0 to 255) {
      checksum = 0;
      for (x = 0 to 255) {
            data = memory[address++];
            checksum += data;
            data += (data >= 10) ? (-10 + "a") : "0";
            uart.load(data);
      }
      upper = (checksum >> 4) &  8'h0f;
      upper += (upper >= 10) ? (-10 + "a") : "0";
      uart.load(upper);
      lower = checksum &  8'h0f;
      lower += (lower >= 10) ? (-10 + "a") : "0";
      uart.load(lower);
      uart.load(LF);
}

前のブログ 次のブログ

UARTのインタフェース

UARTのポート定義は次の図のようになります。

• データ: load_newdata (8bit, 入力)
• Ready: RDY_load (1bit, 出力)
• Enable: EN_load (1bit, 入力)

の3種があり、ReadyとEnableは自動生成されています。ここでReadyはモジュールの受信可能なタイミングを表し、一方EnableはテストベンチからのデータがValidであることを表します。

テストベンチでのモジュール呼び出しは次の図のようになります。

シミュレーション波形は次の図のようになります。

まずRDY_load(オレンジ)がアサートされて受信可能状態になっているとき、55H(赤)というデータが準備できた際にEN_load(赤)がアサートされます。すると次のサイクルで55H(黄)がUART内部に受け付けられ、同時にRDY_load(オレンジ)がネゲートされ、EN_load(赤)もネゲートされます。

テストベンチはすぐにRDY_load(オレンジ)のアサートを待っていますが通信時にはRDY_load(オレンジ)はネゲートされています。次にRDY_load(オレンジ)がアサートされた時点でEN_load(赤)を出力し同時にデータAAH(赤)を出力します。次のサイクルでデータAAH(黄)が受けつけられます。

このようなハンドシェークが自動的に、誤りなく生成されることもBSVの魅力です。

前のブログ 次のブログ

BSVによるインタフェース生成

BSVによるハンドシェークインタフェース信号の生成を細かく見ていきます。 注目するのは、テストベンチからUARTに与える8ビットデータとそのハンドシェーク信号です。記述はデータ(data)だけですが、ハンドシェーク信号(RDY_data, EN_data)が自動的に生成されます。その様子を図396.1に示します。左側がテストベンチで、右側がUARTモジュールです。

右側のモジュールから見た信号は以下のようになります。

• データ: data (8bit, 入力)
• Ready: RDY_data (1bit, 出力)
• Enable: EN_data (1bit, 入力)

ここでRDY_dataはモジュールの受信可能なタイミングを表し、一方EN_dataはテストベンチからのデータがValidであることを表します。

RDYの確認とENのアサートが同サイクルであることに注意します。通常のFF受けの設計だと、RDYを確認した次のサイクルからENのアサートになりそうですが、ENは次のようにRDYを含む組み合わせ回路により構成されています。そのため、ENはRDYと同タイミングでアサートされます。

ENはFF受けされるので、組み合わせ回路出力でヒゲが有っても良いという考えなのでしょうか。このほうがレイテンシが短縮されるため、上手な設計と言えます。

前のブログ 次のブログ

Verilogシミュレーション

bscにより階層的にverilogファイルを生成し、iverilogによりverilogシミュレーションを行います。さらに波形を観測します。太字は入力文字を示します。

$ bsc -u -verilog Tb.bsv
checking package dependencies
compiling ./Uart.bsv
code generation for mkUart starts
Verilog file created: mkUart.v
compiling Tb.bsv
code generation for mkTb starts
Verilog file created: mkTb.v
All packages are up to date.
$ iverilog top.v mkTb.v mkUart.v -o mkTb
$ ./mkTb 
VCD info: dumpfile mkTb.vcd opened for output.
$ gtkwave -A mkTb.vcd

GTKWave Analyzer v3.3.107 (w)1999-2020 BSI

[0] start time.

前記事に示すように、データ55H, AAH, C3H, 3CHを順に送信する場合の、モジュールの内部の波形です。

• 最初にデータがAAHになっていますが、BSVでは不定値をAAHで表しています。最初の送信データは55Hです。
• モジュールからRDY_load(青)がアサートされているので、テストベンチからデータが出力されると同時にEN_load(黄)がアサートされます。
• 次に内部レジスタdata(緑)が55Hに変化します。同時にdoneがネゲートされます。同時にFSMの開始レジスタfsm_start_reg(赤)がアサートされます。
• 次にfsm_start_reg_1(赤)がアサートされ、FSMが開始します。そのタイミングでodata(青)のスタートビット(=L)を出力します。
• 次にodata(青)の8bitをLSBから順に10101010と出力します。これはデータが55Hであるためです。
• 最後にストップビット(=H)を2bit出力します。
• 次にdone(緑)がアサートされ、同時にRDY_load(青)がアサートされます。

• 次の送信データはAAHです。
• 次にモジュールからRDY_load(青)がアサートされているので、テストベンチからデータが出力されると同時にEN_load(黄)がアサートされます。
• 次に内部レジスタdata(緑)がAAHに変化します。同時にdoneがネゲートされます。
• 次にFSMの開始レジスタfsm_start_reg(赤)がアサートされます。
• 次にfsm_start_reg_1(赤)がアサートされ、FSMが開始します。そのタイミングでodata(青)のスタートビット(=L)を出力します。
• 次にodata(青)の8bitをLSBから順に01010101と出力します。これはデータがAAHであるためです。
• 最後にストップビット(=H)を2bit出力します。
• 次にdone(緑)がアサートされ、同時にRDY_load(青)がアサートされます。

• 次の送信データはC3Hです。
• 次にモジュールからRDY_load(青)がアサートされているので、テストベンチからデータが出力されると同時にEN_load(黄)がアサートされます。
• 内部レジスタdata(緑)がC3Hに変化します。同時にdoneがネゲートされます。同時にFSMの開始レジスタfsm_start_reg(赤)がアサートされます。
• 次にfsm_start_reg_1(赤)がアサートされ、FSMが開始します。そのタイミングでodata(青)のスタートビット(=L)を出力します。
• 次にodata(青)の8bitをLSBから順に11000011と出力します。これはデータがC3Hであるためです。
• 最後にストップビット(=H)を2bit出力します。
• 次にdone(緑)がアサートされ、同時にRDY_load(青)がアサートされます。

• 次の送信データは3CHです。
• 次にモジュールからRDY_load(青)がアサートされているので、テストベンチからデータが出力されると同時にEN_load(黄)がアサートされます。
• 次に内部レジスタdata(緑)が3CHに変化します。同時にdoneがネゲートされます。同時にFSMの開始レジスタfsm_start_reg(赤)がアサートされます。
• 次にfsm_start_reg_1(赤)がアサートされ、FSMが開始します。そのタイミングでodata(青)のスタートビット(=L)を出力します。
• 次にodata(青)の8bitをLSBから順に00111100と出力します。これはデータが3CHであるためです。
• 最後にストップビット(=H)を2bit出力します。
• 次にdone(緑)がアサートされ、同時にRDY_load(青)がアサートされます。
• テストベンチはdoneを監視しているので、doneがアサートされると終了です。

前のブログ 次のブログ

トップモジュールの修正

同様にC-c C-aを実行することにより、トップモジュールを修正します。クロックとリセットのレジスタが生成され、呼び出すモジュールのクロックとリセットにそれぞれ接続されます。以下にソースの変化点だけを示します。

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));

前のブログ 次のブログ