BSIM4モデルの互換性とインターフェース部分の実装について

# BSIM4モデルの互換性とインターフェース部分の実装について
─ モデルの仕組み・実装方法と、SPICE シミュレータが独自に工夫する理由 ─

---

## はじめに

**BSIM4** は、UC Berkeley が開発した MOSFET モデルで、現代の IC 設計や回路シミュレーションにおいて**事実上の標準**といえるモデルです。  
ユーザー視点では「**BSIM4モデル**なら SPICE シミュレータを問わず、同じパラメータで同じように使えるはず」と思われるかもしれません。

しかし実際には、

1. **モデルそのもの（理論式・パラメータ）はほぼ共通** ... 各 EDA ツールが同じバージョンの BSIM4 に対応し、互換性を保っている  
2. **モデルを読み出す“C/C++ 関数インターフェース”はベンダー独自** ... ソースコードレベルでは互換性なし  

という状態です。  
さらに、「BSIM4 のパラメータは数百あるが、どうやって巨大モデルカードを扱うのか」「他社ツールのモデルを流用できるのか」「FMI (Model Exchange) のように入出力を規格化する仕組みはないのか」など、現場での疑問も絶えません。

本記事では、こうした **「BSIM4モデルの互換性」** と **「実装の非互換」** がどのように両立しているのか、そして **運用面での疑問** をまとめて解説します。

---

## 1. BSIM4モデルとは何か — 理論・パラメータは共通

### ● UC Berkeley が提供するリファレンスコードの中身

UC Berkeley は BSIM4 モデルの理論式だけでなく、**リファレンスコード（C 言語）**を提供しています。このコードは、BSIM4を実装する際の参考として広く使われています。以下が主な構成です。

- **ヘッダファイル**: パラメータ構造体や定数を定義するファイル
  - `bsim4defs.h`: モデル構造体 (`BSIM4model`) とインスタンス構造体 (`BSIM4instance`) の定義
- **ソースファイル**: モデルの計算ロジックや初期化関数
  - `bsim4.c`: ドレイン電流や容量、偏微分係数を計算する主要な関数
  - `bsim4init.c`: モデルパラメータを初期化する関数

これらのファイルには、次のような機能が含まれます。

1. **パラメータの初期化**  
   - しきい電圧（`vth0`）、移動度（`u0`）、寄生容量などの初期値設定。

2. **モデル評価関数**  
   - 例: `BSIM4eval` 関数が、指定された端子電圧（`vds`、`vgs`、`vbs`）をもとにドレイン電流や微分係数（`gm`、`gds`、`gmb`）を計算。

3. **補助関数**  
   - 温度補正やチャネル長変調の計算など、詳細な物理モデルの補助ロジック。

以下は `BSIM4eval()` のような関数の典型例です。  
```c
/*======================================================================
 *  BSIM4eval():
 *  端子電圧 (vds, vgs, vbs) とモデル情報 (model, instance) をもとに
 *  ドレイン電流 Id や微分 (gm, gds, gmb) を計算する関数
 *====================================================================*/
int BSIM4eval(
    BSIM4model    *model,    // モデル全体 (プロセス/パラメータ)
    BSIM4instance *here,     // このMOSFET固有のインスタンス情報
    double vds,              // ドレイン-ソース電圧
    double vgs,              // ゲート-ソース電圧
    double vbs,              // バルク-ソース電圧
    double temperature,      // 動作温度
    double *Id,              // 出力: ドレイン電流
    double *gm,              // 出力: gm = ∂Id/∂Vgs
    double *gds,             // 出力: gds = ∂Id/∂Vds
    double *gmb              // 出力: gmb = ∂Id/∂Vbs
    /* 必要に応じて他のノイズ/容量パラメータも出力する */
)
{
    // 実際にはここで数百行～数千行の計算が入る：
    // 1) (vgs, vds, vbs) による領域分岐 (弱反転, 強反転, etc.)
    // 2) 各物理パラメータの展開 (しきい電圧, チャネル長変調, etc.)
    // 3) Id の計算
    // 4) gm, gds, gmb の計算
    // 5) 返り値を *Id, *gm, *gds, *gmb に書き込む

    // ここではダミーで戻すイメージ
    *Id  = 1.23e-4;   // 例えば 1.23e-4 [A]
    *gm  = 8.9e-5;    // [S] (∂Id/∂Vgs)
    *gds = 1.1e-5;    // [S] (∂Id/∂Vds)
    *gmb = 5.0e-6;    // [S] (∂Id/∂Vbs)

    return 0;  // 正常終了
}
```
このように、“現在の端子電圧” を引数で受け取り、**ドレイン電流** と **偏微分値** を出力として返す形が主流です。

これらのリファレンスコードは、EDA ベンダーや開発者が自社ソルバに BSIM4 を組み込む際の基盤として使用されますが、そのままでは使用されず、次節で述べるようにカスタマイズが加えられます。

### ● UC Berkeley が定義した標準モデル

BSIM4 は、MOSFET における短チャネル効果、サブスレッショルド領域、接合容量、温度依存などを細かく式で定義した**理論モデル**です。  
バージョンとして “BSIM4.6” “BSIM4.7” “BSIM4.8” などがあり、それぞれ改良やバグ修正が加わってきました。

### ● ユーザーが書く「モデルカード」はほぼ互換

```spice
.model MyNmos bsim4
+ vth0=0.5 u0=300 rdsw=150 ...
```

のように、**`.model bsim4 ...`** でしきい電圧や移動度などを設定する部分は、**いずれの SPICE シミュレータでもほぼ同じ**。  
**同じバージョンの BSIM4** に対応していれば、**同じパラメータセット**をコピペして使える“互換性”があるというわけです。

### ● それでも結果が微妙に違う場合は？

ベンダー各社が内部実装で**最適化や収束アルゴリズム**を変えているので、まったく同一の波形や数値が出るとは限りません。  
しかし、大枠の特性は同じ理論モデルに基づくため、**十分に近い結果**が得られます。

---

## 2. “インターフェースは違う”とはどういう意味？

### ● ソースコードレベルでの呼び出しがバラバラ

BSIM4 のリファレンスソース（C 言語）を Berkeley が提供しているものの、それは**必ずしも統一 API**とはなっていません。  
EDA ベンダーが**自社の SPICE ソルバ**に合わせて、

- **行列組み立て**  
- **ニュートン法ルーチン**  
- **マルチスレッド最適化**  

などを行う際、**各社が独自に C/C++ 関数やクラスを作って取り込む**ため、**API はバラバラ**です。

### ● ユーザーから見えるのは“.model bsim4”だけ

ユーザーは SPICE ネットリストに**`.model bsim4`** と書くだけで済みますが、  
実は裏側で「ベンダー独自のファイル構造やラッパ関数」で BSIM4コードが組み込まれています。  
そのため、**ソースやバイナリレベルでの流用は不可能**でも、**モデルカード（パラメータ）レベルでは互換性**が保たれているのです。

---

## 3. 他社ツールのモデルを持ち込むことはできるのか？

### ● モデルカード(パラメータ)なら可能

「シノプシスのツールで作られた BSIM4 パラメータセット」をテキストで抜き出し、Cadence ツールに貼り付ける… これは**同じバージョンの BSIM4**をサポートしていれば大抵動きます。  
Cadence は**自社の BSIM4実装コード**で「同じパラメータ」を解釈し、**近い結果**を出せる仕組みです。

### ● ソースコードやバイナリは流用不可

「シノプシス独自にビルドしたBSIM4ライブラリ」をCadenceツールが読み込む…という自動変換は行われません。  
各ベンダーが**自分のソルバ**に合わせて独自ビルドをしているため、**他社のライブラリを読み込む仕組み**はないのです。

---

## 4. MOSFETモデルを「後から関数を追加」する仕組み

### ● ソルバ開発者はリファレンスコードを改変し、追加機能を実装

Berkeley の BSIM4リファレンスは“最低限の評価関数”しか備えていない場合が多く、EDA ベンダーや自作ソルバは、

1. **モデルソースをフォーク**し  
2. **行列スタンピングやダイオード容量計算等の独自関数を追加**し  
3. **ビルドシステムに組み込む**  

という形で**後から関数を追加**します。  
こうして完成したソルバ内“BSIM4モジュール”は、ユーザーからは **“1つのモデル”** と見えますが、実際には**共通部 + 独自追加部**の複合体です。

---

## 5. BSIM4には数百パラメータ… どうやって管理する？

### ● 巨大モデルカードの現実

BSIM4 には数百のパラメータがあり、ファウンドリや企業が提供する**モデルライブラリファイル**は数千行～数万行に及ぶこともあります。  
これを**ひとつのネットリストに全部書く**と超巨大になるため、通常は**`.include`** や **`.lib`** 構文で別ファイル化しています。  
ユーザーから見れば、**大容量ライブラリ**をインクルードしておき、主要パラメータだけ上書きすれば済むので、大きな煩雑さはありません。

### ● 多くのパラメータはデフォルトあり

大半のパラメータには**デフォルト値**があるため、ユーザーが1つ1つ手打ちする必要はありません。  
ファウンドリ配布のライブラリを使い、必要箇所だけ上書きする形が実務的です。

---

## 6. プログラムコードはモデルごとに完全別々？ それとも共通？

### ● 共通フレームワーク + モデル固有構造体

SPICE 系ソルバには「パラメータを読み込み、モデルを初期化し、端子電圧を与えて電流・容量を返す」という**共通フレームワーク**があります。  
それに対し、BSIM4 / BSIM3 / PSP など**モデルごとに構造体**があり、数百のパラメータを固有に持っています。  

1. **ベンダー独自の“モデル登録”API**により、  
   - 「BSIM4モデル」は `bsim4defs.h` で定義されたパラメータリスト・評価関数を持つ  
   - 「BSIM3モデル」は `bsim3defs.h` …  

2. **共通フロー**でパラメータを割り当て、初期化し、評価時に呼び出す

こうした仕組みで、**複数のMOSFETモデル**を同じソルバの中で動作させることが可能になっています。  
つまり、**“パラメータをどう読み書きするか”は共通ロジック**、**“実際の方程式や構造体”はモデル固有**、という分担が多いわけです。

---

## 7. FMI3.0 Model Exchange (ME) と MOSFETモデルの比較

### ● FMI3.0 (ME) は「入出力やアルゴリズム呼び出し」を厳格に規定

FMI (Functional Mock-up Interface) 3.0 の Model Exchange は、  
- **状態方程式**  
  $$
  \dot{\mathbf{x}}(t) = f(\mathbf{x}, \mathbf{u}, t)
  $$  
  の入出力を標準化  
- **イベント処理や、時間積分の仕組み** も一定のルールで定義  
- $\mathbf{u}$ (入力)、$\mathbf{x}$ (状態)、$\mathbf{y}$ (出力) が規格化されたインターフェースに従う  

これにより、**どのツールで生成した FMU でも、同じインターフェースで数値解を進められる**という高い相互運用性が実現しています。

### ● MOSFETモデルは“パラメータ名・意味”だけが共通

一方、BSIM4 などの MOSFETモデルでは、  
- “チャネル長変調” や “寄生容量” などの**方程式**や**パラメータ定義**は共通だが、  
- **関数呼び出し手順**や**アルゴリズム**は、ベンダーごとに独自実装  

つまり、**FMI のような厳格API互換は存在しない**ものの、「しきい電圧や移動度といったパラメータが同じ意味を持つ」ことで、**モデルカードレベルの互換**が実現しているのです。

---

## まとめ

1. **BSIM4モデルは“理論式・パラメータ”のレベルで互換性が高い**  
   - バージョンが同じなら、各ベンダーで同等の物理効果を考慮。  
   - ユーザーが `.model bsim4 + param...` を書くと、どのツールでも似た結果が出せる。

2. **ベンダー独自のインターフェースや評価関数は共通規格化されていない**  
   - ソースやバイナリを取り込んで使うことはできず、各社がリファレンスをフォーク＆追加してソルバに組み込む形。  
   - 後から関数を追加する際は、モデルのコードをビルド前に書き換え、独自機能を加えている。

3. **数百パラメータをどう扱うか**  
   - ファウンドリなどのPDKでは巨大なモデルライブラリを `.include` 等で分割管理し、デフォルト値を活用して管理。  
   - パラメータごとの読み書きはソルバの共通フレームワークが担い、モデルごとに固有の構造体や評価関数を差し込む。

4. **FMI3.0 (ME) との対比**  
   - FMI3.0 は「モデルの入出力やアルゴリズム呼び出し」を統一した規格。  
   - MOSFETモデル（BSIM4など）は「パラメータと方程式は共通だが、API はベンダーごとに違う」という形。  
   - すなわち **“パラメータレベル”の互換性のみ**が存在し、FMI のような厳密なインターフェース規定はない。

---

**最終的に、ユーザーとしては `.model bsim4 ...` の互換性恩恵を享受し、ベンダーが内部で各自フォーク・改造を行うおかげで多彩な最適化や機能を活かせる**仕組みになっています。  
こうして「**BSIM4モデルの互換性**」と「**インターフェースの非互換**」が同時に成り立っているわけです。
```