忍者ブログ

Imager マニア

デジカメ / デジタルビデオカメラ / スマホ用の撮像素子(イメージセンサ/imager/CMOSセンサ)について、マニアな情報や私見を徒然なるままに述べるBlogです(^^;)

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

1.3億画素60fps(SHV用)センサの概要が来年ISSCCで発表 ~本年NHK技研で展示されていたものの発表で間違い無し。やはりForzaと共同でした

暫く前に、来年'15年2月のISSCC(←IEEE International Solid-State Circuits Conference。半導体業界のオリンピックと呼ばれる最も著名な国際会議の内のひとつ。論文採択率は例年1/3程度という狭き門)のプログラムが発表されました。
本年2月のISSCCのimager関係の報告内容(件数?)は低調ということであったのですが、来年のISSCCはその辺どうなのでしょうか?

 こちらのサイトでいくつかのimager案件の発表にも触れられていますが、日本からはimager案件で5件の論文が採択されたそうで、(日本に限らず)中でも注目なのは、NHK技研とForza Silicon(←US)の共同発表となっているものだとか。
 僭越ながら私個人の興味からも同意見でして、タイトルだけしか判断できる基準が無いのでなんなのですが(^^;)、タイトルだけで選ぶなら今のところ上記サイトの言う通り、NHK技研とForzaの発表に最も注目しています。

 かくしてその発表のタイトルとは・・・
133Mpixel 60fps CMOS Image Sensor with 32-Column Shared High-Speed Column-Parallel SAR ADCs
(邦題に無理矢理直すなら、”高速列並列逐次比較ADを32列で共有した1.3億画素60fps CMOSイメージセンサ”といったところでしょうか)

 こ、これは・・・!

拍手[5回]

もう間違いありません。その画素数とフレームレートの特異さからして、本年6月にNHK技研公開でお披露目されていて、しかしその詳細を全く教えてもらえなかった(--;)あのセンサについてに違いありません。
やはりNHKとForza Siliconとが共同研究・開発していたということで間違いなかったようです。

 また、この”映像信号ひたすら吐き出しお化け”的な(^^;)イメージャーについて、タイトルから間違いの無いことは、以下だと思われます。
・画素数:1.33億
・フレームレート:60fps
・オンチップADで、それが32列でshareされている
・そのADCの方式は逐次比較型(SAR)

 
元々NHK技研公開時にわかっていた画素数とフレームレートの組み合わせの特異さ(≒凄さ)を置いておくとすると、今回新たにわかる特徴はADが32列でシェアされているという点。

(ADの方式が逐次比較型という点も特徴と言えば特徴で、NHKは静岡大学と組む時は、高速ADにサイクリック型という方式を選択していました。
ただ、ForzaSiliconの方は以前からAptina共々この方式を採用していたという点において、違和感及び新規なイメージは無いという印象です)

 ん!?!?普通に考えたらADを複数列でシェアしちゃったら、むしろ読み出しスピード的には遅くなっちゃうんじゃ!?
(↑各列で占有できるADが個別にあった方が速いんじゃ!?)

 で、結局ISSCCはサンフランシスコまで渡航して出席しないと、その内容や発表内容のレジュメの様なものがもらえない仕組みであるため、来年二月の本番を待っても一般人には詳細な情報が残念ながら降りてこない(--;)ため、上記疑問は解決出来ない訳なのですが・・・
世の中には半年経つと一般人に情報が公開されるIISW (International Image Sensor Workshop)という奇特な(?)ワークショップが存在します。

 そして、上記”32列でshareするという点が今回新たにわかった”と私記載しましたが、実はIISWの2011年と13年のForzaSiliconの発表資料を眺めると、画素数とフレームレートを除けば、タイトルの内容とほぼドンピシャの内容のものが既にありました!

 ので、いつにも増して前振りが長くなりましたが(^^;)、今回は以下より上記IISWのForzaの発表内容を私のわかる範囲でご紹介したいと思います。
 恐らく、来年のISSCCで発表される内容は、このIISW2回の内容を足して、それに実際に試作した1.3億画素センサの特性値が追記されるような内容になるのではないかと予想します。


上記Forzaの発表は2011年と13年の二回に跨っています(←IISWは隔年開催で、現状西暦の奇数年に開催されています)。
一緒にまとめるのがしんどい為(^^;)、まずは2011年の方の概要から。

タイトル「Analysis of Front-end Multiplexing for Column Parallel Image Sensors」
 強引にまとめると”列間で信号をマルチプレクスしよう”というものの様です。

問題は、”何故マルチプレクス(して、列間でAD等を共有)したいのか?”(≒するメリットは何なのか?)なのですが、本件の要約(=abstruct)を読むと、

・センサの画素ピッチがシュリンクされ続けると、読み出し回路を1列ピッチに収めることが難しくなっていく
・上記に解決するための一つのアプローチとして、列アンプでゲインを掛けた後にそれぞれの列中のサンプルアンドホールド回路で信号をホールドし、その後順次画素信号をマルチプレクスして、複数列でシェアされたADCに入力するという方法がある
・上記方策を採るに際し、マルチプレクス(AD等の素子を共有)する列数を何列にするかによって、以下トレードオフの関係がある項目の特性値が異なってくる
 ①レイアウト面積
 ②バッファーノイズ
 ③消費電力
・上記3つの値が最適値となるマルチプレクス数(≒AD等を共有する列数)を求める

 で、後でもう少し詳述しますが、結果、”マルチプレクス(して、AD等を列間で共有)するメリットは、上記①と③を減らせるから”ということの様です。
↑マルチプレクス数を増やすと②は増加してしまうため、増やせば増やすほど良いという訳では無い

 まず①のレイアウト面積とマルチプレクス数の関係は最も単純で、以下の図がわかりやすいです。

↑一番左が、信号読み出しに必要な素子を全て1列に収めた場合のレイアウトイメージ
PGA:恐らくProgramable Gain Amp ←列で信号を増幅するためのアンプ

2p以降で、1列の際に出てこない”S/H Mux”と”Buffer”が登場するのは、複数列でADCを共有するために必要な回路群

 で、1列の狭いスペースにADCをレイアウトすると、当然縦に長いレイアウトになり、4列で1つのADを共有するレイアウトにすれば(例えS/H Mux”と”Buffer”という余計な?回路群が必要になったとしても)4列でひとつのADをレイアウトすれば良いため、センサトータルの面積は小さくすることが可能 という関係。
しかしあまりに多い列数でADCを共有するレイアウトの場合(=上図一番右)、ADC等をそんなに横に平べったくレイアウトすることも難しいため、共有する列数を増やした割には大してレイアウト効率は上がらないというニュアンスも含めた図面と思われます。

 で、以下は信じるしかないのですが、Forzaが立てたモデルにて検証した上記①~③の特性とマルチプレクスする列数の関係を示した図。

↑横軸Logスケールであることにご注意
※青:バッファーノイズ
 赤:レイアウト面積
 緑:(1列あたりの)消費電力
この時は、Forzaは最終的に横軸1.7の、ひとつのAD等を共有する列数を50としてチップ試作しています。


 ②のバッファーノイズに関してですが、まずそもそも”バッファー”って何のこと言ってるの?というところですが、順番が逆になりましたが、以下が関係箇所の等価回路図です。

↑左側が画素からの信号入力で、右がADCとRAMという図です。今回ノイズを気にしている”buffer”とは、この回路図のちょうど中央に位置するユニットになります。

列間で信号をマルチプレクスするということは、複数列の信号を順次読み出しする必要が出てくるため、一度”S/H stage”で画素からの信号電圧を再び容量に電荷信号で自分の列信号の読み出し順番になるまで保持し、自分の列の番になったらBufferで再び電圧信号にしてバッファリングしてADCに入力するためのユニットの様です。

 で、”バッファーノイズ”の考え方ですが、どうやらここでは、以下1)と2)二つの要素によりマルチプレクス数Mを増やすとノイズ増大を招くというものの様です。
(以下私の理解不足のため、誤った解釈をしている可能性が高いです。ご注意ください)

1)マルチプレクス数”M”を増やすと、バッファーはより高速で動作させる必要がある
(↑マルチプレクス数を増やすと、ひとつのバッファとADCで処理する列数が多い分、最終的なセンサの読み出し速度を同じに保つためには、処理速度を速めなければならないため)
 ⇒広帯域なバッファにする必要があり、高周波ノイズをより拾いやすい

2)マルチプレクス数”M”を増やすと、バッファ入力側につく、サンプル&ホールド回路のスイッチの寄生容量が増加し、Feedback Factorが落ちることによりノイズが増加する

 
で、どちらかというと発表資料の方はバッファーについてはノイズよりも、(バッファの)入力MOSサイズ(=W:width)とsettling time (←バッファ出力が所望の電位に落ち着くまでに要する時間。この時間が十分に無いと、画素信号値を正確に読めないため、結果としてノイジーなS/Nの低い出力しか出せないセンサになる)との関係を重視して記載されています。

↑右側の表に示す前提条件をあてがった場合に、左図は横軸入力バッファサイズ(恐らくW)と縦軸settling timeの関係
Cadc:ADの入力容量
Cfb:バッファ(=アンプ)のフィードバック容量
Cp:バッファ入力側のサンプルアンドホールド回路のスイッチの寄生容量
n:恐らく7.6τ(タウ)の意 ←時定数的に所望の電圧値まで残り0.05%ズレのところまで信号が収束すれば良しとするという前提か ←10bitADの場合問題無さそうですが、12bitADを考えると前提が微妙?

 上左図の概略のイメージとしては、流せる電流値が一定(≒消費電力が同じ前提)であった場合、Wを大きくすればgm(←バッファ入力MOSのゲート電圧変化量に対するそのMOSを流れる電流変化量)が大きくなる(←イメージ的には、入力変化に対する出力変化の応答速度が速くなる)ため、
横軸が右に行ってWが大きくなるほど、settlingに要する時間(縦軸の値)が小さくなるという関係になっています。
更に線が何本もあるのは、マルチプレクス数Mの違いで、マルチプレクス数が多いと、Cp(S/H回路のスイッチがバッファ入力側につく数が増えることによる寄生容量)が増加するため、Mの値が小さいのに対してはM数が大きいとsettling時間がそれだけ余計にかかる ということになっているようです。

そして、このWを増やすと、それだけレイアウト面積も増えるため、このMOSサイズも①のレイアウト面積には関係してくることになりそうです。


 最後の③の消費電力ですが、読む限りあまり触れられていないように感じます。
②のsettling time には密接な関係があるはずで、単純に流す電流を増やせればsettling timeはそれだけ速く出来るはずです。
が、当然その分(電源電圧が同じであれば、W=VIで消費電力は決まりますので)消費電力は増加します。
また、マルチプレクス数”M”との兼ね合いで言うと以下の様な関係に大雑把にはなるのだと思われます。
 Mを多くする:電力を食うバッファとADCの数は減るので消費電力は減る
        (が、その分高速でバッファ&AD変換しなければならないため、ひとつあたりのバッファとADCの電力は増える
 Mを少なくする:ひとつのバッファとADCは低速で動かしても良くなるため、一つあたりのバッファとADCの消費電力は減る
        (が、純粋にバッファとADCの数は増加するため、その分消費電力は増える)

 ですので、やはりマルチプレクス数Mと消費電力の間にもベストバランスなところがあるはずで、その結果が二つ目の図の緑のラインの様になるのでしょう。


 ひとまず長くなってしまったので、今週はIISW2011年までにして、2013年のは来週末にしようと思います(^^;)。
2011年のIISWでのForzaの発表資料でわかったことは、
信号読み出しに必要な回路を1列に押し込めてしまうのでは無く、(ISSCC2015では)32列で一つのADCをシェアして読み出すのは、
レイアウト面積 と 消費電力 を勘案してのことだと(ほぼ)わかりました。

しかしここまででは、32列でADをシェアしてしまっては、読み出しスピード的には苦しいのではないか?という私の疑問は解けていません。
正直2013年の発表資料を読んでも100%納得は出来ないのですが、この辺のことが2013年のものに少し書かれていたので、来週も恐らくこのネタを続行しようと思います。
PR

コメント

お名前
タイトル
文字色
メールアドレス
URL
コメント
パスワード Vodafone絵文字 i-mode絵文字 Ezweb絵文字

ブログ内検索

カウンター

最新コメント

[03/28 hoge]
[03/26 hi-low]
[03/22 山川]
[03/18 hoge]
[03/08 hi-low]
[03/04 hoge]
[02/26 山川]
[02/26 山川]
[02/19 hoge]
[02/18 山川]
[02/05 hoge]
[02/05 hi-low]
[01/29 通りすがりです]
[01/28 FT]
[01/23 hi-low]

カレンダー

10 2024/11 12
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

バーコード

プロフィール

HN:
imagerマニア
性別:
非公開