This article was published in the above mentioned Springer issue.
`The material, including all portions thereof, is protected by copyright;
`all rights are held exclusively by Springer Science + Business Media.
`The material is for personal use only;
`commercial use is not permitted.
`Unauthorized reproduction, transfer and/or use
`may be a violation of criminal as well as civil law.
`
`ISSN 0923-8174, Volume 25, Number 6
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 1 of 9
`
`

`

`J Electron Test (2009) 25:301–308
`DOI 10.1007/s10836-009-5118-2
`
`Utilizing On-chip Resources for Testing Embedded
`Mixed-signal Cores
`Carsten Wegener · Heinz Mattes · Stephane Kirmser ·
`Frank Demmerle · Sebastian Sattler
`
`Received: 11 September 2008 / Accepted: 6 October 2009 / Published online: 9 December 2009
`© Springer Science + Business Media, LLC 2009
`
`1 Introduction
`
`The main driver for developing SoCs is to control the
`cost of a system. SoCs are typically implemented by
`combining and scaling the performance of pre-designed
`circuit blocks to suit a particular application at the
`lowest cost. This approach leads to a rapid introduction
`of successive generations of SoCs with higher perfor-
`mance and more analog/digital functionality.
`The typical business characteristics of SoC develop-
`ment environments are [3]:
`
`– Rapid product innovations;
`– Unpredictable market developments;
`–
`Shrinking product life cycles; and
`– Unrelenting cost pressures.
`
`One of the significant challenges faced by the semicon-
`ductor manufacturer in regard to mixed-signal devices
`is the continuous pressure to reduce manufacturing
`costs because of a constant decrease in the average
`selling price of devices [4].
`The first conclusion from the business characteristics
`in the SoC market is that Intellectual Property (IP)
`blocks and modules need to be developed together with
`a module-specific test interface. Keeping the same test
`access mechanism for the module enables the re-use of
`the IP blocks on multiple SoCs while keeping the test
`development costs at a minimum [8].
`For high-volume products, however, the per-device
`test cost is a major concern as it eats directly into
`profit margins that are already tight [6]. Per-device
`test times can be reduced by multi-site testing, i.e. in-
`terfacing multiple Devices Under Test (DUTs) to the
`Automatic Test Equipment (ATE) at the same time.
`This approach works well for testing digital circuits for
`
`Abstract For mixed-signal cores on System-on-a-Chip
`(SoC) platforms, the current methodology in test devel-
`opment is to use special test modes for block isolation
`such that mixed-signal cores are accessible from the
`chip boundary through a well-defined interface. Since
`the access mechanism to the core is preserved, this
`method facilitates fast test development when the core
`is re-used on another SoC. In order to obtain the short-
`est per-device test times on low-cost test platforms,
`we explore the option of operating the SoC in its
`designed functional mode where all on-chip resources
`are fully available for test support. We demonstrate
`this new method for a microcontroller with embedded
`ADCs. For high-volume products, the ultimate target
`is to minimize test costs by maximizing the efficiency
`of testing multiple devices in parallel on one tester.
`We demonstrate two benefits of testing in a functional
`mode that increases parallel test efficiency: (1) Simulta-
`neous testing of multiple on-chip cores, and (2) On-chip
`post-processing to reduce the amount of test data.
`
`Keywords Mixed-signal test · Embedded system test ·
`SoC test
`
`B)
`
`Responsible Editor: C. Metra
`· H. Mattes · S. Kirmser · F. Demmerle
`C. Wegener (
`Infineon Technologies AG, 85579 Neubiberg, Germany
`e-mail: Carsten.Wegener@infineon.com,
`carsten_wegener@email.com
`
`S. Sattler
`Universität Erlangen-Nümberg, Lehrstuhl für Zuverlässige
`Schaltungen und Systeme, Paul-Gordan-Str. 5,
`91052 Erlangen, Germany
`e-mail: sattler@lzs.eei.uni-erlangen.de
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 2 of 9
`
`

`

`302
`
`J Electron Test (2009) 25:301–308
`
`which the parallel efficiency is typically above 95% [9].
`Parallel efficiency is defined in [5] as
`
`e = 1 − (ts − t1)/(s − 1)
`
`(1)
`
`t1
`where s denotes the number of sites tested in parallel,
`t1 and ts denote the test times for testing one or s sites,
`respectively. 95% efficiency implies that the test time
`for testing two devices in parallel is only 5% more than
`the test time required for a device tested at a single site.
`For mixed-signal devices, such as Analog-to-Digital
`Converters (ADCs), parallel efficiency is often signif-
`icantly lower than for purely digital devices because
`the stimulus generation and data post-processing is
`performed on a per-site basis. For SoCs, however,
`we can exploit on-chip resources for test support [1],
`thus reducing the ATE’s task to controlling the test
`sequence only, rather than also dealing with the details
`of carrying out the tests in that sequence [7].
`In this document, we present an example of this
`methodology for ADC modules embedded on a micro-
`controller SoC. The target is to reduce per-device test
`times at the expense of test development time. Addi-
`tional investment in test development is, of course, only
`viable for high-volume products that are established on
`the market.
`In Section 2, our SoC product is briefly described.
`The advantages and drawbacks of testing the on-chip
`modules in isolation are highlighted. In Section 3,
`the available on-chip resources are described and it
`is shown how they can be used for test support. In
`Section 4, the test implementation and resulting test
`times are summarized. In Section 5, the conclusions are
`drawn.
`
`2 State-of-the-Art Mixed-Signal SoC Testing
`
`2.1 System-on-a-Chip Example
`
`A simplified block diagram of our SoC is shown in
`Fig. 1. All modules communicate via a shared bus struc-
`ture. For example, the Central Processing Unit (CPU)
`requests a signal conversion from the module ADCa.
`Consequently, the analog voltage at the chip boundary
`is sensed and converted to a digital representation that
`can subsequently be read by the CPU.
`External components can communicate digitally
`with the SoC via the serial JTAG interface [10] and
`the general-purpose 16-pin parallel digital ports labeled
`“PORTa” through “PORTx”. For on-chip data storage,
`the Static Random Access Memory (SRAM) module
`provides a total of 240 kBytes of memory. The Direct
`
`CPU
`
`SRAM
`
`DMA
`
`ADCb
`
`JTAG
`
`ADCa
`
`PORT x
`
`PORT a
`
`Fig. 1 Block diagram of example SoC
`
`Memory Access (DMA) controller module provides a
`dedicated data transport engine that operates indepen-
`dently of the CPU.
`For example, the ADC module can be configured to
`generate a DMA request at the end of each conversion.
`The requested DMA transport can move the ADC
`conversion result to the SRAM module. Thus, at the
`end of multiple conversions, the results are stored on-
`chip and the CPU can post-process these results.
`
`2.2 Mixed-signal Test in Block Isolation
`
`The basic setup for testing an ADC module in isolation
`is shown in Fig. 2. The test procedures is:
`
`1. Activate the test mode “module isolation” via the
`standardized JTAG interface according to IEEE
`Std. 1149.1 [10],
`2. Provide the analog stimulus with an Arbitrary
`Waveform Generator (AWG), e.g. a voltage ramp
`rising over time, and
`
`JTAG
`
`ADCa
`
`AWG
`
`SoC ín test mode
`
`PORTa
`
`V
`in
`
`t
`
`Automatic Test Equipment (ATE)
`
`Fig. 2 Test setup for ADC test in block isolation with analog
`stimulus generated by Arbitrary Waveform Generator (AWG)
`and digital stimuli generated by ATE
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 3 of 9
`
`

`

`J Electron Test (2009) 25:301–308
`
`303
`
`3. Trigger the ADC repeatedly in order to convert
`the analog stimulus to a digital representation that
`becomes available at the chip boundary through the
`digital port a.
`
`The attractions of testing a module in isolation are that:
`
`– The module can be tested with standard test vectors
`independent of which SoC the module is imple-
`mented on;
`– Other modules on the same SoC are disabled and
`thus these modules do not interfere with the opera-
`tion and performance of the module under test.
`
`Both of these features reduce test development time
`when the module is re-used for a new SoC project. The
`limitations imposed by testing a module in isolation are
`that:
`
`– The influence of other modules on the performance
`of the module under test is not testable;
`– The test equipment needs to match the module
`interface requirements;
`– The module design is more complex as it needs
`to accommodate certain (timing) restrictions and
`(routing) overheads imposed by the test mode re-
`quirements;
`– The module test does not cover the normal data
`path used in the SoC application;
`– The module test times may be increased due to
`additional data protocols of the test interface,
`e.g. when using a standardized serial interface of
`an IEEE Std. 1500 [11] compliant test wrapper as
`suggested in [12].
`
`2.3 Test Economics for High-volume Products
`
`For high-volume SoCs, it is important to develop a
`working test solution quickly and then to reduce the
`test time per device during product ramp up.
`Multi-site testing is the main method to reduce test
`time per device. However, for modules that are tested
`in isolation, the tester needs to interface to all devices in
`parallel and capture the output data. When large data
`volumes are post-processed by the tester, the parallel
`efficiency degrades since the processing is carried out
`site-serially.
`The parallel efficiency of a test is defined in (1).
`Ideally, parallel efficiency is 100%. For digital tests that
`only run a test pattern and evaluate the digital response
`for making a pass/fail decision, parallel efficiencies of
`98% are achievable [9]. For the ADC test in module-
`isolation mode, we have determined parallel efficiency
`to be 83%.
`
`Concurrent testing of on-chip modules is another
`way to reduce test time. However, test modes that are
`designed for concurrent testing of multiple indepen-
`dent modules require simultaneous access to all module
`interfaces from the chip boundary. The straightforward
`implementation of such an access mechanism often
`finds limited acceptance because of the high routing
`effort for the chip design, and the high number of pins
`needed at the chip boundary. As a result, in isolation
`mode, the tester usually interfaces only one module per
`device at a time.
`For the example SoC shown in Fig. 1, the two ADC
`modules can perform conversions in parallel. However,
`for the available implementation of the “module isola-
`tion” test mode, only one ADC interface at a time can
`be accessed from the chip boundary; the other ADC
`module is disabled since both modules share the same
`external pins in their test modes.
`The target of our work is to increase the efficiency
`of multi-site testing by exploiting on-chip processing re-
`sources and by running the data acquisition for multiple
`ADC modules in parallel. For this purpose, the module
`isolation test mode cannot be used. By using the SoC in
`its designed functional mode, however, we can achieve
`this target and can exploit all the flexibility that a
`general microcontroller offers in terms of configuring
`its modules and data paths for internal and external
`communications.
`
`3 Exploiting On-chip Processor During Test
`
`We recommend operating the SoC in its functional
`mode such that both ADCs can operate in parallel
`and their conversion results can be stored in on-chip
`memories. Besides performing data conversions in par-
`allel, this operation scheme overcomes a limitation of
`the tester platform that we use; the data acquisition is
`limited to 2816 capture records of the digital pins due
`to lack of sufficient capture memory.
`Due to this restriction on the capture memory size,
`the complete acquisition of 10,240 conversion results
`per ADC module is carried out in multiple acquisition
`cycles when testing in module isolation mode. At the
`end of each acquisition cycle, a chunk of 2816 ADC
`output data is moved from the tester’s capture memory
`to the tester’s workstation for further post-processing.
`This also complicates the analog signal generation since
`the AWG in Fig. 2 needs to stop updating its output
`voltage during the data transport.
`This requirement for intermittent clearing of the
`capture memory prevents us from using this setup for
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 4 of 9
`
`

`

`304
`
`J Electron Test (2009) 25:301–308
`
`dynamic testing of the ADC. Testing an ADC dynami-
`cally requires us to produce a high-frequency sinewave
`(instead of the quasi-static ramp/staircase) input for
`the ADC. Pausing the sinewave generation while the
`tester clears its capture memory introduces unwanted
`distortions in the ADC results, which are negligible for
`quasi-static ADC input waveforms such as the ramp-
`input shown in Fig. 2.
`With on-chip storage of the conversion results, the
`analog signal generation can be continuous, and more-
`over, the CPU on the SoC can be exploited for post-
`processing the conversion data. This improves the
`parallel efficiency of the test in a multi-site test scenario
`because test interruptions are avoided, and the results
`of post-processing can include less test data than the
`raw ADC conversion results. For a production test,
`only the result of the post-processing needs to be cap-
`tured and evaluated by the tester with respect to the
`test limits.
`
`3.1 Configuration of On-chip Resources
`
`For the module-isolation mode, the digital interface of
`the module is available at the chip boundary as defined
`by the design of the test mode. For the functional mode,
`however, on-chip resources such as the DMA and the
`interrupt system can be used to control the data flow.
`Thus, using the functional mode provides flexibility for
`test development that allows us to optimize the test
`application and thereby to minimize the cost of testing,
`even after the SoC design is finalized.
`The configuration of the on-chip resources can be
`performed under control of the internal CPU or the
`external ATE through the JTAG test interface. The
`module configuration and the associated state flow dia-
`gram that we use is shown in Fig. 3.
`We use the JTAG interface in order to configure the
`on-chip modules; in particular, the CPU is disabled in
`
`order to avoid bus access and interrupt conflicts during
`data acquisition. In our configuration, the ADC module
`is triggered with a START signal received at a digital
`port—a feature that is also available to the user of the
`SoC. After the analog signal is converted, the End-Of-
`Conversion (EOC) signal requests the DMA to trans-
`port the ADC output data to a memory location. The
`memory address pointer in the DMA module is incre-
`mented after the transport operation is complete, thus
`filling a designated memory segment with consecutive
`ADC conversion results.
`Provided that there is sufficient on-chip memory,
`all acquired output data of the ADC can be stored.
`Moreover, the second ADC on the SoC can be similarly
`configured, using an alternative trigger input pin and a
`separate SRAM segment for data storage. With suffi-
`cient time lag between the two trigger signals for the
`ADC modules (in order to avoid bus-conflicts between
`the two DMA engines), both ADC modules can con-
`vert their analog inputs in parallel. This is possible in
`our case because a DMA transfer takes 15 clock cycles,
`while an ADC conversion requires more than 30 clock
`cycles.
`
`3.2 Data Processing and Test Response Compaction
`
`After all data is acquired, the device under test is
`reconfigured to start the CPU and post-process the
`data stored in memory. The results of processing the
`ADCa/b data are stored at particular memory segments
`labeled SRAMa/b, respectively, in Fig. 4. For prod-
`ucts with less memory resources than our microcon-
`troller, data processing could be performed on-the-fly
`by dedicated on-chip computation resources as sug-
`gested in [2].
`After data processing has been completed, the tester
`can read the memory locations either via the four-wire
`JTAG interface or via the 16-bit parallel ports. In the
`
`Fig. 3 Test setup (a) and flow
`diagram (b) for ADC test in
`functional mode using
`on-chip DMA for data
`transport
`
`SRAMa
`
`JTAG
`
`DMAa
`
`EOC
`
`ADCa
`
`START
`
`PORTc
`
`PORTc[0]=0
`
`EOC=0
`
`Idle
`
`Start
`ADC
`
`Wait
`EOC
`
`DMA=busy
`Increment
`SRAM Addr
`
`Transfer
`to SRAM
`
`(a)
`
`(b)
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 5 of 9
`
`

`

`J Electron Test (2009) 25:301–308
`
`Fig. 4 SoC configuration (a)
`and flow diagram (b) for
`result data readback
`
`305
`
`JTAG
`
`PORTc
`
`REQb
`
`REQa
`
`DMAb
`
`DMAa
`
`PORTc[0]=0
`
`DMA=busy
`
`SRAMb
`
`SRAMa
`
`Idle
`
`Trigger
`REQa
`
`Transfer
`from SRAMa
`
`PORTb
`
`PORTa
`
`DMA=busy
`Increment
`SRAM Addr
`
`Transfer
`to PORTa
`
`(a)
`
`(b)
`
`configuration shown in Fig. 4, the on-chip DMAa/b
`is configured to transport data from the memory seg-
`ments SRAMa/b to the parallel ports PORTa/b, re-
`spectively. Each data transport is initiated by a rising
`edge at particular pins of the digital PORTc. Again,
`this configuration is also available to the user of the
`microcontroller SoC.
`By using 16-bit-wide parallel ports, the result table
`can contain 2,816 × 2 = 5,632 bytes of data that is read
`in one capture sequence while taking into account the
`restrictions of the tester’s capture resources. By storing
`the most significant information first, the test time per
`device can be shortened by only reading the top part
`of the result table, thus, further reducing the amount of
`test data.
`shown in
`table is
`the result
`An example of
`Table 1. The top of the table contains an ASCII-
`readable1 header. The length of this header is speci-
`fied to be 320 bytes. This header contains all the test
`results needed to make a pass/fail decision. Additional
`information, such as the histogram in two-byte integer
`format, follows the header and does not need to be read
`by the test program unless a special diagnostic option
`is set.
`Note that the length of the header is customizable,
`and the software that runs on the SoC during the test
`has a version number that is entered into the test data
`
`1ASCII: American Standard Code for Information Interchange.
`
`log, thus allowing for tight version control during test
`debug.
`The original test response of an ADC contains
`10,240 samples requiring 22,480 bytes of storage. This
`amount of test data is reduced by the on-chip CPU to
`320 bytes for the result table, which can be transferred
`to the ATE more efficiently than the raw ADC samples.
`The ATE interprets the results and decides upon pass
`or fail depending on the test limits.
`
`3.3 Application to Other Products
`
`The idea of taking advantage of on-chip resources for
`test data post-processing and compaction is not limited
`to this microcontroller device with embedded ADCs.
`We believe that the concept can be generalized to
`a broad range of SoCs that combine analog/mixed-
`signal/radio-frequency modules with a Digital Sig-
`nal Processing (DSP) core. Examples are products
`
`Table 1 Definition of result table stored on-chip
`Name
`Address
`Value
`Length of header
`0
`320
`Software version
`16
`3.5
`+0.3
`Offset
`32
`Gain
`48
`1.021
`...
`Hist 0
`Hist 1
`...
`Hist 1023
`
`320
`322
`
`2366
`
`Type
`String
`String
`String
`String
`
`16-bit int
`16-bit int
`
`16-bit int
`
`150
`10
`
`180
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 6 of 9
`
`

`

`306
`
`for high-volume, low-cost applications such as DSL
`modems, wireless Bluetooth/LAN devices, and mobile
`phones [6, 8].
`
`4 Test Implementation
`
`4.1 Test Run, Program Execution and Result Capture
`
`ADC test with ramp input By running a digital pattern,
`the SoC is configured as shown in Fig. 3. An Arbitrary
`Waveform Generator (AWG) generates a ramp input
`signal to the ADC. The AWG is synchronized with the
`digital pattern generator that produces the conversion
`START signal in Fig. 3.
`The ADC performs 10,240 conversions of the ramp
`input signal averaging to 10 hits per converter output
`code for the 10-bit ADC with possible output codes
`0, 1,..., 1023. At the end of this conversion sequence,
`all samples are stored on-chip in the memory segment
`labeled as SRAMa.
`
`Program load and execution The processor program
`can be written in C. This source code is compiled and
`linked to an executable in Motorola S Record (sre)
`format using the Tasking (www.tasking.com) en-
`vironment. This executable is converted to a digital
`pattern by a proprietary in-house tool.
`By running the digital pattern, the processor pro-
`gram is loaded into the SRAM of the DUT. The SoC
`goes through a reset sequence such that the pre-loaded
`program is executed. During program execution, the
`results (as shown in Table 1) are stored in SRAMa/b,
`for the ADCa/b data records, respectively.
`
`Result capture The post-processing results are trans-
`ferred to the ATE via the 16-bit parallel ports for the
`SoC configuration shown in Fig. 4. Since the results are
`stored in ASCII-readable format, the ATE can easily
`interpret these values for the test parameters, such as
`gain and offset. Comparing these values to the test
`limits yields the pass/fail decision per module and per
`test site.
`Note that capturing the results from the DUT runs
`in parallel at all-sites; only the interpretation of the
`result table and the decision about pass or fail are ac-
`tions that must be performed site-serially by the tester
`workstation.
`
`4.2 Multi-site Test Evaluation and Efficiency
`
`Testing in module isolation test mode, a single ADC
`module is tested in t seconds. Testing the m = 2 mod-
`
`J Electron Test (2009) 25:301–308
`
`(2)
`
`= 2t seconds. Testing s = 4
`ules sequentially takes tiso
`= 3.02 ∗ t where
`1
`sites in parallel takes in total tiso
`4
`= m · t [1 + (s − 1)(1 − e)] ,
`tiso
`4
`for an efficiency of e = 0.83 as defined in (1).
`When testing in functional mode, the two ADC
`modules acquire their data in parallel and the post-
`processing is performed on-chip faster than on the
`tester. Thus, both ADC modules can be tested faster
`than a single module in isolation mode. Test time
`= 0.82 ∗ t seconds for both
`measurements yield tfunctional
`1
`ADCs on a single site. By comparison, in module isola-
`tion mode this test would require 2t seconds.
`The parallel efficiency of this test in functional mode
`=
`is 96%, and thus, a quad-site test takes tfunctional
`0.92 ∗ t, which is only marginally longer than the single-
`4
`site test in functional mode. Therefore, by testing in
`functional mode instead of isolation mode, the total test
`time for the ADC tests on four SoCs is reduced by a
`= 3.02/0.92 = 3.28.
`factor of tiso
`/tfunctional
`4
`4
`
`5 Conclusion
`
`In this work we have explored the opportunities to
`reduce test times for mixed-signal cores on high-volume
`SoC products. These opportunities arise from substan-
`tial on-chip processing capabilities available for test
`support. The original test implementation that used
`a specifically designed “module isolation” test mode
`served as a starting point for our approach to testing
`the ADC modules on the SoC.
`We successfully reduced per-chip test times by op-
`erating the SoC in its functional mode while testing
`the embedded ADC modules. In functional mode, both
`on-chip ADC modules can run their data acquisition
`simultaneously and store the output data of the ADC
`modules in on-chip memory. This simplified the gen-
`eration of the analog stimulus, and moreover, allowed
`us to use the on-chip CPU for post-processing the raw
`ADC output data. On-chip post-processing reduced
`the amount of test data that needed to be transferred
`back to the ATE, and thereby, improved the parallel
`efficiency of the ADC tests.
`We remark that the data post-processing runs truly
`in parallel when, for a quad-site test, four DUTs are
`connected to one ATE. This yields significant improve-
`ment compared to the quad-site test that uses the
`“module isolation” test mode, and therefore, that re-
`quires the ATE to post-process the acquired ADC data
`site-serially.
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 7 of 9
`
`

`

`J Electron Test (2009) 25:301–308
`
`307
`
`As a result, for the quad-site test solution we have
`shortened the test times for the two ADC modules
`by a factor of more than three by comparison to the
`“module isolation” test approach.
`
`Acknowledgments Part of this work has been funded within the
`MAYA project under label 01M3172A by the German Ministry
`of Education and Research (BMBF).
`
`Carsten has been working for Infineon Technologies on the
`development and implementation of methods for testing mixed-
`signal integrated circuits.
`He has contributed to numerous conferences, publishing pa-
`pers in areas of nonlinear oscillator dynamics and mixed-signal
`testing. In Ireland, he has taught MATLAB courses to de-
`sign and test engineers at Analog Devices B.V., and graduate
`courses on “Digital Design-for-Test” and “Mixed-signal Test and
`Testability” at the Department of Microelectronic Engineering,
`University College Cork.
`
`References
`
`1. Chakrabarty K (2005) Low-cost modular testing and test re-
`source partitioning for SOCs. IEE Proc, Comput Digit Tech
`152(3):427–441
`2. Erdogan ES, Ozev S (2007) An ADC-BiST scheme using
`sequential code analysis. In: Proc. DATE, conf. on design,
`automation and test in Europe, pp 1–6
`3. Garcia R (2003) Redefining cost of test in an SOC world.
`In: EE-Evaluation engineering. Nelson, Jonesville. http://
`archive.evaluationengineering.com/archive/articles/0603ic.
`htm
`4. Kramer R (2005) Test throughput for mixed-signal devices.
`IEEE Instrum Meas Mag 8:12–15
`5. Kramer R, Proskauer D (2005) ATE implementations
`for multisite device test.
`In: EE-Evaluation engineer-
`ing. Nelson, Jonesville. http://archive.evaluationengineering.
`com/archive/articles/0705/0705ate_implementations.asp
`6. Kundu S, Mak TM, Galivanche R (2004) Trends in manufac-
`turing test methods and their implications. In: Proc. ITC, int.
`test conf., pp 679–687
`7. Lee K-J, Chu C-Y, Hong Y-T (2005) An embedded proces-
`sor based SOC test platform. In: Proc. ISCAS, int. symp. on
`circuits and systems, pp 2983–2986
`8. Nikila K, Parekhji RA (2004) DFT for test optimisations in a
`complex mixed-signal SOC—case study on TI’s TNETD7300
`ADSL modem device. In: Proc ITC, int. test conf., pp 773–782
`9. Teradyne Inc (2007) Teradyne showcases J750Ex and Ultra-
`FLEX at SEMICON China. In: Press release, 19 March 2007
`10. Test Technology Technical Committee (2001) Standard
`test access port and boundary-scan architecture. In: IEEE
`Std. 1149.1. IEEE Computer Society, Piscataway
`11. Test Technology Technical Committee (2005) Standard for
`embedded core test (SECT). In: IEEE Std. 1500. IEEE
`Computer Society, Piscataway
`12. Zivkovic V, Schat J, Seuren G, van der Heyden F (2006) A
`generic infrastructure for testing SoC’s with mixed-signal/RF
`modules. In: Proc. IMSTW, int. mixed-signals testing work-
`shop, Edinburgh, UK, 23–26 June 2006
`
`Carsten Wegener was awarded the academic degree “Diplom
`Ingenieur” in Electronic Circuits and Systems by the Technical
`University of Dresden, Germany, in 1997. From 1996 through
`1998, he was enrolled in the lecture series for the “Vordiplom”
`in Mathematics at Humboldt-University at Berlin, Germany.
`In 1998, he moved permanently to Ireland to work with the
`Test Department of Analog Devices B.V. in Limerick, and began
`his doctoral studies with Dr. M.P. Kennedy in the area of model-
`based testing of mixed-signal integrated circuits. He was awarded
`the Ph.D. degree in 2003 and worked until 2006 as a postdoctoral
`scholar in the area of mixed-signal design and test. Since then,
`
`Heinz Mattes received his “Diplom Ingenieur” in 1979 and his
`Ph.D. in Electrical Engineering in 1984 from the University of
`Darmstadt, Germany. He joined the R&D division of Siemens
`AG in 1984 as a DRAM designer. In 1993, he was visiting
`researcher at the Department of Electrical Engineering and
`Computer Sciences, University of California, Berkeley, where
`he joined the research group of Prof. Ernest Kuh. From 1989
`onward he developed EDA tools for high-speed transmission line
`simulations. From 1995 to 2001, he worked as a Lead Engineer
`on the topic of mobile image communications. In 2001, he joined
`Infineon Technologies as a Concept Engineer, working on 40Gb/s
`transceivers. Today as a Principal Investigator, he develops test
`methodology and new concepts for mixed-signal testing.
`He holds more than ten patents and has contributed to nu-
`merous conferences. He publishes papers in the areas of memory
`design, signal propagation and mixed-signal testing. He has also
`lectured at various German Universities on the “Fundamentals
`of Electrical Engineering” and “Techniques for Modeling Trans-
`mission Lines.”
`
`Stephane Kirmser received the “Diplom Ingenieur” in Electri-
`cal Engineering from the “Institut Superieur d’Electronique du
`Nord” - ISEN - of Lille, France, in 1998. Subsequently, he joined
`the R&D division of Siemens Semiconductors (which became
`Infineon Technologies) and worked as a Digital Design Engineer
`until 2001.
`From 2001 to 2004, he worked as a Concept Engineer in the
`Optical Networking division, focusing on 40Gb/s transceivers and
`SFP transceivers. In 2004, Stephane joined the Corporate Test
`and Technology department working on novel mixed-signal test
`technologies. His main focus is currently software-based mixed
`signal testing.
`
`Frank Demmerle received the “Diplom Ingenieur” degree in
`Electrical Engineering from the University of Karlsruhe in 1994.
`Until 1998, he was with the “Institut für Höchstfrequenztechnik
`und Elektronik” in Karlsruhe, where he worked on RF circuit
`and antenna design, measurement techniques in the GHz range,
`and microwave processing for scientific and industrial applica-
`tions. He received the Dr.-Ing. degree for his research on a novel
`multi-beam antenna for communication and sensors.
`In 1998, he joined Infineon Technologies AG (formerly
`Siemens Semiconductors) as an RF Test Development Engi-
`neer focusing on novel test methodologies for the production
`test of integrated RF transceiver circuits. Since 2007, he has
`been the Manager of Infineon’s “Analog Design for Test,” an
`internal service provider for innovative and cost-efficient mixed-
`signal and RF test solutions. His current research interests are
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 8 of 9
`
`

`

`308
`
`J Electron Test (2009) 25:301–308
`
`on-chip measurements and data processing, built-in self-test, the
`application of FPGA in production test, and load-board add-ons
`for mixed-signal and RF test on low-cost equipment.
`
`Sebastian Sattler received his “Diplom Ingenieur” in 1989 and
`his Ph.D. in Electrical Engineering in 1994 from the Technical
`
`University of Munich, Germany. He has been working for over
`thirteen years at Siemens/Infineon as an Application and Con-
`cept Engineer in the area of Analog and Mixed-Signal circuits
`and later as Manager Analog Design for Test. He is currently
`a Manager of Acquisition and Funding Projects. His area of
`interest includes high-speed digital, analog, RF and mixed-signal
`testing.
`
`Facebook v. TLI Communications
`IPR2014-00566 TLI Ex. 2009
`Page 9 of 9
`
`