～～量子コンピューター Advent Calendar 2019の十六日目の記事です。～～～

導入部

未踏ターゲット事業：2019年度採択プロジェクト概要（山崎・新里・今村PJ）

「RISC-V量子拡張の参照実装とマイクロ波制御量子ファームウェアの開発」

として、未踏ターゲット事業に採択されたのが、今年の7月のことでした。

今日までで、約半年、いろいろと苦労したり、問題点が出たり、死にそうな目にあったりしてきたため、今回は、Advent Calendar向けのネタということで、ゆる～くこれまでを振り返ってみたいと思います。

 

開発ターゲット

まずは、どのようなものを製作しているのか？簡単な概要を解説します。

簡単に言えば、量子アプリケーション～量子ビットまでのシミュレートできるシン・量子言語&コンパイラとそのシミュレータです。まさに上から下まで、次世代の量子コンピュータを想定したシン・システム一式を作ってしまおうというわけです。

こちらが、実際の進み具合というところです。実は3/4くらいは実装が進んでいます。

開発秘話

と、全体像が見えてきたところで、各パートの苦労話をしていきたいと思います。

RISC-V量子拡張の参照実装編

まずは量子演算をシュミレートできるライブラリを利用・RISC-V上で動作できる事の確認から行いました。

・RISC-V Quantum Extension
・QuESTをRISC-V上で動かす

ここでQuESTがRISC-V上で動作してしまえば、演算・レジスタ周りはQuESTに任せることが出来て、RISC-V周りのアーキテクチャ・実装・コンパイラ周りに集中できるという足がかりになりました。

量子プロセッサ・シミュレータ

ここからが問題になってきますね。

・Quantum compute on RISC-V emulator(Spike)

当初はQEMU上に量子演算を組み込もうとしたんですが、RISC-V謹製のシュミレーター Spikeのコードがシンプルかつ改造しやすいことが分かって、Spikeを改造していくことにしました。
主に行ったことは次の2点です。

・カスタム命令セットの実装
・QuESTの組込み

opcodeの追加はとっても簡単にSpike上に組み込むことが出来て便利でしたね。同時にRISC-V GNU Toolchain(GCC)でテストプログラムを作って実際にSpike上で命令セットの実行まで行えることが確認できました。

マイクロ波制御量子ファームウェアとはこのシュミレーターから通信(UDPとか)を行って、ファームウェア側 or シュミレーター(QuEST)のどちらかで量子演算を行えるような選択性をもたせることになる感じですね。

量子コンパイラ編

シュミレーターまで動作して、簡単なプログラムを実行できるようになったら、いわゆるハードウェア・OS面までの整備が済んだことに。という事は、次は量子向けのコンパイルを行える環境に必要になってくるという流れです。

・Add Extend Instruction set to RISC-V GNU Toolchain

まずはGCCの改造をします。一般的なC/C++のプログラムから量子系の演算をできるという環境を作りました。追加のライブラリとかは不要で、C/C++のプログラムに量子回路を追加すればあっさり動きます。命令セットやアセンブリの解釈、量子レジスタ周りの改造をgccに行った感じです。

同時にLLVM(clang)を使って中間言語 IRを生成してから、実行形式(アセンブリ=>実行ファイル)にするところはgccを使うことで、LLVM上であれば何でも量子系のプログラミングを行って実行できるという環境も出来たということに。

とりあえず、ここまでで一段落ですね。「プログラミング〜命令セット〜シュミレータ〜量子演算」までの流れが出来たことに。

次に更に抽象化して、量子向けプログラミング言語をLLVMで実装してみることにします。

・qlang(quantum language) with LLVM

これが地味にハマりました。LLVMをビルドした事がある人なら分かるはず、凄まじくCPU・メモリを消費するんですね。ビルド中にスワップして失敗なんてのは当たり前、CPU・メモリが大量にある環境じゃないとソースからのビルドは全くもってオススメ出来ないですね。
そして、LLVMの最新版(現時点での10.0)を使っているのもあって、ビルドはもちろんLLVM上の言語実装についても手探り感がモリモリでした。

一応、golangのような言語形式でコードを記述して、シュミレーター上で実行する所や、最適化(-O[0-3])・Pass Manager経由での量子回路最適化経路といった所まで確認が出来ています。あとは…テレポーテーション用の関数あたりを作ったりアプリを作ったりしてテストとかですね。
LLVMベースの他の言語(C/C++とか)で記述したIRを持ってきても実行出来るという、なんかLLVMマジで便利っすね。

あとオマケで…QuEST単体・シュミレーター(RISC-V)上での演算、実機(K210 64bit dual core RISC-V)での量子演算のパフォーマンステストみたいな事をしたり。
・RISC-V spike vs QuEST
最近流行りのK210でも、一応量子演算のプログラムは実行可能ですねー

マイクロ波制御量子ファームウェア編

まずは、これまでの投稿のうち、下記の2つを読んでもらえると大体何を開発しているのか？つかめるかと思います。

・量子ファームウェアとは？

・GNURadioの量子ファームウェア拡張の概要：ブロック解説編

苦労しまくった点は、下記の2点です。

・2量子ビット対応

・GNURadioとQuTiP連携機能の開発

2量子ビット対応の苦労点

ずばり「同期機能」と「量子もつれ・エンタングルメント（CNOT系の機能）」です。

2量子ビット以上だと、2つ以上の量子ビットに同時に電波を出して、操作しなくてはならないこともあります。しかし、「GNURadio」では「Flowgraph」で実行される「逐次実行型」のシミュレータです。そのため、「前の処理が終わったら、その結果を次の処理へ渡していく」という実装しか書けません。すなわち、「並列同期実行」≒「『クロック』でタイミングを制御する」的な実装はできません。

そこを無理やり「クロック同期させる」機能（ブロック）を用意して、同期を実現することとなりました。当然、GNURadio的には想定外の機能であるため、一筋縄では拡張不可能でした。

さらに、「量子もつれ・エンタングルメント（CNOT系の機能）」の場合は、2つ以上のGNURadioの機能（ブロック）が連携して動作します。しかし、これもまた、そのような機能はGNURadioにはありません。

そのため、ステートマシン機能を実装した機能（ブロック）を用意しました。そこに、上記のクロック同期処理を組み合わせることで、連係動作させて、実現させました。ここは、FPGA化する上でも重要な機能となるため、FPGA化も見据えて実装を考えたので、非常に苦労した点となります。

GNURadioとQuTiP連携機能の開発の苦労点

当然ですが、GNURadioには信号処理の機能はたくさんありますが、量子に関する機能はありません。そこで、本来ならすべて実装しないとならないわけです。

しかし、世の中にはすでに開発済みの量子ビットシミュレータが存在します。その一つでデファクトスタンダードといってよいものがQuTiPです。

そこで、GNURadioとQuTiPを連携させて、極力量子系の処理はQuTiPに任せるという方針としました。しかし、そこに罠がありました。

まず、GNURadioはC++ベースですがPythonのラッパーが用意されているため、Pythonベースでも各種機能を利用することが可能です。そして、QuTiPはPurePythonです。そのため、簡単に連携できるかと思いきや、そうは問屋が卸しませんでした。

ダメだったポイント

・Pythonのバージョン違い

まず、Pythonのバージョンが、GNURadioが2.7系、QuTiPが2.7&3.6系です。なので、2.7系で動かせばよいと思われたのですが、QuTiPが2.7系では動きませんでした。たぶん、2.7系は2020/1で開発停止のため、もう、テストされていないと思われました。

そこで、GNURadioを調べたところ、最新版だとベータ版の3.6版ソースコードがあるとのことでした。そこで、ソースコードからビルドすることでGNURadioを3.6系対応にしようとしたところ、、、さすがはベータ版、全くビルドできませんでした。ビルドが通ったと思ったら、吐き出されるコードは2.7版のコードであるなどは当たり前な感じでした。

約一週間かけて、それらの修正をして、なんとか、3.6版のGNURadioを手にすることができました！