Not sure if everyone is aware of this or not- but there appears to be a major bug in the way that SmarTest 7 handles flow branching.
When a branch is encountered in a test flow, whether it's a pass/fail branch or an if/then branch, the way that SMT7 handles it if some sites follow the branch and others don't is that it will simply treat sites along one branch as "inactive" and disable their compare edges BUT NOT disable their drive edges for any labels being burst.
I.e. sites that are not supposed to see a test pattern along one branch will still see those patterns, albeit without failing. Depending on the device IP being tested, this could cause unexpected effects, such as writing a passcode to a device that failed a test, or running stresses on a device that already received them, etc.
This has been highlighted by Advantest in Application Paper-ID 343852 which has the following excerpts:
Waiting sites (also referred to as inactive sites) receive the same data as the sites currently tested. This may change their initial status. If following tests require certain conditions, the sites may need to be re-initialized.
All sites, waiting (inactive) and currently tested (active), are enabled sites and by default receive the same setup command and execute the same sequencer program. The only difference between those is, that the waiting sites are in a connected and masked state (enabled but not active, TDC Topic 42577). A site of this state receives the same vectors as all other sites. The results, however, are ignored (receivers are masked).
How should we handle this in Origen?
At minimum we should alert the user if they are using SMT7 and attempt to make a pass/flag branch or if/then branch.
In OrigenTesters, the pass/fail branch is used when execution of a test is based on the result of a previous test (Execution Based on a Previous Test), e.g. if_ran / unless ran, if_failed / unless_passed, if_passed / unless_failed.
The if/then occurs if the execution of a test is based on the runtime environment (Execution Based on the Runtime Environment), e..g if_enable, unless enable, if_job, unless_job, though it isn't a big issue since typically all sites see the same user variable in this SMT7 implementation (unless the user modifies it dynamically).
The if/then also can occur if the execution of a test is based on relational expressions (Execution Based on Relational Expressions), e.g. whenever, whenever_all, whenever_any, eq, ne, gt, ge, lt, le. This is more risky since these expressions could be different by site depending on the use case.
Not sure if everyone is aware of this or not- but there appears to be a major bug in the way that SmarTest 7 handles flow branching.
When a branch is encountered in a test flow, whether it's a pass/fail branch or an if/then branch, the way that SMT7 handles it if some sites follow the branch and others don't is that it will simply treat sites along one branch as "inactive" and disable their compare edges BUT NOT disable their drive edges for any labels being burst.
I.e. sites that are not supposed to see a test pattern along one branch will still see those patterns, albeit without failing. Depending on the device IP being tested, this could cause unexpected effects, such as writing a passcode to a device that failed a test, or running stresses on a device that already received them, etc.
This has been highlighted by Advantest in Application Paper-ID 343852 which has the following excerpts:
How should we handle this in Origen?
At minimum we should alert the user if they are using SMT7 and attempt to make a pass/flag branch or if/then branch.
In OrigenTesters, the pass/fail branch is used when execution of a test is based on the result of a previous test (Execution Based on a Previous Test), e.g.
if_ran / unless ran,if_failed / unless_passed,if_passed / unless_failed.The if/then occurs if the execution of a test is based on the runtime environment (Execution Based on the Runtime Environment), e..g
if_enable, unless enable, if_job, unless_job, though it isn't a big issue since typically all sites see the same user variable in this SMT7 implementation (unless the user modifies it dynamically).The if/then also can occur if the execution of a test is based on relational expressions (Execution Based on Relational Expressions), e.g.
whenever, whenever_all, whenever_any, eq, ne, gt, ge, lt, le. This is more risky since these expressions could be different by site depending on the use case.