Vengineerの戯言

人生は短いけど、長いです。人生を楽しみましょう!

Intel ISPC v1.18

はじめに

Intel ISPC について、2020年10月に、Intel GPU をサポートするということでした。

vengineer.hatenablog.com

v1.18

Intel ISPC 1.18 Compiler Brings "Significantly Improved" Xe Graphics Performance

www.phoronix.com

おわりに

Intel ISPCで、Intel GPUが普通に使えることになったようです。

ただし、

が必要です。

Intel Accelerator UBB

はじめに

ちょっと古いですが、とあるものを調べていたら、見つけました。

Intel Accelerator UBB、下記のビデオに出てきました。

youtu.be

Intel Accelertor UBB

上記のスクリーンショットを説明のために引用します。

PVCは、Ponte Vecchio GPU のこと。UBBは、8個のPVCを Xe-Link で接続するということ。

最後のところには、

Designed to enable system flexibility and faster OEM time to market to support both PVC and a next generation Gaudi AI processor

とあります。開発中の Gaudi も Xe-Link にて接続するんでしょうか?

また、左下のコネクタ(8個)と LSI(4個)は、ノード間を接続するためのものだと思うのですが、光モジュールで接続しているのでしょうか?

PVC moduleの写真

おわりに

NVIDIA H100 の SMX5 の back size の写真が下記の記事に載っています。説明のために、引用します。OAM v1.1 / v1.5 / v2.0 とは、違うコネクタの配置っぽいですね。。

OAM v1.1 (説明のために引用します)

OAM v1.5 (説明のために引用します)。v1.1 と v1.5 は同じような感じですかね。

OAM v2.0 (説明のために引用します)。

www.servethehome.com

エッシェンシャル思考とエフォートレス思考を読みました

はじめに

グレッグ・マキューン 氏の「エッシェンシャル思考」と「エフォートレス思考」を読みました。

www.amazon.co.jp

www.amazon.co.jp

出版された順番ではなく、「エフォートレス思考」が先で、「エッシェンシャル思考」の順番で読み増した。

Kindle本だと、紙の本の半額でした。

エッシェンシャル思考

出版元(かんき出版)のページはこちら。 2014年11月17日発売。

kanki-pub.co.jp

エフォートレス思考

出版元(かんき出版)のページはこちら。こちらは、ちょっと気合入っている。。2021年12月8日出版。出版されてからまだ日が浅いからかな。

kanki-pub.co.jp

2014年 => 2021年と7年間のブランク。。何故かって?、本文にちょっと書いてある気がします。

気になったところ

  • エッセンシャル思考

「やら なく ては」「 どれ も 大事」「 全部 できる」 ─ ─ この 3つ の セリフ が、 まるで 伝説 の 妖女 の よう に、 人 を 非 エッセンシャル 思考 の 罠 へと 巧み に 誘う。

「 この 仕事 は、 自分 が 今 やれる こと の なか で いちばん 重要 か?」

エッセンシャル 思考 は、 より 多く の こと を やりとげる 技術 では ない。 正しい こと を やりとげる 技術 だ。

自分自身 という 資産 を 守る

「 完璧 を めざす より まず 終わら せろ」

「早く 小さく」 始める

  • エフォートレス思考

ウォーレン・バフェット は、 従業員 や ビジネス パートナー を 選ぶ 際 に、 信頼 を 測る 3つ の 基準 を 用い て いる 。   その 3つ とは「 誠実 さ( Integrity)」「 知性( Intelligence)」「 自発性( Initiative)」 だ。

「信頼」と「信用」は、違うからね。

おわりに

記録として、残しました。

AMD の xGMI とは?

はじめに

AMD の EPYC の IOD (I/O Die)から出ている xGMI (Socket to Socket Global Memory Interconnect )。この xGMI を使って、2個の EPYC を接続しています。

今日のブログでは、xGMI について、調べてみました

AMD Rome

NASAのサイトの下記の資料にあった図(Configuration of an AMD Rome Node)を説明のために引用します。

www.nas.nasa.gov

下図の EPYC 間の説明のところに、

  • 3 link @16 GT/s theoretical 96GB/s (sustained 63.5 - 72 GB/s per direction) とあります。この部分が、xGMI になります。

xGMI

上記の記事に、Inter-Socket Interconnect つまり、xGMI のことについて、説明しています。

Inter-Socket Interconnect Two EPYC 7742 SoCs are interconnected via Socket to Socket Global Memory Interconnect (xGMI) links, part of the Infinity Fabric that connects all the components of the SoC together. In each Rome node configured with the HPE Apollo 9000 system architecture, there are 3 xGMI links using a total of 48 PCIe lanes. With the xGMI link speed set at 16 GT/s, the theoretical throughput for each direction is 96 GB/s (3 links x 16 GT/s x 2 bytes/transfer) without factoring in the encoding for xGMI, since there is no publication from AMD available. However, the expected efficiencies are 66–75%, so the sustained bandwidth per direction will be 63.5–72 GB/s.

Note: The xGMI link speed and width can be adjusted via BIOS setting. The xGMI Link Max Speed can be set to 10.667, 13, 16 or 18 GT/s. Setting it to a lower speed can save uncore power that can be used to increase core frequency or reduce overall power. It will also decrease cross-socket bandwidth and increase cross-socket latency. xGMI Dynamic Link Width Management saves power during periods of low socket-to-socket data traffic by reducing the number of active xGMI lanes per link from 16 to 8.

ここには、3 x GMI links using a total of 48 PCIe lanes とあります。つまり、物理レイヤーとしては、48 lanes の PCIe なんですね。つまり、PCIe x 16 が 3組ということです。

Rome間は、3 x xGMI ということがわかりました。Rome の次の Milan/Milan-X も同じですね。

AMD GPU : MI250X の xGMI は?

下記の記事の中の図を説明のために引用します。

ascii.jp

MI250Xは、2 die で、die 間は 4 x xGMI で接続していますね。各 die から 4 x xGMI、1 package から 8 x xGMIが出ています。その内の 1組が PCIe 4 x16 になります。

PCIe 4 x16 と物理層では同じなんですよね。

ただし、図の黄色の PCIe は、PCIe 4 x16 ではなくて、下記のブログに書いたように、25GT/s なんですよね。PCIe 4 x16 では、16GT/s です。。SERDESは、16Gbps ではなく、25Gbps なんですよね。たぶん。

vengineer.hatenablog.com

おわりに

AMD の xGMI は、

The xGMI Link Max Speed can be set to 10.667, 13, 16 or 18 GT/s.

のようです。

プロトコルは PCIe ではなく、キャッシュコーレンシーを保つようになっているんでしょうね。

AMD Navi 21/22/23 と31/32/33って?

はじめに

今回は、AMDのコンシューマ用GPUである、Navi シリーズについて調べてみました。

既に出ている、AMD Navi 21、今年出てくるであろう Navi 31/32/33 についても調べてみました。

Navi 21/22/23

下記のツイートに、Navi 21/22/23 の die shot が載っています。

  • Navi 21 : Shader Engines (4)、RDNA Workgroups : WGP (40)、GDDR6 256-bit、L3 Cache (64MB + 64MB)
  • Navi 22 : Shader Engines (2)、RDNA Workgroups : WGP (20)、GDDR6 192-bit、L3 Cache (48MB + 48MB)
  • Navi 23 : Shader Engines (2)、RDNA Workgroups : WGP (16)、GDDR6 128-bit、L3 Cache (16MB + 16MB)

Navi 31/32/33

Navi 31/32/33 については、この記事に詳しく書いてありました。

videocardz.com

  • Navi 31 : 2 die、Shader Engines (6)、RDNA Workgroups : WGP (60)、GDDR6 256-bit、L3 Cache (512MB)
  • Navi 32 : 2 die、Shader Engines (4)、RDNA Workgroups : WGP (40)、GDDR6 196-bit、L3 Cache (384MB)
  • Navi 33 : 1 die、Shader Engines (2)、RDNA Workgroups : WGP (20)、GDDR6 128-bit、L3 Cache (128MB + 128MB)

Navi 21/22/23 と比べると、Navi 31/32/33 では、3 vs 2 vs 1 とスケールする感じですね。

それから L3 Cache を増やしています。WGPが40の Navi 21 と Navi 32 を比べると、Navi 21 の 128MBに対して、Navi 32 では 3倍の384MB です。

1 die の NNavi 33 でも 256MB あり、Navi 21の2倍もあります。

一方、メモリコントローラはスケールしていないのは、ピンの制約があるからですかね。

Navi 31 と 32 は、GCD 2 die + MCD 1 die 構成になっていて、GCD内には L3 Cache と GDDR6 がなくて、MCD 内に 搭載しているようです。

GDDR 64-bit あたり、128MB の L3 Cache が付いている感じですね。

NVIDIA Ampere GA102 GPU Architectureのによると、

The memory subsystem of GA102 consists of twelve 32-bit memory controllers (384-bit total). 512 KB of L2 cache is paired with each 32-bit memory controller, for a total of 6144 KB on the full GA102 GPU.

のようなので、メモリコントローラは 32-bit のようです。。となると、64-bit なので、2個のメモリコントローラが付いていることになり、メモリコントローラ当たり、64MB の L3 Cache が付いていることになりますね。

これって、NVIDIA の GA100の全部のL2 Cacheの48MB、GA100の全部のL2 Cacheの60MBよりも多いですね。すごいですよ。

Navi 21/22/23 でも、L3 Cache が 128MB / 64MB / 32MB も載っているんで、AMD は、L3 Cache 大盛が作戦っぽいですね。

AMD GPU のキャッシュの構成

www.coelacanth-dream.com

によると、

Aldebaran (MI200)のCache構成は、

  • 16KB : TCP L1 Cahe per CU (num_cu_shared = 1)
  • 32KB : Scalar L1 instruction Cache per SoC (num_cu_shared = 2)
  • 32KB : Scalar L1 Data Cache per SoC (num_cu_shared = 2)
  • 8192KB : L2 Data Cache per GPU (Total Tex Cache) (num_cu_shared = 14)

HPC用のGPUは、L3 Cacheないんですね。

Navi23のCache構成

  • 16KB : TCP L1 Cahe per CU (num_cu_shared = 1)
  • 32KB : Scalar L1 instruction Cache per SoC (num_cu_shared = 2)
  • 16KB : Scalar L1 Data Cache per SoC (num_cu_shared = 2)
  • 2048KB : L2 Data Cache per GPU (Total Tex Cache) (num_cu_shared = 8)
  • 32x1024KB : L3 Data Cache per GPU (num_cu_shared = 8)

L2は、2MB で、L3は、32MB なんですね。。。

  • Navi22 は、L2 (3MB)、L3 (96MB)
  • Navi21 は、L2 (4MB)、L3 (128MB)

L3 Cache は、Inifinity Cache

pc.watch.impress.co.jp

下図は説明のために引用します。

こでRadeonの開発チームが着目したのは、CPUの開発チームで採用されたL3キャッシュであった。サーバー向けのEPYCに採用されているL3キャッシュは、容量32MBでダイサイズはわずか27平方mm。これはRDNAアーキテクチャのL2キャッシュの4倍に相当する容量密度だという。RDNA 2ではこのキャッシュデザインを採用し、GPUとは16×64b/1.94GHz駆動のInfinity Fabricで接続した。

あー、やっと説明を見つけた。やっぱり、CPUにあるL3 CacheをGPUに取り込んだんですね。

おわりに

今回は、AMDの Navi 21/22/23 と Navi 31/32/33 について、調べてみました。

Intel版Questaで SystemVerilog + SysmteC

はじめに

下記のVerilatorの薄い本、第三弾、SystemC編の例題を、Intel版Questaで動くようにしました。

vengineer.hatenablog.com

Intel版Questaでは、SystemVerilog + SystemC が動く!

Verilator + SystemC で動くなら、Intel版Questaでも動くじゃんということでやってみました。

テストベンチ側がSystemCなので、SystemVerilog側のコードをSystemC側から呼び出せるような仕組みが必要です。

top の修正

Verilatorでは、DUT(RTL記述のSystemVerilog)のトップ階層名は、top にしてあります。トップテストベンチ側は SystemC (sc_main.cpp) です。sc_main.cpp の中で DUTをインスタンスすると、Vtop になります。Verilatorでは、--cc オプションを付けると、top というモジュールから Vtop という Verilated Module という C++モデルを生成します。また、--sc オプションを付けると、VtopというSystemCモデルを生成しました。

Questaでは、DUTのトップ階層名と同じ名前のモジュールを SystemC 側におけるので、Verilator の top.v を下記のように変更します。VERILATORの時は、top のままですが、それ以外の時は、Vtop にします。

`ifdef VERILATOR
module top
`else
module Vtop
`endif
(
    input  logic        clk,
    input  logic        reset,

    /* verilator lint_off UNUSED */
    input  logic [15:0] addr,
    /* verilator lint_on UNUSED */
    input  logic        cs,
    input  logic        rw,
    input  logic [31:0] data_in,
    output logic        ready,
    output logic [31:0] data_out
    );

SystemCラッパーの生成

Questaの場合は、SystemVerilogのコードに対して、scgenmod コマンドを使って、SystemCのラッパーを生成します。

最初にSystemVerilogのコードを vlog コマンドでコンパイルし、そのコンパイルした top から SystemCラッパーを scgenmod コマンドで生成します。scgenmod コマンドの引数、-bool -sc_uint は ポートの信号の型として、スカラー信号は bool を、ベクター信号は sc_unit を使うように指示しています。

vlog -sv top.v
scgenmod -bool -sc_uint Vtop > Vtop.h

top.v (Vtop) から scgenmod コマンドが生成した Vtop.h は、以下のようになっています。logic が bool、logic [X] が sc_uint に変換されています。

#ifndef _SCGENMOD_Vtop_
#define _SCGENMOD_Vtop_

#include "systemc.h"

class Vtop : public sc_foreign_module
{
public:
    sc_in<bool> clk;
    sc_in<bool> reset;
    sc_in<sc_uint<16> > addr;
    sc_in<bool> cs;
    sc_in<bool> rw;
    sc_in<sc_uint<32> > data_in;
    sc_out<bool> ready;
    sc_out<sc_uint<32> > data_out;


    Vtop(sc_module_name nm, const char* hdl_name,
       int num_generics, const char** generic_list)
     : sc_foreign_module(nm),
       clk("clk"),
       reset("reset"),
       addr("addr"),
       cs("cs"),
       rw("rw"),
       data_in("data_in"),
       ready("ready"),
       data_out("data_out")
    {
        elaborate_foreign_module(hdl_name, num_generics, generic_list);
    }
    ~Vtop()
    {}

};

#endif

コンストラクタの中では、elaborate_foreign_module(hdl_name, num_generics, generic_list); を呼び出しています。elaborate_foreign_module 関数には、HDLのインスタンス名、parameterの数とそれに対する値を渡しています。Vtopでは、parameterは無いので num_generics は 0 で generic_list は NULL になります。

SystemC コードの修正

sc_main.cpp は、Questaに対応するために、かなり修正する必要があります。Questa では、sc_main は使えません。その代わりに、下記のようにSystemC のクラス (ここでは、sc_top) として記述する必要があります。

信号の型は、スカラーは bool、ベクターは sc_uint です。bfm クラスの信号の型も同様に変更する必要があります。変更したものを bfm.h にストアします。

sc_main.cpp の Vtop と bfm の接続を sc_top クラスのコンストラクタ内で行います。

#include <memory>
#include <systemc.h>
#include "Vtop.h"
#include "bfm.h"

SC_MODULE(sc_top) {

    sc_clock clk;

    sc_signal<bool>     reset;
    sc_signal<bool>     cs;
    sc_signal<bool>     rw;
    sc_signal<bool>     ready;
#ifdef VERILATOR
    sc_signal<uint32_t> addr;
    sc_signal<uint32_t> data_in;
    sc_signal<uint32_t> data_out;
#else
    sc_signal<sc_uint<16>> addr;
    sc_signal<sc_uint<32>> data_in;
    sc_signal<sc_uint<32>> data_out;
#endif

    Vtop *u_top;
    bfm *u_bfm;

    SC_CTOR(sc_top) :
        clk("clk", 10, SC_NS, 0.5, 5, SC_NS, true),
        reset("reset"), cs("cs"), rw("rw"), addr("addr"), ready("ready"), data_in("data_in"), data_out("data_out") {

#ifdef VERILATOR
        u_top = new Vtop{"top"};
#else
        u_top = new Vtop{"top", "Vtop", 0, NULL};
#endif

        u_top->clk(clk);
        u_top->reset(reset);
        u_top->cs(cs);
        u_top->rw(rw);
        u_top->addr(addr);
        u_top->data_in(data_in);
        u_top->ready(ready);
        u_top->data_out(data_out);

        u_bfm = new bfm("bfm");

        u_bfm->clk(clk);
        u_bfm->reset(reset);
        u_bfm->cs(cs);
        u_bfm->rw(rw);
        u_bfm->addr(addr);
        u_bfm->data_in(data_out);
        u_bfm->ready(ready);
        u_bfm->data_out(data_in);
    }

    ~sc_top() {
#ifdef VERILATOR
        u_top->final();
#endif
        delete u_top;
        delete u_bfm;
    }
};

Vtop クラスのインスタンスを生成するときに、下記のように、HDLのインスタンス名、その後に、0とNULLを指定しています。

        u_top = new Vtop{"top", "Vtop", 0, NULL};

sc_top.cpp は、下記のようになります。SC_MODULE_EXPORT(sc_top); を設定するところがポイントです。

#include "sc_top.h"
#include <iostream>


SC_MODULE_EXPORT(sc_top);

sc_main は下記のようになります。

#include <memory>
#include <systemc.h>

#include "sc_top.h"

int sc_main(int argc, char* argv[]) {

    if (false && argc && argv) {}

    Verilated::debug(0);
    Verilated::randReset(2);
    Verilated::commandArgs(argc, argv);

    ios::sync_with_stdio();

    const std::unique_ptr<sc_top> u_sc_top{new sc_top("sc_top")};

    sc_start();

    cout << "done, time = " << sc_time_stamp() << endl;
    return 0;
}

#ifdef VL_USER_STOP
void vl_stop(const char *filename, int linenum, const char *hier) VL_MT_UNSAFE
{
    sc_stop();
    cout << "call vl_stop" << endl;
}
#endif

SystemC コードのコンパイル & リンク

SystemC コードは、下記のように sccom コマンドでコンパイル & リンクします。最初の sccom コマンドでは、-g オプション(デバッグオプション)にて sc_top.cpp をコンパイルし、オブジェクトファイルを生成し、2番目の sccom コマンドでは、-link オプションにてリンクします。

sccom -g sc_top.cpp
sccom -link

vsim にて、シミュレーション実行

vsim コマンドにて、トップ階層である sc_top にてシミュレーションを実行します。-c オプションは、GUI無し(コマンドライン)にて実行します。-do オプションにて、vsim コマンド内のコマンドとして、"run -all"、シミュレーションをすべて実行します。

vsim -c sc_top -do "run -all"

おわりに

Intel Questaでも、SystemVerilog + SystemC のシミュレーションができることを確認しました。

便利ですね。

VerilatorとSystemC雑談会を開催しました

はじめに

何となく、先週の土曜日に思いついたので、「VerilatorとSystemC雑談会」を昨日(5/2:火曜)に開催しました。

connpass.com

VerilatorとSystemC で Software Driven Verification

最初の1時間で「VerilatorとSystemC で Software Driven Verification」について、お話しました。

後半の1時間で、VerilatorとSystemC、Software Driven Verificationについて、皆さんと雑談しました。

Verilatorの薄い本「Verilatorの中を調べる」No.3、SystemC編

今回、VerilatorとSystemCについて、お話した内容の詳細については、

vengineer.booth.pm

に書いています。

もっといろいろと知りたいなー、と思ったら、是非、ご利用ください。現在の価格は 600 円です。

おわりに

Software Driven Verificationについては、ASIC を Verilog HDL で開発し始めた30年前からやっています。

今回は、オープンソースのSystemVerilogシミュレータのVerilatorとオープンソースのSystemCを使って、Software Driven Verification。

ここで開発したテストプログラムは、実機評価でも再利用ができます(できるようにします)。

そうすることで、

での生産性が一気に上がります。

是非、みなさんも、Software Driven Verification をやってみてください。

FPGAだから、実機で確認すればいいよ。と、思うかもしれませんが、テストしていないところにはバグがあります。 プロダクトとして世の中に出てしまってからは、簡単には直せません。なので、シミュレータを使った徹底したテストが必要なんです。そのためのツールとして、Software Driven Verification が役立つのです。。