Use Models for Extending IEEE 1687 to Analog Test
2 likes267 views
The document outlines how IEEE 1687 can be extended to accommodate analog and mixed-signal chip testing, addressing the need for standardized methods and automation in analog tests. It presents four use cases, discusses extensions to the PDL and ICL languages, and proposes improvements in the EDA ecosystem. The document concludes with recommendations for enhancing analog testing practices and the establishment of an IEEE study group for further development.
![New ICL Statements
Keyword Description ICL Statement
Primitives to express analog
connectivity
Wire { properties } [new for ICL]
SPICE/RTL model parameters
via ICL attributes
Attribute
ATE and DIB components in ICL
All [no changes to ICL, but
application of it outside DUT]
AccessLink for non-TAP
interfaces
AccessLink (see IEEE P1687.1)
48](https://image.slidesharecdn.com/session8-171104173927/85/Use-Models-for-Extending-IEEE-1687-to-Analog-Test-48-320.jpg)
![New ICL Statements
Keyword Description ICL Statement
Primitives to express analog
connectivity
Wire { properties } [new for ICL]
SPICE/RTL model parameters
via ICL attributes
Attribute
ATE and DIB components in ICL
All [no changes to ICL, but
application of it outside DUT]
AccessLink for non-TAP
interfaces
AccessLink (see IEEE P1687.1)
49](https://image.slidesharecdn.com/session8-171104173927/85/Use-Models-for-Extending-IEEE-1687-to-Analog-Test-49-320.jpg)
Use Models for Extending IEEE 1687 to Analog Test
- 1. Use Models for Extending IEEE 1687 to Analog Test 2017 International Test Conference Peter Sarson Jeff Rearick
- 2. Acknowledgments – in no particular order Steve Sunter Hans Martin von Staudt Salem Abdennadher Ian Harrison Mustapha Slamani Marco Spinetta Heiko Ahrens Ken Ferguson Ken Butler Paul Berndt Ronny Vanhooren Stefan Vock Vladimir Zivkovic Marc Hunter 2
- 4. Purpose • How the proposed IEEE 1687 can be extended to differing complexities of analog and mixed-signal chips. • How the proposed IEEE 1687 can be extended across the ecosystem of the full chip process to also include ATE. • What implications these use models have on the 1687 PDL and ICL languages. - New commands 4
- 5. Outline • Show 4 use cases of analog 1687 with examples • Describe 11 extensions/additions to PDL to form (A)PDL • Describe extensions to ICL language to extend capabilities to ATE, including the associated PDL • Future EDA ecosystem 5
- 6. Outline • Show 4 use cases of analog 1687 with examples • Describe 9 extensions/additions to PDL to form (A)PDL • Describe extensions to ICL language to extend capabilities to ATE, including the associated PDL • Future EDA ecosystem 6
- 7. Introduction • Todays IEEE 1687 is • Aimed at digital circuitry – builds upon 1500 to access onboard instruments via SCAN registers 7
- 8. Introduction • Todays IEEE 1687 is • Aimed at digital circuitry – builds upon 1500 to access onboard instruments via SCAN registers • Mainly digital but does not exclude analog 8
- 9. Introduction • Todays IEEE 1687 is • Aimed at digital circuitry – builds upon 1500 to access onboard instruments via SCAN registers • Mainly digital but does not exclude analog • Analog Test has been a longstanding problem in the industry • No standardization, no EDA automation • No linkage from Design to ATE • Pretty much a fully manual process 9
- 10. Introduction • There is a clear need for improving the development and bring up for analog tests. • A structured method, which facilitates pattern re-use would be beneficial • Keeping the knowledge of the test IP in a generic language such as PDL. Thus maintaining the same test setup between test platforms 10
- 11. Introduction • There is a clear need for improving the development and bring up for analog tests. • A structured method, which facilitates pattern re-use would be beneficial • Keeping the knowledge of the test IP in a generic language such as PDL. Thus maintaining the same test setup between test platforms 11
- 12. Introduction • There is a clear need for improving the development and bring up for analog tests. • A structured method, which facilitates pattern re-use would be beneficial • Keeping the knowledge of the test IP in a generic language such as PDL. Thus maintaining the same test setup between test platforms 12
- 13. Analog/Mixed Signal Use Model Overview • I will now present 4 use models based on the ecosystem of how tests are applied to Analog Mixed Signal Devices 13
- 14. Use Model 1 - Classical Tester (ATE & DIB) Device stimulate measure 14
- 15. Use Model 1 - Classical 15
- 16. Use Model 1 - Classical • All though a power converter would not be the 1st thought for a 1687 application. • Description of ATE instrument in ICL and PDL would allow • Programming of ATE instruments with standardized code that could be leveraged for device IP blocks and easily ported between design • Produce a go to standard for analog test writing in PDL 16
- 17. Use Model 1 - Classical • All though a power converter would not be the 1st thought for a 1687 application. • Description of ATE instrument in ICL and PDL would allow • Programming of ATE instruments with standardized code that could be leveraged for device IP blocks and easily ported between design • Produce a go to standard for analog test writing in PDL 17
- 18. Use Model 1 - Classical • No design information of ATE instruments needed. • Simply provide the ports and register information necessary for a test to utilize them using ICL. • Implementation by either test writer or retargeting tool 18
- 19. Use Model 2 - DUT has some instruments Tester (ATE & DIB) Device stimulate Measure (ADC) Digital 19
- 20. Use Model 2 - DUT has some instruments • Mixed-signal chips may contain on-chip arbitrary waveform generators, DACs • Analog circuits may be connected to on-chip measurement instruments e.g. comparators, ADCs, time counters • All with a digital interface either to program or readout the result 20
- 21. Use Model 2 - DUT has some instruments • Both examples need Analog ATE, to either Stimulate or Measure 21
- 22. Use Model 2 - Examples 22
- 23. Use Model 2 - Examples 23
- 24. Use Model 2 - Examples 24
- 25. Use Model 2 - Examples 25
- 26. Use Model 2 • This model has more independence from the specific ATE due to more digital capability. • But still requires analog signals. • As in the Use Model 1, it would be highly desirable for the ATE to provide procedures for typical ATE source/measure statements • i.e. ICL connection description and PDL test code for instrument operation 26
- 27. Use Model 2 • This model has more independence from the specific ATE due to more digital capability. • But still requires analog signals. • As in the Use Model 1, it would be highly desirable for the ATE to provide procedures for typical ATE source/measure statements • i.e. ICL connection description and PDL test code for instrument operation 27
- 28. Use Model 2 • This model has more independence from the specific ATE due to more digital capability. • But still requires analog signals. • As in the Use Model 1, it would be highly desirable for the ATE to provide procedures for typical ATE source/measure statements • i.e. ICL connection description and PDL test code for instrument operation 28
- 29. Use Model 3 - Stimulus & Response are digital Tester (ATE & DIB) Digital Device Measure (ADC) Stimulate (DAC) Digital 29
- 30. Use Model 3 - Example 30
- 31. Use Model 3 - Example • One digital input and one digital output but huge amount of analog circuitry in between. • PLLs have measurement instruments that produce digital outputs • These are perfectly suited for use with IEEE 1687. • This ATE use model is purely digital and the tests can be written in a portable (tester-independent) manner using PDL. 31
- 32. Use Model 3 - Example • One digital input and one digital output but huge amount of analog circuitry in between. • PLLs have measurement instruments that produce digital outputs • These are perfectly suited for use with IEEE 1687. • This ATE use model is purely digital and the tests can be written in a portable (tester-independent) manner using PDL. 32
- 33. Use Model 4 – Model 3 with Intelligence Tester (ATE & DIB) Digital Device Measure (ADC) Stimulate (DAC) Digital uP 33
- 34. Use Model 4 – Model 3 with Intelligence • Having a BIST onboard could allow • Reduced test data volume and associated test time when BIST is employed • Other tests may be performed concurrently while the analog self-test is underway • ATE can be less complex and therefore significantly cheaper 34
- 35. Use Model 4 – Model 3 with Intelligence • Having a BIST onboard could allow • Reduced test data volume and associated test time when BIST is employed • Other tests may be performed concurrently while the analog self-test is underway • ATE can be less complex and therefore significantly cheaper 35
- 36. Outline • Show 4 use cases of analog 1687 with examples • Describe 9 extensions/additions to PDL to form (A)PDL • Describe extensions to ICL language to extend capabilities to ATE, including the associated PDL • Future EDA ecosystem 36
- 37. New PDL Commands - iForce • iForce instead of iWrite • With addition arguments, "iForce I_in 10 mA" or "iForce ADC_in 1.2 V 1.0e3 Hz" would cover DC current stimulus and AC voltage stimulus, respectively. 37
- 38. New PDL Commands - iForce • iForce instead of iWrite • With addition arguments, "iForce I_in 10 mA" or "iForce ADC_in 1.2 V 1.0e3 Hz" would cover DC current stimulus and AC voltage stimulus, respectively. 38
- 39. New PDL Commands - iForce • iForce instead of iWrite • With addition arguments, "iForce I_in 10 mA" or "iForce ADC_in 1.2 V 1.0e3 Hz" would cover DC current stimulus and AC voltage stimulus, respectively. 39
- 40. New PDL Commands - iMeasure • iMeasure instead of iRead • "iMeasure DAC_out 1V 1kHz" would cover DC current response and AC voltage response, respectively. • With an expected range to give a pass/fail result 40
- 41. New PDL Commands - iMeasure • iMeasure instead of iRead • "iMeasure DAC_out 1V 1kHz" would cover DC current response and AC voltage response, respectively. • With an expected range to give a pass/fail result 41
- 42. New PDL Commands - iMeasure • iMeasure instead of iRead • "iMeasure DAC_out 1V 1kHz" would cover DC current response and AC voltage response, respectively. • With an expected range to give a pass/fail result 42
- 43. New PDL Commands – Real Number & Units • PDL has no concept of analog values, for (A)PDL • iForce & iMeasure commands need to contain two parts :- • a numerical portion • unit of measurement • i.e. 10 mV as in standard within ATE equipment 43
- 44. New PDL Commands – iStream • iStream should be implemented for fast and efficient simultaneous access to DAC’s and ADC • Defined by Steve Sunter, J.F. Cote and Jeff Rearick, ITC 2015 44
- 45. New PDL Commands – iSample • iRunLoop and iApply are ok for coarse – e.g. wait times in ATE run time code • For accurate pattern synchronized timing a new command is needed :- • iSample should be included • This would sample a number of clocks as would be done in an ATE digital pattern. 45
- 46. New PDL Commands Keyword Description New PDL Command Keyword to specify Stimulus iForce Keyword to specify Response iMeasure Keyword for DAC/ADC wrappers iStream Keyword for precise wait time iSample 46
- 47. Outline • Show 4 use cases of analog 1687 with examples • Describe 9 extensions/additions to PDL to form (A)PDL • Describe extensions to ICL language to extend capabilities to ATE, including the associated PDL • Future EDA ecosystem 47
- 48. New ICL Statements Keyword Description ICL Statement Primitives to express analog connectivity Wire { properties } [new for ICL] SPICE/RTL model parameters via ICL attributes Attribute ATE and DIB components in ICL All [no changes to ICL, but application of it outside DUT] AccessLink for non-TAP interfaces AccessLink (see IEEE P1687.1) 48
- 49. New ICL Statements Keyword Description ICL Statement Primitives to express analog connectivity Wire { properties } [new for ICL] SPICE/RTL model parameters via ICL attributes Attribute ATE and DIB components in ICL All [no changes to ICL, but application of it outside DUT] AccessLink for non-TAP interfaces AccessLink (see IEEE P1687.1) 49
- 50. ATE Extensions • ATE user documentation to include ICL • iProc is a procedural call that executes a specific task on IP • To enable 1687 on ATE • Creation of iProc library for ATE instrumentation • Having the combination of ICL and PDL of an ATE instrument will allow retargeting software to map instrument actions to the correct physical resources. 50
- 51. ATE Extensions • ATE user documentation to include ICL • iProc is a procedural call that executes a specific task on IP • To enable 1687 on ATE • Creation of iProc library for ATE instrumentation • Having the combination of ICL and PDL of an ATE instrument will allow retargeting software to map instrument actions to the correct physical resources. 51
- 52. ATE Extensions • ATE user documentation to include ICL • iProc is a procedural call that executes a specific task on IP • To enable 1687 on ATE • Creation of iProc library for ATE instrumentation • Having the combination of ICL and PDL of an ATE instrument will allow retargeting software to map instrument actions to the correct physical resources. 52
- 53. Outline • Show 4 use cases of analog 1687 with examples • Describe 9 extensions/additions to PDL to form (A)PDL • Describe extensions to ICL language to extend capabilities to ATE, including the associated PDL • Future EDA ecosystem 53
- 54. New Ecosystem • Envisaged Ecosystem • Analog DFT insertion tool • Retargeting Tool • Output to either simulator or ATE IPn Design Data IP2 Design Data IP1 Design Data Analog DFT IPn PDL IP2 PDL IP1 PDLSOC Design Data Analog DFT insertion directives Insertion Tool IPn ICL IP2 ICL IP1 ICL SOC ICL Retargeting Tool SOC test Formatting directives Simulator ATE 54
- 55. New Ecosystem • Envisaged Ecosystem • Analog DFT insertion tool • Retargeting Tool • Output to either simulator or ATE IPn Design Data IP2 Design Data IP1 Design Data Analog DFT IPn PDL IP2 PDL IP1 PDLSOC Design Data Analog DFT insertion directives Insertion Tool IPn ICL IP2 ICL IP1 ICL SOC ICL Retargeting Tool SOC test Formatting directives Simulator ATE 55
- 57. IEEE Study Group • IEEE Study Group for Analog Test Access and Coverage was established in July 2017 • If you would like to participate please email me at peter.sarson@ams.com for an invitation. • Goal is to complete 2 Project Authorization Requests to become 2 Working Groups by Q1 2018, • Analog Test Access • Analog Fault Modeling 57
- 58. Conclusion • 4 use models have identified specific interactions between ATE and AMS circuits. - Shows that 1687 can serve as structured approach to Analog DFT • 18 recommendations for the improvement of the ICL and PDL • Recommendations for new practices of ATE providers and instrument designers 58
- 60. Thank You • Please ask Jeff 60
Editor's Notes
- #2: This presentation uses 4 generic models from Analog Mixed signal devices to build upon 1687 infrastructure to encompass analog Industrial Group formed out of ETS2 2014 apart of European Test Symposium A note – Jeff Actually wrote the paper not me, he made me 1st author so he didn’t have to present
- #3: As the industrial working group grew, so did the members of the group. In no particular order other than how I've dropped them at random on the slide are the people and the companies they represent that were actively working towards extending 1687 to analog test.
- #4: Just as a pre text – In todays analog world, we have multiple different entities that have no connection between them. IP designed by several different companies where even the digital may not be common to both. Analog semiconductor companies complain that EDA need to do more to automate the whole design flow of analog IC’s but EDA say we can only automate something that is the same throughout the industry. Stevie sunter loves to say this has been an issue since before I went to high school with no major steps forward to address the problem. From what I have observed myself is that a certain level of egotism has got in the way as all analog designers know best – right ! So with all of this how is any form of automation even supposed to get through to the ATE side of things?
- #5: Extend 1687 from digital to analog Extend the boundary from the chip level to the ATE level Propose new PDL and ICL commands
- #10: No way you could move an analog mixed signal test program between different tester platforms easily Completely new coding required with different software
- #11: And
- #12: And
- #13: And
- #15: This is the classical model for an analog test You have the ATE that stimulates the device with analog signals – Force voltage – Measure current etc And we measure voltage or current etc Using this as the simplest form of a analog mixed signal device has many advantages as no assumptions can be made What is common here with 1687? There are no instruments within the chip – right? But if the periphery of the ecosystem is moved from the device level to the encompass the tester then we have what could be seen as a analog mixed 1687 framework So if it was possible to address and speak to ATE test instruments in a generic language such as ICL and PDL then we have moved the boarder of the EDA/Device to encompass ATE.
- #17: Extend the boundary of 1687 to the ATE so that an ATE instrument can be described and programmed in PDL
- #19: The ATE provider doesn’t have to supply any secrets about how their wonderful instruments are made. They just need to have a 1687 wrapper applied in the instrument driver and an digital access port that all testers have so that the ICL can address the instrument. Once this is available, A test writer can then start to implement code in generic PDL so that tests are independent of the tester and are now specific to the IP the code is meant to test. On a higher level one can imagine and automated tool dumping out code for a specific IP block for different testers.
- #20: ADC is an instrument Can be used to measure on chip biases and voltages rather than having to use a tester resource Data returned from the ADC via the same digital connection used for the communication of the tester instruments as model 1
- #23: Here the 14 bit ADC could be used to measure the LDO or the biasing circuits aswell as the current source on LED and VD4 rather than bringing the signal off chip
- #24: Here the 14 bit ADC could be used to measure the LDO or the biasing circuits aswell as the current source on LED and VD4 rather than bringing the signal off chip
- #25: Here the 14 bit ADC could be used to measure the LDO or the biasing circuits aswell as the current source on LED and VD4 rather than bringing the signal off chip
- #26: Here the 14 bit ADC could be used to measure the LDO or the biasing circuits aswell as the current source on LED and VD4 rather than bringing the signal off chip
- #30: In model 3 we have the situation where is could be possible to have an all digital Analog test depending on the sophistication of the analog IP. There maybe the case that the ADC or DAC needs some form of calibration but once any calibration is done then the whole circuitry could be tested using only internal instruments of the device.
- #33: Enough said.
- #36: Basically a purely digital tester being used primarily to check if the device has passed an onchip test program.
- #37: Ok so these examples are great but how do we actually make it work with what exists today. As 1687 is geared towards digital, the common commands don’t lend themselves greatly towards analog and hence we would need to make some ammendements.
- #38: iWrite is used to write data to an digital IP, the analog version of this would be iForce as we force current and voltage with a floating point number. Thus we suggest iforce for the analog 1687 but with an additional sampling variable such that AC and DC can be accounted for in the same code. If a DC value was needed we would just state 0Hz.
- #39: iWrite is used to write data to an digital IP, the analog version of this would be iForce as we force current and voltage However, iWrite can only use hex numbers and we would need a floating point number for analog. Thus we suggest iforce for the analog 1687 but with an additional sampling variable such that AC and DC can be accounted for in the same code. If a DC value was needed we would just state 0Hz.
- #40: iWrite is used to write data to an digital IP, the analog version of this would be iForce as we force current and voltage. Thus we suggest iforce for the analog 1687 but with an additional sampling variable such that AC and DC can be accounted for in the same code. If a DC value was needed we would just state 0Hz.
- #41: Similarly the analog version of iRead would be iMeasure again with the AC variable available, however in this case the sampling variable can used for two instances, one to measure the AC characteristic so it can be post processed at ATE for fourier analysis and the like. Or it can be used for averaging a DC value as we do so very often. However, one extra extension we suggest is to have a positive and negative limit such that a pass fail result can be returned hence making the test much quicker than returning a full array of data.
- #42: Similarly the analog version of iRead would be iMeasure again with the AC variable available, however in this case the sampling variable can used for two instances, one to measure the AC characteristic so it can be post processed at ATE for fourier analysis and the like. Or it can be used for averaging a DC value as we do so very often. However, one extra extension we suggest is to have a positive and negative limit such that a pass fail result can be returned hence making the test much quicker than returning a full array of data.
- #43: Similarly the analog version of iRead would be iMeasure again with the AC variable available, however in this case the sampling variable can used for two instances, one to measure the AC characteristic so it can be post processed at ATE for fourier analysis and the like. Or it can be used for averaging a DC value as we do so very often. However, one extra extension we suggest is to have a positive and negative limit such that a pass fail result can be returned hence making the test much quicker than returning a full array of data.
- #44: PDL has no concept of analog values therefore we need to be able to incorporate scientific notation such as miilivolts, milli amps etc and floating point numbers.
- #46: If you know ATE, there are 2 ways to program a wait time, one is a simple wait(5ms) as you would write in the run time code, however, usually this is not precise and can change depending on the load of the workstation at anyone time, in PDL this would be the equivalent of irunloop and iapply. For accurate time precison such as we get from using a digital pattern we suggest the command iSample, this would count clocks in the similar way the digital pattern does on ATE but using TCLK, SCLK or something similar within a design.
- #49: For ICL we would need a wire which would define a analog connection such as an analog bus or Attribute that would tag a certain wire to different sections of the circuitry, such as ATB1, 2, 3 etc All ICL statements need to be updated such that they can be referenced to outside of the DUT so as the boundary of the chip is extended to the ATE MOST IMPORTANTLY – the non-TAP interfaces need to be included from the 1687.1 standard so that analog devices that only have spi and i2C can benefit from this standard, without this, this standard will not fly
- #50: For ICL we would need a wire which would define a analog connection such as an analog bus or Attribute that would tag a certain wire to different sections of the circuitry, such as ATB1, 2, 3 etc All ICL statements need to be updated such that they can be referenced to outside of the DUT so as the boundary of the chip is extended to the ATE MOST IMPORTANTLY – the non-TAP interfaces need to be included from the 1687.1 standard so that analog devices that only have spi and i2C can benefit from this standard, without this, this standard will not fly