CMエンジニアリング_FPGA検証の立て直しが急務

tag:

2016年4月20日

FPGA開発を蝕(むしば)む“実機デバッグ症候群” 検証工程と仕様書作成の立て直しが急務

  FPGAの利点は,ユーザの手元で回路構成を変更できる柔軟性にある.その修正の容易さゆえに,FPGAの検証は開発の最終段階である実機デバッグ工程に頼る風潮がある.回路規模が小さい場合はこの方法で問題ないが,開発対象が数十万ゲートを超えたあたりから,トラブルが増えてくる.例えば「納期遅延が頻発する」,「出荷後にバグが見つかった」,「プロジェクトを管理できない」.こうした問題を解消するには,開発管理者の統率のもと,仕様書作成とシミュレーションの工程を粛々と進める必要がある.ここでは,検証手法のコンサルティングを行っているCMエンジニアリングの斎藤 早苗氏に,FPGA検証の課題とその対策について聞いた.
CQ営業部

 

 

 

CMエンジニアリング株式会社 設計・検証サービス部 部長 斎藤 早苗氏

 

実機デバッグには限界がある 

 FPGA(field programmable gate array)の開発と言えば,かつては回路規模が小さく,設計からデバッグまで一人のエンジニアが担当することが珍しくなかった.しかし,昨今では開発対象の大規模化,機能の複雑化が進み,数人のチームでFPGA開発を進めるケースが増えている.

 複雑なシステムをチームで開発するとなると,体系的な設計・検証の方法論が必要になる.大規模ソフトウェアの開発では,ソフトウェア工学に基づく自動テストやプロジェクト管理の手法を適用し,要求されるコード品質を維持している.大規模FPGAの開発についても,基本的な考え方は同じだ.

 例えば,FPGA開発では「パソコン上でのシミュレーションをきちんと行わず,主に実機デバッグによって不具合を洗い出そうとする人が,少なからずいる」(CMエンジニアリングの斎藤 早苗氏)という.小規模な回路の開発であればこの方法で乗り切れるが,システム規模が大きくなると,途端にこの方法では苦しくなる.「いつまでたっても実機が期待通りに動作せず,開発マネージャは検証の進捗状況や検証終了のタイミングを正しく見通せなくなる」(斎藤氏).

 このような状況に陥らないためには,パソコン上で行う機能シミュレーションと実機デバッグの2段構えで検証を進める必要がある.シミュレーションによって論理機能上の不具合やケアレス・ミスに起因するバグを洗い出し,実機デバッグではより詳細なタイミングにまつわる問題をチェックする.一見,「二度手間では?」と考えがちだが,「急がば回れ」という言葉のとおり,結局このほうが検証作業は早く収束する.開発マネージャにとっては,設計品質や検証の進捗を管理しやすくなる.

 CMエンジニアリングも過去には,FPGAの検証漏れによるトラブルを経験したという.PCI Expressインターフェースを備えるシステムを開発した際に,試作したボードが思い通りに動作しなかった.結果としてスケジュールが1カ月遅れ,後工程であるソフトウェア・テストの時間が短くなってしまった.「原因はFPGA内部の機能上の不具合と,基板のピン割り当てのミスにあった.シミュレーションによる事前検証が甘かった」(斎藤氏).それ以降,同社はシミュレーションや体系的な検証手法の適用に,いっそう力を入れるようになったという. 

 

検証ノウハウは買ってくる


 ソフトウェア開発の方法論がソフトウェア工学という技術体系の中で整理されてきたように,FPGA開発の方法論は,主にASIC(application specific integrated circuit)やSoC(system on a chip)といった大規模ディジタルLSIの開発を通して確立された設計・検証手法がベースになっている.とは言っても,かつて隆盛を誇ったASICの設計件数は激減しており,ASICの設計経験のあるエンジニアは少なくなっている.そのノウハウが引き継がれないまま,開発部署が解散してしまった例もある.


 FPGAを搭載したシステムの開発に取り組んでいる企業の中には,こうしたASIC開発の流れをくむ設計・検証効率化のノウハウをきちんと継承しているところもある注1.しかし大多数の開発企業は,こうしたノウハウに接する機会のないまま,日々の業務に追われているように見える.


 そのような開発部署のエンジニアが,テストベンチやテスト自動化の環境を一から構築するのは,かなり大変だろう.そこで,「シミュレーションの作業負担を軽減するツールや検証用IP(intellectual property)を使いこなすことが重要になる」(斎藤氏).検証用IPとは,あらかじめ必要な検証項目が作り込まれた既製品のテストベンチ,および検証環境である注2

........................................................................
注1:CMエンジニアリングはそのうちの1社.同社はLSIを開発していた大手電機メーカの開発子会社からのスピンオフ企業で,検証手法についての経験が10年~15年を超えるベテラン技術者を多く抱えている.
注2:検証ツールや検証用IPの中には高価なものや,仕掛けが大がかりなものが少なくない.費用対効果の精査はきちんと行う必要がある.
........................................................................


 『本当に必要な部分だけを内製し,それ以外の部分はできるだけ外部調達したものを流用する』.これは,標準プラットフォームやオープンソース技術の導入が進んだ昨今の,製品開発手法の定番のフレーズだが,検証ノウハウや検証環境の構築についても同じことが言える.
 

 

RTL記述やテストベンチの作成を省力化


 CMエンジニアリングは,「SpecInsight」というツールを自社開発し,第三者検証サービス(検証業務の受託事業)で利用している.2013年9月には外販も始めた.このツールは,(機能)仕様書を作成する過程で入力した情報(入出力端子表やレジスタ仕様,タイミング・チャート)から,RTL設計やシミュレーションに必要なデータ一式を自動生成する.シミュレーションのために何か特別な入力・編集作業を行うのではなく,仕様書の作成作業と一体になっているところがミソだ.「仕様書と検証用データの間に一貫性を持たせることが,設計品質の向上につながると考えた」(斎藤氏).


 SpecInsightは,以下の四つの機能から構成されている(図1,図2)

  • (1)入出力端子表から最上位階層のRTL記述と各モジュールの入出力宣言記述を生成(SpecInsight-NEO
  • (2)レジスタ仕様からレジスタ・モジュールのRTL記述を生成(SpecInsight-REG
  • (3)タイミング・チャートからテストベンチ(入力信号と期待値のデータ)を生成.入出力端子表からRTLモジュールとテストベンチの間の接続情報を生成.シミュレーション実行用スクリプトを生成(SpecInsight-TEX
  • (4)タイミング・チャートからアサーション仕様記述(SystemVerilogコード)を生成(SpecInsight-ACE


図1 SpecInsightの構成

 


図2 SpecInsightの画面例


 これにより,テストベンチ,およびRTL記述の一部のコーディング作業を自動化できるので,そのぶん人手によるケアレス・ミスが減ると期待できる.またアサーション検証(複数の信号間の関係性を検証する手法)のような,やや難度の高い記述の作成作業も省力化できる.


 上記の(3)のテストベンチ生成については,複数のタイミング・チャートを連結して長いサイクルのシミュレーションを実行する機能がある.ユーザは,この機能を利用して検証シナリオを作成・管理する.例えば,検証資産をタイミング・チャートの形で蓄積し,その後のプロジェクトで再利用することも可能となる.


 さらにユーザ・サポートの一環として,同社はタイミング・チャートのサンプル・データを提供している.バスやインターフェース,FIFO(first-in first-out),競合制御など,使用頻度の高い機能のサンプルが用意されている.このサンプルにはアサーション仕様の情報が含まれており,アサーション検証の勘所をつかむためにも有用だろう.


 同社によると,SpecInsightは大手企業よりも中堅クラスや小規模の企業,また電機系以外の業種の企業がよく利用しているという.「FPGAを利用して画像系や制御系のシステムを開発している部署による採用例が多い」(斎藤氏).
 

仕様書作成で手を抜くと検証の手間が増える


 SpecInsightには,コードの自動生成のほかにもう一つの効用がある.このツールを使うと自然に仕様書の形式が標準化され,チームによる仕様の検討やデザイン・レビューが行いやすくなる.実はここに,FPGAの開発効率化を妨げるもう一つの課題が潜んでいるという.


 同社は第三者検証サービスを通してさまざまな開発企業の設計・検証情報に接している.最近では,略式の仕様書しか用意していなかったり,そもそも仕様書がなかったりするケースが目立っているという.「状況は昔より悪くなっている.開発期間が短くなり,仕様書の作成に時間を割けなくなっているようだ」(斎藤氏).しかし,これではまともなデザイン・レビューが出来ない.作業効率も設計品質も低下する.


 逆に考えると,この問題を解消できれば,設計品質を維持しつつ,開発に要する期間を短縮できるとも言える(図3).仕様書作成とシミュレーション.二つの工程を円滑に回し,きちんと管理することが,大規模FPGAの開発では欠かせなくなってきている.

 
図3 SpecInsightの導入効果


........................................................................


 ここで今回,話を伺ったCMエンジニアリングについて紹介する.同社は検証サービスやアナログ/RF(radio frequency)設計サービス,無線通信モジュール/ボードの開発・販売を行っている企業である(図4).検証サービス事業の一環として,FPGAの設計品質を向上させるコンサルティングや検証環境構築を行っている.


図4 CMエンジニアリングの事業概要

 

........................................................................



下記のタイミング・チャート・エディタ抽選プレゼントは5/31をもちまして終了させていただきました.

 

動画もあります
http://cmengineering.co.jp/products/specinsight-timingcharteditor.html

 

この記事に関するお問い合わせ先


 

 


CMエンジニアリング株式会社  http://cmengineering.co.jp/
〒141-0031 東京都品川区西五反田2丁目18番2号 五反田KYビル TEL:03-6420-0936


 

組み込みキャッチアップ

お知らせ 一覧を見る

電子書籍の最新刊! FPGAマガジン No.12『ARMコアFPGA×Linux初体験』好評発売中

FPGAマガジン No.11『性能UP! アルゴリズム×手仕上げHDL』好評発売中! PDF版もあります

PICK UP用語

EV(電気自動車)

関連記事

EnOcean

関連記事

Android

関連記事

ニュース 一覧を見る
Tech Villageブログ

渡辺のぼるのロボコン・プロモータ日記

2年ぶりのブログ更新w

2016年10月 9日

Hamana Project

Hamana-8最終打ち上げ報告(その2)

2012年6月26日