スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

CDNLive! Japan2011:ユーザー事例(その1)

10/13(木)に行われた「 CDNLive! Japan2011」に行ってきました。

今回は「京速コンピュータ「京」のインタコネクト検証」についてです。

2011年6月に世界一のスパコンということで話題になっていたので、会場のほうでも満席になってました。
発表は以下の流れで行ってました。
・概要:検証の流れ、ゴール
・コア検証:OVMを使用した検証
・システム検証:Palladiumを使用した検証検証工程の振り返り
・まとめ

今回の検証対象物であるインタコネクトチップ(ICC)の概要
・16個の高速I/O
・ノード間接続はXYZABCの6次元。
・DMAエンジンは4つ搭載
・65nmテクノロジ 200Mトランジスタ。
・動作周波数:312.5MHz

このDUTをどうやって検証していったかということで、実際に行った検証フェーズとして4段階あった。講演ではこれらのフェーズに対してゴールに対しての手段だとして、分かりやすい表現で説明していた。
(1)仕様書検証-地図の正確さをチェック
(2)コア検証(OVM)-狭い路地をきめ細かくチェック
(3)システム検証(Palladium)-大きい道路で広範囲をチェック
(4)実機検証-上空から全体を眺める
そして、今回の検証のゴールは「実機検証に Blocking Bug を流出させない」こと。
※ システム開発工程に影響を与えるバグをBlocking Bugと定義していた。

○(1)仕様書検証
仕様書は曖昧に書かれているものなので、その「行間」を取り出す(設計者から聞き出し、文字に書き起こす)作業が必要。

○(2)コア検証(~数MGate)
OVMを使用し、検証環境を構築。
OVM環境のメリットは枠組みが共通化されているため、部品として何を作るかがハッキリしており分かりやすいということと、使い回しが楽。ただ、 デメリットとしては最初の立ち上げに時間がかかる。ということ。
コア検証でのゴールはラインカバレッジは100%、ブランチ、パスはポイントを絞って強化した。検証で抜けがあった場合を同プロジェクトでは、全て報告していたようでその際には必ずと言っていいほど「次からは仕様書の行間を読みます」と対策に書いてあった。つまり、仕様書に書いてないことが検証漏れが一番発生する原因だと言っていた。

○(3)システム検証(数10MGate~)
Cadenceのエミュレータ:Palladium3使用し、ランダム検証で大量に検証。
エミュレータを使用するメリットは、シミュレーションの高速化(講演では、1万倍早い)。そのため大量のシナリオを流すことが可能になる。デメリットは動かすまでに時間がかかる。時間がかかる要因としては、大規模回路のコンパイル時間がネックだった様子(約3時間~)
システム検証でのバグの特徴は、各コア間のI/Fや実行手順などで「え?こんなタイミングで?」というものが多かったらしい。なので、検証強化ではタイミングをサイクル単位で操作することが出来ない場合があるため、最悪はコア検証でやるような事もあった。

結果として、実機検証での障害は4%あったが、目的であるBlocking Bugは0件だったので検証は成功だった。その障害の4%も予めハード側に回避手段を作り込んでいた「チキン回路」で障害自体は回避出来た模様。
※今回チキン回路で回避した障害は、製品版では全て修正済みとのこと。

検証が成功した要因として、機能を一つ一つ積み上げる、アジャイル的開発が結果として出来ていた事がポイントだと。そして、コア検証、システム検証間で相互に補完しあい障害検出が出来たとのこと。

ちなみに、今回のICC設計は1から設計したとのこと。
講演だけ聞くとかなり綱渡りだったようですね。
関連記事

コメントの投稿

非公開コメント

プロフィール

Kocha

Author:Kocha
なんでもチャレンジ!(^o^)/
E-mail
github:Kocha
イベントカレンダー

カレンダー
05 | 2017/06 | 07
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 -
カテゴリ
OVP (4)
最新記事
最新コメント
アーカイブ
リンク
Twitter
アクセス人数
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。