論理回路デザイン
お問い合わせ サイトマップ リンク Tips
ArchiTek home page
目的


論理回路の設計手法は一部確立していますが、経験と知識に依存している[1]部分も多く、人によっては難解で設計に時間がかかったり、独自の誤った手法を用いたりする場合があります。特に大規模LSI設計になると、高いレベルの能力と全体的なバランス能力が求められ、メンバーは意思疎通のためどうしても基礎となるところだけは必ずマスターしておかねばなりません。


このホームページは、メンバーが簡単にエキスパートの入り口にたどり着くためのガイドブック[2]を狙って作ったものです。また広く公開することで、メンバー以外の方のご意見の取得[3]や、これから論理回路を勉強したいという方へ寄与できたらと考えています。

指針


論理設計の現場は、ソフトウェアの開発に比べると比較的緩いルールで開発が行われていると思います。その理由は、個々の技量が性能やコストに直結するためどうしても個人主義になりがちであり、またこれと言った普遍的な教書がない(もしくは育成の場がない)からだと考えます。


かと言って、ルールを強要することが正解かどうかは言い切れません。ただルールを設定すれば、チーム内の思考の共有化に貢献することは間違いありません。ここでは、そのルール作りの参考にして頂けるようさまざまなプリミティブや設計例を更新して行きたいと考えています。


ただ、もし全体構造から細部に至るまで統一した構造ならびに記述方法であれば、金太郎あめのように回路のどの切り口でも理解しやすくなりますし、再配置や再接続も簡単です。また、テスト工数も同じ構造なら考えやすいので短縮できます。


Kintaro Candy

ここでの回路設計の概念


普遍的な部品(プリミティブ)[4]を知っているとアーキテクチャの構築に集中でき、後はパズルのピースを当てはめて行くだけの効率のよい手法がとれます。底辺のプリミティブはその名の通り多くはありません。プリミティブの組み合わせで上位階層の回路が作成できますが、普遍性を与えれば新たなプリミティブとしてさらに上位の回路が作成できます。


このようなプリミティブからアーキテクチャに向かうボトムアップ設計と、仕様からアーキテクチャに向かうトップダウン設計は対であり、両者とも車の両輪のように必要不可欠な存在です。双方の知識がないとバランスの良いシステムは組めないはずです。仕様は変化しますがプリミティブは定型なので、プリミティブから頭に入れて行くことが回路設計を知る上で効率的だと考えています。


Design

内容


プリミティブの基礎の一つであるパイプライン構造を理解すれば、スムーズに高度な設計にも対応できると考えています。大抵のアルゴリズムも、パイプラインの直交性を利用して機能を輪切りに一つずつ回路に落とし込めます。ここでは、このパイプラインに関する知識を基礎にしています。


次に機能モジュールの設計のヒントになるよう、いくつかのテクニックを参考に記載します。恐らくこれだけでは不十分ですが、アイデアを回路に変換する際の参考になると思います。


また設計例をコードとともに具体的に記載します。基本的な部分だけの公開ですが、さらに発展できる余地のあるものを選んでいるため有用だと思います。

とは言うものの


実際どうなのか?と問われることがあります。役立つと言う面ではYesですが、解決すると言う面ではSo-soです。


我々も当初はプリミティブと接続方法のひな形を用意しておけば、機械的な作業に落とし込めるのではと思っていました。しかし実際、具体的な課題を前にすると新たな試行や異なる論理を導出が必要だったりします。つまり、考えを養う上でのサンプルは提供できるものの、課題に対する解決策はやはり技術者の能力にかかってくると言うことだと思います。


従って、ここで掲載する内容は更新されてこそ価値を生むのではないかと考えています。裏を返せば、内容の完成度がどこにあるか分からない、そしてそれは決められないということを最初に謝っておきたいと思います。

回路デザイン > ホーム > はじめに    次のページ(言語・記述スタイル)   このページのTOP ▲

[1]
HDL入門に関する教科書は多くありますが、さらに踏み込んだものはあまり見かけません。先輩が作り上げたRTLを見ながら理解したり、独自に試行錯誤しながら腕を磨く、そんな場合が多いのかなと思います。

それぞれの独自文化が形成されるため、他社や他のグループの文化を覗くと感心することも多々です。建築のように芸術性を大事にしてしまうと言うのは言い過ぎでしょうか。
[2]
熟練者であれば仕様策定から詳細設計まで、目的さえ掴めれば頭にアウトラインが浮かんでくるものです。それら直感は豊富な経験からくるものであり、そのノウハウを失敗例を含めて見える形にすることが理想です。
[3]
実際一人で設計すると、独りよがりになるため大事な仕様矛盾等を見逃す確率が多くなります。一方複数人で設計すると細かいリスクが発生します。レビューを如何に行うかが、品質向上の鍵だと思います。
[4]
プリミティブからテストもしくはアルゴリズム(一般非公開)までを一通り読めば、我々の論理回路設計の手法を理解できるはずです。合わせて、設計サンプルも見てください。いくつかは、深く理解する上で役にたつものだと考えています。
[5]
CPUの高速化やGPUの並列化など、専用ハードウェアを作る意味を問われることがあります。それぞれ一長一短があり、時代により適材適所も変わってきます。そもそも、手段を限定することに意味はありません。いずれの方式も合理的な観点で柔軟に使用していくしかないと思います。