image.ubとはKernelやDevice Treeをまとめたu-bootのブートイメージです。

Xilinx系の評価プロジェクトでこれが提供されていることがあるのだが、ここからDeviceTreeを取り出したくなるときがある。

そのためのメモである。

image.ubを生成するにはmkimageを使用するが、抜き出しにはdumpimageを使用する。

まずはimage.ubがどのように構成されているか確認する。

$ dumpimage -l image.ub
FIT description: U-Boot fitImage for PetaLinux/4.14-xilinx-v2018.3+gitAUTOINC+eeab73d120/plnx-zynqmp
Created:         Tue May 26 22:38:33 2020
 Image 0 (kernel@1)
  Description:  Linux kernel
  Created:      Tue May 26 22:38:33 2020
  Type:         Kernel Image
  Compression:  gzip compressed
  Data Size:    7111615 Bytes = 6944.94 KiB = 6.78 MiB
  Architecture: AArch64
  OS:           Linux
  Load Address: 0x00080000
  Entry Point:  0x00080000
  Hash algo:    sha1
  Hash value:   a28aa4f3f6dc093f484e3d8f62383a7827a6ec49
 Image 1 (fdt@system-top.dtb)
  Description:  Flattened Device Tree blob
  Created:      Tue May 26 22:38:33 2020
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    36434 Bytes = 35.58 KiB = 0.03 MiB
  Architecture: AArch64
  Hash algo:    sha1
  Hash value:   8100aa8e2a88a8e18696033cf27161d56b5b3ad1
 Default Configuration: 'conf@system-top.dtb'
 Configuration 0 (conf@system-top.dtb)
  Description:  1 Linux kernel, FDT blob
  Kernel:       kernel@1
  FDT:          fdt@system-top.dtb
  Hash algo:    sha1
  Hash value:   unavailable

つまり、imageが2個とconfigが1個入っていることになっている。

抜き出すのは2個目のimageで次のようにする。

$ dumpimage -T flat_dt -p 1 -o hoge.dtb image.ub

あとはdtcでテキストにしちゃえばいいだけ。

Draw.ioとはdiagrams.netが提供しているMicrosoft VisioやInkscapeなどのツールと同等レベルのドローツールです。

筆者はよく使うドローツールです。

Web上でお絵描きできるツールとして有名ですがWebだけではなく、Windows、Mac、Linuxなどのネイティブアプリでも提供されています。

Web上ではファイルの保存先を直接、google driveやdropboxなどオンラインストレージを指定できるのでオンラインストレージでファイルを管理して使われている方も多いのではないかと思います。

Draw.ioで作成した絵に限らず、他のドローツールで作成した絵であってもその絵だけで資料が完成することはほぼありません。

何らかの文書とともに絵が存在して一つの資料としてまとまると思います。

このDraw.ioが非公式ながらVSCodeのExtensionとしてインストールすることができます。

インストール

ファイルオープン

ファイルの拡張子は.drawio、.dio、.drawio.svgとなっているとEXPLORERでファイルを選択時すると自動的にDraw.ioで開きます。

ここでは、作成済みのファイルをオープンしていますがファイルを新規作成するとブランクなキャンパスで開くことができます。

キャンパス色の変更

ファイルオープンで見えるキャンパスはwebで作成したファイルを持ってきたものです。

Webでは白背景のキャンパスで作成したものでした。

VScodeは黒背景になっているので文字が消えてしまったいるように見えます。

筆者はキャンパスは白背景で良いのでVScodeのDraw.ioのThemeを変更します。

VScodeでFile→Preference→Hediet > Vscode-drawio:Themeを開いて、atlasに変更します。

キャンパスを白背景にすると次のようになります。

これでWebと同じキャンパスで描けるようになります。

Webで作成

WebでDraw.ioを使うにはdiagrams.netに直接アクセスするか、google driveであれば新規→その他→diagrams.netで作成することができます。

google driveからVSCodeへ

今までにgoogle driveなどで作成した絵はダウンロードして使うことができます。

google driveで保存されるファイルは.drawioですがfile→export→XMLでXMLファイルとしてダウンロードします。

ダウンロードすると拡張子が.xmlになるので.drawioまたは.dioに変換するとVSCodeでもそのまま読み込むことができます。

あとがき

筆者としてはドキュメントとDraw.ioで作成した絵に限らずドキュメントに掲載する元ファイルは一元管理したい思いがあります。

今まではgoogle driveでDraw.ioの絵を描いて、PNGでダウンロードしてMarkdownのドキュメントに入れてということをして、ドキュメントと絵を2つの場所で管理していましたがVScodeでDraw.ioができるようになってドキュメントと絵を一元管理して、githubに入れることができるようなりました。

VScodeは結構便利です。

なんでもかんでもVScodeでというのもあとあと危険な可能性もあるのですが今のところ、いい感じなので当分はこのまま使用していきます。

結局、STAで問題なければよいのでどの記述でもいいわけなんだけど、他にいくつか試してみた。

信号名をRSTでないケース

ケース２と同じ記述でRST_NからRSTを削除したものです。

`default_nettype none
`timescale 1ns/1ps

module fftest5
(
    input wire DINX,
    input wire CLK,

    input wire DIN0,
    input wire DIN1,
    input wire DIN2,
    input wire DIN3,
    input wire DIN4,
    input wire DIN5,
    input wire DIN6,

    output reg DOUT
);

reg CLK_DINX;

always @(posedge CLK) begin
    CLK_DINX <= DINX;
end

always @(posedge CLK) begin
    if(!CLK_DINX) begin
        DOUT <= 0;
    end else begin
        DOUT <= DIN0 | (DIN1 & DIN2 & DIN3 & DIN4 & DIN5 & DIN6);
    end
end

endmodule

`default_nettype wire

結果はケース２と同じになりました。

0への初期化はリセットと認識されるんですかね？

三項演算子にしたケース

RST名前もなしに三項演算子で0に初期化するケースです。

`default_nettype none
`timescale 1ns/1ps

module fftest7
(
    input wire DINX,
    input wire CLK,

    input wire DIN0,
    input wire DIN1,
    input wire DIN2,
    input wire DIN3,
    input wire DIN4,
    input wire DIN5,
    input wire DIN6,

    output reg DOUT
);

reg CLK_DINX;

always @(posedge CLK) begin
    CLK_DINX <= DINX;
end

always @(posedge CLK) begin
    DOUT <= (!CLK_DINX)?0:(DIN0 | (DIN1 & DIN2 & DIN3 & DIN4 & DIN5 & DIN6));
end

endmodule

`default_nettype wire

この場合もケース２と同じ結果になった。

0への初期化はRSTとして認識するんですね。

論理に組み込んだケース

初期化するというよりかいネーブル信号に近い形にしたケースです。

`default_nettype none
`timescale 1ns/1ps

module fftest6
(
    input wire DINX,
    input wire CLK,

    input wire DIN0,
    input wire DIN1,
    input wire DIN2,
    input wire DIN3,
    input wire DIN4,
    input wire DIN5,
    input wire DIN6,

    output reg DOUT
);

reg CLK_DINX;

always @(posedge CLK) begin
    CLK_DINX <= DINX;
end

always @(posedge CLK) begin
    DOUT <= CLK_DINX & (DIN0 | (DIN1 & DIN2 & DIN3 & DIN4 & DIN5 & DIN6));
end

endmodule

`default_nettype wire

この場合は次のようになりました。

ケース２に比べてLUTが1個減り、つぎの構成になりました。

• DINXのFF
• DOUTのFF
• (DIN1 & DIN2 & DIN3 & DIN4 & DIN5 & DIN6)のLUT
• CLK_DINX & (DIN0 | 上記の信号)のLUT

だから、なんなのさぁと言われても何もないんですけどね。

「同期/非同期リセットでの生成回路の違い(1)」の合成結果でつぎのようにでていました。

ケース３は同期リセット、ケース４は非同期リセットを想定して記述したものでしたが上記の結果からもケース３にはリセットのFFはなく、ケース4は明示的にFFを置いているのでリセットのFFが存在します。

ケース３は次のように構成されてほしかったのです。

ケース３の場合、記述は同期リセットのつもりなのに非同期リセットなのでRecovery TimeとRemoval Timeを考慮する必要があります。

同期リセットで表現したつもりが合成するとRecovery TimeとRemoval Timeが考慮され、動作周波数が低い合成結果か、または、できないかが発生するかもしれません。

ケース４は同期リセットのつもりだけど記述が非同期リセットっぽくなっているが同期リセットで合成されたのはある意味、棚から牡丹餅なのかもしれません。

太古の昔の言い伝えは今、どうなっているか確認するつもりでしたがもう言い伝えは今の時代には通用しなく、新しい問題が発生しているということがわかりました。

XilinxのツールはRSTの名称がついているとリセット信号として通常の信号とは違う扱いにするようです。

ただ、配置配線もリセットにFFがあるので同期リセットっぽい、FFが無いので非同期リセットっぽいのはCellの設定を見ても判断を付けにくい。

ただ、これらの状況から言えるのはケース２やケース４のようにリセットはFFで叩いてから使うのが良いだろう。

そして、ツールを信用するしかない・・・

BUFGが余っているなら次のようにRSTを2段FFでメタス回避してBUFGを使用して各FFをリセットするのが良いだろう。

次に実際の合成結果を配置の観点から見てみます

ケース０

ケース０の場合、リセットがないので綺麗に1つのCLKで2つのLUTが使われました。

ケース１

ケース１の場合は次のように配置されました。

まずは全体は2つのCLBに別れました。

下側が6つのANDのLUT、上側がリセットとORのLUTです。

ケース２

ケース２も2つのCLBに配置されましたがケース１のように離れた場所ではなく近接のCLBで配置されました。

ケース３

ケース３はケース１と同じように配置されました。

ケース４

ケース４はケース２と同じように配置されました。

よくみると

配置結果を見てみると、ケース３は非同期リセットでケース４は同期リセットになっていました。