アプリ版:「スタンプのみでお礼する」機能のリリースについて

いつもお世話になります。
コンピュータの技術者の方にお伺いします。
最近のスパコンはマイコンを幾つも搭載したりしてますよね!
前々から思っていたのですが
最近のマイコンの進化にはびっくりしますがマルチコアとかマルチスレッドに走っている一つの要因は電気の伝搬速度がそろそろ限界にきているからだと私は思っています。

1GHzでわずか約30cmの電気信号の伝搬速度で2GHzになればその半分ですよね!
正直、15cmのパターン引き回し何てざらですよね!

そう言う意味で高クロック化はそろそろ限界でマルチ化が進んだ。
また、電気伝搬速度的な制約があるために周辺機器に合わせるためにクロックを変化させたりしているように思います。

私のそういうマイコンの進化の認識って合っていますか?
私は若い時、クロックがMHz時代のマイコン(68系・8bitsですが)は勉強したことがあります。
向学のため、宜しくご教授ください。

A 回答 (17件中1~10件)

もともと一本のパイプラインで処理していたがそこからさらに並列性を上げようとして90年代に流行ったのがスーパースカラです。

スーパースカラではパイプラインを複数持たせることにより並列性をあげて性能を上げてきたのですが、この並列性にも限界がありました。性能シミュレーションでは4命令から6命令程度の同時実行であればかける物量に見合うだけの性能向上があるが、それ以上の並列性を持たせても性能向上がほとんどなくなることがわかっていたので、そこでスーパースカラによる並列実行の限界があったわけです。で、そこからさらに並列性を上げようとして出てきたのが、マルチコアとマルチスレッドです。高クロック化と時期的に重なっているので、高クロック化の限界がマルチ化を生んだように見えますが、スーパスカラからマルチコア、マルチスレッドへの移行は並列実行の進化としてはごく自然な流れであまりクロック周波数の限界とは関係ないでしょう。それよりも半導体プロセスが進んでトランジスタサイズが小さくなり、より多くの論理をチップ上に詰め込めるようになったことが最大の理由です。実際マルチスレッドは90年代の後半くらいに話はありましたが、当時の半導体プロセスではそれだけの論理を詰め込めなかったので実現されていなかっただけです。
こういう話はマルチスレッド、マルチコアにかかわらず常にあります。
80年代にはMPUにはキャッシュやTLBなどは量的な制限のため搭載できませんでした。やがてトランジスタが小さくなり、キャッシュやTLBが載るようになり、演算器の数を増やしてスーパースカラにし、Out of orderや投機実行をするための論理も1チップ上に載せることができるようになったわけです。マルチスレッドなどもその延長で、結局は半導体プロセスの進化に強く依存しています。

まあクロック周波数が限界にきているのはその通りだと思いますが、ふつうはラッチ間の距離はゲートを含めてせいぜい数ミリだし、タイムボローイングのようなこともしているので、伝搬距離は最大の要因ではないのではないかと思ういます。それよりもクロックの制御が難しいからでしょうね。3GHzだと333psの周期で、こんなチップを正常に動作させようとすると、全プロセスコーナで思った通りの動作するきわめて性能のいいPLLとスキューの小さいクロックツリーが必要で、設計はかなり難しいと思います。

クロック周波数を変化させるのはマイクロプロセッサの場合は電力消費を抑えるためです。

この回答への補足

皆さま、親身な回答を賜りこの場を借りて回答者皆さまにあらためて御礼申し上げます。

一番最初により知りたかった回答を纏めてくださったこの回答をベストアンサーとさせていただきます。
正直、一人しか選べず心苦しいですが申し訳ありません。

改めて、皆さま有難うございました。

補足日時:2014/08/04 18:28
    • good
    • 0
この回答へのお礼

ご回答、有難うございます。

一番知りたかった事をより分かり易く回答頂けた気がします。

>それよりも半導体プロセスが進んでトランジスタサイズが小さくなり、より多くの論理をチップ上に詰め込めるようになったことが最大の理由です。

これが答えでしょうか?
確かに電気信号の伝搬速度は媒体を考慮してもチップレベルで気にするには一桁クロックが違うようです。
ナノテク化された集積により、ちょっとしたチップ上の引き回しでもL化したりC化したりして波形がなまったり、信号が干渉する方が問題な気がします。

そう言う認識でよろしいでしょうか?
大変詳細な解説有難うございました。

お礼日時:2014/07/31 19:49

》最終的にはハードウェア的な確認が必要に思います。


これはもちろんそうですが、現実的にチップ内部のノイズを調べることは不可能に近いです。場合によってはあるパターンのデータを走らせてその結果がどうなるか調べることによってどのネットにノイズがのっているか推定することができることもありますが、あくまでも推定でしかありません。なによりもそういう解析ができる場合は極めて稀で、現実にはチップ内部でノイズが乗って誤動作したらノイズの乗った場所の特定はできないと考えたほうがいいでしょう。ですから、テープアウトをする前にソフトウェアで解析をしてできるだけマージンを持たせるような設計をします。

》参考になるサイトURLや話せる範囲で結構です。教えて頂ければ勉強になります。
私はチップを設計をする立場で、どちらかというとCADを使う側のため、CADの具体的な中身については詳しくありませんが、大まかな考え方としてはこういうことです。
まず、信号の遅延解析をするためのソフトウェアがあります。これはラッチ間の信号がクロック周期内に伝搬しきれるか調べるもので、ゲート遅延と配線遅延を計算します(当然配線の容量や抵抗などは計算に含まれます)。ゲート遅延は、使用されるゲートすべてをあらかじめ回路シミュレーションで調べておいて、X軸が入力信号の立ち上がり立下り時間、Y軸が出力の負荷、Z軸をゲートの遅延時間としてテーブルとしてライブラリーに記述しておき、遅延解析ソフトを走らせたときにこのテーブルを参照することによりチップ内の各ゲートの遅延時間を調べられます。配線遅延は、厳密に微分方程式を解いたりするのではあまりにも時間がかかりすぎるので、エルモア(今はもう少し精度のいい計算方法があるのかもしれません)のような簡易的な計算方法を用います(リンクの13ページ目)。
http://www.ieee-jp.org/section/kansai/chapter/ss …

信号の遅延がわかれば、チップ上の全配線上の各点がどのタイミングで変化するかわかります。これに加えて隣接するすべての配線間のカップリング容量も配線の長さからわかるので、隣接する配線間のクロストークを調べて、その結果どの程度信号が早まるかあるいは遅くなるか調べられます。

遅延解析とノイズ解析は密接にかかわりあっているので、普通は信号遅延を解析するソフト(シノプシスのPrimeTimeやケイデンスのETSなどが有名)にはクロストークを解析するためのオプションがついています。
    • good
    • 0
この回答へのお礼

少し、お礼が遅れて済みません。

大変、貴重な回答を賜り有りがたく存じます。
解析の手法など勉強になりました。
nm単位なのでハード的にマニピュレータと言う訳にも行きませんね!
そのものにもL分、C分を含むでしょうし…
最近の開発技術に文章だけでも触れる事が出来て個人的にとても勉強になりました。

心より、御礼申し上げます。

お礼日時:2014/08/04 18:15

> ケーブル的なシリアルデータの送受信の話なら理解できますが違う話であれば理解できますが、


> 単純に考えてデータバスに複数のデータは載せられないと思います。
なぜでしょう?
ただ、送信データが受信側に到達する前に、次の受信データが出てくると言うだけですよね?
この場合でも、
(ちゃんと設計すれば)別に順番が入れ替わったり混じり合ったりするわけじゃないので
受信側はデータを順次受け取れるのではないですか?

シリアル通信で理解できるならそれと同じだと思いますが、
どの部分が違うと思ったのでしょう?
もしかして、クロック方式に共通クロック方式を想定してますか?
高速インターフェースでは、普通は
ソース・シンクロナス方式かエンベディッド・クロック方式になりますよ。

共通クロック・インターフェイスの制約を学ぶ - MONOist(モノイスト)
http://monoist.atmarkit.co.jp/mn/articles/0901/0 …



> 後者はDMAなど一定時間、RAMにデータを書き込むのに1,0等の
> 混在はあり得るかもしれませんがその時間、他のデバイスはデータバスは使えませんよね!
共有バスにおいてバスが占有されている間に
他のデバイスがバスを使えないのは当たり前の話で、
バス上にデータが複数載っているかどうかは関係無いように思えます。

なお、高速なインターフェースになるほど共有バスは忌避されて
ポイントツーポイントになってきます。
双方向バスも高速になるほど使われなくなってますね。
    • good
    • 0
この回答へのお礼

回答有難うございます。

正直、共通クロック方式を描いていました。8bitのMPUを学んだ程度だったものでMPUだけでなく周辺デバイスにも色んな進化が有ったんですね!

>ソース・シンクロナス方式かエンベディッド・クロック方式になりますよ。

少し、理解するのにお時間を頂きました。
とても勉強になる情報有難うございました。
重ねて、お時間を割いて頂き有難うございました。

お礼日時:2014/08/02 17:21

> これが答えでしょうか?


ハイエンドマイクロプロセッサの設計では性能を出すためにできることは全てしますから、より多くのトランジスタを使えるのであれば、とにかくそれを活用する方法を考えます。先にもいいましたが、スーパースカラでは性能は頭打ちになると考えられていたので、それ以外の方法で並列実行を利用して性能を出すにはマルチスレッドとマルチコアが(大量のトランジスタを使えるのであれば)一番実現性のある選択肢だったということです。

> ナノテク化された集積により、ちょっとしたチップ上の引き回しでもL化したりC化したりして波形がなまったり、信号が干渉する方が問題な気がします。
もちろん集積度があがると信号間のノイズは問題になります。以前はノイズの解析などはしなかったのですが、今ではノイズ解析をせずにテープアウトをするというようなことは考えられません。そういった需要があれば供給もあるもので、現在は信号間ノイズによるスパイクや遅延時間への影響などを精度よく解析するための手法もよく研究されていて、そういうソフトウェアもあります。
    • good
    • 0
この回答へのお礼

何度も回答を頂き恐縮です。
更に興味深い回答有難うございます。

>そういった需要があれば供給もあるもので、現在は信号間ノイズによるスパイクや遅延時間への影響などを精度よく解析するための手法もよく研究されていて、そういうソフトウェアもあります。

ソフトウェアで解析するのですか?
電気の世界は比較的数学に載る学問なので可能だとは思います。
最終的にはハードウェア的な確認が必要に思います。
解析含めどうなっているのか長くなるかもしれませんし、社秘等にも触れるかもしれませんね!
参考になるサイトURLや話せる範囲で結構です。教えて頂ければ勉強になります。
回答有難うございました。

お礼日時:2014/08/02 18:14

>1/1MHz=1μS,1/2MHz=0.5μSでGHzでも良いのですが要するに1クロックの時間が違いますよね!


>1μSと0.5μSでは当然、到達距離が違うと言うのを言いたいだけなのですが…

分かりました。
1周期の時間は高集積化に直接影響するものではなく、周波数が高いこと自体が本当の問題です。

CPUをいくつも搭載するような場合に配線を長く引き回そうとする場合など、
配線のもつ寄生インダクタンスの影響が大きくなるからです。
ICチップを多層化(スタック)するような場合にも、チップ同士をワイヤボンディングで配線すると同じ問題が起こります。
これを回避するにはここの通信部分のみ周波数を落とさなければなりません。

また配線に90度に折れ曲がった部分があると、反射波が発生します。高周波にとって見ると、90度に折れ曲がった部分は配線の途切れた末端部分と同じだからです。これも設計上の制約となります。
プリント基板設計の際に”」”←このようなパターンを避け、必ず角に斜めのパターンを入れるのはそのためです。
    • good
    • 0
この回答へのお礼

何度もお時間を頂き恐縮です。

ワイヤボンディングはフリップ・チップ方式(フリップ・チップ・ボンディング)などでしない方向だと認識しています。
恐らく、ご指摘の様な要因があるのでしょう。

プリント基盤については一応、電子機器は扱っていたのでそう言う認識はあります。
アナログ回路などわざとぐちゃぐちゃに引きまわしたりするのも目にしました。
親身に回答を賜り有難うございました。

お礼日時:2014/08/02 18:02

えぇと, 一応確認させてください.



「単純に考えてデータバスに複数のデータは載せられないと思います」という文章における「データバス」というのは, どの部分のことでしょうか?
・プロセッサ内部のバスのこと?
・プロセッサと (プロセッサの外部にある) メモリとの間?
・その他の何か?
    • good
    • 0
この回答へのお礼

ご回答有難うございます。

>・プロセッサ内部のバスのこと?
>・プロセッサと (プロセッサの外部にある) メモリとの間?

後者です。前者は複数のデータが載ることは無いと思います。
8bits時代のMPUとガラエポ基盤を含めた動作をMPUのチップ内で実行しているのではないかと想像します。
後者はDMAなど一定時間、RAMにデータを書き込むのに1,0等の混在はあり得るかもしれませんがその時間、他のデバイスはデータバスは使えませんよね!
方向性が特定されているバス上で送、受のデバイスが特定されていればパターン長が同じなど条件を満たせば時間で切ってデータ送受信は可能だと思います。
この事を言われているのであれば納得できます。
もし、違う事を言われているのであれば教えてください。
認識的にこれであっていますか?

お礼日時:2014/08/01 12:26

> この辺の話でしょうか?


> ===【抜粋】
> マイコンの動作周波数を限界近くにまで高めようとすると、リーク電流が著しく増えてしまうことが問題を厄介にしている。
> ===
リーク電流はクロック周波数に依存しません。
クロックを止めたとしても(つまりクロック周波数0Hzでも)リーク電流は発生します。

では、なぜ動作周波数を高める話とリーク電流が絡むのかというと、
動作周波数を高くするためには高速な素子を使う必要があるからです。
(その理由は分かりますよね?
例えば、1GHzだと1ナノ秒以内に
フリップフロップ間の信号伝達を完了する必要があるので、
フリップフロップ間に置く論理回路は高速な素子で構成しなければ間に合いません。)
しかし、高速な素子はリーク電流が大きいため
リーク電流が問題となるということになります。

> 1GHzでわずか約30cmの電気信号の伝搬速度で2GHzになればその半分ですよね!
> 正直、15cmのパターン引き回し何てざらですよね!
回路設計としてはフリップフロップの間に何個の素子(論理ゲート)を
使えるかという問題になります。
例えば、1個の素子が100ピコ秒の遅延を持つなら、1GHzなら10段まで使えるとか。

使える素子数が少ないと複雑な回路はくめないので
ちゃんと1クロックに収まる回路規模を考えて
設計しないといけませんが、それは当然設計難易度が上がることを意味します。
ただ、プロセスが進めば素子の速度も上がるので、
その場合は同じような設計のままで高速化できたりすることはあります。

そうでなくても高速クロックは取り扱いが難しく
(分配時のスキュー制御、ジッタやクロストークの考慮など)、
消費電力にも響くので何が何でも高速クロック化すれば良いという物ではないです。
    • good
    • 0
この回答へのお礼

回答、有難うございます。

>クロックを止めたとしても(つまりクロック周波数0Hzでも)リーク電流は発生します。

リークそのものはクロックでは無く、素子数などに依存すると認識しています。
リークについて、漠然と、想像、認識していた部分を明確に説明頂き勉強になりました。

後半部分ですが1個のALU等の素子レベルまで考えれば遅延など何段とかその辺まで考慮しないといけないという事の考慮など重要な事が沢山ありました。

ところで、興味本位でお尋ねします。
社秘などに触れるといけないので回答出来ればでいいのですがジッタやクロストークなどチップレベルでどのように確認しているのでしょうか?
マニィピュレータなどではそれ自体に影響があるように思いますし、SEM系のEBテスタとかなのでしょうか?
もっと、私の知らない進歩的な技術でしょうか?

お礼日時:2014/08/02 17:50

No.8です。


こんばんは。

>λ=1/f…懐かしいです。でも周波数である以上逆数は時間(s)とも言えます。

すみません。訂正してお詫びします。
λ=1/fではなく、T=1/fでした。

短縮率を無視する場合、λ=c/fとなります。 (cは真空中の光速です)
逆数ではなくc/fの場合でした。

ところで、周波数の逆数は時間(T)ですが、これは1周期分の時間であり、信号の到達時間とは関係ありません。


例えば放送局から、1MHz、2MHzのそれぞれの周波数の電波で、同じ内容を同時に放送する場合を考えます。
周波数の逆数はそれぞれ、1周期あたり、100万分の1秒と、200万分の1秒で、2倍の差があります。
しかし、電波(配線の場合は電界のみ)の場合は、どちらも光速で受信機に届きます。

受信機に届く放送は、1MHzの放送より2MHzの放送のほうが早く到達する、ということはないですよね?

同じことが、電気信号にも言えます。
    • good
    • 0
この回答へのお礼

何度も済みません。

私こそ、間違えました済みません。
何せ、今現在では最先端の事はやってないので忘れている事もあって、お手を掛けてすみません。
水掛け論になってしまいしたが
1MHzと2MHzの電気信号が同じ時間で伝搬されると言う事に何の異論も唱えていません。
最初に訂正した通りです。
1/1MHz=1μS,1/2MHz=0.5μSでGHzでも良いのですが要するに1クロックの時間が違いますよね!
1μSと0.5μSでは当然、到達距離が違うと言うのを言いたいだけなのですが…

おっしゃりたい事は分かりました。
何度も有難うございました。

お礼日時:2014/07/31 21:26

>MPUのTjは100℃前後はざらですし発熱が問題なのは承知しています。



「リーク電流」については調べられましたか?
おそらく想像されている「発熱」とは異なると思いますよ(クロックを上げたら発熱するとかいう話ではないです)。
    • good
    • 0
この回答へのお礼

ご回答有難うございます。

>「リーク電流」については調べられましたか?

消費電力削減にも効果のある独自のマルチコア技術で
次世代情報家電が求める高性能化のニーズに応える
↓↓
http://japan.renesas.com/products/mpumcu/multi_c …

この辺の話でしょうか?
===【抜粋】
マイコンの動作周波数を限界近くにまで高めようとすると、リーク電流が著しく増えてしまうことが問題を厄介にしている。
===

一応、全部目を通しました。
動作周波数、クロックとリーク電流の関係を言ってられたのでしょうか?
あまり、気にしていませんでした。
押さえときたいポイントですね!大変参考になりました。
有難うございます。

お礼日時:2014/07/31 21:34

No.6です。



>私は若い時、クロックがMHz時代のマイコン(68系・8bitsですが)は勉強したことがあります。

懐かしいですね。
私も、同じ時期だと思いますが、高校の頃、Z80Aを使ったマイコン回路を自作していました。
やっていたことは、本当に自己満足レベルで、アマチュア無線機の音声出力をフィルタ回路を介して接続したマイコンボードでモールス解読などをしていました。
今はPICマイコンを使っています。当時と同じことを簡単にできるようになり便利になりましたね。


>1/1GHzと1/2GHzは同じ時間でしょうか?

周波数の逆数は時間ではなく波長です。もしその68系のマイコン回路やロジック回路を自作なさったことがあれば、ワンショットのパルスの伝送を考えてみると分かりやすいと思います。

ロジック回路間の信号伝送は主に矩形波ですが、例えば矩形波の立ち上がりエッジが受信側に到達するまでの時間は、1GHzでも2GHzでも変わりません。

問題は、波長ではなく、伝送距離が長いと同期のための待ち時間が生じてしまうという点と、発熱の問題です。

例えば、CPUが2つあって、片方の処理結果がでない限りもう片方が処理に入れない場合や
またはCPUがたくさんあって、全部の処理結果が出ないと次の処理に移れない場合などは、
それぞれの伝送距離が異なると、処理内容が平等でも、一番伝送距離の長いCPUの結果が出るまで待ちが発生します。

たとえCPUを一つのダイにまとめてしまうと、高集積化の限界が来ている以上CPUをたくさん接続したのと同じ問題が発生してしまうことになるでしょう。
でも、一番大きな問題は発熱だと思います。ただでさえ、巨大なヒートシンクや冷却ファンを付けないといけないのに…。

※なお、電子の移動速度は非常に遅く秒速数ミリ程度です。
    • good
    • 0
この回答へのお礼

何度も回答を賜り有りがたく存じます。
私は仕事上、6809の勉強をしました。
それで自分では組んだ事はありませんが基盤などは色々、よく目にしています。

私は50過ぎですが工業高校の電子科を出ています。
地方の工業高校で一応、電気、電子、建築科は進学校レベルの学力はあった学校です。

>ロジック回路間の信号伝送は主に矩形波ですが、例えば矩形波の立ち上がりエッジが受信側に到達するまでの時間は、1GHzでも2GHzでも変わりません。

λ=1/f…懐かしいです。でも周波数である以上逆数は時間(s)とも言えます。
ところで、それを踏まえて上記の所が理解できません。
前回回答を頂いた事を踏まえれば1GHzでも2GHzでも大差ない、MPUの内部のALU等のレベルで問題ない時間と言う意味でしょうか?
何度も回答を頂き大変恐縮なのですが教えて頂けますか?

お礼日時:2014/07/31 19:38

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!