※本記事はInterface誌2023年2 月号に掲載されたものの原稿版になります
開発効率⇒性能効率 : ワクワク開発
連載第一回では，ムーアの法則のおさらいと共に，「素子が多い複雑な回路でも設計できる」と紹介しました．一方で，設計対象のプロセッサが大規模になると，全ての工程を一人で担当することは難しく，チームを編成し，機能ブロック毎あるいは工程毎に分業して設計することが一般的です（図１）．チームで設計する場合，様々な課題に直面し，人数の割に開発効率が上がらないことがあります．
図1: プロセッサ開発のプロセス概要
ところで，なぜ開発効率を上げるのでしょうか．それは，開発するプロセッサの競争力(≒性能効率，後述するPPA)を高める時間を確保するためといってよいと思います．まさに連載第三回で述べた「みんな大好きCPU開発」の部分です．しかしながら，微細化の一途を辿りますます複雑化していく製品開発の中では，テンプレート化や自動化といった仕組みを巧みに取り入れていくことができなければ，競争力を高める作業に十分な時間を取ることが難しくなります。もし，単純作業，差異化につながらないような作業は可能な限り自動化して機械に任せ，設計者みんなが「大好きCPU開発」に多くの時間を使うことができたら，開発のワクワク感も増してくるのではないでしょうか．
逆に，ワクワクしないシーンの一例を図２に挙げてみました．開発あるあるなのではないでしょうか．改善しないといけないと分かっていても，スケジュールに追われ，効率が悪くても力技でこなしたり，会話ベースの擦り合わせに時間を要したりすることもあるかと思います．今回は，このような開発中に発生しがちな(あるあるな)課題を解決し，みんなでワクワクする開発をしていくためのヒントをご紹介していきたいと思います．
図2: 開発あるある
自動化(準備編) : テンプレート開発
自動化で手間がかかるところは，自動実行のスクリプトを書くことではなく，各メンバがそれぞれの作法で作った入力アイテムを定型に落とし込むところです．定型になっていないものに対して自動実行スクリプトを組むと，どうしても一品ものになりがちで，再利用も難しくなってしまいます．
これについて筆者の所属するチームでは，GitHub[リンク1]のテンプレートリポジトリ機能を活用しています．RTL(register transfer level)コード(SystemVerilog)や各種ドキュメント(Asciidoctor[リンク2])，EDA(Electronic Design Automation)ツールを使用するための環境群(Tcl, Shell Script, Makefile)等をGitHubに格納していますが，登録の仕方をメンバ任せにせず，初めに定めたディレクトリ構造の中に必要なファイルをパックしたテンプレートリポジトリを用意し，新しいリポジトリを作る際は，そこから始めてもらっています．テンプレート化しておけば自動化の処理もシンプルになり，アウトプットの品質もある程度担保（平均点アップ）できます．
一例として，ドキュメント環境についてご紹介します．ドキュメントはつい後回してしまい，書いていないあまりに問い合わせが増え，自分の時間がなくなるというのはあるあるです（図２の下段)．原因の一つは，書式設定や章立てを含めたセットアップの煩雑さにあると思います．そうしたおぜん立ては全てテンプレート側で対応して配布することにより，設計者は中身を書くことに集中できます．これで手離れよく，大好きコーディングに注力する時間が作れるようになります．完成したドキュメントの見栄えも統一でき，品質の向上も期待できます．図３にテンプレート開発のイメージを示します．
図３: テンプレート開発
自動化(基礎編) : GitHub Actions
自動化の実現方法は色々ありますが，ここでも筆者はGitHubの仕組みを使っています．GitHub Actionsは，ソースコードの登録時やタグ付け等をきっかけとして何かの処理を走らせることができる機能です．例えばRTLをリポジトリ登録する場合ですが，基本的なチェックが不足したまま登録してしまうと，ツールが流れなくなったりして他のメンバに迷惑をかけてしまいます．また，コーディングスタイルについても，ルール定義して周知したとしても，徹底させるのはなかなか難しいです．そこで，自動化です．RTLを登録するタイミングで，Lintチェック，フォーマット調整，簡易的なシミュレーションチェック等を一式流すようなActionsをテンプレートリポジトリに仕込んで配布しているので，設計者は論理を書くことに集中できます．こうしてまた，ワクワクする仕事に費やす時間を稼げるとようになります．Web上に公開されているsvlint[リンク3]，verible[リンク4]等のツールを用いれば，GitHubサーバー側のみで処理を完結させることができます．
自動化(発展編) : モジュラー設計・検証
一つのプロセッサを開発した後に，その構成部品を組み替えて別の製品を作ったり，多数の派生品展開を行ったりするケースがあります．その際，各種コンフィギュレーションに対応したプロセッサの構成部品の自動組み上げや，組み上げたデザインに対応したテストベンチの自動構築といった要求が出てきます．こうした組み上げを自動化するためにはインターフェースの切り口・整理が重要となり，ここでもテンプレート開発が活きます．デザイン及び接続情報ファイル(IP-XACT)の格納場所をテンプレートリポジトリ内に用意しておくことで，組み上げツールに容易に受け渡すことができます．このように，個別パーツを自在に組み替えてプロセッサや検証環境を自在に構築できる仕組み（モジュラー設計）のイメージを図４に示しました．
図４: モジュラー設計
性能効率 : PPA
開発効率を上げた暁には，いよいよ「大好きCPU開発」，開発するプロセッサの性能効率を上げることに注力できるようになります．プロセッサの性能を比較する際，PPAという言葉をよく用います。Performance(最高周波数)，Power(消費電力)，Area(面積)の略です．テクノロジライブラリと，論理合成等のツールがあれば見積もることができます．PPAはテクノロジライブラリ提供元(TSMC, Samsungなどの半導体製造ファブ)，及びテクノロジノード(130nmや16nm等)によって変わります．最近では，SkyWater PDK[リンク5](テクノロジライブラリ)，OpenLane[リンク6](論理合成ツールやレイアウトツール)が公開されるようになって，誰でも使えるようになっています．個人でRISC-V[リンク7]のISA(Instruction Set Architecture)の仕様を読んでプロセッサのRTLを書き，自分でその性能を確かめることができる，すごい時代になりました．アイデアさえあれば誰でも競争力のあるプロセッサを世に問うことができるのです．
経験豊富な設計者であれば，設計構想の段階から目標PPAを想定し，それに合わせたアーキテクチャを考えることができます．しかし，コーディングを進めていく上で，時に意図せず周波数が出ない実装をしてしまったり，想定以上に面積の大きな回路を作りこんでしまったりすることもあるので，定期的に論理合成を行って定点観測しておくと良いです．Actionsで論理合成を定期実行するように仕込んでおくと，問題が発生した際にすぐにフィードバックすることが可能となります．RTLの格納場所は先述の通りテンプレートで統一し，ツールの実行スクリプトもそれに合わせた形でテンプレートとして用意しておけば，論理合成専任の担当者を貼り付けることなく，簡単に実行及び結果確認を行うことができます．設計者自らが結果確認を行うので，担当者間で引き渡すためのオーバーヘッドもありません．
おわりに
今回は，少々華のない話題を取り上げてしまいましたが，こうした下支えの部分をきちんとした基盤として整備することは非常に重要だと考えています．一時的にセットアップのコストはかさみますが，成果が出て開発効率が上がった暁には，設計者それぞれが，存分にプロセッサの性能効率を上げる楽しい仕事に注力する余裕が生まれ，投資回収できるはずです（図５）．プロセッサ開発では，革新的なアーキテクチャを生み出し性能効率を上げることに注目が集まりがちです。しかし，持続的に競争力を維持していくためには，開発効率を上げて余裕を作り出してこそ，差異化領域に注力することができるのであり，性能効率・開発効率は切っても切れない両輪の関係にあるのです．
図５： 開発コストの変遷と投資回収モデル
本記事が読者の皆さんにとって，日頃の開発業務における困りごとの開発のヒント，ワクワクする開発に取り組めるきっかけになれば幸いです．
****
くさかり けん
****
この記事の関連製品
参考文献
[リンク1] https://github.co.jp/
[リンク2] https://asciidoctor.org/
[リンク3] https://github.com/dalance/svlint
[リンク4] https://github.com/chipsalliance/verible
[リンク5] https://github.com/google/skywater-pdk
[リンク6] https://github.com/The-OpenROAD-Project/OpenLane
[リンク7] https://riscv.org/japan/