～モダンC++対応の現状と、新たな展望～
本記事は前編・後編の2部構成を予定しており、前編ではSystemCの停滞感やモダンC++との付き合い方、そしてHigh-Level Synthesis（HLS）の現状を整理します。後編では、他言語ベースHDL（Rust、Python、Chiselなど）の可能性 や、新規に高位合成ツールを作るならどの言語がベースとして有力か(個人的妄想) といった、より広い視点の話題を取り上げる予定です。
まずはこの前編で、SystemCが直面している課題と可能性を俯瞰してみましょう。
1. SystemCとは？
1-1. C++をベースとしたハードウェア設計手法
SystemCは、C++をベースにしたハードウェア記述・システム設計用のライブラリ／言語拡張です。約20年ほど前に「ハードウェアをより高い抽象度で記述しよう」という流れから生まれました。当時は、ハードウェア設計とソフトウェア開発の橋渡しをする存在として、大いに期待が寄せられていました。
- Transaction Level Modeling (TLM) による高レベル設計・検証
- 高位合成（HLS） ツールとの連携
- C++上でのモデル化によるソフトウェアエンジニアとの協業促進
などが主な特徴です。
補足
近年ではSystemC-AMSという拡張も存在し、アナログ/ミックスドシグナル要素をシステムレベルでモデリングできるようにする取り組みも進められています。しかし、こちらも大規模な導入例はまだ多くなく、発展途上という印象です。
1-2. SystemCが対応しているC++バージョンの変遷
歴史的背景：C++98/C++03がベース
SystemCは歴史的にC++98/C++03の仕様をベースとしており、C++11以降のモダンな言語機能には十分追随していないのが現状です。Accellera Systems Initiativeからは2.3.x系がリリースされてきましたが、リリース間隔が数年単位と長めであるため、モダンC++への追随が遅れている印象を持つ方も多いでしょう。結果として、最新のC++機能をフルに活かせるとは言い難い状況です。
筆者の経験
筆者は過去にSystemC 2.3.3を使ったプロジェクトに参加し、コンパイラとしてC++14を設定してビルドを行いました。当時は「最新」としてC++14を使いましたが、一部のモダンC++機能が限定的にしか活用できず、「SystemC側が対応しきれていない」 という差を感じました。
SystemC 2.3.3（C++11ターゲット、2017年頃）
- 公式にはC++11をターゲットとして設計され、C++11が最もテストされている状況。
- C++14やC++17でもビルド可能なケースはあるが、正式対応ではないため、非推奨機能の削除などでビルドエラーが発生するリスクが高い。
- 安定性を重視するならC++11、少しだけ新しさを取り入れたい場合は十分なテストの上でC++14 を利用するのが無難。
SystemC 2.3.4（2020年リリース）
- C++11の一部機能を公式サポートとして改良が加えられ、メモリ使用効率やスケジューリングの面で性能が改善。
- C++98/03環境でも動作するよう後方互換性が維持され、CMakeビルドシステムが正式にサポートされるなど利便性が向上。
- C++17でもコンパイル可能との報告があるものの、公式サポートの中心はC++14 まで。C++17以降を使用する場合は互換性問題に注意が必要。
C++17使用時の注意点 (SystemC 2.3.4)
- 公式対応の範囲: C++11/14が中心で、C++17はテスト不足。
- 非推奨機能の削除: C++17で廃止された古い機能がSystemC内で使われているとビルドエラーに。
- コンパイラ依存: 最新GCCやClangでは比較的問題少ないが、古いコンパイラだとエラーが多発しやすい。
- 既知の問題: ヘッダーのインクルード順や型の扱い変更でランタイム不具合が起きる可能性。
SystemC 3.0.1（2023年リリース）
-
C++17が最低要件となり、
std::string_viewなどC++17機能が一部で採用。 - しかし多くの箇所で
const char*が依然として使われ、モダンC++対応は部分的に留まる。 - 今後も更新はあると見られるが、最新のC++機能をフル活用するには制約が大きい のが実情。
ワンポイント
TLMを使ったシステムレベルのシミュレーションや、ソフトウェア／ハードウェア協調検証においては依然としてSystemCが有力な選択肢です。とはいえ、モダンC++へ移行したいプロジェクトでは、各バージョンのサポート範囲やコンパイラとの相性を事前に検討する必要があります。
2. 停滞を感じる3つの理由
2-1. アップデートの停滞感
SystemCのリリースは2.3.3（2017年頃）→ 2.3.4（2020年）→ 3.0.1（2023年） といずれも数年単位。
- モダンC++への追随がほとんどなく、「古いまま停滞している」 印象を持たれがち
- 最新のC++標準（C++17/20など）を使いたい場合、バージョン選択や互換性検証に大きな手間がかかる
2-2. 高位合成ツール（HLS）の限界
SystemCが注目される理由の一つは「高位合成（HLS）との連携」ですが、近年大きなブレイクスルーはあまり見られません。
- 「ソフトウェア感覚で書けば高効率な回路を自動生成できる」という理想は遠く、最適化テクニックが人に依存しがち
- 主要EDAベンダーのHLSツールも成熟しているが、決定的な「救世主」には至っていない
- 「HLSをやる＝SystemCを学ぶ」 という図式が弱まり、別のアプローチ(MATLAB/Simulinkなど)が選択される場合が増加
2-3. 求人広告の減少
近年、AIやRISC-Vなど新しい技術が注目される中で、SystemCを名指しした求人は減少傾向にあると感じます。
- ハードウェア記述言語としてはVerilog/SystemVerilogが主流
- ソフトウェア分野はPythonやGo、Rustなどが台頭
- 「SystemC経験者を募集」という案件があまりなく、ESLやハイレベル検証でも別の手段が増えてきた
3. SystemVerilogの最新動向
3-1. IEEE Std 1800-2023
- 2024年2月28日に公開された最新規格「IEEE Std 1800-2023」では、機能カバレッジ拡張、配列操作強化、複数行文字列対応などが追加され、設計・検証の効率化が図られている
- RTL設計と検証を統合するSystemVerilogが、今後も業界標準の地位を強化していく見込み
3-2. ミックスドシグナルへの拡張
- 2024年2月にAccellera Systems Initiativeが「SystemVerilog Mixed-Signal Interface Types Working Group」を立ち上げ
- アナログモデルとSystemVerilogデザインの連携を容易にする拡張に取り組むことを発表
- IoTや自動車など、アナログ回路を含むSoC設計が重要になる中、ミックスドシグナル対応は注目度が高い
3-3. SystemVerilogと高位合成（HLS）
- 現時点でSystemVerilogがSystemCに代わって高位合成で本格的に利用される計画は公表されていない
- 一部、Bluespec SystemVerilog（BSV）など独自拡張を使ったHLSツールが存在
- 一般的にはC言語/SystemCベースのHLSフローが依然主流
ワンポイント
SystemVerilogは検証やRTL記述の分野では進化を続けていますが、高位合成に関してはまだCやSystemCが優勢です。一方で、ミックスドシグナル対応など別軸での進化が見られるため、業界標準としての地位は今後も揺るがないでしょう。
4. 今後の展望
SystemCは停滞気味といわれながらも、
- AI向けFPGAアクセラレーションや大規模SoC設計
- TLMによる高速シミュレーション
- C++由来のライブラリ資産を取り込みやすい柔軟性
といった理由から、依然として使われ続ける可能性があります。一方、モダンC++への対応がゆるやかなため、他言語HDLや新たな高位合成手法に注目が集まりつつあるのも事実です。
後編の予告
後編では、他言語ベースHDL（Rust, Python, Chiselなど）の可能性を深掘りし、新規にHLSツールを作るならどの言語を選択すべきかという観点で議論を展開します。
ハードウェア開発はソフトウェア同様、マルチ言語・マルチフレームワーク時代へ移行する兆しがあり、そこにSystemCがどのように立ち回れるかが焦点となるでしょう。
まとめ（前編）
-
SystemCの停滞感
- C++98/03ベースの歴史的背景により、モダンC++対応が部分的。
- HLSや求人での注目度が相対的に低下。
-
それでも残る強み
- TLMを活かしたSoCシミュレーションや、C++由来のライブラリ活用。
- 一部の分野（AI/FPGAなど）では依然大きな需要がある。
-
SystemVerilogや他言語の動向
- SystemVerilogはRTL/検証分野で進化（ミックスドシグナル対応など）。
- Rust/Java/Pythonなど他言語HDLやHLSツールが注目され始めている。
-
次回予告：他言語HDLと新規HLSツール
- 後編で「Rust/Python/Chisel」といった他言語HDLの可能性
- 新規にHLSツールを作るならどの言語がベースとして有力か？
- マルチ言語＆マルチフレームワーク時代のハードウェア開発
以上がSystemCの現状を中心に整理した前編です。後編では、他言語ベースHDLや新規HLSツールの言語選択といった広がりのある話題を取り上げ、ハードウェア開発がソフトウェア同様に「マルチ言語化」しつつある現状について考察していきます。
もしSystemCやHLS、あるいは高位設計全般についてご意見や経験がありましたら、ぜひコメントやフィードバックをお寄せください。
前編はこれにて終了です。
以上