Posts Tagged with "Design"

既に発行済みのブログであっても適宜修正・追加することがあります。
We may make changes and additions to blogs already published.
posted by sakurai on September 26, 2023 #668

過去記事で設計したPCパイプラインをモジュールに変更し、その上にテストベンチをかぶせます。以下にテストベンチTb.bsv及びPCパイプラインProcessor.bsvのソースを示します。

Tb.bsv

import StmtFSM::*;
import Processor::*;

(* synthesize *)
module mkTb();
    Empty proc <- mkProcessor();
    Stmt main = seq
        delay(30);
        $finish;
    endseq;
    mkAutoFSM(main);
endmodule

Processor.bsv

import FIFO::*;

(* synthesize, always_ready *)
module mkProcessor(Empty);

    Reg#(int)  pc     <- mkReg(0);
    FIFO#(int) ifs    <- mkFIFO;
    FIFO#(int) ids    <- mkFIFO;
    FIFO#(int) exs    <- mkFIFO;
    FIFO#(int) mas    <- mkFIFO;
    FIFO#(int) wbs    <- mkFIFO;

     // <PC>
     rule pc_stage;
        if (pc > 100) $finish(0);
        $display("------");
        ifs.enq(pc);
        pc <= pc + 4;
     endrule

     // <IF>
     rule if_stage;
        let pc_if = ifs.first;
        ifs.deq;
        $display (" pc_if = %04h", pc_if);
        ids.enq (pc_if);
     endrule

     // <ID>
     rule id_stage;
        let pc_id = ids.first;
        ids.deq;
        $display (" pc_id = %04h", pc_id);
        exs.enq (pc_id);
     endrule

     // <EX>
     rule ex_stage;
        let pc_ex = exs.first;
        exs.deq;
        $display (" pc_ex = %04h", pc_ex);
        mas.enq (pc_ex);
     endrule

     // <MA>
     rule ma_stage;
        let pc_ma = mas.first;
        mas.deq;
        $display (" pc_ma = %04h", pc_ma);
        wbs.enq (pc_ma);
     endrule

     // <WB>
     rule wb_stage;
        let pc_wb = wbs.first;
        wbs.deq;
        $display (" pc_wb = %04h", pc_wb);
     endrule

endmodule: mkProcesso

コンパイルと起動コマンドは以下のとおりです。gtkwaveはここ

\$ bsc -u -sim Tb.bsv; bsc -sim -e mkTb -o mkTb.exe; ./mkTb.exe -V; gtkwave -A dump.vcd

図%%.1
図668.1 PCパイプラインの波形

左矢前のブログ 次のブログ右矢

Ultra96toPMODの追加製造費用

posted by sakurai on May 29, 2023 #608

Ulta96toPMOD基板製造再見積り

JLCPCBがPCBA(PCB製造及び部品実装)のセールをやっているようなので, 以前掲載したUltra96toPMODボードのオーダー費を再度計算してみました。

前回と同様パープルとグリーン基板を10枚製造し、さらにICを2個/枚×10枚実装した場合の費用の内訳を示します。前回パープル基板はEconomyの有利な価格で基板が製造できず、Standardとなっていました。今回はパープルもグリーンと同じEconomy扱いに変更されています。

表608.1 Ultra96toPMOD Jlcpcbの費用構成
10枚製造時費用内訳 基板色[USD]
グリーン パープル
PCB Special Offer Price 5.00
Components(TXS0108EPWR --- 20個) 9.39
Extended Components 2.96
SMT Assembly 0.65
Setup fee 7.88
Stencil 1.48
合計 27.36
送料(OCS Express:6~8日) 11.68
総計 39.04

前回と比較してみると、部品(レベコンIC)代が若干安くなり、セットアップフィー、SMTアセンブリ、ステンシルがほんの少し安くなりました。一方、送料が上がりクーポンが使えないので、40.2%の値上げ(パープルは28.6%の値下げ)という結果になりました。

今回、再度BokTech及びSeeedFusion PCBの見積もりを取りましたが、それぞれこの2倍、4倍ほどの費用となりました。JLCPCBの安さが光ります。

PMODピンソケットコネクタの再オーダー

PMOD仕様の12ピンソケットの型格はSamtec製のSSW-106-02-T-D-RAです。

図%%.1
図608.1 SSW-106-02-T-D-RA

以前オーダーしたときはMouser から購入しました。この時は単価が141円と安く送料が無料なこともあり、総額が安かったのですが、今回見積もったら単価が258円とかなり値上がりしていたため、Arrowから購入しました。

再度調べたところ、以下のように最安はChip 1stopでした。単価的にはArrowと同じですが、送料が無料となることから、今後はChip 1stopで購入しようと思います。

  • Chip1stop 単価156.2 x 40(送料650)= 6,899円 (税込み) 最安
  • Arrow 単価156.2 x 40(送料3,080)= 9,330円 (税込み)
  • RSオンライン 単価254.9x 40 (送料無料) =10,199円 (税込み)
  • Mouser 単価263.6 x 40 (送料無料) =10,542円 (税込み)

図%%.2
図608.2 送付部品(SSW-106-02-T-D-RA)

本ピンソケット互換品でA2541HWR-2x6Pという製品があるようです。


左矢前のブログ 次のブログ右矢

Ultra96toPMODのBOM

posted by sakurai on May 26, 2023 #607

Ultra96toPMODのBOM

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

表607.1 Ultra96toPMODボードBoM
Degignator Value Qty MPN
C1, C2, C4, ..., C11 0.1u 10 Multilayer Ceramic Capacitor
C3 10u 1 47 µF 50 V Aluminum Electrolytic Capacitors Radial
J1, ..., J4 SSW-106-02-T-D-RA 4 SSW-106-02-T-D-RA
J100 MTMM-120-03-T-D-155 1 MTMM-120-03-T-D-155
LED1 TLLR4400 1 Red LED 3mm Through Hole
R1 470 1 Axial Carbon Film Resistor
R2, ..., R4, R6 3.3k 4 Axial Carbon Film Resistor
R5 10k 1 Axial Carbon Film Resistor
SW1 COUNT 1 4bit DIP SW
SW2 RESET 1 Tactile Push SW
TP1, ..., TP10 Test Pin 10 Test Pin
U1, U3 TXS0108EPWR-TSSOP20 2 Level Converter IC (SMD)
U2 DC DC Converter IC 1 PQ3RD23

Online-shopの開設

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

図%%.1
図607.1 オンラインショップ画面

左矢前のブログ 次のブログ右矢

PL UARTの接続とPCでの表示

posted by sakurai on May 17, 2023 #605

PL部UARTのPCへの出力

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

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

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

図%%.1
図605.1 Ultra96 UART部分回路図

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端子となっています。

図%%.2
図605.2 Ultra96 UART部分端子表

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

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

図%%.3
図605.3 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に示します。

図%%.3
図605.4 メモリダンプ図形

左矢前のブログ 次のブログ右矢

posted by sakurai on December 23, 2022 #576

制御パイプライン

1段FIFOのDEQ修正ではうまく行かないと勘違いして2段FIFOを検討してきましたが、記事で述べたように、LFIFOというパイプライン動作するFIFOと論理が同じであり、それを使用することで正常動作することが判明しました。

さてPC等のデータパイプラインの設計が確定したところで、制御パイプラインを設計します。どこが異なるかと言うと、データパイプラインにはvalid bitが無いのに対して、制御パイプラインにはvalid bitが存在することです。さらにvalid bitの制御は、ウエイトするステージの上流ステージはパイプラインを止める制御行いvalid bitは変更しませんが、下流ステージに対してはinvalidを流す必要があることです。こうしないとウエイトで加算命令が止まっている場合に、加算器がウエイトの回数だけ加算し続けるという現象が起きます。これを防止するために、ウエイト時は下流にinvalidを「流し」ます。$\dagger$

BSVはデータおよびその有効性を示すビット(valid bit)の組をMayBeという「曖昧な用語」できちんと定義します。MayBeな制御データに対して有効か無効かを判定するにはisValid()メソッドを使用します。またMayBeが有効である場合に制御データを取り出す場合はfromMayBe()メソッドを使用します。

これを具体的なタイムチャートで示します。

図%%.1
図576.1 パイプラインシミュレーション

その後、full/emptyの動作がverilogと不一致となる等おかしかったので、Bluespecに報告したところ、LFIFOは古いので、PipelinedFIFOを使用するように勧められました。


$\dagger$:パイプライン用語で、(パイプラインに沿って)「流す」という用語は、下流に向かっては次のステージは次のサイクル先頭でラッチし、その次のステージは、その次のサイクル先頭でラッチすることを意味します。下流に向かってはクロックは停止せず、valid bitで制御します。一方で上流に向かっては「同一サイクルで止める」という言い方をします。この場合はクロックを停止するかサイクルを再実行することになります。上流へと下流へでは制御のやり方が変わってくるわけです。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 21, 2022 #575

2段FIFOの修正

前記事で記載したようなウエイト制御を行えば、実質的に2段FIFOのd1は使用することはないはずです。従ってFIFO2.vからd1の本体及び関連制御信号を削除してしまいます。これによりウエイトシミュレーションを実施しましたが、結果は同様でした。これで実質FIFO1を設計することができました。

違いは、元のFIFO1ではempty=!fullというロジックだったものが、新FIFO1ではemptyとfullが3状態を取るようになったことです。しかし、1段しか無いということは永久にfullにはならないということなので、元のFIFO1でfullをFalse固定としても動作しそうです。

早速元のFIFO1を修正してシミュレーションしてみました。

図%%.1
図575.1 パイプラインシミュレーション

同じく、読み取りにくいので表にしてみます。

表575.1 PCアドレス表
ステージ 0 1 2 3 4 5 6
PC 006c 0070 0070 0070 0074 0078 007c
IF 0068 006c 006c 006c 0070 0074 0078
ID 0064 0068 0068 0068 006c 0070 0074
EX 0060 0064 0064 0064 0068 006c 0070
MA 005c 0060 0064 0064 0064 0068 006c
WB 0058 005c 0060 0064 0064 0064 0068

オリジナルFIFO2と全く同じ結果となりました。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 20, 2022 #574

2段FIFOの修正

さらにFIFO2に変えて各ステージにウエイトを入れる修正を行いました。<WB>だけはウエイト要因が無いためウエイト信号はありません。他のステージでも検討の結果無くなる可能性はあります。

  • <PC>: pc_wait
  • <IF>: if_wait
  • <ID>: id_wait
  • <EX>: ex_wait
  • <MA>: ma_wait

これをシミュレーションした結果、あるステージでウエイトがかかると当然そのステージの上位からENQできなくなるはずですが、FIFOが2段のため、もう1個は受け付けるようになります。これは制御が複雑になるものの性能は向上しないので過去記事で検討したように、あるステージからは上位にウエイトを上げるような接続にします。それぞれのステージ固有のウエイト信号です。

  • <PC>: pc_wait
  • <IF>: if_wait
  • <ID>: id_wait
  • <EX>: ex_wait
  • <MA>: ma_wait

これらを下記のように上位へ伝える結線を行います。

 let mas_wait = ma_wait;
 let exs_wait = ex_wait || mas_wait;
 let ids_wait = id_wait || exs_wait;
 let ifs_wait = if_wait || ids_wait;
 let pcs_wait = pc_wait || ifs_wait;

これによりBluespec謹製FIFO2.vと修正版FIFO2.vでシミュレーションを実行しました。これは<ID>にウエイトが2サイクル入った場合のタイミングですが、微妙な差が出ています。まずBluespec謹製版です。

図%%.1
図574.1 パイプラインシミュレーション

次に弊社での修正版です。

図%%.2
図574.2 パイプラインシミュレーション

読み取りにくいので、表にしてみます。まずBluespec版です。<ID>の2, 3サイクル目に2サイクルのid_wait信号がアサートされた場合です。直接アサートされたサイクルをライトグリーンで、それが同一サイクル内で上流に伝わったステージをライトブルーで塗っています。

表574.1 PCアドレス表
ステージ 0 1 2 3 4 5 6
PC 006c 0070 0070 0070 0074 0078 007c
IF 0068 006c 006c 006c 0070 0074 0078
ID 0064 0068 0068 0068 006c 0070 0074
EX 0060 0064 0064 0064 0068 006c 0070
MA 005c 0060 0064 0064 0064 0068 006c
WB 0058 005c 0060 0064 0064 0064 0068

次に弊社版です。表574.1と相違する部分をライトグレーで塗りました。

表574.2 PCアドレス表
ステージ 0 1 2 3 4 5 6
PC 006c 0070 0070 0070 0074 0078 007c
IF 0068 006c 006c 006c 0070 0074 0078
ID 0064 0068 0068 0068 006c 0070 0074
EX 0060 0064 0068 0000 0068 006c 0070
MA 005c 0060 0064 0068 0000 0068 006c
WB 0058 005c 0060 0064 0068 0000 0068

これで見るとわかるように、ウエイトが入った場合に下流のPC値が相違しています。

本来、パイプラインストールで停止したステージの下流のステージはいわゆるパイプラインバブルとなり、PC値は保証されないはずです。別に設ける予定のバリッドビットが値の妥当性を決めるため、PC値は不定で良いはずです。

パイプラインステージの再実行かと言えば、例えば64番地の命令は繰り返す必要は有りませんし、繰り返してはいけません。例えば64番地の<EX>がデータインクリメント(+1)だった場合には3回の再実行により+3を加算することになり、明らかに誤りです。再実行されるのは、パイプラインウェイトが入ったステージとその上流である68番地以降の再実行となります。

プロセッサではウエイトが入った場合は結果が保証されないのですが、シストリックアレイのような応用ではデキューされた後の状態が同じ状態であって欲しいのかもしれません。そうなると、1, 3, 4, 7も保持(d0)する必要があるかもしれません。試しにd0hに1, 3, 4, 7のケースを加え、反対にd0diに3, 7を加えていたものを引けば、Bluespecと一致する論理となりました。

結論としては推測となりますが、BluespecのFIFO2はデキューしても元の値を保持するのが仕様のようです。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 19, 2022 #573

1段FIFOの検討

FIFOどうしを上位で接続する場合の結線を見ると、図573.1のようになっています。

図%%.1
図573.1 FIFO間の結線

上位ステージFIFOにデータが存在し(!empty)かつ下位ステージFIFOがフルでなければ(!full)上位ステージFIFOのDEQと下位ステージFIFOのENQが同時に実行されます。1段FIFOの実現性を考えると、下位のDEQが有れば上位に!fullになるように制御すれば良さそうです。

修正前の1サイクルおきの動作を示します。

図%-%.1
図573.1 1段FIFOの動作(修正前)

元の論理はemptyとfullは背反論理であり、

 assign FULL_N = !empty_reg;
 assign EMPTY_N = empty_reg ;

このようになっていましたが、これに対して、

 assign FULL_N = !empty_reg || DEQ;
 assign EMPTY_N = empty_reg ;

のように修正したシミュレーション結果を示します。

図%-%.2
図573.2 1段FIFOの動作(修正後)

このように正しく動作しました。なお、この論理はパイプラインFIFOと呼ばれるLFIFOと全く同じであり、ソースに対して

 FIFO#(int) ifs    <- mkLFIFO;

のようにパイプラインFIFOを生成しても全く同じ動作を行います。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 16, 2022 #572

1段FIFOの検討

全く同様に1段FIFOを検討します。ここでの改善点はFullになっている場合にDEQ$ \cap $ENQを実行すると、1サイクル毎にアップデート可能な制御を行うことです。

図%-%.1
図572.1 1段FIFOの動作

表572.1 FIFO段制御表
No. State DEQ/ENQ d0入力制御
0 --- CLR D.C.
1 State0(E:1, F:0) !DEQ$ \cap $!ENQ D.C.
2 !DEQ$ \cap $ENQ d_in
3 DEQ$ \cap !$ENQ D.C.
4 DEQ$ \cap $ENQ D.C.
9 State1(E:0, F:1) !DEQ$ \cap $!ENQ d0
10 !DEQ$ \cap $ENQ D.C.
11 DEQ$ \cap !$ENQ D.C.
12 DEQ$ \cap $ENQ d_in

表より、ENQがアサートされたらd_inを入力する制御とします。

次にステート遷移表です。

表572.2 ステート遷移表
No. Current State ENQ/DEQ Next State
0 --- CLR State0(E:1, F:0)
1 State0(E:1, F:0) !DEQ$ \cap $!ENQ State0(E:1, F:0)
2 !DEQ$ \cap $ENQ State1(E:0, F:1)
3 DEQ$ \cap $!ENQ ERROR
4 DEQ$ \cap $ENQ ERROR
9 State1(E:0, F:1) !DEQ$ \cap $!ENQ State1(E:0, F:1)
10 !DEQ$ \cap $ENQ ERROR
11 DEQ$ \cap $!ENQ State0(E:1, F:0)
12 DEQ$ \cap $ENQ State1(E:0, F:1)

これをこのまま実装するとState1の時にENQをアサートしようとしても、既にfullであるため、キューに入らない事態になります。これをfull=0として見せてやれば同時にDEQする時に限りキューに入れることができます。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 15, 2022 #571

2段FIFOの検討(4)

ここまでで自作FIFO2.vの論理が確定しました。そこでBluespec作成のライブラリであるverilogの論理FIFO2.vと一致するかを確認します。

d0diの論理の手圧縮の結果はd0di = (ENQ && empty == 1) || (DEQ && full == 0)です。一方、Bluespec製verilogソースは、

$BLUESPECDIR/Verilog/FIFO2.v

wire                   d0di = (ENQ && ! empty_reg ) || ( ENQ && DEQ && full_reg ) ;

です。Bluespecと1項目は一致しています。

一方2項目目は不一致です。Bluespecには若干無駄があるようです。これをケース分解すれば、2項目は4, 8ですがさらにD.C.である3と7を加えることができます。ちなみにBluespecではempty_reg及びfull_regはなぜか負論理なので、!empty_regはemptyを、full_regは!fullを意味します。

次にd0d1の論理は、d0d1 = DEQ && full == 1ですがBluespec製verilogソースは、

wire                   d0d1 = DEQ && ! full_reg ;

であり、完全一致しました。

次に、d0hの論理は、d0h = !DEQ && empty == 0ですがBluespec製verilogソースは、

wire                   d0h = ((! DEQ) && (! ENQ )) || (!DEQ && empty_reg ) || ( ! ENQ &&full_reg) ;

であり、かなり無駄があるようです。

Bluespec製verilogソースをケース分解すれば、1項目は1,5,9、2項目は5,6,9,10、3項目は1,3,5,7です。必要なのは5,6,9だけなので2項目のみで全てを満たしているのですが、BluespecはState0でもホールドするとして1項目を加えたようです。State0ではデータは無効なのでホールドの必要はありませんがState0で何も起きない場合のホールドである1と、State1からDEQされた場合の7が追加されています。

3項目はState0, 1でENQとならない場合という意味ですが、そもそもState0では無効データのためホールドの必要は無いし、State1でもDEQの場合(7)はホールド不要です。

【追記】無効データではあるものの、DEQされた場合やENQもDEQも無い場合は、前の値を保持するというのがBluespecの仕様のようです。

最後にd1diの論理は、d1di = ENQ && empty == 0ですがBluespec製verilogソースは、

wire                   d1di = ENQ & empty_reg ;

であり、完全一致しました。弊社の論理に変更したFIFOライブラリを用いてシミュレーションを実行しましたが、正常に動作しました。

さらに、ステート遷移は、手圧縮では、

  • CLRのとき、empty = 1, full = 0
  • !DEQ && ENQのとき、empty = 0, full = !emtpy
  • DEQ && !ENQのとき、empty = !full, full = 0
  • 上記以外のときはホールド。emtpy, full共変化無し。

となりましたが、Bluespec製verilogソースでは、

        begin
            if (CLR)
               begin
                  empty_reg <= `BSV_ASSIGNMENT_DELAY 1'b0;
                  full_reg  <= `BSV_ASSIGNMENT_DELAY 1'b1;
               end // if (CLR)
             else if ( ENQ && ! DEQ ) // just enq
               begin
                  empty_reg <= `BSV_ASSIGNMENT_DELAY 1'b1;
                  full_reg <= `BSV_ASSIGNMENT_DELAY ! empty_reg ;
               end
             else if ( DEQ && ! ENQ )
               begin
                  full_reg  <= `BSV_ASSIGNMENT_DELAY 1'b1;
                  empty_reg <= `BSV_ASSIGNMENT_DELAY ! full_reg;
               end // if ( DEQ && ! ENQ )
          end // else: !if(RST == `BSV_RESET_VALUE)

となっており、完全一致しました。


左矢前のブログ 次のブログ右矢


ページ: