上週在IBIS summit of 2016 DesignCon會中，我們宣讀並分享了最近開發”Ibis to Spice”流程的經驗，反應相當熱烈；在這篇貼文裡，我們集錄在宣讀末之問答階段所提的問題及討論，以供未能有機會親身參與讀者之參考。

• 問：免費版仿真器裡有IBIS parser嗎？
  • 答： 沒有。據我所知的免費仿真器裡都沒有IBIS parser, 更有甚者，它們在寫此貼文的同時跟本就不支援IBIS元件。話雖如此， 有興趣的讀者不妨參考也是開源的pyIbis看有否可利用之處；再者，跟據IBIS官網，只要花約美金兩千五就可拿到公版Ibis Parser的源碼來做商品化的使用。我們（使必信科技）本身是有跨平台的IBIS Parser以在程式及此流程裡直接使用。

• 問：我在Berkeley Spice3f5的手冊裡沒有看到有ASRC元件？
  • 答： 請參考NgSpice; 免費仿真器、諸如NgSpice, EiSpice, LTSpice及TISpice都是由Berkeley Spice的原碼所加以衍伸改進而成，故雖在文件語法上或有些許不同，但我們所舉出的理論應都只要做微幅的語法改變就可在這些仿真器上運作。

• 問：所提供的範例是否只適用於上升及下降波形為對稱的情形？
  • 答：並不是這樣的。我們所提供的範例之初便有一段是將輸入的類比波形轉換成數位信號的設定。這轉換是透過偵測穿越某一臨界電壓值而達成的；一旦轉成數位信號， 其上升及下降沿的維時便很短， 故與波型是否對稱、或 Duty Cycle是否是50%無關。

• 問：所提供的範例是否適用於超頻的情況？
  • 答：在IBIS的官方規格文件裡，並未對在超頻情況下仿真器該如何運作來做規範；故在超頻的情況，不同的仿真器就很有可能會有不同的輸出結果。理想上，吾人應設計模型運作使其在超頻的情況下輸入、輸出電流都能保持連續性；也就是造成的節點電壓也會連續而不會有突波的情況發生。我相信這種機制是有可能外加於現有的範例而達到的。。。比如說利用電容來和緩波形等等；在所提供的範例裡，目前並沒有這種機制來支援超頻的情形。

• 問：如果我對轉出的模型仿真相當長的時間、比如說一微秒，會有問題嗎？
  • 答：在實作做程中，我們發現如果ASRC的變數值很小。。。比如說像我們仿真時時步的ps(1E-12)的程度,則仿真器會將其捨去而造成結果的不正確。這也就是為什麼我們需事先將此值及相對應的切換參數Ku/Kd都予以放大的原因。若以一奈秒1ns為基準，則1ps及1us相對應的值是1E-3及1E3倍。。。都不是太大或太小，仿真器也應就不會將其捨去。所以我想這種情況下、即使進行一微秒的仿真，也應該不會有任何問題。

• 問：為什麼會需要用到傳輸線？ 仿真器裡不是都有各節點的記錄嗎？
  • 答：的確一般在仿真器的內部，都會有一個陣列來儲存各節點過去幾時步的電壓資料；所以比如說如說編程者決定用Trapezoidal rule來算一階導數的話，也都能在那裡找到前兩時步的資料。但我們這裡的建模完全是使用現有Spice的語法及元件來完成，也就是說，我們無法透過C／C++等來存取仿真器內部的陣列資料。如果有需要前數點的資料的話，料想的做法是用數段無損T-Element 元件串列起來，則在每兩段線中間連接的節點，都可取到幾個時步前的電壓值。就是說：藉由串連兩段傳輸線，吾人應就可找到前一及前二時步的值而加以運用。

• 問：為什麼會需要微調來避免突波？轉換係數不是應都已達到穩態了嗎？
  • 答：理論上的確是如此。在未超頻的情況下，一般在做另一向的波形變換之前（比如說開始上升或下降），Buffer應都已達到穩態值。也就是說，KU應是達到1.0值而使pull-up branch能全力供應電流而KD於此同時是0.0使得下拉的pull-down是呈開路的情況。我們之所以需有微調的部份完全是因為在此我們是利用Spice現有的元件來組成這模型的，而非是理論上的需要。有興趣的讀者不妨可Comment掉所提供範例裡微調的部份便可發現突波的出現。若有其它更好可濾此突波的方法，也煩請留言告知或分享。

• 問：您下一步打算做些什麼改進？
  • 答：我們打算繼續向在以免費仿真器上提供系統分析能力的目標前進。以NgSpice為例， 若要在其它加入如IBIS等新元件的支援，一般有三種途徑：
    1. 直接加入仿真器內部做成如R／L／C般之原生元件：這個方法開發者需對仿真器內部的資料結構、運作流程甚至是仿真的原理都有相當的知識；如果成功的話仿真速度將會最快，但也會需要較久的時間來開發。一般是得用C／C++語言來進行編程。
    2. 透過Code-Model的延伸方法來加入：同樣得用C/C++來編程，但因為透過的是XSpice的延伸方式，並不需要去動到基本的仿真器架構及源碼；所開發出來的Code-Model是動態函式庫的模式，故可直接被現有的公版仿真器所使用；唯在開發及偵錯的過程可能較為麻煩。。因得先attach到在進行中的執行緒。不過這是開發者需要傷神。。。使用者則不用去碰到處理這種問題。
    3. 用ASRC元件在仿真器外建模：這就是我們這幾篇貼文所提到的理論及方法；雖是可行，但只能做驗證用，因為仿真起來速度有其限制。

現在公版的NgSpice裡，尚付之闕如的是：IBIS, W-element及S-參數的元件，有了這些元件的支援，吾人便可用其做很多系統上的仿真及分析。我們打算在接下來的時間以上述途徑“2”（Code-Model)的方式來加入對這些元件的原生支援。