HOT TOPIX

 
SIEMENS
s2c
 

「こんなツールを探してた」富士通、5G向けベースバンド開発をSilexicaの「SLX」で大幅改善

2019年7月5日、各種海外EDA製品を取り扱う株式会社ネクストリームは、新横浜のホテルでプライベートセミナ「Nextream Solution Seminar 2019」を開催。100名近くの参加者を集めた。

イベントWebページ

ここでは同セミナーの最終セッションとして行われた事例講演「携帯電話基地局ベースバンド処理開発へのSLX適用事例」についてレポートする。講演者は、富士通株式会社 ネットワークプロダクト事業本部 モバイルネットワーク事業部 シニアマネージャ 小野 義之 氏。


nextreme2019.jpeg

富士通 小野氏の講演は、5G向けの携帯基地局のベースバンド開発にネクストリームの取り扱うSilexica社のソフトウェア開発ツール「SLX」を活用したというもの。本来「SLX」は、マルチコア・プラットフォーム向けのソフトウェア開発に用いられるツールで、シングルコア向けに開発されたソフトウェアのマルチコアへの移植などで重宝されているが、今回の事例はファームウェアの解析に「SLX」を使ったという内容となる。

小野氏は入社以来、組み込みファームウェア開発一本というエンジニアでDSPによるリアルタイム処理の専門家。現在はシステムアーキテクトとして開発に従事しながら携帯基地局のベースバンド開発のあり方を追求している。

小野氏によると、5G基地局のベースベンド開発は厳しいリアルタイム性能の要求や、性能要求の異なるサービスの混在を背景とした設計の複雑さなど、これまでの3G、4G以上に大きな課題が多く、その開発費も膨大なものになりつつある。中でも小野氏が一番難しいと感じているのは「デバイスの性能をいかに引き出すか」という課題で、これが開発費高騰の原因になっているという。

「デバイス性能を引き出す」とは、すなわち基地局で使うチップをいかに上手く使いこなすかを意味するが、小野氏によると最近は複数のCPUと複数のDSPさらに数種類のASICアクセラレータがワンチップ化されているような複雑な大規模SoCが主流で、ハードウェアとして扱いが非常に難しくなってきているとの事。小野氏はその実情を以下のような例を挙げながら説明した。

・CPUとDSPのリアルタイム性能の違い:
 →CPUとDSPでは3倍から10倍近い差がある
・マルチコア化/ヘテロジニアス構成により顕在化するデータの衝突:
 →複数のバスに数十個のCPUコアと十数個のDSPコア
・キャッシュコヒーレンシの問題:
 →データフローを設計しきれずデータの衝突が起こりレイテンシを悪化させる
・メモリアクセス・レイテンシ:
 →多段キャッシュ構成によりレイテンシの差が大きくなる

nextreme2019-02.png

小野氏曰く、CPUとDSPのコアの性能は上がってきていても、外のメモリアクセス、キャッシュのメモリアクセスがそれについて来ていないのが現状。そのため、いかにデータアクセスを少なくするか?そしていかにデータ衝突を回避するか?といった、データフロー設計がデバイス性能を引き出す(=CPU/DSPの使用効率を上げる)リアルタイム設計の最重要ポイントとなってくるとの事。小野氏は、CPU/DSPのコアが進化すればするほど、メモリアクセスのレイテンシの問題はより大きな影響を及ぼすようになると付け加えた。

実際の開発の現場はどういった状況かというと、データ衝突を机上で見積もる事はほぼ不可能というくらいデータフローの設計が難しくなっていると小野氏。各処理の起動タイミングをイベント駆動型で考える難しさに加え、DSPだけではなくCPUも使って処理をするとなると、ある程度の予測はできたとしても正確に性能を見積ることは非常に難しく、結果的に設計段階では分からなかった事がシステム検証の段階で発覚し、再設計を強いられるといった事が起こるという。そこでこの事態を打開すべく取り組んできた中で、辿り着いた一つの答えがSilexicaのソフトウェア開発向けツール「SLX」の活用だった。

まず小野氏は上述した状況を踏まえ、不可能に近い机上検討によるデータ衝突の見積もりは諦めた。代わりにとりあえずファームウェアのコードを書いてみて、コードのロジック検証の段階で衝突する可能性のある箇所を分析するというやり方に変えた。実機動作を予測するデバイスシミュレーションでは時間が足りないので、細かいハードの動きはともかくファームウェアを論理的な観点でシミュレーションし、リードエラーや衝突の可能性をチェックした。ここで利用したのがSilexicaの「SLX」で、どの処理タスクからどのデータに何回リード/ライトを行ったか全てのデータアクセスを「SLX」を使ってモニタした。

小野氏によると、当初はシングルコア向けのソフトウェアをマルチコア向けにマルチスレッド化するツールとして紹介された「SLX」だったが、マルチスレッド化できるということは全てのデータアクセスをモニタしているはずと、ソフトウェアの解析ツールとしての可能性を見出し様々な機能の改修をSilexicaに依頼。約1年半の間、様々なツールの改修を経て現在の適用に至ったとのことで、「SLX」によってデータ衝突箇所を見つけ、アーキテクチャやデータ構造を変更するというプロセスで、データフローで衝突が起きないファームウェアを開発する事が可能となったという。

nextreme2019-03.png
nextreme2019-04.png

なお、富士通ではLinuxシミュレーションでロジック検証したファームウェアをそのままデバイスに実装できるコンバートツールを独自に用意。ファームウェアを基礎設計する段階からロジック実装と「SLX」を用いた性能評価を行い、そのイタレーションを回すことで設計工程の早期段階でアーキテクチャの改修が可能となった。

これにより後工程の評価工程での改修が激減。副次効果としてテ?ータ破壊やデータ競合による不正動作を根絶する事もできたという。小野氏によると「SLX」により開発プロセスを改善する事で、性能改善に関わる開発費を40%程度削減できたという話だ。

nextreme2019-05.png

講演の終わりに聴講者からの質問に対し小野氏は、ファームウェア・アーキテクトの頭の中を可視化するツールをずっと探していたが見つけられなかったとした上で、「SLX」はSilexicaの対応のおかげで良いファームウェアの解析ツールになったとコメント。「今のやり方が正解とは限らない。技術の進化に合わせて開発の仕方も変えて行かなければならない。」という言葉で小野氏は講演を締めた。
 

ページの先頭へ