東海大学紀要情報通信学部
vol.6,No1,2013,pp.15-22

論文
UML と SysML を用いた視覚的なハードウェア設計・検証手法
狩野 大樹*1 ,清水 尚彦*2

The Methodology of Visual Hardware Design and Verification using UML and SysML
by

Daiki
Daiki KANOUKANOU*1

NaohikoNaohiko SHIMIZUSHIMIZU*2andandon March
AcceptedJuly
on July
2013）（Received
Received:
March 28, 20132013 & Accepted:
18, 18,2013

Abstract
We are developing the system-level design methodology with the high abstraction level, in order to raise the HW design productivity. In it, wedeveloped the method for hardware design using UML diagram. By using our methodology, we can design hardware with the system-level.
Furthermore, we experimented using our methodology. As a result, it turned out by automating the design verification in the hardware designthat HW design productivity is raised more. Then, we express hardware constraints visually using SysML, and propose the methodology of
performing design verification automatically.
Keywords: Hardware design, UML, SysML, design verification
キーワード:

ハードウェア設計，UML，SysML，設計検証
また，検証技術の解決策は未だ見当たらず，増大する半導体

1. 研究背景

設計の複雑度に追従できていない状況である．ITRS2011 によ1．研究背景ると，複雑な設計では開発プロジェクト内の検証エンジニアと半導体デバイスの微細化・高集積化により LSI の回路規模は

設計エンジニアの比率は 2:1 にも達し，設計作業の 50% 以上が著しく増大している．その結果，要求仕様やハードウェア/ソフ

検証に費やされているという 1) (Fig.2)．そのため，高抽象レベ

トウェアの仕様書の量も膨大なものとなっており，ソフトウェルによる新たな設計検証手法を確立することで，検証の信頼性

ア/ハードウェア両方の設計負担は増加している．ソフトウェア

を高めると共に検証工程を削減する必要がある．

開発では，UML 図を用いた抽象度の高いモデル駆動開発手法が提案されつつある．一方ハードウェア開発の現場ではレジスタ

1.1 システムレベル設計手法の開発
システムレベル設計手法の開発

転送レベル (RTL) の設計が主流である．抽象度の低い RTL 設
計では，仕様の間違った解釈やコーディングの不具合が起こり

本論文では，我々が開発している，UML を用いてハードウェやすくなる．仕様設計におけるバグが実装段階で発覚すると，アを上位の抽象レベルで設計する手法 3) について述べる．UML

対策に大きなコストがかかる．仕様設計レベルでのミスを減ら図の各図やその要素と高位レベルハードウェア記述言語 NSL4)

し，設計効率を向上させるためには，RTL よりも上位の抽象レの構文を対応するルールを定め，UML 図で実行可能仕様を実ベルでの設計を行うことが望ましい．

現する．また，この対応ルールに則って UML 図から NSL 記述

ITRS 2011 によると，現在実現可能な複雑度の LSI を効率的に開発するためには，今日の実に 50 倍もの設計生産性が必要だという 1) ．そのため RTL より高い抽象レベルで設計を行う記述を生成するコンパイラの開発を行う．ハードウェア記述言語と言語が提案されてきた．その中に，オブジェクト指向の分析・成が困難であること，NSL で記述されたコードはツールを用いしては，VHDL や VerilogHDL がよく用いられるが，これらの言語は UML のオブジェクト指向記述との解離が大きく直接生設計ができるモデリング言語「UML」2) がある．UML を用いて論理合成可能な VHDL や Verilog HDL, System C へと変換でてシステム仕様を記述することで，抽象度の高い記述を行うこきる 4) ので，FPGA 実装やソフトウェア協調シミュレーションとができる．また，抽象度の高いシステムレベル記述言語で記の実現が容易であることを勘案し生成言語として NSL を採用

述したコード生成可能な仕様書を「実行可能仕様」と呼ぶ．実した．

行可能仕様が実現できれば仕様書から曖昧さがなくなり，設計

また，我々は大きな工数がかかるハードウェア設計検証を視のやり直しが起きにくくなるため，設計生産性を向上させるこ

覚的かつ自動的に行う手法を開発している．本論文では，設計とができる．しかしながら，Fig.1 のように実行可能仕様による検証に用いるテストベンチプログラムやハードウェア制約をモデル駆動設計は未だ研究段階である．

UML を用いて表す手法 5) ならびに，組み合わせ回路のようなハードウェア制約を SysML6) のブロック定義図を用いて表す手*1 大学院 工学研究科 情報通信制御システム工学専攻

法について述べる．

*2 情報通信学部 組込みソフトウェア工学科-1-− 15 −

UML と SysML を用いた視覚的なハードウェア設計・検証手法

図との親和性が低く，UML 図との対応が上手く取れていない．

First Year of2011 2013 2015 2017 2019 2021 2023 2025
IC Production

例えば，この手法では UML クラス図におけるクラスの”操作”欄に VHDL の process 文の記述を行ない，”操作の引数”に process

System design
automation

文のセンシティビティリストの信号を記述している．クラス図の”操作”は，他のオブジェクトから呼び出されることで起動す

Executablespecification
Research Required
Development Underway
Qualification / Pre-Production
Continuous Improvement

る処理名とその引数を記述する要素であり，彼らの手法は UMLの概念と異なっている．

T. Schattkowsky は Handel-C をターゲット言語として，UML
図によるハードウェア設計手法を提案した 9) ．彼らはハード
ウェアの構造をクラス図，コンポジット構造図で表し，クラスのインスタンス関係をクロックドメイン図で表した．ハード

Fig.1 System-Level design potential solutions by ITRS 2011.1)

ウェアの振る舞いはアクティビティ図を用いている．彼らはアクティビティ図を階層的に用いることで，ハードウェアの振100%
verificationengineers
66%

designengineers
33%

0%

The engineer’s ratio
in the development projectof the complicated design

る舞い全体を表現している．そのため，この手法ではモジュー

verification
process50%

ル分割が行われないフラットなハードウェアが生成される．モジュール内にある機能毎の検証が出来ないためシミュレーショ
ン単位が大きいものとなり，検証工程が膨大になるという欠点を持つ．

designprocess50%

2.

システムレベル設計手法の開発
2．システムレベル設計手法の開発
本論文で提案する，UML や SysML を用いシステムレベルで

desgin time

ハードウェア設計を行う手法について述べる. 本章では，システ
ムレベル設計手法の工程と UML を用いたハードウェア設計手法を示す．

Fig.2 The ratio of the verification cost.1)

2.1 システムレベル設計の工程
システムレベル設計の工程
2.1

さらに，当設計手法に対する実証実験により設計手法を評価

システムレベル設計の工程を Fig.3 に示す．

した．実験では，同じ仕様のハードウェアをレジスタ転送レベルと当設計手法を用いてそれぞれ設計し，性能や設計時間を比(1) システム要求分析・システム仕様定義
SysML を用いて開発対象のシステム要求分析とシステム仕

較した．

2 章では，我々が開発している UML を用いたハードウェア

様定義を行う 10) ．

設計手法について述べる．3 章では，UML と SysML を用いた

(2) ハードウェア・ソフトウェア機能分割次に SysML により２つの設計検証手法について述べる．4 章では，当設計手法に分析した各機能をハードウェアとソフトウェアどちらで実対して行った実証実験について述べる．

装するか定め，機能分割を行う．

1.2 類似の研究
類似の研究

(1)

過去に提案された UML 図を用いたモデルベース設計手法をSystem Specification Definition

Analysisusing SysML

いくつか紹介し，当設計手法との相違点を挙げる．

E.Riccobene は UML 図を用いたシステムレベルのハードウェ

System Requirements Analysis(2)

ア設計手法を提案した 7) ．ターゲット言語は System C であり，Hardware / Software partitioning

彼らは System C と UML 図の対応ルールを示した．この手法
ではハードウェアの構造をクラス図で表し，振る舞いはステー

Design HWusing UML

トマシン図を用いて表している．しかしハードウェアの振る舞い記述は，ステートマシンの do ラベルのアクションとしてSystem C のコード記述を直接関連付けている．そのため振る舞We built
the SCE-MI
environment.

いの視覚化がなされていない．また，一般に System C で設計されたコードは論理合成サブセットを満たさないため，シミュ(3)
Hardware design(4)
Hardware / Software Co-verification

レーションを行うに留まる．

Moreira T.G は UML 図から VHDL 記述を生成する手法を提案した 8) ．しかし VHDL は抽象度が低い言語であるため UML

Fig.3 The flow of System Level design.

-2-− 16 −

softwaredesign狩野大樹・清水尚彦(3) ハードウェア/ソフトウェア設計
機能分割によって割り振られた機能を UML および SysML

3.1
波形シミュレーションを用いた設計検証手法
3.1 波形シミュレーションを用いた設計検証手法

を用いてハードウェア/ソフトウェアでそれぞれ設計し，実波形シミュレーションを用いた設計検証の流れを Fig.6 に示装および検証を行う 3) ．システム分析では SysML を用いて分析するため，ハードウェア設計で用いるハードウェア仕す．UML 設計を行った後，設計者はテストベンチプログラムを様は SysML 図で表されている．この分析された SysML を

NSL で記述する．次に任意のツールを用いてシミュレーションを行い，波形データを生成する．設計者は生成された波形デー

さらに詳細化し，ハードウェア設計レベルまで落としこむ．

タを元に，自らが理解している仕様通りの動作をしているか確(4) ハードウェア/ソフトウェア協調検証

認する．

ハードウェアとソフトウェアの設計が進んだところで，シ

一般に，設計者が仕様を間違って解釈していた場合，検証のステム検証のためハードウェアとソフトウェアの協調検証
を行う

11)

段階でバグを取り除くことが困難となる．また，テストベンチ．

記述は手書きでコーディングするため，検証工程が複雑になる．
これらは設計生産性の観点からも大きな問題である．我々はこ以上が我々の開発しているシステムレベル設計手法の工程でれらの問題を解決するため，UML と SysML を用いて設計検証ある．本論文ではハードウェア設計に着目し，ソフトウェア設計については述べない．

を自動化する．

2.2 UML を用いたハードウェア設計手法を用いたハードウェア設計手法

3.2 UML
3.2
UML を用いた設計検証手法
を用いた設計検証手法
本論文が提案する UML を用いた視覚的な設計検証手法 5) に

本項では，本論文が提案する前項の Fig.3(3) の UML を用いついて述べる．この手法は，シミュレーション時に用いるテス

たハードウェア設計手法 3) について述べる．我々は UML の要

トベンチと設計するハードウェアの制約を UML で表し，シミュ素とハードウェアの対応ルールを定めることで UML でハード
ウェアの構造と振る舞いを表現する．この手法を用いたハード
ウェア設計の工程を Fig.4 に示す．

System level
Hardware specification Analysis(using SysML and UML)

SysML を用いて要求仕様を分析し，機能分割でハードウェアに割り当てられたものがハードウェア仕様となる．
ハードウェアは対応ルールに則り，UML のクラス図，アクティビティ図，ステートマシン図を用いて表現する．設計者はSystem level
Hardware design and Verification(using SysML and UML)

クラス図を用いてハードウェアの静的構造を表し，アクティビ
ティ図とステートマシン図を用いてハードウェアの振る舞いと状態遷移を表す．ハードウェアを記述した UML は，我々が開発している UML コンパイラによって NSL 記述に変換される．

Structure

behavior

UML class

UML activity & State

さらに NSLcore4) を用いて NSL 記述を論理合成可能な Verilog

HDL や VHDL に変換し，FPGA に実装する．以上が当設計手

automation法を用いたハードウェア設計の流れである．

Fig.5 に VGA コントローラの機能の一つを表した UML と，
この UML を自動変換して得られる回路図を示す．この機能はusing our UMLcompiler

VGA コントローラの縦側表示区域の制御を行うものである．

Behavioral sysnthesis level

VGA コントローラの表示制御機能の構造と振る舞いを記述した UML は，我々の手法を用いることで Fig.5 右のようなゲー

NSL code

トレベルの回路図に自動変換され，FPGA に実装される．UML

using NSLcoreと回路図によって抽象レベルが大きく異なることが分かる．

Register transfer level

このように，我々の手法を用いることで抽象度の高いハード

Verilog HDL or VHDL code

ウェア設計が可能となる．

3．UML と SysML を用いた自動的な設計検証

Gate level

3. UML と SysML を用いた自動的な設計検証手法の開発
手法の開発

on the FPGA

本章では，本論文が提案する UML と SysML を用いた２つの設計検証手法について述べる．２つの設計検証手法はそれぞ

Fig.4 The flow of the hardware design method using the UML
diagram which we developed.

れ表現できるハードウェア制約に対する得手不得手があるため，設計対象のハードウェアの性質によって手法を使い分ける．

-3-− 17 −

UML と SysML を用いた視覚的なハードウェア設計・検証手法

V_count+ VS : output[1]+ VB : output[1]+ start()

auto generate
start[V_reg == 524]
[V_reg == 479]

[V_reg == 524]

V_reg := 0

V_reg++[V_reg == 489]

V_BLANK := 1

[V_reg == 491]

V_SYNC := 1

V_SYNC := 0

V_BLANK := 0(a)
The class and activity diagram expressing the v_count of the VGA controller(b)
The circuit diagram expressing the v_count of the VGA controller

Fig.5 Automatic conversion on the gate level from the system level.

ションツールによってシミュレートし，シミュレーション結UML diagram

果をテキストファイルで出力する．最後に，出力されたシミュ
レーション結果とハードウェア制約を示した中間ファイルを比UML2NSL(out tool)

較することで設計検証を行う．

NSL description

Test Bench program(Hand writing)

このように UML を用いてハードウェア制約とテストベンチ
を表し，設計検証の流れを自動化する．
ハードウェア制約，テストベンチ，ハードウェアを記述した

UML の例を Fig.8 に示す．ハードウェアの例として 4bit 加算器を用いている．4bit 加算器を表したクラスと，テストベンチや制

Simulation tool約を表したクラスは我々が定義したステレオタイプによって区

waveform data

別し，パッケージを分けて表現する．ステレオタイプ constraintを持つ制約クラスの操作には制約条件を表すアクティビティ図やステートマシン図が関連付けられ，これらの UML によって

The designer looks over the waveform data,
and verifies design.

ハードウェア制約を表現する．

Fig.9 に 4bit 加算器の制約条件を表すアクティビティ図やス
テートマシン図の例を示す．Fig.9 のステートマシン図には入力

Fig.6 The flow of the design verification methodology by the
waveform simulation.5)

A と B の値がそれぞれ 2 進数で”1111”と”1100”の場合に遷移する状態 state A がある．この state A には Fig.9 のアクティビ
ティ図の振る舞いが対応しており，このアクティビティ図ではレーション結果と仕様の比較を自動的に行う．UML を用いた

出力 S と Co の値を条件とした分岐がある．つまり，4bit 加算

設計検証手法の流れを Fig.7 に示す．
設計対象ハードウェアの要求・システム分析の後，UML を用

器の入力 A が”1111”で B が”1100”のとき，出力 S が”1011”か

いてハードウェアの制約とテストベンチ，そしてハードウェア

つ Co が”1”であれば true となり，出力が異なる場合は false とを記述する．我々が開発した UML コンパイラを用いてテストなる．

ベンチとハードウェアを表した UML から NSL 記述を生成す

この手法を用いることで設計検証を自動的に行うことができる．同時に UML コンパイラは，ハードウェアの制約を表した

る．ステートマシン図によって制約に条件与えることができる

UML から制約を抽出した中間ファイルを生成する．テストベ
ンチとハードウェアが記述された NSL 記述を任意のシミュレー

ため，この手法は順次回路の制約を表現することができる．しかし，この手法では組み合わせ回路の検証を行う場合，多くの-4-− 18 −

狩野大樹・清水尚彦

State A

Requirement and System analysis

Activity A[A == 4’b1111 && B == 4’b1100]

auto
mationinitial state

UML design
Constraint
Condition(UML)

state Ado / Activity A

TestBench
(UML)

true

false

state Bdo / Activity B

Hardware(UML)[A == 4’b1011 && B == 4’b1010]
State diagram of constraint condition

UML2NSL(our tool)

Constraint
Condition(intermediate file)[S == 4’b1011 && Co == 1’b1]

Activity diagram of constraint condition

Fig.9 The state machine and activity diagram showing the
hardware constraints.5)

NSL source code
(testbench + hardware)
simulation
tool

3.3
3.3 SysML
SysMLを用いた設計検証手法
を用いた設計検証手法

Simulation
resultのような組み合わせ回路の検証を自動的に行う手法について述

本論文が提案する，SysML のブロック定義図を用いて加算器
べる．SysML を用いた設計検証手法の流れを Fig.10 に示す．
この手法では設計対象ハードウェアの要求・システム分析を

Design Verification tool
(our tool)

行った後，ハードウェアを UML で表し，ハードウェア制約を

SysML で表す．ハードウェアを表した UML は，これまでのよ
うに我々が開発した UML コンパイラを用いて NSL 記述を生成する．ハードウェア制約を表した SysML はコンパイラによっVerification
resultて NSL で記述されたテストベンチプログラムを生成する．最後に，それぞれ生成されたテストベンチとハードウェアの NSL 記
述を任意のツールを用いてシミュレートする．生成されるテス

Fig.7 The flow of the automatic design verification methodology using UML.5)

トベンチプログラムには入力と出力の値を見て制約通りの結果が得られているか判定する記述が含まれる．そのため，設計者
はシミュレーション結果に含まれる記述を見ることで制約通り

Package1

Package2<<testbench>>test~ test_act()<<constraint>>
cons

Adder4+ A:input[4]+ B:input[4]+ S:output[4]+ Co:output

3の動作をしているか判断できる．

FA+ A:input+ B:input+ Ci:input+ S:output+ Co:output

Requirements analysis
System analysis
automation+ action(A, B) : S

SysML design+ action(A, B, Ci) : S~ cons1()~ cons2()~ cons3()

1
HA+ A:input+ B:input+ S:output+ Co:output

2+ action(A, B) : S

Fig.8 The class diagram showing the test bench and hardware
constraints.5)

UML design

Constraints

Hardware[SysML]block definition[UML]
class , activity, state

TestBench generator(our tool)

UML2NSL(our tool)

NSL source code
(testbench)

NSL source code
(hardware)

simulation
tool

UML 図を記述する必要がある．例えば 4bit 加算器を検証する
Simulation
result

際，検証する入力パターンの数だけステートマシン図とそれに対応するアクティビティ図を記述しなければならない．
このような組み合わせ回路の検証を行う場合は，次に提案すFig.10 The flow of the automatic design verification methodology using SysML.5)

る SysML を用いた設計検証手法を用いる．

-5-− 19 −

UML と SysML を用いた視覚的なハードウェア設計・検証手法

ションの実行クロック数を制御する．実行クロック数は endcnt

次に，SysML を用いてハードウェア制約を表す手法を解説する．組み合わせ回路は入力のみで出力が決まる回路である．例に与えられた初期値となる．

えば，加算器の制約は２つの入力の値を加算した結果を出力す

7 行目から 10 行目の記述はテストベンチモジュールが持つることである．これを NSL の構文に従った式で表すと以下のよ

データ端子であり，制約ブロックが持つ input と output 型のパ

うになる．

{Co, S} == A + B

ラメータに対応している．input 型である A と B には NSL の乱数生成関数によって乱数が与えられる (15, 16 行目)．output(1)型である S と Co には，サブモジュールとした 4bit 加算器の出{ } で囲われた２つの出力は，NSL における bit 連結を意味す

力と接続される (18, 19 行目)．18 行目は，サブモジュールのCo を連結した値が等しいことを表している．我々の提案する検を動かしている．引数として乱数を生成した端子 A, B を与え，る．この式は，入力 A と B の加算値と，出力 S と桁上がり出力

4bit 加算器が持つ制御入力端子 action を起動することで加算器

証手法ではこのような制約式を SysML で表し，SysML 図から

action の戻り値を端子 S に接続している．

NSL で記述されたテストベンチプログラムを自動生成する．ま21 行目はシミュレーション中のメッセージ出力である．生成た，ハードウェアを表した UML 図と制約を表した SysML 図のした乱数の値と加算器の出力，そしてシミュレーションタイム

繋がりは SysML の allocation table を用いて表す．

を表示する．

Fig.11 に，UML と SysML で表した 4bit 加算器から生成され23 行目は加算器の制約を満たしているか判定する記述であるテストベンチプログラムの例を示す．Fig.11(a) は 4bit 加算器

る．(b) の制約式に記述された内容を条件とした if 判定を行う．

の構造を表したクラス図であり，Fig.11(b) は 4bit 加算器の制約生成した乱数の入力値に対して，得られた出力値が制約を満たを表したブロック定義図である．Fig.11(c) は (a) と (b) の関係していない場合はエラーメッセージを出力する．

を表す allocation table である．(c) により (b) は (a) の制約であることを表している．ここでもし 4bit 加算器内の全加算器を検２つの設計手法はそれぞれ組み合わせ回路と順序回路の検証する場合は全加算器の制約を表すブロック定義図を記述し，証に適している．このように，我々の手法を用いて UML とallocation table でクラス FA と関係付ければ良い．Fig.11(d) は

SysML でハードウェアの構造と振る舞い，そして制約を表すこ(b) から生成される，NSL で記述されたテストベンチプログラとで，自動的に設計検証を行うことが可能となる．

ムである．

4．UML を用いたハードウェア設計手法による
UML を用いたハードウェア設計手法による実証実験
実証実験(b) のブロックはステレオタイプ constraint が与えられてい4.

る．このステレオタイプを持つことで，(b) のブロックは制約ブロックとして扱われる．要素 constraints には数式 (1) のような本論文が提案する，UML を用いたハードウェア設計手法に

制約式を記述する．要素 parameters には制約式で用いられるパ

よって実際にハードウェアを設計する実証実験を行い，当設計

ラメータの定義を行う．(b) の制約ブロックには入力 A，B と出手法を評価した 3)12)13)14) ．3 章では実験方法の概略と実験結果，

力 S，Co，そして endcnt というパラメータがある．A，B，S，考察を示す．

Co は対象ハードウェアである 4bit 加算器が持つ入力出力端子である．endcnt はシミュレーション時間を指定するパラメータ4.1
4.1 実験方法の概略
実験方法の概略

であり，我々が定義する型”simutime”を持つ．この型を持つパラメータの初期値によって，乱数生成の試行回数が決定される．

実証実験では当設計手法と NSL 記述によるコーディング設(d) は，(b) から生成される NSL 記述のテストベンチプログ

計によって同様の仕様をもつハードウェアをそれぞれ設計し，ラムである．(d) のような制約ブロックから生成されるテストベ

設計時間の比較を行った．各実験を行ったのは当研究室に所属

ンチプログラムによる検証では NSL の乱数生成関数を用いる．

するハードウェア設計初心者の学部生 8 名と院生 3 名である．

4bit 加算器の場合 256 種の入力パターンを試す検証が最も信頼

UML 設計と NSL 記述設計によって同様のハードウェアを設計

度が高いが，入力パターンの多い回路の場合全てのパターンをするが，一人の設計者が同じハードウェアを設計することがな

試すことは現実的ではない．そのためいくつかの乱数を生成しいように実験を行った．

て検証を行う．乱数を生成する試行回数は設計者が定める．

実証実験における UML 設計と NSL 設計の設計手順の流れを(b) の制約ブロック名 test Adder4 が，(d)3 行目と 6 行目のFig.12 に示す．設計対象のハードウェア仕様は，UML 設計とテストベンチモジュール名に対応している．また，1 行目と 12

NSL 記述設計共に自然言語で記述された仕様書を用いている．

行目の記述で設計対象のハードウェアである Adder4 をサブモ

各設計者は仕様書を読み仕様を理解した後，UML や NSL 記述

ジュールとして持つことを表している．サブモジュール名など

によって設計を行う．そのため，これらの実験では仕様分析のの情報は allocation table で関連付けられているクラスを参照す

比較は行なっていない．また，設計検証も UML 設計と NSL 記

ることで得られる．(d) では target というインスタンス名で 4bit

述設計共に同様の手法で行った．この実験では，本論文で提案

加算器をサブモジュールとして宣言している．4 行目の define
ディレクティブ endcnt は，(b) の parameters にある endcnt に対した設計検証手法は用いておらず，それぞれハードウェアを設応しており，endcnt は初期値 10 が与えられている．この定数は計した後テストベンチプログラムを NSL で記述して波形シミュ

24 行目で用いられている．24 行目の記述によってシミュレー

レーションを行い，バグがなければ FPGA に実装した．

-6-− 20 −

狩野大樹・清水尚彦

01clientsupplierb <block>test_Adder4

c <class>Adder402(c)
The allocation table
Package
Adder4+ A:input[4]+ B:input[4]+ S:output[4]+ Co:output

3

FA+ A:input+ B:input+ Ci:input+ S:output+ Co:output

Package<<constraint>>
test_Adder4

auto
generate

constraints+ action(A, B) : S+ action(A, B, Ci) : S
1{NSL}{ {Co, S} == A + B}

HA
+ A:input+ B:input+ S:output+ Co:output

parameters
A: input[4]B: input[4]S: output[4]Co: output
endcnt: simutime = 102

+ action(A, B) : S

01 #include "Adder4.h"
02
03 declare test_Adder4 simulation{}04 #define endcnt 1005
06 module test_Adder4 {07 wire A[4];08 wire B[4];09 wire S[4];10 wire Co[1];1112 Adder4 target;
13
14 {15 A = 4’(_random);
16 B = 4’(_random);17
18 S = target.action(A, B);
19 Co = target.Co;
20
21 _display("%d%d %d %d %d\22
23 if(!({Co, S} == A + B)) _display("false");24 if(_time == endcnt) _finish("simulation end");
25 }
26 }

(b)
The constraint block diagramof the 4bit adder(a)
The class diagramof the 4bit adder(d)
The testbench programof the NSL

Fig.11 The test bench program of the NSL generated from the constraint block diagram.

7h

4.2 実験結果
実験結果
4.2

UML design
NSL design

6h

各実験の設計時間と検証時間の結果の平均を Fig.13 に示す．

5h

設計時間とは設計者が仕様の理解を終えた後，UML 記述や NSL

averagetime 4h

記述により設計に入った段階から検証に至るまでの時間である．
検証時間は検証に入ってからデバッグを行い，波形シミュレー
ションや FPGA 実装によって正常に動作することを確認するま

3h

での時間である．
実験結果を平均したところ，設計時間では UML 設計よりも2h

NSL 設計の方が短い時間で設計できていることが分かる．一方で，検証時間では UML 設計の方が NSL 設計よりも短い時間で1h検証し終えていることが分かる．

0h
design timesystem & requirements analyze
by designer reading specification

NSL design

verificationtime

total time

design process
Fig.13 The average of all the experimental results using the ourmethodology.5)

UML design

design verification
by wave simulationても自然言語で記述された抽象度の低い仕様書を設計者が読む

Fig.12 The flow of the procedure of UML design and NSL design in the experiments.

計レベルで記述する UML の量が多いことが設計時間に影響しことで行なっている．仕様を理解した段階から UML 記述を行なっているため UML と NSL が一対一の関係になっており，設ていた．また，仕様分析が手動であるため，設計者が仕様を間違って解釈して設計のやり直しが発生する事例もあった．
そのため，UML や SysML を用いて仕様分析をシステムレベ

4.3 考察考察
4.3

ルで行う必要がある．UML を用いて段階的に仕様を設計レベ
ルまで落としこむことで設計レベルでの UML 記述量を減らし，平均結果を見ると，設計時間は UML 設計よりも NSL 設計の

設計時間を削減する．

方が短い．これらの実験での仕様分析手法は，UML 設計におい-7-− 21 −

UML と SysML を用いた視覚的なハードウェア設計・検証手法

検証時間は設計時間とは反対に NSL 設計よりも UML 設計の1”, http://www.itrs.net/links/2011ITRS/Home2011.htm ,方が短い．ハードウェア設計初心者の学部生が NSL 設計を行っ

2013/02/08 アクセス
2) Object Management Group (OMG) , Unified Modeling Lan-

た際，細かな構文エラーが多かった．また，そのような構文エ
ラーを取り除く作業に時間を要した．一方で UML 設計を行っ

guage(UML) , http://www.uml.org , 2013/02/08 アクセス
3) Daiki KANO, Ryota YAMAZAKI, Naohiko SHIMIZU ,た場合は構文ミスが少なく，UML を用いて図でハードウェアを表す利点が発揮されたと言える．しかし，実験での設計検証手”THE METHOD FOR HARDWARE DESIGN TO GENER-

法は UML 設計と NSL 設計共に同じである．そのため，この検ATE NSL FROM UML DIAGRAM AND THE EXPERIMENTS WITH FPGA” , ICCEETS2012, pp.594-601, 2012.

証時間の差は手法による差ではなく，設計時のバグの量の差によって発生したものである．

5. まとめ4) Overtone Corporation,
Next Synthesis Language,
http://www.overtone.co.jp, 2013/02/08 アクセス
5) 狩野 大樹, 清水 尚彦, ”UML 図を用いた設計検証の自動化

5．まとめ

手法の開発” , リコンフィギャラブルシステム研究会, 信学

我々はハードウェア設計生産性の向上を目的として，抽象度

技報, vol.112, no.377, RECONF2012-85, pp.141-146, 2013の高いシステムレベル設計を開発している．我々が開発してい年1月

る UML を用いたハードウェア設計手法は，UML で実装可能な

6) The SysML Partners , Systems Modeling Language ,ハードウェアを表現する．また，これを実現するための UML

http://www.sysml.org/ 2013/02/08 アクセス

コンパイラの開発を行なっている．この手法を用いることで，

7) E. Riccobene, P. Scandurra, A. Rosti, S. Bocchio , ”A SoC

抽象度の高いハードウェア設計を行うことができる．さらに同

Design Methodology Involving a UML 2.0 Profile for Sys-

手法を拡張し，ハードウェア設計検証を視覚的かつ自動的に行

temC”, the conference on Design, Automation and Test in
Europe - Volume 2, IEEE Computer Society, pp.704-709,
2005.

う手法の開発を行なっている．

UML を用いた設計検証手法では，UML を用いてハードウェ
アの構造・振る舞いとハードウェア制約，そしてテストベンチ

8) Moreira T.G. , Wehrmeister M.A. , Pereira C.E. , Petin J.F.
, Levrat E. , ”Automatic code generation for embedded
systems: From UML specifications to VHDL code”, 2010
8th IEEE International Conference on, Industrial Informatics(INDIN), pp.1085-1090, 2010．
9) T. Schattkowsky , J. H. Hausmann , G. Engels , ”Using UML
Activities for System-on-Chip Design and Synthesis” , MoDELS 2006 , LNCS 4199 , pp 737-752, 2006.
10) 山崎 亮太，清水 尚彦，”SysML を用いたモデルベースハー
ドウェア開発の試行” ，IEICE Technical Report Vol.112,を表す．そしてシミュレーション結果と制約を比較することで自動的に設計検証を行う．この設計検証手法はステートマシン
図によって状態毎の制約を記述することができる．そのため，

USB パケット通信などの順序回路の検証に適している．
SysML を用いた設計検証手法では，SysML を用いてハード
ウェアの制約と表し，UML によってハードウェアの構造と振る舞いを表す．そして UML 図と SysML 図から生成した NSL 記
述をもとにシミュレーションを行うことで設計検証を行う．この設計検証手法は，乱数を生成して入力に与え，そのタイミングで得られる出力を得て検証を行う．そのため，加算器などの組み合わせ回路の検証に適している．

No.325, pp.63-69, 201211) Takahito Nakajima, N.Shimziu , ”Design of Co-Emulation
System with SCE-MI API”, Proceedings of the 2009 RISP

我々が開発している手法を用いることで，UML および SysML
によってハードウェアを視覚的に表し，設計，実装および検証を自動的に行うことができる．

International Workshop on Nonlinear Circuites and Signal

さらに，UML を用いたハードウェア設計手法に対して実証実は多くかかるが、検証時間は短くなることが分かった．

Processing, pp.372-375, 2009.
12) 山崎 亮太, 狩野大樹, 清水尚彦, ”クラス図，アクティビティ
図からのハードウェア合成” , 第 37 回パルテノン研究会,
Vol.37, pp.1-8, 2011.

5.1 今後の課題
5.1
今後の課題

13) 狩野 大樹, 山崎 亮太, 清水尚彦, ”ハードウェア設計のためのモデルコンパイラ開発と実証実験 UML ステートマシン

験を行った．その結果，我々の手法は NSL 設計よりも設計時間

今後，我々はハードウェア仕様を表した SysML 図を設計レベ

図からのハードウェア記述言語の生成” , IEICE Technical

ルまで段階的に詳細化していく手法の開発を行なっていく．同

Report Vol.111, No.218, pp31-36, 2011.
14) 狩野 大樹, 山崎 亮太, 清水尚彦, ”UML モデル図からハードウェアを設計する手法による実証実験と評価” , IEICE
Technical Report Vol.111, No.397, pp.101-106, 2012.

時に本論文で示した開発・検証手法に用いるコンパイラや検証ツールの開発を進め，完成度を高めていく．また．本論文で提案した設計検証手法に対して実証実験を行い，設計検証手法を評価していく．
参考文献
参考文献

1) INTERNATIONAL TECHNOLOGY ROADMAP FOR
SEMICONDUCTORS 2011 EDITION , ”2011 Design-8-− 22 −