Tech Blog

FPGA置き換え開発だって怖くない!

人物
小野です!
よろしくお願いします!!

こんにちは、小野です。今回はOKIアイディエスが展開する「デバイス置き換え開発サービス“iReDevice”」をご紹介します。








置き換え開発は、なぜ怖い?

人物
やぁ、小野くん。
こないだのブログで話した怖い話を覚えていますか?
人物
あぁ、あのCPUの置き換え開発なんて簡単だと思って進めていたら、落とし穴にはまって大失敗。開発に関わっていたボスの知り合いが失踪した…というホラーフィクションですよね。
人物
そうです。実際、失踪まではいかなくても、置き換え開発でうまくいかない例は山ほどありますよ。最近、EOL対応や置き換え開発の相談が増えてますが、その理由はわかりますか?
人物
そういえば、最近はそんな話が結構多いような。。。
あんまり意識したことなかったかもです。
人物
「2025年の崖」、聞いたことありますよね。様々な業界や市場でIoT化が進んでいますが、一部でIoT化が進まないシステムが残っているんです。
人物
「崖」というくらいだから、もしかして相当深刻な問題なんですか?
人物
まさに「崖っぷち状態」というところもあります。技術者や有識者の定年退職による人材不足で、従来の古いシステムのメンテナンスが困難になったり、DX化にも対応できず、ブラックボックス化してしまうんです。
人物
ブラックボックス化…メンテできなきゃ本当に「崖」ですね。
人物
放置すると、システム連携も困難、サポートも受けられず、本当に使えなくなるかもしれないのです。
人物
これは早めに対策しないと、まさに崖から真っ逆さまですよ、早くどうにかしないと…。
人物
かといって、事前検討が不十分な状態で、設計に取り掛かると、まさに「無限城」。課題ばかり増えていきます。だからこそ、OKIアイディエスの「リバースエンジニアリング&マイグレーション統合サービス“N-Process”」が、おススメというわけです。
人物
“N-Process”は、以前にもブログでご紹介したリバースエンジニアリングとデバイスの置き換え開発のサービスです。







FPGAのデバイス置き換えにも落とし穴あり!

人物
実は失敗しがちなのはCPUだけではなく、FPGAでも同様。FPGAならではの課題もたくさんあります。
人物
簡単じゃなさそうですね…。怖いなぁ…。
でも、この流れは秘策か何かがあるんですよね?
人物
そんなFPGAの置き換え開発に特化したサービスが“iReDevice”です!!
人物
というわけで、今回はそんな“iReDevice”についてチェックしていきましょう!







そもそも置き換え開発とは?

人物
小野君。そもそも、置き換え開発ってどういうものでしょうか?
人物
前も似たようなことを聞かれた気がします。置き換え開発とは、元のシステムの機能や性能をそのまま新しい機器・デバイスで再現する開発ですよね。つまり「置き換え前と置き換え後の機能が全く同じである」ことが求められますよね。
人物
That’s right. デバイスがEOL(生産終了)の場合、置き換え開発が必要ですが、単純な置き換えでは済まないことも頻繁にありますよ。
人物
もちろんです。デバイスが違えば仕様も異なりますから、それに対応するためにプログラムの改良や移植の必要がありそうです。このあたりに気を付けないといけないポイントがありそうだな…。
人物
開発時には次のような課題があります。

FPGA置き換え開発の主な課題

  • 既存機能との完全互換性・等価性が必要
  • 設計ルールやデバイス性能の違いから予期しない不具合が発生
  • ソースコードやシミュレーション環境が揃っていない場合、等価性保証が困難
  • IPコアの世代違いによる置き換え、ユーザーインターフェースの修正が不可避
  • 既存設計の隠れたワーニングやタイミングエラーなど潜在リスク
人物
あれ、なんか無理な気がしてきたぞ…。ちょっと逃げ出したいですよ。
人物
こらこら。問題を整理して、どう解決するか明確に方針を立てることが重要です。次の3つのポイントさえ押さえればFPGA置き換え開発は恐れるに足らず!

FPGA置き換え開発の3つのポイント

  1. 置き換え前・後のソフトウェア互換性
  2. デバイス変更に伴うIPの置き換え、周辺設計修正
  3. 設計資産が古いことに起因する“隠れた問題”への対策
人物
この3軸で方針を固めるのが“iReDevice”の手法です。ということでこれを踏まえた開発フローをご紹介したいと思います。







事前検討こそが最重要!!

人物
これが、“iReDevice”の置き換え開発フローです! まず重要なのは、最初の「開発フロー1 事前検討」です。ここで方針が決まるかどうかが開発成否に直結します。OKIアイディエスが最重視しており、他社との差別化ポイントです。

iReDeviceの置き換え開発フロー

人物
事前検討が大切なんですね。方針をがっちり固める必要があると。
人物
そしてもう1つ重要なのが「開発フロー6 SIM検証」です。今日は事前検討とSIM検証にフォーカスを当てて説明しましょうか。
全てをここで語るにはあまりにもながーーーい時間がかかります。
人物
それで、まずは「開発フロー1 事前検討」ですが、何をするんでしょうか。機能の等価性保証という点で考えれば、現行機の仕様は把握しておきたいですから、当時の資料や開発環境はあるといいですよね。
人物
置き換え開発は、置き換え後の等価性を保証する開発であり、比較対象となる置き換え前の“正解値”が必要です。“正解値”=「信頼できる現行の資料やデータ」が残っているかが肝心ですね。状況を把握しリスクを明確化するためのスクリーニングシートを用意しました。

スクリーニングシート

人物
でも、見つからない場合やわからない場合もありえますよね。そういう時は“正解値”を作るしかないんでしょうか?この部分は開発のリスクになりそうです。
人物
資料の有無や最終版であるかの確認は非常に大事です。基本的に、最新版の資料やデータが残っていない場合は、リスクが高くなります。何度確認しても最新版かどうか分からず、“正解値”として扱えない場合は、“正解値”を作るための工程や作業を計画に織り込まなければなりません。
それでは、スクリーニングシートに記入できたら、リスク分析を行います。

リスク分析

人物
なるほど、スクリーニングシートの結果を上の表のようにリスク付けしていくんですね。ここまでくれば、開発の方針が立てられそうです。
人物
方針を確定させるには、あともう一息ですよ。本当にターゲットデバイスへ置き換え可能なのか要チェックです。まず、現行機のFPGAのデザインや合成環境が本当に“正解値”として扱えるか、論理合成、FPGA書き込みデータとのチェックサム比較で確認します。一致すればソースコードと合成環境の“正解値”が得られたことになります。もし一致しない場合は、最新資料の確認・捜索、当時の合成環境との差異確認を繰り返します。もしダメなら他のデバイスを当たらないといけません。

事前検討・解析項目

人物
現在使用しているIPが置き換え可能かどうか、置き換え後に使用するIPの選定を行うのもやらないとじゃないですか?デバイスの世代が変わるとIPも変わるってさっき言ってましたよね。
人物
おっと、それも必要です。置き換えIPを仮組みして、候補デバイスに実装可能か論理合成してチェックします。端子配置など細かい点も見逃せません。大丈夫であればデバイスが確定します。
人物
そしてあともう1つ、置き換え前のデザインも要チェックです。置き換え前のRTLコードの正解値としての検証を行います。LINT検証やCDC検証、カバレッジ検証などです。

事前検討・解析項目

人物
RTLのソースコードをきっちり検証しておかないと後で合成したときに動作不具合の原因になっちゃうんですよね。
人物
RTLコードの品質はここで決まると言っても過言ではありません。そうそう、お客様が持っているRTLコードのLINT/CDC検証を行うサービスもあります。RTLコード検証サービス“RTL Valid”です。
人物
さらりと新しい宣伝を入れ込んできましたね。。。
それもまた今度教えてください。
ここまで来たら、事前検討も完了ですかね。
人物
スクリーニングシートや置き換え後のデバイスやデザインの方針が固まったらそれを置換方針書としてまとめあげます。これが開発フロー2以降の置き換え開発の“道しるべ”となるのです。
人物
まさに、この置換方針書こそが、その後の置き換え開発の命運を分けると言っても過言ではないですね!







SIM検証で等価性を保証

人物
置換方針書に従って設計を進めてきたら、置き換え前と後で本当に機能が同じなのか、検証しなければなりません。
人物
それが、この「開発フロー6 SIM検証」です。RTL論理レベルでシミュレーション動作を比較検証しますよ。具体的にはシミュレーションによる波形比較とシナリオとタスクによるログ比較の2つを実施するのです。
人物
波形比較って、波形を見てどんなことをするんですか?
人物
同じシナリオを、置き換え前と置き換え後のRTLそれぞれに流して、下のようなシミュレータ上で出力される信号の波形を並べて、違いがないかをチェックします。たとえば、IPの置き換えによるインターフェースの差や非同期回路の修正部分など、意図した変更なのかそうでないのかを確認します。

シミュレータ

人物
おお、矩形波が見えますね。この赤い部分は?
人物
それはIPの置き換えによるI/Fの違いとCDCの対策を行った部分ですね。これが意図した差異なのか、デザイン修正時に作成する修正方式設計書にどの様に影響がでるのかが記載してあれば、悩むことなく判別できます。
人物
なるほど、なるほど。違う波形が出たところが修正部分なんですね。あともう1つのログ比較は?
人物
波形比較と並行して、BRAMやレジスタ、外部のメモリー(DDRやSRAM)へのアクセス履歴、いわゆるログも比較します。ここでも置き換え前と置き換え後で全く同じ動きか確認します。
人物
波形とログ、この2つの側面から検証することで、不具合を見落とさないようにしているんですね。まさに死角なしの“検証”ですね!
人物
これらの比較検証を目標のカバレッジ率まで行うことで、開発が完了するのです!







最後に

人物
今回、FPGAの置き換え開発の中でも特に「事前検討」と「SIM検証」が重要ということがよく分かりました。どちらも根気が要りますね。
人物
FPGAの置き換え開発で最も重要なポイントは、
「置き換え前と置き換え後のソフトウェア互換性」、
「デバイス変更によるIPの置き換え」、
「FPGA置き換え前のデザインに隠れた問題の対策」です。
人物
最初に“正解値”を明確にし、しっかりと方針を立てること。そしてSIM検証で等価性をきっちり保証することで、置き換え開発の不安を払拭できますね。
人物
ズバリ、置き換え開発は“等価性保証開発”です。様々な領域でFPGA設計開発を行いノウハウを培ってきたOKIアイディエスだからこそ、システムの維持管理や部品のEOLに悩むお客様の一助になれると信じています。
人物
「リバースエンジニアリング&マイグレーション統合サービス“N-Process”」と「FPGA置き換え開発サービス“iReDevice”」、どちらも困っている方の力になれるサービスですね。
人物
ところで小野くん、後ろに何かいますよ?
人物
え?誰もいませんけど…?不意に怖がらせようとしたってそうはいきませんよ。変な冗談ばかり言っているとボスも置き換えされてしまいますよ?
人物
ちょっと?それはどういう意味ですかな?
人物
もう置き換え開発も怪談も怖くないですよ!FPGAやデバイスの置き換えでお困りの方は、ぜひご相談ください!
人物
次回のブログ更新は10月を予定しています。
お楽しみに!







おまけ:専門用語解説コーナー

人物
「この記事、専門用語てんこ盛りだな~」と思ったあなたのために、簡単に解説します!

CDC(Clock Domain Crossing)検証
デジタル回路設計(特にFPGAやASIC設計)において、異なるクロックドメイン間で信号やデータを受け渡す際に発生する問題を検出・解析し、安全性を確保するための検証手法のこと。

BRAM(Block Random Access Memory)
FPGA内部のメモリー。キャッシュや行列計算など一時的なデータを保存しておける。

SRAM(Static Random Access Memory)
コンピューターや電子機器で使われる一種の半導体メモリー。電源が入っている間は内容を維持し続けることができる。一時的なデータの保管場所に使用される。

DDR(Double Data Rate)
コンピューターなどで使われるメモリーの一種。通常のSDRAMは、1クロックの「立ち上がり」だけでデータ転送する。DDRメモリーは、クロック信号の立ち上がりと立ち下がりの「両方」でデータを転送する。同じクロック周波数でも2倍のデータ転送速度を実現できる。

FPGA(Field Programmable Gate Array)
半導体の一種。プログラミングで回路を書き換えることで、ユーザー独自の回路を作れる半導体。

EOL(End Of Life)
部品の“生産終了”のこと。メーカーのサポートも打ち切られてしまうので、みんな悩んでいる。

IP(Intellectual Property)コア
よく使う機能を回路設計の部品としてまとめ、再利用できる「回路ブロック」のこと。

RTL(Register Transfer Level)コード
FPGAをどのような回路にするかが書かれたプログラム。設計図みたいなもの。内部の動きを細かく指示する“回路構造の説明書”

LINT検証
FPGA設計におけるコードの“書き間違い”や文法などのミスを検出する。

カバレッジ検証(カバレッジ率)
テスト範囲がどの程度網羅できているかを確認する検証。どのくらい網羅できているかカバレッジ率で表す。

シミュレーション波形比較
FPGAが計算した結果をグラフで元デザインと置き換え後を並べてチェックする作業。理科の実験で結果が同じか比べるイメージ。

正解値
デバイス置き換え開発で“絶対に目指すべきお手本”。元の設計や設定情報そのもの。

チェックサム
データが正しく伝わったかどうかを簡単に確かめる仕掛け。間違いを見つけるチェック用の数字を計算し、これをデータの末尾に付けて送信、届いた先で再計算&チェックする。

マイグレーション
既存システムやソフトウェア、データなどを別の環境に移転したり、新しい環境に移行すること。

リバースエンジニアリング
設計図や資料がない中、部品や製品を分解して、どのような部品やプログラムで構成されているのか調べること。

2025年の崖
日本企業の古いシステムが人材不足などの理由で刷新できず、取り残されてしまう問題。放っておくと大きな損失となる。

  • 記載されている会社名、製品名は、各社の商標または登録商標です。
  • ここに記載されている仕様、デザインなどは予告なしに変更する場合があります。
  • YouTube

お問い合わせ

お問い合わせ