cpu開発へのumlを用いたmdd 適用 -...
TRANSCRIPT
東海大学 2007年度 卒業研究
CPU開発へのUMLを用いたMDDの適用
指導教員 清水尚彦 教授
3ADT2224 松永健人東海大学 電子情報学部 コミュニケーション工学科
1
目 次
1 はじめに 5
2 UML 5
2.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 UMLのメリット・デメリット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 UMLの表記法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 MDD 7
3.1 MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 オブジェクト指向 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 オブジェクト指向の概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 CPU設計 9
4.1 開発工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 要求分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.3 システム分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1 画像システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3.2 音声システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3.3 ユーザ操作入力システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3.4 ゲームシステム全体 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 システム設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4.1 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4.2 その他のシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 モデル検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 CPUコーディング 29
6 ハードウェア開発における
MDDのメリット・デメリット 30
7 まとめ 31
2
図 目 次
1 開発プロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 ゲームシステム ユースケース図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 「操作情報を提供する」のユースケース記述 . . . . . . . . . . . . . . . . . . . . . 104 「ゲーム状態を伝える」のユースケース記述 . . . . . . . . . . . . . . . . . . . . . 105 「ゲームのルール・環境を提供する」のユースケース記述 . . . . . . . . . . . . . 106 画像システム分析ユースケース図 . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 音声システム分析ユースケース図 . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 ユーザ操作入力システム ユースケース図 . . . . . . . . . . . . . . . . . . . . . . 139 ゲームシステム全体 ユースケース図 . . . . . . . . . . . . . . . . . . . . . . . . . 1410 画像システム シーケンス図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511 音声システム シーケンス図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612 ユーザ操作入力システム シーケンス図 . . . . . . . . . . . . . . . . . . . . . . . 1713 本研究におけるシステム設計の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . 1814 CPUユースケース図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815 図 14の「命令を実行する」のユースケース記述 (ADC命令および AND命令の部分) 1816 CPUクラス図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917 CPU命令実行クラス ステートマシン図 (ADC命令および AND命令の部分) . . 2018 CPU命令実行クラス ステートマシン図 . . . . . . . . . . . . . . . . . . . . . . . 2119 CPU操作対象指定クラス ステートマシン図 . . . . . . . . . . . . . . . . . . . . 2220 CPU制御クラス ステートマシン図 . . . . . . . . . . . . . . . . . . . . . . . . . 2321 CPUレジスタクラス ステートマシン図 . . . . . . . . . . . . . . . . . . . . . . . 2422 CPU演算クラス ステートマシン図 . . . . . . . . . . . . . . . . . . . . . . . . . 2423 CPUデコーダクラス ステートマシン図 . . . . . . . . . . . . . . . . . . . . . . . 2424 PPU クラス図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2525 APU クラス図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3
表 目 次
1 命令実行クラスの動的検証例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 ハードウェア開発における UMLを用いたMDDのメリット . . . . . . . . . . . . 303 CPUパッケージ内クラスの 1回目の動的検証結果 . . . . . . . . . . . . . . . . . . 304 CPUの全動的検証数のうちの全異常動作割合 . . . . . . . . . . . . . . . . . . . . 305 ハードウェア開発における UMLを用いたMDDのデメリット . . . . . . . . . . . 31
4
1 はじめに
今日、半導体技術の発展と共に高機能・高性
能な組込みシステムの開発が行われるようにな
りその上、開発期間の短縮も求められている。
現在、ソフトウェア開発では UML(UnifiedModeling Language：統一モデリング言語)を用いての開発やCASE(Computer Aided SoftwareEngineering:コンピュータ支援ソフトウェア工学)ツールを用いての開発方法が存在する。また、MDA(Model Driven Architecture:モデル駆動アーキテクチャ)を適用してのMDD(ModelDriven Development:モデル駆動開発)の試行も行われはじめている。しかしながら、ハードウェ
ア開発ではこれらの事例は少ない。
ハードウェア開発では、SystemCやSystemVer-ilogといった、RTL(Register Transfer Level)よりも抽象度の高い ESL(Electoronic SystemLevel) 言語を使っての開発や、C ベース設計による開発といったものはある。しかし、Sys-temC や C ベース設計で開発を行う場合にはVerilogHDLまたはVHDLなどのHDL(HardwareDescription Language:ハードウェア記述言語)、Cまたは C++及びモデルの記述方法といった知識を必要とする。その結果、SystemCや Cベース設計による開発を行うためには、ハード
ウェア開発者の場合はソフトウェアプログラミ
ング言語とモデルの知識を学び、ソフトウェア
開発者はハードウェア記述言語とモデルの知識
を学ぶ必要がある。また、SystemCでの開発において、必ずしも SystemCから RTLを自動合成できるとは限らない。他にも、従来のハード
ウェア開発方法では統一されたモデル記述方法
がなく、要求分析といった抽象度の高い段階で
の表記法も確立されていない。
そこで、本研究では UMLを用いたMDDの適用をハードウェア開発において行った。その
結果得られたメリット・デメリットについて述
べる。
2 UML
2.1 UML
UMLとは、システムの分析、設計、実装などを円滑に進めるために作成するモデルの表記
法を定義したものである。UMLは、オブジェクト指向技術の標準化を進めるOMG（ObjectManagement Group）[8]によって、仕様が策定されている。UMLはモデリング（modeling）のための言語であり、ある対象 (オブジェクト)を図や文字で表現しモデル（model）を作成することができる言語である。システム開発にお
いて、モデルの対象となるのはシステムである。
UMLによって定義されているのはモデルの表記法だけであり、システム開発のための方法
論（開発の手順や管理方法）は含まれていない。
そのため、実際のシステム開発では、UMLとは別に、開発を進めるための開発方法論が必要
となる。UMLは、表記法の範囲内であれば、どのようなシステムのモデルでも作成すること
ができる。しかし、オブジェクト指向（object-orientation）をベースにしているので、オブジェクト指向言語や、オブジェクト指向開発などで
利用するとより高い効果を発揮する。[4]
5
2.2 UMLのメリット・デメリット
UMLの最大の特徴はまず「統一モデリング言語」の名の通り、複数の表記法を統一して作
られたという経緯があるので、世界的な標準モ
デリング言語として利用されているとこにある。
UMLには、システムを分析、設計、実装するために、誰にでもわかりやすい共通の表記法が
定義されている。これを利用することで、ユー
ザと開発エンジニア間のコミュニケーションだ
けでなく、開発エンジニア間のコミュニケーショ
ンも円滑になる。表記に図を使うことによって
対象の全体の理解を感覚的にすることが可能に
なる。また対象の抽象度を変更することも出来
るため、モデリングしたい対象の全体から、細
かな仕様まで記すことが出来る。
UMLに定められているのは表記法である。したがって、UMLだけではシステム開発を行うことができない。実際の開発においては開発方
法を別途選択する必要がある。UMLには複数の図が用意されているが、必ずしもすべてを利
用する必要はないが、それぞれのシステムに必
要な UMLの図を選択する能力が求められる。
2.3 UMLの表記法
UMLの図の表記には大きくわけて、システムの振る舞いをモデルで表現する振る舞い図と、
システムの静的な構造をモデルで表現する構造
図の２種類がある。振る舞い図ではシステムの
動的な変化や相互作用に焦点を当て、構造図で
はシステムの静的な構造に焦点を当てている。
振る舞い図
• ユースケース図：システムに要求される機能を、ユーザの視点から示した図。
• アクティビティ図：システムが起こすアクションの実行順序を示した図。
• シーケンス図：オブジェクト間の相互作用を時系列に示した図。
• ステートマシン図：システムの状態と状態遷移を示した図。
• コミュニケーション図：オブジェクト間の相互作用をオブジェクト間に着目して
示した図。
• タイミング図：相互作用と状態遷移に関する時間制約を示した図。
• 相互作用概要図：相互作用の実行順序を示した図。
構造図
• オブジェクト図：実際の物と情報とその関係を示した図。オブジェクト図は
• クラス図：システムを構成するクラスとクラス間に存在する関係の構造を示した図。
• パッケージ図：クラス図の一部でモデルの要素を分類するパッケージを示した図。
• コンポーネント図：物理的な構成要素からシステムの構造を示した図。
• コンポジット構造図：クラスやコンポーネントの内部構造を示した図。
• 配置図：システムの物理的な構造を示した図。
6
3 MDD
3.1 MDD
MDDとは、UMLを定義した OMG[8]が提唱するオブジェクト指向のモデリング方法論で
ある。MDDを用いるのは、成果物に相互運用性、再利用性および移植性を持たせるという３
つの目的があるためである。MDDではこれらの目的を達成するために、下記の３つのモデル
が定義されている。
• CIM(Computation Independent Model)システムとシステム運用に対する要求を
記述するモデルであり、プラットフォー
ムとは独立したシステムを規定するため
実装技術については触れない。
• PIM(Platform Independent Model)CIMに基づいたシステムの構築方法を記述するモデルであり、プラットフォーム
を規定するが特定のプラットフォームに
対する実装技術には触れない。
• PSM(Platform Specific Model)PIMに基づいたシステムを特定のプラットフォームで実現するための方法が詳細
に記述されているモデルである。
上記のモデルの条件を満たした上で、抽象度
の高いモデルから低いモデルへと抽象度を段階
的に落としていく。これによって、開発により
得られる成果物には、相互運用性、再利用性お
よび移植性が付加される。
MDDは、オブジェクト指向のソフトウェアを開発する考えが広まっていることもあり、ソ
フトウェア開発に用いられている。ソフトウェ
ア開発にMDDを用いることで下記のメリットが得られる。
• オブジェクト指向に沿った設計が可能
• ソフトウェアの設計図を得ることが可能
• モデルを使用することによるコミュニケーションの向上が可能
• モデルコンパイラを使用することで人的ミスの解消と開発期間の短期化が可能
ハードウェア開発にMDDを用いた場合、上記のソフトウェア開発でのメリットに加え、ソフ
トウェアと同じモデリング言語を用いて開発す
ることによりソフトウェア開発者とハードウェ
ア開発者間での意思の疎通を容易にすることが
可能である。
3.2 オブジェクト指向
UMLはオブジェクト指向をベースとしたモデリング言語なので、UMLのメリットを最大限引き出すには、オブジェクト指向の概念を
理解しておくことが必要である。人間が考える
単位であるモノやコトの単位を、システム開発
でも利用しようというのが、オブジェクト指向
の考え方である。オブジェクト指向を採用する
ことで現実世界をシームレスにシステム化する
ことが可能になる。この結果、システムの仕様
変更が必要になった場合、変更箇所に該当する
システム内のオブジェクトを修正すれば対応が
可能になる。
オブジェクトは振る舞いや属性などの特性を
持ち、オブジェクト指向でシステムを開発する
場合は、システム内部のオブジェクトがこのよ
うな特性や責任を持つ必要がある。オブジェク
ト指向では、1つのオブジェクト内に属性（データ）と振る舞い（プロセス）を両方含んでいる
ため、システムに変更があった場合、該当する
オブジェクト単位で変更すればよいので、変更
箇所が最小限に抑えられることになる。
7
3.3 オブジェクト指向の概念
オブジェクト指向の利点を理解するには、オ
ブジェクト指向の特徴を活かしてシステムを開
発する必要がある。オブジェクト指向のポイン
トを次に挙げる。
• 属性（property） 属性とは、オブジェクトが持つ構造上
の特性のことである。属性は、名前と値
を持ち、値は数字や文字列などで表せる。
後述するカプセル化を行うと、オブジェ
クトの外部から属性の値を直接変更でき
なくなる。
• 振る舞い（behavior） 振る舞いはオブジェクトが持つ動作上
の特性で、操作とも呼ばれる。振る舞い
は可視性によって、外部から呼び出す際
の制限を定義できる。振る舞いは、他の
オブジェクトや自分自身からメッセージ
を受け取ることによって呼び出される。
• 責任（responsibility） オブジェクトの責任とは、オブジェク
トが果たすべき役割を表す。例えば、「画
面表示」というオブジェクトは、画面に文
字や図などを表示するという責任を持ち
ます。オブジェクトの責任を実現するた
めに不要な振る舞いや属性は、オブジェ
クトに追加するべきではない。
• 抽象化（abstraction） 1つのシステムは膨大な数のオブジェクトによって構成されるが、それらの仕
様を 1つ 1つ定義することは困難である。そのため、登場するオブジェクトの振る
舞いや属性の共通部分を抽出して、枠組
みを定義する必要がある。この枠組みの
ことをクラス（class）といい、クラスを定義しておけば、様々な状況に応じたオ
ブジェクトをクラスから生成することが
出来る。オブジェクトからクラスを抽出
して、一般化することを、抽象化という。
• カプセル化（encapsulation） カプセル化とは、そのオブジェクトに
関する操作と属性を 1つのまとまりとして扱うことである。これにより、同じ概
念が持つ操作と属性をひとまとめにして
扱うことができるので、システムの保守
性、再利用性の向上につながる。
8
4 CPU設計
本開発の対象であるゲームシステムの開発プ
ロセスを図 1 に示す。組み込みシステムではPSMの段階で外部デバイスに依存する部分が多いため、機能のみを追及していった場合、PIMを PSMへ変換する際にデバイス情報の欠如といった問題が生じる。この問題に対し本開発プ
ロセスでは、モデル化の視点を要求された機能
を提供する側であるアプリケーション側とデバ
イス特有の使用に沿ってデバイスの制御を提供
する側であるサービス側の 2つに分けて開発を行うことで、組み込みシステム特有の問題を解
決する。
������� ��������� �������� ����������
CIM PIM PSM
�������������! "$#!%
& �('*)"�#+%
,�-+.0/
1+2 % )*3�4102 % )+506(78:9�;�<!=0>
,�- 7*?�@:A!B0C ,:- 7*?�@(A =0>D�E
1+2 % )!506�B0C F�G+H 0I*J:�!J+K�L
M 1 J
N:OQP R0SUT �0):V+� " W�X1+2 G I
図 1: 開発プロセス
4.1 開発工程
MDDを用いた本開発のプロセスは以下の通りである。
1. 要求分析 (CIM)ゲームシステムに対して何をしたいか、
何をさせたいかを明らかにし、要求を明
確にする。
2. システム分析要求分析で示した要求の概念構造の理
解をすることを目的とする。
3. システム設計 (PIM)概念構造を示したCIMから設計構造に
移行したゲームシステムに対してどうし
たいか、どうさせたいかを重点的に考え
設計を行い、6502 命令互換 CPU(以下、CPU)の最適な実装構造を表現する。
4. モデル検証システム設計で作成したモデルの動的
検証と静的検証をする。
5. 実装・テスト (PSM)ハードウェアソースコード (HDL)を作
成し、FPGA(Field Programmable GateArray)への実装とテストを行う。その際、ハードウェアソースコードは合成ルール
に基づいてモデルを合成することで作成
する。
4.2 要求分析
要求分析は、CIMに相当する。要求分析ではシステムに対して何をしたいか、何をさせた
いかを明確にし、要求の理解を目的とし分析を
行った。ゲームシステムに対してユーザが要求
するものとして図 2 のユースケース図を作成した。
ユースケース図では関連という実線で、アク
タ (システムを操作するユーザ、対象のシステムと関連する外部システムなどを表す)とユースケース (システム内部の要素)の関係を表す。外部システムとしてアクタにユーザ操作入力
システム、画像表示システム、音声出力システ
ム、ゲームデータ入力システムをおき、要求を
示した。
���������������� ����������
������������� �
������ ���!�"�# ����� �
������$�%���&�'��
����� ����� �
(�)�*�+ ���������
, ��- (�) "�# ����� �
, ��-
.�/�0 # ����� �
図 2: ゲームシステム ユースケース図
9
また作成したユースケース記述を図 3,図 4,図 5に示す。ユースケース記述とは対象となるユースケースの内容を詳細に記述するものであ
る。
以上によりゲームシステムに対しての要求を明
確化した。この要求を基にシステム分析に移行
しユースケース図やクラス図を用いて各システ
ムの詳細化を図った。
ユースケース名 操作情報を提供する
関連アクター ユーザ
目的 ユーザの操作情報がゲームシステムに伝わる。
事前条件 なし
基本フロー 1. ユーザ操作入力システムに操作情報を伝える。
2. 操作情報をゲームシステムに伝える。
事後条件 なし
例外処理 ゲームシステムにユーザの操作情報が伝わっていない場合はユーザは再度「操作情報を提供する」を行うことができる。
図 3: 「操作情報を提供する」のユースケース記述
ユースケース名 ゲーム状態を伝える
関連アクター 画像表示システム, 音声出力システム
目的 ユーザにゲーム状態が伝わる。
事前条件 なし
基本フロー 1. ゲームデータとユーザの操作情報を基にゲーム状態を作る。
2. 画像情報を画像表示システムに音声情報を音声出力システムに伝える。
事後条件 なし
例外処理 「フロー 2」が出来ない場合は終了する。
図 4: 「ゲーム状態を伝える」のユースケース記述
ユースケース名 ゲームのルール・環境を提供する
関連アクター ゲームデータ入力システム
目的 ゲームのルール・環境が提供される。
事前条件 なし
基本フロー 1. ゲームのルール・環境が提供される。
事後条件 なし
例外処理 「フロー１」ができない場合は終了する。
図 5: 「ゲームのルール・環境を提供する」のユースケース記述
10
4.3 システム分析
システム分析では、要求分析で示した要求の
概念構造の理解をすることを目的としている。
要求分析で示したユースケース図を基に、シス
テム全体を画像システム、音声システム、ユー
ザ操作入力システムの 3つのサブシステムに分けて考え、それぞれユーザとの一対一でシステ
ム分析を行い、最後にゲームシステム全体とし
てのシステム分析を行った。
�������������
�������� �
�������������
����� �� ��� ! ��"������ �� ���
���$#�%���&�'���� ( #�%���&�'����
) ( #�%���&�'����
*�+�,�-��$.�/��
0 " ��1 #�%���&�'����
������2�3 ����� �
�� �$4�5����
� � ! 76 �$�������
�� �98�:����
図 6: 画像システム分析ユースケース図
4.3.1 画像システム
サブシステムの 1つ、画像システムのシステム分析を行った。ここでは、アクタをゲーム
プレイヤー、ゲーム処理システムとおき、画像
システムの概念構造を示した。
主なユースケースとして、ゲーム処理システ
ムの「画像を作成する」と、ゲームプレイヤー
の「画像を取得する」がある。さらに「画像を作
成する」では、ゲームシステムの仕様での画像
作成の概念構造に伴って、図 6のようになった。
11
4.3.2 音声システム
サブシステムの 1つ、音声システムのシステム分析を行った。ここでは、アクタをゲームプ
レイヤー、ゲーム処理システムとおき、音声シ
ステムの概念構造を示した。
主なユースケースとして、ゲーム処理システ
ムの「音声を作成する」と、ゲームプレイヤー
の「音声を取得する」がある。さらに「音声を作
成する」では、ゲームシステムの仕様での音声
作成の概念構造に伴って、図 7のようになった。
図 7: 音声システム分析ユースケース図
4.3.3 ユーザ操作入力システム
サブシステムの 1つ、ユーザ操作入力システムのシステム分析を行った。ここでは、アクタ
をユーザ 1P、ユーザ 2P、ゲーム機とおき、ユーザ操作入力システムの概念構造を示した。
主なユースケースとして、ゲーム機の「コマ
ンドを判定する」と、ユーザ 1P2P の「1P2Pコマンドを入力する」がある。さらに「コマン
ドを判定する」「1P2Pコマンドを入力する」では、NESの仕様での操作入力の概念構造に伴って、図 8のようになった。
12
4.3.4 ゲームシステム全体
画像システム、音声システム、ユーザ操作入力
システムと分けて考えたものを、ゲームシステ
ム全体としてまとめ概念構造を示した。ここで
は、クラス図を用いてシステムの構成物を抽出
し、それらの関係を整理することを目的とした。
図 8: ユーザ操作入力システム ユースケース図
クラスにどのような責任があり、責任を果た
すために、どのような「属性」「操作」が必要
かを考えた。また、分析クラスのクラス図なの
で、属性の可視性を private、操作は publicとして固定させた。クラス図の他に、各サブシス
テムの概念構造間の相互作用を時系列に示すた
め、シーケンス図を用いて作成した。
13
図 9: ゲームシステム全体 ユースケース図
14
図 10: 画像システム シーケンス図
15
図 11: 音声システム シーケンス図
16
図 12: ユーザ操作入力システム シーケンス図
17
4.4 システム設計
4.4.1 CPU
システム設計は、PIMに相当する。システム設計では、設計するシステムの構造の理解と
最適な実装構造の表現を目的として設計を行っ
た。設計の流れを図 13に示す。
���������� ��������
6502 ���� CPU ������ �� � ����� ����
�� �� ����
��� � �"! �$#�� ����
�� � �&%��('*)+$�&,.-
�� �./ '�0��� ���132 0���
�� �� � ��� ����CPU ��45+ �� �� � � �&,.-
CPU ��67
図 13: 本研究におけるシステム設計の流れ
図 13のシステム分析のユースケース図の作成では、図 14の CPUユースケース図を作成した。
CPU
�������������� ������� ��� ��������
������� ��!"��#
<extend>
$%�&�'�( ��������
)���* ��������
+, �
- � ������.
図 14: CPUユースケース図
図 14の CPUユースケース図では、CPUシステムの要求を示している。ここで、システム
分析にて CPUを具体的に 6502命令互換 CPUと決めた。CPUの仕様より記述したユースケース記述の一部を図 15に示す。また、ユースケース記述から作成したクラス図を図 16に示す。
ユースケース名 命令を実行する
関連アクター なし
目的 指定された命令を実行する。
事前条件 命令セットを CPUが取得している。
基本フロー 1. デコードを行う。
2. 操作対象指定を行う。
3. 命令を実行する。
(a) ADC命令を実行する。
i. アキュムレータ、操作対象指定によってフェッチされたメモリデータ及びキャリーフラグを加算する。
ii. 加算した結果をアキュムレータへ格納する。
iii. ネガティブフラグに、演算結果のビット 7を格納する。また、オーバーフローフラグに、演算結果が 0x7Fと 0x80をまたぐと 1、またがなければ 0を格納する。そして、ゼロフラグに、演算結果が 0x00なら 1、0x00以外なら 0を格納する。さらに、キャリーフラグに、ビット 7からの桁上げが発生すると1、発生しないと 0を格納する。
(b) AND命令を実行する
i. アキュムレータと操作対象指定によってフェッチされたメモリデータを論理和演算する。
ii. 演算結果をアキュムレータへ格納する。
iii. ネガティブフラグに、演算結果のビット 7を格納する。また、ゼロフラグに、演算結果が 0x00なら 1、0x00以外なら0を格納する。
事後条件 なし
例外処理 なし
図 15: 図 14の「命令を実行する」のユースケース記述 (ADC命令および AND命令の部分)
18
�������- �� ���� : 8bit+ � ������� �
( �� ����� : 8bit)
R2
R6
R5
R8
1
+ ��������� �
1
1
+ ����� �� �
+ �������� � �
R7
R9
+ ��������� ��� � �
1
1
1
1
1
+ !#"�$�% ��� %��'&�( � �
+ !)"�$�% ��� %��&�(+*', �1
1
+� ����� ������ �
+� ����� ��� ���
11+ !#"$�% ��� %��&�( � �
+ !#"�$�% ��� %��'&�(-*', �
1
1
+ ����� �&�(-*', �
R1
R4
1
+ �������� � �
1
+ ��������� �
+ ��������&�( � �
1
+��� %��'�� � �
+ ./01��'�� � �
+��� %���� ���
1 !#"�$�%- 2�3�4#56! � % : 8bit- 7 8 ��9�: $-!#"�$�% X : 8bit- 7 8 ��9�: $-!#"�$�% Y : 8bit+ 2�3 4#56! � %��;�< ��� ( 2�3�4)56! � % : 8bit)+ 7�8 ��9�: $-!#"�$�% X �;�< � � ( 7�8 ��9: $6!#"$�% X : 8bit)+ 7�8 ��9�: $-!#"�$�% Y �;�< � � ( 7�8 ��9: $6!#"$�% Y �;�< � � : 8bit)+ 2�3 4#56! � %��&�( ��� ()+ 7�8 ��9�: $-!#"�$�% X �&�( � � ()+ 7�8 ��9�: $-!#"�$�% Y �&�( � � ()
+ ��� ��� ���
R3
��������� - 2 � ! 9�= 8>�? ��� : 4bit- ��������� @!#"�$�% : 8bit- 2 � !A$��� 2 B#C : 8bit- 2 � !A$��� 2 D#C : 8bit- 2 � !A$��� 1 B#C : 8bit- 2 � !A$��� 1 D#C : 8bit+ ��������� ���EF � � ( 2 � ! 9�= 8�>�? �@� : 8bit)- ��������� GH�I���E'F � � ()+ �� �!)"�$�%��';�< � � ( �������� �!#"�$�% : 8bit)+ J�?LK ��� %��';�< � � ( �������� �!#"�$�% : 8bit)+ MN�>O5�P�Q8�%��;�< � � ( !#"$�% 2 B'C : 8bit, !#"�$�% 2 D'C : 8bit)+ 16bit �������;�< � � ( !)"�$�% 1 B'C : 8bit, !#"�$�% 1 D'C : 8bit)+ ��� RH�I � � ( ������� �!#"�$�% : 8bit)- ������S�G';�<���EF � � ()- J�?6K ��� %�G;�<���E'F � � ()- 7�8 ��9�: $-!#"�$�%�G';�<���E'F � � ()
���- 16bit ����!)"�$�% 1 : 16bit- 16bit ����!)"�$�% 2 : 16bit- 8bit ���@!#"�$�% 1 : 8bit- 8bit ���@!#"�$�% 2 : 8bit+ 16bit T����E'F � � (16bit ����!#"$�% 1 : 16bit, 16bit ����!#"�$�% 2 : 16bit)+ 8bit T����EF � � (8bit ����!)"�$�% 1 : 8bit, 8bit ����!)"�$�% 2 : 8bit)+ 8bit U����EF � � (8bit ����!)"�$�% 1 : 8bit, 8bit ����!)"�$�% 2 : 8bit)
CPU
.�/01- V�WX YZ[O�> : 1bit- � �\�� [N � [O�> : 1bit- Z�!]7 : [O�> : 1bit- 10 ^+[O�> : 1bit- 7�8%�OML_][�O�> : 1bit- �̀N�[O�> : 1bit- 3�a+K � [O�> : 1bit- 2 � ! 9�= 8�>? ��� !)"�$�% : 8bit- 2 � ! 9�= 8�>? ��� 2 � !A$ : 16bit- ./ : 6bit- ./�01�!#"�$�% : 8bit- b�3a-K � [O�> : 1bit+ $X � %�$ [O�>��&�( ��� ()+ 7�8�%OML_][O�>��;�< � � ( 7�8%�OML_][�O�> : 1bit)+ ������S��;�< � � ( 2 � ! 9�= 8>�? ��� !)"�$�% : 8bit)+ ������+2 � !A$�;�< ��� ( 2 � ! 9�= 8�>�? ��� 2 � !A$ : 16bit)+ ./0�1���EF ��� ( ./ : 8bit)- ./�01�GH�I��EF ��� ()+ MN�>O5�P�Q�8%�G&�( �H�I ��� ()+ $�% 9:�c���� %�G&�(��'H�I � � ()- $�% 9�:�d+e M�N�>�O5�P�Q�8�%�G';�<���E'F � � ()+ $�% 9:�d+e MN�>�O5�PQ�8�%�G';�<��H�I � � ()+ $�% 9: G ��� %��;�< ��� ( ./0�1�!#"�$�% : 8bit)+ �� �!)"�$�%�G&�(��H�I � � ()+ �� �!)"�$�%��;�< � � ( .�/01�!)"�$�% : 8bit)- J�?6K ��� %�G'&�(./ ��EF � � ()+ J�?LK ��� %�G&�(./��'H�I � � ()+ $�% 9:�f 7�8�%��;�< ��� ( ./0�1�!#"�$�% : 8bit)- 2�3 4#56! � %'g ��� %�G&�(���E'F � � ()+ 8bit �������;�< � � ( .�/01�!)"�$�% : 8bit)- [O�>�G�h� ���EF � � ()- ��� ��EF � � ()- = [6_�i+N � X ��=-j 8'��EF � � ()
+ $�% 9:�f 7�8�%�G&�(��'H�I � � ()
CPU kl- CPU kl�!#"$�% : 8bit- [O�>#m�n�!#"�$�% : 1bit- MN�>�O'5�P�Q�8% : 16bit- 2 � ! 9= 8�>+!)"�$�% : 4bit- ./�!#"$�% : 6bit- RESET [O�> : 1bit- NMI [O�> : 1bit- IRQ [�O�> : 1bit- BRK [O�> : 1bit- 2 � !A$-!#"�$�% : 16bit- J�?LK)2 � !A$ : 16bit- $�% 9�:f 7�8�% : 8bit- MN�>�O'5�P�Q�8%�[�o 9'p B'C : 16bit- MN�>�O'5�P�Q�8%�[�o 9'p D'C : 16bit+ 7�8�%�OM6_][O�>�G&�(��'H�I � � ()+ J�?LK ��� %��&�( � � (CPU kl@!#"�$�% : 8bit)+ Z�!A7 : [�O�>�G&�(��H�I � � ()+ J�?LK ��� %�G&�( �H�I ��� ()+ 8bit ��������;�< � � (CPU kl@!#"�$�% : 8bit)+ $X � %�$�[O�>��';�< � � (CPU kl�!#"�$�% : 8bit)+ 7�8�%�OM6_][O�>��;�< ��� ( [O�>#m�n�!#"�$�% : 1bit)+ 16bit ��������;�< ��� ( MN�>O5�P�Q8�% : 16bit)- q�r�s��'H�I � � ()+ � ����� �'H�I � � ( 2 � ! 9= 8�>+!#"$�% : 4bit, ./�!#"�$�% : 6bit)
+ RESET [�O�>��;�< � � (RESET [O�> : 1bit)+ NMN [O�>��;�< ��� (NMN [O�> : 1bit)+ IRQ [O�>��;�< � � (IRQ [O�> : 1bit)+ ���O�8 � �&�( ��� ()+ MN�>�O5�P�Q�8�%��&�( ��� ()+ J�?LK ��� %��&�( � � ( 2 � !A$6!#"�$�% : 16bit)+ �������� ��H�I � � ()+ ./01��'H�I � � ()+ $�% 9�:�d�e#��� %��;�< ��� ()+ $�% 9�:�d�e MN�>O5�P�Q8�%��;�< � � ()+ J�?LK ��� %�G&�(�./�� ��� ( J�?LK)2 � !A$ : 16bit, CPU kl�!#"$�% : 8bit)+ J�?LK ��� %�G&�(�R�H�I ��� ()+ $�% 9�:�f 7�8�%��';�< � � ( $�% 9�:�f 7�8�% : 8bit)+ MN�>�O5�P�Q�8�%���$�% 9:�c'tu���� ()+ MN�>�O5�P�Q�8�%��;�< ��� ( MN�>�O'5�P�Q�8% : 16bit)+ $�% 9�:�c#tu�� ���� %��';�< � � (CPU k�l�!#"�$�% : 8bit)
図 16: CPUクラス図
19
システム設計のクラス図作成において、クラ
スの数とそれぞれのクラスが持つ属性や操作の
数について考慮しながら、オブジェクト指向の
設計を行った。作成したクラス図はシステムの
静的な構造を表記している。そして、クラス図
とユースケース記述をもとに、クラスのステー
トマシン図を作成した。
ステートマシン図は、UMLで定義されているアクションセマンティクスに基づいた独自のアク
ション言語を用いた。また、ハードウェアの特性
を考慮し、REQ(request)とACK(acknowledge)の関係および動作タイミングに注意し、また論
理規模をできるだけ小さく作成することを考慮
して行った。作成した命令実行クラスのステー
トマシン図を、図 17に示す。ただし、処理を分かりやすくするため、ADC命令および AND命令と関係がある部分以外は省略している。
省略していない命令実行クラスのステートマ
シン図は図 18に示す。さらに操作対象指定クラスのステートマシン図を図 19に、CPU制御クラスを図 20に、レジスタクラスを図 21に、デコーダクラスを図 23に、演算クラスを図 22に示す。
図 17: CPU命令実行クラス ステートマシン図 (ADC命令および AND命令の部分)
20
図 18: CPU命令実行クラス ステートマシン図
21
図 19: CPU操作対象指定クラス ステートマシン図
22
図 20: CPU制御クラス ステートマシン図
23
図 21: CPUレジスタクラス ステートマシン図
図 22: CPU演算クラス ステートマシン図
4.4.2 その他のシステム
CPU以外のサブシステムのシステム設計を行った。まだモデリングの途中であるが、PPUクラス図の図 24と、APUクラス図の図 25を示す。
図 23: CPUデコーダクラス ステートマシン図
24
図 24: PPU クラス図
25
図 25: APU クラス図
26
4.5 モデル検証
モデル検証について述べる。モデル検証は視
覚的に下記の 2つを行った。
• 静的検証
クラスとステートマシンの整合性のチェッ
ク、UMLの記述方法に従っているかのチェック、およびワードのチェックなどの構
文的な検証を行う。具体的には、ステー
トマシン図のプロシージャで使用されて
いる属性やシグナルがクラスに記述され
ているか、アクションの文法は正しいか、
モデルは UMLの記述に従っているかを視覚的に検証した。
• 動的検証
図 15のユースケース記述からテストケースを抽出して入力を決め、入力に対する
正しい出力結果を明らかにする。また、関
連する属性の仮定値を決定する。そして、
ステートマシン図を用いてモデルを実行
し検証する。検証の際は開始シグナルを
入力値とし、引数があれば意図した値を
持たせる。命令実行クラスに対するテスト
事項と入力、出力の例を表 1に示す。表 1では、アキュムレータを 0b00001111、操作対象指定によってフェッチされたメモ
リデータを 0b00000001、全てのフラグは0b0と仮定して行った。
AND命令のテストを例にとると、図17命令実行クラスのステートマシンの開始シ
グナルは「命令実行を開始する (命令)」であり、設計上、AND命令の場合の引数 (命令)は 0b000011である。そのため、最初の入力は「命令実行を開始する (0b000011)」となる。そして、最終的には CPU 制御クラスの「命令実行を完了する ()」を呼んで終了となる。表 1は、他クラスからの入力、自身のクラスによるレジスタの
設定、および他クラスへの出力を示した
ものである。最後に「命令実行を開始す
る (0b000011)」をステートマシンに入力し、アクションに従って視覚的に追う。そ
して、表 1で示した出力となるかを検証した。
27
表 1: 命令実行クラスの動的検証例
事項 入力 出力
・命令実行クラスの命令実行を開始する ・レジスタクラスのアキュムレータを
(0b000001) 提供する ()・命令実行クラスの指定レジスタを
取得する (0b00001111)・命令実行クラスの 8bit演算結果を ・演算クラスの 8bit加算を開始する
ADC 取得する (0b00001111,0b00000001)命令 (0b00010000)テスト ・命令実行クラスの
オーバーフローフラグ→ 0b0 ・レジスタクラスのアキュムレータを
・命令実行クラスの指定レジスタの 取得する (0b00010000)提供が完了する ()・命令実行クラスの
ネガティブフラグ→ 0b0・命令実行クラスの ・CPU制御クラスの命令実行を完了する ()ゼロフラグ→ 0b1
・命令実行クラスの命令実行を開始する ・レジスタクラスのアキュムレータを
(0b000011) 提供する ()・命令実行クラスの指定レジスタを
取得する ・レジスタクラスのアキュムレータを
AND (0b00001111) 取得する (0b00000001)命令 ・命令実行クラスの
テスト 指定レジスタの提供が
完了する () ・CPU制御クラスの命令実行を完了する ()・命令実行クラスの
ネガティブフラグ→ 0b0・命令実行クラスの
ゼロフラグ→ 0b1
28
5 CPUコーディング
作成したシステム設計の PIMを合成ルール[1]に従って HDLにコード変換をする。HDLには SFLを使用し、UMLから SFLに合成するにあたって下記のようなルールを決めそれに
沿ってコードを記述した
UML(CLASS図)から SFLへの合成ルール
declare クラス名{
/* moduleの記述と同一なもの */
input in_属性名;
instrin パブリックな操作名;
/* 関連クラスについては、確実であるならば、
必要なものだけ記述する */
//CLASS クラス名
output 関連クラス名__関連クラスの属性名;
instrout 関連クラス名__関連クラスの操作名;
instr_arg パブリックな操作名 (in_属性名);
}
module クラス名{
/* declareの記述と同一なもの */
input in_属性名;
instrin パブリックな操作名;
reg reg_属性名;
sel sel_属性名;
instrself プライベートな操作名;
/* 関連クラスについては、確実であるならば、
必要なものだけ記述する */
//CLASS クラス名
output 関連クラス名__関連クラスの属性名;
instrout 関連クラス名__関連クラスの操作名;
instr_arg プライベートな操作名 (sel_属性
名);
//CLASS クラス名
instr_arg 関連クラス名__関連クラスの操作
名 (関連クラスのクラス名__関連クラスの属性
名);
stage_name クラス名_stage {task task1();}
par{
/* 並列処理の記述; */
}
instruct パブリックな操作名 par {
generate クラス名_stage.task1();
reg_属性名 := in_属性名;
}
instruct パブリックな操作名 par {
reg_属性名 := in_属性名;
}
/* ステートマシン図より記述する */
stage クラス名_stage {
state_name ステートマシン図のステート名
_entry,
state_name ステートマシン図のステート名
_do;
first_state ステートマシン図のステート名
_entry;
state ステートマシン図のステート名_entry par {
/* 振るまいの記述 */
プライベートな操作名 ();
29
any {
プライベートな操作名 : goto 次のステー
トマシン図のステート名_entry;
else : goto ステートマシン図のステー
ト名_do;
}
state ステートマシン図のステート名_do par{
if(パブリックな操作名) goto 次のステート
マシン図のステート名_entry;
}
}
}
6 ハードウェア開発における
MDDのメリット・デメリッ
ト
MDDを組込みハードウェア開発に適用した場合のメリットとデメリットを述べる。
表 2にハードウェア開発における UMLを用いたMDDのメリットを示す。要求からコード
表 2: ハードウェア開発における UMLを用いたMDDのメリット
工程 メリット
要求 ・ハードウェアを視覚的に
抽象度の高いレベルから
表現できる。
設計 ・統一した表記ができる。
・レビュー効率の促進。
テスト ・モデル (設計図)上で動作レベルのバグを修正できる
合成の手前までを一貫してモデルで開発を進め
ることが可能であり、完成したモデルはハード
ウェア技術者およびソフトウェア技術者双方に
とって統一した見解が可能な設計図となる。ま
た、動作レベルのバグであれば、モデル実行に
よるモデル上での修正が可能である。モデル実
行による CPUパッケージ内クラスの動的検証結果を表 3に示す。また、その結果の全異常検証数の割合を表 4に示す。
表 3: CPUパッケージ内クラスの 1回目の動的検証結果
検証クラス ステート数 [個] 検証数 [件]
CPU制御 47 28
デコーダ 1 151
操作対象指定 15 15
命令実行 22 57
演算 5 8
レジスタ 4 6
検証クラス 異常検証数 [件]
CPU制御 11
デコーダ 0
操作対象指定 14
命令実行 15
演算 2
レジスタ 0
表 4: CPUの全動的検証数のうちの全異常動作割合
全検証数 [件] 全異常動作割合 [%]
265 16
デコーダなどのステート数の少ない構造のク
ラスはテストケースをクリアすることができた
が、操作対象指定クラスは用意したテストケー
スの約 9割をクリアすることができなかった。最終的にCPUパッケージ内クラスの内、16%のバグを発見することができ、それらすべてを修
正することができた。
次に、表 5にハードウェア開発におけるUMLを用いた MDDのデメリットを示す。UMLは抽象概念のモデルであるため、クロックサイク
30
ルベース並の詳細な表現ができない。また、人
的に視覚的なモデル実行を行うため、人的負荷
が高く、完全にバグを発見することができない
可能性がある。さらに、UMLの表記法を習得する必要があり、そのための時間を要する。
表 5: ハードウェア開発における UMLを用いたMDDのデメリット
工程 デメリット
要求 ・特に無し。
設計 ・単一クラス内で並列動作を
行いたい場合、視覚的
に並列動作が見えにくい。
・クロックサイクルベース並の
詳細なタイミングを
表現することができない。
テスト ・モデル検証の人的負荷が高い。
・人的な検証では完全にバグを
発見することができない。
その他 ・表記法を学ぶ必要がある。
・表記法に沿ったモデルにする
ための人的負荷が高い。
7 まとめ
UMLを用いたMDDの適用を組込みハードウェアの開発において行い、そしてその結果得
たメリット・デメリットを明らかにした。示し
たデメリットの解決策として、クロックサイク
ルベース並の表現を必要とするのであれば、従
来から使用しているクロックサイクルベースな
どの図を併用すれば良い。ここまで詳細なレベ
ルの図はハードウェア技術者のみが知ることが
できれば良いと考えるからである。また、モデ
ル実行による人的負荷に関しては専用のツール
やモデルコンパイラなどを用いることで減らす
ことができる。
現在、開発はテストベンチを作成しテストを
行っているところである。今後 FPGAに実装して動作確認を行う予定である。また、本開発
において問題となった、人的負荷を解消するた
めのモデルコンパイラの開発 [1]および検証システムの開発も予定している。
31
参考文献
[1] 並木滋, 清水尚彦, ”モデルベース開発を適用するためのモデルコンパイラの開発”,第31回パルテノン研究会, 2007
[2] スティーブ J. メラー, マーク J.バルサー,”Executable UML”, 株式会社翔泳社出版,2003
[3] SESSAME WG 2, ”オブジェクト指向モデリング”, 株式会社翔泳社出版, 2006
[4] 株式会社テクノロジックアート, ”独習UML第 3版”, 株式会社翔泳社出版, 2005
[5] Russ Miles, Kim Hamilton, ”入門UML2.0”, オライリージャパン出版, 2007
[6] 浅井麻衣, 重田正俊, 橋本大輔, 浜口弘志,藤井啓詞, ”現場の UML モデルベース開発のすべて”, 株式会社ソーテック社出版,2006
[7] ”W65C02S 8-bit Microprocessor”,http://www.westerndesigncenter.com/wdc/documentation/w65c02s.pdf
[8] ”OMG”, http://www.omg.org/
[9] ”NES研究室”,http://hp.vector.co.jp/authors/VA042397/nes/index.html
[10] ”NES on FPGA”,http://crystal.freespace.jp/pgate1/nes/index.html
32