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

命令数を4種類に限定することでIoT向けに最適化したCPUアーキテクチャ「SubRISC+」 56

ストーリー by nagazou
最適化 部門より
東京工業大学(東工大)と科学技術振興機構(JST)は19日、IoTエッジコンピューティング向けの小型かつ省電力なプロセッサアーキテクチャ「SubRISC+」を設計し、1mm×1mm角のプロセッサとして構築したと発表した(東京工業大学科学技術振興機構論文PC Watchマイナビ)。

東工大のリリースによれば、古い製造プロセスである65nm CMOSを用いても1mm×1mm角を実現できたという。またARM Cortex-M0と比べた場合、1.4倍ほど高速でありながら電力効率は2.7倍、エネルギー効率は3.8倍を達成したとされる。

IoTの普及が増えるとデバイスやセンサー、サーバー間でのデータ通信量の増加が懸念される。そこでエッジとなる端末側での処理能力を高めることにより、遅延を減らしネットワークの負荷を軽減することなどが求められる。しかし既存の組み込みプロセッサは、IoT向けとしては過剰スペックであることから、SubRISC+では命令数を4種類に限定することにより、小型化と低消費電力化を図ったのだとしている。

あるAnonymous Coward 曰く、

東京工業大学 工学院 情報通信系の原祐子准教授らは、IoTにて重要となる小型・省電力性を兼ね備えた新たなプロセッサを設計し、実機の開発に成功した。(ニュースリリースPC Watchの記事)

 既存の32bitプロセッサではARMのCortex-M0で60命令、RISC-Vで47命令の命令数があるが、開発した組み込みプロセッサは減算・シフト・論理演算・メモリアクセスの4種類の命令のみから成り、減算結果に応じて条件分岐するという特徴を持つ。なお、4命令のみでもチューリング完全であるため、適していない用途にも利用はできる模様。
 実機は65nmCMOSプロセスを用いながら1mmx1mmと小型で、既存の32bitプロセッサでは最小となる物(明記されてはいないがおそらくRISC-Vベース)に対し2.7倍の電力効率、3.8倍のエネルギー効率を実現している。
 適用の一例として、加速度データからてんかんの発作をリアルタイムに検出可能な軽量アルゴリズムを実装し実用性を実証したた結果、動作周波数を50 MHzと想定したシミュレーションではデータのサンプリング速度より高速に異常検出でき、かつ、電力は131.1 µWと極めて低い。
 また、このプロセッサLSIを5 MHz(ヘルスケアの異常検出ではリアルタイム処理を十分確保できる周波数)で駆動した場合の消費電力はわずか77.0 µWであり、これはコンビニエンスストア等でも手に入るアルカリボタン電池LR44で約100日連続稼働できる試算である。

情報元へのリンク

  • チューリング完全で「減算結果に応じて条件分岐する」といえば、
    OISC [wikipedia.org](単一命令セット)の Subleq 命令が思い浮かびますが、
    ここにシフト・論理演算・メモリアクセス命令を加えて使い勝手を良くした感じですかね。

    ところでOISCは小型で省電力というだけでなく、命令が単一なのでどんなアルゴリズムを実行していても消費電力・ノイズの変動が少なく、サイドチャネル攻撃に強い特性もあるらしいですね。
    このCPUも、そういう用途での要求があったんでしょうか。

    ここに返信
  • by Anonymous Coward on 2021年02月24日 12時09分 (#3983270)

    ARMやRISC-Vじゃなくて、Z80やPICと比べるべきじゃないかなあ。

    # 新しいインストラクションセットにはわくわくしますが

    ここに返信
    • by Anonymous Coward on 2021年02月24日 12時43分 (#3983297)

      IoT向けというのであれば、最近流行りのESP32と比較してほしいなー。
      Xtensaのメインコアの方はともかく、ULP [espressif.com]の方は、uAオーダーで動くらしいし。

      あと、CPUコア単体もいいけど、無線チップとかセンサチップとか含めたシステム全体でどれくらいの効果があるのかも検証してほしいな。

      • by Anonymous Coward on 2021年02月24日 12時54分 (#3983303)

        結構軽いコア単体ってだけでもニーズあるのよ
        USB充電器作ろうとしてtype-cチップのデータシート見たらM0乗ってたとか、ブラシレスモータのベクトル制御コアにM0乗ってたとか、アプリケーションプログラマとは関係ないとこで頑張ってる

        • by Anonymous Coward

          > IoTエッジコンピューティング向けの小型かつ省電力なプロセッサアーキテクチャ
          って書いてあるだろ。
          USB充電器とかモータ制御にこんな超低消費電力重視の使いづらいプロセッサなんて使う意味ないし、使ってられないでしょ

          • by Anonymous Coward

            USB充電器ってそんなにマイコンの性能いるの?
            せいぜい電力ネゴシエーション程度かと思ってたけど

            • by Anonymous Coward

              開発や実装コストでM0の方が調達しやすいのだろうね。

              時間制限あるから、ある程度の性能は必要だし、
              最近は端末側からの指示で電圧変更とかも必要。

    • by Anonymous Coward

      PICとCortex-M0の比較はARMとかがやってるんじゃないですかね

    • by Anonymous Coward

      機能やスレッドが増えるに応じてその分コアを増やしていくみたいな使い方なんですかね?
      お値段安そうだし

    • by Anonymous Coward

      CASLよりも命令数が少ないって、本当に使い物になるか疑問

    • by Anonymous Coward

      メモリ込みで1平方ミリメートルのプロセッサに、32ビットものアドレス空間必要なの?

  • by Anonymous Coward on 2021年02月24日 13時26分 (#3983325)

    気になりますね。

    ここに返信
    • by Anonymous Coward

      ハード的な面では、単純であればあるほど壊れにくくなるので、リスクは下がりますね
      実行面では、ある命令の実行時間が想定と大きく乖離する可能性(4 種類の命令でエミュレートするようなケース)がありえますが、そういった複雑なことはこのアーキテクチャのスコープ外でしょう
      ソフト的な面が一番難しく、元の命令をこのアーキテクチャに落とし込む変換を完璧にこなす必要がありますので、ここが一番のリスクかと
      とはいえ、LLVM を使っているので入力言語の難しさは緩和されて、中間言語をこのアーキテクチャに落とし込めればいいので、その当たりも昔に比べればリスクは減っているのではないでしょうか

      このハードを使ったシステムなら、多分電源(電池)と命令の格納先(ストレージ)の故障、あとは IF 部のトラブルの方が遙かにリスクが大きいかと

      • by Anonymous Coward

        リスクっていうかコストだな。
        コストが見積もりにくいのはリスクかもしれんが。

    • by Anonymous Coward

      スーパーでプラスな程度です。

  • by Anonymous Coward on 2021年02月24日 12時14分 (#3983272)

    https://www.titech.ac.jp/news/img/news-26828-2-ju8kd24t.png [titech.ac.jp]
    これ見ると実質1命令な気がする。
    そういえばx86のmvもチューリング完全だからって言ってそれだけのコードを吐くコンパイラ作った人いたよね

    ここに返信
  • by Anonymous Coward on 2021年02月24日 12時14分 (#3983274)

    32bitプロセッサにおける〇〇年問題って解消されてたんでしたっけ?

    # 情報元には特に何も記載がなかったけどとっくに問題ない状況なのかな

    ここに返信
    • by Anonymous Coward

      そりゃISAの問題ではなくてどの型で表現するかって話では

      • by Anonymous Coward

        型もあんま関係ないのでは?
        工夫したくないけど工夫すれば済むし。

    • by Anonymous Coward

      そもそもOSとか動かすようなプロセッサじゃないので、UNIX時間の制限は関係ないのでは?

      • by Anonymous Coward

        電源投入からの秒数だけ持ってるとか普通に有るしね。

  • by Anonymous Coward on 2021年02月24日 12時17分 (#3983276)

    いまどきのIoTは、LinuxやFreeBSDやOpenBSDが載ってる場合が多い
    そういった汎用OS乗せる必要が無い単機能IoT(たとえば流量計・温度計・圧力計とか)なら汎用OS不要でも、
    単機能じゃないIoTなら汎用OSが載るほうがいい

    ここに返信
    • by Anonymous Coward

      > SubRISC+では、データからの異常検出やデータ探索をする軽量アルゴリズムをリアルタイムに処理し、警告などのかぎられたデータのみ送信する用途を想定

    • by Anonymous Coward

      載せれば載るだろう(載らない理由はない)けど、用途違うでしょ

    • by Anonymous Coward

      チューリング完全

      • by Anonymous Coward

        とはいえ特権モードはほしいとかMMUはほしいとか太ってく未来が見える

        • by Anonymous Coward

          素直にx64エミュレータ書けばいいんだよw

    • by Anonymous Coward

      「載ったら面白い」なら分かる
      「載った方がいい」はただ頭の悪い人

    • by Anonymous Coward

      IoTって言っても想定してる用途、価格、処理能力、消費電力が人によって違いすぎるから、その想定範囲を変えればいくらでも否定できてしまう。(それに想定範囲は自分では、それが当たり前なのでわざわざ書かないんですよね)
      否定の話ばかり続きそう

      できれば、このプロセッサに絞って、できそうなことをあげてもらえばうれしい。

  • by Anonymous Coward on 2021年02月24日 12時23分 (#3983283)

    たった4個のインストラクションセットでどれだけ冗長なコードを書くのかと思ったら

    ここに返信
  • by Anonymous Coward on 2021年02月24日 12時36分 (#3983293)

    ハードがあっても、開発環境が無いのでフルスクラッチでアセンブラで書いてください・・・とかじゃなく、
    やはりそれなりの開発環境があったほうがいい

    C言語やらArduinoで開発できるとか、基本的なライブラリが揃ってるとか、そういったのがないと

    ここに返信
    • by Anonymous Coward

      RISC-Vのバイナリをこの命令セット用に変換するという仕組みのようだけど

    • by Anonymous Coward
    • by Anonymous Coward

      Brainf*ckで開発ができるとか?

    • by Anonymous Coward

      tinyccとか、いまどきhackしやすいクロスコンパイラがあるから、そのへんで遊んでみたい。
      そしてそのうち、clang/LLVMが追い付いてくる。こういうのは得意な人がいるので、楽観していいと思う。

  • by Anonymous Coward on 2021年02月24日 13時05分 (#3983314)

    省電力を狙うなら、起こされるまで寝る命令は欲しい気がする。
    CPUとしては面倒を見ないから、それができるペリフェラルを付けて叩けという思想なのかな。
    もしくは、ポーリングでも大差ないほどカツカツの低クロックで動かすか。

    ここに返信
    • by Anonymous Coward

      コイツはその「本命のCPU」を起こすためのセンサーに入るんじゃないか

    • by Anonymous Coward

      インターバルタイマに叩き起こされたら1サイクル分の処理を行い、
      それを終えたら次に起こされるまでHALTで待機とかでしょ。
      ゲームボーイがそんな感じだった。

    • by Anonymous Coward

      ヘルスケア製品の様に電源を入れたら切るまで常に入力があり、それを演算し続ける用途を想定しているので、寝ている暇などないのでは?

      • by Anonymous Coward

        ほとんどのセンサーには値を取り出せる周期の限界があるので
        人間の感覚ではリアルタイムでも0.1秒刻みとかのインターバル動作だったりする。

  • by Anonymous Coward on 2021年02月24日 14時29分 (#3983351)

    引き算で分岐ということは、2オペランド命令で
    引数が、比較される数を入れるレジスタと相対指定のジャンプ先で
    2バイト目に相対ジャンプ先を書くんじゃないかなと予想。

    引かれる数を入れるレジスタはZ80のAみたいに固定で、
    引く数を入れるレジスタをどれにするかで、ZとかCとかの
    どのフラグがたったときにジャンプするかが決まるんじゃないだろうか。

    算術演算としてやりたい場合は、ジャンプ先を次の命令ににしておけば
    結果に関わらず次に書いた命令が実行される。

    逆に無条件ジャンプしたい場合は、0-0=0の演算でZフラク立てて
    分岐をトリガーする感じか。

    引き算のときだけ2バイト目(ジャンプ先)をフェッチするなら、
    相対ジャンプオンリーにしてしまえば、リロケートが楽だし
    IMEM側からPCに値をロードするための回路も省略できる。

    構成図を見るとIMEMから直にPCに渡す回路がない
    (必ずALU経由)か、おそらくジャンプは相対指定のみ。
    リロケートも楽という利点もある。

    という感じじゃないかなーと予想したけど、妄想のレベルだな。

    ここに返信
  • https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9133073 [ieee.org]
    Here we briefly explain the basics of SubRISC+ to the extent of highlighting our contributions in this paper.
    SubRISC+ was developed on the basis of a one-instruction set computer (OISC) whose unique instruction is ‘‘subtraction and branch on negative’’ that is capable of realizing any operations and hence is Turing complete.
    By extending the instruction set architecture (ISA) of this OISC, SubRISC+ handles four instructions (subtraction, bitwise AND, shift, and memory access) that can be flexibly expressed in either 16 bits (for compactness) or 32 bits (to support an immediate value or branch) to improve computing and power efficiency while retaining simplicity with a very limited circuit overhead.

    bne a0, t1, .L2 →
     sub a0, t1, t3, .L2 (two 32-bit instructios)
     sub t1, a0, t3, .L2

    not a0, a1 →
     sub -1, a1, a0 (one 16-bit instruction)

    subtract and branch if less than(sublt)命令です。subleqではありません。

    ここに返信
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...