wisetop/tcad-devsim_triac
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
edac7ad0303311f4e6a849e6b59c954c7be53463
tcad-devsim_triac/project_status.md
T

24 KiB
Raw Blame History

Project Status: devsim2026

這是一份專案的狀態與交接說明文件，旨在記錄使用者的開發偏好、專案目前的架構、環境設定以及後續計畫，以便下次直接銜接。

📌 更新歷史紀錄 (Update History)

  • 2026-06-08 (完成 Phase 1~4 核心優化，啟動 Phase 5 種子探路策略)

    • Phase 1 (智慧型步長控制與提早止損)：實作了基於牛頓法迭代次數的反饋機制 (<=2次放大，==3次保持，>3次縮小)，並將 Stage 2 最大迭代次數下修至 12 次，加速失敗判定，大幅減輕了乒乓震盪 (Ping-pong effect)。
    • Phase 2 (平行化多執行緒求解器)：成功引入並啟動 Intel MKL PARDISO 稀疏矩陣求解器。在背景運作時可見 CPU 使用率達 80%~100%，記憶體使用穩定，單步求解時間從數分鐘大幅縮短至 10 幾秒，完全排除了原先 SuperLU 的單核心效能瓶頸。
    • Phase 3 (兩階段混合求解策略 Pre-conditioning)：針對極端電壓點，導入「Stage 1 寬鬆預處理 (tol=1e-1)」結合「Stage 2 嚴格收斂 (tol=1e-3)」的雙階段求解法。成功解決了高壓非線性區因為初始猜測值偏差過大而導致發散的問題。
    • Phase 4 (可控的雪崩崩潰模型 Avalanche Model)：於 new_physics.py 中掛載 Chynoweth 碰撞游離模型，並巧妙利用 edge_volume_model 機制完美將網格邊緣的雪崩電流轉換為節點的電荷生成率 (\alpha \times |J|)，同時保留了精準的 Jacobian 解析導數。
    • Phase 5 (啟動：種子電壓重啟與動態探路策略)：為解決全程掛載 Avalanche 帶來的巨大運算負擔 (單步從 14s 暴增至 40s)，將掃描腳本一分為二：
      1. solve_sweep_recon.py：關閉 Avalanche 以極速推進，每 50V 瞬間開啟 Avalanche 進行漏電流探測 (Probe) 並記錄至報表，同時利用 pickle 將該電壓點之完整狀態存為 .pkl 種子檔。
      2. solve_sweep_bv.py：讀取指定的種子檔 (例如 seed_300V.pkl) 瞬間恢復高壓狀態，並全程開啟 Avalanche 以微小步幅進行擊穿掃描。目前 recon 探路腳本正於背景高速收集數據中。

  • 2026-06-08 (完成方案 B：C++ 原始碼修改與客製化 DEVSIM Wheel 編譯)

    • C++ 原始碼修改與驗證：成功在獨立的 devsim-dev 環境中實作方案 B，於 EquationHolder.cc/hh 與 EquationCommands.cc 中加入了 SetMinError 的介面與選項註冊，將原本硬編碼的 1.0e-10 解放為可在 Python 端指定的參數 min_error。
    • 編譯挑戰排除：解決了第三方相依庫（SuperLU v5.2.2 API 兼容性問題），切換編譯器為 gcc 並引入 QUADMATH_ARCHIVE=-lquadmath 修正 128 位元浮點數的連結錯誤，修復了官方 build_standalone_wheel.sh 中未處理空白檔名的 Bug。
    • 部署與驗證：成功編譯並打包為客製化的 .whl 檔案，並於虛擬環境中完成 pip install --force-reinstall 安裝與 Python API 驗證 (min_error=1.0e-5 生效)。詳細實作紀錄請參見 devsim_min_error_implementation_notes.md。

  • 2026-06-08 10:45 (確立方案 B 的架構設計原則與物理意義探討)

    • 確立 min_error 的架構設計 (保持普遍適用性)：為兼顧掌控度與 DEVSIM 既有的向後相容性，決定不修改 C++ 全域的 1.0e-10 預設值。而是仿效現有的 variable_update 參數設計，將 min_error 做為選填參數加入 Python 的 devsim.equation() 介面。如此可讓電位方程維持嚴格的 1e-10，而載子方程可獨立放寬至 1e5，完全符合 DEVSIM 方程獨立抽象化的哲學。
    • 物理意義的對接：當載子絕對誤差遠低於室溫本質濃度 n_i \approx 10^{10} \text{ cm}^{-3} 時，強求嚴格的相對誤差是無物理意義的（完全被熱雜訊掩蓋）。將載子的 min_error 設在 10^5 量級，形同為數值求解器設定合理的「物理底噪過濾器」。
    • Flow Control 觀察 (log_damp vs positive)：log_damp 適用於指數變化（如電位），若套用於線性變化的載子，會嚴重壓縮 Newton 步長，破壞二次收斂；positive 則能保留完整的 Newton 步長以維持極速收斂，且僅在變數即將變負時才介入阻擋以維持物理合理性，是載子更新的最佳選擇。
    • 相對誤差運算機制：min_error 在底層公式中作為分母防除零的基底：$|\Delta x| / (|x| + \text{min_error})$。對於空乏區 x \approx 0 的情況，加入客製化的 min_error 可避免極微小的數值雜訊 \Delta x 被虛假放大為數百萬倍的相對誤差，使求解器能順暢收斂。

  • 2026-06-07 22:07 (方案 A 測試完成與定位偽收斂，定案採取方案 B 修改 C++ 原始碼)

    • 方案 A 測試結果與問題：執行高壓偏壓掃描至 1000V 後，發現每步僅以 1 次迭代即判為收斂，產生的 2D 電位分布極不合理。經查為設定 relative_error=1e30 後，電位方程（Poisson）的相對誤差檢查被直接忽略，且其絕對殘差小於寬鬆的 1e10 全域上限，導致 solver 在第 0 步迭代後便草率退出（偽收斂），電位未經真正求解，P-wells 電位與 Molding 電位也都呈現不正確的分布。
    • 確定接線設定 (Wiring Configuration)：
      • MT2：外接電路 0V。
      • MT1：外接電路進行高壓偏壓 sweep。
      • MRING 與 Substrate_Bottom (基底 leadframe)：完全不接外部電路（處於浮空狀態），因此在 Python 模擬中維持無 Contact 註冊狀態（自然呈現 Neumann 絕緣邊界）。
    • 定案明天執行方案 B：
      • 目標：修改 C++ 原始碼以在 devsim.equation 中增加 min_error 參數供 Python 呼叫。這樣 Electrons/Holes 方程可獨立使用 min_error=1e5 以避開空乏區載子低電位的數值雜訊；而電位方程仍保留嚴格的 1e-10，全域 relative_error 則能收緊至嚴格的 1e-3 或 1e-5，迫使 Newton 求解器進行足夠次數的迭代直至電位和載子均真正收斂。

  • 2026-06-07 21:26 (發現 DEVSIM 空乏區載子相對誤差卡死機制與應對方案)

    • 發現 DEVSIM C++ 相對誤差分母硬編碼限制：經研讀 DEVSIM C++ 原始碼，在計算各方程的相對誤差時，分母防除零的基準值 minError 在 Equation.cc 中被硬編碼為 defminError = 1.0e-10。
    • 空乏區卡死原理：在反向偏壓或 TVS 空乏區中，載子濃度 n, p 指數衰減趨近於 0（例如 $10^{-5} \text{ cm}^{-3}$）。此時，極微小的數值更新雜訊（例如 $\Delta n \approx 10^{-7}$）在除以極小的分母（$10^{-10}$）後，會被虛假放大為數千倍的相對誤差（$100,000%$）。Newton 求解器因而拒絕收斂，導致偏壓步長不斷折半卡死，此即 positive 更新法下低壓即震盪的核心原因。
    • 記錄應對方案 A & B：
      • 方案 A (純 Python 數值規避 - 優先嘗試)：在 Sweep 的 solve 參數中，將載子相對誤差限制放寬至 relative_error=1e30（實質忽略載子的相對誤差收斂判定），並同步將絕對誤差 absolute_error 收緊至 1e5 或 1e6，以保證高精度的電流守恆性（不產生假性漏電流）。
      • 方案 B (修改 C++ 原始碼並編譯)：DEVSIM 的 Equation 類別內建有 setMinError(DoubleType) 接口但未暴露給 Python。我們可以修改 EquationCommands.cc（在 createEquationCmd 增加 min_error 選項並呼叫該接口），接著以 CMake 重新編譯 Python 共享庫 .so 置換環境。此法能讓 Potential 保留 1e-10，而 Electrons/Holes 方程獲取合理的 1e5 基準值。

  • 2026-06-07 16:55 (重置方程式更新機制與放寬相對收斂標準)

    • 發現 log_damp 更新法對線性載子濃度的數學窒礙：在 Drift-Diffusion 掃描中，使用 log_damp 更新法會導致線性求解器算出的載子濃度更新量 $\Delta n$（量值在 10^{10} \sim 10^{20} 之間）被底層 LogSolutionUpdate 強制壓縮為： \Delta n_{\text{damped}} \approx 0.0259 \times \ln\left(1 + \frac{\Delta n}{0.0259}\right) \approx 0.8\text{ cm}^{-3} 這導致載子每步牛頓迭代僅被更新極微量，造成收斂速度極慢（每步相對誤差僅減小 0.2%），並陷入 5 步週期的極限環震盪而無法收斂。
    • 方程式更新法調整：將 ElectronContinuity 與 HoleContinuity 改回標準的 variable_update="positive" 更新，使 Newton 求解器在載子非負的條件下能走滿 Newton 步長，恢復快速的二次收斂；將電位方程式 PotentialEquation 的更新改為無約束的 variable_update="default"，避免電位在負值區崩潰。
    • 放寬相對誤差容許度至 1e-3 (0.1%)：分析顯示，電極與接面邊緣的低電位節點（例如 $V \approx 10^{-6}\text{ V}$）在電位微幅調整（微伏級，如 $10^{-7}\text{ V}$）時，會因為除以系統預設的 10^{-10} 底限而被虚假放大為數十百分比的「相對誤差」。將 relative_error 放寬至 $10^{-3}$（0.1%），既能滿足元件電學特性的高精度模擬要求，又能避免 Newton 求解器在極低數值區被數值殘差卡死，確保偏壓掃描能快速流暢前進。

  • 2026-06-07 15:55 (系統記憶體升級與接面/介面網格集中優化)

    • WSL 記憶體分配升級：由於 UMFPACK 直接求解器在 45 萬節點（118 萬方程組）下因 2D 矩陣填滿效應在 LU 分解時耗盡記憶體崩潰（OOM），檢查發現 WSL2 預設僅分配電腦 32GB 記憶體的 50%（約 15 GiB）。已在 Windows 主機使用者目錄寫入 .wslconfig 檔案分配 26GB 記憶體與 8GB swap，重啟 WSL 後生效。
    • 網格分布集中優化：為徹底提升計算效能並防止記憶體溢出，對網格進行了重構：
      1. 移除了在 Silicon 表面下方 6 微米區域強制均勻切成 150 奈米細網格的 Box 欄位（改為 1.5 * um 背景過渡），以過濾非接面區域的冗餘節點。
      2. 收緊 Threshold 介面細化範圍至 DistMin = 0.15 * um, DistMax = 1.0 * um，將高密度網格精準集中於二氧化矽介面旁 150 奈米窄帶內。
      3. 平滑化接面背景網格（generate_analytical_bgmesh.py），將 N_ref 提高至 2.0e17 cm^-3。
      4. 優化後總節點數預估將從 45 萬降至 58 萬，單步求解速度將從數分鐘縮短至 35 秒，且接面/介面精度依然維持在 150nm。
    • VTK 格式輸出支援：修改了靜態與掃描程式，除了原有的 Tecplot .tec 格式外，現在會同時導出 .vtm / .vtu (XML VTK) 檔案格式。這解決了 ParaView 在讀取超大網格 Tecplot 檔案時崩潰閃退的問題，為 ParaView 提供原生、順暢的讀取。

  • 2026-06-07 13:55 (載子收斂速度優化 - 改回 positive 更新)

    • 改善收斂速度：發現 ElectronContinuityEquation 與 HoleContinuityEquation 原先採用的 log_damp 更新法在接近收斂時速度過慢（每步 Newton 迭代僅減少約 1% 相對誤差，導致單步需要 30 次迭代）。經評估後改回 DEVSIM 標準的 variable_update="positive"。此法可在確保載子非負的同時走完整 Newton 步長，實現二次收斂，使每步迭代次數從 30 次大幅縮減至約 4~6 次。

  • 2026-06-07 12:20 (最新發現 - 解決 17.24V 處的指數溢位崩潰)

    • 定位 17.24V 溢位原因：偏壓掃描在 17.24V 左右中斷，詳細日誌顯示在 IntrinsicElectrons 計算中發生了 exp(Potential / V_t) 浮點數溢位（當電位達到約 17.5V 時，指數值已超出雙精度浮點數極限 $1.79 \times 10^{308}$）。這是因為平衡態 Poisson 初始解中定義了依賴於電位的指數載子模型，但在高偏壓 Drift-Diffusion 掃描中已不再需要此指數關係。
    • 提出重新定義（Redefining）方案：在 0V Poisson 求解並設定好載子初始值之後，我們在 Drift-Diffusion 求解前，將 IntrinsicElectrons、IntrinsicHoles 等模型及其導數重新定義為對應的載子變數本身（例如將 IntrinsicElectrons 的公式重新設定為 Electrons ）。此舉可徹底消除空間指數電位項，防止高壓下溢位，同時使電極接觸孔的電荷模型保持物理正確與數值平滑。

  • 2026-06-07 12:00 (最新進度 - 載子收斂與漏電流精度優化)

    • 引入 charge_error 機制解決收斂發散：分析了先前偏壓掃描在 17.2V 左右因步長不斷折半而中斷的問題。發現是由於空乏區中少數載子濃度極低，微小的數值波動引起了巨大的相對誤差，導致 Newton 求解器在 relative_error 上無法收斂。我們在 DC 求解中引入了 charge_error=1e12，此參數可令 DEVSIM 忽略濃度低於 10^{12}\text{ cm}^{-3} 的節點的相對誤差檢查，從而能使用嚴格的收斂標準（relative_error=1e-5, absolute_error=1e4）順利前進。
    • 漏電流精準度修正與守恆性驗證：先前因未設置 charge_error，為了能求解成功而將 relative_error 放寬至 0.8 且 absolute_error 設為 1e10，這導致了計算中出現假性的微安級漏電流且電流量不守恆（MT1 與 MT2 電流不同）。在使用嚴格的收斂參數後，成功消消除數值殘差引起的漏電假象，重現了元件在 V < 17\text{ V} 下極低（且完全飽和）的真實阻斷狀態。

  • 2026-06-06 23:15

    • Drift-Diffusion 絕對誤差修正：修正了 solve_sweep_2d.py 中將 Drift-Diffusion 絕對收斂誤差設為 absolute_error=1.0 的 bug。將其調整為標準的 1e10 搭配 relative_error=1e-8 後即可順利收斂。
    • 防止節點暴增與記憶體崩潰 (OOM)：移成了長度達 200\ \mu\text{m} 的側壁介面（silicon_molding_side_curves）在深部的細緻化，並利用 Gmsh 的 Restrict 欄位將 0.15 * um 限制僅在 Silicon 與 Oxide 表面生效。外圍無場無載子的 Molding 區與基板深部則採用 15.0 * um 的粗網格。

1. 元件幾何與電極配置參數 (Validated Layout Dimensions)

最新確定的幾何參數（左半邊自動鏡像對稱）：

  • 晶片半寬度 (W_{DEVICE})：$356\ \mu\text{m}$。
  • 模擬總半寬度 (W_{SIM})：456\ \mu\text{m} (包含側邊各擴展 100\ \mu\text{m} 的 Molding 區)。
  • 矽區厚度：200\ \mu\text{m} (Y \in [0, 200])。
  • 二氧化矽厚度：2\ \mu\text{m} (Y \in [-2, 0])。
  • 封裝膠厚度：頂部 100\ \mu\text{m} (Y \in [-102, -2])，側邊包覆至底部 $Y = 200\ \mu\text{m}$。
  • P-wells (深度 5 um)：
    • p11：75 \sim 100\ \mu\text{m}
    • p12：120 \sim 130\ \mu\text{m} (峰值 1\times10^{17}\text{ cm}^{-3})
    • p13：150 \sim 255\ \mu\text{m}
  • N+ 區域 (深度 1 um)：
    • N+：164 \sim 185\ \mu\text{m} (位於 p13 內，中間開口位於 174.5\ \mu\text{m})
    • MRING：340 \sim 356\ \mu\text{m} (晶片最邊緣通道阻擋環)
  • 電極與接觸孔 (Vias)：
    • MT1 長板：$30 \sim 186\ \mu\text{m}$，短板：$250 \sim 295\ \mu\text{m}$。
    • MRING 頂部與側壁接觸：Y = -2\ \mu\text{m} 平面 340 \sim 356\ \mu\text{m} 及 X = 356\ \mu\text{m} 側壁。
    • 底部 Leadframe Conductor Pad：Y = 200\ \mu\text{m} 平面全寬。

2. 專案目錄結構 (Project Structure)

  • device_config.py：幾何、電極、濃度及擴散梯度設定檔。
  • generate_mesh_2d.py：利用 Gmsh Python API 生成 2D 網格，已配置 Threshold 細化限制介面與接面，輸出為 device_2d.msh。
  • generate_analytical_bgmesh.py：根據 doping gradient 生成自適應接面背景網格。
  • preview_doping_2d.py：在 DEVSIM 中加載網格、建立摻雜模型、生成 preview.tec 與 doping_2d.png。
  • physics/：物理模型資料夾，包含 new_physics.py、model_create.py。
  • solve_static_2d.py：執行零偏壓 Poisson 模擬，輸出 static_preview.vtm 等 VTK 與 Tecplot 檔案。
  • solve_sweep_2d.py：高壓 bias sweep 主程式，具備 checkpoint 與溢位重定義機制，輸出 sweep_preview_* 檔案。

3. 下一步計畫 (Next Steps)

🚨 優先行動：解決 WSL 記憶體崩潰與自動續命機制

由於模擬遇到記憶體撐爆導致 WSL 斷線的狀況，下次開機後優先執行以下三項修改：

  1. 加入 Rolling Checkpoint 自動備份與完工刪除機制：在 Sweep 迴圈中加入計數器，每 10 個成功的 Step 就覆寫一次固定檔名 (如 backup_A.dat 或 wsl_recovery_checkpoint.dat)，且當迴圈 100% 跑完後自動刪除該備份檔以節省空間。此機制獨立於 Avalanche 的種子檔。
  2. 導入主動記憶體回收：在 Sweep 迴圈內加入 import gc; gc.collect()，強制回收每一步產生的無用記憶體，從根本嘗試降低峰值記憶體 (Peak Memory) 使用量。若情況依舊，考慮進一步將 .wslconfig 的 processors 降至 4。
  3. 建立 resume_run.py 輔助腳本：撰寫一個簡短的腳本，專門用來讀取上述的 backup_A.dat，以便未來如果不幸再發生斷線，可以一鍵無縫接軌繼續跑。

1. 分析 1000V 掃描結果 (I-V 曲線與 2D 電場)

2. 評估是否需要切換至方案 B

  • 當前的 1000V 偏壓掃描採用 方案 A (放寬載子相對誤差至 1e30) 已成功收斂，且在 absolute tolerance 10^{10} 之下維持了極高精度的物理電流守恆。
  • 若未來物理模型需要更嚴格的載子相對誤差判定，可參考 第 4 節 修改 DEVSIM C++ 原始碼並重新編譯，以啟用 方案 B。

4. 空乏區收斂與載子誤差判定方案 (方案 A & B 備忘錄)

📌 背景與問題診斷

  • DEVSIM C++ 相對誤差分母硬編碼限制：經研讀 DEVSIM C++ 原始碼，在計算各方程的相對誤差時，分母防除零的基準值 minError 在 Equation.cc 中被硬編碼為 defminError = 1.0e-10： const DoubleType nrerror = n1 / (n2 + minError); (其中 n1 為該節點 Newton 更新量，n2 為該節點變數值)。
  • 空乏區卡死原理：在反向偏壓或 TVS 空乏區中，載子濃度 n, p 指數衰減趨近於 0（例如 $10^{-5} \text{ cm}^{-3}$）。此時，極微小的數值更新雜訊（例如 $\Delta n \approx 10^{-7}$）在除以極小的分母（$10^{-10}$）後，會被虛假放大為數千倍的相對誤差（$100,000%$）。Newton 求解器因而拒絕收斂，導致偏壓步長不斷折半卡死，此即 positive 更新法下低壓即震盪的核心原因。

💡 應對方案 A：純 Python 數值規避 (目前已採用並驗證成功)

  • 具體做法： 在 solve_sweep_2d.py 的 devsim.solve 呼叫中，設定： devsim.solve(type="dc", absolute_error=1e10, relative_error=1e30, charge_error=1e12, ...) 這會使載子相對誤差限制放寬至 1e30（實質忽略載子的相對誤差收斂判定），並同步將絕對誤差 absolute_error 收緊至 1e10。
  • 優點：
    • 無須編譯：完全在 Python 層面解決，不依賴 C++ 編譯環境。
    • 極速收斂：Newton 求解器不再受到空乏區微小載子雜訊的干擾，每步偏壓（50\text{ V} 步進）僅需 1 次迭代即可收斂，總掃描時間僅需 164 秒。
    • 嚴格電流守恆：由於 absolute_error=1e10 相當於約 $1.6 \times 10^{-9}\text{ A/cm}^2$，因此 MT1 與 MT2 之間的電流守恆差異極小（在 0.1\text{ V} 時驗證為 $9.93 \times 10^{-15}\text{ A}$），無假性漏電流。
  • 缺點：
    • 完全關閉了載子濃度的相對誤差檢查，若在某些敏感區域發生數值震盪但殘差較小，可能無法被相對誤差指標檢出。

🛠️ 應對方案 B：修改 DEVSIM C++ 原始碼並編譯 (目前已成功實作並採用)

為滿足後續模擬對於嚴密相對誤差收斂判定的需求，我們已於 devsim-dev 目錄下完成對 DEVSIM 原始碼的修改、編譯及封裝。

1. 原始碼修改與編譯重點 (詳閱 devsim_min_error_implementation_notes.md)

  • 核心修改：於 EquationHolder.hh/cc 及 EquationCommands.cc 暴露 SetMinError 介面，並將其連接至 Python API 的 min_error 參數。
  • 編譯修正：降版並採用與 DEVSIM 2.0 完全相容的 SuperLU v5.2.2；於 CMake 中加入 -lquadmath 連結參數以支援擴展精度。
  • 封裝修正：修復了 build_standalone_wheel.sh 中未處理含空白檔名的 Bug，成功編譯出客製化 .whl 檔案並安裝至虛擬環境。

2. Python 端使用方式

現在我們可以在建立載子方程式時，透過 Python 設定合理的相對收斂分母下限（避開空乏區極微小載子的數值雜訊干擾）：

devsim.equation(device=device, region="Silicon", name="ElectronContinuityEquation", variable_name="Electrons", ..., min_error=1e5)

如此一來，Electrons 和 Holes 方程可獨立使用合理的 10^5 \text{ cm}^{-3} 作為防除零下限，而電位方程式 PotentialEquation 亦補上 1e-3 的下限保護，完美兼顧了物理精準度與數值極速收斂。這將成為後續 BJT / MOS 元件模擬的標準最佳作法！

🔜 未來優化與待辦事項 (To-Do & Future Optimizations)

1. 分析探路者報表 (Reconnaissance Report) 與決定 BV 掃描起點

  • 優化目標：等待背景的 solve_sweep_recon.py 跑出足夠多的 50V 檢查點。
  • 實作細節：檢視 recon_avalanche.log，觀察帶有雪崩效應的漏電流趨勢。若發現在某個區間 (如 300V 到 350V) 電流產生數個數量級的暴增，即選定該區間的起點作為種子。

2. 執行終極擊穿掃描 (Final Breakdown Sweep)

  • 優化目標：使用選定的高壓種子，精準描繪元件的 Avalanche Breakdown 曲線。
  • 實作細節：執行 python solve_sweep_bv.py --seed seed_XXXV.pkl，以 0.1V 等微小步幅，平穩推升電壓直到電流衝破 1mA。

3. BV 曲線後處理與 2D 電場熱像圖提取

  • 優化目標：將最終的 I-V 曲線可視化，並找出元件最脆弱的熱點 (Hotspot)。
  • 實作細節：將擊穿掃描的結果繪製成 I-V 曲線圖，並利用 ParaView 讀取最後一個收斂狀態的 .vtm 檔，剖析雪崩崩潰瞬間元件內部的電場集中區 (例如 P-well 邊緣或 N+ 轉角處)，做為後續 Layout 尺寸與 Doping 濃度優化的依據。

4. 腳本重構與模組化 (Refactoring Sweep and Resume)

  • 優化目標：改善目前 sweep (solve_sweep_recon.py) 與 resume (resume_run.py) 程式碼重複 (Code Duplication) 的問題，避免修改核心掃描流程或參數（例如記憶體監控）時需要在兩個檔案中重複修改。
  • 實作細節：計畫將兩支腳本合併為單一主程式，透過引入命令列參數解析 (例如 Python 的 argparse 提供 --resume 參數) 或是自動偵測 Checkpoint 檔案的方式，來動態決定是要從 0V 初始狀態開始計算，還是從存檔點接續掃描。
Reference in New Issue View Git Blame Copy Permalink