計 算 機 の 仕 様 書

仕様書は, 設計の段階により, 方式設計から機能設計までのものが求められている. 以下, まず一般的な ハードウェアの設計/製作の手順 について述べた後, 各仕様書の内容 についてまとめる.

ハードウェアの設計/製作プロセス

ハードウェアの設計/製作は一般に, 以下のような段階を追って進められる：

1. 方式設計 (System Design)
設計するシステムに対する要求仕様を定め, それを実現するための技術的裏付けを求める.
2. 機能設計 (Function Design)

方式設計によって定められたシステムを機能コンポーネントに分割し, 各コンポーネントの構造 (structure) と動作 (behavior) を定める. そのためには, 各コンポーネント内に存在する主要なレジスタと それらの間のデータ・パスを設計することでその構造を規定し; それらのレジスタ間のデータ転送 (Data Transfer) を設計することで その動作を規定することになる. したがって機能設計は, RTL (Register Transfer Level) 設計とも呼ばれる.

最近では, ハードウェア記述言語 (HDL) を用いて行われることが多い.
3. 論理設計 (Logic Design)
機能設計で定められた各コンポーネントを, 論理ゲートの組み合わせによって実現する. 最近では, 多くの部分が HDL 記述からの 論理合成 (Logic Synthesis) によって自動的に行われる.
4. 機能シミュレーション (Function Simulation)
後述する配置配線の結果得られる実際の遅延を考慮せずにシミュレーションを行い, 論理設計の機能的な正しさを検証する. なお HDL を用いた設計では, 論理設計以前に機能シミュレーションを実行することができる.
5. 配置配線 (Place & Route)
論理設計の結果得られた論理回路を 実際に製作されるデバイスに写像する. 論理ゲートとゲート間の配線の物理的位置を定める.
6. タイミング・シミュレーション (Timing Simulation)
配置配線後の実遅延データを考慮したシミュレーションにより, 設計の検証を行う.
7. テスト用のハードウェアの製作
実際にハードウェアを製作する.
8. ハードウェア・テスト (Hardware Test)
ハードウェアが実際に正しく動作することを確かめる.
9. 量産

各段階において設計に実現不可能な点が見つかった場合には, 当然のことながら, 適切な段階まで戻る必要がある. この際の前の段階への申し送り事項を バック・アノテーション (Back Annotateion) と呼ぶ.

本実験における設計/製作プロセス

ハードウェアの設計/製作プロセスは, 本実験では以下のようになる. 上述した一般的なプロセスと異なる部分を 赤字 で示す：

1. 方式設計 (System Design)
設計するシステムに対する要求仕様を定め, それを実現するための技術的裏付けを求める.
2. 機能設計 (Function Design)
方式設計によって定められたシステムを機能コンポーネントに分割し, 各機能コンポーネントの動作を定める.
3. 論理設計 (Logic Design)
論理 CADのスケマティック・エディタを用いて, 論理回路図 (Schematic, スケマティック) を記述する. 本実験では, HDL, 論理合成ツールは使用しない.
4. 機能シミュレーション (Function Simulation)
配置配線（後述）の結果得られる実際の遅延を考慮せずにシミュレーションを行い, 論理設計の機能的な正しさを検証する.
5. 配置配線 (Place & Route)
スケマティックとして記述された設計データに基づいて, 論理ゲートを FPGA の論理ブロックへの割り当てて, その間の配線を行う. この操作は, CAD のインプリメンテーション・ツールによって 自動的に行うことができる. もちろん, 人手で行ってもよい.
6. タイミング・シミュレーション (Timing Simulation)
配置配線後の実遅延データを考慮したシミュレーションにより, 設計の検証を行う.
7. テスト用ハードウェアの製作
コンフィギュレーション・データを PowerMedusaボードにダウンロードすることによって行われる.
8. ハードウェア・テスト (Hardware Test)
ハードウェアが実際に正しく動作することを確かめる.
9. 量産
量産はしない.

仕 様 書

実際の設計では, 各段階においてそのレベルの仕様書を記述することが普通である. 本実験では, 中間報告 において, 方式設計と機能設計レベルの仕様書を提出する.

　各レベルの仕様書は, それがあれば, 誰がその先の設計を行っても 完成したハードウェアのその設計段階で規定される特徴が一致するように 記述されている必要がある.

　本実験で提出する方式設計と機能設計レベルの仕様書には, 以下の事柄などが必要であろう：

方式設計仕様書

方式設計では, 設計する計算機に対する要求仕様を定め, それを実現するための技術的裏付けを求める.

方式設計レベルの仕様書は, それさえあれば誰がその先の設計を行っても, システムの機能, 性能が同一となるように記述されている必要がある. したがって本実験の場合には, 完成した計算機があるプログラムを実行した場合に その実行サイクル数が一致することが求められよう.

具体的には, 提出する方式設計仕様書には 設計する計算機に関する以下の項目が含まれる：

なお, 配布資料 に書いてあるようなことを再掲する必要はない. 必要であれば, 参考文献として挙げ, 適宜引用すること.

SIMPLE 設計資料 における SIMPLE/B の記述, バス・インターフェイス仕様書 の1章, 2章は, 方式設計レベルの仕様書である.

機能設計仕様書

機能設計では, 方式設計によって定められたシステムを実現するため, 全体をいくつかの機能コンポーネントに分割し, 各コンポーネントの構造 (structure) と動作 (behavior) を定める.

計算機の場合には, 以下のようなコンポーネントに分割するのが適当であろう:

フェーズごとに分割するのは, 同一の『もの』が異なる複数のフェーズで動作することになるため, うまく行かない.

機能設計レベルの仕様書は, それがあれば, 誰がその先の設計, すなわち論理設計を行っても, そのコンポーネントの動作周波数とチップ面積に 大きな差が出ないように記述されていなければならない. 具体的には, およそ以下の項目が含まれる：

外部仕様
  1. 特徴
  2. 方式設計, 他のコンポーネントとの関わり: コンポーネントの, 計算機全体における位置付け, 役割. 外部とのインターフェイス, 外部から見た動作.
    構造
    計算機全体のブロック図における, そのコンポーネントの位置づけ.
    動作
    計算機全体のフェーズ・フロー・チャート, データ・フロー・チャートにおける, そのコンポーネントの位置づけ.

他のコンポーネントを担当者は, このコンポーネントの外部仕様だけを参照すればよい.

内部仕様
  1. 実装上の特徴
  2. コンポーネントの内部構造と動作:
    構造
    コンポーネントのブロック図 (論理回路図ではない),
    動作
    コンポーネントのフェーズ・フロー・チャート, データ・フロー・チャート, タイミング・チャート.
  3. 論理設計にあたって特に留意すべき点. 例えば, critical path の指摘など.

バス・インターフェイス仕様書 の3章は, 機能設計レベルの仕様書である. 提出する仕様書には, プロセッサの各部について, 同程度の記述が必要であろう.

質問の宛先は shimada@kuis.kyoto-u.ac.jp.
Last modified: 2007/5/11 9:30