An embedded 1149.4 extension to support mixed-signal debugging

This article appeared in a journal published by Elsevier. The attached copy is furnished to the author for internal non-commercial research and education use, including for instruction at the authors institution and sharing with colleagues. Other uses, including reproduction and distribution, or selling or licensing copies, or posting to personal, institutional or third party websites are prohibited. In most cases authors are permitted to post their version of the article (e.g. in Word or Tex form) to their personal website or institutional repository. Authors requiring further information regarding Elsevier’s archiving and manuscript policies are encouraged to visit: http://www.elsevier.com/copyright Author's personal copy An embedded 1149.4 extension to support mixed-signal debugging $ Manuel C. Felgueiras a, n , Gustavo R. Alves a , J.M. Martins Ferreira b a ISEP/DEE, Rua Dr. Anto ´nio B. de Almeida, 4200-072 Porto, Portugal b FEUP/DEEC, Rua Dr. Roberto Frias, 4200-465 Porto, Portugal article info Article history: Received 30 July 2009 Received in revised form 30 July 2010 Accepted 9 August 2010 Available online 15 September 2010 Keywords: Built-in test Diagnostics IEEE 1149.4 Mixed-signals Verification abstract Debugging electronic circuits is traditionally done with bench equipment directly connected to the circuit under debug. In the digital domain, the difficulties associated with the direct physical access to circuit nodes led to the inclusion of resources providing support to that activity, first at the printed circuit level, and then at the integrated circuit level. The experience acquired with those solutions led to the emergence of dedicated infrastructures for debugging cores at the system-on-chip level. However, all these developments had a small impact in the analog and mixed-signal domain, where debugging still depends, to a large extent, on direct physical access to circuit nodes. As a consequence, when analog and mixed-signal circuits are integrated as cores inside a system-on-chip, the difficulties associated with debugging increase, which cause the time-to-market and the prototype verification costs to also increase. The present work considers the IEEE1149.4 infrastructure as a means to support the debugging of mixed-signal circuits, namely to access the circuit nodes and also an embedded debug mechanism named mixed-signal condition detector, necessary for watch-/breakpoints and real-time analysis operations. One of the main advantages associated with the proposed solution is the seamless migration to the system-on-chip level, as the access is done through electronic means, thus easing debugging operations at different hierarchical levels. &2010 Elsevier Ltd. All rights reserved. 1. Introduction Prototype debugging is one of the development phases of a circuit where design errors and, eventually, structural defects are typically detected, diagnosed and corrected. This activity is traditionally done with the assistance of benchtop equipment directly connected to the circuit under debug. However, the applicability of this traditional equipment has been progressively impaired by trends such as the ever-increasing circuit complexity and miniaturization, and the use of surface mount devices (SMD). These trends had limited effect with respect to analog and mixedsignal (AMS) circuits due to their reduced complexity and number of pins when compared to their digital counterparts. This meant that, at the digital side, the increasing difficulties in doing the structural test of digital printed circuit boards (PCB) led to the proposal, development and market acceptance of mechanisms able to surpass the restrictions imposed by physical access. The strategy followed consisted off embedding on the circuit the mechanisms facilitating that structural test, thus initially leading to proprietary solutions inspired in level sensitive scan design (LSSD) [1], and later leading to standard solutions such as the IEEE Std. 1149.1 [2],alsoknownas JointTestActionGroup(JTAG) or Boundary Scan Test (BST). The BST infrastructure facilitated both structural and the internal test and so the market quickly adopted it, with a large part of its success being supported by its potential use as an electronic access port for debug operations [3,4,5]. In fact, several integrated circuits (IC) made available to the market were specifically designed to increase the controllability/observability levels of digital/analog circuit nodes/ buses. This was the case of components belonging to the System Controllability/Observability Partitioning Environment (SCOPE TM )family of Texas Instruments [6] and of the SCAN TM family of National Semiconductor [7,8], as well as other components proposed by the academic community [9]. Some of these components allowed to partition a circuit into sub-circuits where debugging could be done with test equipment connected through a standard electronic access port, i.e. the test access port (TAP) [5]. This strategy was however clearly insufficient for debug operations in real-time due to the serial nature of the BST architecture (i.e. information is serially shifted through the 4-pin TAP). In this context, components that reuse the Contents lists available at ScienceDirect journal homepage: www.elsevier.com/locate/mejo Microelectronics Journal 0026-2692/$ - see front matter &2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.mejo.2010.08.007 $ The present paper is a condensed compilation of previous papers published by the authors with new material, namely the methodology for verifying the value of a resistor present on an extended interconnection, using the mixed-signal condition detector. This detector reduces the external test and measurement equipment needed for verifying extended interconnections, as required when only using the mandatory IEEE1149.4 infrastructure, in a similar to how simple interconnections are verified in digital printed circuit boards with IEEE1149.1-compatible components. n Corresponding author. Tel.: +351 228340532. E-mail addresses: [email protected] (M.C. Felgueiras), [email protected] (G.R. Alves), [email protected] (J.M. Martins Ferreira). Microelectronics Journal 42 (2011) 218–232 Author's personal copy IEEE1149.1 infrastructure for supporting advanced debug operations started to emerge, e.g. the digital bus monitor [10] that implements a logic/signature analyzer at board-level. This component included a digital condition detector that allowed filtering the data captured at board-level, during a certain functional operation period, and subsequently stored in an internal memory. The stored data could then be shifted out, through the TAP, for later analysis with external equipment. The following trend consisted in embedding, inside the IC or system-on-chip (SOC), blocks specifically designed for supporting debug operations, reusing once again the TAP as an interface mechanism. This trend was particularly visible in microprocessors, with several examples provided by industry, e.g. [11], which converged to a standard solution known as NEXUS TM [12].In this context, the problems associated with the migration of entire digital ICs into SOCs, particularly at the debug phase, benefited from earlier, proven solutions based on electronic access mechanisms. In the AMS area, the dominant situation is practically the opposite, as this type of circuit is usually designed with restrictive specs, tight tolerance margins, and presents a lower complexity level when compared to their digital counterparts. This means that, when mixedsignal ICs are present in a PCB that also contains digital ICs, the AMS part is a relatively small portion of the entire circuit complexity. The debug phase of this type of circuits benefited from the market appearance of the mixed-signal oscilloscope (MSO) [13,14],which combined the visualization of several tens of pure digital channels with that of 2–4 analog channels, while accepting trigger conditions in the digital, analog, or mixed-signal domains. The intrinsic characteristics of AMS circuits and the lack of a standard infrastructure for accessing its nodes supported the long lasting solution of using physical access for debug purposes. Nevertheless, this type of access was to be progressively replaced by ad-hoc and structured electronic access mechanisms [15,16,17].Thepublicationofthe IEEE1149.4 std. [18] raised high expectations in the test/debug community, as this infrastructure was formally presented as the natural extension of the IEEE1149.1 std. to the AMS area, aiming at facilitating structural, parametric and internal tests. However, its adoption has proved slow, with most cited limitations being related to the degradation of the circuit performance [19] and the relative high overhead in ICs of reduced complexity, typically the case in the AMS area. While the first limitation can be minimized with proper design rules [20], the second can only be tackled if the infrastructure proves to be useful for purposes other than the original ones specified in the standard, thus further justifying its inclusion at the IC level. In this sense, it has already been proposed to reuse it for:  parameter characterization, i.e. V OL ,I OL ,V OH ,I OH ,V IL ,I IL and I IH [21];  supporting radio-frequency (RF) measurements [22];  supporting the test of ADCs and DACs [23];  remote test and debug of PCBs with AMS components [24];  monitoring analog signals in automotive environments [25]; Additionally, and following a trend observed in the digital domain, some manufacturers made available to the market IEEE1149.4-compatible ICs targeting the increment of controllability/observability levels of analog nodes in PCBs [26,27]. In this line of evolution, the natural, subsequent step should now be the development of IEEE1149.4-compatible mechanisms offering the possibility to execute, inside the PCB, debug operations similar to those supported by an MSO. Considering this equipment as a combination of a logic analyzer with an oscilloscope, this step would be equivalent to the introduction of the digital bus monitor [10], now for the AMS arena. The experience and limitations arising from the use of such a debug mechanism would allow guiding the subsequent development of specific infrastructures for supporting debug operations in mixed-signal circuits. Any standardization effort built on top of such infrastructures would also benefit the later migration to the SOC level, of AMS circuits. In this sort of AMS components, which assume every-day an increasing importance, the analog part accounts for approximately 2% of the total number of transistors, 20% of the total area, and 40% of the total design effort [28], a direct consequence of the lack of a common platform to support the debug phase. Although the analog/mixed-signal portion is smaller than the digital part, its contribution to the development costs is higher and will continue to grow unless a new debugging paradigm is found. A direct consequence of this fact is the extended time spent on the prototype validation phase, which negatively influences the component’s time-to-market (TTM), a key factor for the final product success. The current need for structured mechanisms supporting debug operations in AMS circuits is so crucial that, if not properly addressed in the near future, it may impair the normal development curve of several consumer electronic manufacturers [29]. Another emergent and promising area requiring such mechanisms refers to the use of reconfigurable analog circuits, i.e. fieldprogrammable analog arrays (FPAA) [30,31,32], which call for effective functional verification methodologies. Notice that in the case of field-programmable gate arrays (FPGA), the IEEE1149.1 infrastructure is presently reused for reconfiguration purposes [33] as well as for accessing internal user-defined registers or even the contents of all register elements [34]. In summary, the IEEE1149.1 infrastructure proved particularly useful as a structured mechanism for debug operations in digital circuits, and did also provide the basis for other infrastructures specifically developed for debug purposes. Considering the IEEE1149.4 infrastructure to be the formal extension of its predecessor for mixed-signal components, its reuse should be also analyzed for supporting debug operations in AMS circuits. This is the aim of the present work, which proposes reusing this infrastructure for (1) accessing, in an analog fashion, analog/digital nodes (either corresponding to internal nodes or associated with component pins), and (2) interfacing with a mixed-signal condition detector (MCD), i.e. an internal block specifically designed to support debug operations such as breakpoints/watchpoints or real-time analysis. The rest of this paper is organized as follows: Section 2 presents a debug model for MS circuits; Section 3 explains how the IEEE1149.4 infrastructure is re-used for accessing the circuit nodes under debug; Section 4 introduces and describes the MCD; Section 5 deals with the validation of the associated debug methodology; Section 6 discusses the impact and cost of the MCD; and, finally, Section 7 concludes the paper. 2. The debug model Circuit debugging is traditionally done with the assistance of benchtop equipment requiring some sort of access type. Some debug tools are specific of microprocessor-based circuits, such as in-circuit emulators (ICE), while others remain generic, such as logic analyzers, oscilloscopes or multimeters. Although each tool can do/support a large number of debug operations, these can be grouped in a small set of debug operation types. According to the simple debug model illustrated in Fig. 1, any debug operation fits into one of four debug operation types, namely:  Control, observation and verification (COV) of the circuit state  Breakpoint/watchpoint  Step-by-step  Real-time analysis COV operations are assumed to be the basic debug operations and are used to control/observe/verify the state of a circuit. Breakpoint/ watchpoint, step-by-step and real-time analysis are considered M.C. Felgueiras et al. / Microelectronics Journal 42 (2011) 218–232 219 Author's personal copy Advanced debug operations and are used to control/observe/verify the circuits function in the time domain. Providing a simple example of a debug sequence in the digital domain, suppose one intends to verify if a given memory location contains a given value, when the program counter reaches a certain address.Thesequenceofstepsis:(1)placeaknownvalueinthe memory target location, using a control operation; (2) place the circuit in its normal functioning state and then wait till the breakpoint condition is met, i.e. the program counter reaches given address, causing the circuit to stop; (3) read the contents of the memory target location, using an operation of the observation type; and (4) verify if the read value matches the expected one, using an operation of the verification type. These debug operations are generic and hence applicable to any sort of digital circuit. For instance, a breakpoint operation can be applied in a sequential circuit by stopping the clock signal, when a certain circuit condition is met, forcing the circuit to retain its present state and enabling the use of COV operations to ascertain about the correctness of that state. A step-by-step operation can be applied to the same circuit to observe and verify each one of its possible states. Real-time analysis operations comprehend state recording and the validation of circuit conditions, in real-time. Typical application examples of this type of debug operation include: store the circuit state until breakpoint condition; store the circuit state after a breakpoint condition; among others usually supported by logic analyzers, oscilloscopes with memory, and also by MSOs. In realistic terms, this very basic debug model can be extended to the MS domain. Suppose, for instance, one intends to store the circuit state when an analog value (e.g. a voltage) reaches a given threshold—in basic terms, this would correspond to a breakpoint operation. In the same line of reasoning, a step-by-step operation could be used to verify the cut-off frequency of a digital programmable filter, by applying at the filter input (at each step) an analog signal of increasing frequency and observing (at each step) the filter output. Both debug operation types (breakpoint and real-time analysis) imply the evaluation of circuit conditions and thus require an MCD able to detect them. The proposed basic debug model and the described debug sequences reveal the need for (1) a mechanism enabling the access to the circuit nodes under debug, and (2) an MCD capable of supporting the referred advanced debug operations. These two aspects will now be addressed in detail in Sections 3 and 4. 3. Extending the IEEE1149.4 infrastructure for COV operations The access types that distinguish the possible alternatives for implementing COV operations can be divided into: (a) direct physical access; (b) direct electronic access; and (c) non-direct access. Direct physical access comprises the circuit primary inputs/ outputs (I/O) and any other circuit access points enabling a direct connection with an automatic test equipment (ATE) or any other test and measurement equipment. This access type presents serious limitations due to the ever-increasing circuit miniaturization levels and the existence of components on both PCB sides – surface-mount technology (SMT) – where some totally prevent the physical access to the device pins, when encapsulated with the ball grid array (BGA) technology. Even when the direct physical access enables observing a given node of the circuit under debug (CUD), it does not imply the possibility to actually control the node value, which depends on the limit for the backdriving current. Direct electronic access is done through scan chains or any other dedicated logic/circuit paths. Nondirect access is based on signal propagation through internal circuit blocks, which restricts its practical use to circuits of low/medium complexity. The IEEE1149.1 and the IEEE1149.4 infrastructures are two examples of the direct electronic access type. While the first is largely used as a mechanism for controlling and/or observing the circuit internal nodes and pins, the second one faces some difficulties for that purpose, according to the study presented in [35]. In fact, the most usual boundary scan cell (BSC) configuration described in the IEEE1149.1 std. (i.e. with two 2:1 multiplexers and two flip-flops) presents a fixed signal flow orientation, allowing at all-times the control of the BSC parallel output, irrespective of the circuit connected to the pin associated with that BSC. In contrast, the switching structure of the analog boundary module (ABM) described in the IEEE1149.4 std. presents a fixed pin orientation. According to the scheme illustrated in Fig. 2a, it is only possible to control, via AT1/AB1, the value of the mission circuit connection (MCC) if the driving source of the pin connection (PC) can be placed in a highimpedance state, i.e. the case, for instance, when the IC containing that driving source is IEEE1149.4-compatible. Fig. 2b presents a solution to overcome this limitation by adding an extra switch to the ABM switching structure. Notice the IEEE1149.4 std. allows placing additional switches inside that structure. 1 Furthermore, an ABM can also be associated with digital pins to allow controlling/observing the corresponding signals in an analog mode. 2,3 In this line of reasoning, Fig. 3 presents the topology of a proposed generic ABM (G-ABM) that allows controlling/observing the nodes located at both sides of the SD switch. For a large number of applications, not all elements that form the G-ABM are strictly necessary. However, this a starting point to Fig. 1. A simple debug model. 1 (IEEE1149.4—7.3.4): The infrastructure allows adding extra conceptual switches to increase the flexibility of the ABM. 2 (IEEE1149.4—7.2.1.1.a): The infrastructure allows associating ABMs or DBMs to digital pins. 3 (IEEE1149.4—3.1.1 NOTE): An ABM may be attached to a digital function pin in order to provide analog measurement capability to the pin. M.C. Felgueiras et al. / Microelectronics Journal 42 (2011) 218–232220 Author's personal copy allow a systematic approach to the needs raised by each and every possible case. The present work proposes additions to the IEEE1149.4 std. allowing (1) the circuit designer to freely choose any ABM resulting from the illustrated G-ABM; (2) the chosen ABMs to be associated with both pins and internal nodes; and, (3) the corresponding control registers to be part of the boundary scan register (BSR). These proposals are twofold. First, they increase the flexibility of the IEEE1149.4 infrastructure, following an approach similar to the IEEE149.1 std., which describes several BSCs that can be selected according to the specific control/ observation requirements of each node. Second, they support the claim of conformity with the IEEE1149.4 std. of several circuits using variations of the G-ABM. In fact, conformity will still apply even if partial implementations are used. This is the case, in particular, of several manufacturers that have adopted solutions based on the IEEE1149.4 std., but following internal requirements that led to simpler/reduced modules, in order to minimize the associated overhead [36,37]. In this sense, it is possible to design specific ABM versions targeting the interconnection of internal nodes to the MCD, so as to extend the range of possible breakpoint/watchpoint conditions. 4. The mixed-signal condition detector From a functional point of view, the MCD compares the value present at the node(s) under debug with one or two limits. As mixed-signal circuits have both digital and analog values, the MCD should support comparison operations in both domains. A detection circuit operating in the digital domain and fully compatible with the IEEE1149.1 infrastructure was already described in [38]. Since this infrastructure uses a serial data transmission protocol, there is a considerable delay between the moment a condition occurs (inside the circuit) and the moment an external detector validates and signals its occurrence. A possible and obvious solution is to move the condition detector into the circuit under debug. There are already proposals of such detection circuits in the analog domain [39,40], which support a reduced number of analog comparison limits and detectable condition types. The proposed solutions also face serious limitations due to their inherent dependence of externally defined analog voltages, corresponding to the comparison limits, which compromise the overall detector precision. The design of a MCD can follow several directions, according to the requirements identified. In our case, we have considered the following ones:  Support different comparison operations between observed/ expected values.  Rely on electronic access rather than physical access.  Guarantee compatibility with the IEEE1149.4 infrastructure.  Minimize the impact, i.e. the overhead due to the MCD.  Compare both analog and digital values inside the circuit under debug. The comparison operations supported by the MCD require an expected value and a mask for operations of the type ¼and a,a Limit_A for operations of the type 4,Z,oand r, and also a Limit_B for operations of the type A[Limit_A;Limit_B] and e[Limit_A;Limit_B]. The most efficient solution to overcome the difficulties associated with the physical access is to migrate all the mechanisms needed for doing those operations into the circuit under debug. This has been the most relevant reason to justify the inclusion on the target circuit (i.e. the circuit under debug) of adhoc mechanisms, plus standard or proprietary infrastructures. Also in the present case, the best location will be the one allowing access to both digital and analog nodes. Depending on the hierarchical level, that location can either correspond to an IC inside a PCB or a block inside an IC. The trend towards miniaturization, which increasingly promotes the interest for the SOC level, justifies the inclusion of both the MCD, as a built-in dedicated block, and the mechanisms necessary to access any node under debug. The overhead introduced by the MCD should be minimized through the reuse, whenever possible, of the test resources already available inside the IC. In this sense, it is possible to reuse the IEEE1149.4 test infrastructure to: (1) access this new block; (2) select the nodes under debug; and (3) store, in a digital form, values required for the comparison operations (expected value/ mask or Limit_A/Limit_B). The register elements of every BSC – now called digital bus module (DBM) in the IEEE1149.4 – can be used for this purpose, as test operations are not concurrent with debug operations. In contrast, the register elements pertaining to the test bus interface circuit (TBIC) and ABM control structures cannot be reused for this purpose, as the state of the associated switching structures depends on the current contents of those registers. As both the TBIC and ABMs are used to route the signal from the analog node under debug till the MCD analog input, it is not possible to accommodate simultaneously the two concurrent goals. Fig. 2. Modifying the ABM to allow full-control of the mission circuit connection. Fig. 3. Topology of the G-ABM. M.C. Felgueiras et al. / Microelectronics Journal 42 (2011) 218–232 221 Author's personal copy In order to support detection operations in both domains, the MCD must include two independent condition detectors [41], one for the digital condition and another for the analog condition, as illustrated in Fig. 4. Each detector has the following inputs: the signal(s) from the node(s) under debug; the expected value/Limit_A; the mask/ Limit_B, and a set of configuration lines to define the current operation. The output of each detector is named after its domain, i.e. analog/digital valid condition (AVC/DVC), which is logic high (‘‘1’’) whenever a condition is evaluated as true. The MCD output, named output valid condition (OVC), can either exhibit the AVC signal, the DVC signal, or a logic combination of both, following a typical functionality present in MSO. The OVC signal can be used for debug purposes inside the CUD (e.g. stop the clock signal on a breakpoint operation) or simply to externally indicate the detection of a valid condition (e.g. on a watchpoint operation). Fig. 5 illustrates a debug scenario where the MCD is used to support a breakpoint operation on an AMS circuit with a microprocessor. In this sort of circuits (with a microprocessor) it is important to hold the operation at the very moment a condition is met, either in the digital or analog domain. However, holding the circuit operation on the digital/analog domain, upon the occurrence of a condition in the pure analog domain, is not often supported due to the implicit interaction between the two domains. As the comparison operations of the MCD are done in the pure digital domain, the most direct solution to store all the data needed for those operations is to reuse the memory elements pertaining to the test infrastructure (not simultaneously used for other purposes) and include additional registers accessible through that same infrastructure. These operations take place while the CUD is on its normal operational state, so it is possible to reuse the IEEE1149.4 infrastructure for storing part of the data needed. In fact, the DBM registers can be reused to store the expected value and the mask (or the Limit_A and the Limit_B) – for the condition in the digital domain – on the update (U) and capture/shift (C/S) stages, respectively. In this way, the BSR is reused on its full storage capacity (minimizing overhead), as the memory elements of the TBIC and ABM control registers must hold their previous values. Notice that while the operational mode of a BSC depends mostly on the current test instruction, the operational mode of the TBIC and ABMs also depend on the contents stored in the corresponding control registers that are part of the BSR. In order to store 2 vectors in the U and C/S stages of each DBM, the UpdateDR signal (true at logic ‘‘1’’ when the TAP controller is on the Update-DR state) must be deactivated to avoid Fig. 4. Conceptual block diagram of the MCD. Fig. 5. Using the MCD to support a breakpoint operation. M.C. Felgueiras et al. / Microelectronics Journal 42 (2011) 218–232222 Author's personal copy corrupting the data stored in the Update stage. A DBM can thus contain the 3 signals needed for a comparison operation, as illustrated in Fig. 6. The structure composed by a single DBM and a single F block forms a basic (1-bit) condition detector, whose output (Q2,Q1,Q0) depends on the:  actual observed value, present at the parallel input (PI) of the BSC;  expected value/mask or Limit_A/Limit_B stored in the DBM (C/ S, U stages);  result from the previous basic condition detector (I2,I1,I0); and  selected comparison operation (C2,C1,C0). There are five possible comparison results exhibited at (Q2,Q1,Q0): false, true, equal to A, great than A, or less than B; thus 3 lines (2 3 ) are necessary to codify all possibilities. The F block supports 8 comparison operations, which requires 3 lines to codify them, according to the sequence presented in Table 1. According to the current operation type (C2,C1,C0), the F block evaluates the result present at (Q2,Q1,Q0), which is a logic function of the inputs (I2,I1,I0) and of the contents present at C/S, U and PI. Table 2 presents, as an example, the truth table for operation ‘‘¼A’’, selected when (C2,C1,C0)¼(0,0,0). The remaining 7 truth tables are not shown here due to space restrictions. Fig. 7a illustrates how the several basic condition detectors, each formed by a DBM+an F block, are concatenated to form a digital condition detector register (DCDR), which allows detecting n-bit digital conditions. This register acts as a word comparator whose result is shown in the DVC output. The additional FA block is necessary to define, according to the current operation, the input values (I2,I1,I0) for the first basic condition detector. Likewise, the additional FB block is necessary to compute the DVC logic value according to the current operation and the output values of the last basic condition detector. A simplified representation of the DCDR is illustrated in Fig. 7b. A similar yet simplified register associated with an ADC is used to detect analog conditions. The comparison operation takes place in the pure digital domain, as illustrated in Fig. 8, with the ADC input connected to one line (AB2) of the internal analog test bus—a part of the IEEE1149.4 infrastructure. The analog condition detector register (ACDR) is an optional register, permitted by the IEEE1149.4 std., internally built with DBM-alike blocks without the second multiplexer (i.e. it does not have primary outputs), as it only receives information from the ADC. The operation type implemented by the analog condition detector register (ACDR) and the DCDR is defined by inputs (C2A,C1A,C0A) and (C2D,C1D,C0D), respectively, fed by an equal number of bits belonging to the detection configuration register (DCR). The FC block is responsible for driving OVC (an MCD primary output), from 4 possible sources: (i) AVC, (ii) DVC, (iii) AVC AND DVC and (iv) AVC OR DVC. The source is selected through signals VS1 and VS0, i.e. 2-bits belonging to the DCR. OVC is valid when inputs COMP2 and RTI are true. These two signals act as an enable input. COMP2 is true at logic level ‘‘1’’ when the IEEE1149.4 instruction register (IR) is loaded with the optional instructions EXTEST2,PROBE2 or INTEST2 (described ahead), while RTI is true at logic level ‘‘1’’ when the TAP controller is on the RunTest/Idle state. Table 3 resumes the operation of the FC block. OVC can either be an internal signal used for breakpoint operations, when the necessary mechanisms for stopping the circuit operations are present, or a dedicated output pin used to flag an event to the outside world, as already illustrated in Fig. 5. DCR corresponds to an 8-bit optional register added to the registers structure accessible through the IEEE1149.4 infrastructure. Fig. 9 illustrates its internal contents, where the purpose of each group of bits was already described in the previous paragraph. Fig. 6. Structure of a basic (1-bit) condition detector and the corresponding simplified representation. Table 1 Comparison operation types supported by the MCD. C2 C1 C0 Operation type Note 000¼A Requires a mask 001aA Requires a mask 0104Limit_A 011oLimit_A 100ZLimit_A 101rLimit_A 1 1 0 Inside the interval [A, B] Requires a Limit_B 1 1 1 Outside the interval [A, B] Requires a Limit_B Table 2 Truth table of the F block for the ‘‘¼A’’ operation. Coded (I2,I1,I0) C/S U PI Coded (Q2,Q1,Q0) FXXXF T0XXT T1O0T T1O1F T110F T111T M.C. Felgueiras et al. / Microelectronics Journal 42 (2011) 218–232 223 Author's personal copy The DCDR is formed by the DBMs already present in the circuit, making this register a part of the BSR. The same does not apply to the ACDR. However, it should be possible to shift in the Limit_A vectors to both registers, during the same shift sequence, and then store them at the respective update stages. The same should be also possible for the Limit_B vector. The register structure presented in Fig. 10 enables this possibility by serially connecting the boundary scan and the analog condition detector registers (i.e. BSR+ACDR), when the data multiplexer input 2 is selected. Selecting input 1 enables accessing the DCR for debug configuration purposes, while the two remaining inputs (3 and 0) serve the mandatory boundary scan and bypass registers. Notice that DCDR is not represented as a discrete register as it is part of the mandatory BSR. In order to operate the functionally provided by the MCD, it is necessary to add a number of new optional instructions to the IEEE1149.4 infrastructure. A first optional instruction, named SELCON, is required to place the DCR into the test data input (TDI)—test data output (TDO) path, i.e. to select input 0 of the data mux illustrated in Fig. 10. A second optional instruction, Fig. 7. DCDR structure and simplified representation. Fig. 8. MCD structure. Table 3 Truth table for the OVC signal. RTI COMP2 VS1 VS0 OVC 0X X X 0 X0 X X 0 1 1 0 0 DVC 1 1 0 1 AVC 1 1 1 0 DVC OR AVC 1 1 1 1 DVC AND AVC Fig. 9. The DCR description. M.C. Felgueiras et al. / Microelectronics Journal 42 (2011) 218–232224 Author's personal copy named SAMPLE/PRELOAD2 (or S/P2, in an abbreviated form) selects input 2 of the same data mux, to allow storing the Limit_A vector on the U stages of DCDR and ACDR. A third optional instruction, named PROBE2, has multiple purposes: (1) it selects input 2 of the data mux to allow storing the Limit_B vector on the C/S stages of DCDR and ACDR; (2) it disables the UpdateDR signal to avoid corrupting the previously stored Limit_A, when the TAP controller passes through the Update-DR state; (3) it allows selecting the current analog node under debug feeding the ADC input, i.e. in a similar operating mode provided by the mandatory PROBE instruction, it connects the AB2 switch of the ABM associated with the analog node selected for debug purposes and routes the signal through the internal test bus line with the same name (AB2) to the input of the ADC associated with the ACDR. Similar to the PROBE mandatory instruction, the PROBE2 optional instruction allows using the internal analog test bus in a non-intrusive mode during the mission circuit normal operation mode. Another two optional instructions, named INTEST2 and EXTEST2, allow using the MCD when the IEEE1149.4 infrastructure is placed in the internal and external test modes, respectively. When the present instruction is PROBE2, INTEST2 or EXTEST2, the remaining elements of the IEEE1149.4 infrastructure retain their operational conditions, defined for the mandatory instructions PROBE, INTEST and EXTEST, respectively. Table 4 summarizes some characteristics of the proposed optional instructions. The following section will now describe the sequence of IEEE1149.4 operations necessary for using the MCD and the GABM to implement part of the debug model presented in Section 2. 5. Validating the proposed solution through simulation To validate the proposed debug model it is necessary to have a mission circuit surrounded by an IEEE1149.4 infrastructure comprising the previously defined extensions, i.e. the MCD and the non-canonical ABM topologies that allow (i) controlling the mission circuit inputs in an independent mode, and (ii) accessing internal analog nodes for control/observation purposes. The selected mission circuit should also allow demonstrating the use of both analog and mixed-signal condition detection operations. Developing a circuit in hardware with such characteristics would be quite time consuming, as the number of IEEE1149.4-compatible devices is reduced and, furthermore, do not support the proposed ABM variants. The alternative of implementing a compatible circuit, using discrete components, is also quite cumbersome and time consuming as already demonstrated through the example described in [42], referring to a simple functional circuit composed of a digital inverting buffer and an operational amplifier with unitary gain, surrounded by the mandatory IEEE1149.4 infrastructure. In order to validate the proposed debug model, a substantially more complex circuit is required, thus favouring the use (in a first approach) of a simulation environment. We decided for OrCAD v10.3, supported by Cadence, which includes a PSpice simulator. The main characteristics of the mission circuit designed for validation purposes are:  Includes at least two mixed-signal macro blocks, enabling the association of an ABM to an internal analog node.  Enables detection operations on analog nodes and/or digital buses. As illustrated by Fig. 11, the selected macro-blocks composing the mission circuit are a 4:1 analog mux and a 12-bits ADC (named ADC1). ADCs and analog multiplexers/switches are quite common in MS circuits, with the association of ADC plus analog mux, in particular, being frequently found in circuits comprising a microcontroller. The complete target circuit includes the mission circuit plus an IEEE1149.4 infrastructure with the proposed extensions, i.e. the ABM variants described in Section 3, and the MCD described in Section 4. The main characteristics of the target circuit are:  The digital pins have DBMs associated with.  The analog input pins have ABMs associated with a topology corresponding to the one illustrated by Fig. 2b (identified as variant ABM-1). Fig. 10. Registers structure supporting the MCD. Table 4 Characteristics associated with the proposed optional instructions. Optional instruction Selected data mux input UpdateDR signal disabled Behaviour of the remaining IEEE1149.4 infrastructure PROBE2 2 Yes ¼PROBE INTEST2 2 Yes ¼INTEST EXTEST2 2 Yes ¼EXTEST S/P2 2No¼S/P SELCON 0– ¼BYPASS M.C. Felgueiras et al. / Microelectronics Journal 42 (2011) 218–232 225 Author's personal copy the form of a dedicated microprocessor for supporting test (e.g. structural, parametric and functional), debug and maintenance (e.g. monitoring the IC internal temperature) operations. Finally, for the examples described, the associated overhead is approx. 33%, in relation to the digital part of the IEEE1149.4 infrastructure (which, in its turn, usually represents a small fraction of the total circuit complexity), plus the ADC for the MCD. Considering an SOC with a microprocessor, memory, ADC and DAC converters, etc., the total overhead may be relatively smaller and easily acceptable face to the time-to-market and the total design verification costs, presently the major cost factor in AMS circuits [29]. References [1] E.B. Eichelberger, T.W. Williams, A logic design structure for LSI testability, IEEE Transactions on Computers (1977) 462–468. [2] IEEE Std. 1149.1, Standard test access port and boundary-scan architecture. IEEE Standards Board, October, 1993. [3] S. Sunter, P1149.4—problem or solution for mixed-signal IC design? in: Proceedings of the International Test Conference, 1997, p. 625. [4] R.M. Sedmak, Boundary scan: beyond production test, in: Proceedings of VLSI Test Symposium, 1994, pp. 415–420. [5] A. Halliday, G. Young, A. Crouch, Prototype testing simplified by scannable buffers and latches, in: Proceedings of the International Test Conference, 1989, pp. 174–181. [6] Texas Instruments, SCOPE TM Logic Products: Application and Data Manual, 1994, ISBN:3-88078-098-6. [7] National Semiconductors, System Test Access IEEE 1149 (JTAG) Solutions, /http://www.national.com/analog/interface/scanS(accessed on July 23rd, 2009). [8] National Semiconductors, SCANSTA476—Eight Input IEEE 1149.1 Analog Voltage Monitor, /http://www.national.com/pf/SC/SCANSTA476.htmlS(accessed on July 23rd, 2009). [9] J.S. Matos, A.C. Le~ ao, J.C. Ferreira, Control and observation of analog nodes in mixed-signal boards, in: Proceedings of the International Test Conference, 1993, pp. 323–331. [10] L. Whetsel, An IEEE 1149.1 based logic/signature analyzer in a chip, in: Proceedings of the International Test Conference, 1991, pp. 869–878. [11] JTAG TAP Controller PP4XX Cores, IBM PowerPC Application Note, 2007, /http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/ C9C0D48DDA776C968725723700676D0ES(accessed on January 18th, 2009). [12] IEEE-ISTO Std.5001, The Nexus 5001 TM Forum Standard for a Global Embedded Processor Debug Interface. IEEE Industry Standards and Technology Organization (IEEE-ISTO), December, 2003. [13] LeCroy Corporation, /http://www.lecroy.comS(accessed on January 18th, 2009). [14] Agilent Technologies, /http://www.agilent.com/S(accessed on January 18th, 2009). [15] N.-C. Lee, A hierarchical analog test bus framework for testing mixed-signal integrated circuits and printed circuit boards, Journal of Electronic Testing: Theory and Applications 4 (1993) 361–368. [16] K.-J. Lee, S.-Y. Jeng, T.-P. Lee, A new architecture for analog boundary scan, in: Proceedings of the IEEE International Symposium on Circuits and Systems, 1995, pp. 409–412. [17] A.H. Bratt, R.J. Harvey, A.P. Dorey, A.M.D. Richardson, Design-for-test structure to facilitate test vector application with low performance loss in non-test mode, IEE Electronics Letters 29 (16) (1993) 1438–1440. [18] IEEE Std. 1149.4. 1999, Standard for a Mixed-Signal Test Bus. IEEE Standards Board, June, 1999. [19] R. Schuttert, D.C.L. van Geest, A. Kumar, On-chip mixed-signal test structures re-used for board test, in: Proceedings of the International Test Conference, 2004, pp. 375–383. [20] S.K. Sunter, Cost/benefit analysis of the P1149.4 mixed-signal test bus, IEE Proceedings on Circuits, Devices and Systems 143 (6) (1996) 393–398. [21] S.K. Sunter, B. Nadeau-Dostie, Complete, contactless I/O testing—reaching the boundary in minimizing digital IC testing cost, in: Proceedings International Test Conference, 2002, pp. 446–455. [22] P. Syri, J. Hakkinen, M. Moilanen, IEEE 1149.4 compatible ABMs for basic RF measurements, in: Proceedings of Design Automation and Test in Europe, 2005, pp. 172–173. [23] S.K. Sunter, Testing high frequency ADCs and DACs with a low frequency analog bus, in: Proceedings International Test Conference, 2003, pp. 228–234. [24] S. Tatum, Lockheed Martin team integrates state-of-the-art technologies to conduct first ever demonstration of a remote controlled test and fault isolation system. Lockheed Martin Press Release, January 17th, 2002. [25] C. Jeffrey, A. Lechner, A. Richardson, Online monitoring for automotive subsystems using 1149.4, in: Proceedings of the IEEE Board Test Workshop, 2003. [26] SCAN STA400—National Semiconductor, /http://www.national.com/opf/ST/ STA400EP.htmlS(datasheet accessed on January 10th, 2009). [27] MNABST-1, Hewlett Packard Company/Matsushita Electric Industrial Co., LTD., /http://grouper.ieee.org/groups/1149/4/me1p.htmlS(datasheet accessed on January 10th, 2009). [28] Cadence white paper, Cadence Company, /http://www.cadence.com/pro ducts/orcad/index.aspxS(accessed on December 10th, 2008). [29] ITRS, International Technology Roadmap for Semiconductors. 2007 Edition, /http://www.itrs.net/home.htmlS(accessed on February 20th, 2008). [30] Anadigm, /http://www.anadigm.com/S(accessed on January 10th, 2009). [31] Lattice Semiconductor Corporation, /http://www.latticesemi.com/products/ maturedevices/isppac/index.cfmS(accessed on January 10th, 2009). [32] Cypress Semiconductor, 2007, /http://www.cypress.com/S(accessed on January 10th, 2009). [33] IEEE Std. 1532, Standard for in-system configuration of programmable devices, IEEE-SA Standards Board, December 2001. [34] M.G. Gericota, G.R. Alves, M.L. Silva, J.M. Ferreira, Reliability and availability in reconfigurable computing: a basis for a common solution, IEEE Transactions on Very Large Scale Integration (VLSI) Systems 16 (11) (2008) 1545–1558 November. [35] M.C. Felgueiras, G.C. Alves, J.M.M. Ferreira, Debugging mixed-signal circuits via the IEEE1149.4 Std.—analysis of limitations and requirements, in: Proceedings of the 12th IEEE International Mixed-Signal Testing Workshop, 2006, pp. 2–7. [36] IEEE 1149.4, Working Group Meeting Minutes, 2003. [37] A. Gorodetsky, Bridge for on-board and on-chip 1149.4—compliant testability, in: Proceedings of the IEEE Board Test Workshop, 2005. [38] G.R. Alves, J.M.M. Ferreira, From Design-for-test to design-for-debug-andtest: analysis of requirements and limitations for 1149.1, in: Proceedings of VLSI Test Symposium, 1999. [39] G.O. Ducoudray-Acevedo, J. Ramı ´rez-Angulo, Innovative built-in self-test schemes for on-chip diagnosis, compliant with the IEEE1149.4 mixed-signal test bus standard, Journal of Electronic Testing: Theory and Applications 19 (2003) 21–28. [40] M. Slamani, B. Kaminska, T-BIST: a built-in self-test for analog circuits based on parameter translation, in: Proceedings of the Second Asian Test Symposium, 1993, pp. 172–177. [41] M.C. Felgueiras, G.C. Alves, J.M.M. Ferreira, A built-in debugger for 1149.4 circuits, in: Proceedings of the 13th IEEE International Mixed-Signal Testing Workshop, 2007, pp. 93–98. [42] A.V. Fidalgo, R.J. Costa, J.M. Ferreira, G.R. Alves, Experimenting the 1149.1 and 1149.4 test infrastructures in a Web-accessible remote Lab (without Plugins!), in: Proceedings of the XVI Conference on Design of Circuits and Integrated Systems, 2001. [43] M.C. Felgueiras, G.C. Alves, J.M.M. Ferreira, Debugging mixed-signals circuits via IEEE1149.4—a built-in mixed condition detector, in: Proceedings of the XXII Conference on Design of Circuits and Integrated Systems, 2007. [44] F. Jong, F. Heyden, Testing the integrity of the boundary scan test infrastructure, in: Proceedings of the International Test Conference, 1991, pp. 105–112. [45] A.T. Dahbura, M.U. Uyar, C.W. Yau, An optimal test sequence for the JTAG/ IEEEP1149.1 test access port controller, in: Proceedings of the International Test Conference, 1989, pp. 55–62. [46] M.C. Felgueiras, G.C. Alves, J.M.M. Ferreira, Integrity checking of 1149.4 extensions to 1149.1, in: Proceedings of the XXI Conference on Design of Circuits and Integrated Systems, 2006. [47] Duzevik, Preliminary Results of Passive Component Measurement Methods Using an IEEE 1149.4, in: Proceedings Board Test Workshop, 2002. [48] T. Saikkonen, M. Moilanen, Component value calculations and characterization for measurements in 1149.4 environment, in: Proceedings of the 12th IEEE International Mixed-Signal Testing Workshop, 2006, pp. 76–82. [49] M.C. Felgueiras, G.C. Alves, J.M.M. Ferreira, Measurements in 1149.4 environments—correcting the infrastructure switches influence, in: Proceedings of the IEEE Board Test Workshop, 2007. [50] IEEE P1687 (IJTAG) Standard for Access and Control of Instrumentation Embedded within a Semiconductor Device, /http://grouper.ieee.org/groups/ 1687/S(accessed on July 23rd, 2009). M.C. Felgueiras et al. / Microelectronics Journal 42 (2011) 218–232232