starc...

STARC STILテスト推進委員会(SSTAG)

IEEE Std 1450.0-1999

STIL活用ガイド

Revision 6.202011/10/17

Copyright STARC 2005-2011

変更履歴Revision Date No SectionTitle 修正内容

6.2 2011/10/17 48 コメントに関する問題点新規追加

STIL活用ガイド【 IEEE Std 1450.0-1999 】

STIL1450.0活用ガイド 2011/2/7（Revision 6.00)

※1 IEEE Specificationにおいて問題点のあった箇所をセクション毎に1から数えて、例えば 1-5（1行目から5行目）として行数を示している※2 審議して問題のあった項目については「有」、無かった項目については「無」、審議案件が出なかった項目については「－」で示している※3 Description：STILデータを記述あるいは解釈する上で共通認識しておくべき内容であることを示す

Application：STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケーションツールや装置で共通認識されるべき内容であることを示すEnvironment：STILをサポートするテスト環境において、STILデータを相互利用する上で共通認識されるべき内容であることを示す

章セクションページ項目ページ行数※1 有無※2 タイトル問題点の解説問題点の関連資料へのリンク分類※3 解釈備考

6 -

1 55 Case sensitivity 55 1-2 有ユーザ定義名における大文字と小文字の区別の扱いに関する問題点

STILは大文字と小文字を区別する言語である。しかし大文字と小文字を区別したユーザ定義名（特に信号名）を使用することは、以下のことから問題を引き起こす可能性があると予想される。・STARC発行の「RTL設計スタイルガイド」ではコメントを除き、大文字／小文字のみの違いで名称を区別することが禁止されている・VHDL、EDIFなど、大文字/小文字の違いを区別しないフォーマットが存在する・テスターからEDAツールにSTILデータを読ませた場合に不具合の生じる可能性がある

Page1 Environment ユーザー定義名では、大文字と小文字のみの違いで名称を区別しない使用方法を推奨する。（例　Abc, ABC, abcのような大文字と小文字の違いのみの名称は混在させて使用しないことを推奨する。）

2 55 Whitespace -

3 55 Reserved words -

4 57 Reserved characters -

5 58 Comments 58 4 有コメントに関する問題点

コメントは、//ラインコメント、/*ブロックコメント*/の２種類の記述形式があり、両者はすべての空白箇所に記述でき、空白（whitespace)として扱われると規定されているが、その具体的な取り扱いが不明確である。

Page138-141 Description //ラインコメント、/*ブロックコメント*/の２種類のコメント記述は、STILファイルの任意の場所に記述できるものと解釈する。

//ラインコメント、/*ブロックコメント*/の空白（whitespace)としての扱い方は、特に規定せず、個々のアプリケーションに任せるものとする。　なお、//ラインコメント、/*ブロックコメント*/の扱い方は、スペース1文字に解釈することを推奨する。

6 58 Token length -

7 58 Character strings 58 5-10 有連結された文字列の扱いに対する問題点

ピリオド文字は、2つの文字列を連結するための表記方法として用意されている特殊文字である。連結文字の表記方法を用いれば、STILの表記上の制約である1024文字を超える長い文字列を表現することができる。ただし、Timingブロック内でのInherit参照機能においては、ピリオド文字はブロック階層を表すための意味と、連結文字を表すための意味の2つがあるため、どちらの意味を優先して解釈すれば良いかが曖昧なために問題を引き起こす可能性がある。

Page2 - 4 Application 階層としての解釈を優先する。すなわちTimingブロックのInherit参照機能では、ピリオド文字は初に階層を示すものとして解釈し、それで参照される定義情報がなければ、連結文字としての解釈を行うものとする。

アプリケーションでは、Inherit参照機能において、ピリオド文字が階層として扱われたのか、連結文字として扱われたのかをユーザに対して知らせるためのメッセージを出力することを推奨する。

SSTAG問題点

STIL syntax description

IEEE Std 1450.0-1999 Specification


fukui

ハイライト表示

fukui


fukui






章セクションページ項目ページ行数※1 有無※2 タイトル問題点の解説問題点の関連資料へのリンク分類※3 解釈備考SSTAG問題点IEEE Std 1450.0-1999 Specification

8 59 User-defined name characteristics 59 4-5 有 STIL予約語と予約文字の利用における問題点

予約文字を使ったユーザー定義名において二重引用符の有無が不明確である。予約文字は特殊文字とSI単位やSI単位のプレフィックス文字などで構成される(具体的にはIEEESpecificationのPage57-58のTable2を参照のこと)。これらの予約文字そのもののユーザ定義名あるいは予約文字を含んだユーザ定義名は二重引用符で囲むべきかどうかが曖昧である。

Page5 - 7 Description 予約文字そのもののユーザー定義名と、特殊文字など（Special CharactersとWhitespaceCharacters）を含んでいるユーザー定義名は二重引用符で囲まなければならない。ただしCelやOhmなどの複数文字の予約文字は二重引用符で囲まなくても良いものとする。

ユーザ定義名は混乱を避けるため二重引用符で囲む使用方法を推奨する。またWaveformChar referencesを除き1文字のユーザー定義名や予約語、予約文字そのもののユーザ定義名は使用しないことを推奨する。

下記は予約文字そのものあるいは予約文字を含んだユーザ定義名(Signal Name)に対する使用可否について例示したものである。大文字、小文字が同名の混在ケースと一文字のユーザ定義名のケースが記載されているが、このような記述はあくまでも便宜上であり、実際のSTIL記述においてはSTIL活用ガイド1450.0の「ユーザ定義名における大文字と小文字の区別の扱いに関する問題点」と「STIL予約語と予約文字の利用における問題点」のSolutionに従って記述することを推奨する。

例(1)User defined name of reserved word itself Signals { A In; a In; Alignment In; Ann In; } // not OK Signals { "A" In; "a" In; "Alignment" In; "Ann" In; } // OK(2)User defined name including reserved word Signals { AA In; aa IN; XAlignment In; XAnn In; } // OK Signals { "AA" In; "aa" IN; "XAlignment" In; "XAnn" In; } // OK(この記述を推奨)(3)User defined name of Special Character itself Signals { ; In; * In; } // not OK Signals { ";" In; "*" In; } // OK(4)User defined name including Special Character Signals { name; In; name* In; } // not OK Signals { "name;" In; "name*" In; } // OK(5)User defined name for Engineering Prefix itself Signals { E In; P In; T In; } // not OK Signals { "E" In; "P" In; "T" In; } // OK

(6)User defined name including Engineering Prefix Signals { EE In; PP In; TT In; } // OK Signals { "EE" In; "PP" In; "TT" In; } // OK(この記述を推奨)(7)User defined name for SI Unit itself of single character Signals { A In; V In; F In; s In; } // not OK Signals { "A" In; "V" In; "F" In; "s" In; } // OK(8)User defined name including SI Unit itself of single character Signals { AA In; VV In; FF In; ss In; } // OK　Signals { "AA" In; "VV" In; "FF" In; "ss" In; } // OK(この記述を推奨)(9)User defined name for SI Unit itself of multiple character(Cel, Hz, Ohm) Signals { Cel In; Hz In; Ohm In; } // OK Signals { "Cel" In; "Hz" In; "Ohm" In; } // OK(書き方としてはこちらを推奨するが、

予約文字そのものなので使用しないことを推奨する)

(10)User defined name including SI Unit of multiple character(Cel, Hz, Ohm) Signals { XCel In; XHz In; XOhm In; } // OK Signals { "XCel" In; "XHz" In; "XOhm" In; } // OK(この記述を推奨)(11)User defined name for min, max itself Signals { min In; max In; } // OK　Signals { "min" In; "max" In; } // OK(書き方としてはこちらを推奨するが、予約文字そのものなので使用しないことを推奨する)(12)User defined name including min, max Signals { Xmin In; Xmax In; } // OK Signals { "Xmin" In; "Xmax" In; } // OK(この記述を推奨)


fukui







ユーザー定義名では、二重引用符の有無で名前の区別を図るのではなく、番号や文字を付加するなど違いを明確に示したユーザ定義名によって記述することを推奨する。

STILを出力するアプリケーションでは、ユーザ定義名を二重引用符付きで出力することを推奨する。

バスピンに対する記述方法では、"BUS[0]"として全体を囲むのではなく、"BUS"[0]として書くことを推奨する。それは、"BUS"[0..7]はバスピン表記とのみ解釈できるが、"BUS[0..7]"は特殊文字を使った文字列とも解釈でき、区別がつかなくなるからである。

59 34 有ユーザ定義名に含まれる改行とタブ文字に対する問題点

IEEE Specificationにおいてはユーザ定義名でブランク文字を用いた記述例はあるが、タブや改行文字を用いた記述例は無い。ユーザ定義名においてタブや改行、ブランクが使われた場合、紙の上では区別がつけられない。このため,このSTILデータの受け渡しを行なう場合、タブや改行、ブランクを使ったユーザ定義名の記述方法を明確にする必要がある。

Page13 - 14 Description WhiteSpace（ブランクやタブや改行）を用いたユーザ定義名を記述すると、STIL作成者や利用者が目視によって、ブランクやタブや改行がどのように記述されているかを認識することが難しく、書き換えられてしまっても分からず、トラブルを引き起こしやすい。このためWhiteSpaceを用いた記述を行なう場合には、目視において問題が起こらない低限必要な使用上のルールを設けるべきである。したがってWhiteSpaceのうち、ブランクを用いたユーザ定義名は使用できるが、タブや改行を用いたユーザ定義名は使用しないものとする。

タブや改行を使用したユーザ定義名がSTILに含まれている場合、アプリケーションではSTIL記述における記述のエラーとして扱うとともに、修正を促すメッセージを出力することを推奨する。

59 1 - ユーザ定義名に関する問題点

ユーザ定義名(User-defined name)の記述が以下のように定義されている。6.8 User-defined name characteristics（P59)　There are several categories of user-definednames in STIL: signal and group references,WaveformChar references, WaveformTablereferences, variable references, UserKeywords,labels, and domain names(*).

ユーザ定義名として明記されていないScanStructuresブロックのScanChain名、ScanCells名、UserFunctions名の記述の扱いは不明確なものとなっている。

(*) domain names : Domain names provide amechanism to reference the data defined in anamed block. When a domain name is present fora SignalGroups, Procedures, MacroDefs,PatternBurst, Timing, Selector, Pattern orScanStructures block, that domain name shall bespecified in a “reference“ statement in order tomake use of the data in that block.

さらにTable 6 (P66)のSpec、PatternExec等のブロック名はユーザ定義名とP59に記述あり。

Page119 - 120 Description Named Blockとなるブロックステートメントに付けられるブロック名はユーザ定義名として扱うものと解釈する。従ってScanStructuresブロックのScanChain名はユーザ定義名として扱われる。またUserFunctionsに付けられる名前はUserKeywordsに準じるものとしてユーザ定義名として扱うものと解釈する。ScanStructuresブロックのScanCells名はSignals名に準じてユーザ定義名として扱うものと解釈する。

従ってユーザ定義名(User-defined name)はSTILを作成する人またはツール、設計者が付けることが出来る全ての名前の総称と解釈することになる。

STILの拡張スペック（IEEE1450.1、1450.2、1450.3、1450.6）でも同様の問題があり同様に解釈するものとする。詳細については各STIL活用ガイドを参照のこと

9 59 Domain names -

10 60 Signal and group namecharacteristics

60 2 - BUS端子の記述に関する問題点

BUS記述のIndex Numberを昇順、降順に記述できるが、同一のIndex Numberで表記された場合の取り扱いが不明確となっている。例："BUSA"[0..31]　//Index Numberが昇順、"BUSA"[0], "BUSA"[1], … "BUSA"[31] と同じ

"BUSA"[31..0] //Index Numberが降順、"BUSA"[31], "BUSA"[30], … "BUSA"[0] と同じ

"BUSA"[15..15] // Index Numberが同一の整数値、この場合の取り扱いが不明・・・(*)

Page121 Description BUS記述においてIndex Numberに同一の整数値が記述(*)されている場合はその整数値のBUS端子、即ち”信号名”[整数値]と同じ端子を表すものと解釈する。

ただし、Index Numberに同一の整数値がある記述(*)は使用しないことを推奨する。また、一つのBus端子の表記においてIndex Numberに同一の整数値がある記述(*)とその整数値のBUS端子の記述の混在は混乱を避けるためアプリケーションサイドでエラーとして扱っても良いものとする。

11 60 Timing name constructs -

二重引用符で囲まれているユーザ定義名と、二重引用符で囲まれていないユーザ定義名、例えば”Xyz”とXyz の2つが同じ種類（ピン名であったり、ピングループ名、ドメイン名など）で使用されているユーザ定義名は、そのユーザ定義名が記述されたSTILを扱うアプリケーションにおいて、ユーザー定義名の重複定義としてエラー処理されても構わない扱いとする。二重引用符の有無は、たとえアプリケーションで判断できる事項だとしても可読性や、口頭での項目指示などで誤認し運用面でのミスを誘発する可能性が高いためである。

ユーザ定義名は、アプリケーションの内部処理に際しては、二重引用符がない形式、あるいは二重引用符が付けられた形式のいずれか一方の形式で統一的に扱われるものとする。

Applicationユーザ定義名における二重引用符の扱いに対する問題点

IEEE Specificationにおいて、二重引用符は信号名の一部には使用できないとしている。一方、IEEE Clarificationでは、二重引用符で囲まれた信号名と、囲まれていない信号名の両方を、Signalsブロックに一緒に記述できると記載されている。二重引用符が信号名の一部として使えないのであれば、二重引用符で囲まれた信号名と、囲まれていない信号名は、共に同じ信号名を示すものであり、両方を一緒に記述できることは、同じ信号名の重複定義を行なっていることになる。このため両者は一つのSTILファイル中では区別して取り扱うことになる。ネットファイルにおいて信号名は二重引用符で囲まれていないにも関わらず、ATPGツールによって出力されたSTILでは二重引用符で囲まれている場合が多くある。STILファイルに二重引用符で囲まれた信号名に加えて、二重引用符で囲まれていない信号名も記述されている場合には、どちらの信号名との対応を取れば良いかがアプリケーションサイドでは判断できなくなる。

Page8 - 1259 9-37 有


fukui


fukui


fukui


fukui







12 60 Number characteristics -

13 61 Timing expressions and units(time_expr)

-

14 63 Signal expressions (sigref_expr) -

15 64 WaveformChar characteristics 65 19-20 有パターンの繰り返し記述の範囲に関する問題点

ベクターフラグ\rの繰り返しCharactersのlist記述において、\rが記述できるかどうかが明確でなく、ｌist記述の中で使われた場合の解釈が曖昧である。 <書式> 　　\rN XXX 　　例) sigref_expr=\r3 00\r2 11 0 01;

Page122 - 124 Description \rの繰り返し回数の後のスペースは\rの繰り返し回数を示す数字(count fields)の一部(デリミタ)として扱われている。\rで繰り返す記述のデリミタ(the first white space)としては扱われず、繰り返すlist記述の中に\rを記述しても矛盾は生じない。従ってベクタフラグ\rの繰り返すlist記述の中に\rは記述できるものと解釈する。例）V { sigref_expr=\r3 00\r2 11 0 01; }　は、V { sigref_expr=001111001111001111001;}　と等価となる。

注1)STILの仕様書ではWhiteSpaceは、空白(space)、タブ(tab)、改行(newlinecharacter)を意味している。注2) \rで繰り返すlist記述の中において、\h、\dによって文字の種別を切り替える記述はできない。\wによるhex記述ないしはdecimal記述からの文字の種別を切り替える記述は可能である。

　　\h01 11 \r2 A\wLH 0101 は 00010001 1010 LH 1010 LH 0101　　と等価になる。

16 65 STIL name spaces and name -

7 -

1 69 Top-level statements and requiredordering

-

2 70 Optional top-level statements -

3 70 STIL files -

Statement structure and organization of STIL information


fukui







8 -

1 70 STIL syntax -

2 70 STIL example -

9 -

1 71 Header block syntax -

2 71 Header example -

10 71 1-11 有 Includeのネスティング記述の可否に関する問題点

Include文で参照されるSTILファイルの中で、更にInclude文を使って他のSTILファイルからの参照を行なうInclude文のネスティング記述がある場合、その記述の可否が仕様では明確に記載されていないため、扱いをどのようにすべきか不明である。

即ちSTILファイル(A)からInclude文によって参照されるSTILファイル(B)の中で、更にInclude文によってSTILファイル（C)の参照を行なうネスティング記述がある場合、STILファイル（C)を参照するInclude文の使用の可否が不明である。

Page15 - 16 Description Include文のネスティング記述を許すものとし、そのネスティング回数には制限を設けず記述できるものとする。

Include文によるネスティング記述で無限ループになる場合には、誤った記述と見なして、そのSTILファイルを扱うアプリケーションにおいてはエラーメッセージの出力を推奨する。

即ちSTILファイル(A)からInclude文によって参照されるSTILファイル(B)の中で、更にInclude文によってSTILファイル（A)の参照を行なう回帰するようなネスティング記述がある場合には、無限ループとなるためアプリケーションはエラーメッセージを出力することを推奨する。

1 72 Include statement syntax -

2 72 Include example -

3 72 File path resolution with absolutepath notation

-

4 72 File path resolution with relative pathnotation

-

STIL statement

Header block

Include statement


fukui







11 -

1 73 UserKeywords statement syntax -

2 73 UserKeywords example -

12 -

1 74 UserFunctions statement syntax -

2 74 UserFunctions example -

13 -

1 74 Annotations statement syntax -

2 74 Annotations example -

14 -

1 75 Signals block syntax 76 63-67 有 Alignmentステートメントを定義した場合に使用できるパターン記述の問題点

SignalsブロックおよびSignalGroupsブロックの信号/信号グループ定義においてAlignmentステートメントを記述した場合に、 Vectorステートメントに記述できるパターンはWFC、数値の両方なのかどうかが不明である。

Page66 - 67 Description SignalsブロックおよびSignalGroupsブロックの信号／信号グループ定義においてAlignmentステートメントを記述した場合に、対象となるVectorステートメントにHexあるいはDecの数値が使用された場合にはAlignmentステートメントで指定されたMSBないしはLSBから信号数分のbitデータが順に割り付けられ、そのbitデータに対応付けられたWFC列になる。WFCの並びに対してはAlignmentステートメントは無効となる。パターンにWFC を記述する場合にはWFCの個数と信号の個数は同じでなければならない。

2 77 Signals block example -

ピンが0個のピングループを定義する場合、1450.0の範囲では方法１が、1450.1の範囲では方法1と方法2の記述が仕様上許されている。1450.0の範囲では方法2は使えないものとし、STILバージョンによる違いの混乱を避けるためにも方法１の記述を推奨する。

ピンが0個のピングループを定義する必要がある場合を除き、ピン名の記述忘れを明確にするために、できるだけPseudoピンを用いて定義することを推奨する。

ピン名と同じ名前を使ったピングループの定義が必要な場合を除き、同じ名前のピングループ名はできるだけ使用しないことを推奨する。

Description ピングループ名の定義において、ピン数が0個の記述を定義する場合は以下の二つの記述方法が考えられるが、方法１で記述するものとする。（方法１）GroupName = '';（方法２）GroupName = ;ピンが0個のピングループを参照するSTIL記述があった場合は、参照した結果としてピングループ名に対応する記述はなかったものと解釈する。例えばパターンブロックで0個のピングループに対するパターン定義がされている場合には、そのピングループ名に対するパターンは定義されていないものと解釈する。また、タイミングブロックで0個のピングループに対するタイミング定義がされている場合には、そのピングループ名に対するタイミングは定義されていないものと解釈する。

有 SignalGroupsブロックの定義に関する問題点

15 Page17 - 20SignalGroups block

UserFunctions statement

Ann statement

UserKeywords statement

Signals block

1-277 SignalGroupsブロックで定義されるピングループは、0個または複数個のピンをグループとしてまとめて扱う定義ができるが、0個の定義を行なう記述方法が不明確である。また0個のピングループを参照したSTIL記述があった場合にその解釈が不明である。例えばパターンブロックで0個のピングループに対してパターン定義がされている場合や、タイミングブロックで0個のピングループに対してタイミング定義がされている場合の解釈が不明である。


fukui


fukui







1 77 SignalGroups block syntax

2 78 SignalGroups block example -

3 78 Default attribute values -

4 79 Translation of based data intoWaveformChar characters

-

16 80 1-15 有複数のPatternExecブロックの扱いに関する問題点

複数のPatternExecブロックが定義されたSTILデータにおいて複数のPatternExecブロックの実行順番に関する規定が無いために、どのように扱えば良いのか、その扱い方が不明である。

Page21 - 22 Application 複数のPatternExecブロックが定義されたSTILデータにおいて記述されている複数のPatternExecブロックの解釈は、複数のPatternExecブロックを記述されている順番に実行して、全てのPatternExecブロックを実行するものと解釈する。この解釈に対するアプリケーションサイドにおける具体的な対応方法は規定せず、個々のアプリケーションに依存するものとする。

1 81 PatternExec block syntax

2 81 PatternExec block example -

17 -

1 82 PatternBurst block syntax -

2 82 PatternBurst block example -

18 -

86 11-13 有一つのWFCに対して同じイベント時刻に複数のイベント定義がある場合、そのイベント定義が入力イベントと出力イベントであれば、同時刻に記述しても良いものとする。

同じイベント時刻に複数のイベントが記述されたWFC定義は、記述された順番に実行されるものと解釈する。同じイベント時刻に入力イベント同士や出力イベント同士の記述がされた場合に対しては、基本的にエラーと解釈しアプリケーションでエラーメッセージを出力するものとする。また入力用イベントと出力用イベントはお互いに作用しないものとして扱うものとする。従って出力モードに設定した時点でドライバがオフする排他的な動作はしない。テスターにおいてドライバオフの動作が必要であれば明確にForceOff(Z)のイベント定義を行なわなければいけない。

エラーメッセージ出力後のアプリケーションの処理の継続については、記述順に実行する、あるいはその結果としての後方優先などアプリケーションでの処理に任せるものとし、その動きをメッセージ出力することを推奨する。

テスターにおけるアプリケーションでは、デバイステストで期待されるSTIL記述と異なる動作をする場合、即ち本解釈と異なった動きをする場合、ワーニングないしはエラーメッセージを出力することを推奨する。

2 87 Waveform event definitions 88 Table 11 有 Markerイベント記述に対する問題点

Markerイベントが記述されているときの扱いが不明。IEEE仕様に記述例が無いため、どのようなケースでの使用を想定しているのかが分からない。

Page25 Application Markerイベントは、テスト動作に関するイベントではないため、一般のアプリケーションでは無視するなどアプリケーションの処理に任せるものとする。

Markerイベントの情報を扱う必要がないアプリケーションでは、STILファイルに記述されたMarkerイベントの定義を無視したことが分かるようにメッセージ出力することを推奨する。

3 89 Timing and WaveformTable example -

4 90 Rules for timed event ordering andwaveform creation

-

5 93 Rules for waveform inheritance -

19 -

DescriptionPage23 - 24一つのWFCに対して同じイベント時刻に複数のイベント定義がある場合の解釈はどのように行なえばよいか、また、出力モードへの切り替えは、ForceOffの明確な定義を必要とするかが不明である。例えば次のような定義に対する解釈はどうすべきか。[ 0 ｛ 0ns Z; 0ns X; ｝]

同時刻に複数のイベントが記述された場合の解釈についての問題点

PatternBurst block

PatternExec block

1

Timing block and WaveformTable block

Spec and Selector blocks

Timing and WaveformTable syntax84


fukui


fukui


fukui







1 94 Spec and Selector block syntax 94 10-22 有 SelectorブロックのMeas選択時における問題点

Meas選択時はMeasの実行によりタイミング値が定まるため、実際にテスターでのデバイス実測を行なうまで明確にタイミング値を決めることができない。このためアプリケーションによってはタイミング値の扱いをどうするかが問題となる。例えばMeasが選択されたSTILデータでシミュレーションを実行する場合にはタイミング値が決められないことになる。

Page26 - 28 Application Meas選択時にタイミング値を決めるようなSTILデータに対して、その通り動けるアプリケーションと動けないアプリケーションがあるため、その取扱いは必ずしも同じである必要は無い。したがってMeas選択時のタイミング値の取扱いは個々のアプリケーションに任せるものとする。

アプリケーションではMeas選択時のタイミング値の取り扱いをメッセージ出力することを推奨する。


fukui







2 96 Spec and Selector block example -

20 -

1 98 ScaｎStructures block syntax 98 8 有 ScanCellsのScanCell Names記述に関する問題点

STIL1450.0 ScanCellsの中にCELLNAME-LISTの記述が以下のように定義されている。20.1 ScanStructures block syntax(P98)ScanCells: Identifies the scan cells comprisingthe scan chain.CELLNAME-LIST is ScanLength scan cellNAMEs separated by whitespace.Inversion is also specified by interleaving the "!"character between scan cell NAMEs (alsoincludes before the first scan cell and after thelast scan cell). Scan cell NAMEs are orderedfrom the first scan cell to be shifted (input) tothe last scan cell to be shifted (output).

ScanStructuresブロックのScanCellsステートメントにおいてScan Cell Names記述にFFのインスタンス名までを記述すれば良いのか、FFのピン名までも含めて記述すれば良いのかが明確でない。さらにインスタンス名の記述がVerilog形式なのかVHDL形式なのか、または独自形式なのかが指定できないため、インスタンス名の記述形式の判断はツールのインプリに依存してしまう。このためパラレルロードシミュレーションの実行に支障をきたしている。

Page113-116 Application パラレルロードシミュレーションに必要な情報はSTIL1450.1のScanCellTypeブロックとScanCellsブロックで記述可能なため、STIL1450.1で記述することを推奨する。　ScanCellsステートメントに替わってScanCellsブロックでFF(セル)のインタンス名を書き、ScanCellTypeのスキャン入力/出力でFF(セル)のピン名を記述することを推奨する。また各FF(セル)のインスタンス名をVerilog形式あるいはVHDL形式のいずれかで記述することを推奨する。どちらを採用するかはアプリケーションに任せる。詳細はSTIL活用ガイド1450.1の「ScanCellsの定義に関する問題点」を参照。例) STIL 1.0 { Design 2005; } ScanCellType FD1 {　　CellIn "MASTER" : "SIN1" ; //セルタイプのスキャンイン名SIN1を定義　　CellOut "SLAVE" : "SOUT1" ; //スキャンアウト名SOUT1を定義 }　ScanCellType FD2 { CellIn “MASTER" : “SIN2" ; //セルタイプのスキャンイン名SIN2を定義　　 CellOut “SLAVE" : “SOUT2" ; //スキャンアウト名SOUT2を定義 }　ScanCells {　 "top.a1" "FD1" ; "top.a2" "FD1" ; "top.a3" "FD2" ;・・・・・； } // “top.a1"、“top.a2"はScanCellType FD1を"top.a3"はScanCellType FD2を参照

2 99 ScanStructures block example -

21 -

1 100 Cyclized data -

2 101 Multiple-bit cyclized data 101 1-22 有 DataBitCount記述のパターン省略記述に関する問題点

DataBitCountが記述されたVecor文の後に空のVector文が記述された場合に、終状態を引きずるのか、直前のVector文と全く同じ記述がされているものとするのかが曖昧である。

Page57 - 59 Description DataBitCountが記述されたVecor文の後に空のVector文が記述された場合に、直前のVector文と全く同じ記述がされているものと解釈する。

3 102 Non-cyclized data -

4 102 Scan data -

5 103 Pattern labels -

22 -

1 103 Vector (V) statement 103 1-9 有パターン多重定義に関する問題点

同じピンに対して一つのアドレスに複数の異なるパターンが記述された場合の解釈が不明確である。また双方向ピンに対して、一つのアドレスのパターン記述が入力用のパターン(WFC)と出力用のパターン(WFC)の双方が別々に記述されている場合の解釈が不明確である。そのため解釈の相違によりシミュレーションでエラーとなるケースも生じており問題である。

Page29 - 31 Application 一つのVector文、1つのCondition文では同じピンに対してパターンの多重定義は許さないものとする。すなわち一つのVector文、1つのCondition文では各ピンに対して少なくとも一度だけパターンの定義ができるものとする。また双方向ピンに対して、一つのアドレスのパターン記述が入力用のパターン(WFC)と出力用のパターン(WFC)の双方が別々に記述されている場合は、エラーと解釈しアプリケーションでエラーメッセージを出力するものとする。

エラーメッセージ出力後のアプリケーションの処理の継続については、後方に記述されているパターン(WFC)定義だけを有効にするなどアプリケーションでの処理に任せるものとし、その動きをメッセージ出力することを推奨する。

2 104 WaveformTable (W) statement -

3 104 Condition (C) statement -

4 105 Call statement -

5 105 Macro statement -

ScanStructures block

STIL Pattern data

STIL Pattern statements


fukui


fukui


fukui







6 106 Loop statement 106 1-8 有 Loopブロック内のタイミング切り替え・パターン省略表記における問題点

Loopブロック内で先頭のVector文のパターンが省略表記されている場合、またLoopブロック内の途中でタイミング切り替えが行なわれている場合、テストパターンはどのように記述されているものと解釈すればよいかが不明である。

Page32 - 35 Description Loopブロック内で先頭のVector文においてパターン記述が省略表記されている場合（即ち全てのピンに対してのパターン記述がされていない場合）、省略表記されたピンに対するパターン(WFC)は、Loopブロックの前のパターン(WFC)が記述されているものと解釈する。すなわち、Loopブロック内に記述されたテストパターンの記述は、ループブロック内を実行する1回目と2回目以降で、同じテストパターンが実行されるものと解釈する。

Loopブロック内の先頭ではパターンの省略表記を行なわないことを推奨する。

Loopブロック内の先頭でタイミング設定が行われておらず、Loopブロック内の途中でタイミングの切り替えが行なわれている場合、先頭のVector文において使用されるタイミング情報は、Loopブロック内に入る直前に記述されているVector文が使用するタイミング情報と同じであると解釈する。このタイミング情報はLoopブロックの先頭のテストパターン（Vector文)のタイミング情報と見なされ、1回目のみならず2回目以降もLoop実行時に参照されるものとする。

Loopブロック内の先頭ではタイミング設定の省略表記を行わないことを推奨する。特にLoopブロックのパターンの途中でタイミングの切り替えを行なう場合には、Loopブロックの先頭パターンのタイミングを明示するためにタイミング設定を行うことを推奨する。


fukui







Gotoステートメント、Startステートメントを使った飛び先についてもLoopブロックの先頭文と同じようにパターンやタイミングの省略表記を行なわず、明記することを推奨する。

7 106 MatchLoop statement -

8 107 Goto statement -

9 107 BreakPoint statement -

10 107 IddqTestPoint statement 107 1-3 有 IDDqテストの測定順に関する問題点

IDDqテストはIddqTestPointステートメントで指定された複数のポイントで測定を行なうが、その際の測定順は故障検出能力の高いポイントから順に測定するのが効率的である。しかしながら、現状のIddqTestPointステートメントの仕様では、故障検出率など測定順に関わる情報を記述することができない。このため、効率の良いテストプログラムを作成するためにはIDDqの測定順を故障検出能力の高い順に決める必要があるため、故障シミュレーションの結果ファイルなどを参照しなければならなくなる。

Page60 - 62 Description IDDqテストポイントの測定順に関わる情報を記述する際にはIddqTestPointステートメントを拡張しUserKeywords　Detectionを使って記述することを推奨する。

11 108 Stop statement -

12 108 ScanChain Statement 108 1-10 有 ScanChainステートメントに対する問題点

複数のScanChainブロックをアクティブにする記述方法が明確に仕様に定義されていない。

Page36 - 38 Description Patternブロック内、Proceduresブロック内、MacroDefsブロック内において、ScanChain文が記述されていない場合には、全てのスキャンチェーンがアクティブになるものとする。ScanChain文が記述された場合には、そのScanChain文で指定されたスキャンチェーンだけがアクティブになるものとする。複数のスキャンチェーンをアクティブにするには、ScanChain文でアクティブにしたいスキャンチェーンを一つずつ全て記述するものとする。また、アクティブにされたスキャンチェーンを解除するステートメントが用意されていないため、スキャンチェーン文の後の任意のスキャンチェーンに対するシフト動作の実行によって解除されるものと解釈する。再度特定のスキャンチェーンをアクティブにするには、特定のスキャンチェーンに対するScanChain文を記述し直す必要がある。

ScanChain文の後に実行される一連のパターンのシフト動作の対象となるスキャンチェーンとスキャンチェーン文でアクティブであることを宣言したスキャンチェーンとが異なるとアプリケーションサイドで認識できる場合には、エラーとするか、ワーニングを出力して処理を継続するかの取り扱いは各アプリケーションに任せる。

複数のスキャンチェーンをアクティブにするには、設計環境へのSTIL拡張仕様(STIL1450.1)にあるActiveScanChains(16章)、ScaninChainGroups(14章)を使用すれば簡潔に記述することができる。

23 -

1 108 Pattern block syntax -

2 109 Pattern initialization - Patternブロックの先頭Vector文におけるピン定義の問

題点

(1)Patternブロックの先頭Vector文に記述されていないピンが、 Patternブロックの途中で独立したPatternブロックとして使用されるProcedureブロックやIncludeファイルに記述されている場合、記述されていないピンに対してDefaultStateの値を適用すべきか、仕様違反として取り扱うべきかが不明である。

Page63 - 65 Description Patternブロックの先頭Vector文に記述されていないピンが、 Patternブロックの途中で独立したPatternブロックとして使用されるProcedureブロックやIncludeファイルに記述されている場合、 Patternブロックの先頭Vectorで使用されていないピンが途中のVector文で使用されているものと同じ扱いとして仕様違反とする。

(2)Patternブロックの先頭に独立したPatternブロックとして使用されるProceduresブロックやIncludeファイルが記述されており、そのProceduresブロックやIncludeファイルの先頭にパターンブロックで使われているピンが全て記述されていない場合、記述されていないピンに対してDefaultStateの値を適用すべきか、仕様違反として取り扱うべきかが不明である。

Page63 - 65 Description Patternブロックの先頭に独立したPatternブロックとして使用されるProceduresブロックやIncludeファイルがあり、それらの先頭Vector文に記述されていないピンがある場合、全パターンブロックを通して途中で記述されていないのであれば、 Patternブロックの先頭ピンはデフォルトステートを適用する。独立したPatternブロックとして使用されるProceduresブロックやIncludeファイルの先頭Vector文に記述されていないピンが、全パターンブロックを通して途中で記述されている場合は仕様違反とする。

3 109 Pattern example -

Patternブロックの先頭Vector文ではそのPattternブロックで使用される全てのピンのステートを記述することを推奨する。

Pattern block


fukui


fukui


fukui


fukui







24 109 Table13 有 Proceduresブロックにおける未定義ピンの状態に関する問題点

Procedures中に全てのピンが記述されていない場合、記述されていないピンの取り扱い方法が不明である。

Page39 - 40 Description 記述されていないピンに対してはDefaultState文で定義されている場合はその値を、またDefaultState文で定義されていない場合はDefautState文のデフォルト値をそのピンの値とする。なお入力のデフォルト値はZであり、明確に規定のない出力のデフォルト値はXとする。

DefaultStateは1回でもCondition文ないしはVector文でパターン(WFC)がPatternブロックのどこかで記述された場合には無効になる、すなわち、DefaultState文で定義されていないものと見なされる。

Proceduresブロックは独立したブロックであり先頭のパターンにおいては常にDefaultStateが有効となっている。

Proceduresブロックの先頭には、MacroDefsブロックやPatternブロックと同様に、DefaultState文が有効なピンを除き、Patternブロックで使用される全てのピンに対するステートをCondition文ないしはVector文で記述することを推奨とする。

1 110 Procedures block -

2 111 Procedures example -

3 111 MacroDefs block -

4 111 Scan testing -

5 112 Procedure and Macro Datasubstitution

112 16-20 有パターン代入文字"#"に対する問題点

パターンに代入を行う場合、"#"を使用してShiftブロック内でのスキャンパターンへの代入やMacroDefsブロック内のVector文、またはProceduresブロック内のVector文への代入を行うことができる。しかし後者のVector文への代入方法が仕様に明確に記載されておらず不明確である。

Page41 - 46 Description MacroDefsブロック内のVector文、またはProceduresブロック内のVector文にある#には、Macro文またはCall文で記述されているパラメータデータ(パターン)はAlignment文の定義に従って記述された順番に#へ代入するものと解釈する。(cf. %を使用した代入の場合には、MacroDefsブロック内のVector文、またはProceduresブロック内のVector文にある%に、Macro文またはCall文で記述されているパラメータデータ(パターン)はAlignment文の定義に従って1つだけ%に代入される。）

Macro文またはCall文で記述されているパラメータデータ(パターン)がピンに対してまたはピングループ一括に対して定義されている場合には、そのピンまたはピングループに対する#と%の混在したVector文による代入記述は許さないものとする。

Macro文またはCall文で記述されているパラメータデータ(パターン)がピングループに対してピン毎に定義されている場合には、そのピングループの各ピンに対しVector文を通して#と%の混在しないVector文による代入記述は許されるものとする。

114 114 1-17 有パターンの代入に関する問題点

ProcedureやMacroの引数にパターンを代入する際、引数の数に対してパターンが不足している場合の代入方法が不明確である。

Page125 - 137 Description 　呼出し時に代入されるSignalGroups名(sigref-exprs)の中に、本体の定義中にあるSignalGroups名と同じものがあれば、先頭の一致するSignalGroups名のV文から順にパターン(引数)を代入する。この操作を一致するSignalGroups名がなくなるまで繰り返す。ただし一致するSignalGroups名の呼出し時にある代入パターンは後続の同一名の本体の代入すべきV文(# or %があるV 文)にのみ使われ余れば捨てられ、展開して対応する信号の代入には用いられない。　次に代入すべき本体のV文が残り呼出し時に代入されるSignalGroups名が残っていれば、呼出し時に記述された順にSignalGroupsを展開して対応する信号に記述されたパターンを代入していく。本体の代入すべきV文がなくなれば、これで代入操作は終了となる。このとき残ったSignalGroups名の中に代入すべき信号が重複しているときにはどの値を代入すべきか特定できないためエラーとなることに注意する

Procedures and MacroDefs blocks


fukui


fukui


fukui







　これでもまだ本体の代入すべきV文に信号が残り、呼出し時に代入するパターンが不足する場合には、その信号に代入すべきV文が本体の定義中で初に現れる直前に明示されているパターンをその信号に代入するものとする。　もし本体定義中で代入すべきV文の直前に明示されたパターン(WFC)がなく、代入するパターンが不足する場合には、Procedureの呼び出しがエラーとなり、Macroに対しては呼出し直前のパターン(WFC)を継承し代入することになる。

以下の項目はテストプログラムを作成する際に必要となるテスター制御情報の中で現STIL標準仕様に不足している情報である。これらの情報についてはSTIL標準もしくはClarificationとして新たに盛り込まれるまでは、UserKeywordsやPragma,NameMapsなどを使用して、提案する記述例に従い共通利用を図ることを推奨するものである。なお、IEEEによってSTIL標準として記載された場合にはそれに従うものとする。UserKeywordsについては、問題点の関連資料をご参照願います。







Waveform event definitions 有ドライバ切り替え時刻＞入力波形のエッジのタイミング使用時の問題点

ドライバ切り替え時刻を入力波形のエッジより大きい時刻に設定する場合、現状のSTILの仕様の範囲内でその波形を表現しようすると、出力モード→入力モードに切り替わった場合の入力波形と、入力モード→入力モードの場合の入力波形とでWFCを変えるか、WaveformTableを切り替えないと表現できない。ドライバイネーブルタイミングをサポートしているテスターでは、上記制約によりテストパターンを書き換えないとテストできないケースが生じる。

Page47 - 51 Application 出力モード→入力モードの場合と、入力モード→入力モードの場合とで入力タイミングが異なる場合、STILの仕様通りに定義し記述する（関連資料の記述例参照)ことを推奨する。但し、ドライバイネーブルタイミングをサポートしているテスターでは、パターンデータの記述が複雑になるため、アプリケーションサイドで出力から入力に切り替わるときの入力タイミングをドライバイネーブルタイミングとして例外的に処理しても良いものとする。以下のように記述した場合、WFC 0,1使用時にドライバ切り替えタイミングがL,H,T,Xと同様に50nsで切り替わっている、つまり関連資料の記述例と同等であると見なして処理しても良いものとする。即ち、　　01{'0ns' D/U; }　　LHTX { '50ns' Z; '80ns' L/H/T/X; }

で定義されたテストパターンに対して、出力から入力に変化するサイクルのパターンデータ「０，１」を

　01{ '0ns' D/U; } 　LHTX { '50ns' Z; '80ns' L/H/T/X; }　 AB{ '50ns' D/U; }

で定義されたパターンデータ「Ａ，Ｂ」と見なして処理しても良いものとする。上記のように見なしてアプリケーションが動くとき、この動作を明示的に表すために、関連資料において新規に定義するドライブイベントのUserKeywords e を使って表記しても良いものとする。上記例外処理をサポートするアプリケーションがSTILデータを出力する際には、STIL仕様に従った形式とドライブイベントのUserKeywords e を使用した形式のいずれにおいても出力可能なものとする。

TestType statement 有テスト種別記述に関する問題点

テスト種別を記述するためのステートメントが仕様に用意されていない。

Page52-53 Description テスト種別は1450.6のPatternInformationブロックのPatternあるいはPatternBurstブロックステートメントを用いて、その中で定義できるPurposeステートメントの UserUSER_DEFINEDを使って、これまで活用ガイドで提案してきた下記のキーワードで記述することを推奨する。なお詳細はSTIL活用ガイド1450.6の「テストパターンの種別やテスト方式などパターン属性の記述に関する問題点」の提案するSolution を参照のこと。

InfiniteLoop statement 有無限ループ記述に関する問題点

テスターにおいて、テストパターン実行時に無限ループをさせる場合があるが、そのステートメントが仕様に用意されていない。

Page54 - 55 Description テストパターン実行時に無限ループをさせる場合は、UserKeywordsでInfiniteLoopを定義してpatternブロック中でInfiniteLoopステートメントを記述することを推奨する。

16

TestType statement in PatternExec 有 PatternExecブロック内のテスト種別記述に関する問題点

テスト実行時に、テスト種別を定義するステートメントをPatternExecブロックに記述する必要があるが記述できるようになっていない。

Page56 Description PattenExecブロックに、TestTypeステートメントを記述することを推奨する。

有 ADC変換テストにおけるテスターのDACユニットの設定に関する問題点

ADC変換テストにおけるDACユニットの設定が記述できるようになっていない。

Page68-70 Description STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したADCUnitsブロックを使用してテスターのDACユニット設定を記述することを推奨する。

有 ADC変換テストにおけるリファレンス電源の条件記述に関する問題点

ADC変換テストにおけるリファレンス電源の条件が記述できるようになっていない。

Page71-72 Description STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したVrefLevelsブロックを使用してリファレンス電源の条件を設定することを推奨する。

有 ADC変換テストにおけるテスターのデータ取り込みユニット記述に関する問題点

ADC変換テストにおけるテスターのデータ取り込みユニットを記述できるようになっていない。

Page73-74 Description STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したDoutCapUnitsブロックを使用してテスターのデータ取り込みユニットを設定することを推奨する。

有 ADC変換テストにおけるブロック名の参照に関する問題点

ADCUnits/VrefLevels/DoutCapUnitsブロック名をPatternExecで参照できるようになっていない。

Page75-77 Description UserKeywordsで定義したADCUnits/VrefLevels/DoutCapUnitsブロック名をDCSetsブロックで定義し、PatternExecで参照できるようにすることを推奨する。

PatternExec block

ADCUnits block

VrefLevels block

DoutCapUnits block

PatternExec block（DCSets）


fukui


fukui


fukui


fukui


fukui


fukui


fukui


fukui







UserKeywordsで定義したADCUnits/VrefLevels/DoutCapUnitsブロック名を直接PatternExecブロックで参照できるようにすることを推奨する。

有 ADC変換テストにおけるADC変換動作パターンの記述に関する問題点

ADC変換テストにおけるADC変換動作パターンを記述できるようになっていない。

Page78-79 Description UserKeywordsでStartAnalogVoltage/ StopAnalogVoltage、ADCMeasLoopを定義し、StartAnalogVoltage/ StopAnalogVoltageステートメントを使用してDACユニット出力のデバイスアナログ入力への印加開始、終了位置を記述し、ADC変換動作の繰り返しをADCMeasLoopステートメントを使用して記述することを推奨する。

有 DAC変換テストにおけるADCユニット記述に関する問題点

DAC変換テストにおけるADCユニットの設定が記述できるようになっていない。

Page80-83 Description STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したDACUnitsブロックを使用してADCユニット条件を設定することを推奨する。

有 DAC変換テストにおけるリファレンス電源の条件記述に関する問題点

DAC変換テストにおけるリファレンス電源の条件が記述できるようになっていない。

Page84-85 Description STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したVrefLevelsブロックを使用してリファレンス電源の条件を設定することを推奨する。

有 DAC変換テスにおけるブロック名の参照に関する問題点

ADCUnits/VrefLevelsブロック名をPatternExecで参照できるようになっていない。

Page86-88 Description UserKeywordsで定義したDACUnits/VrefLevelsブロック名をDCSetsブロックで定義し、PatternExecで参照できるようにすることを推奨する。

UserKeywordsで定義したDACUnits/VrefLevelsブロック名を直接PatternExecブロックで参照できるようにすることを推奨する。

有 DAC変換テストにおけるDAC変換動作パターンの記述に関する問題点

DAC変換テストにおけるDAC変換動作パターンを記述できるようになっていない。

Page89-90 Description UserKeywordsでDACMeasPattern、Cap、DaCUnitsを定義し、Patternブロック中にDACMeasPatternブロックを定義し、Capステートメント、DACUnitsステートメントを使用し、DAC変換動作パターンを記述することを推奨する。

有 PLLテストのテスターの周期測定器の設定に関する問題点

PLLテストのテスターの周期測定器の設定が記述できるようになっていない。

Page91-92 Description UserKeywordsで定義したPeriodCounterブロックを使用してテスターの周期測定器の設定を記述することを推奨する。

有 PLLテストのテスターの周期測定器の設定の参照に関する問題点

PLLテストのテスターの周期測定器の設定をPatternExecで参照できるようになっていない。

Page93 Description UserKeywordsで定義したPeriodCounterブロックをPatternExecブロックで参照できるようにすることを推奨する。

有 PLLテストのPeriodカウンタ測定パターンのループ指定の記述に関する問題点

PLLテストのPeriodカウンタ測定パターンのループを記述できるようになっていない。

Page94 Description UserKeywordsでPeriodCounterLoopを定義し、Patternブロック中にPeriodCounterLoopステートメントを使用してPeriodカウンタ測定パターンのループを記述することを推奨する。

PatternExec block（DCSets）

Pattern statement

PeriodCounter block

PatternExec block

Pattern statement

DACUnits block

VrefLevels block

Pattern statement


fukui


fukui


fukui


fukui


fukui


fukui


fukui


fukui







有 MemoryBistパターンの設定に関する問題点

MemoryBistパターンの設定が記述できるようになっていない。

Page95-100 Description UserKeywordsで定義したMemoryBistブロックを使用してMemoryBistパターンの設定を記述することを推奨する。

有 MemoryBistパターンの設定がMemoryBIST回路、Redundancy(BIRA)回路のインスタンス毎に記述できるようになっていない。

Page95-100 Description UserKeywordsで定義したMemoryBistブロック中にInstanceブロックを使用して記述することを推奨する。

有 MemoryBistパターンの設定がRAMマクロ毎に記述できるようになっていない。

Page95-100 Description UserKeywordsで定義したMemoryBistブロック中にMacroNameブロックを使用して記述することを推奨する。

有 MemoryBistパターン設定の参照に関する問題点

MemoryBistパターン設定をPatternBurstで参照できるようになっていない。

Page101 Description UserKeywordsで定義したMemoryBistブロック名をPatternBurstブロックで参照できるようにすることを推奨する。

有 Pattern中でのBISTパターン位置に関する問題点

MemoryBistパターンのBISTパターン開始位置、BISTデータ出力のVector位置をPattern中で設定できるようになっていない。

Page102-103 Description UserKeywordsでBistStart,BistPatternOutを定義し、Pattern中にBistStart/BistPatternOutステートメントを使用してBIS開始位置/BISTデータ出力のVector位置を記述することを推奨する。

有 Pattern中でのリペアパターン位置に関する問題点

MemoryBistパターンのリペアパターン開始位置、リペアデータ取得のVector位置をPattern中で設定できるようになっていない。

Page104-105 Description BiraStart/RepairPatternOutステートメントを使用してリペア開始位置/リペアデータ取得のVector位置を記述することを推奨する。

22

100 有 Transitionパターンにおいて区別すべきrelease/captureクロック定義に関する問題点

STILにはパターンの属性を表すステートメントが存在しないため、STILだけを見てもどのようなテストパターンであったのか一概には区別がつかない。例えば、Transitionテスト用パターンであったのかどうかや、そのテストパターンの方式が ”LoC”、”LoS”のどちらであったのかの区別が出来ない。

Page106-112 Description故障診断ツールではATPGが出力したSTILがどのような情報(属性)を持ったパターンなのかを認識する必要がある。これまでSTIL活用ガイド1450.0Rev4.00ではそれらを区別するため、UserKeywords PatType;で記述することを推奨していたが、これを見直しSTIL1450.6のPatternInformationブロックのPatternあるいはPatternBurstブロックステートメントを用いて、その中で定義できるPurposeステートメントのUserUSER_DEFINEDを使って記述することを推奨する。なお詳細はSTIL活用ガイド1450.6の「テストパターンの種別やテスト方式などパターン属性の記述に関する問題点」の提案するSolutionを参照のこと。

有 Transitionパターンとして故障診断を実行する際に、Launch(*)/Captureクロックの区別がつかない。このため、故障診断実行に支障をきたしている。

Page106-112 DescriptionLaunch/Captureクロックについては区別する必要がある。これまでSTIL活用ガイド1450.0Rev4.00ではそれらを区別するため、 UserKeywords ClockRelations;で記述することを推奨していたが、これを見直しLaunch/Captureクロックの定義は1450.6の Internalブロックの中でUserKeywords ClockRelations RELATION_NAME を使って行い、Patternブロック中のLaunch/Captureクロックが入るVector文の直後にClockRelations RELATION_NAMEを記述してLaunch/Captureクロックの区別を明示することを推奨する。なお詳細はSTIL活用ガイド1450.6の「Transitionパターンにおいて区別すべき Launch/Captureクロック定義に関する問題点」の提案するSolutionを参照のこと。

98 有スキャンチェーン構成に関する問題点

ATPGはシャドースキャンチェーンにもスキャンインされるものとしてパターンを生成するため、シャドースキャンチェーンにもパラレルロードが必要となるが、現状のScanStructuresではシャドースキャンチェーンを簡潔には表現できない。

Page116-118 Description 現状、ScanChainの分岐を示す記述がないため、UserKeywords(ScanBranch)を使用して分岐の起点を定義し、ScanStrcturesのScanChain構成を明示することを推奨する。

MemoryBist block

STIL Pattern Data


fukui


fukui


fukui


fukui


fukui


fukui


fukui


fukui


fukui







Rev 更新履歴1.00 2006/1/25

2.00 2007/3/26

3.00 2008/8/1

4.00 2009/8/26

5.00 2010/9/30

6.00 2011/2/7 下記表のNo46～No47を追加

6.10 2011/7/15

6.20 2011/10/17

※4

NoNo1No2No3No4No5No6No7No8No9No10No11No12No13No14No15No16No17No18No19No20No21No22No23No24No25No26No27No28No29No30No31No32No33No34No35No36No37No38No39No40

ADC変換テストにおけるブロック名の参照に関する問題点ADC変換テストにおけるADC変換動作パターンの記述に関する問題点

PLLテストのPeriodカウンタ測定パターンのループ指定の記述に関する問題点MemoryBistパターンの設定に関する問題点

DAC変換テストにおけるADCユニット記述に関する問題点

PLLテストのテスターの周期測定器の設定の参照に関する問題点

DAC変換テストにおけるリファレンス電源の条件記述に関する問題点DAC変換テストにおけるブロック名の参照に関する問題点DAC変換テストにおけるDAC変換動作パターンの記述に関する問題点PLLテストのテスターの周期測定器の設定に関する問題点

MemoryBistパターン設定の参照に関する問題点

SignalGroupsブロックの定義に関する問題点

パターン代入文字"#"に対する問題点

Markerイベント記述に対する問題点SelectorブロックのMeas選択時における問題点パターン多重定義に関する問題点Loopブロック内のタイミング切り替え・パターン省略表記における問題点

Patternブロックの先頭Vector文におけるピン定義の問題点

ADC変換テストにおけるリファレンス電源の条件記述に関する問題点

複数のPatternExecブロックの扱いに関する問題点

Alignmentステートメントを定義した場合に使用できるパターン記述の問題点

IDDqテストの測定順に関する問題点DataBitCountのパターン省略記述に関する問題点

Pattern中でのBISTパターン位置に関する問題点Pattern中でのリペアパターン位置に関する問題点

ADC変換テストにおけるテスターのDACユニットの設定に関する問題点

テスト種別記述に関する問題点ドライバ切り替え時刻＞入力波形のエッジのタイミング使用時の問題点

PatternExecブロック内のテスト種別記述に関する問題点

ADC変換テストにおけるテスターのデータ取り込みユニット記述に関する問題点

無限ループ記述に関する問題点

更新内容※4

Includeのネスティング記述の可否に関する問題点

初版発行

タイトル

下記表のNo17～No24を追加

STIL-UGからのコメントに対して以下のとおりに変更修正。No1：問題点の解説を修正。SSTAGの備考を修正。No2：問題点の解説を修正。SSTAGの解釈、備考を修正。No3：問題点の解説を修正。SSTAGの解釈、備考を修正。No4：SSTAGの備考を修正。N05：問題点の解説を修正。SSTAGの解釈、備考を修正。No6：問題点の解説を修正。SSTAGの解釈、備考を修正。No7：問題点の解説を修正。SSTAGの解釈、備考を修正。No8：問題点の解説を修正。SSTAGの解釈を修正。No9：問題点の解説を修正。SSTAGの解釈、備考を修正。No10：問題点の解説を修正。No11：タイトルを修正。問題点の解説を修正。SSTAGの解釈、備考を修正。No12：タイトルを修正。問題点の解説を修正。SSTAGの解釈、備考を修正。No13：SSTAGの備考を修正。No14：SSTAGの解釈、備考を修正。N015：問題点の解説を修正。SSTAGの解釈、備考を修正。No16：問題点の解説を修正。SSTAGの解釈を修正。WhiteSpaceに関する説明資料を修正。

問題点の関連資料へのリンクのページ数修正。

更新内容のNo表記は以下の表に対応する

下記表のNo25～No43を追加

下記表のNo44～No45を追加No3：備考に補足追加No22:備考を修正No41：備考を修正No42：備考を修正

NO.48を追加

No15:サンプルの誤記訂正No47: サンプル例９の誤記訂正

ユーザ定義名における二重引用符の扱いに対する問題点

同時刻に複数のイベントが記述された場合の解釈についての問題点

ユーザ定義名に含まれる改行とタブ文字に対する問題点

ScanChainステートメントに対する問題点Proceduresブロックにおける未定義ピンの状態に関する問題点

ユーザ定義名における大文字と小文字の区別の扱いに関する問題点連結された文字列の扱いに対する問題点STIL予約語と予約文字の利用における問題点







No41No42No43No44

No45No46

No47

No48

BUS端子の記述に関する問題点

Transitionパターンにおいて区別すべきrelease/captureクロック定義に関する問題点ScanCellsのScan Cell Names記述に関する問題点スキャンチェーン構成に関する問題点ユーザ定義名に関する問題点

パターンの代入に関する問題点

パターンの繰り返し記述の範囲に関する問題点

コメントに関する問題点


説明資料１

ユーザー定義名に関する説明資料

ユーザー定義名とは

ユーザー定義名は下記の10個に分類した各項目を指しているものである。

（１）ピン名（Signalsブロックで定義した信号名）

（２）グループ名（SignalGroupsブロックで定義したグループ名）

（３）WFC（４）WaveformTableブロック名

（５）変数名（Specブロックで定義するVariable名）

（６）ユーザーキーワード（UserKeyworsステートメントとUserFunctionsステートメントで定義するキーワード）（７）ラベル（８）ドメイン名（SignalGroupsブロック名、Timingブロック名、Specブロック名、Selectorブロック名、ScanStructuresブロック名、PatternBurstブロック名、PatternExecブロック名、Proceduresブロック名、MacroDefsブロック名、Patternブロック名）

（９）その他ブロック名（ScanChainブロック名、Categoryブロック名、Macroブロック名、Procedureブロック名：Proceduresブロック内に定義するブロック名）（１０）その他（セル名：ScanCellsステートメントで定義するスキャンF/Fの各セル名）


説明資料２

WhiteSpace（空白、タブ、改行）に関する説明資料

WFCリストに対するWhitespaceの記述の注意事項

WFCリストは、whitespaceも含めて記述できる（改行やタブ、ブランクも自由に記述することができる）。

なお、VectorステートメントやConditionステートメントなどのパターンを記述するためのステートメントにおいて、whitespaceを含めずにWFCリストを記述す

る場合にはtokenの制限から1024文字を超えて記述できないことに注意すること。1024文字を超えて記述したい場合はwhitespaceをtoken間のセパレータとして記述しなければいけない。

Annotation文に対するWhitespaceの記述の注意事項

Annステートメントにおいて、アノテーションの文字列には「*}」以外の任意の文字列を記述できるため、Whitespaceは自由に記述できる。

Headerブロック（TITLE_STRING, DATE_STRING, SOURCE_STRING）に対するWhitespaceの記述の注意事項

TITLE_STRING, SOURCE_STRING では改行が自由に使用できる。Whitespaceを含めずにWFCリストを記述する場合にはtokenの制限から1024文字を超えて記述できないことに注意すること。1024文字を超えて記述したい場合はwhitespaceをtoken間のセパレータとして記述しなければいけない。ただし、DATE_STRINGは、Cプログラミングのctime()関数に定義された出力フォーマットで記述すると規定されており、Whitespaceは自由に記述できない。Ctime関数における出力フォーマットは以下の通り。

Includeステートメントに対するWhitespaceの記述の注意事項

インクルードファイル名は必要に応じてパス情報が付加されたSTILファイル名を記述することができる。パス情報は絶対パスや相対パスの記載はできるものとしており、パス記述やファイル名記述で使用できるWhitespaceはOSに依存する範囲になる。改行（タブも含め）はほとんどのOSで使用不可であり、ブランクは一部のOSで使用可である。従って、IncludeステートメントでWhiteSpaceを使用する場合にはOSを含めたアプリケーションサイドでの注意が必要である。Includeステートメントでパス名を指定する場合は、1024文字を超えてはならない。もし必要なら、Whitespaceではなく.(ドット)で連結して記述する。

sigref_expr, time_expr, vec_data, serial_data 　に対するWhitespaceの記述の注意事項

sigref_exprでは、ピン名（グループ名）、 + 、や - などの各々が個々に1つのtokenとなり、tokenとtokenの間にはWhitespaceが記述できる。time_exprは、sigref_exprと同様に、tokenとtokenの間にはwhitespaceが記述できる。vec_dataとserial_dataは、「WFCリストに対するWhitespaceの記述の注意事項」と同様、Whitespaceは自由に記述できるが、1024文字を超える場合はセパレータとしてのWhitespaceの記述が必要になる。


STIL活用ガイド【審議メンバー】

STIL1450.0-1999 STIL活用ガイドの審議参加会社名2011年度以降　STILテスト推進委員会定期委員会参加会社名（アルファベット順）

株式会社アドバンテスト富士通セミコンダクター株式会社パナソニック株式会社ルネサスエレクトロニクス株式会社ソニー株式会社株式会社東芝（東芝マイクロエレクトロニクス株式会社）横河テストソリューションズ株式会社

2011年度以降　STILテスト推進委員会拡大委員会参加会社名（アルファベット順）定期委員会参加会社株式会社アストロンATEサービス株式会社日本ケイデンス・デザイン・システムズ社日本イヴ株式会社メンター・グラフィックス・ジャパン株式会社日本マイクロニクス株式会社有限会社三和テクノ日本シノプシス合同会社株式会社シスウェーブテラダイン株式会社ヴェリジー株式会社

2005年度～2010年度　STILテスト推進委員会定期委員会参加会社名（アルファベット順）富士通セミコンダクター株式会社パナソニック株式会社NECエレクトロニクス株式会社※6OKIセミコンダクタ株式会社※4ルネサスエレクトロニクス株式会社※7株式会社ルネサステクノロジ※4ローム株式会社※1セイコーエプソン株式会社※1シャープ株式会社※5ソニー株式会社※1株式会社東芝（東芝マイクロエレクトロニクス株式会社）

2005年度～2010年度　STILテスト推進委員会拡大委員会参加会社名（アルファベット順）定期委員会参加会社株式会社アドバンテストアジレント・テクノロジー株式会社※1日本ケイデンス・デザイン・システムズ社クリーデンス・システムズ株式会社※1ロジックヴィジョンジャパン株式会社※5メンター・グラフィックス・ジャパン株式会社ローム/OKIセミコンダクタ株式会社※7シャープ株式会社※7日本シノプシス合同会社セイコーエプソン株式会社ソニー株式会社※2テラダイン株式会社ヴェリジー株式会社※3横河電機株式会社

※1　2006年度～2010年度は不参加※2　2007年度～2010年度は不参加※3　2008年度から参加※4　2009年度から不参加※5　2010年度から不参加※6　2005年度～2009年度は参加※7　2010年度から参加


STIL活用ガイド【特別会員コメント】

特別会員からのコメントNo タイトルコメント（社名）


関連リンク資料

STARC SSTAG


IEEE Specification (Page55)

6.1 Case sensitivity

分類

Environment：

STILをサポートするテスト環境において、STILデータを相互利用する上で共通認識されるべき内容

問題点

STILは大文字と小文字は区別する言語である。しかし大文字と小文字を区別したユーザ定義名（特に信号

名）を使用することは、以下のことから問題を引き起こす可能性があると予想される。

・STARC発行の「RTL設計スタイルガイド」ではコメントを除き、大文字／小文字のみの

違いで名称を区別することが禁止されている

・VHDL、EDIFなど、大文字/小文字の違いを区別しないフォーマットが存在する

・テスターからEDAツールにSTILデータを読ませた場合に不具合の生じる可能性がある

提案するソリューション

ユーザー定義名では、大文字と小文字のみの違いで名称を区別しない使用方法を推奨する。

（例

Abc, ABC, abcのような大文字と小文字の違いのみの名称は混在させて使用しないことを推奨す

る。）

ユーザ定義名における大文字と小文字の区別の扱いに関する問題点ユーザ定義名における大文字と小文字の区別の扱いに関する問題点

STARC SSTAG



6.7 Character strings

分類

Application：

STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケーシ

ョンツールや装置で共通認識されるべき内容

連結された文字列の扱いに関する問題点連結された文字列の扱いに関する問題点

STARC SSTAG


問題点

ピリオド文字は、2つの文字列を連結するための表記方法として用意されている特殊文字である。連結文字の表記

方法を用いれば、STILの表記上の制約である１０２４文字を越える長い文字列を表現することができる。ただし、

Timingブロック内でのInherit参照機能においては、ピリオド文字はブロック階層を表すための意味と、連結文字

を表すための意味の2つがあるため、どちらの意味を優先して解釈すれば良いかが曖昧なために問題を引き起こす

可能性がある。

Timing "WFT" {WaveformTable "TS1" {

Period ‘100ns’; Waveforms { … }

}Timing {

WaveformTable "WFT"."TS1" {Period ‘100ns’;Waveforms { … }

}WaveformTable "WFT"."TS2" {

InheritWaveformTable "WFT"."TS1";Waveforms { … }

}}

この記述は、ピリオド文字を連結文字として解釈

すれば青字で書かれたブロックから定義情報を参

照することとなるが、階層区切りと解釈すれば

InheritWaveformTableステートメントは、赤字

のWFTのタイミングブロックにあるTS1の

WaveformTableブロックから参照することとな

る。

この記述は、ピリオド文字を連結文字として解釈

すれば青字で書かれたブロックから定義情報を参

照することとなるが、階層区切りと解釈すれば

InheritWaveformTableステートメントは、赤字

のWFTのタイミングブロックにあるTS1の

WaveformTableブロックから参照することとな

る。

Timing {

WaveformTable "WFT.TS1" {

Period ‘100ns’;

Waveforms { … }

}

WaveformTable WFT.TS2 {

InheritWaveformTable "WFT.TS1";

Waveforms { … }

}

}

二重引用符で囲まれた文字列であ

れば参照は明確になる。

二重引用符で囲まれた文字列であ

れば参照は明確になる。

STARC SSTAG


提案するSolution階層としての解釈を優先する。すなわちTimingブロックのInherit

参照機能では、

ピリオド文字は初に階層を示すものとして解釈し、それで参照される定義情報が

なければ、連結文字としての解釈を行うものとする。

アプリケーションでは、Inherit参照機能においての結果、ピリオド文字が階層と

して扱われたのか、連結文字として扱われたのかをユーザに対して知らせるための

メッセージを出力することを推奨する。

STARC SSTAG



6.8 User-defined name characteristics

分類

Description：

STILデータを記述あるいは解釈する上で共通認識しておくべき内容

問題点予約文字を使ったユーザー定義名において二重引用符の有無が不明確である。予約文字は特殊文字とSI単位やSI単位のプレフィックス文字などで構成される(具体的にはIEEE SpecificationのPage57-58のTable2を参照のこと)。これらの予約文字そのもののユーザ定

義名あるいは予約文字を含んだユーザ定義名は二重引用符で囲むべきかどうかが曖昧である。

STILSTIL予約語と予約文字の利用における問題点予約語と予約文字の利用における問題点

※他にもFigure 7(Page14)、Figure 9(Page 18)、Figure 11(Page 23)などで多々記述されている。

STARC SSTAG


提案するSolution予約文字そのもののユーザー定義名と、特殊文字など（Special CharactersとWhitespace

Characters）を含んでいるユーザー定義名は

二重引用符で囲まなければならない。ただしCelやOhmなどの複数文字の予約文字は二重引用符で囲まなくても良いものとする。ユーザ定義名は混乱を避けるため二重引用符で囲む使用方法を推奨する。またWaveformChar

referencesを除き1文字のユーザー定義名や予約語、予約文字そのもののユーザ定義名は使用しないことを推奨す

る。

下記は予約文字そのものあるいは予約文字を含んだユーザ定義名(Signal Name)に対する使用可否について例示したものである。大

文字、小文字が同名の混在ケースと一文字のユーザ定義名のケースが記載されているが、このような記述はあくまでも便宜上であり、

実際のSTIL記述においてはSTIL活用ガイド1450.0の「ユーザ定義名における大文字と小文字の区別の扱いに関する問題点」と「STIL

予約語と予約文字の利用における問題点」のSolutionに従って記述することを推奨する。

例(1)User defined name of reserved word itselfSignals { A In; a In; Alignment In; Ann In; } // not OKSignals { "A" In; "a" In; "Alignment" In; "Ann" In; } // OK

(2)User defined name including reserved wordSignals { AA In; aa

In; XAlignment

In; XAnn

In; } // OKSignals { "AA" In; "aa" In; "XAlignment" In; "XAnn" In; } // OK(この記述を推奨)

(3)User defined name of Special Character itselfSignals { ; In; * In; } // not OKSignals { ";" In; "*" In; } // OK

STARC SSTAG


(4)User defined name including Special CharacterSignals { name; In; name* In; } // not OKSignals { "name;" In; "name*" In; } // OK

(5)User defined name for Engineering Prefix itselfSignals { E In; P In; T In; } // not OKSignals { "E" In; "P" In; "T" In; } // OK

(6)User defined name including Engineering PrefixSignals { EE In; PP In; TT In; } // OKSignals { "EE" In; "PP" In; "TT" In; } // OK(この記述を推奨)

(7)User defined name for SI Unit itself of single characterSignals { A In; V In; F In; s In; } // not OKSignals { "A" In; "V" In; "F" In; "s" In; } // OK

(8)User defined name including SI Unit itself of single characterSignals { AA In; VV In; FF In; ss In; } // OKSignals { "AA" In; "VV" In; "FF" In; "ss" In; } // OK(この記述を推奨)

(9)User defined name for SI Unit itself of multiple character(Cel, Hz, Ohm)Signals { Cel

In; Hz In; Ohm In; } // OKSignals { "Cel" In; "Hz" In; "Ohm" In; } // OK(書き方としてはこちらを推奨するが、

予約文字そのものなので使用しないことを推奨する)(10)User defined name including SI Unit of multiple character(Cel, Hz, Ohm)

Signals { XCel

In; XHz

In; XOhm

In; } // OKSignals { "XCel" In; "XHz" In; "XOhm" In; } // OK(この記述を推奨)

(11)User defined name for min, max itselfSignals { min In; max In; } // OKSignals { "min" In; "max" In; } // OK(書き方としてはこちらを推奨するが、

予約文字そのものなので使用しないことを推奨する)(12)User defined name including min, max

Signals { Xmin

In; Xmax

In; } // OKSignals { "Xmin" In; "Xmax" In; } // OK(この記述を推奨)

STARC SSTAG



Clause 6.8: User-defined name characteristics

（参考）IEEE STIL Clarifications (Page1)

分類

Application:

STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケー

ションツールや装置で共通認識されるべき内容

ユーザ定義名における二重引用符の扱いに対する問題点ユーザ定義名における二重引用符の扱いに対する問題点

STARC SSTAG


問題点

IEEE Specificationにおいて、二重引用符は信号名の一部には使用できないとしている。一方、

IEEE Clarificationでは、二重引用符で囲まれた信号名と、囲まれていない信号名の両方を、

Signalsブロックに一緒に記述できると記載されている。

二重引用符が信号名の一部として使えないのであれば、二重引用符で囲まれた信号名と、囲ま

れていない信号名は、共に同じ信号名を示すものであり、両方を一緒に記述できることは、同

じ信号名の重複定義を行なっていることになる。このため両者は一つのSTILファイル中では

区別して取り扱うことになる。

ネットファイルにおいて信号名は二重引用符で囲まれていないにも関わらず、ATPGツールに

よって出力されたSTILでは二重引用符で囲まれている場合が多くある。STILファイルに二重

引用符で囲まれた信号名に加えて、二重引用符で囲まれていない信号名も記述されている場合

には、どちらの信号名との対応を取れば良いかがアプリケーションサイドでは判断できなくな

る。

STARC SSTAG


【記述例】ネットとSTILにおける信号名の対応付けに関する問題点

【Verilog-HDL記述のネットファイル】

module SCNxxxx ( X, Y, SDO1, SYSCK, TM, A, B, C, D, SDI1, ACLK1, BCLK1 ) ;

output X, Y, SDO1 ;

input SYSCK, TM, A, B, C, D, SDI1, ACLK1, BCLK1 ;

supply0 NC_0 ;

supply1 NC_1 ;

IBUFU INPBUF1 ( SYSCK1, , SYSCK, NC_0 ) ;

IBUFU INPBUF2 ( A1, , A, NC_0 ) ;

IBUFU INPBUF3 ( B1, , B, NC_0 ) ;

...以下省略...

【STILファイル】

STIL 1.0;

Header {

Title " xxxxxxx ";

Date "Mon Dec 20 16:39:08 2004";

History {

...省略...

}

}

Signals {

"SYSCK" In; "TM" In; "A" In; "B" In; "C" In; "D" In; "SDI1" In { ScanIn; } "ACLK1" In;

"BCLK1" In; "X" Out; "Y" Out; "SDO1" Out { ScanOut; }

}

【STILファイル（"SYSCLK"とSYSCLKを含むSTIL）】

Signals {

"SYSCK" In; "TM" In; "A" In; "B" In; "C" In; "D" In; "SDI1" In { ScanIn; } "ACLK1" In;

"BCLK1" In; "X" Out; "Y" Out; "SDO1" Out { ScanOut; }

SYSCK In;

}

信号名の対応付けは可能

信号

名の

対

応付

けは

不可

能

STARC SSTAG


提案するSolution

二重引用符で囲まれているユーザ定義名と、二重引用符で囲まれていないユーザ定義名、例えば”Xyz”とXyz の

2つが同じ種類（ピン名であったり、ピングループ名、ドメイン名など）で使用されているユーザ定義名は、そ

のユーザ定義名が記述されたSTILを扱うアプリケーションにおいて、ユーザー定義名の重複定義としてエラー

処理されても構わない扱いとする。二重引用符の有無は、たとえアプリケーションで判断できる事項だとして

も可読性や、口頭での項目指示などで誤認し運用面でのミスを誘発する可能性が高いためである。

ユーザ定義名は、アプリケーションの内部処理に際しては、二重引用符がない形式、あるいは二重引用符が付

けられた形式のいずれか一方の形式で統一的に扱われるものとする。

記述例１：

Patternブロック名が二重引用符で囲まれたブロック名と二重引用符で囲まれていないブロック名を用いた記述

PatternBurst "BLOCK" {PatList { "PATTERN"; PATTERN;}

}PatternExec { PatternBurst "BLOCK"; }Pattern "PATTERN" {

W TS1;V { RESET=0; CLK=0; Q[7..0]=XXXXXXXX; }V { RESET=1; CLK=P; Q[7..0]=LLLLLLLH; }

}Pattern PATTERN {

W TS1;V { RESET=0; CLK=0; Q[7..0]=XXXXXXXX; }V { RESET=1; CLK=P; Q[7..0]=LLLLLLLH; }

}

STARC SSTAG


Pattern "_pattern_" {W "_default_WFT_";"precondition all Signals": C { "_pi"=¥r9 0 ; "_po"=XXX; }Macro "test_setup";"chain_test": Call "load_unload" {

"SDI1"=¥r4 0011 ; "SDO1"=¥r7 X LLHHLLHHL; }pattern0: Call "load_unload" {

"SDI1"=1010110; }Call "capture_SYSCK" {

"_pi"=001100100; "_po"=HLH; }"apply 1": Call "master_observe";"pattern0": Call "load_unload" {

"SDO1"=LLHHLLH; "SDI1"=0011011; }Call "capture_SYSCK" {

"_pi"=001001000; "_po"=HHL; }"apply 2": Call master_observe;"pattern 1": Call "load_unload" {

"SDO1"=LLHHHHL; "SDI1"=0001001; }

記述例２：

ラベル名が、二重引用符で囲まれた名前と二重引用符で囲まれていない名前を用いた記述

ユーザー定義名では、二重引用符の有

無で名前の区別を図るのではなく、番

号や文字を付加するなど違いを明確に

示したユーザ定義名によって記述する

ことを推奨する。

STILを出力するアプリケーションでは

、ユーザ定義名を二重引用符付きで出

力することを推奨する。

バスピンに対する記述方法では、

“BUS[0]”として全体を囲むのではなく、

“BUS”[0]として書くことを推奨する。

それは、“BUS”[0..7]はバスピン表記と

のみ解釈できるが、“BUS[0..7]”は特殊

文字を使った文字列とも解釈でき、区

別がつかなくなるからである。

STARC SSTAG




分類

Environment：

STILをサポートするテスト環境において、STILデータを相互利用する上で共通認識されるべ

き内容

問題の起こる背景IEEE Specificationにおいてはユーザ定義名でブランク文字を用いた記述例はあるが、タブや改行文字を用いた記述例は無い。ユーザ定義名においてタブや改行、ブランクが使われた場合、紙の上では区別がつけられない。このため,このSTILデータの受け渡しを行なう場合、タブや改行、ブランクを使ったユーザ定義名の記述方法を明確にする必要がある。

ユーザ定義名に含まれる改行、タブ文字についての問題点ユーザ定義名に含まれる改行、タブ文字についての問題点

PatternBurst "PB

BLOCK" {

PatList { BLOCK; }

}

PatternExec {

PatternBurst "PB

BLOCK";

}

Pattern BLOCK {

W TS1;

V { RESET=0; CLK=0; Q[7..0]=XXXXXXXX; }

V { RESET=1; CLK=P; Q[7..0]=LLLLLLLH; }

}

■で示された箇

所の区別

STARC SSTAG



WhiteSpace（ブランクやタブや改行）を用いたユーザ定義名を記述すると、STIL作成

者や利用者が目視によって、ブランクやタブや改行がどのように記述されているかを認

識することが難しく、書き換えられてしまっても分からず、トラブルを引き起こしやす

い。このためWhiteSpaceを用いた記述を行なう場合には、目視において問題が起こら

ない低限必要な使用上のルールを設けるべきである。したがってWhiteSpaceのうち、

ブランクを用いたユーザ定義名は使用できるが、タブや改行を用いたユーザ定義名は使

用しないものとする。

タブや改行を使用したユーザ定義名がSTILに含まれている場合、アプリケーションでは

STIL記述における記述のエラーとして扱うとともに、修正を促すメッセージを出力する


STARC SSTAG



10. Include statement

分類

Description：STILデータを記述あるいは解釈する上で共通認識しておくべき内容

問題点Include文で参照されるSTILファイルの中で、更にInclude文を使って他のSTILファイルからの参

照を行なうInclude文のネスティング記述がある場合、その記述の可否が仕様では明確に記載されて

いないため、扱いをどのようにすべきか不明である。即ちSTILファイル(A)からInclude文によって参照されるSTILファイル(B)の中で、更にInclude文

によってSTILファイル（C)の参照を行なうネスティング記述がある場合、STILファイル（C)を参

照するInclude文の使用の可否が不明である。

IncludeIncludeのネスティング記述の可否に関する問題点のネスティング記述の可否に関する問題点

STARC SSTAG



Include文のネスティング記述を許すものとし、そのネスティング回数には制限を設けず記述できる

ものとする。

STIL 1.0;

Timing {

…省略…

}

PatternBurst BURST {

PatList { PAT1; }

}

PatternExec { PatternBurst BURST; }

Include "sample.stil.pat";

sample.stil.tim_to_pat ファイル

STIL 1.0;

Pattern PAT1 {

W TS1;

Vector { …省略… }

}

sample.stil.pat ファイルSTIL 1.0;

Signals {

"SYSCK" In; "TM" In; "A" In; "B" In; "C" In; "D" In;

"SDI1" In { ScanIn; } "ACLK1" In; "BCLK1" In;

"X" Out; "Y" Out; "SDO1" Out { ScanOut; }

}

Include "sample.stil.tim_to_pat";

sample.stilファイル

参照参照

推奨事項について

Include文によるネスティング記述で無限ループになる場合には、誤った記述と見なして、その

STILファイルを扱うアプリケーションにおいてはエラーメッセージの出力を推奨する。即ちSTIL

ファイル(A)からInclude文によって参照されるSTILファイル(B)の中で、更にInclude文によって

STILファイル（A)の参照を行なう回帰するようなネスティング記述がある場合には、無限ループと

なるためアプリケーションはエラーメッセージを出力することを推奨する。

STARC SSTAG



15. SignalGroups block

分類


問題点

SignalGroupsブロックで定義されるピングループは、0個または複数個のピンをグルー

プとしてまとめて扱う定義ができるが、0個の定義を行なう記述方法が不明確である。ま

た0個のピングループを参照したSTIL記述があった場合にその解釈が不明である。例えばパターンブロックで0個のピングループに対してパターン定義がされている場合や、

タイミングブロックで0個のピングループに対してタイミング定義がされている場合の解

釈が不明である。

SignalGroupsSignalGroupsブロックの定義に関する問題点ブロックの定義に関する問題点

STARC SSTAG


提案するSolutionピングループ名の定義において、ピン数が0個の記述を定義する場合は以下の二つの記述方法が考え

られるが、方法１で記述するものとする。

（方法１）GroupName = ’ ’;

（方法２）GroupName = ;ピンが0個のピングループを参照するSTIL記述があった場合は、参照した結果としてピングループ

名に対応する記述はなかったものと解釈する。例えばパターンブロックで0個のピングループに対するパターン定義がされている場合には、そのピ

ングループ名に対するパターンは定義されていないものと解釈する。また、タイミングブロックで0個のピングループに対するタイミング定義がされている場合には、そ

のピングループ名に対するタイミングは定義されていないものと解釈する。ピンが0個のピングループを定義する必要がある場合を除き、ピン名の記述忘れを明確にするために、

できるだけPseudoピンを用いて定義することを推奨する。

ピン名と同じ名前を使ったピングループの定義が必要な場合を除き、同じ名前のピングループ名は

できるだけ使用しないことを推奨する。

【補足】ピンが0個のグループ名にパターンの定義を行なった場合、以下のように解釈する。

V { Pin1=0; Pin2=L; GRP_Empty=000; } //

GRP_Emptyはピン名が0個

等価の記述と解釈する

V { Pin1=0; Pin2=L; }

⇔

STARC SSTAG


Aブロック

Bブロック

STIL 1.0;

Signals {P1 In; P2 In; P3 Out; P4 Out;

}SignalGroups

{

ALL='P1+P2+P3+P4';

｝…タイミング情報の定義は省略…

PatternBurst

A_TEST {PatList

{ A_PAT1; }}PatternExec

{

PatternBurst

A_TEST；

}Pattern A_PAT1 {

W TS1;C { ALL=00XX; }

V { P1=1;P2=０;P3=L;P4=H; }

…以降のパターン記述は省略… }

STIL 1.0;

Signals {P1 In; P2 In; P3 Out; P4 Out;

}SignalGroups

{

ALL='P1+P2+P3+P4';

｝…タイミング情報の定義は省略…

PatternBurst

A_TEST {PatList


{

PatternBurst A_TEST；

}Pattern A_PAT1 {

W TS1;C { ALL=00XX; }

V { P1=1;P2=０;P3=L;P4=H; }


AブロックのSTILファイル

（ファイル名

AFUNC.stil）

STIL 1.0;

Signals {P1 In; P2 In; P3 Out; // P4の定義を削除

…その他のピン情報の定義は省略…}SignalGroups

B_block

{

P4 = '';ALL= 'P1+P2+P3+P4';

}…タイミング情報の定義は省略…

PatternBurst

B_TEST {SignalGroups

B_block;PatList


{

PatternBurst

B_TEST；

}Include “AFUNC.stil”

IfNeed

Pattern;

STIL 1.0;

Signals {P1 In; P2 In; P3 Out; // P4の定義を削除

…その他のピン情報の定義は省略…}SignalGroups

B_block

{

P4 = '';ALL= 'P1+P2+P3+P4';


PatternBurst

B_TEST {SignalGroups

B_block;PatList


{

PatternBurst B_TEST；


IfNeed

Pattern;

P1

P2

P3 P3

P4

P1

P2

何れもテスト

内容は同じ

STIL 1.0;

Signals {P1 In; P2 In; P3 Out; ;

…その他のピン情報の定義は省略… }SignalGroups

{

ALL= 'P1+P2+P3';}

…タイミング情報の定義は省略… PatternBurst

B_TEST {PatList

{B_PAT1; }}PatternExec

{

PatternBurst

B_TEST；

}Pattern B_PAT1 {

W TS1;C { ALL=00X; }

V { P1=1;P2=０;P3=L; }


STIL 1.0;

Signals {P1 In; P2 In; P3 Out; ;


{

ALL= 'P1+P2+P3';}

…タイミング情報の定義は省略… PatternBurst

B_TEST {PatList

{B_PAT1; }}PatternExec

{


}Pattern B_PAT1 {

W TS1;C { ALL=00X; }

V { P1=1;P2=０;P3=L; }


AブロックのテストパターンをInclude文でそのまま使用。BブロックのSTILにおいてPatternブロックは結果的にAブロック

のPatternブロックに対して「ピンP4に対するパターンの削除」が

行われたことになる。

【ピンが0個のピングループを使用するケースについて】

Aブロックのテストパターンを

そのまま使用したBブロックの

テストパターン記述

Aブロックのテストパターンを

基に作り直したBブロックの

テストパターン記述

IPなど中に組み込まれたブロックのテストパターン（STILファイル）をそのまま使用する場合には、未使用ピ

ンに対してはピンが0個のピングループを使用することができる。記述例1 記述例2

STARC SSTAG


STIL 1.0;

Signals {P1 In; P2 In; P3 Out; P4 Pseudo;


{

ALL= 'P1+P2+P3+P4';


PatternBurst

B_TEST {PatList


{

PatternBurst

B_TEST；


IfNeed

Pattern;

STIL 1.0;

Signals {P1 In; P2 In; P3 Out; P4 Pseudo;


{

ALL= 'P1+P2+P3+P4';


PatternBurst

B_TEST {PatList


{



IfNeed

Pattern;

Aブロックのテストパターンをそのまま使用するために外部

に出ないピンP4 をPseudoとして扱う

Aブロック

Bブロック

P1

P2

P3 P3

P4

P1

P2

前のページの記述例1では、

Aブロックのテストパターン記述の

STILを利用するために「ピンが0個のピングループ」を用いてい

る。ピンが0個のピングループの定義「P4=‘

’;」がピン名の記述

忘れでないことを明確にするために、この様なピンはPseudoで

扱うことをSTIL活用ガイドでは推奨している。Pseudoで扱う記述例3は、ピンが0個のピングループを用いた

記述例1に比べて記述の追加・変更（赤字部分）は少なくて済む。なお、Pseudoピンに対するパターンの解釈はアプリケーション

に任されているので、その取り扱いには注意が必要である。

【推奨】ピンが0個のピングループは使用せずPseudoピンとしての定義を行う

Pseudo

ピンと定義

記述例3

STARC SSTAG



16. PatternExec block

分類

Application：

STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケー

ションツールや装置で共通認識されるべき内容

問題点

複数のPatternExecブロックが定義されたSTILデータにおいて複数のPatternExecブロックの

実行順番に関する規定が無いために、STILをどのように扱えば良いのか、またその扱い方が不明

である。

複数の複数のPatternExecPatternExecブロックの扱いに関する問題点ブロックの扱いに関する問題点

STARC SSTAG


複数のPatternExecの記述例PatternBurst "BURSTBLK1" {

PatList { PAT1; PAT2; }}PatternBurst "BURSTBLK2" {

PatList { PAT3; }}PatternExec "ONE" {

PatternBurst "BURSTBLK1";}PatternExec "TWO" {

PatternBurst "BURSTBLK2";}


複数のPatternExecブロックが定義されたSTILデータにおいて複数のPatternExecブロックが記述

された場合のSTIL解釈は、複数のPatternExecブロックを記述している順番に実行して、全ての

PatternExecブロックを実行するものと解釈する。この解釈に対するアプリケーションサイドにお

ける具体的な対応方法は規定せず、個々のアプリケーションに依存するものとする。

STARC SSTAG



18.1 Timing and WaveformTable syntax

分類


問題点

一つのWFCに対して同じイベント時刻に複数のイベント定義がある場合の解釈はどのように行なえ

ばよいか、また、出力モードへの切り替えは、ForceOffの明確な定義を必要とするかの解釈が不明

である。例えば次のような定義に対する解釈はどうすべきか。

（問題点を説明する記述例）下線で示した記述の解釈についてTiming {

WaveformTable "TS1" {

Period '300ns';

Waveforms {

ABUS { 01 { '0ns' D/U; }}

BBUS { 01 { '0ns' D/U; }}

ABUS { HLZX { '0ns' Z; '0ns' X; '250ns' H/L/T/X;}}

BBUS { HLZX { '0ns' Z; '0ns' X; '250ns' H/L/T/X;}}

}

}

同時刻に複数のイベントが記述された場合の解釈についての問題点同時刻に複数のイベントが記述された場合の解釈についての問題点

テスター動作に依存する範囲であり意識して記述すべきであるが、本件の扱いについてテスターメーカーへ調査

を行ない、その結果を審議の参考にする。

STARC SSTAG



一つのWFCに対して同じイベント時刻に複数のイベント定義がある場合、そのイベント定義が入力

イベントと出力イベントであれば、同時刻に記述しても良いものとする。

同じイベント時刻に複数のイベントが記述されたWFC定義は、記述された順番に実行されるものと解釈する。同じイベント時刻に入力イベント同士や出力イベント同士の記述がされた場合に対しては、基本的にエラーと解釈しアプリケーションでエラーメッセージを出力するものとする。また入力用イベントと出力用イベントはお互いに作用しないものとして扱うものとする。従って出力モードに設定した時点でドライバがオフする排他的な動作はしない。テスターにおいて

ドライバオフの動作が必要であれば明確にForceOff(Z)のイベント定義を行なわなければいけない。

エラーメッセージの出力後のアプリケーションの処理の継続については、記述順に実行する、あるいはその結果としての後方優先などアプリケーションでの処理に任せるものとし、その動きをメッセージ出力することを推奨する。テスターにおけるアプリケーションでは、デバイステストで期待されるSTIL記述と異なる動作をす

る場合、即ち本解釈と異なった動きをする場合、ワーニングないしはエラーメッセージを出力する


STARC SSTAG


IEEE Specification (Page88 Table11)

分類

Application：

STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケーションツールや装

置で共通認識されるべき内容

問題点

Markerイベントが記述されているときの扱いが不明。IEEE仕様に記述例が無いため、どのようなケースでの使用

を想定しているのかが分からない。


Markerイベントは、テスト動作に関するイベントではないため、一般のアプリケーションでは無視するなどアプ

リケーションの処理に任せるものとする。Markerイベントの情報を扱う必要がないアプリケーションでは、STIL

ファイルに記述されたMarkerイベントの定義を無視したことが分かるようにメッセージ出力することを推奨する。

MarkerMarkerイベント記述に対する問題点イベント記述に対する問題点

STARC SSTAG



19. Spec and Selector blocks

分類

Application：



問題点Meas選択時はMeasの実行によりタイミング値が定まるため、実際にテスターでのデバイス実測を行なうまで明

確にタイミング値を決めることができない。このためアプリケーションによってはタイミング値の扱いをどうする

かが問題となる。

例えばMeasが選択されたSTILデータでシミュレーションを実行する場合にはタイミング値が決められないことに

なる。

SelectorSelectorブロックのブロックのMeasMeas選択時における問題点選択時における問題点

STARC SSTAG


PatternBurst

"tester burst" {

PatList

{ "tester pattern"; {

}

PatternExec

{

Timing "tester timing";

Selector "measure";

PatternBurst

"tester burst";

}

Pattern "tester pattern" {

W TS1;

V { ALL=0000000000LLLLLLLL; }

V { ALL=0010000000HLLLLLLL; }

V { ALL=0001000000LHLLLLLL; }

V { ALL=0000100000LLHLLLLL; }

V { ALL=0000010000LLLHLLLL; }

V { ALL=0000001000LLLLHLLL; }

V { ALL=0000000100LLLLLHLL; }

V { ALL=0000000010LLLLLLHL; }

V { ALL=0000000001LLLLLLLH; }

}

記述例：【変数名"oe_clk_edge"をMeas指定した記述例】イネーブル信号の立下りエッジタイミングをMeas指定

STIL 1.0;Signals {DIR In;OE In;A[7..0] In; B[7..0] Out;

}SignalGroups

{ABUS='A[7..0]';BBUS='B[7..0]';ALL ='DIR + OE + ABUS + BBUS';

}Selector "measure" {"oe_clk_edge" Meas;

}Timing "tester timing" {WaveformTable

TS1 {Period '500ns';Waveforms {DIR { 01 { '0ns' D/U; } }OE { 01 { '0ns' U; '"oe_clk_edge"' D/U; '350ns' U; } }ABUS { 01 { '10ns' D/U; } }BBUS { HLZ { '0ns' Z; '0ns' X; '250ns' h/l/t; '300ns' X;} }

}}

} 右へ続く

→

STARC SSTAG



Meas選択時にタイミング値を決めるようなSTILデータに対して、その通り動けるアプリケーショ

ンと動けないアプリケーションがあるため、その取扱いは必ずしも同じである必要は無い。した

がってMeas選択時のタイミング値の取扱いは個々のアプリケーションに任せるものとする。

アプリケーションではMeas選択時のタイミング値の取扱いをメッセージ出力することを推奨する。

STARC SSTAG


IEEE Specification （Page103）

22.1 Vector (V) statement

分類

Application：



問題点

同じピンに対して一つのアドレスに複数の異なるパターンが記述された場合の解釈が不明確である。

また双方向ピンに対して、一つのアドレスのパターン記述が入力用のパターン(WFC)と出力用のパ

ターン(WFC)の双方が別々に記述されている場合の解釈が不明確である。そのため解釈の相違によ

りシミュレーションでエラーとなるケースも生じており問題である。

パターン多重定義に関する問題点パターン多重定義に関する問題点

STARC SSTAG


提案するSolution一つのVector文、1つのCondition文では同じピンに対してパターンの多重定義は許さないもの

とする。すなわち一つのVector文、1つのCondition文では各ピンに対して少なくとも一度だけ

パターンの定義ができるものとする。また双方向ピンに対して、一つのアドレスのパターン記述

が入力用のパターン(WFC)と出力用のパターン(WFC)の双方が別々に記述されている場合は、

エラーと解釈しアプリケーションでエラーメッセージを出力するものとする。

エラーメッセージ出力後のアプリケーションの処理の継続については、後方に記述されているパ

ターン(WFC)定義だけを有効にするなどアプリケーションでの処理に任せるものとし、その動

きをメッセージ出力することを推奨する。

STARC SSTAG


【【例１例１】】11つのつのVectorVector内において内において双方向ピンを入力と出力に分ける双方向ピンを入力と出力に分ける記述記述Signals { "IN1" In; "OUT1" Out; "IO1" InOut; }SignalGroups { "_pi" = ' "IN1"+"IO1" '; "_po" = ' "OUT1"+"IO1" ' }…Procedures {

"proc" {W "_default_WFT_";V { "_pi"=01; "_po"=XX; }…

}}

【例2】

複数の複数のVectorVector内において内において双方向ピンを入力と出力に分ける双方向ピンを入力と出力に分ける記述記述

Signals { "CLK" In; "IN1" In; "OUT1" Out; "IO1" InOut; }SignalGroups { "_pi" = ' "IN1"+"IO1" '; "_po" = ' "OUT1"+"IO1" ' }…Procedures {

"proc" {W "_default_WFT_";V { "_pi"=01; }C { "_po"=XX; }V { "CLK"=P; }…

}}

双方向の"IO1"ピンは、パターン1とXがマッピングされ入力状

態1であるものとして、ATPGは出力している。

STIL1450.0ではマッピングする考えは無いため、重複するパターンは

後ろ側の記述を有効にするので、IO1はXになる。

正しい記述にするためには、下記のように編集する。V { "_pi"=01; "_po"=XX; "IO1"=1; }

"_po"に対してCondition文でパターンを記述しているが、"_pi" のパターン1は、次のVector文でも有効であると解釈している。

そのため、"IO1"は入力状態1であるものとして、ATPGは出力

している。

例1と同じ。正しい記述にするためには、下記のよう編集する。V { "CLK"=P; "IO1"=1; }

問題を起こすSTIL

問題を起こすSTIL

修正事例

修正事例

STARC SSTAG


IEEE Specification(Page106)

22.6 Loop statement

分類


問題点

Loopブロック内で先頭のVector文のパターンが省略表記されている場合、またLoopブロック内の

途中でタイミング切り替えが行なわれている場合、テストパターンはどのように記述されているも

のと解釈すればよいかが不明である。

Pattern PAT1 {W TS1;V { P1=0; P2=0; P3=X; }Loop 10 {

V { }W TS2;V { P1=1; P2=1; P3=H; }

}}

LoopLoopブロック内のタイミング切り替え・パターン省略表記における問題点ブロック内のタイミング切り替え・パターン省略表記における問題点

STARC SSTAG



Loopブロック内で先頭のVector文においてパターン記述が省略表記されている場合（即ち全てのピンに対しての

パターン記述がされていない場合）、省略表記されたピンに対するパターン(WFC)は、Loopブロックの前のパ

ターン(WFC)が記述されているものと解釈する。すなわち、Loopブロック内に記述されたテストパターンの記述

は、ループブロック内を実行する1回目と2回目以降で、同じテストパターンが実行されるものと解釈する。

Loopブロック内の先頭でタイミング設定が行われておらず、Loopブロック内の途中でタイミングの切り替えが行

なわれている場合、先頭のVector文において使用されるタイミング情報は、Loopブロック内に入る直前に記述さ

れているVector文が使用するタイミング情報と同じであると解釈する。このタイミング情報はLoopブロックの先

頭のテストパターン（Vector文)のタイミング情報と見なされ、1回目のみならず2回目以降もLoop実行時に参照

されるものとする。

【推奨するSTIL記述】

Loopブロック内の先頭にはパターンの省略表記を行なわないことを推奨する。

Loopブロック内の先頭ではタイミング設定の省略表記を行わないことを推奨する。特にLoopブロックのパターンの途中でタイミングの切り替えを行なう場合には、Loopブロックの先頭パターンのタイミングを明示するためにタイミング設定を行うことを推奨する。

Pattern PAT1 {W TS1;V { P1=0; P2=0; P3=X; }Loop 10 {

W TS1;V {P1=0; P2=0; P3=X; }W TS2;V { P1=1; P2=1; P3=H; }

}}

STARC SSTAG


【補足】Loop以外でパターンの実行を制御するGoto文とStart文について

実行順番により影響のあるステートメントとしてLoop文の他にGoto文やStart文がある。パターンとタイミングの省略表記に関して、（１）と（２）のケースにおいて、省略表記されたピンに対するパターンやタイミ

ングが、記述された順番によって記述されているという解釈では、STILデータの記述に問題は無い。一方、実行する順

番によって記述されているという解釈では、Patternブロックでの初のパターンが何も書かれていないことになってしま

う。したがって、Loop文の場合も含め、Goto文やStart文では、記述順番で解釈した方が、混乱が生じない。

（１）Gotoステートメントを使った場合Pattern PATT1 {

W TS1;Goto JUMP;V { ALL=11111LLLLL; } // ①JUMP: V {} // ②

}

（２）Startステートメントを使った場合PatternBurst {

Start FIRST;PatList { PATT1; }

}Pattern PATT1 {

W TS1;V { ALL=00000XXXXX; } // ①FIRST: V {} // ②V { ALL=11111LLLLL; }

}

②におけるパターンは？

②におけるパターンは？

記述順であれば①であるが、実行順であれば空白パターン②である。

(通常のアプリケーションでは、Patternブロックの先頭Vectorが空白の場合、

エラーとして扱われることになる。）

記述順であれば①であるが、実行順であれば空白パターン②である。

(通常のアプリケーションでは、Patternブロックの先頭Vectorが空白の場合、

エラーとして扱われることになる。）

STARC SSTAG


GotoステートメントやStartステートメントを用いた場合の推奨記述

Gotoステートメント、Startステートメントを使った飛び先についてもLoopブロックの先頭文と同

じようにパターンやタイミングの省略表記を行なわず、明記することを推奨する

。

STARC SSTAG



22.12 ScanChain statement

分類


問題点

複数のScanChainブロックをアクティブにする記述方法が明確に仕様に定義されていない。

提案するSolutionPatternブロック内、Proceduresブロック内、MacroDefsブロック内において、ScanChain文が

記述されていない場合には、全てのスキャンチェーンがアクティブになるものとする。ScanChain

文が記述された場合には、そのScanChain文で指定されたスキャンチェーンだけがアクティブにな

るものとする。複数のスキャンチェーンをアクティブにするには、ScanChain文でアクティブにし

たいスキャンチェーンを一つずつ全て記述するものとする。また、アクティブにされたスキャンチェーンを解除するステートメントが用意されていないため、

任意のスキャンチェーンに対する一連のパターンのシフト動作の実行によって解除されるものと解

釈する。再度特定のスキャンチェーンをアクティブにするには、特定のスキャンチェーンに対する

ScanChain文を記述し直す必要がある。

ScanChainScanChainステートメントに対する問題点ステートメントに対する問題点

STARC SSTAG


MacroDefs {unload_load {

W scan;C { all=100 001 00 XX 0000 XXXX; }Shift {

V {si1=#; si2=#; so1=#; so2=#;}}

} // unload_load}

…途中省略…

Pattern scan_loads {W wft_base;V { all = 110 111 00 XX 0000 XXXX;}ScanChain "CHAIN1";ScanChain "CHAIN2";Macro unload_load {

si1=1101110101; si2=0000111011;}V { pis = 1010;} // FORCE PIsV { pos = HLHL;} // MEASURE POsV { capture_clks = 00; pos = XXXX;}ScanChain "CHAIN1";Macro unload_load {

so1=HLHHHLHLHL;}V { all = 111 111 11 XX 0000 XXXX;}ScanChain "CHAIN2";Macro unload_load {

so2=HHHLLHHLHL;}

}

補足：IEEE Specification (Page108)•シンタックスは以下の通り定義されている。

( LABEL : ) ScanChain CHAINNAME ;

１つのScanChainステートメントで

は1つのスキャンチェーン名だけが定

義できる仕様になっているため、複

数個の定義方法が不明である。

ScanChainステートメントを用いた記述例

このシフト動作では"CHAIN1"だけがアクティブである。

このシフト動作では"CHAIN2"だけがアクティブである。

STARC SSTAG


【補足】ScanChain

の定義と、アクティブなスキャンチェーンが相違の場合について

ScanChainステートメントは、指定されたスキャンチェーンがアクティブであることをユーザ

が識別できるようにするためだけのステートメントである。そのため、Macro/Callで呼び出されるスキャンチェーンが本当にアクティブになっているかど

うかは、STILデータだけでは判断できない。

STILを扱うアプリケーションにおいて、Macro/Callで呼び出されるスキャンチェーンとアクティブで

あることを宣言したスキャンチェーンが異なると認識できる場合、エラーとするかワーニングを出力す

るか否かについては各アプリケーションに任せる

。

ScanChain文の後に実行される一連のパターンのシフト動作の対象となるスキャンチェーンとスキャン

チェーン文でアクティブであることを宣言したスキャンチェーンとが異なるとアプリケーションサイドで認識

できる場合には、エラーとするか、ワーニングを出力して処理を継続するかの取り扱いは各アプリケーション

に任せる。複数のスキャンチェーンをアクティブにするには、設計環境へのSTIL拡張仕様(STIL1450.1)にある

ActiveScanChains(16章)、ScaninChainGroups(14章)を使用すれば簡潔に記述することができる。

STARC SSTAG


IEEE Specification（Page109 Table13)

分類


問題点

Procedures中に全てのピンが記述されていない場合、記述されていないピンの取り扱い方法が不明である。

提案するSolution記述されていないピンに対してはDefaultState文で定義されている場合はその値を、またDefaultState文で定義

されていない場合はDefaultState文のデフォルト値をそのピンの値とする。なお入力のデフォルト値はZであり、

明確に規定のない出力のデフォルト値はXとする。

DefaultStateは1回でもCondition文ないしはVector文でパターン(WFC)がPatternブロックのどこかで記述さ

れた場合には無効になる、すなわち、DefaultState文で定義されていないものと見なされる。

Proceduresブロックは独立したブロックであり先頭のパターンにおいては常にDefaultStateが有効となってい

る。Proceduresブロックの先頭には、MacroDefsブロックやPatternブロックと同様に、DefaultState文が有効な

ピンを除き、Patternブロックで使用される全てのピンに対するステートをCondition文ないしはVector文で記述

することを推奨とする。

ProceduresProceduresブロックにおける未定義ピンの状態に関する処理ブロックにおける未定義ピンの状態に関する処理

STARC SSTAG


Patternブロック

Signals {Pin1 In { DefaultState D; } Pin2 In;Pin3 Out;si1 In; SYSCLK In;

｝

…途中省略…Procedures {

unload_load {W TS2;Shift {

V {si1=#; SYSCLK=P; }}

} } …途中省略…Pattern "SCAN" {

W TS1;V { all = 110 111 00 XX 0000 XXXX;}Call unload_load {

si1=1001110101;}…以降省略…

記述例

Proceduresブロック中のVector文 Proceduresブロック内に記述のない

ピンがあるこれらのピンに対する値をどのように

解釈するかが問題

提案するSolutionでは、DefaultStateが定義されているピンは、

DefaultState値が利用され、それ以外のピンはDefaultState文のデ

フォルト値（入力はZ、出力はX）を利用する

。

V{ si1=1; SYSCLK=P; } //Pin1; Pin2; Pin3;

Patternブロック

Proceduresブロック中のVector文Proceduresブロック内で定義されてい

なかったピンは以下の値になる

V{ si1=1; SYSCLK=P; @0{ Pin1=D; Pin2=Z; Pin3=X;} }

Pin1はDefaultState文のDefaultState値Dになる。

Pin2はDefaultState文のデフォルト値Zになる。Pin3

はDefaultState文のデフォルト値Xになる。

STARC SSTAG



24.5 Procedure and Macro Data substitution

分類


問題点

パターンに代入を行う場合、“#”を使用してShiftブロック内でのスキャンパターンへの代入や

MacroDefsブロック内のVector文、またはProceduresブロック内のVector文への代入を行うこ

とができる。しかし後者のVector文への代入方法が仕様に明確に記載されておらず不明確である。

パターン代入文字パターン代入文字””##””に対する問題点に対する問題点

STARC SSTAG


提案するSolutionMacroDefsブロック内のVector文、またはProceduresブロック内のVector文にある#には、Macro文または

Call文で記述されているパラメータデータ(パターン)はAlignment文の定義に従って記述された順番に#へ代入す

るものと解釈する。(cf. %を使用した代入の場合には、MacroDefsブロック内のVector文、またはProceduresブロック内のVector

文にある%に、Macro文またはCall文で記述されているパラメータデータ(パターン)はAlignment文の定義に従っ

て1つだけ%に代入される。）

%では、1つの値が全ての%に代入される

#では、1つずつ順番にパラメータの値が代入される

Macro文またはCall文で記述されているパラメータデータ(パターン)がピンに対してまたはピングループ一括に対して定義されている場合には、そのピンまたはピングループに対する#と%の混在したVector文による代入記述は許さないものとする。

Macro文またはCall文で記述されているパラメータデータ(パターン)がピングループに対してピン毎

に定義されている場合には、そのピングループの各ピンに対しVector文を通して#と%の混在しないVector文による代入記述は許されるものとする。

Call "Replace" { P1=011; P2=110; }

Procedures { "Replace" {

W TS1;

V { P1=%; P2=#; }

V { P1=%; P2=#; }

V { P1=%; P2=#; }

} }

Procedures { "Replace" {

W TS1;

V { P1=0; P2=1; }

V { P1=0; P2=1; }

V { P1=0; P2=0; }

} }

代入結果Proceduresブロック

STARC SSTAG


提案する提案するSolutionSolution（補足）：（補足）：

ピングループに対する代入は以下の通りとする。

Call "Replace" { P1=011; P2=110; ‘P3+P4'=LLHH;}

Procedures {

"Replace" {

W TS1;

C { 'P3+P4'=XX; }

V { P1=%; P2=#; 'P3+P4'=#; }

V { P1=%; P2=#; 'P3+P4'=#; }

V { P1=%; P2=#; 'P3+P4'=#; }

}

}

Procedures {

"Replace" {

W TS1;

C { 'P3+P4'=XX; }

V { P1=0; P2=1; 'P3+P4'=LL; }

V { P1=0; P2=1; 'P3+P4'=HH; }

V { P1=0; P2=0; 'P3+P4'=XX; }

}

}

代入結果Proceduresブロック

STARC SSTAG


Procedures {

"Replace" {

W TS1;

V { P1=#; P2=#; }

V { P1=#; P2=#; }

V { P1=#; P2=#; }

}

}

各ピンの#（もしくは%）

の代入はOK

各ピン毎に#%を代入する例

Procedures {

"Replace" {

W TS1;

V { P1=%; P2=#; }

V { P1=#; P2=%; }

V { P1=%; P2=#; }

}

}

同一ピンに対して#、%を

混在した代入はNG

Procedures {

"Replace" {

W TS1;

V { P1=%; P2=#; }

V { P1=%; P2=#; }

V { P1=%; P2=#; }

}

}

各ピン毎の#、%を使い分

けた代入はOK

Call “Replace” { P1=011; P2=110;}

一つのピンに

対する＃、％

の混在はNG

STARC SSTAG


Call “Replace” { "Pin"=011110;}

ピングループ表記の#（も

しくは%）の代入はOK

SignalGroupsで定義されたピングループに#%を代入する例

Procedures {"Replace" {

W TS1;V { Pin=%#; }V { Pin=%#; } V { Pin=%#; }

}}

ピングループ表記で各ピ

ン毎の#、%を使い分けた

代入はNG

SignalGroups {"Pin" = 'P1 + P2';}


W TS1;V { Pin=##; }V { Pin=##; } V { Pin=##; }

}}

各ピンの#（もしくは%）

の代入はOK


W TS1;V { P1=#; P2=#; }V { P1=%; P2=%; } V { P1=#; P2=#; }

}}

同一ピンに対して#、%を

混在した代入はNG


W TS1;V { P1=%; P2=#; }V { P1=%; P2=#; } V { P1=%; P2=#; }

}}

各ピン毎の#、%を使い分

けた代入はNG


W TS1;V { P1=#; P2=#; }V { P1=#; P2=#; } V { P1=#; P2=#; }

}}


W TS1;V { Pin=##; }V { Pin=%%; } V { Pin=##; }

}}

ピングループで＃、％の混在はNGピングループ表記での＃、％の混在はNG

ピングループ表記での同

一ピンに対して#、%を混

在した代入はNG

一つのピンに

対する＃、％

の混在はNG

Call文がピングループで定

義されているため＃と％の

混在となるためNG

STARC SSTAG


Procedures {unload_load {

W scan;C { all=100 001 00 XX 0000 XXXX; }Shift {

V {si1=#; si2=#; so1=#; so2=#;}}

} // unload_load} // Procedures

…途中省略…

Pattern scan_loads {W wft_base;V { all = 110 111 00 XX 0000 XXXX;}Call unload_load {

si1=1101110101; si2=0000111011;}V { pis = 1010;} // FORCE PIsV { pos = HLHL;} // MEASURE POs

// FIRE CAPTURE CLK (SUBSET OF all_scan_clks)V { capture_clks = 00; pos = XXXX;}Call unload_load {

so1=HLHHHLHLHL; so2=HHHLLHHLHL;}

}

Shift文での代入で#を用いた記述例

参考：参考：

通常Vectorへの代入で#を用いた記述例

Procedures {

"Replace" {

W TS1;

C { 'P3+P4'=XX; }

V { P1=%; P2=#; 'P3+P4'=#; }

V { P1=%; P2=#; 'P3+P4'=#; }

V { P1=%; P2=#; 'P3+P4'=#; }

}

}

…途中省略…

Pattern scan_loads {W wft_base;V { all = 110 111 00 XX 0000 XXXX;}Call "Replace" { P1=011; P2=110; 'P3+P4'=LLHH；}

}

STARC SSTAG



18.2 Waveform event definitions

分類

Application：

STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケーションツールや装

置で共通認識されるべき内容

問題点

ドライバ切り替え時刻を入力波形のエッジより大きい時刻に設定する場合、現状のSTILの仕様の範囲内でその波

形を表現しようすると、出力モード→入力モードに切り替わった場合の入力波形と、入力モード→入力モードの場

合の入力波形とでWFCを変えるか、WaveformTableを切り替えないと表現できない。

ドライバイネーブルタイミングをサポートしているテスターでは、上記制約によりテストパターンを書き換えない

とテストできないケースが生じる。

ドライバ切り替え時刻＞入力波形のエッジドライバ切り替え時刻＞入力波形のエッジのタイミング使用時の問題点のタイミング使用時の問題点

STARC SSTAG


［出力モード→入力モードの場合と、入力モード→入力モードの場合とでWFCを変えた場合］

【記述例】現状のSTIL仕様内でのドライバ切り替え時刻＞入力波形のエッジのタイミング記述

テスト周期：100ns入力波形：delay=0のNRZ波形I/O切り替え時刻：50ns

の場合

［出力モード→入力モードの場合と、入力モード→入力モードの場合とでWaveformTableを変えた場合］

01 { '0ns' D/U; }LHTX {'50ns' Z; '80ns' L/H/T/X; }AB {'５0ns' D/U; }

WaveformTable

"TS1" {01 { '0ns' D/U; }LHTX {'50ns' Z; '80ns' L/H/T/X; }

}WaveformTable

"TS2" {01 { '５0ns' D/U; }LHTX {'50ns' Z; '80ns' L/H/T/X; }

}

XXXXXXXX

0

100

150 200 250 300

400

１

H B ０

XXXXXXXX

0

100

150 200 250 300

400

１

H 1 ０

TS1 TS2 TS1

入力パターンの記述時に、モード切替を考慮してWFC 0/1とA/Bを変えなければならず、パターンの記述と

その理解が困難。

I/Oの切り替え毎にWaveformTableを切り替える必要がある。このため、テスターのタイミングリソースの制

限によっては使用できない場合がある。

STARC SSTAG


XXXXXXXX

0

100

150 200 250 300

400

１

H 1 ０

１０

■問題点の補足説明（ご参考）

上図のようなドライバイネーブルタイミングをサポートしたテスターの波形は、Pを使ってもうまく記述できない。01 {‘0ns’P; '50ns' D/U; }LHTX {'50ns' Z; '80ns' L/H/T/X; }

ドライバをオンするイベントPの定義はSTILの言語仕様では以下のようになっている。「Force logic to last driven state. Turn the drive on and go to the last drive state (i.e.,Ifthe last drive state was "D", then go to low;if

the last drive state was "U" then go to high).」

Pは、「ドライブONにして、その値は直前のドライブ値を引きずるステートメント」である。上図では、I/O切り替えタイミングが50nsのため、３サイクル目では250nsまでが出力モード、250nsからは入力モードとなるが、「01 {‘0ns’P; ‘50ns’ D/U; }」と定義した場合には、３サイクル目の先頭(時刻200ns)でドライバがON

してしまうことになる。上図はドライバイネーブルタイミングをサポートしたテスターの「入力波形：delay=0のNRZ波形、I/O切り替え時刻：50ns」の波形の例であるが、入力波形を「01 {‘0ns’P; ‘50ns’ D/U; }」と定義した場合には、入力１から入力０に変化したとき、波形は以下のように50nsで変化し、delay=50nsのNRZ波形となってしまう。

即ちドライバイネーブルタイミングをサポートしたテスターの「ドライバ切り替え時刻＞入力波形のエッジ」の場合の波形は、入力モー

ドから入力モードの波形と、出力モードから入力モードへ切り替わる場合の波形を分けて定義しないと表現できない。

STARC SSTAG


提案するSolution出力モード→入力モードの場合と、入力モード→入力モードの場合とで入力タイミングが異なる場合、STILの仕様通りに定義し記述する（前述の記述

例参照)ことを推奨する。但し、ドライバイネーブルタイミングをサポートしているテスターでは、パターンデータの記述が複雑になるため、アプリケー

ションサイドで出力から入力に切り替わるときの入力タイミングをドライバイネーブルタイミングとして例外的に処理しても良いものとする。

以下のように記述した場合も、WFC 0,1使用時にドライバ切り替えタイミングがL,H,T,Xと同様に50nsで切り替わっている、つまり前述の記述例と同等で

あると見なして処理しても良いものとする。即ち、

01{'0ns' D/U; }LHTX { '50ns' Z; '80ns' L/H/T/X; }

で定義されたテストパターンに対して、出力から入力に変化するサイクルのパターンデータ「０，１」を

01{ '0ns' D/U; }LHTX { '50ns' Z; '80ns' L/H/T/X; }AB{ '50ns' D/U; }

で定義されたパターンデータ「Ａ，Ｂ」と見なして処理しても良いものとする。

上記のように見なしてアプリケーションが動くとき、この動作を明示的に表すために、次ページにおいて新規に定義するドライブイベントの

UserKeywords

e を使って表記しても良いものとする。

上記例外処理をサポートするアプリケーションがSTILデータを出力する際には、STIL仕様に従った形式とドライブイベントのUserKeywords

e を使用し

た形式のいずれにおいても出力可能なものとする。

STARC SSTAG


新規ドライブイベント

e をUserKeywordsとして定義する。

UserKeywords文による宣言：

UserKeywords

e ;

e はWaveformTableブロック中におけるタイミング定義のイベント記号として使用することができる。

e の定義を以下に示す。

＜e の定義＞

・Driver-Offの状態からDriver-Onになる状態変化があるサイクルでのみ有効となり、以下を満たすイベントである。

・Driver-Offの状態から初めてDriver-Onになる時刻を設定するイベントで、論理レベルはドライブイベント

ForcePrior(P)と同じ後のドライブ状態とする。

・直前のDriver-Off状態から

e で設定されたDriver-On時刻までに現れたドライブイベントは無効とし、それ以降の

ドライブイベントは有効とする。

［eを使用したタイミング記述例］

01 { '0ns' D/U; '50ns' e; }LHTX {'50ns' Z; '80ns' L/H/T/X; }

XXXXXXXX

0

100

150 200 250 300

400

１

H

１０

出力モード→入力モードの場合と、入力モード→入力モードの場合とでWFCを変えたり、WaveformTableを

切り替えなくても表現可能となる。

UserKeywords e ;・・・

STARC SSTAG


IEEE Specification (追加提案)

TestType

statement

分類

Description：STILデータを記述あるいは解釈する上で共通認識しておくべき内容であることを示す

問題点

テスト種別を記述するためのステートメントが仕様に用意されていない。


テスト種別は1450.6のPatternInformationブロックのPatternあるいはPatternBurst

ブロックステートメントを用いて、その中で定義できるPurposeステートメントの

User USER_DEFINEDを使って記述することを推奨する。

テスト種別記述に関する問題点テスト種別記述に関する問題点

＜書式＞STIL1.0 {Design 2005;CTLMode 2005;

}Environment (ENV_NAME) {(CTLMode （CTLMODE_NAME）

{(PatternInformation {(<Pattern ｜ PatternBurst> (pat_or_burst_name) {(Purpose ( User TestType < FC | DC | FCDC | AC >) //テスト種別

(1)})*//End Pattern or PatternBurst

})//End PatternInformation})*//End CTLMode

}//End Environment

<書式中のキーワードの説明>

(1)TestType：テストパターンの種別を示すキーワード

FC：ファンクションテスト用パターンであることを示すキーワード

DC：DCテスト用パターンであることを示すキーワード

FCDC：ファンクションテスト用パターンとDCテスト用パターンの

混在であることを示すキーワード

AC：ACテスト用パターンであることを示すキーワード

STARC SSTAG


なお詳細はSTIL活用ガイド1450.6の「Transitionパターンにおいて区別すべき

release/captureクロック定義に関する問題点(1) 」の提案するSolutionを参照のこと。

＜記述例1＞STIL 1.0 {Design 2005；CTL 2005;

}PatternBurst

BURST1 {PatList

{TR1;

}}PatternExec

EXEC1 {PatternBurst

BURST1;｝Pattern TR1{

}Environment ENV1 {CTLMode

MODE1 {PatternInformation

{Pattern TR1 {

Purpose User TestType

FC; }//End Pattern

}//End PatternInformation}//End CTLMode

}//End Environment


}PatternBurst

TR1 {PatList

{PAT1;PAT2;

}}PatternExec

EXEC1 {PatternBurst

TR1;｝Pattern PAT1{

}Pattern PAT2{

}Environment ENV1 {

CTLMode


{PatternBurst

TR1 {Purpose User TestType

FC; }//End PatternBurst


}//End Environment

Pattern TR1はファンクションテスト用パ

ターンであることを示している。

PatternBurst

TR1はファンクションテス

トの実行を示している。

STARC SSTAG



InfiniteLoop

statement

分類


問題点

テスターにおいて、テストパターン実行時に無限ループをさせる場合があるがステートメントが

用意

されていない。


テストパターン実行時に無限ループをさせる場合は、

UserKeywordsでInfiniteLoopを定義して

patternブロック中でInfiniteLoopステートメントを記述することを推奨する。

無限ループ記述に関する問題点無限ループ記述に関する問題点

STARC SSTAG


＜書式＞UserKeywords

InfiniteLoop;Pattern "パターン名" {W "WaveformTableドメイン名";V { "ピングループ名"=ニーモニック; }

：：V { "ピングループ名"=ニーモニック; }

：：LABEL: InfiniteLoop

{ // STIL

WGに書式追加を提案

(複数記述可)// 無限ループ範囲を記述。DC測定の場合は測定ア// ドレス(パターン動作範囲)を表す。LABEL名は、// PatternExecのMeasureステートメントの"DC測定//名"で参照される。

V { "ピングループ名"=ニーモニック; }}

}

STARC SSTAG



TestType

usage in PatternExec

分類


問題点

テスト実行時に、テスト種別を定義するステートメントをPatternExecブロックに記述する必要があるが

記述できるようになっていない。


PattenExecブロックに、"TestType

テスト種別;"を記述することを推奨する。


TestType

;PatternExec

ドメイン名{TestType

"FC"; //テスト種別PatternBurst

"FC1";}

PattenExecPattenExecブロック内のテスト種別記述に関する問題点ブロック内のテスト種別記述に関する問題点

STARC SSTAG


IEEE Specification1450.０ (Page101)21.2 Multiple-bit cyclized

dataVector statements may contain references to groups that were defined to support multiple-bit data definitions.Multiple-bit data is defined in waveforms through the use of square brackets (See Clause 18 for additionaldetails.)

Multiple bit data may be presented in cyclized

data in two formats. Each format has a set of requirements inorder to process this multiple-bit data.

The first format is identical to the Cyclized

Data statement presented in 21.1, with the extension that theVEC_DATA length is longer than the length necessary to assign a bit to each signal referenced in sigref_expr.The number of WaveformChars

is defined by the DataBitCount

statement associated with the definition ofthe Signal or Group being referenced (and the default is 1).

The second statement format is:sigref_expr

{ ( vec_data; )+ }

In this format, there are one or more vec_data; statements. Each statement contains the number of WaveformCharreferences necessary to apply to all signals defined in the sigref_expr. There are as many statementsdefined as index values present in the waveform definition applied.

In addition to these constructs, multiple-bit data has the following additional requirements:—

The sigref_expr

shall be a group only. The definition of this group shall include a DataBitCountattribute. The definition of this group shall also include a Base attribute identifying the multiple-bitWaveformChars

that may be applied to the signals in this group.—

The waveform referenced by the WaveformChars

shall define all WaveformChars

listed in the Baseattribute in a single waveform definition. All waveforms applied

across all signals defined in amultiple-bit group shall have the same number of indexed timed events.

DataBitCountDataBitCountのパターン省略記述に関する問題点のパターン省略記述に関する問題点

STARC SSTAG


分類

Description：DataBitCount記述における問題点

問題点DataBitCountが記述されたVecor文の後に空のVector文が記述された場合に、終状態を引

きずるのか、直前のVector文と全く同じ記述がされているものとするのかが曖昧である。

Signals {A In; B Out; "Pin" In { DataBitCount

2; }

}Timing {WaveformTable

"TS1" {Period '100ns' ;Waveforms {"A" { 01 { '0ns' D/U; } }"B" { LHTX { '0ns' X; '10ns' L/H/T/X; } }"Pin" { 01 { '0ns' D/U [0]; '10ns' D/U [1]; }}}

}}Pattern "PAT1"{W "TS1";C { "A"=0; "B"=X; }V { "Pin"{0;1;} }V {}

}このVector文の記述が以下のどちらになるのかが曖昧である。

終状態を引きずる

V{“Pin”

{1;1;}}直前のVector文と全く同じ記述となる

V{ "Pin"{0;1;} }

STARC SSTAG



DataBitCountが記述されたVecor文の後に空のVector文が記述された場合に、直前の

Vector文と全く同じ記述がされているものと解釈する。

Signals {A In; B Out; "Pin" In { DataBitCount

2; }

}Timing {WaveformTable

"TS1" {Period '100ns' ;Waveforms {"A" { 01 { '0ns' D/U; } }"B" { LHTX { '0ns' X; '10ns' L/H/T/X; } }"Pin" { 01 { '0ns' D/U [0]; '10ns' D/U [1]; }}}

}}Pattern "PAT1"{W "TS1";C { "A"=0; "B"=X; }V { "Pin"{0;1;} }V {} V { "Pin"{0;1;} }

}Vector文でWFCが省略された場合の表記に準じてDataBitCountに関しても直前の

Vector文と同じ記述がされているものと解釈する。これにより、DataBitCountに関

しても同じ記述を繰り返して記述する必要がなくなる。

STARC SSTAG


IDDqIDDqテストの測定順に関する問題点テストの測定順に関する問題点

IEEE Specification1450.０ (Page107)

22.10 IddqTestPoint statement

The IddqTestPoint statement defines a place in the Pattern where an IDDq measurement may be performed.IddqTestPoint statements are optional. The syntax of the IddqTestPoint statement is:

( LABEL : ) IddqTestPoint;

The following is an example Iddq TestPoint statement:

V { new-delta-change-data }IddqTestPoint; // perform Iddq measurement between 2 vectorsV { new-delta-change-data }

分類

Description：STIL記述における問題点

STARC SSTAG


問題点

IDDqテストはIddqTestPointステートメントで指定された複数のポイントで測定を行なうが、その際の

測定順は故障検出能力の高いポイントから順に測定するのが効率的である。しかしながら、現状のIddqTestPointス

テートメントの仕様では、故障検出率など測定順に関わる情報を記述することができない。

このため、効率の良いテストプログラムを作成するためにはIDDqの測定順を故障検出能力の高い順に決める必要があ

るため、故障シミュレーションの結果ファイルなどを参照しなければならなくなる。

提案するSolutionIDDqテストポイントの測定順に関わる情報を記述する際にはIddqTestPointステートメントを拡張しUserKeywords

Detectionを使って記述することを推奨する。

UserKeywords

Detection;

既存のステートメント(IddqTestPoint)にDetection情報の記述を追加することになるため、これをUserKeywordsで

定義する。

現状

( LABEL : ) IddqTestPoint;

追加

( LABEL : ) IddqTestPoint

｛

Detection detection_expr

（ｄetection_expr）；

｝detection_expr : 数値

... IDDqテストの測定順を示す。

数値% ... 故障検出率を示す。

IddqTestPointに「Detection detection_expr

（detection_expr）;」を追記可能とすることにより、

テストプログラムを生成するアプリケーションがIDDq測定順を考慮してプログラム生成を可能とする。

STARC SSTAG


<STIL-1>Pattern PAT1

{V { PATT=001001001HLLHLLHLHLH;}V { PATT=100100111LLHLHLLHLHL;}V { PATT=111110010HHLHHHHLHHL;}IddqTestPoint;

...

①V { PATT=001001001HLLHLLHLHLH;}IddqTestPoint;

...

②V { PATT=100100111LLHLHLLHLHL;}V { PATT=111110010HHLHHHHLHHL;}IddqTestPoint;

...

③V { PATT=111110010HHLHHHHLHHL;}

}


{V { PATT=100100111LLHLHLLHLHL;}V { PATT=111110010HHLHHHHLHHL;}IddqTestPoint;

...

④V { PATT=001001001HLLHLLHLHLH;}IddqTestPoint;

...

⑤V { PATT=100100111LLHLHLLHLHL;}V { PATT=111110010HHLHHHHLHHL;}

}

<IDDqテスト測定順>

<STIL-1>①

<STIL-1>②

<STIL-1>③

<STIL-2>④

<STIL-2>⑤

※測定順が明記されていないため、記述

順に測定している。

適用例

【従来】


{V { PATT=001001001HLLHLLHLHLH;}V { PATT=100100111LLHLHLLHLHL;}V { PATT=111110010HHLHHHHLHHL;}IddqTestPoint

{ Detection 50.0% 1;}...①V { PATT=001001001HLLHLLHLHLH;}IddqTestPoint

{ Detection 70.0% 3;}...②V { PATT=100100111LLHLHLLHLHL;}V { PATT=111110010HHLHHHHLHHL;}IddqTestPoint

{ Detection 91.7% 2;}...③V { PATT=111110010HHLHHHHLHHL;}

}


{V { PATT=100100111LLHLHLLHLHL;}V { PATT=111110010HHLHHHHLHHL;}IddqTestPoint

{ Detection 92.5% 5;}...④V { PATT=001001001HLLHLLHLHLH;}IddqTestPoint

{ Detection 98.5% 4;}...⑤V { PATT=100100111LLHLHLLHLHL;}V { PATT=111110010HHLHHHHLHHL;}

}

【Detectionで故障検出率(累積)と測定順を指定した場合】

<IDDqテスト測定順>

<STIL-1>①

<STIL-1>③

<STIL-1>②

<STIL-2>⑤

<STIL-2>④

※故障検出能力の高い順に

測定可能となる。

STARC SSTAG


IEEE Specification（Page109 23.2 Pattern initialization)

分類


問題点

（１）Patternブロックの先頭Vector文に記述されていないピンが、

Patternブロックの途中で独立した

Patternブロックとして使用されるProceduresブロックやIncludeファイルに記述されている場合、記述

されていないピンに対してDefaultStateの値を適用すべきか、仕様違反として取り扱うべきかが不明であ

る。

（２）Patternブロックの先頭に独立したPatternブロックとして使用されるProceduresブロックや

Includeファイルが記述されている場合、ProceduresブロックやIncludeファイルの先頭で記述されてい

ないピンに対してDefaultStateの値を適用すべきか、仕様違反として取り扱うべきかが不明である。

PatternPatternブロックの先頭ブロックの先頭VectorVector文におけるピン定義の問題点文におけるピン定義の問題点

STARC SSTAG


問題点(1)例

Signals{

"A1" In; "B1" Out; "C1" InOut;}

Procedures {

"xxx" {

W “T1”;

V{"A1"=1;"B1"=X;"C1"=0;}

}

}

Pattern "P1" {

W "T1";

V {"A1"=1;"B1"=H;}

Call "xxx";

}

問題点(2)例

Patternブロックの先頭に独立した

Patternブロックとして使用される

Proceduresブロックがあり、その先頭

Vectorに記述されていないピンがPattern

中で使用されるケース

Signals{


Procedures {

"xxx" {

W "T1";

V{"A1"=1;"B1"=0;}

}

}

Pattern "P1" {

W "T1";

Call "xxx";

V {"A1"=1;"B1"=0;"C1"=X;

}

}

信号C1のパターンを、DefaultState

の値とするのか、エラーとして扱うの

か不明

問題点(2)例

Patternブロックの先頭に独立した

Patternブロックとして使用される

Proceduresブロックがあり、その先頭

Vectorに記述されていないピンがPattern中

で使用されないケース

Signals{


Procedures {

"xxx" {

W "T1";

V{"A1"=1;"B1"=0; }

}

}

Pattern "P1" {

W "T1";

Call "xxx";

V {"A1"=1;"B1"=0; }

}


の値とするのか、エラーとして扱うの

か不明


の値とするのか不明

STARC SSTAG



(1)Patternブロックの先頭Vector文に記述されていないピンが、

Patternブロックの途中で独立した

Patternブロックとして使用されるProcedureブロックやIncludeファイルに記述されている場合、

Patternブロックの先頭Vectorで使用されていない

ピンが途中のVector文で使用されているものと同じ

扱いとして仕様違反とする。Patternブロックの先頭Vector文ではそのPatternブロックで使用される全てのピンのステート

を記述することを推奨する。

(2) Patternブロックの先頭に独立したPatternブロックとして使用されるProceduresブロックや

Includeファイルがあり、それらの先頭Vector文に記述されていないピンがある場合、全パターンブロッ

クを通して途中で記述されていないのであれば、

Patternブロックの先頭ピンはデフォルトステートを適

用する。

独立したPatternブロックとして使用されるProceduresブロックやIncludeファイルの先頭

Vector文に記述されていないピンが、全パターンブロックを通して途中で記述されている場合は仕様違反

とする。

STARC SSTAG


IEEE Specification（Page109 23.2 Pattern initialization)

Alignment: An optional statement indicating how to map the bits of a non-WaveformChar

numeric value

into the individual signals of a multiple-signal definition or group. This attribute is significant only for multiple-

signal definitions or groups, and is applied only in the context

of Vector assignments (see 21.1 and 21.2).

It is not applied to scan environments (21.4), as scan relies on

padding operations to resolve data length issues.

分類 Description：STILデータを記述あるいは解釈する上で共通認識しておくべき内容

問題点

SignalsブロックおよびSignalGroupsブロックの信号／信号グループ定義においてAlignmentステートメントを記述した場合に、

対

象となるVectorステートメントに記述できるパターンの書き方がWFC、数値の両方なのかどうかが不明である。

AlignmentAlignmentステートメントを定義した場合に使用できるパターン記述の問題点ステートメントを定義した場合に使用できるパターン記述の問題点

(例)Hexでパターンを記述した場合

SignalGroups

{

"group"=‘"A1"+"B1"+"C1"'{

Base Hex 01; Alignment LSB;

}

}

Pattern "P1"

{

W "T1";

：

V { "group"=¥h A; }

}

(例)WFCでパターンを記述した場合

SignalGroups

{

"group"=‘"A1"+"B1"+"C1"' {

Alignment LSB;

}

}

Pattern "P1"

{

W "T1";

：

V { "group"=1010; }

}

STARC SSTAG



SignalsブロックおよびSignalGroupsブロックの信号／信号グループ定義においてAlignmentステートメント

を記述した場合に、対象となるVectorステートメントにHexあるいはDecの数値が使用された場合には

Alignmentステートメントで指定されたMSBないしはLSBから信号数分のbitデータが順に割り付けられ、そ

のbitデータに対応付けられたWFC列になる。WFCの並びに対してはAlignmentステートメントは無効となる。

パターンにWFC を記述する場合にはWFCの個数と信号の個数は同じでなければならない。

(例)Hexでパターンを記述した場合

SignalGroups

{

group=‘"A1"+"B1"+"C1"'{

Base Hex 01; Alignment LSB;

}

}

Pattern "P1"

{

W "T1";

：

V { group=¥h A; }

}

(例)WFCでパターンを記述した場合

SignalGroups

{

group=‘"A1"+"B1"+"C1"' {

Alignment LSB;

}

}

Pattern "P1"

{

W "T1";

：

V { group=1010; }

}

このケースは

仕様違反である

STARC SSTAG



ADCUnits block

分類


問題点

ADC変換テストにおけるDACユニットの設定が記述できるようになっていない。


STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したADCUnitsブロックを使用してテス

ターのDACユニット設定を記述することを推奨する。

ADCADC変換テストにおける変換テストにおけるDACDACユニットの設定に関する問題点ユニットの設定に関する問題点

STARC SSTAG


＜書式＞STIL

1.0{DCLevels

2002; AMD P7;}UserKeywords

ADCUnits;ADCUnits “ドメイン名”{

//テスターのDACユニットの設定を記述するブロック。InheritADCUnits

“ADCUnitsドメイン名”;

// 他のADCUnitsブロック条件を継承する。AinSignals ’“信号ピン名”+ ”信号ピン名”’・;// DACユニットの出力が繋がるADC入力信号。ForceRange ‘印加設定範囲’,‘分解能’,‘設定確度’;

//印加設定範囲(設定値は±の範囲)、分解能、設定確度(設定値は±範囲)を記述。//テスターのDACユニットレンジを選択する時の条件として使用する。//ForceRangeステートメントは省略可能。また、FroceRangeステートメントを記述した//場合、引数は全て記述する必要はない(引数は部分的に省略可能）。

ZeroCode_Voltage ‘電圧値’ ; // ゼロコードが出力される理想的な入力信号の電圧値を設定FullCode_Voltage ‘電圧値’ ; // フルコードが出力される理想的な入力信号の電圧値を設定ADC_Bit_Number ビット数

; // ADCのデータビット数を設定Ain_Resolution ‘分解能’; // 入力信号の分解能を設定。演算式も記述可。ADC_Resolution ‘分解能’; // ADCの分解能を設定。演算式も記述可。Limit ‘Low側リミット,High側リミット’;//判定Limit。OverDrive_Voltage ‘Low側電圧,High側電圧’;

//アナログ入力の許容電圧を設定//Low側電圧：リファレンス電源(負電源)との差分を設定。//High側電圧：リファレンス電源(正電源)との差分を設定。

STARC SSTAG


DC_Offset_Voltage < ‘Low側電圧,High側電圧’; | ‘電圧値’>;//アナログ入力オフセット電圧値を設定。//Low側電圧：負側(マイナス)のオフセット値を設定。//High側電圧：正側(プラス)のオフセット値を設定。//電圧値のみ：正側、負側一律のオフセット値を設定。

Gain_Ratio ‘ゲイン係数’ ;//DACユニット振幅に対するゲイン係数(振幅に対する割合)を記述//する。DACユニット振幅にゲイン係数を乗算した振幅が、実際に//ADCへ入力される振幅となる。ゲイン係数は小数(＜1)で記述。// ※DACユニット振幅 × ゲイン係数 = ADCへの入力振幅// ゲインを変えない(減衰させない)場合は設定しない。

Slope < Positive | Negative > ;

// 入力波形の傾きを設定DoutCapUnits DoutCapUnitsドメイン名

;

//参照するDoutCapUnitのドメイン名//PatternExecにおいて、複数ユニットを用いた同時測定//を行う場合のみ記述する。

｝

STARC SSTAG



VrefLevels

block

分類


問題点

ADC変換テストにおけるリファレンス電源の条件が記述できるようになっていない。


STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したVrefLevelsブロックを使用して

リファレンス電源の条件を設定することを推奨する。

ADCADC変換テストにおけるリファレンス電源の条件記述に関する問題点変換テストにおけるリファレンス電源の条件記述に関する問題点

STARC SSTAG


＜書式＞STIL

1.0{DCLevels


VrefLevels;VrefLevels

ドメイン名

{リファレンス電源名

{Force_VRH ‘電圧値’;

// 正電源側の印加電圧値を設定Force_VRL ‘電圧値’;

// 負電源側の印加電圧値を設定Force_VRM ‘電圧値’;

// 中間電圧値を設定ForceRange ‘印加設定範囲’,‘分解能’,‘設定確度’;

//印加設定範囲(設定値は±の範囲)、分解能、設定確度(設定値は±範囲)を記述。//テスターの電源ユニットレンジを選択する時の条件として使用する。//ForceRangeステートメントは省略可能。また、FroceRangeステートメントを記述した//場合、引数は全て記述する必要はない(引数は部分的に省略可能）。

IClamp

‘負側クランプ値,正側クランプ値’;

//電流クランプ値範囲を記述}

｝

STARC SSTAG



DoutCapUnits

block

分類


問題点

ADC変換テストにおけるテスターのデータ取り込みユニットを記述できるようになっていない。


STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したDoutCapUnitsブロックを使用して

テスターのデータ取り込みユニットを設定することを推奨する。

ADCADC変換テスト変換テストにおけるにおけるテスターのデータ取り込みユニット記述に関する問題点テスターのデータ取り込みユニット記述に関する問題点

STARC SSTAG


＜書式＞STIL

1.0{DCLevels


DoutCapUnits;DoutCapUnits ドメイン名{

//テスターのデータ取り込みユニットの設定を記述するブロック。DoutSignals < MSB

| LSB> ’“信号ピン名or信号グループ名”+ ”信号ピン名or信号グループ名”・・’;// データ取り込み対象信号を記述。デフォルト(Msb)は、左側の信号//ピンがMSB、右側の信号ピンがLSB。”Lsb”指定時は、左側の信//ピンがLSB、右側の信号ピンがMSB。// 信号ピン名 or 信号グループ名は複数記述可//信号グループ名の場合、SignalGroupsで定義されている信号ピン順//がデータ並び順に考慮される。

DoutSignalsMapping <BusNo | Alpha | BusNoAlpha | AlphaBusNo>

;//DoutSignalsの信号ピン名をSignalGroups名で記述した場合のみに定義できる。//定義はなくてもよい。データ取り込み対象信号の順番を指定//BusNo バス番号順。数字の大きい方がMSB。//Alpha アルファベット順。ABC側がMSB。//BusNoAlpha バス番号とアルファベットが混在している場合、バス番号順を優先させる。//AlphaBusNo バス番号とアルファベットが混在している場合、アルファベット順を優先させる

CapMode < Pararel | Serial < MSB | LSB> > ;// データ取り込みを並列モード or 直列モードのどちらが選択。

Sampling_Count 回数; // アナログ入力電圧１分解能あたりのデジタル変換後のデータ取り込み// 回数を設定。回数が複数の場合は平均値をデータ値とする。

}//End DoutCapUnits

STARC SSTAG



DCSets

block、

PatternExec

block

分類


問題点

ADCUnits/VrefLevels/DoutCapUnitsブロック名をPatternExecで参照できるようになっていない。


（1）

UserKeywordsで定義したADCUnits/VrefLevels/DoutCapUnitsブロック名をDCSetsブロッ

クで定義し、PatternExecで参照できるようにすることを推奨する。

（２）

UserKeywordsで定義したADCUnits/VrefLevels/DoutCapUnitsブロック名を直接

PatternExecブロックで参照できるようにすることを推奨する。

ADCADC変換テスト変換テストにおけるにおけるブロック名の参照に関する問題点ブロック名の参照に関する問題点

STARC SSTAG


＜書式１＞

ADCUnits/VrefLevels/DoutCapUnitsブロック名をDCSetsブロックで定義し、PatternExecで参

照するケースUserKeywords

ADCUnits

VrefLevels

DoutCapUnits;DCSets

“ドメイン名”{ADCUnits


// 参照するADCUnitsブロックのドメイン名を記述VrefLevels “VrefLevelsドメイン名”; // 参照するVrefLevelsブロックのドメイン名を記述DoutCapUnits “DoutCapUnitsドメイン名”; // 参照するDoutCapUnitsブロックのドメイン名を

//記述}//End DCSetsPatternExec

“ドメイン名”{DCSets

“DCSetsドメイン名”;: :

}

STARC SSTAG


＜書式２＞

ADCUnits/VrefLevels/DoutCapUnitsブロック名を直接PatternExecブロックで参照するケースUserKeywords

ADCUnits

VrefLevels

DoutCapUnits;PatternExec

“ドメイン名”{ADCUnits


// 参照するADCUnitsブロックのドメイン名を記述// 複数のDACユニットを使用して測定する場合の記述//（必要であればADCUnits毎の印加レンジ切り替えもできる）// <同時印加>ADCUnits

{ ParallelForce

"ADCUnitsドメイン名1" "ADCUnitsドメイン名2" "ADCUnitsドメイン名3"･･;}// <順次印加>

ADCUnits

{ SerialForce

"ADCUnitsドメイン名1" "ADCUnitsドメイン名2" "ADCUnitsドメイン名3”･･;

}

: :VrefLevels “ドメイン名”; // 参照するVrefLevelsブロックのドメイン名を記述DoutCapUnits “ドメイン名”; // 参照するDoutCapUnitsブロックのドメイン名を記述// 複数のDoutCapユニットを使用して測定する場合の記述// <同時データ取り込み>DoutCapUnits

{ ParallelCapture

"DoutCapUnitsドメイン名1" "DoutCapUnitsドメイン名2" "DoutCapUnitsドメイン名3”･･;

}

// <順次データ取り込み>DoutCapUnits { SerialCapture "DoutCapUnitsドメイン名1"

"DoutCapUnitsドメイン名2" “ DoutCapUnitsドメイン名3”･･;

}

: :}

STARC SSTAG



Pattern

statement

分類


問題点

ADC変換テストにおけるADC変換動作パターンを記述できるようになっていない。


UserKeywordsでStartAnalogVoltage/ StopAnalogVoltage、ADCMeasLoopを定義し、

StartAnalogVoltage/ StopAnalogVoltageステートメントを使用してDACユニット出力のデバイスア

ナログ入力への印加開始、終了位置を記述し、ADC変換動作の繰り返しをADCMeasLoopステートメン

トを使用して記述することを推奨する。

ADCADC変換テストにおける変換テストにおけるADCADC変換動作パターンの記述に関する問題点変換動作パターンの記述に関する問題点

STARC SSTAG



StartAnalogVoltage

StopAnalogVoltage

ADCMeasLoop;Pattern “パターン名” {

：StartAnalogVoltage ; // DACユニット出力のデバイスアナログ入力への印加開始位置を示す。ADCMeasLoop { // ADC変換動作を繰り返す

V { “ピングループ名”=ニーモニック; }

// ADC変換動作パターンを記述}StopAnalogVoltage ; // DACユニット出力のデバイスアナログ入力への印加終了位置を示す。：

}

STARC SSTAG



DACUnits block

分類


問題点

DAC変換テストにおけるADCユニットの設定が記述できるようになっていない。


STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したDACUnitsブロックを使用して

ADCユニット条件を設定することを推奨する。

DACDAC変換テスト変換テストにおけるにおけるADCADCユニット記述に関する問題点ユニット記述に関する問題点

STARC SSTAG


＜書式＞STIL

1.0{DCLevels


DoutCapUnits;DACUnits "ドメイン名” {

//テスターのADCユニットの設定を記述するブロック。InheritDACUnits

DACUnitsドメイン名;

// 他のDACUnitsブロック条件を継承する。AoutSignals ’“信号ピン名(または信号グループ名)”+”信号ピン名(または信号グループ名)”+・・’;

// ADCユニットの入力が繋がるDACの出力信号。複数記述可。DcodeSignals < MSB

| LSB>

'"信号ピン名(または信号グループ名)”+"信号ピン名(または信号グループ名)”+・・’;

//ADCユニットでDAC出力を取り込む際に、DACデジタルコード別に取り込みの同期を取る//場合、デジタル入力信号名を指定する。対応するデジタルコード値は、Patternブロックの//Capパターンから参照する。デジタル入力信号がゼロコードからフルコード（またはフル//コードからゼロコード）へ順番に可変する場合はSlopeステートメントを記述できるため、//このステートメントは不要。//DACデジタルコードの並びがD7 ... D0の場合はmsb(デフォルト。記述無しでもよい)、//D0 ... D7の場合はlsbとなる。Slopeステートメントも定義されている場合、本ステートメント//が優先される。//信号グループ名の場合、SignalGroupsで定義されている信号ピン順//がデータ並び順に考慮される。

STARC SSTAG


DcodeAoutMapping

{“AoutSignals信号ピン名1” ‘“信号ピン名(または信号グループ名)”+

”信号ピン名(または信号グループ名)”+・・’;“AoutSignals信号ピン名2” ‘“信号ピン名(または信号グループ名)”+

”信号ピン名(または信号グループ名)”+・・’;:

}//DcodeSignalsとAoutSignalsに複数ピン指定した場合のデジタル入力信号とアナログ//出力信号の対応付けを行う。MeasRange ‘測定範囲’,‘分解能’,‘設定確度’;

//測定範囲(設定値は±の範囲)、分解能、設定確度(設定値は±範囲)を記述。//テスターのADCユニットレンジを選択する時の条件として使用する。//MeasRangeステートメントは省略可能。また、MeasRangeステートメントを記述した//場合、引数は全て記述する必要はない(引数は部分的に省略可能）。

ZeroCode_Voltage ‘電圧値’ // ゼロコードに対する理想的なDAC出力信号の電圧値を設定FullCode_Voltage ‘電圧値’ // フルコードに対する理想的なDAC出力信号の電圧値を設定DC_Offset_Voltage < ‘Low側電圧,High側電圧’ | ‘電圧値’>;

//アナログ出力オフセット値を設定。//Low側電圧：負側(マイナス)のオフセット値を設定。//High側電圧：正側(プラス)のオフセット値を設定//電圧値のみ：正側、負側一律のオフセット値を設定。

STARC SSTAG


Gain_Ratio ‘ゲイン係数’ ;

//ADCユニット入力フルスケール電圧(入力レンジ)に対するゲイン係数//(入力フルスケール電圧に対する割合)を記述する。// ※ADCユニット入力フルスケール電圧× ゲイン係数 = 実際に// ADCユニットへ入力可能なフルスケール電圧// ゲインを変えない場合は設定しない。

Slope < Positive | Negative > ;

// DAC出力波形の傾きを設定// DcodeSignalsステートメントが記述されている場合、本// ステートメントは記述不要であり、同時に記述されている// 場合、DcodeSignalsステートメントが優先される。

DAC_Bit_Number ビット数

;

// DACのデータビット数を設定DAC_Resolution ‘分解能’; // DACの分解能を設定。演算式も記述可。Sampling_Count 回数; // 1デジタルコードあたりのアナログ出力取り込み時のサンプリング

// 回数を設定。Limit ‘Low側リミット,High側リミット’;//判定Limit。FullScaleLevelResio < On | Off > ;

// 複数のDAC出力信号間におけるフルスケールレベル比// テスト対象のDACUnitブロックであることを示す。

}

STARC SSTAG



VrefLevels

block

分類


問題点

DAC変換テストにおけるリファレンス電源の条件が記述できるようになっていない。


STILextensionsでAMD P7を宣言した時にUserKeywordsで定義したVrefLevelsブロックを使用して

リファレンス電源の条件を設定することを推奨する。

DACDAC変換テスト変換テストにおけるにおけるリファレンス電源の条件記述に関する問題点リファレンス電源の条件記述に関する問題点

STARC SSTAG


＜書式＞STIL

1.0{DCLevels


VrefLevels;VrefLevels

ドメイン名

{リファレンス電源名

{Force_VRH ‘電圧値’;

// 正電源側の印加電圧値を設定Force_VRL ‘電圧値’;

// 負電源側の印加電圧値を設定Force_VRM ‘電圧値’;

// 中間電圧値を設定ForceRange ‘印加設定範囲’,‘分解能’,‘設定確度’;

//印加設定範囲(設定値は±の範囲)、分解能、設定確度(設定値は±範囲)を記述。//テスターの電源ユニットレンジを選択する時の条件として使用する。//ForceRangeステートメントは省略可能。また、FroceRangeステートメントを記述した//場合、引数は全て記述する必要はない(引数は部分的に省略可能）。

IClamp

‘負側クランプ値,正側クランプ値’;

//電流クランプ値範囲を記述}

｝

STARC SSTAG



DCSets

block、

PatternExec

block

分類


問題点

ADCUnits/VrefLevelsブロック名をPatternExecで参照できるようになっていない。


（1）UserKeywordsで定義したDACUnits/VrefLevelsブロック名をDCSetsブロックで定義し、

PatternExecで参照できるようにすることを推奨する。

（２）UserKeywordsで定義したDACUnits/VrefLevelsブロック名を直接PatternExecブロックで参

照できるようにすることを推奨する。

DACDAC変換テスト変換テストにおけるにおけるブロック名の参照に関する問題点ブロック名の参照に関する問題点

STARC SSTAG


＜書式１＞

DACUnits/VrefLevelsブロック名をDCSetsブロックで定義し、PatternExecで参照するケース。UserKeywords

DACUnits

VrefLevels;DCSets

“ドメイン名”{DACUnits

“DACUnitsドメイン名”;

// 参照するDACUnitsブロックのドメイン名を記述VrefLevels “VrefLevelsドメイン名”; // 参照するVrefLevelsブロックのドメイン名を記述

}//End DCSetsPatternExec

“ドメイン名”{DCSets

“DCSetsドメイン名”;: :

}

STARC SSTAG


＜書式２＞

DACUnits/VrefLevelsブロック名を直接PatternExecブロックで参照するケースUserKeywords

DACUnits

VrefLevels;PatternExec

“ドメイン名”{DACUnits


// 参照するDACUnitsブロックのドメイン名を記述// 複数のADCユニットを使用して測定する場合の記述//（必要であればDACUnits毎の測定レンジ切り替えもできる）// <同時測定>

DACUnits

{ ParallelMesure

“DACUnitsドメイン名1”“DACUnitsドメイン名2”“DACUnitsドメイン名3”･･;

} //※“DACUnitsドメイン名”は必ず複数。// <順次測定>

DACUnits

{ SerialMeasure

“DACUnitsドメイン名1”“DACUnitsドメイン名2”“DACUnitsドメイン名3”･･;

} //※“DACUnitsドメイン名”は必ず複数。: :

VrefLevels “VrefLevelsドメイン名”; // 参照するVrefLevelsブロックのドメイン名を記述: :

}

STARC SSTAG



Pattern statement

分類


問題点

DAC変換テストにおけるDAC変換動作パターンを記述できるようになっていない。


UserKeywordsでDACMeasPattern、Cap、DaCUnitsを定義し、Patternブロック中に

DACMeasPatternブロックを定義し、Capステートメント、DACUnitsステートメントを使用し、DAC

変換動作パターンを記述することを推奨する。

ＤＡＤＡCC変換テストにおける変換テストにおけるDACDAC変換動作パターンの記述に関する問題点変換動作パターンの記述に関する問題点

STARC SSTAG



DACMeasPattern

Cap DACUnits;Pattern “パターン名” {

：DACMeasPattern {

// DAC変換パターン範囲を示す。このブロックでは、DACUnitsの// AoutSinalに接続される信号名は省略する。V { “ピングループ名”=ニーモニック; }

// DAC変換動作パターンを記述Cap { “ピングループ名”=ニーモニック; }

// DAC変換動作パターンを記述// デジタイザのDAC結果取り込み位置を記述

DACUnits


// 参照するDACUnitsブロックのドメイン名を記述// パターン途中でDACUnits条件を切り替える

V { “ピングループ名”=ニーモニック; }Cap { “ピングループ名”=ニーモニック; }

。

：｝：

}

STARC SSTAG



PeriodCounter

block

分類


問題点

PLLテストのテスターの周期測定器の設定が記述できるようになっていない。


UserKeywordsでPeriodCounterLoopを定義し、Patternブロック中にPeriodCounterブロックを使

用してテスターの周期測定器の設定を記述することを推奨する。

PLLPLLテストのテスターの周期測定器の設定に関する問題点テストのテスターの周期測定器の設定に関する問題点

STARC SSTAG



PeriodCounter;PeriodCounter “ドメイン名”{

//テスターの周期測定器の設定を記述するブロック。InheritPeriodCounter “PeriodCounterドメイン名”;

//他のPeriodCounterブロック条件を継承する。//省略可。

TestMode

<Priod | Freq>; //測定モードを指定。省略可。省略時のモードは”Priod”になる。

//Priod:

測定値をピリオド(時間単位)で扱う。//Freq: 測定値を周波数(Hz単位)で扱う。

MeasureRange

‘ 小測定値’,

‘ 大測定値’,’分解能’ ;

//周期測定器の測定範囲、分解能を記述する。

//時間単位またはHz単位で記述する。MeasureSignals

“信号ピン名(または信号グループ名)”; //ピリオド測定ピン名の指定。複数記述可。ComparatorLevels

”信号ピン名(または信号グループ名)” {‘変数（値）’;} //被測定信号の波形検出電圧値の設定。省略可。複数記述可。省略時はVOL値を使用する。

Limit‘Low側リミット,High側リミット’;//判定Limit。TestModeがPriodの場合、時間単位で記述する。//TestModeがFreqの場合、Hz単位で記述する。

}//End PeriodCounter

STARC SSTAG



PatternExec

block

分類


問題点

PLLテストのテスターの周期測定器の設定をPatternExecで参照できるようになっていない。


UserKeywordsで定義したPeriodCounterブロックをPatternExecブロックで参照できるようにするこ

とを推奨する。

PLLPLLテストのテスターの周期測定器の設定の参照に関する問題点テストのテスターの周期測定器の設定の参照に関する問題点


PeriodCounter;PatternExec

”ドメイン名”{PeriodCounter

“PeriodCounterドメイン名”;

// 参照するPeriodCounterブロックのドメイン名を記述。: :

}

STARC SSTAG



Pattern statement

分類


問題点

PLLテストのPeriodカウンタ測定パターンのループを記述できるようになっていない。


UserKeywordsでPeriodCounterLoopを定義し、Patternブロック中にPeriodCounterLoopステート

メントを使用してPeriodカウンタ測定パターンのループを記述することを推奨する。

PLLPLLテストのテストのPeriodPeriodカウンタ測定パターンのループ指定の記述に関する問題点カウンタ測定パターンのループ指定の記述に関する問題点


PeriodCounterLoop;Pattern “パターン名” {

LABEL:PeriodCounterLoop｛//Periodカウンタ測定パターンのループ指定。周期測定器の測定が終了したらループを抜ける。W “WaveformTableドメイン名”;V { “ピングループ名”=ニーモニック; }

：｝

}

STARC SSTAG



MemoryBist

block

分類


問題点

（１）MemoryBistパターンの設定が記述できるようになっていない。

（２）MemoryBistパターンの設定がMemoryBIST回路、Redundancy(BIRA)回路のインスタンス毎に

記述できるようになっていない。

（３）MemoryBistパターンの設定がRAMマクロ毎に記述できるようになっていない。


（１）UserKeywordsで定義したMemoryBistブロックを使用してMemoryBistパターンの設定

を

記述することを推奨する。

（２）UserKeywordsで定義したMemoryBistブロック中にInstanceブロックを使用して記述すること

を推奨する。

（３）UserKeywordsで定義したMemoryBistブロック中にMacroNameブロックを使用して記述する


MemoryBistMemoryBistパターンの設定に関する問題点パターンの設定に関する問題点

STARC SSTAG


＜書式１＞

MemoryBistブロックを使用してMemoryBistパターンの設定を記述するケースUserKeywords

MemoryBist;MemoryBist ドメイン名{

//MemoryBistブロックの開始。//BIRA<Built-In Redundancy Allocation>回路を搭載していない場合は、BIRA関連のキーワード//(BiraIf、RepairFlagPin、RepairDatatPin、BiraStart、RepairBitLength、RepairOutPin、//RepairBitNo、RepairPatternOut)を記述しなくて良い。

BistIf

<Serial | Parallel>; //BIST回路のI/F種類。SerialかParallelかを記述する。＜省略可＞BiraIf

<Serial | Parallel>;

//BIRA回路のI/F種類。SerialかParallelかを記述する。＜省略可＞BistFlagPin

信号名;

//BIST結果判定の信号ピン名。

＜省略可＞RepairFlagPin

信号名;

//リペア可否判定の信号ピン名。

＜省略可＞BistDataPin

{信号ピン名1; 信号ピン名2;・・・信号ピン名n;} ＜省略可＞//BIST情報を出力する信号ピン名を全て記述する。BIST IfがSerialの場合は1ピンを記述。Parallel//場合は、全てのピンを記述する。

RepairDataPin

{信号ピン名1; 信号ピン名2;・・・信号ピン名n;} ＜省略可＞//リペア情報を出力する信号ピン名を全て記述する。BIRA IfがSerialの場合は1ピンを記述。Parallel//の場合は、全てのピンを記述する。

BistStart

ラベル名;

//BISTパターンの開始位置を示すラベル。＜省略可＞BiraStart

ラベル名; //リペアデータ取得開始のVector位置を示すラベル名。＜省略可＞BistBitLength

Bit幅;

//BISTビット幅。//Macro単位、Instance単位で記述したい場合は、それぞれのブロック内//に記述する。1以上の整数で10進記述と16進記述が可能。16進記述の場//合は、”¥h数字”で記述する。

STARC SSTAG


BistOutPin

{出力信号ピン名1; 出力信号ピン名2;・・・出力信号ピン名n;}

<省略可>//Macro単位、Instance単位で記述したい場合は、それぞれのブロック内に記述する。// BISTの故障情報を出力する信号ピン名。Serial I/Fの場合は、１ピンを記述。Parallel I/Fの//場合は、上記Bit幅数分の信号ピン名を記述する。

RepairBitLength

Bit幅;

//BIRAビット幅

<省略可>//Macro単位、Instance単位で記述したい場合は、それぞれのブロック内に記述する。

RepairOutPin


<省略可>//Macro単位、Instance単位で記述したい場合は、それぞれのブロック内に記述する。//リペアデータが出力される信号ピン名。Serial I/Fの場合は、１ピンを記述。Parallel I/Fの//場合は、上記Bit幅数分の信号ピン名を記述する。

BistBitNo{Bit番号;・・・Bit番号;}

//上記BIST出力信号ピンに対するBit番号。//Macro単位、Instance単位で記述したい場合は、それぞれのブロック内に記述する。// Serial I/Fの場合は、Bit番号の出力順に記述する。Parallel//I/Fの場合は、出力信号ピンに対するBit番号を記述する。

BistPatternOut

{ラベル名

(Increment (step数)/Decrement(step数)); ラベル名;・・・ラベル名;} //BISTデータ出力のVector位置を示すラベル名とパターンカウント方法を記述する。＜省略可＞//Macro単位、Instance単位で記述したい場合は、それぞれのブロック内に記述する。//上記のBistBitNoに対するラベル名を記述する。ただし、パターンカウント方法にIncrement//または、Decrementを記述する場合は、Bit番号毎にラベル名を記述する必要は無い。//increment、decrementは、BistIfがSerialのときにのみ記述可能。Parallelのときは記述できない。//step数は、パターンカウントのstep数。整数で記述する。省略時は、”1”とする。//パターンカウント方法は省略可能で、省略時は、ラベルが修飾するVectorのみがパターンカウント//の対象となる。ラベル名を複数記述する場合、ラベル名のみの記述とラベル名＋パターンカウント//方法の混載記述は不可。//パターンカウント方法にIncrementを記述した場合は、ラベルが修飾するVectorからstep数ずつ

STARC SSTAG


//Bit幅までパターンを下る。例えば、ラベルが修飾するVectorのパターンカウントが100で、//step数が2で、Bit幅が4の場合、パターンカウントは、100,102,104,106となる。//パターンカウント方法にDecrementを記述した場合は、ラベルが修飾するVectorからstep数ずつ//Bit幅までパターンを遡る。例えば、ラベルが修飾するVectorのパターンカウントが100で、//step数が2で、Bit幅が4の場合、パターンカウントは、100,98,96,94となる。

RepairBitNo{Bit番号;・・・Bit番号;}

//上記Repair出力信号ピンに対するBit番号。<省略可>//Macro単位、Instance単位で記述したい場合は、それぞれのブロック内に記述する。//Serial I/Fの場合は、Bit番号の出力順に記述する。Parallel I/Fの場合は、出力信号ピンに対す//るBit番号を記述する。

RepairPatternOut

{ラベル名

(Increment (step数)/Decrement (step数)); ラベル名;・・ラベル名;}//リペアデータ取得のVector位置を示すラベル名とパターンカウント方法を記述する。<省略可>//Macro単位、Instance単位で記述したい場合は、それぞれのブロック内に記述する。//上記の//RepairBitNoのBit番号に対するラベル名を記述する。ただし、パターンカウント方法に//Incrementまたは、Decrementを記述する場合は、Bit番号毎にラベル名を記述する必要は無い。//increment、decrementは、BiraIfがSerialのときにのみ記述可能。Parallelのときは記述できない。//step数は、パターンカウントのstep数。整数で記述する。省略時は、”1”とする。//パターンカウント方法は省略可能で、省略時は、ラベルが修飾するVectorのみがパターンカウント//の対象となる。ラベル名を複数記述する場合、ラベル名のみの記述とラベル名＋パターンカウント//方法の混載記述は不可。//パターンカウント方法にIncrementを記述した場合は、ラベルが修飾するVectorからstep数ずつ//Bit幅までパターンを下る。例えば、ラベルが修飾するVectorのパターンカウントが100で、//step数が2で、Bit幅が4の場合、パターンカウントは、100,102,104,106となる。//パターンカウント方法にDecrementを記述した場合は、ラベルが修飾するVectorからstep数//ずつBit幅までパターンを遡る。例えば、ラベルが修飾するVectorのパターンカウントが100で、//step数が2で、Bit幅が4の場合、パターンカウントは、100,98,96,94となる。

}

STARC SSTAG


＜書式２＞

MemoryBistブロック中にInstanceブロックを使用して記述するケースUserKeywords


Instance インスタンス名

{

//<ブロックごと省略可>//MemoryBIST回路、Redundancy(BIRA)回路のインスタンス情報。Macro単位で記述したい//場合は、Macroブロックに記述する。BistBitLength

Bit幅;

//<省略可>BistOutPin{出力信号ピン名1; 出力信号ピン名2;・・・出力信号ピン名n;} //<省略可>BistBitNo{Bit番号;・・・Bit番号;}

//<省略可>BistPatternOut

{ラベル名

(Increment (step数)/Decrement(step数)); ラベル名;・・・ラベル名;} //<省略可>

RepairBitLength

Bit幅;

//BIRAビット幅

<省略可>RepairOutPin


//<省略可>RepairBitNo{Bit番号;・・・Bit番号;}

//上記Repair出力信号ピンに対するBit番号。//<省略可>RepairPatternOut

{ラベル名

(Increment (step数)/Decrement (step数)); ラベル名;・・ラベル名;}//<省略可>

}//END Instance}

STARC SSTAG


＜書式３＞

MemoryBistブロック中にMacroNameブロックを使用して記述するケースUserKeywords


MacroName ドメイン名{MacroNo

番号;

//マクロ番号

＜省略可＞//0以上の整数で10進記述と16進記述が可能。16進記述の場合は、//”¥h数字”で記述する。

MacroType

マクロタイプ;

//マクロの種類（任意文字列）

＜省略可＞Instance インスタンス名

{

//<ブロックごと省略可>//Macroに対するインスタンス情報。複数記述可能。BistBitLength

Bit幅;

//<省略可>BistOutPin{出力信号ピン名1; 出力信号ピン名2;・・・出力信号ピン名n;} //<省略可>BistBitNo{Bit番号;・・・Bit番号;}

//<省略可>BistPatternOut

{ラベル名

(Increment (step数)/Decrement(step数)); ラベル名;・・・ラベル名;} //<省略可>RepairBitLength

Bit幅;

//BIRAビット幅

<省略可>RepairOutPin


//<省略可>RepairBitNo{Bit番号;・・・Bit番号;}

//上記Repair出力信号ピンに対するBit番号。//<省略可>RepairPatternOut

{ラベル名

(Increment (step数)/Decrement (step数)); ラベル名;・・ラベル名;}//<省略可>

}//END Instance}}//END Macro

}

STARC SSTAG



MemoryBist

block

分類


問題点

MemoryBistパターン設定をPatternBurstで参照できるようになっていない。


UserKeywordsで定義したMemoryBistブロック名をPatternBurstブロックで参照できるようにするこ

とを推奨する。

MemoryBistMemoryBistパターン設定の参照に関する問題点パターン設定の参照に関する問題点


MemoryBist;PatternBurst

ドメイン名{MemoryBist

ドメイン名;

//MemoryBistブロックのドメイン名: :

}

STARC SSTAG



MemoryBist

block

分類


問題点

MemoryBistパターンのBISTパターン開始位置、BISTデータ出力のVector位置をPattern中で設定できる

ようになっていない。


UserKeywordsでBistStart,BistPatternOutを定義し、Pattern中にBistStart/BistPatternOutステート

メントを使用してBIS開始位置/BISTデータ出力のVector位置を記述することを推奨する。

PatternPattern中での中でのBISTBISTパターン位置に関する問題点パターン位置に関する問題点

STARC SSTAG



BistStart

BistPatternOut;Pattern "パターン名1" {

W "WaveformTableドメイン名";V { “ピングループ名”=ニーモニック; }

BistStart {ラベル名;}：：

V { "ピングループ名"=ニーモニック; }BistPatternOut {ラベル名;}

：：}

STARC SSTAG



MemoryBist

block

分類


問題点

MemoryBistパターンのリペアパターン開始位置、リペアデータ取得のVector位置をPattern中で設定でき

るようになっていない。


UserKeywordsでBiraStart,RepairPatternOutを定義し、Pattern中に

BiraStart/

RepairPatternOutステートメントを使用してリペア開始位置/リペアデータ取得のVector位置を記述する


PatternPattern中でのリペアパターン位置に関する問題点中でのリペアパターン位置に関する問題点

STARC SSTAG



BiraStart

RepairPatternOut;Pattern "パターン名1" {

W "WaveformTableドメイン名";V { “ピングループ名”=ニーモニック; }

BiraStart {ラベル名;}：：

V { "ピングループ名"=ニーモニック; }RepairPatternOut {ラベル名;}

：：}

STARC SSTAG


IEEE Specification （Page100）

Clause 21: STIL Pattern Data

分類

Application：

STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケーションツールや装置で共通認識され

るべき内容

問題点

(1)STILにはパターンの属性を表すステートメントが存在しないため、STILだけを見てもどのようなテストパターンであった

のか一概には区別がつかない。例えば、Transitionテスト用パターンであったのかどうかや、そのテストパターンの方式

が

”LoC”(*1)、”LoS”(*2)のどちらであったのかの区別が出来ない。

* 1 LoC：Launch On Capture/ Launch Off Capture ( Broadsideとも言う)

* 2 LoS：Launch On Shift/ Launch Off Shift ( Skewed-Loadとも言う

)

(2)Transitionパターンとして故障診断を実行する際に、Launch(*)/Captureクロックの区別がつかない。このため、故障診

断実行に支障をきたしている。

* LaunchクロックはReleaseクロックとも言う。

TransitionTransitionパターンにおいて区別すべきパターンにおいて区別すべきrelease/capturerelease/captureクロック定義に関する問題点クロック定義に関する問題点

STARC SSTAG



(1)故障診断ツールではATPGが出力したSTILがどのような情報(属性)を持ったパターンなのか

を認識する必要がある。これまでSTIL活用ガイド1450.0Rev4.00ではそれらを区別するため、

UserKeywords

PatType;で記述することを推奨していたが、これを見直しSTIL1450.6の

PatternInformationブロックのPatternあるいはPatternBurstブロックステートメントを用いて、その

中で定義できるPurposeステートメントのUser USER_DEFINEDを使って記述することを推奨する。

＜書式＞STIL1.0 {Design 2005;CTLMode 2005;

}Environment (ENV_NAME) {(CTLMode （CTLMODE_NAME）

{(PatternInformation {(<Pattern ｜ PatternBurst> (pat_or_burst_name) {(Purpose ( User TestType < FC | DC | FCDC | AC >) //テスト種別

(1)( User ScanLaunch < Shift | Capture | Mix | Any >) // Scanパターンのラウンチ方式

(2)( User Load < Normal | DeCompression >)//スキャン入力方式

(3)( User Unload < Normal | Compression >) ; )//スキャン出力方式

(4)})*//End Pattern or PatternBurst

})//End PatternInformation})*//End CTLMode

}//End Environment

なお詳細はSTIL活用ガイド1450.6の「テストパターンの種別やテスト方式などパターン属性の記述に関する問題点

」

の提案するSolutionを参照のこと。

STARC SSTAG


提案するSolution(続き)

<書式中のキーワードの説明>

(1)TestType：テストパターンの種別を示すキーワード

FC：ファンクションテスト用パターンであることを示すキーワード

DC：DCテスト用パターンであることを示すキーワード

FCDC：ファンクションテスト用パターンとDCテスト用パターンの混在であることを示すキーワード

AC：ACテスト用パターンであることを示すキーワード

(2)ScanLaunch：ScanTypeのDynamicのテストパターンのラウンチ方式を記述するキーワード

Shift：

LoS方式のパターン、シフト動作による遷移でラウンチを行うパタ-ンであることを示すキーワード

Capture：LoC方式のパターン、キャプチャ動作による遷移でラウンチを行うパターンであることを示すキーワード

Mix ：上記の方式の混在を示すキーワード

Any：上記の方式を含めどのようなパターンでも可能であることを示すキーワード

(3)Load：スキャン入力を行うパターンであることを示すキーワード

Normal：圧縮スキャン構造を使用しないパターンであることを示すキーワード

STILに記述されたパターンがスキャンFFと一対一に直接対応がとれる。

DeCompression

：圧縮スキャン構造を使用したパターンであることを示すキーワード

STILに記述されたパターンがスキャンFFと一対一に直接対応がとれない。

(4)Unload：スキャン出力を行うパターンであることを示すキーワード

Normal：圧縮スキャン構造を使用しないパターンであることを示すキーワード

STILに記述された期待値がスキャンFFと一対一に直接対応がとれる。

Compression ：圧縮スキャン構造を使用したパターンであることを示すキーワード

STILに記述された期待値がスキャンFFと一対一に直接対応がとれない。

STARC SSTAG



}PatternBurst

BURST1 {PatList

{TR1;

}}PatternExec

EXEC1 {PatternBurst

BURST1;｝Pattern TR1{

}

Environment ENV1 {CTLMode


{Pattern TR1 {

Purpose User TestType

FC User ScanLaunch

Shift User Load DeCompressionUser Unload Compression ;

}//End Pattern}//End PatternInformation

}//End CTLMode}//End Environment


}PatternBurst

TR1 {PatList

{PAT1;PAT2;

}}PatternExec

EXEC1 {PatternBurst

TR1;｝Pattern PAT1{

}Pattern PAT2{

}

Environment ENV1 {CTLMode


{PatternBurst

TR1 {Purpose User TestType

FC User ScanLaunch

Capture ; }//End PatternBurst


}//End Environment

Pattern TR1はファンクションテスト用パ

ターンで、

LOS方式のTransition用テス

トパターンで、

またスキャンの入力と出力に圧縮構造

を使用したパターンであることを示して

いる。

PatternBurst

TR1はファンクションテス

トの実行と、

TransitionテストはLOC方

式で行われることを示している。

STARC SSTAG


(2)Launch/Captureクロックについては区別する必要がある。これまでSTIL活用ガイド1450.0Rev4.00ではそれらを

区別するため、

UserKeywords

ClockRelations;で記述することを推奨していたが、これを見直しLaunch/Caputre

クロックの定義は1450.6の

Internalブロックの中でUserKeywords

ClockRelations

RELATION_NAME を使って行い、

Patternブロック中のLaunch/Captureクロックが入るVector文の直後にClockRelations

RELATION_NAMEを記述し

てLaunch/Captureクロックの区別を明示することを推奨する。

TestAccessの< Macro | Procedure > NAMEには分周クロックの動作を定義した

Macroあるいは

Procedureブロックの名

前を記述する。

DECIMAL_INTEGER には分周クロックの動作を定義

したMacroあるいは

Procedureブロック内の先頭

Vectorを１として、LaunchまたはCaptureクロック

が入るまでのVector数を記述する。

sigref_expr：Signal expressions define an ordered list of signals; they are either a single token, or an expression enclosed in single quotes. Signal expression operators are plus (+), minus (-), ellipsis (..), and parentheses. These operators are not extendable. Expressions are

evaluated left-to-right, with parentheses used to override this order. Signals referenced in signal expressions may occur only once in the sub-expressions generated during evaluation of the expression.

OffsetはLaunchClockの入ったVectorを０と

数えCaptureClockが入るVectorまでの

Vector数を示す。従って１サイクル内に

Launchクロック, Captureクロックが入る場合

はオフセットは0であり、この時のオフセット

値０をデフォルトとする。

PLLで同期が

取れた後のク

ロック開始ま

での遅れ時間

＜書式＞STIL 1.0 {Design 2005；CTL 2005;

}UserKeywords

ClockRelations;Environment ( ENV_NAME ) {

CTLMode

( CTLMODE_NAME ) {Internal {

(ClockRelations

RELATION_NAME {(sigref_expr｛

//1ピン以上の信号定義IsConnected

In {(TestAccess

( User VectorCountToLaunch

DECIMAL_INTEGER

(StartDelay time_exor) )

( User VectorCountToCaptue DECIMAL_INTEGER (StartDelay

time_exor) )

< Macro | Procedure >

NAME;)*( < LaunchClock

| CaptureClock

( offset DECIMAL_INTEGER) > SIGNAME {

//1ピンの信号定義<LeadingEdge

| TrailingEdge>;StateAfterEvent

<ExpectLow

| ExpectHigh

> ; )} )* // end LaunchClock

}* // end IsConnected})* // end sigref_expr

})* // end ClockRelations} // end Internal

} // end CTLMode} // end Environment

STARC SSTAG


＜書式＞PatternBurst

DOMAIN_NAME {

ParallelPatList

SyncStart

{PATTERN_NAME1;PATTERN_NAME2;

}}Pattern PATTERN_NAME1 {

V{ } ClockRelations

(RELATION_NAME)+ }

Pattern PATTERN_NAME2 {V{ } ClockRelations

(RELATION_NAME)+ }

//ClockRelationsは一つ前のVectorを修飾する。

なお詳細はSTIL活用ガイド1450.6の「Transitionパターンにおいて区別すべき

Launch/Captureクロック定義に関する問題点

」の提案するSolutionを参照のこと。

STARC SSTAG


Environment {

CTLMode

CTLMODE1 {//CTLMODE_NAME

Internal {

ClockRelations

“TEST1”

{

"CLK3" ｛IsConnected

In {

LaunchClock

"CLK3" {LeadingEdge;

StateAfterEvent

ExpectHigh;

} // end LaunchClock

} // end IsConnected

IsConnected In {

CaptureClock "CLK3" {TraillingEdge;

StateAfterEvent ExpectLow;

} // end CaptureClock

} // end IsConnected

} // end sigref_expr

} // end ClockRelations

} // end Internal

} // end CTLMode

} // end Environment


}UserKeywords

“ClockRelations”;Procedures {

“load_unload”{

W “TS”;

C{ ・・・・;}

Shift { V{ si=#; so=#;・・・・・;} }

}

}Pattern PAT1 {W “Default”;Macro “test_setup”;//MacroDefsで全ピンの初期設定と

// テストモードを定義し、ここでコールCall “load_unload”

{ si= ・・・; so=・・・・; } V{ } // CLK3の立上りでLaunch、

//CLK3立下りでCapture

ClockRelations

“TEST1”; V{ }V{ }：：

}

１サイクル内にLaunch 、

Captureが入る場合

STARC SSTAG


IEEE Specification （Page９８）

20.1 ScanStructures

block syntax

分類

Application：

STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケーションツールや装置で共通認識され

るべき内容

問題点

STIL1450.0 ScanCellsの中にCELLNAME-LISTの記述が以下のように定義されている。

20.1 ScanStructures

block syntax(P98)

ScanCells: Identifies the scan cells comprising the scan chain.

CELLNAME-LIST is ScanLength

scan cell NAMEs

separated by whitespace.

Inversion is also specified by interleaving the "!" character between

scan cell NAMEs

(also includes before the first scan cell and after the

last scan cell). Scan cell NAMEs

are ordered from the first scan cell to

be shifted (input) to the last scan cell to be shifted (output).

ScanCellsScanCellsののScanScan Cell Cell NamesNames記述に関する問題点記述に関する問題点

STARC SSTAG


ScanStructuresブロックのScanCellsステートメントにおいてScan Cell Names記述にFFのインスタンス名

までを記述すれば良いのか、FFのピン名までも含めて記述すれば良いのかが明確でない。

さらにインスタンス名の記述がVerilog形式なのかVHDL形式なのか、または独自形式なのかが指定できないた

め、インスタンス名の記述形式の判断はツールのインプリに依存してしまう。

このためパラレルロードシミュレーションの実行に支障をきたしている。

STARC SSTAG



パラレルロードシミュレーションに必要な情報はSTIL1450.1のScanCellTypeブロックとScanCellsブロッ

クで記述可能なため、STIL1450.1で記述することを推奨する。

ScanCellsステートメントに替わってScanCellsブロックでFF(セル)のインタンス名を書き、

ScanCellTypeのスキャン入力/出力でFF(セル)のピン名を記述することを推奨する。

また各FF(セル)のインスタンス名をVerilog形式あるいはVHDL形式のいずれかで記述することを

推奨する。どちらを採用するかはアプリケーションに任せる。

詳細はSTIL活用ガイド1450.1の「ScanCellsの定義に関する問題点」を参照。

例) STIL 1.0 { Design 2005; }

ScanCellType FD1 {

CellIn "MASTER" : "SIN1" ; //セルタイプのスキャンイン名SIN1を定義

CellOut "SLAVE" : "SOUT1" ; //スキャンアウト名SOUT1を定義

}

ScanCellType FD2 {

CellIn “MASTER" : “SIN2" ; //セルタイプのスキャンイン名SIN2を定義

CellOut “SLAVE" : “SOUT2" ; //スキャンアウト名SOUT2を定義

}

ScanCells {

"top.a1" "FD1" ; "top.a2" "FD1" ; "top.a3" "FD2" ;・・・・・；

} //

“top.a1"、“top.a2"はScanCellType FD1を"top.a3"はScanCellType FD2を参照

STARC SSTAG


IEEE Specification （Page９８）

20.1 ScanStructures

block syntax

分類

Application：

STILデータ記述あるいは解釈する上では問題はないが、STILデータを取り扱うアプリケーションツールや装置で

共通認識されるべき内容

問題点

ATPGはシャドースキャンチェーンにもスキャンインされるものとしてパターンを生成するため、シャドースキャ

ンチェーンにもパラレルロードが必要となるが、現状のScanStructuresではシャドースキャンチェーンを簡潔に

は表現できない。

スキャンチェーン構成に関する問題点スキャンチェーン構成に関する問題点

STARC SSTAG



現状、ScanChainの分岐を示す記述がないため、UserKeywords(ScanBranch)を使用して分岐

の起点を定義し、ScanStructuresのScanChain構成を明示することを推奨する。

＜書式＞

UserKeywords

ScanBranch;

ScanStructures

(SCAN_NAME){

(ScanChain

CHAINNAME {

(ScanIn

SIGNALNAME;) //ScanBranchの分岐開始点のラベル名を記載

(ScanOut

SIGNALNAME;)//分岐したスキャンチェーンのFF 終段がオープンノードの場合はPseudoで記載

(ScanCells

(CELLNAME-LIST);)

(ScanBranch

(BRANCHNAME DECEMAL_INTEGER;)+;)// BRANCHNAMEは分岐点

//につける名前

// DECEMAL_INTEGERは

//Scan-Inから分岐点までのFFの数

})*

}

STARC SSTAG


si1-> ---□---□---□---□---□---□---□---□---

->so1 ←スキャンチェーンSC1

--□---□---□--

←シャドースキャンチェーンSC2

--□---□--

←シャドースキャンチェーンSC3

(記述例）UserKeywords

ScanBranch; ScanStructures

{ScanChain

SC1{ScanIn

si1;ScanOut

so1;ScanCells

A B C D E F G H;ScanBranch

branch1 1;}

ScanChain

SC2{ScanIn

branch1;ScanOut

net1 Pseudo;ScanCells

I J K;ScanBranch

branch2 2;}

ScanChain

SC3{ScanIn

branch2;ScanOut

net2 Pseudo;ScanCells

L M; }

}

A B C D E F G H

I J K

L Mbranch1

branch2

net1

net2

STARC SSTAG


IEEE Specification （Page５９）


分類


問題点

ユーザ定義名(User-defined name)の記述が以下のように定義されている。

6.8 User-defined name characteristics（P59)

There are several categories of user-defined names in STIL: signal and group references, WaveformChar

references, WaveformTable

references, variable references, UserKeywords, labels, and domain names(*).

ユーザ定義名として明記されていないScanStructuresブロックのScanChain名、ScanCells名、

UserFunctions名の記述の扱いは不明確なものとなっている。

ユーザ定義名に関する問題点ユーザ定義名に関する問題点

(*) domain names :

Domain names provide a mechanism to reference the data defined in a named block.

When a domain name is present for a SignalGroups, Procedures, MacroDefs, PatternBurst, Timing, Selector, Pattern or ScanStructures

block, that domain name shall be specified in a “reference“ statement in order to

make use of the data in that block.

さらにTable 6 (P66)のSpec、PatternExec等のブロック名はユーザ定義名とP59に記述あり。

STARC SSTAG



Named Blockとなるブロックステートメントに付けられるブロック名はユーザ定義名

として扱うものと解釈する。従ってScanStructuresブロックのScanChain名は

ユーザ定義名として扱われる。

またUserFunctionsに付けられる名前はUserKeywordsに準じるものとしてユーザ定義名

として扱うものと解釈する。

ScanStructuresブロックのScanCells名はSignals名に準じてユーザ定義名として扱うものと解釈する。

従ってユーザ定義名はSTILを作成する人またはツール、設計者が付けることが出来る全ての名前

の総称と解釈することになる。

STILの拡張スペック（IEEE1450.1、1450.2、1450.3、1450.6）でも同様の問題があり

同様に解釈するものとする。詳細については各STIL活用ガイドを参照のこと。

STARC SSTAG


IEEE Specification （Page６０）

6.10 Signal and group name characteristics

分類


問題点

BUS記述のIndex Numberを昇順、降順に記述できるが、同一のIndex Numberで表記された場合の

取り扱いが不明確となっている。

例：

"BUSA"[0..31] //Index Numberが昇順、"BUSA"[0], "BUSA"[1], … "BUSA"[31] と同じ

"BUSA"[31..0] //Index Numberが降順、"BUSA"[31], "BUSA"[30], … "BUSA"[0] と同じ

"BUSA"[15..15] // Index Numberが同一の整数値、この場合の取り扱いが不明

・・・(*)

BUSBUS端子名の記述に関する問題点端子名の記述に関する問題点

提案するSolutionBUS記述においてIndex Numberに同一の整数値が記述(*)されている場合はその整数値のBUS端子、即ち”信号名”[整数値]と同じ端子を表すものと解釈する。

ただし、Index Numberに同一の整数値がある記述(*)は使用しないことを推奨する。

また、一つのBus端子の表記においてIndex Numberに同一の整数値がある記述(*)とその整数値の

BUS端子の記述の混在は混乱を避けるためアプリケーションサイドでエラーとして扱っても良いも

のとする。

STARC SSTAG

Copyright STARC 2005-2011 122

IEEE Specification (Page 65)

6.15 WaveformChar characteristics(Page 65)

(cf. 21.1 Cyclized data (Page 100))

分類

Description： STILデータを記述あるいは解釈する上で共通認識しておくべき内容であることを示す

問題点

ベクターフラグ¥rの繰り返しCharactersのlist記述において、¥rが記述できるかどうかが明確でなく、ｌist記述の中で使われた場合の解釈が曖昧である。

<書式> ¥rN XXX

例) sigref_expr=¥r3 00¥r2 11 0 01;

パターンの繰り返し記述の範囲に関する問題点

6.15 WaveformChar characteristics (P65)

The repeat flag ¥r is applied to a list until terminated by the end of the expression, or by

the first whitespace after the ¥r and count fields.

(cf. 21.1 Cyclized data (P100))

¥rN XXX: Repeat the next group of characters N times (e.g., ¥r60 01). N copies of the XXX

characters are generated. The XXX characters are delimited by whitespace and may be

WaveformChars, Hexadecimal characters, or Decimal characters.

STARC SSTAG



¥rの繰り返し回数の後のスペースは¥rの繰り返し回数を示す数字(count fields)の一部(デリミタ)として扱われ

ている。¥rで繰り返す記述のデリミタ(the first white space)としては扱われず、繰り返すlist記述の中に¥rを

記述しても矛盾は生じない。従ってベクタフラグ¥rの繰り返すlist記述の中に¥rは記述できるものと解釈する。

sigref_expr=¥r3 00¥r2 11 0 01;

空白1 空白2

空白３

空白4

空白1、2はそれぞれ¥r3、¥r2の繰り返し回数を示す数字(count fields)の一部(デリミタ)として

扱い、空白3が¥r3、¥r2双方のlist記述のデリミタ(the first white space)となる。

したがって、上記のケースでは、

V { sigref_expr=001111001111001111001;} と等価となる。

例）

V { sigref_expr=¥r3 00¥r2 11 0 01; } は、

V { sigref_expr=001111001111001111001;} と等価となる。

STARC SSTAG


提案するソリューション(続き)

6.15 WaveformChar characteristics(P65)

Since the ¥r construct is terminated by whitespace, it is not possible to define a repeat construct around a list that specifies ¥h or ¥d options. For example, the list “¥r2 ¥hwW f0” attempts to apply the WaveformChars ‘w’and ‘W’ to the hex value f0. However, the whitespace required for ¥h also terminates the ¥r operation. This situation is resolved by putting the hex flag first as follows: “¥hwW ¥r2 f0.”

注1)STILの仕様書ではWhiteSpaceは、空白(space)、タブ(tab)、改行(newline character)を意味して

いる。

注2) ¥rで繰り返すlist記述の中において、¥h、¥dによって文字の種別を切り替える記述はできない。

¥wによるhex記述ないしはdecimal記述からの文字の種別を切り替える記述は可能である。

¥h01 11 ¥r2 A¥wLH 0101

00010001 1010 LH 1010 LH 0101

STARC SSTAG


パターンの代入に関する問題点

■提案するソリューション：STILの仕様書とClarificationに従い以下の動作とする。

呼出し時に代入されるSignalGroups名(sigref-exprs)の中に、本体の定義中にあるSignalGroups

名と同じものがあれば、先頭の一致するSignalGroups名のV文から順に

パターン(引数)を代入する。この操作を一致するSignalGroups名がなくなるまで繰り返す。

ただし一致するSignalGroups名の呼出し時にある代入パターンは後続の同一名の本体の代入

すべきV文(# or %があるV 文)にのみ使われ余れば捨てられ、展開して対応する信号の代入には用いられない。

次に代入すべき本体のV文が残り呼出し時に代入されるSignalGroups名が残っていれば、

呼出し時に記述された順にSignalGroupsを展開して対応する信号に記述されたパターンを

代入していく。本体の代入すべきV文がなくなれば、これで代入操作は終了となる。

このとき残ったSignalGroups名の中に代入すべき信号が重複しているときにはどの値を代入

すべきか特定できないためエラーとなることに注意する。

これでもまだ本体の代入すべきV文に信号が残り、呼出し時に代入するパターンが不足

する場合には、その信号に代入すべきV文が本体の定義中で最初に現れるの直前に明示されているパターンをその信号に代入するものとする。ただし、もし本体定義中で代入すべきV文の直前に明示されたパターン(WFC)がなく、代入する

パターンが不足する場合には、Procedureの呼び出しがエラーとなり、Macroに対しては呼出し直前のパターン(WFC)を継承し代入することになる。

STARC SSTAG


■提案するソリューション(続き)

なおProcedure本体の定義で記述される信号は、先頭のV文ないしはC文ですべて記述

することがSTILでは要請されており、記述されていなければエラーとなる。特に初の

V文に代入(# or %)がある場合や部分代入を行う場合には、Procedure先頭のW文に続けて

C文でデフォルトの状態値を明示することを推奨する。

またProcedureは独立したパターンブロックであり呼出し前後のパターンに影響

されないし影響しないが、Macroは呼出し時の位置で展開されるパターンブロックであり

呼出し前後のパターンに影響されるし影響することに注意する。

このため呼出し時の代入パターン(引数)が不足する場合において、代入すべき信号に対し

本体の定義で明示された代入パターンがない場合のProcedureの呼出しはエラーとなるが、

Macroの呼出しは直前の状態値を引きずってくるため、この状態値が暗黙の明示パターンと

なり代入されるため、エラーとはならない。

ただしShiftブロックを含む代入処理においては、Pre/Postパターンへの代入パターン数を

考慮してShiftブロックへの代入操作が行われることになるが、Shiftブロックへの代入パター

ンが引数として残らない場合にはShiftブロックの動作が抑制されることに注意する。

代入操作で混乱をきたさないため、出来る限り本体の定義と呼出し時の代入操作は同じ

ピングループ名とそれに対応した同じ信号数での代入を行うことを推奨する。

STARC SSTAG


問題点とソリューション例1 代入パターン（引数）が無いケース（SignalGroups）

STIL 1.0;

Signals {"A1" InOut;"A2" InOut;"SI1" InOut { ScanIn; }"SO1" InOut { ScanOut; }

}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';}

Timing "tim1" {}PatternBurst "test1" {}PatternExec {}Procedures {

"proc1" {W "tim_wf";C { "gr2 "=¥r3 0 X; } // 明示されたパターンV1:V{ “gr2 ”=¥r4 # ; } // 代入パターンV2:V { "gr1 "=¥r4 # ; } // 代入パターンC { "gr2"=¥r4 1; }V3:V { " gr3 "=¥r2 # ; } // 代入パターン

}}Pattern "test1" {

W "tim_wf";C { “gr1”=¥r3 0 H ; }

Call "proc1" { " gr1 " =Z0ZL; // Procedure本体の " gr1 "(V2)に代入" gr3 " =0H; // Procedure本体の" gr3 "(V3)に代入} // 代入パターンのない“gr2 “(V1)には#の前に明示されたC文のパターンを代入

V4:V{“ gr3 ” =1L;}//Call文の前のC文のパターンが初期パターンとして割り付けられる}

上記例のPatternブロックは、以下の記述と等価になる。Pattern "test1" {

W "tim_wf";V1:V { "gr1"=000X ; } V2:V { "gr1"=Z0ZL ; }V3:V { "gr1"=110H ; } V4:V { "gr1"=001L ; }

}

ソリューション＞Procedure本体に代入すべきV文が残り、呼出し時に代入するパ

ターンが不足する場合には、本体の定義中でその信号に代入す

べきV文が初に現れる記述の直前に明示されているパターン

(WFC)を代入する。

STARC SSTAG


STIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';}

Timing "tim1" {}PatternBurst "test1" {}PatternExec {}Procedure {

"proc1" {W "tim_wf";

V1:V {" gr1 " =¥r4 0; } V2:V {" A1 "= # ; } V3:V {" A2 "= 1 ; }V4:V {" A2"= # ; }V5:V {"gr3"= # ; }

}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r4 X ; }

Call "proc1" { " gr3 "=1P; // Procedure本体の " gr3 "(V4)に代入} // 代入パターンのない”A1”(V1)には#の直前に明示されたV0のパターン0 を代入//代入パターンのない”A2”(V3)には#の直前に明示されたV2のパターン1を代入

V6:V{“ gr3 ” =1L;}//Call文の前のC文のパターンが初期パターンとして割り付けられる

}

ソリューション＞Procedure本体に代入すべきV文が残り、呼出し時に代入す

るパターンが不足する場合には、本体の定義中でその信号

に代入すべきV文が初に現れる記述の直前に明示されてい

るパターン(WFC)を代入する。

問題点とソリューション例2 代入パターン（引数）が無いケース（Signals）


W "tim_wf";V1:V { "gr1"=0000 ; } V2:V { "gr1"=0000 ; }V3:V { "gr1"=0100 ; } V4:V { "gr1"=0100 ; }

V5:V { "gr1"=011P ; } V6:V { "gr1"=XX1L ; }

}

STARC SSTAG


STIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';}


"proc1" {W "tim_wf";C { "gr2 "=¥r3 0 X; } // 明示されたパターンV0V1:V { "gr2 "=¥r4 # ; } // 代入パターンV2:V { "gr1 "=¥r4 # ; } // 代入パターンV3:V { "gr2 "=¥r4 # ; } // 代入パターンC { "gr2"=¥r4 1; }V4:V { " gr3 "=¥r2 # ; } // 代入パターン

}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r3 0 H ; }

Call "proc1" { “ gr1 ” =Z0ZL; // Procedure本体の “ gr1 ”(V2)に代入。“ gr3 ” =1P; // Procedure本体の" gr3 "(V3)に代入} // 代入パターンのない“gr2 “(V1)には#の前に明示されたV0のパターンを代入V5:V{“ gr3 ” =1L;}//Call文の前のC文のパターンが初期パターンとして割り付けられる

}





問題点とソリューション例3 代入パターン（引数）が無いケース（SignalGroups複数）


W "tim_wf";V1:V { "gr1"=000X ; } V2:V { "gr1"=Z0ZL ; }V3:V { "gr1"=000X ; } V4:V { "gr1"=111P ; } V5:V { "gr1"=001L ; }

}

STARC SSTAG


問題点とソリューション例4（SignalGroups,Signal混載のケース）

STIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';}


"proc1" {W "tim_wf";C { "gr2 "=¥r3 1 X; } // 明示されたパターンV1:V { "gr2 "=¥r4 # ; } // 代入パターンV2:V { "gr1 "=¥r4 # ; } // 代入パターンC { "gr2"=¥r4 0; }V3:V { " gr3 "=¥r2 # ; } // 代入パターン

}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r3 0 X ; }

Call "proc1" { " gr1 " =Z0ZL; // Procedure本体の " gr1 "(V2)に代入

“ A1 ” =0; “ A2” =0; // Procedure本体の “ gr2 ”(V1)のA1,A2に代入。埋めきらないところは// #の前に明示的されたV1のパターンを代入。

“ gr3 ” =1P; // Procedure本体の " gr3 "(V3)に代入} V4:V{“ gr3 ” =1L;}//Call文の前のC文のパターンが初期パターンとして割り付けられる

}






W "tim_wf";V1:V { "gr1"=001X ; } V2:V { "gr1"=Z0ZL ; }V3:V { "gr1"=001P ; } V4:V { "gr1"=001L ; }

}

STARC SSTAG


問題点とソリューション例5 代入パターン（引数）が不足するケースSTIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';}



}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r3 0 X ; }

Call "proc1" { “ gr1 ” =Z0ZL; // Procedure本体の “ gr1 ”(V2)に代入。“gr2” =10; // “gr2”の引数 4つに対して代入パターンは2つ。引数不足している2ピン分は、

//#前に明示されたパターンV0を代入。“ gr3 ” =1P; // Procedure本体の“ gr3 ”(V3)に代入。} V4:V{“ gr3 ” =1L;}//Call文の前のC文のパターンが初期パターンとして割り付けられる

}







}

STARC SSTAG


問題点とソリューション例6 代入パターン（引数）が余るケースSTIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';}



}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r3 0 X ; }

Call "proc1" { “ gr1 ” =Z0ZLZ1ZH; // Procedure本体の “ gr1 ”(V2)に代入。余ったパターンは捨てられる。“ gr3 ” =1P; // Procedure本体の" gr3 "(V3)に代入} // 代入パターンのない“gr2 “(V1)には#の前に明示されたV0のパターンを代入V4:V{“ gr3 ” =1L;}//Call文の前のC文のパターンが初期パターンとして割り付けられる

}

ソリューション＞一致するSignalGroups名の呼出し時にある代入パターン（

引数）は後続の同一名の代入すべき本体のV文にのみ使われ

余れば捨てられ、展開して対応する信号の代入には用いら

れない。



}

STARC SSTAG


STIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';}


"proc1" {W "tim_wf";// gr2#の前に明示されたパターンが無いV1:V { "gr2 "=¥r4 # ; } // 代入パターンV2:V { "gr1 "=¥r4 # ; } // 代入パターンC { "gr2"=¥r4 X; }V3:V { " gr3 "=¥r2 # ; } // 代入パターン

}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r4 X ; }

Call "proc1" { "gr1 "=Z0ZL; // V2に代入"gr3 "=1P; // V3に代入} // “gr2”の#の直前に明示されたパターンがなく代入するパターンが不明でありエラーV4:V{“ gr3 “ =1L;}//Call文の前のC文のパターンが初期パターンとして割り付けられる

}

問題点とソリューション例7 初の#の前に明示されたVectorが無い場合(Procedure)

ソリューション＞本体定義中で代入すべきV文の直前に明示されたパターン

(WFC)がなく、代入するパターンが不足する場合には

Procedureに対してはエラーとする。

エラー

STARC SSTAG


問題点とソリューション例8 初の#の前に明示されたVectorが無い場合(Macro )STIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';}

Timing "tim1" {}PatternBurst "test1" {}PatternExec {}MacroDefs {

" Macro1 " {W "tim_wf";// V1の" gr2 "の#の前に明示されたパターンが無いV1:V { "gr2 "=¥r4 # ; } // 代入パターンV2:V { "gr1 "=¥r4 # ; } // 代入パターンC { "gr2"=¥r4 1; }V3:V { " gr3 "=¥r2 # ; } // 代入パターン

}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r3 0 X ; }

Macro " Macro1 " { "gr1 "=Z0ZL; // V2に代入"gr3 "=1P; // V3に代入} // 代入パターンのない"gr2 "の

// V1には呼出し直前のパターン

“ gr2 ” =¥r4 X ; を代入V4:V{“gr3 ” =1L;} //不足パターンはMacro文の終パターンが割り付けられる

}

ソリューション＞本体定義中で代入すべきV文の直前に明示されたパターン

(WFC)がなく、代入するパターンが不足する場合にはMacro

に対しては呼出し直前のパターン(WFC)を継承し代入する。



}

STARC SSTAG


問題点とソリューション例9 SignalGroupsの展開STIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';"gr4" = '

" A1"+ " A2"

';"gr5" = '" A2"+ " A1"

';}


“Macro1" {W "tim_wf";V1:V { "gr2 "=¥r4 # ; } // 代入パターンV2:V { "gr1 "=¥r4 # ; } // 代入パターンV3:V {" gr2 "=¥r4 #; } //代入パターンV4:V { " gr3"=¥r2 # ; } // 代入パターンV5:V{ “ gr4”=¥r2 # ; } // 代入パターン（代入パターンの残り）

}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r3 0 X ; }Macro " Macro1 " { "gr2 " =00001111; // 0000はV1に代入、1111は V3に代入"gr1 " =Z0ZL; // V2に代入"gr3 " =1P; // V4に代入"gr5 " =1P; // “ gr4 ”の引数無し。”gr5”のパターンをV5に代入} V6:V{“gr3 ” =1L;} //不足パターンはMacro文の終パターンが割り付けられる

}

ソリューション＞

呼出しで代入されるSignalGroups名の中に、本体の

定義中にあるSignalGroups名と同じものがあれば、先頭の一致するSignalGroups名のV文から順にパタ

ーンを代入する。この操作を一致するSignalGroups名がなくなるまで繰り返す。次に呼出しで代入されるSignalGroups名が残っていれば、呼出しで記述

された順にSignalGroupsを展開して対応する信号に記述されたパターン

を代入していく。


W "tim_wf";V1:V {"gr1"=0000 ; } V2:V {"gr1"=Z0ZL ; }V3:V {"gr1"=1111 ; } V4:V {"gr1"=111P ; } V5:V {"gr1"=P11P ; } V6:V {"gr1"=P11L ; }

}

STARC SSTAG


問題点とソリューション例10 SignalGroupsの展開STIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"+ "A2"+ "SI1"+ "SO1"

';"gr3" = '

"SI1"+ "SO1"

';"gr4" = '

" A1"+ " A2"

';"gr5" = '" A2"+ " A1"

';}


" Macro1 " {W "tim_wf";V1:V { "gr2"=¥r4 # ; } // 代入パターンV2:V { "gr1"=¥r4 # ; } // 代入パターンV3:V { “gr2”=¥r4 #; } //代入パターン（代入パターンの残りgr5のA2のデータ1をA2に代入）V4:V { “gr3”=¥r2 # ; } // 代入パターンV5:V { “gr4”=¥r2 # ; } // 代入パターン

(代入パターンの残りgr5のA1のデータPをA1に代入）} //V3とV5の不足パターンにはMacro直前のC文のデータから

} //V3のSI1,SO1には0Xが、V5のA2には0が代入されるPattern "test1" {

W "tim_wf";C { "gr1"=¥r3 0 X ; }Macro " Macro1 " { "gr2 " =00001; // 0000はV1に代入、1は V3の”A1”に代入"gr1 " =Z0ZL; // V2に代入"gr3 " =1P; // V4に代入“gr5 ” =1P; // “ gr4 ”の引数無し。V3の”A2”とV5の”A1”にはそれぞれ1Pを代入} // 不足パターンとしては明示されたXを代入V6:V{“gr3 ” =1L;} //不足パターンはMacro文の終パターンが割り付けられる

}

ソリューション＞

呼出しで代入されるSignalGroups名の中に、本体の

定義中にあるSignalGroups名と同じものがあれば、先頭の一致する

SignalGroups名のV文から順にパターンを代入する。この操作を一致するSignalGroups名がなくなるまで繰り返す。次に呼出しで代入されるSignalGroups名が残っていれば、呼出しで記述

された順にSignalGroupsを展開して対応する信号に記述されたパターン

を代入していく。


W "tim_wf";V1:V { "gr1"=0000 ; } V2:V { "gr1"=Z0ZL ; }V3:V { "gr1"=110X ; } V4:V { "gr1"=111P ; } V5:V { "gr1"=P01P ; } V6:V { "gr1"=P01L ; }

}

STARC SSTAG


問題点とソリューション例11 代入パターンが特定できないケース

STIL 1.0;


}SignalGroups {

"gr1" = '"A1"+ "A2"+ "SI1"+ "SO1"

';"gr2" = '

"A1"';"gr3" = '"A1"

';"gr4" = '

"A1"';"gr5" = '

" A2"+ " SI1 "+ " SI2 "

';

}

Timing "tim1" {}PatternBurst "test1" {}PatternExec {}MacroDefs {“Macro1" {

W "tim_wf";V1:V { "gr1"=¥r4 # ; } // 代入パターンV2:V { "gr2"=# ; } // 代入パターン

}}Pattern "test1" {

W "tim_wf";C { "gr1"=¥r3 0 X ; }Macro “Macro1" { “gr3”=0; // ”A1”の信号を”gr3”と“gr4 ”のSignalGroupsが参照している。“gr4”=1; //V1の”A1”に代入するパターンとして”gr3”、 “gr4 ”“gr5”=111; //のどちらを代入するか決定できない。}

V3:V{“gr3” =1L;} //不足パターンはMacro文の終パターンが割り付けられる}

ソリューション＞ProdedureやMacroの呼出しで、１つの信号を複数のSignalGroupsが参照することはできない。エラーとする。

エラー

STARC SSTAG


コメントに関する問題点

■IEEE Specification(Page58)

6.5 Comments (Page58)

■分類

Description： STILデータを記述あるいは解釈する上で共通認識しておくべき内容であることを示す

■問題点

コメントは、//ラインコメント、/*ブロックコメント*/の２種類の記述形式があり、両者はすべての空白箇

所に記述でき、空白（whitespace)として扱われると規定されているが、その具体的な取り扱いが不明確である。

■提案するソリューション

//ラインコメント、/*ブロックコメント*/の２種類のコメント記述は、STILファイルの任意の場所に記述できるものと解釈する。//ラインコメント、/*ブロックコメント*/の空白（whitespace)としての扱い方は、特に規定せず、個々のアプリケーションに任せるものとする。

なお、//ラインコメント、/*ブロックコメント*/の扱い方は、スペース1文字に解釈することを推奨する。

STIL 1.0; ：： Pattern “PAT1”{ W/*comment1*/”TS1” V {ALLPAT=0100HL;} Loop/*comment2*/2{ V {ALLPAT=0100LL;} } }

例１）

/* Comment */ (改行） STIL 1.0; Header ｛：：

例2）

STIL 1.0; ：： Pattern “PAT1”{ W ”TS1” V {ALLPAT=0100HL;} V {ALLPAT=0100/* comment3 */LL;} V {ALLPAT=0100LL;} }

例3）

STARC SSTAG


IEEE 1450.0 5.1.1 STIL grammatical constructs STILのステートメントはSimple StatementとBlock Statementの2種類のみである。

Simple Statement Keyword (OPTIONAL_TOKENS)*;

Block Statement Keyword (OPTIONAL_TOKENS)* { (OPTIONAL_MORE_STATEMENTS)* }

したがって、//ラインコメントと/* ブロックコメント*/ はSTILのステートメントではない。

以下のようにwhitespaceとして扱われ、whitespaceが記述できる場所に記載できる。

whitespace

は1文字以上の空白文字、タブ文字(¥t)、改行文字(¥n)で構成される文字列をいう。

IEEE 1450.0 6.5 CommentsThere are two styles of comment in STIL:

// line comment line comments are terminated by newline/* block comment */ block comments may span multiple lines

Comments may appear at any legal whitespace

location and are treated as whitespace. Nested block comments shall not be allowed (e.g., “/* /* */ */”), but line comments may be containedin block comments. Comments defined using these constructs may not be preserved through STIL processes. See Clause 13 for annotations, which are a type of comment that is preserved through processes.

STARC SSTAG


【記述例について】

STIL 1.0;：：

Pattern

“PAT1”{W/*comment1*/”TS1”V

{ALLPAT=0100HL;}Loop/*comment2*/2{

V

{ALLPAT=0100LL;}}

}

例１）

/* Comment */(改行）STIL 1.0;

Header

｛：：

STIL 1.0;：：

Pattern

“PAT1”{W ”TS1”V

{ALLPAT=0100 HL;}V

{ALLPAT=0100/* comment3 */LL;}V

{ALLPAT=0100 LL;}}

例2）

例3）

例２：//ラインコメント、/* ブロックコメント*/は空白文字に解釈される。

Wの後、およびLoopの後にはwhitespaceが記述されたとみなされ、

正しいSTILである。

例1：//ラインコメント、/* ブロックコメント*/はSTILのステートメントではない。

左のようにSTILステートメントの前にコメントを記述できる。

STIL1450.0 STIL statement (Page70)の中に以下のように定義されている。8. STIL statement

The STIL statement shall be the first statement of a STIL file. The version number refers to the revision of STIL that the writer is designed to support.

例３：//ラインコメント、/* ブロックコメント*/は空白文字に解釈される。

例2のようにwhitespaceとして扱われ、Loop圧縮の対象にできるか

についてはアプリケーションに任せるものとする。

STARC SSTAG


注意

STIL活用ガイドではユーザ定義名の中にwhitespace を使うことを禁止しているがSTILデータの中にwhitespaceを含むユーザ定義名があるSTILデータがあり、その中でwhitespaceを含むユーザ定義名にwhitespaceの代わりにコメント文字列を

記述した場合はコメント文字列とは扱わず、別の定義名と解釈する。

例

“abc d” と

”abc/* comment */d” は同じ定義名ではない。

Annotationの記述位置STIL1450.0 Annotation

の中にAnnotationの記述が以下のように定義されている。

13. Ann statement (P74)Annotations are text strings that are maintained through a STIL process as appropriate for that process. (In

particular, a STIL output shall contain any annotations that were present in the input.) Annotations may containany desired user information or comments. The Ann statement may occur any place a STIL statementmay occur after the initial STIL (version) statement. It may occur as a top-level statement or inside STILblock statements.

The Ann statement uses two-character delimiters to identify an annotation block. The Ann statement blockstarts after the token “{*”

and is terminated by the token “*}”. These delimiters shall be separated withwhitespace

from the annotation text.

13.1 Annotations statement syntaxAnn {* ANNOTATION *}Ann: Keyword for the annotation statement.ANNOTATION : Text string of annotation.

Annotationの記述はSTIL定義のステートメントとして位置づけられており、ステートメントが記述できる任意の場所に記述することができるが、STILステートメント（ファイルの先頭）より前には記述することができない。

starc...

Documents