« 2022年10月 | トップページ | 2022年12月 »

2022.11.30

インターネプコンに出展します

出ようか出まいか悩んでいましたが、インターネプコンに出展することを決意しました。

Nepukon2

 

会期:2023年1月25日(水)~1月27日(金) 10:00~17:00

会場:東京ビッグサイト

勇気を出して契約書を送りました。

Nepukon

出展内容はもちろん、「FPGAに特化した半導体真贋判定装置と検査サービス」です。

エレクトロテストのゾーンに残っていた、最後の一小間をいただきました。出展料はかなり高い💰ので、一瞬たりとも無駄にはできません。

人生の賭けに出ます。

| | コメント (0)

2022.11.29

試算表を作ってみる

今日はバイトがない日なので、自社の仕事を片付けていました。

まず、展示会に向けてデモ機を作りたいので、ICソケットとか発注したり、銀行に振り込みに行ったり、それから信金から言われていた試算表を作ったりしていました。

数か月分の銀行データを弥生会計に取り込んで、売掛金や買掛金の見逃しがないかどうかを念入りにチェックします。

 

今年は全然基板が作れないのでボロボロかと思ったのですが、試算表を見ると、去年と比べて微減くらい。

それほど悪くないのかなと思ったのですが、去年が危機的にボロボロなので、去年と同じということは相当にヤバいということなのです。

半導体不足で自社製品は作れないし輸入のボードも入ってきません。

もうFPGAボードという商売は辞め時にきているのかもしれません。

| | コメント (0)

2022.11.28

TrenzElectronic社のTE0802用に自分でLinuxをビルド成功

TrenzElectronic社のTE0802用に自分でLinuxをビルドしていたのですが、はじめて、FSBLからU-Bootからデバイスツリーから全部作ってLinuxを動作させることに成功しました。

Petalinuxは一切使用していません。

Myte0802linux

要点はいくつかあるのですが、

  • Ubuntuのバイナリは、armhf用(つまり32bit)でも64bitのARMは動く
  • Linuxカーネルはもちろんコンパイルしなおす

カーネルをコンパイルするコマンドは、

make ARCH=arm64 UIMAGE_LOADADDR=0x8000

です。

uImageを作るコマンドは

mkimage -n 'TE0802hoge' -A arm64 -O linux -C none -T kernel -a 0x3000000 -e 0x3000000 -d arch/arm64/boot/Image uImage 

です。-n 'TE0802hoge'は名前なので、何でもよいのかもしれません。-a や -e でアドレスを指定していますが、このアドレスがどういう影響があるのかはわかりません。

  • hsiを使って、Vivadoが吐き出したハードウェアエクスポートからデバイスツリーを作るときのカスタマイズは下記のとおり。

まず、system-top.dtsに自分のハードウェアの特色を出したい部分を書きます。(起動時のメッセージとか)

/dts-v1/;
#include "zynqmp.dtsi"
#include "zynqmp-clk-ccf.dtsi"
#include "pcw.dtsi"
/ {
model = "### TOKUDEN Trenz TE0802 v1.1 ###";
chosen {
bootargs = "console=ttyPS0,115200, root=/dev/mmcblk0p2 rw earlyprintk rootfstype=ext4 rootwait devtmpfs.mount=1 earlycon";
stdout-path = "serial0:115200n8";
};
aliases {
ethernet0 = &gem3;
i2c0 = &i2c0;
i2c1 = &i2c1;
serial0 = &uart0;
spi0 = &qspi;
sdhc0 = &sdhci0;
};
memory {
device_type = "memory";
reg = <0x0 0x0 0x0 0x3ff00000>;
};
cpus {
/delete-node/ cpu@2 ;
/delete-node/ cpu@3 ;
};
};
&sdhci0 {
clock-frequency = <187500000>;
status = "okay";
no-1-8-v;
disable-wp;
xlnx,mio-bank = <0x0>;
};

sdhci0にdisable-wpを付けるのは重要です。ハードウェアの構成上、WP(ライトプロテクト)が無いので、WPが無いことを明示的に示しておかないと、なぜか、Linuxの起動時にクラッシュします。それくらいのことで・・と思うのですが仕方ありません。

hsiで作ったUltraScale+用のデバイスツリーのソースをコンパイルするときには、dtcでそのまま変換することはできませんでした。

C言語風のinclude文などが、大量にひっかかっています。

どうやら、dtcに食わせる前にgccを使って変換してからでないといけないようです。それにはLinuxのカーネルをコンパイルしたディレクトリを用いて、

gcc -E -P -x assembler-with-cpp -I $(LINUX_KERNEL_SRCDIR)/arch/arm/boot/dts -I $(LINUX_KERNEL_SRCDIR)/include system-top.dts | dtc -I dts -O dtb -i $(LINUX_KERNEL_SRCDIR)/arch/arm/boot/dts -o hoge.dtb

とコマンドを与えるようです。

 

 

 

それから、真贋判定装置の中継基板の設計を進めました。右側8個のコネクタにも同じように配線を行い、基板上側のコネクタに接続しました。

Np11451128

ここからがなかなか難しい。

 

| | コメント (0)

2022.11.27

JTAG出力基板の完成へ

JTAG出力基板の完成に向けて作業をしています

Np11441

これが、45本の端子の好きな位置からJTAGの信号を出せるボードです。左にあるCPLDからJTAGの信号を出します。

右側は検査対象ICにつながるのですが、検査対象ICには最大で5Vくらいの電圧が加わっているかもしれないので、CPLDの端子を保護するためにMOSFETとショットキバリアダイオードをつないでいます。

出来たと思ったのですが、この基板だと検査対象のICのJTAG信号のレベルが1.8Vとかだと逆にCPLDの出力のほうが高いので保護が効きません。MOSFETによる保護は一方向だけです。

なので、VCCIO=JTAG信号のIO電圧にすることにしました。そうするとCPLD自体のJTAG信号やSPI信号もターゲットデバイスのVCCIOになってしまうので、一部分の信号だけレベル変換バッファをかませました。

Np11442

もうこれ以上の修正はないはず。

出図してこの基板は終了です。

作らなければいけない基板はあと10種類くらいある。

 

| | コメント (0)

2022.11.26

JTAG出力基板

真贋判定装置の肝であるJTAG出力基板を作成中です。

Jtagbrd

先日シミュレーションした回路を45個並べています。

VCCIOより高い電圧が加わった場合にショットキダイオードとMOSFETでクリップしてFPGAに過電圧がかからないようになっています。

| | コメント (0)

2022.11.25

ZCU111でUbuntu Linuxの起動に成功

大学の研究室で使っているZCU111用にLinuxをコンパイルし、Ubuntu Linuxを起動させることができました。

Zcu111linux

といっても、これはそんなに難しくはありませんでした。

なぜかというと、XILINXはXILINXのボード用のボード定義ファイルを用意してくれているからです。

ご存じのとおり、Linuxカーネルの構築は

make ARCH=arm64 xilinx_zynqmp_defconfig

でUltraScale用のデフォルトのコンフィグを作り、ネットワークの有効化などを適当に行ったのち、

make ARCH=arm64
mkimage -A arm64 -O linux -C none -T kernel -a 0x3000000 -e 0x3000000 -d arch/arm64/boot/Image uImage

を行います。

カーネルの構築で一番わけがわからないのはデバイスツリーだと思いますが、さすがはXILINXの標準ボードだけあって、linux-xlnx/arch/arm64/boot/dts/xilinxにデバイスツリー・ソースも入っていて一緒にビルドされます。そのディレクトリには出来上がったzynqmp-zcu111-revA.dtbがあるので、適当に改名してSDカードの第一パーティションに入れておけばよいのです。

標準ボードだとデバイスツリーがあらかじめ用意されているというのが、非常にありがたいことです。

 

なお、SDカードの第一パーティションはFSBLが入るためのFAT32にして、第二パーティションにEXT4でLinuxのファイルシステムを入れるというやり方をするのであれば、デバイスツリーのchosenを、

chosen {
bootargs = "console=ttyPS0,115200, root=/dev/mmcblk0p2 rw earlyprintk rootfstype=ext4 rootwait devtmpfs.mount=1 earlycon";
stdout-path = "serial0:115200n8";
};

にします。

 

また、SDカードの第一パーティションに存在する謎のファイルboot.scrとboot.scriptですが、boot.scriptをコンパイルするとboot.scrになります。

これは作らなくても構いません。従来はuEnv.txtでやっていたことをif文やwhile文や環境変数を使って、さまざまな起動メディアに柔軟に対応できるようにしようとした結果boot.scrになったようです。

SDカードから起動すると決めているのであれば、従来どおりのuEnv.txtを置いておけば全く問題ありません。

つまり、ZYNQ UltraScale+であっても、SDカードの第一パーティションには、

  • boot.bin
  • bl31.elf
  • u-boot.elf
  • devicetree.dtb
  • uImage

があればよいのです。増えたのはbl31.elfだけです。

| | コメント (0)

真贋判定装置子基板の設計再開

展示会「SEMIジャパン」も近づいてきたので、真贋判定装置の設計を急ぎます。

Np11413d

まずは、電源子基板。

Np1141paneled

次はGND子基板

Np1142paneled

次はアナログ子基板

Np1143paneled

出図完了!

えっ?

全部同じじゃないかって?

微妙に違うんです。

でもメタルマスクは共通だから実装費用が少しは安くなるかな。

 

| | コメント (0)

2022.11.24

ZYNQMPのBoot.binでXFSBL_ERROR_ADDRESSが出る原因

2日前からZynqMPのBoot.binを作っていて、

XFSBL_ERROR_ADDRESS: FFFC0000
Partition 3 Load Failed, 0x2E

というエラーで止まってしまって困っていました。

Xfsbl_error_address

ZynqMPのBoot.binを作る際にセカンドステージのブートローダであるU-bootを組み込んだり、テスト用であればペリフェラルテストやメモリテストを組み込んだBoot.binを作ることになると思います。

このとき、メモリテストやU-bootなどの少し大きなものを組み込むと、前述のXFSBL_ERROR_ADDRESS: FFFC0000が出て止まってしまします。

今日はこの原因を究明しました。

まず、Partition 3 Load Failed, 0x2Eの「2E」というのはXFSBL_ERROR_ADDRESSの意味なので、U-Bootが読み込まれるアドレスが異常だと言っているのです。

デフォルトのFSBLではXFSBL_OCMというマクロが定義されていて、BOOT.BINに含まれたアプリのロードアドレスがOCMの範囲(0xFFFEA000~0xFFFFFFFF)外だと、XFSBL_ERROR_ADDRESSを出すからです。

一方、Trenz社が作ったboot.binを起動してみると、0x8000000にu-boot.elfを読み込んでいるようです。

Trenzboot

0x8000000はDDR4 SDRAMの範囲なので、OCMを外れていてもDDRメモリにロードするのはOKなのでしょう。

それでは、どこでU-bootをFFFC0000にロードしようとする不届きな設定があるのかというと、U-bootを作るときにひな形にしたxilinx_zynqmp_mini_defconfig でした。

この中に

CONFIG_SYS_TEXT_BASE=0xFFFC0000

と書かれているからこのアドレスにロードしようとしてクラッシュします。

これを

CONFIG_SYS_TEXT_BASE=0x8000000

にすればロードできて起動できるようになります。

 

Ubootlaunched

そうしたら今度はSDカードがどうのというエラーを出してきます。

Nosd

一つ問題を解決すると次から次へと問題が出てきますね。

それがLinux構築の楽しみでもありますが。

| | コメント (0)

2022.11.23

電圧保護クリップ回路に放電抵抗は不要

双方向過電圧保護回路は、最終的にこうなりました。

Nores

FPGA PINと書かれたノードに放電抵抗は不要なのです。

Xが0→5Vに立ち上がったときに少しだけFETが漏れでオーバーシュートが出ますが、昨日のブログで書いたように、ショットキバリアダイオードでクリップされたVCCIO+Vf以上には上がらないようになっています。

Nprestrans

しかも、このヒゲは抵抗で放電しなくても速やかにVCCIOに収束します。

ショットキバリアダイオードは電位差がVfより高ければ導通して電流を流すと思われているかもしれませんが、ショットキバリアダイオードはもともと漏れ電流が大きいので、Vfより低くてもそれなりに(μAのオーダーで)電流を流してくれるからです。相当に漏れているダイオードというイメージです。

それゆえ放電抵抗は不要です。

そればかりか、放電抵抗がないほうがヒゲも低くなるというシミュレーション結果も得られました。この原因はわかりません。

 

| | コメント (0)

2022.11.22

MOSFETを使った双方向電圧クリップ保護回路

FPGAと、正体不明のデバイス「X」を接続する回路を作りたいのですが、Xが何Vを出してくるかはわからない。

そんな場合にFPGAの端子を過電圧から保護するという回路を作ることになりました。

MOSFETを使えば電圧クリップ回路ができるということなので、シミュレーションをしてみました。

 

まずは、FPGAのピンを想定したパルス源から「X」に向かって信号を出力する場合。

Mosclip1

当然のことながらFPGA PINとXは導電圧になります。

Mosclip2

 

次は逆方向。FPGAが入力側になる場合です。

基本的にはMOSFETはゲート+Vthより高い電圧はD→S方向に通さないので、ゲートにVCCIOからVthだけ高い電圧をかけておけば、それ以上高い電圧はカットされてVCCIOになるという考えです。

Mosclip3

左側の1.8VというのがFPGAのVCCIOを想定したもので、5Vから10kΩで吊っているのはバイアスを与えるための抵抗です。左側のMOSFETはダイオード接続をしているので、1.8V+Vthの電圧がゲートに加わります。

これで「X」から0~5Vの電圧を加えてみると見事にクリップされました。

Mosclip4

ところが、@lyuka_jp さんから矩形波の過渡時には過電圧が発生するとの指摘をいただきました。

矩形波でシミュレーションしてみると、確かにヒゲがすごい出ます。

Mosclip5

 

実機でもこんなにヒゲが出るのかと訝しんで、適当な基板(SMAと電源コネクタがあるやつ)にMOSFETや抵抗を付けてジャンパを飛ばして実験してみました。

Mosclip6

その結果、たしかにシミュレーションと同じようなヒゲが出ていました。

1.8Vにクリップしたいのに3.3Vくらいまで出ていますね。

Mosclip6_20221123011001

まず改善しようと思ったのはゲートの電位です。

5Vのパルスを受けると、MOSFETのゲートはこんなにも揺らぎます。

Mosclip7

ゲートに3000pFのコンデンサをつないでもほとんど変わりませんが、10uFのコンデンサをつなぐと、突然おとなしくなりました。

Mosclip8

ただ、ゲートの電圧を安定化させてもパルスの立ち上がりが貫通してヒゲが出る現象はあまり変わりません。

Mosclip9

ヒゲが出る原因はゲートの電圧が揺れるのが原因ではなく、ソース・ドレイン間容量によって矩形波の立ち上がりが微分波形になって出てきているからのようでした。

次に試したのは、MOSFETとXとの間に47Ωくらいの抵抗を入れること。これはほとんど効果はありませんでした。

一番効いたのがMOSFETのソースからVCCIOに向けてショットキバリアダイオードを入れたこと。

Mosclip10

これが効果てきめん。ヒゲをカットすることができました。

Mosclip11

こういったショットキバリアダイオードはFPGAのピンに保護用として埋め込まれているので、あえて付けなくてもFPGAのピンにつなぐだけで自動的に挿入されます。しかし、本来はFPGAのピン内蔵ショットキバリアダイオードは導通させてはいけないダイオードです。(何のための保護素子だ!)。通常はこのダイオードが導通しないギリギリの電圧がIOピンの絶対最大定格になっています。

ですから、安全のためにはFPGAの内蔵ダイオードよりも低いVfのショットキダイオードを使ってVCCIOに放電して保護すればよいわけです。まぁ、短時間だから内蔵ダイオードがONしても平気だと思うんですけどね。

ただし、過電圧はVCCIOに流したらOKではなくて、VCCIOの電圧が上昇しないかどうかも注意深く見守る必要があります。LDOには吸い込みができないタイプもあるからです。シミュレーションした感じではVCCIOに10uFくらいのコンデンサをつないでおけばダイオードを通じて流れてきた過電圧は吸収できるようでした。

 

これも実機でやってみました。

まずは5Vの矩形波を800mVでクリップ。

800mv

次は1.8Vでクリップ。

1800mv

次は2.8Vでクリップ。

2800mv

最後は3.8Vでクリップです。

3800mv

このとおり保護回路として働くことがわかりました。

 

| | コメント (0)

2022.11.21

アナログスイッチで電圧がクリップできない

アナログスイッチを使ってFPGAの入力端子を保護できないかどうかと思い、実験してみました。

アナログスイッチというのはロジック入力でアナログ信号をON/OFFする部品です。もともとCMOS 4000シリーズに4066というアナログスイッチがあって、それを1回路化したものが各社より発売されています。

下の図は74AHC1G66のものですが、おおよそどのアナログスイッチも似たような回路になっています。

Asw_20221123025201

EがHレベルのときZとYの間がONするというものなのですが、MOSFETはゲート電圧でクリップされるという神話を信じて実験してみました。

その結果がこちらです。

 

下の図はVCC=3.3Vにして、Zの端子に5Vの矩形波を加え、Yの端子の電圧を測ったものです。

Asw2

全然クリップされていない。

しかも、E=Lなのに100%漏れてきている。

OFFになりません。

どうやら、アナログスイッチはVCC以下の電圧を入れなければならないようです。

VCC以上の電圧を印可した場合どうなるかは一概にはいえませんが、バグります。

下の図は、どこまで電圧を加えるとOFF状態が壊れるかを試したもので、VCC=3.3Vで、Z=4.5Vくらいの電圧を加えたところです。

Asw3

なんだかニョロニョロしています。サインカーブかなと思ったのですが、

Asw4

このニョロニョロはランダムでした。

チンアナゴの大群のように見えます。

こんなことをしていたらアナログスイッチが猛烈に発熱して壊れてしまいました。

74AHC1G66; 74AHCT1G66のデータシートを読んでみると、

Asw2_20221123030301

MC74VHC1G66のデータシートを読んでみると、

Asw3_20221123030501

やはり4066タイプのアナログスイッチはVCCを超えてはいけないようです。とほほ・・

結論を言うと、アナログスイッチはVCC以下の電圧で使わなければならず、電圧をクリップしてくれる保護素子にはならないということがわかってきました。

 

ここまで設計した基板をどうするんだべという感じです。

Np1144

| | コメント (0)

2022.11.20

DSF2022で講演します

すっかり忘れていました。

11月25日(金)に開催されるDesign Solution Forum 2022で、

【参加型】 DSF×ACRiコラボ企画:本音で語ろう!日本のものづくりとエンジニアはどうなる!?

というテーマですすたわりさんと対談します。

Dsf2022

時間は16:00から17:10までです。

なお、この対談会はオンライン配信されません

現地に来ないと聞くことはできません。

だからこそできるオフレコな話になると思います。

https://dsforum.jp/2022/seminer/3180/

多くの皆様のご来場をお待ちしております。

 

 

| | コメント (0)

2022.11.19

任意のピンからJTAGを出す回路

IC真贋判定装置を作るため、任意のピンからJTAGの信号を出す回路を作っています。

10月31日時点の回路

Np11441031

本日の回路

Np1144

あまり変わっていないように見えるかもしれませんが、内層の配線をいっぱい引いています。

右側に45個並んだICはアナログスイッチで、FPGAの端子とターゲットICとの間の電圧をクリップして保護するために入っています。

FPGAは2個使っていて、左側のFPGAがJTAGの信号を作るもの、右側のFPGAがアナログスイッチのON/OFFをするためのものです。

 

真贋判定装置では最大2340ピンのICを検査しますが、任意の端子からJTAGの信号を出せるように45chのこのようなモジュールを作って、52個並べて、任意の端子からTCKやTDIを出せるようにしています。

つまり、4ch-2340chのマトリックスというか、クロスバースイッチを作ろうというわけです。

DUTの2340個のピンはどのような電圧になるかわからない(VCC 3.3Vかもしれないし、1.0Vかもしれない)のですが、JTAGのロジック電圧も何Vになるかわからないので、FPGAに何Vが加わってもよいようにしなければなりません。

ここまで設計していてふと不安になりました。

  • アナログスイッチで本当に電圧クリップができるのか?
  • この基板のFPGAは秋月のLattice MACHXO2-256だけど、入るのか?

このあたりを検証していかなければなりません。

 

 

| | コメント (0)

2022.11.18

RFSoCのバウンダリスキャン

MITOUJTAGでZYNQ UltraScale+ RFSoCのバウンダリスキャンができるかどうか試してみることにします。

使ったボードはXILINXのZCU111。

ZCU111に搭載されているUSB-JTAGはMPSSEのピン配置なので、MPSSEとして接続します。

ところが、Genericと書かれたデバイスが1個出るだけ

どうやら、Dummy DAPが解除されていないようです。

SVFで次のコードを実行したら自動認識することができて、

STATE RESET;
TDR 0;
HDR 1 TDO (1); // ARMのDAPを無視するため
SIR 16 TDI (83FF) ; // JTAG_CTRL
SDR 32 TDI (00000003) ; // ARM DAPとPL TAPを有効化
RUNTEST RESET 16 TCK; // 切り替えた後は、Test-Logic-Resetステートで5回以上 TCKをトグルする

RFSoCを無事にバウンダリスキャンすることができました。

Zcu111bscan

作ったBitStreamをそのまま書き込むこともできました。

Zcu111bscan2

書き込みは遅いけど、ちゃんと起動します。

ただ、バイナリカウンタを作ってカウントアップしていく信号をLEDのところから出力してみたのですが、何だかようすがおかしい。

Zcu111bscan3

どうやら、入力と出力が反転しているようです。

2018年に解決したはずのバグが

http://nahitafu.cocolog-nifty.com/nahitafu/2018/10/ultrascale-e5ac.html

なぜか再燃しているようです。

もしかすると、MPSoCバグだと思ってMITOUJTAGの中で入力と出力を反転させたのですが実はRFSoCではそのバグは起きておらず入力と出力を反転させる必要がなかったとか、XILINXがバグに気が付いて入力と出力の反転をこっそり修正していたとか、そういう理由かもしれません。

| | コメント (0)

2022.11.16

EdgeTech+に行ってきました

今日はET/IoT・・・EdgeTech+に行ってきました。

出展者もスカスカ、来場者もスカスカで空きブースがいっぱいという感じでした。

ETどうしてしまったのか・・。

そういえば、当社も出展していない 

( ゚д゚)ハッ!

 

もとい。

ETのあとで組み込みFPGA関係者飲み会を実施してきました。多くの方とお会いできて楽しかったです。

Etnomi

| | コメント (0)

2022.11.05

突然の伊勢神宮

伊勢神宮にいくことが昨夜なぜか突然決まって、今日、日帰りで行って帰ってきた。もう19年目だ。電車の予約やスケジュールはほとんど息子が手配してくれたので楽だった。

| | コメント (0)

« 2022年10月 | トップページ | 2022年12月 »