実践的！FPGA開発セミナー vol.13（2022/08/31）

実践的！FPGA開発セミナー vol.13 2022/08/31 18:00～ Copyright© Fixstars Group

論理検証の効率化＆ 自動化テクニック ～テストベンチ作成からCIまで ラクできる検証環境を創る～ Copyright© Fixstars Group

Who I am Hiroki NISHIMOTO 写真 西本 宏樹 ソリューション第四事業部 エンジニア Copyright© Fixstars Group

突然ですが、こんな経験ありませんか？ シミュレーションの波形見る感じ 動きそうだし、 合成回してみよう...... 6時間後...... → 動かない Copyright© Fixstars Group 4

突然ですが、こんな経験ありませんか？ ちょっと修正した回路、 簡単な変更しかしてないし、 シミュレーションはいらないかな...... 6時間後...... → 動かない Copyright© Fixstars Group 5

丁寧な論理検証は転ばぬ先の杖、しかし手間が...... 『少しの手間を省かなければ避けられていたいたな...』 みたいなこと、誰しもあると思います。 - 期待値検証のため、 Cで書いたアプリケーションをSystemVerilogに書き直すの手間 - 立ち上がりに1,2分掛かるGUIを起動してチェックするのが億劫 - ちょっとした修正の度に毎回検証する待ち時間がもどかしい こういった絶妙な手間は、どうしても億劫になり、 『多分動く......！（合成ボタンを押す）』の誘惑についつい乗ってしまいます Copyright© Fixstars Group 6

色々使って出来るだけストレスなく検証しよう SystemVerilogでのテストベンチ作成が面倒 → DPI-Cを使って、豊富なC/C++のライブラリを直接使おう GUIの起動を待つのが億劫 → CUI＆バッチ化で繰り返しのストレスなく論理検証をしよう ちょっと修正する度にテストするのが...... → 典型化したテストをCIに投げよう Copyright© Fixstars Group 7

今回の検証対象モジュール AXI-Lite グレースケール化係数 coef_r, coef_g, coef_b AXI-Stream ABA27AFFAA… AXI-Stream グレースケールモジュール Output[i] = Input[i].r × coef_r + Input[i].g × coef_g + Input[i].b × coef_b 2ABABC… Copyright© Fixstars Group 8

具体的な論理検証のシナリオ 1. 2. 3. 4. 5. 6. 7. テストパラメータを設定 入力値・期待値を生成する AXI-Liteで係数を書き込む tvalidやtreadyの入力開始 入力値を検証対象モジュールへ送信する 検証対象モジュールからの出力値の受信する 期待値を用いた出力値の検証 Copyright© Fixstars Group 9

具体的な論理検証のシナリオ 1. 2. 3. 4. 5. 6. 7. テストパラメータを設定 入力値・期待値を生成する AXI-Liteで係数を書き込む tvalidやtreadyの入力開始 入力値を検証対象モジュールへ送信する 検証対象モジュールからの出力値の受信する 期待値を用いた出力値の検証 グレースケール化係数 coef_r, coef_g, coef_b 入力画像 tvalid, treadyは - 遷移タイミングはランダム - Highとなる頻度をパラメータとして与える ex1) tvalid 50%, tready 50% Copyright© Fixstars Group ex2) tvalid 20%, tready 80% 10

具体的な論理検証のシナリオ 1. 2. 3. 4. 5. 6. 7. テストパラメータを設定 入力値・期待値を生成する AXI-Liteで係数を書き込む tvalidやtreadyの入力 入力値を検証対象モジュールへ送信する 検証対象モジュールからの出力値の受信する 期待値を用いた出力値の検証 Output[i] = Input[i].r × coef_r + Input[i].g × coef_g + Input[i].b × coef_b Copyright© Fixstars Group 11

具体的な論理検証のシナリオ 1. 2. 3. 4. 5. 6. 7. テストパラメータを設定 入力値・期待値を生成する AXI-Liteで係数を書き込む tvalidやtreadyの入力開始 入力値を検証対象モジュールへ送信する 検証対象モジュールからの出力値の受信する 期待値を用いた出力値の検証 グレースケール化係数 coef_r, coef_g, coef_b グレースケールモジュール Output[i] = Input[i].r × coef_r + Input[i].g × coef_g + Input[i].b × coef_b Copyright© Fixstars Group 12

具体的な論理検証のシナリオ 1. 2. 3. 4. 5. 6. 7. テストパラメータを設定 入力値・期待値を生成する AXI-Liteで係数を書き込む tvalidやtreadyの入力開始 入力値を検証対象モジュールへ送信する 検証対象モジュールからの出力値の受信する 期待値を用いた出力値の検証 期待値 出力画像 FAILED Copyright© Fixstars Group OK 13

色々使って出来るだけストレスなく検証しよう SystemVerilogで期待値作成が面倒 → DPI-Cを使って、豊富なCのライブラリを直接使おう GUIの起動を待つのが億劫 → CUI＆バッチ化で繰り返しのストレスなく論理検証をしよう ちょっと修正する度にテストするのが...... → 典型化したテストをCIに投げよう Copyright© Fixstars Group 14

DPI-Cとは？
Direct Programming Interface : DPI
用いることで他言語とSystemVerilogを接続できる
SystemVerilog
export "DPI-C" task run_stream;

C/C++
C/C++で呼び出すための関数を
生成するための宣言
run_stream();

task automatic run_stream;

SystemVerilogのtaskの実装部分

…

C/C++での
呼び出し

endtask : run_stream

import "DPI-C" context task

int c_main(

c_main(input string testcase, output int ret);

const char* testcase_file,
int* ret){

C/C++関数をSystemVerilog で呼び出すための宣言

…
c_main(testcase_file, ret);

}

SystemVerilogでの呼び出し

C/C++の関数の実装部分
Copyright© Fixstars Group

15

設定値読み込みはC++のライブラリを用いて楽に 1. テストパラメータを設定 <テストケース名>.cfg DPI-C C/C++ライブラリ 呼び出し ファイル 読み込み ・解析 テストベンチ (SystemVerilog) <テストケース名> <テストパラメータ> GenImage.width = 256 GenImage.height = 256 … width = 256 height = 256 … DPI-C パラメータ 設定タスク呼び出し Copyright© Fixstars Group テストパラメータ設定 16

期待値はライブラリで計算したものをそのまま持ってくる
2. 入力値・期待値を生成する

ファイル
読み込み・解析
(png, bmp, etc.)

DPI-C
C/C++ライブラリ呼び出し

グレー
スケール化

DPI-C テストデータ
設定タスク呼び出し

テストベンチ
(SystemVerilog)

<入力値テストデータ>
ABA27AFFAA…

cv::Mat img_in;

<期待値テストデータ>
cv::Mat img_out;
Copyright© Fixstars Group

2ABABC…
17

直接の検証モジュールとやり取りするところは SystemVerilogで 1. 2. テストパラメータを設定 期待値を生成する 3. AXI-Liteで係数を書き込む 4. tvalidやtreadyの入力開始 5. 入力値を検証対象モジュールへ送信する 呼出 C++ (DPI-C) - テストパラメータ読み込み 入力画像読み込み テスト用期待値の作成 テストドライバ (SystemVerilog) - CLK, RSTの生成 FIFOを用いたデータの送受信 それらをCLK同期且つ非同期で実行 結果と期待値を用いた検証 CLK RST 検証回路 (Verilog) 送信部 受信部 coef.r = 0.299 coef.g = 0.587 ceef.b = 0.144 GenImage.width = 256 GenImage.height = 256 … SimImage.out_file = act_gray.pgm Copyright© Fixstars Group 18

直接の検証モジュールとやり取りするところは SystemVerilogで 1. 2. 3. 4. 5. テストパラメータを設定 期待値を生成する AXI-Liteで係数を書き込む tvalidやtreadyの入力開始 入力値を検証対象モジュールへ送信する 6. 検証対象モジュールからの出力値の受信する 7. 期待値を用いた出力値の検証 C++ - テストパラメータ読み込み テスト用期待値の作成 テストドライバ (SystemVerilog) 期待値 - CLK, RSTの生成 FIFOを用いたデータの送受信 それらをCLK同期且つ非同期で実行 結果と期待値を用いた検証 CLK RST 結果 検証回路 (Verilog) 送信部 受信部 OK or Copyright© Fixstars Group FAILED 19

次はテストの効率化へ SystemVerilogで期待値作成が面倒 → DPI-Cを使って、豊富なCのライブラリを直接使おう GUIの起動を待つのが億劫 → CUI＆バッチ化で繰り返しのストレスなく論理検証を走らせよう ちょっと修正する度にテストするのが...... → 典型化したテストをCIに投げよう Copyright© Fixstars Group 20

CUI（バッチ処理）で論理検証しよう モジュール少し修正したし、 論理検証回したいな... 長い...... GUI起動...... こういった微妙なストレスは CUIベースでテスト環境を構築して置くことで、解決することができます VIVADO is a trademark of Xilinx, Inc. Copyright© Fixstars Group 21

論理検証全体の流れ 1. 2. 3. 4. RTL・Simulation Sourceのコンパイル DPI-C用のコンパイル テストベンチのelaborate シミュレーションの実行 今回はこれら全てをCUIコマンド一発でビルド・実行できるようにします Xilinx環境用シミュレータ Vivado Simulator v2021.2 Intel環境用シミュレータ Questa Intel Starter FPGA Edition-64 vsim 2022.1 Simulator 2022.01 Jan 29 2022 OS CentOS Linux release 7.9.2009 (Core) QUESTA is a trademark of QUESTA CORPORATION. Copyright© Fixstars Group 22

CUIコマンドはGUIから持ってこよう GUIで実行するとTcl Consoleに 対応するCUIコマンドが表示されている Vivadoの場合、vivado.jouというファイルに 同様の内容が出力されている。 これらのTclコマンドを参考にバッチ処理コマンドを作成していく Copyright© Fixstars Group

Vivado simulator 実行コマンドフロー xvlog … テストベンチとRTLファイルをコンパイル xvlog -work work --sourcelibdir . -sv [rtlファイル] … xelab –dpiheader [DPIヘッダファイル名 ] … DPIヘッダファイルの出力 xelab --timescale 1ns/1ps -sv -dpiheader \ sv_export.h tb_gray_scale -L [ベンダモジュール] g++ -o [.soファイル] … DPI共有ライブラリを生成 g++ -c -g -std=c++11 -Wall -fPIC -I[インクルードパス] c_main.cpp g++ c_main.o -o dpi.so -L[ライブラリパス] -L… -l[ライブラリ] xelab -sv_lib [共有ライブラリ名 ] … DPI共有ライブラリを含めてelaboration xelab --debug typical --timescale 1ns/1ps --snapshot \ work.tb_gray_scale tb_gray_scale -L [ライブラリパス] \ -sv_lib dpi xsim … シミュレーションの実行 xsim work.tb_gray_scale -onfinish quit -runall \ -testplusarg TESTCASE=[テストケース名] \ -testplusarg TESTCASE_FILE=[テストパラメータ設定ファイル] Copyright© Fixstars Group

Questa simulator 実行コマンドフロー vlog … テストベンチとRTLファイルをコンパイル vlog -work work +incdir+[参照先] -sv [rtlファイル].v [テストベンチ].sv vlog -sv -dpiheader sv_export.h … DPIヘッダファイルの出力 g++ -o [.soファイル] … DPI共有ライブラリを生成 vsim … シミュレーションの実行（実行時、elaborationも行われる） vlog -sv -dpiheader sv_export.h ../tb_gray_scale.sv g++ -c -g -std=c++11 -Wall -fPIC -I[include先] ../c_main.cpp g++ c_main.o -o dpi.so -L[ライブラリ参照先] -L… -l[ライブラリ] -l… vsim work.tb_gray_scale -c -do "run -all; quit" \ -L [モジュールパス] -L ... -sv_lib dpi \ +TESTCASE=[テストケース名] \ +TESTCASE_FILE=[テストパラメータ設定ファイル] Copyright© Fixstars Group

CUI化 ≒ 手続きをファイルにまとめておく xvlog -work ... 手続きを順に記述し、 実行可能な形でまとめておく xelab -dpiheader [DPIヘッダファイル名] g++ -o [.soファイル] コマンド xelab -sv_lib [共有ライブラリ名] コマンド xsim コマンド：シミュレーション実行 ex) make, shell script, Python - Makefile中に、ターゲットと実行されるコマンドの対応、 コマンド実行に必要となる依存ファイルの関係を記載する ① ② ③ ④ ⑤ make [target]で用意しておいたコマンドが実行される make make make make make comp ... コンパイル dpi_c ... ① + ヘッダファイル生成 & DPI-Cライブラリコンパイル elab ... ① + ② + elabration <TESTCASE名> ... ③ + テストケースの シミュレーション実行 all ... ④の全テストケースを順次シミュレーション実行 Copyright© Fixstars Group ※ファイル更新をチェックするので、 例えば④シミュレーション実行をすると、 ①～③の実行要否を判断して、 必要に応じて再コンパイルをする。

最後に、CI化やってみました SystemVerilogで期待値作成が面倒 → DPI-Cを使って、豊富なCのライブラリを直接使おう GUIの起動を待つのが億劫 → CUI＆バッチ化で繰り返しのストレスなく論理検証を走らせよう ちょっと修正する度にテストするのが...... → 典型化したテストをCIに投げよう Copyright© Fixstars Group 27

細かくテストを行うことで原因特定は容易になる 修正ごとにテストを行うことで、どの修正がエラーの原因になったかが分かる。 修正 テスト OK 修正 テスト OK Copyright© Fixstars Group 修正 テスト 28

CIについて CI : Continuous Integration（継続的インテグレーション） CloneからBuild, Testの手順を確立しておけば、自動でやってくれる テスト 修正 1. 2. 3. 4. リポジトリのクローン 検証対象のビルド テストの実行 成功 or 失敗判定 GITLAB is a trademark of GitLab Inc. in the United States and other countries and regions Copyright© Fixstars Group 29

こういうことがしたい テストをCIにやらせておき、自分は修正を進める テスト OK 修正 修正 テスト OK 修正 テスト FAILED 修正 Copyright© Fixstars Group 30

GitLab-Runnerの利用 CI/CDは基本的にクラウドのサーバ等で行う。 ベンダツールのインストール時間やライセンスは......？ → ローカルでGitLab-CIのテスト環境を実現するGitLab-Runnerの導入で解決 やれ はい... ベンダツールがインストールしたサーバで CIテストが実行できる 社内サーバ Copyright© Fixstars Group 31

5分くらいでできるGitLab-Runner導入 curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64" chmod +x /usr/local/bin/gitlab-runner useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner gitlab-runner start 実行ファイルのダウンロード・権限付与, Runner用アカウントの追加, インストール・実行 gitlab-runner register 項目 入力内容 GitLab instance URL CIの説明ページに書いてある URL 〃 registration token トークン description for the runner 任意 tags for the runner 任意 Executer 色々ある。今回は shellに設定 Copyright© Fixstars Group 追加されたGitLab Runner 32

• https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

させたいことを.gitlab-ci.ymlに書く CIはリポジトリ内の.gitlab-ci.ymlに書かれた内容を元に テストのPipelineを作成し、順にテストを実行する stage … Pipelineのstage。前のstageが止まると以降は実行されない job … stage内で実際に実行される命令群。並列にも逐次にも設定可能 例） Build1 Build2 Test Test Case 1 Test Case 2 Test Case 3 Copyright© Fixstars Group 並列に実行

CIでさせたいこと 1. xilinx_ipディレクトリでmakeを実行し、 Xilinxのipのシミュレーションファイルを作成 2. hw_proj/simディレクトリでmake comp elab dpi_cを実行し、 シミュレーション実行ファイルを作成 3. 同ディレクトリでmake simを実行 これらをそれぞれstagesとして.gitlab-ci.ymlに記述した Copyright© Fixstars Group

.gitlab-ci.ymlの記述 ステージの設定 stages: - build_xilinx_ip - build_hw - test 3つのstageを定義 ジョブの設定 build_xilinx_ip-job: stage: build_xilinx_ip stageにjobが属するstageを設定 variables: GIT_STRATEGY: clone before_script: ko - source /home/hiroki.nishimoto/share/.bashrc script: - cd xilinx_ip/ && make Copyright© Fixstars Group before_script, scriptに 実際にjobでさせたいでことを書く 35

.gitlab-ci.ymlの記述 GIT_STRATEGYについて build_xilinx_ip-job: build_hw-job: stage: build_xilinx_ip stage: build_hw variables: variables: GIT_STRATEGY: clone GIT_STRATEGY: none before_script: before_script: - source /home/hiroki.nishimoto/share/.bashrc script: - source /home/hiroki.nishimoto/share/.bashrc script: - cd xilinx_ip/ && make - ls - ls xilinx_ip - cd gray_scale/sim && make comp elab dpi_c リポジトリに対して最初に行う処理。 前のstageでbuildした実行ファイルを使いたい場合noneにしていないと初期化されるので注意。 Copyright© Fixstars Group 36

実際に動かして見る どのコミットでテストが失敗したかが分かる Copyright© Fixstars Group どのstageで失敗したかが分かる

まとめ - DPI-Cを使って、豊富なCのライブラリを直接使おう SystemVerilogで書くには煩雑な処理も OpenCV等のC/C++の豊富なライブラリでらくらく実装 - CUI＆バッチ化で繰り返しのストレスなく論理検証をしよう GUIで行っていた処理をCUIコマンドでまとめることで、 GUIを立ち上げることなくコマンド一発で論理検証が可能に また、GUIを使用しないことでテストのCI化も容易に - 典型化したテストをCIに投げよう ちょっとした修正もcommit & pushしておけば、 CIが代わりにテストしてくれるように 尚、ライセンスの問題はGitLab-Runnerで解決（5分程度で導入可能） Copyright© Fixstars Group 38

AI Engine の使い方と シミュレーション 方法の解説 Copyright© Fixstars Group

Who I am Yuki MATSUDA 写真 松田 裕貴 ソリューション第四事業部 リードエンジニア Copyright© Fixstars Group

本日のセミナーの内容 ● 前回のセミナーで AI Engine のアーキテクチャとプログラミング方法につい て概説したので、その続き ○ ● https://speakerdeck.com/fixstars/shi-jian-de-fpgakai-fa-semina-vol-dot-7?slide=2 プログラミング方法についてもう少し掘り下げ & 論理シミュレーションを通して AI Engine がどのように動くかについてを解説します Copyright© Fixstars Group

• https://speakerdeck.com/fixstars/shi-jian-de-fpgakai-fa-semina-vol-dot-7?slide=2

AI Engine とは ● Versal FPGA に追加された Intelligent Engines ● 従来の FPGA + 計算に特化したエンジン (AI Engine) というアーキテクチャ https://github.com/Xilinx/Vitis-Tutorials/tree/2022.1/AI_Engine_Development/Design_Tutorials/02-super_sampling_rate_fir Copyright© Fixstars Group

• https://github.com/Xilinx/Vitis-Tutorials/tree/2022.1/AI_Engine_Development/Design_Tutorials/02-super_sampling_rate_fir

AI Engine 開発環境の準備 ● ライセンスセンターから AI Engine Tools License をダウンロードする ○ ● https://japan.xilinx.com/getlicense ダウンロードしたライセンスを XILINXD_LICENSE_FILE 環境変数に 設定すれば準備完了 ○ シミュレーションまではこのライセンスで可能となる Copyright© Fixstars Group

• https://japan.xilinx.com/getlicense

AI Engine のプログラミングモデル ● AI Engine は、複数のコアの上で 異なる命令列を実行することができる MIMD architecture ● AI Engine のプログラミングモデルでは、 kernel, graph という抽象化を行って C++ でプログラミングを行う ○ kernel : 1つのコア上で動く処理ブロック ○ graph : 複数の kernel を組み合わせて構成するグラフ Copyright© Fixstars Group

AI Engine のプログラミングモデル (cont.) ● このセミナーでは、 vector multiplication + addition をサンプルに プログラミングモデルについて説明する ○ multiplication, addition はそれぞれ別のカーネルで処理する out[i] = a[i] * b[i] + c[i]; ● 公式の資料だと以下のものが参考になる ○ https://github.com/Xilinx/Vitis-Tutorials/tree/2022.1/AI_Engine_Development ○ https://docs.xilinx.com/r/ja-JP/ug1076-ai-engine-environment Copyright© Fixstars Group

• https://github.com/Xilinx/Vitis-Tutorials/tree/2022.1/AI_Engine_Development
• https://docs.xilinx.com/r/ja-JP/ug1076-ai-engine-environment

kernel の作成 ● kernel には 1 つの AI Engine 上で動かすロジックを記載する ● kernel のインターフェースは選択肢があるので、適切なものを使用する ○ window型: 高帯域なローカルメモリ (青線) ■ ○ ○ 容量に制限あり (32KiB / tile) stream型: 低帯域なストリーム (黒線) ■ 隣接してないコアとやり取り可能 ■ multicast などが可能 cascade型: 高帯域なストリーム (緑線) ■ accumulator を 直接渡せるので速い https://docs.xilinx.com/r/en-US/am009-versal-ai-engine/AI-Engine-Tile-Architecture Copyright© Fixstars Group

• https://docs.xilinx.com/r/en-US/am009-versal-ai-engine/AI-Engine-Tile-Architecture

kernel の作成: vecadd ● vecadd kernel のコード例 (window interface) ○ window interface だと容量の限界があるので、要素数N だけ処理する ○ window API だとランダムアクセス可能なため、普通の C++ コードのように書ける kernel.cpp Copyright© Fixstars Group

graph の作成 ● 複数のカーネルを組み合わせてグラフを構成する ● top のグラフには外部への IF が含まれるので、 PL と接続するのか (PLIO), DDR と接続するのか (GMIO) を選ぶ Copyright© Fixstars Group

graph の作成 ● graph には kernel 定義, kernel と入出力の接続を書く graph.hpp Copyright© Fixstars Group

テストコードの作成 ● グラフを定義し、main 関数内にテストロジックを記載する test.cpp Copyright© Fixstars Group

コンパイル ● ● aiecompiler でテストコードをコンパイルする ○ kernel のビルド、グラフで記載された形式でのデバイスへのマッピングが行われる ○ libadf.a という実際のデバイスで使用可能なライブラリが出力される ○ $ aiecompiler test.cpp vitis_analyzer によりシミュレーションポートを確認できる ○ $ vitis_analyzer *.aiecompile_summary Copyright© Fixstars Group

コンパイラレポートの確認 ● コンパイラレポートにはグラフの形状や AI Engine のどの領域に 物理的にマッピングされたかが記載される ● window interface を使う場合はデフォルトでダブルバッファリングされる Copyright© Fixstars Group

aiesimulator によるシミュレーションの実行 ● aiesimulator コマンドでサイクルアキュレートなシミュレーションを行う ○ ● $ aiesimulator –profile –dump-vcd=wave ■ -profile: CPU プロファイリングの有効化 ■ -dump-vcd: シミュレーション波形の出力 vitis_analyzer によりコンパイルレポートを確認できる ○ $ vitis_analyzer *.aierun_summary Copyright© Fixstars Group

シミュレーション結果の確認 : タイムライン ● vecmul/add を 4 回実行したときのタイムライン a. AIE のカーネルは、 window buffer にデータが埋まってから動き始める (window IF の場合) b. 今回のように複数のカーネルを使う場合だと、パイプライン上に動いていく c. バッファがダブルバッファであるため、前後のカーネルは同時に動くことができる Copyright© Fixstars Group

シミュレーション結果の確認 : タイムライン ● vecmul/add を 4 回実行したときのタイムライン a. AIE のカーネルは、 window buffer にデータが埋まってから動き始める (window IF の場合) b. 今回のように複数のカーネルを使う場合だと、パイプライン上に動いていく c. バッファがダブルバッファであるため、前後のカーネルは同時に動くことができる Copyright© Fixstars Group

シミュレーション結果の確認: プロファイル結果 ● プロファイル結果には、CPU 上の命令毎の実行数が出力される ○ ● 下図は vecadd kernel における加算ループの部分 この例だと 1 回の加算に 22 cycle 使っているので非常に遅い ○ 前回のセミナーで話したように、SIMD 命令を使うとこのあたりは高速化可能 Copyright© Fixstars Group

• https://speakerdeck.com/fixstars/shi-jian-de-fpgakai-fa-semina-vol-dot-7?slide=2

まとめ ● 前回のセミナーに引き続き、AI Engine における プログラミング方法・シミュレーション方法について解説した ● AI Engine は新しいアーキテクチャで動作するため、 シミュレーションを通して動作を理解するのが大事 ○ aiesimulator が優秀なため、シミュレーション結果から分かることは多い印象 Copyright© Fixstars Group

Thank you! お問い合わせ窓口 : [email protected] Copyright © Fixstars Group