128 Design Wave Magazine 2000 December

ここでは，米国Texas Instruments社によるシステム・

レベル設計の事例研究を紹介する．題材は，QAMモデムの

アーキテクチャ設計である．QAMモデムの機能を分割し，

DSP（TMS320C62X）上で実行するソフトウェア，および

二つの高速化ハードウェア（フレキシブル・コプロセッサ）に

マッピングした．アーキテクチャのよしあしを評価するため

に，市販のアーキテクチャ解析ツール（米国Innoveda社

の「eArchitect」）を利用した．各ハードウェア・リソース

の稼働率を確認しながら，アーキテクチャの改善を図ること

ができた． （編集部）

時間の経過とともにどんどん狭まっていくマーケット・ウ

ィンドウ，そしてますます複雑になるエレクトロニクス製品の

組み込みソフトウェア．このような状況に対応するため，設

計サイクルの早い段階で，アーキテクチャについて一貫性の

ある包括的な検討を行うことが求められている．こうしたア

プローチをとることで，設計技術者は最適なアーキテクチャ

を選択したり，高い確度でアーキテクチャの性能要求を満足

させられる．さらに，統合テストのとき，あるいは最悪でも

製品が出荷された後で，ひやひやさせられるような事態を大

幅に減らすことができる．

大規模なシステムの開発では，アーキテクチャ設計がしっ

かりしていないと，大きな損失につながるトラブルが増える．

アーキテクチャ設計に必要な方法論やEDAツールはすでに世

の中に存在しており，その気になれば利用可能な状態にある．

いくつかの方法論（またはツール）は，アーキテクチャ設計の

ある一つの側面だけを取り扱っており，またいくつかの方法

論はアーキテクチャをより総合的に取り扱おうとしている．

ほとんどの場合，こうした方法論を利用すると，シンプルな

モデルを短期間に作成できる．

ここではハードウェアとソフトウェアを含むシステム・レベ

ルの設計に関して，いくつかの考え方と課題について解説す

る．理想的なシステム・レベル設計フローを実現するためには

なにが必要かについて議論する．また，筆者の所属する企業

（米国Texas Instruments社）で行ったQAM（quadrature

amplitude modulation）モデムによる事例研究を紹介する．

この事例研究では，アーキテクチャ・モデリングとシミュレ

ーションを通して，システム設計のさまざまな要素を説明し

ていく．

システム・レベル設計に必要な考え方

システム設計を理解するには，“システム”の対象範囲を理

解することが重要である．これについては，現在，さまざま

な定義が世の中に存在する．ほとんどの設計技術者は，“シス

テム”を設計工程における最上位階層の表現形態というくらい

にしか捉えていない．これは，設計者1人1人の知見として

は正しいのだが，しかし，本当のシステム設計はすべての設

計工程に関与しているということを理解しておくべきである．

すなわち，最終製品を定義する上流の要求分析から，回路や

ソフトウェアを作成する下流の実装設計に至るまで，すべて

の工程がその対象となる．システムとは，たんなるハードウ

ェアやソフトウェア以上のものであり，機構設計（メカ設計）

の要求，設計・製造管理，さらには製品に対するもともとの

要求仕様と設計の関連づけなどを含む場合もある．

システム・レベル設計を重視する傾向が高まっているのは，

現在のエレクトロニクス製品がどんどん複雑さを増している

からである．市場競争に勝ち続けるために，エレクトロニク

ス製品には革新性と独自性（他社製品との差異化）が要求され

ている．そのため，設計工程全体を最適化しなければならな

い．システム・レベルの見地から，設計技術者には設計工程

全体を包括的にながめる視点が要求されている．

●ドメイン，工程間の円滑なコミュニケーションが必要どのような製品開発サイクルであっても，リスクはつきも

のである．リスクを管理するには，設計工程の各段階でメト

リックス（問題を定量的に評価するための指標）を関連づけ，

比較すればよい．

システム設計の大きな課題の一つに，工程と工程の間が自

動化されていない，ということがある．要求分析，アーキテ

クチャ検討，仕様策定，実装設計の各工程はそれぞれ互いに

影響を及ぼし合っているのだが，これらの間の相互依存関係

11

Design Wave Magazine 2000 December 129

を管理することが困難なのである．実装設計だけを取り上げ

てみても，ハードウェア設計とソフトウェア設計の間の相互

依存関係を管理しなければならない．システム・レベルの設

計工程は，各ドメイン（設計領域．たとえばソフトウェア設

計，ディジタル回路設計，機構設計など）におけるコア・コン

ピテンシを維持し，適切に処理を行う一方で，各工程間のコ

ミュニケーションやデータの受け渡しが円滑に行えるものであ

るべきだ．

システム・レベル設計の領域は，それ自身のなかに複雑な

課題を抱えている．非常に抽象度の高い要求を詳細な仕様に

ブレーク・ダウンしたり，あるいはそれをもとに実際の回路

やソフトウェアを作成していく際に，さまざまな抽象度でそ

の設計対象を表現することになる．異なるドメインの間でそ

れぞれの要求を伝え合うことは，（かりに設計の抽象度が同じ

であったとしても），とてつもなくたいへんな作業である．た

とえば詳細なハードウェアの仕様が言葉でつづられた文書と

してハードウェア設計チームに渡されたとしよう．ハードウェ

アの設計チームはこの文書を正�

し�

く�

読解し，そのハードウェ

アを正�

し�

く�

実装しなければならない．

ただし，仮想プロトタイプ（ハードウェア・ソフトウェア協

調検証）や実行可能な仕様書（システム・レベル設計言語）と

いった新しい技術が登場したおかげで，抽象度のギャップを

埋めたり，文書のあいまいさをなくす作業はやりやすくなっ

ている．

●理想のシステム・レベル設計フローを考えるシステム設計工程では，各ドメイン，各設計抽象度の間で

互いに協調し合ったり，不具合の原因を求めて互いに設計情

報をトレースし合う必要があるが，その一方でさまざまなド

メインや設計工程（要求分析，機能設計，アーキテクチャ設

計，実装設計）の間を，設計者が自由に行き来するための仕

組みが用意されるべきである．理想的な設計工程を実現する

には，工程の各段階ごとにツールが用意されるとともに，効

果的なシステム・レベル設計工程を構築するための基本ブロ

ックが提供されなければならない．

�要求分析に対する要件

要求分析フェーズは非常に重要である．というのは，この

段階で，そのほかの工程の優先順位をどうするか，各要求間

の相互依存関係をどうするかが決まるからである．ただし，

その要求が実現可能であるかどうかを検証するためには，機

能設計工程や実装設計工程からのフィードバックを得ること

が不可欠になる．したがって，要求を定義したり，管理する

ツールは，機能設計工程や実装設計工程とのコミュニケーシ

ョンを円滑にする機能を備えていなければならない．このよ

うな工程間の連携機能をもつツールがあれば，実現不可能な

要求（たとえば，時間的な制約や技術上の制約）の修正が先送

りにされ，後の工程，ことによると実装設計工程までその要

求が残ってしまう，といったトラブルを最小限に抑えること

ができる．

�機能設計に対する要件

機能設計フェーズで使われるツールは，要求をより詳細な

仕様，つまり実現されるべき具体的な“what（もの）”にスム

ーズに変換する機能を備えるべきである．そして仕様の表現

形式は，言葉でつづられた文書に限定するべきではない．そ

うではなく，ツールはシステムを抽象的な形でモデル化した

り，機能のよしあしを検証できなければならない．このレベ

ルでは，さまざまなツールや手法を用いることができる．た

とえばC言語やC++言語でカスタムの機能モデルを開発した

り，UML（unified modeling language）をはじめとするそ

のほかのモデリング言語で開発することが考えられる．多く

のアルゴリズムもまた，機能レベルで開発されている．

機能設計フェーズでは，機能仕様を明確に示すため，ビジ

ュアル・ツールやグラフィカル・ツールに対する要求もある．

これによって，まちがって動作速度の要求を満足していない

機能を実装してしまうといったトラブルを減らすことができ

る．こうしたツールはアーキテクチャ設計フェーズのツールと

統合し，連携することも必要である．一般に，機能設計フェ

ーズとアーキテクチャ設計フェーズの間で並行作業や繰り返

し作業が発生することは珍しくない．

�アーキテクチャ設計に対する要件

アーキテクチャ設計フェーズで使われるツールは，システム

を物理的に実現するための“how（方法）”を明示したり，理解

しやすくするための機能を提供する必要がある．こうしたツ

ールが実用になるためには，アーキテクチャの性能に問題が

ないかどうかを評価できなければならない．アーキテクチャを

評価する際には，機能以外の特性（システムのスループット，

コスト，消費電力，設計の複雑さ，およびプロセッサの稼働

率）を分析し，これらを元のシステム要件と比較する．アーキ

テクチャ設計に関するツールは，設計の抽象度を下げなくて

もこうした属性を比較できるようなメトリックスを提供しなけ

ればならない．

メトリックスを評価するときは，複数のアーキテクチャ（の

候補）に対して行う．したがって，どのようなアーキテクチャ

であっても，すばやく入力・編集し，解析できなければなら

ない．アーキテクチャ設計はシステム全体を対象にすること

が多いが，それほど重要ではない小規模なエレメントを抽象

化したり，あるいはこれらを「ブラックボックス化」する余地

を残しておく必要がある．またアーキテクチャに関する記述

には，回路を構成したり，分割する方法についての決定事項

が含まれる．そのため，アーキテクチャを表現・伝達するた