はじめに

SystemVerilogでアナログ信号の実数値表現を扱う際、まれに wreal というネット型を見かけます。筆者自身もかつて、この wreal を使って何ができるか調べていた時期がありました。（正直、あまり必要もないのに無理やり使ったりした事もあります。）しかし、後になって IEEE 1800系のSystemVerilog標準には wreal が存在しない という事実に直面し、「では、あの時使っていた“あれ”は一体何だったのだろう？」と一時期モヤモヤを抱えていました。

このwrealは、業界では事実上の標準として流通している一方で、その出自やツール間の挙動の違いが初学者を混乱させる大きな要因となっています。本記事では、このwrealにまつわる謎を解き明かすべく、その技術的な側面だけでなく、普及したビジネス的な背景にも踏み込み、生い立ちと現状、標準規格での代替手段、そして将来の展望を多角的に解説します。

`wreal` とは何か、なぜ生まれたか

技術的定義: 語源は wire‐real。Verilog-AMS LRMに由来し、連続時間ドメインの電圧・電流などを実数スカラーとして扱うためのネット型です。
生まれた背景: 2000年代前半、半導体の集積化が進み、アナログとデジタルが混在したSoC（System‐on‐a‐Chip）の検証が急務となりました。SPICEによるフルアナログシミュレーションは精度が高い一方、非常に低速で、大規模なデジタル回路を含む検証には不向きでした。この「ミックスドシグナル検証の壁」を打ち破るため、高速なデジタルシミュレータ上でアナログ動作を近似するwrealが登場しました。

`wreal` が一時期推進された理由 ― Cadenceの戦略

wrealが「標準ではないのに一時期使われていた」最大の理由は、EDAベンダであるCadenceが、技術的優位性と巧みなビジネス戦略を組み合わせて強力に推進したことにあります。

1. ベンダー戦略としての`wreal`

2000年代初頭のミックスドシグナル検証需要の急増期、Cadenceは標準化を待たずにwrealを自社ツールに先行実装しました。これにより「今すぐ使える」ソリューションとして市場に浸透させ、競争優位を確立しました。

ツールの先行展開: Incisive（現 Xcelium）やSpectre-AMSなどのシミュレータでwrealを積極的にサポート。
エコシステムの構築: トレーニングやサポート体制を充実させると同時に、IPベンダーにwrealベースのモデル作成を推奨。
ロックイン効果: 結果として、ユーザーがCadence環境から離れにくい「ベンダーロックイン」状況を創出しました。

2. 標準化への絶妙な距離感

Cadenceは表向きは標準化に協力的でしたが、同時に便利な独自拡張機能を提供することで差別化を図りました。「標準にも準拠するが、Cadenceツールならもっと便利で高機能」という立ち位置を確立し、自社製品の魅力を高めました。

3. 業界への影響

この戦略の結果、多くのIPベンダーがCadence環境向けにwrealベースのモデルを提供するようになり、これが事実上の標準（デファクトスタンダード）として定着。後発の他社EDAツールも、設計資産の互換性を確保するためにwrealをサポートせざるを得ない状況が生まれました。

`wreal` がもたらした光と影

ポジティブな面

イノベーションの加速: ある程度は、ミックスドシグナル検証の普及を早め、複雑なSoC開発に貢献したかもしれません。
実用性の提供: 標準化を待てない現場のニーズに、実用的な機能を素早く提供しました。

ネガティブな面

移植性の低下: wrealとその独自拡張に依存したコードは、他のEDAツールで再利用するのが困難になりました。

保守コストの増大: 特定のシミュレータに依存するコードが量産され、メンテナンスを複雑化させました。

// ベンダー依存コードが量産されてしまった悲劇
`ifdef CADENCE_SIMULATOR
    // Cadence独自のwreal-sum解決機能付きネット型を宣言
    wreal current_sum; // `wrealsum`と通称される型
`else
    `ifdef SYNOPSYS_SIMULATOR
        // Synopsys向けの代替実装が必要
    `else
        $error("This IP requires a supported simulator.");
    `endif
`endif

SystemVerilog 標準での代替策: UDR nettype

幸い、SystemVerilog-2012以降の標準機能である ユーザ定義nettype (UDR) を使えば、wrealとその拡張機能を、移植性と信頼性の高い形で実現できます。

例えば、Cadenceのwrealネットにsum解決関数を適用した機能（通称 wreal-sum）は、UDRを使えば以下のように標準準拠で記述できます。

// UDRによるwreal-sum相当の標準準拠な実装例

// 1. データ型を定義
typedef real current_t;

// 2. 解決関数を定義 (複数ドライバの値を合計する)
//    引数は開配列 (open array) `drivers[]` を使います
function automatic real resolve_current_sum(input real drivers[]);
  real sum = 0.0;
  foreach (drivers[i]) sum += drivers[i];
  return sum;
endfunction

// 3. データ型と解決関数を紐付けたnettypeを定義
nettype current_t wreal_sum_net with resolve_current_sum;

// 4. 定義したnettypeの使用例
module current_summing_node;
    wreal_sum_net i_node; // 複数の電流源が接続されるノード
    
    // 複数のドライバから値を代入
    assign i_node = 1.5e-6; // 電流源1 (1.5uA)
    assign i_node = 2.3e-6; // 電流源2 (2.3uA)
    
    // シミュレーションでは、i_nodeの値は解決関数により 3.8e-6 になる
endmodule

この方法なら、どのEDAツールでも同じように動作することが保証されます。

現在の状況変化と将来展望

興味深いことに、近年はwrealを推進してきたCadence自身も、標準準拠の方向へ完全にシフトしています。

IEEE 1800.1への積極的な貢献: ワーキンググループに参加し、自社の知見を標準化プロセスに提供しています。
ユーザーからの圧力: マルチベンダー環境での設計が一般化し、IPの移植性に対する要求が高まっています。
競合他社の追い上げ: 他社もwreal互換機能を実装し、独自拡張による差別化の効果が薄れています。

IEEE P1800.1 WG（実質的な開発は Accellera） では、SystemVerilogとVerilog-AMSの統合が議論されており、承認目標は2026年とされています。これが実現すれば、長年の懸案だったwreal相当の機能が正式に標準化され、ツール間の互換性が劇的に向上するでしょう。

注記: 標準化プロセスは遅延が常態化しており、この時期は変更される可能性があります。

まとめと教訓

wrealの歴史は、単なる技術仕様の話ではなく、ビジネス戦略、標準化の重要性、そして業界の力学が絡み合った物語です。

技術的結論: wrealはSystemVerilog標準ではありません。移植性と将来性を考えるなら、今からでもUDR nettypeで記述すべきです。
教訓:
1. 標準化の重要性: ベンダー独自拡張への過度な依存は、長期的に見て技術的負債となるリスクがあります。
2. 移行コスト: 一度広まった「疑似標準」から標準準拠の技術へ移行するには、大きな労力とコストがかかります。
3. バランス感覚: 迅速なイノベーションと、オープンな標準への準拠。このバランスを取ることが、健全な技術エコシステムの鍵です。
4. EDAベンターのビジネス戦略にだまされない: 新しい事を導入する時には、EDAベンターのビジネス戦略なのか、自分たちにとってほんとうに役に立つ事なのか、あとで後悔しないためによくよく考える必要があります。

参考資料

以上