EDAアニュアルレポート 2008
Annual Report on Electronic Design Automation－

65nmから45nmテクノロジ世代のEDA技術の進展に向けて－

2009年5月発行

作

成

EDA技術専門委員会
EDA Technical Committee

発
社団法人

行

電子情報技術産業協会

Japan Electronics and Information Technology Industries Association

【巻頭言】「65nmから45nmテクノロジ世代のEDA技術の進展に向けて」
ＥＤＡ技術専門委員会

2008年度委員長

山田節

現在および近い将来のユビキタス社会を構築していく上で、基幹となる半導体産業への期待が高まっている。なかでも、半導体の設計に関する技術は、LSI の高密度化、高集積化、高性能化、低消費電力化の要求を支える重要な役割を担っており、より一層の技術向上を図る必要がある。
半導体加工の超微細化の進展に伴い、設計上流では超大規模システム LSI の機能・論理の設計・検証
問題、設計下流では SI(Signal Integrity）や DFM(Design For Manufacturing)問題、そしてこれをつなぐインプリメンテーションの難易度の飛躍的増大への対応である。
EDA 技術専門委員会は、電子情報技術産業協会(JEITA)における業界活動組織の一つとして、電子機器の設計自動化(EDA：Electronic Design Automation)に関わる様々な活動を行っている。特に、電子機器の機能・性能を決定するシステム LSI 設計技術に関して、以下の 3 つの領域を推進している。
第 1 の活動の領域は、システム LSI 設計技術に関する調査・検討と課題解決手法の提案である。本年度は、製造ばらつきに起因するリーク電流変動の低減法などのプロセス微細化に伴う設計課題とその課
題解決手法を、ナノ世代物理設計ワーキンググループが検討を行った。
第２の活動領域は、EDA 技術に関する標準化活動と関連機関、団体への協力と貢献である。IEC、IEEE等の国際的な標準化活動に対し EDA 標準化小委員会を中心に、標準化提案の検証、技術提案・交流会
議などを行なっている。設計記述言語 SystemC および SystemVerilog の IEEE 標準化では、本委員会の各ワーキンググループが、2005 年末の標準化に貢献し、その後も両標準の普及推進活動と、追加標仕様の検討、提案を行っている。二つの標準化グループが存在し混迷している Power Format は、PowerFormat ワーキンググループが業界としての検討を行い、IEEE.p1801 への投票を行った。また、
EDA 標準化小委員会は電子情報通信学会内の IEC/TC93 国内委員会/WG2(ハードウェア設計記述言語)
としての標準化活動も行っており、2008 年 11 月には IEC/TC93 国際会議(シンガポール)に参加し、国際標準化の課題を議論してきた。
最後に、第 3 の活動領域は、EDA 技術および標準化の普及、推進のためのイベント開催、支援である。本年度も、2009 年１月にパシフィコ横浜にて EDSFair2009（Electronic Design and Solution Fair
2009）を開催した。EDSFair は、電子機器の設計技術に関する、国内唯一の総合的な展示会であり、時開催の FPGA コンファレンスおよびシステム・デザイン・フォーラム 2009 と合わせ、特設ステージ
での当委員会企画イベントも含めて積極的・精力的に、企画、出展者誘致、来場者誘致活動を行った。
その結果、最新の EDA 技術と関連情報との出会いの場として、LSI 設計者・電子機器設計者をはじめとした 1 万人に近い方々に参加頂いた。

次の図でこれらの委員会活動と関係する団体の関係を示す。

-1-

EDA技術専門委員会の活動
標準化案

標準化活動の推進(国際標準化日本代表)
国際
標準化
団体
（IEC/
TC93等）

日本意見の反映

・業界の技術ﾚﾍﾞﾙ向上
・若手技術者の育成
ナノ世代物理設計WG

EDA 標 準 化 小 委 員 会

最新EDA技術の業界内での普及促進

標準化案
の提案

EDSFair実行委員会

メンバ参加

論文発表

国内学会
(ASP-DA
企画支援
C等)

メンバ参加

STRJ

成果活用

STARC

EDA技術開発の主要プレイヤ全て参加によるオープンな活動、関連組織との協調
半導体ベン ダEDAベンダ

IEC/TC93 ： 国際電気標準会議/設計自動化

図-１

システムベンダ

大学

ASP-DAC：Asia South Pacific-Design Automation
Conference
STRJ： 半導体技術ロードマップ委員会
STARC ： 半導体理工学研究センター

EDA技術専門委員会と関連組織との関係

EDA 技術専門委員会は、上図の関連組織・団体との密な連携のもと、技術検討、標準化、そしてそれらの普及促進という 3 つの活動領域の活動を通じ、65nm から 45nm テクノロジー世代の「システム・
オン・チップ時代」の電子情報機器業界に対し、さらには地球温暖化などの世界規模での課題に対し、設計技術の面で貢献し、「システム・オン・チップ時代」がもたらす産業界の変革を乗り越えて、日本の電子情報機器業界の発展に寄与すべく、本年度 21 社約 60 名の業界各社・有志メンバーの参画で運営してきた。
「システム・オン・チップ時代」に入り、半導体および電子機器が切り拓く素晴らしい未来が今後も広がることを確信しつつ、2009年度も積極的な活動を展開していきたい。
本冊子「ＥＤＡアニュアルレポート2008」は、EDA技術専門委員会の2008年度年次報告として、上記３つの活動領域について、活動成果をまとめたものである。
Webにも各種報告を掲載しているので、ご覧いただきたい。
(http://eda.ics.es.osaka-u.ac.jp/jeita/eda/index-jp.html)-2-

2008 年度 JEITA/EDA 技術専門委員会 委員一覧
委員長

山田

節

三洋電機㈱

デジタル技術研究所担当課長（ＬＳＩ設計技術担当）

副委員長

太田

光保

パナソニック㈱セミコンダクター社
システムＬＳＩ事業本部
商品開発センター
設計第三開発グループ

副委員長

江田

努

ローム㈱

ＹＴＣ開発システムユニット
ＬＳＩ企画推進Ｇ

監事

齋藤

茂美

ソニー㈱

半導体事業本部

吉田正昭

ＮＥＣエレクトロニクス㈱次席技術員

設計基盤技術部門

企画部第１課
幹事

参事

統括課長

基盤技術開発本部
設計技術開発部
シニアプロフェッショナル

幹事

西本

猛史

シャープ㈱

電子デバイス事業本部
ＮＢ事業化推進センター
ＮＢプロジェクトチーム

幹事

熊谷

敬

セイコーエプソン㈱半導体事業部

副参事

ＩＣ基盤技術部

部長
幹事

南

文裕

㈱東芝

セミコンダクター社
システムＬＳＩ設計技術部
設計メソドロジ技術開発

幹事

河村

薫

担当主査

富士通マイクロエレクトロニクス㈱テクノロジ開発統括部
主席部長

幹事

秋山

俊恭

㈱ルネサステクノロジ

製品技術本部
副統括部長-3－－

設計技術統括部

委員

長野

義史

㈱エッチ・ディー・ラボ

代表取締役社長

委員

川原

常盛

コーウェア㈱

取締役

委員

下出

隆文

三洋半導体㈱ＳＳ事業本部

営業技術本部長

設計技術部

ＳＳ事業推進統括部
課長

委員

山城

治

㈱ジーダット

取締役

委員

野坂

啓介

㈱図研

ＳｏＣ事業部イノベーション営業部

委員

平尾

栄二

凸版印刷㈱

半導体ソリューション事業本部
事業企画部

委員

安井

孝史

日本ケイデンス・デザイン・システムズ社
ＴＦＯ

委員

飯島

委員

牧

一彦
克眞

部長

日本シノプシス㈱Ｄｉｒｅｃｔｏｒ

技術本部

本部長

マグマ・デザイン・オートメーション㈱営業ディレクタ

委員

瀬谷

和宏

丸紅情報システムズ㈱製造ソリューション事業本部事業本部長補佐委員

三橋明城男

メンター・グラフィックス・ジャパン㈱テクニカルセールス部
テクニカルディレクター

委員

前野

酉治

㈱リコー

電子デバイスカンパニー
画像ＬＳＩ開発センター
ＣＡＤ技術室シニアスペシャリスト

委員

山本

一郎

ローム㈱

ＯＫＩセミコンダクタ㈱開発本部

設計技術サポートチーム

チームリーダー
特別委員

黒川

敦

三洋半導体㈱

ＬＳＩ事業本部
設計技術部

-4－－

設計統括部

課長

特別委員

小島

智

ＮＥＣシステムテクノロジー㈱ＰＦ統括本部ＣＷＢ事業推進室

テクニカルマーケティング
ディレクター
特別委員

浜口加寿美

パナソニック㈱セミコンダクター社
システムＬＳＩ事業本部
商品開発センター
設計第三開発グループ
チームリーダー

特別委員

中森

勉

富士通マイクロエレクトロニクス㈱テクノロジ開発統括部
第一設計技術部
プロジェクト課長

特別委員

長谷川

隆

富士通マイクロエレクトロニクス㈱共通技術本部
第１設計部

特別委員

金本

俊幾

㈱ルネサステクノロジ

製品技術本部

設計共通技術統括部部長
設計技術統括部

ＳＩＰ・アナログＥＤＡ技術開発部
物理検証技術開発グループ主任技師
客員

神戸

尚志

近畿大学

理工学部

電気電子工学科

教授
客員

今井

正治

大阪大学

大学院

情報科学研究科

情報システム工学専攻
客員

岡村

芳雄

教授

㈱半導体理工学研究センター
執行役員・開発第２部長

客員

若林

一敏

日本電気㈱

中央研究所
ビジネスイノベーションセンター
ＥＤＡ開発センター研究部長-5－－略 語 一 覧［１］団体・組織の名称
Accellera
VIとOVIを統合した、設計記述言語の標準化に関連する活動機関
ANSIAmerican National Standards Institute
米国の標準化国家機関

ASP‐DAC

Asia and South Pacific Design Automation Conference
アジア･太平洋地域でのEDA関連の国際学会（1995年に始まる）

CENELEC

European Committee for Electrotechnical Standardization
EC（欧州委員会）の電気電子分野に関する標準化機関

DAC

Design Automation Conference
米国で行われるEDA関連の国際学会

DASC

Design Automation Standardization Committee
IEEEの下部組織で設計自動化に関する標準化委員会

ECSI

European Electronic Chips & Systems design Initiative
欧州の設計自動化に関する標準化機関

EDIF Div．

Electronic Design Interchange Format Division
EIAの下部組織で電子系の惜報データ交換規格の検討機関

EIA

Electronic Industries Alliance
米国の電子業界団体(AssociationをAllianceに改称）

JEITA

Japan Electronics and Information Technology Industries Association
社団法人電子情報技術産業協会（電子業界団体）

ICCAD

International Conference on Computer Aided Design
CADに関する国際学会

IECInternational Electrotechnical Commission
電気電子分野に関する国際標準化機関

IEEE

Institute of Electrical and Electronics Engineers,Inc．
米国の電気電子分野の国際的な学会組織

IPC

Institute for Interconnecting andPackaging Electronic Circuits Industry Association
米国のプリント回路に関する業界組織

ISOInternational Organization for Standardization
国際標準化機関-6-

IVC

International Verilog Conference
OVIが主催するVerilog HDL国際学会

JPCA

Japan Printed Circuit Association
社団法人日本プリント回路工業会

OSCI

Open SystemC Initiative
SystemC の標準化団体

OVI

Open Verilog International
Verilog‐HDLに関連する技術の標準化と普及推進組織

SEMATECH

Semiconductor Manufacturing Technology Initiative （Consortium）
半導体技術を向上するために始まった米国の官民プロジェクト

Si2

Silicon Integration Initiative
設計環境の整備促進を支援する米国の非営利法人（旧CFI）

VASG

VHDL Analysis and Standards GroupDASC傘下のVHDL標準化に関するワーキンググループ

VITAL

VHDL Initiative Toward ASIC Libraries
VHDLライブラリ標準化団体

VSIA

Virtual Socket Interface Alliance
LSIの機能ブロックのI/F標準化を目指している業界団体［２］標準化・規格に関する技術用語
ALF

Advanced Library Format
OVIで検討されたIPをも含むASICライブラリのフォーマットALR

ASIC Library Representation
ASICライブラリ表現

CALS

Computer Aided Logistics Support（1985）
Commerce At Light Speed（1995）

CHDS

Chip Hierarchical Design System
SEMATECHが要求仕様を作成した0.25-0.18um世代設計システム

CHDStdChip Hierarchical Design System technical data
CHDSで使用するデータモデルの標準化

-7-

DCL

Delay Calculation Language
遅延計算のための記述言語

DPCS

Delay and Power Calculation System
IEEE1481として標準化推進されている遅延と消費電力の計算機
構仕様

EDI

Electronic Data Interchange
電子データ交換

EDIF

Electronic Design Interchange Format
EIAの下部組織で検討されている電子系の情報データ交換規格

ESPUT

European Strategic Program for Research andDevelopment in Information Technology
欧州情報技術研究開発戦略計画

HDL

Hardware Description Language
ハードウェア記述言語

IPIntellectual Property
流通/再利用可能なLSI設計資産（本来は知的財産権の意）

JISJapanese Industrial Standard
日本工業規格SDF

Standard Delay Format
遅延時間を表記するフォーマットSLDL

System Level Design Language
システム仕様記述言語

STEP

Standard for the Exchange of Product Model Data
CADの製品データ交換のための国際規格

VHDL

VHSIC（Very High Speed Integrated Circuit)
Hardware Description Language
IEEE1076仕様に基づくハードウェア記述言語

VHDL-AMS

VHDL-Analog and Mixed-Signal (Extensions)DASCの中で進められているVHDLのアナログ及びミックストシ
グナルシステムへの拡張-8-

１．ＥＤＡ技術専門委員会の活動

1.1

2008 年度

委員会の名称JEITA/EDA 技術専門委員会

事業計画

EDA 技術専門委員会 (Electronic Design Automation Technical Committee)

EDA に関連する技術およびその標準化の動向を調査し、その発展、推進を図り、もって国内外の関係業界の発展に寄与する<方針>
1.情報収集力の強化(PowerFormat 取組
委員会の構成会員会社 /委員
21 社/24 名
みの反省)
特別委員
6名
IEEE-SA の加入継続
客員
4名
IEEE/DASC への加入検討
国際会議(TC93, DASC)への積極的参委員会の役員加と国内開催（WG2）
委員長：
三洋電機
山田 節
標準化団体との定期的な会議開催
副委員長（正）：パナソニック 2.委員会活動の活性化
太田 光保
副委員長（代行）：ローム
江田 努
委員会を主体にした運営 EDSFair に
監事：
ソニー
齋藤 茂美
係 る JESA,ASP-DAC,FPGA/PLD
Conf.
下部組織の役員などとの連携を再構築とイベント
EDA 標準化小委員会 主査
パナソニック
太田 光保
運営の見直しSystemC WG
主査
富士通ﾏｲｸﾛｴﾚｸﾄﾛﾆｸｽ 長谷川 隆
HP を活用したドキュメントの電子
SystemVerilogWG 主査
パナソニック
浜口 加寿美化（情報共有強化）Power Format WG 主査
富士通ﾏｲｸﾛｴﾚｸﾄﾛﾆｸｽ 中森 勉
ペーパーレス化の推進
ナノ世代物理設計 WG 主査
ルネサステクノロジ 金本 俊幾
3.委員会の継続的発展
EDSFair 実行委員会 委員長 富士通ﾏｲｸﾛｴﾚｸﾄﾛﾆｸｽ 河村 薫
新公益法人制度への対応
EDSFair 企画 WG 主査
ソニー
齋藤 茂美
予算の最適運用
SDF WG
主査
ローム
江田 努
委員会の目的EDA 技術専門委員会メンバと担当 (敬称略)
委員長： 三洋電機
山田 節
副委員長：パナソニック
太田 光保
副委員長：ローム

江田努

委員
監事：ソニー
齋藤 茂美
幹事：NEC エレクトロニクス 吉田 正昭
幹事：シャープ
西本 猛史
幹事：セイコーエプソン

熊谷

敬

幹事：東芝
幹事：富士通ﾏｲｸﾛｴﾚｸﾄﾛﾆｸｽ
幹事：ルネサステクノロジ

南 文裕
河村 薫
秋山 俊恭

委員：エッチ･ディー･ラボ
委員：コーウェア
委員：三洋半導体
委員：ジーダット
委員：図研
委員：凸版印刷委員：日本ｹｲﾃﾞﾝｽ・ﾃﾞｻﾞｲﾝ・ｼｽﾃﾑｽﾞ社
委員：日本シノプシス
委員：ﾏｸﾞﾏ･ﾃﾞｻﾞｲﾝ･ｵｰﾄﾒｰｼｮﾝ
委員：ﾏｸﾞﾏ･ﾃﾞｻﾞｲﾝ･ｵｰﾄﾒｰｼｮﾝ

EDSFair/ASP-DAC 小委員会 主査、ASP-DAC 支援
EDA 標準化小委員会 主査 (IEC/TC93 WG2 国内 主査)
国際標準化対応支援委員会 委員 (IEC/TC93 担当)
SDF WG 主査、ＥＤＡ標準化小委員会 副主査、内規改訂、
EDSFair 実行委員、ASP-DAC2009 Designer’s ForumEDSFair 企画 WG 主査、EDSFair 実行委員
ホームページ、メールシステム、予算実績管理
ASP-DAC2009 Designer’s Forum 委員
EDSFair 企画 WG 委員
アニュアルレポート、EDSFair 企画 WG 委員
システム･デザイン･フォーラム WG 委員
EDSFair 企画 WG 委員
EDSFair 実行委員長、SDF WG 委員
EDSFair 実行委員、広報パンフレット
長野 義史
川原 常盛
下出 隆文
山城 治
野坂 啓介
平尾 栄二
安井 孝史
飯島 一彦
船津 英世
牧 克眞
-9-

委員：丸紅情報システムズ
委員：ﾒﾝﾀｰ・ｸﾞﾗﾌｨｯｸｽ・ｼﾞｬﾊﾟﾝ
委員：リコー
委員：ローム

瀬谷
三橋
前野
山本

特別委員：三洋半導体
黒川 敦
特別委員：NEC ｼｽﾃﾑﾃｸﾉﾛｼﾞｰ 小島 智
特別委員：パナソニック
浜口 加寿美特別委員：富士通ﾏｲｸﾛｴﾚｸﾄﾛﾆｸｽ中森 勉
特別委員：富士通ﾏｲｸﾛｴﾚｸﾄﾛﾆｸｽ長谷川 隆
特別委員：ルネサステクノロジ金本 俊幾

EDA 用語辞典担当
IEC/TC93/WG2 コンベナ、EDA 標準化小委員会 副主査
国際標準化担当
SystemVerilog WG 主査
Power Format WG 主査
SystemC WG 主査
ナノ世代物理設計 WG 主査

客員：
客員：
客員：
客員：

IEC/TC93 国内委員長、元委員長
上流設計識者、ASP-DAC リエゾン
元委員長
ASP-DAC リエゾン

近畿大学
大阪大学
STARC
日本電気

事務局： JEITA
事務局： JEITA

神戸
今井
岡村
若林

尚志
正治
芳雄
一敏

和宏
明城男
酉治
一郎

古川 昇
岩渕 幸吾

活動計画の概要＜別紙-1 参照＞

委員会の予算会費委員会の開催

年６回程度 (予定日： 別紙-2 参照)
必要に応じて幹事会を開催する

担当事務局

JEITA/電子デバイス部

230,000 円 * 22 社 =5,060,000 円- 10 -EDSFair 企画 WG 委員

＜別紙‐1＞
活動計画の概要
1. EDA 技術の動向＆関連情報の調査検討、課題解決への提案(1) 小委員会及び WG による技術動向とニーズ調査
・最先端テクノロジ ： ナノ世代物理設計 WG
・設計言語 ： EDA 標準化小委員会(2) 関連機関、団体、キーパーソン等との合同会議、意見交換、交流
・STARC, STRJ 等(3) 国内外の学会,研究会,イベントへの参加と連携
・ASP-DAC2009, DAC2008, IEICE, 軽井沢ワークショップ
2. EDA に関する標準化活動への貢献と関連機関、団体への対応(1) EDA 設計言語およびモデル標準化のための技術的検討と提案
・SystemC, SystemVerilog, PowerFormat を継続
・Verilog-HDL,VHDL,A-HDL などは、EDA 標準化小委員会で必要に応じて対応(2) 国際的な関連機関、団体への参画・連携と標準化活動への協力
・IEC/TC93 国際会議(11 月@シンガポール)への参加
・WG2 会議を開催(6 月@DAC(US), 1 月@EDSFair(Yokohama), 2 月@DVcon(US))
・IEEE/DASC,IEEE-SA, OSCI, Accellera, Si2 等との連携を強化
・IEEE/DASC への加入を検討
3. EDA 技術および標準化の普及推進のためのイベント実施、支援(1) 「EDSFair2009」（横浜）・日本エレクトロニクスショー協会へ運営委託
・半導体部会/技術委員会を活用した各社への依頼とアナウンス
・ASP-DAC, FPGA/PLD Conference との連携と新企画の提案
・特設ステージの継続実施(2) 各種ワークショップ、講演会の開催
・ ｢システム・デザイン・フォーラム 2009｣を EDSFair2009 と同時開催(3) 「ASP-DAC2009」（Yokohama）
・Designer’s Forum との連携
4. 委員会活動の広報(1) 広報パンフレットの配布@EDSFair2009(2) アニュアルレポートの発行(下記 HP でも公開)(3) WWW ホームページの公開(4) 活動成果の発表
・システムデザインフォーラム ： 標準化活動
・学会での公演/学術論文 ： ナノ世代

- 11 -

＜別紙‐２＞
2008 年度

JEITA/EDA 技術専門委員会 会合予定

年/月

技術専門委員会

懇親会

2008/44/25(金) (東京地区) 議事録 メンター・08 年度事業計画説明、承認
・08 年度小委員会/WG 計画説明、承認
・07 年度会計収支と 08 年度会計予算説明、承認
・07 年度版アニュアルレポート作成状況報告

関連イベント・DATE2007（4/16-4/19） @ Nice
・軽井沢 WS (4/21-22)@軽井沢○2008/5

2008/6

6/20(金) (東京地区) 議事録 図研・小委員会/WG 進捗報告
・半導体部会/半導体技術委員会報告内容説明
・委員名簿更新内容確認
・予算消費状況・DAC2008 （6/8-6/13）@Anaheim,
California

・STARC Forum&Symp. (7/16-17)@新横浜
・DA シンポジウム 2008 (8/26-27)@浜松・TC93 国際会議 (11 月)@シンガポール

2008/7
2008/8

2008/99/19(金) (関西地区) 議事録 コーウェア
・小委員会/WG 進捗報告
・半導体部会/半導体技術委員会報告内容説明
・予算消費状況2008/10
11/14(金) (東京地区) 議事録 エッチ･ディ-･ラボ
・小委員会/WG 進捗報告
2008/11
・半導体部会/半導体技術委員会報告内容説明
・予算消費状況・EDSFair 用パンフレット作成手順説明

・ICCAD2008 (11/10-13)@San Jose, California
・デザインガイア (11/17-19) @北九州

2008/12

2009/11/14(水) (東京地区) 議事録 マグマ
・小委員会/WG 進捗報告
・半導体部会/半導体技術委員会報告内容説明
・09 年度体制協議・EDSFair 用パンフレッ
ト内容確認・アニュアルレポート作成分担
・手順説明・予算消費状況

・ASP-DAC2009 (1/19-21)@Yokohama・EDSFair2009 (1/22-23)@横浜

2009/2
3/19(木)(関西地区) 議事録 沖・半導体部会/半導体技術委員会報告内容説明
・08 年度小委員会/WG の年間活動報告
2009/3 ・08 年度予算消費状況
・09 年度事業計画説明
・09 年度プロジェクト/研究会の年間活動計画
説明- 12 -・SASIMI2009 (3/9-10) @沖縄
・DATE2009 (4/20-24)@ Nice, 仏○1.2

2008 年度 JEITA/EDA 技術専門委員会ホームページ

1.2.1

目的

電子情報技術産業協会（JEITA）の EDA 技術専門委員会の活動状況を公開し、EDA 技術の標準化や技術調査に関するご理解とご協力をいただくことを目的とする。
1.2.2

ホームページの詳細

2006 年度よりホームページを一新し、よりわかりやすく、また、欲しい情報に簡易にアクセスできるような構成に変更を行った。ホームページは日本語版の他、英語版も用意し海外からの利用者の利便性を考慮している。日本語版、英語版の切り替えは簡単にできるように構成されている。
(1) URL: http://eda.ics.es.osaka-u.ac.jp/jeita/eda/
大阪大学のご協力を頂き、大阪大学のサーバーにホームページを設置させていただいている。またデータの更新など、メンテナンスについてもご協力を頂いている。
(2) エントリーページの構成
日本語版、英語版はそれぞれ次のエントリーで構成されている。
日本語版：

英語版：

委員会の紹介

Introduction of a committee

委員会活動Committee activity

公開資料ライブラリ

Open data library

イベント・関連機関

Event・A related organization

お問い合わせInquiry

サイトマップ

Site map(3) 委員会の紹介/ Introduction of a committee
委員長挨拶、活動と成果、メンバーをサブエントリとする。本委員会の概要、前年度の活動内容・成果、本年度の活動計画、委員会メンバーを紹介している。
(4) 委員会活動/ Committee activity
下記の研究会・小委員会等の活動状況を紹介している。
・

EDA 標準化小委員会（EDA 標準化小委員会の他、SystemC WG、SystemVerilog WG、PowerFormat WG の活動が紹介されている）

・

ナノ世代物理設計 WG

・

EDSFair 実行委員会(5) 公開資料ライブラリ/ Open data library「公開資料ライブラリ」のページでは、EDA 技術専門委員会内の各委員会の活動報告や各委員からの発表資料等を適宜掲載している。主な掲載資料を以下に示す。なお、英語版も日本語版と同一の日本語資料を掲載している。
・

EDA 技術専門委員会（過去のアニュアルレポート）

・

EDA 標準化小委員会（IEEE-SA セミナー、Power Format 比較表など）

・

ナノ世代物理設計 WG（過去の資料）- 13 -

・

EDSFair 実行委員会（システムデザインフォーラムの紹介）

・

システムレベル設計研究会（旧サイトへのリンク）

・

その他（過去の委員会活動報告）(6) イベント・関連機関/ Event・A related organization
関連の会議としては、次の関係の深い EDA 関連技術委員会の紹介が行われている。
・

IEEE/DASC（電気電子学会/設計自動化標準化委員会）

・

IEC/TC93（国際電気標準化会議/デザインオートメーション標準化技術委員会）

また、関連機関として本委員会に関連のある 17 機関の紹介があり、さらにそれぞれのホー
ムページへのリンクが行われている。

- 14 -

1.3

2008 年度 JEITA/EDA 技術専門委員会 年間実績・予定表
月

2008 年 4 月
5月
6月
7月
8月
9月
10 月
11 月
12 月
2009 年 1 月
2月
3月

月
2008 年 4 月
5月
6月
7月
8月
9月
10 月
11 月
12 月
2009 年 1 月
2月
3月

月
2008 年 4 月
5月
6月
7月
8月
9月
10 月
11 月
12 月
2009 年 1 月
2月
3月

EDA 技術専門委員会
幹事会
4/25（金）

14:00-17:00

委員会
JEITA 402 会議室

6/20（金）

14:00-17:00

JEITA

506 会議室

9/19（金）

11:00-13:00

9/19（金）

14:00-17:00

JEITA 関西支部

第２会議室

11/14（金）10:00-13:00

11/14（金）14:00-17:00

JEITA

506 会議室

1/14（水）

11:00-13:30

1/14（水）

14:00-17:00

JEITA

502 会議室

3/19（金）

10:00-12:30

3/19（金）

13:00-17:00

ｷｬﾝﾊﾟｽﾌﾟﾗｻﾞ京都

第２会議室

4/22(火) 13:00-17:00
5/30(金) 10:00-12:00
5/16(金) 13:00-17:00
6/20(金) 13:00-17:00
7/25(金) 11:00-13:00
7/18(金) 13:00-17:00

EDA 標準化小委員会関連
第 1 回 SystemC-WG JEITA 406 会議室
第 1 回 EDA 標準化小委員会 機械振興会館
第 2 回 SystemC-WG 龍名館 竹の間
第 3 回 SystemC-WG JEITA 406 会議室
第 2 回 EDA 標準化小委員会 機械振興会館
第 4 回 SystemC-WG JEITA 405 会議室

9/19(金) 13:00-17:00
10/ 2(金) 11:00-13:00
10/17(金) 13:00-17:00
11/26(水) 10:00-17:00
11/21(金)-11/22(土)11/27(木) 11:00-13:30
12/19(金) 14:00-17:30
12/19(金) 13:00-17:00
1/16(金) 13:00-17:00
2/20(金) 13:00-17:00
3/26(木) 11:00-13:30
3/19(金) 13:00-17:00

第 5 回 SystemC-WG 日本ケイデンス社 新横浜本社内会議室
第 3 回 EDA 標準化小委員会 機械振興会館 会議室
第 6 回 SystemC-WG JEITA 関西支部 第２会議室
第 1 回 Power FormatWG 龍名館 龍の間
第 7 回 SystemC-WG(集中審議) 下呂ロイヤルホテル 雅亭
第 4 回 EDA 標準化小委員会 機械振興会館 会議室
第 2 回 SystemVerilog-WG 日本ケイデンス社 新横浜本社内会議室
第 8 回 SystemC-WG JEITA 404 会議室
第 9 回 SystemC-WG 龍名館 龍の間
第 10 回 SystemC-WG JEITA 501 会議室
第 5 回 EDA 標準化小委員会 機械振興会館 会議室
第 11 回 SystemC-WG 九段会館 4F あおいの間

会議室

会議室

ナノ世代物理設計 WG 関連
4/18(金) 13:00-17:00 第 1 回ナノ世代物理設計 WG 日本教育会館 902 会議室
5/23(金) 10:00-17:00 第 2 回ナノ世代物理設計 WG 龍名館 竹の間
6/27(金) 13:00-17:00 第 3 回ナノ世代物理設計 WG JEITA 502 会議室
7/25(金) 13:00-17:00 第 4 回ナノ世代物理設計 WG JEITA 関西支部 電子会館 8 階会議室
8/29(金) 13:00-17:00 第 5 回ナノ世代物理設計 WG JEITA 507 会議室
9/26(金) 10:00-17:00 第 6 回ナノ世代物理設計 WG JEITA 505、507 会議室
10/24(金) 11:00-17:00 第 7 回ナノ世代物理設計 WG JEITA 関西支部 第一会議室
11/28(金)-11/29(土)（集中審議）第 8 回ナノ世代物理設計 WG ヴィラ伊豆（富士通保養所）
12/19(金) 13:00-17:00 第 9 回ナノ世代物理設計 WG JEITA 403 会議室
1/16(金) 10:00-17:00 第 10 回ナノ世代物理設計 WG 龍名館 竹の間
2/20(金) 10:00-17:00 第 11 回ナノ世代物理設計 WG JEITA 503 会議室
3/27(金) 10:00-17:00 第 12 回ナノ世代物理設計 WG JEITA 405 会議室

-－－
15 -

月
2008 年 4 月
5月
6月
7月
8月
9月
10 月
11 月
12 月
2009 年 1 月
2月

EDS Fair 実行委員会関係
4/ 1(火) 13:00～17:00 第 1 回実行委員会 JESA 会議室
4/25(金) 10:00～13:50 第 2 回実行委員会 JEITA5 階「501」会議室
5/30(金) 13:00～16:50 第 1 回企画 WG JESA 会議室
6/20(金) 11:00～14:00 第 2 回企画 WG
JEITA 403⇒506 会議室
6/27(金) 14:00～18:00 第 3 回実行委員会 JESA 会議室
7/25(金）13:00～16:30 第 3 回企画 WG JEITA 会議室
8/28(木) 14:00～18:30 第 4 回実行委員会 JESA 会議室
9/11(木) 10:00～13:30 第 4 回企画 WG JESA 会議室
10/ 9(木) 13:30～17:00 第 5 回実行委員会 JESA 会議室
10/23(木) 14:00～17:30 第 5 回企画 WG JESA 会議室
11/ 6(木) 14:00～17:30 委員長会議 JESA 会議室
11/19(木) 14:00～17:30 第 6 回企画 WG JESA 会議室
11/28(金) 13:30～17:30 第 6 回実行委員会 JESA 会議室
12/12(金) 12:00～15:00 第 7 回企画 WG JESA 会議室
2/ 6(金) 10:00～12:00 幹部会議(次期体制) JESA 会議室
2/19(木) 11:00～13:00 幹部会議(次期体制) JESA 会議室
2/19(木) 13:00～15:00 第 8 回企画 WG
JESA 会議室
2/27(金) 13:30～17:00 第 7 回実行委員会 JESA 会議室

3月

月
2008 年 4 月
5月
6月
7月
8月
9月
10 月
11 月
12 月
2009 年 1 月
2月
3月

システム・デザイン・フォーラム 2009WG 関連
5/12(月) 15:00-18:00
6/20(金) 10:00-12:00
7/23(水) 14:00-17:00

第 1 回システム・デザイン・フォーラム 2009WG
第 2 回システム・デザイン・フォーラム 2009WG
第 3 回システム・デザイン・フォーラム 2009WG

JESA 会議室
JEITA 502 会議室
JESA 会議室

9/11(木) 14:00-17:00 第 4 回システム・デザイン・フォーラム 2009WG JESA 会議室
10/17(金) 10:00-12:00 第 5 回システム・デザイン・フォーラム 2009WG JESA 会議室
12/12(金) 15:00-17:00 第 6 回システム・デザイン・フォーラム 2009WG JESA 会議室
1/ 8(木) 15:00-17:00 第 7 回システム・デザイン・フォーラム 2009WG JESA 会議室
2/19(木) 15:00-17:00 第 8 回システム・デザイン・フォーラム 2009WG JESA 会議室

-－－
16 -

月
2008 年 4 月
5月
6月
7月
8月

関連行事
5/14(水)

9:30-18:00

IEEE SA セミナー 「Global Standards, Local Benefits」
ソニー（株）本社 2 階 大会議場
6/10(火) IEC/TC93/WG2 会議 アナハイム

9月
10 月
11 月
12 月
2009 年 1 月
2月
3月

10/28(火)-10/30(木) IEC/TC93 国際会議 IEC Asia-Pacific Regional Centre (IEC-APRC)

1/22(木) IEC/TC93 Secretary、JPN NC 意見交換会 パシフィコ横浜 会議室
1/23(金) IEEE DASC 会議 パシフィコ横浜 会議室
2/25(水) IEC/TC93/WG2 会議 サンノゼ

-－－
17 -

２．各技術委員会の活動報告

2.1
2.1.1

ナノ世代物理設計ワーキンググループ(Nano Scale Physical Design Working Group)
目的

半導体デバイス・配線テクノロジの進化に伴い、新たな設計上の課題があらわれてきている。
また、これらの課題を解決するため各社が開発した手法やライブラリが、そのテクノロジが一般化した後も標準化されず、設計環境の開発・サポートコスト低減の障害となる事例や、半導体ベンダと顧客との情報授受がスムーズに行えない事例が増えてきている。
上記課題を背景として、本ワーキンググループでは、次のような調査及び標準化を実施することにより、より効率的な設計環境の実現に貢献することを目的として活動を行っている。
•

次世代(45 ナノメータ)以降のテクノロジ･ノードにおける、LSI の物理設計・検証に関する
課題の抽出

•

半導体ベンダとその顧客との間でやり取りするライブラリや設計情報等を規定する、設計
ルール・ガイドラインの作成•

LSI の物理設計、検証手法の精度、互換性や効率を向上できるライブラリの標準化•

各種ライブラリを用いて行う検証が十分な精度で行えるかを判定するための標準ベンチマ
ークデータの作成

2.1.2

活動内容

2007 年 5 月から活動を開始し、今年度は、ばらつきに関わる下記のテーマを取り上げて調査や検討を行った。
•

製造ばらつきに起因するリーク電流変動の低減法•

32nm プロセスにおける配線自己発熱の信号伝播遅延に対するインパクト調査•

配線ばらつきの表現手段の調査、検討

今年度の活動の成果として、以下の２項目について調査を行い、有用な知見を得た。
(1) 製造ばらつきに起因するリーク電流変動の低減アプローチ
リーク電流は LSI 製品の商品価値を大きく左右する重要な因子である。プロセスばらつきによるリーク電流ばらつきは、チップ毎にリーク電流が異なる結果となり、リーク電流ばらつきを抑えることは LSI の品質を確保する上で重要である。本活動では、プロセスばらつきが遅延とリーク電流ばらつきへ与える影響に着目した。はじめにプロセスばらつきが遅延とリーク電流へ与える影響を評価するための解析式を導出し、遅延が一定でもリーク電流ばらつきが変動する場合を議論し、リーク電流ばらつきを低減する方法を提案した。提案するリーク電流ばらつき低減方法
は、実験により、何も考慮しない従来の一般設計と比較して、歩留まり 90%とした場合のリーク
電流値に対して 50%の低減効果があることを示した。

- 18 -

(2) 32nm プロセスにおける配線自己発熱の信号伝播遅延に対するインパクト調査
現実的な物理的なパラメータを使用して、32nm プロセスにおける信号伝播遅延に対する配線自己発熱のインパクト評価を行った。配線自己発熱が顕著になると思われる回路構成の 1 つとして
64 ビットのデータ伝送モデルを評価した。解析の結果、周囲の温度からの最大温度上昇は 5.49℃、
配線抵抗の増加は 4.82%となり、それによる遅延時間増加は 2.72%となった。想定した 32nm プ
ロセスに対しては、遅延マージンとして 2.72%分に相当するインパクトを生じうることがわかった。また、実験結果は、配線自己発熱が大きな負荷を短距離配線で駆動する場合に顕著であることも示した。
これらの活動で得られた成果は、次のような形態により無償で一般に公開する。
•

アニュアルレポート•

JEITA のホームページ•

関連学会の研究会・学会における発表や論文誌への投稿

成果の詳細は本アニュアルレポートの付録に掲載した。また、今年度の成果の一部を以下の学会、にて発表した。
[1] 「製造ばらつきに起因するリーク電流変動の低減アプローチ」, 回路とシステム軽井沢ワーク
ショップ, 2009 年 4 月.
また、本年度は EDS フェア/システムデザインフォーラムにおいて、プロセス微細化による製造
ばらつきの問題に対して、「最先端統計から見た 32nm ばらつき予測と設計法」をテーマとした、「ナノ世代物理設計フォーラム」を開催。
さらに、EDS フェア会期中に開催された IEEE DASC 会議に参加、配線ばらつきを表現する
Sensitivity SPEF フォーマットの策定に対応する DPC-WG との連絡を開始した。
2.1.3

関連機関の動向

米国に本部を置き、世界各国に多数の会員を持つ国際的な学会であり、電気および電子関連の標準化活動を長年にわたり実施している IEEE。その下部組織として、エレクトロニクス産業に
お け る 設計自 動 化 関連の 標 準 化活動 を 行 ってい る DASC (Design Automation Standards
Committee がある。その中のワーキンググループのひとつに、P1481 Circuit Delay and Power
Calculation (DPC) Working Group があり、本ワーキングのテーマのひとつである配線ばらつきの表現フォーマット(Sensitivity SPEF)策定を行っている。
一方日本では、半導体MIRAI(Millennium Research for Advanced Information Technology)プ
ロジェクトが、ASRC（産総研次世代半導体研究センター）、ASET（技術研究組合 超先端電子技
術開発機構）、Selete（株式会社 半導体先端テクノロジーズ）を中心とする産官学で共同し、半導体最先端技術の「壁」を克服する共通基盤としての役割を担っている。具体的には、半導体の微細加工において、45nmの技術世代以降の LSIの消費電力や処理速度といった基本的な性能を格 段 に 向 上 さ せ る 技 術 を 開 発 し て い る 。 ま た 、 半 導 体 理 工 学 研 究 セ ン タ ー STARC（http://www.starc.or.jp/）では、SoC設計技術等の先導開発(あすか 2)が行われている。

- 19 -

2.1.4
主参加メンバー査

金 本 俊 幾㈱ルネサステクノロジ

副 主 査

中 島 英 斉ＮＥＣエレクトロニクス㈱同高 藤 浩 資

㈱リコー

黒 川

敦

三洋半導体㈱同蜂屋孝太郎㈱ジーダット

同

古 川

且 洋

㈱ジーダット

同

田 中

正 和

パナソニック㈱同増 田 弘 生㈱ルネサステクノロジ

同佐

富士通マイクロエレクトロニクス㈱同

奥 村 隆 昌㈱半導体理工学研究センター

委

員

方

剛

客

員

佐 藤 高 史東京工業大学客員

橋 本 昌 宜大阪大学- 20 -

２.２ EDA 標準化小委員会
２.２.１ EDA 標準化小委員会(１)発足の背景とミッション
JEITA/EDA 技術専門委員会の標準化活動は、1990 年の EIAJ/EDIF 研究委員会設立に始まり、当初は EDA に関するグローバルな重要課題に対して日本の業界を代表する唯一の機関として、
特に設計記述言語の仕様標準化とその啓蒙等に多大な貢献を果たしてきた。近年は活動の中心
が設計記述言語の普及定着と環境変化に応じて、先端的設計技術に関する調査･研究等にシフトしてきている。
システム設計メソドロジの革新が進展する中で、設計技術言語の国際標準化は依然として重要なテーマである。そこで、標準化関連の活動をより明確に位置づけるため、2000 年 11 月に本小委員会が設立された。
世界的にみれば EDA 関連の標準は IEC(International Electrotechnical Commission)とIEEE(The Institute of Electrical and Electronics Engineers)で議論、制定されてきた。
IEC ではデザインオートメーションを議論する TC(Technical Committee)93、IEEE はコンピュータソサイエティの DASC(Design Automation Standards Committee)、および SA(Standards
Association)である。
これまでは IEEE で定められた標準を IEC でも追認するものも多かった。
2003 年より議論は IEEE の DASC/SA のワーキンググループでも、標準の制定は IEC と IEEE で同時にできるようになった(Dual Logo)。
国内では IEC の対応機関は、日本工業標準調査会（ＪＩＳＣ：Japanese Industrial Standards
Committee）である。また、TC 毎に国内委員会があり、電子情報通信学会や JEITA 内に組織化されている。TC93 とハードウェア設計記述言語関連のワーキンググループ(WG2)の国内委員会
は電子情報通信学会にある。
本小委員会は IEC/ＴＣ93/ＷＧ2 国内委員会を兼ねて活動するという協調体制を 2002 年度に確立した（図-1 参照）。その結果、EDA 標準化小委員会の委員が IEC/ＴＣ93/ＷＧ2 の各種標準化提案を直接審議することができるようになった。
2003 年度には、SystemC および SystemVerilog の標準化を業界として検討・推進する目的で、それぞれワーキンググループを発足させた。2007 年度には、CPF(Common Power Format)とUPF(Unified Fower Format)の二つの Power Format の標準化案の議論と統一を目的に、検討ワーキンググループを発足させた。SystemC は、ますます重要性が認識されているシステムレベ
ルの設計言語のひとつであり、SystemVerilog は IEEE1364(VerilogHDL)の後継・検証技術の拡張である。CPF/UPF の Power Format は、主にシステム LSI の低消費電力化設計の効率化を目的とした設計言語である。これらワーキンググループは、日本の標準化組織として、海外の関連団体と連携し、言語仕様の専門的な技術検討と改善提案を通じて、標準化へ貢献すること目指して活動を行っている。

- 21 -

図－１ EDA 標準化小委員会と他の標準化組織との関係

以上のような発足の背景の中で、2002 年度に本小委員会は、そのミッションを以下のように規定し、活動に取り組んでいる。
目的：
EDA 標準化小委員会(以下本小委員会)は EDA(Electronic Design Automation)関連技術の標準化動向の調査、標準化の推進、標準の策定、標準案の調査、標準の保守・改定、などを推進し、もって国内外の関連業界の発展に寄与することを目的とする。
活動内容：
本小委員会は EDA および関連技術の標準化に関して、・内外の動向を調査、検討し、・技術および関連業界の発展に資する提案の必要性を模索し、・必要かつ可能な場合には、関係機関に対して提案を行い、・内外の標準化関連機関との連携・協調・協力を推進し、・特に、デザインオートメーション/設計記述言語(TC93/WG2)WG の活動を支援し、・また広報活動を行う。

- 22 -

(２)２００８年度 EDA 標準化小委員会メンバー（2009 年 3 月現在 敬称略）
主査

太田 光保

パナソニック(株)

副主査

江田 努

ローム(株)

副主査

小島 智

NEC システムテクノロジー(株)（TC93/WG2 ココンべナ）

委員

吉田 正昭

NEC エレクトロニクス(株)

委員

山田 節

三洋電機(株)委員

西本 猛史

シャープ(株)委員熊谷

セイコーエプソン(株)

委員

齋藤 茂美

ソニー㈱

委員

南

(株)東芝

委員

河村 薫

富士通マイクロエレクトロニクス(株)

委員

秋山 俊恭

(株)ルネサステクノロジ

特別委員

相京 隆

(株)半導体理工学研究センター敬文裕（TC93/WG2 Member）
特別委員

長谷川 隆

富士通マイクロエレクトロニクス(株)（SystemC WG 主査、TC93/WG2 Member）

特別委員

今井 浩史

東芝(株)
（SystemC WG 副主査）

特別委員

浜口加寿美

パナソニック(株)（SystemVerilog WG 主査 TC93/WG2 Member）

特別委員

中森 勉

富士通マイクロエレクトロニクス㈱(Power Format WG 主査)

特別委員

金本 俊幾

㈱ルネサステクノロジ(ナノ世代物理設計 WG 主査)

特別委員

星野 民夫

(株)アプリスター（TC93/WG2 Member）

特別委員

石河久美子

富士通マイクロソリューションズ(株)（TC93/WG2 Member）

客員

今井 正治

大阪大学

客員

神戸 尚志

近畿大学
（TC93 国内委員長）(３)２００８年度活動
EDA標準化小委員会としては、年5回の会合を行い、傘下のSystemCワーキンググループ、
SystemVerilogワーキンググループ、Power Formatワーキンググループの活動状況の確認、標準化関連課題の議論を行った。SysyemC/SystemVerilogの両ワーキンググループは2005年末のSystemC、SystemVerilogのIEEE標準化に引き続き、新規標準化項目の調査検討、設計適用事例- 23 -

の調査などの積極的な活動を継続した。具体的には、SystemCワーキンググループは、TLM2.0の標準化の推進と合成サブセットの状況調査、および、推奨設計メソドロジのガイドライン作
成に取り組んだ。また、最新SystemCに関わる技術の普及促進と標準化の推進を目的として、2009年1月のシステム・デザイン・フォーラム200９でSystemCユーザ・フォーラムを開催した。
SystemVerilogワーキンググループは、IEEE1364(VerilogHDL)とIEEE1800 (SystemVerilog)の統合ドラフトに対し、国内半導体業界の意向を反映させるべくレビューを行い、IEEE-SA標準案作成に貢献し、最終案に対して賛成投票を行なった。
昨年活動を開始したPower Formatワーキンググループでは、今年は、国内半導体業界の意向を反映させるべくIEEE P1801(UPF)の標準案についての調査と検討を行い、Si2が規定しているCPFとのインターオペラビリティに関する課題の指摘・修正案の提示を行なうと共に、反対投票を行なった。

また、関連する標準化関連の組織・団体とも、下記のような活発な交流を行った。
2008 年 10 月の IEC/TC93 シンガポール国際会議には、本委員会から TC93 国内委員会委員長である神戸客員、WG2 国際コ・コンベナの小島副主査、および小委員会主査の太田の 3 名が出席した。
（詳細は 2.2.3 章 IEC/TC93 の（５）項参照）
また、IEEE DASC の段階から標準の詳細についての論議が進む実態があることから、本年度より小島副主査を正規にメンバーとして登録し、深い連携がとれる体制をとった。また、2009
年 1 月には、Victor Berman 議長他を招き、DASC の月例会議を日本で開催し、本小委員会からも多数が出席した。
更に、IEEE-SA との連携・協力の一環として、IEEE-SA One-Day Seminar(Tokyo Japan)において、小島副主査と長谷川 SystemC ワーキンググループ主査が、それぞれ「日本ＥＤＡ標準化の推進状況」「The IEEE P1666 Project :日本国内における SystemC 標準化活動」というタイトルで講演し、我々の活動のアピールを行なった。
また、SystemC ワーキンググループは、TLM2.0 等の調査・検討で OSCI との連携を図っている。システム・デザイン・フォーラム 2009 では、OSCI から、後援と、TLM2.0 の最新状況に関するご講演とを頂いている。

- 24 -

２.２.２ IEEE/DASC(電気電子学会／設計自動化標準委員会）
・IEEE-SA(１) 活動の概要
IEEE は米国に本部を置く電気、電子、情報、などの国際的な学会である。また、この分野の標準化活動を長年にわたり、しかも広範囲に実施している。DASC、SA は IEEE の下部組織として、エレクトロニクス産業における設計自動化関連の標準化活動を行っている。
活動の中心は、標準設計記述言語(HDL: Hardware Description Language)の VHDL と Verilog
HDL に関連する設計と検証であり、タイミング情報、論理合成、算術関数とテストの標準化に注力している。これら設計言語に関連して、 システムレベルまで適用範囲を拡大して、Analog
Mixed Signal、ソフトウェアとハードウェア協調設計等の拡張の標準化を検討している。2005
年には SystemC と SystemVerilog という高位設計技術言語、設計と検証を統合した記述言語の標準化作業が完了した。

(２)JEITA/EDA-TC との関連
これまでは EDA 技術専門委員会は IEEE/DASC のメンバーとして関連する WG に参加し、標準化案に日本の意見を反映してきた。
2004 年 12 月には IEEE-SA の正式メンバーにもなり、IEEEの標準化活動に、ドラフトレビュー・標準化案の改善の提案・投票を通じて積極的に参加している。
特に、今年度は、EDSFair2009 合わせてに IEEE/DASC の月例会議を日本で開催した。
（2008
年 1 月 23 日） 会議には、米国からは Victor Berman 議長、Stan Krolikoski 副議長 Dennis Brophy
氏（Accellera Vice Chair）、本小委員会関係からは、太田主査、小島副主査、齋藤委員、山本委
員、古井 TC93 国内幹事、長谷川特別委員、浜口特別委員、中森特別委員、金本特別委員、他
ナノ世代物理設計ＷＧからも委員 3 名が出席した。また、国外からの電話会議出席者も 8 名あり、計 23 名が出席し、盛会であった。
会議において、EDA 技術専門委員会からは、活動状況の紹介と、SystemC TLM2.0 の標準化のマイルストーン、IEEE1801（Power Format）の balloting、Sensibity SPEF、ＡＭＳ関連言語のハーモナイゼーション等の状況確認を行なった。Sensibity SPEF については、WG の John Beatty
議長と金本特別委員がコンタクトをとることとなった。Berman 議長からは、各標準化団体間での標準の調整についての課題提起等があった。標準の調整に関する課題提起は、予ねてより、一つの分野には一つの標準を主張している JEITA の方針に合致しており、今後、重要となる案件である。

(３)これまでの成果と現在の状況①これまでの成果
DASC/SA ではこれまでに以下の標準化作業を行っており、そのうちのいくつかは、IEC でも標準として承認されている。

- 25 -

(1) VHDL (Std-1076)(2) VHDL Analog Extensions (Std-1076.1)(3) VHDL Math Package (Std-1076.2)(4) VHDL Synthesis Package (Std-1076.3)(5) VHDL Timing (VITAL) (Std-1076.4)(6) Verilog HDL (Std-1364)(7) MVL-9 (Std-1164)(8) Waveform and Vector Exchange (WAVES) (Std-1029.1)(9) The RTL Synthesis Interoperability Standard (Std-1076.6)(10) The Delay and Power Calculation Standard (Std-1481)(11) The Open Model Fundations Standard (Std-1499)(12) SystemVerilog (Std 1800-2005)(13) Verilog (Std 1364-2005)(14) SystemC 2.1 (Std 1666)②現在の状況
2009 年 3 月現在の DASC および SA とその傘下の Working Group と Study Group は以下のとおり。
•

P1076 Standard VHDL Language Reference Manual (VASG)o

VHDL-200x: the next revisionoIssues Screening and Analysis Committee (ISAC)oVHDL Programming Language Interface Task Force (VHPI)•

P1076.1 Standard VHDL Analog and Mixed-Signal Extensions (VHDL-AMS)•

P1076.1.1 Standard VHDL Analog and Mixed-Signal Extensions - Packages for Multiple
Energy Domain Support (StdPkgs) - this group is now part of 1076.1•

P1076.4 Standard VITAL ASIC (Application Specific Integrated Circuit) ModelingSpecification (VITAL) - This group is now part of 1076.

•

P1481 Standard for Integrated Circuit (IC) Open Library Architecture (OLA) (IEEE1481R)•

P1647 Standard for the Functional Verification Language 'e' (eWG)•

P1685 SPIRIT XML Standard for IP Description (IEEE-1685)•

P1699 Rosetta System Level Design Language Standard•

P1778 ESTEREL v7 Language Standardization•

SystemVerilog Working Groupo

P1800 SystemVerilog: Unified Hardware Design, Specification and Verification
Language (SV-IEEE1800) [cosponsored with IEEE-SA CAG]

- 26 -

o

P1364 Standard for Verilog Hardware Description Language (IEEEVerilog)•

P1850 Standard for PSL: Property Specification Language (IEEE-1850)•

P1801 Standard for the Design & Verification of Low Power ICs

２.２.３ IEC/TC93 (国際電気標準会議／デザインオートメーション)(１)活動の概要
IEC は 1906 年に設立された国際標準化機関であり、本年が 102 年目ににあたる。設計自動化を取り扱う IEC/TC93 は 1992 年に設立された。
TC93 の全体会議は毎年開催されており、
スイス、
英、仏、米、デンマーク、日、英、米、独、伊と開催されてきた。最近は、2002 年 10 月 中国･北京、2003 年 11 月・2004 年 10 月 米国・Piscataway、2005 年 9 月 日本・京都（奈良）、200
６年 9 月 ドイツ・ベルリン、2007 年 9 月米国・ガイザーズバーグでの開催があり、本年度は、10 月にシンガポールの IEC Asia-Pacific Regional Centre で開催された。

(２)TC93 の組織と参加国
2008 年 3 月現在 IEC の Web サイト(www.iec.ch)によれば､24 カ国が TC93 のメンバーとなっている。IEC のメンバー資格には、P(Participating) と O(Observer) の二種類があるが、今年度、韓国が O メンバーから P メンバーに変わったことで、P メンバーが 4 カ国、O メンバーが 20 カ国となった。韓国以外の P メンバーとしては、日本、中国、米国が登録されており、Oメンバーとして、オーストラリア、ベルギー、チェコ共和国、デンマーク、エジプト、フィンランド、フランス、ドイツ、ハンガリ、インド、アイルランド、イタリア、オランダ、ロシア、
セルビア、シンガポール、スペイン、スウェーデン、ウクライナ、イギリスが登録されている。
幹事国は米国（国際幹事：Victor Berman 氏）が、国際会議議長は日本(唐津氏)が担当している。

(３)TC93 の組織とワーキンググループ(WG)
TC93 は７つの WG/JWG から構成されている。 特に、WG2、WG3、WG6、および WG7 は日本から提案も含め積極的な貢献をしてきた。今までの各 WG の主な活動を示す。
WG1:モデルのハーモナイゼーション： (a)STEP Electrical(ISO 規格)と EDA 標準の整合性の検討、(b)EDIF と AP-210 との整合性の検討。(c)言語間のＩｎｔｅｒｏｐｅｒａｂｉｌｉｔｙの検討
WG2:ハードウェア設計記述言語： (a)VHDL 言語仕様、Verilog HDL の整合性等の検討、システ
ム記述言語(SLDL)も議題に取り上げられてきた。(b)IC delay&power calculation system の検討。 日本からの提案 ALR 標準化;IS(国際規格)化完。現在は- 27 -

SystemC,SystemVerilog,PowerFormat が中心。
WG3:設計データ交換表現：PDX(Product data eXchange)によるマテリアルデクラレーション関連への対応の議論。
JWG11:記述の XML 化の流れへの取り組み方の議論。
WG5:規格適合性（コンフォマンス）テストの具体的事案の議論。
WG6:再利用可能部品ライブラリ、日･米･欧の各プロジェクト間の仕様整合と連携の検討、日本からは JEITA/ECALS プロジェクトの成果を提案している。IBIS も話題に取り上げられている。
最近は電子カタログの流通に関する規格案が議論の中心となっている。
WG7:システムテスト記述言語、ATML(Automatic Test Markup Language)の検討。

(４)TC93 国内委員会と主要メンバー（2008 年 3 月現在。敬称略）･ TC93 国際会議
議長: 唐津 治夢(SRI ｲﾝﾀｰﾅｼｮﾅﾙ)
・ 国内専門委員会
委員長: 神戸 尚志(近畿大学) *幹事:

古井 芳春（STARC）

委員: 太田 光保(パナソニック) *、柴田 明一(JPCA) 、高橋 満(日立)、山下 寛巳(SML)･ WG2:(ハードウェア設計記述言語) 主査:

太田 光保（パナソニック） *国際コ・コンベナ: 小島 智(NEC システムテクノロジー) *委員: 長谷川 隆(富士通マイクロエレクトロニクス) *、浜口 加寿美(パナソニック) *、中森 勉(富士通マイクロエレクトロニクス)*、山田 節（三洋） *･ WG3:(設計データ交換表現) 主査: 神戸 尚志(近畿大学) *･ WG6:(再利用可能部品ライブラリ) 主査: 高橋 満(日立、国際コ・コンベナｰ)･ WG７:( システムテスト記述言語) 主査: 山下 寛巳(SML)
委員: 唐津 治夢(SRI ｲﾝﾀｰﾅｼｮﾅﾙ、国際コ・コンベナ)*印は EDA 技術専門委員会からの参加者(５)TC93 シンガポール会議の報告
2008 年の国際会議は、10 月にシンガポールの IEC Asia-Pacific Regional Centre(IEC-APRC)で開催された。
従来、P メンバー国としては日本と米国のみの参加も多かったが、本年は、中国と、新たにP メンバー国として加わった韓国、および、O メンバー国シンガポールの計 5 カ国からの参加があり、深い議論ができた。出席者は、米国から 4 名、日本からは 7 名、韓国・中国・シンガポールからは、各 1 名の出席があった。
会議では、TC93 プレナリー会議、WG1,WG2,WG3, WG6,WG7,JWG11 の 7 会合が開催された。
WG２では、小島副主査から国際コ・コンベナとして、IEEE1076-2008/IEC61691-1-2 (VHDL) 、
IEEE1800-2010/ IEC61691-6-2(Integration of System Verilog and VerilogHDL)、IEEE1801/- 28 -

IEC61523-4(Power Format)、IEEE1481-1999/IEC61523-1-2(DPC)、
IEEE1497-2001/IEC61523-3-2(SDF)等の 2009 年以降に予定されているデュアルロゴ案件の報告・確認等が行なわれた。
JEITA からは EDA 技術専門委員会の活動状況や、IEEE、Accellera、OSCI 等との連携状況を紹介するとともに、Power Format に関する二つの標準化の動向に懸念を示し、インタオペラ
ビリティの確保を求めた。
また、WG1 では、神戸国内委員長より、WG2 で標準が規定される前に、その言語やフォーマットを検討して、既存の標準とのインタオペラビリティを確認すべきであるとの提案が出され、WG1 の課題として残すこととなった。

(６) IEC 規格投票について
本年は IEC 標準に関わる投票は無かったが、2009 年度以降、次の 5 件が IEEE 標準からのデュアルロゴとして、FDIS(Final Draft International Standard)投票が行われる見込みである。
1) IEEE1076-2008(VHDL) ⇒ IEC61691-1-22) IEEE1800-2010(Integration of System Verilog and VerilogHDL) ⇒ IEC61691-6-23) IEEE1801 (Power Format) ⇒ IEC61523-4
4) IEEE1481-1999(DPC) ⇒ IEC61523-1-25) IEEE1497-2001(SDF) ⇒ IEC61523-3-2- 29 -

２.２.４ SystemC ワーキンググループ報告(1) 背景ハードウェア記述言語によるシステム LSI の設計は、VHDL（IEEE 1076）や Verilog-HDL（IEEE 1364）の標準化への JEITA(旧 EIAJ)の貢献とともに広く普及して、産業界で活用されている。一方、半導体の微細化技術は開発がさらに加速され、既に 1000 万ゲート規模の LSI が開発されるに至り、さらに抽象度の高いレベルからの設計が必須となってきている。1990 年代半ばより複数のシステムレベル設計言語の提案が行われ、標準化推進団体が結成されたものもあった。この中で、C++言語を基本とする SystemC は広く半導体メーカ、
システムメーカ、EDA ベンダーの賛同を得て、Open SystemC Initiative（OSCI） が結成
され、標準化のための言語仕様の策定と整備が進められてきた。
システムレベル設計言語としての要件を備えた SystemC 2.0 のリファレンスシミュレー
タがまず 2001 年 10 月にリリースされ、その後 2003 年 5 月に言語参照マニュアル（Language Reference Manual, 以下 LRM）が一般公開された。この LRM が 2004 年 11
月に OSCI より IEEE に移管され、IEEE P1666 として正式な標準化プロセスが開始された。並行して OSCI にて開発されていた SystemC 2.1 の言語拡張仕様も IEEE P1666 標準の一部として追加移管され、2005 年 12 月に IEEE Std. 1666-2005 として SystemC のコ
ア言語部分の標準化が完了した。
(2) 目的
上記のように標準化が進められた SystemC は、SoC(System on Chip)の開発のためのシステムレベル記述言語として既に設計や検証に幅広く使われるようになり、欠くことのできない言語となってきている。設計言語は設計の基本となるもので、この標準化策定に早くから関わることは、産業界にとって次世代の設計手法を構築する上で非常に重要なことである。
本ワーキンググループは2003年10月に設置され、日本国内における唯一のSystemCの標準化関連組織として、IEEE P1666で進められるSystemC標準作業に対して日本の産業界として意見を述べ、国内事情・要求事項を取り込んだ形で国際標準化に貢献していく。また、
SystemCに関連した調査結果をアニュアルレポートやユーザ・フォーラム等で積極的に情報発信を行うことで、SystemCを利用した設計手法の国内普及を図り、ひいては日本の産業界の国際競争力を高めることを目指す。
(3) これまでの成果
2003年10月に発足した後、これまでに次のような成果をあげた。
① SystemC 標準化活動
・

2003 年度は OSCI より 2003 年 5 月に一般公開された LRM についてレビューを行
い、問題点を 62 件抽出し(うち 46 件については 2003 年度の活動報告書に一覧を記載)、IEEE 並びに OSCI に報告した。

・

2004 年度は IEEE P1666 のメンバーとして活動を行い、IEEE 版の LRM(Draft)- 30 -

をレビューし、43 件の問題点を IEEE に報告した。
・

2005 年度は SystemC 2.1 が追加された IEEE P1666 版 LRM についてレビューを行い、１９件の問題点を抽出し IEEE に報告した。2005 年 12 月 5 日に IEEE Std.
1666-2005 として SystemC の基本言語部分の標準化が完了した。プレスリリースも発行され、EDA-TC/JEITA としてもコメントを掲載した。

・

2006 年度は OSCI よりリリースされた TLM(トランザクションレベルモデリング)
2.0 ドラフト１、及び合成サブセットドラフトについてレビューを行い、問題点や要望事項をそれぞれ４件、５７件 OSCI に伝えた。

・2007 年度は OSCI よりリリースされた TLM 要求仕様、用語集について分析を行い、また 11 月にリリースされた TLM 2.0 ドラフト２についてレビューを行い、問題点や要望事項を 10 件 OSCI に伝えた。

・2008 年度は OSCI よりリリースされた TLM 2.0 正式版のユーザーズマニュアルについてレビューを行い、問題点や要望事項を 7 件 OSCI に伝えた。（詳細は「4.2.4
OSCI TLM2.0 へのフィードバック」を参照）また、ユーザーズマニュアルの抄訳を作成し、本アニュアルレポートにて公開した。

② SystemC 技術調査・

2003 年 11 月度に集中審議を行い、本ワーキンググループ参加各社の SystemC 利
用状況について紹介しあい、業界内の現状ステータスについて理解を深めた。

・

2004 年度には、過去５年間に一般に公開されている SystemC 関連の論文や発表資料等 50 件の調査を行い、報告書を作成した。

・2005 年度は、SystemC 2.1、TLM(トランザクションレベルモデリング)、合成サブセットのテーマを定め、それぞれ分科会形式で掘り下げた調査を行った。

・2006年度はTLMに関する動向調査を実施し、結果をSystemCユーザ・フォーラム
2007にて公表。欧州ユーザと比較し、国内ユーザは低抽象度のモデルを利用する傾向が高いことを掴んだ。TLMの標準化の遅れにより再利用性があまり高くないことから、RTL設計に近いレベルでの利用に留まっていると予想される。欧州では標準化を持たずに社内でTLM標準化を行い、一丸となって利用を進めているようである。

・

SystemCを用いた高位合成を効果的に行うためには記述スタイルの標準化が望ましいため、スタイルガイドの骨子を検討し、「合成スタイルガイド構成要件」としてまとめ、アニュアルレポートにて公開した。

・

2007年度はSystemCを用いた推奨設計メソドロジについて検討し、合成編について審議を完了し、アニュアルレポートにて公開した。

・2008年度は引き続きSystemCを用いた推奨設計メソドロジについて検討し、昨年作成した合成編以外の部分について審議を完了し、本アニュアルレポートにて公開した。

③ SystemC 普及活動
- 31 -

・

2004 年度より、それまでの OSCI から引き継いで JEITA EDA 技術専門委員会の主催で SystemC ユーザ・フォーラムを開催している。

・

2005 年 1 月 27 日に SystemC ユーザ・フォーラム 2005 を開催。受講料は無料。定員 200 名のところ 250 名弱の聴講者が訪れ、立ち見が出るほどの盛況であった。

・2006 年 1 月 27 日に SystemC ユーザ・フォーラム 2006 を開催。今回より、受講料を徴収することにした。(SystemC 単独の場合¥1,600、SystemVerilog と通しの場
合¥2,000) 定員 200 名のところ、事前予約では満員であったが、実際に会場に訪れた聴講者は 172 名で前年比 30%減となった。 また、アンケートは 134 名の方に記入いただけた。

・2007 年 1 月 26 日に SystemC ユーザ・フォーラム 2007 を開催。前回より値上げした影響か、聴講者は前年比 14%減の 148 名と減少した。また、アンケートは 13２
名の方に記入いただけた。

・2008 年 1 月 25 日に SystemC ユーザ・フォーラム 2008 を開催。今回は TLM に関するトピックを多くしたせいか、聴講者は前年比 12%増の 166 名となった。また、
アンケートは 1４４名の方に記入いただけた。

・2009 年 1 月 23 日に SystemC ユーザ・フォーラム 2009 を開催。今回は聴講者が前年比 26％減の 123 名と大幅に減少した。TLM 2.0 に関しては 2008 年夏に山場を越えており、SystemC そのものにおける大きな変化がなかった点と、景気の悪化もひとつの要因と考えられる。また、アンケートは 113 名の方に記入いただけた。

・2009 年のアンケート調査結果から、次のような事が読み取れた。(詳細については
4.2.6 を参照)¾

今年度は SystemC の利用経験がない方の参加が多かった。

¾

過去のアンケートで、SystemC を利用しない理由としては、「HDL で十分」「言語の完成度が低い」等の回答があったが、今回のアンケートでは、これらが大幅に減少する一方で、 「効果が不明」 「検討する時間がない」といった理由が多く挙がった。これについては、本アニュアルレポートにて公開した推奨設計メソドロジが貢献できるものと期待している。

¾

TLM の標準化が一段落したこともあり、標準化に対する興味よりは、適用事例に期待して参加する方が多かった。

(4) 参加メンバー
主査

長谷川

隆

富士通マイクロエレクトロニクス㈱

副主査

今井

浩史

㈱東芝

委員

中西

早苗

ＮＥＣエレクトロニクス㈱小島智ＮＥＣシステムテクノロジー㈱- 32 -

客員

清水

靖介

ＯＫＩセミコンダクタ㈱長尾文昭

三洋半導体㈱

柿本

勝

ソニー㈱

逢坂

孝司

日本ケイデンスデザインシステムズ社

西園寺 修

日本シノプシス㈱竹村

パナソニック㈱和祥

牧野 潔

メンターグラフィクスジャパン㈱大島 良紀㈱ルネサステクノロジ

長谷川 裕恭㈱エッチ・ディー・ラボ

東島清宏

コーウェア㈱

今井

正治

大阪大学
（計 15 名）- 33 -

2.2.5 SystemVerilog ワーキンググループ(1) 背景
昨今の LSI 設計において、一般的に使用されている Verilog HDL(ハードウエア記述言語)は、特定ツールの独自言語として開発されたが、その後、OVI（Open Verilog International）による言語仕様の公開を経て、標準化がなされた。
JEITA（旧 EIAJ）の EDA 技術専門委員会では、当時より Verilog HDL 標準化プロジェクトを設置し、継続的に言語仕様の技術検討・国際標準化に貢献してきた。
VerilogHDL は、1995 年に IEEE1364 として標準化承認がなされ、その 5 年後にはディープサブ
ミクロン対応の機能が盛り込まれ、IEEE1364-2001 として改訂された。
その後、半導体の微細化技術はさらに進化し、1000 万ゲート規模の LSI が開発されるに至り、機能検証の網羅性と検証効率を飛躍的に向上させるために、新しいテストベンチ記述、アサーション／
プロパティ記述など、いくつかの検証用言語が実用化された。
SystemVerilog は、Verilog HDL に 新たな「デザイン記述構文」の機能追加と、「検証用言語」を追加したものである。デザインにおいて、Verilog HDL に比べ「記述量の削減」や「曖昧性の排除」
といったメリットがあり、設計品質の向上が期待される。また検証においては、「網羅性」や「効率」の向上が期待される。Accellera が、この言語仕様を SystemVerilog V3.1a としてまとめ、IEEE での標準化作業を経て、2005 年に IEEE1800 として標準化された。
現在は、Verilog HDL の IEEE1364 と、SystemVerilog の IEEE1800 をひとつの標準言語として統合するための標準化活動がされており、2009 年度中に IEEE1800 として標準化される計画である。
本ワーキンググループは、2005 年の初の IEEE1800-2005 と IEEE1364 を統合した改訂版
IEEE1800-2009 の標準化に取組んできた。
(2) 目的日本の半導体業界の要望に沿った形で、SystemVerilog 言語の標準化を進めることが、国内の設計
現場での適用容易性を高め、「設計品質の向上」そして「国際的な競争力確保」といった結果につながる。本ワーキンググループでは、業界各社から参加したエキスパートにより、SystemVerilog 言語
仕様の技術的な検討を実施し「国際標準化に貢献すること」、SystemVerilog に関する最新の情報収集と発信、「日本国内での SystemVerilog の普及推進を図ること」を目的としている。
(3) 活動内容①グループ結成
03 年 10 月に、SystemVerilog言語仕様の技術検討・標準化を推進するためのタスクグループとして「SystemVerilogタスクグループ」を結成した。07 年度 4 月に「SystemVerilogワーキンググループ」に名前を変更し現在に至る。

- 34 -

②IEEE1800-2005、IEEE1800-2009 言語仕様検討とIssue Listの提出(03～07 年度)
IEEE1800-2005 の標準化に対し、04 年 8 月に改善提案を含む 32 件の Issue List をまとめ AccelleraとIEEE に提出、
IEEE1800-2009の標準化に対しては、
07年5月に新たに35件のIssue ListをIEEEに提出した。
各提案については、全件が採択あるいは対応を完了するまで、状況チェックとフォローを実施した。

③国際的な情報収集・標準化組織との連携と投票(03～08 年度)
04 年と 07 年には、米国で開催された国際学会 DVCon(Design & Verification Conference)にメンバを派遣し、最新技術動向の情報収集をおこなうとともに、IEEE のワーキンググループ会議参加により、日本での活動内容を報告した。
また、
本ワーキンググループでの活動成果を IEEE の標準化作業に反映するため(提案の優先度をあげ投票権を得る)、IEEE の標準化機関 IEEE-SA に加入した。
そして、05 年度、08 年度の IEEE1800 投票グループに登録し、それぞれ投票を実施した。
④SystemVerilog/SystemCの対訳表の作成(05～06 年度)
SystemVerilog の専門用語に関し、多くの翻訳書や EDA ベンダが提供するユーザマニュアル類で多様な訳語が存在すると利用者の混乱を引き起こすため、標準的な訳語を定義することを目的として対訳表を作成した。SystemC ワーキンググループとも連携し、SystemC と SystemVerilog 共通の対訳表をひとつにまとめた。本対訳表を標準訳語として、出版社・EDA ベンダをはじめ、業界全体に公 開 し 、 適 用 さ れ る よ う 推 進 し た 。 対 訳 表 は 、 2006 年 度 版 ア ニ ュ ア ル レ ポ ー ト に「SyetemC/SystemVerilog 専門用語対訳表」として掲載した。

⑤SystemVerilogユーザフォーラムの開催(04～06 年度)
05 年、06 年、07 年の 1 月に、EDS フェア併設の「システム・デザイン・フォーラム」のカリキュ
ラムのひとつとして「SystemVerilog ユーザ・フォーラム」を 3 年連続開催した。
このフォーラムでは、Accellera・IEEE p1800-WG の標準化状況の説明、SystemVerilog の特徴・利点を広く周知させるための「SystemVerilog 言語チュートリアル」を３部に分けて実施した。

(4) 08 年度の主な活動内容○08 年 6 月 IEEEp1800/Draft5（英語 1162 ページ)のレビュー
35 件の指摘･要望のうち、32 件が対応済みであることを確認
残り 3 件に対し、追加説明と再要求を IEEEp1800-WG に対して実施○08 年 12 月

IEEEp1800/Draft8（英語 1162 ページ)のレビュー

35 件の指摘･要望の全件が対応済みであることを確認- 35 -

○08 年 3 月 最終ドラフトを確認し投票を実施
本ワーキンググループは、この IEEE1800-2009 の投票をもって活動を終了した。
本ワーキンググループが IEEEp1800 に提出した Issue List(35 案件とその最新対応状況)
を「SVTG-1 IEEEp1800-2009 Issue List」として付録に添付する。

(6) 参加メンバ

主査

浜 口 加寿美松下電器産業㈱副 主 査

明 石 貴 昭日本シノプシス㈱委員

湯 井 丈 晴㈱沖ネットワークエルエスアイ

同後 藤 謙 治日本ケイデンス・デザイン・システムズ社

同

土 屋 丈 彦㈱東芝

同

竹田津 弘 州

松下電器産業㈱同李

メンター・グラフィックス・ジャパン㈱同高 嶺 美 夫㈱ルネサステクノロジ

同

杉 浦 正 志㈱図研

建 道- 36 -

2.2.6 PowerFormat 検討グループ報告(1) 背景近年、System-LSI に対する低消費電力化の要求はますます強くなってきている。 バッテリー
駆動の携帯機器用のみならず、環境保護の面から家電製品やサーバー用途に至るまで全ての領域で低消費電力化は LSI 設計における最大の課題のひとつとなってきた。 一方で、性能向上の要求とプロセスの微細化によるチップあたりの回路規模の増加、さらにはリーク電流の増加が低消費電力化を困難な問題にしている。
その結果、LSI インプリ時において従来から適用されてきたクロックゲーティングやマルチ Vthといった低消費電力技術に加え、マルチ VDD・パワーゲーティング・バックゲートバイアス等の高度な技術が一般に適用される割合が飛躍的に増加している。
市販のインプリツールでもこれらの技術のサポートが進んできたが、従来の RTL では表現することが出来ない電源接続（や分離）に関する情報を記述する共通のフォーマットが設計における重要なポイントのひとつになってきた。
2006 年 6 月、CADENCE 社は 十数社の半導体ベンダー、EDA ベンダーと共に PFI(PowerForward Initiative) を組織し、電源接続やマルチ VDD,パワーゲーティングを表現可能な標準形式
CPF(Common Power Format)を策定した。 一方、SYNOPSYS と MENTOR はこの動きに対抗
し、Accellera で UPF(Unified Power Format) を作り、２つの「標準」フォーマットが出来てしまった。
現在、CPF は Si2 にて Rev 1.0 が公開され、CADENCE をはじめとしたインプリツール群で2007 年初頭からサポートされている。 UPF は Accellera にて Rev 1.0 が公開された後、IEEEに引き継がれ IEEE-P1801 として標準化作業中である。 2007 年終り頃からシノプシス、メンタ
ーのツールでのサポートも始まっている。
複数のツール間で電源表現を共通にするべく作成された両フォーマットであるが、ベンダー毎にサポートしている PF（パワーフォーマット）が異なるため、皮肉にもコンバージョンや互換性といった新たな問題を半導体ベンダーにもたらす結果となった。

(2) 目的日本を始め多くの半導体ベンダーでは、複数の EDA ベンダーのツールを使用して LSI 設計を行っているため、２つの「標準」PF の存在は今後障害となることが予想される。 フローのある部
分のツールは CPF, 別の部分のツールは UPF が必要となれば、結局フォーマットのコンバージョンが必要となり、手間が減らず互換性も問題となる。
PF を統一し、全てのツールがそれをサポートするのが理想ではあるが、既に CPF/UPF 共に仕様が固まっており、Si2, Accellera 両陣営も統一化に対しては後ろ向きであるため、現時点では非常に難しい。 ツールへの CPU/UPF インプリメントも進んでしまっている状況である為、たとえ今- 37 -

すぐフォーマットが統一されたとしても全ツールがそのサポートを完了するには１～２年の時間が必要で、その間はやはり両フォーマット間のコンバージョンが必要となることが予想される。
以上の理由から、早急なフォーマットの統一は目指さず、両フォーマットのインターオペラビリ
ティの確保を第一の目的とする。 また、IEEE P1801 へのフィードバック、投票を行う。
(3) 活動内容
ワーキンググループの結成とPF比較表の作成(08 年度 下期)
08 年 10 月に開始された IEEE P1801 (UPF) 投票に JEITAとして参加した。 具体的には 各委員によりドラフトをレビューし、特にCPFとのインターオペラビリティ保持の観点から 13 件のフィードバック（改善提案を含む）を JEITAとして合意した。 このうち 4 件が採用され、ドラフトの最新版に反映された。

主な活動は以下のミーティングとメーリングリスト上にて実施した。
2008 年 11 月 26 日 第一回ミーティング IEEE P1801 ドラフトへの各社フィードバック
すり合わせ、合意
2008 年 11 月 27 日 IEEE P1801 投票(4) 関連機関の動向
IEEE では、P1801 の投票を 2008 年 11 月 27 日（第一回）、 2009 年 01 月 08 日（第二回）を実施、2009 年 3 月に正式に規格化見込みである。
(5) 参加メンバ
主

査

中 森

勉

副 主 査

南

委

安 井 卓 也

パナソニック同

井 上 善 雄ルネサステクノロジ

同

中 村 正 昭三洋半導体

同

熊 野 義 則リコー

同山 田 陽 一セイコーエプソン

同山 縣 暢 英

ソニー

同

北 原

東芝

客

員

員

特別委員

文 裕

富士通マイクロエレクトロニクス健

東芝

神 戸 尚 志IEC/TC93 国内委員長 （近畿大学）

小 島

IEC/TC93/WG2 ココンベナ (NEC システムテクノロジー)

智- 38 -

３．各種イベント(主催／協賛)報告

3.1 Electronic Design and Solution Fair 2009 (EDSFair2009)
社団法人 電子情報技術産業協会（JEITA） 半導体部会主催により、2009 年 1 月 22 日（木）～23 日（金）の 2 日間、パシフィコ横浜にて、半導体に関連する設計、製造技術の専門性の高い情報を一堂に集めた展示会「Electronic Design and Solution Fair 2009 (略称:EDSFair2009 )」を開催した。
出展社数は、143 社、来場者 9,117 人であった。
今回は、キャッチフレーズを 「未来を設計する！～先端技術を見て、聴いて、感じる 2 日間～」とし、新しいソリューションが求められる時代に対応した世界最先端技術・サービスの展示とともに、若手技術者向けのオープンセッション、国内外のベンチャー企業を集めたゾーンの設置、産学官の技術交流を深め
る企画、多彩なコンファレンス等を展開し、広く情報発信を行った。
キーノートスピーチでは、「より速く、より大きく、日本の創造的半導体技術」と題して、テラ・ヘル
ツ帯の光通信技術や、損失の少ない送電や給電を研究されてきた、首都大学東京学長の西澤潤一先生にご登壇いただき、300 名が熱心に聴講した。
また、会場内の特設ステージでは、ベンダのエグゼクティブと日本のユーザ（設計者）とのパネルディ
スカッションを行い、開発現場が抱えているノイズと FPGA/PLD の課題について解決案をぶつけて討論した。また、前回に引続き、『今さら聞けないことがわかる！未来がわかる！』と題した若手エンジニア
や元エンジニアの方向けの講演を行った。いずれのセッションも多数の聴衆を集め、立ち見がでるほどであった。
さらに、エンジニアが注目する最新技術やトピックスに関する展示をまとめた特別ゾーンとして、
SI/PI/EMC 対策をテーマに、この問題の解決策を展示紹介する、「電磁界解析・SI/PI テクノロジ・ゾー
ン」、FPGA 関連の出展者を集めた、「FPGA ビレッジ」、近年日本への進出が目覚ましい、インドの半導体設計技術に関連する企業が集結した、「インド・パビリオン」を新たに設置した。また、昨年から引き続き、普段接することが少ない国内外のベンチャー企業のソリューションを集めた「新興ベンダエリア」
や、産学官の技術交流を深める大学の研究発表の場となる「ユニバーシティ・プラザ」、EDA 開発に携わる国内のベンチャー企業が一同に集結し、日本企業ならではの「ものづくり力」を活かした技術や製品をアピールする、「JEVeC ビレッジ」の合計 6 つの特別ゾーンを会場内に設置した。
また、日頃多忙な来場者に、効率的、効果的に EDSFair を見学いただくためのサポートサービスとして、消費電力、コスト削減、技術課題を解決するソリューションが一目でわかる案内マップを提供する「コンシェルジュサービス」を新たに企画した。また、海外出展企業を見学希望する来場者に、日本の設計技術・EDA 技術の第一人者が、ツアー・ガイドとしてブースへ同行訪問し、各社の技術紹介・質疑応答を日
本語でサポートする「ガイド・ツアー」を「インド・パビリオン」まで拡大させ実施した。各ツアーとも
10～20 名の参加者がおり、訪問した新興ベンダからは非常によい企画と好評であり、参加者からも新興ベンダへアクセスするきっかけができたと大変好評であった。

- 39 -

3.1.1 EDSFair2009 の概要(1) 開催期間：2009 年 1 月 22 日(木)～1 月 23 日(金) 2 日間
(2) 場所：パシフィコ横浜（展示ホール、アネックスホール）(3)主催：社団法人電子情報技術産業協会（JEITA）
協力：Electronic Design Automation Consortium（EDAC）
後援：経済産業省、アメリカ合衆国大使館、外国系半導体商社協会（DAFS）、横浜市経済観光局（順不同）
協賛：社団法人電子情報通信学会（IEICE）、社団法人情報処理学会（IPSJ）、社団法人日本電子回路工業会（JPCA）（順不同）
運営：有限責任中間法人日本エレクトロニクスショー協会（JESA）(4) 開催概況① 入場者数：9,117（前年 10,431 名）② 出展者数：143 社/317 小間（前年 169 社／339 小間）③ 出展者セミナー：104 セッション、延べ聴講者数 2,070 名（前年 101 セッション、3,225 名）④ スイートルーム：6 社（前年 6 社）
⑤ ユニバーシティ・プラザ：22 ブース、22 大学研究室（前年 21 ブース、21 大学研究室）⑥ キーノートスピーチ：聴講者数 300 名（前年 355 名）⑦併催
第 16 回 FPGA/PLD Design Conference：8 セッション、聴講者数 349 名（前年 8 セッション、
515 名）⑨同時開催
システム・デザイン・フォーラム 2009：2 セッション、聴講者数 216 名（前年 2 セッション、
282 名）ASP-DAC 2009 (Asia and South Pacific Design Automation Conference)/Designers' Forum
来場者業種内訳
2009 年2008 年率

半導体・電子部品

3,747

4,736

79%

機器メーカ

2,250

2,660

85%

ツールベンダ

579

563

103%

設計関連サービス

1,071

1,095

98%

商社・営業

437

428

102%

出版・マスコミ

135

115

117%

その他

898

834

108%

計

9,117

10,43187%

世界経済が低迷する中で、来場者数が昨年より約 13％減少し、2 日間合計で 9,117 名となった。
大手電機メーカーが大幅な赤字を発表しい出張規制を行うなど、大変厳しい環境の中での開催となった。
- 40 -

3.1.2 出展カテゴリー(1)ハードウェア・ソリューション
システム LSI、ASIC/ASSP、MPU／MCU／DSP、FPGA/PLD デバイス、他(2)ハードウェア開発環境（EDA)①EDA/LSI 設計関連ツール
システムレベル設計（RTL より高位）、論理設計（RTL～ネットリスト）、論理検証、アナログ設計・検証、レイアウト、レイアウト検証・解析、LSI 信号解析、テスト設計（DFT/BIST/ATPG など）、
DFM 関連（OPC/RET/PSM/LRC/TCAD など）、ASIC プロトタイピング、他②PCB/SiP 設計関連ツール
回路図作成、アナログ設計・検証、レイアウト、SI/PI/EMC 解析、電磁界解析、熱解析、他(3)ソフトウェア・ソリューション
組込み OS、デバイスドライバ、ファームウェア、ミドルウェア、仮想開発環境・技術、他(4)LSI テスト、計測器
LSI テスタ、PCB テスタ、計測器、他(5)IP コア、マクロ、セルライブラリ(6)組込みプロセッサ開発環境
リコンフィギャラブルプロセッサ、ICE、デバッガ、マイコン CASE、コンパイラ/クロスコンパイラ、
シミュレータ、ハード/ソフト協調設計環境、他(7) 設計サービス関連（LSI/PCB）
デザインセンタ、設計サービス、設計コンサルティング、試作・製造、IP 流通サービス、他(8)設計インフラ（WS/PC、ネットワーク）(9)設計データ管理ツール
設計データ管理ツール、他(10)マスクメーカ、ファウンダリメーカ(11)大学（研究室）、コンソーシアム(12)PR 関連
出版物、他- 41 -

3.1.3 開会式
1 月 22 日(木)午前 9 時 40 分より展示会場入口において開会式を執り行った。開会式への登壇者は次のとおりである。
・ご祝辞･テープカット:
経済産業省商務情報政策局情報通信機器課長 住田孝之様
アメリカ合衆国大使館上席商務官 マーク・ワイルドマン様
横浜市経済観光局長 塚原良一様
・主催者挨拶/テープカット:
社団法人 電子情報技術産業協会 半導体部会 部会長 岡田 晴基
社団法人 電子情報技術産業協会 専務理事 半田力・
開会式終了後、登壇者および関係者による会場一巡が行われ、本年は下記のブースを訪問し、新技術･研究開発等の成果の説明をおこなった。
（株）半導体理工学研究センター(STARC)、日本ケイデンス・デザイン・システムズ社、新興ベンダエ
リア、(株)図研、ユニバーシティ・プラザ（以上、見学順）- 42 -

3.1.4 出展者一覧
Jasper Design Automation

アーム(株)(株)アイヴィス

サイバネットシステム(株)アットデザインリンクス(株)サン・マイクロシステムズ(株)Accelicon Technologies Inc.

シーケンスデザイン(株)アトレンタ(株)情報処理装置等電波障害自主規制協議会(株)ｱﾉｰﾊﾞ・ｿﾘｭ-ｼｮﾝｽﾞ /ｴｰﾄｯﾌﾟﾃｯｸ(株)(株)シルバコ・ジャパン

アパッチデザインソリューションズ(株)(株)図研(株)アプリスター
アルデック・ジャパン(株)NEC システムテクノロジー(株)(株)スピナカー・システムズ

E2 パブリッシング(株)ベリフィック・デザイン・オートメーション

伊藤忠テクノソリューションズ(株)シリコン・デザイン・ソリューションズ

日本ヒューレット・パッカード(株)スプリングソフト(株)（旧社名; ノバフロー(株)）ネットアップ(株)スペイシャル日本アイ・ビー・エム(株)タナーリサーチジャパン(株)シーティーシー・エスピー(株)ChipVision Design Systems

フォーステン・ネットワークス(株)DSM ソリューションズ(株)(株)アノーバ・ソリューションズ

Prolifi c,Inc.

マクニカネットワークス(株)DeFacTo Technologies SA

アジリティ・ジャパン(株)イノテック(株)DCG システムズ(株)デナリソフトウエア(株)Arteris Inc.

(株)電波新聞社

eASIC Corporation

日経 BP 社

Jazz Semiconductor

日本イヴ(株)

Novelics LLC

日本ケイデンス･デザイン･システムズ社

Rapid Bridge LLC
Target Compiler Technologies N.V.
ATE サービス(株)Sigrity, Inc.

イノテック(株)日本シノプシス（株）
日本ヒューレット・パッカード(株)(株)ノア(株)エッチ･ディー･ラボ

LogicVision, Inc.

エポック・マイクロエレクトロニクス

Nascentric，Inc.

(株)沖ネットワークエルエスアイ

Javelin Design Automation

カーボン・デザイン・システムズ・ジャパン(株)Berkeley Design Automation, Inc.

兼松エレクトロニクス(株)パルシックジャパンリミテッド

カリプト・デザイン・システムズ(株)(株)半導体理工学研究センター(STARC)

コーウェア(株)日立情報通信エンジニアリング(株)コ・フルエント デザイン

フォルテ・デザイン・システムズ(株)(株)コスモス・コーポレイション(財)福岡県産業・科学技術振興財団

CyberTec(株)マグマ・デザイン・オートメーション(株)- 43 -

三菱電機エンジニアリング(株)Analog Rails

MunEDA GmbHALTOS DESIGN AUTOMATION

メンター・グラフィックス・ジャパン(株)Incentia Design Systems, Inc.

(株)モーデック

EDXACT SA

リード・ビジネス・インフォメーション(株)nSys Design Systems Pvt Ltd

OneSpin Solutions Japan K.K.

ENTASYS DESIGN, INC.

電磁界解析・SI/PI テクノロジ・ゾーン

ENVIS CORPORATION

アジレント・テクノロジー(株)CONCEPT ENGINEERING GMBH

アンソフト･ジャパン(株)Certicom(株)エーイーティー

Sidense Corp.

日本ケイデンス･デザイン･システムズ社

CLK DESIGN AUTOMATION, INC.

PHYSWARE INC

シリコン・フロントライン・テクノロジー (株)HELIC, Inc.

シンテスト・ジャパン

FPGA ﾋﾞﾚｯｼﾞ/特定非営利活動法人 FPGA ｺﾝｿｰｼｱﾑ

SYNFORA(株)アルティマ

Z Circuit Automation

特定非営利活動法人 FPGA コンソーシアム

SOLIDO DESIGN AUTOMATION

匠ソリューションズ(株)DUOLOG TECHNOLOGIES

立野電脳(株)

Dorado Design Automation, Inc.

東京エレクトロン デバイス(株)Nangate(株)トーメンエレクトロニクス

Pextra Corporation

特殊電子回路(株)POLYTEDA Software Corporation(有) ヒューマンデータ

Micrologic Design Automation Inc.

富士エレクトロニクス(株)メガシス(株)

プロトタイピング・ジャパン(株)Rapid Bridge LLC

三菱電機マイコン機器ソフトウエア(株)リアルインテント社

菱洋エレクトロ(株)

JEVeC ビレッジ

インドパビリオン(株)アストロン

泉ネットワーク(有)(株)礎デザインオートメーション

Wipro Limited

エイシップ・ソリューションズ(株)Kitatec KK.

ギガヘルツテクノロジー(株)コスミック・サーキット

ケイレックス・テクノロジー(株)Zensar technologies Ltd. & Zensar Advanced(株)ジーダット

technologies Co.

(株)ジェム・デザイン・テクノロジーズ

ナレッジアイティ(株)(株)システム・ジェイディー

ﾊﾟﾄｩﾆ・ｺﾝﾋﾟｭｰﾀｰ・ｼｽﾃﾑｽﾞ・ﾘﾐﾃｯﾄﾞ(株)数理システム

IC サービス（株）

TOOL(株)
日本 EDA ベンチャー連絡会(JEVeC)

新興ベンダエリア
50 音順
44（※一字下げは共同出展）

3.1.5 出展傾向
EDSFair2009 は、出展者数が 143 社となった。
出展者数

小間数

2009 年

143 社

317 小間2008 年

169 社

339 小間2007 年

154 社

348 小間

2006 年

148 社

343 小間2005 年

119 社

336 小間2004 年

104 社

306 小間2003 年

99 社

320 小間2009 年2008 年

社数

小間数

社数

小間数

通常出展

107 社

278 小間

115 社

294 小間新興ベンダ（ブース）出展）

36 社

39 小間

54 社

45 小間

厳しい環境の中で、出展者数・小間数ともに大変厳しい数字となったが、新規出展者数は 35 社と昨年の 29 社を上回った。また、今年の大きな特徴として、申込後のキャンセルが続いた。最終的に 7 社 10 小
間がキャンセルとなった。
3.1.6 出展者セミナー
1 セッション 45 分間で、30～100 名の適正人数のお客様に向けて集中 PR が行える出展者セミナールー
ムを提供した。2009 年は 10 会場にて 104 セッションを開催した。
聴講者数：2,070 名
3.1.7 キーノートスピーチ－より速く、より大きく、日本の創造的半導体技術－
首都大学東京
西澤

学長

潤一

(1) 日

時: 1 月 22 日（木）10:30～11:30(2) 場

所:アネックスホール(3) 聴講料:無料(4) 聴講者数：300 名

45

3.1.8 第 16 回 FPGA/PLD Design Conference(1) 日

時：1 月 22 日（木）・23 日（金）(2) 場

所：アネックスホール(3) 聴講料：事前申込：10,500 円（1 日券）※消費税込
当日申込：12,600 円（1 日券）※消費税込
聴講者数：
セッション 1

53 名

セッション 537 名

セッション 255 名

セッション 635 名

セッション 356 名

セッション 738 名

セッション 446 名

セッション 829 名

EDSFair と併設の第 16 回 FPGA/PLD Design Conference が 1 月 22 日（木）と 23 日（金）の両日、アネックスホールにて開催され、全 8 セッションで合計 349 名の聴講者を集めた。
1 月 22 日(木)セッション 1（10:00～11:20）
CPLD/FPGA の基礎と活用方法
大木 真一氏[(株)武蔵野電波 / 東海大学 専門職大学院]
セッション 2 （11:35～12:55）
FPGA 回路設計初心者のための開発トラブルシューティング
豊岡 治宏 氏[三菱電機マイコン機器ソフトウエア(株) 第 3 事業部 開拓部 開拓第 1 課主査]
セッション 3（14：05～15：25）
FPGA に搭載された専用機能を有効活用する～RAM/MAC/PLL/DCM/SerialIO～
井倉 将実 氏[来栖川電工(有) 応用技術部 技術取締役]
セッション 4 （15:40～17:00）
FPGA に CPU を搭載し、オリジナル SoC を実現する～ FPGA を中心とした組み込みシステムの開発
実吉 智裕 氏[株式会社アットマークテクノ 代表取締役]46～

1 月 23 日(金)セッション 5（10:00～11:20）
FPGA 高速 I/O を設計力で使いこなす ～DDR メモリ I/F, LVDS, PCI-Express の設計ポイント～
櫻井 剛 氏[三精システム株式会社 第 1 設計部 部長補佐]
セッション 6（11:35～12:55）
安心できる、高速 IO 系の基板設計初歩の初歩
金子 俊之 氏[株式会社トッパン NEC サーキットソリューションズ 技術開発本部 設計部 スーパーバイザー]
セッション 7（14:05～15:25）
System Verilog による FPGA 設計
岩本 正美 氏[匠ソリューションズ株式会社 代表取締役社長]
セッション 8（15:40～17:00）
プログラマブル・システム LSI 時代の到来 - 続々登場のミックスド・シグナル LSI の技術動向
三上 廉司 氏
[日本サイプレス(株) マーケティング・マネジャー]47

3.1.9 特別ゾーン
新企画：電磁界解析・SI/PI テクノロジ・ゾーン
いまや全ての設計者にとって必須の知識となった SI/PI/EMC 対策をテーマに取り上げた、「ここまでできる！最新電磁界シミュレーション技術と SI/PI/EMC 対策」テクノロジ・ゾーンは、基板上の信号劣化要因に対するソリューションを提供する電磁界解析ツール・ベンダおよびその関連企業が一同に集まりこの問題の解決策を展示、紹介した。
出展者：
アジレント・テクノロジー(株)日本ケイデンス･デザイン･システムズ社

アンソフト･ジャパン(株)PHYSWARE INC(株)エーイーティー

Helic, Inc.

また、ゾーンに併設されたミニ・ステージにおいてシステム機器ユーザが SI/PI/EMC の課題に対する取組みをプレゼンテーション形式で紹介した。
◆1 月 22 日（木）12:00～12:20(19 名)、15:00～15:20(28 名)

プレゼンター：パナソニックエレクトロニックデバイス株式会社
顧問

越智

敏

◆1 月 23 日（金）氏
13:00～13:20(44 名)、15:10～15:30(42 名)

プレゼンター：ソニー（株）モノ造り本部
担当部長

デバイスアプリケーションセンター

村山 敏夫

モノ造り技術部門

技術開発室

氏

下記ゾーン参加者による、自社ソリューションを紹介するプレゼンテーションも両日行なわれた。
(22 日


5回

合計 62 名、23 日

7回

合計 121 名)

高速ディジタル信号の解析に最適な MW STUDIO による時間領域シミュレーション（株）エーイーティーAllegro にタイトに統合された、EMS 2D フルウェーブ・フィールドソルバ
日本ケイデンス･デザイン･システムズ社



シミュレーションで設計期間短縮 アンソフトの SI、PI、EMI ソリューション
アンソフト･ジャパン（株）

High Speed, high capacity, true-parallel, 3D full-wave solution for chip-package-board SI, PI
and EMI
パラレル処理と独自のアルゴリズムにより、フル・ウエーブ 3D フィールド・ソルバを実現した
Physware のシグナルおよびパワー・インテグリティと電磁界解析のソフト
PHYSWARE INC



An inductance aware RFIC design flow
VeloceRF によるプロセス設計キット(PDK)に統合したスパイラル・インダクタ自動生成及び伝送路やインダクタ間で起きる相互インダクタンス解析ソリューション
Helic, Inc.

48

新企画：FPGA ビレッジ
出展者を集めた、FPGA ゾーンを設置した。
また、FPGA/PLD Design Conference 実行委員会の協力のもと、特設ステージにおいてエグゼクティブ
セッションも開催した。
1 月 22 日（木）：15:45～17:15 『FPGA/PLD の未来と課題を探る』～ユーザの視点から FPGA/PLD の未来予測～
出展者：(株)アルティマ

特殊電子回路(株)特定非営利活動法人 FPGA コンソーシアム(有)ヒューマンデータ

匠ソリューションズ(株)富士エレクトロニクス(株)立野電脳(株)

プロトタイピングジャパン(株)東京エレクトロンデバイス(株)三菱電機マイコン機器ソフトウエア(株)(株)トーメンエレクトロニクス

菱洋エレクトロ(株)新企画：インドパビリオン
近年、日本への進出が目覚ましい、インドの半導体設計技術に関連する企業が集結した、パビリオンを設置した。効率よくインド企業の最新情報、技術の見学が可能となった。
出展者：
Izumi Network Yugen Kaisha

Zensar technologies Ltd. & Zensar Advanced

Wipro Limited

technologies Co.

Kitatec KK.

ナレッジアイティ(株)コスミック・サーキット

Patni Computer Systems Ltd

49

新興ベンダエリア
国内外新興企業 25 社の最新ソリューションが集まり、設計開発者向けに最新情報を紹介した。
出展者：
IC サービス(株)SYNFORA

Analog Rails

Dorado Design Automation, Inc.

ALTOS DESIGN AUTOMATION

nSys Design Systems Pvt Ltd

Incentia Design Systems, Inc.

NangateEDXACT SA

Pextra Corporation

ENTASYS DESIGN, INC.

POLYTEDA Software Corporation

CONCEPT ENGINEERING GMBH

Micrologic Design Automation Inc.

Sidense Corp.

メガシス(株)Certicom

Rapid Bridge LLC

CLK DESIGN AUTOMATION, INC.

Real Intent, Inc.

Silicon Frontline Technology, Inc.
シンテスト・ジャパン
DUOLOG TECHNOLOGIESZ Circuit Automation
SOLIDO DESIGN AUTOMATIONJEVeC ビレッジ
日本の EDA の発展を目指して設立された「日本 EDA ベンチャー連絡会（JEVeC）」との協力による特別企画。EDA 開発に携わる国内のベンチャー企業が一同に集結し、日本企業ならではの「ものづくり力」
を活かした技術や製品をアピールした。
出展者：(株)アストロン(株)ジェム・デザイン・テクノロジーズ(株)礎デザインオートメーション(株)システム・ジェイディー

エイシップ・ソリューションズ(株)(株)数理システム

ギガヘルツテクノロジー(株)TOOL(株)

ケイレックス・テクノロジー(株)日本 EDA ベンチャー連絡会(JEVeC)(株)ジーダット

ユニバーシティ・プラザ
産学の交流を促進すると共に、大学研究機関による研究成果を発表する場とする企画である。設計技術に関する研究成果を発表実演した。
50

22 大学研究室
 VLSI における新しい故障モデルに基づく故障検査法の開発
愛媛大学 大学院理工学研究科 電子情報工学専攻 情報システム工学講座研究室
 ユビキタス･センサネットワーク向き低消費電力プロセッサ大阪大学 大学院情報科学研究科 情報システム工学専攻 集積システム設計学講座 今井研究室
 ディペンダブル再構成可能アーキテクチャとばらつき考慮設計技術
大阪大学 大学院情報科学研究科 情報システム工学専攻 尾上・橋本研究室
 パターンマッチング回路の合成と応用について
九州工業大学 情報工学研究院 電子情報工学研究系 笹尾研究室
 LSI 低消費電力テスト技術
九州工業大学 情報工学府 梶原・温研究室
 アナログ LSI 回路設計自動化環境の構築
九州工業大学 マイクロ化総合技術センター 中村研究室
 高性能・低電力システム LSI アーキテクチャとその電力削減手法
九州大学 システム LSI 研究センター
 耐ソフトエラー設計支援ツールの開発
九州大学 大学院システム情報科学研究院 情報工学部門 安浦・松永・吉村研究室
九州大学 システム LSI 研究センター
豊橋技術科学大学 工学部 情報工学系 組込みシステム研究室
 次世代リコンフィギャラブルロジックとその設計支援技術
熊本大学 工学部 情報電気電子工学科/大学院自然科学研究科 情報電気電子工学専攻 末吉研究室
 インテリジェント・ユビキタスセンサーLSI 技術神戸大学 工学研究科 情報知能学専攻 プロセッサ・アーキテクチャ研究室
 高シグナルインテグリティ信号波形整形技術
筑波大学 システム情報工学研究科 コンピュータサイエンス専攻 安永研究室(集積システム研究室)
 動的再構成可能 LSI を活用したシステム構築および技術応用
筑波大学 大学院システム情報工学研究科 コンピュータサイエンス専攻
高度 IT 人材育成のための実践的ソフトウェア開発専修プログラム
 LSI 設計のための開発環境
東海大学 専門職大学院 組込み技術研究科 清水尚彦研究室
 キテレツ・アイディア・コンペ
東京工業高等専門学校
 VDEC の活動紹介
東京大学 大規模集積システム設計教育研究センター
 システムレベル設計記述の検証・デバッグ支援技術
東京大学 工学部電気電子工学科 藤田研究室
 組込み RTOS 向けアプリケーションの開発支援に関する研究報告 ～実行時ログの見える化～名古屋大学 大学院情報科学研究科 情報システム学専攻 高田・冨山研究室
 ディジットシリアル演算を用いた再構成型プロセッサと科学技術用エンジンの紹介
広島市立大学 大学院情報科学研究科 情報工学専攻 コンピュータアーキテクチャ研究室
 FPGA を用いたハイパフォーマンスコンピューティング
広島市立大学 大学院情報科学研究科 情報工学専攻 論理回路システム研究室
 ダイナミック・アーキテクチャ型細粒度並列処理
広島市立大学 情報科学部 情報工学専攻 高橋隆一研究室
 多層プリント配線基板設計支援システム MULTI-PRIDE
広島大学 大学院工学研究科 情報工学専攻 アルゴリズム論研究室
 FPGA を用いたシステム実現 --- エステティック・フィルタ, PLC, 高信頼性回路の実現 --明治大学 理工学部 情報科学科 理工学研究科 基礎理工学専攻 情報科学系 井口研究室
51

新興ベンダプレゼンテーション
会場内に設置の特設ステージでは、国内外新興企業が、次々とプレゼンテーションを行った。
◆1 月 22 日
12：00～12：20
Ultra-fast Characterization andvalidation.
(206)Altos Design Automation,Inc.
Mr.Jim McCanny CEO

15：10～15：40
Functional ECO & MMMC Timing ECO(120)Dorado Design Automation, Inc.
Mr.J.J. Hsiao,Executive VP

library

PICO EXTREME-THE MOIST ADVANCEDALGORITHM SYNTHESIS(112)SYNFORA
Mr.Atsushi Uria,
Director of TechnicalSupportCDC Venfication(118)REAL INTENT, INC.
Mr.Naoto Kimura, Director, FAE JapanDUOLOG's Chip Integration Platform(108)DUOLOG TECHNOLOGIESMr.Brian Clinton, Product Manager◆1 月 23 日
12：00～12：20
システム設計者のためのノイズ対策の勘どころ(410)ギガヘルツテクノロジー株式会社
河村 隆二 氏, 代表取締役

13：10～13：30
Micrologic Design Automation(212)Micrologic Design Automation
Mr.Danny Rittman PHD, CTO

ケイレックスがご提供する EDA サービスのご紹介(412)ケイレックス・テクノロジー株式会社
今井 広明 氏, 営業部長

Parasitics Analysis and Management(109)EDXACT SA
Mr.Daniel Borgraeve, VP Sales
13：30～13：50
Automated Standard Cell Library Creation
and Optimization(210)Nangate
Mr.Yutaka Kumagai,
Partner
Cubic
Micro(Nangate
Representative)

12：20～12：40
STILAccess(TM)によるテストコスト削減事例(413)株式会社システム・ジェイディー
伊達 博 氏, 代表取締役
SiP Feasibility Study, Before CAD.
(411)Gem Design Technologies, Inc.
Mr.Hiroshi Murata, President
Anti-Counterfeiting: SOC Digital Content
Protection and Management(113)Certicom
Mr.Craig Rawlings,
Senior Director Product Management

15：50～16：１0
情報共有化基盤(インテリジェント Hub)機能付
き SaaS サービス
(019)The Knowledge IT 株式会社
へアント セティア 氏, 代表取締役

15：30～15：50
Translation Service from India(018)Izumi Network Yugen Kaisha
Mr.Hiroyuki Kanae

Process
Variation
Solutions
Transistor-Level Designers(116)SOLIDO DESIGN AUTOMATION
Mr.Johnson Lau, Senior Director

India IT Club(020)Kitatec K.K.
Mr.Harsh Obrai
52for3.1.10 ガイド・ツアー
日本の設計技術・EDA 技術の第一人者が、ツアー・ガイドとしてブースへ同行訪問し、各社の技術紹介・質疑応答を日本語でサポートする「ガイド・ツアー」を「インド・パビリオン」まで拡大させ実施した。
□新興ベンダ・ツアー参加企業：１９社
内訳：米国企業：9 社、カナダ企業：3 社、独企業：1 社、アイルランド企業：１社
インド企業：１社、韓国企業：１社、仏企業：１社、デンマーク：1 社、台湾企業：１社
実施回数：１月 22 日 2 回、１月 23 日 2 回
ツアー参加人数：各ツアーとも 5－20 名□インドパビリオン・ツアー参加企業：6 社
実施回数:1 月 23 日 1 回
ツアー参加人数:30 名弱
EDSFair2009 では、ツアー方式のブース訪問を企画。ツアー・ガイドが引率して海外新興ベンダのブースを訪問、コミュニケーションのサポートを日本語で行うことにより、来場者が新興ベンダの技術を理解しやすいように支援を行った。
新興ベンダ・ガイド・ツアーでは、二人の設計技術のエキスパートがツアー・ガイドを努めた。1 月 22
日は、米国 D2S, Inc の日本代表の吉田憲司氏、23 日は、東芝のシステム LSI 設計技術部長の樋渡有氏である。二人とも、LSI 設計技術や EDA に精通し、講演経験も豊富なベテランである。また、インドパ
ビリオン・ツアーには、インド電子機器コンピュータソフトウェア輸出振興会（ＥＳＣ）日本代表のジェネシス株式会社代表取締役、西山 征夫 氏であった。
新興ベンダ・ガイド・ツアーおよびインドパビリオン・ツアーは、まず特設ステージにおいて、ツアー・
ガイドによりツアーで訪問するベンダの企業紹介が行われ、各ベンダの代表者もステージ上で紹介した。
ブース訪問に先立って、ベンダがどのような会社か、特徴とする製品や技術は何かを事前に理解してもらった。

企業紹介のスライドも日本語で準備されていたので、参加者にとっては、ブース訪問前にベンダについてある程度の知識を得ることができた。 ステージでの企業紹介が一通り終わると、ガイド・ツアーの旗のもと、ツアー・ガイドを先頭に紹介されたベンダのブースを訪問した。
各ブースでは、最初そのベンダの代表がパネルや、PC を使って製品や技術をさらに紹介。中には、日本語デモや、パンフレットなどの資料を準備していた企業もあり、出展者としてもこのツアーによるブース来場者を期待していた様子が見受けられた。

ツアー・ガイドは、必要に応じてベンダの説明を日本語に訳したり、また Q&A では参加者が聞きたいであろう質問を代わって行ったり、日本語でなされた質問を英語で伝えたり、また、回答を日本語で伝えたりと、ツアー参加者の技術の理解のためのコミュニーケションのサポートを行っていた。
各ツアーは、大まかに設計分野ごとでまとめられ各ツアーとも毎回 10－20 名の参加者があり、盛況であった。

- 53 -

3.1.11 特設ステージ
場

所：展示フロア内特設ステージ

参加無料

展示会場内の特設ステージにて、昨年に続いて、ベンダーエグゼクティブを迎えての「エグゼクティブ
が語る！」3 セッションと「今さら聞けないことがわかる！未来がわかる！」2 セッションを開催し、二日間で計 1049 名の聴講者を集めた。「エグゼクティブが語る！」では LSI 設計と PCB 設計にまたがる技術
課題をとりあげたセッション１、FPGA コンファレンスとの連携による FPGA 関連セッション、そして、
半導体ベンダー2 社のエグゼクティブとメディアのエグゼクティブを迎えて電子産業の将来と EDA 技術をとりあげたセッションを開催した。
「今さら聞けない・・」では「高位合成」と「検証メソドロジ」につき、対話式講義と講演により、それぞれ注目の先端技術につき、基礎から設計適用事例までが紹介された。
今年度は EDSF 実行委員会の他の WG との連携により、特設ステージのセッションテーマと関連した展
示エリアの取り組み（セッション１のテーマと関連したテクノロジーテーマゾーンの設置、セッション２に関連して FPGA パビリオン）も行われ、EDSFair 全体の一体感を示すとともに、来場誘致に貢献できた。
また、特設ステージ企画 WG メンバとして、EDA 技術専門委員会と EDSF 実行委員会の EDA ベンダ委員の参加を頂き、それぞれセッションオーガナイザとして、活動頂いた。
EDSFair2009 来場者アンケートによると、来場者の約 3 分の１は特設ステージを来場目的にあげており、
目的達成度も回答数中 44%と否達成 12％を大きく上回った。自由記入でも、「特設ステージは企画がよく、いろいろな意見を聞くことができた」など積極的評価の記載が 5 件と、他のセミナなどとの時間割の整合と、客席の窮屈度の 2 件の改善要望の記載を上回った。
資料スライドの操作、スクリーンを指示するポインタ、各セッションの時間管理などの運営面の反省点
は、次年度委員に引き継ぎ、改善をお願いする。
以下、各セッション毎に、企画概要（開催案内）と、実施結果として、聴講数と簡単なコメントを記載する。

- 54 -

1 月 22 日（木）■『エグゼクティブが語る！』□13:00～14:30 セッション 1

日英同時通訳付き「ノイズに悩まされない設計の実現に向けて ～ LSI 設計・PCB 設計・EDA ツールで、今すべきこと ～」『LSI を PCB に実装したら想定外の電気的ノイズトラブルが発生した』こんな声をよく聞くようになってきたのは、なぜか? その原因は? どうしたら未然に防げるのか? このステージでは、LSI 設計と PCB 設計にまたがる課題を認識し、解決への道筋を探ります。
Dr. Dian Yang ［Apache Design Solutions, Inc., SVP, Product Management］
Mr. A. J Incorvia ［Cadence Design Systems, Inc., VP, Research and Development］
仮屋和浩

氏 ［（株）図研中村

篤 氏 ［（株）ルネサステクノロジ］

福場義憲

氏 [東芝セミコンダクター社 システム LSI 事業部 カスタム SoC 応用設計技術部]

金子

俊之

氏

【司

会】

小島 郁太郎 氏 ［㈱日経 BP 社］：

技術本部長］［（株）トッパン NEC サーキットソリューションズ【オーガナイザ】
聴講者数

取締役

技術開発本部

設計部］

南 文裕氏 ［東芝マイクロエレクトロニクス㈱］225 名

オーガナイザ、司会者の周到な準備により、特設ステージの開幕にふさわしい、活発なセッションであった。会場からも多数の質問がでた。チップ、パッケージ、PCB の各設計間の協力連携が今後、ますます重要となる。会場からの質問にもあった、設計データの、共通化・標準化あるいは相互乗り入れへの取り組
みの進展を期待したい。
□15:45～17:15 セッション 2

日英同時通訳付き「FPGA/PLD の未来と課題を探る～ユーザの視点から FPGA/PLD の未来予測～」
近年、FPGA/PLD は製品づくりに不可欠なデバイスとして日本市場でも認知されつつあります。そのFPGA/PLD に今後どのような成長を求め期待するのか、ユーザの視点から技術面、経済面として将来の製品に求められるソリューションを提起します。そして、それに対して、デバイスベンダー、EDA ベンダー
とともに、FPGA/PLD のあるべき姿を探りながら課題を議論し、日本市場における FPGA/PLD の未来を予測します。
Mr. Danny Biran ［Altera Corporation, SVP, Product & Corporate Marketing］
小島洋一

氏 ［ザイリンクス（株）, フィールドアプリケーションエンジニアリング本部

本部長］

Mr. Gary Meyers ［Synopsys, Inc., VP & GM, Synplicity Business Group］
Mr. Simon Bloch ［Mentor Graphics Corp., VP & GM, Design and Synthesis Division］
山本

靖 氏 ［山本靖

松本

仁 氏 ［三菱電機（株）コミュニケーション製作所

【司

会】

弘中

【オーガナイザ】
聴講者数

：

＆

アソシエーツ］

哲夫 教授 ［広島市立大学
松本大学院

光技術 G ］
情報科学研究科 ］

仁 氏 ［三菱電機（株）コミュニケーション製作所 ］

140 名

5 つの特設ステージセッション中では唯一聴講数が 100 人台だったのは残念だったが、ここ数年 EDSF への展示がない 2 大 FPGA ベンダのエグゼクティブと、関連 EDA ベンダーエグゼクティブの参加のもと、- 55 -

国内 FPGA ユーザ代表とのパネル討論は FPGA/PLD の未来と課題を探るよい機会となった。
1 月 23 日（金）■『エグゼクティブが語る！』□10:30～11:30 セッション 3「電子産業の成長シナリオと EDA 業界の役割」
日本の電子産業の将来像を、「携帯電話・情報家電・パソコンなどの既存製品の将来性」「環境やエネルギ
ー問題へ向けた新製品・ビジネスモデルの創出」「MEMS など次世代技術の将来性」といった視点から語りあって頂きます。日々、難しい技術課題にとりくまれるエンジニア、管理職の方にも参考になる話が山盛りです。
氏 ［日経 BP 社

望月

洋介

野口

達夫 氏 ［東芝セミコンダクター社

福間雅夫 氏 ［NEC エレクトロニクス（株）執行役員］

【司

会】 高野

一郎 氏

【オーガナイザ】 荒木
聴講者数：

電子・企画局

局長補佐］

技師長］

［㈱テクノアソシエーツ 代表取締役社長］

大 氏［㈱インターデザイン・テクノロジー］

218 名

設計や EDA の個々の技術ではなく、半導体ビジネスの視点から技術を語るセッションを、半導体ベンダエ
グゼクティブ（2 名）の参加を得て開催したのは、今回、初めての取り組みである。世界不況の中、半導体業界も非常に厳しい状況にあるが、このような場での業界および、関連業界関係者への発信はぜひ今後も続けてほしいものである。
■『今さら聞けないことがわかる！未来がわかる！』□ 14:00～15:00 セッション 4「今さら聞けない高位合成～一から学ぶ高位合成～」

最近高位合成を用いた設計事例の紹介が聞かれるようになったけど、本当はどうなの？どこまでできるの？
ここでは、高位合成を改めて理解するために、高位合成の仕組み、特長、適用範囲を設計事例も含め対話形式でレクチャー。生徒と先生の学習シリーズ第３弾で高位合成をわかりやすくお伝え致します。
山田晃久 氏 ［シャープ㈱電子デバイス事業本部］【聞き手】

銭 岩 氏 ［シャープ㈱電子デバイス事業本部］

【司

西本

会】

【オーガナイザ】
聴講者数：

猛史 氏 ［シャープ㈱電子デバイス事業本部］
西本猛史 氏 ［シャープ㈱電子デバイス事業本部］

263 名

5 セッション中、聴講数が最大で、高位合成に対する関心の高さが伺えた。高位合成の基本的な技術と、設計からみた動作レベル設計と RTL 設計の違いなどの説明から、実際の LSI 設計への適用事例まで、高位合成のエキスパートである講師の説明と、生徒役の若手エンジニアからの質問でわかりやすく紹介された。

- 56 -

□16:15～17:15 セッション 5「検証メソドロジ入門から超並列計算機向けインターコネクトへの適用事例まで～仏作って魂を入れる検証～」
SystemVerilog を用いた検証メソドロジが整備されたことで、検証の枠組みを容易かつ堅牢に構築することが可能になりました。しかしこれで検証の問題は解消されたのでしょうか？違います！これはまだ仏を作った段階。この中に込める「魂」ともいうべき検証項目や検証シナリオと結びついてはじめて、品質と生産性が両立した検証が可能となります。本講演では、仏としてのクラスベースの検証環境構築手法と、魂としての仕様書起点の検証手法を紹介し、検証のための組織の在り方も含めて大規模 LSI への適用事例までをご紹介します。
松岡

正 氏 ［（株）ベリフォア

高山

浩一郎

【司

会】 三橋

氏［富士通（株）次世代テクニカルコンピューティング開発本部
明城男 氏 ［（株）メンター・グラフィックス・ジャパン【オーガナイザ】
聴講者数：

代表取締役］

三橋

LSI 開発統括部］

テクニカルセールス部］

明城男 氏 ［（株）メンター・グラフィックス・ジャパン］

233 名

検証メソドロジとは何か？、導入のメリットは？から、超並列計算機向けインターコネクトへの適用事例までを「仏」と「魂」をキーワードに、必要なスキルや組織のありようも含め紹介された。
「ぜひ検証メソ
ドロジに飛び込んでほしい」との講師の呼びかけが、導入をためらっていた会社（部署）への、後押しになることを期待したい。

JEITA EDA 技術専門委員会 企画 WG
主査

ソニー(株)

齋藤

委

員

(株)東芝

南

委

員

三菱電機(株)松本

委員(株)インターデザイン・テクノロジー

荒木 大

委

員

シャープ(株)

西本

猛史

委

員

メンター・グラフィックス・ジャパン(株)

三橋

明城男

委

員

セイコーエプソン(株)

熊谷

敬

委

員

セイコーエプソン(株)

藤原

安英

委

員

富士通マイクロエレクトロニクス(株)

河村

薫

委

員

三洋電機(株)山田節- 57 -

茂美
文裕
仁3.1.12 来場者数詳細
2009 年来場者数
1 月 22 日(木）

晴れ

3,953

1 月 23 日(金)

晴れ

5,164

合

9,117

計

過去の来場者数
開催年

１日目

２日目

合

計

2008 年

4,604

5,827

10,431 名

2007 年

4,956 名6,180 名

11,136 名

2006 年

5,006 名5,997 名11,003 名

2005 年

5,066 名6,087 名

11,153 名

2004 年

4,764 名

6,023 名10,787 名- 58 -

3.1.13 全来場者入場登録票アンケート回答 集計結果
入場登録票アンケートによる来場者プロファイルを以下に示す。

- 59 -

- 60 -

- 61 -

- 62 -

3.1.14 出展社アンケート回答 集計結果
出展社アンケートの回答結果を示す。
出展社 143 社（窓口数 117 社）の内、回答 51 社回答。

Q1-1. 今回の出展にあたっての目的について該当するものをお選びください。（いくつでも）(回答数) 2009年度 2008年度
48名
14.6%
16.4%
製品の販売促進
60名
18.2%
19.6%
新規顧客開拓
20名
6.1%
7.5%
商談の成約、契約
44名
13.4%
15.0%
新製品、新技術のアピール
41名
12.5%
8.9%
取引のある顧客との関係強化
39名
11.9%
11.7%
来場者からの反応・意見等の収集
44名
13.4%
14.5%
企業としての総合的なPR
19名
5.8%
4.7%
競合他社に対し優位性を示す
14名
4.3%
1.9%
社員の意識向上、社内活性化
329名
100.0%
100.0%
合計

Q1-2. なかでも今回の出展にあたってもっとも重視した目的一箇所をお選びください。
(回答数) 2009年度 2008年度
企業として
の総合的な
12名
18.8%
17.6%
製品の販売促進
PR
24名
37.5%
49.0%
新規顧客開拓
来場者から
1名
1.6%
2.0%
商談の成約、契約
の反応・意
7名
10.9%
9.8%
新製品、新技術のアピール
見等の収集
6名
9.4%
2.0%
取引のある顧客との関係強化
2名
3.1%
3.9%
来場者からの反応・意見等の収集
取引のある
12名
18.8%
15.7%
企業としての総合的なPR
顧客との関
0名
0.0%
0.0%
競合他社に対し優位性を示す
係強化
0名
0.0%
0.0%
社員の意識向上、社内活性化
新製品、新
64名
100.0%
100.0%
合計
技術のア
ピール

Ｑ1-1で「製品の販売促進」を目的とされていた場合、当項目の評価をお聞かせください。
(回答数) 2009年度 2008年度
期待通り
7名
10.9%
7.8%
無回答
やや期待を下回る
8名
12.5%
7.8%
どちらともいえない
15名
23.4%
29.4%
やや期待はずれ
10名
15.6%
11.8%
期待はずれ
6名
9.4%
2.0%
期待はず
無回答
18名
28.1%
41.2%
れ
合計
64名
100.0%
100.0%
やや期待
加重平均値
-1.6%
1.8%
はずれ

- 63 -

社員の意識
向上、社内
活性化

競合他社に
対し優位性
を示す

製品の販売
促進

新規顧客開
拓

商談の成
約、契約

期待通り
やや期待
を下回る

どちらと
もいえな
い

Ｑ2. 出展にあたってターゲットとした来場者の業種について該当するものをお選びください。（いくつでも）【機器メーカ・部門】コンピュータ関連機器(今回回答数) 2008年度年度（参考）
7.2%
6.9%
24名
24名

7.2%

6.9%

【機器メーカ・部門】一般民生機器

25名

7.5%

8.2%

【機器メーカ・部門】画像処理機器

29名

8.7%

8.8%

【機器メーカ・部門】医療機器

14名

4.2%

3.5%

【機器メーカ・部門】アミューズメント

14名

4.2%

4.1%

【機器メーカ・部門】自動車・輸送機器

18名

5.4%

6.0%

【機器メーカ・部門】産業機器（機械・精密機器等

18名

5.4%

6.0%

【機器メーカ・部門】通信機器

26名

7.8%

7.9%

【機器メーカ・部門】放送機器

15名

4.5%

4.4%

【機器メーカ・部門】その他

8名

2.4%

2.8%

【半導体・電子部品メーカ部門】システムLSI、A

40名

12.0%

12.9%

【半導体・電子部品メーカ部門】FPGA/PLD

18名

5.4%

5.0%

【半導体・電子部品メーカ部門】ディスプレイ

17名

5.1%

4.4%

【半導体・電子部品メーカ部門】電子コンポーネ

17名

5.1%

4.1%

【半導体・電子部品メーカ部門】プリント基板【半導体・電子部品メーカ部門】その他

18名
9名

5.4%

4.4%

2.7%

3.7%

合計

334名

100.0%

100.0%【機器メーカ・部門】ネットワーク関連機器

なかでも出展にあたって最も重視したターゲット一箇所をお選びください。
【機器メーカ・部門】コンピュータ関連機器(今回回答数) 2008年度年度（参考）
0.0%
2.0%
0名

【機器メーカ・部門】ネットワーク関連機器

1名

2.0%

2.0%

【機器メーカ・部門】一般民生機器

6名

11.8%

12.0%

【機器メーカ・部門】画像処理機器

6名

11.8%

6.0%

【機器メーカ・部門】医療機器

0名

0.0%

0.0%

【機器メーカ・部門】アミューズメント

0名

0.0%

0.0%

0名

0.0%

2.0%

1名

2.0%

0.0%

1名

2.0%

4.0%

0名

0.0%

0.0%

【機器メーカ・部門】自動車・輸送機器【機器メーカ・部門】産業機器（機械・精密機器等【機器メーカ・部門】通信機器【機器メーカ・部門】放送機器【機器メーカ・部門】その他

1名

2.0%

0.0%

【半導体・電子部品メーカ部門】システムLSI、A

22名

43.1%

50.0%

【半導体・電子部品メーカ部門】FPGA/PLD

3名

5.9%

8.0%

【半導体・電子部品メーカ部門】ディスプレイ

0名

0.0%

4.0%

【半導体・電子部品メーカ部門】電子コンポーネ

0名

0.0%

2.0%

【半導体・電子部品メーカ部門】プリント基板

4名

7.8%

2.0%

【半導体・電子部品メーカ部門】その他
無回答

1名
5名

2.0%

0.0%

9.8%

6.0%

合計

51名

100.0%

100.0%- 64 -

3.1.15 まとめ
EDSFair2009 の過去にない特徴は、年度の開始時点と EDSFair 開催時点で、世の中の情勢が全く異なるものとなっていたことである。実行委員会を立ち上げ、年度の方針や計画を決定した春の時点では、
EDSFair2008 を上回る出展者数、来場者数を期待していたが、第三四半期頃から顕在化した不況の嵐は、
まさに Fair 開催のころには最悪の状況となっていった。大手企業は軒並み大幅な赤字予想を発表し、電気各社も出張を含めた極めて厳しい予算措置をとっている最中での開催となった。EDSFair2009 も２０％以上の出展者数、来場者数減少を覚悟し、一旦決定していた予算も大幅にカットした。
このような状況の中で、出展者数で１５％、来場者数で１３％の減少で抑えられたのは、まさに関係者の努力によるところが大きいと言える。Tech ON!においても、「EDSF，参加者数 13％減で踏ん張る」という形で記事となった。
出展者から見た今年の目玉は、テクノロジーテーマゾーン、インドパビリオン、FPGA ビレッジの３つの新企画であった。いずれの企画も多数の来場者を集め、アンケートにおいても高い評価を得ており、
EDSF でしか得られない情報の発信という当初の目的を十分に達成できた。
来場者の観点では、コンシェルジュサービスや通訳サービスを新規に行った。利用者には満足してもらえたので、次回以降は来場者にさらに周知させることで来場者増につながる企画になると期待したい。
今回は最終的に実現できなかったが、メディア各社がテーマや出展者を独自に集めて特別ゾーンで展示するというメディアゾーン企画は、この不況の嵐さえなければ実現できていたものであった。出展企業の分野拡大の観点からは大変有効であり、来年度以降継続して検討の価値があると思われる。
今回出展者数、来場者数ともに減少ということになったが、これを機として、出展者の間に、現在の延長では来年度の開催が危ないのではないか、新機軸を出さないと自社の出展もできなくなるか、良くても縮小せざるを得ない、結果として出展者、小間数が減った場合には、予算的に開催ができなくなるのではないかという不安と問題意識が一気に広まった。
EDA-TC 幹事会では、元々委員の負荷の軽減という立場から EDSFair 開催方法の見直しを進めていたこともあり、出展者の意見を聞いたうえで、次年度以降の開催方法について早急に方針の決定を行うこととした。

- 65 -

3.2
3.2.1

システム・デザイン・フォーラム 2009
はじめに最新の EDA 技術の標準化推進、業界内での普及･促進活動の一環として、EDA 技術専門委員会主催による“システム・デザイン・フォーラム 2009”を、EDSFair2009 と同期して2009 年 1 月 23 日に開催した。
EDA 技術専門委員会は、今回と同様の目的とするフォーラムを、ほぼ毎年継続して開催してきた。まず、1990 年から 1994 年にかけて EDA 標準化活動の発表とその一般への普及を図ることを目的とした“EDA 標準化フォーラム”を 4 回開催し、つづいて、EDA 技術専
門委員会の活動に係る内容の発表、討論の場を目的として“EDA フォーラム”を 1999 年から 2002 年にかけて 2 回開催してきた。また、2004 年には、最新の設計技術、課題を設計事例とともに紹介する“システム・デザイン・セミナー”を、2005 年には “システム・デザ
イン・フォーラム 2005”を、2 日間の日程で開催した。この“システム・デザイン・フォー
ラム 2005”では、1 日目に SystemVerilog ユーザ・フォーラムと SystemC ユーザ・フォ
ーラムを、2 日目に SoC に関連した設計技術、課題等を含めた設計事例を紹介する 2 セッションと、LSI、パッケージ、基板を含めた統合設計に関するパネル討論のセッションを行っている。2006 年には、“システム・デザイン・フォーラム 2006”として、“SystemVerilog
ユーザ・フォーラム”と“SystemC ユーザ・フォーラム”の 2 セッション構成で、両設計言語の標準化動向の紹介、チュートリアル、設計適用事例の紹介を行った。2007 年は“システ
ム・デザイン・フォーラム 2007”として、“SystemVerilog ユーザ・フォーラム”と“SystemC
ユーザ・フォーラム”の 2 セッションに、65nm 以下のプロセスノードで深刻化するプロセ
スばらつきを打破する最新の設計技術動向を紹介するフィジカル･デザイン･フォーラムを新たに加え、計 2 日間 3 セッションを開催した。去年は、“システム・デザイン・フォーラ
ム 2008”として、“SystemC ユーザ・フォーラム”と“Power Format フォーラム”の 2 セッションを開催した。“SystemC ユーザ・フォーラム”では、最新の SystemC 標準化動向、
TLM2.0 のチュートリアル、JEITA SystemC ワーキング・グループの取り組みの報告と、設計適用事例の紹介を行った。“Power Format フォーラム”では、最新の低消費電力設計技術の紹介と、
個々に Power Format 標準化を目指す二つの団体 Accellera Organization, Inc.、
Si2(Silicon Initiative, Inc.双方からの標準化活動の最新状況や設計適用事例の紹介と、
JEITA Power Format 検討ワーキング・グループの Power Format の標準化に対する検討
状況の報告を行った。
今年は、「SystemC ユーザ・フォーラム 2009」に加えて、新たに、プロセス微細化による製造ばらつきの問題に対して、「最先端統計から見た 32nm ばらつき予測と設計法」をテーマとした、「ナノ世代物理設計フォーラム」を開催した。

- 66 -

SystemC ユーザ・フォーラム 2009 では、OSCI（Open SystemC Initiative）によるSystemC の最新動向の紹介、JEITA SystemC ワーキング・グループによる、システム設計から実装、検証を含む SystemC 推奨設計メソドロジの紹介、半導体理工学研究センター（STARC）による TL モデリングガイドの紹介、SystemC を用いた高位合成適用事例、および TLM2.0 を利用した回路設計事例を報告した。
ナノ世代物理設計フォーラムでは、プロセスの微細化により、新たな設計上の課題としてあらわれてきた製造ばらつきによる設計の収束性および製造時の良品率の低下に対処す
るため、ばらつきの影響を考慮できる統計的な設計手法の現状を報告した。

- 67 -

3.2.2

システム・デザイン・フォーラム 2009 概要• 開催日時1 月 23 日(金)10:00～12:00

SystemC ユーザ・フォーラム 200912:45～16:30

ナノ世代物理設計フォーラム• 開催場所
パシフィコ横浜 アネックスホール• 聴講料（消費税込）
事前申込

当日申込

SystemC ユーザ・フォーラム 2009

2,100 円

2,625 円ナノ世代物理設計フォーラム

3,150 円

4,200 円

• 定員
200 名/セッション• 主 催
社団法人 電子情報技術産業協会 EDA 技術専門委員会• 協 賛
OSCI(Open SystemC Initiative)• 受 付
インターネットで受け付け
http://www.edsfair.com/conference/systemdesign.html• 開催案内プログラム
社団法人電子情報技術産業協会(JEITA)EDA 技術専門委員会では、最新 EDA 技術の普及促進を目的としてシステム・デザイン・フォーラムを 2005 年から開催しております。その中で今年は、「SystemC ユーザ・フォーラム 2009」に加えて、新たに、プロセス微細化による製造ばらつきの問題に対して、「最先端統計から見た 32nm ばらつき予測と設計法」をテーマとした、「ナノ世代物理設計フォーラム」を開催いたします。
SystemC ユーザ・フォーラム 2009 では、OSCI（Open SystemC Initiative）によります SystemC の最新動向の紹介、JEITA SystemC ワーキング・グループによります、シス
テム設計から実装、検証を含む SystemC 推奨設計メソドロジの紹介、半導体理工学研究センター（STARC）によります TL モデリングガイドの紹介、SystemC を用いた高位合成適
用事例、および TLM2.0 を利用した回路設計事例のご紹介をいたします。是非、システム
LSI 設計の最先端状況の把握と、論議の場としてお役立てください。
LSI物理設計・検証においては、半導体デバイス・配線テクノロジの進化に伴い、新たな設計上の課題があらわれてきています。その一つとして、プロセスの微細化に伴う製造ば- 68 -

らつきが顕著化し、設計の収束性および製造時の良品率を低下させています。こうしたばらつきに対処するため、ばらつきの影響を考慮できる統計的な設計手法が注目を集めています。そこで、ナノ世代物理設計フォーラムでは、「デバイス・回路ばらつきの要因と統計的側面」および「Statistical回路設計イノベーション」をサブタイトルとして、国内外から著名な先生方をお招きし、ばらつきを考慮した設計方法の現状を紹介していただきます。
このフォーラムが、次世代以降のLSI物理設計における新たな課題を知る良い機会となり、また論議する良い場になると確信しております。
なお、ナノ世代物理設計フォーラムは、EDA 技術専門委員会活動開始 10 周年記念事業
として、国内外から著名な先生をお招きしており、特別聴講料となっております。奮ってご参加下さい。
z SystemC ユーザ・フォーラム 2009 (1 月 23 日 10:00～12:00)
司会：長谷川 隆 氏（SystemC ワーキング・グループ 主査/富士通マイクロエレクトロニクス）
SystemC は、2005 年 12 月に IEEE 標準仕様として IEEE 1666-2005 が承認された後も、TLM2.0 の LRM 作成、動作合成サブセット策定、アナログ/アナログ－デジタル混在拡張
仕様の検討が進められており、適用領域がさらに広がっています。実設計においても、C 言
語ベースのシステムレベル設計言語の業界標準として、検証、設計分野で幅広く利用されており、今後にも期待が寄せられています。
本セッションでは、1)OSCI による SystemC の最新動向の紹介、2)JEITA SystemC ワー
キング・グループによる、システム設計から実装、検証を含む SystemC 推奨設計メソドロ
ジの紹介、3) STARC による TL モデリングガイドの紹介、4) SystemC を用いた高位合成
適用事例、5) TLM2.0 を利用した回路設計事例の発表を行います。
①

OSCI アップデート
Stan Krolikoski 氏 （OSCI）②

SystemC 推奨設計メソドロジの紹介
SystemC ワーキング・グループ③

STARC TL モデリングガイドの紹介
吉永和弘 氏 （㈱半導体理工学研究センター）④

事例#1：画像処理 IP 開発への高位設計適用事例
浅野哲也 氏 （㈱ルネサステクノロジ）⑤

事例#2：TLM2.0 を利用した大規模回路設計
長谷川裕恭 氏 （㈱エッチ・ディー・ラボ）- 69 -

z ナノ世代物理設計フォーラム (1 月 23 日 12:45～14:30，14:45～16:30)
司会：金本 俊幾 氏
（ナノ世代物理設計ワーキング・グループ主査/ルネサス テクノロジ）
現在量産段階にある 45nm、さらにこの先の 32nm テクノロジノードでは、デバイス特性、回路特性の WID(Within Die)および D2D(Die to Die)ばらつきの増大が、SoC 設計上の深刻な課題となっています。これに対し、さまざまな手法がばらつきに起因する課題を克服する手段として提案されています。
本セッションでは、最先端統計から見た 32nm ばらつき予測と設計法を以下のトピックを通じてお伝えします。
セッション 2A：「デバイス・回路ばらつきの要因と統計的側面」 12:45～14:30①

最先端統計から見た 32nm デバイス特性ばらつき
平本②

俊郎 教授（東京大学 生産技術研究所）

最先端技術におけるデバイスばらつきと統計的回路特性
桜井

貴康 教授（東京大学 生産技術研究所）

セッション 2B：「Statistical 回路設計イノベーション」③

14:45～16:30

Parameter variations and process variation tolerant design of logic and
SRAMsProf. Kaushik Roy（Purdue University）④

Variability immune circuits and statisticalestimation of process

variation towards 32nm era
Prof. Dennis Sylvester（University of Michigan）

3.2.3

開催結果

各セッションのインターネットでの事前聴講登録数、当日申込数、有料の参加者数、及びアンケート回答数は以下であった。
表 1 システム・デザイン・フォーラム 2009 の参加者数
SystemC ユーザ・フォーラム

ナノ世代物理設計フォーラム

事前申込者

118

83

当日申込者

9

12

申込者数合計127

95

参加者数（有料）

123

93

アンケート回答数

113

74- 70 -

今年は、経済状況が厳しい中にも関わらず、SystemCユーザ・フォーラムには100名を越える参加者があり、システムLSI設計の最先端状況の把握に役立ったと思われる。また、ナノ世代物
理設計フォーラムにも100名近い参加者があり、次世代以降のLSI物理設計における新たな課題
を知る良い機会となった。
z 各セッションの状況
各セッションとも熱の入った発表、討論となり盛況であった。
■

SystemC ユーザ・フォーラム 2009
毎年恒例の SystemC ユーザ・フォーラムが、2009 年 1 月 23 日の午前にパシフィコ
横浜にて「EDS Fair 2009」に併設される形で開催された。OSCI、JEITA SystemC WG、及び STARC による報告、SystemC 適用事例 2 件の盛りだくさんの内容であった。また例年通り、100 名を超える入場者があった。

図 1 SystemC ユーザ・フォーラム 2009
最初にワーキング・グループ主査、長谷川 隆 氏(富士通マイクロエレクトロニクス)の開会挨拶から始まり、まず OSCI（Open SystemC Initiative）の役員である Stan
Krolikoski 氏（米 Cadence, Inc.）が、2008 年に OSCI が設立 10 年目を迎え、TLM(Transaction Level Modeling) 2.0 の正式版や AMS(Analog Mixed Signal)のドラ
フト仕様がリリースされた重要な節目の年であった事を報告した。TLM2.0 に関しては、
現在 LRM(Language Reference Manual)を執筆中であり、本年中にリリースされた後に IEEE に移管されて標準化の審議に入るはずだが、その具体的時期については明言- 71 -

されなかったのが残念である。
AMS 標準に関しては、今回リリースしたドラフトに対するフィードバックを募集している事、合成サブセットワーキング・グループからこの四半期中に次のドラフトがリリースされる予定である事、また、新しいワーキング・グループとして、SystemCで記述されたモデルの内部をＥＤＡツールがアクセスする際の標準ＡＰＩを定める
CCI(Configuration, Control, and Inspection)ワーキング・グループが設立された事が紹介された。
続いて、JEITA SystemCワーキング・グループの清水氏(OKIセミコンダクタ)より、
同WGの活動の紹介があった。昨年同WGでは「SystemC推奨設計メソドロジ」の合成編について紹介していたが、本年夏には設計メソドロジ全般を公開予定であり、今回はその概要が紹介された。(http://eda.ics.es.osaka-u.ac.jp/jeita/eda/index-jp.html)
また、先日公開された TLM 2.0 に関する補足説明として、比較的難解なプロトコル拡張について、例を用いてわかりやすく解説された。配布資料には、より詳細な解説書
や TLM 2.0Glossary(用語集)の日本語版も添付されており、OSCI 提供の資料を読む際に役立つものである。質疑応答では、「無視できない拡張」を使用した際のエラーメッ
セージの出方について質問が投げかけられたが、現状では特別なエラーメッセージは出ないため、ログファイルを注意深く見なければいけない点は変らないようだ。
次に、STARC(㈱半導体理工学研究センター)の吉永氏より、TL モデリングの概要とその必要性、そして公開されたばかりの TL モデリングガイドライン第 2 版の紹介があった。この第 2 版では、OSCI の TLM 2.0 に完全準拠しており、これを用いることで設計の容易化や再利用性が高まることが期待される。旧版からの変更点も解説され、スムーズな移行が可能である。TL モデリングガイドは、STARC の WEB から無償ダウンロード可能となっている。また有償で書籍を購入することもできる。
(http://www.starc.jp/tlmg/index-j.html)
後半は、SystemC のユーザー事例が２件講演された。
まず、ルネサステクノロジの浅野哲也氏より、SystemC 記述を用いた高位設計環境の紹介があった。同社における高位設計環境の狙いと構成、そして画像処理 IP 開発への適用事例と得られた結果が示された。SystemC 関連のツールとしては、記述チェッ
カ、シミュレータ、動作合成、等価検証のツールを適用し、いずれも実用レベルであるとのことであった。質疑応答では、動作合成を適用するか否かの判断をどこですべきかの議論になったが、現状では決め手がないようである。

- 72 -

最後を締めくくったのは、エッチ・ディー・ラボの長谷川裕恭氏であり、同社で実際に行われている SystemC を用いた大規模回路設計について紹介された。的確に階層化することにより段階的に詳細化することで動作合成結果と SystemC の混在や既存のRTL 設計との混在シミュレーションが可能であること、また TLM 2.0 によるシステム
シミュレーションも実施していることなどが紹介された。また、設計や検証の負担を軽くするため、インタフェース仕様は一本化すべきであるとの意見も示された。
長谷川 隆 ＝ 富士通マイクロエレクトロニクス株式会社
JEITA SystemC ワーキング・グループ- 73 -

■

ナノ世代物理設計フォーラム
システム・デザイン・フォーラム 2009 のセッションのひとつとして，2009 年 1 月
23 日の午後、パシフィコ横浜においてナノ世代物理設計フォーラムが開催された。
LSI におけるプロセス技術や回路設計技術をリードしてきた講師陣を招聘、100 名近い
入場者があった。

図 2 ナノ世代物理設計フォーラム
最初にナノ世代物理設計ワーキング・グループ主査の、金本 俊幾 氏（ルネサス テクノロジ）から本フォーラム開催の趣旨説明および本ワーキング・グループの活動紹介がありスタートした。
次にプロセス技術の立場から、東京大学生産技術研究所教授の平本俊郎氏が登壇した 。 同 氏 は 、 半 導 体 MIRAI プ ロ ジ ェ ク ト で の 研 究 成 果 で あ る 超 大 規 模
DMA-TEG(Device Matrix Array Test Element Group)の測定結果から、MOS トラン
ジスタの閾値 Vth バラつきが正規分布すること、および PMOS よりも NMOS のばら
つきが大きいことを示した。また、PMOS トランジスタのばらつきは、製造ラインや製造条件によらず、ほぼチャネルの離散不純物バラつきに依存することと、NMOS ト
ランジスタのばらつきは、離散不純物ばらつきに加えて他の要因が関与していることを示唆した。
将来展望としては、High-k/Metal-Gate の導入により一時的にランダムばらつきは低減するものの、チャネル不純物濃度を低くできる SOI、FinFET、ナノワイヤの追求は続き、さらにメタルソース・ドレインなど、ソース・ドレインの不純物もなくす方- 74 -

向と予想。ただし、不純物をなくしても、必ず他のばらつき要因が現れ支配的となる
ため、ナノ領域ではバラつきに対する総合対策が必須と締めくくった。
続いて、回路設計の立場から同じく東京大学生産技術研究所教授の桜井貴康氏が登壇。回路特性に対するデバイスばらつきの影響を論じた。まず、WID（Within Die)バ
ラつきの中のランダムバラつきについて、一般に n 段直列ゲートの遅延バラつきは 1/√n に緩和されると考えられるが、最低動作電圧はそれらのうちワーストなゲートで規定されることを指摘。低消費電力を目指した超低電圧設計において問題になることを示した。
また、規則正しいレイアウトパターンによりバラつきの幅を抑えられるか、という点について Sea-Of-Gates 型と通常の標準セルレイアウトの 90nm における特性比較結果を紹介し、期待したほどランダムバラつき幅は狭まらず、むしろ面積と平均遅延値
へのペナルティが大きいことを示した。
なお、講演時間内には十分な時間がなく議論ができなかった D2D(Die to Die)バラつきについてもコメントがあり、今後、設計に対し本質的に重要となるため、設計者としての以下の 2 つの希望を挙げた。
１）なるべく、D2D ばらつきを小さくするプロセス
２）Post-fabrication Vth adjustment (tuning)を許すデバイス（例えば、短チャネル
でも基板バイアスの効くデバイス）
3 番目には、「Statistical 回路設計イノベーション」をテーマに米 Purdue University,
Roscoe H George Professor の Kaushik Roy 氏が登壇。バラつきに対して敏感な回路である SRAM を中心とした最新の耐バラつき設計を紹介した。
Kaushik Roy 氏は SRAM について、D2D バラつきの影響をリード、ライト、アクセス、ホールドの各動作に分けて論じ、低 Vth 側のコーナーではリード、ホールド、
高 Vth 側のコーナーではライト、アクセスの不良が増加することを解説。双方の不良を低減するため、D2D バラつきを確実に捉える SRAM アレイのリーク電流モニタ回路と、その検出値をフィードバックして適切なボディバイアスを SRAM アレイに与える
自己修復回路を紹介した。その他、ビット線のリークを補償するキーパー回路のサイ
ズをダイナミックに調整し、遅延ばらつきを補正する手法や、ロジック回路において活性化率の低いクリティカルパスを敢えて２サイクル動作とし、低電力と耐バラつき性を向上するアプローチ CRISTA(CRitical path ISolation for Timing Adaptiveness)
等、様々な手法が紹介された。結論として、プロセスバラつき、およびプロセス許容性は益々重要な問題となっており、電力、性能、歩留まりを考慮した最適化設計が必要となってきている、と述べた。

- 75 -

本フォーラムの最後は米 University of Michigan, Associate Professor の Dennis
Sylvester 氏が登壇。"Coping with Variability in Nanoscale CMOS ～Analyze, Sense,
Correct, Exploit" と題して、多角的にバラつき問題を俯瞰した。
Sylvester 氏は、バラつき問題はバラつきそのものではなく、バラつきを見込んで設定する設計マージンの問題である、とした。その上で、まず Sense として信頼性モニ
タ、具体的には NBTI(Negative Bias Temperature Instability)センサ回路やゲートリ
ークモニタ回路により LSI の寿命を正確に見積もって、設計マージンを適切に制御するアプローチを紹介した。NBTI 特性劣化による PMOS 寿命を平均値だけでなく分布形状まで示すスライドに、初めてこのようなデータを見る！と感嘆する質問があった。
実際は実験的に測定したものではなくシミュレーション結果であるという説明であったが、新たに提案された TEG でこのようなデータが測定できる可能性があるということで反響を呼んだ。しかし、このようにして得られたデータを信頼性設計にどのように使うかはまだ明確な方法論が確立されておらず、今後の実用化を期待したい分野である。そのほか、Analyze としてモンテカルロベース SSTA、Correct として劣化に応じた動的電源制御 DVS(Dynamic Voltage Scaling)、Exploit としてストレス効果を制御するための設計ガイドラインの紹介があった。
金本俊幾 ＝ 株式会社ルネサステクノロジ
JEITA ナノ世代物理設計ワーキング・グループ

3.2.4

まとめ

本年の SystemC ユーザ・フォーラム 2009 の参加人数は、厳しい経済状況の中、例年より少ない人数ではあったが、123 名を集められたことは、依然として SystemC への興味が高いことを表していると考えられる。
講演は 2 時間で 5 講演を実施。OSCI、JEITA SystemC ワーキング・グループ、及びSTARC による報告、SystemC 適用事例 2 件と充実した内容であったが、時間的にはやや不足気味であった。質疑応答も活発に行われた(7 件)。
フォーラム終了後のアンケートでは、SystemC ユーザ・フォーラム 2009 の満足度（満足＋まあ満足）が 70％と前年度の 81％を下回り、昨年よりは低い結果となった。しかしながら、「満足」だけを取り上げると、17%から 26%へ増加がみられる。適用が進み、はっきりとした目的意識を持った参加者が多かったのかもしれない。来年度以降開催する場合には、フォーラムの位置づけを見直す必要があると思われる。
ナノ世代物理設計フォーラムの満足度（満足＋まあ満足）が 76％となっており、今後の参加希望についての設問でも、「希望する」（参加する＋内容次第で参加する）が 88％とな- 76 -

り、フォーラム内容の充実と開催への期待が確認された。
本フォーラムに期待された講演内容については、「デバイス特性ばらつき動向」と「耐ばらつき設計」がともに 35%とあり、副っていると考えられる。またもっとも得られた知見は、という設問には「デバイス特性ばらつき動向」が 52%と高い評価であった。
その他、意見、要望の設問では、「有料でも 2,000～3,000 円であれば、ありがたい」、「DFM、
DFY Technology フォーラムを開いて欲しい」等、今後に対する期待をいただいた。
運営に関しては、「始まってからしばらく、カメラのフラッシュがひどかった。有料のセッションではひかえていただきたい」、「受け付けの対応が悪い」、「全体的に講演内容に対して時間が足らない印象。特に 3 番目の講演は、項目を絞った方が良かった」とのコメントをいただいた。今後の反省材料としたい。
また要望として「電子資料の配布」、「予稿集と実際の発表時スライドで差がある。最新の予稿を PDF で入手できるようにして欲しい」、「英語が苦手なので、Q＆A の解説がほしかった」とのコメントもあり、検討事項としたい。

3.2.5

システム・デザイン・フォーラム 2009WG 委員（敬称略、順不同）

主

査

江 田

努

ローム㈱

委

員

熊 谷

敬

セイコーエプソン㈱

同

河 村

薫

富士通マイクロエレクトロニクス㈱同金 本 俊 幾㈱ルネサステクノロジ

同

中 森

勉

富士通マイクロエレクトロニクス㈱

同

長谷川 隆

富士通マイクロエレクトロニクス㈱同

中 西 早 苗NEC エレクトロニクス㈱

同

西園寺 修

日本シノプシス㈱同今 井 正 治大阪大学

同

若 林 一 敏日本電気㈱同山 田 陽 一セイコーエプソン㈱アドバイザ

太 田 光 保パナソニック㈱

オブザーバ

山 田

三洋電機㈱

事 務 局

小田 佳代子節

日本エレクトロニクスショー協会- 77 -

3.3 ASP-DAC 2009
3.3.1 はじめに
ASP-DAC (Asia and South Pacific Design Automation Conference)は、VLSI およびシステム LSIの設計技術や設計自動化技術をテーマにしたアジア太平洋地域での最大規模の国際会議である。
ASP-DAC は米国で開催されるこの分野のトップ・コンファレンスである DAC (Design Automation
Conference)、ICCAD（International Conference on Computer Aided Design）や欧州で開催される
DATE (Design, Automation and Test in Europe)とはシスター・コンファレンスの関係にあり、お互いにリエゾンを交換して協力関係を持っている。
ASP-DAC は、電子情報通信学会や情報処理学会などの学会だけでなく、電機メーカおよび半導体メーカの業界団体である JEITA（会議開始当時は EIAJ）と EDSF（会議開始当時は EDAT）の支援のもとで 1995 年に開始された。業界団体である JEITA が ASP-DAC のような国際会議の支援を行っているのは、次のような理由による。電機メーカや半導体メーカが国際競争力のある電子製品の開発を行うた
めには、マーケッティングや製品企画だけでなく、大規模・高機能・低消費電力のシステム LSI の最適設計を短期間で行える設計力を持つ必要がある。そのためには、最新の設計自動化技術についての情報収集と研究開発を行う必要がある。一流の国際会議を国内で開催することにより、わが国からより多くの技術者と研究者が参加して最先端の設計技術および設計自動化技術についての情報収集、情報交換などを行うことが可能になる。
3.3.2 会議の開催経緯
ASP-DAC の第 1 回目の会議は 1995 年 8 月 30 日から 9 月 1 日にかけて幕張メッセの日本コンベンションセンターで、情報処理分野の国際学会である IFIP（International Federation on Information
Processing）の TC10 WG10.2 および WG10.5 に属する CHDL および VLSI という名称の 2 つの国際会議と並列開催の形で開催された。第 2 回目は 1997 年 1 月に開催され、それ以降毎年 1 月に開催されてきた。この間、1999 年には香港（中国）で、2002 年にはバンガロール（インド）でそれぞれ開催された。2007 年以降は、日本と国外で交互に開催するというローテーションで運営されている。今回の会議（ASP-DAC 2009）は 14 回目で、横浜市パシフィコ横浜で 1 月 19 日（月）から 22 日（木）の日
程で開催された。
3.3.3 ASP-DAC 2009 の概要
ASP-DAC 2009 の概要を表 1 に示す。一般講演としては、33 カ国から投稿された 355 編の論文の中から 116 編が採択され、3 日間にわたって並列の 4 つのトラック、24 のセッションで発表された。表
１からもわかるように、論文の投稿数については前回韓国で開催された ASP-DAC

2008 を越す 355

件で、論文の採択率は前年よりやや低い 33％であり、この分野での他の国際会議（DAC,

ICCAD,DATE）とほぼ同じ水準を維持している。これまでどおり、ASP-DAC は名実ともに一流の国際会議であると評価できる。
基調講演のタイトルと講演者を表 2 に、特別セッションのタイトルを表 3 に示す。また、表 4 に、昨年に引き続いて実施されたデザイナーズ・フォーラムのセッション・タイトルを示す。表 5 には、有料チュートリアルのタイトルを示す。
発表された論文の中から、表 6 に示す 2 本の論文が選ばれ、ベストペーパー賞が授与された。また、デザイン・コンテストに応募した作品の中から、表 7 に示すベストデザイン 2 件が選ばれて表彰された。
- 78 -

前回と同じく学生フォーラムも実施された。

表 1: ASP-DAC 2007、2008、2009 の比較
開催年
日時
会場

2007 年2008 年2009 年

2007 年 1 月 23 日（火） 2008 年 1 月 21 日（月） 2009 年 1 月 19 日（月）～26 日（金）～24 日（木）～22 日（木）横浜市 (日本)
横浜市 (日本)
ソウル (韓国)
パシフィコ横浜
パシフィコ横浜
COEX

併設展示会

EDSF 2007---

EDSF 2009

論文投稿数

408

350

355

論文投稿国
（地域）数

30

27

33

論文採択数
（採択率）

131（32%）

122（35%）116（33%）

3件

3件

3件
（表 2 参照）

キーノート
アドレス
一般講演

27 セッション（131編）

特別セッション
（招待講演等）

5 セッション

4 セッション

4 セッション
（表 3 参照）

デザイン・
コンテスト

1 セッション

1 セッション

1 セッション

学生フォーラム

昼休みに実施（Student Forum と改称）

昼休みに実施（Student Forum）

昼休みに実施（Student Forum）

ポスターボード－－－

有料チュートリアル

デザイナーズ・フォーラム

24 セッション（122 編） 24 セッション（116 編）

6件
5件
7 件 （表 5 参照）（全日 2 件、半日 4 件） （全日 2 件、半日 3 件） （全日 1 件、半日 6 件）
4 セッション
（招待講演 2、
パネル討論 2）

4 セッション
（招待講演 2、
パネル討論 2）

- 79 -

4 セッション（表 4 参照）（招待講演 2、
パネル討論 2）

表 2: 基調講演
講演タイトル

講演者

Challenges to EDA system from the view point of processor
design and technology drivers
Automated Synthesis and Verification of Embedded Systems:
Wishful Thinking or Reality?

Mitsuo Saito（Toshiba Corp., Japan）
Wolfgang Rosenstiel(Univ. of Tuebingen, Germany)
Leon Stok(IBM Corp., USA)

From Restrictive to Prescriptive Design

表 3: 特別セッションのタイトル種類

セッション・タイトル
セッション 2D: EDA Acceleration Using New Architectures

招待講演

セッション 3D: Hardware Dependent Software for Multi- and Many-Core
Embedded Systems
セッション 4D: Challenges in 3D Integrated Circuit Design

パネル討論

セッション 9D: Dependable VLSI: Device, Design and Architecture – Howshould they cooperate? -表 4: デザイナーズ・フォーラムのタイトル種類

セッション・タイトル
セッション 5D: Consumer SoCs

招待講演
セッション 7D: Analog/RF Circuit Designs
セッション 6D: ESL Design Methods
パネル討論

セ ッ シ ョ : ン 8D: Near-Future SoC Architectures – Can Dynamically
Reconfigurable Processors be a Key Technology?

- 80 -

表 5：

Tutorial のタイトル

トラック

種類

タイトル

1

全日

Software Development and Programming of Multi-core LSI

2

半日Formal Methods for C-Based Embedded System Design Verification –Technical Trends and Practical Aspects -3

半日Statistical Design on the Verge of Maturity: Revisiting the Foundation

4

半日

Circuit Reliability I: Reliability Mechanisms and the Impact on IC Design

5

半日

Circuit Reliability II: Circuit Aging Prediction and Resilient Design

6

半日

Recent Advances in Low-Leakage VLSI Design

7

半日

Memory Architectures and Software Transformations for System Level Design

表 6: ベストペーパー賞が授与された論文

論文タイトル・著者
1C-1: “Fast Yield: Variation-Aware, Layout-Driven Simultaneous Binding and Module Selection
for Performance Yield Optimization”, Gregory Lucas, Scott Cromar and Deming Chen (Univ. of
Illinois, Urbana-Champaign, USA)
5C-1: “Efficiently Finding the ‘Best’ Solution with Multi-Objectives from Multiple Topologies in
Topology Library of Analog Circuit”, Yu Liu, Masato Yoshioka, Katsumi Homma and Toshiyuki
Shibuya (Fujitsu Laboratories Ltd., Japan)
表 7: ベストデザイン賞が授与された設計
種類
Best
Award

論文タイトル・著者
DesignSpecial FeatureAward

1D-1: "A Wireless Real-Time On-Chip Bus Trace System", Shusuke Kawai,
Takayuki Ikari (Keio Univ., Japan), Yutaka Takikawa (Renesas Design Corp.,
Japan), Hiroki Ishikuro, Tadahiro Kuroda (Keio Univ., Japan)
1D-13: "Ultra Low-Power ANSI S1.11 Filter Bank for Digital Hearing Aids",
Yu-Ting Kuo, Tay-Jyi Lin, Yueh-Tai Li (National Chiao Tung Univ., Taiwan),
Chou-Kun Lin (ITRI, STC, Taiwan), Chih-Wei Liu (National Chiao Tung
Univ., Taiwan)

3.3.4 論文の投稿状況
1998 年から 2009 年の、ASP-DAC への論文投稿数の地域別の推移を図 1 に示す。ただし、ASP-DAC
2002 については、インドのバンガロールで同時開催された VLSI Design 2002 への投稿論文を含む。図1 に示すように、1999 年（香港開催）以降は投稿論文数が増加し、安定的に 300～400 件の投稿がある。
名実ともに、ASP-DAC は設計自動化分野の国際会議として定着したと言ってよいであろう。
表 8 に、日本からの論文投稿数の推移と、全世界から投稿された論文に占める割合を示す。日本からの論文投稿数が全体に占める割合は、2000 年をピークにして、10%前後に低下している。今回は、日- 81 -

本と台湾、北米などの地域からの投稿が増加した。論文投稿数が多かったのは、米国の 105 編（前回は92 編）、中国の 43 編（前回は 67 編）、日本の 50 編（前回は 31 編）、台湾の 54 編（前回は 34 編）、イ
ンドの 21 編（前回は 25 編）であった。

図１ 地域別論文投稿数
7 00
6 00

A fr ic a/ O ther sEuro pe

5 00

A m erica

4 00
投稿
論文 数

A SP (e xc .
Jap an)Jap an

3 00
2 00
1 00

09
20

20
08

7
20
0

20
06

20
05

04
20

2
20
03

20
0

20
01

20
00

99
19

19
98

0

年

表 8 日本からの論文投稿数と全体に占める割合
年
地域

1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

46
日本
(38%
（割合）
)

18
(16%
)

42
(29%
)

29
(18%
)

24
(9%)

42
(18%
)

36
(12%
)

46
(7%)

51
(12%
)

44
(11%
)

31
(9%)

50
(14%
)

121

111

144

161

269

235

291

692

424

408

350

355

全体

次に、研究分野別の論文投稿数および採択論文数を表 9 に示す。ASP-DAC 2009 では、研究分野を
13 種類に分類して論文の査読と採否の決定を行った。今回論文投稿数が多かった分野は、分野 1 のシステムレベル設計手法のセッション、分野 8 のタイミング・消費電力関係のセッション、分野 2 のシス
テム・アーキテクチャおよび最適化のセッション、分野 3 の組み込みシステムおよびリアルタイム・シ
ステムのセッションであった。

- 82 -

表 9: 分野別の論文投稿数と採択論文数
分野

研究分野

投稿数

採択数

採択率

1

System-Level Design Methodology

48

16

33.3%

2

System Architecture and Optimization

40

12

30.0%

3

Embedded and Real-Time Systems

36

12

33.3%

4

High-Level/Behavioral/Logic Synthesis and Optimization

23

8

34.8%

5

Validation and Verification for Behavioral/Logic Design

21

6

28.6%

6

Physical Design (Routing)

17

6

35.3%

7

Physical Design (Placement)

15

5

33.3%

8

Timing, Power, Thermal Analysis and Optimization

41

14

34.1%

9

Signal/power Integrity, Interconnect/Device/Circuit Modelingand Simulation

18

7

38.9%

10

Design for Manufacturability/Yield and Statistical Design

16

6

37.5%

11

Test and Design for Testability

22

9

40.9%

12

Analog, RF and Mixed Signal Design and CAD

26

5

19.2%

13

Emerging Technologies and Applications

32

10

31.3%

355

116

32.7%

合

計

3.3.5 参加者の内訳
ASP-DAC への地域別の参加者数の推移を図 2 に示す。また、日本からの参加者の推移を表 10 に示す。今回の全参加者数は 492 名であった。前回（412 名）と比べると、参加者が増加した。日本からの参加者数は全体の 62.0%の 305 名であった。
図 2 地域別参加者の推移

800
Europe700
600

America500
ASP (exc.
Japan)

参 加 者数 400
300

Japan

200
100

Grand Total

年- 83 -

09
20

08
20

07
20

06
20

05
20

04
20

03
20

02
20

01
20

00
20

99
19

19

98

0

表 10: 日本からの参加者数と全体に占める割合（チュートリアルのみの参加者を除く）
年
地域

1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

日本
(割合)

416
(79%
)

32
(21%
)

383
(76%
)

379
(73%
)

N/A

253
(59%
)

316
(61%
)

55
(11%
)

494
(70%
)

450
(66%
)

77
(19%
)

305
(62%
)

全体

524

156

507

520

623

429

515

516

708

685

412

492

3.3.6 今後の展望
ASP-DAC の今後の開催予定を表 11 に示す。引き続き、隔年で日本開催になる模様である。
表 11:
年

開催予定地

2010 年

Taipei（台湾）2011 年

横浜（日本）ASP-DAC の今後の開催予定
開催時期

実行委員長

Y.L.Lin 氏 （National
Tsing Hua Univ.）
浅田邦博 氏2011 年 1 月 25 日（火）～28 日（金）（Univ. of Tokyo.）2010 年 1 月 18 日（月）～21 日（木）- 84 -

3.4

EDA 用語辞典

3.4.1

背景と目的

エレクトロニクス機器の中核部品であるシステム LSI は、半導体微細化技術の目覚ましい進歩の恩恵を受けて大規模・高機能化している。システム LSI のこのような複雑化に伴い、設計上流
では超大規模システム LSI の機能・論理の設計や検証問題、設計下流ではバラツキ問題（DFM：
design for manufacturability）が顕在化しており、これらの設計課題を解決するために、LSIの自動設計化技術（EDA：electronic design automation)も進歩している。
JEITA（(社)電子情報技術産業協会） EDA 技術専門委員会は、EDA 技術の進歩に伴う最先端技術を分かり易く解説して EDA 技術の普促・推進を行うために、EDA 用語辞典ワーキンググループ（WG）
を発足させて、日経 BP 社『Tech-On!』サイトの「EDA 用語辞典 LSI 設計ツール編」（初版 1999 年）
を、「改訂版 EDA 用語辞典」として最新版に改訂した。
「改訂版 EDA 用語辞典」では、｢設計言語の標準化｣、｢アサーション検証｣、｢プラットフォーム・ベース設計｣、｢パワー・フォーマット｣、「故障診断」などの新規の用語が用語全体の半分を占めると共に、DFM 技術を中心にして全ての用語が最新技術を反映した内容に更新された。
「改訂版 EDA 用語辞典」の出版に際し、今井正治 教授（大阪大学）を監修者にお招きし、国内を代表する専門家によって EDA 用語辞典 WG を構成し、第一線の先生、研究者、技術者の方々に執筆を頂いた。
3.4.2

概要

本 「 改 訂 版 EDA 用 語 辞 典 」 は 、 以 下 の 日 経 BP 社 『 Tech-On! 』 サ イ ト に 掲 載 さ れ た 。
（http://techon.nikkeibp.co.jp/word/column/eda/）
見出し用語数は以下の 44 件である。
分類
LSI設計とEDA技術
標準化
システム・レベル
設計・検証

見出し用語
[LSI設計とEDA用語辞典][標準化][設計言語の標準化][フォーマット・モデリングの標準化][システム設計・検証][システム・レベル記述言語][ハードウェア・ソフトウェア協調設計][動作合成][プラットフォーム・ベース設計][トランザクション・レベル・モデリング][ASIP][機能設計・検証][検証カバレッジ][ハードウェア記述言語・検証記述言語][アサーション・ベース検証][フォーマル検証][非同期検証]
機能設計・検証[論理エミュレーション、プロトタイピング][論理シミュレーション][論理合成][コーディング・スタイル・チェック][LSIのテスト][故障シミュレーション][ATPG][DFT]LSIのテスト[スキャン・テスト][BIST][故障診断]
低消費電力設計[低消費電力設計][パワー・フォーマット]
回路設計・検証[ミックスド・シグナル][回路シミュレーション][物理設計・検証][プロトタイピング][シグナル・インテグリティ解析][信頼性解析]
物理設計・検証[自動レイアウト][レイアウト寄生パラメータ抽出][レイアウト検証][DFM]
タイミング設計・検証 [STA][SSTA][セル・キャラクタライズ][OCV]

3.4.3

参加メンバ

主査

黒川 敦

三洋半導体(株)監修今井正治

国立大学法人 大阪大学

専門家(標準化技術)

神戸尚志

近畿大学

専門家(システム)長谷川隆

富士通マイクロエレクトロニクス(株)

-－－
85 -

今井正治(兼)専門家(テスト設計)

吉田正昭

ＮＥＣエレクトロニクス(株)専門家(物理設計)

金本俊幾(株)ルネサステクノロジ

黒川敦(兼)委員

山田節

三洋電機(株)委員

西本猛史

シャープ(株)委員

熊谷 敬

セイコーエプソン(株)

委員

齋藤茂美

ソニー(株)

委員

南(株)）東芝委員

太田光保

パナソニック(株)委員河村

富士通マイクロエレクトロニクス(株)

委員

秋山俊恭

(株)ルネサステクノロジ

委員

江田 努

ローム(株)

委員

長野義史(株)エッチ・ディー・ラボ

委員

川原常盛

コーウェア(株)委員

山城 治(株)ジーダット

委員

野坂啓介

(株)図研

委員

平尾栄二

凸版印刷(株)委員

安井孝史

日本ケイデンス・デザイン・システムズ社

委員

飯島一彦

日本シノプシス(株)

委員

船津英世

マグマ・デザイン・オートメーション(株)

委員

瀬谷和宏

丸紅情報システムズ(株)

委員

三橋明城男

メンター・グラフィックス・ジャパン(株)

委員

前野酉治

(株)リコー

文裕
薫

-－－
86 -

４．添付資料

4.1 ﾅﾉ世代物理設計 ﾜｰｷﾝｸﾞｸﾞﾙｰﾌﾟ報告
1.
1. 製造ばらつきに起因する製造ばらつきに起因するリーク電流変動の低減法
リーク電流変動の低減法

1

報告内容
報告内容
• はじめに• 提案手法• 提案手法の検証
• まとめ

2

-87-

背景
背景
• LSIの微細化が進むにつれ、リーク電流は、増加傾向にあり、リーク電流の低減は必須である。
• リーク電流はプロセスばらつきに敏感であり、出来上がったチップ毎にリーク電流に大きな差を生じさせ、歩留りの低下につながる。
リーク電流のばらつきの要因を明確化し、ばらつきを低減することは非常に重要である。

3

課題
課題
• リーク電流のばらつきに対してどのデバイスパラ
メータがどのように影響するのかを明瞭に報告している例はみられなかった。
• プロセスばらつきに対して遅延分布を悪化させずに、リーク電流ばらつきを低減する手法は報告されてい
ない。

4

-88-

目的
目的
プロセスばらつきによる遅延時間とリーク電流の関係から、遅延一定となる条件下でリーク電流を変動させるパラメータの関係を吟味し、リーク電流ばらつきを低減する方法を提示し、その有効性を示
す。

5

提案手法
提案手法
• NMOSとPMOSの各種パラメータのバランスを調整し、等しい遅延の中でリーク電流を最小にさせる。

リーク電流

リーク電流の低減

遅延
6

-89-

キーアイデア
キーアイデア• スタンダードセルにおけるNMOSとPMOSのパラメータのチューニング手法
Lp
リークの分布（等高線）
リーク小遅延の分布（等高線）

遅延が一定のライン

Ln
遅延時間が一定の中で、リーク電流が最小となる
LpとLnの組み合わせ
7

解析式の導出方法
解析式の導出方法• 遅延時間とリーク電流を解析式で表現する。
解析式では、閾値電圧Vth、チャネル長L、ゲート酸化膜厚Toxを考慮し、それぞれNMOSとPMOSを個別に扱う。解析式の変数はVth,P,Vth,N, LP, LN, ToxP, Tox,N の6個となる。
• インバータ2段分の遅延とリーク電流を取り扱う。
• 遅延とリーク電流の解析式は、応答曲面法により以下の2次の多項式で表現する。
n

n

i =1

i =1 j ≥ iny = β 0 + ∑ β i x i + ∑∑ β ij x i x j
8-90-遅延の解析式
遅延の解析式•

インバータの遅延はα乗モデル[1]から、以下の式で得られる。

C LV ddε W
μ ⋅ ox ⋅ (V dd − Vth )α
Tox L
1
Td ∝
, L, Tox(Vdd − Vth )αTd =遅延の解析式は以下のように表現する。

Td ,1 − Td ,0 = f (Vth , P ,1 − Vth , P , 0 , Vth , N ,1 − Vth , N , 0 ,LP ,1 LN ,1 Tox , P ,1 Tox , N ,1 ⎞⎟,,,LP ,0 LN , 0 Tox , P ,0 Tox , N , 0 ⎟⎠PとNはPMOSとNMOS、0はノミナル時の値、1は変動した時の値の意味
9リーク電流の解析式
リーク電流の解析式•

リーク電流はおおよそ以下のトータル電流で表される[2]。

I total = I BTBT + I sub + I gate + I GIDL
BSIM4[3]で、Isubは以下で表される。
I sub = με ox W
Tox L

V gs −VthVT 2 e nVT−Vds ⎞
⎛
⎜
VT ⎟
−
1
e
⎜
⎟
⎜
⎟
⎝
⎠

Gate
Source
N+
P-sub

Drain
Isub
Igate

N+
IGIDL
IBTBT

ln (I sub ) ∝ (V dd − Vth ), ln (Tox ), ln (L )リーク電流の解析式は以下のように表現する。

⎛ Ileak,1 ⎞⎛ LP,1 ⎞ ⎛ LN ,1 ⎞ ⎛ Tox, P,1 ⎞ ⎛ Tox, N ,1 ⎞ ⎞⎟⎟⎟, ln⎜
⎜
⎟
⎜
⎟ ⎜
⎟ ⎜
ln⎜
⎟ = g(Vth,P,1 −Vth,P,1, Vth,N ,1 −Vth,N ,1,ln⎜ L ⎟, ln⎜ L ⎟, ln⎜ T
⎟ ⎜T
⎟⎟
I
⎝ leak,0 ⎠⎝ P,0 ⎠ ⎝ N ,0 ⎠ ⎝ ox, P,0 ⎠ ⎝ ox, N ,0 ⎠ ⎠
10

-91-

解析式導出に用いた回路と条件
解析式導出に用いた回路と条件•

回路は多段インバータとし、波形が安定した2段の遅延(Td)とリーク電流(Ileak)を求める。
項目

値

SPICEモデルパラメータ

Delay

Td

PTM 45nm (Bulk)[23]

SPICE電流モデル

BSIM4

電源電圧V dd

1V

基本（×1インバ ータ ）の トラ P W/L=450nm/45nm
ンジスタサイズ
N W/L=225nm/45nm

I

A leak閾値電圧（V th ）の3σ42%チャネル長（L）の3σ

12%

ゲート酸化膜厚（T ox ）の3σ

4%

変動パラメータは閾値電圧Vth、チャネル長L、ゲート酸化膜厚Toxの3種とし、PMOS、NMOSそれぞれ、各パラメータの値を-3σ,-1σ,0,1σ,3σの5点で振り、計56= 15625点のSPICEシミュレーションを行う。求めた結果を遅延とリーク電流の解析式に当てはめ、係数を抽出する。
11

インバータにおける解析式の結果
インバータにおける解析式の結果•

Vth, L, ToxのPMOS、NMOSトランジスタ全6パラメータを用いた遅延解析
式とリーク電流解析式の係数
n

n

i =1

i =1 j ≥ iny = β 0 + ∑ β i x i + ∑∑ β ij x i x j

リーク電流解析式係数 と解析式

遅延解析式係数 と解析式
β0
β1
β2
β3
β4
β5
β6
2.38E-11 1.11E-10 -8.70E-11 -2.86E-11
8.51E-12 -4.72E-11 -4.02E-11

β0
β1
β2
β3
β4
β5
β6
6.17E-01 1.02E+01 -8.80E+00 -1.57E+01 -1.10E+01 -1.03E+00 -2.53E+00

βij
β1
β2
β3
β4
β5
β6

βij
β1
β2
β3
β4
β5
β6

β1
β2
β3
β4
β5
β6
3.07E-11 -3.08E-11 -7.54E-11 -2.51E-11 -1.81E-11 -1.09E-11
2.30E-11
3.77E-11
4.00E-11
1.05E-11
1.49E-11-8.61E-12
3.00E-11
3.29E-11
1.36E-11-2.67E-11
8.86E-12
2.32E-11
3.93E-12
3.35E-12
3.18E-12

Tox , N ,1⎞⎛I
y = ln⎜⎜ leak ,1 ⎟⎟, x1 = Vth , P ,1 − Vth , P ,1 , x2 = Vth , N ,1 − Vth , N ,1 ,⎝ I leak , 0 ⎠LL
x3 = P ,1 , x4 = N ,1 ,LP , 0LN ,0Tox , N , 0

x5 =y = Td ,1 − Td , 0 , x1 = Vth , P ,1 − Vth , P , 0 , x2 = Vth , N ,1 − Vth , N , 0 ,
x3 =
x5 =

LP ,1
LP , 0, x4 =Tox , P ,1
Tox , P , 0

LN ,1
LN , 0, x6 =

β1
β2
β3
β4
β5
β6
1.79E+01
3.06E+01 -3.77E+01
3.57E+01 -8.35E+00
1.31E+01
1.58E+01 -4.35E+01
3.37E+01 -3.37E+00 -5.51E-01
7.98E+01 -5.30E+01 -7.18E+00 -1.58E+01
5.55E+01 -3.79E+00 -1.37E+01
4.44E-01 -1.64E+00
3.85E+00,

Tox , P ,1
Tox , P , 0, x6 =Tox , N ,1
Tox , N , 0
12

-92-

インバータにおける解析式の結果
インバータにおける解析式の結果•

Vth、L、Toxそれぞれ個別に扱った遅延解析式とリーク電流解析式の係数
n

n

i =1

i =1 j ≥ iny = β 0 + ∑ β i x i + ∑∑ β ij x i x j

リーク電流解析式係数 と解析式

遅延解析式係数 と解析式
Vth
L
Tox

β0
β1
β2
β11
β22
β12
-6.42E-15 -1.86E-11
1.63E-11
3.01E-11
2.35E-11 -2.97E-11
β0
β3
β4
β33
β44
β34
-5.27E-11
2.20E-11
4.04E-11 -9.73E-12 -2.53E-11
2.54E-11
β0
β5
β6
β55
β66
β56
-2.98E-12 -3.29E-12 -1.68E-12
2.87E-12
2.43E-12
2.65E-12

Vth
L
Tox

Vth： y = Td ,1 − Td ,0 , x1 = Vth, P ,1 − Vth, P ,0 , x2 = Vth , N ,1 − Vth, N , 0
y = Td ,1 − Td , 0 , x3 =

L：

LP ,1
LP , 0, x4 =Tox , P ,1

Tox： y = Td ,1 − Td ,0 , x5 = T

ox , P , 0

LN ,1

Tox , N ,1

Tox：

Tox , N ,0

⎛ I leak ,1 ⎞⎟, x1 = Vth , P ,1 − Vth , P ,1 , x2 = Vth , N ,1 − Vth , N ,1⎟
⎝ I leak , 0 ⎠ILL
y = leak ,1 , x3 = P ,1 , x4 = N ,1
I leak , 0
LP , 0
LN , 0Vth： y = ln⎜⎜
L：

LN , 0, x6 =

β0
β1
β2
β11
β22
β12
2.26E-01
1.14E+01 -9.43E+00 3.21E+01 2.66E+01
4.37E+01
β0
β3
β4
β33
β44
β34
1.42E-01 -1.88E+01 -1.34E+01 1.14E+02 8.34E+01 -9.11E+01
β0
β5
β6
β55
β66
β56
-6.36E-06 -1.60E+00 -2.29E+00 9.17E-01 6.33E+00 -3.64E+00y=

I leak ,1
I leak ,0, x5 =Tox , P ,1
Tox , P ,0

, x6 =Tox , N ,1
Tox , N ,013

解析式の精度解析式の精度
本解析では、解析式を用いて評価を実施するので、 SPICEシミュレーショ
ン結果と解析式から計算した結果を比較し、解析（回帰）式の精度を確認
する。
遅延変動値

Log(リーク変動率)
解析式計算値

解析式計算値 (ps)•SPICE sim. 値 (ps)SPICE sim. 値

遅延とリーク電流の回帰式の決定係数R2 は、それぞれ0.995と0.968であった。Vth, L, Tox個別の係数、回路をNAND、NORに変更した場合においても、決定係数は0.95以上となり、解析式で十分高い精度が得られる
ことを確認した。
14-93-

プロセス・パラメータがリーク電流へ与える影響
プロセス・パラメータがリーク電流へ与える影響•

プロセス・パラメータが変動した時のリーク電流への影響を示す。

10.0 100.0
1.0

Vth
L
Tox

0.1

リーク電流の変動比率

ノミナル値1に対するリーク電流の変動率− 3σ− 2σ− 1σ 0

Vthの3σ

42%

Lの3σ

12%

Toxの3σ4%

1σ 2σ 3σ

プロセス・パラメータの変動

Toxはリーク電流のばらつきに対して寄与が少ないことがわかる。
15

プロセスばらつきによる遅延とリーク電流の相関
プロセスばらつきによる遅延とリーク電流の相関

1e-08

1e-06

1e-04

Vth, L, Toxのパラメータがばらついた場合の、遅延とリーク電流の分布を示す。横軸が遅延、縦軸がlogをとったリーク電流値 である。

Ileak(A)•

試行回数1万回のモンテ
カルロ解析の結果

5

10

15

20

Td(ps)

遅延とリーク電流は1対1に対応しているわけではなく、遅延が一定でも様々なリーク電流値になる条件が存在する。このような幅を持つことは、実測値[4]でもみられている。
16

-94-

解析式による遅延とリーク電流の評価
解析式による遅延とリーク電流の評価
INVでのリーク電流と遅延の分布を求めた。遅延とリーク電流の解析式
は2次式のフィッティングであるため、Vth,P,Vth,Nの2次元のパラメータ空間の中ではリーク電流と遅延値は楕円の分布を形成する。

LN,1/LN,0

Vth,N,1-Vth,N,0(V)•:遅延一定のままリーク電流が最小になるポイント

LP,1/LP,0

Vth,P,1-V th,P,0 (V)パラメータのノミナル値を遅延の等高線が0の線に沿って動かすことにより、遅延が一定のまま、リーク電流が変動する。インバータの例では、初期値がリーク電流最小に近い条件であることがわかった。
17

解析式による遅延とリーク電流の評価
解析式による遅延とリーク電流の評価
2入力NOR、2入力NANDでのリーク電流と遅延の分布を求めた。
2-NAND

2-NOR
Vth,N,1-Vth,N,0(V)Vth,N,1-Vth,N,0(V)•

Vth,P,1-V th,P,0 (V):遅延一定のままリーク電流が最小になるポイント

Vth,P,1-V th,P,0 (V)パラメータのノミナル値(0,0)を遅延一定のままリーク電流最小の位置に移動させることにより、移動させる前よりもリーク電流が最小に近い値で分布し、リーク電流のばらつきは低減されることが予想される。
18

-95-

2パラメータ間の遅延とリーク電流
2パラメータ間の遅延とリーク電流•

PMOS、NMOSトランジスタのVth, L, Tox各々について、遅延とリーク電流値の累積分布として表した。
Tox

0.8
0.6

遅延の累積相対度数

L

1.0

Vth

0.4
0.2
0.0

10

15

20

遅延値(ps)

25

30 5

10

15

20

遅延値(ps)

25

+2%
- 2%

30 5

10

15

20

遅延値(ps)25

30

累積の90%の確率点でリーク電流が最大16倍変動している。

0.6

0.8

1.0

5

リークの累積相対度数

+10%
+5%
+1%
- 1%
- 5%
- 10%

+100mV+50mV+10mV- 10mV- 50mV- 100mV

+10%
+5%
+1%
- 1%
- 5%
- 10%

0.0

0.2

0.4

+100mV+50mV+10mV- 10mV- 50mV- 100mV

1e-08

1e-06

1e-04 1e-08

リーク電流値(A)

1e-06

+2%
- 2%

1e-04 1e-08

リーク電流値(A)

1e-06

1e-04

リーク電流値(A)19

全パラメータを用いた改善
全パラメータを用いた改善
2入力NORについて、Vth, L, ToxのP/N ６パラメータ全てを用いて遅延一定のままリーク電流小のポイントを抽出して、モンテカルロ解析を行った結果である。
最適化後

90 percentile point-49.7%

5e-09

5e-09

5e-07

5e-07

90 percentile point

5e-05

5e-05

最適化前

リーク電流値 (A)

•

20

30

40

遅延値 (ps)

50

60

20

30

40

50

遅延値 (ps)60

リーク電流値のばらつきが狭まっていることがわかる。90%の確率点で、リーク電流に対して49.7%の低減効果があった。
20

-96-

まとめ
まとめ
・遅延ばらつきとリーク電流ばらつきを解析・評価するための解析式を提案し、45nmテクノロジモデル
を例に係数を導出した。
・解析式を元にして遅延を一定にしながらリーク電流ばらつきを削減する方法を提案し、提案手法による実験を行った。
・本提案手法の有効性が確認され、リーク電流ばらつきコーナーが削減されることを示した。

21

参考文献
参考文献
[1]T. Sakurai and A. R. Newton, “Alpha-power law MOSFET model and its
applications to CMOS inverter delay and other formulas,” IEEE J. Solid-State
Circuits, vol. 25, pp. 584–594, Apr. 1990.
[2]W. Nabel and J. Mermet, “Low power design in deep submicron electronics,”
Kluewer Academic Publishers, 1997.
[3]BSIM4, UC Berkeley, [online]. Available: http://wwwdevice.eecs.berkeley.edu/~bsim3/bsim4.html[4]H. F. Dadgour, S.-C. Lin, and K. Banerjee, “A statistical framework for
estimation of full-chip leakage-power distribution under parameter variations,” IEEE
Trans. Electron Devices, vol. 54, no. 11, pp. 2930–2945, Nov. 2007.

22

-97-

2.
2. 32nmプロセスにおける32nmプロセスにおける配線自己発熱の信号伝播遅延に対する
配線自己発熱の信号伝播遅延に対するインパクト調査
インパクト調査

23

背景
背景• 「ばらつき」におけるローカルシステマティック（Deterministic)成分として、配線の自己発熱（Self-heating）考慮要否、あるいは考慮要となる
シチュエーションをスクリーニングしたい。
- 配線-基板間で数十℃も温度差が生じる
シチュエーションがあるかどうか1)- 現実的な構造、物性値を使って配線伝播遅延へのインパクトを評価

24

-98-

配線のSelf-heating
配線のSelf-heating• 配線のSelf-heating とは：電荷の充放電等にともなう配線を流れる
電流による発熱→ 配線と基板との間に温度差を生じる• MOSトランジスタの発熱による基板面内温度分
布は議論が活発→ 配線Self-heating による垂直方向の温度差はOpen issue

25

評価指針
評価指針
• ITRS20072)の物理パラメータ、PTM3) の回路パラ
メータ、Ｎangate4)の設計データから32nmプロセ
ス相当の評価データを策定• 配線自己発熱がSignificantになると思われるケースを抽出→ 短距離配線で大きな容量負荷を駆動1)• 解析手段：有限差分法容量/熱解析、SPICE回路
シミュレーション

26-99-

評価フロー
評価フロー
GDS

GDS

C 抽出 スクリプト 生成

熱解析 スクリプト 生成

C 抽出 スクリプト

熱解析 スクリプト

FDM ソルバ (Raphael )FDM ソルバ (Raphael )FDM ソルバ

駆動 /負荷 ゲート
配線抵抗

配線容量

温度分布

SPICE

POWER

温度分布

27

評価ケース策定
評価ケース策定• 配線自己発熱による温度差が大きくなる要因- 配線の電流量:大 → 負荷容量:大- 体積あたりの消費電力:大→ 短距離配線、細線- 基板からの距離:大 → 上層配線
- 絶縁膜の熱抵抗:大 → 空孔を含む材質（Porous-silicaなど)

28

-100-

ケース1:
ケース1: 64bit-FF駆動モデル
64bit-FF駆動モデル• 64bitMPUのFullAdder5)、Busモデル6)• 64bitのデータ(送)受信部のFF CLK配線→ 負荷容量:大, 上層配線

FF

FF
・
・
・
FF

・
・
・

・
・
・
FF

Data送受信

CLK

29

Driver/Receiver/配線モデル
Driver/Receiver/配線モデル• 典型的な64bit-FF駆動モデルを想定

・・・

４th Metal配線
64個パラレル駆動 Buffer

XC

XC
D

・・・

D

配線51ピッチ分（Scan Flip-flop with Set and Reset～Nangate 45nm Open Cell Library
からピッチを決定→32nm相当に変換）

-101-

XC
D

電源
1Metal+VDD:4Metal ＋
GND：4Metal30配線断面寸法・物理定数
配線断面寸法・物理定数• ITRS2007
Category Year of Production
DRAM ½ Pitch (nm) (contacted)
MPU/ASIC Metal 1 (M1) ½ Pitch (nm)Interlevel metal insulator – effective dielectric constant (κ)
Cu Temperature Coefficient of ResistanceOn-chip local clock frequency (MHz)Interconnects Metal 1 wiring pitch (nm)Metal 1 A/R (for Cu)
Metal 1 wiring width (nm)(Metal 1) Metal 1 wiring thickness (nm)Height (dielectric thickness) between Metal 1 and substrate (nm)Barrier/cladding thickness (for Cu Metal 1 wiring) (nm)Intermediate wiring pitch (nm)Intermediate wiring dual damascene A/R (Cu wire)Intermediate wiring dual damascene A/R (Cu via)
Intermediate wiring width (nm)(Intermediate) Intermediate wiring thickness (nm)Height (dielectric thickness) between Intermediate wiring levels (nm)Barrier/cladding thickness (for Cu intermediate wiring) (nm)
Cu thinning at minimum intermediate pitch
due to erosion (nm), 10% × height, 50% area density, 500 μm square array
Conductor effective resistivity (μΩ-cm)
Cu intermediate wiring including effect of width-dependent scattering and a conformal barrier ofthickness specified below

2013
32
32
εr
2.8
0.0044
f
7344
p
64
1.9
w
32
t
60.8
h
60.8
2.4
p
64
1.9
1.7
w
32
t
60.8
h
54.4
2.4
6
4.83

31

等価回路
等価回路

R1

R2
C1

・
・
・

• ITRS2007 32nmプロセスの配線寸法を代入、配線長から抵抗、電磁界解析で容量を算出• 上記を３Dモデルとして、熱解析を実施

R1
C64
32

-102-

物理構造パラメータの決定(1)
物理構造パラメータの決定(1)•

ドライバ・レシーバサイズ
レシーバ入力Inverter：
Scan FF CLK入力
NMOS:W/L=0.4μm/32nm,
PMOS:W/L=2.0μm/32nm
ドライバ出力Inverter：
64FF, および配線負荷を7.3GHzで駆動可能な寸法。
Rise/Fallの電流のピーク値が等しくなるよう
P/N間でゲート幅を調整
NMOS:W/L=25.6μm/32nm,
PMOS:W/L=128μm/32nm

33

物理構造パラメータの決定(2)物理構造パラメータの決定(2)• 配線：4M（Intermediate層）
配線幅：最小寸法×5 = 0.16μm→最遠方のFFを7.3GHzで駆動可能な最小寸法
隣接電源配線（幅/間隔= 0.16μm /32nm）

R1

R2
C1

・
・
・

配線容量 Ctotal=C1＋・・・＋C64
容量シミュレーション結果よりCtotal= 4.34e-14 F → C1=C2=・・・=C64= 6.77E-16 F
配線抵抗 Rtotal=R1+R2+・・・+R64= 1037 Ω→ R1=R2=・・・=R64= 16.2 Ω

R1
C64
34

-103-

配線断面寸法・物理定数
配線断面寸法・物理定数• 配線絶縁膜の熱伝導率導出
Step.1: SiO2にAirを混合した材質と仮定
Step.2: 比誘電率が等価になるように混合比を決定
Step.3: 求めた混合比に対する熱伝導率

SiO2
εr
熱伝導率
W/meter・k

Air

ITRS

4.2
1.38

1
0.02412.8
0.140935

ケース1
ケース1 解析結果
解析結果• 熱解析結果
最大温度差： 1.53℃ → 配線抵抗増加： 0.67%
1.8

1.00%

1.6

温度上昇
抵抗値増分

0.80%
0.70%

1.2

0.60%

1

0.50%
0.8

0.40%

0.6

抵抗増分

温度上昇（℃）

1.4

0.90%

0.30%

0.4

0.20%

0.2

0.10%

0

0.00%
1

5

9 13 17 21 25 29 33 37 41 45 49 53 57 61
ＦＦ No.

36-104-

ケース2:
ケース2: リピータ間配線
リピータ間配線• データ送受信のリピータ間配線→ 負荷容量:大 or 短距離
上層細配線
FF

FF
・
・
・
FF

・
・
・

・
・
・
FF

Data送受信CLK
37

物理構造パラメータの決定
物理構造パラメータの決定• 配線：4M（Intermediate層）
配線幅：最小寸法 = 32nm
隣接電源配線（幅/間隔= 32nm /32nm）
配線容量 Cwire = 1.644E-16 F/μm
配線抵抗 Rwire = 24.825 Ω/μm

Wire

Driver(P1)(P2)

Receiver
(P3)
38

-105-

物理構造パラメータの決定
物理構造パラメータの決定• 配線長、ドライバ・レシーバサイズ決定条件
1. ドライバ・レシーバは同一サイズ
2. ドライバ遅延+配線遅延=クロック周期の1/7 1)
3. ドライバ遅延と配線遅延の比:
1/8, 1/4, 1/2, 1, 2, 4, 8
（2. の条件を満たす範囲）• 配線モデル： 3段に分割し、電力見積り→熱解析→遅延時
間評価
Wire

Driver(P1)

Receiver

(P2)

(P3)
39

物理構造パラメータの決定
物理構造パラメータの決定• 単位Inverter諸元

Pmos(Unitサイズ)

ε0

Nmos(Unitサイズ)

8.85E-12

epsrox

F/m

ε0

3.9

8.85E-12

epsrox

F/m

3.9

cgso

8.50E-11

F/m

cgso

8.50E-11

F/m

cgdo

8.50E-11

F/m

cgdo

8.50E-11

F/m

cgbo

2.56E-11

F/m

cgbo

2.56E-11

F/m

toxm

1.75E-09m

toxm

1.65E-09m

L

3.20E-08m

L

3.20E-08m

W

9.00E-07m

W

4.00E-07m

Cgate

7.22E-16

F

Cgate

3.37E-16

F• Elmore遅延で求めたドライバ・レシーバサイズ、配線長
Td_drv/Td_wire
Driverサイズ
比)
配線長

1/8

1/4

1/2

1

2

4

8

(Unit

μm

22.4

7.2

3.6

2.0

1.2

0.8

0.5

26.8

52.5

59.7

57.1

48.9

38.8

29.3

40

-106-

ケース2
ケース2 解析結果
解析結果• 熱解析結果(1)
ドライバ遅延が配線遅延の1/8となるケースで配線自己発熱による温度差が最大（P1: 0.162℃）→ このケースに対し、当該配線を最小間隔で敷き詰めた状態で、熱解析をさらに実行（Data送受信配線64bit分並走を想定）
Tdriver/Twire比P1
P2
Power(W)
P3
Total
P1
⊿T(℃）
P2
P3

1/8
8.99E-06
8.34E-06
7.77E-06
2.51E-05
1.62E-01
1.49E-03
1.37E-03

1/4
2.76E-06
1.93E-06
1.37E-06
6.06E-06
2.60E-02
1.77E-04
1.25E-04

1/2
1.96E-06
1.16E-06
6.39E-07
3.76E-06
1.60E-02
9.37E-05
5.19E-05

1
1.45E-06
7.92E-07
3.65E-07
2.61E-06
1.30E-02
6.74E-05
3.11E-05

2
9.70E-07
5.13E-07
2.11E-07
1.69E-06
1.00E-02
5.04E-05
2.08E-05

4
6.00E-07
3.14E-07
1.23E-07
1.04E-06
8.00E-03
3.85E-05
1.50E-05

8
3.05E-07
1.57E-07
5.87E-08
5.21E-07
6.00E-03
2.53E-05
9.80E-06

41

ケース2
ケース2 解析結果
解析結果• 熱解析結果(2)最大温度差： 5.49℃ → 配線抵抗増加： 4.82%
Drv.入力－Ｒcv.入力
Tdriver/Twire
P1
Delay増加： 2.72%
Power(W)

⊿T(℃）

Wire

DriverReceiver
⊿R（Ω）

(P1)

(P2)

(P3)

1/8
8.99E-06

P2

8.34E-06

P3

7.77E-06

Total

2.51E-05

P1

5.49E+00

P2

1.10E+01

P3

5.49E+00

P1

2.41%

P2

4.82%

P3

2.41%

42

-107-

Summary
Summary•

配線の自己発熱（Self-heating）要考慮シチュエーションをスクリーニング• 32nmプロセスを想定した現実的な構造、物性値を使って配線伝播遅延へのインパクトを評価• 64bitのデータ送受信モデル
1) データ受信部のFF CLK配線→ 配線-基板間最大温度差 1.53℃、配線抵抗増加 0.53%
2) データ送受信のリピータ間配線→ 最大温度差 5.49℃、配線抵抗増加 4.82%→ Drv.入力－Rcv.入力Delayの増加： 2.72%

43

参考文献
参考文献
1)
2)
3)
4)
5)
6)

K. Shinkai, M. Hashimoto, T. Onoye, “Future Prediction of Self-heating in
Short Intra-block Wires, ” Proceedings of International Symposium on
Quality Electronic Design (ISQED), pp. 660-665, March 2007.
Semiconductor Industry Association,”International Technology Roadmap
for Semiconductors 2007 Edition,” 2007.
http://www.itrs.net/Links/2007ITRS/Home2007.htm
W. Zhao, Y. Cao, “New generation of Predictive Technology Model for sub45nm design exploration,” Proceedings of International Symposium on
Quality Electronic Design (ISQED), pp.585-590, March 2006.
Nangate Inc.,”45nm Open Cell Library,” http://www.nangate.com/
Radu Zlatanovici,” Power - Performance Optimization for Digital Circuits,”
EECS Department, U.C.Berkeley Technical Report No. UCB/EECS-2006164, December, 2006.
P.P. Sotiriadis, A.P. Chandrakasan, “A Bus Energy Model for Deep
Submicron Technology,” IEEE Transactions on VLSI Systems, Vol.10,
No.3, pp341-350, June 2002

44

-108-

3.
3. 配線ばらつきの表現手段の配線ばらつきの表現手段の
調査、検討
調査、検討

45

もくじ
もくじ
•

配線ばらつきのインパクト– 配線ばらつきの要因– ロジック回路性能への影響• 遅延• 電源ノイズ•

配線ばらつきを考慮した設計フロー– タイミング解析– クロストーク、Power解析•

Sensitivity SPEF標準化状況– Sensitivity SPEFフォーマット– IEEE標準化委員会の状況– 現フォーマットの課題

•

まとめ

46

-109-

配線ばらつきの要因
配線ばらつきの要因• リソグラフィー• エッチング• Copper Electroplating• CMP (Chemical-Mechanical Polishing)47

配線ばらつきの大きさ
配線ばらつきの大きさ
3σ／μ

250

180

130

100 70nm

S. Nassif, “Delay Variability: Sources, Impacts and Trends” ISSCC 2000.
48

-110-

配線ばらつきのロジック回路への影響
配線ばらつきのロジック回路への影響• 遅延• クロストークノイズ• 電源ノイズ• 消費電力49

配線ばらつきの信号伝播遅延への影響(1)配線ばらつきの信号伝播遅延への影響(1)Nassifの予測

S. Nassif, “Delay Variability: Sources, Impacts and Trends” ISSCC 2000.
50

-111-

配線ばらつきの信号伝播遅延への影響(2)配線ばらつきの信号伝播遅延への影響(2)DMD研究会の予測(2002)

世代によらず一定’05, ’08, ’11=100, 70, 50nm

51

配線ばらつきの電源ノイズへの影響
配線ばらつきの電源ノイズへの影響• ばらつきパラメータ： 配線W, T, デバイスWd, Vth (3σ/μ=30%)→ ノード電圧のσ=15～28%• ばらつきパラメータ： デバイスVth (3σ/μ=30%)→ ノード電圧のσ=10～20%
P. Ghanta et. al. “Analysis of Power Supply Noise in the Presence of Process Variation”, IEEE Design& Test of Computers, 2007.
52

-112-

配線ばらつきを考慮したLSI設計
配線ばらつきを考慮したLSI設計• 配線ばらつき情報(SSPEF)を用いた設計フロー– タイミング解析• Statistical STA• 従来フローの延長（STA）– クロストーク、Power解析

53

タイミング解析
タイミング解析• Statistical STAに使用
デザインデータ
ライブラリ
ばらつき
パラメータ

NetlistTiming制約

SSPEF

レイアウト
情報

Sensitivity
パラメータ

SSTA対応セルlibrary

SSTAツール

RC Sensitivity抽出

Timingレポート
Prob.
TimingViolation

0

Slack

54

-113-

タイミング解析
タイミング解析• 従来フローの延長– 従来：コーナー条件毎にSPEFを作成– SSPEFからコーナーSPEFを生成• RC抽出の実行回数が低減できる
レイアウト
情報

RC抽出

RC抽出

SPEF
(corner #1)

SPEF(corner #2)

…

レイアウト
情報

SSPEF

RC抽出

RC抽出

変換

変換

SPEF
(corner #n)

SSPEF

SPEF
(corner #1)

SPEF(corner #2)

…

変換

SPEF
(corner #n)

55

クロストーク、Power解析
クロストーク、Power解析• RC値に関して、コーナー条件での値ではなく統計的に処理– ツールの対応が必要– クロストーク解析• Critical Path解析に活用– 配線ばらつきを考慮したインクリメンタルSDF– Glitchエラー緩和への利用– Power解析• より実chipに近いPower見積り値• EM、IR-Drop解析時に適用し、marginの取り過ぎを防止
56

-114-

Sensitivity-SPEF
Sensitivity-SPEF フォーマット
フォーマット
W/T/H Variation (VC) W/T/H Mean (NF)
*VARIATION_PARAMETERS
0 M2_W N D X 0.0330000 0.600000
1 M2_T N D X 0.0670000 0.700000

param_id param_name param_type_for_cap param_type_for_res
param_type_for_induc var_coeff normalization_factor:*D_NET RCXX_NET1 122.995:*CAP
1 RCXX_NET1:24 RCXX_NET2:48 0.0235753 *SC 0:0.497 1:0.445
2 RCXX_NET1:24 RCXX_NET2:49 2.17010 *SC 0:0.436 1:0.387:*RES

Sensitivities (cnj)

Cap Mean (C0)1 RCXX_NET1:24 RCXX_NET1:23 16.5000 *SC 0:0.375 1:1.000

Param_type: N (numerator), D (denominator) or X (not applicable).

57

Sensitivity
Sensitivity SPEF標準化
SPEF標準化• IEEE標準化委員会状況– IEEE Std. 1481-1999 Standard Parasitic Exchange Format に配
線ばらつきに関する記述を追加(SSPEF)– 現在、最終ドラフト作成完了、投票前レビュー中– 最終ドラフト版をNPD-WGとして正式に入手、ML参加• NPD今後のアクション– IEEE最終ドラフト版に至った背景調査– 現状フォーマットの課題調査– ドラフト版に対する修正提案– SSPEFの適用方法検討・提案

58

-115-

SSPEFの課題
SSPEFの課題• ばらつきパラメータとRLCの関係式は、比例もしくは反比
例のみ表現可能• 正側負側非対称なばらつきの表現不可
R-1

C
-3σ

T

T

-3σ

+3σ

SSPEF model
Physical model+3σ• D2D（W2W,L2Lを含む）成分のみ表現可能
R• WID成分の表現不可
On-chip randomvariation
Net(i)• 距離依存、配線層間等、パラメータ間相関係数の定義不可

H2
metal2

T2
H1

metal1

T1

59

まとめ
まとめ
•

微細化に伴いLSI性能に与える配線ばらつきは増大している。配線
ばらつきを精度よくモデル化し解析に用いなければ、過剰/過小設計を強いられることになる。

•

配線ばらつきを反映した設計フローとしては、SSTAに代表されるタイ
ミング解析、クロストーク解析、Power解析等が想定される。

•

主要な配線ばらつきの表現フォーマットとしては、Sensitivity SPEFをIEEEで標準化作業中。 Sensitivity SPEFでは、配線のRLCに対するばらつきパラメータ感度が表現可能。

•

ただし、 Sensitivity SPEFはまだ実用実績はなし。ばらつき表現上の課題もあり。今後、適用方法、および次期改訂に向けたばらつき表
現上の改善提案を行う予定。

60

-116-

61

-117-

4.2 SystemCワーキンググループ
２００８年度活動報告
JEITA EDA技術専門委員会
標準化小委員会

SystemCワーキンググループ© Copyright 2009 JEITA, All rights reserved

SystemCワーキンググループメンバー
主査
副主査
委員

客員

長谷川 隆 （富士通ﾏｲｸﾛｴﾚｸﾄﾛﾆｸｽ）
今井 浩史 （東芝）
中西 早苗 （NECエレクトロニクス）
小島 智（NECシステムテクノロジ）
清水 靖介 （ﾛｰﾑｸﾞﾙｰﾌﾟ・OKIｾﾐｺﾝﾀﾞｸﾀ）
逢坂 孝司 （ケイデンス）
長尾 文昭 （三洋半導体）
西園寺 修（シノプシス）
柿本 勝（ソニー ）
竹村 和祥 （パナソニック）
牧野 潔（メンター）
大島 良紀 （ルネサステクノロジ）
長谷川 裕恭 （HD LAB）
東島 清宏 （CoWare）
今井 正治 （大阪大学）（計15名）© Copyright 2009 JEITA, All rights reserved

-118-

2

目次
4.2.1 SystemCワーキンググループ概要
SystemCとは
 SystemCワーキンググループについて
 SystemCワーキンググループの活動 これまでの成果と本アニュアルレポートでの報告内容


4.2.2 TLM 2.0 ユーザマニュアルの日本語要約
4.2.3 TLM 2.0 補足解説
4.2.4 TLM 2.0のOSCIへのフィードバック
4.2.5 SystemC推奨設計メソドロジ 2008年度版
4.2.6 SystemCユーザフォーラム2009開催報告© Copyright 2009 JEITA, All rights reserved

3

4.2.1 SystemCワーキンググループ
概要© Copyright 2009 JEITA, All rights reserved

-119-

4

SystemC とは


C++言語をベースとした、システムレベル設計言語の代表的な言語である
Open SystemC Initiative (OSCI)という標準化組織により、言語仕様(LRM)とリファレンスシミュレータが策定され、無償提供されている
http://www.systemc.org/

2005年12月に、 SystemC 2.1のLRMがIEEE Std. 1666として標準化された
現在は合成サブセットやTLM(Transaction Level Modeling)の標準化案が検討されている

C++の文法を保持したまま、クラスライブラリの形で以下のような言語拡張がなされている

並列動作を可能とするシミュレーションエンジン(クロック、イベント、等)
抽象化された通信手段(Channels, Interfaces)
ハード実装に必要なデータタイプ (固定小数点、固定長ビット、等)
0, 1, Z, X 等の信号値等© Copyright 2009 JEITA, All rights reserved

5

SystemCの標準化の階層
ユーザ

OSCI

ユーザレイヤTLM 1.0

TLM 2.0

AMS

合成
サブセット

SCV 標準1.0

IEEEへ移管予定

Std.1666-2005 SystemC コア言語定義
IEEE

基本チャネル Signal, Timer, Mutex, Semaphore, FIFO, etc.
基本言語 Modules, Ports, Events,
Interfaces, Channels, Processes,…

データタイプ Logic Type (01XZ), Logic/ Bit
Vectors, Arbitrary Precision Integers, .

C++ 言語標準ANSI

OSCI資料(2007)に加筆© Copyright 2009 JEITA, All rights reserved

-120-

6

SystemCワーキンググループについて


設立と名称変更
2003年10月に、JEITA EDA技術専門委員会 標準化小委員会内にSystemCタスクグループとして設置(SystemVerilogタスクグループと同時) 2007年4月度よりSystemCワーキンググループに名称変更して活動
継続




目的
日本国内における唯一のSystemCの標準化関連組織として、OSCIやIEEE P1666ワーキンググループと連携しつつ、日本国内の事情・要求事項を取り込むべくSystemCの国際標準化を進めていく。
 SystemCに関連した調査結果を積極的に情報発信を行うことで、国内普及を図る。これらにより日本の産業界の国際競争力を高めることを目指す。
© Copyright 2009 JEITA, All rights reserved

7

SystemCワーキンググループの活動
SystemC ワーキンググループ
TLMサブグループ
合成サブグループ

2003
これまでの歩み SystemCユーザ・フォーラム
 SystemC動向調査
 OSCI LRMレビュー
 IEEE P1666 WG 標準化活動
 SystemC 2.1調査
 SystemC-SystemVerilog共通辞書
 合成サブセットレビュー
 動作合成スタイルガイド構成要件
 TLM標準化(レビュー) SystemC推奨設計メソドロジ© Copyright 2009 JEITA, All rights reserved-121-

2004 2005 2006 2007 20088

これまでの活動内容と主な成果
SystemC標準化活動









SystemC技術調査










IEEE P1666 WGに投票権のあるメンバーとして参加し、SystemC言語仕様書のレビューにて50件以上の改善提案によりIEEE Std. 1666-2005の策定に貢献(2005年度)
OSCI動作合成サブセットdraft、TLM2.0 draft1に対するレビューを実施し、OSCIへフィードバックを提出。
TLM 2.0 draft2のレビューを実施し、OSCIへ10件のフィードバックを提出した(説明不足７件、例題追加要望３件) (2007年度)
2008年6月にリリースされたTLM 2.0正式版ユーザマニュアルのレビューを実施し、OSCIへ7件のフィード
バックを提出。レビュー作業の過程を日本語抄訳としてまとめ、本アニュアルレポートに掲載(2008年度)

2000年～2005年度における国内外でのSystemCの利用状況について調査を実施
SystemC 2.1について調査を行い、その特長を日本語で紹介(2005年度)
国内外におけるTLM(Transaction Level Modeling)の利用状況調査を実施(2006-2007年度)
OSCIより公開されている合成サブセットのドキュメントのレビュー及び抄訳の作成を実施(2006年度)
SystemC動作合成ガイドライン構成要件の検討と、ガイド準拠のドキュメントのレビュー(2007年度)
SystemC推奨設計メソドロジの検討を行い、合成編について審議完了(2007年度)
SystemC推奨設計メソドロジの総合編の検討・レビューを行い審議完了し、本アニュアルレポートに掲載(2008年度)

SystemC普及活動


SystemCユーザフォーラムを開催し、積極的に情報発信を行いSystemCを利用した設計の普及をはかる
SystemC Japan 2007にてこれまでの活動成果を講演(2007年度)
JEITA EDA-TCのWEBページを活用し、これまでの活動成果を一挙掲載(2007年度)
http://eda.ics.es.osaka-u.ac.jp/jeita/eda/index-jp.html© Copyright 2009 JEITA, All rights reserved

92008年度報告資料について
4.2.2 TLM 2.0 ユーザマニュアルの日本語要約

OSCI TLM-2.0 User Manual (JA22)の日本語抄訳

4.2.3 TLM 2.0 補足解説
TLM 2.0 Draft2からの変更点について解説

4.2.4 TLM 2.0 のOSCIへのフィードバック


OSCI へ提出した TLM2.0 における改善要望

4.2.5 SystemC推奨設計メソドロジ 2008年度版
推奨設計メソドロジとしてSystemCの効果的な使い方を提案

4.2.6 SystemCユーザフォーラム2009開催報告SystemCユーザフォーラムの開催報告とアンケート結果© Copyright 2009 JEITA, All rights reserved

-122-

10

4.2.2 TLM 2.0 ユーザ・マニュアルの日本語抄訳
本節は、OSCI の TLM2 USER MANUAL Software version: TLM-2.0、Document version: JA22 を日本語抄訳したものである。
1. あらまし• TLM-2.0 の内容

TLM-2.0

コア・インタフェース
ブロッキング/ノンブロッキング・トランスポート・インタフェース
ダイレクト・メモリ・インタフェース（DMI）
デバッグ・トランスポート・インタフェース

イニシエータ/ターゲット・ソケット
汎用ペイロード
メモリ・マップ・バスの抽象モデリング
メモリ・マップド・バスの抽象モデリング
特定のバス・プロトコルのための拡張メカニズム
相互利用性の最大化

基本プロトコル
解析インタフェースとポート
TLM-1.0コア・インタフェース• TLM-2 クラス

相互利用性を最大にするため、このレイヤーのクラスを使用することを推薦

ユーティリティ、解析ポート/インタフェースの使用は厳密には必要ではないが、スタイルの一貫性を保つ
ためTLM-2.0標準に入れる。

• 汎用ペイロード— メモリ・マップド・バスのモデリングを主なターゲット（非バス・プロトコルにも使用可能）とする。
— アトリビュート、フェーズは拡張可能（特定なプロトコルをモデリングするため）。
• 相互利用性を阻害するので使用には注意が必要。
• コーディング・スタイル- 123 -

— モデルとスタイルの関係• ルーズリー・タイムド・モデル ⇒ ブロッキング・トランスポート・インタフェース、DMI、
テンポラル・デカップリング• アプロキシメイトリー・タイムド・モデル ⇒ ノンブロッキング・トランスポート・イン
タフェース、ペイロード・イベント・キュー
上記は推奨される使い方であるが、これらに限定される訳ではない。
1.1 スコープ• このドキュメントの焦点— TLM-2 コア・インタフェースとクラスのキー・コンセプトとセマンティクスである。
• TLM-1 コア・インタフェースをリストアップするがそのセマンティクスを定義はしない。
• 言語リファレンス・マニュアルではない。
• TLM-2.0 を如何に使うかといった、より実践的なガイドラインを追加していくつもりである。
1.2 ソースコードとドキュメント• TLM-2.0 リリースのディレクトリ構造
include/tlm/
include/tlm/tlm_h/tlm_req_rsp
include/tlm/tlm_h/tlm_req_rsp/tlm_1_interfaces
include/tlm/tlm_h/tlm_req_rsp/tlm_channels
include/tlm/tlm_h/tlm_req_rsp/tlm_ports
include/tlm/tlm_h/tlm_req_rsp/tlm_adapters
include/tlm/tlm_h/tlm_transinclude/tlm/tlm_h/tlm_trans/tlm_2_interfaces
include/tlm/tlm_h/tlm_trans/tlm_generic_payload
include/tlm/tlm_h/tlm_trans/tlm_sockets
include/tlm/tlm_h/tlm_quantum
include/tlm/tlm_h/tlm_analysis
include/tlm/tlm_utils
docs
examplesunit_test:ソースコード、readme ファイル、リリース・ノート:TLM-1 標準:TLM-1 コア・インタフェース:TLM-1 fifo、req-rsp チャネル
:TLM-1 ノンブロッキング・ポート、イベント・ファインダー
:TLM-1 スレーブ-トランスポート、トランスポート-マスタ・ア
ダプタ:TLM-2 相互利用性クラス:TLM-2 コア・インタフェース:TLM-2 汎用ペイロード:TLM-2 ソケット
:TLM-2 グローバル・クォンタム:TLM-2 解析インタフェース、ポート:TLM-2 ユーティリティ・クラス
:ドキュメント（ユーザ・マニュアル、ホワイト・ペーパー、
Doxygen）:コード例:リグレッション・テスト

2. リファレンス
• 本標準は以下の文書とともに使用すること。
— ISO/IEC 14882:2003, Programming Languages—C++— IEEE Std 1666-2005, SystemC Language Reference Manual— Requirements Specification for TLM 2.0, Version 1.1, September 16, 2007
2.1 参考文献• Transaction-Level Modeling with SystemC, TLM Concepts and Applications for Embedded
Systems, edited by Frank Ghenassia, published by Springer 2005, ISBN 10 0 387-26232-6(HB),
ISBN 13 978-0-387-26232-1(HB)• Integrated System-Level Modeling of Network-on-Chip enabled Multi-Processor Platforms,
by Tim Kogel, Rainer Leupers, and Heinrich Meyr, published by Springer 2006, ISBN 10
1-4020-4825-4(HB), ISBN 13978-1-4020-4825-4(HB)• ESL Design and Verification, by Brian Bailey, Grant Martin and Andrew Piziali, publishedby Morgan Kaufmann/Elsevier 2007, ISBN 10 0 12 373551-3, ISBN 13 978 0 12 373551-5
3. イントロダクション
3.1 背景• TLM-1 標準は、メモリ・マップド・バス、オンチップ・コミュニケーション・ネットワークをモデリングする上で 3 つの欠点がある。
欠点
TLM2 での解決
トランザクション・クラスの標準が無い。
汎用ペイロード- 124 -

タイミング・アノテーションをサポートしな
ブロッキング/ノンブロッキング・トランス
い。
ポート・インタフェースでのタイミング・ア（モデル間でタイミング情報を交換する標
ノテーション
準的方法がない。wait 文で遅延を実装する。）
トランザクション・オブジェクトが幾つかのトランザクションを値もしくは参照渡しす トランスポート・コールに渡る仕組み（新しいトランスポート・インタフェースがサポーる。
ト）
3.2 トランザクション・レベル・モデリング、ユースケース、抽象度• 分類法を変更— ユースケースに応じた抽象度を定義する代わりに、インタフェース（API）とコーディング・
スタイルを区別するといアプローチをとる。
— 様々なユースケースに適するコーディング・スタイルを説明する。
• TLM-2 インタフェースは、相互利用性を保証する。
• 各コーディング・スタイルは様々な抽象度をサポートできる。
• アンタイムド機能モデル（アルゴリズム・モデル）— 唯一つの SystemC プロセスからなる。
— トランザクション・レベルではない（プロセス間の通信がないから）。
• トランザクション・レベル— 複数のプロセスから成る。
— 他のプロセスへ制御を譲渡する仕組み（wait 文）。
— 強い同期と弱い同期• 強い同期：一連のコミュニケーションがあらかじめ正確に決まっている。
FIFO、セマフォで実現可能。これは完全なアンタイムド・モデリング・スタイルなので、TLM-2.0 の範囲外。
• 弱い同期：一連のコミュニケーションが個別のプロセスの詳細タイミングで部分的に決まる。
• ルーズリー・タイムド・コーディング・スタイル— 複数の組込みソフトウェア・スレッドの並列実行を許すバーチャル・プラットフォーム・モ
デルは、強い、もしくは、弱い同期を使う。このモデルに適したスタイル。
• アプロキシメイトリー・タイムド・コーディング・スタイル— プロトコル固有の複数のタイミング・ポイント（プロトコルの各フェーズの開始・終了のタ
イミング等）をトランザクションに関連付けるためには、より詳細なトランザクション・レ
ベル・モデルが必要なケースがある。適切なタイミング・ポイントを選ぶことにより、コン
ポーネント・モデルをクロック精度で動作させることなくタイミング精度の高いコミュニケーションをモデリング可能。このようなコーディング・スタイル。

- 125 -

3.3 コーディング・スタイル• 本ドキュメントでは、2 つのコーディング・スタイルについてのみ詳しく述べる。
— ルーズリー・タイムド— アプロキシメイトリー・タイムド• コーディング・スタイルは厳密に定義されるわけではない。
• TLM-2 コア・インタフェースを律するルールはコーディング・スタイルとは別に定義される。
3.3.1 アンタイムド・コーディング・スタイル• アンタイムド・コーディング・スタイルは規定しない。
— 現代のバス・ベース・システムは組込みプロセッサ上で動作するソフトウェアをモデリングするため、何らかのタイミングの概念が要求される。
• アンタイムド・モデリングは TLM-1 コア・インタフェースでサポートされる。
3.3.2 ルーズリー・タイムド・コーディング・スタイルとテンポラル・デカップリング• ブロッキング・トランスポート・インタフェースを使用。
— 2 つのタイミング・ポイント（トランスポート関数コールと戻り）• リクエスト開始とレスポンス開始にゆるく対応。
• 同じシミュレーション時刻でも、異なる時刻でも良い。
• ユースケース：SW 開発（マルチ・プロセッサのバーチャル・プラットフォーム・モデル）— タイマーと割込みのモデリングをサポート（OS ブートとコード実行に十分）。
• 特徴：テンポラル・デカップリング• テンポラル・デカップリングをサポート— モデルは他モデルとの同期ポイントに到達するまで自分のローカル時間を先行して実行可能。
• 各プロセッサは次のプロセッサが実行される前に、ある時間（クォンタム）だけ実行— ⇒高速なシミュレーション• スケジューリングのオーバーヘッド低減。
• SystemC スケジューラからの考察— イベントが発生する時刻まで時間を進め、その時刻で動作すべきプロセスを実行。
— プロセスの実行が終了すると、シミュレーション・カーネルに制御が返る。
— モデルが詳細だと、イベント・スケジューリングとプロセスのコンテクスト・スイッチのオーバーヘッドがシミュレーション速度の支配的要因となる。
— ⇒シミュレーション高速化の一つの方法： 現在時刻に先行してプロセスを実行すること。
• テンポラル・デカップリング- 126 -

• テンポラル・デカップリングの実装— プロセスは、以下の 2 つの外部依存のケースに出会うまで時刻を先行して実行可能。このとき、現状の値を受け入れて実行継続か、シミュレーション・カーネルに制御を返す。
• 他プロセスにより値を書きかえられる変数に依存• 他プロセスと情報交換— 2 つの対処法• 同期を強制（シミュレーション時間に追いつくまで他のプロセスに制御を譲渡 = 標準のSystemC シミュレーション・セマンティクス）。
• 現在の値を受入れ、実行継続（値の早期サンプリングがダメージを与えない、以降の値変化は以降のプロセス実行中で取込まれると仮定。ソフトウェア・スタックがハードウェアの詳細タイミングに依存しないバーチャル・プラットフォーム・モデルではこの仮定が成り立つ）。
• クォンタム— 制限なしにシミュレーション時刻を先行してプロセスが実行 ⇒ SystemC スケジュール動作
しない ⇒ 他プロセスは決して動作しない。
— ⇒グローバル・クォンタムで制限。
• 先行実行の上限を設定。
• アプリケーションが設定。
• シミュレーション速度と精度のトレードオフ
小さすぎる値 ⇒ 低速。制御の譲渡と同期が頻繁。
大きすぎる値 ⇒ システム機能停止。タイミングの一貫性が保てない。
• 例：プロセッサ、メモリ、タイマー、低速なペリフェラルから構成されるシステム。
— ソフトウェアはその実行時間の大半をメモリからの命令のフェッチと実行に費やし、システ
ムの残りとはタイマーからの割込み（例えば、1 ms 毎）が発生したときのみ情報交換。
— ISS モデルは 1 ms のクォンタムまで先行実行可能（メモリ・モデルには直接アクセスし、タ
イマー割込みでペリフェラルとのみ同期）。この間は他のハードウェア・モデルのクロックにロックされる必要なし。
— 1000 倍のスピード・アップが可能。
• テンポラル・デカップリングしたモデル、しないモデルが混在する場合、テンポラル・デカッ
プリングしないモデルがシミュレーションスピードのボトルネックになる可能性が高い。
• TLM-2 でのサポート— テンポラル・デカップリング• ↑ tlm_global_quantum クラス、ブロッキング/ノンブロッキング・トランスポートのタイ
ミング・アノテーション— グローバル・クォンタム• ↑ tlm_quantumkeeper ユーティリティ・クラスによるアクセス
3.3.3 ルーズリー・タイムド・モデルの同期• アンタイムド・モデル— 明示的同期ポイント（wait 文、ブロッキング・メソッドのコール）• ルーズリー・タイムド・モデル— 明示的同期 ⇒ 予測可能な実行を保証— イニシエータはクォンタムが終了するまで先行実行可能（明示的同期ポイントなし）— 要求ベース同期（クォンタム終了前にスケジューラへ制御を譲渡） ⇒ タイミング精度向上• タイム・クォンタム・メカニズム— 正確なシステム同期を保証するためのものではない。
— スケジューラの仕組みに基づいたシミュレーション環境で、複数イニシエータが動作する仕組みを提供。
— システム・レベルでの明示的同期スキームを設計するための仕組みではない。
3.3.4 アプロキシメイトリー・タイムド・コーディング・スタイル• インタフェース：ノンブロッキング・トランスポート・インタフェース— タイミング・アノテーション— 複数フェーズ
— トランザクションのライフタイム中のタイミング・ポイント- 127 -

• ユースケース：アーキテクチャ探索、性能解析• トランザクションのフェーズ— 4 つのタイミング・ポイント• リクエストの開始と終了、レスポンスの開始と終了— 特定プロトコルでは、タイミング・ポイントの追加が必要なケースあり ⇒ 汎用ペイロードとの相互利用性が失われる。
— 2 つのタイミング・ポイント（トランザクションの開始と終了）も可能だが、ルーズリー・
タイムド・モデルでは、ブロッキング・トランスポート・インタフェースの使用が望ましい。
• アプロキシメイトリー・タイムド・モデルの特徴— テンポラル・デカップリングを使わない（要求されるタイミング精度のため）。
— プロセスの情報交換に 2 種類のディレイをアノテート。
• ターゲットのレイテンシ。
• ターゲットの開始間隔（アクセプト・ディレイ）• wait(delay)もしくは notify(delay)で実装。
3.3.5 ルーズリー・タイムドとアプロキシメイトリー・タイムド・コーディング・スタイルの特徴• コーディング・スタイルはタイミング・ポイントとテンポラル・デカップリングで特徴付けられる。
テンポラル・デカップリング
タイミング・ポイント（タイミング制御）使用。
プロセスは先行実行した時
2つ間情報を持つ。
ルーズリー・タイムド（トランザクション開始と明示的同期ポイント、クォン
終了）
タムを使いきったら制御を譲渡。
SystemC スケジューリング・
セマンティクスに従う。
プロセス間の情報交換時にアプロキシメイトリー・タイ 4 つ
ディレイとアノテート。
ムド（基本プロトコル）
wait(delay)、notify(delay)
で実装。
明示的に予め決定されている同期ポイントで制御を譲
アンタイムドなし
渡。
3.3.6 ルーズリー・タイムドとアプロキシメイトリー・タイムド・コーディング・スタイル間の切換え• シミュレーション中にモデルのルーズリー・タイムド・コーディング・スタイルとアプロキシ
メイトリー・タイムド・コーディング・スタイル間のスイッチが可能。
• 利用例— ルーズリー・タイムド・レベルでリセットとブートを高速に実行し、興味のあるステージに到達したら、より詳細な解析をするためアプロキシメイトリー・タイムド・モデリングへスイッチする。
3.3.7 サイクル精度モデリング• 現時点では TLM-2 の範囲外
— TLM-1 でモデリング可能。
— 標準化は未解決の課題（将来の OSCI 標準ではカバーされるかもしれない）• 原理的には、アプロキシメイトリー・タイムド・コーディング・スタイルに含まれるように拡張可能と思われる。
— 適切なフェーズとルールの定義により。
— TLM-2.0 リリースはこれに十分な機構が含まれるが、詳細はまだ詰められていない。
3.3.8 ブロッキングとノンブロッキング・トランスポート・インタフェースの対比• 異なるタイミング・レベルをサポートする別個のインタフェース- 128 -

・トランザクションの開始と終了をモデリング可能。
・1 回の関数コールでトランザクションを完了。
・トランザクションを複数のタイミング・ポイントへ分割。
ノンブロッキング・1 回のトランザクションを完了するのに複数の関数コールが必要。
• 相互利用性：1 つのインタフェースにまとまっている。
— コーディング・スタイルに従って、ブロッキング、ノンブロッキングのいずれか、もしくは、両方を使用。
— TLM-2 トランスポート・インタフェースを提供するモデルは、相互利用性を最大にするため、ブロッキングとノンブロッキングの両方を提供すること（実装はかならずしも必要ない）。
• 便利ソケット— ブロッキング → ノンブロッキング、ノンブロッキング → ブロッキングのトランスポー
ト・コール変換を提供。
— 変換にコストがかかる（特に、ノンブロッキング → ブロッキング変換）• アプロキシメイトリー・タイムド・モデルがシミュレーション時間を支配しているので、このコスト・オーバーヘッドはおそらく緩和される。
• トランスポート・コールの混在と順序のルール— イニシエータは動的にブロッキング、ノンブロッキングのどちらをコールするか選べる。
— 本標準には、同じターゲットへのブロッキング/ノンブロッキング・トランスポート・コールの混在と順序のルールが含まれる。
• 各トランスポート・インタフェースの強み
・コーディング・スタイルが単純（1 回の関数コールでトランザクシ
ョンが完了）。
ブロッキング・テンポラル・デカップリングを有効に利用可能。
・複数タイミング・ポイントのサポート。
ノンブロッキング（テンポラル・デカップリングも可能だが、・複数タイミング・ポイ
ントのサポートがテンポラル・デカップリングの利点を無効化。）
3.3.9 ユースケースとコーディング・スタイル
ユースケースコーディング・スタイル
ソフトウェア・アプリケーション開発
ルーズリー・タイムド
ソフトウェア・パフォーマンス解析
ルーズリー・タイムド
ルーズリー・タイムド
ハードウェア・アーキテクチャ解析
アプロキシメイトリー・タイムド
アプロキシメイトリー・タイムド
ハードウェア・パフォーマンス検証
サイクル精度
アンタイムド（検証環境）
ハードウェア機能検証
ルーズリー・タイムド
アプロキシメイトリー・タイムド
3.4 イニシエータ、ターゲット、ソケット、ブリッジ• コンポーネントの種類
トランザクションを開始
・トランザクション・オブジェクトを生成。
イニシエータ・コア・インタフェースの 1 つのメソッドをコールしてトランザク
ション・オブジェクトを渡す。
トランザクションの最終目的地
・ライト・トランザクションでは、イニシエータ（プロセッサ）がターゲット（メモリ）にデータを書き込む。
ターゲット
・リード・トランザクションでは、イニシエータがターゲットからデータを読む。
イ ン タ ー コ ネ ク イニシエータもしくはターゲットとして振舞う
ト・コンポーネント ・例：アービタ、ラウター• トランザクションのライフタイム①イニシエータがトランザクション・オブジェクトを生成。
ブロッキング- 129 -

②フォワード・パス• アービタのようなインターコネクト・コンポーネントが実装するトランスポート・インタ
フェース・メソッドに渡される。
• インターコネクト・コンポーネントで、さらにトランスポート・メソッド（ラウターのような 2 番目のインターコネクト・コンポーネントで実装）に渡される。
• 2 番目のインターコネクト・コンポーネントで、さらにトランスポート・メソッド（メモリにようなターゲットで実装）に渡される。
③ターゲットでトランザクションが処理される。
④イニシエータへトランザクション・オブジェクトを返す（ノンブロッキング・トランスポー
ト・メソッドの返り値により決まる）。
(1)メソッド・コールの返り値 ＝ リターン・パス(2)逆方向のメソッド・コール ＝ バックワード・パス• フォワード・パスとバックワード・パス• 汎用ペイロードを使用するとき、フォワード・パスとバックワード・パスはコンポーネントとソケットの同じ組（もしくは逆向き）を通る。

• ソケット— フォワード・パスとバックワード・パスをサポートするため、ポートとエクスポートが要求- 130 -

される。
インタフェース・メソッド・コール
フォワード・パス
バックワード・パス
イニシエータポート
エクスポートターゲット
エクスポートポート— イニシエータは、少なくとも 1 つのイニシエータ・ソケットを持つ。
— ターゲットは、少なくとも 1 つのターゲット・ソケットを持つ。
— 異なるトランザクション・タイプを転送するコンポーネントはいくつかのソケットを持つ。
• イニシエータとターゲットの役割。
• TLM-2 トランザクション間のブリッジ。
• バス・ブリッジのモデリング方法(1)インターコネクト・コンポーネント• 1 つのトランザクション・オブジェクトのポインタを渡す。 ⇒ シミュレーション高速化に適する。
(2)TLM-2 トランザクションのブリッジ• トランザクションをコピー。
• 別のアトリビュートを付加できる（より柔軟）。
• TLM-2 ソケットの使用を推薦— 相互利用性を最大化— 便利— 一貫性を持つコーディング・スタイル
3.5 DMI とデバッグ・トランスポート・インタフェース• ターゲットの持つメモリへの直接アクセス、デバッグ・アクセスを提供するインタフェース。
• インターコネクト・コンポーネントを通る通常のパスをバイパス。
インタフェース
目的
提供するパス・フォワード・パス
ルーズリー・タイムド・シミュレーシ（イニシエータ→ターゲット）
ョンでの通常のメモリ・トランザクシ
DMI
・バックワード・パス
ョンの高速化。
（ターゲット→イニシエータ）
デバッグ・トラ 通常のトランザクションに付随するデンスポート・イ ィレイ、副作用を引き起こさないデバ ・フォワード・パス
ッグ・アクセスを提供。
ンタフェース
3.6 統合インタフェースとソケット
ソケット
提供するインタフェース
・ブロッキング・トランスポート・インタフェース
・ノンブロッキング・トランスポート・インタフェース
イニシエータ・DMI
ターゲット・デバッグ・トランスポート・インタフェース• 4 つのインタフェースと汎用ペイロード• ⇒ TLM-2 標準を使ったモデルの相互利用性を保証• ターゲット・ソケット— 4 つのインタフェースを提供 ⇒ 事実上、すべてを実装• ブロッキング⇄ノンブロッキング変換の用意があれば、両方実装する必要なし。
• モデルのスピードと精度の要求に応じてどちらかを実装してもよい。
— イニシエータは、スピードと精度の要求に応じて、コア・インタフェースのどのメソッドをコールしてもよい。
• コーディング・スタイルは適切なインタフェースの選択のガイドとなる• 典型例
コーディング・スタイル
インタフェース（イニシエータ）
ソケット- 131 -

ルーズリー・タイムド
アプロキシメイトリー・タイムド・ブロッキング・トランスポート
・DMI
・デバッグ
・ノンブロッキング・トランスポート
・デバッグ

3.7

ネームスペース
namespace
クラス
tlm
メモリ・マップド・バスのモデリング用の相互利用インタフェースのクラス
ユーティリティ・クラス
tlm_utils（相互利用性には必ずしも必要ではないが、TLM-2 標準の一部）
3.8 ヘッダー・ファイルとバージョン• アプリケーションは、以下のヘッダー・ファイルをインクルードすること。
— include/tlm 下の tlm.h— include/tlm/tlm_utils 下のヘッダー・ファイル（ユーティリティ・クラスを使用する場合）• 最新版の OSCI シミュレータを使用する場合は、を SystemC ヘッダー・ファイルをインクルードする前に、SC_INCLUDE_DYNAMIC_PROCESSES マクロを定義すること。
• include/tlm/tlm_h/tlm_version.h はマクロと OSCI TLM-2 ソースコードのバージョン・ナンバ
ーの定数を含んでいる。アプリケーションはこれらを使ってもよい。
— tlm_release メソッドは、sc_core::sc_release メソッドが返すのと同じフォーマットの文字列を返す。
4. TLM-2 コア・インタフェース
TLM-1 からのコア・インタフェースに加えて、TLM-2 ではブロッキングとノンブロッキングのトラ
ンスポート・インタフェース、ダイレクト・メモリ・インタフェース(DMI)、およびデバッグ用トランスポート・インタフェースが追加される。
4.1 トランスポート・インタフェース
トランスポート・インタフェースはイニシエータとターゲット、そしてインターコネクト・コン
ポーネントの間のトランザクションを転送するのに使用される主要なインタフェースである。ブ
ロッキング及びノンブロッキングのトランスポート・インタフェースの両方ともタイミング・ア
ノテーションとテンポラル・デカップリングをサポートするが、ノンブロッキング・トランスポート・インタフェースだけがトランザクションのライフタイム中の複数フェーズをサポートする。
ブロッキング・トランスポートは明示的なフェーズ引数を持たず、ブロッキング・トランスポー
トとノンブロッキング・トランスポート・インタフェースのフェーズの間のどんな関連でも純粋に抽象的である。ノンブロッキング・トランスポートのメソッドだけが、リターン・パスが使用されたかどうかを示す値を返す。
トランスポート・インタフェースと汎用ペイロードは、メモリ・マップド・バスの抽象モデリン
グで高速で使われる為に設計された。トランスポート・インタフェースは、それらが汎用ペイロードから単独に使用される事を許可するトランザクション・タイプ上にテンプレート化されるが、しかし相互利用性の利益の多くが失われるだろう。
トランザクション・オブジェクトのメモリ管理、トランザクションの順序、及び許可された関数
呼び出しのシーケンスの規則は、トランスポート・インタフェースのテンプレート引数として渡された特定のトランザクション・タイプに依存しており、同様にソケットのテンプレート引数として渡されたプロトコル・タイプ・クラスに依存している。
（もしソケットが使用されているなら
ば）4.1.1 ブロッキング・トランスポート・インタフェース
4.1.1.1 イントロダクション
新しい TLM-2 のブロッキング・トランスポート・インタフェースは、ルーズリー・タイムド・コーディング・スタイルをサポートする事を意図している。ブロッキング・トランスポート・イン
タフェースは、イニシエータが 1 回の関数呼び出しの経過の間、ターゲットと一緒にトランザク
ションを完了することをのぞむ所、トランザクションの開始と終了を記録する唯一の重要なタイ
ミング・ポイントにおいて適切である。
ブロッキング・トランスポート・インタフェースは、イニシエータからターゲットまではフォワード・パスを使用するだけである。
- 132 -

TLM-2 のブロッキング・トランスポート・インタフェースは、TLM-2 の規格の一部としてまだ TLM-1
からのトランスポート・インタフェースとの計画的な類似性を持っているが、TLM-1 のトランス
ポート・インタフェースと TLM-2 のブロッキング・トランスポート・インタフェースは同一ではない。特に、新しい b_transport メソッドは、non-const 参照渡しによる単一のトランザクショ
ン引数とタイミングをアノテートする為の第 2 引数を持っているのに対し、TLM-1 の transport
メソッドは、タイミング・アノテーションを持っていない単一の const 参照の要求引数を取り、応答の値を返す。TLM-1 は、値が渡される（もしくは const の参照による）分離された要求と応答オブジェクトを仮定するのに対し、TLM-2 ではブロッキング・インタフェースを使用するかノンブロッキング・インタフェースを使用するかに関わらず、参照渡しによる単一のトランザクション・オブジェクトを仮定する。
b_transport メソッドはタイミング・アノテーション引数を持っている。この単一の引数は、現在のシミュレーション時間に相対的なトランザクションの開始及び終了の各々の時間を示すために、b_transport の呼び出しと b_transport からの応答の両方で使用される。
4.1.1.2 クラス定義
namespace tlm {template <typename TRANS = tlm_generic_payload>class tlm_blocking_transport_if : public virtual sc_core::sc_interface {public:virtual void b_transport(TRANS& trans, sc_core::sc_time& t) = 0;};
} // namespace tlm

4.1.1.3 TRANS テンプレート引数
このコア・インタフェースがあらゆるタイプのトランザクションを転送するのに使用されてもよい事が意図されている。特別なトランザクション・タイプである tlm_generic_payload は、トラ
ンザクション属性の正確な詳細があまり重要でない場合のモデル間の相互利用性の簡便さの為に提供される。
最大限の相互利用性の為には、アプリケーションは基本プロトコルと一緒に標準のトランザクション・タイプである tlm_generic_payload を使うべきである。特定のプロトコルをモデル化する
ために、アプリケーションはそれら自身のトランザクション・タイプを代えることができる。異なるトランザクション・タイプで特殊化されたインタフェースを使用するソケットは、バインド出来ない。そして、コンパイル時チェックが提供されるが、相互利用性を制限する。
4.1.1.4 規則a) b_transport メソッドは wait を直接もしくは間接的に呼び出すことができる。
b) b_transport メソッドはメソッド・プロセスからは呼び出されないものとする。
c) イニシエータは、１つの呼び出しから次の呼び出し、トランスポート・インタフェース、DMI、
及びデバッグ・トランスポート・インタフェースに渡る呼び出しでトランザクション・オブジェ
クトを再利用することができる。
d) b_transport の呼び出しは、トランザクションの最初のタイミング・ポイントである事を示すものとする。b_transport からの応答は、トランザクションの最終的なタイミング・ポイントである事を示すものとする。
e) タイミング・アノテーション引数は、関数呼び出し及び応答が実行されるシミュレーション時
間（sc_time_stamp()で返された値）からのオフセットのタイミング・ポイントである事を示す。
f) 呼び出し先関数は、トランザクション・クラス TRANS によって課せられたどんな制約にも従う
ようにトランザクション・オブジェクトを変更もしくはアップデートしてもかまわない。
g) トランザクション・オブジェクトにタイミング情報を含まないことを推奨する。タイミングは
b_transport の sc_time 引数を使ってアノテートするべきである。
h) b_transport が nb_transport_fw を呼び出す事を許可されるかどうかは、プロトコルと連携されたルールに依存する。基本プロトコルにおいて、自動的にこの変換をする事が出来る便利ソケ
ットの simple_target_socket が提供される。5.3.2 章「Simple sockets」を参照の事。
4.1.1.5 メッセージ・シーケンス図－ブロッキング・トランスポート
ブロッキング・トランスポート・メソッドは、すぐに応答するか（すなわち、現在の SystemC 評
価フェーズで）、スケジューラに制御を譲り、シミュレーション時間より遅れたポイントでイニシ
エータに戻るかもしれない。イニシエータのスレッドはブロックされるかもしれないが、イニシエータの他のスレッドは、プロトコルに依存して、最初の関数呼び出しが応答する前に- 133 -

b_transport を呼び出すことが許可されるかもしれない。

4.1.1.6 メッセージ・シーケンス図－テンポラル・デカップリング
テンポラル・デカップリングされたイニシエータは、現在のシミュレーション時間に先立って抽象的なローカル時間で走るかもしれないが、その場合以下に示すように、時間引数の為の非ゼロの値を b_transport に渡すべきである。イニシエータとターゲットは、時間引数の値を増加させる事で、各々のローカル時間のオフセットを進めるであろう。呼び出し先から返された時間引数を加えた現在のシミュレーション時間は、各々のトランザクションが完了するまでの抽象的な時間を与えるが、シミュレーション時間自身はイニシエータのスレッドが切り替わるまで進むことが出来ない。
b_transport の本体は、それ自身で wait を呼び出すかもしれないが、その場合はローカル時間のオフセットはゼロにリセットすべきである。以下のダイアグラムでは、イニシエータからの最後の応答は 140ns のシミュレーション時間後に起こるが、5ns の遅延がアノテートされたため、有効なローカル時間としては 145ns となる。

- 134 -

4.1.1.7 メッセージ・シーケンス図－タイム・クォンタム
テンポラル・デカップリングされたイニシエータは、タイム・クォンタムが超えるまでローカル
時間で進み続けるであろう。その時、イニシエータは次のクォンタムの境界まで実行を停止し同期せざるをえないだろう。これはモデルの他のイニシエータが動作して、追いつくのを許す。そして、それは効果的に、イニシエータが順番に実行することを意味する、各々がいつそれ自身のローカル時間の経過を追うことによって制御を返すべきかを決定する役割を果たす。オリジナルのイニシエータは、シミュレーション時間が次のクォンタムに達した後に再び走るだけであるべきである。
ルーズリー・タイムド・コーディング・スタイル中の遅延の第一の目的は、各々のイニシエータ
がいつ制御を返すべきかを決定する事を考慮する為のものである。もし正確に機能するためのタ
イミングの詳細を当てにしないのであれば、それが最良である。
各クォンタム中、所定のイニシエータによって生成されたトランザクションは厳密な連続した順序で起こるが、シミュレーション時間は進まない。ローカル時間は SystemC のスケジューラによって追跡されない。

4.1.2 ノンブロッキング・トランスポート・インタフェース
4.1.2.1 イントロダクション
ノンブロッキング・インタフェースは、アプロキシメイトリー・タイムドによるコーディング・
スタイルのサポートを意図しており、各トランザクションが通過するイニシエータとターゲット間の相関関係の詳細な流れをモデリングするのに適している。言い換えると、各フェーズ・トラ
ンザクションが明示的にタイミング・ポイントをいずれかで検出し、複数フェーズにトランザク
ションを分解する事である。
タイミング・ポイント数を２つに制限する事によってルーズリー・タイムドにも使用する事は出来るが、一般的には推奨されない。ルーズリー・タイムドにおいてはブロッキング・インタフェースの容易性が好まれる。ノンブロッキング・インタフェースはブロッキング・トランスポート・
インタフェースの使用が難しいパイプライン化されたトランザクション・モデリングに適している。
ノンブロッキング・インタフェースはイニシエータからターゲット（フォワード・パス）とター
ゲットからイニシエータ（バックワード・パス）の両方で使用する。それら二方向で使用される
tlm_fw_nonblocking_transport_if と tlm_bw_nonblocking_transport_if の２つの異なるインタ
フェースが用意されている。
ノンブロッキング・インタフェースは、ノンブロッキング・インタフェース・メソッドがトランザクション・オブジェクトとタイミング・アノテーションの非コンスト参照を渡す点だけが新しいブロッキング・インタフェースの引数渡しのメカニズムと良く似ている。ノンブロッキング・- 135 -

インタフェース・メソッドはまた、トランザクションの状態を示す為のフェーズを渡し、関数からの戻りがフェーズ・トランザクションを表すかを示す為に列挙型の値を返す。
ブロッキングとノンブロッキングの両方のトランザクションがタイミング・アノテーションをサポートするが、ノンブロッキングだけがトランザクションのそのライフタイムの間、複数フェー
ズをサポートしている。ブロッキング、ノンブロッキング・トランザクション・インタフェースと汎用ペイロードは、高速で抽象モデリングされるメモリ・マップド・バスと共に使用する事を前提に設計されている。しかし、トランスポート・インタフェースは特定のプロトコルをモデルする為の汎用ペイロードから分けて使用出来る。トランザクションの型とフェーズの型はいずれもノンブロッキング・トランスポート・インタフェースのテンプレート引数である。
4.1.2.2 クラス定義
namespace tlm {enum tlm_sync_enum { TLM_ACCEPTED, TLM_UPDATED, TLM_COMPLETED };template <typename TRANS = tlm_generic_payload, typename PHASE = tlm_phase>class tlm_fw_nonblocking_transport_if : public virtual sc_core::sc_interface {public:virtual tlm_sync_enum nb_transport_fw(TRANS& trans, PHASE& phase,sc_core::sc_time& t) = 0;};
template <typename TRANS = tlm_generic_payload, typename PHASE = tlm_phase>class tlm_bw_nonblocking_transport_if : public virtual sc_core::sc_interface {public:virtual tlm_sync_enum nb_transport_bw(TRANS& trans, PHASE& phase,sc_core::sc_time& t) = 0;};
} // namespace tlm

4.1.2.3 TRANS と PHASE テンプレート引数
ノンブロッキング・トランスポート・インタフェースは、任意のフェーズ数やタイミング・ポイ
ントと共に、あらゆる型のトランスポート・トランザクションで使用しても良い事が意図されている。詳細なトランザクションのアトリビュートが重要にならないようなモデル間の相互利用性向上向けに、特別なトランザクション型である tlm_generic_payload 型が提供され、また基本プ
ロトコルで使用される特別な型である tlm_phase 型も提供されている。相互利用性を最大限に活用するには基本プロトコルとしてデフォルト・トランザクション型の tlm_generic_payload とデ
フォルト・フェーズ型の tlm_phase を使用すべきである。
4.1.2.4 nb_transport_fw と nb_transport_bw 呼び出しa) フォワード・パス上で使用する nb_transport_fw と、バックワード・パス上で使用する
nb_transport_bw の、二つのノンブロッキング・トランスポート・メソッドが用意されている。
名前と呼び出しの方向は異なるが、これら二つのメソッドのセマンティクスはよく似ている。本書ではイタリック体で書かれている nb_transport は、二つのメソッドを区別する必要が無い状況において、両方のメソッドを説明する際に使用される。
b) 基本プロトコルの場合、フォワードとバックワードのパスは逆並びで同じコンポーネントとソケットのシーケンスを通じて渡すべきである。
c) nb_transport_fw はフォワード・パスのみで呼ばれるものとし、nb_transport_bw はバックワード・パスのみで呼ばれるものとする。
d) フォワード・パス上の nb_transport_fw 呼び出しは、バックワード・パス上の nb_transport_bw
を直接的または間接的に呼び出さないものとする。また逆も同様である。
e) nb_transport メソッドは直接、または間接的に wait を呼ばないものとする。
f) nb_transport メソッドはスレッド・プロセスまたはメソッド・プロセスから呼ばれる。
g) nb_transport では b_transport 呼び出す事が許可されていない。一つの解決策は、オリジナ
ルの nb_transport_fw メソッドによって生成または通知された別のスレッド・プロセスから
b_transport を呼び出す事である。基本プロトコルでは便利な simple_target_socket が提供されており、この変換を自動的に行わせる事が出来る。詳細は 5.3.2 の『シンプル・ソケット』を参照。
h) ノンブロッキング・トランスポート・インタフェースは、明確にパイプライン化されたトランザクションのサポートを意図している。言い換えれば、最初のトランザクションの完了を待つ必要はなく、同じプロセスから nb_transport_fw が連続して呼ばれ、それぞれ個別のトランザクシ- 136 -

ョンを開始する事が出来る。
i) トランザクションの最終タイミング・ポイントは、フォワード・パスまたはバックワード・パスのいずれかにおける nb_transport を呼び出しか、そこから戻る事によって検出される。
4.1.2.5 trans 引数a) 与えられたトランザクション・オブジェクトのライフタイムは、nb_transport への一連の呼び出しがイニシエータ、インターコネクト・コンポーネント、ターゲット間で一つのトランザク
ション・オブジェクトをフォワードとバックワードへ渡すことができるよう、nb_transport からの戻りを超えて拡張しても良い。
b) イニシエータは、一つの呼び出しから次の呼び出し、トランスポート・インタフェース、DMI、およびデバッグ・トランスポート・インタフェースに渡る呼び出しでトランザクション・オブジ
ェクトを再利用してもよい。
c) トランザクション・オブジェクトのライフタイムは nb_transport の呼び出し毎に拡張できる
為、呼び出し元関数と呼び出し先関数のいずれかは、トランザクション・クラスの TRANS によって課せられたなんらかの制約条件の下に、そのトランザクション・オブジェクトの変更または更新を行っても良い。例えば、汎用ペイロードでは、そのターゲットはリードコマンドの場合にそのトランザクション・オブジェクトのデータ配列をアップデートしても良いが、コマンド・フィールドを更新すべきではない。
4.1.2.6 phase 引数a) 各 nb_transport 呼び出しはフェーズ・オブジェクトの参照を渡す。あるフェーズから他のフェーズへの変化はタイミング・ポイントを検出する。基本プロトコルの場合、同一のフェーズにおける nb_transport の連続的な呼び出しは許可されない。sc_time 引数を使用したタイミング・
アノテーションは、もしそれが一つならフェーズ変化を遅らせるものとする。
b) トランザクションのアトリビュートは各フェーズにおいて基本的にステーブルであり、フェーズ変化が検出されたタイミング・ポイントの時のみ変化する。フェーズ途中で起こっているトラ
ンザクション・オブジェクトのあらゆる変化は、次のタイミング・ポイント時に他のコンポーネ
ントに見えるようになるだけなはずである。
c) フェーズ引数は参照渡しされる。呼び出し元関数または呼び出し先関数のいずれかがそのフェーズを変更してもよい。
d) トランザクションのあらゆる状態変更は、一つの呼び出しから次の呼び出しのフェーズ引数の値を比較する事によって呼び出し元関数か、呼び出し先関数のいずれかでその変更が検出出来るようにフェーズ引数の変更を伴わせるべきである。
e) フェーズ引数の値は、呼び出し元関数と呼び出し先関数間における通信用プロトコル・ステー
トマシンの現在の状態を表す。単一トランザクション・オブジェクトは二つ以上のコンポーネン
ト（イニシエータ、インターコネクト、ターゲット）間のいずれかに渡され、各呼び出し元関数／呼び出し先関数の接続は、別々のプロトコル・ステートマシンを（少なくとも概念的には）要求する。
f) トランザクション・オブジェクトは一つの nb_transport 呼び出しを超えるライフタイムとス
コープを持つのに対して、フェーズ・オブジェクトは一般的に呼び出し元関数においてローカルである。トランザクションを与える為の各 nb_transport 呼び出しは異なるのフェーズ・オブジェ
クトを持っても良い。異なる呼び出し元関数／呼び出し先関数上に対応するフェーズ・トランザ
クションは、シミュレーション時間内の異なるポイントで発生しても良い。
g) デフォルト・フェーズ型の tlm_phase は基本プロトコル向けである。その他プロトコルについては、拡張型の tlm_phase、またはそれ自身のフェーズタイプ（相互利用性低下への対応と共に）を代入出来る。7.1 章 フェーズを参照。
4.1.2.7 tlm_sync_enum の戻り値a) 同期の概念は方々で示されている。同期する事とは、いくつかプロセスが動作している中でSystemC スケジューラに制御を譲渡する事であるが、テンポラル・デカップリング用に追加的な意味も含まれる。 これは別の場所でより多くの議論がされている。8.1.3 章 テンポラル・デカ
ップリングを使用するプロセス向けの一般的なルールを参照。
b) 原則として同期は制御の譲渡によって実行可能であるが(スレッド・プロセスの場合 wait を呼ぶか、またはメソッド・プロセスでカーネルに戻る)、テンポラル・デカップリングされたイニシ
エータは、tlm_quantum_keeper クラスの sync メソッドを呼ぶことによって同期する。一般的に他の SystemC プロセスが実行される事を許す一方で、時々同期するイニシエータにはそれが必要- 137 -

である。
c) 下記のルールはフォワードとバックワード・パスの両方に適用する。
d) nb_transport の戻り値の意味は固定されており、トランザクション型またはフェーズ型によって変わらない。したがって、以下の規則は tlm_phase と tlm_generic_payload の制限を受けな
いが、しかしノンブロッキング・トランスポート・インタフェースをパラメタライズする際に使用される、あらゆるトランザクションとフェーズ型に適用する。
e) TLM_ACCEPTED： 呼び出し先関数は呼び出しを許可される。呼び出し先関数は呼び出し中のトランザクション・オブジェクト、フェーズ、または時間引数の状態を変更しないものとする。言い換えると、TLM_ACCEPTED はリターン・パスが使用されていない事を示す。フェーズ・トランザ
クションを無視している呼び出し先関数は TLM_ACCEPTED を返すべきである。呼び出し元関数は、その呼び出しに続く nb_transport 引数の値は変化しない為無視すべきである。
f) TLM_UPDATE： 呼び出し先関数はトランザクション・オブジェクトを更新する。呼び出し先関
数は、呼び出し中にフェーズ引数の状態変更、トランザクション・オブジェクトの状態変更、時間引数の値の増加を行える。言い換えると、TLM_UPDATED はリターン・パスが使用されている事を示し、そして呼び出し先関数は、トランザクションと共に連想されるプロトコル・ステートマ
シンの状態を進める。呼び出し先関数が各々引数を変更する事を実際に行う義務があるかどうか
はそのプロトコルに依存する。nb_transport 呼び出しに続き、その呼び出し先関数は、フェーズ、
トランザクション、または時間引数を検査し、適切な動作をすべきである。
g) TLM_COMPLETED： 呼び出し先関数はトランザクション・オブジェクトを更新して、そしてそのトランザクションは完了する。呼び出し先関数は、呼び出し中にフェーズ引数の状態変更、トランザクション・オブジェクトの状態変更、時間引数の値の増加を行える。呼び出し先関数は、
最終フェーズのトランザクションを TLM_COMPLETED の値を暗黙的に示している為フェーズ引数を更新する義務を持たない。呼び出し元関数は、トランザクションの最終タイムポイントがsc_time_stamp()+t（t は時間引数）時間に起こるよう振舞うべきである。言い換えると、
TLM_COMPLETED はリターン・パスが使用されており、そのトランザクションは完了である事を示す。nb_transport 呼び出しに続くその呼び出し先関数は、フェーズ、トランザクション、または
時間引数を確認し、適切な動作をすべきである。これ以上フォワードまたはバックワードのいず
れかに沿って、このトランザクションに関連して呼び出されるトランスポートはない。この意味
上の完了は、必ずしも無事に完了したという意味ではなく、その為トランザクション型に依存して呼び出し元関数はトランザクション・オブジェクト内に埋め込まれた応答状態の検査を必要とする可能性がある。
h) ３つの戻り値のいずれであってもプロトコルによって、nb_transport の呼び出しに続く呼び出し先関数はトランザクション・オブジェクトの応答を生成するか、またはリリースする為に呼び出し先関数を含むコンポーネントを許可する上で制御の譲渡を必要とする可能性がある。
4.1.2.8 tlm_sync_enum のまとめ
tlm_sync_enum Transaction object Phase on return Timing annotation on return
TLM_ACCEPTED
Unmodified
Unchanged
Unchanged
TLM_UPDATED
UpdatedChangedMay be increased
TLM_COMPLETED
UpdatedIgnoredMay be increased
4.1.2.9 メッセージ・シーケンス・チャート － バックワード・パスを使用しているケース
記のメッセージ・シーケンス・チャートは、nb_transport のシーケンスを呼び出すバリエーションを図示している。nb_transport へ、または nb_transport から渡される引数と戻り値は、return、
phase、delay の表記で表される。return は関数呼び出しからの戻り値、phase はフェーズ引数の値、delay は sc_time 引数の値を意味し、 “－”の表記は値が使用されない事を示す。
下記のメッセージ・シーケンス・チャートを例として、BEGIN_REQ や END_REQ 等の基本プロトコ
ルのフェーズを使用する。アプロキシメイトリー・タイムド・コーディング・スタイルと基本プロトコルで、トランザクションはイニシエータとターゲット間を前後２回渡される。他のプロト
コルではフェーズ数とその名前は異なる可能性がある。
nb_transport 呼び出しの受け取り側が、その次のトランザクションの状態、または次のフェーズ・
トランザクションの遅延を即座に計算出来ない場合、それは TLM_ACCEPTED の値を戻すべきである。
呼び出し元関数は、スケジューラへの制御の譲渡し、呼び出し先関数が応答する準備が完了した時に、反対の経路から nb_transport の呼び出しを受ける事を想定すべきである。
トランザクションはパイプラインされても良い。イニシエータは前のトランザクションの最終タ- 138 -

イミング・ポイントを確認する以前に、ターゲットに対して他のトランザクションを送る為の
nb_transport を呼び出す事が出来る。
プロセスはシミュレーション時間を進める事を許可する為の一般的な制御の譲渡をしているのであり、アプロキシメイトリー・タイムド・コーディング・スタイルは、ルーズリー・タイムド・コーディング・スタイルより遅いシミュレーションを実行する事が想定されている。

図 8 バックワード・パス使用
4.1.2.10 メッセージ・シーケンス・チャート － リターン・パスを使用しているケース
nb_transport 呼び出しの受け取り側が、そのトランザクションの次の状態、または次のフェーズ・
トランザクションの遅延を即座に計算出来る場合、それは反対の経路を使用するのではなく
nb_transport からのリターンにより新しいステートを戻す可能性がある。このタイミング・ポイ
ントがトランザクションの最後を示さない場合に、その戻り値の TLM_UPDATED が提供され、トラ
ンザクションの最後を示す場合は、TLM_COMPLETED が提供される。トランザクションの完了時に呼び出し先関数は、それが他のフェーズを先取りして最終フェーズまでジャンプした事を呼び出し元関数に示す為に、どのステージでも TLM_COMPLETED を返すことが出来る。これはイニシエー
タとターゲットのいずれも適用される。
TLM_UPDATED であるなら、呼び出し先関数は、トランザクションとフェーズの更新とフェーズ・
トランザクションに遅延をアノテートすべきである。
TLM_COMPLETED であるなら、トランザクションの最終フェーズが暗黙的に示されるので、フェーズ引数の値は呼び出し元関数によって無視されるべきである。

図 9 リターン・パス使用- 139 -

4.1.2.11 メッセージ・シーケンス・チャート － 早期完了
プロトコルに依存して、イニシエータやターゲットは早期にトランザクションを完了する為に
nb_transport から TLM_COMPLETED を任意のタイミング・ポイントで返しても良い。イニシエータとターゲットのいずれも、このトランザクション・インスタンスの nb_transport 呼び出しを行わなくても良い。イニシエータやターゲットは、このようなトランザクションのショートカットを受け入れられるか否かは、その特定のプロトコルのルールに依存する。
以下のダイアグラムのリターン・パスにおけるタイミング・アノテーションは、与えられた遅延
後に最終タイミング・ポイントが起こる事をイニシエータに指示している。

図 10 早期完了
4.1.2.12 メッセージ・シーケンス・チャート － タイミング・アノテーション
呼び出し元関数は、nb_transport 呼び出しに遅延をアノテートしても良い。これは、呼び出し元関数に対応するフェーズがあたかも与えられた遅延の後に、それを受け取ったかのように処理されるべきである事を示す。アプロキシメイトリー・タイムドな呼び出し先関数は、このシミュレ
ーション時間がアノテートされた時間に到達際、処理する為のペイロード・イベント・キューに
トランザクションを入れる事によって、通常この状況をハンドルする。
遅延はフォワードまたはバックワード・パスのいずれかの呼び出しにアノテートさせる事が出来る。

図 11 タイミング・アノテーション
4.1.3 トランスポート・インタフェースにおけるタイミング・アノテーション
タイミング・アノテーションはブロッキングまたはノンブロッキング・トランスポート・インタ
フェースの共有の機能であり、b_transport、nb_transport_fw、nb_transport_bw メソッドに
sc_time 引数を使用して表される。下記の章では、イタリック体の transport は、b_transport、
nb_transport_fw、nb_transport_bw の３つのメソッドの意味で用いられる。
- 140 -

4.1.3.1 sc_time 引数a) トランザクション・オブジェクトは、タイミング情報を含まない事が推奨される。あらゆるタ
イミング・アノテーションは transport の sc_time 引数を使用してアノテートされるべきである。
b) 時間引数はマイナスにはならず、常にカレント・シミュレーション時間の sc_time_stamp()に連動して表される。
c) 時間引数は transport の呼び出しと transport からの戻りの両方で適用されるものとする。
（tlm_sync_enum のルールに従って nb_transport の値を戻す）d) nb_transport メソッドはそれ自身に時間引数の値を増加する可能性があるが値は減少しない。
b_transport メソッドは wait が呼ばれる場合にのみ時間引数の値を減少させる事でシミュレーシ
ョン時間に同期する。このルールは SystemC シミュレーションにおいて時間が戻らない事と同様である。
e) 以下の説明では、transport 呼び出しにおけるトランザクションの受け取り側は呼び出し先関数であり、そして transport からの戻りにおけるトランザクションの受け取り側は呼び出し元関数である。
f) 受け取り側は、sc_time_stamp()+t（t は時間引数の値）の時間でトランザクションを受け取るように振舞うものとする。言い換えると、受け取り側は対応しているフェーズ・トランザクシ
ョンをマークするタイミング・ポイントが sc_time_stamp()+t の時間に起こるかのように振舞うものとする。
g) トランザクションが処理される事により時間順番を増やす可能性のある sc_time_stamp()+t
時間の transport を呼び出すシーケンスが与えられる。一般的には呼び出し元、または呼び出し
先関数は、タイミング・アノテーションをいかなる特定順番で生成する事を強いられない。アウト・オブ・オーダーのタイミング・アノテーション付きトランザクションをハンドルする為の責任は受け取り側が持つ。
h) タイミング・アノテーションと共にトランザクションを受け取る上で、受け取り側はスピードと精度間におけるトレードオフをモデリングに反映させるいくつかの選択肢を持つ。言い換えると、モデルは速くして精度を落とす（ルーズリー・タイムド）事も出来るし、遅くして精度を上げる事も出来る。ブロッキング・トランスポートはルーズリー・タイムド・モデルが推奨され、
ノンブロッキング・トランスポートはアプロキシメイトリー・タイムドが推奨される。その選択
はトランスポート・インタフェースによって実施されるのでは無く、プロトコル型クラスや、コーディング・スタイルの部分に記載される。
i) もし受け取り側がタイミング並びに実行順番の正確なモデルを実装する事があるなら、それはトランザクションが相互作用の可能性があるその他の SystemC プロセスに基づいた正しい時間に処理される事を確実にするべきである。SystemC における将来の時間に起きるイベントのスケジ
ュールを適切に行うメカニズムは時間イベント通知である。容易性を考慮し、TLM-2 では SystemCの通常のセマンティクス（8.2 章 ペイロード・イベント・キューを参照）に従った適切なシミュレーション時間に処理する為、トランザクションをキューイング出来るペイロードのイベン
ト・キューを知るユーティリティ・クラスのファミリを提供する。言い換えると、アプロキシメ
イトリー・タイムド（原文のまま）の受け取り側は、ペイロードのイベント・キューに通常トラ
ンザクションを置くべきである。
j) もしタイミングの精度、またはそれらタイミング・アノテーションによって与えられた順番に来ているトランザクションのシーケンスを処理する事が受け取り側に関係がない場合、それは遅延を除いて各トランザクションを即座に処理出来る。またその場合受け取り側は、トランザクシ
ョンを処理するのに必要な時間をモデルする為の、タイミング・アノテーションの値を増やす事を選択出来る。言い換えると、ルーズリー・タイムドの受け取り側は通常テンポラル・デカップ
リングを使用出来る。このシナリオは、システム設計が正しいイベントの連続性を実施する為の明確的なメカニズム（上記の TLM-2 インタフェースの上で）が存在する為、アウト･オブ･オーダ
ー実行を許容出来るとみなせる。
k) トランザクションを処理するいかなる場合にも、受け取り側はトランザクションの変更と、同一のフェーズとタイミング・アノテーションを使用している事を除き、更なる transport からの呼び出し、またはリターンと共にトランザクションを渡しても良い。
l) またタイミング・アノテーションについては、テンポラル・デカップリングの観点でも説明される。ゼロでないタイミング・アノテーションは、“タイム・ワープ”が受け取り側に要請されたと見なす事が出来る。受け取り側は、タイム・ワープに入るか、後処理とイールド制御の為にキ- 141 -

ューにトランザクションを置くか選択する事が出来る。ルーズリー・タイムド・モデルにおいて、
タイム・ワープは一般的に有効である。もう一方では、もしターゲットが他の非同期イベントに依存関係を持つ場合、そのターゲットは確実に先のトランザクションの状態を予測する事が出来るまでは、シミュレーション時間の更新を待たなければならない可能性がある。
m) テンポラル・デカップリングの説明については、3.3.2 章 ルーズリー・タイムド・コーディ
ング・スタイルとテンポラル・デカップリングを参照。
n) クォンタムの説明については、8.1 章 グローバル・クォンタムとクォンタム・キーパーを参照。
4.1.4 TLM-1 からのマイグレーション・パス
旧 TLM-1 と新 TLM-2 インタフェースはどちらも TLM-2 標準の一部である。TLM-1 ブロッキングとノンブロッキング・インタフェースは現在も使用出来る。例えばベンダの何社かは、HDL 設計向けに機能検証環境の構築にこれらインタフェースを使用している。
新旧ブロッキング・トランスポート・インタフェース間の類似性は、TLM-1 インタフェースを使用した古いモデルと、新しい TLM-2 インタフェース間におけるアダプタを構築する作業を容易にする事を意図している。
4.2 ダイレクト・メモリ・インタフェース
4.2.1 イントロダクション
ダイレクト・メモリ･インタフェース（DMI）は、イニシエータがターゲット内のメモリ領域に直接アクセスできる手段を提供する。つまりトランスポート・インタフェースを使わずに直接ポインタを使ってメモリアクセスが可能である。DMI によって、イニシエータからインターコネクト・コンポーネントに接続されたターゲットへの複数の b_transport 関数や nb_transport 関数の呼び出しをバイパスできるため、イニシエータとターゲット間のメモリアクセスを高速化することが可能となる。
ダイレクト・メモリ・インタフェースには２つのインタフェースがあり、ひとつはイニシエータ
からターゲットへのフォワード・パス呼び出しともうひとつはターゲットからイニシエータへのバックワード・パス呼び出しである。フォワード・パスは、ある指定されたアドレスに対する DMI
アクセス（読み込みまたは書き込み）の特定モードを要求するために利用され、DMI 領域の境界を含む tlm_dmi 型の DMI 記述子へのリファレンスを返す。バックワード・パスは、フォワード・
パスによって確立されたＤＭＩポインタが無効な場合にターゲットから呼び出される。フォワー
ド・パスとバックワード・パスは、全く通らないか、ひとつまたは複数のインターコネクト・コンポ
ーネントを通ってもよいが、同じソケットを通る対応するトランスポート呼び出しにおいては、フォ
ワードとバックワードは同一の経路を通るべきである。
DMI ポインタは、フォワード・パスにそってトランザクションを通過することによって要求される。デフォルトの DMI トランザクション型は、tlm_generic_payload であり、トランザクション･
オブジェクトのコマンドとアドレス・アトリビュートのみ使用する。DMI は、トランスポート・
インタフェースの拡張と同じ仕組みである。つまり、DMI 要求には、無視可能拡張があってもよ
いが、必須拡張は、新しいプロトコル型のクラス定義を必要とする。
（tlm_generic_payload の型
定義が記載されている 6.2.2 章の新しいプロトコル型のクラスの定義を参照）
DMI 記述子は、イニシエータで消費されるレイテンシ値を返し、その結果ルーズリー・タイムド・モデリングに十分なタイミング精度を確保することができる。
DMI ポインタはデバッグ用途にも使えるが、通常デバッグのトラフィックよりもメモリアクセスのトラフィックの方が支配的であるため、デバッグ用途では、DMI ではなくデバッグ・トランザ
クション・インタフェースで十分である。DMI ポインタをデバッグ用に使う場合、レイテンシ値
は無視すべきである。
4.2.2 クラス定義
class tlm_dmi{
public:tlm_dmi() { init(); }void init();enum dmi_access_e {DMI_ACCESS_NONE = 0x00,
DMI_ACCESS_READ = 0x01,
DMI_ACCESS_WRITE = 0x02,- 142 -

DMI_ACCESS_READ_WRITE = DMI_ACCESS_READ | DMI_ACCESS_WRITE};
unsigned char* get_dmi_ptr() const;
sc_dt::uint64 get_start_address() const;
sc_dt::uint64 get_end_address() const;
sc_core::sc_time get_read_latency() const;
sc_core::sc_time get_write_latency() const;
dmi_access_e get_granted_access() const;bool is_none_allowed() const;bool is_read_allowed() const;bool is_write_allowed() const;bool is_read_write_allowed() const;
void set_dmi_ptr(unsigned char* p);void set_start_address(sc_dt::uint64 addr);
void set_end_address(sc_dt::uint64 addr);
void set_read_latency(sc_core::sc_time t);
void set_write_latency(sc_core::sc_time t);
void set_granted_access(dmi_access_e t);
void allow_none();void allow_read();void allow_write();void allow_read_write();};template <typename TRANS = tlm_generic_payload>class tlm_fw_direct_mem_if : public virtual sc_core::sc_interface{
public:virtual bool get_direct_mem_ptr(TRANS& trans, tlm_dmi& dmi_data) = 0;};class tlm_bw_direct_mem_if : public virtual sc_core::sc_interface{
public:virtual void invalidate_direct_mem_ptr(sc_dt::uint64 start_range, sc_dt::uint64 end_range) = 0;};
} // namespace tlm

4.2.3 get_direct_mem_ptr メソッドa) get_direct_mem_ptr メソッドは、ターゲットではなく、イニシエータまたはインターコネク
ト・コンポーネントからのみ呼び出されるべきである。
b) trans 引数には、イニシエータで生成された DMI トランザクション・オブジェクトへの参照値。
c) dmi_data 引数には、イニシエータで生成された DMI 記述子への参照値。
d) すべてのインターコネクト・コンポーネントでは、get_direct_mem_ptr 呼び出しをイニシエータからターゲットへのフォワード・パスに沿って通過させる必要がある。言い換えれば、インターコネクト・コンポーネントのターゲット・ソケットで、get_direct_mem_ptr の実装は、イニ
シエータ・ソケットで get_direct_mem_ptr メソッドを呼び出すことかもしれない。
e) それぞれの get_direct_mem_ptr 呼び出しは、イニシエータからターゲットへのトランスポー
ト呼び出しの対応するセットと全く同一のパスに従う。言い換えれば、それぞれの DMI 要求は、
一つのイニシエータと一つのターゲット間の相互作用を含む。これら二つのコンポーネント（イニシエータとターゲット）もまた、トランスポート・インタフェースを通る一つのトランザクション・オブジェクトのイニシエータとターゲットとしての役割をする。DMI は二つ目のトランザク
ション・オブジェクト（例えばバス幅変換のようなもの）を発生するようなコンポーネントを通るパ
ス上では使うことができない。（もし DMI がシミュレーション速度が非常に要求される場合には、シミュレーション・モデルを再構成する必要があるかもしれない）
f) すべてのインターコネクト・コンポーネントは、フォワード方向での trans と dmi_data 引数を伝える必要がある。唯一許されている修正は、以下のように記述される DMI トランザクション・
オブジェクトのアドレス引数値である。トランザクションと DMI 記述子のアドレス・アトリビュ- 143 -

ートは両方とも get_direct_mem_ptr メソッド終了後に修正されるかもしれない。つまり、ターゲットからイニシエータへの関数呼び出しを巻き戻しているとき。
g) もし、指定されたアドレスへの DMI アクセスをターゲットがサポートしていれば、以下に記述
するように、DMI 記述子のメンバーをセットし、関数の返り値として true をセットする必要がある。
h) もし、指定されたアドレスへの DMI アクセスをターゲットがサポートしていなければ、以下に記述するように、アドレス範囲と DMI 記述子の型メンバーのみセットし、関数の返り値としてfalse をセットする必要がある。
i) get_direct_mem_ptr を複数回呼び出した場合、ターゲットは同じメモリ領域、同じ時刻に DMI
アクセスを複数のイニシエータに許可するかもしれない。アプリケーションは同期とデータの一貫性を保証する必要がある。
j) それぞれの get_direct_mem_ptr の呼び出しで隣り合うメモリ領域への単一 DMI ポインタのみを返すので、実際にはそれぞれの DMI 要求は一つのターゲットでのみ実行可能である。別の言い方をすれば、もしメモリ領域が複数のターゲットに分散している場合、例えアドレス範囲が隣りあっていても、それぞれのターゲットは分割された DMI リクエストを要求するだろう。
4.2.4 テンプレート引数と tlm_generic_payload クラスa) tlm_fw_direct_mem_if テンプレートは DMI トランザクション・クラスの型でパラメタライズ
される。
b) トランザクション・オブジェクトはダイレクト・メモリ・アクセスが要求するアドレスを指し示すアトリビュート及び、要求されるアクセスの型、つまり指定されたアドレスに対する読み込
みアクセスか、書き込みアクセスかを含む。
c) TRANS テンプレートの引数のデフォルト値は tlm_generic_payload クラスである。
d) 相互利用性を最大化するために、DMI トランザクション・クラスは tlm_generic_payload にすべきである。必須拡張または他のトランザクション型を使うことによって相互利用性は制限される。
e) イニシエータは DMI トランザクション・オブジェクトを生成及び管理する必要があり、また
get_direct_mem_ptr への引数として渡される前に適切な属性を設定する必要がある。
f) トランザクション・オブジェクトのコマンド属性は、要求されている DMI アクセスの種類、つまり読み込みアクセスの TLM_READ_COMMAND または書き込みアクセスの TLM_WRITE_COMMAND かを示すために、イニシエータによって設定される。
g) トランザクション・オブジェクトのアドレス属性は、ダイレクト・メモリ・アクセスが要求しているアドレスを指し示すために、イニシエータによって設定される。
h) フォワード・パスに沿って DMI トランザクション・オブジェクトが通過するインターコネク
ト・コンポーネントによって同じソケットの対応するトランスポート・インタフェースにトランザクションのアドレス属性をデコード及び、必要に応じて修正すべきである。例えば、インターコネクト・コンポーネントによって、ターゲットのアドレス幅やシステム・メモリ・マップにおける場所に応じて、アドレスをマスク(上位ビットの数を削減）する必要がある。
i) インターコネクト・コンポーネントは,アドレスエラーを検知した場合、get_direct_mem_ptr
呼び出しを通過させる必要はない。
j) 基本プロトコルの場合、イニシエータは、コマンドとアドレスを除いて汎用ペイロードの属性を設定する必要はない。また、ターゲットとどんなインターコネクト・コンポーネントでも、他のすべての属性を無視してもよい。特に、応答ステータスの属性や許可されている DMI 属性は無視してもよい。許可されている DMI 属性は、トランスポート・インタフェースとともに利用することだけを想定している。
k) イニシエータは、一つの DMI 呼び出しから次の呼び出し、さらには DMI やトランスポート・イ
ンタフェース、そしてデバッグ・トランスポート・インタフェースの呼び出しに渡ってトランザ
クション・オブジェクトは再利用されるかもしれない。
l) もしアプリケーションが、要求されている DMI アクセスの種類が決定したときターゲットによって利用される DMI トランザクション・オブジェクトにさらに属性を追加する必要があるならば、無関係なトランザクション・クラスに置き換えるよりも、汎用ペイロードを拡張することを推奨する。例えば、DMI トランザクションは、CPU の種類に応じて異なった DMI 要求をターゲットが処理するために、CPU Id が必要かもしれない。そのような拡張が無視不可能な場合は、新しいプロ
トコル型クラスを定義する必要がある。
- 144 -

4.2.5 tlm_dmi クラスa) DMI 記述子は tlm_dmi クラスのオブジェクトである。DMI 記述子は、イニシエータで生成されるが、そのメンバーはインターコネクト・コンポーネントまたはターゲットで設定される。イニシエータは DMI 記述子を再利用してもよい。その場合イニシエータは get_direct_mem_ptr 関数を呼び出す間に init メソッドを呼び出し再度初期化する。
b) DMI 記述子は、次の属性を持つ：DMI ポインタ属性、許可されたアクセス型の属性、開始アド
レス属性、終了アドレス属性、読み込みレイテンシ属性、そして書き込みレイテンシ属性c) インターコネクト・コンポーネントは DMI 記述子をフォワード・パスで修正してはいけないので、DMI 記述子はターゲットで受け取ったときに初期状態にあるべきである。
d) init メソッドはメンバーを以下に記述したように、初期化する。
e) set_dmi_ptr メソッドは DMI ポインタ・アトリビュートを引数で渡される値に設定される。
get_dmi_ptr メソッドは DMI ポインタ・アトリビュートの現在の値を返す。
f) DMI ポインタ・アトリビュートは開始アドレス・アトリビュートの値に対応するストレージ場
所を示すためにターゲットによって設定される。これは get_direct_mem_ptr 呼び出しで要求されるアドレス以下である。初期値は 0 である。
g) DMI 領域のストレージは unsigned char*の型で表現される。ストレージは汎用ペイロードのデータ配列と構成を持つ。もしターゲットがその構成のメモリ領域へのポインタを返すことが出来ない場合は、ターゲットは DMI をサポートできず、get_direct_mem_ptr は偽の値を返すべきである。TLM2.0 におけるメモリ構成とエンディアンの扱い方の詳細は、6.17 節を参照。
h) インターコネクト・コンポーネントは、get_direct_mem_ptr 関数呼び出しからのリターン・
パスにおいて DMI アクセスが許可された領域を制限するために DMI ポインタ・アトリビュートを修正することが許されている。
i) set_granted_access メソッドは、許可されたアクセス型アトリビュートを引数で渡された値で設定される。get_granted_access メソッドは、許可されたアクセス型アトリビュートの現在の値を返す。
j) allow_none、allow_read、allow_write そして allow_read_write メソッドは、許可されたア
クセス型アトリビュートをそれぞれ DMI_ACCESS_NONE、DMI_ACCESS_READ、DMI_ACCESS_WRITE、または DMI_ACCESS_READ_WRITE の値に設定する。
k) is_none_allowed メソッドは、許可されたアクセス型アトリビュートが DMI_ACCESS_NONE の値の場合及びその場合のみ真の値を返す。is_read_allowed メソッドは、 許可されたアクセス型ア
トリビュートが DMI_ACCESS_READ または DMI_ACCESS_READ_WRITE の値の場合及びその場合のみ真の値を返す。is_write_allowed メソッドは、 許可されたアクセス型アトリビュートが
DMI_ACCESS_WRITE または DMI_ACCESS_READ_WRITE の値の場合及びその場合のみ真の値を返す。
is_read_write_allowed メソッドは、許可されたアクセス型アトリビュートが
DMI_ACCESS_READ_WRITE の値の場合及びその場合のみ真の値を返す。
l) ターゲットは、許可されたアクセス型アトリビュートに許可されたアクセスの型を設定する。
ターゲットは、読み込みまたは読み込み／書き込みアクセスが許可されることよって読み込みア
クセスの要求に答えることができ、同様に書き込みみまたは読み込み／書き込みアクセスが許可されることよって書き込みアクセスの要求に答えることができる。インターコネクト・コンポー
ネントは、get_direct_mem_ptr 関数呼び出しのリターン・パスにおいて、DMI_ACCESS_READ_WRITEの値を DMI_ACCESS_READ または DMI_ACCESS_WRITE で上書きすることによって許可されたアクセスを制限ことができる。
m) ターゲットは、イニシエータへの読み込みや書き込みまたは読み込み／書き込みアクセスが許可されていないが、DMI トランザクション・オブジェクトへの拡張によって要求されるあるほかのアクセスの種類を許可していることを示すために、DMI_ACCESS_NONE を許可されたアクセス型に設定すべきである。この値は、DMI トランザクション・オブジェクトの拡張によって事前に定義されたアクセス型(読み込み、書き込みと読み込み／書き込み）が不要または意味がなくなる場
合にのみ利用されるべきである。この値は基本プロトコルの場合に利用されるべきではない。
n) イニシエータは、許可されたアクセス型アトリビュートを使ってターゲットによって許可されている（または基本プロトコルとは別に、汎用ペイロードの拡張やまたほかの DMI トランザクシ
ョン型を使って許可されている）DMI アクセスのこれらのモード（インターコネクトによって修正される可能性はあるが）のみを利用する責任がある。
o) set_start_address と set_end_address メソッドは、開始と終了アドレス・アトリビュートを- 145 -

それぞれ引数で渡される値を設定する。get_start_address と get_end_address メソッドは、開始と終了アドレス・アトリビュートの現在の値をそれぞれ返す。
p) 開始と終了アドレス・アトリビュートは DMI 領域における最初と最後のバイトのアドレスを示すためにターゲットによって設定（またはインターコネクトによって修正）される。DMI 領域が有効か無効かが get_direct_mem_ptr メソッド返り値（true または false）によって決まる。
q) ターゲットは、それぞれの get_direct_mem_ptr 呼び出しに対して一つの隣接するメモリ領域を許可または拒絶しかできない。ターゲットは、開始と終了アドレス・アトリビュートを同じにすることによってメモリ領域を一つのアドレスに設定することができ、DMI 領域を任意の大きさに設定することもできる。
r) 指定された領域への指定された型の DMI アクセスが許可されているとき、イニシエータはその領域が無効になるまでその領域のどこでも指定された型のアクセスを実行することができる。別の言い方でいうと、DMI 要求によって指定されたアドレスはアクセス制限されない。
s) get_direct_mem_ptr 呼び出しが通過するいかなるインターコネクト・コンポーネントでも、アドレス引数を変換するように開始と終了アドレス・アトリビュートを変換する必要がある。DMI
記述子におけいるアドレスのいかなる変換も、記述子が get_direct_mem_ptr 関数呼び出しのリタ
ーン・パスを通過するときに実行される。例えば、ターゲットは開始アドレス・アトリビュート
をそのターゲットが知っているメモリ・マップ内での相対アドレスに設定する。その場合インターコネクト・コンポーネントは相対アドレスをシステム上のメモリ・マップにおける絶対アドレ
スに変換する必要がある。初期値はそれぞれ 0 と sc_dt::uint64 の取り得る最大値である。
t) インターコネクト・コンポーネントは、DMI アクセスが許可されている領域を制限するため、または DMI アクセスが許可されていない領域を拡張するために、開始と終了アドレス・アトリビ
ュートを修正することができる。
u) もし get_direct_mem_ptr が true を返す場合は、開始と終了アドレス・アトリビュートで示される DMI 領域が DMI アクセスできる領域である。もし get_direct_mem_ptr が false を返す場合は、
DMI アクセスできない領域である。
v) ターゲットまたはインターコネクト・コンポーネントが二つまたはそれ以上のget_direct_mem_ptr 呼び出しを受け取る場合は、二つまたはそれ以上の重なり合う DMI アクセス
許可領域、または二つまたはそれ以上の重なり合う DMI アクセス禁止領域を返すかもしれない。
w) ターゲットまたはインターコネクト・コンポーネントは、同じアクセス型（例えば、読み込み
及び読み込み／書き込みの両方や書き込み及び読み込み／書き込みの両方）に対して、最初の領域を無効にするために invalidate_direct_mem_ptr を途中で呼び出さない場合には、許可領域と禁止領域がオーバーラップする DMI 領域を返してはならない。
x) 別の言葉で言えば、DMI 領域の定義は invalidate_direct_mem_ptr を途中呼び出しによって最初の領域が無効化されない限り、生成された順番に依存しない。特に禁止 DMI 領域の生成は、同
じアクセス型ですでに許可された DMI 領域に穴をあけることができない。逆もまた真。
y) ターゲットは DMI アクセスをすべてのアドレス領域（開始アドレスを 0、終了アドレスを最大値）で禁止してもよい。ターゲットが DMI アクセスを全くサポートしないようなケースである。
その場合、インターコネクト・コンポーネントはこのターゲットが占有しているメモリ・マップの一部だけを禁止領域として制限するべきである。もしインターコネクト・コンポーネントがア
ドレス領域を制限することに失敗したら、イニシエータはすべてのシステム上のアドレス空間のすべてが DMI 禁止されていると勘違いをするだろう。
z) set_read_latency と set_write_latency メソッドは、それぞれ読み込み及び書き込みレイテ
ンシ・アトリビュートに引数で渡された値を設定する。get_read_latency と get_write_latency
メソッドは、それぞれ読み込み及び書き込みレイテンシ・アトリビュートの現在の値を返す。
aa) 読み込み及び書き込みレイテンシ・アトリビュートは、それぞれ読み込み及び書き込みのメ
モリ・トランザクションにかかるレイテンシを設定する。初期値は SC_ZERO_TIME。インターコネ
クト・コンポーネントとターゲットの両方が読み込み、書き込みのどちらかのレイテンシの値を増やし、その結果 DMI 記述子が get_direct_mem_ptr メソッドからのリターン・パスにおいてイニ
シエータからターゲットへ戻るときにレイテンシが積算される。許可されたアクセス型アトリビ
ュートの値によって、一つまたは両方のレイテンシが有効になる。
bb) イニシエータはダイレクト・メモリ・ポインタを使ってメモリにアクセスするときはいつでも、レイテンシを考慮する必要がある。もしイニシエータがレイテンシを無視すれば、タイミン
グが不正確になる。
- 146 -

4.2.6 invalidate_direct_mem_ptr メソッドa) invalidate_direct_mem_ptr メソッドはターゲットまたはインターコネクト・コンポーネント
だけによって呼び出される。
b) ターゲットは存在する DMI 領域の有効性やアクセス型を修正する変更の前にinvalidate_direct_mem_ptr メソッドを呼び出す必要がある。例えば、存在する DMI 領域のアドレス領域を制限する前や、アクセス型を読み込み／書き込みから読み込みに変更する前や、アドレス空間をリマップする前などである。
c) start_range と end_range の引数は、DMI 領域が無効化されるアドレス範囲の最初と最後のアドレスを示す。
d) イニシエータが invalidate_direct_mem_ptr を受け取ったらすぐに指定されたアドレス範囲と重なり合う DMI 領域（get_direct_mem_ptr で事前に獲得していたもの）
を無効にして廃棄する。
e) 部分的に重なり合う場合、つまり存在する DMI 領域の一部分だけ無効な場合には、イニシエー
タは存在する領域の境界を調整するか、または全体の領域を無効化する。
f) 各 DMI 領域は、ターゲットが invalidate_direct_mem_ptr 呼び出しで明示的に無効化するまでは有効のままである。各イニシエータは、有効な DMI 領域の管理表を管理し、無効化されるまで各領域を利用し続ける。
g) すべてのインターコネクト･コンポーネントは、デコードや必要に応じて対応するトランスポート・インタフェースのためにアドレス引数を修正するときに、invalidate_direct_mem_ptr 呼
び出しをイニシエータからターゲットへのバックワード・パスに沿って通過させる義務がある。
トランスポート・インタフェースがフォワード・パスと DMI のバックワード・パスでアドレスを変換するので、トランスポートと DMI 変換は相互に逆であるべきである。
h) もし一つの invalidate_direct_mem_ptr をターゲットから呼び出すならば、インターコネク
ト・コンポーネントは複数の invalidate_direct_mem_ptr をイニシエータへ呼び出してもよい。
複数のイニシエータが存在しそれぞれが同じターゲットに対してダイレクト・メモリ・ポインタを得るかもしれないので、インターコネクト・コンポーネントがすべてのイニシエータに対して
invalidate_direct_mem_ptr を呼び出すのが安全な実装方法である。
i) インターコネクト・コンポーネントは、start_range を 0、end_range を sc_dt::uint64 の最大値に設定することによって、イニシエータにあるすべてのダイレクト・メモリ・ポインタを無効化することができる。
4.2.7 DMI ヒントを使った最適化a) DMI ヒントは DMI アクセスの繰り返しポーリングをなくすことによってシミュレーションスピ
ードを最適化するメカニズムである。DMI ポインタが使える状態か確認するために
get_direct_mem_ptr を呼び出すかわりに、イニシエータがトランスポート・インタフェースを通過する通常のトランザクションの DMI ヒントを確認することができる。
b) 汎用ペイロードによって DMI ヒントは提供される。ユーザ定義のトランザクションによって同じメカニズムを実装できる。その場合ターゲットによって DMI ヒントの値を適切に設定すべきである。
c) DMI ヒントを使うかどうかは自由に選択できる。イニシエータは汎用ペイロードの DMI ヒントを自由に無視できる。
d) イニシエータが DMI ヒントを有効にするための推奨手順は下記に示す。
i. イニシエータが有効な DMI 領域のキャッシュに対するアドレスを確認する。
ii. もし DMI ポインタが存在しないなら、イニシエータはトランスポート・インタフェースを通して通常のトランザクションを実行する。
iii. その後、イニシエータはトランザクションの DMI ヒントを確認する。
iv. もし DMI ヒントが DMI を許可していることを示していれば、イニシエータは
get_direct_mem_ptr を呼び出す。
4.3 デバッグ・トランスポート・インタフェース
4.3.1 イントロダクション
デバッグ・トランスポート・インタフェースによって、遅延、待ち、イベント通知または通常のトランザクションに対する副作用を一切発生させないでターゲットのストレージに対して読み込
み及び書き込みが可能である。デバッグ・トランスポート・インタフェースは、トランスポート・
インタフェースと同じパスを通るため、デバッグ・トランスポート・インタフェースの実装は通常のトランザクションと同じアドレス変換を実行する。
- 147 -

例えばデバッグ・トランスポート・インタフェースによって、ISS に接続されたソフトウェアデ
バッガがシミュレーションされるシステム内のメモリデータを読み出したり、書き込んだりできる。またデバッグ・トランスポート・インタフェースによって、イニシエータがシステムメモリの内容をシミュレーション中に解析目的でスナップショットを取ることや、システム内のメモリのある領域を初期化することも可能である。
デフォルトのデバッグ・トランザクション型は tlm_generic_payload であり、トランザクション・
オブジェクトのコマンド、アドレス、データ長及びデータ・ポインタ・アトリビュートのみを利用する。デバッグ・トランザクションは、トランスポート・インタフェースにおける拡張と同じアプローチを取る。つまり、デバッグ・トランザクションは無視可能拡張を含むかもしれないが、必須拡張の場合は新しいプロトコル型クラスを定義する必要がある（tlm_generic_payload の型
定義の内容を含む 6.2.2 節 新しいプロトコル型クラスの定義を参照）。
4.3.2 クラス定義
namespace tlm {template <typename TRANS = tlm_generic_payload>class tlm_transport_dbg_if : public virtual sc_core::sc_interface{
public:virtual unsigned int transport_dbg(TRANS& trans) = 0;};
} // namespace tlm

4.3.3 TRAN テンプレート引数と tlm_generic_payload クラスa) tlm_transport_dbg_if テンプレートはデバッグ・トランザクション・クラスの型でパラメタライズされている。
b) デバッグ・トランザクション・クラスには、デバッグ・アクセスに必要なコマンド、アドレス、
データ長及びデータ・ポインタをターゲットに教えるためのアトリビュートが含まれる。基本プ
ロトコルの場合、これらは汎用ペイロードの対応するアトリビュートである。
c) TRANS テンプレート引数のデフォルト値は tlm_generic_payload クラスである。
d) 相互利用性を最大化するために、デバッグ・トランザクション・クラスは tlm_generic_payload
であるべき。必須拡張や他のトランザクション型を使えば、相互利用性が制限される。
e) もしアプリケーションがデバッグ・トランザクションにさらにアトリビュートを追加する必要がある場合には、関連性のないトランザクション・クラスに置き換えるよりも汎用ペイロードを拡張する方法を推奨する。その拡張が無視不可能の場合には、新しいプロトコル型クラスを定義する必要がある。
4.3.4 ルールa) transport_dbg への呼び出しは、通常のトランザクションで利用されるトランスポート・イン
タフェースと同じフォワード･パスに従う。
b) trans 引数はデバッグ・トランザクション・オブジェクトへの参照渡しである。
c) イニシエータはデバッグ・トランザクション・オブジェクトを生成し、管理する必要がある。
また transport_dbg への引数で渡す前にオブジェクトの適切なアトリビュートを設定する必要がある。
d) トランザクション・オブジェクトのコマンド・アトリビュートはイニシエータによって要求されているデバッグ・アクセスの種類（TLM_READ_COMMAND はターゲットへの読み込みアクセス、
TLM_WRITE_COMMAND はターゲットへの書き込みアクセス）を示すために設定される。
e) アドレス・アトリビュートはイニシエータによって読み込みまたは書き込みされる領域の最初のアドレスに設定される。
f) フォワード・パスに沿ってデバッグ・トランザクション・オブジェクトを通るインターコネク
ト・コンポーネントで、同じソケットの対応するトランスポート・インタフェースに、トランザ
クション・オブジェクトのアドレス属性をデコード及び必要に応じて修正されるべきである。例
えば、インターコネクト・コンポーネントで、ターゲットアドレス幅とシステム・メモリマッ上の場所に従ってアドレスをマスク（上位ビットを削減）する必要がある。
g) インターコネクト・コンポーネントでは、アドレッシング・エラーを検知した場合
transport_dbg 呼び出しを通過させる必要はない。
- 148 -h) アドレス・アトリビュートは、もしデバッグ・ペイロードが複数のインターコネクト・コンポ
ーネントを通って転送されれば、複数回修正されているかもしれない。デバッグ・ペイロードがイニシエータに戻ってきた時には、アドレス・アトリビュートのもともとの値は上書きされているかもしれない。
i) データ長アトリビュートはイニシエータによって読み込むまたは書き込むバイト数に設定される。
j) データ・ポインタ・アトリビュートはイニシエータによってターゲットにコピーされる値（書き込み時）またはターゲットからコピーされる値（読み込み時）の配列のアドレスに設定される。
この配列はイニシエータによって割り当てられ、transport_dbg から戻ってくる前に削除されない。配列サイズは少なくともデータ長アトリビュートの値と同じである。
k) もし可能であれば、ターゲットにおける transport_dbg の実装は、指定されたアドレスを使って（インターコネクトを通してアドレス変換後に）指定されたバイト数を読み込みまたは書き込
むようにする。
l) トランスポート・インタフェースと一緒に利用されたときに、データ配列は汎用ペイロードのデータ配列と同じ構成を持つ。transport_dbg の実装は、ターゲット内のローカル・データ・ス
トレージの構成と汎用ペイロードの構成間で変換する必要がある。
m) 基本プロトコルの場合、イニシエータはコマンド、アドレス、データ長及びデータ・ポインタ
以外の汎用ペイロードのアトリビュートを設定する必要はない。ターゲットとインターコネク
ト・コンポーネントは他のすべてのアトリビュートを無視してもよい。特に、応答ステータス・
アトリビュートは無視される。
n) イニシエータは一つの呼び出しから次の呼び出し、デバッグ・トランスポート・インタフェー
ス、トランスポート・インタフェース及び DMI に渡る呼び出しでトランザクション・オブジェク
トを再利用してもよい。
o) transport_dbg は、実際に読み込みまたは書き込みしたバイト数の合計を返す。それは
num_bytes よりも少ないことがある。もしターゲットが実行できない時には、0 の値を返す。
p) transport_dbg は、待ち(wait)を呼ばない、イベント通知を生成しない、ターゲットやインターコネクト・コンポーネントへの副作用がない。
5. 結合インタフェースとソケット
5.1 統合インタフェース
5.1.1 イントロダクション• フォワード・トランスポート I/F 、バックワード・トランスポート I/F は、TLM-2 コア・イン
タフェースをグループ化している。これは、イニシエータ/ターゲット・ソケットによりグループ化される。
• コア・インタフェースには、トランスポート、DMI、デバッグ・トランスポート・インタフェー
スを含むが、TLM-1 コア・インタフェースは含まない。
• フォワード I/F は、イニシエータ・ソケットからターゲット・ソケットへのフォワード・パス
におけるメソッド呼び出しを提供する。バックワード I/F は、ターゲット・ソケットからイニシエータ・ソケットへのバックワード・パスにおけるメソッド呼び出しを提供する。ブロッキ
ング・トランスポート I/F とデバッグ・トランスポート I/F はバックワード・パスを必要としない。
• 標準のイニシエータ・ソケットやターゲット・ソケットに関連のない新しいソケットクラスを定義することは、技術的には可能であるが、相互利用性の観点からは推奨しない。一方、標準のソケットクラスから新しいソケットクラスを派生させる方法は、推奨する。
• 結合された I/F のテンプレートは、プロトコル・タイプ・クラスでパラメタライズされる。プ
ロトコル・タイプ・クラスは、フォワード I/F、バックワード I/F で使われるタイプ、すなわ
ちペイロード・タイプとフェーズ・タイプを定義する。プロトコル・タイプ・クラスは、特定のプロトコルに関連付けられる。デフォルトのプロトコル・タイプは tlm_base_protocol_typesである。
5.1.2 クラス定義
namespace tlm {// The default protocol types class:struct tlm_base_protocol_types{- 149 -

typedef tlm_generic_payload tlm_payload_type;typedef tlm_phase tlm_phase_type;};// The combined forward interface:template< typename TYPES = tlm_base_protocol_types >class tlm_fw_transport_if: public virtual tlm_fw_nonblocking_transport_if<typename TYPES::tlm_payload_type ,typename TYPES::tlm_phase_type>, public virtual tlm_blocking_transport_if< typename TYPES::tlm_payload_type>, public virtual tlm_fw_direct_mem_if< typename TYPES::tlm_payload_type>, public virtual tlm_transport_dbg_if< typename TYPES::tlm_payload_type>{};// The combined backward interface:template < typename TYPES = tlm_base_protocol_types >class tlm_bw_transport_if: public virtual tlm_bw_nonblocking_transport_if<typename TYPES::tlm_payload_type ,typename TYPES::tlm_phase_type >, public virtual tlm_bw_direct_mem_if{};} // namespace tlm

5.2 イニシエータ・ソケットとターゲット・ソケット
5.2.1 イントロダクション• ソケット：port と export を組み合わせたもの— ソケットの種類• イニシエータ・ソケット：フォワード・パス用 port とバックワード・パス用 export• ターゲット・ソケット：フォワード・パス用 export とバックワード・パス用 port
— ソケットは、port と export を接続先の port と export とをバインドする機能を持つ。
— 階層をまたいでバインドを行う場合は、順序に注意が必要。
— アプリケーションが通常使用するソケット• tlm_initiator_socket• tlm_target_socket— これらのソケットは、プロトコル・タイプ・クラスでパラメタライズされる。
— ソケットは、プロトコル・タイプが同じである場合にのみバインド可能となる。デフォルトのプロトコル・タイプは tlm_base_protocol_types である。
— 新規にプロトコル・タイプを定義する場合は、汎用ペイロードを使用するかどうかに関わらず、新しいプロトコル・タイプ・クラスを持つ結合された I/F テンプレートをインスタンス
化するべきである。
• ソケットの利点
a. フォワード・パス、バックワード・パスに対するトランスポート、ダイレクトメモリ I/F、
デバッグ・トランスポート I/F を 1 つのオブジェクトにグループ化する。
b. フォワード・パスとバックワード・パスそれぞれの port と export を、 1 回の呼び出しでバインドするメソッドを提供。
c. 互換性のないプロトコル・タイプでパラメタライズされたソケットに対する、強力なタイ
プ・チェック機能を提供。
d. トランザクションを中断させるために利用可能なバス幅パラメタを持つ。
• tlm_initiator_socket と tlm_target_socket クラスは、インタオペラビリティ・レイヤに属する。更に、ユーティリティ・ネームスペース内に便利ソケットとして知られる派生ソケットが定義されている。
5.2.2 クラス定義
namespace tlm {// Abstract base class for initiator sockets
template <unsigned int BUSWIDTH = 32,
typename FW_IF = tlm_fw_transport_if<>,
typename BW_IF = tlm_bw_transport_if<>>class tlm_base_initiator_socket_b- 150 -

{public:virtual ~tlm_base_initiator_socket_b() {}virtual sc_core::sc_port_b<FW_IF> & get_base_port() = 0;virtual BW_IF & get_base_interface() = 0;virtual sc_core::sc_export<BW_IF> & get_base_export() = 0;};// Abstract base class for target sockets
template <unsigned int BUSWIDTH = 32,
typename FW_IF = tlm_fw_transport_if<>,
typename BW_IF = tlm_bw_transport_if<>>class tlm_base_target_socket_b{
public:virtual ~tlm_base_target_socket_b();
virtual sc_core::sc_port_b<BW_IF> & get_base_port() = 0;virtual sc_core::sc_export<FW_IF> & get_base_export() = 0;virtual FW_IF & get_base_interface() = 0;};// Base class for initiator sockets, providing binding methods
template <unsigned int BUSWIDTH = 32,
typename FW_IF = tlm_fw_transport_if<>,
typename BW_IF = tlm_bw_transport_if<>,
int N = 1,
sc_core::sc_port_policy POL = sc_core::SC_ONE_OR_MORE_BOUND>
class tlm_base_initiator_socket : public tlm_base_initiator_socket_b<BUSWIDTH, FW_IF, BW_IF>,
public sc_core::sc_port<FW_IF, N, POL>{
public:typedef FW_IF fw_interface_type;typedef BW_IF bw_interface_type;typedef sc_core::sc_port<fw_interface_type, N, POL> port_type;typedef sc_core::sc_export<bw_interface_type> export_type;typedef tlm_base_target_socket<BUSWIDTH, fw_interface_type, bw_interface_type, N ,POL >target_socket_type;typedef tlm_base_target_socket_b<BUSWIDTH, fw_interface_type, bw_interface_type>base_target_socket_type;typedef tlm_base_initiator_socket_b<BUSWIDTH, fw_interface_type, bw_interface_type>base_type;
tlm_base_initiator_socket();explicit tlm_base_initiator_socket(const char* name);
unsigned int get_bus_width() const;
void bind(base_target_socket_type& s);
void operator() (base_target_socket_type& s);
void bind(base_type& s);
void operator() (base_type& s);
void bind(bw_interface_type& ifs);
void operator() (bw_interface_type& s);// Implementation of pure virtual functions of base classvirtual sc_core::sc_port_b<FW_IF> & get_base_port() { return *this; }virtual BW_IF & get_base_interface() { return m_export; }virtual sc_core::sc_export<BW_IF> & get_base_export() { return m_export; }protected:
export_type m_export;};// Base class for target sockets, providing binding methods
template <- 151 -

unsigned int BUSWIDTH = 32,
typename FW_IF = tlm_fw_transport_if<>,
typename BW_IF = tlm_bw_transport_if<>,
int N = 1,
sc_core::sc_port_policy POL = sc_core::SC_ONE_OR_MORE_BOUND>
class tlm_base_target_socket : public tlm_base_target_socket_b<BUSWIDTH, FW_IF, BW_IF>,
public sc_core::sc_export<FW_IF>{
public:typedef FW_IF fw_interface_type;typedef BW_IF bw_interface_type;typedef sc_core::sc_port<bw_interface_type, N, POL> port_type;typedef sc_core::sc_export<fw_interface_type> export_type;typedef tlm_base_initiator_socket_b<BUSWIDTH, fw_interface_type, bw_interface_type>base_initiator_socket_type;typedef tlm_base_initiator_socket<BUSWIDTH, fw_interface_type, bw_interface_type, N, POL>
initiator_socket_type;typedef tlm_base_target_socket_b<BUSWIDTH, fw_interface_type, bw_interface_type>base_type;
tlm_base_target_socket();explicit tlm_base_target_socket(const char* name);
unsigned int get_bus_width() const;
void bind(base_initiator_socket_type& s);
void operator() (base_initiator_socket_type& s);
void bind(base_type& s);
void operator() (base_type& s);
void bind(fw_interface_type& ifs);
void operator() (fw_interface_type& s);
int size() const;
bw_interface_type* operator-> ();bw_interface_type* operator[] (int i);// Implementation of pure virtual functions of base classvirtual sc_core::sc_port_b<BW_IF> & get_base_port() { return m_port; }virtual FW_IF & get_base_interface() { return *this; }virtual sc_core::sc_export<FW_IF> & get_base_export() { return *this; }protected:
port_type m_port;};// Principle initiator socket, parameterized with protocol types classtemplate <unsigned int BUSWIDTH = 32,
typename TYPES = tlm_base_protocol_types,
int N = 1,
sc_core::sc_port_policy POL = sc_core::SC_ONE_OR_MORE_BOUND>
class tlm_initiator_socket : public tlm_base_initiator_socket <BUSWIDTH, tlm_fw_transport_if<TYPES>, tlm_bw_transport_if<TYPES>, N, POL>{
public:tlm_initiator_socket();explicit tlm_initiator_socket(const char* name);};// Principle target socket, parameterized with protocol types classtemplate <unsigned int BUSWIDTH = 32,
typename TYPES = tlm_base_protocol_types,
int N = 1,
sc_core::sc_port_policy POL = sc_core::SC_ONE_OR_MORE_BOUND>- 152 -

class tlm_target_socket : public tlm_base_target_socket <BUSWIDTH, tlm_fw_transport_if<TYPES>, tlm_bw_transport_if<TYPES>, N, POL>{
public:tlm_target_socket();explicit tlm_target_socket(const char* name);};} // namespace tlm

5.2.3 tlm_base_initiator_socket_b と tlm_base_target_socket_ba. 抽象ベースクラス tlm_base_initiator_socket_b と tlm_base_target_socket_b は、複数の純粋仮想関数を備えている。これらはソケットと関連付けられた port、export、インタフェースオ
ブジェクトを返すためのもので、派生クラスで上書きされる必要がある。
b. これらソケットは、通常アプリケーションから直接使われることはない。
5.2.4 tlm_base_initiator_socket と tlm_base_target_socket
a. tlm_initiator_socket クラスでは、コンストラクタで指定されたキャラクタ文字列を、ベースクラスである sc_port のコンストラクタに対して引き渡し、インスタンス名として設定する。
また、同じ文字列に”_export”を付加した名前を、backward パスの sc_export に対してインス
タンス名として設定する。これらは sc_gen_unique_name の呼び出しにより設定される。
e.g.) tlm_initiator_socket(“foo”)と指定→ sc_port ：foo
→ sc_export：foo_exporte.g.) デフォルト→ sc_port ： sc_gen_unique_name(“tlm_base_initiator_socket”)→ sc_export: sc_gen_unique_name("tlm_initiator_socket_export")
b. tlm_target_socket クラスでは、コンストラクタで指定されたキャラクタ文字列を、ベースクラスである sc_export のコンストラクタに対して引き渡し、インスタンス名として設定する。また、同じ文字列に”_port”を付加した名前を、sc_port に対してインスタンス名として設定する。
これらは sc_gen_unique_name により設定される。
e.g.) tlm_target_socket(“foo”)と指定→ sc_export：foo→ sc_port ：foo_porte.g.) デフォルト→ sc_port ： sc_gen_unique_name("tlm_base_target_socket")→ sc_export: sc_gen_unique_name("tlm_target_socket_port")c. get_bus_width メソッドは、テンプレート引数 BUSWIDTH の値を返す。
d. テンプレート引数 BUSWIDTH は、ソケットを介して転送される、個々のデータ・ワードのワード長を決定するもので、ワード中のビット数で表される。バースト転送では、BUSWIDTH は各ビー
ト中のビット数を決定する。本アトリビュートの厳密な解釈はトランザクション・タイプに依存する。汎用ペイロードにおける BUSWIDTH の意味は、「6.11 データ長アトリビュート」を参照。
e. ソケットとソケットをバインドする場合、二つのソケットは同一の BUSWIDTH 値を持たなければならない。
f. bind、operator（）メソッドがソケットを引数とする場合、メソッドが属するソケット・イン
スタンスが、引数で渡されたソケット・インスタンスの当該メソッドにバインドされる。
g. bind、operator（）メソッドがインタフェースを引数とする場合、メソッドが属するソケット・
インスタンスの export が、引数で渡されたチャネル･インスタンスにバインドされる（チャネルはインタフェースを実装するクラスを表す SystemC 用語）。
h. イニシエータ・ソケットをターゲット・ソケットにバインドする場合、bind、operator()メソ
ッドは、イニシエータ・ソケットの port をターゲット・ソケットの export にバインドする。また、ターゲット・ソケットの port とイニシエータ・ソケットの export をバインドする。これは、双方のソケットが同じ階層に置かれている場合に適用される。
i. イニシエータ・ソケットはターゲット・ソケットに対して、どちらのソケットの bind メソッド、または operator()メソッドでも、バインドすることができる。
j. イニシエータ・ソケットをイニシエータ・ソケットにバインドする場合、または、ターゲット・
ソケットをターゲット・ソケットにバインドする場合、bind、operator()メソッドは、それぞれ- 153 -

のソケットの port と port をバインドする。また、それぞれのソケットの export と export をバインドする。これは、階層をまたぐバインド、すなわち、子ソケットから親ソケット、または、
親ソケットから子ソケットへ接続される場合、トランザクションがモジュール階層上下に受け渡される場合に適用される。
k. 階層バインディングにおいては、正しい順序でバインドする必要がある。イニシエータ・ソケ
ットをイニシエータ・ソケットにバインドする場合は、子ソケットが親ソケットに対してバイン
ドされなければならない。ターゲット・ソケットをターゲット・ソケットにバインドする場合は、
親ソケットが子ソケットに対してバインドされなければならない。このルールは、
tlm_base_initiator_socket が sc_port から派生しており、tlm_base_target_socket が sc_exportから派生していることと一致している。階層をさかのぼる場合は、port から port へ、トップ階層においては port から export へ、階層を下がる場合は export から export へバインドされなけ
ればならない。
l. tlm_base_initiator_socket と tlm_base_target_socket の二つのソケットを相互にバインドする場合、フォワード・インタフェース・タイプ、バックワード・インタフェース・タイプ、バ
ス幅は同じでなければならない。
m. ターゲット・ソケットの size メソッドは、バックワード・パスのターゲット・ソケットのポートの size メソッドを呼び出し、そのポートの size で返される値を返す。
n. ターゲット・ソケットの operator->メソッドは、バックワード・パスのターゲット・ソケッ
トのポートの operator->メソッドを呼び出し、そのポートの operator->で返される値を返す。
o. ターゲット・ソケットの operator[]メソッドは、バックワード・パスのターゲット・ソケッ
トのポートの operator[]メソッドを同じ引数で呼び出し、そのポートの operator[]で返される値を返す。
p. tlm_base_initiator_socket と class tlm_base_target_socket は、マルチ・ソケットとして振舞う。すなわち、一つのイニシエータ・ソケットは、複数のターゲット・ソケットとバインドすることができ、一つのターゲット・ソケットは、複数のイニシエータ・ソケットとバインドすることができる。インデックスは、bind や operator()メソッドが呼ばれた順序に依存する。
q. tlm_base_initiator_socket または tlm_base_target_socket が複数回バインドされた場合、operator[]メソッドは接続先の対応するオブジェクトを指定する目的に使用できる。インデック
ス値は bind または operator()メソッドがよびだされた順序に依存する。しかしながら、受け取り側のソケットは、呼び出し側を特定するメカニズムを持たないため、受け取り側のインタフェース・メソッド呼び出しは、anonymous となる。このメカニズムについては、便利ソケットの側で提供される。「5.3.4 マルチソケット」を参照。
r. 例えば、一つのソケットが、二つのターゲットにバインドされる場合を考える。二つの呼び出
し、socket[0]->nb_transport_fw(...)、socket[1]->nb_transport_fw()は、ターゲットを区別することはできるが、これら二つのターゲットからの nb_transport_bw()は、呼び出し側は区別することができない。
s. 仮想メソッド get_base_port と get_base_export は、ソケットの port と export のオブジェク
トを返す。仮想メソッド get_base_interface は、イニシエータ・ポートの場合は export オブジ
ェクトを、ターゲット・ソケットの場合はソケット・オブジェクトそのものを返すように実装するべきである。
5.2.5 tlm_initiator_socket と tlm_target_socket
a. tlm_initiator_socket と tlm_target_socket は、プロトコル・タイプ・クラスをテンプレー
ト・パラメタとしてとる。これらのソケット(またはこれらから派生する便利ソケット)は、通常
アプリケーションが利用する。
b. tlm_initiator_socket と tlm_target_socket を相互にバインドする場合は、同じプロトコ
ル・タイプ・クラス（デフォルトは tlm_base_protocol_types）、同じバス幅を持つ必要がある。
新規プロトコル・タイプに対しても、新しいプロトコル・タイプ・クラスを定義することにより、ソケット間の強力なタイプ・チェックが可能である。これは汎用ペイロードをベースにしたプロ
トコルでなくても可能である。
例#include <systemc>#include "tlm.h"using namespace sc_core;using namespace std;

- 154 -

struct Initiator: sc_module, tlm::tlm_bw_transport_if<> // Initiator implements the bw interface{
tlm::tlm_initiator_socket<32> init_socket; // Protocol types default to base protocol
SC_CTOR(Initiator) : init_socket("init_socket") {SC_THREAD(thread);
init_socket.bind( *this ); // Initiator socket bound to the initiator itself}
void thread() { // Process generates one dummy transaction
tlm::tlm_generic_payload trans;
sc_time delay = SC_ZERO_TIME;
init_socket->b_transport(trans, delay);}virtual tlm::tlm_sync_enum nb_transport_bw(
tlm::tlm_generic_payload& trans,
tlm::tlm_phase& phase,sc_core::sc_time& t) {return tlm::TLM_COMPLETED; // Dummy implementation}
virtual void invalidate_direct_mem_ptr(sc_dt::uint64 start_range, sc_dt::uint64 end_range){ } // Dummy implementation};
struct Target: sc_module, tlm::tlm_fw_transport_if<> // Target implements the fw interface{
tlm::tlm_target_socket<32> targ_socket; // Protocol types default to base protocol
SC_CTOR(Target) : targ_socket("targ_socket") {targ_socket.bind( *this ); // Target socket bound to the target itself}
virtual tlm::tlm_sync_enum nb_transport_fw(
tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_core::sc_time& t) {return tlm::TLM_COMPLETED; // Dummy implementation}
virtual void b_transport( tlm::tlm_generic_payload& trans, sc_time& delay ){ } // Dummy implementation
virtual bool get_direct_mem_ptr(tlm::tlm_generic_payload& trans, tlm::tlm_dmi& dmi_data){ return false; } // Dummy implementation
virtual unsigned int transport_dbg(tlm::tlm_generic_payload& trans){ return 0; } // Dummy implementation};
SC_MODULE(Top1) // Showing a simple non-hierarchical binding of initiator to target{
Initiator *init;
Target *targ;
SC_CTOR(Top1) {init = new Initiator("init");targ = new Target("targ");
init->init_socket.bind(targ->targ_socket); // Bind initiator socket to target socket}};
struct Parent_of_initiator: sc_module // Showing hierarchical socket binding{
tlm::tlm_initiator_socket<32> init_socket;
Initiator* initiator;
SC_CTOR(Parent_of_initiator) : init_socket("init_socket") {initiator = new Initiator("initiator");initiator->init_socket.bind( init_socket ); // Bind initiator socket to parent initiator socket}};
struct Parent_of_target: sc_module- 155 -

{
tlm::tlm_target_socket<32> targ_socket;
Target* target;
SC_CTOR(Parent_of_target) : targ_socket("targ_socket") {target = new Target("target");targ_socket.bind( target->targ_socket ); // Bind parent target socket to target socket}};
SC_MODULE(Top2){
Parent_of_initiator *init;
Parent_of_target *targ;
SC_CTOR(Top2) {init = new Parent_of_initiator("init");targ = new Parent_of_target("targ");
init->init_socket.bind(targ->targ_socket); // Bind initiator socket to target socket at top level}};

5.3 便利ソケット
5.3.1 イントロダクション
要素モデルをより簡単に書け、追加機能性を実装した便利ソケットファミリーがある。 便利ソケ
ットは、tlm_initiator_socket クラスと tlm_target_socket クラスから派生される。便利ソケッ
トは、TLM-2 の相互利用性レイヤ(インタオペラビリティ・レイヤ） の一部ではないが、ネームスペース tlm_utils で参照できる。
• コールバック登録とは、ソケットは、インタフェース・メソッド読み出しに対応するコールバ
ック・メソッドを提供している。簡単に言うと、コールバックは、応答するオブジェクトをソケットに登録する。
• マルチポートとは、単一イニシエータ・ソケットを複数のターゲット・ソケットにバインドすることができる。また、逆に単一ターゲット・ソケットを複数のイニシエータ・ソケットにバインドすることができる。ソケット・クラス・テンプレートは、バインド数とテンプレート・アーギュメントのバインディング方針を提供する。
• b-nb 変換とは、ターゲット・ソケットは、呼び出された b_transport 関数を nb_transport_fw
関数呼出しに変換したり、その逆をすることができる。
• タグ付けとは、インタフェース・メソッド呼び出しは、id でタグ付けをされている。id は、どのソケットに到着したかを示す。
• 階層バインドとは、ソケットは、階層化されている状態で、イニシエータ・ソケットからイニシエータ・ソケット、またイニシエータ・ソケットからターゲットにバインドできる。
クラス名
コールバ マルチポ b/nb 変換 タグ付け 階層バイ
ック登録
ート
ンド
tlm_initiator_socket
no
yes
no
yes
tlm_target_socket
no
yes
no
no
yes
simple_initiator_socket
yes
no
no
no
simple_initiator_socket_tagged
yes
no
yes
no
simple_target_socket
yes
no
yes
no
no
simple_target_socket_tagged
yes
no
yes
yes
no
passthrough_target_socket
yes
no
no
no
no
passthrough_target_socket_tagged
yes
no
no
yes
no
multi_passthrough_initiator_socket
yes
yes
yes
yes
multi_passthrough_target_socket
yes
yes
no
yes
yes
5.3.2 シンプル・ソケット
5.3.2.1 イントロダクション
シンプル・ソケットは、使用するのがとても簡単なので”シンプル・ソケット”と呼ぶ。 シンプ
ル・ソケットは、互利用性レイヤ・ソケット tlm_initiator_socket と tlm_target_socket から派生し、そのタイプを持つソケットに直接バインドできる。
- 156 -

シンプル・ソケットは、双方向にバインドする代わりに、コールバック関数を登録する方法を提供する。コールバック関数は、インタフェース・メソッド呼び出しが到着する毎に、呼び出される。コールバック・メソットは、ソケットによってサポートされた、関数登録のメソッドと言える。
ユーザは、あらゆるインタフェース・メソッド対応する為、シンプル・ソケットにすべてのコー
ルバック関数を登録する必要があると考えるかもしれない。しかし、強制されていない。例えば、
シンプル・ターゲット・ソケットにおいては、ユーザは b_transport 関数と nb_transport_fw 関
数の両方、あるいは片方を登録するだけで、自動的に、登録されていないインタフェース・メソ
ッドを、登録されたインタフェース・メソッドに変換できる。この変換過程は、重要である。これは、イニシエータとターゲットが尊重する基本プロトコルの規則に依存している。
passthrough_target_socket は、simple_target_socket の一種で、ブロッキングとノンブロッキ
ング呼び出しの間の変換をサポートしていない。
現在、シンプル・ソケットインプリメンテーションとして、ダイナミックプロセスを利用している。したがって、OSCI(proof-of-concept)SystemC シミュレータの現在のリリースでは、シンプ
ル・ソケットを使用しているアプリケーションをコンパイルする際、 SystemC のヘッダー・ファ
イルをインクルードする前に、SC_INCLUDE_DYNAMIC_PROCESSES マクロを定義する必要がある。
5.3.2.2 クラス定義
namespace tlm_utils {template <typename MODULE,
unsigned int BUSWIDTH = 32,
typename TYPES = tlm::tlm_base_protocol_types>
class simple_initiator_socket : public tlm::tlm_initiator_socket<BUSWIDTH, TYPES>{
public:typedef typename TYPES::tlm_payload_type transaction_type;typedef typename TYPES::tlm_phase_type phase_type;typedef tlm::tlm_sync_enum sync_enum_type;
explicit simple_initiator_socket(const char* n = "simple_initiator_socket");void register_nb_transport_bw(
MODULE* mod,sync_enum_type (MODULE::*cb)(transaction_type&, phase_type&, sc_core::sc_time&));void register_invalidate_direct_mem_ptr(
MODULE* mod,void (MODULE::*cb)(sc_dt::uint64, sc_dt::uint64));};
template <typename MODULE,
unsigned int BUSWIDTH = 32,
typename TYPES = tlm::tlm_base_protocol_types>
class simple_target_socket : public tlm::tlm_target_socket<BUSWIDTH, TYPES>{
public:typedef typename TYPES::tlm_payload_type transaction_type;typedef typename TYPES::tlm_phase_type phase_type;typedef tlm::tlm_sync_enum sync_enum_type;
explicit simple_target_socket(const char* n = "simple_target_socket");tlm::tlm_bw_transport_if<TYPES> * operator ->();
void register_nb_transport_fw(
MODULE* mod,sync_enum_type (MODULE::*cb)(transaction_type&, phase_type&, sc_core::sc_time&));void register_b_transport(
MODULE* mod,void (MODULE::*cb)(transaction_type&, sc_core::sc_time&));void register_transport_dbg(
MODULE* mod,unsigned int (MODULE::*cb)(transaction_type&));- 157 -

void register_get_direct_mem_ptr(
MODULE* mod,bool (MODULE::*cb)(transaction_type&, tlm::tlm_dmi&));};template <typename MODULE,
unsigned int BUSWIDTH = 32,
typename TYPES = tlm::tlm_base_protocol_types>
class passthrough_target_socket : public tlm::tlm_target_socket<BUSWIDTH, TYPES>{
public:typedef typename TYPES::tlm_payload_type transaction_type;typedef typename TYPES::tlm_phase_type phase_type;typedef tlm::tlm_sync_enum sync_enum_type;
explicit passthrough_target_socket(const char* n = "passthrough_target_socket");void register_nb_transport_fw(
MODULE* mod,sync_enum_type (MODULE::*cb)(transaction_type&, phase_type&, sc_core::sc_time&));void register_b_transport(
MODULE* mod,void (MODULE::*cb)(transaction_type&, sc_core::sc_time&));void register_transport_dbg(
MODULE* mod,unsigned int (MODULE::*cb)(transaction_type&));void register_get_direct_mem_ptr(
MODULE* mod,bool (MODULE::*cb)(transaction_type&, tlm::tlm_dmi&));};} // namespace tlm_utils

5.3.2.3 規則a) シンプル・イニシエータ・ソケット、シンプル・ターゲット・ソケットまたはパススルー・タ
ーゲット・ソケットは、階層バインドできない。コールバック関数登録によって、入ってきたイ
ンタフェース・メソッドだけを実行する。
b) シンプル・イニシエータ・ソケットは、bind()か operator()どちらかの呼び出しによって、正確に同じ動作をするよう、シンプル・ターゲット・ソケットにバインドできる。
c) nb_transport_fw が登録されているシンプル・ターゲット・ソケットでは、b_transport コー
ルバック関数の登録は強制されない。入力された b_transport 呼び出しは、自動的に登録されている nb_transport_fw 呼び出しに変換される。(5.3.2.4 シンプル・ターゲット・ソケット b/nb
変換を参照)d) b_transport が登録されているシンプル・ターゲット・ソケットでは、nb_transport_fw コー
ルバック関数の登録は強制されない。入力された nb_transport_fw 呼び出しは、自動的に登録されている b_transport 呼び出しに変換される。
e) ターゲットのシンプル・ターゲット・ソケットに b_transport も nb_transport_fw も登録されていない場合、インタフェース・メソッドの応答は、実行時エラーになる。(コンパイルエラーにはならない)
f) ターゲットは、b_transport と nb_transport_fw コールバック関数をパススルー・ターゲット・
ソケットに登録するべきである。もし、そうしないとインタフェース・メソッドの応答時に、実行時エラーとなる。
g) 入力された transport_dbg 呼び出しに対し 0 の値をリターンする場合、ターゲットはシンプ
ル・ターゲット・ソケットかパススルー・ターゲット・ソケットに transport_dbg コールバック
関数の登録は強制されない。
h) 入力された get_direct_mem_ptr が false 値をリターンする場合、ターゲットはシンプル・タ
ーゲット・ソケットかパススルー・ターゲット・ソケットに get_direct_mem_ptr コールバック関
数の登録は強制されない。
i) イニシエータは、nb_transport_bw コールバック関数をシンプル・イニシエータ・ソケットに登録するべきである。もし、そうしないと nb_transport_bw メソッドの応答時に、実行時エラー- 158 -となる。
j) イニシエータは、invalidate_direct_mem_ptr を使わないのであれば、シンプル・イニシエー
タ・ソケットで invalidate_direct_mem_ptr の登録を強制されない。
5.3.2.4 シンプル・ターゲット・ソケット b/nb 変換a) b_transport か nb_transport_fw メソッドが simple_target_socket クラスのソケットを通して呼ばれて、どんな対応するコールバック関数も登録されていない場合、シンプル・ターゲット・
ソケットは、２つのインタフェースを結ぶアダプタのように振舞う。
b) シンプル・ターゲット・ソケットがアダプタとして機能する時、イニシエータの観点から、また、ターゲットにある b_transport か nb_transport_fw メソッドをインプリメントした観点から、
基本プロトコルの規則を尊重する。
c) ソケットは、インタフェース・メソッドに何ら変更を加えなければ、トランザクション・オブ
ジェクトを通り抜けるだけで、新しいトランザクション・オブジェクトを生成しない。
d) ターゲットに登録されているのが、nb_transport_fw コールバック関数だけの場合、イニシエータからコールされた b_transport メソッドがまだ進行中に、イニシエータが、nb_transport_fwと呼ぶことが許可されない。これはシンプル・ターゲット・ソケットの現在のインプリメンテー
ションの制限である。

図 12 Simple target socket nb/b adaptere) 図 12 は、イニシエータがどう nb_transport_fw メソッドをコールする様子を示している。イ
ニシエータは nb_transport_fw メソッドをコールするが、ターゲットは、シンプル・ターゲット
ケットに b_transport コールバック関数が登録されているだけである。
イニシエータは BEGIN_REQを送る。そして、ソケットは TLM_ACCEPTED をイニシエータにリターンする。ソケットは、次に、
b_transport をコールして、リターンされたら、BEGIN_RESP をイニシエータにリターンする。最後は、イニシエータは TLM_COMPLETED をソケットにリターンする。SystemC では、ノンブロッキ
ング・メソッドから直接ブロッキング・メソッドを呼ぶのが許されない。したがって、ソケット
は、nb_transport_fw メソッドから b_transport 関数をコールするのではなく、別のプロセスから b_transport をコールする。
f) 図 12 は 1 つの可能なシナリオを示している。他の例は、図の一番最後の遷移で、イニシエー
タは TLM_COMPLETED ではなく、TLM_ACCEPTED をリターンした場合である。その場合、ソケットはイニシエータからこの後に END_RESP を受け取ると予想される。また、ターゲットは、b_transportが呼ばれた場合、wait を発行する場合もある。
g) 図 13 は、イニシエータは、b_transport メソッドをコールする様子を示している。イニシエータは、b_transport メソッドをコールするが、ターゲットでは、シンプル・ターゲット・ソケ
ットに nb_transport_fw コールバック関数が登録されている。イニシエータは、b_transport メ
ソッドをコールする。そして、ソケットとターゲットは、基本プロトコルの規定に従って、- 159 -

nb_transport_fw を使いハンドシェークする。ターゲットは、END_RESP を送るかもしれない。あるいは、いきなり BEGIN_RESP フェーズまでジャンプするかもしれない。ソケットは、コールされた nb_transport_bw が BEGIN_RESP であるのを見て TLM_COMPLETED をリターンする。

図 13 Simple target socket b/nb adapter
例：#define SC_INCLUDE_DYNAMIC_PROCESSES#include "tlm.h"#include "tlm_utils/simple_initiator_socket.h" // Header files from utilities#include "tlm_utils/simple_target_socket.h"
struct Initiator: sc_module{
tlm_utils::simple_initiator_socket<Initiator,32,tlm::tlm_base_protocol_types> socket;
SC_CTOR(Initiator): socket("socket") // Construct and name simple socket{ // Register callbacks with simple socket
socket.register_nb_transport_bw( this, &Initiator::nb_transport_bw );socket.register_invalidate_direct_mem_ptr( this, &Initiator::invalidate_direct_mem_ptr );}virtual tlm::tlm_sync_enum nb_transport_bw(
tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) {return tlm::TLM_COMPLETED; // Dummy implementation}
virtual void invalidate_direct_mem_ptr(sc_dt::uint64 start_range,sc_dt::uint64 end_range){ } // Dummy implementation};
struct Target: sc_module // Target component{
tlm_utils::simple_target_socket<Target, 32, tlm::tlm_base_protocol_types> socket;
SC_CTOR(Target): socket("socket") // Construct and name simple socket{ // Register callbacks with simple socket
socket.register_nb_transport_fw( this, &Target::nb_transport_fw );socket.register_b_transport( this, &Target::b_transport );socket.register_get_direct_mem_ptr( this, &Target::get_direct_mem_ptr );socket.register_transport_dbg( this, &Target::transport_dbg );}virtual void b_transport( tlm::tlm_generic_payload& trans, sc_time& delay ){ } // Dummy implementation
virtual tlm::tlm_sync_enum nb_transport_fw(
tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) {return tlm::TLM_ACCEPTED; // Dummy implementation}- 160 -

virtual bool get_direct_mem_ptr( tlm::tlm_generic_payload& trans,tlm::tlm_dmi& dmi_data){ return false; } // Dummy implementation
virtual unsigned int transport_dbg(tlm::tlm_generic_payload& r){ return 0; } // Dummy implementation};
SC_MODULE(Top){Initiator *initiator;
Target *target;
SC_CTOR(Top) {initiator = new Initiator("initiator");target = new Target("target");initiator->socket.bind( target->socket ); // Bind initiator socket to target socket}};

5.3.3 タグ付きシンプル・ソケット
5.3.3.1 イントロダクション
タグ付きシンプル・ソケットは、シンプル・ソケットの一種である。タグ付きシンプル・ソケッ
トは、コールバックが届いた時、どのソケットに到着したかを特定できる整数 id をタグとして持っている。これは、同じコールバック・メソッドが複数のイニシエータ・ソケットかマルチ・ターゲット・ソケットに登録される場合で役に立つ。
5.3.3.2 クラス定義
namespace tlm_utils {template <typename MODULE,
unsigned int BUSWIDTH = 32,
typename TYPES = tlm::tlm_base_protocol_types>
class simple_initiator_socket_tagged : public tlm::tlm_initiator_socket<BUSWIDTH, TYPES>{
public:typedef typename TYPES::tlm_payload_type transaction_type;typedef typename TYPES::tlm_phase_type phase_type;typedef tlm::tlm_sync_enum sync_enum_type;
explicit simple_initiator_socket_tagged(const char* n = "simple_initiator_socket_tagged");void register_nb_transport_bw(
MODULE* mod,sync_enum_type (MODULE::*cb)(int, transaction_type&, phase_type&, sc_core::sc_time&),int id);void register_invalidate_direct_mem_ptr(
MODULE* mod,void (MODULE::*cb)(int, sc_dt::uint64, sc_dt::uint64),
int id);};template <typename MODULE,
unsigned int BUSWIDTH = 32,
typename TYPES = tlm::tlm_base_protocol_types>
class simple_target_socket_tagged : public tlm::tlm_target_socket<BUSWIDTH, TYPES>{
public:typedef typename TYPES::tlm_payload_type transaction_type;typedef typename TYPES::tlm_phase_type phase_type;typedef tlm::tlm_sync_enum sync_enum_type;typedef tlm::tlm_fw_transport_if<TYPES> fw_interface_type;typedef tlm::tlm_bw_transport_if<TYPES> bw_interface_type;typedef tlm::tlm_target_socket<BUSWIDTH, TYPES> base_type;
explicit simple_target_socket_tagged(const char* n = "simple_target_socket_tagged");
tlm::tlm_bw_transport_if<TYPES> * operator ->();
void register_nb_transport_fw(- 161 -

MODULE* mod,sync_enum_type (MODULE::*cb)(int id, transaction_type&, phase_type&, sc_core::sc_time&),int id);void register_b_transport(
MODULE* mod,void (MODULE::*cb)(int id, transaction_type&, sc_core::sc_time&),int id);void register_transport_dbg(
MODULE* mod,unsigned int (MODULE::*cb)(int id, transaction_type&),
int id);void register_get_direct_mem_ptr(
MODULE* mod,bool (MODULE::*cb)(int id, transaction_type&, tlm::tlm_dmi&),int id);};template <typename MODULE,
unsigned int BUSWIDTH = 32,
typename TYPES = tlm::tlm_base_protocol_types>
class passthrough_target_socket_tagged : public tlm::tlm_target_socket<BUSWIDTH, TYPES>{
public:typedef typename TYPES::tlm_payload_type transaction_type;typedef typename TYPES::tlm_phase_type phase_type;typedef tlm::tlm_sync_enum sync_enum_type;
explicit passthrough_target_socket_tagged(const char* n = "passthrough_target_socket_tagged");void register_nb_transport_fw(
MODULE* mod,sync_enum_type (MODULE::*cb)(int id, transaction_type&, phase_type&, sc_core::sc_time&),int id);void register_b_transport(
MODULE* mod,void (MODULE::*cb)(int id, transaction_type&, sc_core::sc_time&),int id);void register_transport_dbg(
MODULE* mod,unsigned int (MODULE::*cb)(int id, transaction_type&),
int id);void register_get_direct_mem_ptr(
MODULE* mod,bool (MODULE::*cb)(int id, transaction_type&, tlm::tlm_dmi&),int id);};} // namespace tlm_utils

5.3.3.3 規則a) タグ付きシンプル・ソケットは、int id タグが別な引数として追加されるだけで、タグ付けをされていないシンプル・ソケットと全く同じ振る舞いをする。
b) 与えられたコールバック・メソッドは、異なったタグを使用する複数のソケットとして登録できる。
c) タグ(int id)は、コールバック関数登録時のインタフェース・メソッドの最後のアーギュメン
トになる。しかし、ソケットは、コールバック関数実装の本体には最初のアーギュメントにこのタグを付ける。
d) タグ付きシンプル・ソケットは、マルチソケットではない。
e) タグ付きシンプル・ソケットは、マルチソケットや他のコンポーネントにバインドすることができない。(5.3.4 マルチソケットを参照)
5.3.4 マルチソケット
5.3.4.1 イントロダクション
マルチソケットは、タグ付きシンプル・ソケットの一種である。マルチソケットは、単一のソケ- 162 -

ットが他のコンポーネントの複数のソケットに割り当てられることを許可する。タグ付きシンプ
ル・ソケットはどのソケットを通して呼び出されたのか特定可能であるが、マルチソケットのコールバックもマルチポートのインデックス番号をタグとして、インタフェース・メソッド呼び出
しが別のコンポーネントのどのソケットから到着するかを特定できる。また、マルチソケットは、他の便利ソケットと異なり、イニシエータ、ターゲット双方で、子から親へのソケット階層バイ
ンドをサポートする。TLM-2.0 キットのマルチソケットのインプリメンテーションはブーストラ
イブラリを使用している。ユーザは、www.boost.org からブーストライブラリをダウンロードして、コンパイラのインクルードパスに適切なディレクトリを加える必要がある。
5.3.4.2 クラス定義
namespace tlm_utils {template <typename MODULE,
unsigned int BUSWIDTH = 32,
typename TYPES = tlm::tlm_base_protocol_types,
unsigned int N=0,
sc_core::sc_port_policy POL = sc_core::SC_ONE_OR_MORE_BOUND>
class multi_passthrough_initiator_socket : public multi_init_base< BUSWIDTH, TYPES, N, POL>{
public:typedef typename TYPES::tlm_payload_type transaction_type;typedef typename TYPES::tlm_phase_type phase_type;typedef tlm::tlm_sync_enum sync_enum_type;typedef multi_init_base<BUSWIDTH, TYPES, N, POL> base_type;typedef typename base_type::base_target_socket_type base_target_socket_type;multi_passthrough_initiator_socket(const char* name);~multi_passthrough_initiator_socket();void register_nb_transport_bw(
MODULE* mod,sync_enum_type (MODULE::*cb)(int, transaction_type&, phase_type&, sc_core::sc_time&));void register_invalidate_direct_mem_ptr(
MODULE* mod,void (MODULE::*cb)(int, sc_dt::uint64, sc_dt::uint64));// Override virtual functions of the tlm_initiator_socket:
virtual tlm::tlm_bw_transport_if<TYPES>& get_base_interface();virtual sc_core::sc_export<tlm::tlm_bw_transport_if<TYPES> >& get_base_export();void bind(base_target_socket_type& s);
void operator() (base_target_socket_type& s);// SystemC standard callback// multi_passthrough_initiator_socket::before_end_of_elaboration must be called from// any derived classvoid before_end_of_elaboration();// Bind multi initiator socket to multi initiator socket (hierarchical bind)void bind(base_type& s);
void operator() (base_type& s);
tlm::tlm_fw_transport_if<TYPES>* operator[](int i);unsigned int size();};
template <typename MODULE,
unsigned int BUSWIDTH = 32,
typename TYPES = tlm::tlm_base_protocol_types,
unsigned int N=0,
sc_core::sc_port_policy POL = sc_core::SC_ONE_OR_MORE_BOUND>
class multi_passthrough_target_socket : public multi_target_base< BUSWIDTH, TYPES, N, POL>{
public:typedef typename TYPES::tlm_payload_type transaction_type;typedef typename TYPES::tlm_phase_type phase_type;- 163 -

typedef tlm::tlm_sync_enum sync_enum_type;typedef sync_enum_type(MODULE::*nb_cb)(int, transaction_type&, phase_type&, sc_core::sc_time&);typedef void (MODULE::*b_cb)(int, transaction_type&, sc_core::sc_time&);typedef unsigned int (MODULE::*dbg_cb)(int, transaction_type& txn);
typedef bool (MODULE::*dmi_cb)(int, transaction_type& txn, tlm::tlm_dmi& dmi);
typedef multi_target_base<BUSWIDTH, TYPES, N, POL> base_type;typedef typename base_type::base_initiator_socket_type base_initiator_socket_type;typedef typename base_type::initiator_socket_type initiator_socket_type;multi_passthrough_target_socket(const char* name);~multi_passthrough_target_socket();void register_nb_transport_fw (MODULE* mod, nb_cb cb);void register_b_transport (MODULE* mod, b_cb cb);void register_transport_dbg (MODULE* mod, dbg_cb cb);void register_get_direct_mem_ptr(MODULE* mod, dmi_cb cb);// Override virtual functions of the tlm_target_socket:
virtual tlm::tlm_fw_transport_if<TYPES>& get_base_interface();virtual sc_core::sc_export<tlm::tlm_fw_transport_if<TYPES> >& get_base_export();// SystemC standard callback// multi_passthrough_target_socket::end_of_elaboration must be called from any derived classvoid end_of_elaboration();void bind(base_type& s);
void operator() (base_type& s);
tlm::tlm_bw_transport_if<TYPES>* operator[] (int i);unsigned int size();};} // namespace tlm_utils

5.3.4.3 規則a) マルチバインド能力と int id(タグ)の解釈は別として、multi_passthrough_initiator_socket
は simple_initiator_socket_tagged と同様に振舞う。そして、multi_passthrough_target_socket
もまた passthrough_target_socket_tagged と同様に振舞う。
b) クラス multi_passthrough_initiator_socket は、複数のターゲット・ソケットにバインドする１つのイニシエータ・ソケットとして、multi_passthrough_target_socket は、複数のイニシ
エータ・ソケットにバインドする１つのターゲット・ソケットとして振舞う。この２つクラステ
ンプレートは、バインド数とバインドポリシーを定義するテンプレート・パラメータを持つ。このパラメータは、sc_port テンプレートインスタンスをパラメタライズするクラスインプリメン
テーションとして使われる。
c) multi_passthrough_initiator_socket は、異なる multi_passthrough_initiator_socket と階層バインドできる。multi_passthrough_target_socket は、異なる
multi_passthrough_target_socket と階層バインドできる。
d) バインディング・オペレータは、直接 initiator-socket-to-target-socket で使える。言い換
えれば、multi_passthrough_target_socket には、クラスの tlm_target_socket とsimple_target_socket と異なって、ターゲット・ソケットをイニシエータ・ソケットに割り当てる演算子がない。
e) もし、multi_passthrough_initiator_socket か multi_passthrough_target_socket が複数回バインドされていた場合、メソッド operator [] を、 ソケットにバインドしている応答オブジ
ェクトにあてはめることができる。 インデックス値は、bind メソッドか operator()がソケットをバインドする為に呼ばれた順番で決まる。これと同じインデックス値は、コールバックで id タグを決めるのに使わる。
f) 例えば、multi_passthrough_initiator_socket が２つの別なターゲットにバインドされている場合を考えてみる。
socket[0]->nb_transport_fw(...)
socket[1]->nb_transport_fw()
は２つのターゲットに割り当てられる。これら２つのターゲットからの nb_transport_bw()メ
ソッド呼び出しはそれぞれ 0 と 1 のタグを持つ。
g) メソッドサイズは、現在接続されているマルチソケットのインスタンス数をリターンする。
SystemC のマルチポートのように、サイズがエラボレーション中すなわち、end_of_elaboration- 164 -

コールバックの前の値なら、その値は、インプリメンテーション定義の値をリターンするはずだ。
なぜなら、ポートがバインドされている時間は、インプリメンテーション定義だからである。
6. 汎用ペイロード
6.1 イントロダクション
汎用ペイロードは MMB モデルの相互利用性を高めることを目的に、モデル間の通信に必要となる
アトリビュート(コマンド、アドレス、データなど）を定義したクラスである。汎用ペイロードは全ての MMB プロトコルで必要となるアトリビュートを含んでいるわけではない。しかし、そのための拡張メカニズムが用意されている。拡張されたとしても汎用ペイロードは共通のベース型となり、異なるプロトコルを繋ぐブリッジ開発の工数低減に寄与する。
汎用ペイロードはイニシエータ・ソケット/ターゲット・ソケットの両方で使用されることが奨められる。汎用ペイロードをベースとしているか否かで異なるプトロコル型のチェックを行うことが出来る。ブロッキングとノンブロッキング・トランスポート・インタフェースの両方と共に汎用ペイロードを使用できる。また、ダイレクト・メモリ、デバック・トランスポート・インタフ
ェース共に汎用ペイロードを使用できる。その場合、制限されたアトリビュートセットだけが使用される。
6.2 拡張性と相互利用性
3 つの推奨する拡張手法がある。これらは blocking、non-blocking transport I/F のトランザク
ションテンプレート引数 TRANS と複数の I/F が組合されて定義された TYPES を置き換えることで実現するものである。
実現方法
A
B
C

TRANS
トランザクション型
tlm_generic_payload
tlm_generic_payload
ユーザ定義型

TYPES
プロトコル型
tlm_generic_payload_types
ユーザ定義型
ユーザ定義型

A→B→C の順に相互利用性が損なわれる。これら 3 つの方法で実現したモデルは、一つのシステ
ムで混在されることも考えられている。
6.2.1 無視可能な拡張を含む、Generic Payload（汎用ペイロード）を直接利用• トランザクション型は tlm_generic_payload を、プロトコル型は tlm_generic_payload_types
を指定する• 拡張部分は"無視可能"とする。"無視可能"とはインターコネクト/ターゲット共この拡張に関してエラーや転送失敗などを起こさないこと• コンパイル時に型のチェックを行うことが出来る
6.2.2 tlm_generic_payload の型を含む新しいプロトコル型の定義• トランザクション型は tlm_generic_payload であるが、プロトコル型は
tlm_base_protocol_types を用いず、独自で定義した型を利用する• コンパイル時の型チェックは行える• 拡張されたアトリビュートを"無視可能"と実現/義務化することは出来るが意味定義には十分な注意が必要• 推奨される 2 つの利用パターンがある• イニシエータ/インターコネクト/ターゲット全てが共通に同じ新しいプロトコル型を使用• 末端だけが新しいプトロコルで、その間のモデルは generic_base_protocol_types を使用• この拡張は、各モデルがそれを知る/知らないに関わらず正しく転送が行えるよう考慮が必要
6.2.3 新しいプロトコル型とトランザクション型の定義• トランザクション型、プロトコル型共新しい型を定義/利用する• この手法は実現するプロトコルと汎用ペイロードが著しくことなる場合に利用する• 相互利用性を考えるとこの手法よりは、前 2 つの手法を推奨する
6.3 Generic Payload（汎用ペイロード）アトリビュートとメソッド
汎用ペイロードクラスはプライベートなアトリビュートとそれにアクセスするパブリックはメソッドを持つ。各アトリビュートの変更は原則イニシエータが行うが、アドレスやステータスなど
はインターコネクトやターゲットが変更する場合がある。リードコマンドにおけるデータ配列はターゲットが更新する。
6.4 クラス定義
namespace tlm {- 165 -

class tlm_generic_payload;class tlm_mm_interface {public:virtual void free(tlm_generic_payload*) = 0;virtual ~tlm_mm_interface() {}};class tlm_extension_base{
public:virtual tlm_extension_base* clone() const = 0;virtual void free() { delete this; }virtual void copy_from(tlm_extension_base const &) = 0;protected:
virtual ~tlm_extension_base() {}};template <typename T>
tlm_extension : public tlm_extension_base{
public:virtual tlm_extension_base* clone() const = 0;virtual void copy_from(tlm_extension_base const &) = 0;virtual ~tlm_extension() {}const static unsigned int ID;};
enum tlm_command {TLM_READ_COMMAND,
TLM_WRITE_COMMAND,
TLM_IGNORE_COMMAND};
enum tlm_response_status {TLM_OK_RESPONSE = 1,
TLM_INCOMPLETE_RESPONSE = 0,
TLM_GENERIC_ERROR_RESPONSE = -1,
TLM_ADDRESS_ERROR_RESPONSE = -2,
TLM_COMMAND_ERROR_RESPONSE = -3,
TLM_BURST_ERROR_RESPONSE = -4,
TLM_BYTE_ENABLE_ERROR_RESPONSE = -5};
#define TLM_BYTE_DISABLED 0x0#define TLM_BYTE_ENABLED 0xff
class tlm_generic_payload {public:// Constructors and destructor
tlm_generic_payload();explicit tlm_generic_payload( tlm_mm_interface* );virtual ~tlm_generic_payload();private:// Disable copy constructor and assignment operator
tlm_generic_payload( const tlm_generic_payload& );tlm_generic_payload& operator= ( const tlm_generic_payload& );public:// Memory managementvoid set_mm( tlm_mm_interface* );bool has_mm();void acquire();void release();int get_ref_count();
void reset();void deep_copy_from( const tlm_generic_payload& ) const;
void update_extensions_from(const tlm_generic_payload & );void free_all_extensions();// Access methods- 166 -

tlm_command get_command() const;
void set_command( const tlm_command );bool is_read();void set_read();bool is_write();void set_write();sc_dt::uint64 get_address() const;
void set_address( const sc_dt::uint64 );unsigned char* get_data_ptr() const;
void set_data_ptr( unsigned char* );unsigned int get_data_length() const;
void set_data_length( const unsigned int );unsigned int get_streaming_width() const;
void set_streaming_width( const unsigned int );unsigned char* get_byte_enable_ptr() const;
void set_byte_enable_ptr( unsigned char* );unsigned int get_byte_enable_length() const;
void set_byte_enable_length( const unsigned int );// DMI hint
void set_dmi_allowed( bool );bool is_dmi_allowed() const;
tlm_response_status get_response_status() const;
void set_response_status( const tlm_response_status );std::string get_response_string();bool is_response_ok();bool is_response_error();// Extension mechanism
template <typename T> T* set_extension( T* );tlm_extension_base* set_extension( unsigned int , tlm_extension_base* );template <typename T> T* set_auto_extension( T* );tlm_extension_base* set_auto_extension( unsigned int index , tlm_extension_base* );template <typename T> void get_extension( T*& ) const;
template <typename T> T* get_extension() const;
tlm_extension_base* get_extension( unsigned int ) const;
template <typename T> void clear_extension( const T* );template <typename T> void clear_extension();template <typename T> void release_extension(T* ext);
template <typename T> void release_extension();void resize_extensions();};} // namespace tlm

6.5 汎用ペイロード・メモリ管理a) イニシエータは既存ストレージにデータ・ポインタ、バイトイネーブルポインタ・アトリビュートを設定する。ストレージはスタティック、オートマティック（stack）、ダイナミック（new）
で確保されている。トランザクションのライフタイムが完了するまで、イニシエータはこのストレージを削除しない。汎用ペイロードのデストラクタはこれら 2 つのアレイを削除しない。
b) この節に関連して 6.20 の汎用ペイロード拡張を読むこと。
c) 汎用ペイロードはメモリ管理への 2 つの異なったアプローチをサポートする。１つは明白なメ
モリ・マネージャ、もう一つはイニシエータによる臨時のメモリ管理。混在は可能である。いずれのアプローチもトランザクション・オブジェクトとその拡張の両方を管理すること。
d) メモリ・マネージャは抽象的な基底クラス tlm_mm_interface の free メソッドを実行するユー
ザによって定義されたクラスである。そのクラスは汎用ペイロード・トランザクション・オブジ
ェクトを割り当てるためにメソッドを提供する
e) メソッド set_mm、acquire、release、get_ref_count、reset はメモリ管理に存在する。汎用
ペイロードのオブジェクトはメモリ管理セットを持っていないf) イニシエータによる臨時のメモリ管理の場合、TLM-2 コア・インタフェース呼び出しの前にイ
ニシエータはトランザクション・オブジェクトのためのメモリを割り当てる。また、呼出し後にイニシエータはトランザクション・オブジェクトとその拡張オブジェクトを削除あるいはプールする。
- 167 -

g) 汎用ペイロードがブロッキング・トランスポート・インタフェース、ダイレクト・メモリ・イ
ンタフェースまたはデバッグ・トランスポート・インタフェースと共に使用されるとき、いずれのアプローチも使用される。イニシエータによる臨時のメモリ管理は十分である。メモリ・マネージャが不在のとき b_transport、get_direct_mem_ptr、または transport_dbg メソッドが、トランザクション・オブジェクトとその拡張はリターンの時に無効にされるか、または削除されると仮定するべきである。
h) 汎用ペイロードがノンブロッキング・トランスポート・インタフェースと共に使用されるとき、メモリ・マネージャは使用されるものとする。これは呼び出し元関数がイニシエータ、インターコネクト・コンポーネント、またはターゲットであることにかかわらず適用される。
i) なにも既に存在していないなら、ブロッキングからノンブロッキングへのトランスポートアダ
プターはメモリ・マネージャを設定しなければならないj) メモリ・マネージャを使用するとき、ヒープ(new か malloc で)からトランザクション・オブ
ジェクトとその拡大オブジェクトも割り当てるものとする。
k) 臨時のメモリ管理を使用するとき、トランザクション・オブジェクトとその拡大オブジェクト
はヒープまたはスタックに割り当てられるものとする。スタックに割り当てられた時、拡大オブジェクトのメモリ管理によって取られる必要があることに注意を払うこと。
l) メソッド set_mm は汎用ペイロード・オブジェクトのメモリ・マネージャを設定するものとする。引数として、アドレスが通過される。引数が null である場合、既存のメモリ・マネージャはトランザクション・オブジェクトから切り離される。また、それ自体は、削除されない。メモリ・マネージャと参照が 0 以上を数えるトランザクション・オブジェクトのために set_mm を呼ばないものとする。
m) メモリ・マネージャが用意できていた場合にだけ、メソッド has_mm が true を返すものとする。
nb_transport メソッドのボディーから呼ばれると、has_mm は true を返すはずである。
n) b_transport、get_direct_mem_ptr、または transport_dbg メソッドのボディーから呼ばれると、has_mm は true か false を返す。インターコネクト・コンポーネントは、has_mm と呼んで、トランザクションにはメモリ・マネージャがいるかどうかによる適切な行動を取る。さもなければ、インターコネクト・コンポーネントはメモリ・マネージャ(例えば、ヒープ割り付け)がいる
トランザクションのすべての義務を引き受けるものとする。そして、メモリ・マネージャ(例えば、
acquire)の存在を要求するメソッドのいずれも呼ばないだろう。
o) それぞれの汎用ペイロード・オブジェクトは参照カウントを持つ。そのデフォルト値はゼロ。
p) メソッド acquire は参照カウントの値を増加するものとする。メモリ・マネージャが不在のとき、acquire が呼ばれると、ランタイムエラーが発生する。
q) メソッド release は参照カウントの値を減少させるものとする。参照カウントの値が０となると、メモリ・マネージャ・オブジェクトの free メソッド呼んで、引数としてトランザクション・
オブジェクトのアドレスを渡す。メモリ・マネージャが不在のとき、acquire が呼ばれると、ランタイムエラーが発生する。
r) メソッド get_ref_count は参照カウントの値を返すものとする。メモリ・マネージャが不在のとき、返された値は 0 であるだろう。
s) メモリ・マネージャで、そのオブジェクトを最初にインタフェース・メソッド呼び出しの引数のとして、渡す前に、各イニシエータは、それぞれのトランザクション・オブジェクトの acquire
メソッドを呼ぶ。そして、オブジェクトはもう必要でないときに、そのトランザクション・オブ
ジェクトの release メソッドを呼ぶべきである。
t) メモリ・マネージャで、現在のインタフェース・メソッド呼び出しを超えてトランザクション・
オブジェクトのライフタイムを延長するときは、各インターコネクト・コンポーネントとターゲ
ットは acquire メソッドを呼ぶべきである。そして、オブジェクトはもう必要でないときに
release メソッドに呼ぶ。
u) 解析目的のためにトランザクション・オブジェクトのライフタイムを無期限に広げるのならば、各インターコネクト・コンポーネントとターゲットは参照カウント・メカニズムを使用するよりもトランザクション・オブジェクトのクローンを作るべきである。言い換えれば、プロトコルの正常なフェーズを超えてトランザクション・オブジェクトのライフタイムを広げるのに参照カウントを使用するべきでない。
v) メモリ・マネージャで、参照カウントが、イニシエータ自体以外のどんなコンポーネントにもトランザクション・オブジェクトの参照がまだないのを示すまで、トランザクション・オブジェ- 168 -

クトを新しいトランザクションを表すのに再使用されないものとするか、異なったインタフェー
スと共に再使用しないものとする。参照カウントが 1 と等しくなるまで、イニシエータは、トラ
ンザクション・オブジェクトのために acquire を呼ぶことを仮定する。このルールは、同じインタフェースのトランザクションの再利用、トランスポートの転送、ダイレクト・メモリ、デバッ
クトランスポート・インターフェイスの時、適用される。
w) メソッド reset は自動削除のためにマークされた拡張を削除して、対応する拡張へのポインタ
を null に設定する。各拡張は拡張オブジェクトのメソッド free と呼ぶことによって、削除されるものとする。ユーザが拡張オブジェクトのための明白なメモリ管理を提供したいなら、多分 free
メソッドをオーバーロードできる。
x) 拡張オブジェクトは set_extension コールで追加され、release_extension コールで削除される。clear_extension コールは拡張のポインタをクリアし、拡張オブジェクトを削除しない。ト
ランザクション・オブジェクトがメモリ・マネージャなしでスタックに割り当てられて、且つ拡
張オブジェクトがプールになる場合、この後者の振舞いが必要である。
y) メモリ・マネージャが不在の場合、b_transport、get_direct_mem_ptr、または transport_dbg
からコントロールを返す前に、コンポーネントが割り当てるあるいは与えられた拡張にセットするのいずれの場合でも、その同じ拡張を削除またはクリアする。たとえば、b_transport で実装され、set_mm にてトランザクション・オブジェクトをメモリ・マネージャに追加した場合のインターコネクト・コンポーネントは、トランザクション・オブジェクトとその拡張が削除されるまで、b_transport から返らない。
（下流コンポーネントも同様に拡張が既に削除されていることを仮定する）
z) メモリ・マネージャが存在する場合、拡張は set_auto_extension コールで追加され、メモリ・マネージャで自動的に削除あるいはプールされる。set_extension コールで追加された拡張はス
ティッキー拡張と呼ぶ。スティッキー拡張とは、トランザクション参照カウントが０の場合でも、自動的に削除されないものを指す。
aa) メモリ・マネージャの存在の有無が分からない場合、拡張は set_extension コールで追加、
release_extension コールで削除すべきである。この呼出し手順はメモリ・マネージャの存在の如何によらず安全である。この状況は has_mm コールしないインターコネクト・コンポーネントかターゲットの中で起こることができる。
（イニシエータの中では、常に、メモリ・マネージャの存
在の有無は分かっている、且つ has_mm コールはメモリ・マネージャの有無に関わらず常に自明である）
bb) メソッド free_all_extensions は自動削除のためにマークした他を含むすべての拡張を削除
して、対応する拡張ポインタを null に設定する。各拡張は拡張オブジェクトの free メソッド・
コールで削除される。ユーザが拡張オブジェクトのための明白なメモリ管理を提供したいなら、
多分 free メソッドをオーバーロードできる。
cc) Free_all_extensions はメモリ・マネージャを使用しないでプールされたトランザクション・
オブジェクトから拡張を削除する時に便利である。メモリ・マネージャを使う時、自動削除のためにマークされた拡張は削除される。スティッキー拡張は削除されない。
dd) deep_copy_from メソッドは、別のトランザクション・オブジェクトをコピーすることによって、現在のトランザクション・オブジェクトのアトリビュートと拡張を変更するものとする。もし２つの（コピー元とコピー先）トランザクションのポインタが non-null ならば、データとバイト・イネーブル配列は deep コピーされる。アプリケーションは現在のトランザクションで配列が十分に大きいことを確認することを保証する。他のトランザクションの拡張が現在のトランザク
ションに存在しているならば、拡張クラスの copy_from メソッドのコールでコピーされる。さもなければ、新しい拡張オブジェクトは拡張クラスの clone メソッド・コールで作成され、現在のトランザクションにセットされる。クローニングの場合で、もしメモリ・マネージャが現在のトランザクションのために存在するならば、新しい拡張は自動削除のマークがされる。
ee) 言い換えれば、メモリ・マネージャが存在する場合で、deep_copy_from は現在のオブジェク
トに存在しない新しい拡張の全てに自動削除をマークする。メモリ・マネージャが存在しない場
合は、全ての拡張は、スティッキー拡張である。
ff) メソッド update_extensions_from は、別のトランザクション・オブジェクトからそれらの現在のオブジェクトに存在している拡張をコピーすることによって、現在のトランザクション・オ
ブジェクトの拡張を変更するものとする。拡張は拡張クラスの copy_from メソッド・コールによってコピーされる。
- 169 -gg) Deep_copy_from と update_extensions_from の一般的なユースケースはターゲット・ソケッ
トを通して到着するトランザクション・オブジェクトを deep コピーして、イニシエータ・ソケッ
トを通してコピーを出すことである。そして（backward パスあるいは return パスをつかって）
トランザクションが返る時、最初のトランザクション・オブジェクトに拡張をコピーバックする
ために update_extensions_from をコールする。下流で追加された拡張は無視される。
hh) これらの義務は汎用ペイロードに適用される。原則として、同様の義務は汎用ペイロードに関係ないトランザクション・タイプにも適用される。
6.6 コンストラクタ、代入、デストラクタa) デフォルトコンストラクタは、汎用ペイロード・アトリビュートにデフォルト値を設定する。
b) コンストラクタ tlm_generic_payload( tlm_mm_interface*)はそれらのデフォルト値に汎用ペイロード・アトリビュートを設定して、アドレスが引数として通過されるオブジェクトに汎用ペ
イロード・オブジェクトのメモリ・マネージャを設定する。
c) コピーコンストラクタと代入演算は不可である。
d) 仮想のデストラクタ~tlm_generic_payload はすべての拡張を削除するものとする（自動削除のためにマークした他を含む）。各拡張は拡張オブジェクトの free メソッド・コールで削除される。デストラクタはデータ配列、バイト・イネーブル配列を削除しない。
6.7 デフォルト値と標準的なアトリビュート
アトリビュート

デフォルト値

コマンド
アドレス
データ・ポインタ
データ配列
データ長
バイト・イネーブル・ポインタ
バイト・イネーブル配列
バイト・イネーブル長
ストリーミング幅DMI 許可レスポンス・ステータス
拡張ポインタTLM_IGNORE_COMMAND
0
0
0
0
0
0
False
TLM_INCOMPLETE_RESPONSE
0

インターコネクト
での変更
No
Yes
No
No
No
No
No
No
No
Yes
No
Yes

ターゲット
での変更
No
No
No
Yes(read cmd)
No
No
No
No
No
Yes
Yes
Yes

6.8 コマンド・アトリビュート• set_command メソッドは値渡しの引数でコマンド・アトリビュートを設定し、get_command メソ
ッドは現在のコマンド・アトリビュートを値で返す。
• set_read メソッドと set_write メソッドはそれぞれ TLM_READ_COMMAND、TLM_WRITE_COMMAND を
コマンド・アトリビュートに設定する。is_read メソッドと is_write メソッドはそれぞれ現在のコマンド・アトリビュートの値が TLM_READ_COMMAND、TLM_WRITE_COMMAND かどうかを判定しそれを返す。
• リードコマンドはコマンド・アトリビュートが TLM_READ_COMMAND と等しい汎用ペイロード・ト
ランザクションであり、ライトコマンドはコマンド・アトリビュートが TLM_WRITE_COMMAND と等しい汎用ペイロード・トランザクションである。
• リードコマンドを受取った時、ターゲットはローカル配列の内容をデータ・ポインタ・アトリ
ビュートとなるよう配列ポインタにコピーする。
• ライトコマンドを受取った時、ターゲットはデータ・ポインタ・アトリビュートにより指定されている配列をターゲット内のローカル配列にコピーする。
• もしターゲットがリードまたはライトコマンドを実行することが出来ない場合は、標準的なエラーレスポンスを生成する。推奨するレスポンス・ステータスは TLM_COMMAND_ERROR_RESPONSE。
• 汎用ペイロード・トランザクションのコマンド・アトリビュートが TLM_IGNORE_COMMAND であった場合、ターゲットはライトまたはリードコマンドを実行してはならない。
• コマンド・アトリビュートはイニシエータにより設定され、インターコネクトやターゲットは書き換えない。
• コマンド・アトリビュートのデフォルト値は TLM_IGNORE_COMMAND である。
6.9 アドレス･アトリビュートa) set_address は、アドレス・アトリビュートに引数で与えられた値を設定し, get_address は- 170 -

現在値を返す。
b) read コマンドや write コマンドに対して、ターゲットはアドレス：アトリビュートの現在値
が read/write される連続するデータ・ブロックの最初のバイトを指しているものと解釈する。ただし、データ・ポインタで示される配列の先頭バイトを指しているかどうかは、ホスト計算機のエンディアンに依存する。
c) データ配列中の特定のバイトのアドレスは、アドレス・アトリビュート、配列インデックス、
ストリーミング幅・アトリビュート、ホスト計算機のエンディアン、ソケット幅で決まる。6.17
エンディアン を参照のこと。
d) アドレス・アトリビュートの値は、ワード・アラインメントである必要はない。 （もしアドレス・アトリビュートがバイトで表現されるローカルソケット幅の倍数であれば、アドレス計算
が大幅に単純化できる)e) ターゲットが指定されたアドレス・アトリビュートでトランザクションを実行できない場合は、
標準エラーを生成する。推奨のエラーコードは、TLM_ADDRESS_ERROR_RESPONSE。
f) アドレス・アトリビュートはイニシエータで設定されるが、一つ以上の接続コンポーネントにより上書きされることがある。上書きは、接続コンポーネントがメモリの絶対アドレスからター
ゲットが認識できる相対アドレスへ変換する場合などのために必要である。アドレス・アトリビ
ュートが上書きされた場合、明示的に別の場所に退避しない限り、上書き前の値は失われる。
g) アドレス・アトリビュートのデフォルト値は‘0’6.10 データ・ポインタ･アトリビュートa) set_data_ptr はデータ・ポインタ・アトリビュートに、引数で与えられた値を設定し、get_data_ptr は現在値を返す。データ・ポインタ・アトリビュートは、データ配列へのポインタ
で、ポインタ値の設定や取得をするもので、データ配列の内容の設定や取得をするものではない。
b) ターゲットは read/write コマンドで、それぞれデータのデータ配列からの読み出し/書き込みを行う。
c) データ配列用の領域はイニシエータが確保する。その領域は、イニシエータ内のレジスタ・フ
ァイルやキャッシュ・メモリのようなデータ領域や、トランザクションレベル・インタフェースのデータ転送に使うテンポラリ･バッファである。
d) 一般には、汎用ペイロードのデータ配列の構成は、イニシエータやターゲットのローカル・レ
ジスタの構成とは独立である。しかしほとんどの場合、汎用ペイロードはターゲットとのデータ・
コピーは memcopy 一回で行うよう設計されるので、ターゲットのレジスタは汎用ペイロードと同じ構成であることを想定している。この前提はあくまでもシミュレーション速度のためであり、汎用ペイロードの表現能力を制約するものではない。ターゲットはデータアレイとのコピーについて任意のデータ変換をすることができる。
e) トランザクション･オブジェクトが Null(0)ポインタでトランスポート・インタフェースを呼び出すとエラーとなる
f) データ配列長はデータ長アトリビュートの値以上であること（単位はバイト）g) データ・ポインタ・アトリビュートはイニシエータが設定するもので、他のコンポーネントやターゲットによって上書きされないh) write コマンドや TLM_IGNORE_COMMAND では、データ配列はイニシエータが設定するもので、他のコンポーネントやターゲットによって上書きされないi) read コマンドでは、データ配列はバイト・イネーブルの設定に従って、ターゲットで上書きされるが、他のコンポーネントから上書きはできないj) データ・ポインタ・アトリビュートのデフォルト値は 0（null）
6.11 データ長アトリビュートa) set_data_length はデータ長・アトリビュートに引数で与えられた値を設定し,get_data_length は現在値を返す。
b) read コマンドや write コマンドに対して、ターゲットはデータ長アトリビュートの現在値を、
バイト・イネーブル・アトリビュートでディスエーブルされているバイトも含めた、コピーされるデータ･アレイのバイト数であると解釈する。
c) 値はイニシエータが設定して、他のコンポーネントやターゲットによって上書きされないd) ‘０’に設定してはいけない。ゼロバイト転送の場合は、コマンド・アトリビュートを’
TLM_IGNORE_COMMAND’とするe) 相互利用性レイヤの標準ソケットクラスもしくはその派生クラスを使って、バースト転送をす- 171 -

る場合、転送のワード長はソケットの BUSWIDTH テンプレート・パラメータで指定される。BUSWIDTHはデータ長アトリビュートとは独立で、ビット数で表される。もし、データ長が BUSWIDTH／８と同じか小さいとシングルワード転送を、それより大きいとバースト転送をトランザクションを効率的にモデリングしていることになる。一つのトランザクションを異なるバス幅のソケットで渡すことが出来る。BUSWIDTH は転送のレイテンシ計算に使用される。
f) ターゲットは、ターゲットのワード長より大きなデータ長のトランザクションをサポートするかもしれないし、サポートしないかもしれない。そのときのワード長は、BUSWIDTH テンプレート・パラメータで与えられるか、もしくは他の値で与えられる。
g) ターゲットは与えられたデータ長のトランザクションが実行できなかった場合は、標準エラー
レスポンスを返して、データ配列の内容を変更してはいけない。推奨レスポンス・ステータスは、’
TLM_BURST_ERROR_RESPONSE’h) データ長アトリビュートのデフォルト値は’0’で、無効な値である。故に、データ長・アトリビュートはインタフェース・メソッド・コールでトランザクション・オブジェクトが渡される
前に明示的に設定されるべきである。
6.12 バイト･イネーブル･ポインタ･アトリビュートa) set_byte_enable_ptr で、バイト･イネーブル配列へのポインタに引数で与えられた値を設定
し、get_byte_enable_ptr でバイト･イネーブル･ポインタ・アトリビュートの値を返す
b) バイト･イネーブル配列の各要素は次のように解釈される。’0’は、対応するバイトがディス
エーブルされていることを示し、‘0xff’は対応するバイトがイネーブルされていることを示す。
その他の値は未定義である。‘0xff’は、バイト・イネーブル配列がそのままマスクとして使えるように値が選ばれた。TLM_BYTE_DISABLED と TLM_BYTE_ENABLED の２つのマクロが用意されているc) バイト・イネーブルは、それぞれのビートのアドレスの増加分がビートの最上位バイトより大きいときや、バスの選ばれたバイト･レーンに複数ワードを設定するバースト転送に使われる。より抽象度の高いレベルでは、データ配列に歯抜けがある状態でバースト転送を行う時に使用するd) 小さなパターンを繰り返し使用する場合や、データ配列全体をカバーする大きなパターンがある場合に、byte enable mask が定義される。6.13 バイト･イネーブル長アトリビュートを参照のことe) バイト･イネーブル配列のエレメント数は、バイト･イネーブル長アトリビュートで与えられる
f) バイト･イネーブル･ポインタが’0’(null)に設定されている場合は、その転送ではバイト･イネーブルは使用されず、バイト･イネーブル長は無視されるg) バイト･イネーブルが使われる場合は、バイト･イネーブル･ポインタ･アトリビュートはイニシ
エータが設定する。バイト･イネーブル配列領域はイニシエータが確保して、バイト･イネーブル
配列の内容もイニシエータが設定し、イネーブル配列の内容は他のコンポーネントやターゲット
で上書きされない。
h) バイト・イネーブル・ポインタが null でないときは、ターゲットは以下に定義された動作を実装するか、もしくは標準エラー応答を生成する。推奨エラー
は’TLM_BYTE_ENABLE_ERROR_RESPONSE’i) write コマンドでは、データ配列のディスエーブルされたバイトのデータは接続コンポーネン
トやターゲットでは無視されなければならない。ディスエーブルされたバイトは、接続コンポー
ネントやターゲットの動作に影響を与えないことが推奨される。これらの無視されるバイトに対しては、イニシエータはどのような値を書き込んでも良い。
j) write コマンドで、ターゲットがトランザクション･データ配列からローカル配列へバイト単位のコピーをしている場合には、ターゲットは、汎用ペイロードのディスエーブル･バイトに対応するローカル配列のバイト値を書き換えてはならない。
k) read コマンドでは、データアレイ中のディスエーブルされたバイトの値を、接続コンポーネントやターゲットが変更してはならない。イニシエータは、これらのディスエーブルされたバイ
トは接続コンポーネントやターゲットが変更しないものとみなすことができる。
l) read コマンドでは、ターゲットがローカル配列からトランザクション･データ配列へバイト単位でコピーする場合、ターゲットは、汎用ペイロードのディスエーブル･バイトに対応するローカ
ル配列の値は無視すべきである。
m) もし、アプリケーションでこれらの規定を破らなければならない場合や、本書の汎用ペイロードの規定を破らなければならない場合は、新しくプロトコル･タイプ･クラスを作ることを推奨す- 172 -

る。6.2.2 tlm_generic_payload の型を含む新しいプロトコル型の定義を参照のこと
n) イネーブル･ポインタ･アトリビュートのデフォルト値は’0’。Null ポインタ
6.13 バイト･イネーブル長アトリビュートa) set_byte_enable_length は、引数で与えられた値をバイト･イネーブル長アトリビュートに設定し、get_byte_enable_length は現在の値を返す
b) read/write コマンドに対して、ターゲットは、バイト･イネーブル長アトリビュートをバイト・
イネーブル配列の要素数として解釈する
c) バイト･イネーブル長アトリビュートの値はイニシエータが設定して、接続コンポーネントやターゲットは上書きしないd) データ配列のあるエレメントに適用するバイト・イネーブルは
byte_enable_array_index=data_array_index%byte_enable_length で与えられる。つまり、バイト・イネーブル配列はデータ配列に繰り返し適用されるe) バイト･イネーブル長がデータ配列の長さより大きい場合、余分なバイト･イネーブルは
read/write コマンドに影響しない。ただし、拡張に使用することはできる
f) バイト･イネーブル･ポインタが 0、つまり null pointer の場合、バイト・イネーブル長の値
は接続コンポーネントやターゲットから無視される。もし、バイト･イネーブル･ポインタが’0’でなければ、バイト･イネーブル長は’0’ではないg) ターゲットが、指定されたバイト・イネーブル長を使ってトランザクションが実行できないときは、エラーを出す。推奨は、TLM_BYTE_ENABLE_ERROR_RESPONSEh) バイト･イネーブル長アトリビュートのデフォルト値は、’0’6.14 ストリーミング幅アトリビュートa) set_streaming_attribute は、引数の値をストリーミング幅アトリビュートに設定し、get_streaming_attribute は現在値を返す
b) read/write コマンドに対して、ターゲットはストリーミング幅の現在値に従って動作する
c) ストリーミングは、コンポーネントがデータ配列をどのように解釈するかに影響する。ストリームは、継続するビートで発生するデータ転送のシーケンスを構成し、各々のビートは汎用ペイロードのアドレス・アトリビュートで与えられる同じスタートアドレスを持つ。ストリーミング・
幅アトリビュートはストリームの幅を決定し、それは、各々のビートで転送されるバイト数である。すなわち、データアレイの構成にストリーミングは影響しない。
d) データ配列中のバイトは、汎用ペイロード・トランザクションにアクセスしているコンポーネント内のローカルアドレスの順序に対応している。最下位アドレスはアドレス・アトリビュートで与えられる。最上位アドレスは、address_attribute+streaming_width-1 で与えられる。ター
ゲットにコピーされる各々のバイトのアドレスは、各々のビートのスタートでアドレス・アトリ
ビュートの値として設定される。
e) データ配列の実装としては、ストリーミングの幅を持つ単一のトランザクションは、一連のトランザクションと機能的には等価である。そのトランザクションは、オリジナルトランザクショ
ンと同じアドレスで、オリジナルストリーミング幅と同じデータ長・アトリビュートをもち、それぞれのビートでオリジナルデータ配列の異なるサブセットをデータ配列としたものである。このサブセットは、オリジナルデータ配列のデータ順を維持したものである。
f) 0 のストリーミング幅は無効である。もし、ストリーミング転送が必要でなかったなら、ストリーミング幅アトリビュート は、データ長・アトリビュートと同じがそれ以上の値にすべきである。
g) ストリーミング幅アトリビュートはデータ配列の長さやデータ配列に格納されているバイト数には影響しない。
h) ストリーミング幅がソケットの幅と異なる場合には、幅変換の問題が生じる。 6.17 エンデ
ィアンを参照のこと
i) ターゲットが、指定されたストリーミング幅を使ってトランザクションが実行できないときは、
標準エラーを出す。推奨は、TLM_BURST_ERROR_RESPONSEj) ストリーミングは、バイト･イネーブルと組み合わせて使われるときがあり、その場合通常は、ストリーミング幅はバイト・イネーブル長 と同じ値になる。バイト･イネーブル長がストリーミ
ング幅の倍数ならば、各々のビートで異なるバイト数がイネーブルされることを意味するk) ストリーミング幅アトリビュートのデフォルト値は、0- 173 -

6.15 DMI 許可アトリビュートa) set_dmi_allowed は、DMI 許可アトリビュートに引数の値を設定し、get_dmi_allowed は、現在の値を返すb) DMI 許可アトリビュートは、ダイレクト・メモリ・ポインタを取得できる可能性をイニシエー
タに示すもので、DMI 経由で現在のトランザクションが実行できた場合は、ターゲットが DMI 許可アトリビュートを’true’にセットする。4.2.7 4.2.7DMI ヒントを使った最適化を参照のこと
c) DMI 許可アトリビュートのデフォルト値は、false
6.16 応答ステータス・アトリビュートa) set_response_status は、引数の値を response status attribute へ設定し,get_response_status は、現在値を返す
b) 応答ステータスの現在値が TLM_OK_RESPONSE の場合にのみ、is_response_ok は’true’を返す。 is_response_error は、応答ステータスの現在値が TLM_OK_RESPONSE と異なる場合にのみ’ture’を返す
c) get_response_string は現在の状態を文字列で返す
d) 原則としてターゲットは汎用ペイロードの全ての機能を実装することが推奨されているが、そのようになっていない場合はエラーを返す.6.16.1 標準エラー応答を参照のこと
e) 応答ステータス･アトリビュートには、イニシエータが TLM_INCOMPLETE_RESPONSE を設定して、ターゲットが上書きする。TLM_INCOMPLETE_RESPONSE は、トランザクションがターゲットに届いていないことを示すものなので、他の接続しているコンポーネントが上書きをしてはならないf) ターゲットは処理が成功した場合には、応答ステータス･アトリビュートに TLM_OK_RESPONSE
を設定して、そうでなければ、以下のテーブルにある 5 つのエラーレスポンスを設定してエラーであることを示す。ターゲットは、エラーの原因に応じて適切なエラーを選ぶべきである。
Error response
Interpretation
アドレス：アトリビュートで与えられた値では動作できない、
TLM_ADDRESS_ERROR_RESPONSE
もしくはアドレス範囲を超えている
TLM_COMMAND_ERROR_RESPONSE
与えられたコマンドを実行できない与えられたデータ長、もしくはストリーミング幅では動作でTLM_BURST_ERROR_RESPONSE
きない
TLM_BYTE_ENABLE_ERROR_RESPONSE 与えられたバイト･イネーブルでは動作できない
TLM_GENERIC_ERROR_RESPONSE
その他のエラーg) ターゲットがエラーを検出しても、特定のエラーを選ぶことが出来ないときは、、
TLM_GENERIC_ERROR_RESPONSE を設定してよいh) 応答ステータス･アトリビュート のデフォルト値は、TLM_INCOMPLETE_RESPONSEi) ターゲットは、トランザクションのライフタイムの適当なところで、イニシエータは応答ステ
ータス･アトリビュートを設定しなければならない。ブロッキングトランスポートインタフェースの場合、b_transport から制御が戻る前に設定する必要がある。ノンブロッキング・インタフェースと基本プロトコルでは、BIGIN_RESP フェーズを設定する前か、TLM_COMPLETE を返す前になる。
j) イニシエータは、BEGIN_RESP まで、もしくはトランザクションが完了するまで、受け取るト
ランザクションの応答ステータス･アトリビュートを常にチェックすることを推奨される。前もって、TLM_OK_RESPONSE であることが分かっている場合には、イニシエータは、応答ステータス･アトリビュートを無視することを選ぶかもしれない。たとえば、イニシエータが、常にTLM_OK_RESPONSE を返すターゲットにのみ接続していることを前もって知っている場合。ただし、常にそうであるとは限らないので、イニシエータは自らの責任で、応答ステータス･アトリビュー
トを無視することになる。
6.16.1 標準エラー応答
ターゲットが汎用ペイロードのトランザクションを受け取ったときには、次のいずれか一つのみの処理をすべきである
a) 汎用ペイロードのアトリビュートやモデル化されたコンポーネントの公にドキュメント化されているセマンティックスに従って、トランザクションで示されるコマンドを実行して、レ
スポンス・ステータスを TLM_OK_RESPONSE に設定する
b) 先に示した５つのエラーメッセージのうちの一つを汎用ペイロードのレスポンス・ステータ
スとして設定する
c) SystemC の標準レポートハンドラを使って、コマンド実行失敗、コマンド無視を含む SystemC- 174 -

の４つの重要度レベルのひとつでレポートを生成して、レスポンス・ステータスを
TLM_OK_RESPONSE に設定する
ターゲットは上記の 3 つのうちのいずれか一つを実行することが推奨されるが、実装は、この推奨を押しつけられるものではない。
汎用ペイロード以外のトランザクション・タイプに対しても、上記と同様の応答を推奨する。すなわち、コマンドを期待されるとおりに実行するか、トランザクション・アトリビュートを使ってエラー応答を生成するか、もしくは SystemC レポートを生成する。しかしながら、処理の詳細とエラー応答メカニズムはこの標準の範囲外である。
上記の a)を満たすための条件は、コンポーネントのユーザが見ることのできるターゲットコンポ
ーネントの期待されている動作によって決まる。汎用ペイロードの・アトリビュートはメモリ・
マップド・バスにおける慣例適用法に対応したセマンティックで規定されているが、それは、ターゲットが RAM のような動作をすることを必ずしも想定するものではない。現実には、多くの異なった状況がある。
i. ターゲットが write コマンドと read コマンドの両方をサポートしているメモリマップドレ
ジスタを持っていて、write コマンドがターゲットのステータスを変更しても、write コマンドの後の read コマンドが直前に書き込まれた値ではなく、ターゲットのステータスで決まる値を返すことがある。もしこれが、コンポーネントに期待される正常な動作であれば、a)でカバー
される
ii. ターゲットの write コマンドがデータ・アトリビュートを無視してビットを設定するように実装されていることがある。もしこれが、期待されている正常な動作であれば、a)でカバー
される
iii. ROM は、応答ステータス･アトリビュートを使ったエラー応答をイニシエータに出すことなく無視することがある。write コマンドはターゲットのステートを変更せず、無視されているが、ターゲットは、少なくとも SC_INFO か SC_WARNING の重要度レベルの SystemC レポートを生成すべきである
iv. ターゲットは read コマンドを実行する write コマンドや write コマンドを実行する read
コマンドを実装してはならない。これは汎用ペイロードの基本的な使い方に違反するものである。
v. ターゲットは、汎用ペイロードのルールに対応はしているが、副作用を持つ read コマンドを実装するかもしれないが、これは a)でカバーされる
vi. アドレス指定可能なレジスターファイルで構成したメモリマップドレジスタを持つターゲットが、アドレス範囲外の write コマンドを受け取った場合には、トランザクションの応答ス
テータス･アトリビュートに TLM_ADDRESS_ERROR_RESPONSE を設定するか、SystemC レポートを生成すべきである
vii. 受動的シミュレーション・バスモニター・ターゲットが、バスの物理範囲を越えるアドレスのトランザクションを受け取った時には、a)の対応として、エラーの可能性があるトランザ
クションを後処理のためにログ記録して、b)や c)によるエラー生成はしないのがよい。代替として、c)に基づくレポートを生成しても良い。
言い換えれば、a),b),c)の選択は、最終的に具体的な判断はケースバイケースであるが、汎用ペイロードに対しては、いずれかの対応をすることが明確なルールとなっている。
例// Showing generic payload with command, address, data, and response status// The initiator
void thread() {tlm::tlm_generic_payload trans; // Construct default generic payload
sc_time delay;trans.set_command(tlm::TLM_WRITE_COMMAND); // A write command
trans.set_data_length(4); // Write 4 bytes
trans.set_byte_enable_ptr(0); // Byte enables unused
trans.set_streaming_width(4); // Streaming unusedfor (int i = 0; i < RUN_LENGTH; i += 4) { // Generate a series of transactions
int word = i;trans.set_address(i); // Set the addresstrans.set_data_ptr( (unsigned char*)(&word) ); // Write data from local variable ‘word’- 175 -

trans.set_dmi_allowed(false); // Clear the DMI hinttrans.set_response_status( tlm::TLM_INCOMPLETE_RESPONSE ); // Clear the response status
init_socket->b_transport(trans, delay);if (trans.get_response_status() <= 0) // Check return value of b_transport
SC_REPORT_ERROR("TLM-2", trans.get_response_string().c_str());
...
}
...
// The target
virtual void b_transport( tlm::tlm_generic_payload& trans, sc_core::sc_time& t){
tlm::tlm_command cmd = trans.get_command();sc_dt::uint64 adr = trans.get_address();
unsigned char* ptr = trans.get_data_ptr();unsigned int len = trans.get_data_length();unsigned char* byt = trans.get_byte_enable_ptr();unsigned int wid = trans.get_streaming_width();if (adr+len > m_length) { // Check for storage address overflow
trans.set_response_status( tlm::TLM_ADDRESS_ERROR_RESPONSE );return;}if (byt) { // Target unable to support byte enable attributetrans.set_response_status( tlm::TLM_BYTE_ENABLE_ERROR_RESPONSE );return;}if (wid < len) { // Target unable to support streaming width attributetrans.set_response_status( tlm::TLM_BURST_ERROR_RESPONSE );return;}if (cmd == tlm::TLM_WRITE_COMMAND) // Execute command
memcpy(&m_storage[adr], ptr, len);else if (cmd == tlm::TLM_READ_COMMAND)
memcpy(ptr, &m_storage[adr], len);trans.set_response_status( tlm::TLM_OK_RESPONSE ); // Successful completion}// Showing generic payload with byte enables// The initiator
void thread() {tlm::tlm_generic_payload trans;
sc_time delay;
static word_t byte_enable_mask = 0x0000fffful; // MSB..LSB regardless of host-endianness
trans.set_command(tlm::TLM_WRITE_COMMAND);trans.set_data_length(4);trans.set_byte_enable_ptr( reinterpret_cast<unsigned char*>( &byte_enable_mask ) );trans.set_byte_enable_length(4);trans.set_streaming_width(4);...
...
// The target
virtual void b_transport(
tlm::tlm_generic_payload& trans, sc_core::sc_time& t){
tlm::tlm_command cmd = trans.get_command();sc_dt::uint64 adr = trans.get_address();
unsigned char* ptr = trans.get_data_ptr();unsigned int len = trans.get_data_length();unsigned char* byt = trans.get_byte_enable_ptr();unsigned int bel = trans.get_byte_enable_length();unsigned int wid = trans.get_streaming_width();- 176 -

if (cmd == tlm::TLM_WRITE_COMMAND) {if (byt) {for (unsigned int i = 0; i < len; i++) // Byte enable applied repeatedly up data arrayif ( byt[i % bel] == TLM_BYTE_ENABLED )m_storage[adr+i] = ptr[i]; // Byte enable [i] corresponds to data ptr [i]}elsememcpy(&m_storage[adr], ptr, len); // No byte enables} else if (cmd == tlm::TLM_READ_COMMAND) {if (byt) { // Target does not support read with byte enablestrans.set_response_status( tlm::TLM_BYTE_ENABLE_ERROR_RESPONSE );return;}else
memcpy(ptr, &m_storage[adr], len);}trans.set_response_status( tlm::TLM_OK_RESPONSE );}6.17 エンディアン
6.17.1 イントロダクション
イニシエータとターゲット間でデータ転送するために汎用ペイロードを使う時、ホストマシンのエンディアン（ホストエンディアン）とイニシエータのエンディアンとモデル化されるターゲッ
ト（モデル化エンディアン）の両方が関連する。この章では汎用ペイロードを使用しているイニ
シエータとターゲット間の相互利用性を確保するための規則を定義する。すなわち、汎用ペイロ
ードのデータ配列とバイト・イネーブル配列の構造に特に関係する。しかしながら、ここで示す
規則は汎用ペイロードの直接スコープを超えてエンディアンをモデル化するいくつかの選択肢に影響することがある。
TLM 2.0 アプローチの基本原則は汎用ペイロード・データ配列の構造がイニシエータ、インターコネクト・コンポーネントまたはターゲット内部で局所的に知りえる情報だけに依存する。特に、これはソケット、ホストマシンのエンディアンとモデル化されたコンポーネントの幅に依存する。
汎用ペイロードの構造とエンディアンのアプローチは、ある共通システムのシナリオにおいてシ
ミュレーション速度を最大限に引き出すために選択された。これから述べる規則は、汎用ペイロードの構造を示している。そして、これはモデル化されたシステムの構造から独立である。例えば、汎用ペイロード内部の Word は必ずしもモデル化されたアーキテクチャ内部のどんな Word の内部表現とは対応しない。
マクロ視点では、主原則は汎用ペイロードが MSB 対 MSB と LSB 対 LSB で結ばれたエンディアン混在システムにおけるコンポーネントを仮定している。換言すると、１Word が異なったエンディア
ンのコンポーネント間で転送されるなら、MSB ．．．LSB 関係が保存される。しかし各コンポーネント内部で見られる各 Byte のローカルアドレスはアドレス・スウィズリング(address swizzling)と一般的に呼ばれる変換を用いて必ず変換される。これは、モデル化されたシステムと TLM2.0 モ
デルの両方に当てはまる。一方、もしエンディアン混在システムが、各コンポーネント内部でローカルアドレスが変化しないように接続されていれば、（すなわち、各 Byte がどんなコンポーネントから参照されても同じアドレスを持つ時）、明示的 Byte スワップが TLM2.0 モデルに挿入される必要がある。
Helper 関数群がデータ配列の構造を支援するために準備されている。6.19 章を参照。
6.17.2 規則（省略）
6.18 ホストエンディアンを決定する Helper 関数
6.18.1 イントロダクション
Helper 関数群がホストマシンのエンディアンを決めるために提供されている。これらは、汎用ペイロード・データ配列を作ったり解釈する時に使うことを目的としている。
6.18.2 定義
namespace tlm {enum tlm_endianness {- 177 -

TLM_UNKNOWN_ENDIAN, TLM_LITTLE_ENDIAN, TLM_BIG_ENDIAN };inline tlm_endianness get_host_endianness(void);
inline bool host_has_little_endianness(void);
inline bool has_host_endianness(tlm_endianness endianness);} // namespace tlm

6.18.3 規則（省略）
6.19 エンディアン変換用 Helper 関数
6.19.1 イントロダクション
汎用ペイロード・データ配列の構造を統括する規則は十分定義されているし、多くの簡単なケースでは、データ配列を作り解釈するためのホストとは独立なＣ＋＋コードを書くことは明確な作業となる。しかしながら、規則はモデル化されたコンポーネントのエンディアンとホストエンデ
ィアン間の関係に依存する。そこでホストとは独立なコードを書くことは、ソケット幅と異なる
アラインされないアドレスとデータ Word 幅を含む場合では極めて複雑になる。Helper 関数群はこの作業を支援するために準備されている。
エンディアンに関して、相互利用性はエンディアン規則だけに依存する。Helper 関数は必ずしも相互利用性に重要ではない。
エンディアン変換関数の背後にあるモチベーションは、ホストエンディアンとは関係なく一度書かれたイニシエータのための汎用ペイロード・トランザクションを作るＣ＋＋コードを可能にすること、さらに一度の関数呼び出で、ホストエンディアンにマッチするように変換されたとトラ
ンザクションを持つことである。各変換関数は、存在する汎用ペイロード・トランザクションを行いそして修正する。変換関数は対になっており、to_hostendian 関数と from_hostendian 関数
はいつも一緒に使われる。to_hostendian 関数はトランスポート・インタフェースを介してとト
ランザクションを送る前にイニシエータにより呼ばれる。from_hostendian 関数は受取った後に呼ばれる。
４つの関数ペアが提供されている。もっとも一般的で強力な_generic、制限された場合だけに使える_word、_aligned、_single である。コスト面で_generic 関数の使用が推奨される。
変換関数には Arithmetic モードと Byte order モードがある。性能面で、Arithmetic モードが推奨される。変換関数は data word コンセプトが使われており、これは TLM2 ソケット幅と汎用ペイロード・データ配列とは独立である。
6.19.2 定義
namespace tlm {template<class DATAWORD>
inline void tlm_to_hostendian_generic(tlm_generic_payload *, unsigned int );template<class DATAWORD>
inline void tlm_from_hostendian_generic(tlm_generic_payload *, unsigned int );template<class DATAWORD>
inline void tlm_to_hostendian_word(tlm_generic_payload *, unsigned int);
template<class DATAWORD>
inline void tlm_from_hostendian_word(tlm_generic_payload *, unsigned int);
template<class DATAWORD>
inline void tlm_to_hostendian_aligned(tlm_generic_payload *, unsigned int);
template<class DATAWORD>
inline void tlm_from_hostendian_aligned(tlm_generic_payload *, unsigned int);
template<class DATAWORD>
inline void tlm_to_hostendian_single(tlm_generic_payload *, unsigned int);
template<class DATAWORD>
inline void tlm_from_hostendian_single(tlm_generic_payload *, unsigned int);
inline void tlm_from_hostendian(tlm_generic_payload *);} // namespace tlm
6.19.3 規則（省略）- 178 -

6.20 汎用ペイロードの拡張
6.20.1 イントロダクション
拡張メカニズムは汎用ペイロードに組み込まれていて、汎用ペイロード無しに使うことはできない。その目的は、汎用ペイロードにアトリビュートの追加を許すことである。
拡張は無視可能(ignorable)か必須(mandatory)のどちらかにする。無視可能拡張は汎用ペイロー
ド・トランザクションを受け取るどのインターコネクト・コンポーネントやターゲットからも無視されるかもしれない。無視可能拡張の主な意図はダウンストリームコンポーネントの機能性に直接の影響を及ぼさない補助的な情報やシミュレーション生成物やサイドバンド情報やメタデー
タをモデル化することである。無視可能拡張は基本プロトコルによって許される。必須拡張はトランザクションを受け取るどんな内部コンポーネントもターゲットも検査し動作することを義務付けられている。必須拡張の主な意図は、特定のプロトコルの詳細をモデル化するために汎用ペイロードを適応するときに使うことである。必須拡張には、新しいプロトコル型のクラス定義が必要である。
（言い換えれば、）イニシエータの観点から見て、標準の汎用ペイロード・トランザクションのア
トリビュートの機能的な意味を変えるか、基本プロトコルの規則を変えるのであれば、その拡張を必須にすることを考慮しなければならない。ターゲットの観点から見て、その拡張がないときに使うことのできるその拡張に代わる適切なデフォルト値がなければ、その拡張を必須にすることを考慮しなければならない。
6.20.2 原理
拡張メカニズムの原理は、汎用ペイロードのコアアトリビュート一式の変化を運ぶ TLM ポートやソケットに同じトランザクション型で特殊化させることを許すことである。そうして、適応や橋渡しの必要なしに TLM ポートやソケットが互いに接続することを許す。拡張メカニズムなしに汎用ペイロードに新しいアトリビュートを追加すると、そのコアインタフェースクラスの新しいテンプレートの特殊化を導く新しいプロトコルクラスの定義が必要である。そのクラスは汎用ペイ
ロードやこのように特殊化されたほかのものと型非互換である。拡張メカニズムは、TLM ポートの型互換を犠牲にすることなく汎用ペイロードに主要でない変更を加えることを許す。そうして、少し異なる情報を伝達するポートを接続するために必要なコード作成の仕事を減らす。
6.20.3 拡張ポインタとオブジェクトとブリッジ
拡張は tlm_extension クラスから派生した型のオブジェクトである。汎用ペイロードは拡張オブジェクトへのポインタ配列を含む。すべての汎用ペイロードのオブジェクトは拡張のすべての型の単体のインスタンスを運ぶことができる。
拡張を指し示すポインタ配列はすべての登録された拡張のために１つのスロットを持つ。
set_extension メソッドは単純にポインタを上書きし、原則としてイニシエータか、インターコ
ネクト・コンポーネントかターゲットから呼び出されることができる。これはとても自由度の高
い低レベルのメカニズムを提供するが、使用間違いも起こしやすい。拡張オブジェクトの所有権と削除はユーザによって良く理解され注意深く考慮されなければならない。
２つの別の汎用ペイロード・トランザクションの間にブリッジを作るとき、もし要求されたら入ってくるトランザクション・オブジェクトから出て行くトランザクション・オブジェクトへすべての拡張をコピーし出て行くトランザクションとその拡張を所有し管理するのはブリッジの責任である。
（同じことがデータ配列とバイト・イネーブル配列にも言える。）deep_copy_from メソッ
ドは、データ配列とバイト・イネーブル配列や拡張オブジェクトを含むトランザクション・オブ
ジェクトの深いコピーをブリッジが行えるようにするために提供されている。もしそのブリッジが出て行くトランザクションにさらなる拡張を加えるなら、それらの拡張はそのブリッジによって所有される。
拡張の管理は 6.5 章「汎用ペイロードのメモリ管理」に十分に記述されている。
6.20.4 規則a) 拡張はイニシエータかインターコネクトかターゲットのコンポーネントにより加えることができる。特に、拡張の作成はイニシエータには制限がない。
b) どんな数の拡張でも汎用ペイロードの個々のインスタンスに加えることができる。
c) 無視可能な拡張の場合、どのインターコネクトやターゲットのコンポーネントも自由に与えられた拡張を無視できるようにすることを推奨する。しかし、これは実装によって強制されるべきではない。インターコネクトやターゲットのコンポーネントが拡張を持たないという理由で標準
エラー応答を行うようにすることは可能であるが、推奨される動作ではない。
- 179 -

d) 無視可能な拡張の場合、与えられた拡張の有無がどのコンポーネントにおいても主要な機能に影響を与えないことを推奨する。しかし、たとえば診断レポートやデバッグや最適化などであれば影響してもよい。
e) 与えられた拡張の存在を強制する組み込みのメカニズムはない。
f) 個々の拡張の意味はアプリケーションが定義する。あらかじめ定義された拡張はない。
g) 拡張は tlm_extension クラスからユーザ定義クラスを派生させて作り、ユーザ定義クラスそれ自身の名前を tlm_extension のテンプレート引数として渡してそのクラスのオブジェクトを作らなければならない。ユーザ定義クラスは汎用ペイロードの拡張されたアトリビュートを表すメンバーを含んで良い。
h) tlm_extension_base クラスの free 仮想メソッドは、拡張オブジェクトを削除しなければならない。このメソッドは、拡張のユーザ定義のメモリ管理の実装を上書きするかもしれない。しかし、これは必須ではない。
i) tlm_extension クラスの clone 純粋仮想関数は、すべての拡張されたアトリビュートを含む拡
張オブジェクトのクローンを作るためにユーザ定義の拡張クラスの中に定義されなければならない。この clone メソッドは、汎用ペイロードのメモリ管理と共に使うことを意図されている。それは、すべての拡張オブジェクトのコピーを作って、オリジナルのオブジェクトのデストラクシ
ョンがあっても副作用なくそのコピーが残るようにしなければならない。
j) tlm_extension クラスの copy_from 純粋仮想関数は、別の拡張オブジェクトのアトリビュート
をコピーすることによって自身のオブジェクトを修正するためにユーザ定義の拡張クラスの中で定義されなければならない。
k) tlm_extension クラステンプレートをインスタンスすると ID 公開データ・メンバが初期化され、これは汎用ペイロード・オブジェクトを持つ与えられた拡張を再登録しその拡張にユニークな ID を割り当てる効果を持たなければならない。その ID はプログラム実行中のすべてに対してユニークでなければならない。
l) 汎用ペイロードは、可変サイズの配列に拡張のポインタを蓄え、拡張の ID はその配列の中への拡張ポインタのインデックスを与えるようにふるまわなければならない。拡張の汎用ペイロードへの登録は、その拡張のための配列インデックスを保持しなければならない。個々の汎用ペイロードのオブジェクトは現在実行中のプログラムの中で登録されるすべての拡張へのポインタを蓄える能力のある配列を含まなければならない。
m) 拡張配列の中のポインタはトランザクションが生成されたときには空でなければならない。
n) 個々の汎用ペイロードのオブジェクトはすべての与えられた拡張型のせいぜい１つのオブジ
ェクトへのポインタしか蓄えることができない。
（しかし、異なる拡張型のたくさんのオブジェク
トを蓄える。
）o) メソッド set_extension と set_auto_extension、get_extension、clear_extension、
release_extension は複数の形態で提供され、関数テンプレートの使用や拡張ポインタ引数の使用、ID 引数の使用のような異なる方法でアクセスされてその拡張を認識する。ID 引数を受け取る
関数は、汎用ペイロードのオブジェクトのクローンを作るときのような特別なプログラムタスクのために意図されており、アプリケーションで一般的に使うためのものではない。
p) set_extension(T*)メソッドは、ポインタの配列の中の T 型の拡張オブジェクトを示すポイン
タを引数の値で置き換えなければならない。その引数は登録された拡張へのポインタでなければならない。関数の戻り値は、この呼び出しで置き換えられた汎用ペイロードの中のポインタの前の値でなければならない。それは空(null)のポインタかもしれない。set_auto_extension(T*)メ
ソッドは、その拡張が自動削除にマークされるのを除き、同様にふるまわなければならない。
q) set_extension(unsigned int, tlm_extension_base*)メソッドは、第 1 引数で与えられる配列
インデックスの示す、配列のポインタの中の拡張オブジェクトへのポインタを第 2 引数の値で置
き換えなければならない。与えられたインデックスは、拡張 ID として登録されていなければならない。そうでない場合の関数のふるまいは未定義である。関数の戻り値は、与えられた配列イン
デックスへのポインタの前の値でなければならない。それは空(null)のポインタかもしれない。
set_auto_extension(unsigned int, tlm_extension_base*)メソッドは、その拡張が自動削除にマークされるのを除き、同様にふるまわなければならない。
r) メモリ管理が存在するときの与えられた拡張のための set_auto_extension の呼び出しは、
set_extension の呼び出しに続いてすぐに同じ拡張の release_extension を呼び出すのに等しい。
メモリ管理のないときに set_auto_extension を呼び出すとランタイムエラーを起こす。
- 180 -s) もし拡張が自動削除とマークされたら、与えられた拡張オブジェクトはユーザ定義のメモリ管理の free メソッドの実装によって削除されるかプールされなければならない。
free メソッドは、
トランザクション・オブジェクトの参照数が 0 に到達したときに呼び出される。拡張オブジェク
トは tlm_generic_payload クラスの reset メソッドか拡張オブジェクトの free メソッドを呼び出すことによって削除されても良いし、プールされても良い。
t) もし汎用ペイロードのオブジェクトがすでにその型の拡張への空（null）でないポインタを含んでいたら、古いポインタは上書きされる。
u) メソッド関数 get_extension(T*&)と T* get_extension()は、もしそれが存在するなら、与えられた型の拡張オブジェクトへのポインタを、存在しなければ空(null)のポインタを返さなければならない。T 型は tlm_extension から派生した型のオブジェクトへのポインタでなければならない。この関数テンプレートを使って存在しない拡張の検索を試すことはエラーではない。
v) get_extension(unsigned int)メソッドは、引数によって与えられた ID の拡張オブジェクトへのポインタを返さなければならない。与えられたインデックスは拡張の ID として登録されていなければならない。そうでない場合のこの関数のふるまいは未定義である。もし与えられたインデックスへのポインタが拡張オブジェクトへのポインタではなかった場合、この関数は空(null)のポインタを返さなければならない。
w) メソッド clear_extension(const T*)と clear_extension()は、汎用ペイロード・オブジェク
トから与えられた拡張を取り除かなければならない。すなわち、拡張配列の中の対応するポイン
タを空(null)に設定しなければならない。拡張は、引数として拡張オブジェクトのポインタを渡すか、clear_extension<ext_type>()のように関数テンプレートのパラメータの型を使うことで特定される。もし存在するならば、その引数は tlm_extension から派生した型のオブジェクトへのポインタでなければならない。clear_extension メソッドはその拡張オブジェクトを削除してはならない。
x) メソッド release_extension(T*)と release_extension()は、もしトランザクション・オブジ
ェクトがメモリ管理を持つならば自動削除としてその拡張をマークしなければならない。そうでない場合、これらのメソッドは、拡張オブジェクトの free メソッドの呼び出しと拡張配列の中の対応するポインタに空(null)を設定することで与えられた拡張を削除しなければならない。拡張は、引数として拡張オブジェクトのポインタを渡すか、release_extension<ext_type>()のように
関数テンプレートのパラメータの型を使うことで特定される。もし存在するならば、その引数はtlm_extension から派生した型のオブジェクトへのポインタでなければならない。
y) release_extension メソッドのふるまいは、トランザクション・オブジェクトがメモリ管理を持つかどうかに依存することに注意せよ。メモリ管理がある場合は、拡張はまれに自動削除にマークされ、アクセス可能な状態で続く。メモリ管理がない場合は、拡張ポインタがクリアされるだけでなく拡張オブジェクトそれ自身も削除される。存在しない拡張オブジェクトを開放しない
ように気をつけなければならない。開放した場合にはランタイムエラーになる。
z) メソッド clear_extension と release_extension は、たとえば set_auto_extension でセットされた拡張のように自動削除としてマークされた拡張や release_extension ですでに開放された拡張のために呼び出してはならない。もしそうすると、ランタイムエラーになるかもしれない。
aa) 個々の汎用ペイロードのトランザクションは、すべての登録された拡張へのポインタを蓄えられる十分な領域を割り当てられなければならない。これは次の 2 つの方法のどちらかで達成できる。１つは C++の静的な初期化の後にトランザクション・オブジェクトを構築するとであり、
もう 1 つは静的な初期化の後で最初にトランザクション・オブジェクトを使う前にresize_extensions メソッドを呼び出すことである。前に述べたの方法において、拡張配列の大きさを設定するのは汎用ペイロードのコンストラクタの責任である。後に述べた方法において、最初に拡張にアクセスする前に resize_extensions メソッドを呼び出すのはアプリケーションの責任である。
bb) resize_extensions メソッドは、すべての登録された拡張に応じられるように汎用ペイロー
ドの中の拡張配列のサイズを増加させなければならない。
例// Showing an ignorable extension// User-defined extension classstruct ID_extension: tlm::tlm_extension<ID_extension>{
ID_extension() : transaction_id(0) {}- 181 -

virtual tlm_extension_base* clone() const { // Must override pure virtual clone method
ID_extension* t = new ID_extension;t->transaction_id = this->transaction_id;
return t;}// Must override pure virtual copy_from method
virtual void copy_from(tlm_extension_base const &ext) {transaction_id = static_cast<ID_extension const &>(ext).transaction_id;}
unsigned int transaction_id;};// The initiatorstruct Initiator: sc_module{ ...
void thread() {tlm::tlm_generic_payload trans;...
ID_extension* id_extension = new ID_extension;trans.set_extension( id_extension ); // Add the extension to the transactionfor (int i = 0; i < RUN_LENGTH; i += 4) {...
++ id_extension->transaction_id; // Increment the id for each new transaction...
socket->b_transport(trans, delay);...
// The target
virtual void b_transport( tlm::tlm_generic_payload& trans, sc_core::sc_time& t){ ...
ID_extension* id_extension;trans.get_extension( id_extension ); // Retrieve the extension
if (id_extension) { // Extension is not mandatorychar txt[80];sprintf(txt, "Received transaction id %d", id_extension->transaction_id);
SC_REPORT_INFO("TLM-2", txt);}...
// Showing a new protocol types class with a mandatory extension
struct cmd_extension: tlm::tlm_extension<cmd_extension>{ // User-defined mandatory extension class
cmd_extension(): increment(false) {}virtual tlm_extension_base* clone() const {cmd_extension* t = new cmd_extension;t->increment = this->increment;
return t;}
virtual void copy_from(tlm_extension_base const &ext) {increment = static_cast<cmd_extension const &>(ext).increment;}bool increment;};
struct my_protocol_types // User-defined protocol types class{typedef tlm::tlm_generic_payload tlm_payload_type;typedef tlm::tlm_phase tlm_phase_type;};- 182 -

struct Initiator: sc_module{
tlm_utils::simple_initiator_socket<Initiator, 32, my_protocol_types> socket;...
void thread() {tlm::tlm_generic_payload trans;
cmd_extension* extension = new cmd_extension;trans.set_extension( extension ); // Add the extension to the transaction...
trans.set_command(tlm::TLM_WRITE_COMMAND); // Execute a write commandsocket->b_transport(trans, delay);...
trans.set_command(tlm::TLM_IGNORE_COMMAND);extension->increment = true; // Execute an increment commandsocket->b_transport(trans, delay);...
...
// The target
tlm_utils::simple_target_socket<Memory, 32, my_protocol_types> socket;
virtual void b_transport( tlm::tlm_generic_payload& trans, sc_core::sc_time& t){
tlm::tlm_command cmd = trans.get_command();...
cmd_extension* extension;trans.get_extension( extension ); // Retrieve the command extension...
if (!extension) { // Check the extension exists
trans.set_response_status( tlm::TLM_GENERIC_ERROR_RESPONSE );return;}if (extension->increment) {if (cmd != tlm::TLM_IGNORE_COMMAND) { // Detect clash with read or write
trans.set_response_status( tlm::TLM_GENERIC_ERROR_RESPONSE );return;}++ m_storage[adr]; // Execute an increment command
memcpy(ptr, &m_storage[adr], len);}...

6.21 インスタンス固有の拡張
6.21.1 イントロダクション
汎用ペイロードは、個々のトランザクション・オブジェクトが個々の拡張型の１つまでのインスタンスを含むことができるように拡張オブジェクトへのポインタの配列を持たなければならない。
このメカニズム単体で、与えられたトランザクション・オブジェクトに同じ拡張の複数のインスタンスを直接加えることはできない。この節では、インスタンス固有の拡張を提供するユーティ
リティ一式、すなわち、単体のトランザクション・オブジェクトに加えられた同じ型の複数の拡張について述べる。
インスタンス固有の拡張の型は、tlm_extension クラスと同様な使い方で
instance_specific_extension クラステンプレートを使うことで作られる。tlm_extension と違って、アプリケーションは仮想メソッド clone と copy_from の実装を要求されないし許されない。
そのアクセス方法は set_extension と get_extension、clear_extension、resize_extension に制限される。インスタンス固有拡張の自動削除はサポートされない。だから、set_extension を呼ぶコンポーネントは clear_extension も呼び出さなければならない。tlm_extension クラスと同様に、resize_extensions メソッドはトランザクション・オブジェクトが静的初期化の間に作られたときだけ呼び出されなければならない。
インスタンス固有の拡張は、instance_specific_extension_accessor クラスのオブジェクトを使ってアクセスされる。このクラスはただ１つの operator()メソッドを提供し、そのメソッドはア- 183 -

クセスメソッドを呼び出すことができる間の代理オブジェクトを返す。
instance_specific_extension_accessor クラスの個々のオブジェクトは、同じトランザクショ
ン・オブジェクトに使われているときでさえ、拡張オブジェクトの別個のセットへのアクセスを与える。
以下のクラス定義においてイタリックの単語はアプリケーションによって直接使われてはならな
い。それは実装において定義される名前である。
6.21.2 クラス定義
namespace tlm_utils {template <typename T>class instance_specific_extension : public implementation-defined {public:virtual ~instance_specific_extension();};template<typename U>class proxy {public:template <typename T> T* set_extension(T* ext);
template <typename T> void get_extension(T*& ext) const;
template <typename T> void clear_extension(const T* ext);
void resize_extensions();};class instance_specific_extension_accessor {public:instance_specific_extension_accessor();
template<typename T> proxy< implementation-defined >& operator() ( T& );};} // namespace tlm_utils

例struct my_extn : tlm_utils::instance_specific_extension<my_extn> {int num; // User-defined extension attribute};struct Interconnect: sc_module{
tlm_utils::simple_target_socket<Interconnect> targ_socket;
tlm_utils::simple_initiator_socket<Interconnect> init_socket;...
tlm_utils::instance_specific_extension_accessor accessor;
static int count;virtual tlm::tlm_sync_enum nb_transport_fw(
tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ){my_extn* extn;
accessor(trans).get_extension(extn); // Get existing extension
if (extn) {accessor(trans).clear_extension(extn); // Delete existing extension} else {extn = new my_extn;
extn->num = count++;
accessor(trans).set_extension(extn); // Add new extension}
return init_socket->nb_transport_fw( trans, phase, delay );
} ...
};

- 184 -

... SC_CTOR(Top) {// Transaction object passes through two instances of Interconnect
interconnect1 = new Interconnect("interconnect1");
interconnect2 = new Interconnect("interconnect2");
interconnect1->init_socket.bind( interconnect2->targ_socket );...

7. フェーズと基本プロトコル
7.1 フェーズ
7.1.1 イントロダクション• tlm_phase クラスは、non-blocking transport インタフェース・クラスのテンプレートと基本
プロトコルによって使用されるデフォルト・フェーズ・タイプである。
• tlm_phase オブジェクトは unsigned int 値でフェーズを表す。
• unsigned int タイプ tlm_phase クラスは、4 つのベースプロトコル・フェーズ BEGIN_REQ、END_REQ、BEGIN_RESP、および END_RESP の列挙体に割り当てる。
• DECLARE_EXTENDED_PHASE マクロを使用して tlm_phase_enum として提供された 4 つのフェーズのセットは拡張することができる。
• このマクロは対応するオブジェクトを返す get_phase メソッドを持つ tlm_phase から拡張された別物のクラスを作成する。そのオブジェクトは新しいフェーズとして使用可能である。
• 各 application では相互利用性を最大限に生かすには tlm_phase_enum の 4 つのフェーズのみを使用すべきである。もし、 更なるフェーズが特定のプロトコルの詳細をモデル化するのに必要であるなら、DECLARE_EXTENDED_PHASE を使用すべきである。
• DECLARE_EXTENDED_PHASE は tlm_phase タイプとの互換性を有す。
• 無視可能 vs 必須な拡張の本質は汎用ペイロード拡張と同様にフェーズにも適用される。つまり、無視可能フェーズは基本プロトコルに許容される。
• 無視可能フェーズは、ターゲットとイニシエータ両方から無視可能にする必要がある。ターゲットの場合ターゲットがフェーズを見ていないかのように単に動作できるという意味での無視可能であって、イニシエータではターゲットからどんな応答がないときでもイニシエータが続けることができるという意味で無視可能でなければならない。
• この意味でフェーズを無視できないなら、新しいプロトコル・タイプのクラスを定義するべきである。
7.1.2 クラス定義
namespace tlm {enum tlm_phase_enum {UNINITIALIZED_PHASE=0, BEGIN_REQ=1, END_REQ, BEGIN_RESP, END_RESP };class tlm_phase{public:tlm_phase();tlm_phase( unsigned int );tlm_phase( const tlm_phase_enum& );tlm_phase& operator= ( const tlm_phase_enum& );operator unsigned int() const;};
inline std::ostream& operator<< ( std::ostream& , const tlm_phase& );#define DECLARE_EXTENDED_PHASE(name_arg) \class tlm_phase_##name_arg : public tlm::tlm_phase{ \public:\static const tlm_phase_##name_arg& get_phase();\implementation-defined \}; \static const tlm_phase_##name_arg& name_arg=tlm_phase_##name_arg::get_phase()} // namespace tlm

7.1.3 ルールa) デフォルトコンストラクタ tlm_phase はフェーズの値を 0 に設定するものとする。対応する列
挙体は文字通り UNINITIALIZED_PHASE である。
b) メソッドの tlm_phase( unsigned int)、operator= と operator unsigned int は対応する
unsigned int もしくは enum を使ってフェーズの値を得たり設定したりするものになる。
- 185 -

c) 機能オペレータ << はフェーズの名前に対応する文字列を与えられた出力ストリームに書くものとする。たとえば 「BEGIN_REQ」である。
d) DECLARE_EXTENDED_PHASE(arg)マクロは tlm_phase から拡張された tlm_phase_arg という新しい単独のクラスを創設する。tlm_phase は public メソッドの get_phase を持っていて static
object のリファレンスを返す。マクロの引数はオペレータ<<によって書かれた文字列として、指示された対応するフェーズが使用される。
e) static const name_arg によって指示されたオブジェクトは拡張フェーズを表し、それがフェーズ引数として nb_transport に渡されることが意図されている。
f) もし、受け取った拡張フェーズがコンポーネントで無視できないなら、アプリケーションは、関連するソケットをインスタンスする時、 新しいプロトコル・タイプのクラスを定義して、テン
プレート引数としてそのクラスの名前を使用するべきである。 これは、非互換なプロトコルのソケットとのバインディングを防ぐ。
g) 無視可能フェーズへのトランジションはどんな受取コンポーネントにも単に無視される場合もある。 nb_transport をコールする場合、呼ばれる側（callee）がフェーズへのトランジショ
ンを無視した時、値として TLM_ACCEPTED を返すべきである。
例
DECLARE_EXTENDED_PHASE(ignore_me); // Declare two extended phases
DECLARE_EXTENDED_PHASE(internal_ph); // Only used within target
struct Initiator: sc_module
{ ...
{ ...
phase = tlm::BEGIN_REQ;
delay = sc_time(10, SC_NS);
socket->nb_transport_fw( trans, phase, delay ); // Send phase BEGIN_REQ to target
phase = ignore_me; // Set phase variable to the extended phasedelay = sc_time(12, SC_NS);
socket->nb_transport_fw( trans, phase, delay ); // Send the extended phase 2ns later...
struct Target: sc_module{...
SC_CTOR(Target): m_peq("m_peq", this, &Target::peq_cb) {} // Register callback with PEQ
virtual tlm::tlm_sync_enum nb_transport_fw( tlm::tlm_generic_payload& trans,
tlm::tlm_phase& phase, sc_time& delay ) {cout << "Phase = " << phase << endl; // use overloaded operator<< to print phasem_peq.notify(trans, phase, delay); // Move transaction to internal queue
return tlm::TLM_ACCEPTED;}
void peq_cb(tlm::tlm_generic_payload& trans, const tlm::tlm_phase& phase){ // PEQ callback
sc_time delay;
tlm::tlm_phase phase_out;
if (phase == tlm::BEGIN_REQ) { // Received BEGIN_REQ from initiator
phase_out = tlm::END_REQ;
delay = sc_time(10, SC_NS);
socket->nb_transport_bw(trans, phase_out, delay); // Send END_REQ back to initiator
phase_out = internal_ph; // Use extended phase to signal internal event
delay = sc_time(15, SC_NS);
m_peq.notify(trans, phase_out, delay); // Put internal event into PEQ}
else if (phase == internal_ph) // Received internal event{
phase_out = tlm::BEGIN_RESP;
delay = sc_time(10, SC_NS);
socket->nb_transport_bw(trans, phase_out, delay); // Send BEGIN_RESP back to initiator}} // Ignore phase ignore_me from initiator- 186 -

tlm_utils::peq_with_cb_and_phase<Target, tlm::tlm_base_protocol_types> m_peq;};

7.2 基本プロトコル
7.2.1 イントロダクション• 基本プロトコルは、メモリ・マップド・バスへのインタフェースを持つコンポーネントのトラ
ンザクション・レベル・モデル間の最大限の相互利用性を確実にするために 1 セットの規則から成る。 基本プロトコルは以下の使用を必要とする。
1. TLM-2 コアトランスポート、ダイレクト・メモリ、およびデバッグトランスポートインタフ
ェース
2. ソケットのクラスの tlm_initiator_socket と tlm_target_socket(または、これらから派生したクラス)
3. 汎用ペイロードのクラス tlm_generic_payload
4. フェーズのクラス tlm_phase
5. 以下で定義される更なる 1 セットの規則• もし、無視可能なフェーズ拡張であれば、基本プロトコル規則は汎用ペイロードと、フェーズの拡張を可能にする。 無視可能でない拡張は新しいプロトコル・タイプのクラスの定義を必要とする。
• 基本プロトコルは事前に定義された tlm_base_protocol_types クラスによって表される。しかしながらこのクラスは、2 種類の型だけを定義される。 このクラス(ソケットへのテンプレー
ト引数としての)を使用するすべてのコンポーネントが、基本プロトコルの規則を尊重するのをコンベンションによって強いられる。
7.2.2 クラス定義
namespace tlm {struct tlm_base_protocol_types{
typedef tlm_generic_payload tlm_payload_type;typedef tlm_phase tlm_phase_type;};} // namespace tlm

7.2.3 Base protocol phase sequencesa) この項は、基本プロトコルに特定しているが、他のプロトコルをモデル化するのにノンブロッ
キング・トランスポート・インタフェースを使用するときのガイドとして使用されるかもしれない。他のプロトコルをモデル化する時、他のフェーズを定義することが必要であるが、その定義による基本プロトコルに相互運用性の損失の影響が出て来る可能性もある。
b) 基本プロトコルはブロッキング・トランスポート・インタフェース、ノンブロッキング・トラ
ンスポート・インタフェース、または両方同時使用を可能にする。ブロッキング・トランスポー
ト・インタフェースはフェーズ情報を運ばない。 基本プロトコルと共に使用される場合、
nb_transport を呼ぶ順番の強い規制管理がある。しかし、b_transport を呼び出す順番を管理す
るそのような規制は無い。したがって、 nb_transport は AT 記述に最適で、 b_transport は LT
記述に最適でる。
c) phase transition の完全なシーケンスは以下の通りである。
BEGIN_REQ → END_REQ → BEGIN_RESP → END_RESPd) BEGIN_REQ と END_RESP はイニシエータ・ソケットのみ送信可能である。 END_REQ と BEGIN_RESP
はターゲット・ソケットのみ送信可能である。
e) ブロッキング・トランスポート・インタフェースの場合、一つのトランザクション・インスタ
ンスの全ライフタイムは b_transport へのコールとその応答のリターンになる。また、
b_transport と BEGIN_REQ へのコール、および、 b_transport と BEGIN_RESP からのリターン、どの通信も純粋に概念的である。
f) 基本プロトコルには、TLM_UPDATED の値を持つ nb_transport への各コールと nb_transport からの各リターンはフェーズ・トランジションとする。つまり、同じトランザクションのための
nb_transport への 2 つの連続した呼び出しには、フェーズ引数に違う値を持つ。 無視可能なフェーズ拡張は受入れられる。その場合、拡張フェーズの挿入がこの規則の目的のために（フェーズが無視されても）phase transition とみなすものとなる。
g) nb_transport に TLM_COMPLETED の値を返させることによって、短く phase sequence を切るこ- 187 -

とができる。 TLM_COMPLETED のリターン値はトランザクションの終わりを示す、その場合、フェーズ引数が無視されるべきである。 (第 4.1.2.7 項 The tlm_sync_enum return value を参照) 。
TLM_COMPLETED が成功した終了を意味しないので、イニシエータは成否の確認のためにトランザ
クションの応答状態をチェックするべきである。 また、フェーズ END_RESP へのトランジション
はトランザクションの終わりを示すものとする。その場合、呼ばれる側（ callee）が TLM_COMPLETEDの値を返す義務は無い。
h) もし、イニシエータにおいて、END_REQ が最初に受信されていなくてターゲットからBEGIN_RESP を受ける場合、 イニシエータはすぐに、BEGIN_RESP に先行する暗黙の END_REQ を仮定するものとする。

Examples of early completioni) 前述のすべての規則を纏めると、許された phase transition sequences の組み合わせは以下の通りになる。経路(forward, backward or return)が括弧内に示されている。 無視可能なフェーズ拡張は任意な点で挿入されるかもしれない。 その都度、トランザクションはうまくいったりいかなかったりする場合もある。
BEGIN_REQ(fw) (target returns TLM_COMPLETED)BEGIN_REQ(fw) → END_REQ(bw) (initiator returns TLM_COMPLETED)BEGIN_REQ(fw) → BEGIN_RESP(bw) (initiator returns TLM_COMPLETED)BEGIN_REQ(fw) → END_REQ(rtn/bw) → BEGIN_RESP(bw) (initiator returns TLM_COMPLETED)BEGIN_REQ(fw) → BEGIN_RESP(rtn/bw) → END_RESP(rtn/fw)
BEGIN_REQ(fw) → END_REQ(rtn/bw) → BEGIN_RESP(bw) → END_RESP(rtn/fw)j) コンポーネントがイリーガルか out-of-order フェーズ・トランジションを受け取った場合、これは送信側の誤りである。 受信側の振舞いは未定義である。 これは、実行時にエラーが発生するかもしれないことを意味している。
7.2.4 Base protocol timing parameters and flow controla) 4 つのフェーズの場合、 request accept delay (or minimum initiation interval between
sending successive transactions) 、 request accept delay、 response accept delay をモデル化できる。 AT 記述には、この種類のタイミング精度は適切である。
b) 基本プロトコルの場合、 イニシエータは BEGIN_REQ フェーズを使って新トランザクションを始まる前にすぐ前のトランザクションから END_REQ か BEGIN_RESP を受けとるか、またはターゲッ
トが一つ前のトランザクションの終了を TLM_COMPLETED という値を nb_transport_fw から受けとるかで決まる。
c) 基本プロトコルの場合、ターゲットは BEGIN_RESP フェーズを使って新トランザクションを始
まる前にすぐ前のトランザクションから END_RESP を受けとるか、または イニシエータが一つ前のトランザクションの終了を TLM_COMPLETED という値を nb_transport_bw から受けとるかで決まる。
d) 与えられたソケットを通して non-blocking トランスポート・インタフェースを使用すること- 188 -

で、送られた連続したトランザクションはパイプライン化することができる。各 BEGIN_REQ(または、BEGIN_RESP) を END_REQ(または、END_RESP)で応じることによって、相互接続コンポーネン
トは、同時に、いろいろなトランザクション・オブジェクトを発行可能にすることができる。 すぐに END_REQ(または、END_RESP)で応じないことによって、相互接続コンポーネントはイニシエータ(または、ターゲット)から来るトランザクション・オブジェクトの流れにフロー制御を及ぼすことができる。

Approximately-timed timing parameterse) 与えられたソケットを通して 2 個のアウトスタンディング要求か応答の可能性を除くこの規則は、 non-blocking トランスポート・インタフェースに当てはまるだけで、 b_transport への呼び出しに直接影響を与えられない。(規則は b_transport 自身が nb_transport_fw とコールする
場合、b_transport への呼び出しに間接的に影響しているかもしれない。)
7.2.5 Base protocol transaction ordering rulesa) この項の規則は基本プロトコル、および単体の基本プロトコルに適用される。他のプロトコ
ル・タイプのクラスによって表された特定のプロトコルは、それら自身に必要な規則を持つ。
b) 同じトランザクション・オブジェクトか異なったトランザクション・オブジェクトにかかわらず連続した b_transport 呼び出しのタイミング・アノテートには決まった規制が全く無い。したがって、loosely-timed コード化スタイルに、ブロッキング・トランスポート・インタフェース
は適切である。
c) 与えられたトランザクション・オブジェクトのための nb_transport への連続した呼び出しのタイミング・アノテートには強く決められた規制がある。したがって、approximately-timed コ
ード化スタイルに、non-blocking トランスポート・インタフェースは適切である。
d) b_transport コールはリエントラントである。 b_transport の実装は、wait をさせることができる、そして、その間、同じトランザクション・オブジェクト（または、違うトランザクショ
ン・オブジェクト）のためにタイミング・アノテートの規制のない同じソケットを通して、
b_transport への別の call をかけることができる。
e) 与えられたトランザクション・オブジェクトのための与えられたソケットを通した
nb_transport への連続した呼び出しには、増加するタイミング・アノテートがあるものとする。
すなわち、t が時間引数である nb_transport の表現 sc_time_stamp() + t から計算された値のシーケンスは減少不可である。これは forward と backward パスで同じく適用される。
f) 異なったトランザクション・オブジェクトのための与えられたソケットを通した連続した
nb_transport 呼び出しのタイミング・アノテートには決まった規制が全く無い。
approximately-timed シミュレーションのために、タイミング・アノテート命令は通常、減少不可である。しかしながら、ブロッキングとノンブロッキング・トランスポート呼び出しが複雑であった場合では、異なったトランザクションのための nb_transport 呼び出しは out-of-order に現れることができる。
g) 各イニシエータが、減少不可のタイミング・アノテートで b_transport を呼ぶことが勧められる。(そして、減少不可のタイミング・アノテートで nb_transport と呼ぶのが強いられる。)二つの異なるイニシエータが loosely-timed の場合、起きたトランザクション・ストリームの収束時- 189 -

に Out-of-order タイミングアノテートは必要になる。
h) 与えられたソケットに関しては、イニシエータはブロッキング、ノンブロッキング・トランス
ポート・インタフェース、ダイレクト・メモリ・インタフェース、およびトランスポート・デバ
ッグ・インタフェースを通して一般的なペイロードのメモリ管理規則を条件として同じトランザ
クション・オブジェクトにパスすることができる。第 6.5 項の汎用ペイロード・メモリ管理を参照すること。
i) 与えられたソケットに関しては、イニシエータが異なったトランザクション・オブジェクトのためにブロッキングとノンブロッキング・トランスポート・インタフェースを切り換えることが許可されている。あらゆるターゲットがブロッキングとノンブロッキング・トランスポート・イ
ンタフェースの両方をサポートして、どのような内部状態情報も保守するのが強いられるので、それは両方のインタフェースからアクセスしやすくなっている。意図としては、イニシエータがloosely-timed と approximately-timed シミュレーションモードの間で切り替えのスイッチを作ることを許可することである。 b_transport と nb_transport_fw をインターリーブで呼び出すイ
ニシエータは、タイミング精度に関して低い期待を持つべきである。
j) b_transport と nb_transport_fw のどちらか 1 つを実装するのが必要なベース・プロトコル・
ターゲットがブロッキングとノンブロッキング・トランスポート・インタフェースの両方をサポートできるように、便利ソケット simple_target_socket を提供する。第 5.3.2 項の Simple ソケットを参照すること。
k) 与えられたトランザクション・オブジェクトに関しては、イニシエータはトランザクションのライフタイムの中頃でブロッキングとノンブロッキング・トランスポート・インタフェースを切り換えないものとする。言い換えれば、b_transport が戻る前にイニシエータは、nb_transport_fwと呼ばないものとする。または、未完了の BEGIN_REQ があるときには b_transport を call すること。
l) 同時に、複数の平行なソケット、または、複数の平行な経路で与えられたトランザクション・
オブジェクトを送らないものとする。それぞれのトランザクション・インスタンスはトランザク
ション・インスタンスのライフタイムが残っている間、1 セットのコンポーネントとソケットを通してユニークな明確な経路を取るものとする。そして、それはトランスポート、ダイレクト・
メモリ、およびデバッグ・トランスポート・インタフェースに共通である。もちろん、与えられたソケットを通して送られた異なったトランザクションは、異なった経路を取るかもしれない。
すなわち、それらが異なって送られるかもしれない。
m) Write トランザクション(TLM_WRITE_COMMAND)のために、TLM_OK_RESPONSE の応答状態は、write
コマンドがターゲットで完了した状態で持っているのを示すものとする。ターゲットはトランジションで BEGIN_RESP フェーズに応答状態を設定するのが強いられる。言い換えると、相互接続コンポーネントがターゲットからうまくいった完了の確認を持っていなくて Write コマンドトラン
ザクションを終了するのが許容されていない。この規則の意図は、ターゲット・シミュレーショ
ン・モデルの中でストレージのコヒーレンシーを保証することである。
n) Read トランザクション(TLM_READ_COMMAND)のために、 TLM_OK_RESPONSE の状態は、Read コマンドが終了し、汎用ペイロード・データ配列がターゲットによって変更されたことを示すものとする。ターゲットがトランジションで BEGIN_RESP フェーズに応答状態を設定するのが強いられる。
7.2.6 Summary of obligations on base protocol components• これは、本書の他の場所でより完全に提示されたいくつかの規則の簡潔な再表示であり、単に便利さを提供しているものである。
7.2.6.1 Obligations on an initiator
基本プロトコルを使用するとき、これはイニシエータの義務の概要である:
a) 各接続にクラス tlm_initiator_socket(または、派生しているクラス)の 1 個のイニシエータ・
ソケットをメモリ・マップド・バスに使用すること。
b) デフォルト・テンプレート・タイプ引数 tlm_base_protocol_types を tlm_initiator_socketに使用すること。
c) メソッドの nb_transport_bw と invalidate_direct_mem_ptr を実装すること。
d) 呼び出しの前に忘れずに応答状態と DMI ヒント属性を特にいつもリセットして、引数として
b_transport か nb_transport_fw にそれを通過する前にそれぞれの汎用ペイロード・トランザク
ション・オブジェクトのあらゆる属性を設定すること。
e) トランザクションが、extend される必要があるなら、汎用ペイロードの拡張メカニズムだけ- 190 -

を使用すること。そして、どんな拡張も無視可能であることをターゲットとあらゆるインターコ
ネクトで許可すること。
f) 引数として b_transport、nb_transport_fw または nb_transport_bw に通過されたあらゆるタ
イミング・アノテートを受け取ること。
g) トランザクション(または BEGIN_RESP を受けた後に)の完了のときに、応答状態属性の値をチェックすること。
7.2.6.2 Obligations on an initiator using nb_transporta) 引数としてトランザクションを nb_transport_fw に渡す前に、トランザクション・オブジェク
トにメモリ・マネージャを設定すること。そして、トランザクションのアクワイアー・メソッド
を call すること。トランザクションが完了するときにはリリース・メソッドを call すること。
b) nb_transport_fw と呼ぶときには、トランザクションの状態に従って、BEGIN_REQ か END_RESPにフェーズ引数を設定すること。前のトランザクションのための END_REQ を受けるまで(または、暗示するまで) BEGIN_REQ を送らないこと。
c) 与えられたトランザクションのために nb_transport_fw と呼ぶときには、現在のシミュレーシ
ョン時間に加えられるタイミング・アノテートが、値の非減少シーケンスを形成するのを確実にすること。
d) メソッド nb_transport_bw の実装では、適切に入って来るフェーズ値の END_REQ と BEGIN_RESPに応じること。BEGIN_REQ と END_RESP として入って来るフェーズ値は不正である。他のすべての入って来るフェーズ値は無視可能なものとして扱うこと。
7.2.6.3 Obligations on a target
基本プロトコルを使用するとき、これはターゲット上の義務の概要である:
a) 各接続にクラス tlm_target_socket(または、派生しているクラス)の 1 個のターゲット・ソケ
ットをメモリ・マップド・バスに使用すること。
b) デフォルト・テンプレート・タイプ引数 tlm_base_protocol_types を tlm_target_socket に使用すること。
c) メソッドの b_transport、nb_transport_fw、get_direct_mem_ptr、および transport_dbg を実装すること。(ターゲットは便利ソケット simple_target_socket を使用することによって明らかにあらゆるメソッドを実装する必要性を避けることができる。)
d) メソッドの b_transport と nb_transport_fw の実装では、応答状態の例外、DMI ヒント、および各種拡張を含む、汎用ペイロードのあらゆる属性の値を点検して、作用すること。汎用ペイロードの完全な機能性を実装するよりむしろ、ターゲットは、誤り応答を発生させることによって与えられた属性に応じるのを選べるようにすること。応答状態属性の値にトランザクションの成否を示すように設定すること。
e) 引数として b_transport、nb_transport_fw または nb_transport_bw にパスされたあらゆるタ
イミング・アノテートを受け取ること。
f) get_direct_mem_ptr の実装では、値の false を返すか、コマンドの値と汎用ペイロードのア
ドレス属性を点検して、作用すること、そして、適切に DMI 記述子のすべての属性を設定すること。 (クラス tlm_dmi)g) transport_dbg の実装では、値 0 を返すか、汎用ペイロードのコマンド、アドレス、データの長さ、およびデータ・ポインタ属性の値を点検して、作用すること。
h) 各インタフェースに関しては、ターゲットは、汎用ペイロードにおけるどんな無視可能な拡張も点検して、作用するかもしれないが、そうすることは強制されない。
7.2.6.4 Obligations on a target using nb_transporta) nb_transport_bw と呼ぶときには、トランザクションの状態に従って、END_REQ か BEGIN_RESPにフェーズ引数を設定すること。前のトランザクションのために END_RESP を受けるまで(または、暗示されるまで) BEGIN_RESP を送らないこと。
b) 与えられたトランザクションのための nb_transport_bw と呼ぶときには、現在のシミュレーシ
ョン時間に加えられる値の非減少しているシーケンスを形成するタイミング・アノテーションを確実にすること。
c) メソッド nb_transport_fw の実装では、適切に入って来るフェーズ値の BEGIN_REQ と END_RESPに応じること。 END_REQ と BEGIN_RESP が入って来るフェーズ値は不正である。他のすべての入って来るフェーズ値を無視可能であるとして扱うこと。
d) nb_transport_fw の実装で、return を超えてトランザクション・オブジェクトのポインタか参- 191 -

照を保つのが必要であるときには、トランザクションのアクワイアー・メソッドを call すること。
トランザクション・オブジェクトが使い終わられたらリリース・メソッドを call すること。
7.2.6.5 Obligations on an interconnect componenta) 各接続にクラス tlm_initiator_socket か tlm_target_socket(または、派生されたクラス)の 1
個のイニシエータかターゲット・ソケットをメモリ・マップド・バスに使用すること。
b) 各ソケットにデフォルト・テンプレート・タイプ引数 tlm_base_protocol_types を使用すること。
c) それぞれのイニシエータ・ソケットのためにメソッドの nb_transport_bw とinvalidate_direct_mem_ptr を実装して、それぞれのターゲット・ソケットのためにメソッドのb_transport、nb_transport_fw、get_direct_mem_ptr、および transport_dbg を実装すること。 (便利ソケットを使用することによって、明らかにあらゆるメソッドを実装する必要性を避けることができる。)d) 両方の forward と backward パスの適切なソケットを通してあらゆる入って来るトランザク
ション・オブジェクトを伝えること。唯一の例外は get_direct_mem_ptr と transport_dbg メソッドの実装である。(トランザクション・オブジェクトを進めないで、それぞれ値 false と 0 を返す
かもしれない)。
e) トランスポート・インタフェースの実装では、インターコネクト・コンポーネントで修正できる唯一の汎用ペイロード属性は、アドレスと、DMI ヒントと、拡張である。いかなる他の属性も変更しないこと。いかなる他の属性も変更する必要があるコンポーネントは、新しいトランザク
ション・オブジェクトを組み立てて、その結果、それ自体でイニシエータになるはずである。
f) トランスポート・インタフェースの実装では、イニシエータとターゲットのために上で説明されるようにフェーズとタイミング・アノテートのための基本プロトコル規則を受け取ること。
g) フォワード・パスの汎用ペイロードアドレス属性を解読すること、そして、必要なら、ターゲットの位置に従って、システム・メモリ・マップでアドレス属性を変更すること。これはトラン
スポート、ダイレクト・メモリ、およびデバッグトランスポートインタフェースに適用される。
h) get_direct_mem_ptr の実装では、フォワード・パスのどんな DMI 記述子属性も変更しないこと。 DMI ポインタ、DMI 開始アドレス、および終わりのアドレスを変更すること。そうすれば、DMI はリターン・パスで適切に属性にアクセスする。
i) invalidate_direct_mem_ptr の実装では、バックワード・パスに沿って呼び出しを通過する前に、アドレスレンジ引数を変更すること。
j) nb_transport_fw の実現で、機能からのリターンを超えてトランザクション・オブジェクトのポインタか参照を保つのが必要であるときは、
トランザクションのアクワイアー・メソッドを callすること。トランザクション・オブジェクトが使い終わったらリリース・メソッドを call すること。
k) 各インタフェースに関して、インターコネクトは、汎用ペイロードにおけるどんな無視可能拡張も検査して、作用するかもしれないが、そうすることを強制するわけではない。トランザクシ
ョンが、さらに拡張される必要があるなら、汎用ペイロード拡張メカニズムだけを使用すること、
そして、どんな拡張もターゲットや相互接続で無視可能な拡張を許可すること。拡張のための汎用ペイロード・メモリ管理規則を守ること。
8. その他のクラス
8.1 グローバル・クォンタムとクォンタム・キーパー
8.1.1 イントロダクション
テンポラル・デカップリング機能は、SystemC のプロセスに対して、クォンタムと呼ばれる時間
を実際のシミュレーション時刻より先に進めるもので、LT コーディング・スタイルと関連付けて用いられる。テンポラル・デカップリング機能を用いると、スレッドのコンテクスト・スイッチとイベントを減らすことにより非常に高速なシミュレーション速度が実現できる。
テンポラル・デカップリング機能を用いる時には、b_transport()および nb_transport()の引数によって渡される時間は、クォンタム時間の開始（通常、sc_time_stamp()の戻り値である現在のシミュレーション時刻）からの相対時間として定義される。
グローバル・クォンタム時間の値は、唯一の tlm_global_quantum クラスによって管理される。各プロセスはグローバル・クォンタム時間を使うべきだが、1 つのプロセスは、自身のローカル・
クォンタム時間の計算を行うことだけが許可されている。
tlm_quantumkeeper クラスには、クォンタム時間に対して制御するためのメソッドが用意されて- 192 -

いる。
テンポラル・デカップリング機能を用いる時には、一定のコーディング・スタイルを保つために、
クォンタム・キーパーを用いることを強く推奨する。しかしながら、SystemC 記述の中にこの機能を実装するということも可能である。tlm_quantumkeeper クラスの使用有無に関わらず、テン
ポラル・デカップリング機能を用いる全てのモデルは、tlm_global_quantum クラスによって管理されるグローバル・クォンタムを参照すべきである。
tlm_global_quantum クラスのネームスペースは tlm で、tlm_quantumkeeper クラスのネームスペースは tlm_utils である。
テンポラル・デカップリングの詳細については、3.3.2 章 LT コーディング・スタイルとテンポラ
ル・デカップリングも参照のこと。
タイミング・アノテーションに関しては、4.1.3 章トランスポート・インタフェースを用いたタ
イミング・アノテーションも参照のこと。
8.1.2 クラス定義
namespace tlm {class tlm_global_quantum{
public:static tlm_global_quantum& instance();virtual ~tlm_global_quantum();void set( const sc_core::sc_time& );const sc_core::sc_time& get() const;
sc_core::sc_time compute_local_quantum();protected:
tlm_global_quantum();};} // namespace tlm
namespace tlm_utils {class tlm_quantumkeeper{
public:static void set_global_quantum( const sc_core::sc_time& );static const sc_core::sc_time& get_global_quantum();tlm_quantumkeeper();
virtual ~tlm_quantumkeeper();
virtual void inc( const sc_core::sc_time& );virtual void set( const sc_core::sc_time& );virtual sc_core::sc_time get_current_time() const;
virtual sc_core::sc_time get_local_time();virtual bool need_sync() const;
virtual void reset();virtual void sync();protected:
virtual sc_core::sc_time compute_local_quantum();};} // namespace tlm_utils

8.1.3 テンポラル・デカップリングの使い方に関する一般ルールa) 最大のシミュレーション速度を実現するためには、全てのイニシエータ・モデルがテンポラ
ル・デカップリングを用い、他の SystemC プロセスは全く存在しないか、必要最小限に抑える必要がある。
b) 理想的には、テンポラル・デカップリングを持つイニシエータ・モデルのみに、SystemC プロ
セスがあり、それぞれの SystemC プロセスにおいては、時間を先に進めておき、クォンタム量を超えた時のみシミュレーション・カーネルに戻る(Yield)ようにする。
c) クォンタム時間は、イニシエータ間の一般的な間隔よりも小さくなるよう設定すべきである。
d) Yield とは、SC_THREAD または SC_CTHREAD の場合には、wait()を実行すること、SC_METHOD の場合には、関数から return することを意味する。
e) テンポラル・デカップリングといえども、あくまでも標準的な SystemC カーネル上で動作するものであるので、イベントはスケジュールできるし、プロセスは停止、再開することもでき、LT- 193 -

コーディング・スタイルは他のコーディング・スタイルと混在できる。
f) すべてのイニシエータがテンポラル・デカップリングを使用しなければいけないというわけではない。使用しているプロセスと使用していないプロセスは混在可能である。しかし、そうすると、シミュレーション速度が落ちてしまう。
g) テンポラル・デカップリングを行う各イニシエータは、本章で説明するローカル・オフセット
時間変数を用いて、ローカルな処理時間と通信時間を計算する。クォンタム・キーパーがローカ
ル・オフセット時間を管理することを強く推奨する。
h) sc_time_stamp()を呼んだときにはあくまでも現在のクォンタムが開始した実シミュレーショ
ン時間を返す。
i) ローカル・オフセット時間は、SystemC スケジューラからは不明である。トランスポート・イ
ンタフェースを使用する場合は、b_transport()あるいは nb_transport()関数の引数にローカル・
オフセット時間を渡すべきである。
j) nb_transport()関数でテンポラル・デカップリングやクォンタム・キーパーを使用することは、ルールの範囲外である。しかし、AT コーディング・スタイル固有のプロセス間通信のオーバーヘ
ッドが大きく、テンポラル・デカップリングによる速度の利点が無効になる可能性があるため、常に有利に働くとは限らない。
k) ローカルでないオブジェクトの値を読み出した場合には自他のプロセスで変更しない限り、あくまでもクォンタムの開始した実際の時間における値を返す。とくに、sc_signal の値はアップ
デートされない。
8.1.4 tlm_global_quantum クラスa) tlm_global_quantum クラスによって単一のグローバルなクォンタム時間(同期間隔)が定義される。これがクォンタム時間のデフォルトとなる。テンポラル・デカップリングをサポートしているイニシエータ・モデルは、おおよそこのクォンタム時間が来るごとに実際のシミュレーショ
ン時間との間で同期が図られる。ただし、ターゲットの要求によってはそれよりも頻繁に同期が実行される場合もある。
b) それぞれのイニシエータ・モデルはそれぞれ別のクォンタム時間を持つことも可能であるが、一般的には全てのイニシエータ・モデルはグローバルなクォンタム時間を持つ。同期の回数が少なくてもすむイニシエータは他よりクォンタム時間を長く設定できるわけではあるが、一般的には、同期の回数が多く必要なモデルがもっともシミュレーション時間に大きく影響してしまうからである。
c) instance()メソッドは、唯一のグローバル・クォンタム・オブジェクトのリファレンスを返す。
d) set()メソッドは、引数で受け取った値をグローバル・クォンタム値として設定する。
e) get()メソッドは、グローバル・クォンタムの値を返す。
f) compute_local_quantum()は、唯一のグローバル・クォンタムを元に、ローカル・クォンタムの値を計算して返す。グローバル・クォンタムの次の倍数から、sc_time_stamp の値を引くことにより計算する。compute_local_quantum()がグローバル・クォンタムの整数倍のシミュレーショ
ン時間でコールされる場合は、ローカル・クォンタムはグローバル・クォンタムと等しい。そう
でない場合は、ローカル・クォンタムはグローバル・クォンタムよりも小さい。
8.1.5 tlm_quantumkeeper クラスa) コンストラクタはローカル・タイムのオフセットを SC_TIME_ZERO に設定するが、仮想関数のcompute_local_quantum()はコールしない。これは、コンストラクタでローカル・クォンタムを計算せずに、アプリケーションがクォンタム・キーパー・オブジェクトを生成直後に、reset()メソッドをコールからである。
b) tlm_quantum_keeper クラスの実装では、sc_time クラスの静的オブジェクトは生成せずに、コンストラクタが sc_time クラスのオブジェクトを生成してもよい。これは、アプリケーションが最初のクォンタム・キーパー・オブジェクトを生成する前に、sc_core::sc_set_time_resolution()関数をコールしてもよいことを意味している。
c) set_global_quantum()メソッドは、グローバル・クォンタム時間を引数によって設定する。しかしローカルのクォンタム時間は変更されない。get_global_quantum()メソッドはグローバル・
クォンタム時間を返す。set_global_quantum()を呼んだ後には、reset()メソッドを呼び出し、ローカル・クォンタム時間を再計算させることが望ましい。
d) get_local_time()メソッドはローカル・オフセット時間を返す。
e) get_current_time()メソッドは、ローカル時間、すなわち、sc_time_stamp()+ローカル・オフ- 194 -

セット時間を返す。
f) inc()メソッドは、ローカル・オフセット時間を引数によって渡しローカル時間を実時間よりも先に進める。
g) set()メソッドは、引数で渡された値をローカル・オフセット時間に設定する。
h) need_sync()メソッドは、現在のローカル・オフセット時間がローカル・クォンタムより大きい時に true を返す。
i) sync()メソッドは、wait(ローカル・オフセット時間)を呼び出し、実際のシミュレーション時
間とローカルの時間との同期をとり、reset()メソッドを呼び出す。
j) reset()メソッドは、compute_local_quantum()を呼び出し、ローカル・オフセット時間を 0 に戻す。
k) tlm_quantumkeeper クラスの compute_local_quantum()メソッドは、tlm_global_quantum クラ
スの compute_local_quantum メソッドを呼び出す。
l) tlm_quantum_keeper クラスはクォンタム・キーパーのデフォルトの実装となり、このクラスを継承したクラスを作り、compute_local_quantum メソッドを書き換えることが可能ではあるが、普通ではない。
m) ローカル・オフセット時間がローカル・クォンタム以上になった場合には、プロセスを yield
させる必要があるが、自分で wait()を呼び出さないで、sync()メソッドを呼び出すことを強く推奨する。
n) ローカル・クォンタム量を超えた場合に同期を自動的に実行するようなしかけはない。したがって、イニシエータは自分で need_sync メソッドを呼び出し、必要に応じて sync()を呼び出す必要がある。
o) b_transport()メソッドは、そのコール前後でグローバル時間が変化していた場合に、自身でyield するかもしれない。ローカル・オフセット時間やタイミング・アノテーションの値は、常にグローバル時刻からの相対値で表現される。b_transport()あるいは nb_transport_fw()からの戻りでは、イニシエータが set()メソッドのコールによって、クォンタム・キーパーのローカル・
オフセット時間を設定し、need_sync()メソッドのコールによって同期チェックを行う必要がある。
p) イニシエータがローカル・クォンタム量を超えるよりも前に実行をサスペンドして、実時間を先に進んでしまっているローカル時間に追いつかせる必要が生じた場合、sync()を呼び出すか、あるいは明示的に別のイベントを wait させてもいい。途中で同期させるこの方法を、
sync-on-demand(要求に応じた同期)と呼ぶ。
q) sync()を頻繁にコールし過ぎると、テンポラル・デカップリングの効果が減ってしまう
例
struct Initiator: sc_module // Loosely-timed initiator{
tlm_utils::simple_initiator_socket<Initiator> init_socket;
tlm_utils::tlm_quantumkeeper m_qk; // The quantum keeper
SC_CTOR(Initiator) : init_socket("init_socket") {SC_THREAD(thread); // The initiator process...
m_qk.set_global_quantum( sc_time(1, SC_US) ); // Replace the global quantum
m_qk.reset(); // Re-calculate the local quantum}
void thread() {tlm::tlm_generic_payload trans;
sc_time delay;trans.set_command(tlm::TLM_WRITE_COMMAND);trans.set_data_length(4);for (int i = 0; i < RUN_LENGTH; i += 4) {int word = i;trans.set_address(i);trans.set_data_ptr( (unsigned char*)(&word) );delay = m_qk.get_local_time(); // Annotate b_transport with local time
init_socket->b_transport(trans, delay );qk.set( delay ); // Update qk with time consumed by target
m_qk.inc( sc_time(100, SC_NS) ); // Further time consumed by initiator
if ( m_qk.need_sync() ) m_qk.sync(); // Check local time against quantum}- 195 -

}...
};

8.2 ペイロード・イベント・キュー
8.2.1 イントロダクション
ペイロード・イベント・キュー(PEQ)は、トランザクション・オブジェクトに関連付けられた SystemCのイベント通知用のキューである。それぞれのトランザクションは遅延と共に PEQ 内に格納され、現在のシミュレーション時間と設定された遅延時間の合計時間になった時点で PEQ から出力される。
２つのペイロード・イベント・キューがユーティリティとして提供されている。PEQ は便利なだ
けではなく、AT コーディング・スタイルにおけるタイミング・アノテーションの仕組みを理解する上でも概念的に関連がある。
しかし、ここで説明するペイロード・イベント・キューを使わなくても、アプロキシメイトリー・
タイムド・モデルの実装は可能である。アプロキシメイトリー・タイムド・モデルでは、
nb_transport()によって遅延時間を持つトランザクションを受け取る時、PEQ への格納が適している。PEQ は、正確なシミュレーション時間に発生する nb_transport()コールに関するタイミン
グ・ポイントをスケジューリングする。
PEQ の notify()メソッドを、引数にディレイを指定してコールすることにより、PEQ へトランザ
クションを格納する。引数を取らずに、すぐにスケジューラへ通知を行う notify()メソッドも存在している。
遅延時間は現在のシミュレーション時間(sc_time_stamp)との加算に使われ、トランザクションがPEQ の最後から出力する時間となる。イベントのスケジューリングは、内部的に sc_event クラス
を利用し、SystemC の時間イベント通知によって管理される。待ち状態のイベント通知がある時に notify()メソッドがコールされた場合は、他の通知がキャンセルまでの間、最も早いシミュレーション時間における通知が残ったままとなる。
PEQ には 2 種類があって、それぞれトランザクションの取り出し方法が異なる。peq_with_get の場合は、get_event()メソッドをコールすると、取り出しが可能な状態のトランザクションに関連するイベントを返す。get_next_transaction()メソッドは、あるタイミングで有効になっている
トランザクションの 1 つを取り出すために、繰り返しコールされるメソッドである。評価フェー
ズにおいてイベント通知が発生した時に PEQ からトランザクションを取り出すことができない場
合には、その後のタイミングで再度 get_next_taransaction()コールによって取り出すまでトラ
ンザクションは有効なまま継続する。受け取れるトランザクションが１つもない場合は、
get_next_transaction()は NULL ポインタを返す。
peq_with_cb_and_phase の場合は、コールバック・メソッドをコンストラクタ引数に登録することで、各トランザクションを取り出す際にそのコールバック・メソッドがコールされる。この PEQを用いる場合には、通知ごとにトランザクション・オブジェクトとフェーズ・オブジェクトの両方が、コールバック関数の引数として渡される。
トランザクションは PEQ に追加された順番ではなく、シミュレーション時間とディレイ引数の合計で決まるスケジュール時間順に基づいて取り出される。同じ時間に取り出し可能なトランザク
ションが複数ある場合には、同一のデルタ・サイクルで、追加された順番に従って１つずつトラ
ンザクションを取り出せる。トランザクションが失われたりキャンセルされることはない。
8.2.2 クラス定義
namespace tlm_utils {template <class PAYLOAD>
class peq_with_get : public sc_core::sc_object{
public:typedef PAYLOAD transaction_type;
peq_with_get(const char* name);
void notify(transaction_type& trans, sc_core::sc_time& t);
void notify(transaction_type& trans);transaction_type* get_next_transaction();sc_core::sc_event& get_event();};- 196 -

template<typename OWNER, typename TYPES=tlm::tlm_base_protocol_types>
class peq_with_cb_and_phase : public sc_core::sc_object{
public:typedef typename TYPES::tlm_payload_type tlm_payload_type;typedef typename TYPES::tlm_phase_type tlm_phase_type;typedef void (OWNER::*cb)(tlm_payload_type&, const tlm_phase_type&);
peq_with_cb_and_phase(OWNER* , cb );peq_with_cb_and_phase(const char* , OWNER* , cb);~peq_with_cb_and_phase();void notify (tlm_payload_type& , tlm_phase_type& , const sc_core::sc_time& );void notify (tlm_payload_type& , tlm_phase_type& );};} // namespace tlm_utils

8.3 アナリシス・インタフェースとアナリシス・ポート
アナリシス・ポートは、複数のコンポーネントにまたがるトランザクションに対する解析機能、
例えば、機能の正確性をチェックするとか機能カバレージ情報を取得するなどを実現するために使用される。
アナリシス・ポートのもっとも大切な点は、一つのアナリシス・ポートが複数のチャネル(サブスクライバー)にバインド可能であり、アナリシス・ポートに対して write()をコールしたときにそれぞれのサブスクライバーに対して同一の write()をコールさせるようにすることである。アナリシス・ポートは 0 以上複数のサブスクライバーに対してバインドすることができ、バインドしなくても構わない。
それぞれのサブスクライバーは、tlm_analysis_if の write()メソッドを実装する。このメソッド
は const reference によってトランザクションに渡され、サブスクライバーはただちに処理を実行する。もし、サブスクライバーがトランザクションのライフタイムを延長しておきたいような場合には、自分でトランザクション(generic_payload)に対する deep_copy()メソッドを行い、サブスクライバー自身がコピーして作成したトランザクションの持ち主になり自分でメモリ管理を行うことになる。
アナリシス・ポートはモデルの動作そのものに関わるようなことに対して用いてはならず、その他の解析等の側面的な解析機能のみで使用しなければならない。 tlm_analysis_if インタフェー
スは、tlm_write_if を継承したクラスである。この tlm_write_if は、アナリシスの目的だけではなく、他の目的にも使用可能である。例えば、8.2 の Payload event queue においても用いられている。
TLM2 キットには、tlm_analysis_fifo という、段数が無限の tlm_fifo に対して tlm_alansysis_if
を用いてトランザクションを write できるようにするものが含まれている。tlm_fifo は、
tlm_analysis_triple というトランザクションと、開始時間、終了時間を含むものもサポートしている。
8.3.1 クラス定義
namespace tlm {// Write interface
template <typename T>class tlm_write_if : public virtual sc_core::sc_interface {public:virtual void write( const T& ) = 0;};
template <typename T>class tlm_delayed_write_if : public virtual sc_core::sc_interface {public:virtual void write( const T& , const sc_core::sc_time& ) = 0;};// Analysis interface
template < typename T >class tlm_analysis_if : public virtual tlm_write_if<T>{- 197 -

};
template < typename T >class tlm_delayed_analysis_if : public virtual tlm_delayed_write_if<T>{};// Analysis port
template < typename T>class tlm_analysis_port : public sc_core::sc_object , public virtual tlm_analysis_if< T >{public:tlm_analysis_port();tlm_analysis_port( const char * );// bind and () work for both interfaces and analysis ports, since analysis ports implement the analysis
interfacevoid bind( tlm_analysis_if<T> & );void operator() ( tlm_analysis_if<T> & );bool unbind( tlm_analysis_if<T> & );void write( const T & );};// Analysis triple
template< typename T>
struct tlm_analysis_triple {sc_core::sc_time start_time;
T transaction;sc_core::sc_time end_time;// Constructors
tlm_analysis_triple();tlm_analysis_triple( const tlm_analysis_triple &triple );tlm_analysis_triple( const T &t );operator T() { return transaction; }operator const T& () const { return transaction; }};// Analysis fifo - an unbounded tlm_fifo
template< typename T >class tlm_analysis_fifo :public tlm_fifo< T > ,public virtual tlm_analysis_if< T > ,public virtual tlm_analysis_if< tlm_analysis_triple< T > > {public:tlm_analysis_fifo( const char *nm ) : tlm_fifo<T>( nm, -16 ) {}tlm_analysis_fifo() : tlm_fifo<T>( -16 ) {}void write( const tlm_analysis_triple<T> &t ) { nb_put( t ); }void write( const T &t ) { nb_put( t ); }};} // namespace tlm

8.3.2 ルールa) tlm_write_if と tlm_analysis_if は、単方向、ネゴシエーション無し、ノンブロッキングのインタフェースであり、引数で渡されるトランザクションに対して即座に応答しなければならない。
b) tlm_analysis_port のコンストラクタは、ポートのインスタンス名の文字列を引数として使用する。これは、ベースクラスの sc_object に渡される。
c) bind メソッドは、サブスクライバーのアナリシス・ポートのインスタンスを登録し、write メ
ソッドが呼ばれたときに登録されたサブスクライバー内の write メソッドが呼ばれる。複数のサ
ブスクライバーを単一のアナリシスポートインスタンスに登録することも可能。
d) operator() は、bind()メソッドと同一。
e) サブスクライバーの数が 0 であっても構わない。その場合には、write()メソッドは伝達され- 198 -

ない。
f) unbind()メソッドは、bind()の逆であり、サブスクライバーのリストから削除される。
g) tlm_analysys_port の write()メソッドが呼ばれた場合、そのポートに登録されたすべてのサブスクライバーに対して、write()メソッドが const リファレンスの引数と共に呼ばれる。
h) write()メソッドはノンブロッキングであり、その実装の中に wait()を含んではいけない。
i) write()メソッドは、const reference によって渡されたトランザクションの内容や、その中のポインタ先のデータ(data,バイトイネーブル配列)を書き換えてはいけない。
j) もし、write()メソッドが return する前にそのトランザクション・オブジェクトに対しての処理を完了することができない場合には、新しいトランザクション・オブジェクトを deep_copy()
メソッドによってコピーしてから実行する。コピーされたオブジェクトのメモリ管理はサブスク
ライバーが責任を負う。
k) tlm_analysys_fifo クラスのコンストラクタは、bound されてない tlm_fifo を構成する。
l) tlm_analysys_fifo クラスの write()メソッドは tlm_fifo ベースクラスの nb_put()を同一の引数とともに呼び出す。
例
struct Trans // Analysis transaction class{
int i;};
struct Subscriber: sc_object, tlm::tlm_analysis_if<Trans>{
Subscriber(const char* n) : sc_object(n) {}virtual void write(const Trans& t){
cout << "Hello, got " << t.i << "\n"; // Implementation of the write method}};
SC_MODULE(Child){
tlm::tlm_analysis_port<Trans> ap;
SC_CTOR(Child) : ap("ap"){SC_THREAD(thread);}void thread(){
Trans t = {999};
ap.write(t); // Interface method call to the write method of the analysis port}};
SC_MODULE(Parent){
tlm::tlm_analysis_port<Trans> ap;
Child* child;
SC_CTOR(Parent) : ap("ap"){child = new Child("child");
child->ap.bind(ap); // Bind analysis port of child to analysis port of parent}};
SC_MODULE(Top){
Parent* parent;
Subscriber* subscriber1;
Subscriber* subscriber2;- 199 -

SC_CTOR(Top){parent = new Parent("parent");
subscriber1 = new Subscriber("subscriber1");
subscriber2 = new Subscriber("subscriber2");
parent->ap.bind( *subscriber1 ); // Bind analysis port to two separate subscribers
parent->ap.bind( *subscriber2 ); // This is the key feature of analysis ports}};

9. TLM1 レガシー
以下の TLM1 のコア・インタフェース及び tlm_fifo チャネルは依然として TLM 2.0 標準であるが、このドキュメントでは詳しく触れない。
9.1 TLM1 コア・インタフェース
シグネチャ付きのトランスポート・メソッドである transport( const REQ& , RSP& ) は TLM 1.0に含まれていなかったが、TLM 2.0 において付け加えられた。
9.2 TLM1 fifo インタフェース（省略）
9.3 tlm_fifo（省略）- 200 -

1. TLM 2.0 Glossary (用語集)
注：青字は SystemC LRM にて定義・使用されている用語
Words
Descriptions
A module that connects atransaction level interface to apin level interface (in thegeneral sense of the wordinterface) or that connects
together two transaction level
adaptorinterfaces, often at different
abstraction levels. Typically, an
adaptor is used to convert between
two transaction-level interfacesofdifferent
types.
Seetransactor.
A modeling style for which there
exists a one-to-one mapping
between the externally observablestates of the model and the statesof some corresponding detailed
approximately
reference model such that the
timed (AT)mapping preserves the sequence ofstate transitions but not theirprecise timing. The degree oftiming accuracy is undefined. See
cycle approximate.
Data that is part of and carried
with the transaction and is
implemented as a member of thetransaction object. These may
attribute (of ainclude attributes inherent intransaction)
the bus or protocol being modeled,
and attributes that are artefactsof the simulation model (atimestamp, for example).
A generic payload extension
marked for automatic deletion
will be deleted at the end of theautomatictransaction lifetime, that is,deletionwhen the transaction reference
count reaches 0.

backward path

The calling path by which a target
or interconnect component makes
interface method calls back in the
direction of another interconnect
component or the initiator.

訳語

アダプタ

アプロキシメイトリー・タイムド

アトリビュー
ト

自動削除

バックワー
ド・パス

説明
トランザクション・レベ
ル・インタフェースとピン・レベル・インタフェー
ス間、もしくは、異なる抽象度のトランザクション・
レベル・インタフェース間を接続するモジュール。異なるタイプの 2 つのトラン
ザクション・レベル・イン
タフェースを変換するために用いられる。
外部から観測可能な状態と対応した詳細リファレン
ス・モデルの状態に一対一対応が付き、その対応が状態遷移を保つ（正確なタイ
ミングは保たない）ようなモデリング・スタイル。タ
イミング精度は定義されない。

トランザクションで運ばれる、トランザクション・オ
ブジェクトのメンバーとして実装されるデータ。モデル化された BUS もしくはプロトコルで継承されたアトリビュート、タイムスタン
プ等とシミュレーション・
モデルの成果物も含む。
自動削除のためにマークされた汎用ペイロード拡張はトランザクション・ライフ
タイムの終わり、すなわちトランザクション参照カウ
ントが 0 に達すると、削除される。
ターゲットかインターコネ
クト・コンポーネントが別のインターコネクト・コン
ポーネントかイニシエータの向きにインタフェース・
メソッド・コールバックする際に使用するパス。

- 201 © Copyright 2009 JEITA, All rights reserved

base protocol

bidirectional
interface

blocking

blocking
transportinterfacebridgeA protocol types class consistingof the generic payload andtlm_phase types, together with anassociated set of protocol rules
which together ensure maximal
interoperability
betweentransaction-level models
A TLM 1.0 transaction levelinterface in which a pair oftransaction objects, the request
and the response, are passed in
opposite directions, each being
passed according to the rules of
the unidirectional interface. For
each transaction object, thetransaction
attributes
arestrictly readonly in the period
between the first timing point andthe end of the transaction
lifetime.
Permitted to call the wait method.
A blocking function may consume
simulation time or perform acontext switch, and therefore
shall not be called from a method
process. A blocking interface
defines only blocking functions.

A blocking interface of the TLM-2
standard which contains a single
method b_transport. Beware that
there still exists a blocking
transport method named transport,
part of TLM-1.0.

A module that connects together
twosimilaror
dissimilartransaction-levelinterfaces,
each representing a memory-mappedbus or other protocol, usually at
the same abstraction level. A bus
bridge is a device that connects
two similar or dissimilar buses
together. A communication bridge
is a device that connects network
segments on the data link layer ofa network. See transactor.

基本プロトコル

双方向インタフェース

ブロッキングブロッキン
グ・トランス
ポート・インタフェース

ブリッジ

汎 用 ペ イ ロ ー ド と
tlm_phase タイプからなるプロトコル・タイプのクラスであり、トランザクショ
ン・レベル・モデルの間の最大限度の相互利用性を確実にするため関連セットのプロトコル規則を持つ.
TLM 1.0 のトランザクショ
ン・レベル・インタフェー
ス。トランザクション・オ
ブジェクトのペア、リクエ
ストとレスポンスが、それぞれ反対方向に、単方向インタフェースのルールに従って送信される。各トラン
ザクション・オブジェクトのトランザクション・アト
リビュートはトランザクシ
ョン存続期間中は厳密に読
み出しのみ。
（値を書き換えてはいけない。）
wait 関数を呼び出すことが許されている。ブロッキン
グ関数はシミュレーション
時間を消費する。また、コンテクスト・スイッチする。
したがってメソッド・プロ
セスから呼び出してはいけない。ブロッキング・イン
タフェースはブロッキング
関数のみ定義する。
TLM-2 標準におけるブロッ
キングインフェースであり、ただ一つのメソッド
b_transport か ら な る 。
TLM-1.0 標準の一部である
transport という名のブロッキング・トランスポー
ト・メソッドは依然として存在する事に注意されたい。
2 つのトランザクション・レ
ベル・インタフェース間を接続するモジュール。それ
ぞれはメモリ・マップド・
バスもしくは他のプロトコルを表すもので、通常は同じ抽象度のもの。バス・ブ
リッジは 2 つのバスを接続するデバイス。コミュニケーション・ブリッジはネッ
トワークのデータ・リンク
層のネットワーク・セグメ
ントを接続するデバイス。

- 202 © Copyright 2009 JEITA, All rights reservedcallercalleechannelchild

combinedinterfaces

conveniencesocketIn a function call, the sequenceof statements from which the givenfunction is called. The referentof the term may be a function, aprocess, or a module. This term isused in preference to initiator torefer to the caller of a function
as opposed to the initiator of atransaction.
In a function call, the functionthat is called by the caller. This
term is used in preference totarget to refer to the function
body as opposed to the target ofa transaction.
A class that implements one ormore interfaces or an instance ofsuch a class. A channel may be ahierarchicalchanneloraprimitive channel or, if neitherof these, it is strongly
recommended that a channel atleast be derived from classsc_object. Channels serve toencapsulate the definition of acommunication
mechanismorprotocol. (SystemC term)
An instance that is within a given
module. Module A is a child of
module B if module A is within
module B. (SystemC Term)
Pre-defined groups of coreinterfaces used to parameterize
the socket classes. There are fourcombined interfaces: the blocking
and non-blocking forward andbackward interfaces.

A socket class, derived from
tlm_initiator_socketortlm_target_socket,
that
implements
someadditional
functionality and is provided forconvenience. Several conveniencesockets are provided as utilities

呼び出し元関数

呼び出し先関数

チャネル

子

統合インタフェース

便利ソケットある関数を呼び出している
関数、プロセス、モジュール。この用語は、トランザ
クションのイニシエータとしてではなく、関数の呼び出し元としてイニシエータを指すときによく使われる。
呼び出し元関数から呼び出される関数。この用語は、トランザクションのターゲットとしてではなく、呼び出される関数本体としてターゲットを指すときによく使われる。
1 つ以上のインタフェースを実装したクラス、もしくは、そのクラスのインスタンス。チャネルは階層チャネル、プリミティブ・チャネル、そうでなければ、
sc_object クラスを継承したチャネルが強く推薦される。チャネルはコミュニケーション機構もしくはプロ
トコルをの定義を隠蔽するのに使われる。（SystemC 用語）
あるモジュールの中にインスタンスされたもの。 モジュール B の中にモジュール Aがあるなら、モジュール A
はモジュール B の子である。
ソケットクラスをパラメタライズするためあらかじめ定義されたコア・インタフ
ェースのグループ。次の 4
つの統合インタフェースがある: ブロッキングとノン
ブロッキング、フォワードとバックワード(を統合した)インタフェース。
tlm_initiator_socket か
tlm_target_socket か ら 派
生したソケットクラスであり、何らかの追加機能を実装して、利便性のため提供される。 ユーティリティとして数個の便利ソケットが提供される。

- 203 © Copyright 2009 JEITA, All rights reservedcore interface

cycle accurate

cycle
approximate

One
of
the
[N]
specifictransaction level interfaces
defined in this standard, notderived from any other interface,
and with a template parameter
representing a transaction type,.
Each core interface is aninterface proper. The coreinterfaces are distinct from thegeneric payload API.

A modeling style in which it ispossible to predict the state of
the model in any given cycle at theexternal boundary of the model andthus to establish a one-to-one
correspondence between the statesof the model and the externallyobservablestatesofacorresponding RTL model in eachcycle, but which is not required
to explicitly reevaluate thestate of the entire model in every
cycle or to explicitly represent
the state of every boundary pin orinternal register. This term isonly applicable to models thathave a notion of cycles.
A model for which there exists a
one-to-one mapping between theexternally observable states ofthe model and the states of somecorresponding cycle accurate
model such that the mapping
preserves the sequence of statetransitions but not their precise
timing. The degree of timing
accuracy is undefined. This termis only applicable to models thathave a notion of cycles.

コア・インタフェース

サイクル精度

サイクル近似この標準で定義されるトラ
ンザクション・レベル・イ
ンタフェースで、他のいかなるインタフェースも継承しておらず、トランザクション・タイプをテンプレー
ト・パラメータとして持つ。
コア・インタフェースはインタフェース・プロパである。コア・インタフェース
は汎用ペイロード API とは違う。
モデルの外部境界で、あるサイクルでのモデルの状態の予測ができる、従って、モデルの状態とそれに対応する RTL モデルの外部観測可能な状態との対応付けが毎サイクルできるモデリン
グ・スタイル。ただし、毎サイクルでモデル全体の状態の再評価、全ての外部ピ
ン、内部レジスタの状態を表すことは要求されない。
この用語は、サイクルの概念を持つモデルにのみ使われる。

モデルの外部観測可能な状
態とそのモデルに対応する
サイクル精度モデルの状態
間に 1 対 1 の対応付けが可
能なモデル。その対応付け
は、状態遷移を保持するが、正確なタイミングは保持しない。タイミングの精度は定義されない。この用語は、サイクルの概念を持つモデ
ルにのみ使われる。

- 204 © Copyright 2009 JEITA, All rights reservedcyclecount
accurate, cycle
count accurate
at transaction
boundaries

declaration

definition

extension

A modeling style in which it ispossibletoestablisha
one-to-one
correspondence
between the states of the modeland the externally observablestates of a corresponding RTL
model as sampled at the timing
points marking the boundaries ofa transaction. A cycle countaccurate model is not required tobe cycle accurate in every cycle,
but is required to accurately
predict both the functional state
and the number of cycles atcertain key timing points as
defined by the boundaries of thetransactions through which themodel communicates with othermodels.
A C++ language construct that
introduces a name into a C++
program and specifies how the C++
compiler is to interpret thatname. Not all declarations aredefinitions. For example, a classdeclaration specifies the name of
the class but not the classmembers,whileafunctiondeclaration
specifiesthefunction parameters but not thefunction body. (See definition.)(C++ term)
The complete specification of avariable, function, type, or
template. For example, a classdefinition specifies the classname and the class members, and afunction definition specifies thefunction parameters and thefunction body. (See declaration.)(C++ term)
A user-defined object added to andcarried around with a generic
payload transaction object, or auser-defined class that extends
the set of values that areassignment compatible with thetlm_phase type. An ignorable
extension may be used with thebase protocol, but a mandatory
extension requires the definitionof a new protocol types class.

サイクル数精度、トランザクション境界でのサイクル
数精度

宣言

定義

拡張

モデルの状態とそのモデルに対応する RTL モデルの外部観測可能な状態との間で、トランザクション境界を表すタイミング・ポイン
トで状態をサンプルすることで 1 対 1 の対応付けが可
能なモデリング・スタイル。
サイクル数精度モデルは全てのサイクルでサイクル精度である必要はないが、機能的状態とトランザクショ
ン境界で定義されるキーとなるタイミング・ポイント
でサイクル数が正確に予測されることが求められる。

C++プログラムにある名前を導入し、C++コンパイラがその名前をいかに解釈すべ
きかを指定する C++の構成概念。宣言は定義とは限らない。例えば、クラス宣言
はクラス名を規定するが、クラス・メンバーは規定しない。一方、関数宣言は、関数のパラメータと関数本体を規定する。（C++用語）

変数、関数、型、テンプレ
ートの完全な規定。例えば、クラス定義はクラス名とク
ラス・メンバーを規定する。
関数定義は、関数のパラメータと関数本体を規定する。（C++用語）

汎用ペイロード・トランザ
クション・オブジェクトに付け加えられ、かつ一緒に転送されるユーザ定義オブジ ェ ク ト 、 あ る い は
tlm_phase タイプに代入コ
ンパチブルな値のセットを拡張するユーザ定義クラス。無視可能拡張は基本プ
ロトコルと一緒に使用してもよいが、必須拡張は新しいプロトコル・タイプのクラスの定義を必要とする。

- 205 © Copyright 2009 JEITA, All rights reservedforward pathgeneric payload

global quantum

The calling path by which an
initiatororinterconnect
component makes interface method
calls forward in the direction ofanother interconnect component or
the target.
A specific set of transaction
attributes and their semantics
together defining a transactionlevel protocol which may be usedtoachieveadegreeofinteroperability
betweenuntimed, loosely timed andapproximately timed models forcomponents communicating over amemory-mapped bus. The attributes
are partitioned into those
applicable for all models, and
those
only
applicablefor
approximately timed models
The default time quantum used by
every
quantum
keeperandtemporally decoupled initiator.
The intent is that all temporally
decoupled
initiators
shouldtypically synchronize on integer
multiples of the global quantum,
or more frequently on demand.

フォワード・
パス

汎用ペイロードグローバル・
クォンタム

イニシエータかインターコ
ネクト・コンポーネントが別のインターコネクト・コ
ンポーネントかターゲットの向きにインタフェース・
メソッド・コールする際に使用するパス。
トランザクション・アトリ
ビュートのセットとメモ
リ・マップド・バスを介して通信するコンポーネントのアンタイムド、ルーズリ
ー・タイムド、アプロキシ
メイトリー・タイムド・モデル間のある程度の相互利用を達成するためのセマン
ティクス。アトリビュート
は、全てのモデルに使えるものとアプロキシメイトリ
ー・タイムド・モデルにのみ使えるものとに分けられる。
すべてのクォンタム・キー
パーとテンポラル・デカッ
プリングされたイニシエー
タが使用する、規定のタイ
ム・クォンタム。 意図はすべてのテンポラル・デカッ
プリングされたイニシエー
タが通常はグローバル・ク
ォンタムの整数倍、または、要求に応じてより頻繁に同期を取るべきであるということ。

- 206 © Copyright 2009 JEITA, All rights reservedinitiatorinitiator socketinterconnect
component

A module that can initiate
transactions. The initiator is
responsible for initializing thestate of the transaction object,and for deleting or reusing thetransaction object at the end of
the transaction’s lifetime. An
initiator is usually a master anda master an initiator, but theterm initiator means that acomponent
caninitiatetransactions, whereas the term
master means that a component cantake control of a bus. In the caseof the TLM 1.0 interfaces, theterm initiator as defined here may
not be strictly applicable, so theterms caller and callee may be
used instead for clarity.

A class containing a port forinterface method calls on theforward path and an export forinterface method calls on the
backward path. A socket also
overloads the SystemC binding
operators to bind both port andexportA module that accesses atransaction object, but does act
as an initiator or a target withrespect to that transaction. An
interconnect component may or may
not be permitted to modify theattributes of the transaction
object, depending on the rules ofthe payload. An arbiter or arouter would typically be modeled
as an interconnect component, thealternative being to model it asa target for one transaction andan initiator for a separatetransaction.

イニシエータイニシエー
タ・ソケットインターコネクト・コンポーネント"トランザクションを開始
できるモジュール。イニシ
エータはトランザクションのライフタイムの終わりに、トランザクション・オ
ブジェクトの状態を初期化すること、そして、トランザクション・オブジェクトを削除するか、または再利用する責任がある。イニシ
エータは通常マスタであり、マスタは通常イニシエータである。ただし、イニ
シエータと言う用語はトラ
ンザクションを開始することのできるコンポーネントを意味し、マスタと言う用
語はバスの制御を取ることのできるコンポーネントを意味する。TLM 1.0 インタフ
ェースにおいては、イニシ
エータと言う用語は厳密には適切でないため、代わりに呼び出し元関数、呼び出
し先関数といった用語を使って明確にするのがよい。
"
フォワード・パス上の、インタフェース・メソッド・
コールのためのポートを含むクラス、及び、バックワ
ード・パス上のインタフェース・メソッド・コールのためのエクスポート。 また、このソケットはポートとエクスポートの両方をバインドするために SystemCのバインド演算子をオーバーロードする。
トランザクション・オブジ
ェクトにアクセスするが、そのトランザクションに関してイニシエータあるいはターゲットとして作用するモジュール。ペイロードのルールに従って、インターコネクト・コンポーネント
がトランザクション・オブ
ジェクトのアトリビュートを変更することを許可または禁止される。

- 207 © Copyright 2009 JEITA, All rights reservedinterface

Interface Method
Call (IMC)interface properinteroperabilityA class derived from classsc_interface. An interface properis an interface, and in theobject-oriented sense a channel
is also an interface. However, achannel is not an interface
proper. (SystemC term)
A call to an interface method. Aninterface method is a member
function declared within aninterface. The IMC paradigm
provides a level of indirection
between a method call and theimplementation of the method
within a channel such that one
channel can be substituted withanother without affecting thecaller. (SystemC term)
An abstract class derived fromclass sc_interface but notderived from class sc_object. An
interface proper declares the setof methods to be implemented
within a channel and to be called
through a port. An interface
proper contains pure virtualfunctiondeclarations,buttypically contains no function
definitions and no data members.
(SystemC term)
The ability of two or moretransaction level models fromdiverse sources to exchange
information using the interfaces
defined in this standard. The
intent is that models that
implement common memory-mappedbus protocols in the programmers
view
use
case
shouldbeinteroperable without the needforexplicit
adaptors.
Furthermore, the intent is to
reduce the amount of engineering
effortneededtoachieveinteroperability for models ofdivergent protocols or use cases,
although it is expected that
adaptors will be required ingeneral.

インタフェース

インタフェー
ス・メソッ
ド・コール

インタフェー
ス・プロパ

相互利用性

sc_interface を継承したクラス。インタフェース・プ
ロパはインタフェース。オ
ブジェクト指向の意味では、チャネルもインタフェース。ただし、チャネルはインタフェース・プロパではない。（SystemC 用語）
インタフェース・メソッドの呼び出し。インタフェー
ス・メソッドとはインタフ
ェース内で宣言されたメンバー関数。IMC の枠組みは、
メソッド呼び出しとメソッ
ドの実装の分離を提供する。例えば、呼び出し元に影響を与えることなく、チャネルの置き換えが可能となる。
（SystemC 用語）
sc_interface を継承した抽
象 ク ラ ス （ た だ し 、
sc_object は継承しない）。
インタフェース・プロパはチャネル内で実装されるメ
ソッドを宣言し、それらはポートを介して呼び出される。インタフェース・プロ
パは純粋バーチャル関数の宣言を持つが、通常は、関数定義、データ・メンバは持たない。（SystemC 用語）
この標準で定義するインタ
フェースを使うことにより、異なった出所のトランザクション・レベル・モデ
ルで情報を交換できるようになること。この意味は、
PV ユースケースで共通メモ
リ・マップド・バスプロト
コルを実装したモデルアダ
プター無しで相互利用できるはずだということ。さらに、異なったプロトコル、
ユースケースのモデルについても、一般にはアダプタが要求されるが、相互利用のための手間を削減を意味する。

- 208 © Copyright 2009 JEITA, All rights reserved

lifetime (of an
object)lifetime (of atransaction)

local quantum

The lifetime of an object starts
when storage is allocated and theconstructor call has completed,
if any. The lifetime of an object
ends when storage is released or
immediately before the destructor
is called, if any. (C++ term)

The period of time that starts
when the transaction becomes
valid
and
ends
when
the
transaction becomes invalid.
Because it is possible to pool or
re-use transaction objects, thelifetime of a transaction object
may be longer than the lifetime of
the corresponding transaction.
For example, a transaction object
could be a stack variable passed
as an argument to multiple put
calls of the TLM1.0 interface.

The amount of simulation timeremaining before the initiator isrequiredtosynchronize.
Typically, the local quantum
equals the current simulation
time subtracted from the next
largest integer multiple of the
globalquantum,but
thiscalculation can be overridden fora given quantum keeper.

（オブジェクトの）ライフタイム（トランザクションの）ライフタイム

ローカル・クォンタム

オブジェクトのライフタイ
ムは、ストレージがある場
合アロケートされ、コンス
トラクタ呼び出しが完了した時に開始され、そしてス
トレージがリリースされた
時、もしくはデストラクタ
が呼び出される直前に終了する。
（C++用語）
トランザクションが有効になった時に始まり、無効になるまでの時間の周期を指す。トランザクション・オ
ブジェクトはプールまたは再利用される可能性がある
為、そのトランザクショ
ン・オブジェクトのライフ
タイムは、対応するトランザクション自身のライフタ
イムより長い場合がある。
例えば、トランザクショ
ン・オブジェクトは、TLM1.0
インタフェースの呼び出し時のように、複数の引数スタックされる事もある。
イニシエータが同期を要求される前に残っているシミュレーション時間の量。通常、ローカル・クォンタム
はグローバル・クォンタムの次の最も大きい整数倍から現在のシミュレーション
時刻を差し引いたものと等
しいが、クォンタム・キー
パーを与えることで、この計算をオーバーライドすることができる。

- 209 © Copyright 2009 JEITA, All rights reservedloosely timed

mastermethodA modeling style that represents
minimaltiminginformation
sufficient only to support
features necessary to boot an
operating system and to manage
multiple threads in the absence of
explicit synchronization between
those threads. A loosely timed
model may include timer models anda notional arbitration intervalor execution slot length. Some
users adopt the practice ofinserting random delays intoloosely timed descriptions inorder to test the robustness of
theirprotocols,but
thispractice does not change the basic
characteristics of the modelingstyle.
This term has no precise technicaldefinition in this standard, but
is used to mean a module or portthat can take control of amemory-mapped bus in order toinitiate bus traffic, or acomponent that can execute anautonomous software thread andthus initiate other system
activity. Generally, a bus masterwould be an initiator.

A function that implements the
behavior of a class. This term issynonymous with the C++ term
member function. In SystemC, theterm method is used in the context
of an interface method call.
Throughout this standard, theterm member function is used whendefiningC++classes(forconformance to the C++ standard),
and the term method is used in more
informal contexts and when
discussing
interfacemethodcalls. (SystemC term)

ルーズリー・
タイムド

マスタ

メソッド

オペレーティング・システ
ムのブートと、複数スレッ
ド間の明示的な同期管理に必要とされる機能をサポートする為に、最適で十分な最小タイミング情報を与えたモデリング・スタイル。
ルーズリー・タイムド・モ
デルには、タイマー・モジ
ュール、または調停間隔や実行スロット長が含まれる
場合がある。ユーザによっては、それらプロトコルの頑健性をテストするにあたり、ルーズリー・タイムドの記述にランダム遅延を入れる場合があるが、しかしこれによってモデリング・
スタイルの基本的な性質を変える事はない。
この用語には明確な標準の技術定義は無いが、バス・トラフィックを開始する為にメモリ・マップド・バス
制御を行う事の出来るモジュール、またはポート、また自律的なソフトウェア・
スレッドを実行する事が出来るものや、その他システ
ムを起動するコンポーネン
トを指す。一般的には、バス・マスタはイニシエータになりうる。
クラスの動作を実装した関数。この用語は C++用語のメンバー関数と同じ事を表している。SystemC でメソッドとは、インタフェース・メ
ソッド呼び出しの文脈の中で用いられる。一般的にメンバー関数は C++クラス定義（C++標準に準拠した）される時に使用され、メソッ
ドはより略式的な文脈か、またはインタフェース・メ
ソッド呼び出しを論じている 時 に 使 用 さ れ る 。
（SystemC 用語）- 210 © Copyright 2009 JEITA, All rights reservedmulti-socket

nb_transport

non-blocking

non-blocking
transportinterface

objectOne of a family of conveniencesockets that can be bound tomultiple sockets belonging toothercomponents.
A
multi-initiator socket can bebound to more than one target
socket, and more than one
initiator socket can be bound toa single multi-target socket.
When calling interface methods
throughmultisockets,thedestinations are distinguishedusing the subscript operator.

Thenb_transport_fw
and
nb_transport_bw methods. In thisdocument, the italicised term
nb_transport is used to describe
both methods in situations where
there is no need to distinguishbetween them.
Not permitted to call the wait
method. A non-blocking function
is guaranteed to return without
consuming simulation time or
performing a context switch, andtherefore may be called from athread process or from a method
process. A non-blocking interface
defines
only
non-blocking
functions.

A non-blocking interface of the
TLM-2 standard. There a two suchinterfaces, containing methods
named
nb_transport_fw
and
nb_transport_bw.

A region of storage. Every object
has a type and a lifetime. An
object created by a definition has
a name, whereas an object createdby a new expression is anonymous.
(C++ term)

マルチソケット

nb_transport

ノンブロッキング

ノンブロッキング・トラン
スポート・インタフェース

オブジェクト他のコンポーネントに属す
る複数のソケットにバインドすることができる便利ソ
ケットのひとつ。マルチイ
ニシエータ・ソケットに複数のターゲット・ソケットをバインドすることができ、また、単一のマルチ・ターゲット・ソケットに複数のイニシエータ・ソケッ
トをバインドすることができる。マルチソケットを通してインタフェース・メソ
ッド・コールをする際、ディスティネーションは、添字演算子を使用して識別される。
nb_transport_fwと
nb_transport_bw メソッド。
本書では、nb_transport というイタリック体で示した
用語は、それらを区別する必要がない状況にいて両方のメソッドを指すのに使用されている。
wait の呼び出しが許されない。ノンブロッキング関数
はシミュレーション時間の消費、コンテクスト・スイ
ッチ無しでリターンすることが保証されている。そのため、ノンブロッキング関
数はスレッド・プロセスもしくはメソッド・プロセス
から呼び出される。ノンブ
ロッキング・インタフェー
スはノンブロッキング関数
のみ定義する。
TLM-2 標準におけるノンブ
ロッキング・インタフェー
ス 。 nb_transport_fw と
nb_transport_bw と 命 名 されたメソッドを含んだ、2 種類のインタフェースがある。
ストレージの領域。あらゆるオブジェクトは型とライ
フタイムを持つ。定義によって作成されたオブジェク
トは名前を持つが、new 構文
によって作成されたオブジ
ェクトは匿名である。（C++用語）- 211 © Copyright 2009 JEITA, All rights reserved

parent

payloadevent
queue (PEQ)

The period in the lifetime of atransaction occurring between
successive timing points.

phase

programmers view(PV)protocolclass

The inverse relationship tochild. Module A is the parent ofmodule B if module B is a child of
module A. (SystemC term)
A class that maintains a queue ofSystemC event notifications,where each notification carries
an associated transaction object.
Transactions are put into thequeue annotated with a delay, andeach transaction pops out of theback of queue at the time it was
put in plus the given delay.
Usefulwhen
combiningthenon-blocking interface with theapproximately-timed
codingstyle.

types

quantumquantum keeper

The use case of the software
programmer
who
requiresafunctionally accurate, loosely
timed model of the hardware
platform for booting an operating
system and running application
software.
A class containing a typedef for
the type of the transaction object
and the phase type, which is used
to parameterize the combinedinterfaces,andeffectively
defines a unique type for a
protocol.

In temporal decoupling, theamount a process is permitted torun ahead of the current
simulation time.
A utility class used to store thelocal time offset from the current
simulation time, which it checks
against a local quantum.

親ペイロード・
イベント・キュー

フェーズ

プログラマーズ・ビュー（PV)プロトコル・
タイプ・クラス

クォンタム

クォンタム・
キーパー

子とは逆の関係。もしモジュール A がモジュール B の親であるならば、B は A の子である。(SystemC 用語)
SystemC イベント通知のキ
ューを保持するクラスであり、各通知が関連トランザ
クション・オブジェクトを運ぶ。トランザクションは
遅延時間をアノテートしてキューに積まれる。そして、各トランザクションはそれらが積まれた時刻＋与えられた遅延時間後にキューの後ろから出てくる。アプロ
キシメイトリー・タイム
ド・コーディング・スタイ
ルとノンブロッキング・イ
ンタフェースを組み合わせ
ると、便利である。
継続的なタイミング・ポイ
ント間で発生しているトラ
ンザクションが有効な期間を指す。
機能要求に忠実なソフトウェア・プログラマ向けの使用法であり、オペレーティ
ング・システムのブートとアプリケーション・ソフト
ウェアの実行を実施するハードウェアのルーズリー・
タイムド・モデルを指す。
トランザクション・オブジ
ェクトとフェーズのタイプのための typedef を含むクラスであり、統合したインタフェースをパラメタライ
ズするのに使用され、また、
プロトコルのためにユニー
クなタイプを効率良く定義することができる。
テンポラル・デカップリン
グにおいて、現在のシミュ
レーション時刻よりさらに進めることが許されている処理の量。
現在のシミュレーション時
刻からのローカル時間へのオフセットを保持するためのユーティリティ・クラス
であり、ローカル・クォン
タムに対してチェックされる。

- 212 © Copyright 2009 JEITA, All rights reservedreturn path

simple socket

slave

socket

The control path by which the callstack of a set of interface method
calls is unwound along either theforward path or the backward path.
The return path for the forward
path can carry information fromtarget to initiator, and thereturn path for the backward pathcan carry information frominitiator to target.

One of a family of conveniencesockets that are simple to use
because they allows callback
methods to be registered directlywith the socket object rather than
the socket having to be bound toanother object that implements
the required interfaces. The
simple target socket avoids theneed for a target to implement
both blocking and non-blocking
transport interfaces by providing
automatic conversion between thetwo.

This term has no precise technicaldefinition in this standard, but
is used to mean a reactive module
or port on a memory-mapped busthat is able to respond tocommands from bus masters, but is
not able itself to initiate bus
traffic. Generally, a slave would
be modeled as an OSCI target.

See initiator socket and target
socket

リターン・パス

シンプル・ソ
ケット

スレーブ

ソケット

一組のインタフェース・メ
ソッド・コールのスタックが呼ぶコントロールパスであり、フォワード・パスか
バックワード・パスのどち
らかに沿って巻き戻される。フォワード・パスへのリターン・パスはターゲットからイニシエータまで情報を運ぶことができ、そして、バックワード・パスへのリターン・パスはイニシエータからターゲットまで情報を運ぶことができる。
直接制限されなければならないソケットよりむしろ必要なインタフェースを実装する別のオブジェクトへのソケット・オブジェクトに登録されるべきコールバッ
ク・メソッドを許容するので使用するのが簡単な便利
ソケットのひとつ。シンプ
ル・ターゲット・ソケット
は、自動変換を 2 つの間に提供することによってブロッキングとノンブロッキン
グの両方のトランスポー
ト・インタフェースをター
ゲットに実装する必要性を排除する。
この用語は、この標準の中では明確な技術的定義を持たないが、バス・マスタからのコマンドに応答する事が出来る反応的なメモリ・
マップド・バス上のモジュールまたはポートを意味する際に用いられる。しかしそれ自身は、バス・トラフ
ィックを起こす事が出来ない。一般的にスレーブは、
OSCI ターゲットのようにモデルされる。
イニシエータ・ソケットとターゲット・ソケットを参照のこと。

- 213 © Copyright 2009 JEITA, All rights reservedstandard
response

error

sticky extension

synchronize

synchronization-on-demandtagged socket

The behavior prescribed by thisstandard for a generic payload
target that is unable to executea transaction successfully. A
target should either a) executethe transaction successfully orb) set the response status
attribute to an error response orc) call the SystemC report
handler.

A generic payload extension
object
that
will
not
be
automatically deleted when thereference
count
of
the
transaction object reaches 0.
Sticky extensions are not deleted
by the memory manager.
To yield such that other processes
may run, or when using temporaldecoupling, to yield and wait
until the end of the current timequantum.
Anindication
fromthenb_transport method back to its
caller that it was unwilling or
unable to fulfill a request toeffectively execute a transaction
at a future time (temporaldecoupling), and therefore thatthe caller must yield control backto the SystemC scheduler so thatsimulation time may advance andother processes run.

One of a family of conveniencesockets that add an int id tag toevery incoming interface method
call in order to identify thesocket(orelementofamulti-socket) through which thetransaction arrived.

標準エラー応答

スティッキー拡張同期

オンデマンド同期

タグ付きソケット

汎用ペイロードのターゲッ
トがトランザクションをうまく完了できない時の、この標準において定義された動作。ターゲットは、次のいずれかを行う。a) トラン
ザクションを完了させる。
b) レスポンス・ステータ
ス・アトリビュートに、エラーレスポンスをセットする。c) SystemC のリポート
ハンドラをコールする。
トランザクション・オブジ
ェクトの参照カウントが 0に達しても自動的に削除されない汎用ペイロードの拡
張オブジェクト。 スティッ
キー拡張はメモリ・マネー
ジャによって削除されない。
他のプロセスが走るのを待つ。あるいは、テンポラル・
デカップリングを使用する
際、または現在のタイム・クォンタムの終わりまで待つ。
意図していないか、あるいは将来の時刻(すなわちテンポラル・デカップリング)にトランザクションを効果的に実行するという要求を実現させることができな
い 、 と い う 内 容 の
nb_transport メソッドから
呼び出し元への表示。従って、関数呼び出し元がSystemC スケジューラにコントロールを譲り返さなけ
ればならないので、シミュレーション時刻は進むし、他のプロセスは走る。
トランザクションが到着したソケット(または、マルチソケットの要素)を特定するためにあらゆる入って来るインタフェース・メソッ
ド・コールに int id tag を加える便利ソケットのひとつ。

- 214 © Copyright 2009 JEITA, All rights reserved

targettarget socket

temporaldecoupling

timing point

A module that represents the finaldestination of a transaction,
able to respond to transactions
generated by an initiator, but notitself initiate new transactions.
For a write operation, data is
copied from the initiator to one
or more targets. For a read
operation, data is copied from one
target to the initiator. A target
may read or modify the state of thetransaction object. In the case of
the TLM 1.0 interfaces, the term
target as defined here may not bestrictly applicable, so the terms
caller and callee may be usedinstead for clarity.

A class containing a port forinterface method calls on the
backward path and an export forinterface method calls on theforward path. A socket also
overloads the SystemC binding
operators to bind both port andexport.

The ability to allow one or moremasters to run ahead of thecurrent simulation time in orderto reduce context switching andthus increase simulation speed.
A point in time at which theprocesses that are interacting
through a transaction eithertransfer
controloraresynchronized. Certain timing
pointsare
implemented
asfunction calls or returns, others
as event notifications. Timing
points mark the boundaries
betweenthephasesofatransaction.

ターゲット

ターゲット・
ソケット

テンポラル・
デカップリング

タイミング・
ポイント

トランザクションの最終的な到達先を表すモジュール
で、イニシエータによって生成されるトランザクショ
ンに応答する事が出来る。
しかしそれ自身は新しいト
ランザクションを開始する
事は出来ない。書き込み操作においては、データがイ
ニシエータから 1 個以上のターゲットまでコピーされる。読み出し操作においては、データはあるターゲッ
トからイニシエータまでコピーされる。 ターゲット
は、トランザクション・オ
ブジェクトの状態を読む事
や、変更する事が可能である。TLM 1.0 インタフェース
においては、ターゲットと言う用語は厳密には適切でないため、代わりに呼び出
し元関数、呼び出し先関数といった用語を使って明確にするのがよい。
バックワード・パス上の、
インタフェース・メソッ
ド・コールのためのポートを含むクラス、及び、フォ
ワード・パス上のインタフェース・メソッド・コールのためのエクスポート。 また、このソケットはポートとエクスポートの両方をバインドするために SystemCのバインド演算子をオーバーロードする。
コンテクスト・スイッチを抑えてシミュレーション速
度を向上させる目的で、シミュレーション時間を進めるマスタを一つ以上許容する機能を指す。
トランザクションを通じて相互に影響しているプロセスにおける、転送制御や同期される時点のタイミングを指す。一定のタイミン
グ・ポイントは、関数の呼び出しや関数からの復帰のように実装され、外部にイ
ベントを通達する。タイミ
ング･ポイントはトランザ
クションのフェーズ間のを範囲を示す。

- 215 © Copyright 2009 JEITA, All rights reserved

TLM-1

TLM-2

transaction

transaction
objecttransactionlevel (TL)transaction
level
model,
transactionlevel modeling(TLM)

The first major version of the
OSCI Transaction Level Modelingstandard. TLM-1.0 was released in
2005.
The second major version of the
OSCI Transaction Level Modelingstandard. This document describes
TLM-2.0.
An abstraction for an interaction
or communication between two or
more concurrent processes. A
transaction carries a set of
attributes and is bounded in time,
meaning that the attributes are
only valid within a specific time
window. The timing associatedwith the transaction is limited toa specific set of timing points,
depending on the type of thetransaction. Processes may bepermitted to read, write, or makethemselves
sensitive
toattributes of the transaction. A
transaction may be an atomic
transactionoracomplextransaction.
"The object that stores theattributes associated with an
OSCI transaction. The type of thetransaction object is passed as atemplate argument to the coreinterfaces."
The abstraction level at which
communication between concurrent
processes is abstracted away frompin wiggling to transactions.
This term does not imply any
particular level of granularity
with respect to the abstraction oftime, structure, or behavior.
A model at the transaction level
and the act of creating such amodel, respectively. Transaction
level
modelstypically
communicate using function calls,
as opposed to the style of setting
events on individual pins or nets
as used by RTL models.

TLM-1

TLM-2

トランザクション

トランザクション・オブジェクト

トランザクション・レベル（TL）

トランザクション・レベ
ル・モデル、
トランザクション・レベ
ル・モデリング（TLM）OSCI Ｔ Ｌ Ｍ標 準 の 最 初のメジャーバージョン。TLM
1.0 は 2005 年にリリースされた。
OSCI Ｔ Ｌ Ｍ標 準 の ２ つ目のメジャーバージョン。本ドキュメントは TLM 2.0 について記載している。
二つ以上の並列プロセスにおける、相互作用や通信を行う為の抽象化。トランザ
クションは時間範囲とアトリビュートのセットを伝える。アトリビュートは、特定の時間範囲内で有効である事を意味する。トランザ
クションにおける時間調整
は、トランザクションの型に依存した特定のタイミン
グ・ポイントのセットに限定される。

トランザクションに含まれるアトリビュートを保持するオブジェクト。

並列プロセス間通信で、ピンレベルの信号動作からトランザクションとして抽出される際の抽象度。この用語には、時間、構造、動作の抽象化についての詳細な粒度は含まない。
トランザクション・レベル
によるモデルと、そのようなモデルを作成する行動を表す。トランザクション・
レベル・モデルは一般的に、RTL モデルによって使用されるような各ピンやネット上にイベントを設定するようなスタイルとは異なり、
関数呼び出しを使用して通信を行う。

- 216 © Copyright 2009 JEITA, All rights reservedtransactor

transportinterfaceA module that connects atransaction level interface to apin level interface (in thegeneral sense of the wordinterface) or that connects
together two or more transactionlevel interfaces, often at
different abstraction levels. In
the typical case, the firsttransaction
levelinterface
represents a memory mapped bus orother protocol, the second
interface
represents
theimplementation of that protocol
at a lower abstraction level.
However, a single transactor may
have multiple transaction levelor pin level interfaces. See
adaptor, bridge.

The one and only bidirectionalcore interface in TLM-1. The
transport interface passes arequest transaction object fromcaller to callee, and returns a
response transaction object fromcallee to caller. TLM-2 adds
separate
blocking
andnon-blocking
transportinterfaces.

トランザクタトランスポー
ト・インタフェース

トランザクション・レベ
ル・インタフェースからピン・レベル・インタフェー
ス（一般的なワード・イン
タフェースの意味）への接
続や、二つ以上のトランザ
クション・レベル・インタ
フェースの集合による接続がなされるような、異なる抽象度を扱う際に頻繁に使用されるモジュール。一般
的には、初めのトランザク
ション・レベル・インタフ
ェースはメモリ・マップ
ド・バスやその他プロトコ
ルを表し、次のレベルのイ
ンタフェースは、低抽象度のプロトコルの実装を表す
が、一つのトランザクタには、複数のトランザクショ
ン・レベルや、ピン・レベ
ル・インタフェースを持つ可能性がある。アダプタ・
ブリッジを参照。
"TLM-1 標準では一つしかな
い双方向のコア・インタフ
ェース。トランスポート・
インタフェースは呼び出し元関数から呼び出し先関数
へリクエスト・トランザク
ション・オブジェクトを送り、呼び出し先関数から呼び出し元関数へリクエス
ト・トランザクション・オ
ブジェクトを返す。
TLM-2 標準ではさらにブロッキング・トランスポー
ト・インタフェースとノン
ブロッキング・トランスポート・インタフェースの２つに分割される。"- 217 © Copyright 2009 JEITA, All rights reservedunidirectional
interface

untimedA TLM 1.0 transaction levelinterface in which the attributesof the transaction object arestrictly readonly in the period
between the first timing point andthe end of the transaction
lifetime.
Effectively,theinformation represented by thetransaction object is strictly
passed in one direction either
from caller to callee or fromcallee to caller. In the case ofvoid put(const T& t), the firsttiming point is marked by thefunction call. In the case of voidget(T& t), the first timing point
is marked by the return from thefunction. In the case of T get(),strictly speaking there are two
separate transaction objects, andthe return from the function marks
the degenerate end-of-life of thefirst object and the first timing
point of the second.

A modeling style in which there is
no explicit mention of time orcycles, but which includes
concurrency and sequencing ofoperations. In the absence of any
explicit notion of time as such,the sequencing of operations
acrossmultipleconcurrent
threads must be accomplishedusing synchronization primitives
such as events, mutexes andblocking FIFOs. Some users adopt
the practice of inserting random
delays into untimed descriptions
in order to test the robustness of
theirprotocols,but
thispractice does not change the basic
characteristics of the modelingstyle.

単方向インタフェース

アンタイムドトランザクションのアトリ
ビュートがトランザクショ
ン・ライフタイムの最初のタイミング・ポイントから最後までの期間で厳密に読み出しのみに限定された
TLM1.0 の ト ラ ン ザ ク シ ョン・レベル・インタフェー
ス。トランザクション・オ
ブジェクトで表される情報
は、呼び出し元関数から呼び出し先関数、または呼び出し先関数から呼び出し元
関 数 へ 送 ら れ る 。 voidput(const T&t)の場合では、最初のタイミング・ポイン
トは関数呼び出しによって表される。T valid get(T& t)の場合では、この関数からのリターンによって表される。T get()の場合、厳密に言うと二つのトランザクション・オブジェクトが関わっている。この関数からのリターンは 1 つ目のトラン
ザクション・オブジェクトの終わりと 2 つ目のトラン
ザクション・オブジェクトの最初のタイミング・ポイ
ントを表す。
時間やサイクルを明示的に言及しないモデリング・ス
タイル。しかしオペレーシ
ョンの並列性や順序は含まれる。時間概念は無いが、複数並列スレッド間のオペ
レーションの順序性は、イ
ベント、ミューテックス、
ブロッキング FIFO 等の同期
プリミティブを使って、複数並列スレッド間のオペレーションの順序性を実現しなければならない。ユーザ
によっては、プロトコルの頑健性をテストするため、アンタイムドな記述にランダム遅延を入れる場合があるが、この方法によってモデリング・スタイルの基本的な性質が変わることはない。

- 218 © Copyright 2009 JEITA, All rights reserved

validwithinyield

The state of [...] an object
returned from a function by
pointer or by reference, during
any period in which the [...]
object is not deleted and its
valueor
behavior
remains
accessible to the application.
[...] (SystemC term)
The relationship that exists
between an instance and a module
if the constructor of the instanceis called from the constructor of
the module, and also provided thatthe instance is not within anested module. (SystemC term)

Return control to the SystemC
scheduler. For a thread process,to yield is to call wait. For amethod process, to yield is toreturn from the function.

バリッド

包含

（制御を）譲渡する

ポインタまたは参照で関数からリターンされるオブジ
ェクトの状態で、そのオブジェクトが削除されておらず、その値や動作をアプリ
ケーションからアクセスが可能な状態である期間。
（SystemC 用語）
インスタンスのコンストラ
クタがモジュールのコンス
トラクタから呼ばれる場合にインスタンスとモジュールの間に存在する関係。あるいは、入れ子にされたモジュールの中にインスタン
スがなければ、提供される。
（SystemC 用語）
SystemC スケジューラにコントロールを返すこと。ス
レッド・プロセスにおいて、
yield は、call wait である。
メソッド・プロセスにおいては、yield は、関数から戻ることである。

- 219 © Copyright 2009 JEITA, All rights reserved

4.2.3 TLM 2.0 補足解説
4.2.3.1 TLM-2.0 Draft から正式版への変更点
本節は、OSCI の TLM2 USER MANUAL Software version: TLM-2.0、Document version: JA22 における TLM2 USER MANUAL Software version: TLM 2.0 Draft 2、Document version: 1.0.0 からの変更点を解説したものである。
3. イントロダクション• セクション 3.3.3 が変更。
Draft2: Untimed versus loosely-timed modeling ⇒loosely-timed models• セクション追加。
3.6 Combined interfaces and sockets

正 式 版 : Synchronization in

4. TLM-2 コア・インタフェース• ノン･ブロッキング・トランスポート・インタフェースの用途
Draft2: アプロキシメイトリー・タイムドとルーズリー・タイムドの両方
正式版: アプロキシメイトリー・タイムド向け。ルーズリー・タイムドのモデリングには推奨されない。
• ブロッキングでタイミング・アノテーションがサポートされ、ノンブロッキングをルーズ
リー・タイムドで使用する必要がなくなった為。
• tlm_phase の変更
Draft2: enum tlm_phase {BEGIN_REQ, END_REQ, BEGIN_RESP, END_RESP };正式版: enum tlm_phase_enum と class tlm_phase• ユーザによってフェーズ拡張が可能なように、tlm_phase がクラスに、元の tlm_phase が
tlm_phase_enum として変更されている。
• tlm_sync_enum の変更
Draft2: enum tlm_sync_enum { TLM_REJECTED = 0, TLM_ACCEPTED = 1, TLM_UPDATED = 2,
TLM_COMPLETED = 3 };正式版: enum tlm_sync_enum { TLM_ACCEPTED, TLM_UPDATED, TLM_COMPLETED };• リジェクトは TLM2.0 の範疇でないと判断された。LRM リリース時に再度理由を確認する。
• nb_transport メソッドの変更
Draft2: nb_transport メソッド
正式版: nb_transport_fw、nb_transport_bw• フォワードパス、バックワードパスで呼ばれるメソッドが見た目で分かり辛い為に名前が変更された。
• メッセージ・シーケンス・チャートに２つの図が追加された。
トランザクションの早期終了
タイミング・アノテーション• sc_time 引数の説明が詳細になった。
• DMI/Debug ともにトランザクションとして汎用ペイロード(tlm_generic_payload)がデフォルトが採用され，DMI は拡張機構で実現された。
• トランザクション形式を一般の形に統一。
• transport が b_transport に変更された。
• debug transaction interface から debug transport interface に名称変更された。
• DMI 関連のクラス定義が変更・削除された。
• get_direct_mem_ptr メソッドの引数が大きく変更され，adress の代わりに
tlm_generic_payload が追加され，tlm_dmi_mode クラスが tlm_dmi クラスに統合された• メソッドの説明文が追加。
• 特に tlm_dmi クラスについての説明項目が 12 個も追加（16 個→28 個）• tlm_transport_dbg_if クラス定義が変更された。
• 注釈“helper function 開発中”が削除。
- 220 -

5. 結合インタフェースとソケット• クラスの継承関係が大幅に変更。
• I/F クラスのグルーピングの仕方が変更。
• blocking 用ソケットと non-blocking 用ソケットを 1 つにマージ。
• ソケットの複数接続が可能になった(従来は 1 対 1)。
TLM2.0
コアインタフェース

Draft2

正式版

tlm_nonblocking_transport_if

tlm_fw_nonblocking_transport_if tlm_bw_nonblocking_transport_if

tlm_blocking_transport_if
tlm_fw_direct_mem_if

tlm_blocking_transport_if

tlm_bw_direct_mem_if

tlm_transport_dbg_if

tlm_fw_direct_mem_if

tlm_bw_direct_mem_if

tlm_transport_dbg_if

グループ化
tlm_fw_b_transport_if

tlm_bw_b_transport_if

tlm_fw_transport_if

tlm_bw_transport_if

tlm_bw_nb_transport_if

tlm_fw_nb_transport_if
ソケット

port/export/IFオブジェクトを取得するメソッドを定義

sc_porttlm_initiator_socket
tlm_nb_initiator_socket

ポートバインド用
メソッドの定義

typedef tlm_generic_payload tlm_payload_type;typedef tlm_phase tlm_phase_type;typedef tlm_dmi_mode(tlm_base_protocol_typesでは削除)

tlm_base_initiator_socket_b

ポートバインド用
メソッドを定義

tlm_b_initiator_socket

テンプレートパラメタ：
unsigned int BUSWIDTH = 32,
typename TYPES = tlm_generic_payload_types

tlm_base_target_socket_b
sc_porttlm_base_initiator_socket
tlm_initiator_socket

テンプレートパラメタ：
unsigned int BUSWIDTH = 32,
typename TYPES = tlm_base_protocol_types,
int N = 1,
sc_core::sc_port_policy POL = sc_core::SC_ONE_OR_MORE_BOUND

イニシエータのクラスの継承関係
6. 汎用ペイロード• 6.10 Data pointer attribute: 全体として、言語マニュアル的表現からユーザーマニュアル表
現になり、使い方の説明が加わり分かりやすくなった• 6.11 Data length attribute: データ長はトランザクション･オブジェクトがインタフェースメ
ソッドコールで渡される前に明示的に指定されるべきなので、デフォルト値が 1 から 0 に変更された。
• 6.12 Byte enable pointer attribute: Byte Enable pointer の値を、イネーブル/ディスエー
ブルのマスクとして使えるように値を決めた。
• 6.13 Byte enable length attribute: デフォルト値が、１から０(null)に変更された• 6.14 Streaming width attribute:• ストリーミングの扱いについての説明が追加された。
• 0 は通常のデータ転送として扱われるとなっていたのが、無効に変更された。
• 6.16 Response status attribute: response status attribute の扱い方の具体的な解説が追加された• 6.20 汎用ペイロードの拡張:• 9.19 Extension mechanism → 6.20 Generic payload extension• 6.21 Instance-specific extensions の章が追加された。
• 安全使用のガイドラインと規則が規則に１本化された。
• tlm_extension_base クラスに copy_from 純粋仮想関数と free 仮想関数が追加された。デストラクタが public から protected に変更された。
8. その他のクラス• 8.1 グローバル・クォンタムとクォンタム・キーパー: 機能自体に変更はないが、クラス・API
体系に若干の変更あり— クラス・ルールの変更• Draft2 では tlm_quantumkeeper クラスだけであったが、グローバル・クォンタムに関連する機能だけ、tlm_global_quantum クラスとして切り出された。
- 221 -

• Draft2 では 29 個のルール、正式版では 34 個のルールがある。大部分のルールは共通で変更点は瑣末。
— 仕様の変更• nb_transport 関数(AT コーディングスタイル)でのテンポラル・デカップリングやクォンタ
ム・キーパーの使用はルールの対象外と明記された。
• 8.2 ペイロード・イベント・キュー: 機能自体に大きな変更はないが、クラス・API 体系に若干の修正あり— クラス・API の変更• Draft2 では tlm_peq クラスだけであったが、正式版では peq_with_get クラス、
peq_with_cb_and_phase クラスの２つがある。
— 仕様の変更• PEQ へのトランザクションの格納・取り出し API が変更になった。
tlm_peq::delayed_write_export → peq_with_get::notify
tlm_peq::write_port → peq_with_get::get_next_transaction• peq_with_cb_and_phase クラスを使用する場合は、トランザクションが取り出し可能になった際、自動的に呼ばれるコールバック・メソッドの登録が可能。
またフェーズ情報をセットにした格納が可能になった。
4.2.3.2 TLM2.0 拡張方法
TLM2.0 では、MMB(メモリ・マップド・バス)をモデリングするための基本的なプロトコルが定義されています。しかしながら、TLM2.0 では、どのバスにでもあるような必要最小限のデータ構造(Generic Payload)と、必要最小限の通信手段(Base Protocol)が定義されているにすぎず、実際の何らかのバスを厳密に定義しようとすると、いくつかの拡張をする必要があります。
TLM2.0 の中心部分の定義は、どんなバスにでも適用可能な、全ての機能を盛り込んだ汎用的なものというよりは、どのようなバスにでもある共通的なもののみのサポートになっているわけです。
このように TLM2.0 を汎用的なものではなく、共通的なものに絞りこんだ理由としては、SystemC
TLM メソドロジをサポートした IP の普及のために必要な相互利用性の確保を最大の目標にしていることがあげられます。
特に、ソフトウエア/ハードウエア協調設計環境の構築においては、バスの詳細定義よりも、接続の容易さが必要になりますので、TLM2.0 は、タイミング精度、個別のバスによって異なる仕様を詳細に定義するというよりは、高速性と一般化による汎用性を重視していると言えます。
とはいっても、世の中にあるバスモデルの詳細仕様が TLM2.0 ベースで全くモデリングできないことになってしまうと、TLM2.0 の適用範囲が狭まってしまいます。そこで考え出されたのが、いく
つかの拡張手段です。
TLM2.0 には、大きく分けて、転送する情報を追加する方法と、詳細なタイミング・ポイントとその通信プロトコルを定義するための、Phase を追加する二つの拡張手段があります。これらの二つを利用して、詳細なプロトコルを定義することが可能になっています。
1. Generic Payload 拡張
Generic Payload に、ユーザが定義したクラスのポインターを追加して転送することによる拡張手段です。標準ではアドレス、データ、データ長、バースト長等の基本情報がサポートされていますが、これ以外の情報、例えば、ロック、バスマスターID 等のプロトコル依存の情報、トラン
ザクション ID 等、解析機能のための情報等をユーザ定義のクラスのメンバ変数に設定し、標準のGeneric Payload と一緒に転送します。
2. フェーズ拡張
TLM2.0 では、通信の手段として、ブロッキング転送である、b_transport()と、ノンブロッキン
グ転送である、nb_transport()がサポートされています。このうち、nb_transport()には、BEGIN_REQ、END_REQ、BEGIN_RESP、END_RESP の 4 つの Phase が定義されており、この Phase をイ
ニシエータとターゲットにより交換することにより、基本的なタイミング・ポイントを定義でき
るようになっています。しかし現実のバス・プロトコルでは、4 つでは足りず、6 つ必要な場合もあります。こういった詳細なバス・プロトコルを定義するために、ユーザが Phase を追加できるようになっています。
- 222 -

3. 無視可能な拡張とそうでない拡張
それでは、ある IP ベンダーが Generic Payload の拡張や Phase 拡張をしてモデルを開発した場合、そのモデルは他のベンダーの TLM2.0 準拠のモデルと一緒に動かすことができるのでしょうか？
つまり、拡張をおこなうことによって互換性がどこまで保たれるのでしょうか？
残念というべきか当然ですが、あるベンダーが独自に拡張してそのプロトコルを自分で定義した場合、そのモデルは、TLM2.0 をベースにしているとはいえ、そのプロトコルを知らないモデルとの間で正しく動かすことはできません。
しかしながら、そこには一定のルールがあります。Generic Payload の拡張にしろ、フェーズ拡
張にしろ、「無視できる拡張」と「無視できない拡張」があります。「無視できる拡張」とは、相手がそのプロトコルを知らなかったとしても、基本的な TLM2.0 の動作に影響を与えない拡張のことです。
「無視できない拡張」とは、プロトコル依存の拡張をした場合で、相手がその内容を知らない場
合には、基本的な TLM2.0 の動作にまで影響を与えてしまう拡張のことです。
例えば、バスのパフォーマンス解析のためにそれぞれのトランザクション ID とか、イニシエータの ID とかを Generic Payload の拡張クラスに定義したとします。
こういったツール依存の拡張は、
ツールによっては必要な場合もありますが、TLM2.0 としての基本的な機能そのものには影響を与えません。つまり必須ではありませんので、無視できるわけです。このようなものは、独自にイニシエータに追加しても、ターゲットに問題なく渡すことができます。
例えば、バスモデルのみ特定ベンダーから受け取った IP を使用し、イニシエータとターゲット・
モデルを自分で作成する場合を考えてみます。この場合、イニシエータ側で情報を追加し、ター
ゲットでその情報を取得することができます。バスモデルは、それらの追加情報のヘッダファイ
ル等がなくても、ソースが公開されていないモデルであったとしても、ユーザが追加した情報をそのまま素通りさせることができます。つまり、バスモデルベンダーに特別なエンハンスメント要求等をしなくても、ユーザ独自の情報をイニシエータ側とターゲット側でやりとりできるような仕組みになっているわけです。
それでは、ターゲット・モデルのみを開発する場合においで、イニシエータが何らかの拡張情報を追加している場合はどうなるでしょうか？
この場合、イニシエータが勝手に追加した情報のヘッダファイルがなくても無視すればいいだけです。もし、そのヘッダファイルを入手することができれば、初めて、その追加情報にアクセスすることができるようになります。
逆に、バスモデルを開発するときには、そういった拡張情報を消してはいけません。知らない拡
張情報に関しては、変更を加えず素通りさせることが明確にルールで決められています。また、
イニシエータではなく、バスモデルがイニシエータから渡されたトランザクションに拡張情報を追加してターゲットに渡すこともできますが、この場合にはターゲットから戻ってきた時点において自分で追加した情報を削除する必要があります。
このような無視できる情報に対して、モデルの動作そのものに影響を与えるようなものを追加してしまうと、もはや、その拡張情報を知るもののみがその IP に対応したモデルを動かすことができるようになってしまいます。
問題になるのは、ある TLM2.0 に対応したモデルが無視できる拡張しか持たないのかそうでないのかをどう判断させるかです。仕様書を参照してほしいという曖昧な方法はここでは通用しません。
TLM2.0 では、このために、無視できない拡張をした場合には、新しい「Traits クラス」を別途定義して、それを使用したソケットを使用することが定められています。
つまり、無視できない特定プロトコルをサポートしたソケットを接続する場合には、特定のクラスを用いてソケットを定義し、それら同士のみが接続できるように強制させているのです。もし違うもの同士を接続したとしても、コンパイルエラーとなります。このことが重要なのです。エ
ラボレーション時ではなく、コンパイル時点で、異なる意味をもつプロトコル同士の接続をさせないようにしているということです。
この新しい「Traits クラス」を使用する義務があるというのは、何も自分で拡張構造を定義した
り拡張フェーズを定義したときだけではありません。意味論として、少しでも TLM2.0 のルールからはずれたモデルを作成してしまうと、その時点で互換性が無くなってしまうので、Traits クラスを使用する必要があるのです。
ある意味では、TLM2.0 のベース・プロトコルとほとんど同等で、少しだけ違うといったものが簡単に作れるということになります。その IP を使うユーザ同士がそのことを認識して使えばいいと- 223 -

いうことになります。
4. 新しいソケットを定義する具体的方法
例えば、Generic Payload も、Phase も拡張しないが、ルールだけを変えたい場合に具体的にどうすればいいかをみてみましょう。
以下のようなモデルがあるとします。
SC_MODULE (target1_pv_base),tlm::tlm_fw_transport_if<>{
typedef tlm::tlm_target_socket<32> target_socket_type;target_socket_type socket1;...

ここでは、template 内でデフォルト値を使用しています。もう少し省略しないで書くと次のようになります。
SC_MODULE(target1_pv_base),tlm::tlm_fw_transport_if<tlm::tlm_base_protocol_types>{
typedef tlm::tlm_target_socket<32,tlm::tlm_base_protocol_types>
target_socket_type;target_socket_type socket1;...

この tlm::tlm_base_protocol_types は、次のように TLM2.0 で定義されています。
struct tlm_base_protocol_types{
typedef tlm_generic_payload tlm_payload_type;typedef tlm_phase tlm_phase_type;};

これをそのままコピーして、次のように自分のプロトコル（「Traits クラス」）を定義します。中身の generic payload や、phase はそのままでも別のものでも構いません。
struct my_protocol_types{
typedef tlm_generic_payload tlm_payload_type;typedef tlm_phase tlm_phase_type;};

あとは、上記の tlm_base_protocol_types の部分を、my_protocol_types に置き換えるだけです。
SC_MODULE(target1_pv_base),tlm::tlm_fw_transport_if<my_protocol_types>{
typedef tlm::tlm_target_socket<32,my_protocol_types> target_socket_type;target_socket_type socket1;

これだけで、後はいっさい変更する必要はありません。これで、my_protocol_types を持ったソケットを、TLM2.0 のベース・プロトコル(tlm::tlm_base_protocol_types)につなげようとすると、コンパイル時にエラーがでるようになり、間違った接続であることがわかります。
なお、モデル内で typedef によりソケットタイプ等を使用するようにしておいた方が後での変更に柔軟に対応できるようになります。
5. Generic Payload の拡張方法
tlm_generic_payload にないメンバが必要な場合には、tlm_generic_payload を継承するのではな
く、別途必要なメンバ変数を保持するクラスを定義して、generic_payload に対して
set_extension()関数を用いてそのクラスを登録します。
例:class my_payload : public tlm::tlm_extension<my_payload> {public:virtual tlm::tlm_extension_base* clone() const {my_payload* t = new my_payload;t->m_lock = this->m_lock;return t;- 224 -

}
my_payload(bool lock) : m_lock(bool lock) {}public:bool m_lock;};

上記は、m_lock という変数を持ったクラスでこれを generic_payload にセットします。
追加方法(イニシエータ側)
tlm_generic_payload* trans = new tlm_generic_payload;
my_payload* my_p = new my_payload(true);trans->set_extension(my_p);

取得方法(ターゲット側)
b_transport(tlm_generic_payload &trans,sc_time& time) {my_payload* my_p; = NULL;
trans->get_extention(my_p);if(!my_p) {// No such extension, Initiator is not my IP.
} else {bool lock = my_p->m_lock; // Oh, this is my IP.
...

拡張したクラスのヘッダファイルさえあれば、そのクラスの拡張があるかどうかを調べて、あった場合にはそれを利用するという使い方ができます。
6. Phase の拡張方法
Phase を拡張するには次のようにします。DECLARE_EXTEND_PHASE とは TLM2.0 で定められたマクロです。
DECLARE_EXTENDED_PHASE (BEGIN_DATA);DECLARE_EXTENDED_PHASE (END_DATA);

イニシエータ側
phase = BEGIN_DATA;
sync = i_socket->nb_transport_fw(trans,phase,time);

ターゲット側
tlm::tlm_sync_enum nb_transport_fw(transaction_type &trans, phase_type &phase,
sc_time &time){cout << "Target: received phase[" << phase << "]" << endl;

Phase 拡張は、主にプロトコルを拡張するために使われることから、通常ユーザ定義の「Traits
クラス」を用います。もし、自分の知らない phase が来た場合には無視します。つまり何も来な
かったことにします。エラーにしてはいけません。
ベース・プロトコル(つまり Traits クラスを定義しない場合)のまま使用する場合、無視可能なフェーズ拡張を受信した場合には、TLM_ACCEPTED のみを返す仕様になっています。そのため、関数の戻り値を判別して、ターゲットが無視したのか、理解されたのかを、イニシエータが簡単に知る手段はありません。
7. ベース・プロトコルとは何か？
TLM2.0 には、tlm_fw_transport_if、tlm_bw_transport_if という二つのインタフェース・クラスとそのクラスに定義されている b_transport, nb_transport があり、これが中心になっています。
これらを使わなかったら、TLM2.0 とは呼べません。
このインタフェースに渡すべき、tlm_generic_payload、tlm_phase は、TLM2.0 の中の、ベース・プロトコルとして定義されている部分であり、これらを拡張することも、全く異なるものを使用することもできるようになっています。
互換性を最大限追求するのであれば、このベース・プロトコルの仕様に基づいたものにするべきであるといえます。詳細なバス・プロトコルを使用する場合には、バス・プロトコル専用のソケ
ットクラス(「Traits クラス」）を使用してベース・プロトコルとは別ものであるということをは- 225 -

っきりさせる必要があるということになります。
4.2.3.3 TLM のタイミング精度
TLM2.0 では、タイミング精度と高速性の 2 つの相反する要求を満たすためにいくつかのコーディ
ングスタイルを提唱しています。また、必要なタイミング精度を確保するためには、Phase 拡張などを実装する場合もあります。ここでは、どのようなタイミング精度が実際のデザインにおいて必要になり、それぞれのタイミング精度に対して、TLM2.0 がどのような手法を用意しているかについてまとめます。
1. タイミング・ポイント
トランザクション・レベル・モデリングを行う際には、そのトランザクションが開始されて、何らかの処理を行い、終了するまでの時間軸において、重要な時刻に着目したモデリングを行うことにより、高速化なシミュレーション環境を構築します。
ゲートレベルのシミュレーション環境においては、それぞれのゲートの遅延時間までモデリング
してシミュレーションするのに対し、RTL 記述においては、ゲートの遅延時間を排除して、クロックにのみ着目してモデリングします。これと同様、TLM においては、クロックよりも粒度の荒いタイミングに着目して、クロックを排除することにより高速化させます。
TLM2.0 では、このタイミング・ポイントの取り方によって、2 タイミング・ポイント、3 タイミ
ング・ポイント、4 タイミング・ポイント、それ以上のタイミング・ポイントを表現することができます。
TLM2.0 の基本インタフェースには、b_transport() （ブロッキング)と、nb_transport()（ノンブロッキング)の 2 つの関数が用意されており、b_transport()においては、2 つのタイミング・
ポイント、nb_transport()においては、2,3,4,それ以上のタイミング・ポイントを定義することができます。
通常、b_transport()の 2 つのタイミング・ポイントを用いたコーディングスタイルを、LT コー
ディングスタイル(Loosely（粗い)Timed)コーディングスタイルと呼び、それ以上のタイミング・
ポイントを用いたコーディングスタイルを、AT(Approximately Timed)コーディングスタイルと呼んでいます。
2. 2 つのタイミング・ポイント
もっとも簡単なタイミング精度は、開始と終了の 2 つのタイミング・ポイントのみを持つものです。
CPU など、データの送受信を要求する側(イニシエータ)がトランザクションの要求をした時点が開始時刻となり、要求された側(ターゲット)が処理をおこない、その終了後送信側に制御を戻した時点が、トランザクションの終了時刻になります。この場合、開始時刻と終了時刻との差がレ
イテンシとなり、通常はターゲット側において、そのレイテンシを決めることになります。
イニシエータとターゲットが直結している場合には、ターゲットの処理時間のみがトータルの処
理時間を左右することになります。しかし、間にバス等のインターコネクトモデルが含まれている場合には、バス内の時間をそれぞれ追加することになるので、最大 3 つの時間を定義可能です。
レイテンシ = (バスの前処理時間) + (ターゲットのレイテンシ) + (バスの後処理時間)- 226 -

2 つのタイミング・ポイント：直結の場合
イニシエータ
要求開始
終了

ターゲット
----> 処理開始
(処理)<---- 処理終了

2 つのタイミング・ポイント：バスを含む場合
イニシエータ
要求開始

終了

バス
ターゲット
----> 事前処理開始(処理)
要求開始 -------->処理開始(処理)
事後処理開始<-----処理終了（処理)<---- 事後処理終了

3. 3 つのタイミング・ポイントが必要になる例
しかしながら、2 つのタイミング・ポイントではモデリングできず、どうしても 3 つのタイミン
グ・ポイントが必要な場合があります。
例えば、ターゲットがイニシエータにデータを戻す際に、イニシエータ側の受信スピードが遅く、その時間をイニシエータ側で制御したいとします。この場合、2 つのタイミング・ポイントでは、
ターゲット側の処理が終わってから、イニシエータ側に戻った後、イニシエータ側で wait()を行っても、ターゲット側はすでに処理を終わってしまっているため、ターゲット側での処理時間が全体として実際よりも短くなってしまいます。
2 つのタイミング・ポイント
イニシエータ
要求開始

ターゲット----> 処理開始
(処理)
受信処理開始 <---- 処理終了
(処理)
本来はここもビジーのはず。
受信処理終了

3 つのタイミング・ポイント
イニシエータ
要求開始

ターゲット----> 処理開始
(処理)
受信処理開始 <---- 受信処理開始(処理)
受信処理終了 ----> 受信処理終了

このため、イニシエータとターゲット間では、開始時刻と終了時刻の間にもう 1 つのタイミング・
ポイントをもうける必要があります。
TLM2.0 のベース・プロトコルでは、こういった途中の処理状態を表すために、4 つの Phase を定義しています。
イニシエータ ターゲット
BEGIN_REQ
END_REQ
BEGIN_RESP
END_RESP

リクエスト開始
リクエスト終了
レスポンス開始
レスポンス終了

上記の 3 つのタイミング・ポイントでは、このうち、END_REQ は使わずに、BEGIN_REQ、BEGIN_RESP、
END_RESP の 3 つの Phase を用いることにより、2 つの時間を設定できます。
イニシエータBEGIN_REQ

ターゲット---> 処理開始（処理)- 227 -

受信処理開始（処理)
END_RESP<--- BEGIN_RESP---> 処理終了

つまり、イニシエータがターゲットに BEGIN_REQ を送ることによりターゲットが処理を開始し、ターゲットのレスポンス送信が可能になった時点で BEGIN_RESP をイニシエータ側に通知して、イ
ニシエータ側がすべての処理を終了した時点で、ターゲット側に END_RESP を通知することにより、両者が同時に終了させることができるわけです。
4. 4 つのタイミング・ポイントが必要になる例
それでは、BEGIN_REQ の後の END_REQ は、どういうケースで必要になるのでしょうか？
イニシエータ側は、BEGIN_REQ により要求をターゲットに開始しています。ターゲットの処理が終わるのを待つだけであれば、END_REQ という要求受付という情報を受け取らなくても良さそうです。
これがどうしても必要になるケースは、1 つのトランザクション処理が終了する前に、別のトラ
ンザクションを開始したい場合です。つまり、ターゲットに対して始めの要求をしたら、その処理が終了する前に２番目の要求を開始したい場合です。2 番目の要求を開始できるタイミングは少なくとも 1 番目の要求が完了した時点になりますので、どうしても、END_REQ という Phase を
ターゲットから受け取る必要が出てくるのです。
BEGIN_REQ1

BEGIN_REQ2---><--- END_REQ1----><--- END_REQ2......
<--- BEGIN_RESP1---><--- BEGIN_RESP2--->

END_RESP1
END_RESP2

このように処理待ちのトランザクションのことを、アウトスタンディング・トランザクションと呼びます。 (処理の形態としてはパイプライン処理）
5. 何故アウトスタンディング・トランザクションが必要になるか？
ここで、少し本題から離れて、どういう場合にアウトスタンディング・トランザクションが必要になるかを考えてみます。
アウトスタンディング・トランザクションをサポートしていないバスの場合、1 つのトランザクションが開始してから終了するまでの間、バスそのものはずっと占有し続けます。しかし、例えば SDRAM のようにページのミスヒットによっては、レイテンシが非常に長くなる場合もあり、メモリの実際の読み書きをしている時間中ずっとバスを占有し続けるのは非常に無駄になります。
そこで、ターゲット側のコントローラーに、FIFO を用意して、とりあえずアドレス等の要求のみを受け付けて、バスを解放してしまいます。つまり、BEGIN_REQ から、END_REQ までの時間は、要求を受け付けるだけの時間になります。通常、READ 命令の場合には、アドレスを送るだけの処理となり、WRITE 命令の場合には、アドレスと実際のデータを送る処理になります。その後、END_REQ
から BEGIN_RESP の間に実際のメモリの読み書き処理が行われ、それが終了した BEGIN_RESP とEND_RESP の間に、READ 命令の場合には、実際のデータを転送する処理、WRITE 命令の場合には終了通知をイニシエータにおこなうことになります。
WRITE 命令の場合
BEGIN_REQ ---><--<--END_RESP --->

アドレス送信
データ送信
END_REQ 受付処理終了、バス解放(メモリ書き込み処理)
BEGIN_RESP (終了通知)

READ 命令の場合- 228 -BEGIN_REQ --->
アドレス送信<--- END_REQ 受付処理終了、バス解放(メモリ読み込み処理)<--- BEGIN_RESP (データ送信)
データ受信
END_RESP --->

データ受信終了通知

なお実際には、ターゲットが BEGIN_REQ を受け取った時点で FIFO が空であれば、すぐにメモリの読み書きを始めることができますが、それはあくまでも FIFO の出口側の話で、FIFO の入り口でアドレスなりデータの受信を終了した時点で、END_REQ をイニシエータに通知してバスを解放できます。FIFO がフルであったとすると、FIFO が空くまで、END_REQ を返すことはできなくなります。レスポンス側でも同様のことが起こり、イニシエータ側のデータの受け取り作業が遅れると、ターゲット側の出力側の FIFO にデータがたまり続けます。こういったシステムではデッドロック
を起こす危険性もあります。
いずれにせよ、アウトスタンディング・トランザクションをサポートする高機能なバスを使用し、バスの占有率を取得したいケースでは、少なくとも 4 つのタイミング・ポイントをサポートしたモデリングスタイルが必要になります。
6. 4 つ以上のタイミング・ポイントが必要になるケース
通常は、上記の 4 つのタイミング・ポイントがあればほとんどの場合モデリングできるわけです
が、バス・プロトコルによっては、Phase を追加して、6 つのタイミング・ポイントが必要になる場合があります。
例えば、AXI プロトコルが良い例です。AXI の場合、アドレスチャネルとデータ送信チャネル、データ受信チャネルがすべて独立して、それぞれイニシエータとターゲット間にてハンドシェイク
しています。
例えば、WRITE 命令の場合、通常はアドレスを送信した後、ただちにデータを送信し始めるため、その間に別の処理をするというのはありません。しかし AXI プロトコルの場合、アドレスだけを複数送っておいて、あとからデータを別途送るということができるわけです。そうすると、アドレス開始、アドレス終了、データ送信開始、データ送信終了、レスポンス開始、レスポンス終了という 6 つのタイミング・ポイントが必要になってきます。
TLM2.0 では、ベース・プロトコルとして互換性を最大限確保する Phase としては、4 つが定義されていますが、こういったバス独自の機能をサポートするために、Phase を追加することができるようになっています。この Phase 拡張の機能を使用すれば、AXI プロトコルの複雑なバスにも完全に対応することができるわけです。
ただし、Phase 拡張を用いた場合には、通常イニシエータ側とターゲット側にて TLM2.0 のベース・プロトコルを逸脱したプロトコルを双方で守って送受信する必要がでてきますので、当然のことながら、互換性は損なわれることになります。
BEGIN_REQ--> アドレス送信<-- END_REQ 受付終了

BEGIN_AXI_DT --> データ送信<-- END_AXI_DT

END_RESP<-- BEGIN_RESP-->

注：BEGIN_AXI_DT、END_AXI_DT は、このドキュメント内で便宜的に定義しているもの
注意したいのは、AXI を使用することと、6 つの Phase が必要になるということが同義語ではないことです。
AXI はバスの定義ではなく、Point-to-Point でのプロトコルを定義しているにすぎず、6 つのPhase が本当に必要になるかどうかは、AXI のどの機能を用いてどのようにバスを構成しているかに依存するのです。たとえ、アドレスチャネルとデータチャネルが独立してハンドシェイクしていたとしても、常にアドレスを送った直後にデータを送るようにしているのであれば、BEGIN_REQとその後の Phase を分ける必要はなく、TLM2.0 のベース・プロトコルで十分だということになります。これは、OCP-IP 等のプロトコルでも同じことがいえます。
- 229 -

7. イニシエータ側のモデリング方法
イニシエータ側におけるモデリング方法は、アウトスタンディング・トランザクション/パイプラ
インを使用しているかどうかによって大きく異なってきます。
例えば、2 つのタイミング・ポイントを実現する b_transport()を用いてイニシエータ側のモデリングをする場合は非常に簡単です。
何故かというと、b_transport()の場合、その関数が戻ってきたときには、必ず全ての処理が終了しているため、連続的に b_transport()をコールし、簡単にそこで取得した値を利用することができるからです。
例socket.b_transport(Read,アドレス 1、&データ 1);
cout << データ 1 << endl;
sccket.b_transport(Read,アドレス 2、&データ 2);
cout << データ 2 << endl;(模式的に表現しています)

これは、b_transport()を使用している時だけでなく、たとえ、nb_transport()を用いて 4 つのPhase を用いた場合でも、複数のトランザクションを同時にスタートしなくても良い場合には、同じようなコーディングをおこなうことができます。
socket.my_transport(Read,アドレス 1、&データ 1);
cout << データ 1 << endl;
sccket.my_transport(Read,アドレス 2、&データ 2);
cout << データ 2 << endl;(模式的に表現しています)** my_transport() の中で、nb_transport()、レスポンス処理を待つ等の処理をインプリメント
しておけばいい。
しかし、アウトスタンディング・トランザクションやパイプライン処理をしている場合にはこうはいきません。1 つめの送信処理が終了した時点で 2 つ目の送信処理をしたのでは遅すぎるからです。1 つめの送信処理をしている途中で、2 つ目の送信処理を開始しなければいけなくなります。
こういった場合には、複数の Thread を SystemC で用意して、それぞれ送信処理と受信処理を別々の Thread にて実行するようにモデリングする必要があります。これは考えてみれば当たり前のことで、RTL においても、複数トランザクションのサポートが必要なければ、1 つのステートマシン
で実現できるのに対し、こういった場合には、複数のステートマシンで実現することが必要にな
り、TLM でも同じことがいえるわけです。
ただし、アウトスタンディング・トランザクションとして使用できる数にはたいてい制限があり、むやみに送信要求をするということはあり得ません。したがって、個別の送信では上記のようなモデリングはできなくても、ある程度まとまった送受信を行うという処理にしてしまえば、全体
としては 1 つの送受信処理と見なすようなモデリングは可能です。
8. どのタイミング・ポイントを使うべきか
それでは、実際問題として、どのようなタイミング・ポイントを用いてモデリングするべきでしょうか？ これはトランザクション・レベル・モデリングを利用する目的によって変わってきます。例えば、ハードウエア－ソフトウエア協調シミュレーション等を行うだけであれば、たとえバスとして AXI を使用していたとしても、2 つのタイミング・ポイントで十分のはずです。これに対し、バスの占有率を調査したいようなケースにおいては、やはり詳細なタイミング・ポイン
トまで表現しておかないと、現実の数値とかけ離れてしまいます。
できれば、複数の利用目的にかなうように、タイミング精度を切り替えられるようなコーディン
グスタイルにしておくのがいいのではないかと考えられます。あるいは、機能とタイミングを分離したコーディングスタイルを利用するという手もあります。
いずれにしても、TLM2.0 では様々な目的に利用できるようなコーディングスタイルを提唱していますので、用途と目的に応じたモデリングをおこなうことにより、新しい設計環境に対応できるようになっています。

- 230 -

4.2.4 OSCI TLM2.0 へのフィードバック
Recommendation for OSCI/TLM2.0 document by JEITA SystemC Working Group (v1.0)
JEITA SystemC working group has been working to review TLM2.0 official document and
we are briefly translating it to Japanese so that TLM2.0 user in Japan can understand it
easily.
We heard that OSCI TLMWG are working to write LRM targeting to IEEE standard, So werecommend some documentation issues so that LRM will be easier to be understood.
1) Base protocol concept and each extension have to be clarify at beginning of the standard
Explanation of base protocol and extension for phase and generic_payload and new traits
class related issues are described in several different sections.
We think base protocol concept should be discussed at very beginning of the standard andneed to be clarified together with real world bus protocol and interoperability issue. Becauseinteroperability of TLM2.0 and usage model of TLM2.0 depend on base protocol andextensions.
Also, more explanation about what is covered by base protocol, what is covered by ignorable
extension, or by non ignorable extension should be discussed clearly, maybe using somegraphics.
2) Require phase transition table to explain nb_transport phase
Base protocol define 4 phases for nb_transport, but it is very difficult to start writing code
based on this document.
For example, when a user try to implement nb_transport_bw() function, he or she needs tocover every cases for each transition. By this document, it is very difficult to understandwhich phase he or she needs to implement, and what should be done if he or she receives
erroneous phase.
We strongly recommend to add some kind of table to address these issues.
3) 5.3.2.4 get_direct_mem_ptr should be invalidate_direct_mem_ptr.
5.3.2.4j) An initiator is not obliged to register an invalidate_direct_mem_ptr callback with asimple initiator or socket, in which case an incoming get_direct_mem_ptr call shall beignored.
This get_direct_mem_ptr should be invalidate_direct_mem_ptr
We think this is just a document typo.
4) 5.3.2.4 Simple target socket b/nb conversion figure is not clear
5.3.2.4 has 2 figures to explain nb/b adaptor and b/nb adaptor (figure 12/figure 13).
But it is difficult to understand how it works.
We recommend to add which process calling "wait()" in the figure.
5) Simple target socket b/nb conversion examples need more scenarios
5.3.2.4 shows how b/nb conversion works, but it uses only one scenario. Other scenarios
such as using END_RESP phase or directory jumping to BEGIN_RESP are required.
- 231 -

6) 8.2 Payload event queue explanation is not enough, need more examples
8.2 describes 2 classes, peq_with_get, peq_with_cb_and_phase, but it does not have any
example how to use these classes. We recommend to add examples and better explanation.
7) TLM1.0 positioning
TLM1.0 positioning is not clear in the document. Please clarify which part of TLM1.0 is
standard in the LRM.

- 232 -

4.2.5 SystemC推奨設計メソドロジ

2008年度版

SystemC推奨設計メソドロジ 1© Copyright 2004-2009 JEITA, All rights reserved

はじめに


目的
SystemCの特徴を生かした設計メソドロジ（スタイル）の提案を行い、設計メソドロジの共通認識を広める 設計メソドロジの議論の土台を作る
 設計メソドロジ案を公開し、それに対応してもらうこと
で各種ツールの親和性を高めたい

対象
主にデジタル信号処理系を対象とする
 アルゴリズムをHWとSWに分割し、実装及び検証するまでの手法を検討する

SystemC推奨設計メソドロジ 2© Copyright 2004-2009 JEITA, All rights reserved

-233-

目次
1. 背景
 2. システム設計
 3. SW設計
 4. HW設計
 5. 検証 6. モデリング(高速化) 7. その他


SystemC推奨設計メソドロジ 3© Copyright 2004-2009 JEITA, All rights reserved

１．背景

SystemC推奨メソドロジー 4© Copyright 2004-2009 JEITA, All rights reserved-234-

1-1.システムＬＳＩの状況






システム技術が１チップに統合 （コンピュータ技術、無線技術、ネットワーク
技術、デジタル信号処理等）
主な用途は、デジタルＡＶ機器用、携帯電話用と車載用
開発期間は、ＨＷとＳＷ共、６ヶ月から長くて１年「ＥＳＬ設計技術」の育つ土壌
プロセス技術- 微細化- 多層配線- Cu配線、Ｌｏｗｋ- アナログ混載

設計技術

ＣＰＵ

Specific
Processor Ｆｌａｓｈ

ＤＳＰ

Processing- 音声圧縮伸長- 画像圧縮伸長- 音声認識- 暗号化

Signal
H/W

ソフトＩＰ
Specific
H/W- ＥＳＬ設計- チップ設計- ｿﾌﾄｳｪｱ設計

Control
H/W

AnalogハードＩＰ
Interface

- ＣＰＵ
- ＤＳＰ
- ＭＰＥＧ- インタフェース
SystemC推奨設計メソドロジ 5© Copyright 2004-2009 JEITA, All rights reserved

1-2.「牧本ウェーブ」 と ＥＤＡ設計技術
 1991年に英国の新聞が命名（牧本氏、テクノビジョン代表）。「半導体産業は、

標準化指向とカスタム指向が10年毎に入れ替わる。」
 ＥＤＡ設計技術革新がパラダイムシフトをドライブした。
 ＡＳＩＣとＦＰＧＡは、ＲＴＬ検証と合成がビジネスを可能にした。
Abstraction

C Synthesis

ES Level
RT Level
Gate Level
Trs. Level

RTL Synthesis
Auto P&R
Layout Editor

‘75

‘85

‘95

‘05

‘15

Next Wave- New Design Method- Maskless Method- New SiP
‘17

Automated
SoC/SiP

SystemC推奨設計メソドロジ 6© Copyright 2004-2009 JEITA, All rights reserved-235-

1-3.設計危機
 低消費電力ＳｏＣ（ITRSシステムドライバー）

２００１年での設計コスト：１５Ｍ＄
 過去１２年設計技術の改善なし：３４２Ｍ＄
 今後も、設計コストを抑止するための設計技術の改善努力が必要（出展：２００１ ＩＴＲＳ）

SystemC推奨設計メソドロジ 7© Copyright 2004-2009 JEITA, All rights reserved

1-4. EDAとは ?
 Electronic Design Automation (EDA)

広義では、電子機器システムの構想設計、実装設計と設計検証を可能にする「設計技術（DT: Design Technology）」
 狭義では、エレクトロニクス製品の設計ツール
 設計技術は、設計ツール、設計ライブラリと設計方法論
 設計技術は、システム設計者の設計構想と設計目標をコスト低減を考慮し、製造可能で検査可能な形式に変換する技術

EDA
z 設計ツールz 設計ライブラリ

システム設計者

z 設計方法論

SystemC推奨設計メソドロジ 8© Copyright 2004-2009 JEITA, All rights reserved-236-

1-5.設計システムとEDA標準の位置付け
 設計システムは、多種多様なツールを統合化し、仕様検討から製造可能データ作成を実現

SystemDesignSpecification(Function +Constraints)

 EDA標準は、設計システムへの ＥＤＡ標準の分類

Ｌａｎｇｕａｇｅz Ｆｏｒｍａｔz Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙz Standard for new standards
developmentz

Implement
w/Opt.
Software
Logic

Verification

共通セマンティックスのための機構を提供

Validation
Function
Performance
Testability

Analyze
Area
TimingCommunicat
Scan/BISTPowere
Circuit
Noise
Place Libraries
DFT
Route
DFM

Data formanufacturing
SystemC推奨設計メソドロジ 9© Copyright 2004-2009 JEITA, All rights reserved

1-6. 設計言語標準化の歴史
 ＲＴＬでは、シミュレーションー＞合成ー＞検証と進化

ＥＳＬでもこのアナロジーを踏襲
 設計技術の高度化が、推奨メソドロジを要求
高度化

システムレベル
記述言語

ESL Synthesis& Verification

ANSI-C/C++ESL Simulation based

SystemC-2005Methodology
JEITA SCDM

RTL Verification
ＲＴレベル
記述言語
RTL Simulation
VHDL -1993

RTL Synthesis
VLOG Synthesis
Subset -2002
VHDL Synthesis
Subset -1999

SystemVLOG-2005

Methodology
OVM/VMM

VLOG -1995
1995

2000

2005

2010
SystemC推奨設計メソドロジ 10© Copyright 2004-2009 JEITA, All rights reserved-237-

2. システム設計

SystemC推奨メソドロジー 11© Copyright 2004-2009 JEITA, All rights reserved

2-1.概要SystemCは、LSIのシステムレベルの設計に使われます。LSIシステム全体を高速にシミュレーションし、システムアーキテクチャ（CPUやメモリ、周
辺ハードウエア、CPUバスなどの配置や接続）の最適解を探索します。
または、周辺ハードウエアの詳細アーキテクチャを決め、ハードウエアに実装する（合成する）ために使われています。
2005年にSystemCはIEEE-1666として標準化されました。2006年にTLM
1.0がOSCIより公開され、また合成サブセットがレビューのため公開されています。2008年にはTLM 2.0が正式リリースされる予定です。EDA
ツールもこれらの標準に対応していくと思われます。
ハードウエアの設計においても、これら標準化の流れに従って方法論を構築できれば、システムLSIの設計全体の流れをスムースにします。しかしながら、これら標準においてTLMと合成の橋渡しに関する議論がまだ十分行われていません。OSCIの合成サブセットにおいてSystemCの特徴を生かす合成方法について十分に述べられていません。
ここでは、システムLSI設計の方法論について、主に合成の立場から１つの筋の通る骨組みを提案します。

SystemC推奨設計メソドロジ 12© Copyright 2004-2009 JEITA, All rights reserved-238-

2-2.システムLSIの開発ステップ
システム設計システムモデリングと機能要求の確認

システム性能の解析

システムの処理を複数のタスクに分ける(Function Network)
タスクをプロセッサやハードウエアのモデルに置き換える
接続をOSCI-TLMに沿ったチャネルにする

SW設計

HW設計
SystemC推奨設計メソドロジ 13© Copyright 2004-2009 JEITA, All rights reserved

2-3.システムLSIの開発ステップ
システムモデリングと機能要求の確認
システム全体または一定単位（ユニット）をC/C++/SystemCによって、Untimedな機能検討用モデリングを行い、機能要求が満たされている事を確認する。

システム性能の解析
機能検討モデルを用いたシステム性能検討C/C++/SystemCシミュレーション、ソフトウェアエミュ
レーションで実施する。

システムの処理を複数のタスクに分ける(Function Network)
システム性能確認に基づいた各機能単位を分割し、それら分割単位と接続からシステムのデータフローを明確にする。

タスクをプロセッサやハードウエアのモデルに置き換える
接続をOSCI-TLMに沿ったチャネルにする
各ファンクションユニットをCPU、SW、HWのモデルに置き換え、バス周辺のアーキテクチャ検討やSWとHWの検討を行う。
SystemC推奨設計メソドロジ 14© Copyright 2004-2009 JEITA, All rights reserved-239-

2-4.本ステップにおけるSystemCユースケース
デ
｜
タ
型

並
列
性

時
間

チ
ャ
ネ
ル

システムモデリングと機能要求の確認

△

×

×

×

システム性能の解析

△

×

×

×

システムの処理を複数のタスクに分ける

△

○

×

○

タスクをプロセッサやハードウエアのモデルに置き換える
接続をOSCI-TLMに沿ったチャネルにする

○

○

△

○

© Copyright 2004-2009 JEITA, All rights reserved

SystemC推奨設計メソドロジ 15

2-5.システムモデリングと機能要求の確認

このフェーズにおける目的

C/C++を用いて、コンセプトモデルとなる機能検討用モデルの作成を行う。
機能検討を効率的に行う為に出来るだけ詳細化を行わない。
 ここでのモデルで使用するアルゴリズムは既に検討済みとする。


機能検討に関わる構文に限定してSystemCを使用する。
タイミング、構造的な詳細化は避ける。

ゴール
パフォーマンスを可能な限り損なわない機能検討モデルを構築する。
 機能が要求に満たす事を確認する。


SystemC推奨設計メソドロジ 16© Copyright 2004-2009 JEITA, All rights reserved-240-

2-6.機能検討モデリングにおけるSystemC要件


ここでのSystemCの使用は、機能検討に関わる構文のみに限定する。
タイミング、構造的な詳細化は避ける。
シミュレーション速度の低下。
 機能ユニット分割後の検討でタイミングや構造は修正の可能性がある為、機能分割に影響を及ぼさない追加が望ましい。


必要に応じてハードウェア化を検討する際にSystemCを利用する。
SystemCデータ型
 SC_FIXED等
 シミュレーション速度やソフトウェア化を考慮する場合、#ifdefやtypedefによるSystemCとCの構文切り替えを用いる。


SystemC推奨設計メソドロジ 17© Copyright 2004-2009 JEITA, All rights reserved

2-7.機能検討モデリングにおけるSystemC要件


後段の実装手法を意識したコード記述をする事が望ましい。


例えば動作合成によるRTL実装を行う場合に避ける事が望ましい記述例
再帰呼び出し 動的メモリアロケーション
 STLの使用等
SystemC推奨設計メソドロジ 18© Copyright 2004-2009 JEITA, All rights reserved-241-

2-8.システム性能要求の確認

このフェーズにおける目的
モデルの性能解析を行う。
 機能分割要件の明確化。




ゴール
モデルの性能要件を満たす事を確認する。
 機能分割要件の情報をまとめる。


SystemC推奨設計メソドロジ 19© Copyright 2004-2009 JEITA, All rights reserved

2-9.システム性能の検討と確認
モデルの性能評価
 ファンクション・ネットワーク構築向けの機能分
割の為の性能検討

単純に機能単位に分割
 ブロック間のデータ通信量を観測
 各機能の動作率等プロファイリングを行う


SystemC推奨設計メソドロジ 20© Copyright 2004-2009 JEITA, All rights reserved-242-

2-10.システムLSIの開発ステップシステムの処理を複数のタスクに分ける(Function Network)
システム設計
LT/AT

AT/CA

タスクをプロセッサやハードウエアのモデルに置き換える
接続をOSCI-TLMに沿ったチャネルにする
遅延情報を挿入して動作を確認する

SW設計

SWを実装する接続をModular Interfaceに モジュールの変えて動作を確認する
遅延情報はない
HWを動作合成する

HW設計

性能を確認し、最適化を行う。
LT:Loosely Timed , AT:Approximately Timed , CA: Cycle Accurate
SystemC推奨設計メソドロジ 21© Copyright 2004-2009 JEITA, All rights reserved

2-11.システム処理を複数タスクに分ける

このフェーズにおける目的

アルゴリズムの分割と処理手順の明確化を行う。
ファンクション・ネットワークを構築し、TLM等を用いてデータのフローや並列性をモデルする。
 SW/HW分割の為の基本情報を見つける。




ゴール


処理フローから並列処理、順次処理、パイプライン化の可能性が判明する。
並列処理やパイプライン化のためには複数のハードウ
エアかプロセッサが必要である
 順次処理が多い場合は、プロセッサを用いるのが最適である可能性が高い


SystemC推奨設計メソドロジ 22© Copyright 2004-2009 JEITA, All rights reserved-243-

2-12.Function Network機能ユニット(Function Unit)がデータの流れに応じて接続(Network)される。

FU_B
FU_A

FU_D

FU_E

FU_C
図からわかること•FU_BとFU_Cは並列に動作可能。
•A->B/C->Dの処理はパイプライン化することもシーケンシャル処理することもできる。
•D->Eの処理はフィードバックがあるためにシーケンシャルにしか処理できない。
SystemC推奨設計メソドロジ 23© Copyright 2004-2009 JEITA, All rights reserved

2-13.システムの検討項目


Function Unit

Network

データフローをモデル化
端子(port)と接続(interface)

Structure

機能役割をモデル化
ファンクション(function)とデータ(data)

データ構造をモデル化
クラス(class)とアクセスメソッド(member function)

Process

計算過程をモデル化
状態遷移(state machine)とイベント(event)

SystemC推奨設計メソドロジ 24© Copyright 2004-2009 JEITA, All rights reserved-244-

2-14.TLMの設計場面(use case)① SWアプリケーション開発とSW/HW実装② SWパフォーマンス解析③ SWアーキテクチャ解析④ HWアーキテクチャ解析⑤ HWパフォーマンス検証⑥ HW改良と実装
HWはBL、テストベンチがTL⑦ HW機能検証
HWはRTL,テストベンチがTL

SystemC推奨設計メソドロジ 25© Copyright 2004-2009 JEITA, All rights reserved

2-15.ソフトウエアとハードウエア


ソフトウエアの利点
実装後も変更が容易
 開発期間が短い（RTLと比べた場合、BLとはど
うか）




ハードウエアの利点
高速性能が得やすい
 低消費電力化の可能性が高い


SystemC推奨設計メソドロジ 26© Copyright 2004-2009 JEITA, All rights reserved-245-

2-16. アーキテクチャ設計
CPUを含むシステムでのアーキテクチャ設計では、CPUの速度、メモリのサイズ、周辺ハードウエアの仕様、CPUバスについて検討します。CPUに着目した場合、その上で動作するソフトウエアのサイズ、処理能力を確認します。メモリは、データ格納場所の割り当て、インタフェース速度が十分であるかを確認します。
周辺ハードウエアは、IPなどを使用して仕様が固定されている場合と新規に作成するために詳細設計が必要な場合があります。新規のハード上の回路規模が大きい場合には、さらにそれ単体で細かくアーキテクチャ設計を行っていくことになります。CPUを含まないシステムの場合には、データの流れが決まっていることが多く、データは個々のモジュール間で直接渡されるようになります。
CPUやメモリ、CPUバスなど既存のものをシステムに組み込む場合は、シミュレーションの高速化のために主にデータ転送のモデリングを工夫します。
一般に用いられるのがTransaction Level Modeling(TLM)と呼ばれるものです。モデリングのためにはシミュレーションの速度を落とすことなく遅延情報などを詳細に記述することに重きを置きます。一方、ハードウエア
設計ではリソースの詳細を明確にする必要があります。
SystemC推奨設計メソドロジ 27© Copyright 2004-2009 JEITA, All rights reserved

2-17.タスクをプロセッサやハードウエアのモデルに置換える

このフェーズにおける目的

タスクをSW/HWを考慮したモデルに置き換える。
TLM等を用いて検証速度を考慮したモデルを行う。
 SW/HW分割したモデルの詳細な検討を行う。




ゴール


CPUやバス周辺、メモリ等システムのアーキテク
チャが要求に満たす事を確認する。


モデルは各SW/HW設計に渡される。

SystemC推奨設計メソドロジ 28© Copyright 2004-2009 JEITA, All rights reserved-246-

2-18. CPUを中心としたアーキテクチャ

CPU

メモリ

周辺ハードウエア

MMB

１つのCPUはファンクションの１個か複数個を実現する。
 ファンクションを接続するネットワークは、MMB上に実現される。ネットワークを実現するSWのライ
ブラリが必要である。


SystemC推奨設計メソドロジ 29© Copyright 2004-2009 JEITA, All rights reserved

2-19 周辺ハードウエアのアーキテクチャ
メモリ1

モジュール１

モジュール2メモリ2モジュール3

MMBインタフェース

一般にモジュールは単機能。
 ファンクションを接続するネットワークは、HWライ
ブラリとして用意する。


SystemC推奨設計メソドロジ 30© Copyright 2004-2009 JEITA, All rights reserved-247-

2-20.システム
Function Unit A
processingdoFunction Unit B

Function Unit C

didiprocessing

doprocessing

dodicontrol

lc

lc

gc

control

lc

lc

gc

controlgc

Global Control Unitgc
cpu

gc: global control （全体の制御信号）
lc: local control （FU間の制御信号）
SystemC推奨設計メソドロジ 31© Copyright 2004-2009 JEITA, All rights reserved

3.HW/SW協調検証

SystemC推奨メソドロジー 32© Copyright 2004-2009 JEITA, All rights reserved-248-

3-1.内容
HW/SW協調検証編の位置づけ
 HW/SW協調検証の4つのPhase Phase1-4の目的と抽象度
 各Phaseの詳細説明
Phase1の詳細説明
 Phase2の詳細説明
 Phase3の詳細説明
 Phase4の詳細説明
SystemC推奨設計メソドロジ 33© Copyright 2004-2009 JEITA, All rights reserved

3-2.HW/SW協調検証編の位置づけ
HW/SW協調検証環境
システム・バス
TLM2.0

TLM2.0

TLM2.0

ＨＷエンジン

メモリI/FCPU

FU_D

TLM2.0

CPU

GCU
GC

FU_E

メモリ

対象とするSW

GC

GC

FU

FU

FU_A

このSWの検証にフォーカス

FU_B

FU_C

HW/SW協調検証編では，Function NetworkにおいてHW/SW分割でSWに割り当てられたFunction Unitの検証にフォーカス
 目的に応じたSW検証に必要なHWモデルの抽象度を定義
SystemC推奨設計メソドロジ 34© Copyright 2004-2009 JEITA, All rights reserved-249-

3-3. HW/SW協調検証の4つのPhase
Phase1
HW/SW分割SW設計

HWモデルの抽象度
HW(Untimed)

Phase2

SW機能設計HW(TLM-LT)

協調検証

HW(TLM-AT)
SW性能解析
(チューニング）Phase3/4

HW(CA/RTL)

Phase1：システム全体の機能設計，HW/SW分割見積り
Phase2：SW機能設計・検証，機能的なHWとSWのIF検証
Phase3：システム性能の再確認，SWチューニング(HWとSWのタイミング)
Phase4：HW性能の再確認
SystemC推奨設計メソドロジ 35© Copyright 2004-2009 JEITA, All rights reserved

3-4. Phase1-4の目的と抽象度
Phase1

Phase2Phase3Phase4

目的

SW抽象度
（言語）

システム全体の機能設計
HW/SW分割見積り

SystemC(UT),
Host
C, C++
Native

SW機能設計・検証
機能的なHWとSWのIF検証

SW環境選定実際のSW

CPUモデル HWモデル抽象度（CPU除く）
抽象度

相対必要
速度

Untimed

数Gcps

ISS

TLM-LT

数Mcps

CPU選定

（RTOSとデバイ
スドライバの開発）

システム性能の再確認
SWチューニング(HWとSWのタイミング)

実際のSW（RTOS上で、ア
ルゴリズムを動作させる）

ISS

TLM-AT

数
100Kcps

HW性能の再確認

実際のSW（HWとのIFをサイクル精度ISS/RTL

CA/RTL

数Kcps

確認する）
© Copyright 2004-2009 JEITA, All rights reserved-250-

SystemC推奨設計メソドロジ 36

3-5.Phase1の詳細説明
目的

SystemC推奨設計メソドロジ（システム設計編）に従いシステムモデリングと機能要求の確認
 システム性能の解析
モデリング（HW・SW)
各Function unitにはHW/SWの区別なくアルゴリズムを表現する機能のみをモデル化
 なるべく高い抽象度モデル

C,C++, SystemC(UT)など

結果（出力）
Function Networkのモデル
 HW/SWの分割結果（各FunctionがSWかHWか） CPUとSW開発環境（ソフトウェアスタック）の選定


SystemC推奨設計メソドロジ 37© Copyright 2004-2009 JEITA, All rights reserved

3-6.Phase2の詳細説明
目的

SW機能設計・検証

機能的なHWとSWのIF検証

システム性能の再確認











RTOSなどのソフトウェアスタックの実装

IF検証用としてHWモデル内のレジスタのR/Wプログラム
RTOSなどのソフトウェアスタックの実装


デバイスドライバ（HW非依存部とHW依存部の両方）

HWのモデリング

システム・バスのプロトコルに従ったTLMモデル（TLM2.0に準拠）
ブロッキングモデル（TLM-LTレベル）


HWに依存しているデバイスドライバの機能設計

SWの開発




デバイスドライバを開発する

タイミング精度より，機能確認を優先

結果（出力）


実際のSW（ソフトウェアスタック）

HWエンジンモデル（TLM-LT)

RTOS、ファームウェア、ライブラリ（OpenGLなど）

SystemC推奨設計メソドロジ 38© Copyright 2004-2009 JEITA, All rights reserved-251-3-7.Phase3の詳細説明
目的

SWのチューニング（HWとSWのタイミング）




SWの開発


SW全体をチューニング






アルゴリズム（演算の並列化やデータの固まりの見直し）
RTOS（タスク・スレッドのスケジューリングや優先順位）
デバイスドライバ（割込みの優先順位やレジスタ本数）

HWのモデリング

検証対象に準じて、モデルの詳細化を実施する
ノンブロッキングモデル（TLM-ATレベル）


最適なHWとSWのI/F（並列化など）を確認

タイミングクリティカルなHW-SW間プロトコルをTLM-ATへ変更

結果（出力）


実際のSW




チューニングされたSW（ソフトウェアスタック全体）

HWエンジンモデル（TLM-AT）
SystemC推奨設計メソドロジ 39© Copyright 2004-2009 JEITA, All rights reserved

3-8.Phase4の詳細説明
目的

HW性能の再確認




SWの開発





サイクル精度レベルでの最終確認
必要ならチューニングも実施

HWのモデリング

サイクル精度のモデルを作成する


SWを含めた正確なタイミングでのHWの性能解析とチューニング

動作合成結果のRTLやサイクル精度のSystemCモデルを利用．動
作合成しないモデルについては別途サイクル精度のモデルを用意（例えば既存RTLなど）

結果（出力）


実際のSW




サイクル精度でチューニングが必要な場合

HWエンジンモデル（CAまたはRTL）
SystemC推奨設計メソドロジ 40© Copyright 2004-2009 JEITA, All rights reserved-252-

4. HW設計

SystemC推奨メソドロジー 41© Copyright 2008 JEITA, All rights reserved

4-1.はじめに

設計対象のシステム


データ加工を行うシステム
デジタルフィルタ・サーボ
 音声・画像・動画圧縮伸長
 誤り訂正符合生成・再生
 暗号化・復元
 ・・・




対象外
アナログシステム メモリやペリフェラルなどの単純なモジュール単体
 制御が主体のシステム


SystemC推奨設計メソドロジ 42© Copyright 2004-2009 JEITA, All rights reserved-253-

4-2.FNDM2Function Network Design Methodology
version 2.0

SystemC推奨メソドロジー 43© Copyright 2004-2009 JEITA, All rights reserved

4-2.FNDM2について2007年度に「SystemC推奨設計メソドロ
ジ・合成編」として作成されたものを改良。
 2007年度はHWの動作合成を前提にしたFNDM(Function Network Design
Methodology)と呼ぶ設計手法を提案した。
 そこで、2007年度版をFNDM１とし、新たに提案するものをFNDM2とする。
 FNDM2は設計対象範囲をデータ処理する
HWだけでなく、HWと組み合わせられる
データ処理を行うSWにまで広げている。


SystemC推奨設計メソドロジ 44© Copyright 2004-2009 JEITA, All rights reserved-254-

4-2.FNDM1で設計対象としたHW
Memory Mapped Bus

CPU

Memory
I/F

設計対象のHW
CPU

GCU
GC

Memory

GC

GC

FU

FU
SystemC推奨設計メソドロジ 45© Copyright 2004-2009 JEITA, All rights reserved

4-2.FNDM2で設計対象とするHWとSW
Memory Mapped Bus

CPU

MemoryI/F

Original HW
CPU

GCU
GC

FU_D

FU_E

Memory

GC

GC

FU

FU

FU_A

FU_B FU_C
SystemC推奨設計メソドロジ 46© Copyright 2004-2009 JEITA, All rights reserved-255-

4-2.Function Network機能ユニット(Function Unit)がデータの流れに応じて接続(Network)される。

FU_B
FU_A

FU_D

FU_E

FU_C
図からわかること•FU_BとFU_Cは並列に動作可能。
•FU_A->FU_B/FU_C->FU_Dの処理はパイプライン化することもシーケンシャル処理することもできる。
•FU_D->FU_Eの処理はフィードバックがあるためにシーケンシャルにしか処理できない。
SystemC推奨設計メソドロジ 47© Copyright 2004-2009 JEITA, All rights reserved

4-2.Function Network を実装するシステムの構成
Function Unit A
processingdoFunction Unit B

Function Unit C

didiprocessing

doprocessing

dodicontrol

lc

lc

gc

controllc

lc

controlgc

gc

Global Control Unitgc
cpu

gc: global control （全体の制御信号）
lc: local control （FU間の制御信号）
SystemC推奨設計メソドロジ 48© Copyright 2004-2009 JEITA, All rights reserved-256-

4-2.信号の分類


データ転送
片方向のハンドシェークを使ったデータ転送が多い。
モジュラーインタフェースを使う。



ローカル制御データ転送の相手との制御情報の交換する（データのハンドシェーク信号はデータ転送に含まれる）グローバル制御
GCU (Global Control Unit)と制御信号を交換する。
パラメータのような静的な制御信号が多い。

SystemC推奨設計メソドロジ 49© Copyright 2004-2009 JEITA, All rights reserved

4-2.Function Unit
データの処理を行うユニット
 データの演算、加工はprocessingプロセスで行う。
 データに依存して処理が変わる場合、
processingプロセスから取り出されたその制御
信号はcontrolプロセスで扱う。
 プロセスは、processingプロセスかcontrolプロセスに分類できる。その数に制約はない。
 データの入出力ポート数に制約はない。
 gcポートは１つでなければならない。


SystemC推奨設計メソドロジ 50© Copyright 2004-2009 JEITA, All rights reserved-257-

4-2.Global Control Unit
FU (Function Unit)の制御を行う。
 通常はシステムに１つ。
 将棋倒し型の場合は、CPUインタフェースと制御データの保持を行う。
 中央制御型の場合は、将棋倒し型の機能に加えて各FUの動作タイミングを制御する。


SystemC推奨設計メソドロジ 51© Copyright 2004-2009 JEITA, All rights reserved

4-2.FUの動作タイミング


将棋倒し型
データの入力側のモジュールから順に入力デー
タを受け取り準備が整ったところから処理を始める。
出力が滞り、内部バッファに余裕がなくなった場
合は、データ入力を停止する。



中央制御型
GCUの合図に基づいて各モジュールは動作を行う。

SystemC推奨設計メソドロジ 52© Copyright 2004-2009 JEITA, All rights reserved-258-

4-2.HW設計の流れ
アルゴリズムの分割とモジュール作成
モジュールの接続
シミュレーションで記述のデバッグ

データ型の決定
レジスタにする配列とメモリにする配列を分類
動作合成可能にするための修正要求性能を満たす
ように修正する

レイテンシの削減
回路規模削減SystemC推奨設計メソドロジ 53© Copyright 2004-2009 JEITA, All rights reserved

4-2.動作記述の特徴を生かす
下記の４つを独立して設計を行う。
ライブラリ
インタフェース （モジュラーインタフェース）
 メモリアクセス （モジュラーインタフェース）
 演算系 （ユーザ定義型）


システム


アルゴリズムとアーキテクチャ（モジュールと階層構造）
SystemC推奨設計メソドロジ 54© Copyright 2004-2009 JEITA, All rights reserved-259-

4-2.基本ルール
モジュールの役割をFU(Function Unit)か
GCU(Global Control Unit)のどちらかに定める。
 モジュールはそれぞれの用意された雛形を拡張して記述する。
 インタフェース、メモリアクセス、演算系はライブラリを利用する。
 ライブラリを拡張したり、新規に作成する場
合は、メンバ関数名、引数の統一化を行う。


SystemC推奨設計メソドロジ 55© Copyright 2004-2009 JEITA, All rights reserved

4-3.インタフェース

SystemC推奨メソドロジー 56© Copyright 2004-2009 JEITA, All rights reserved-260-

4-3.出力インタフェースの公開メンバ関数


ブロッキング関数（データの送受信が終了するまで戻らない）
void put(const TD &data, const bool &vld=true)

ブロッキング関数（データの送受信を1回だけ試み成否を返す）
bool ns_put(const TD &data, const bool &vld=true)

ノンブロッキング関数（毎サイクル実行される必要がある）
前準備
bool nb_can_put(const bool &vld=true)実行bool nb_put(const TD &data)
後処理
bool nb_clr_put()



ポート接続
void bind(T channel)
void operator ()(T channel)

インタフェースポートの初期化
void reset()
SystemC推奨設計メソドロジ 57© Copyright 2004-2009 JEITA, All rights reserved

4-3.シングル入力インタフェースの公開メンバ関数

ブロッキング関数（データの受信が終了するまで戻らない）
void get(TD &data, const bool &en=true)
T get(const bool &en=true)

ブロッキング関数（データの受信を1回だけ試み成否を返す）
bool ns_get(TD &data, const bool &en=true)

ノンブロッキング関数（毎サイクル実行される必要がある）
前準備
bool nb_can_get(const bool &en=true)実行bool nb_get(TD &data)
後処理
bool nb_clr_get()



ポート接続
void bind(T channel)
void operator ()(T channel)

インタフェースポートの初期化
void reset()
SystemC推奨設計メソドロジ 58© Copyright 2004-2009 JEITA, All rights reserved-261-

4-3.インタフェース・チャネルの公開メンバ関数とポート

チャネルのトレース
friend sc_trace(sc_trace_file*, const T&, const
std::string&)FIFOなどの内部にレジスタを持つチャネルでは、クロックやリセットが必要になるが、その場合は、以下のポート名を使うものとする。
clk クロックrst リセット（負論理）※解析用に信号が必要な場合については検討中である。

SystemC推奨設計メソドロジ 59© Copyright 2004-2009 JEITA, All rights reserved

4-3.put関数
void put(const TD &data, const bool&vld=true)
vldが真のときにdataを送信する。送信が終了するまで次の処理に進まない。
vldが偽のときは、送信を行わない。vldが真のときに必要な最小クロック数だけ待って次の処理に進む。

SystemC推奨設計メソドロジ 60© Copyright 2004-2009 JEITA, All rights reserved-262-

4-3.ns_put関数
bool ns_put(const TD &data, const bool&vld=true)
vldが真のときにdataの送信を1回試みる。成功
した場合はtrueが、失敗した場合はfalseが戻る。
vldが偽のときは、送信を行わない。vldが真のときに必要な最小クロック数だけ待って次の処理に進む。

SystemC推奨設計メソドロジ 61© Copyright 2004-2009 JEITA, All rights reserved

4-3.nb_can_put関数
bool nb_can_put(const bool &vld=true)
ノンブロッキング関数であり、クロックを含まずに処理する。
vldが偽の場合は常に偽が戻される。
vldが真でかつ送信がすぐ可能な場合に真が戻り、それ以外の場合は偽が戻る。

SystemC推奨設計メソドロジ 62© Copyright 2004-2009 JEITA, All rights reserved-263-

4-3.nb_put関数
bool nb_put(const TD &data)
ノンブロッキング関数であり、クロックを含まずに処理する。
データ送信が行われる場合に真が戻り、行われないと判断できる場合に偽が戻る。

SystemC推奨設計メソドロジ 63© Copyright 2004-2009 JEITA, All rights reserved

4-3.nb_clr_put関数
bool nb_clr_put()
ノンブロッキング関数であり、クロックを含まずに処理する。
nb_put()を実行した次のクロックサイクルでデータ送信を終了する場合に必ず実行する。
nb_can_put(false)で代用させる事ができる。

SystemC推奨設計メソドロジ 64© Copyright 2004-2009 JEITA, All rights reserved-264-

4-3.put()のnon-blocking関数による定義
non-blocking関数は、以下の使用方法でblocking関数が作れるように実装すること。
void put(const TD &data, const bool &vld=true){if(vld){while(!nb_can_put()) wait();while(!nb_put(data)) wait();do{wait();}while(nb_clr_put());}elsewait();}

SystemC推奨設計メソドロジ 65© Copyright 2004-2009 JEITA, All rights reserved

4-3.get関数
void get(TD &data, const bool &en=true)
T get(const bool &en=true)
enが真のときにデータを受信する。受信が終了するまで次の処理に進まない。
enが偽のときは、受信を行わない。enが真のときに必要な最小クロック数だけ待って次の処理に進む。
get()関数には2通りの形態があり、dataを引数として渡してそこに受信値を受け取るか、戻り値として受信値として受け取る。

SystemC推奨設計メソドロジ 66© Copyright 2004-2009 JEITA, All rights reserved-265-

4-3.ns_get関数
bool ns_get(TD &data, const bool
&en=true)enが真のときにdataの受信を1回試みる。成功
した場合はtrueが、失敗した場合はfalseが戻る。
enが偽のときは、受信を行わない。enが真のときに必要な最小クロック数だけ待って次の処理に進む。

SystemC推奨設計メソドロジ 67© Copyright 2004-2009 JEITA, All rights reserved

4-3.nb_can_get関数
bool nb_can_get(const bool &en=true)
ノンブロッキング関数であり、クロックを含まずに処理する。
enが偽の場合は常に偽が戻される。
enが真でかつ受信の予約ができた場合に真が戻り、それ以外の場合は偽が戻る。

SystemC推奨設計メソドロジ 68© Copyright 2004-2009 JEITA, All rights reserved-266-

4-3.nb_get関数
bool nb_get(TD &data)
ノンブロッキング関数であり、クロックを含まずに処理する。
データ受信が行われる場合に真が戻り、行われない場合に偽が戻る。nb_can_get()が真になったあと一定数のクロック後に1クロックだけ真になる。このタイミングを逃すとnb_get()で真の戻り値を得ることができない。

SystemC推奨設計メソドロジ 69© Copyright 2004-2009 JEITA, All rights reserved

4-3.nb_clr_get関数
bool nb_clr_get()ノンブロッキング関数であり、クロックを含まずに処理する。
nb_can_get()を実行した次のクロックサイクル
で次のデータ受信を続けない場合に必ず実行する。nb_can_get(false)で代用させる事ができる。

SystemC推奨設計メソドロジ 70© Copyright 2004-2009 JEITA, All rights reserved-267-

4-3.get()のnon-blocking関数による定義
non-blocking関数は、以下の使用方法でblocking関数が作れるように実装すること。
void get(TD &data, const bool &en=true){
if(en){
while(!nb_can_get()) wait();do{wait();}while(!nb_get(data));while(!nb_clr_get()) wait();}else
wait();}

SystemC推奨設計メソドロジ 71© Copyright 2004-2009 JEITA, All rights reserved

4-3.bind関数
void bind(T channel)
void operator ()(T channel)
モジュールのポートとそのモジュールの外部のチャネルとを接続する。そのモジュールの上位モジュールのポートとの接続も可能。

SystemC推奨設計メソドロジ 72© Copyright 2004-2009 JEITA, All rights reserved-268-

4-3.reset関数
void reset()
インタフェースポートに関連したレジスタを初期化する。

SystemC推奨設計メソドロジ 73© Copyright 2004-2009 JEITA, All rights reserved

4-3.sc_trace関数
friend sc_trace(sc_trace_file*, const T&,
const std::string&)
vcdファイルにトレースを記録する場合に使用する。

SystemC推奨設計メソドロジ 74© Copyright 2004-2009 JEITA, All rights reserved-269-

4-3.blocking関数の使い方
blocking関数の記述は簡単。
while(1){input.get(d_in);
d_out = calc(d_in);
output.put(d_dout);}

SystemC推奨設計メソドロジ 75© Copyright 2004-2009 JEITA, All rights reserved

4-3.Non-blocking関数の使い方
nb_clr_get()とnb_clr_putをnb_can_get()とnb_can_put()に続くwait()の直後におく。条件判定に直接記述
するとどちらか一方のみしか起動できない場合があるので、check_stall()関数を用意する。
bool en、vld, is_ds; T data;
en=true; vld=false; is_ds=false;
while(1){input.nb_can_get(en);if(is_ds)
is_ds = false;
else
vld = input.nb_get(data);
if(vld) d_out = calc(d_in);if(vld)if(en=output.nb_can_put()) output.nb_put(d_dout);}

do{wait();}while(check_stall(data, is_ds));

SystemC推奨設計メソドロジ 76© Copyright 2004-2009 JEITA, All rights reserved-270-4-3.check_stall関数
ノンブロッキング関数を利用するとき、複数のclr関数がある場合に用意する。
 出力の都合でストールする場合、入力データを取りこぼす可能性があるので対処をしておく。
bool check_stall(T &ds, bool &is_ds ){bool stall = !input.nb_clr_get();stall = stall || !output.nb_clr_put();if(stall&&!is_ds)
is_ds = input.nb_get(ds);return stall;}

SystemC推奨設計メソドロジ 77© Copyright 2004-2009 JEITA, All rights reserved

4-3.インタフェース・ライブラリ

モジュラーインタフェースで用意される。
mi::mi_get_if<TD>クラスかmi::mi_put_if<TD>クラスを継承している。
ハンドシェークのみでバッファされないデータ転送
fn_rdyvld_ch<TD> チャネル
fn_rdyvld_ch<TD>::in データ入力ポート
fn_rduvld_ch<TD>::out データ出力ポート



レジスタで構成されたFIFOを持つデータ転送
fn_fifo_ch<TD,FL> チャネル
fn_fifo_ch<TD,FL>::in データ入力ポート
fn_fifo_ch<TD,FL>::out データ出力ポート



SRAMで構成されたFIFOを持つデータ転送

fn_fifo_sram_ch<TMW> チャネル
fn_fifo_sram_ch<TMW>::in データ入力ポート
fn_fifo_sram_ch<TMW>::out データ出力ポート



FIFOのチャネルにはclk（立ち上がり動作）とrst(負論理）のポートがあり、クロックとリセットの供給が必要である。
SystemC推奨設計メソドロジ 78© Copyright 2004-2009 JEITA, All rights reserved-271-

4-3.ハンドシェーク (fn_rdyvld_ch)

module_A

put（）
processmodule_B

out

fn_rdyvld_ch

in

get（）
process

SystemC推奨設計メソドロジ 79© Copyright 2004-2009 JEITA, All rights reserved

4-3.FIFO (fn_fifo_ch)

module_A

module_B
fn_fifoput（）
processout

fn_fifo_ch

in

get（）
processclk

rst

SystemC推奨設計メソドロジ 80© Copyright 2004-2009 JEITA, All rights reserved-272-

4.3.SRAMを用いたFIFO(fn_fifo_sram_ch)fn_sram_wrapperclk

fn_srammodule_A

module_B
memp

put（）
processout

fn_fifo_sram_ch
process

get（）inprocess

fn_fifo
clk rstSystemC推奨設計メソドロジ 81© Copyright 2004-2009 JEITA, All rights reserved

4-3.マルチ入力インタフェース

SystemC推奨メソドロジー 82© Copyright 2004-2009 JEITA, All rights reserved-273-

4-3.マルチ入力インタフェースの概要
１つのモジュールに同一種類の入力インタ
フェースが複数あるときに使用することができる。
 複数の入力を一度にアクセスするためのメンバ関数が用意されている。
 同一種類の入力インタフェースが複数ある場
合でも、独立して入力する場合は、シングル
入力インタフェースを用いた方が良い。
 ポートは入力の数だけ存在し、シングル入力
インタフェースと同じチャネルを接続する。


SystemC推奨設計メソドロジ 83© Copyright 2004-2009 JEITA, All rights reserved

4-3.マルチ入力インタフェースの例

fn_rdyvld_chIn<0>sc_uint<3> en;
TD data[3];fn_rdyvld_ch

In<1>In.get(data,en)

fn_rdyvld_ch

In<2>

SystemC推奨設計メソドロジ 84© Copyright 2004-2009 JEITA, All rights reserved-274-

4-3.マルチ入力インタフェースの公開メンバ関数

ブロッキング関数（データの受信が終了するまで戻らない）
void get(TD data[num_of_port], const sc_uint<num_of_port> &en)



ブロッキング関数（データの受信を1回だけ試み成否を返す）
sc_uint<num_of_port> ns_get(TD data[num_of_port], const
sc_uint<num_of_port> &en)

ノンブロッキング関数（毎サイクル実行される必要がある）
前準備
sc_uint<num_of_port> nb_can_get(const sc_uint<num_of_port> &en)
実行
sc_uint<num_of_port> nb_get(TD &data, const sc_uint<num_of_port>&en)
後処理
sc_uint<num_of_port> nb_clr_get(const sc_uint<num_of_port> &en)



ポート接続
void bind<num>(T channel)

全インタフェースポートの初期化
void reset()
SystemC推奨設計メソドロジ 85© Copyright 2004-2009 JEITA, All rights reserved

4-3.get関数
void get(TD data[num_of_port], const
sc_uint<num_of_port> &en)
enのビットが1のポートのデータを受信する。指定した全受信が終了するまで次の処理に進まない。
enが0のときは、受信を行わない。enが0でないときに必要な最小クロック数だけ待って次の処理に進む。
num_of_portは、ポートの数。

SystemC推奨設計メソドロジ 86© Copyright 2004-2009 JEITA, All rights reserved-275-

4-3.ns_get関数
sc_uint<num_of_port> ns_get(TDdata[num_of_port], const
sc_uint<num_of_port> &en)enと戻り値は各ビットが各ポートの動作を示す。
enのビットが1のポートのdataの受信を1回試みる。成功したポートのビットは1が、失敗したポートのビットは0が戻る。
enのビットが0のポートは、受信を行わない。enが0の場合は、0でないときに必要な最小クロック数だけ待って次の処理に進む。

SystemC推奨設計メソドロジ 87© Copyright 2004-2009 JEITA, All rights reserved

4-3.nb_can_get関数
sc_uint<num_of_port> nb_can_get(const
sc_uint<num_of_port> &en)
ノンブロッキング関数であり、クロックを含まずに処理する。
enが偽の場合は常に偽が戻される。
enが真でかつ受信の予約ができた場合に真が戻り、それ以外の場合は偽が戻る。

SystemC推奨設計メソドロジ 88© Copyright 2004-2009 JEITA, All rights reserved-276-

4-3.nb_get関数
sc_uint<num_of_port> nb_get(TD &data,
const sc_uint<num_of_port> &en)
ノンブロッキング関数であり、クロックを含まずに処理する。
データ受信が行われる場合に真が戻り、行われない場合に偽が戻る。nb_can_get()が真になったあと一定数のクロック後に1クロックだけ真になる。このタイミングを逃すとnb_get()で真の戻り値を得ることができない。

SystemC推奨設計メソドロジ 89© Copyright 2004-2009 JEITA, All rights reserved

4-3.nb_clr_get関数
sc_uint<num_of_port> nb_clr_get(const
sc_uint<num_of_port> &en)
ノンブロッキング関数であり、クロックを含まずに処理する。
nb_can_get()を実行した次のクロックサイクル
で次のデータ受信を続けない場合に必ず実行する。nb_can_get(0)で代用させる事ができる。

SystemC推奨設計メソドロジ 90© Copyright 2004-2009 JEITA, All rights reserved-277-

4-3.get()のnon-blocking関数による定義
non-blocking関数は、以下の使用方法でblocking関数が作れるように実装すること。
void get(TD data[num_of_port], const sc_uint<num_of_port>&en){if(en){
sc_uint<num_of_port> abits = en;while(nb_can_get(en)!=en) wait();do{ wait(); }while((abits &= ~nb_get(abits))!=0);
while(nb_clr_get(en)!=en) wait();}else
wait();}

SystemC推奨設計メソドロジ 91© Copyright 2004-2009 JEITA, All rights reserved

4-3.bind関数
template<unsigned int num>
void bind(T channel)
モジュールのポートとそのモジュールの外部のチャネルとを接続する。そのモジュールの上位モジュールのポートとの接続も可能。numはポート番号。

SystemC推奨設計メソドロジ 92© Copyright 2004-2009 JEITA, All rights reserved-278-

4-3.reset関数
void reset()
インタフェースポートに関連したレジスタを初期化する。

SystemC推奨設計メソドロジ 93© Copyright 2004-2009 JEITA, All rights reserved

4-4.マルチ出力インタフェース

SystemC推奨メソドロジー 94© Copyright 2004-2009 JEITA, All rights reserved-279-

4-4.マルチ出力インタフェースの概要
１つのモジュールに同一種類の出力インタ
フェースが複数あるときに使用することができる。
 複数の出力を一度にアクセスするためのメンバ関数が用意されている。
 同一種類の出力インタフェースが複数ある場
合でも、独立して出力する場合は、シングル
出力インタフェースを用いた方が良い。
 ポートは出力の数だけ存在し、シングル出力
インタフェースと同じチャネルを接続する。


SystemC推奨設計メソドロジ 95© Copyright 2004-2009 JEITA, All rights reserved

4-4.マルチ出力インタフェースの例

fn_rdyvld_chOut<0>

sc_uint<3> vld;
TD data[3];fn_rdyvld_chOut<1>

Out.put(data,vld)

fn_rdyvld_chOut<2>

SystemC推奨設計メソドロジ 96© Copyright 2004-2009 JEITA, All rights reserved-280-

4-4.マルチ出力インタフェースの公開メンバ関数

ブロッキング関数（データの送受信が終了するまで戻らない）
void put(const TD data[num_of_port], const sc_uint<num_of_port> &vld)

ブロッキング関数（データの受信を1回だけ試み成否を返す）
sc_uint<num_of_port> ns_put(const TD data[num_of_port], const
sc_uint<num_of_port> &vld)



ノンブロッキング関数（毎サイクル実行される必要がある）
前準備
sc_uint<num_of_port> nb_can_put(const sc_uint<num_of_port> &vld)
実行
sc_uint<num_of_port> nb_put(const TD data[num_of_port], const
sc_uint<num_of_port> &vld)
後処理
sc_uint<num_of_port> nb_clr_put(const sc_uint<num_of_port> &vld)



ポート接続
void bind<num>(T channel)

全インタフェースポートの初期化
void reset()
SystemC推奨設計メソドロジ 97© Copyright 2004-2009 JEITA, All rights reserved

4-4.put関数
void put(const TD data[num_of_port], const
sc_uint<num_of_port> &vld)
vldのビットが1のポートのデータを送信する。指定した全送信が受信されるまで次の処理に進まない。
vldが0のときは、送信を行わない。vldが0でないときに必要な最小クロック数だけ待って次の処理に進む。
num_of_portは、ポートの数。
SystemC推奨設計メソドロジ 98© Copyright 2004-2009 JEITA, All rights reserved-281-

4-4.ns_put関数
sc_uint<num_of_port> ns_put(const TD
data[num_of_port], const
sc_uint<num_of_port> &vld)
vldと戻り値は各ビットが各ポートの動作を示す。
vldのビットが1のポートのdataの送信を1回試みる。成功したポートのビットは1が、失敗したポートのビットは0が戻る。
vldのビットが0のポートは、送信を行わない。vldが0の場合は、0でないときに必要な最小クロック数だけ待って次の処理に進む。

SystemC推奨設計メソドロジ 99© Copyright 2004-2009 JEITA, All rights reserved

4-4.nb_can_put関数
sc_uint<num_of_port> nb_can_put(const
sc_uint<num_of_port> &vld)
ノンブロッキング関数であり、クロックを含まずに処理する。
vldが偽の場合は常に偽が戻される。
vldが真でかつ送信がすぐ可能な場合に真が戻り、それ以外の場合は偽が戻る。

SystemC推奨設計メソドロジ 100© Copyright 2004-2009 JEITA, All rights reserved-282-

4-4.nb_put関数
sc_uint<num_of_port> nb_put(const TD
data[num_of_port], const
sc_uint<num_of_port> &vld)
ノンブロッキング関数であり、クロックを含まずに処理する。
データ送信が行われる場合に真が戻り、行われないと判断できる場合に偽が戻る。

SystemC推奨設計メソドロジ 101© Copyright 2004-2009 JEITA, All rights reserved

4-4.nb_clr_put関数
sc_uint<num_of_port> nb_clr_put(const
sc_uint<num_of_port> &vld)
ノンブロッキング関数であり、クロックを含まずに処理する。
nb_put()を実行した次のクロックサイクルでデータ送信を終了する場合に必ず実行する。
nb_can_put(0)で代用させる事ができる。

SystemC推奨設計メソドロジ 102© Copyright 2004-2009 JEITA, All rights reserved-283-

4-4.put()のnon-blocking関数による定義
non-blocking関数は、以下の使用方法でblocking関数が作れるように実装すること。
void put(const TD data[num_of_port], const
sc_uint<num_of_port> &vld){
if(vld!=0){
sc_uint<num_of_port> abits = vld;
while(nb_can_put(vld)!=vld) wait();while((abits &= ~nb_put(data,abits))!=0) wait();do{wait();}while(nb_clr_put(vld)!=vld) wait();}else
wait();}

SystemC推奨設計メソドロジ 103© Copyright 2004-2009 JEITA, All rights reserved

4-4.bind関数
template<unsigned int num>
void bind(T channel)
モジュールのポートとそのモジュールの外部のチャネルとを接続する。そのモジュールの上位モジュールのポートとの接続も可能。numはポート番号。

SystemC推奨設計メソドロジ 104© Copyright 2004-2009 JEITA, All rights reserved-284-

4-4.reset関数
void reset()
インタフェースポートに関連したレジスタを初期化する。

SystemC推奨設計メソドロジ 105© Copyright 2004-2009 JEITA, All rights reserved

4-5.メモリアクセス

SystemC推奨メソドロジー 106© Copyright 2004-2009 JEITA, All rights reserved-285-

4-5.メモリ書き込みの公開メンバ関数


ブロッキング関数（メモリの書き込みが終了するまで戻らない）



ブロッキング関数（メモリの書き込みを1回だけ試み成否を返す）

void put( const TA &address, const TD &data, const bool &vld=true)bool ns_put(const TD &data, const bool &vld=true)

ノンブロッキング関数（毎サイクル実行される必要がある）
前準備
bool nb_can_put(const TA &address, const bool &vld=true)実行bool nb_put(const TD &data)
後処理
bool nb_clr_put()



ポート接続
void bind(T channel)
void operator ()(T channel)

インタフェースポートの初期化
void reset()

SystemC推奨設計メソドロジ 107© Copyright 2004-2009 JEITA, All rights reserved

4-5.メモリ読み出しの公開メンバ関数


ブロッキング関数（メモリの読み出しが終了するまで戻らない）
void get(const TA &address, TD &data, const bool &en=true)
T get(const TA &address, const bool &en=true)

ブロッキング関数（メモリの読み出しを1回だけ試み成否を返す）
bool ns_get(TD &data, const bool &en=true)

ノンブロッキング関数（毎サイクル実行される必要がある）
前準備
bool nb_can_get(const TA &address, const bool &en=true)実行bool nb_get(TD &data)
後処理
bool nb_clr_get()



ポート接続
void bind(T channel)
void operator ()(T channel)

インタフェースポートの初期化
void reset()

SystemC推奨設計メソドロジ 108© Copyright 2004-2009 JEITA, All rights reserved-286-

4-5.メモリアクセス・チャネルの公開メンバ関数とポート

チャネルのトレース
friend sc_trace(sc_trace_file*, const T&,
const std::string&)ポート
clk クロックrst リセット（負論理）// 解析用信号（検討中）

SystemC推奨設計メソドロジ 109© Copyright 2004-2009 JEITA, All rights reserved

4-5.put関数
void put(const TA &address, const TD&data, const bool &vld=true)
vldが真のときにdataを書き込む。書き込みが終了するまで次の処理に進まない。
vldが偽のときは、書き込みを行わない。vldが真のときに必要な最小クロック数だけ待って次の処理に進む。

SystemC推奨設計メソドロジ 110© Copyright 2004-2009 JEITA, All rights reserved-287-

4-5.ns_put関数
bool ns_put(const TA &address, const TD&data, const bool &vld=true)
vldが真のときにdataの書き込みを1回試みる。
成功した場合はtrueが、失敗した場合はfalseが戻る。
vldが偽のときは、書き込みを行わない。vldが真のときに必要な最小クロック数だけ待って次の処理に進む。

SystemC推奨設計メソドロジ 111© Copyright 2004-2009 JEITA, All rights reserved

4-5.nb_can_put関数
bool nb_can_put(const TA &address,
const bool &vld=true)
ノンブロッキング関数であり、クロックを含まずに処理する。
vldが偽の場合は常に偽が戻される。
vldが真でかつ書き込みがすぐ可能な場合に真が戻り、それ以外の場合は偽が戻る。

SystemC推奨設計メソドロジ 112© Copyright 2004-2009 JEITA, All rights reserved-288-

4-5.nb_put関数
bool nb_put(const TD &data)
ノンブロッキング関数であり、クロックを含まずに処理する。
データ書き込みが行われる場合に真が戻り、行われないと判断できる場合に偽が戻る。

SystemC推奨設計メソドロジ 113© Copyright 2004-2009 JEITA, All rights reserved

4-5.nb_clr_put関数
bool nb_clr_put()
ノンブロッキング関数であり、クロックを含まずに処理する。
nb_put()を実行した次のクロックサイクルでデータ書き込みを終了する場合に必ず実行する。nb_can_put(false)で代用させる事ができる。

SystemC推奨設計メソドロジ 114© Copyright 2004-2009 JEITA, All rights reserved-289-

4-5.put()のnon-blocking関数による定義
non-blocking関数は、以下の使用方法でblocking関数が作れるように実装すること。
void put( const TA &address, const TD &data, const
bool &vld=true){if(vld){while(!nb_can_put(address)) wait();while(!nb_put(data)) wait();do{wait():}while(nb_clr_put());}elsewait();}

SystemC推奨設計メソドロジ 115© Copyright 2004-2009 JEITA, All rights reserved

4-5.get関数
void get(const TA &address, TD &data, const
bool &en=true)
T get(const TA &address, const bool &en=true)
enが真のときにデータを読み出す。読み出しが終了するまで次の処理に進まない。
enが偽のときは、読み出しを行わない。enが真のときに必要な最小クロック数だけ待って次の処理に進む。
get()関数には2通りの形態があり、dataを引数として渡してそこに受信値を受け取るか、戻り値として受信値として受け取る。

SystemC推奨設計メソドロジ 116© Copyright 2004-2009 JEITA, All rights reserved-290-

4-5.ns_get関数
bool ns_get(const TA &address, TD &data,
const bool &en=true)
enが真のときにdataの読み出しを1回試みる。
成功した場合はtrueが、失敗した場合はfalseが戻る。
enが偽のときは、読み出しを行わない。enが真のときに必要な最小クロック数だけ待って次の処理に進む。

SystemC推奨設計メソドロジ 117© Copyright 2004-2009 JEITA, All rights reserved

4-5.nb_can_get関数
bool nb_can_get(const bool &en=true)
ノンブロッキング関数であり、クロックを含まずに処理する。
enが偽の場合は常に偽が戻される。
enが真でかつデータ読み出しの予約ができた
場合に真が戻り、それ以外の場合は偽が戻る。

SystemC推奨設計メソドロジ 118© Copyright 2004-2009 JEITA, All rights reserved-291-

4-5.nb_get関数
bool nb_get(TD &data)
ノンブロッキング関数であり、クロックを含まずに処理する。
データ読み出しが行われる場合に真が戻り、行われない場合に偽が戻る。nb_can_get()が真になったあと一定数のクロック後に1クロックだ
け真になる。このタイミングを逃すとnb_get()で真の戻り値を得ることができない。

SystemC推奨設計メソドロジ 119© Copyright 2004-2009 JEITA, All rights reserved

4-5.nb_clr_get関数
bool nb_clr_get()ノンブロッキング関数であり、クロックを含まずに処理する。
nb_can_get()を実行した次のクロックサイクル
で次のデータ読み出しを続けない場合に必ず実行する。nb_can_get(false)で代用させる事ができる。

SystemC推奨設計メソドロジ 120© Copyright 2004-2009 JEITA, All rights reserved-292-

4-5.get()のnon-blocking関数による定義
non-blocking関数は、以下の使用方法でblocking関数が作れるように実装すること。
void get(const TA &address, TD &data, const bool
&en=true){
if(en){
while(!nb_can_get(address)) wait();do{wait();}while(!nb_clr_get());
while(!nb_get(data)) wait();}else
wait();}

SystemC推奨設計メソドロジ 121© Copyright 2004-2009 JEITA, All rights reserved

4-5.bind関数
void bind(T channel)
void operator ()(T channel)
モジュールのポートとそのモジュールの外部のチャネルとを接続する。そのモジュールの上位モジュールのポートとの接続も可能。

SystemC推奨設計メソドロジ 122© Copyright 2004-2009 JEITA, All rights reserved-293-

4-5.reset関数
void reset()
メモリアクセスポートに関連したレジスタを初期化する。

SystemC推奨設計メソドロジ 123© Copyright 2004-2009 JEITA, All rights reserved

4-5.sc_trace関数
friend sc_trace(sc_trace_file*, const T&,
const std::string&)
vcdファイルにトレースを記録する場合に使用する。

SystemC推奨設計メソドロジ 124© Copyright 2004-2009 JEITA, All rights reserved-294-

4-5.blocking関数の使い方
blocking関数の記述は簡単。
forループの中で使われる場合が多い
sum = 0;for(address = address_min; address <address_max; ++address){
input.get(address, d_in);
sum+=din;}
SystemC推奨設計メソドロジ 125© Copyright 2004-2009 JEITA, All rights reserved

4-5.Non-blocking関数の使い方
Non-blocking関数は毎サイクル実行されなければならない。
メモリアクセスのnb_can_getとnb_getは並列に実行する。
forループの中で使われる場合が多い。
sum=0; addr=addr_min;for(sc_uint<4> i=0; i<8;){
if(mem.nb_can_get(addr, addr<addr_max)) addr++;vld = mem.nb_get(din);if(vld){++i;sum+= din;}wait();}

SystemC推奨設計メソドロジ 126© Copyright 2004-2009 JEITA, All rights reserved-295-

4-5.Non-blocking関数の使い方2
nb_can_getの第2引数enableを使用するのではなく、nb_clr_get関数によって処理を継続しないことを示した方がわかりやすいかもしれない。
sum=0; addr=addr_min;for(sc_uint<4> i=0; i<8;){
if(addr<addr_max)
if(mem.nb_can_get(addr)) addr++;vld = mem.nb_get(din);if(vld){++i; sum+= din;}wait();
mem.nb_clr_get();}

SystemC推奨設計メソドロジ 127© Copyright 2004-2009 JEITA, All rights reserved

4-5.Non-blocking関数の使い方3
メモリアクセスのnb_can_putとnb_putの使い方は、インタフェースの場合に似ている。
これもforループの中で使われることが多い。
en=true; vld=false;for(address = address_min; address < address_max; ){if(input.nb_can_get(en)) vld = input.nb_get(d_in);else vld = !en;if(vld) d_out = calc(d_in);}if(mem.nb_can_put(address, vld)){
en = mem.nb_put(d_dout);++address;}else en = !vld;
wait();
mem.nb_clr_put();

SystemC推奨設計メソドロジ 128© Copyright 2004-2009 JEITA, All rights reserved-296-

4-5.メモリアクセス・ライブラリ

モジュラーインタフェースで用意される。
mi::mi_mem_get_if<TA,TD>クラスかmi::mi_mem_put_if<TA,TD>クラスを継承している。
メモリはモジュールの外部に配置する。
１つのプロセスからgetとputをする場合
fn_sram_port<TMW> SRAMアクセスポートgetするプロセスとputするプロセスが異なる場合
fn_sram_ch<TMW> チャネル
fn_sram_ch<TMW>::mem SRAMアクセスポートgetするモジュールとputするモジュールが異なる場合
fn_sram_wr_ch<TMW> チャネル
fn_sram_wr_ch<TMW>::in SRAMリードアクセスポート
fn_sram_wr_ch<TMW>::out SRAMライトアクセスポート

getとputをするモジュールが複数ある場合

fn_sram_multi_ch<TMW, num_of_port> チャネル
fn_sram_multi_if<TMW, port_number> SRAMアクセスポート

getとputが別のチャネルにはclk（立ち上がり動作）とrst(負論理）のポートがあり、クロックとリセットの供給が必要である。
SystemC推奨設計メソドロジ 129© Copyright 2004-2009 JEITA, All rights reserved

4-5.メモリアクセス(fn_sram_port)

module_Aput（）

fn_sram
fn_sram_wrapper

fn_sram_port

process
get（）clk

SystemC推奨設計メソドロジ 130© Copyright 2004-2009 JEITA, All rights reserved-297-

4-5.メモリアクセス(fn_sram_port)

module_Aput（）

fn_sram
fn_sram_wrapper

fn_sram_port

fn_sram_port

process
get（）clk

SystemC推奨設計メソドロジ 131© Copyright 2004-2009 JEITA, All rights reserved

4-5.メモリアクセス(fn_sram_ch)

module_A

in_process
fn_sramadapter

fn_sram_wrapper

memp fn_sram_ch

put（）
mem
get（）
out_process

clk

clk

rst

SystemC推奨設計メソドロジ 132© Copyright 2004-2009 JEITA, All rights reserved-298-

4-5.メモリアクセス(fn_sram_ch)

module_A

fn_sram_wrapper

in_processadapter

fn_sramput（）

fn_sram_port

memp fn_sram_ch

mem
get（）
out_process

clk

clk

rst

SystemC推奨設計メソドロジ 133© Copyright 2004-2009 JEITA, All rights reserved

4-5.メモリアクセス(fn_sram_wr_ch)fn_sram_wrapperclk

fn_srammodule_A

module_B
memp

put（）
processout

fn_sram_wr_ch

in

get（）
process

adapterclk

rst
SystemC推奨設計メソドロジ 134© Copyright 2004-2009 JEITA, All rights reserved-299-

4-5.メモリアクセス(fn_sram_multi_ch)fn_sram_wrapperclk

fn_srammodule_A

module_B
memp

put（）
get()

fn_sram_multi_if<TMW,0>fn_sram_multi_ch<TMW,2>

fn_sram_multi_if<TMW,1>

get（）
put()

adapterclk

rst
SystemC推奨設計メソドロジ 135© Copyright 2004-2009 JEITA, All rights reserved

4-6.演算系

SystemC推奨メソドロジー 136© Copyright 2004-2009 JEITA, All rights reserved-300-

4-6.演算系ライブラリ

次の定数と演算子と関数は必ず用意する。
static const unsigned int raw_bits_len
T(const sc_uint<raw_bits_len>&)void set_raw_bits(T&, const sc_uint<raw_bits_len>&)
ビット列を与えて値を初期化
sc_uint<raw_bits_len> raw_bits(const T&)
値をビット列として取り出し// sc_uintを使わずにfn_raw_bits<ram_bits_len>クラスを用意した方が良いが、そうするとクラスの名前まで統一化することになる。
== 等値の評価<< 外部出力
const std::string to_string()
sc_trace(sc_trace_file*, const T&, const std::string&)

SystemC推奨設計メソドロジ 137© Copyright 2004-2009 JEITA, All rights reserved

4-6.値のビット列による初期化と取り出し演算系の値をsc_uint<raw_bits_len>との間で相互変換可能にする。この値は、演算系がその値を示す場合に最低限必要なビット列である。たとえば、浮動小数点であれば、指数と仮数のデー
タを並べたものである。並べ方はライブラリ依存とする。
データ保存などの演算を行わないデータ処理が共有可能になる。
合成不可能な型（たとえばdouble型など）の定数は、あらかじめビット列に変換しておいて使用する。
SystemC推奨設計メソドロジ 138© Copyright 2004-2009 JEITA, All rights reserved-301-

4-7.アルゴリズムとアーキテクチャ

SystemC推奨メソドロジー 139© Copyright 2004-2009 JEITA, All rights reserved

4-7.モジュールGCUとFUの雛形
モジュールGCUとFUの接続は、モジュラー
インタフェースgcのみとする。
 モジュールFUは、GCUとの接続gcと必要な数だけのデータ入出力とローカルコント
ロール入出力がある。これらは、すべてモ
ジュラーインタフェースである。基本的にモジュールFUは、これ以外にクロックポート
clkとリセットポートrstだけを持つ。


SystemC推奨設計メソドロジ 140© Copyright 2004-2009 JEITA, All rights reserved-302-

4-7.共有ヘッダファイル// common.hh#ifndef _COMMON_HH_#define _COMMON_HH_ 1#if SYSTEMC_VERSION <= 20050714 // 2.1.v1#include <systemc.h>#else#include <systemc>
using namespace sc_core;using namespace sc_dt;#endif#include “fn.h”
typedef sc_int<16> data_t;
typedef fn_rdyvld_ch<data_t> data_ch_t;
typedef data_ch_t::in data_in_if_t;
typedef data_ch_t::out data_out_if_t;#endif

SystemC推奨設計メソドロジ 141© Copyright 2004-2009 JEITA, All rights reserved

4-7.GCUのヘッダファイル// gcu.hh#ifndef _GCU_HH_#define _GCU_HH_ 1
class gcu : public sc_module{
public:sc_in<bool> clk;
sc_in<bool> rst;// CPU interface のポートを羅列する。
...
gc_ch::gcu gc;
void processing1();
SC_HAS_PROCESS(gcu);
gcu(const sc_module_name& name=“gcu”);};#endif
SystemC推奨設計メソドロジ 142© Copyright 2004-2009 JEITA, All rights reserved-303-

4-7.GCUのソースファイル// gcu.cc#include “common.hh”#include “gc_ch.hh”#include “gcu.hh”
void gcu::processing1(){
if(!rst){// 初期化処理}else{// 動作}}
gcu::gcu(const sc_module_name& name):
sc_module(name),clk(“clk”),rst(“rst”), ..., gc(“gc”){
SC_METHOD(processing1); // processing1はRTL
sensitive << clk.pos() << rst.neg();}

SystemC推奨設計メソドロジ 143© Copyright 2004-2009 JEITA, All rights reserved

4-7.FUのヘッダファイル// fxxx.hh#ifndef _FXXX_HH_#define _FXXX_HH_ 1
class fxxx : public sc_module{
public:sc_in<bool> clk;
sc_in<bool> rst;
gc_ch::fu1 gc;
lc_ch::out lc;
data_in_if_t din;data_out_if_t dout;
void processing1();
SC_HAS_PROCESS(fxxx);
fxxx(const sc_module_name& name=“fxxx”);};#endif

SystemC推奨設計メソドロジ 144© Copyright 2004-2009 JEITA, All rights reserved-304-

4-7.FUのソースファイル// fxxx.cc#include “common.hh”#include “fxxx.hh”
void fxxx::processing1(){// 初期化処理
wait();
while(true){
// 動作
}
}
fxxx::fxxx(const sc_module_name& name) :sc_module(name), clk(“clk”), rst(“rst”),
gc(“gc”), lc(“lc”), din(“din”), dout(“dout”) {SC_CTHREAD(processing1, clk.pos()); // processing1はBL
reset_signal_is(rst, false);}

SystemC推奨設計メソドロジ 145© Copyright 2004-2009 JEITA, All rights reserved

4-7.モジュラインタフェースgcまたはlc// gc_ch.hh#ifndef _GC_CH_HH_#define _GC_CH_HH_ 1#include “common.hh”
class gc_gcu_port;
class gc_fu1_port;
class gc_fu2_port;
class gc_ch : public sc_object{
public:sc_signal<ttt1> sss1; // tttnは型名で、sssnは信号名で置き換える。
sc_signal<ttt2> sss2;
sc_signal<ttt3> sss3;
typedef gc_gcu_port gcu;
typedef gc_fu1_port fu1;
typedef gc_fu2_port fu2;
friend void sc_trace(sc_trace_file* tf, const gc_ch &ch, const std::string& str){
sc_trace(tf, ch.sss1, str+”.sss1”);
sc_trace(tf, ch.sss2, str+”.sss2”);
sc_trace(tf, ch.sss3, str+”.sss3”);}gc_ch(const char* name=“gc_ch”):sc_object(name),sss1(“sss1”),sss2(“sss2”),sss3(“sss3”){};};

SystemC推奨設計メソドロジ 146© Copyright 2004-2009 JEITA, All rights reserved-305-

4-7.モジュラインタフェースgcまたはlc(続き)class gc_gcu_port : public sc_object{
public:sc_out<ttt1> sss1;
sc_in<ttt2> sss2;
sc_in<ttt3> sss3;
void bind(gc_ch &ch){
sss1(ch.sss1);
sss2(ch.sss2);
sss3(ch.sss3);}
void operator ()(original_gc_ch &ch){ bind(ch); }gc_gcu_port(const char* name=“gc_gcu_port”) :sc_object(name),sss1(“sss1”), sss2(“sss2”), sss3(“sss3”){};};
SystemC推奨設計メソドロジ 147© Copyright 2004-2009 JEITA, All rights reserved

4-7.モジュラインタフェースgcまたはlc(続き)class gc_fu1_port : public sc_object{
public:sc_in<ttt1> sss1;
sc_out<ttt2> sss2;
void bind(gc_ch &ch){
sss1(ch.sss1);
sss2(ch.sss2);}
void operator ()(gc_ch &ch){ bind(ch); }gc_fu1_port(const char* name=“gc_fu1_port”) :sc_object(name),sss1(“sss1”), sss2(“sss2”){};};

SystemC推奨設計メソドロジ 148© Copyright 2004-2009 JEITA, All rights reserved-306-

4-7.モジュラインタフェースgcまたはlc(続き)class gc_fu2_port : public sc_object{
public:sc_in<ttt1> sss1;
sc_out<ttt3> sss3;
void bind(gc_ch &ch){
sss1(ch.sss1);
sss3(ch.sss3);}
void operator ()(gc_ch &ch){ bind(ch); }gc_fu2_port(const char* name=“gc_fu2_port”) :sc_object(name),sss1(“sss1”), sss3(“sss3”){};};#endif
SystemC推奨設計メソドロジ 149© Copyright 2004-2009 JEITA, All rights reserved

4-8.その他のHW設計について

SystemC推奨メソドロジー 150© Copyright 2004-2009 JEITA, All rights reserved-307-

4-8.HW/SW分割後のシステム
Memory Mapped Bus

CPU

Memory
I/F

I/O

H/W
ブロック

HW設計の初期段階では、外部
I/O等のペリフェラルは一つのtargetとして表現されている

SW

MemorySystemC推奨設計メソドロジ 151© Copyright 2004-2009 JEITA, All rights reserved

4-8.HWプラットフォームの詳細化
Memory Mapped Bus

CPU

MemoryI/F

USB UART

Ether
SATA
Mac

H/W
ブロック

ペリフェラル部を、システムで使用するIPモデルとしてSystemCで作成する
SW with
デバイスドライバ

MemorySystemC推奨設計メソドロジ 152© Copyright 2004-2009 JEITA, All rights reserved-308-

4-8.HWプラットフォームの詳細化

外部I/O等のペリフェラルは、HW設計初期段階では、一つのTargetモジュールとして表現されているHWを詳細化を進めるにあたり、一つのTargetモジュールを、具体的なインタフェースIPのモデルに置き換えていく


各IPのアドレス空間（レジスタ割付）を行う
想定されるレイテンシの設定を設定する（必要であれば）IP内部でのデータ処理を実装する

これらのIPモデルは主に低レベルSW（デバイスドライバ
開発）用のプラットフォームに用いられる
 これらのIPモデルは、最終的に等価なRTLのIPと置き換えることを想定している


動作合成の対象外になる

SystemC推奨設計メソドロジ 153© Copyright 2004-2009 JEITA, All rights reserved

4-8.ペリフェラルのRTL検証環境
Memory Mapped Bus

CPU

SW

MemoryI/F

アダプタ

USB UART

SATA

H/W
ブロック

Ether
Mac
(RTL)

MemorySystemC推奨設計メソドロジ 154© Copyright 2004-2009 JEITA, All rights reserved-309-

4-8.ペリフェラルのRTL検証環境
動作合成により作られるブロック、及びペリ
フェラルIP部の検証環境として、詳細化されたHWプラットフォームを流用できる
 RTLを検証する場合、HWプラットフォームとRTLを接続する為のアダプタを用意する
 またSystemCで作成した各IPモデルは、RTL単体検証時のリファレンスモデルとしても流用できる

その場合はモデルの詳細な機能実装が必要
SystemC推奨設計メソドロジ 155© Copyright 2004-2009 JEITA, All rights reserved

5.検証

SystemC推奨メソドロジー 156© Copyright 2004-2009 JEITA, All rights reserved-310-

5-1. 内容
１．内容
２．本章の位置付け
３．検証対象
４．検証内容５．検証方法1
６．検証方法2
７．今後の検討事項・課題

SystemC推奨設計メソドロジ 157© Copyright 2004-2009 JEITA, All rights reserved

5-2．本章の位置付け
本章の範囲（SW部分の検証は範疇外）

システム設計
HW設計部分

動作記述

検証（SystemC）

動作合成
RTL記述

検証

（Verilog、VHDL）

SystemC推奨設計メソドロジ 158© Copyright 2004-2009 JEITA, All rights reserved-311-

5-3．検証対象
新規にHW設計する部分
 HW設計の手法としては、動作合成利用を想定

動作記述（SystemC）
通信はサイクル精度
 機能はUntimed

機能





RTL記述（Verilog、VHDL）


入出力



動作記述

サイクル精度Untimed

動作合成で合成したもの

SystemC推奨設計メソドロジ 159© Copyright 2004-2009 JEITA, All rights reserved

5-4．検証内容

動作記述を十分に検証し、RTLでのみ検証可能な項目のみRTL記述を検証する。


RTLでは動作確認が基本。

検証内容

動作記述

イ ン タ フ ェ ー ス○

メ モ リ ア ク セ ス○

演算系（ユーザ定義型）○

ア ル ゴ リ ズ ム

○

階

層

構

造

○

性

能

制

約

RTL記述（追加検証）○

パイプライン・ストール等動作記述で表現できないもの○

レイテンシ、スループット
SystemC推奨設計メソドロジ 160© Copyright 2004-2009 JEITA, All rights reserved-312-

5-5．検証方法


シミュレーション


動作記述




HW化
対象

SystemCシミュレーション

RTL記述




トランザクション
レベル

TL環境

SystemC + Verilog/VHDL TL環境
混在シミュレーション

ピンレベル

動作
記述

テスト環境の再利用
TL環境の利用 ファームウェアの利用


アダプタ

動作合成

TL環境

アダプタ

RTL
記述

SystemC推奨設計メソドロジ 161© Copyright 2004-2009 JEITA, All rights reserved

5-6．検証方法


RTL記述の検証


抽象度の詳細化に伴いテストケース追加
テスト
ケース
追加

TL環境

アダプタ

RTL
記述
もしくは

テスト
ケース
追加

RTL環境
RTL
記述

SystemC推奨設計メソドロジ 162© Copyright 2004-2009 JEITA, All rights reserved-313-

5-7．今後の検討事項・課題


複数モジュールに分割実装後のテスト
動作合成利用時はアルゴリズム記述を複数モジュー
ルに分割するケースが多い。
⇒ モジュール毎のテストケースと期待値の準備に手間
が掛る





検証の品質
RTL検証での品質指標の一つにカバレッジがある。
⇒ 高位設計でも良い指標となるか?





等価性検証
RTL 対 ゲートレベル では実用化⇒ SystemC 対 RTL では適用範囲がまだ狭い

SystemC推奨設計メソドロジ 163© Copyright 2004-2009 JEITA, All rights reserved

6.モデリング（高速化）

SystemC推奨メソドロジー 164© Copyright 2004-2009 JEITA, All rights reserved-314-

6-1. モデリング（高速化）のポイント必要となる（実装すべき）機能の明確化

機能検証？性能検証？動作合成？

適切なモデル抽象度



時間概念必要？ サイクル精度必要？

I/Fのトランザクション化

OSCI TLM2.0の活用

イベントドリブン（処理のポーリングは行わない）



コンテキストスイッチを極力減らすモデリング

動的な抽象度の切り替え

観測ポイントに達するまで高速シミュレーション

処理が重くなるコーディングを避ける

コピーでなくポインタ使用、動的アロケーションを減らす
SystemC推奨設計メソドロジ 165© Copyright 2004-2009 JEITA, All rights reserved

6-2.必要となる（実装すべき）機能の明確化


モデルの使われる用途/開発フェーズに応じ実装対象を検討

機能検証用途時間の概念は組込まない
 計算で概略時間を求める


性能検証用途タイミングだけを合わせ込んで、機能の実装を端折る
 トラフィックジェネレータなど


動作合成用途モデリングの高速化を行う上ではターゲット外
SystemC推奨設計メソドロジ 166© Copyright 2004-2009 JEITA, All rights reserved-315-6-3. 適切なモデル抽象度


用途に応じ適切な抽象度を選ぶ（STARCのTLモデリングガイド参照）


UTTR (Unitimed + Transaction)
機能モデル設計・検証、通信量・計算量見積り
 先行SW機能設計・検証

ATTR/ATBP (Approximately-timed + Transaction/Bus Phase)
共有リソース競合検証、HW/SW分割・検証
 先行SWタイミング設計・検証
 プロセッサ必要性能検証、バス・メモリアーキ設計・検証

CABC (Cycle-accurate + Bus Cycle)

HW機能モデルのサイクル精度レベルでの設計・検証

SystemC推奨設計メソドロジ 167© Copyright 2004-2009 JEITA, All rights reserved

6-4. I/Fのトランザクション化


データ転送単位、I/Fの単純化


OSCI TLM2.0の活用
２つのコーディングスタイル
LT(Loosely-timed)では、Blocking APIを使用→ b_transport
AT(Approximately-timed)では、Non-blocking APIを使用→ nb_transport_fw、nb_transport_bw
 Generic Payload
バスを介したモデル間で通信を行うトランザクションの共通定義
 Generic Phase
BEGIN_REQ、END_REQ、BEGIN_RESP、END_RESPの４フェーズ
 Temporal Decoupling
モデルがローカル時間を持ち、グローバル時間に先行して実行する
グローバル時間への同期回数を減らすことでSim速度を高速化する
 DMI (direct memory interface)
メモリへのポインタにダイレクトにアクセスし、Sim速度を高速化する
 Debug Transaction Interface
SystemC推奨設計メソドロジ 168© Copyright 2004-2009 JEITA, All rights reserved-316-

6-5. イベントドリブン（処理のポーリングは行わない）


無駄にコンテキストスイッチを起こさず、最小限のイ
ベントドリブンに留める（処理のポーリングは行わない）
TLM2.0のPEQを利用

TLM1.0を使ったクロックベース
でのポーリング
void Target::get_process() {while (1) {while (!port->nb_get(req) == false) {wait(clk.posedge_event());}
if (req.get_addr() == REG1) {・・・

Target::Target(sc_module_name name): sc_module(name) {SC_THREAD(get_process);sensitive << m_peq.get_event();
dont_initialize();・・・}
void Target::get_process() {while (1) {ptr = m_peq.get_next_transaction();・・・
sock->nb_transport_bw(ptr, phase, delay);
・・・
SystemC推奨設計メソドロジ 169© Copyright 2004-2009 JEITA, All rights reserved

6-6. 動的な抽象度の切り替え


OSのブートが完了するまでは抽象度の高い（時間精度の低い）高速シミュレーションを行い、観測したいポ
イントに達してからは抽象度の低い（時間精度の高い）低速シミュレーションに切り替える
 TLM2.0では、シミュレーション中に動的に抽象レ
ベルの切り替えが可能な枠組みを提供
LT（高速・抽象レベル高・時間精度低）AT（低速・抽象レベル低・時間精度高）
SystemC推奨設計メソドロジ 170© Copyright 2004-2009 JEITA, All rights reserved-317-

6-7. 処理が重くなるコーディングを避ける

処理速度の高速化ノウハウ
 sc_intなどのSystemC型は使わずに、int型などの
ANSI C整数型を使用
 データコピーをせず、ポインタ・参照渡しを用いる
 メモリ領域の動的な生成・解放を減らす
 オペレータのオーバーロードを用いない
 処理の重い条件式は後置にする

コンパイル速度の高速化ノウハウ
ヘッダファイルのインクルードを途中で切る
 テンプレートを多用しない

SystemC推奨設計メソドロジ 171© Copyright 2004-2009 JEITA, All rights reserved

6-8. より良いモデリングを目指して


再利用性向上 (STARCのTLモデリングガイドより)通信インタフェースの共通化
 計算機能と通信機能を明確に分離したモデル構成


特定の通信APIコール(ベンダツールのAPI等)

計算
機能

通信
機能

共通の通信APIコール(TLM2.0のAPI等)

計算・通信
計算・通信
機能
機能

推奨できないモデリング推奨できるモデリング
SystemC推奨設計メソドロジ 172© Copyright 2004-2009 JEITA, All rights reserved-318-

7. その他

SystemC推奨メソドロジー 173© Copyright 2004-2009 JEITA, All rights reserved

7-1.概要ここでは、主に設計工程にまたがって考慮するべきトピッ
クス、他のカテゴリに当てはまらないトピックスを集めた。
 具体的には以下について説明を行っている。






ECO
配線性の考慮
フォルスパス

SystemC推奨設計メソドロジ 174© Copyright 2004-2009 JEITA, All rights reserved-319-

7-2.ECO

動作合成を前提としたECOの課題






RTLの可読性が低く、人手修正が困難。
動作記述とRTLの対応が1対1ではない。
動作記述の修正が微少であっても生成されるRTLの差分が大きい。

対応




マイナーなタイミング修正を除いては、基本的にECOは、動作記述の修正で行う。
→ 問題を把握しやすく、修正ミスを防ぐことができる。
→ 動作記述を設計資産とする。
等価性検証を使用する場合は、検証を行ったコードをリファレンスとする。
動作記述#0

ECO対応
修正

動作記述#1

機能検証

機能検証

動作合成

動作合成再実行

RTL#0

RTL#1

ECO

C-RTL等価性検証

RTL-RTL等価性検証

RTL#0’

SystemC推奨設計メソドロジ 175© Copyright 2004-2009 JEITA, All rights reserved

7-3.配線性の考慮


動作合成を前提とした配線性の課題


自動リソースシェアリングの結果、ロジックコーンが巨大化し、レイアウト時に問題になる場合がある。

対応

動作合成ツールのレポートや、RTLチェックツール等により、ロジックコーンの大きさを確認しておく。
問題がある場合は、動作合成実行時に制約を指定するか、コードの修正を行う。

＋

演算器の
共有化

＋

＋

SystemC推奨設計メソドロジ 176© Copyright 2004-2009 JEITA, All rights reserved-320-7-4.フォルスパス


動作合成を前提とした設計おけるフォルスパスの課題


動作合成ツールのリソースシェアリングの結果、False Pathが発生する場合があり、後工程で問題になる場合がある。

対応




要求性能を満たす範囲で、フォルスパスが発生しないよう、動作合成ツールに対する制約を設定する。
フォルスパス・スクリプトを利用する場合は、別途妥当性をチェックするためのツールを利用し、確認を行うこと。

A

C

B

D

FSM

＋

A
B
C
D

＋

＋

＋
演算器の共有によるFalse Pathの例
SystemC推奨設計メソドロジ 177© Copyright 2004-2009 JEITA, All rights reserved-321-4.2.6 SystemCユーザフォーラム2009
開催報告© Copyright 2009 JEITA, All rights reserved

1

SystemCユーザフォーラム2009の概要

主催：JEITA EDA技術専門委員会
協賛：OSCI
日時：2009年1月23日 10:00～12:00
会場：パシフィコ横浜アネックスホール (定員200名)
参加者数：123名(申し込み者数：127名)



講演内容：








司会




SystemCコミュニティの最新状況

吉永 和弘 氏( (株)半導体理工学研究センター)

事例#1 画像処理IP開発への高位設計適用事例


SystemCワーキング・グループ

STARC TLモデリングガイドの紹介

Stanley.J.Krolikoski 氏 (OSCI)

SystemC推奨設計メソドロジの紹介

長谷川 隆 氏 (SystemC-WG主査/富士通マイクロエレクトロニクス(株))浅野 哲也 氏 ( (株)ルネサス テクノロジ)

事例#2 TLM2.0を利用した大規模回路設計


長谷 川裕恭 氏 ((株)エッチ・ディー・ラボ)© Copyright 2009 JEITA, All rights reserved

2

-322-

SystemCユーザフォーラム2009開催の目的


本年度のSystemCユーザフォーラムは、SystemCの普及を目的として以下の方針の下で実施した。



SystemCユーザへのOSCI活動状況を報告する事。
JEITA SystemC WG活動内容を紹介し、活動実績を発表する事。
SystemCに関する国内の活動、適用事例を紹介し、ユーザへ普及の現状をアピールする事。

© Copyright 2009 JEITA, All rights reserved

3

SystemCユーザフォーラム2009サマリー


講演について

２時間で5講演を実施。OSCI、JEITA SystemC WG、及びSTARCによる報告、
SystemC適用事例2件と充実した内容であったが、時間的にはやや不足気味であった。
質疑応答も活発に行われた(7件)。

講演内容：









OSCIからは標準化活動の状況について説明がなされた。（20分）。
JEITA SystemCからは、SystemC推奨設計メソドロジの概要の紹介、TLM
2.0に関する補足説明を行った（20分）。
STARCの吉永氏からは、TLモデリングの概要とその必要性、そして公開されたばかりのTLモデリングガイドライン第2版の紹介があった（20分）。
ユーザ事例としては、ルネサステクノロジの浅野氏から、SystemC記述を用いた高位設計環境の紹介があった。（30分）。
同じくユーザ事例としてエッチ・ディー・ラボの長谷川氏からは、同社で実際に行われている SystemCを用いた大規模回路設計について紹介された。
（30分）。

© Copyright 2009 JEITA, All rights reserved

4

-323-

SystemCユーザフォーラム2009サマリー


会場状況・予稿集について

本年のフォーラム参加人数は昨年の172名から123名と大幅に減少し、目標
人数150名を達成できなかった。ただし、厳しい経済状況を考慮すれば、それでも十分に高い数字であり、SystemCへの興味が依然高いことを表していると考えられる。
参加者減少の他の要因としては、昨年度はTLM2.0の発表直後に開発担当者がチュートリアルを行うという、タイムリーな内容であったのに対し、今年度は大きなイベントもなく、アップデート的な内容、事例紹介が中心だった点が挙げられる。
全体の満足度(満足+やや満足)は昨年よりは低い結果となったが、満足だ
けみると増加している。参加人数が少ない分、はっきりした目的を持った参加者が多かったのかもしれない。来年度以降開催の際には、フォーラムの位置づけも見直す必要があるものと思われる。

© Copyright 2009 JEITA, All rights reserved

5

SystemCユーザフォーラム2009サマリー
アンケートからのフィードバック

ユーザフォーラムについて

システムレベル言語の動向を知る貴重な機会としていつも参考にしております
ぜひ、来年度も開催してほしいです

運営について

後の予定があるので、終了時間はオーバーしないで欲しい
セミナー中にスタッフが動き回るな
カメラのフラッシュで目が痛い© Copyright 2009 JEITA, All rights reserved

6

-324-

アンケート調査集計結果


昨年度とほぼ同様の内容（但し一部新規項目が追加されている）でアン
ケートを実施し、昨年度までの結果と合わせて聴講者の動向を分析。
今年度はSystemCの利用経験がない方の参加が多かった。
過去のアンケートで、SystemCを利用しない理由としては、「HDLで十分」「言語の完成度が低い」等の回答があったが、今回のアンケートでは、これらが大幅に減少する一方で、 「効果が不明」 「検討する時間がない」といった理由が多く挙がった。これは、SystemC-WGで開発中の推奨設計メソドロジが貢献できるものと期待している。
TLMの標準化が一段落したこともあり、標準化に対する興味よりは、適用事例に期待して参加する方が多かった。
有料開催については、8割の参加者が問題ないとしている(昨年とほぼ同等)。








© Copyright 2009 JEITA, All rights reserved

7

0. 申込者属性
エンジニアの中心は
３０代～４０代


年代

2009年

2008年

不明
5名(3%)

50代以上(18
名)
14%

10代
0名(0%)

50代以上
13名(8%)
40代
49名(28%)不明
0%

10代(0名)0%
20代(18名)
14%

20代
21名(12%)40代(38名)
30%

30代
84名(49%)172名(100%)

30代(53名）
42%

113名(100%)© Copyright 2009 JEITA, All rights reserved

8

-325-

1. 本フォーラムを何で知りましたか？

今年度は案内パンフレットが少なかったため、e-mailが増加

2009年

2008年
取引先より
1名(1%)

無回答
7名(5%)

取引先より(3名)
3%同僚より(8名)
7%

案内パン
フレット
45名(31%)

無回答(6名)5%

案内パンフレット
(18名)
16%

同僚より
24名(17%)
上司より(22名)
19%

上司より18名(13%)

案内FAX(0名)0%

案内E-mail
49名(33%)

案内FAX
0名(0%)

案内E-mail(56名)
50%

132名(100%)

113名(100%)© Copyright 2009 JEITA, All rights reserved

9

2. 本セッションの内容について(1/2)


満足/やや満足が減少
満足だけみると増加

内容は期待通りでしたか。

2008年

無回答
不満

9. 7 %

満足

2009年
不満(1名)
1%

17 . 4%や や 不 満 0. 0 %9. 7 %

無回答(17名)
15%
満足(29名)26%

やや不満(18
名)
16%

やや満足

144名(100%)

やや満足(48名)
42%

113名(100%)

6 3 .2 %予稿集の内容は期待通りでしたか？

2008年
不満
1名(1%)

無回答
14名(10%)満足/やや満足が減少
満足だけみると増加

2009年

無回答(16名)
14%

満足
27名(19%)不満(1名)
1%

満足(33名)29%

やや不満(16名)
14%

やや不満
16名(11%)

やや満足
86名(59%)144名(100%)

113名(100%)© Copyright 2009 JEITA, All rights reserved-326-

やや満足(47名)
42%

10

2. 本セッションの内容について(2/2)


内容は業務に役立ちますか？

2008年

2009年
無回答
13名(9%)

不満
0名(0%)

無回答16%

満足
31名(22%)

満足(29名)
26%

不満(2名)
2%

やや不満
19名(13%)

チュートリアル中心だった
昨年に比べると、今年はUpdate的内容、事例中心であったため、業務への直接的な貢献は減っている。

やや不満(20
名)18%
やや満足
81(56%)

113名(100%)

144名(100%)

やや満足(44
名)
38%

講演時間

2008年

2009年

多少改善されたが、短いという回答が多い。発表5
件は多かったかもしれない。

無回答(15名)
13%

無回答
14(10%)

短い(15名)13%

短い
33名(23%)長い(5名)
4%

適切
91名(63%)長い
6名(4%)

適切(78名)
70%

113名(100%)

144名(100%)© Copyright 2009 JEITA, All rights reserved

11

3. ご担当業務またはビジネスは?

SOC/System設計・検証が減少傾向

ご担当業務またはビジネスは？

SOC/System設計・検証
IP・Block設計・検証
ﾒｿﾄﾞﾛｼﾞｰ・設計ﾌﾟﾗｯﾄﾌｫｰﾑ開発
ﾂｰﾙ開発(含むEDA関連業務)

2009
2006
2008
2007
2007
2008
2006
2009

ﾌﾟﾛｼﾞｪｸﾄ管理
ｿﾌﾄｳｪｱ・ﾌｧｰﾑｳｪｱ開発
ｼｽﾃﾑ仕様・方式検討
ｺﾝｻﾙﾃｨﾝｸﾞ・ﾄﾚｰﾆﾝｸﾞ
大学・研究機関関連
その他
0%

10%

20%

© Copyright 2009 JEITA, All rights reserved

30%

40%

50%

60%

12

-327-

4. 担当されている製品アプリケーションは?
担当されている製品アプリケーションは？
Micro Processor/DSP関連
Computer
System/Subsystems関連

マルチメディア関連が例年通り多いWired Network関連

2009
2006
2008
2007
2007
2008
2006
2009

Wireless Network関連
Multimedia関連
Automotive関連
その他
0%

10%

20%

30%

40%

© Copyright 2009 JEITA, All rights reserved

13

5. 現在主に使用している言語は?
現在主に使用している言語は？（複数回答可）

VeriogHDL
VHDL
SystemC

2003
2004
2005
2006
2007
2008
2009

ANSI CC++e
Vera
SystemVerilog
SVA
PSL/Sugar
その他
0%

5%

10%

15%

20%

25%

30%

35%

40%

VerilogHDLがメインだが、全体としては減少傾向。
C設計は微増。SystemVerilogが着実に伸びている。
© Copyright 2009 JEITA, All rights reserved

14

-328-

6. SystemCユーザフォーラムに参加された目的は?
今回SystemCﾕｰｻﾞｰﾌｫｰﾗﾑに参加された目的は？（複数回答可）

SystemC導入検討
SystemC標準化動向

2009
2006
2008
2007
2007
2008
2006
2009

SystemC開発情報
ﾕｰｻﾞｰ事例
EDA技術動向
その他
0%

5%

10%

15%

20%

25%

30%

35%

40%

フォーラムのプログラムが設計メソドロ
ジやユーザ事例がメインだったため？

© Copyright 2009 JEITA, All rights reserved

15

７. SystemCの利用度について
SystemCの利用度について非常に良く理解した上で頻繁に利用する
よく利用する2009

2006

時々利用する2008
2007

利用した事が無い

2007
2008

2009
2006

無回答
0%

5% 10% 15% 20% 25% 30% 35% 40%

今回は新規ユーザが多かった© Copyright 2009 JEITA, All rights reserved

16

-329-

8. SystemCでの設計･検証環境構築について
SystemCでの設計・検証環境構築について既に行っている

既に行っている（一部）

2009
2006
2008
2007
2007
2008
2006
2009

検討中

必要ない

新規ユーザが多いため、「既に行っている」が減少、「検討中」が増えている。

無回答
0%

10%

20%

30%

40%

50%

60%

「必要ない」は人数的にも増えている。

© Copyright 2009 JEITA, All rights reserved

17

9. 「8」で「既に行っている」または「検討中」と回答された方a) SystemCの使用目的は?
a）SystemCの使用目的は？（複数回答可）

仕様検討が増加、システ
ムモデリングが減少。

仕様検討
システムモデリング
ソフトウェア開発

2009
2006
2008
2007
2007
2008
2006
2009

機能検証用ﾘﾌｧﾚﾝｽﾓﾃﾞﾙ開発
テストベンチ・検証
ハードウエア実装
その他
0%



5%

10%

15%

20%

25%

30%

35%

40%

45%

2008年に項目を追加した段階で、システ
ムモデリング、テストベンチ・検証が依然から大きく減少、目的が大きく変わったためではないと推測。

その他

トレーニング
研修で© Copyright 2009 JEITA, All rights reserved

18

-330-

9. 「8」で「既に行っている」または「検討中」と回答された方b) SystemCの活用範囲は?
b）SystemCの活用範囲は？（複数回答可）

システムレベルよりはモ
ジュールレベルでの適用に落ち着きつつある。

システム（チップ）レベル
2003
2004
2005
2006
2007
2008
2009

モジュール（ブロック）レベル

その他

0%

10%

20%

30%

40%

50%

60%

© Copyright 2009 JEITA, All rights reserved

19

9. 「8」で「既に行っている」または「検討中」と回答された方c) 設計・検証の抽象度は？
アルゴリズムレベル、トランザク
ションレベルの減少は、ビヘイビ
アレベルの追加によるものか、
本当に減っているのかは不明？

設計・検証環境の抽象度は？

アルゴリズムレベル(2007年はUntimedレベル)
トランザクションレベル(次頁詳細参照)

2009
2006
2008
2007
2007
2008
2006
2009

ビヘイビア・レベル(動作合成用)
RTL
その他
0%

10%

© Copyright 2009 JEITA, All rights reserved

20%

30%

40%

50%

60%

20

-331-

9. 「8」で「既に行っている」または「検討中」と回答された方c) 設計・検証の抽象度は(トランザクションレベルの詳細)？
設計・検証環境の抽象度は？（トランザクションレベルの抽象度）

UntimedLoosely-timed
2009
2006
2008
2007
2007
2008

Approximately-timed

2006
2009

サイクル精度
その他
0%

5%

10%

15%

20%

25%



35%

40%

メインは抽象度の高いレベルであるが、サイクル精度も多い。

２００７年度はPV(Untimed)/PVT(Loosely Timed)/CA(サイクル精度)の分類
2008年度はUntimed/サイクル精度/その他の分類

30%© Copyright 2009 JEITA, All rights reserved

21

9. 「8」で「既に行っている」または「検討中」と回答された方d) どのようなトランザクションAPIを使用していますか？

使用しているAPI

OSCI TLM(1.0, 2.0)
ベンダー提供API

2009
2006
2008
2007
2007
2008
2006
2009

独自API
その他
無回答
0%



5%

10%

15%

20%

その他

SystemCをツール間のインターフェースとして使用C←→Verilog

検討のみ、使用していない© Copyright 2009 JEITA, All rights reserved

25%

30%

35%

40%

独自APIが強いのはなぜ？

22

-332-

10. 「8」で「検討中」と回答された方へ
導入予定時期は?

現状導入が明確な人は少ない導入予定時期は？

3ヶ月以内

6ヶ月以内

2009
2006
2008
2007
2007
2008
2006
2009

1年以内

未定

無回答
0%

10%

20%

30%

40%

50%

60%

70%

80%

© Copyright 2009 JEITA, All rights reserved

23

11. 「8」で「必要ない」、「検討中」と回答された方へ導入の障害となっている理由は?
導入の弊害となっている理由は何ですか？
傾向の変化が、項目を増やしたことによるものなのか、実際に問題が解消されてきたことによるのかは判断できない。
現状HDLで十分
言語の完成度が不十分
対応ツールが少ない
他の言語を使用

2009
2006
2008
2007
2007
2008
2006
2009

習得が困難
検討時間がない
効果が不明
ツールが高価担当業務で利用場面がない
その他
0%

5%

10%

15%

20%

25%

30%

35%

HDLでは不十分、言語の完成度はOKとした
上で、導入に踏み切れない方が多いのは問
題。


その他

MATLABの方が優れている。

営業なので© Copyright 2009 JEITA, All rights reserved

24

-333-

12. SystemCをより活用する為に充実が必要なものは？
高位（動作）合成ツール
I/F合成ツール
システム検証（解析）ツール
等価性・プロパティチェックツール
デバックツール・環境
検証IP・モデル
ソフトウェア開発環境との連携
バックエンド実装への自動化
シミュレーション高速化
SW/HW分割の自動化
コーディングスタイルガイドライン
IEEEやIECでの標準化
他の言語のリンク
トレーニングコース
その他
0%


2009
2006
2008
2007
2007
2008
2009
2006

5%

10%

15%
20%
25%
デバッグツール・環境、高速化が挙がっているのは実際に運用されているため？
高位合成、等価性・プロパティチェックが減少
傾向なのはなぜ？

その他

価格削減

導入用（勉強用）のフリーツールの普及Modular I/F記述スタイルの標準化
検証機能
情報共有（ネット上等）コンパイルエラーのメッセージをもっと判りやすくする。

ツールコストの削減（工数の削減コスト＞ツール導入コストにならないと難しい）

他の言語のリンク
VHDL、SystemVerilog、e© Copyright 2009 JEITA, All rights reserved

25

13. 今後SystemCの言語拡張･標準化で期待することは?
今後SystemCの言語拡張・標準化で期待することは？（複数回答可）

動作合成サブセットに対する期待が下がっているのは何故？

データパス設計の容易化、
HW/SW間のI/Fが増加

動作合成サブセット定義
論理合成サブセット定義
データパス設計の容易化

2009
2006
2008
2007
2007
2008
2006
2009

テストベンチﾊｰﾄﾞｳｪｱ・ｿﾌﾄｳｪｱ間のｲﾝﾀｰﾌｪｰｽ
モジュール間の標準プロトコル
トランザクションレベルモデルの標準化
アナログのモデリング
その他
0%


5%

10%

15%

その他

アサーションーライブラリ

入力物理現像のシミュレーション出来ない。

カバレッジで、アサーションで不検証Modular I/F記述スタイルの標準化（HLSとシステム検証のシームレスな接続に必要
ツールやモデルの導入容易化
Sampleの充実© Copyright 2009 JEITA, All rights reserved

20%

25%

30%

トランザクションレベルモデリン
グは、標準化が一段落したため、
減少。
26

-334-

14. 今後Open SystemC Initiative（OSCI）やJEITAに期待する活動は？
今後Open SystemC Initiative（OSCI）やJEITAに期待する活動は？（複数回答可）

ｾﾐﾅｰ・ﾜｰｸｼｮｯﾌﾟの定期的開催
日本語による情報発信

2009
2006
2008
2007
2007
2008
2006
2009

国内でのワーキングGp活動
ユーザーの意見・提案の標準化への反映
その他
0%



5%

10%

15%

20%

その他

マーケットの要求に応えられる。SystemCの必要性、有意性の確認

25%

30%

35%

40%

45%

大きな変化なし© Copyright 2009 JEITA, All rights reserved

27

15.有料開催についてはどう思われますか？
有料開催についてはどう思われますか？

有料であっても内容次第

有料でも参加する

有料でも内容次第で参加する

2009
2006
2008
2007
2007
2008
2006
2009

無料の場合のみ参加する

参加しない

無回答
0%

10%

20%

30%

© Copyright 2009 JEITA, All rights reserved

40%

50%

60%

70%

80%

28

-335-

その他コメントSystemCの進展は、C設計がさけばれはじめている頃から注意してみていたが、ほとんど進展が見られないように感じる。メリットや、工数削減効果に対して、全体的な検証が不充分ではないか？例えばツール費用が高くて導入が容易にできなかったり、モデルが不充分で、実質的な工数が削減できないなど前から変わってないように思える。



等価性（SystemCとRTL）チェック後にもRTLの検証が必要となり、それほど工数が減らないように感じる。そのあたりも今後事例で説明して頂きたい。



システムレベル設計で、記述したCレベル（SystemCでも）から高位合成を行って早い段階
でFPGAの様な物で、評価を行いたい（画像処理のアプリケーションでは、シミュレーション
だけでは、アルゴリズム評価が不充なため）、こういったツールのフローが確立されると良
いと思う。





FPGAベンダーのEDAツールにSystemC開発モデル／フローを導入して欲しい。これらのツールが広まれば汎用のSystemC開発ツールも広まっていくと思う。
OSCIベースのSystemC開発を行うとき、Compile Errorなどを分かりやすくする方法が欲し
いと思います。特にRTL設計者が、C＋＋経験が少ない技術者、SystemCを学ぶとき、その部分が、大きなネックとなっています。

© Copyright 2009 JEITA, All rights reserved

29

-336-

4.3 SystemVerilog ﾜｰｷﾝｸﾞｸﾞﾙｰﾌﾟ報告 添付資料
SVTG-1 IEEEp1800-2009 Issue List
了承

SVTG
Issue #

assigned

editorial/not fixed
再アピール"Fixed"status ischecked

Summary

AssignedID

100"HDL" doesn't seem to be a suitable expression for SystemVerilog. In
some cases, SystemVerilog is referred as "HDVL.". Please discuss in
TWG and define the terminology and keep consistency in the entire
document.

NA

fixed

101

"Elaboration occurs after parsing the HDL and before simulation"
should be revised. The reasons are (1). because Compilation
description has been added before this description and compilation
has been defined as the pre-process of elaboration (2). not only
simulation is the purpose to use SystemVerilog.

1825

not fixed
closed102"IEEE Std 11364-2005" should be "IEEE Std 1364-2005"

NA

fixed

103

There is no "'begin_keyword" description in index

NA

fixed

104

Want to see the keyword list categorized by approved version. (e.g.
1800-2005 keywordA, keywordB; 1800-2008 keywordC, keywordE…;)
Please see the attached file for the example.

1826

fixed

We expect this item
will be fixed.

105

WindowsNT is shown as the example to describe the difference ofbinary file operation. Need more updated OS example.

1827

fixed

OK

106

"Syntax 20-22—" should be "Syntax 20-22" because the originalcontains redundant hyphens.

NA

fixed

SystemVerilog-WG

Status"Syntax21-"1 should be "Syntax21-7"

NA

fixed

108

"Syntax21-2" should be "Syntax21-8"

NA

fixed

109

"Syntax21-3" should be "Syntax21-9"

NA

fixed

110

"SDF to Verilog delay value mapping" should be "SDF to
SystemVerilog delay value mapping"

NA

fixed

111

"SDF constructs mapping to Verilog" should be "SDF constructs
mapping to SystemVerilog"

NA

fixed

112

"SDF delay constructs mapping to Verilog declarations" should be"SDF delay constructs mapping to SystemVerilog declarations"

NA

fixed

113

"Table" are at the top of the charts but "Syntax" are at the bottom of
the charts. Using link-jump feature, we can jump to "Table"/"Syntax"
but our expectation is to jump to the charts. To remove thisinconvenience, please put both at the top of the charts.

NA

fixed

114

In the definition of "pass_enable_switch_instance","inout_terminal ,(black comma) inout_terminalred " should be"inout_terminal ,(red comma) inout_terminalred "

NA

fixed

115

Syntax continues to the subject with "--" but Table continues to thesubject with ":". Please unify.

NA

fixed

116

on Page 668, "//from A.3.2" should be "//from A.5.2"

NA

fixed

117

The hyperlink from Syntax29-5 on page 683 is not active.

NA

FIXED

118

"Software tools can perform" should be "Software tools should
perform". Such warnings are mandatory to avoid describing
unexpected behavior.

1828

fixed

-337-

OK as our request
makes the scope tochange too large

1107

SystemVerilog-WG

JEITA ack2

Our intention was toremove thesestatements as LRM
doesn't have to define
how to implement intools.

119"assert (req1 || req2);" in the example should be "assert (req1 || req2)"

NA

fixed

120

"Table 7-2" should be "Table 8-2" on line 2 of page 124.

NA

fixed

121

"fileId" should be "fileID" on line 6 of page 126.

NA

fixed

122

we believe that usually logic [31:0] would be little endian.

1829

normal,fixed

Correction: 6.8 ->11.5.1As the previous
example shows, using
up/down-vect would
be better for readersthan big/little-vect.

123

There are no Sequence methods(ended, triggered, matched) in the
BNF

1830

fixed

We strongly expect
this item will be fixed.

124

The indentation of Yes/No in table18-29 are broken.

NA

fixed

125

the title at the article and at the bookmarks in Acrobat is different

NA

fixed

126

the title at the article and at the bookmarks in Acrobat is different

NA

fixed

127

the title at the article and at the bookmarks in Acrobat is different

NA

fixed

128

the title at the article and at the bookmarks in Acrobat is different

NA

fixed

129

the title at the article and at the bookmarks in Acrobat is different

NA

fixed

130

"It shall be illegal for a module declaration to mix the port_reference
port lists of nonANSI style module headers with the list_of_port_declarations ports
lists of ANSI style headers." should be "It shall be illegal for a module
declaration to mix the port_reference port lists of nonANSI style module headers with the list_of_port_declarations ports
lists of ANSI style headers in one module" to explicitly show that the
mixture of non-ANSI and ANSI in one module is prohibited.

1831

not fixed
close

OK

SystemVerilog-WG

3

131

path rule/scope rule is not clearly described here. 22.7 definition
would be mentioned here.remove "If $root is not specified, ahierarchical path isambiguous. For example, A.B.C can mean the local A.B.C or the toplevel A.B.C (assuming there is an
instance A that contains an instance B at both the top level and in thecurrent module). Verilog addresses thatambiguity The ambiguity is resolved by giving priority to the local
scope and thereby preventing access tothe top-level path. $root allows explicit access to the top level in thosecases in which the name of the top-level
module is insufficient to uniquely identify the path."

1832

FIXED

We expect this item
will be fixed.

132"The immediate assertion statement is a test of an expression
performed when the statement is executed in theprocedural code." should be more precisely defined, i.e. thescheduling should be independently defined to avoid racing. We
recommend to execute the immediate assertions at "observed".We
don't put this to the situation at "$display" which cause the different
behavior for each simulator.

1833

fixed as#2005

We expect this item
will be fixed.

133

for PLI, tf_ and acc_ should be kept, at least in appendix for legacy
code maintenance purpose

1834

not fixed
closedOK

134

Give the name of the superset (summation) of Assertion API,
Coverage API, Data read API and VPI. For example, SVPLI.

1835

FIXED

We expect this item
will be fixed.

SystemVerilog-WG

-338-

4

EDAアニュアルレポート

20082009年5月発行
禁無断転載

発

行

社団法人 電子情報技術産業協会〒101-0065

電子デバイス部

東京都千代田区西神田3-2-1
千代田ファーストビル南館
電話
作

成

03-5275-7258

FAX

03-5212-8121

三協印刷株式会社〒152-0002
東京都目黒区目黒本町5-20-7
電話

03-3793-5971

FAX

03-3793-6242

Copyright 2008 by Japan Electronics and Information Technology Industries Association
本書中に記載の会社名および商標名は、各社の登録商標、商標です。