how to use starc rtl design style guide verilog-hdl 2011 version

STARC RTL設計スタイルガイドを「こう使おう」Verilog-HDL版VER4.0 2011年版改定に対応

技術士(情報工学）・博士（工学）

小川清

20150327 1(c) @kaizen_nagoya, [email protected]

概要

背景

1. 振る舞い言語の標準化

2. ＳＴＡＲＣ RTL設計スタイルガイド

3. 教育のための準備

4. 業務利用のための準備

５. 逸脱の手続きと事例

まとめと付録

20150327(c) @kaizen_nagoya, [email protected]

背景

HDL言語の標準化をIEEEで決めた。標準に適合するだけの書き方では適切な動作をしない可能性あり。同じ記述でも，言語処理系，物理的な回路によって，

同じ振る舞いをしない可能性あり。可読性，保守性の高い振舞設計記述。ASIC設計とFPGA設計で違いあり。ここでは主にFPGAに着目。

Verilog HDLはシミュレーションのために文法が緩い。よりよい実装のためには強い規約が必要。C言語とMISRA-C等のコーディング標準の関係と相似：MISRA-C等はソフトウェアの空間的な部分集合で、時間の指針が弱い。

20150327 (c) @kaizen_nagoya, [email protected]

FPGAを利用する理由すばやい設計すばやい実装すばやい物理実験。

FPGA(flexible programmable gate array)は入出力、RAMなどの機能ブロックが事前に決まっている。

構成要素として、LUT(look up table)、FF(flipflop)などの配置, クロック配線

場合によってはCPU, DSP, ネットワークなどをハードウェアまたはソフトウェアで導入

道具が完備。書いてすぐに模擬試験(simulation)。すぐに実装可能。

最終顧客がFPGAで実装試験を実施

発注時の仕様の打ち合わせ

FPGAの開発競争激しい低消費電流化

高速度化

CPLD(小規模）から大規模FPGAまでの製品展開


FPGA ASIC

消費電流大

小にできる

処理速度遅

速くできる

IC面積大小にできる

設計から実装

短くできる長

１個作成費用

安くできる高

供給主要２者の競争

製造者による

RTL設計スタイルガイド言語の部分集合を定義し、HDLの曖昧さを排除(時間的にも）

Verilog-HDLは特に。

ASIC向けのガイドが基本。

Verilog-HDLでは,第二版でFPGA向けの節を追加。Verilog-HDLの第二版は本では日本語。System-Verilogに対応した第三版。

ＣＳＶなど古典的ソフトでの記述だった。

定量的な記述は当時の制約の影響。

ＦＰＧＡの場合の詳細が未整備。

Xilinx, Alteraのガイドを参考に対応付けがあるとよい

規則を守ることよりも、守らないときの理由が大事（規則を守るよりも価値があることがあるかも）


1. 振舞言語設計自動化(Design automation)/振舞言語(Behaviourallanguages)

IEEEで設計自動化として標準化、順次IECで振る舞い言語国際規格化

VHDLはAda(modula-2/pascal)から, Verilog-HDLはCとmodula-2/pascalから

RTL設計スタイルガイド

㈱半導体理工学研究センター(STARC:SemiconductorTechnology Academic Research Center)

ＦＰＧＡベンダによるガイド

Xilinx合成シミュレーション設計ガイド

Altera ハンドブック第1巻推奨HDLコーディング構文など

(c) @kaizen_nagoya, [email protected]

HDL:Hardware Description Language設計自動化(Design automation)/HDLハードウェア記述言語

VHDL:VHSIC Hardware Description Language

VHSIC: Very High Speed Integrated Circuits

Verilog-HDL

振る舞い言語(Behavioural languages)


Pascal -> Modula-2-> Ada -> VHDL

->Verilog-HDL -> System Verilog-> System C-> C#

-> C -> C++ -> JAVA

言語の関連

2. STARC RTL設計スタイルガイド

論理回路の振る舞いを記述する手引き規則に沿った書き方をすると、間違が少ない

VHDL版とVerilog-HDL

版がある

それぞれ日本語版と

英語版がある

約600個の規則を３つ

（５つ）に分類必須。守らないときには、理由を文書化するとよい

推奨。推奨には１，２，３の区分あり

参考。自社の規則を作る際に検討


VHDL Verilog-HLD

日本語初版第2版（追加、改定あり）

英語初版初版(pdfは第2版)

スタイルガイドの主な章構成1章基本設計制約

命名規則,設計スタイル,クロック,（非）同期設計,階層設計

設計を開始時に考慮する設計制約

2章 RTL記述テクニック組合せ回路,順序回路の記述スタイル, ステートマシン記述

always文, function文, if文, case文, for文

3章 RTL設計手法分割設計,機能ライブラリ,設計資産のパラメータ化、テスト容易化設計、低消費電力設計、設計データの管理

4章検証のテクニックテストベンチのパラメータ化、タスクの使用、検証の進め方


利用処理系によるガイドの使い方

Verilog-HDL利用

System Verilog編以外を利用

Verilog -2001利用時は、Verilog-2001と特記部分も利用

System-Verilog利用

System Verilog編と記載の部分を合わせて利用

Design Compiler利用

付録 A-5 （この資料では省略）

Encounter RTL Compiler利用

付録 A-6 （この資料では省略）


3. 利用の準備ルールの体系の確認

優先順位をつけてみる

現場の言葉を使った愛称(nick name)

現場の理解に合った番号の振りなおし

教育の順番を設定（以下は例です）

<1>:実習前に

<2>:実習中に

<3>:進んでいる人が自習

<4>：教育の作業の範囲外


次頁以降の検討成果記述汎例

<1>,<2>,<3>,<4>と教育順序を設定。

青文字の項目：RTL設計スタイルガイドで省略している注記

＜小川清による補足＞

赤茶字：初学者のうちから習慣付けするとよい項目


1章基本設計制約

(静的規則)

1.1 命名規則 <1>

＜プログラムを書く際に、名前は必ず使う＞

(動的規則) <2>

1.2 同期設計1.3初期リセット1.4 クロック1.5 非同期設計

(構造設計) <4>

1.6 階層設計1.7 FPGA<Verilog-HDL版ver.2以降>


2章 RTL記述技法(1/2)(always文) <2>

2.1組み合わせ回路2.2組み合わせ回路のalways文記述2.3 FFの推定2.4 ラッチ記述2.5 トライステート・バッファ2.6 回路構造を意識した always文記述

(制御文と演算) <2>

2.7 if文記述

2.8 case文記述2.9 for文記述2.10 演算子と代入文の記述

2.11 ステートマシン記述 <3>


2章 RTL記述技法(2/2)


(system Verilog編) <4>

2.12 データタイプの拡張2.13 新しいalways文2.14 if文とcase文の拡張2.15 モジュール、ファンクション宣言と接続(verilog-2001)

2.16 インターフェース

3章 RTL設計手法

(機能ライブラリ) <3>

3.1 機能ライブラリの作成

3.2 機能ライブラリの使用

3.3 試験容易化設計(DFT) <4>

3.4 低消費電力設計 <3>

3.5 ソースコード, 設計データの管理 <1>

＜ソースコードを必ず扱うため＞


4章検証技術(Verification Techniques )

(試験台(test bench))

4.1 試験台記述 <2>

4.2 手続記述(Task description) <3>

4.3 検証の進め方(Verification process ) <3>

4.4 アサーションベース検証

4.5 アサーション記述テクニック(System Verilog編)

4.6 機能カバレッジ

4.7 ゲート水準模擬試験(simulation) <4>

4.8 静的刻時解析(static timing analysis) <3>


1章基本設計制約1.1. 命名規則

1.1.1. 基本命名規則を守る

1.1.2. 回路名や端子名は階層構造を意識した命名規則に従う

1.1.3. 信号名には意味のある名前を付ける

1.1.4. includeファイル、パラメータ、defineの命名規則

1.1.5. クロック系を意識した命名をする


1.1.1. 基本命名規則を守る①ファイル名は、”<モジュール名>.v” または”<モジュール名>.sv”とする [推奨2]＜推奨なのは過去の道具、遺産があるため。System verilogの拡張子sv追加＞

②使用文字は、英数字と’_’、最初の文字は英字のみ[必須]

③ Verilog HDL, SystemVerilog, VHDLの予約語は、使用しない [必須] ＜他の言語と連動して使う場合に困る＞

④ ”VDD”, ”VSS”, ”VCC”, ”GND”, ”VREF” で始まる名前は、使用しない（大小文字とも） [必須] ＜回路シミュレータと連動して使う場合に困る＞

⑤英字の大文字/ 小文字で、名称を区別しない(Abc,abcなど) [必須]＜可読性が良くないし、OSや道具によっては混同するため＞

⑥最上位のポート名・モジュール名は ‘_’を最後に使用及び連続使用しない[推奨1]

⑦負論理信号は極性がわかるように末尾に識別記号(”_X”, ”_N” など) を付ける[推奨2]<_Xよりは_Nの方がよい。>

⑧インスタンス名はモジュール名を基本とし、複数使用されるインスタンス名は”<モジュール名>_< 数値>” とする [推奨3]

⑨最上位のモジュール名・ポート名は16 文字以内で大文字/ 小文字

を混在させない[推奨1]

⑩使用するASIC ライブラリと同じインスタンス名、セル名を使用しない[必須]


1.1.2. 回路名や端子名は階層構造を意識した命名規則に従う

① モジュール名、インスタンス名は、2 文字以上、32 文字以下とする[必須]

＜解説：1文字の名前は一覧を作り、目的を記載する（逸脱文書）。それ以外の目的では使わない事、今後、1文字の名前を作らないことを徹底する＞

・16 文字以下を推奨する（推奨2）

・階層を含んだインスタンス名は128 文字以内とする（推奨3）

② 最上位(TOP) にある階層(ブロック名)の先頭には、階層識別文字を付加する[推奨3]

③ サブ階層の階層識別文字には、上位階層の階層識別文字を付加する[推奨3]

④ 各ブロック出力端子名の先頭文字は、”< 階層識別文字>”+”_” とする[推奨3]

⑤ ブロックの入力信号名・出力信号名は、内部の信号とは別の命名規則があるとよい [参考]

⑥ 出力端子名と接続されるネット名は同一とする[推奨2]

・上位階層のネット名と入力端子名を同一とする（推奨2）


1.1.3. 信号名には意味のある名前を付ける

①ブロック内部の信号名は、入出力信号名とは別の命名規則があるとよい [参考]

②階層内部は、意味のある理解しやすい信号名を付ける [参考]

③信号名、ポート名、パラメータ名、define 名、ファンクション名は、2 文字以上、40 文字以下とする [必須]

＜1文字の名前は一覧を作り、目的を記載する（逸脱文書）。それ以外の目的では使わない事、今後、1文字の名前を作らないことを徹底する＞

・24 文字以下を推奨する（推奨2）


1.1.4.include ファイル,パラメータ,defineの命名規則

① include ファイルは、RTL 記述に対しては ”.h”, ”.vh”, ”.inc”、テストベンチに対しては ”.h”, ”.inc”, ”.ht”, ”.tsk”とする [推奨2]

②パラメータ名は、異なる命名規則があるとよい [推奨3]

③同一名称のパラメータを、異なるモジュールで使用しない [推奨3]

④ defineは、同一モジュール内で宣言されたもののみを使用する [推奨1]

⑤ 1 つの階層内だけで使用するパラメータは、階層識別文字を付加するとよい[参考]

⑥定数を出力ポートに直接出力しない [推奨1]

・入力ポートにも定数を入力しないほうがよい（参考）

⑦再利用を考えた回路は、必要なポートのビット幅をパラメータ化する [推奨3]

⑧パラメータも<数値>’b,’h,’d,’oの指定を明確化する [推奨1]

⑨ 32ビット幅以上の場合は、ビット幅を指定する [必須]


1.1.5. クロック系を意識した命名をする

①レジスタの出力信号名にはクロック系やレジスタを意識した命名をする [推奨3]

②クロック信号名はCLK またはCK、リセット信号はRST_X またはRESET_X、イネーブル信号はEN を基本とし、末尾に種別を付加する[推奨3]

③クロック系を意識した命名 [参考]

④レジスタを意識した命名 [参考]


1.7. FPGA1.7.1. ASICとFPGAの両方を使用する場

合の注意点

①FPGA固有のクロックライン生成方法に従う＜改定＞ [参考]

② FPGA とASIC で異なる部分はCORE の記述から除外する [参考]

③ FPGA, ASIC で異なる記述は`ifdefで切り替える [参考]


3章 RTL設計手法3.5. ソースコード、設計データの管理

3.5.1. ディレクトリを目的ごとに作成する

3.5.2. ファイルのサフィックス名

3.5.3. ファイルヘッダに必要な情報を定義する

3.5.4. ファイルのバージョンを管理する

3.5.5. ファイルのバックアップは定期的に

3.5.6. コメントを多用する

3.5.7. バージョン管理にCVSを使用する<CVS用>

3.5.8. CVSの基本操作<CVS用>

3.5.9. CVSの高度な使い方<CVS用>)

3.5.10. CVSの履歴によって変更内容を確認する<CVS用>

3.5.11. バグトラッキングシステムを構築する


3.5.1. ディレクトリを目的ごとに作成する

① RTL 記述、合成スクリプト、論理合成結果、Sim

結果は、異なるディレクトリに保管する [必須]

② RTL 記述のディレクトリにはテストパターンを置かない [推奨1]

③データのバージョン管理はディレクトリをコピーして、いらないファイルを消去する [推奨2]

④ファイル名は相対パスで参照する [推奨1]


3.5.2. ファイルのサフィックス名①各ファイルの参照は相対パスで指定（1 度master 階層まで戻る） [推奨1]

② RTL 記述は、”< モジュール名>” ＋ ”.v”または”<モジュール名>”+.”sv” [推奨1]

③テストベンチは、”_tb.v”,”_test.v”, ”.vt” [推奨3]

④ゲート記述は、”< モジュール名>” ＋ ”.v” あるいは、”.vnet” [推奨3]

⑤ include ファイルは、RTL 記述に対しては “.h”,“.vh”,“.inc”、テストベンチに対しては“.h”,“.inc”,“.ht”,“.tsk” にする [推奨2]

⑥ Unix 上の実行ファイルは、”.run” [推奨3]

⑦シミュレーション用(Verilog HDL)スクリプトファイルは、”.v_scr” [推奨3]

⑧ lint 用スクリプトファイルは、”.l_scr” [推奨3]

⑨合成スクリプトは、”.scr” [推奨3]

⑩合成、シミュレーション、レイアウトのlog はすべて、”.log” [推奨3]

⑪ lint のlog は、”.l_log” [推奨3]

⑫論理合成のレポートファイルは、”.rep” あるいは、”.tim” あるいは”.ara” [推奨3]

⑬ SDF ファイルは、”.sdf” [推奨1]

⑭ EDIF ファイルは、”.edif” または”.edf” [推奨1]

⑮合成データベースは、”.db” [推奨1]


3.5.3. ファイルヘッダに必要な情報を定義する

①ファイルヘッダに回路名、回路機能、作成者、作成日などを示す [推奨1]

②再利用の場合には修正者や修正項目を示す [推奨1]

③ファイルヘッダを共通化する [推奨1]

④必要があればCVS を使用する [推奨3] <当時もRCSなどの別の版管理の道具はあった。現在はSubversion, redmineなどを使うことがある。CVS固有の記述は他の道具に変換する。>


3.5.4. ファイルのバージョンを管理する

①複数メンバーでの開発ではマスターデータと個人用データを分離する [推奨1]

② CVS でファイルのバージョンを管理することができる [参考]<当時もRCSなどの別の版管理の道具はあった。現在はSubversion,

redmineなどを使うことがある。CVS固有の記述は他の道具に変換する。>


3.5.5. ファイルのバックアップは定期的に

①ファイルのバックアップを行なう [推奨2]

②設計ディレクトリ全てを定期的にバックアップする[推奨2]

＜版管理の道具を使ったり，ディスクごとバックアップを取ったり，バックアップを常時取っているネットワークディスクを使ったり，方法は様々。＞


3.5.6. コメントを多用する①コメントの多用によりソースコードの可読性が向上する [推奨2]

②記述内の演算子などに、その目的や内容を示すコメントを付ける[推奨2]

③入出力ポート、宣言は1 行で記述し必ずコメントを付ける [推奨2]

④コメントはできるだけ英語で記述する [推奨2]

⑤日本語のコメントはEDA ツールによっては読めないことがある [参考]

⑥もっともトラブルの少ない日本語コードEUC を使用する [推奨1]

⑦コメントは、// で始める [推奨3]


コメントに関する補足（小川清）コメントを多用するとよくない場合

言語記述と矛盾したり，意味が不明になることがある

言語記述を改訂する際に，コメントも変更しないといけない。

コメントの自動生成部分以外は多用しない方がよい場合もある

//コメントの方がよい理由

/* */の間に入るコード例えば /* など，/* を利用しているとMISRA-Cのように関連ルールが必要

/* */だと，どこからどこまでがコメントかを理解するのにタブなどが必要


3.5.11. バグトラッキングシステムを構築する

① 登録、アサイン、解決、検証の段階を明記する [参考]

② 状況をメールで送信するとともに表で表示する [参考]

<TRAC, Redmineなどの単独ソフトウェアを使う場合と統合設計環境に組込み可能な機能を使う場合がある。メール，表での表示はソフトウェアの機能にあるかを確認するとよい>


4. 業務利用の準備

優先順位のつけ直し

個々人に優先順位をつける

班構成の会合で上位10個を確認（班に一人は専門家）して班での合意を作成

過去に公開講座で数度実施（SWEST2008を含む）

累計上位10を紹介

関連項目の中で再掲載(KWIC:key word in

context)


優先順位上位10(ver2当時)

1.4.3の推奨は、より詳細な必須ルールに改定

1.2.1 必須 ② AND,OR などのプリミティブセルでRS ラッチ、FF を作成しない

1.2.1 必須 ③ 組み合わせ回路のフィードバックは使用しない

1.3.1 必須 ⑥ 同一リセットラインで非同期リセットと同期リセットを混在させない

1.4.3 推奨1 ④ クロック信号は、FF のクロック入力端子以外（D 入力等）には供給しない

1.4.3 推奨3 ⑤ クロック信号は、ブラックボックスや双方向端子、リセットラインに接続しない

1.5.1 必須 ③ 非同期間転送後、1 段目のFF でフィードバックループをしない

2.1.2 必須 ③ 引数はすべてfunction文の入力として定義する

2.1.3 必須 ① 引数のビット幅とfunction文の入力宣言のビット幅を合わせる(Verilog HDL only)

2.1.3 必須 ⑤ function文内では、グローバル信号に代入を行なわない(Verilog HDL only)

2.1.5 必須・(?)は最大でも10 回までにする

20150327(c) @kaizen_nagoya, [email protected]

RTL1.2同期設計

(c) @kaizen_nagoya, [email protected] 36

RTL1.3 初期化リセット


RTL1.4.3 ゲーティッドクロック

の使用は注意（ver2当時）


推奨2① 同一クロックライン上での反転、ゲーティッドクロックの使用、エッジの異なるFF の使用は避ける

推奨1 ② FF の出力ピンを他のFF のクロックピンに入力しない

参考 ③ ゲーティッドクロックは、消費電力を抑えるためにはよい方法

推奨1 ④ クロック信号は、FF のクロック入力端子以外（D 入力等）には供給しない

推奨3 ⑤ クロック信号は、ブラックボックスや双方向端子、リセットラインに接続しない

推奨1 ⑥ 反転エッジのFF を使用しない

Gated clock, clock gating: 時計開閉。省電力のために時間信号を開閉する。

FPGAは組込みの省電力機構を用いるとよい

RTL1.4.3 ゲーティッドクロックの使用は注意<改定2011後>


推奨2 ① 同じクロックラインでの正負両エッジクロックを使用しない。

推奨1 ② 反転エッジFFを使用しない

必須 ③ FF の出力ピンを他のFF のクロックピンに入力しない

必須 ④ ゲーティッドクロックはOR型、AND型以外は用いない

必須⑤ クロックラインにNAND, NOR, XOR, XNOR,拉致、トライステートバッファは用いない

推奨1 ⑥ クロックラインにグリッチを発生させない

必須⑦ クロック選択信号を生成しているFFは、クロック選択後のクロックを入力しない

必須⑥ ゲーティッドクロックを生成しているFFは、ゲーティッドされた後のクロックを入力しない

RTL1.5.1. 非同期クロック間の信号に

はメタ・ステーブルを考慮（ver2当時）


必須① 非同期クロックドメイン間は、メタ・ステーブル対策のため組み合わせ論理回路を置かない

推奨1② メタ・ステーブル対策のため、データ取り込み用のFF と、その次のFF の間に組み合わせ論理回路を置かない

必須 ③ 非同期間転送後、1 段目のFF でフィードバックループをしない

推奨2 ④ ノイズが乗りやすいIC 外部からの入力にもメタ・ステーブル対策が必要

Meta stable:不安定平衡状態(unstable equilibrium state)。一定期間発振する。1か0かに収束する。収束時間のデータがない。

RTL1.5.1. 非同期クロック間の信号にはメタ・ステーブルを考慮<改定後>

1.5.1. 非同期クロック間の信号にはメタ・ステーブルを考慮

必須① 非同期クロックドメイン間は、メタ・ステーブル対策のため組み合わせ論理回路を置かない

推奨1② メタ・ステーブル対策のため、制御信号は、非同期クロックドメイン間転送後、次のFFとの間に組み合わせ論理回路を置かない

必須③ データ信号は、メタステーブルが生じないようsetup, hold期間を確保して転送する

必須④ 非同期クロックドメイン間転送後、異なる信号を合流させない（リコンバージェンスエラー）

推奨1 ⑤ 非同期クロックドメイン間転送出たを、２ケ所以上で同期しない

必須 ⑥ 異なる非同期クロックドメイン間同士の信号を合流させない

推奨2⑦ ノイズが乗りやすいIC 外部からの入力にもメタ・ステーブル対策が必要


RTL2.1.2. function 文によって組み合わせ回路を定義


必須 ① function文はFF推定のalways文内で、非同期リセットラインの論理に使用しない

必須 ② function文内では、ノンブロッキング代入(<=)を使用しない(Verilog HDL only)

必須 ③ 引数はすべてfunction文の入力として定義する

推奨1 ④ task文は使用しない(Verilog HDL only)

必須 ⑤ task文内では、クロックエッジ記述をしない(Verilog HDL only)

RTL2.1.3 function 文では、引数やビット幅に

対するチェックを入念にする(ver2当時）

(c) @kaizen_nagoya, [email protected] 43改定 ⑤「グローバル信号」ー＞「モジュール内信号」

RTL2.1.5. 条件演算（(A)?B:C）の使用は1 回まで


推奨3 ① 条件演算(?)のネストは1回までにする(Verilog HDL only)

・(?)は最大でも10 回までにする(必須)

参考 ② 条件式が不定値ﾕxﾕの場合、分岐文の各ビット毎に値を比較して出力される

・条件式が不定値ﾕxﾕの場合、if文より正確な値を出力する(Verilog HDL only)

推奨2 ③ if 文あるいは(?)の条件式を、ベクタにしない(Verilog HDL only)

５．逸脱の手続きと事例


優先順位付けに基づいて規則を合意し対象外を決める

例：テストベンチでの習慣（逸脱文書は作る）

Tbを名前の最初につける方法

整数は10進数を標準にする場合にDをつけない

不足している規則を追加（分野固有の命名規則など）

できればHAZOPなど設計審査を経る

対象外にする方法は3つ

規則そのものを考慮せず検査もしない

共通の逸脱文書を作るが、検査をして資料は残す

共通の逸脱文書にはないが、必要な逸脱なので個別の文書化をする

逸脱の手続き例（1）


逸脱の手続き例（2）


事例


逸脱例：1.1.3.3 信号名、ポート名、パラメータ名、define 名、ファンクション名は、2

文字以上、40 文字以下とする


1文字でよく使っている変数は逸脱文書を作成する。

新たに1文字の変数を作らない。

場合によっては出現箇所一覧を確認（チェッカの出力をつけ利用目的と同じことを確認した人の署名）

まとめ任意性の少ない設計

検証，試験しやすい

教育時の事前，最中，事後、範囲外に区分

作業時に優先順位付けをする

知見の集約，環境の変化への対応、逸脱の合意

逸脱した方が効果的な場合は逸脱のの手続き

道具の有効利用

道具の紹介

HAZOPの実施


参考文献[１] 岐阜大学 FPGA による画像処理入門編, 名古屋ソフトウェアセンタ, 2010

[２] 長谷川誠, 渡会勝彦, 米永裕司, 渡部謹二, 小川清,VerilogHDL スタイルガイドの利用方法, IPSJ 研究報告. EMB,組込みシステム 2008(1), pp. 7-10, 2008

[3] Miron A, Melvin A.B., Arthur D.f., Digital systems testing and testable design, Jaico publishing house, 1993

[4] 小川清，渡部謹二，斉藤直希，森川聡久，服部博行, デジタル設計工学の基礎の検討, 第6 回ディペンダビティシンポジウム, 2009

[5] RTL設計スタイルガイドverilog-HDL編/VHDL編,STARC, 2006/2011


例(sample)をコンパイルしようスタイルガイドには、例の記述があります。眺めて、ふんふん言っているだけでなく、実際に打ち込んで、コンパイルしてみましょう。

省略部分を補足しないとコンパイルエラーになる場合があります。

補足してもコンパイルエラーになる場合（コンパイラの性能、仕様に依存）は対応を検討

複数のコードを回路生成して比較

模擬試験(simulation)して比較

FPGAに実装してみて振る舞い確認

Xilinx ISE Webpackでの実験結果をhttp://researchmap.jp/kaizen/STARC-RTL設計スタイルガイド/に掲載予定


http://researchmap.jp/kaizen/STARC-RTL%E8%A8%AD%E8%A8%88%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%AB%E3%82%AC%E3%82%A4%E3%83%89/

実習で利用しているFPGA例

Xilinx

ISE WebpackとModelSimを同梱。そのまま利用可能。

最新のISE Webpackでも利用可能


第5回5都市FPGAカンファレンス2010

http://www.fpga.or.jp/5city2010/ChubuSC2010.html

中部招待講演「STARC RTL設計スタイルガイドを「こう使おう」Verilog-HDL版」小川清

「ドクターＦＰＧＡ FPGA初心者のためのデバッグヒン

ト」で紹介のあった事例について、スタイルガイドのどの規則を参照しているとよいかをその場で解説


http://www.fpga.or.jp/5city2010/ChubuSC2010.html

改定履歴

1.0 FPGA研修で説明

2.0 SWEST での優先順位付け

3.0 企業のVerilog-HDL研修

4.0 2011年版に対応


謝辞

STARC RTL設計スタイルガイドの取り組みは産業技術推進連絡会議でFPGAコンソーシアムの代表の熊本大学の末吉敏則教授のご指導により始めました。

規則の検討会に、ルネサステクノロジー、富士通VLSI、中央製作所、大同大学、名古屋市工業研究所が参加しました。

スタイルガイド利用、検討のセミナはSWEST, FPGAカンファレンスなどにおいて実施してきました。

Design Wave 2009年2月号（CQ出版）に関連記事があります。

関係者の皆様に感謝いたします。
