【導讀】在用于汽車 SoC 的納米技術中，硅上的大多數缺陷都是由于時序問題造成的。因此，汽車設計中的全速覆蓋要求非常嚴格。為了滿足這些要求，工程師們付出了很多努力來獲得更高的實速覆蓋率。主要挑戰是以盡可能低的成本以高產量獲得所需質量的硅。在本文中，我們討論了與實時測試中的過度測試和測試不足相關的問題，這些問題可能會導致良率問題。我們將提供一些有助于克服這些問題的建議。
在用于汽車 SoC 的納米技術中，硅上的大多數缺陷都是由于時序問題造成的。因此，汽車設計中的全速覆蓋要求非常嚴格。為了滿足這些要求，工程師們付出了很多努力來獲得更高的實速覆蓋率。主要挑戰是以盡可能低的成本以高產量獲得所需質量的硅。在本文中，我們討論了與實時測試中的過度測試和測試不足相關的問題，這些問題可能會導致良率問題。我們將提供一些有助于克服這些問題的建議。
全速測試的主要目的是檢測硅在其工作頻率下可能發生的任何時序故障。要測試的重要部分是生成可控時鐘脈沖的邏輯，該時鐘脈沖的頻率與功能操作所需的頻率相同。提供受控時鐘脈沖的方法是通過輸入焊盤從測試器 (ATE) 提供，因為這將降低復雜性并限度地減少需要在設計中構建的額外測試邏輯。
然而，這種方案會有頻率限制，因為焊盤通常不能支持非常高頻率的時鐘。因此，片上鎖相環 (PLL) 和振蕩器用于提供時鐘脈沖。然而，不能直接使用這些的自由運行時鐘，因為首先我們必須以低頻（移位頻率）通過掃描鏈移位矢量，以功能頻率捕獲，然后以移位頻率清除數據。我們需要可控脈沖，同時以功能頻率捕獲，這可以通過使用斬波邏輯來實現。圖 1顯示了具有全速時鐘的典型時鐘架構。
圖 1： 具有全速時鐘的典型時鐘架構
對于任何 SoC，STA（靜態時序分析）簽核對于驗證時序性能是不可或缺的。時序簽核確保硅將以所需的功能頻率運行。同樣的邏輯也適用于全速測試。必須對全速模式和功能模式一起完成 STA 簽核，因為時鐘路徑在全速模式下可能不同，并且添加的測試控制邏輯也需要定時。在正常功能模式下不需要斬波邏輯，因此我們還需要滿足斬波邏輯的時序要求。
理想情況下，如果時鐘的變化是在公共路徑中完成的，那么在全速模式下關閉時序應該不是問題，例如在時鐘路徑的開始處，以便啟動和捕獲觸發器的變化是共同的，因此不會影響設計的設置和保持時序。測試控制邏輯一般工作在低頻或靜態，因此不難滿足時序要求。
典型的 SoC 時鐘方案
然而，現代 Soc 設計并不那么簡單。高性能和低泄漏要求導致設計在單個 SoC 中具有各種時鐘源，例如 PLL、振蕩器、時鐘分頻器等。根據架構，可能有許多 IO 接口在外部時鐘上運行幾個 MHz，例如 SPI、JTAG、I2C 等。因此，SoC 的不同部分可以以不同的頻率運行。
這就是事情變得復雜的地方。前面討論的用于全速時鐘的時鐘解決方案（斬波邏輯）對于以不同頻率運行的復雜芯片來說是不夠的。在全速測試中，這些復雜性會引發稱為測試不足和測試過度的問題，從而導致需要進行測試。
與功能模式下的運行頻率相比，在全速模式下以更高的頻率測試邏輯時會發生過度測試。參考圖 2，如果在全速模式下向看門狗和 RTC 等任何低頻模塊提供 pll_clock，就會發生過度測試。采用這種方法的一個關鍵原因是測試時鐘路徑的簡單性，因為這種方法只需要對功能邏輯進行的更改。在我們的示例中，我們只需要通過掃描時鐘繞過所有分頻時鐘/RC osc 時鐘/外部時鐘，而掃描時鐘又將由 pll 時鐘控制。
圖 2： 存儲器和閃存在分頻 PLL 時鐘上運行，而平臺在實際 pll_clock 下工作。內部 RC 振蕩器為 RTC（實時計數器）和看門狗定時器等塊提供時鐘，這些塊需要非常慢的時鐘頻率。像顯示大師這樣的積木既有IPS接口又有攝像頭接口。IPS 接口通常以系統頻率工作，而攝像頭邏輯以外部提供的較慢頻率時鐘工作。SPI 和 JTAG 等 IO 接口在幾 MHz 下工作。因此，SOC 的整體配置需要多個模塊在多個頻率下工作。
當在全速模式下以低于預期操作頻率的頻率測試任何邏輯時，就會發生測試不足。這種情況通常存在于無法提供與功能模式相同頻率的測試時鐘時，但同時由于較大的數據路徑延遲或技術限制而無法以高頻率關閉設計。在這種情況下，我們被迫提供較低頻率的時鐘。
因此，有必要以與功能頻率完全相同的頻率測試硅的缺陷。任何偏差都會導致過度測試或測試不足的問題：
? 當功能邏輯旨在以較低的頻率工作時，關閉較高頻率的設計以進行全速測試將影響整體設計的面積和功率。在時序關鍵設計的情況下，實時測試工具將使用高驅動強度單元，甚至可能需要低 Vt 單元來滿足這些頻率目標。
? 即使設計的時序以更高的頻率收斂，以功耗和面積為代價，我們在良率計算中也可能會不必要地悲觀。在全速測試期間可能會出現不切實際的良率下降。例如，在具有兩個時鐘域（domain1 @ 120MHz 和 domain2 @ 80MHz）的設計中，我們將整個設計的時序關閉在 120MHz 平坦處以簡化全速模式下的時鐘架構。這兩個域的所有 ATPG 模式生成都將在 120MHz 時發生。由于工藝可變性，在硅上，domain1 在 120MHz 下工作正常，但 domain2 僅在 110MHz 下工作，因此所有管芯都將被視為有缺陷的部件。盡管該芯片足以滿足功能要求，但基于全速模式故障，我們會將芯片宣布為故障芯片，這會降低我們的產量。
? 在測試不足的情況下，全速模式不能保證芯片實際工作在預期頻率。由于壞芯片可以通過全速測試，所以原先的全速測試過濾掉壞芯片的目的就落空了。在這種情況下，我們在收益率計算中會過于樂觀。
了解了缺點后，我們將重點關注在任何 SoC 中存在過度測試和測試不足的原因：
時鐘架構的簡單性
鑒于功能模式下的時鐘源如此之多，簡單的方法是在全速模式下提供少量可控測試時鐘。
圖 3： 簡單和簡單的測試時鐘解決方案是將 PLL 時鐘與外部時鐘復用，即使對于全速模式也是如此，這是一種過度測試的情況。
讓我們以 DSPI 模塊為例。該 IP 在 2 個時鐘上工作，一個 15 MHz 的外部時鐘和一個用于內部邏輯的 120MHz 功能 PLL 時鐘。如圖3所示，簡單和簡單的測試時鐘解決方案是將 PLL 時鐘與外部時鐘復用，即使對于全速模式也是如此，這是一種過度測試的情況。
納米設計中的分頻器
對于時鐘分頻器，原始源時鐘用于所有測試模式，并與分頻時鐘復用，如下圖 4所示。
圖 4： 原始源時鐘用于所有測試模式，并與分頻時鐘復用。
這是設計中的常見場景，我們有很多分頻器，但我們不能在全速測試中使用它們，因為這些分頻器在測試期間不可控（相位確定）。因此，簡化全速測試的簡單方法是在測試模式下提供一個不分頻的時鐘，這會導致過度測試。
多周期路徑等時序異常
在設計中，當信號傳播在功能操作期間需要多于單周期時鐘時，會使用多周期路徑、偽路徑、分析等形式的各種時序異常。這些異常在at-中有效速度模式，因此也應以 SDC（標準設計約束文件）的形式適當地移植到全速模式。然而，當前的 ATPG 工具在理解其中一些約束方面存在局限性，尤其是多循環路徑。當通過 SDC 文件進行解析時，它會忽略多周期路徑并且不會為此創建任何模式。例如，如果我們有一個從一個寄存器到另一個寄存器的 2 的多周期，它將簡單地屏蔽任何檢查這兩個寄存器之間捕獲的模式。
所以這意味著所有多周期路徑都沒有在全速測試中進行測試，導致測試不足。另一方面，如果這些異常未成為 SDC 文件的一部分，則時序檢查將在單個時鐘周期內發生，而從功能上講，該路徑將在兩個時鐘周期內工作，這是過度測試的典型情況。總的來說，這是一個大問題，因為通常我們在任何復雜的設計中都會遇到很多多周期異常，如果我們采用傳統方法，這可能會導致過度測試或測試不足。
實時測試
到目前為止，我們已經看到過度測試和測試不足都是不可取的，因此我們需要一種方法來確保在不影響設計 QOR 的情況下實現實時測試的實際好處。這個想法是，由于實時測試，設計上不應有任何顯著的面積/功率開銷，但同時我們應該確保在預期的功能頻率下檢查實時測試設計，而不是高于或低于該頻率。
這里列出了一些指南/技術，以確保以正確的方式完成全速測試：
? 在 func 模式下識別設計中的不同頻域。這是重要的一步，因為您越早確定頻域，就越能了解全速測試要求。對時鐘架構的全面分析有助于定義的全速時鐘。例如，在開始一個項目時，通常不會過多強調外部 IO 接口頻率目標，這會在以后影響為這些接口定義全速時鐘策略。
? 定義全速模式時序約束以及功能模式約束生成。全速模式下的任何時序關鍵路徑都可以在設計周期開始時解決。在早期階段進行更改總是比較容易。
? 關鍵解決方案之一是識別測試不足和測試過度的情況，因為很多時候這些問題會在終 STA 運行期間突然出現，甚至在滿足時序時甚至不會被注意到。使用某種腳本，可以比較功能模式和全速模式下所有寄存器的頻率。將寄存器分為三類：在兩種模式下具有相同頻率的觸發器——可以使用；觸發器在全速模式下的頻率低于功能模式下的頻率——測試中的情況；觸發器在全速模式下的頻率高于功能模式下的頻率——過度測試的情況。
一旦確定了這些情況，就應該進行徹底的分析，并探索所有架構的可能性，以提供與功能模式下頻率完全相同的時鐘。
為了解決時序異常，解決方案在于通過以較低頻率進行測試，將多周期路徑轉換為單周期路徑。這個概念很簡單。假設一個設計工作在 200MHz，并且有幾個 2 的多周期路徑。用 2 的多周期在 200MHz 時對這些路徑進行定時相當于在單個周期中以 100MHz 測試這些路徑。在全速測試中，分兩次測試邏輯。在遍中，將提供 200MHz 的捕獲時鐘來測試所有單周期路徑，并將屏蔽所有多周期路徑。在第二遍中，將提供 100MHz 的捕獲時鐘以僅測試所有多周期路徑。相同的概念可以應用于更高的多周期。
分多次進行at-speed testing也會在很大程度上解決over-testing/under-testing的問題。正如我們上面所討論的，有時不可能同時為所有域提供的頻率時鐘，但我們可以通過在每次傳遞中以多個頻率配置捕獲時鐘來做到這一點。通常，在我們將 pll 用作系統時鐘的設計中，我們可以靈活地將 pll 配置為某些離散頻率。
可以使用相同的多次測試方法來解決與分頻器相關的過度測試問題。不同之處在于，在多周期路徑的情況下，觸發器可以被屏蔽，但在分頻器的情況下，我們需要分頻時鐘的可控性，以便時鐘可以在掃描模式下被門控。
圖 5： 當系統時鐘為 200Mhz 時，在通道 1 的全速測試期間，時鐘門控邏輯會將時鐘門控到在 100Mhz 下正常運行的域（通過除以 2 邏輯）。
如圖 5所示，在系統時鐘為 200Mhz 的第 1 輪全速測試期間，時鐘門控邏輯會將時鐘門控到在 100Mhz 下正常運行的域（通過除以 2 邏輯）。但在第 2 輪中，當系統時鐘設置為 100Mhz 時，時鐘門控單元的使能將被驅動為邏輯 1。這將確保邏輯現在以 100Mhz 的預期頻率進行測試。
使用上述指南，應該可以解決大多數與過度測試和測試不足相關的問題。但萬一被迫在測試不足和過度測試之間做出選擇，決定取決于 SoC 的應用。汽車設計中，人身安全是首要考慮因素，應該選擇安全的過度測試方法，而在功耗大的設計，例如在網絡和無線領域，需要進行測試。即使對于這些情況，也應盡一切努力確保與所需頻率的偏差盡可能小。
讓我們舉一個具有多個頻率時鐘的設計示例，這將有助于理解這個概念：
假設一個設計在 240MHz 上工作，我們有一個 2、3、4 等的多周期用于各種路徑。還有一些接口工作在 10MHz 和 60MHz 的外部時鐘上。為避免任何類型的過度測試或測試不足，請在全速模式下多次通過測試。在 240、120、80、60MHz 下配置 PLL，并以實際功能速度測試所有邏輯。
? 第一遍：@240MHz - 所有單周期路徑（掩碼 100MHz 和 60MHz 接口，其余 SDC 是標準的）
? 第二遍：@120MHz – 多周期 2 的路徑（從 SDC 中刪除多周期 2 異常）+ 100MHz 接口邏輯（過度測試化）
? 第三遍：@80MHz – 多周期為 3 的路徑（刪除 2 和 3 的所有多周期異常）
? 第四遍：@60MHz – 4條路徑+60mhz接口邏輯的多周期路徑（去除所有多周期異常）
結論
隨著 SoC 的功能變得越來越復雜以及技術向更低的節點轉移，良好的成品率被證明是任何設計公司的一個重要關注點。收益率直接影響損益方程式，需要認真努力解決低收益率的原因。實速測試是衡量硅質量的重要標準，因此我們應該以高覆蓋率為目標。但同時，我們應該只在適當的時鐘頻率下運行我們的實速模式，因為在錯誤的時鐘頻率下測試會導致問題過度測試或測試不足。這兩種情況（測試不足和測試過度）既不利于設計 QOR，也不利于良率估算。
測試時鐘應該與功能時鐘同等重要，并且應該努力為不同的域提供相同頻率的時鐘，因為它們在功能域中被計時。同時，應該對多周期路徑給予相當大的關注，因為它們通常構成任何設計中時序路徑的重要組成部分。At-speed testing in multiple pass是解決多周期路徑at-speed testing的方法。Multipass測試方法也可以用來解決其他過度測試和under-testing的情況。因此，總而言之，使用上述建議和方法，我們可以實現更準確的全速覆蓋，這反過來將確保我們在不影響設計 QOR 的情況下將良率下降問題降至。
免責聲明：本文為轉載文章，轉載此文目的在于傳遞更多信息，版權歸原作者所有。本文所用視頻、圖片、文字如涉及作品版權問題，請聯系小編進行處理。
推薦閱讀：
知名半導體芯片制造企業——揚州晶新微電子參展CITE2023
