WSL + Vivado 2020.2
WSLにVivado2020.2をInstallする手順
まずはドライブに 30G 程度の空きがあるのを確認する。
- ダウンロード
https://japan.xilinx.com/support/download.html から Xilinx_Unified_2020.2_1118_1232_Lin64.bin をダウンロードしてくる。
- binからインストーラを抽出
./Xilinx_Unified_2020.2_1118_1232_Lin64.bin --noexec --target <path_to_dir>
上記コマンドの <dir> には展開するディレクトリのパスを入力する。
- ユーザ名、パスワードの入力
./xsetup -b AuthTokenGen E-mail Address: suima@huga Password:
展開したディレクトリに移動し xsetup からXilinxのアカウントでダウンロードトークンを作成する。
E-mail の入力まで結構時間かかるので、辛抱強く待つ。
- 設定ファイルの作成
./xsetup -b ConfigGen Running in batch mode... Copyright (c) 1986-2021 Xilinx, Inc. All rights reserved. INFO : Log file location - /home/suima/.Xilinx/xinstall/xinstall_1621928573150.log Select a Product from the list: 1. Vitis 2. Vivado 3. On-Premises Install for Cloud Deployments (Linux only) 4. BootGen 5. Lab Edition 6. Hardware Server 7. PetaLinux (Linux only) 8. Documentation Navigator (Standalone) Please choose: 2 Select an Edition from the list: 1. Vivado HL WebPACK 2. Vivado HL Design Edition 3. Vivado HL System Edition Please choose: 1
インストール用の設定ファイルを作成する。
実行すると以下の様な選択項目が表示されるため適宜選択する。
上記では 2.Vivado、1. WebPACK を選択している。
コマンドが完了すると、ホームディレクトリに .Xilinx/install_config.txt が作成される。
- インストール先のディレクトリ作成/権限の変更
sudo groupadd xilinx less /etc/group sudo usermod -aG xilinx suima id suima
グループ権限で実行できるように、 xilinx グループを作成しておく。
sudo mkdir -p /tools/Xilinx/Vivado sudo chgrp xilinx /tools/Xilinx/Vivado sudo chmod 770 /tools/Xilinx/Vivado
上記では、デフォルトのインストール先である /tools/Xilinx/Vivado を作成している。
sudo で作成していると、後の作業で詰まるため、一般ユーザーが実行できるようにしている。
ここでは xilinx グループを作成しているが、個人でしか使わないのであれば、 chown とかで所有権を変更したほうが楽かも。
- インストールの実行
./xsetup --agree XilinxEULA,3rdPartyEULA,WebTalkTerms --batch Install --config <path_to_config>
上記のコマンドでVivado のダウンロートとインストールを開始する。
このコマンドに sudo つけると失敗する。
サブネットマスク，ビットマスクの早見表
サブネットマスク，ビットマスクの早見表
時々、見返す用
| クラス | ビットマスク | サブネットマスク | IPの数 |
|---|---|---|---|
| クラスA | /8 | 255.0.0.0 | 16,777,216 |
| /9 | 255.128.0.0 | 8,388,608 | |
| /10 | 255.192.0.0 | 4,194,304 | |
| /11 | 255.224.0.0 | 2,097,152 | |
| /12 | 255.240.0.0 | 1,048,576 | |
| /13 | 255.248.0.0 | 524,288 | |
| /14 | 255.252.0.0 | 262,144 | |
| /15 | 255.254.0.0 | 131,072 | |
| クラスB | /16 | 255.255.0.0 | 65,536 |
| /17 | 255.255.128.0 | 32,768 | |
| /18 | 255.255.192.0 | 16,384 | |
| /19 | 255.255.224.0 | 8,192 | |
| /20 | 255.255.240.0 | 4,096 | |
| /21 | 255.255.248.0 | 2,048 | |
| /22 | 255.255.252.0 | 1,024 | |
| /23 | 255.255.254.0 | 512 | |
| クラスC | /24 | 255.255.255.0 | 256 |
| /25 | 255.255.255.128 | 128 | |
| /26 | 255.255.255.192 | 64 | |
| /27 | 255.255.255.224 | 32 | |
| /28 | 255.255.255.240 | 16 | |
| /29 | 255.255.255.248 | 8 | |
| /30 | 255.255.255.252 | 4 | |
| /31 | 255.255.255.254 | 2 | |
| /32 | 255.255.255.255 | 1 |
tx2がサスペンドするのを防ぐ
tx2がサスペンドするのを防ぐ
UbuntuのGUI周りから設定を変えてもなぜかサスペンドしてしまった． 結果的に以下のコマンドでサスペンドが防げるようになった．
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
GUI関連から設定できる値も変更。
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0 gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type nothing gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
DJIのmanifold2-Gでも効果があり．
参考
Ethernet Numbers
Ethernet Numbers
LinuxのrawsocketやRTLでパケットフレーム制御等で割と使うのでメモ．
- IANA
- よく見る奴ら抜粋
| types (hex) | Protocol |
|---|---|
| 0000-05DC | IEEE802.3 Length Field (0 - 1500) |
| 0101-01FF | 実験用 |
| 0800 | Internet IP (IPv4) |
| 0806 | Address Resolution Protocol (ARP) |
| 8035 | Reverse Address Resolution Protocol (RARP) |
| 805B | VMTP (Versatile Message Transaction Protocol) |
| 809B | AppleTalk (EtherTalk) |
| 80F3 | AppleTalk Address Resolution Porotocol (AARP) |
| 8137 | IPX (Novell Netware) |
| 814C | SNMP over Ethernet |
| 8191 | NetBIOS/NetBEUI |
| 817D | XTP |
| 86DD | IP version 6 (IPv6) |
| 8863 | PPPoE Discovery Stage |
| 8864 | PPPoE Session Stage |
| 9000 | Loopback (Configuration Test Protocol) |
標準出力からsudoへパスワードを渡す
-S オプションを付ける
echo 'hoge' | sudo -S fuga
使い道？
大学のころ、パスワードの管理をハッシュで行っていた。
その時に使っていた sudo の入力
echo -n 'hoge' | md5sum | awk '{ print $1 }' | sudo -S fuga
ハッシュからパスワードを作成する方法は簡単な単語から複雑な文字列を生成できるのでなかなか便利。
HOTSWAP: 活線挿抜 でやらかした話
JTAGは活線挿抜に非対応
なので電源を切ってから挿抜しましょう、という話。 認識しないときに気軽に抜き差ししてした結果、FPGAが逝ってしまわれた。 深く反省したい。
活線挿抜とは
活線挿抜(かっせんそうばつ)とは電源を入れたまま抜き差しすることである。 HOT SWAP とも呼ばれる。 基本的に、活線挿抜は非対応だと考えて行動するのが良い。 活線挿抜に対応するためには、そのための回路/物理的機構を設定する必要がある。
活線挿抜に対応したコネクタ
活線挿抜に対応しているUSB、SDカードの端子をよく見ると、長さの異なるピンがあることに気づく。 これは、物理的にGND/電源が信号線よりも先に接触するように設計されている。 この設計のことを シーケンシャル 嵌合 と呼ぶらしい。
pip + sys.stderr.write(f“ERROR: {exc}”)
やんごとなき事情で、古臭いPythonを使っていたら pip が使えなくなってしまった。 python 3.5、2.x を使っていたのだが、どちらも sys.stderr.write(f“ERROR: {exc}”) とエラーが出てしまう。 どうやら 3.6以下は 今後pipのサポートから外れるとのこと。
最新バージョンを追えれば問題ないのですが、 仕方ないこともある。
このエラーが出ると python -m pip hoge が使えなくなるので、pip を使ってpip のバージョンを管理できなくなってしまう。
get-pip.py で特定のバージョンをインストール
にアクセスして，お目当ての pip を探そう．
適当なバージョンの get-pip.py を読めば，どのバージョンがダウンロードできるかわかる．
python 2.x の場合
pip (version 20.3.4) をインスコ
virtualenv --python=python2 .venv/ cd .venv source bin/activate curl https://bootstrap.pypa.io/2.7/get-pip.py --output get-pip.py python get-pip.py pip install hoge
python 3.x の場合
pip (version 7.1.2). をインスコ
virtualenv --python=python3 .venv/ cd .venv source bin/activate curl https://bootstrap.pypa.io/3.2/get-pip.py --output get-pip.py python get-pip.py pip install hoge
余談
get-pip.py を読めばわかるが，DATA = b""" ... の箇所はzipで固めたpipがそのまま張り付けられてる．
安定動作している自環境のpipをzip圧縮し， hexdump でダンプすれば，似たようなことが合出来る．
Periodic OCT Recalibration(Arria10 + DDR4)
Arria10 + DDR4@1200MHzで使った際のメモ
参考資料
- External Memory Interfaces Intel® Arria® 10 FPGA IP User Guide (19.3, 2020.12.18)
- p32, 3.4. Periodic OCT Recalibration
- https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/archives/ug-20115-19-3-19-1-0.pdf
Periodic OCT Recalibration 機能が有効になっていることが推奨されている
- 推奨となっているが 必須 らしい
- EMIF Spec Estimator で表示される Fmax の Notes
- IP生成時のメッセージにこのメッセージ
- で確認する
- 推奨となっているが 必須 らしい
無効になってると以下のようなメッセージが出る。INFOで出るだけなので注意。
./sys/ip/system/system_emif/system_emif_generation.rpt:Info: system_emif.system_emif.arch: Periodic OCT re-calibration is disabled because the interface uses calibrated IO standards for either Address, Command or Clock signals. ./sys/ip/system/system_emif/system_emif_generation.rpt:Info: system_emif.system_emif.arch: The interface will have reduced Read Capture timing margin due to Periodic OCT re-calibration being disabled. ./sys/ip/system/system_emif/system_emif_generation_previous.rpt:Info: system_emif.system_emif.arch: Periodic OCT re-calibration is disabled because the interface uses calibrated IO standards for either Address, Command or Clock signals. ./sys/ip/system/system_emif/system_emif_generation_previous.rpt:Info: system_emif.system_emif.arch: The interface will have reduced Read Capture timing margin due to Periodic OCT re-calibration being disabled.
Periodic OCT Recalibration
- 有効になっていると、500ms毎にアクセス停止になる期間が発生する。
- アクセス停止の時間は、設定によって異なる
WindowsでDHCPからIPを再取得する
コマンドプロンプトで以下を実行する。
ipconfig /renew
パケットロスト、キュー/フレーム損失の改善
フレームがドロップしてるかを調べる
<devname> 内でいくつのフレームがドロップされたか調べる。
とりあえず ifconfig の dropped で調べられる。
<devname>: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.0.130 netmask 255.255.0.0 broadcast 10.10.255.255
inet6 fe80::2d8:61ff:fe6f:5a95 prefixlen 64 scopeid 0x20<link>
ether 00:d8:61:6f:5a:95 txqueuelen 1000 (Ethernet)
RX packets 157561 bytes 20855430 (19.8 MiB)
RX errors 0 dropped 16450 overruns 0 frame 0
TX packets 118302 bytes 55624032 (53.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16
ethtool で詳細を調べる。
$ ethtool -S <devname>
NIC statistics:
rx_packets: 165081
rx_bcast_packets: 33476
rx_mcast_packets: 15379
rx_pause_packets: 0
rx_ctrl_packets: 24
rx_fcs_errors: 0
rx_length_errors: 0
rx_bytes: 21501848
rx_runt_packets: 0
rx_fragments: 0
rx_64B_or_less_packets: 62795
rx_65B_to_127B_packets: 93092
rx_128B_to_255B_packets: 16385
rx_256B_to_511B_packets: 6979
rx_512B_to_1023B_packets: 776
rx_1024B_to_1518B_packets: 5270
rx_1519B_to_mtu_packets: 0
rx_oversize_packets: 0
rx_rxf_ov_drop_packets: 0
rx_rrd_ov_drop_packets: 0
rx_align_errors: 0
rx_bcast_bytes: 2632366
rx_mcast_bytes: 1912872
rx_address_errors: 20324
tx_packets: 123396
tx_bcast_packets: 431
tx_mcast_packets: 26
tx_pause_packets: 0
tx_exc_defer_packets: 0
tx_ctrl_packets: 0
tx_defer_packets: 0
tx_bytes: 57629090
tx_64B_or_less_packets: 7608
tx_65B_to_127B_packets: 52101
tx_128B_to_255B_packets: 20852
tx_256B_to_511B_packets: 5505
tx_512B_to_1023B_packets: 7292
tx_1024B_to_1518B_packets: 30038
tx_1519B_to_mtu_packets: 0
tx_single_collision: 0
tx_multiple_collisions: 0
tx_late_collision: 0
tx_abort_collision: 0
tx_underrun: 0
tx_trd_eop: 0
tx_length_errors: 0
tx_trunc_packets: 0
tx_bcast_bytes: 43980
tx_mcast_bytes: 3866
tx_update: 0
ドライバでキューを長くする
ドライバーが許可する最高値まで指定のキューでバッファー数を増やせる。 メモリに余裕があるなら取り合経ず増やして損はない、と思う。
$ ethtool -g <devname> Ring parameters for eth0: Pre-set maximums: RX: 1020 <-- ここまで上げられる RX Mini: 0 RX Jumbo: 4080 TX: 255 Current hardware settings: RX: 255 <-- 現在値 RX Mini: 0 RX Jumbo: 0 TX: 255
増やす。
$ ethtool -G <devname> rx 512
ただ、NICによって、リングバッファが変更できないこともある。
$ ethtool -g <devname> Cannot get device ring settings: Operation not supported
カーネルのキューを長くする
リングバッファが増やせなかった場合 netdev_max_backlog を増やすことで対応できる。
ネットワークデバイス別にカーネルが処理できるように貯めておく queue サイズを大きくできる。
メモリの使用量が増えるだけなので、適当に大きくしても問題ない、はず。
$ sysctl -w net.core.netdev_max_backlog="30000"
キューの排出率を高める
NAPIの1回のソフトウェア割り込みでポーリングする上限パケット数を設定する。 大量の受信トラフィックでポーリング処理が追い付かずNICにパケットのドロップが発生する状況では値を増加させると症状が改善する場合がある。
$ cat /proc/sys/net/core/dev_weight 64
増やす。
$ sysctl -w net.core.dev_weight=128 net.core.dev_weight = 128
一回のソフトウェア割り込みでポーリングする回数が増えるので、その間CPUはスケジューリングが出来なくなる。 なので、あまり大きくしないこと。
capability で権限を与える
rawsocket を使ったアプリを作成した際に、動作に sudo を使っていた。
ナンセンスなので capability を使う。
rawsocket の capability
sudo setcap cap_net_raw=ep ./hoge
p : permitted- スレッドの継承可能ケーパビリティに関わらず、そのスレッドに自動的に 認められるケーパビリティ
e : effective- このビットがセットされていると、 execve(2) 実行中に、そのスレッドの新しい許可ケーパビリティが全て 実効ケーパビリティ集合においてもセットされる。 このビットがセットされていない場合、 execve(2) 後には新しい許可ケーパビリティのどれも新しい実効ケーパビリティ集合 にセットされない。
i : inheritable- このセットと、スレッドの継承可能ケーパビリティセットとの 論理積 (AND) がとられ、 execve(2) の後にそのスレッドの許可ケーパビリティセットで有効となる 継承可能ケーパビリティが決定される
exec で呼んだ子プロセスに capability を継承させるのには ambient capabilities を使う。
inheritable で継承されるには条件があるっぽい、が良く調べていない。
setcap で制御しているのはプロセスでなく、スレッド単位で渡しているので、子スレッドに権限を渡したい場合に inheritable をセットする。
getcap で調べる
正しく権限が与えられたか確認する。
$ getcap ./hoge hoge = cap_net_raw+ep
capability を削除する
setcap -r ./hoge
