Digital Circuit Functional Verification(六)

检测与测试的比较( TESTING VERSUS VERIFICATION )

Verification => 保证在功能上实现设计要求
Testing       => 最后的硬件结构和制造工艺中的网表一致

1. 扫描测试(Scan-Based Testing ) (DFT-ATPG)

目的：扫描检测在某种程度上解决检测覆盖问题
方法：把所有的寄存器组成一个很长的串行链。在正常的状态下，
寄存器正常工作，在扫描状态下，寄存器则表现为一个很长的移位寄存器。

• 进行扫描检测时，检测对象必须置于扫描状态，再用一个输入量移位通
过所有的寄存器。
• 把检测对象置为正常状态，外加一个单时钟周期，把扫描状态下的正常
运行结果载入寄存器。
• 再一次把检测对象置为扫描状态。由寄存器输出结果（同时输入下一个
变量），并把它和期望值比较。
为了能插入扫描链和自动产生检测形式，设计必须受到一些限制。这些
限制包括：完全的同步性，没有导出时钟和门控时钟，只能使用时钟的
单个边沿，等等。

2. 为测试而设计 (BIST...)

• 设计方案作某些修订，以适应测试的要求。
• 因为功能测试所花的时间是设计本身的两倍，所以完全有必要在设计
上多花点时间，以简化测试过程。
• 正如设计中插入扫描链可以增加可检测性而不增加功能一样，应该在
设计中加入非功能性结构和特征以适应测试的需要。
• 要求在一个项目的开始就考虑到测试，尤其是在制定要求的阶段。
• 设计本身不仅要回答“要实现什么功能？”，而且要回答“如何来进行测
试？”。
• 典型的技术包括: 额外提供可软件编码的的寄存器，以控制和观察内部
地址，或用另外的可编程器件来隔离或绕过某些功能部件。

3 测试与设计方案再用(IPs)

设计能够被再用的关键是取得别人的信任： 设计再用最大的障碍是人为差
异，设计人员都不大愿意在自己的设计过程中引进不熟悉的方法和结果，他
们认为别人设计的没有自己亲自设计的好，或着不如自己设计的可靠。
是否值得信任的特征是看有没有一个适当的测试过程。如果能向用户证明该
设计曾按照要求从头到尾认真测试过，那么就能取得用户的信任。
再用一项设计，只能通过功能测试来证明其正确性。因此，可再用设计和一
般的设计比起来，更需要通过测试来取得信任。
可再用设计需更加结构化，更具有可编程性，方能满足不同的环境条件和不
同的应用，所以所有可能的结构和应用都要测试到。可再用设计所有的特点
都要展示给用户，并作出测试。

PrimeTime再了解(十八)

Specify false paths

設定false path的技巧
1.     Using Permutation and Combination [Mathematics] to set false paths
between all clock domains
2.     To hide the false paths which are relationship with each clock domain

以下是一個簡單例
## False paths from CLKC domain to the other domain
set_false_path –from [get_clock “CLKC” ]  -to [get_clock “CLKD”]
set_false_path –from [get_clock “CLKD” ]  -to [get_clock “CLKC”]
set_false_path –from [get_clock “CLKC” ]  -to [get_clock “gc_CLKD_1”]
set_false_path –from [get_clock “gc_CLKD_1” ]  -to [get_clock “CLKC”]
set_false_path –from [get_clock “CLKC” ]  -to [get_clock “gc_CLKD_2”]
set_false_path –from [get_clock “gc_CLKD_2” ]  -to [get_clock “CLKC”]

## False paths from CLKD domain to the other domain
## 紅色部分為可不設的重覆部份，因為前面已經會設定下面的部份
## set_false_path –from [get_clock “CLKD” ]  -to [get_clock “gc_CLKD_1”]
## set_false_path –from [get_clock “gc_CLKD_1” ]  -to [get_clock “CLKD”]
## set_false_path –from [get_clock “CLKD” ]  -to [get_clock “gc_CLKD_2”]
## set_false_path –from [get_clock “gc_CLKD_2” ]  -to [get_clock “CLKD”]

## False paths from gc_CLKD_1 domain to the other domain
set_false_path –from [get_clock “gc_CLKD_1” ]  -to [get_clock “gc_CLKD_2”]
set_false_path –from [get_clock “gc_CLKD_2” ]  -to [get_clock “gc_CLKD_1”]

另外
Setting false paths for test_mode/scan_enable signals

本區其他參考頁
http://kirenenko-tw.blogspot.com/2011/08/design-compiler_5306.html

http://kirenenko-tw.blogspot.com/2011/08/design-compiler_14.html

DFT再了解(二十八)

網路上找到關於 autofix 的例子可供參考

DFT之autofix(一)

http://bb2hh.blogbus.com/logs/59523721.html

DFT之autofix(二)

http://bb2hh.blogbus.com/logs/59523820.html

ATPG再了解(十七)

Data Flow for PowerFault Strobe Selection

ATPG再了解(十六)

TetraMAX Pattern Formats



















Write Verilog

TetraMAX supports two forms of Verilog:
• A multifile data table format
• Single file all-in-one format
Both forms of Verilog enable you to select either serial or parallel application of scan shift as
specified by the -serial or the -parallel option. The default selection is the parallel application
of scan shift.
Verilog single-file format contains Verilog test bench and all patterns for input and expected
data output.
Verilog multifile table format uses a testbench with an instantiated design and a small
sequencer state machine along with files containing primary input forces, primary output
measures, scan load/unload data, and state machine sequencer codes to provide process
control.
The -format Verilog option writes patterns in the Verilog format. See the
write_patterns command in the TetraMAX online help for details.

Write STIL
The Verilog testbench is written either with a serial or a parallel application of scan shift as
specified by the -serial or the -parallel option. By default, no selection of the option writes
as serial form of the testbench with a STIL pattern file.
The -format stil option writes patterns in the proposed IEEE-1450.1 Standard Test
Interface Language (STIL) for Digital Test Vectors format. For more information on the
proposed IEEE-1450.1 STIL for Digital Test Vectors format (extension to the 1450.0-1999
standard), see Appendix E STIL Language Format in the TetraMAX ATPG User Guide. This
format can be both written and read; however, only a subset of the language written by
TetraMAX is supported for reading back in.
The -format stil99 option writes patterns in the official IEEE-1450.0 Standard Test
Interface Language (STIL) for Digital Test Vectors format. This format may be both written
and read, but only the subset of the language written by TetraMAX is supported for reading
back in.

Note:
You must use a 1450.0-compliant DRC procedure as input when to write output in stil99
format.

If your design contains PI pin equivalency, use the -stil99 option when writing patterns for
Verilog DPV. The syntax generated when using the -stil option is part of the proposed IEEE
1450.1 extensions to STIL 1450-1999; it is not yet supported with the external applications
such as Verilog DPV.

If you select -format stil or stil99, TetraMAX generates a STIL file with a name in the
filename <pfile>.<ext> in which you specified write_patterns <pfile>.<ext>.

ATPG再了解(十五)

Verilog DPV Testbench Overview

The Verilog direct pattern validation (Verilog DPV) testbench is a tool that lets you directly
simulate and validate STIL test patterns generated by TetraMAX and Boundary-scan test
vectors generated by BSD Compiler.

The tool eliminates the need to generate intermediate formats or additional simulator
constructs.

Verilog DPV testbench consists of a set of PLI tasks that function with the Verilog simulator.

In TetraMAX, issue a write_patterns <pfile.ext> -format [stil | stil99]
command to generate the Verilog testbench. For example:

test> write_patterns pfile.stil -format stil99

The name of the generated testbench file, in this case, would be pfile_stildpv.v, where
TetraMAX replaces the file extension (here, “.stil”), with “_stildpv.v”. Verilog DPV.

TetraMAX generates a Verilog-formatted testbench that contains an instance of the device
to be tested and includes appropriate connections to the Verilog DPV testbench interface.
The testbench contains the necessary calls to the Verilog DPV testbench PLI tasks.

When you run the Verilog simulation, Verilog DPV testbench applies STIL-formatted test
data as stimulus to the design and validates the design’s response against the
STIL-specified expected data. The simulation results ensure both the logical operation and
timing sensitivity of the final STIL test patterns generated by TetraMAX.

Verilog DPV testbench validates the simulated device response against the timed output
response defined by STIL. For windowed data, it confirms that the output response is stable
within the windowed time region.

Note:
1.  To use Verilog DPV, you must have access to GCC (GNU Compiler Collection) 3.2.2 and
ld: Software Generation Utilities - 5.9-1.388.
2. Verilog DPV might not work on unsupported operating platforms or simulators. See the
release notes for a list of supported platforms and simulators.

3. The validation of DPV testbench for IDDQ STIL patterns is not supported.

Then, to simplify the procedures, point the environment variable STILDPV_HOME to the
stildpv directory where you installed Verilog DPV testbench. For example, in a typical
Synopsys installation using csh, the command is:
setenv STILDPV_HOME $SYNOPSYS/<platform>/stildpv

where $SYNOPSYS is the Synopsys software installation directory.
The operations in the following sections use the STILDPV_HOME environment variable to
designate the location of Verilog DPV testbench code. 

請參考網址 http://www.blogger.com/post-edit.g?blogID=3719279094522729974&postID=4888427122763162222

ATPG再了解(十四)

Dual Simulation Flow and Unified Simulation Flow Format Support

ATPG再了解(十三)

Fault Class Hierarchy

DT – Detected:
 DS - detected by simulation
 DI - detected by implication
 DR - robustly detected delay fault


PT – Possibly Detected:
 AP - ATPG untestable, possibly detected
 NP - not analyzed, possibly detected


UD – Undetectable:
 UU - undetectable unused
 UT - undetectable tied
 UB - undetectable blocked
 UR - undetectable redundant


AU – ATPG Untestable:
 AN - ATPG untestable, not-detected


ND – Not Detected:
 NC - not controlled
 NO - not observed

TetraMAX Support for BSD Designs

ATPG再了解(十二)

TetraMAX Design Rule Checks

Checked during read netlist, run build_model:
 N rules (netlist) and B rules (build_model)

Checked during run drc:
 S rules (scan chain or shift)
 C rules (clocks or capture)
 Z rules (internal tristate buses and bidi-directional pins)
 X rules (combinational feedback loops)
 V rules (vector statements in the SPF)
 L rules (Logic BIST violation preventing SoCBIST flow)
 T rules (Optional ATE rule checks when Tester STIL
available)


Other rule categories:
 P rules (Path delay checks for DSM Test ATPG)

ATPG再了解(十一)

Memory DFT Strategies

A. Testing RAM/ROM for Internal Faults:
The transistor-level fabric of a RAM/ROM can’t be tested by gate-level
stuck-at-fault techniques. Use direct pin access or memory BIST.


B. Applying a Black-Box Model:
A vendor RAM/ROM primitive in a synthesized design often behaves
as a black box. This casts a low-coverage shadow over nearby logic.


C. Inserting Test Points:
The testability of shadow logic can be improved by automatic insertion
of DFT control-and-observe test points around a black-box RAM/ROM.


D. Writing Functional Models:
Testability of shadow logic can be maximized by replacing the black box
RAM/ROM cell with a user-supplied functional Verilog model.

白安鵬--半導體積體電路測試技術部落格

還不錯的測試技術網站

http://ictesting-tom.blogspot.com/2009/01/blog-post_477.html

set_false_path 與 set_case_analysis 的差別

1. "set_false_path" - 用來設立 Design Compiler 不作此路徑的分析, 將此路徑視為理想
ex. - 如橫跨 Multi-clock 的路徑, 設立之後方可滿足 setup/hold timing constraint
2. "set_case_analysis" - DC 仍會做此路徑的分析, 但會對此路徑設立條件(定值)
ex. A - 正常模擬時, 電路中 mux 的某個選擇(也許用作DFT)永遠不會執行,
則設立之後方可滿足正常模擬的環境
ex. B - 如 SRAM model 的 EMA/RETN port, 若無設立可能導致 setup time
出現極不合理的 violation
參考網址 http://daviddai0219.pixnet.net/blog/post/26580130



另舉一例，對於pulse的分析
set_case_analysis rising  [get_pins OR/B]
set_case_analysis falling [get_pins OR/A]

ATPG再了解(十)

ATPG model error

使用以下兩個指令可以看到Build model的資料與錯誤
TEST-T> report module –summary

TEST-T> report module –errors

Although TetraMAX attempts to translate vendor cell descriptions into ATPG gate equivalent
models, this automatic translation is not always successful. For example, it is quite common to
experience “N” class violations when reading libraries.

In general, this topic is important for library developers, as they have to deliver certified libraries.

TetraMAX users should always look for library problems to make sure TetraMAX does not
generate wrong patterns due to library issues. It is beneficial for TetraMAX users to have at least a basic idea of how to debug library issues, just in case.

The important question is: Did all of the cells translate properly? To casually answer this question, you should use the summary option to the report modules command and look for any X detectors or Errors indicated, either of which will indicate an ATPG model that may not be suitable for use.

To review specific modules on which errors were encountered use the -error option of report
modules. Once a module which had an error or other problem such as N13 or N24 is identified you can report the connectivity information of the module as one way to reveal how the module was translated.

ATPG再了解(九)

Empty Boxes Versus Black Boxes

使用下面指令
set build -reset_boxes # clears black & empty box list
set build -empty_box BUS_SWITCH
set build -black RAM32x8 -empty IRQ_CORE


An “empty box” is similar to a black box with the exception that its output pins are floating.
These can be used for an embedded memory with tristate-able outputs.

Specify an Empty Box module only if its outputs are actually at Z state during test. The empty box can be helpful if multiple modules are connected to a bus, but the module outputs are all at Z state.

Using black boxes in this case would result in bus contention.

Two additional ‘box’ models are supported To make TetraMAX treat a module as a library cell, use the –design_box option:

TetraMAX will then add faults to just the ports of this module, but not inside

To maintain the port connections of a level of hierarchy, use the –portfault_box option:
May be used in SoCBIST flow where scan ports of a module need to be maintained in design

ASIC設計中的可測性

ASIC 設計中的可測性 ASIC設計者總以為提供給IC工廠的測試資料(TEST PATTERN)是用來測試實際IC的功能，事實上這是一個錯誤的認知。站在IC工廠的角度來看，如何確保ASIC功能正確是屬於設計者分析模擬前段工作 的責任，IC工廠所需要的，是一組用延而有效的測試資料，能夠將所有製程失敗的不良IC，在測試過程中分辨出來。對於一顆量產的ASIC而言，設計者確認 它的功能無誤，而IC工廠可以保證生產的流程沒有瑕疵(各盡各的責任)，那麼毫無疑問，這個ASIC應該是好的：

(1) FAULT COVERAGE(偵錯率)
如何來衡量一組測試資料(TEST PATTERN)的周延性和效率呢？最常被使用的指標就是FAULT COVERAGE (偵錯率)。計算FAULT COVERAGE，必須先定義FAULT MODEL(故障模式)，最常用的是單一永久性的S-A-0(短路到地)和S-A-1(短路到電源)兩個MODELS，假設線路中有100個線路節點，每 個節點都有SA0和SA1兩種可能，那麼線路中共有200個FAULTS，如果設計者提供的測試資料可以使其中120個FAULT出現不同於正常結果的輸 出(這些FAULT是DETECTABLE)，偵錯率的計算結果就是60%(120÷ 200)。盡責的設計者應盡可能將偵錯率提高到接近100%。

(2) SCAN PATH DESIGN
要提高線路的可測性(TEEST ABILITY，COMBINA-TIONAL線路不是問題，但對SEQUENTIAL線路則困難極多後者中有D-FF和LATCH之類的記憶性元件，系 統的整體輸出不僅取決於系統的輸入，還與記憶體元件所保存的上一個邏輯狀態有關，所以要提高SEQUENTIAL線路的可測性，最重要的就是提高記憶體元 件的可控制性和可讀性。最有名的方法，就是引進所謂的SCAN PATH DESIGN。

首先將記憶性元件換成SCAN FF(當SE=0時，S-FF有如一個正常的D-FF；當SE=1時，D端被關掉，輸入改由SI端進入)。然後透過SI端將整個系統的SCAN FF-串接在一起。當SE=1時，系統中所有的S-FF事實上是串成一個大型的SHIFTER (SCAN PATH)。設計者可以依靠這個SCAN PATH來控制或讀取任何一個原本D-FF中所保存的邏輯態。如此一來，系統的偵錯率可以很容易提高。



(3) SCAN PATH所帶來的問題
使用SCAN PATH DESIGN會出現一些新問題，這些新問題必須經過設計者的細心考慮，才能令SCAN PATH的效能提到最高。

I. FULL SCAN還是PARTIAL SCAN
FULL SCAN是指將所有D-FF全換成SCAN FF,PARTIAL SCAN則只置換部份影響較大的記憶性元件。前者會增加相當多的閘數(增加晶片成本)，後者則需要設計者做深一步的判斷，而且偵錯率會降低。

II. CLOCK SKEW的問題
使用SCAN PATH DESIGN必須是同步設計，而且會在SCAN模式下產生一個極大的SHIFTER線路，必須小心CLOCK SKEW問題造成SCAN PATH出錯。其中一個解決之道，是將SCAN FF在換成有兩個時鐘的LSSD設計，這樣一來，可能又要增加許多的閘數。

III. SCAN DESIGN和IC佈局的關係
假設SCAN FF的連接不能依照佈局結果的遠近來串接(實際上相近的D-FF才串在一起)這不但會使D-FF因負載加大而頻率降低，也會阻礙整體系統的可繞性 (ROUTABILITY)。很可惜，目前的商用軟體都未考慮到此點。增加ASIC的可測性是一個重要而艱難的問題，必須有長足經驗的累積，才能令一個 ASIC設計者在準備測試資料的過程中得心應手。

轉貼自http://hi.baidu.com/qrnujianglin/blog/item/37dfcc0a83f3191b94ca6bc9.html

DFT再了解(二十七)

DFT specification commands 共有四種

 set_* Creates the specification
 report_* Reports the specification
 reset_* Restores settings back to default
 remove_* Removes the specification

例如
set_dft_signal » report_dft_signal » remove_dft_signal

ATPG再了解(九)

Empty Boxes Versus Black Boxes

使用下面指令
set build -reset_boxes # clears black & empty box list
set build -empty_box BUS_SWITCH
set build -black RAM32x8 -empty IRQ_CORE


An “empty box” is similar to a black box with the exception that its output pins are floating.
These can be used for an embedded memory with tristate-able outputs.

Specify an Empty Box module only if its outputs are actually at Z state during test. The empty box can be helpful if multiple modules are connected to a bus, but the module outputs are all at Z state.

Using black boxes in this case would result in bus contention.

Two additional ‘box’ models are supported To make TetraMAX treat a module as a library cell, use the –design_box option:

TetraMAX will then add faults to just the ports of this module, but not inside

To maintain the port connections of a level of hierarchy, use the –portfault_box option:
May be used in SoCBIST flow where scan ports of a module need to be maintained in design

ATPG再了解(八)

Duplicate Module Definitions

By default, if a module
definition already exists in
the internal list and a second
module with the same name
is read this will replace the
first definition:

An N5 violation (severity
warning) will be issued

To prevent module redefinition of any kind, set the N5 rule to
severity error:
TEST-T> set rule n5 error

DFT再了解(二十六)

Create Test Protocol

Specify Scan In
Define scan in signal that you want to be connected during insert_dft
















Specify Scan Out

Define scan out signal that you want to be connected during insert_dft

















Specify Scan Chains