コデザイン
はい、コデザインです。協調設計です。
御大の登場です。
トポロジーソートする
HDL記述から回路構造抽出して
★演算のレベル付け★
(最適化)
コンパイルコード
→タイミングがわからなくなったほい
→→静的タイミング検証で、積み上げる(STA)
御大の登場です。
Day1
はじめに
- CPUを玉と呼ぶ
- HW/SWの分割は、まあバカみたいな方法しかない。
- 大局的アーキテクチャの詮索
- Pureのアルゴリズムの世界と、実装レベルのCの世界後外
- コデザインもアーキテクチャ探索も、とにかくむちゃくちゃにみんなつかっている
- だからこの講義では何やってもいいのかな??
- 世の中一般のHW/SW分割は、重いところをHW化ということになっているけども、、、
- 通信を減らす方がいいんじゃない?
- μアーキテクチャってのがある
- レジスタの本数、メモリ、ほげほげ
- 大局的でもマイクロでもアーキテクチャ選択にはトレードオフがある。が混乱しますねー
- やっとC設計
- HW
- なんでコデザインが必要なの??????
- 馬鹿な新人3人で3億円!
- HWの検証はたいへんですね
- bitabiデコーダの検証なんか、30cycle/secしかでないのに30分のSIM歯。。。数週間。。。
雑談モード
- 電気系CAD
- いまはアメリカのEDAが席捲している
- ベンチャーとして比較的当たりおおい
- LSICADやっていると大金持ちになることもありますよ。。。と学生には説明していますが、。
- あれ?ここにいるひとはシニアでなおかつ金持ちでない??
Cプログラミングでハードに
- 動作合成とよびます(いやそれはVHDLでもいうんですけど)
- いまやなんでもHWになります。
- HWにして意味があるかどうかが問題になっている。
ここで休憩:いやああRTLはSW系のひとにはわからんでしょう。
- コンパイラと対比させるとRTLがわかるのではないかねえ??
- CPUのなににあるのは”汎用"レジスタといってますね。
つづき
- RTLの説明、
- 機能的RTL:いい加減なRTL
- 構造的RTL: SynthesizableなRTL??なんじゃこりゃ?
- ゲート回路にかなり近いのかな?
- HWはいい加減なので、ゲートにならないRTLもある
- つまり「いんちきくさい」ということです
- 上位の用語はめちゃくちゃなんですよ。
- 高位合成、機能合成、動作合成、おなじこと
- 動作合成ってすごい変な日本語ですね。。。
- 雑誌によっても呼び方が違うんですよ。
- いきなり形式検証の話
- SWの場合はコンパイラの等価性検証なんかしないが、HWはやる
- 今回説明する話は、伝統的なHW設計とは関係ないですが
- 2日でとりあえずHWが設計できるようになるんです。
- 設計生産性の話
- 日本人全員がHW技術者にならないといけなくなってします
- どこかに嘘がある→それが抽象度と、。。。
- 抽象度高い=行数少ない
- 7倍の絵。。。
- HWはゲート→RTLと図形の世界だったのが、突然動作のところで
- いいたかたたのは、動作とRTLの間には断層があるということです。
- インプリメンテーションレベルは上がらざるを得ない
- 部品点数が多すぎると設計できません、10万部品が限界??
- 6Mゲートを超えると、動作レベルになるしかないですね。
- 動作レベルはもう実用にきています。
- C言語で設計されたチップが相当うれてます
- 4万→30万行->100万
- SIMulatioの時間
Gate | RTL | 動作 |
100万 | 40万 | 4万 |
10Hz | 100Hz | 1MHz |
- デバックできないでしょう?
- こまっているんです。
- CHIPを作らざるをえなくなっている
- いままでは経験と勘で、CをRTLにしていた。。
- 動作合成は、入力かわらなくても、出力(RTL)は様々
- コンパイラの能力だけで、様々な合成解をださないといけない
- いまの設計者は歩く速度でアメリカに行こうとしている
- C言語設計にすると100倍ぐらいにはなる
- C言語設計の基礎
- セレクタ
- AND OR回路
- セレクタ
さあこれから、C言語→RTLの真骨頂!
- 紙の上でできるHWコンパイラー
- まずはDFGにします
- 制約がありますから、自ずとスケジューリング結果がひけます
- きれたところとがレジスタですね。
- ひええー時間軸が、縦になったり横になったり
;;
- ひええー時間軸が、縦になったり横になったり
- とにかく、初期データパスができます、正しい回路です
- 欠点は、面積が大きい、レジスタが8本なんて、、Cコンパイラと同じ
- セレクタもたくさん、配線もいっぱい
- 配線はfanoutでも2と数えるんです
- 小さくしましょう
- +や*は入力がっかんなので、selectorが得します。
- レジスタのライフタイム解析します。
- バインディング
- 演算にラベルを付けるだけで、ブロック図が画けるんですよ。
転送表作成からデータパス作成
- いやあまさに "under the hood"! なんだろうか
- 転送表ができれば、もうこれはデータパスなんですねー
Day2:御大!遅刻です!
動作合成
- 合成のオプションはたくさんあるのです
- 結果をみないといけない、論理合成するまえに、RTLで結果を予測するということが必要になります
- ゲートの数とか遅延とか、そういうこもの
- 論理合成は時間とコストがかかるので
- 面積ちょっと像で2倍の性能の例(つくったなー)
- SWとHWのコンパイラの違い
- C言語は拡張する、インチキ??
- bit幅とin/out
- clock記述などのなど
- C言語は拡張する、インチキ??
仕組み
- 1)言語レベルの最適化
- 共通項の抽出は、HWでは必ずしもgainにならない
- CDFGの変形
- バランス化:段数削除→高速化
- バランス化の結果精度がかわるのが落とし穴
- →演算器のビット幅を自動で変える機能が必要
- 多次元配列の1次元化
- すごい、0を入れると*2になるの説明。。
- 複数配列を1つのメモリへ
- 自動キャスト、 a=00:b;
- 2)動作記述から内部でーた構造へ(CFGとDFG)
- CFGとDFGを一つにしたのがCDFG
- forkとjoinと線の色で表す
- 3)アロケーションとスケジューリング
- 面積制約と時間制約
- 単純なスケジュールでは局所的にしかみないのでだめ
- [面積制約スケジューリング]
- ASAP:処理する順番にgreedyに行う
- リストスケジューリング:
全員が早く出世できるのが幸せだ 部下が多い人を早く出世させる。。
- スケジューリング問題はNP完全
- →というわけでヒューリスティックでやっている
- [時間制約スケジューリング]
- 演算器のlifetimeを計算し自由度があるものが余地がある
- ASAP:
- ALAP:
- パイプライン
- riple-carryなので乗算期はうまく会わせると3ns+3nsは4とか5nsになる
- パイプライン演算子
前半と後半をわける
- メモリ、外部入出力なども考慮しないといけない。
ここで演習(CDFGとスケジューリング)です
- バインディング
演算 | 演算器 |
変数、配列 | レジスタ、メモリ |
データ転送 | 結線,MUX,バス |
- バインディングの秘密
- 逐次割当アルゴリズム
- MUXのかずと結線がかわる
- 4)データ通信路の割付
- 伝統的なバスはいろんいろな都合で使われて無くて、
- MUXのお化けになっている(安全)
- 5)制御回路生成とモジュール生成
演習2
Cコンパイラとの違い
- ここまでくるとHWは簡単だと思われるかもしれないが。。
- 合成はコンパイラよりもずいぶんがんばってますよ
- 投機実行はSWよりがんばるよ
- "out of order"=Cで書いた順番どおりにやらないよということ
- まあコンパイラでいうところの code motion--
- HWの場合は、code motionより賢い!
- 投機実行はSWよりがんばるよ
昼から
- CPUの最大の欠点はメモリをもたないといけないこと。。
- RTLでは絶対設計できない例。
- デバックできないので、とにかく正しい回路を出さなくて鼻なら内ので、HWは最適化にはならん。
- インプリレベルがRTLならば、使い回すので、最適化にならない構成になる可能性が高い。
- Cに一つあがれば、適材適所になる場合もある。
- RTLだと周波数が変われば使い回せない→
- 周波数があがると、回路規模が小さくなって行く。。
Day3:
機能・論理検証
- 等価性検証
- 「レベル」といったなあーーー
- Simulation
- イベントドリブン
- time wheel
- サイクルベースシミュレータ
トポロジーソートする
HDL記述から回路構造抽出して
★演算のレベル付け★
(最適化)
コンパイルコード
→タイミングがわからなくなったほい
→→静的タイミング検証で、積み上げる(STA)
- BDDはコンパクトな表現形式であっって
- NPコンプリートな問題が、グラフマッチングというのにおちうr。
- SATでとく方法:最近のはやりですたい。
- 動作合成では、すごく変換する、定数を溶かすので。大変よん
- 10万行のCと100万行のVerilogの透過性の証明は3時間
- 全部はできませんので、ベストミックスでやるのがマネージャの腕のみせどころですね。
SOCアーキテクチャのトレンド
- Softの部分が増えてきた(機能の一部を分担して)
- →→co-designが必須になってきてんですよ
- どうもHW設計者が疲れてきた。。
- custom CPU
- 基本的には簡単なシーケンサみたいなもんですわ。
- 専用命令追加によるストリーム処理
- 本当のコ・デザインってのは、カスタムCPUのことななのかなあ?
- SW屋さんが、欲しい命令が、追加できる。
- SWからHWを設計していることになる。
- あっ、「パタヘネ」といった。。
- コプロセッサ方式(世の中の普通の方式:MEP等)
- 論理合成ベース
- 立派なプロセッサコア(RISC)がある
- リソースシェアはできないね。
- 動作合成ベース方式
- プロセッサもCでかかれていて
- 全体をグニャグニャグニャと合成しますのでね、
- いやあなんでもできます、
- なんていうか、超高速のプロセッサはねらってない
- ねじ釘プロセッサ???
- コプロセッサ方式(世の中の普通の方式:MEP等)
四方山話
- SW/HW技術者の壁壁壁
- 長い間教育してきた
- どっちが困ったか?
- 指導要領が全く違う
- HW屋さん
- COREダンプするし、
- 1割がCのコースで断念!
- テストベンチがわかりにくい
- トークンが流れるのがわからない。気持ち悪い
- 回路の部品を書く
- 構造的発想から抜けられない。
- 最近はあきらめている。。
- コンパイルが以上に遅い!Verilogに比べて
- ボトムアップ設計の発想!
- 根本から発想転換が必要
- SW屋さん
- 組込ソフトやさんなら結構よい
- FPGAでチップつくってJAXAに納めている!!!
- printer/camera, TBSとかでねももうはいいてますSW屋さん製のHW
*動作合成は危険だよ。
- 賢い人がつかうとよい回路がでるし、
- そういうそういう危険製がある。
*微細化が進むと、HWそものものが変わっちゃう(私論)
- 分散制御アーキテクチャ
- 配線が重くなる、とっても。1クロックでは、
- それぞれにCUがいて、分散になれば、よろしい。
- なんでもかんでも通信しすぎ、配線のシェアもやらんといけない
2006年02月24日(金) 20:56:44 Modified by miwamasa3