パスワードを忘れた? アカウント作成
5945 story

LSIのクロック調整で消費電力半減 29

ストーリー by Oliver
微細な世界はアナログ 部門より

jack_mexfer曰く、"産業技術総合研究所が,クロック調整による高速LSIの消費電力を半減させることに成功したとのことです.( プレスリリース) 遺伝的アルゴリズム(GA)を用いたクロック調整の実装と,その発想がなかなか面白いです.FAとかロボットに使えそうで期待してます."

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • なんでもかんでも産総研 (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2003年06月21日 17時07分 (#342530)
    おまえらいろいろ研究しすぎですよ、と。
  • by gonta (11642) on 2003年06月21日 23時18分 (#342714) 日記
    このような機能を実現するようなことってありませんでしたっけ?

    MacだとG3の電力消費機能であったと思いますし、
    IBM/PCでもノートPCで「CPU速度重視」か「バッテリの持ち重視」
    かを選択し、CPUの動作速度を調節できるのがあったと思います。

    パソコン屋なので、こういうことをすぐ思い付いてしまうの
    ですが、産総研が実現したのは別の話なのでしょうか?
    --
    -- gonta --
    "May Macintosh be with you"
    • Re:CPUで (スコア:2, 参考になる)

      by tt (2867) on 2003年06月21日 23時37分 (#342728) 日記
      出来ることと簡単なことは大きく違うのです。

      電圧を下げたてもちゃんと動くかどうか、というのを製造時のばらつきも含めて保証するのは難しいです。ちゃんと検査をした後の選別品を特別におろしてもらうとかすれば別ですが、高くつきます。

      今回の技術の肝は「その辺で買ってきたRAMチップをてきとーに組み合わせても、そのチップ用に最適な値にあわせた電圧などの組み合わせに自動的に調整します」というところではないかと。

      http://pc.watch.impress.co.jp/docs/2003/0619/epf01.htm の最後の方にある、「組み込みで多く使われるARMが何故動的クロックを実現できないか」という記述のあたりが参考になるかもしれません。

      --
      -- Takehiro TOMINAGA // may the source be with you!
      親コメント
      • チップでしょ? (スコア:2, 参考になる)

        by yanagi (6075) on 2003年06月22日 8時04分 (#342876) ホームページ 日記
        >今回の技術の肝は「その辺で買ってきたRAMチップをてきとーに
        >組み合わせても、そのチップ用に最適な値にあわせた電圧などの
        >組み合わせに自動的に調整します」というところではないかと。

        今回のクロック遅延素子ってのはLSIの中に内蔵のものでしょ?
        だからその辺のチップを適当に買ってきて...って話とは別でしょう。
        ただ動作クロックの違うLSIを複数組み合わせて動作させる
        時に同様の手法は使えると思いますが。
        --
        やなぎ
        字面じゃなく論旨を読もう。モデレートはそれからだ
        親コメント
        • by Anonymous Coward on 2003年06月22日 11時04分 (#342903)
          > ただ動作クロックの違うLSIを複数組み合わせて動作させる
          > 時に同様の手法は使えると思いますが。

          それはまさにこういうデバイス [idt.com]ですね。
          ただ、今回の技術では、駆動電圧を自動調整するというわけではないと思いますよ。
          単にグチャグチャとクロックラインに遅延付けてフリップフロップのセットアップマージンをできるだけ平均化(普通はクリティカルパスがあって、そこがセットアップマージンゼロとなる周波数が動作周波数上限)してあげる、と。
          そうすると、セットアップマージンが平均化されているので、駆動周波数の上限が上がる(ので、動作周波数未達で捨てるチップが減る)、あるいは電圧を下げて遅延が増えても大丈夫な方向にいく、ということでしょう。
          親コメント
      • by Anonymous Coward
        >、「組み込みで多く使われるARMが何故動的クロックを実現できないか」という記述のあたりが参考になるかもしれません。

        良くわかりませんでした。
        実際、ARMではありませんが、クロック固定仕様のCPUを動作時に可変可能にした事がありますので、
  • by Anonymous Coward on 2003年06月21日 17時21分 (#342536)
    DDR-SDRAMコントローラっていってもせいぜい5000~10000ゲート(nand換算)くらいのような気がする。この提案手法をプロセッサや大規模IPでやろうとしたらどうなるのかが知りたいぞ。
  • by Anonymous Coward on 2003年06月21日 19時24分 (#342604)
    GAを理解しないで書いてスンマセン. ただ,人手(with CAD)で作るのと,GAで解けるように問題設定してシミュレーションするのとでは,工程としてどちらがどういった点で有効なんでしょうか?
    • by Anonymous Coward on 2003年06月21日 19時53分 (#342613)
      直接の回答でなくてすみません。

      この開発のキモは、事前に周到な設計を行って生産をした場合、生産時のバラ付きによって設計通りの性能が出ない場合がある(歩留まりがあがらない)orオーバースペックになってしまうので、調整可能なようにしておいて、製造後調整する事によって歩留まりを上げようという事のようです。
      GAというのはあくまでも、その調整にGAを使うと大量の調整個所を素早く調整できるというだけみたい。

      LSIではなく電子機器の製造一般の話で言えば、昔はバラ付きが必ずあるのでトリマとか付けて調整するのがあたりまえでした。
      その後、製造コストを下げるために調整を最小限にして、一番のコスト要因である人手による調整を排除し(その分余裕のある設計にしておき)、製造コストを下げるという方向になって来ました。
      最近ではトリマなどのハードウェアによる調整ではなく、パラメータ調整などソフト的な解決方法により、調整を行うのが多くなってきています。

      この開発は、そのLSI版って所ですかね?
      クロックが上がる事によって設計時点での余裕を取りにくくなってきたので、その代りにLSIでも生産後調整ができるようにして歩留まりを上げようと、そういう事でしょう。

      電圧を下げて省電力云々という話は、電圧が低いほどバラ付きによる影響が出やすくなる=歩留まりが下がるので、より効果的というだけですね。
      タレ込みも勘違いしてるような気がしますが、これは「電力を下げるための開発ではありません」。
      (電圧を下げる場合の障害を軽減する事にも有用ですが、この技術を用いれば電力が減る訳ではない)

      しかし、この技術を用いる事による歩留まり向上と、この技術で使われる遅延回路(およびテスト用、設定用の回路)で増えるロジック(と、それに伴うチップ面積拡大)によって下がる歩留まり。どっちが大きいファクターになるんだろうか?

      親コメント
      • まぁ,電子機器でトリマコンデンサとかバリオームを排除するというのは,調整工数の問題だけではなく,信頼性向上という意味合いもあります. (調整工数というだけなら,トリマを自動的に回して調整点を追い詰めるという機器もあるようですし) これらの部品はどうしても振動や経年変化で調整点がずれてしまうものです. また,バリオームで摺動点が密閉されていないものの場合,耐塵性の問題とかも出てきます.

        あと,GA のあたりは,おそらくは「研究者の趣味」なんじゃないかな,と思います. brute force 的に順列組み合わせで全部をチェックすると爆発するような問題を,実用的な時間内で実用的な(最適とは限らない)解を如何に導き出すか. この問題の解決に GA を利用しているようです. まぁ,おそらくここらは「GA」とあるところを「ニューラルネット」とか書き換えても同じことはできるのではないかな,と思います.

        で,「順列組み合わせで爆発する」ような調整素子の数だから,きっと遅延回路の数も結構たくさんあるのではないかな,と思います. が,遅延回路自体はインバータの直列接続でも実現できるわけだし,ゲート規模としてはそれほど大きなものではないんじゃないかな,と思います.

        親コメント
        • by Anonymous Coward on 2003年06月21日 22時25分 (#342681)
          で,「順列組み合わせで爆発する」ような調整素子の数だから,きっと遅延回路の数も結構たくさんあるのではないかな,と思います.が,遅延回路自体はインバータの直列接続でも実現できるわけだし,ゲート規模としてはそれほど大きなものではないんじゃないかな,と思います.
          確かに遅延回路自体はインバータでもできますが、その遅延の有無や遅延時間をプログラマブルにしなきゃいけないですし、GA使った評価を行うのであれば不可逆な形(たとえばワンタイムみたいにヒューズを切るような実装)は取れませんから、再プログラミング可能で不揮発なメモリか何かが必要になってきます。
          そういう遅延回路を入れる相手がレジスタ程度の回路規模ですから、無視できるほど小さくはないと思います。
          親コメント
    • 速いチップを作ろうとすると、クロックツリー合成(CTS)ではダメだということなんだろうか?
      なんか、クロックのタイミングをフリップフロップ(FF)ごとにずらしてタイミング調整するなんてすごく違和感があります。
      まあ、FFのクロ
      • by Anonymous Coward on 2003年06月21日 23時33分 (#342726)
        > まあ、FFのクロックに遅延挿入できれば
        > 部分的なセットアップ不足には効き目がありそうな気がしますが・・・。

        まさにこれじゃないですか?
        CTSでは遅延がでかいパスに全体がひきずられて、
        高速化の足かせになってしまうような話は数年前からあります。
        そのころにはCTSの途中にバッファ挿入したり配線調整したりして、
        このような遅延調整したCTS(?)の生成を目指すベンチャーも出来てました。
        #ものになったという話は聞きませんが・・・

        多分現在でも、高性能なチップの設計ではなんらかの調整を考えたり
        実行したりしててるんじゃないですかね。
        #私はASIC屋なので、そんな調整してる暇はないですが。

        > 製造後のチップで調整しようなんてコストが合わないような気がする・・・。
        > (だいたい、どうやって測定するんだろう?)

        この辺がこの研究のもう一つのキモなんでしょうね。
        リンク先の真中から少し下を見ると、
        テスターと連携してやるようです。
        この辺の詳しいやり方を私も知りたい。

        遅延調整素子調整用の配線を埋め込まなければならないとしたら、
        配線性が悪化して製造期間増大→コスト増になる可能性が。
        親コメント
        • by redbrick (4865) on 2003年06月23日 3時17分 (#343326) 日記
          同じく、一応、ASIC屋です。

          >CTSでは遅延がでかいパスに全体がひきずられて、
          >高速化の足かせになってしまうような話は数年前からあります。

          CTSと言うよりデータラインの問題では?
          #データライン側が遅れてタイミングが合わないのは、CTSのせいでしょうか?
          #・・・違いますよね? ブロックの配置位置などの問題ではないですか?

          あと、CTS側で高速対応が出来ない、ってのはCTSの構成の調整で
          なんとかするしかない気がします。
          #論理合成側で遅いパスを高速部分から切り離すってのもアリ。
          #論理合成でなんとかなるんなら、製造後にいろいろいじる必要がなくて
          #コスト的に楽になるし。

          >そのころにはCTSの途中にバッファ挿入したり配線調整したりして、
          >このような遅延調整したCTS(?)の生成を目指すベンチャーも出来てました。

          こっちは寡聞にして知らないのですが・・・、chipやテクノロジの
          アーキテクチャ依存の部分が大きいので、ベンチャーは難しいでしょうね。

          一応、大手メーカーは配置に関し、TDLだのPhysical Synthesisなどと、
          CAD側での対策を考えているみたいですが、まだまだ十分なものとは言えない
          みたいですね。

          あとは、ちょっと発想を変えて、CTSは可変だけどその遅延が可変じゃ
          なかったり、なんてアプローチもあったりしますね。

          >多分現在でも、高性能なチップの設計ではなんらかの調整を考えたり
          >実行したりしててるんじゃないですかね。

          たぶん色々とノウハウはあるとは思います。
          わたしも、GHzなんて到底無理だけど、一応少しはノウハウを持っては
          いますけど、メシのタネなので、こんなところでは口に出せません。
          #まぁ、それにしても、クロックを局所的にいじるのは大胆な方策でしょう。
          #しかも製造後とは、周囲に与える影響がどのくらいになるか、コストが
          #どれだけ跳ね上がるか、きちんと試算しないとまずいでしょうね。

          >遅延調整素子調整用の配線を埋め込まなければならないとしたら、
          >配線性が悪化して製造期間増大→コスト増になる可能性が。

          んー・・・ちょっと言葉が違うと思います。
          「配線性が悪化して製造期間増大」→「配線性が悪化して設計期間増大」ですよね?

          製造はマスク露光なのでどうせ1shotですから、製造期間の長さに
          影響が出るようなヘンな回路だと、タイミングが満たせず、そもそも
          マスク作れないと思います。
          #コスト増は同感。

          >遅延調整素子調整用の配線を埋め込まなければならないとしたら

          クロック配線に自動的にフューズ付きみたいな経路切り替え可能な
          ブロックをぶら下げておくしかないでしょうね。
          ただし、調整範囲はやはり配線の長さ(=ブロックを置けるスペース)に
          依存するので、それで充分かどうかは、設計してもわからない。
          #作る製品ごとに変わる可能性があるものに対し、統一的に出来るもの
          #ではないと思います。

          どの程度の調整を考えるか、によって、製造後の微調整で救える数が
          決まるか、も、結局、ある程度の数を作って実測データを統計的処理して
          みた後じゃなきゃわからない・・・ですよね?

          #クロックだから周囲や自身へのクロストークも怖いし、余分なブロックのせいで
          #配線負荷も、制御信号のために配線数自体も増えるし、それに
          #ブロック配置領域まで圧迫するわけですな(汗)。
          #ちょっと、CADや設計側への負担が大きいなぁ・・・。
          --
          ---- redbrick
          親コメント
          • >>CTSでは遅延がでかいパスに全体がひきずられて、
            >>高速化の足かせになってしまうような話は数年前からあります。
            > CTSと言うよりデータラインの問題では?
            > (以下略)

            そうですよ。
            データラインの遅れのせいで、Clockを高速化出来ない。
            CTSでは、そのCTSにぶら下がっているFF/Latch全体に
            同時にClock信号が到達することを前提にしています。
            周波数をその遅れがあるパスにあわせることで、
            そのCTSに繋がる部分全てに影響しますよね。
            なので、遅れが生じるパスに部分的に遅延を挿入することで
            それを制御しようという考えが出るのは自然だと思います。
            • >データラインの遅れのせいで、Clockを高速化出来ない。

              ですよね。

              >CTSでは、そのCTSにぶら下がっているFF/Latch全体に
              >同時にClock信号が到達することを前提にしています。

              まぁ、多少のずれはありますが、それなりに高精度に、各F/Fや
              Latchにクロックが伝播するようにCTSを作りますよね。

              >周波数をその遅れがあるパスにあわせることで、
              >そのCTSに繋がる部分全てに影響しますよね。

              んー・・・わたしがそうする場合は、データラインに改良の余地がない
              場合のみ、ですね。
              クロックより修正しにくいデータラインって、あんまりないですし。

              >なので、遅れが生じるパスに部分的に遅延を挿入することで
              >それを制御しようという考えが出るのは自然だと思います。

              いやぁ、それは同期回路とは違ってしまうので、非同期回路を完全に
              検証漏れがないように検証できる方だけがやってください(苦笑)。
              #わたしには到底出来ないです(汗)。

              >まぁ、ようはユーザーへの納入が遅れるってことで

              それは、わたしも避けたいですね・・・(汗)。
              #今は、早くできないとASICも売れない時代だしなぁ・・・。

              >やるなら、制御素子を埋め込んだFF/latchを作成して、
              >一つのブロックとして扱うのではないでしょうか。

              そういうのもありですねぇ。

              >ていうかそうしないと上記の問題に対処できんと思います。
              >それでもブロックが大きくなって配置に影響出そうですが。

              確かに・・・。

              >そういう意味でもっと詳しいレポートを見たいですね。

              同感です。
              コスト面などに関する続報などが出たら、興味深いですね。
              #ちょっとウオッチングしておこうっと。
              --
              ---- redbrick
              親コメント
      • by Anonymous Coward on 2003年06月21日 23時59分 (#342737)
        >速いチップを作ろうとすると、クロックツリー合成(CTS)ではダメだということなんだろうか?

        設計というのは実物をモデル化して行うものですが、実際にできたものにはバラ付きが発生してモデル通りには動きません。
        通常はバラ付きが出ても大丈夫なだけの余裕を持った設計をするか、不良品の山を築くかのどちらかです。
        で、製造後に調整する事ができれば、その不良品の山の一部は良品として出荷できるじゃないかというのがこの技術でしょう。

        ですから、これは設計技法ではありません
        (もちろん、これを使えるような設計はしなくてはいけませんが)

        親コメント
      • >速いチップを作ろうとすると、クロックツリー合成(CTS)ではダメだ
        >ということなんだろうか?

        単純に、アプローチする観点が違うって事じゃないかと思います。
        #CTSで解決するかもしれないけど、こういう手法もあるよ、って事かと。

        まぁ、ASIC屋の立場からすると、

        >クロックのタイミングをフリップフロップ(FF)ごとにずらして
        >タイミング調整するなんてすごく違和感があります。

        ってところで、「はっきり言って使えないなぁ」と言うしかないですけどね。
        #理屈はそんなに筋が悪くないとは思うけど、なんか視点が数年くらい
        #古い気がするし。
        #セットアップエラーの対策でクロックラインを遅らせるって事は
        #クロックに対してのクロストークの影響とかが、部分的に狂うって事で、
        #同期設計の製品ではシステムレベルで製造後の調整で全く違う影響、
        #エラーが発見されかねず、はっきり言って危なくて使えない技術ですね。

        >FFのクロックに遅延挿入できれば部分的なセットアップ不足には
        >効き目がありそうな気が

        製造後は無理だけど、設計中はそんな程度のパッチワークみたいな
        対症療法的な手法は全然可能ですけど、システムとしての動作に支障を
        きたさないか、検証が大変なだけであんまり意味がないので、普通は
        やらないですね。

        #遅らせてセットアップエラーを回避したクロックの次段で、遅らせてない
        #クロックでF/F叩いてデータ取りこんだら、マージン足りないよな気が。
        #それでなくても、クロックの位相がずれるから、同じクロックの根元から
        #分岐してるのに、異クロックとして扱わなければならない、なんて
        #事にもなりそうだし・・・。
        #あと、製造後、ってのがちょっとイヤだなぁ・・・。
        #条件の違う1chip毎に、ずらした状況で全F/Fのタイミングの再検証するの?
        #しないんなら使えないよ、これ・・・(汗)。
        --
        ---- redbrick
        親コメント
        • >>FFのクロックに遅延挿入できれば部分的なセットアップ不足には
          >>効き目がありそうな気が
          >
          >製造後は無理だけど、設計中はそんな程度のパッチワークみたいな
          >対症療法的な手法は全然可能ですけど、システムとしての動作に支障を
          >きたさないか、検証が大変なだけであんまり意味がないので、普通は
          >やらないですね。

          普通はやらないけど、ASIC屋さんのお客の立場から言うと、スケジュール的に厳しいときにはやってしまい
          • >ASIC屋さんのお客の立場から言うと、スケジュール的に
            >厳しいときにはやってしまいたくなる技のような

            クロックを局所的にずらした状況で、製品の信頼性や機能の妥当な
            検証作業が、すぐに終わるなら、誰も反対しやしないと思うのです
            けど・・・。

            >そんなパスは早く見つかるだろうから普通は優先パス(だっけ?)指定して
            >とっとと再レイアウト

            そうですね、それが普通の対処だと思います。

            >#ピンの同時変化制限対策には使えないかな

            外部端子の出力ピンでなら可能性は皆無ではないと思いますが・・・
            かなり難しそうな気が。
            #出力の波形を同時動作対策としてラインごとにずらしても、お客さんが
            #満足してくれるか?ってのもあるので、ASIC屋としては提案しにくいですし。
            #パッケージに出たら、パラメータが数桁変わるから、なかなか
            #chip内だけで閉じた検証のようにはいかないしなぁ・・・。
            --
            ---- redbrick
            親コメント
      • クロック遅延が微妙に問題になるようなら、ラッチの段数を増やせば
        よいような気がするが、
        プロセス歩留まりは判るけどなんか設計配慮不足で、単に設計段階で歩留まりを悪くしているのを無理矢理救済している様にしか見えないなぁ。
        ちゃんと条件振ってシミュレーションしているのだろうか?

        元アナデジ混載ASIC屋なので、AC
  • by Anonymous Coward on 2003年06月23日 1時58分 (#343298)
     フリップフロップ一個ごとにプログラマブルな遅延素子を
    入れるとなると、結構な回路増加になるような気がするんですけど
    ニュースリリースを斜め読みしてもそこら辺読みきれなかった。
    どっかに書いてありました?
    回路が増えれば価格も消費電力も・・・とおもうのだけど
    どうなんだろう。
    • by Anonymous Coward
      私も余計な回路を入れてダイサイズを増やすより、入れない方が製造コストが低いと思うのだけど、
      1枚のウェハから取れる数が少ないチップでないと効果がない気がしますが。

      クロックを動的変化させるクルソーとどう意味合いがちがうのか良くわからない。誰か詳しい人解説お願いします。
typodupeerror

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

読み込み中...