« 2018年1月 | トップページ | 2018年3月 »

2018.02.28

UIOの使い方

ZYNQを使った組み込みLinuxで、PLに実装したAXI経由のIPにアクセスしたい場合、デバイスドライバが必要です。

Cosmo-Zの場合、0xb8800000からの64kバイトと、0x20000000からの512MByteを使用します。以下の2つの領域を使用します。0xb8800000にはAXI経由でコントロールレジスタが実装されていて、0x20000000からは波形バッファのメモリとなっています。

そのような場合、UIOを使うと簡単です。

UIOは普通はカーネルに組み込まれているので、これを使うには、デバイスツリーに以下のような記述をします。

/dts-v1/;

/ {
    ・・・
    amba {
        ・・・
        cosmoz-reg@b8800000 {
            compatible = "generic-uio";
                reg = <0xb8800000 0x10000>;
        };
        cosmoz-mem@20000000 {
            compatible = "generic-uio";
                reg = <0x20000000 0x20000000>;
        };
        ・・・・
    };
    ・・・

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

    ・・・

割込みを使わないのであれば、この記述で十分です。

AXIバスにつながったIOを操作するためのuioはambaセクションに書きます。

cosmoz-reg@b8800000 というのはラベルです。自分のドライバの名前と先頭アドレスを書いておきます。compatible = "generic-uio";というのは、UIOドライバを使うことを意味します。reg = <0xb8800000 0x10000>;は、確保したい先頭アドレスとサイズを書いておきます。

こういう記述をコントロールレジスタ用と、メモリ用に2個書きます。

そして、chosenのbootargsに、uio_pdrv_genirq.of_id=generic-uioを書きます。これで、UIOドライバが使えるようになります。

デバイスツリーは、SDカードの先頭パーティションに書かれているので、マウントして、dtcコマンドを使ってテキストに戻します。

$ mount /dev/mmcblk0p1 /mnt
$ dtc -I dtb -O dts /mnt/devicetree.dtb -o/mnt/devicetree.dts

そして上記の変更を施したのち、

$ dtc -I dts -O dtb /mnt/devicetree.dts -o/mnt/devicetree.dtb

で、バイナリに戻します。

dtcがお使いにZYNQ Linuxに入っていない場合は、

apt-get install device-tree-compiler

でインストールします。

さて、UIOでメモリマップドIOにアクセスするには、以下のようなプログラムを書きます。

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/ioctl.h>

int main() {

int fd_regs = open("/dev/uio0",O_RDWR);
	int fd_mems = open("/dev/uio1",O_RDWR);
	unsigned long *regs;
	unsigned long *mems;

	printf("UIO driver test\n");
	if(!fd_regs) {
		printf("Can not open /dev/uio0\n");
		return 1;
	}
	regs = (unsigned long *)mmap(NULL, 0x1000, PROT_READ | PROT_WRITE, MAP_SHARED, fd_regs, 0);
	for(int i=0;i<6;i++) {
		printf("FPGA reg(%x) data=%08lx\n",i,regs[i]);
	}
	regs[0] = 0x123;
	mems = (unsigned long *)mmap(NULL, 0x20000000, PROT_READ | PROT_WRITE, MAP_SHARED, fd_mems, 0);
	for(int i=0;i<16;i++) {
		unsigned long offset = 0x10000 << i;
		if(offset >= 0x20000000 / 4) break;
		printf("write offset=%x\n",offset * 4);
		mems[offset] = i;
	}
	int baseaddr = 0x20000000;
	for(int i=0;i<16;i++) {
		unsigned long offset = 0x10000 << i;
		if(offset >= 0x20000000 / 4) break;
		printf("addr=%08lx, val=%08lx\n",baseaddr + offset, mems[offset]);
	}
	munmap(regs,0x1000);
	munmap(mems,0x20000000);
	close(fd_regs);
	close(fd_mems);
	return 0;
}

このプログラムを簡単に説明します。

まず、open()で、/dev/uio0をオープンしたら、mmapでその仮想アドレスを取得します。

mmapの第一引数は通常はNULLを指定します。第二引数は確保したいメモリサイズで、単位はバイトです。第三引数はPROT_READ | PROT_WRITEにして、第四引数はMAP_SHAREDにしておきます。こうしておけば他のプログラムからアクセスした際にも問題が起きず、読み書き可能な空間としてマッピングされます。

第5引数はopenで取得したファイルハンドラを指定します。

第6引数はオフセットですが。ここは0にします。UIOドライバで0以外の値を指定するとこの関数は失敗してしまうようです。

mmapで得られた仮想アドレスはvoid型のポインタなので、適当な型にキャストしてから使います。*regs = 0x123やreg[0]=0x123とすれば、物理アドレスの0xb8800000番地に0x00000123が書き込まれ、AXIバスが動き始めます。

上のプログラムではregsはunsigned long *なので、regs[1]にアクセスすると、0xb8800004番地が読み書きされます。

このようにして、FPGAのコントロールレジスタやメモリ空間にアクセスしたら、(プロセス終了時に自動的に開放されるそうですが)最後にmunmapで開放します。munmapの第二引数は、mmapで確保したサイズです。

デバイスツリーで申告したアドレスが、実際にはPLに何もつながっていなかったりした場合は、読み書きしようとしたときに固まってしまうか、Bus Errorというのが出ます。

このようにUIOを使えば、PLに実装したペリフェラルや物理メモリを自由に使うことができるようになります。

| | コメント (0)

2018.02.27

FCLKの変更が反映されないとき

後で書く

| | コメント (0)

2018.02.26

基板の実装とか生基板とか超特急で仕上がってきた

今月の19日にできていた生基板の実装が、もう上がってきました。

これは16bit 2ch 1GspsのAD変換基板です。

Np1111_top

Np1111_bot

40Gbpsの光ファイバで変換結果を送ります。

それから、先週の火曜日に出図した基板の生板が出来上がってきました。

Np1104a_top

Np1104a_bot

これはHDMI 2入力2出力のビデオ処理ボードです。

基板屋さんや実装屋さんが頑張ってくれているのだから、私も頑張ってデバッグして納品しなければなりませんね。

| | コメント (0)

2018.02.25

AD360の基板実装が完了

2月12日から実装をしていたAD360という高精度AD変換基板の実装が上がってきました。土曜日に到着しました。

Ad360a_top

Ad360a_bot

これは±1Vppの入力を18bit 500kHzでサンプリングして、6枚のSDカードに書き込むという装置です。

主役のマイコンはRX63Nで、ライブラリには昔作ったRXduinoの1.20を使っていて、超低消費電力です。

今夜か、月曜日には動作テストと調整を行い、今月中に出荷の予定です。

| | コメント (0)

2018.02.24

UIOを使う

User Space IOというデバイスドライバを使うことで、Cosmo-Z MiniのADCレジスタの内容を読み出すことができるようになりました。

自分でドライバを作るよりもずっと楽です。よくできていますね。

デバイスツリーに記述すると、/dev/uio0や/dev/uio1というのができているので、これをopenしてmmapすればFPGA内のレジスタを叩けるようになります。

Cosmo-Z Miniは、FPGA内の制御レジスタ(0xb8800000から0x1000バイト)と、波形用のバッファメモリ(0x20000000から512Mバイト)の2つのアドレスにアクセスしたかったので、どうすればよいか悩んで、自分でドライバを作ろうと思っていました。

UIOでやるには、uioを2つ入れればよかったのです。

0x20000000から0x3fffffff番地までのメモリを一気にmmapすることもできるようです。

Cszmini4

これなら波形バッファの読み出しが細切れにならないで済みます。

それから、Cosmo-Z MiniにはAD9253というADCが乗っていて、FPGAのPLからアクセスするようになっています。

Cszmini1

そのADCをSPIでたたいて、内蔵レジスタの値を読み出した結果です。

Cszmini2

ちゃんと読み出せています。

Cszmini3

どうやら問題ないようです。

詳しいUIOの使い方は別の機会に書こうと思います。

| | コメント (0)

2018.02.23

Cosmo-Z MiniでリッチなLinuxが動くようになった

Cosmo-Z MiniでU-BootやLinuxが動くようになりました。

Cosmozmini

FPGAの移植はそれほど難しくなかったのですが、Linuxの移植で苦労しました。

U-BootやLinuxは、他のボードのを持ってくるだけはだめで、そのボード専用に作らないと、いろいろなところでトラブルが起きますね。

そこで、Zynqberryスタータキットに付属している小冊子「ZYNQのLinuxが動くまで」の小冊子がとても役に立ちました。

Zb1

「ZYNQのLinuxが動くまで」は、Zynqberryスタータキットについてきます。

https://www.trenz.jp/product/zbstart/

これを見ながらカスタマイズしていったら、ZYNQでUbuntuが動くようになって、有線LANも無線LANもつながりました。

まだアプリができていないので、AD変換した波形は見えませんが、MITOUJTAGを使ってピンの状態を確認したところ、LVDSを通じてADCから何らかの信号を受信できている模様。

Dwtboi3vqaamw5_

Dwtbpbbvoaa4frn

Dwtbp_cv4aewdud

MITOUJTAGを使うと、ハードウェアレベルで信号の確認ができるので、デバッグがとても楽になります。

| | コメント (0)

2018.02.19

先週火曜日に注文した基板がもうできた

先週の火曜日に基板屋さんに依頼した6層基板がもう出来上がってきました。

Np1111_top

Np1111_bot

6層!金フラ!国産!早い!

しかも、某ネット系の基板屋さんよりずっと安い。

仕上がりも全く問題ありません。

この基板は超高速ADCボードなのですが、ADCの発熱がすごいので、放熱の良いケースに入れることを前提として設計しています。

Np1111_inbox

ついに、ボード単体・基板ではなく、箱に入っていることを前提とした製品を開発することになりました。

| | コメント (0)

Digikeyの新しいInvoiceをインポートできるようにした

特電ではDigikeyからたくさん仕入れているので、InvoiceのPDFを自動的に解析してデータベースに登録するような仕組みを作っていました。

しかし、2月10日ごろからDigikeyのInvoiceの形式が変わってしまいました。て困っていてもしょうがないので、なんとか新しい形式のInvoiceを解析できるようにしました。

Invoice1

新しいInvoiceのPDFは、テキストにコピーすると、こうなります。

1 190 0 190 PART: 490-6470-1-ND DESC: CAP CER 10UF 6.3V X5R 0805
COO : CHINA ECCN: EAR99 HTSUS: 8532.24.0020
12.68000 2409 T
LEAD FREE ROHS COMP REACH UNAFFECTED Jun-2016
2 220 0 220 PART: 445-4112-1-ND DESC: CAP CER 10UF 6.3V X5R 0603
COO : JAPAN ECCN: EAR99 HTSUS: 8532.24.0020
7.11000 1564 T
LEAD FREE ROHS COMP REACH UNAFFECTED Jan-2017

簡単に説明すると、

数字 空白 数字 空白 数字 空白 数字 空白 PART:

の行は、注文数量や、注文したDigikey品番などを表しています。

その次のCOO:で始まる行は、生産国、ECCNなどを示しています。

その次の、数字 数字 Tの行は単価と金額、消費税の意味です。

最後は鉛フリーやRoHSのステータスを示しています。

preg_match("/([0-9]+)\s([0-9]+)\s([0-9]+)\s([0-9]+)\sPART:\s(\S+)/",$line,$matches))とかで解析できるかと思ったのですが、

すべての行がこの形式で来るわけではありません。

不定期にMercury: Cert on File. For more information contact RoHS@DigiKey.comという行が来たり、CUST番号(顧客が勝手につけられる品番)を付けると、行の順序が変わってしまいます。

そこで、ある程度はどんな順序で来ても解析できるようにしておかなければなりませんが、無事に取り込むことができるようになりました。

Analyzed

これで溜まりに溜まったDigikeyから入荷した部品を仕分けることができました。Many

これ以上、DigikeyのInvoiceの形式が変わりませんように・・

| | コメント (0)

2018.02.18

クロストークを減らすために

HDMI入出力基板の再設計をしています。

昨年の3月に、こんな基板を作りました。

Cosmokdvi_720

この基板は、HDMI入力が2CH、HDMI出力が2CH、MIPIのCSIカメラのコネクタが2CH、それからUSB3.0があります。中央のヒートシンクの下にあるのはKintex-7で、横には1GBのDDR3 SDRAMが乗っています。

この基板は、2つのHDMIコネクタから1080pを入力できるように設計したはずなのですが、どうしても片方のチャネルで720pまでしか解像度が上がらないという問題がありました。

その原因は、HDMIのデータ0とHDMIクロックが並走している区間が4cm程度あり、データからクロックへクロストークが起きているためだと推測されました。

下の図が、CLKとD0、D1のレイアウトです。

Old

そこで、新しい基板では、クロックとD0、D1、D2の各ペアの間にGNDを挟むことで、クロストークを減らすことを狙っています。

New

これで2CHとも1080pが出ればと思っています。

他にも、前回の基板では水晶発振器を乗せ忘れたとか、細かい間違いがいくつかあったので、それも修正しました。またVCCAUX_IOに2.0Vを与えることができるよう分離したりもしました。

基板全体の姿はこんな感じです。わかりやすくするため、ポリゴンを消しています。

Overview

結構いい感じの基板になってきました。

| | コメント (0)

2018.02.16

VivadoでのIBERT試験

Kintex-7と40Gbps QSFP光ファイバ搭載のFPGAボード「Cosmo-K」には、特電製のUSB-JTAGが乗っています。

Qsfp_self

このUSB-JTAGをVivadoから接続し、10Gbps光リンクのIBERT試験をすることができるようになりました。

IBERT試験というのは、高速シリアルトランシーバの試験のひとつで、時間や電圧をずらしていってどこまでずれても通信ができるかというのを確かめるものです。

下の図はその結果です。青い部分がエラーのない箇所になります。

Vivado_ibert

10Gbpsとかになるとオシロでアイパターンを見るのが困難になってくるので、受信側でタイミングや電圧を既知の量だけずらしていって、どのくらい耐性があるかを見るというわけです。

この図によれば時間軸は50%以上の余裕があります。つまり、10Gbpsは余裕、20Gbpsでもいけるかも、というくらいの性能なのです。

XILINX ISEに付属のAnalyzerでも同様のことはできましたが、Vivadoになって使い勝手がすごくよくなりました。

ちなみに、Vivadoと特電のJTAGライブラリとの間はXVCServerというプロトコルでつないでいます。そのため、Platform Cable USBは不要で、USBでつなぐだけでこの検査ができるようになりました。

Xvcserver

この図は横と縦の増分を1にしているので、1個の結果を得るのに10分くらいかかりますが、増分を4くらいにすれば1分程度で検査が終わります。

Ibertk316

| | コメント (0)

2018.02.13

DigikeyのInvoiceの形式が変わった!

2月10日ごろから、DigikeyのInvoiceの形式が変わりました。

下の図は旧型式。

Olddigikey_2

次の図が新形式です。

Newdigikey_2    

Invoiceの形式が変わることは特電にとって大問題なのです。

なぜならば、特電ではPHPとMySQLを使って電子部品在庫管理システムを作って管理していたのですが、

Tokuden_parts_2

「Digikey Invoiceのインポート」機能が動かなくなってしまうからです。

ああ困った。

| | コメント (0)

2018.02.12

1Gsps ADCボードの新基板の設計がだいたい終わった

1Gsps 16bit 2chのADCボードの改版を設計しています。

114mm×100mmのサイズに収まりました。6層基板です。

Np1111_top

裏面はこんな感じ。

Np1111_bot

今回使用するADCは非常に発熱が大きいので、放熱ができるよう放熱器付きのケースを選んだこととで、基板のサイズが少し大きくなりました。その分、放熱のための戦略がいくつか選べるようになったと思います。

AD変換したデータは40Gbpsの光ファイバでPCI Expressボードに送るのですが、このQSFPモジュールの発熱も大きいですね。

とにかく発熱との闘いです。

| | コメント (0)

2018.02.10

特電製品お見積りフォームを作りました

特電製品のお見積りフォームというものを作りました。

このお見積りフォームを使うと、PDFの見積書が年中無休で24時間いつでも作ることができます。

Quote1

まずは、https://www.tokudenkairo.co.jp/quote/  のページで、「商品一覧へ」を押して

https://www.tokudenkairo.co.jp/quote/prodlist.php

のページへ行ってください。

下の図のように、特電の製品がいろいろと並んでいます。

この中で見積書が必要な商品を選んで、カートに入れます。

Quote2

お取引条件の設定の画面まで行きます。

この画面が、この見積もりフォームの特長です。

大学や公的研究機関の見積もりでは、代表者名や代表者印が必要だったり、日付の指定や、印刷されたハンコが不可、など、さまざまな要求があります。

しかも、それらの要求事項は大学によってみな違うので、細かい条件をユーザが指定ができるようなフォームにしてしまったというわけです。

Quote3

そして、Webブラウザ上で仮の見積書が表示された後、

Quote4

希望される方にはメールでPDF版の見積書がとどくというしくみになっています。

Quote5

これで、大学や研究機関向けの見積書が、オンラインで作成できるようになり、事務作業の簡素化が図れます。

| | コメント (0)

2018.02.09

AD360の基板が届いた

月曜日に出図した基板「AD360」がもう出来上がりました。

6層基板で0.1mmルール、金フラッシュなのに、実働4日です。しかもネット基板屋さんの某P社より安い!

作っていただいたのは大阪にある国産のプリント基板メーカーさんです。本当は土曜日着の予定だったのですが、予定より早く出来上がったようです。とても助かりました。

Ad360a_pcb

来週早々から実装です。

一発で動くといいな。

| | コメント (0)

2018.02.05

AD360の新基板を出図

18bit 20chの多チャネル精密AD変換ボード「AD360」の新しい基板を出図しました。

Np1071_top

Np1071_bot

これまでのAD360は入力電圧範囲が±10Vという仕様でした。10Vという電圧をあまり使うことはないと思うので、今回からは±1Vに変更しました。

AD360のノイズはほとんどがAD変換器のノイズです。プリアンプがあってもなくても、ノイズレベルは変わらずに±2LSB程度ですから、ゲインを稼がないほうが有利になります。

入力換算のノイズレベルが17μV程度となり、従来の約10分の1に減る見込みです。

| | コメント (0)

2018.02.03

Cosmo-ZをC#でコントロールためのXML-RPCプログラムを妻に発注した

うちの妻がプログラミングの勉強をしているので、Cosmo-Zのファームウェア2.0をWindowsから遠隔操作したり、Windows用のソフトを自作できるようにするためのソフトウェアを発注してみました。

プログラムの構造は下のようになっています。

Cosmozcs_2

XML-RPCというのは、XML形式でRPCを行うためのプロトコルです。あるマシンで関数呼び出しをすると、リモートにあるCosmo-Z上でその関数が実行されて、結果が返るというもので、その関数の呼び出しや引数の受け渡しにXMLを使っているというものです。

クライアント側のOSや言語によらないのと、Pythonとの親和性が高そうなので、ちょっと古いけどXML-RPCを選択しました。

PythonならXML-RPCは簡単に使えるのですが、Windows上でも簡単にGUIアプリを作りたいよねということで、C#でXML-RPCが動くようにしたかったわけです。

Cszcli1

・・・もちろんVisualStudio上でPythonでGUIアプリ作成することもできるのでしょうが、私がPythonに慣れていないのと、最近の若い人はPythonかC#なので、C#でCosmo-Zにアクセスできるようにと頼んでみました。

Cszcli2

だいぶん苦労したようですが、ちゃんとADCの値や、FPGAの温度が取れています。

えらい!

| | コメント (0)

« 2018年1月 | トップページ | 2018年3月 »