2013年10月31日

FX3の高速化検証3 〜論理的な速度の考察と結果〜

前回のブログでは、全体の仕組みや検証結果、サイプレス社との検証の違いについて説明をしました。

簡単に前回のブログの内容をまとめると、FPGA〜FX3のGPIFUインターフェイスまでは380MB/s、FX3〜PCまでは340MB/sの転送レートとなりました。

今回は、後者のFX3〜PCまでの転送レートについて少し考察をしてみたいと思います。
(前者のFPGA〜FX3については、弊社独自の技術のため説明は割愛します。ただし、高速転送を支えているのがFPGAの内部処理技術になります!!!!)

まず初めに論理的にはFX3〜PCまでどのくらいの転送レートが出るのか検討してみます。

この論理的な転送レートの検討については、FPGAマガジンNo.2のP31の特集記事および、アプリケーションノートAN86947が参考になります。(というか記事の内容そのものです。)

USB3.0バスの転送性能(スループット)は5Gbps(625Mバイト/s)といわれています。しかし、FPGAマガジン「【転送レート400Mバイト/sをたたき出す!】システムのボトルネックをアナライザでじっくり調べる」の記事では、2つの要因でUSB実行転送速度が低下すると説明されています。

1.8b/10b符号変換によるもの
2.リンク層での制御やプロトコル層でのパケットの付加によるもの

どちらもUSB3.0の規格上の仕様になりますがどのような影響があるのか検討します。

1の8b/10b符号変換とは、8bitのデータを10bitへ符号化する変換です。そのため、USBバスを通るデータは10bitに符号化されたデータとなります。
つまり、実際のデータ伝送効率=8/10=0.8倍となります。そのため、1秒間に625Mバイトのスループットだとしても、その中を通る実データは625MB/s×0.8=500MB/sとなります。つまり、8b/10b符号変換を採用したことにより、論理的に125MB/sの転送性能ダウンが発生するのです。

2のパケット付加も1.と同様の理由によりUSBバスの転送レートを低下させる要因となりますが1.のように論理的に計算することは難しいと思います。それは、1パケットで見るとわかりやすいのですが、全データの伝送ということで考えると、各部の処理速度や相互のタイミングなど複数のことが複雑にからむためです。

そこで、この2の影響による性能をみるために今回は実際に転送速度を計測してみることにしました。この時に参考になるのが、サイプレス社から出されているアプリケーションノートAN86947です。
前回も記載をしましたが、このアプリケーションノートによると、バルク転送のサンプルアプリを用いることにより、454,300KB/s(=443MB/s)のスループットを実現できると書かれています。念のため、SVI-06改ボードのFX3をアプリケーションノートにあるファームウェアに書き換えて実際に実験をした結果、アプリケーションノートと同様の速度となりました。(注:全く同じ速度になっていますがSVI-06改ボードでの実測値になります。)


SVIの結果.jpg


当然、アプリケーションノートに記載のバルク転送でも、1および2の影響を受けていることになります。
そのうえで、結果として454,300KB/s(=443MB/s)のスループットが確認されたということは、1と2両方の影響を受けたとしても、FX3〜PCへのデータ伝送の実測した転送レートとして443MBは出すことができるということになります。

2だけの単独の結果ではないのですが、1の論理的な転送レート(500MB/s)を踏まえてみても、443MB/sはUSBバスの転送レートの上限に近いのではないかと考えられます。
2を単独で論理的に求められているわけではありませんが、USBバスの論理的な転送レートの上限として443MB/sと考えてもよいと思います。

今回の検証システムでは、FPGA〜FX3まで380MB/sであるため、USBバスの転送レートによる制限を受けることはありません。そのため、380MB/sがFX3〜PCの転送における転送レートの目標値として目指したいと思います。

次回以降はこの目標値を達成させるために行った各部分での方策について説明していきます。
posted by デベマネ at 15:32| Comment(0) | EZ-USB/FX3

2013年10月29日

FX3の高速化検証2 〜サイプレス社独自検証と弊社検証の違いについて〜

前回は検証の全体像と結果について説明をしました。
一方サイプレスからも転送レートの検証を行ったレポートである、アプリケーションノートAN86947 - Optimizing USB 3.0 Throughput with EZ-USB FX3 が発表されています。

今回は、サイプレスと弊社の検証の違いについて説明を行います。

<サイプレス社独自の検証結果>
サイプレスからもFX3の速度検証結果の公式なレポートが最近になって出ています。
サイプレスのアプリケーションノートAN86947 - Optimizing USB 3.0 Throughput with EZ-USB FX3 がそのレポートです。

このレポートには、下記の4つの転送速度の結果が記載されています。
1.アイソクロナス転送
2.バルク転送
3.インタラプト転送
4.GPIFUを用いたバルク転送

このうち今回の検証と関係するのは4番のGPIFUを用いたバルク転送で、レポートのP7〜8に結果が記載されています。
その結果をみると、394,000KB/s(=384MB/s)の転送レートが出るとレポートをしています。
そこで、SVI-06改ボードのFX3を使用してアプリケーションノートと同様の環境を再現し検証を行ったところ、レポートに近い転送レートまで出ることを確認しています。

<サイプレス社独自検証と弊社検証でのFX3ファームウェアの違い>
今回の弊社で使用したslfifosyncファームウェアと、サイプレス社独自検証用ファームウェアの大きな違いはGPIFUデザイナーを見るとわかります。


GPIF2比較.jpg

サイプレス社検証ファームウェアはFX3からApplication Processorに対してクロックを送出しているのに対して、slfifosyncはApplication ProcessorからFX3にクロックを送出しています。
アプリケーションノートのサンプルはFX3が理想的に動作できる状態での検証といえます。
つまり、アプリケーションノートの検証のほうがより高速転送がしやすいと思います。


次に、ボード全体のデータのフローについて違いを説明します。
弊社検証でのボードのデータの流れを下図に示します。


SVI-06簡易ブロック図.jpg


今回の弊社の検証では、ピンヘッダからイメージセンサと同等のデータを受けてFPGAに取り込みます。
取り込んだデータは先程説明した通りヘッダ付加等の処理を行いDDR2 SDRAMに格納されます。
格納されたデータはFPGAがフロー制御を行いながらFX3へと渡されます。

一方、アプリケーションノートでのデータの流れは下図となります。


AN86947簡易ブロック図.jpg


このアプリケーションノートの検証の場合は、弊社検証ではFPGAが行っていたフロー制御を行なっていません
そのため、FX3はターゲットからのデータの取りこぼしが無いものと想定して動作しています(取りこぼしたかどうか誰もわからないし、知る由もない状態ともいえます)。
このような処理がないため、FX3動作は転送レートを求める上では都合のよい仕組みで動作していると考えることができます。
ゆえに、GPIFUを通して取り込んだ時のFX3の最大転送レートを求めることが可能となっていると考えられます。

しかし、アプリケーションノートの仕組みを現実的なシステムに活用できるかというと、このアプリケーションノートの仕組みでは現実的なシステムを作る際には問題が発生します。
それは、まったくフロー制御が行われていないため、ボード上でデータの管理が行えないという問題です。
そのため、現実のシステムとしては活用しにくいと考えられます。
つまり、弊社検証では実用的なシステム構成での転送レート検証であり、アプリケーションノートはFX3にとっての理想的な動作環境での転送レート検証といえます。
そのため、弊社が行った今回の検証のほうがより現実的なシステムであり、かつフロー制御も行われているため、速度検証としてはハードルが高くなっているといえます

次回以降では、この違いを前提として転送レートの検証の結果等を紹介します。
posted by デベマネ at 10:59| Comment(0) | EZ-USB/FX3

2013年10月24日

FX3の高速化検証1 〜FX3の最高峰に挑む〜

ネットビジョンでは、2011年11月からEZ-USBレジスタードマーク FX3(以降、「FX3」といいます。)を使用したイメージキャプチャーボードSVI-06の製造・販売をしております。その後、UVC版であるSVI-05の開発により、FX3を高速に駆動させるノウハウが着実に蓄積されてきました。

一方FX3チップはリープモーションに採用されるなど、国内、国外問わず活用が進んできているUSB3.0用のチップになります。

しかし、高性能なチップではあると思いますが、最高に近いスペックを引き出すためのノウハウが共有されていないため、国内での爆発的な普及には至っていないのではと考えています。

そこで、弊社にて行ったハードウェアからPCアプリケーションまでの高速化の道のりについて紹介してみたいと思います。

<検証システム全体像>

はじめに今回検証をおこなったシステムの全体像を説明します。


システム全体像.jpg



ハードウェアとしてCypress社(以下、「サイプレス」といいます。)から発売されているEZ-USB FX3を搭載した弊社開発ボードSVI-06をベースとして高速化のための改造を行ったもの(以下「SVI-06改ボード」といいます。)を使用しています(上段のボード)。

SVI-06改ボードにはFPGA(Spartan6)が搭載されておりピンヘッダからの信号やPCからの制御に対する処理などを行います。SVI-06改ボードとイメージセンサなどのデバイスとの接続はピンヘッダにより行います。

なお、この検証システムでは、SVI-06改ボードのピンヘッダへのデータ信号を供給するには下段にあるエミュレーションボードから行っています。このエミュレーションボードは弊社製品であるSVO-02を用いており、データ信号はイメージセンサーと同様にエミュレーションを行っています。SVI-06改ボードへは16GBのインクリメントデータを供給しています。

SVI-06改ボードは、USB3.0ペリフェラル・コントローラとしてFX3を使用することで、PCと接続されています。
PC側には、USBからの情報を取得するためのカスタムドライバーおよびアプリケーションが動作しています。
PCのOSはwindows8 64bit版となっています。
ブロック図にすると下記になります。(赤点線はデータの流れを表します。)


全体ブロック図.jpg
※xHC:ホストコントローラ



<FPGAについて>

今回検証に用いたSVI-06改ボードのFPGAの機能としては大きく分けて3つあります。
1.フレーム化(FullHDサイズにフレーム分けを行う)
2.情報ヘッダの付加
3.ボード全体のフロー制御

フレーム化とは、ピンヘッダからFPGAに入ってくるデータを解析し、FullHDサイズのフレームに分割してDDR2 SDRAMに保存を行います。
具体的には、下段のエミュレーションボード(SVO-02)からイメージセンサ出力と同等のデータを送出しているため、FPGA内部において、ブランキングエリアの信号を解析して画像サイズを自動判別し、画像エリアのデータのみをフレーム単位に分割してDDR2 SDRAMに保存を行っています。

分割した各フレームには、フレームのサイズなどのフレーム情報等をホストへ通知するためのヘッダを付加します。なお、DDR2はダブルバッファとして使用しており、その制御もFPGAが行っています。
また、高速にかつ安定して駆動させるためFPGAがFX3チップを含むSVI-06ボード全体のフロー制御を行っています。このアーキテクチャーの採用により現在弊社で発売しているSVI-06よりもさらに高速に駆動することができます。

なお、今回の検証で高速化処理を支えているのがFPGAであり、弊社独自の技術によるものです。この内容については公開したいところではあるのですが、独自技術でありブログで詳細を説明することはできないみたいです。すいません。自社のFPGAに活用したいなどの話があれば個別にお問い合わせください。


SVI-06改説明.jpg



<FX3について>

FX3のファームウェアはEZ-USB FX3 SDKに同梱されている「slfifosync」を修正して使用しています。(格納先:EZ-USB FX3 SDK\1.2\firmware\slavefifo_examples\slfifosync)
ただし、修正といってもエンドポイントの設定やDMAのバッファサイズ等コンフィグレーションの変数を変更しているだけになります。ほぼSDKサンプルそのままと考えてもよいと思います。

<PC環境について>

Windows PC側については、OSはWindows8 64bitを使用しドライバーおよびAPIは下記の組み合わせにより実験を行いました。
1.ユーザーモードドライバ + SVI-06用API
2.カーネルモードドライバ + SVI-06用API
3.サイプレスドライバ(カーネルモード) + サイプレス提供API

今回の検証で使用した、1,2のドライバーについてはマイクロソフトから提供されているリファレンスをそのまま利用したものと考えてください。

PC側の送受信アプリケーションはUSB3.0のデータを取得するためだけの機能を持ったコンソールアプリケーションを用いました。FX3との転送レート計測の検証のため、送受信コスト以外にはほぼコストがかからないアプリケーションとなっています。

下図が今回の検証環境の全体概要になります。


各部の役割.jpg



<各部での転送レート計測結果>

最高速が出るようにチューニングを行った結果、各部分での転送レートは下図のようになりました。


計測結果.jpg



USBのバルクイン転送にて、ボードからPCへ16GBのデータを転送し、送信開始から受信終了までの時間から転送レートを求めています。結果として、FX3〜PC上のコンソールアプリまでの転送レートは平均340MB/sになりました。
なお、今回の検証では詳細をふれませんが、FPGA〜FX3のGPIFUインターフェイスへは平均380MB/sにてデータ転送を行っています。

<検証PCスペック>

今回、転送レート検証に使用しているPCのスペックは下記となります。

PC:NEC LaVie Z LZ750/LS
OS:Windows8 64bit
チップセット:モバイル インテル UM77 Express
CPU:Core i7-3537U@2.00GHz メモリー:4.00GB
ドライブ(SSD):TOSHIBA THNSNF256GMCS

長かったですが、システム全体像から検証結果までを説明しました。次回以降部分に絞ってチューニングで行ったことなどを説明していきます。
posted by デベマネ at 18:05| Comment(0) | EZ-USB/FX3

2013年10月22日

EZ-USB FX3の高速化検証 〜予告編〜

2011年末から開発者ブログでは機会があるごとにEZ-USB FX3(以下「FX3」といいます。)の話題を取り上げてきました。最近は1年ほど前の記事の更新を最後に沈黙し続けてきました。

その間、国内でのFX3の普及率はどれほどかわかりませんが、今年に入ってからLeap Motion ControllerにFX3が使用されたりとUSB3.0用のチップとして使用されてくるようになりました。さらには、HPからLeap Motion内臓のノートPCまで発表されました。

また、Cypress社からも転送レートの最適化を検証したアプリケーションノートAN86947 - Optimizing USB 3.0 Throughput with EZ-USB FX3 が発表されるなどFX3の普及が進んできているのではないかと感じております。

そこで、アプリケーションノートAN86947やFPGAマガジンNo.2等をリファレンスしつつ弊社で独自に検証した転送レートに関するレポートを数回に分けてブログで発表します。

なお、弊社の検証のポイントは、FX3〜PCへのデータ保存までをトータルに検証し転送レートを算出しているところにあります。

次回以降の内容は次のようなものを予定しています。

1.FX3高速検証の全体像の紹介と、FX3〜PC保存を含めた転送レート(334.4MB/sを達成!)紹介
2.プリケーションノートAN86947と弊社検証の違い
3.FX3〜PC転送までの論理的な速度考察
4.高速転送を実現するFX3ファームウェアでの対応実例
5.高速転送を実現するPC側での対応実例
6.Streamアプリケーションの内部構造簡易解剖
7.データをPCに保存する

週2回のペースで更新をと考えております。
記事に対する質問や励ましのコメントなどはコメント欄に記載いただければ筆者の励みになります。なお、いただいた質問についてはご回答できる範囲で誠実に対応できればと思います。
posted by デベマネ at 11:12| Comment(1) | EZ-USB/FX3

2013年10月10日

ハードウェア技術者を募集しております

お知らせです。

現在ネットビジョンではハードウェア技術者を募集しております。

弊社少人数ですので、ハードウェア製作のすべての工程を担当することができます。

ご興味ある方はこちらの採用情報をご覧ください。

気になるので詳細をですとか、すぐじゃないけど話だけ聞いてみたいなどでもOKです!
是非お気軽にお問い合わせください。
posted by デベマネ at 18:42| Comment(0) | おしらせ

使ってみてわかった! クラウドワークスでのお仕事

今回はクラウドワークスでロゴを募集して分かったクリエイターの行動や閲覧数や提出件数の推移等を開発者ブログ番外編としてご紹介します。


ネットビジョンは純粋な組み込み系の開発会社です。そのため、デザイナーという職種の人は社内にはおりません。そんな会社でも、会社のロゴを今のよりもデザイン性のあるものに作り直したいという話になりました。

そこで、「社内にいないのなら社外から募集してみればいい!」ということになり、クラウドワークスというクラウドソーシングサービスを利用してみることにしました。

※クラウドソーシングとはWikipediaによると、「不特定多数の人に業務を委託するという新しい雇用形態。ウェブサービスのトレンドの一つでもある。群衆(crowd)と業務委託(sourcing)を組み合わせた造語。」とのこと。


さて、クラウドワークスでの仕事の登録や募集の仕方等は、クラウドワークスを見たり、nanapiサイトに解説があったりしますのでそちらをご覧ください。

開発者ブログでは、ネットビジョンのロゴ募集においてどのような推移で閲覧やロゴの提案がなされたか、データとともに考察してみたいと思います。

※毎日決まった時間にデータを取得していたわけではないので取得の時間差により多少の増減はあるかと思いますがご容赦ください。
※土日や一部取得していない日については、前後の数から均等割りにより数を推定しています。


まずは、閲覧数(累積)のデータです。ロゴの募集期間は2週間(9/25〜10/9)でした。

閲覧数.png

グラフから登録開始当日は閲覧数が多いことがわかります。ただ、当初の勢いは2日目に失速し閲覧者数は減少しています。3日目以降は日々の閲覧数はほぼ横ばいの状態が続きます。

ではなぜ、登録日当日は閲覧数が伸びたのかを振り返ってみたい。登録日当日ということで、お仕事リストの最初のページに出ていたため目につきやすかったということが考えられます。しかし、それ以外にも多くの人に見て欲しいという思いもあり、弊社のツイッタでの告知や、クラウドワークスのサイトにある「見てみて」ボタンを活用して多くのデザイナーの方にこちらから登録情報をプッシュ通知して、デザイナーの方に認知してもらう活動を行いました。この活動が功を奏して当日の閲覧数の伸びにつながったと思います。

この「見てみて」ボタンは2日目までは積極的に押していました。しかし、あることに気が付き3日目以降押しにくくなりました。あることとは、一度「みてみて」ボタンを押した人であっても、時間を置いたりすると何回も「見てみて」ボタンが押せてしまうのです。何回も押せてしまうということは、相手にはその分メールがいっぱい届いてしまうのでは?と考え、スパムメールのような状態になることを危惧して押すのをやめました。

10/2〜3にかけて閲覧数が急増しておりますが、これは10/2に行ったツイートのリツイートが多く(といっても3件でしたが・・・)の人からあったからだと思います。
結果として2週間で1600回以上も閲覧していただけました。クラウドワークスで活動するデザイナーの方は多くおり、活動も活発だということがわかります。つまり、デザイナーの方には有効なサービスとして認知されており、クラウドワークスでロゴ募集を行うことは効率的なのではなないかと推測できます。

さて、次に気になるリストの登録者数(累積)の推移です。

気になるリスト数.png

2日目までの登録が半数を占めるという結果になっています。
このことから、登録当初のうちに、デザイナーの方々の目にとまりかつ、その仕事の内容が気に入ってもらえるか、気にしてもらえるかという勝負ではないかと考えられます。つまりは、登録内容をどう書くかの勝負とも言えます。まずはデザイナーの方がイメージしやすい内容を詳細に記載することがよいのではないかと思います。(クラウドワークスのサポートの方もそのようにおっしゃっておりました。)

また、1週間目までにある程度気になるリストの人数を増やしておかないと、提出件数に大きく影響がでる感じがします。その理由としては、締め切りが近づけば近づくほど気になるリストに登録する人が少なくなっており、ロゴ制作してもいいよという人がどんどん少なくなっていくことになるからです。だから、スタートダッシュが重要なのではないかということです。
しかし、お仕事の登録初日に気になるリストに登録する人が多いのは少し驚きました。今回だけの傾向かもしれませんが、もう少し平均的になるのかと予想しておりました。

最後に、提案件数と提案人数の推移です。提案件数についてはリテイクの件数も含みますがそれほど多くはありません。

提出数.png

初日から数件の提案があり、1日目から7日目まではほぼコンスタントに提案があるような状態です。後半の1週間は締め切りに近づくほど提案件数が多くなってきます。
また、提案人数に比べて提案件数の伸びが大きく、1人の人が複数の提案を行っていることがわかります。またこの複数提案も7日目以降に増えていく傾向があります。

締め切りの2日前に提出件数が急増し、締め切り当日を迎えるという傾向を示しています。想定するにこれは、2日前に提出した提案を確認し、翌日(最終日)にリテイク対応ができる時間を確保しているのではないでしょうか。そうであれば、なかなかクラウドでの働き方が浸透してきているとも考えられます。そうであれば新たな働き方を確立しつつある、すごいですねクラウドワークス!!

これらのデータから個人的に想像できるクリエイターの仕事の流れとしては、
1. 登録日が近い案件を確認し気になるものを、気になるリストに登録。
2. 案件の内容を踏まえて、提出物を検討。
3. 締め切り2日前をめどに提出
といったことではないでしょうか。この傾向をもとに登録する人はいろいろとクリエイターとやり取りするとスムーズなのかなと思いました。

ということで、開発者ブログということもあり、簡単なデータからクラウドワークスでの働き方や募集の仕方を解析してみました。
次回もロゴの提案を予定しております。またデータを取ることがあれば紹介してみたいです。
posted by デベマネ at 13:34| Comment(0) | 日記