Test architecture for electronic circuits, corresponding apparatus and method
By adopting a highly configurable LBIST architecture, the problem of insufficient flexibility of existing LBIST solutions in SoC and IP is solved, enabling efficient testing in both complex and simple cuts, meeting the ISO 26262 safety specification, reducing area overhead and improving testing efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- STMICROELECTRONICS SRL
- Filing Date
- 2022-03-30
- Publication Date
- 2026-05-29
Smart Images

Figure CN115144725B_ABST
Abstract
Description
[0001] Cross-references to related applications
[0002] This application claims priority to Italian application No. 102021000007856, filed on March 30, 2021, the entire contents of which are incorporated herein by reference. Technical Field
[0003] This application relates to testing electronic circuits, and in certain embodiments to a logic built-in self-test (LBIST) architecture. Background Technology
[0004] Today, in sectors such as the automotive industry, electronic devices are no longer solely used to achieve in-vehicle comfort features. Electronic devices are now widely involved in realizing passive / active safety systems aimed at preventing or at least reducing harm to drivers and passengers: related functions can include features such as forward collision warning, blind spot monitoring, automatic emergency braking, airbags, and ABS features.
[0005] This situation is based on standards such as ISO 26262, which are applied to the design of automotive electronic equipment to provide a common basis for evaluating and documenting safety levels in electrical and electronic (E / E) systems.
[0006] To detect potential faults in the implemented safety mechanisms, potential point faults (LPFs) or single points of failure (SPFs) in functional logic blocks, periodic online testing is used to promote full compliance with safety specifications such as ISO 26262.
[0007] Despite extensive activity in this field, products such as SoCs and others for the automotive market can benefit from the availability of a configurable online BIST mechanism that can effectively test a variety of hardware (HW) security mechanisms. Summary of the Invention
[0008] One or more embodiments of this application help to provide a highly configurable LBIST architecture for online / offline testing of (sub)systems.
[0009] One or more embodiments may relate to corresponding devices. A semiconductor device, such as a SoC including a self-test control architecture as shown herein (possibly in conjunction with associated scan chain circuitry), can be an example of such a device.
[0010] One or more embodiments may involve corresponding methods.
[0011] One or more embodiments may provide one or more of the following advantages. A sufficient trade-off can be achieved between area cost and performance objectives (test coverage, test time) by selecting (static) configuration parameters. Integration across multiple simple / complex digital subsystems is possible for full / partial online LBIST testing of the system and subsystems. Testing can involve the entire suite of safety designs / circuit devices or only programmable / configurable subsets. One or more test sessions can be triggered at runtime (e.g., via software) with reduced area overhead. Modules involved in a test session can be tested sequentially or in parallel; this level of configurability helps to achieve appropriate trade-offs in area, test time, and coverage of various scenarios. As a byproduct, a general "rule of thumb" for calibrating system size can be obtained. Attached Figure Description
[0012] One or more embodiments will now be described by way of example only with reference to the accompanying drawings, in which:
[0013] Figure 1A and Figure 1B These block diagrams collectively represent circuit structures according to embodiments of this specification.
[0014] Figure 2 It is possible to do so Figure 1A and Figure 1B Examples of fields provided in registers included in the architecture shown.
[0015] Figure 3 This is a block diagram of a test circuit configured to cooperate with an architecture according to embodiments of this specification, and
[0016] Figure 4 yes Figure 1B An exemplary circuit diagram of the components of the circuit structure. Detailed Implementation
[0017] In the following description, one or more specific details are shown to provide a thorough understanding of examples of embodiments described herein. Embodiments may be obtained without one or more specific details, or by utilizing other methods, components, materials, etc. In other instances, known structures, materials, or operations have not been shown or described in detail so as not to obscure certain aspects of the embodiments.
[0018] References to "an embodiment" or "one embodiment" within the framework of this specification are intended to indicate that a particular configuration, structure, or feature described with respect to that embodiment is included in at least one embodiment. Therefore, phrases such as "in an embodiment" or "in one embodiment" that may appear at one or more points in this specification do not necessarily refer to the same embodiment.
[0019] Furthermore, in one or more embodiments, a particular conformation, structure, or feature can be combined in any suitable manner.
[0020] The headings / references used herein are provided for convenience only and are not intended to limit the scope of protection or the scope of the embodiments.
[0021] For the sake of brevity, various abbreviations are used throughout the instruction manual.
[0022] Although known to those skilled in the art, many of these acronyms and their meanings are reproduced below for direct reference.
[0023] LBIST = Logic Built-in Self-Test
[0024] SoC = System on Chip
[0025] IP = Intellectual Property (Core or Block: Reusable logic, cell, or integrated circuit layout design unit)
[0026] CAD = Computer-Aided Design
[0027] CUT = Circuit under test
[0028] LFSR = Linear Feedback Shift Register
[0029] MISR = Multiple Input Signature Register
[0030] ECC = Error Correction Code
[0031] FCU = Fault Collection Unit
[0032] SPF = Single Point of Failure
[0033] LPF = Potential Point Fault
[0034] EDPA = Enhanced Data Processing Architecture
[0035] RTL = Register Transfer Level
[0036] EOC = Counter End
[0037] One or more embodiments provide a (circuit) architecture for periodic online / offline LBIST operation.
[0038] The static and dynamic configurability of this structure makes it suitable for testing various types of digital blocks (combinations or sequences).
[0039] This also applies to complex blocks (e.g., subsystems with many logic gates and memory elements).
[0040] Furthermore, one or more embodiments can simultaneously (in accordance with the efficient manner of the hardware involved) handle different types of circuits under test (CUTs) and different numbers of instances, each type of instance may exist in a single IP or throughout the entire system.
[0041] It should be understood that, as used herein, the term “circuit under test” (and therefore the phrase “at least one” circuit under test) can be applied to multiple instances of different DUTs (designs under test) that have different complexities and are (completely) independent of each other (e.g., belong to different subsystems, design units, etc. in the device).
[0042] One or more embodiments involve reduced area overhead. This also facilitates the application of runtime LBIST features to small logic blocks, such as ECC check / correction and generation (1). These are currently present in various automotive IPs and may be affected by potential failures.
[0043] Today, various CAD vendors have proposed proprietary solutions for automatically inserting LBIST schemes into SoCs or IPs.
[0044] Despite the flexibility in designing and generating LBIST schemes, automatically generated and inserted LBIST schemes may not be able to provide concurrent testing for different types of CUTs using a single LFSR and internal controller.
[0045] This limitation makes it difficult to find a satisfactory trade-off between parameters such as area overhead, test coverage, and time. This can be the case when the cut is not particularly complex (e.g., logic blocks are used to generate and inspect different types of ECC schemes).
[0046] The highly configurable LBIST scheme discussed here is able to handle both complex and simple cuts that may exist in IP or SoC due to its (static / dynamic) flexibility.
[0047] One or more embodiments are based on a hierarchical architecture comprising different types of sub-blocks, each dedicated to a specific function, the number of which and their internal parallelism can be configured (statically) via (static) RTL parameters during the configuration or design phase. Furthermore, internal connectivity and their parallelism can be varied based on values set for design parameters.
[0048] like Figure 1A and Figure 1B The architecture shown is built around the Advanced Peripheral Bus (APB) and is designed to work with the Fault Collection Unit Interface (FCU Intf.) and the Self-Test Control Unit Interface (STCU Intf.).
[0049] like Figure 1A As shown on the left side, for (at least) one circuit under test (200 – see also) Figure 3 The test stimulus (and related discussion below) is generated pseudo-randomly using a specific number of LFSRs (LFSR_1_1, LFSR_1_2, ..., LFSR_M_NM), collectively referred to as 12.
[0050] As previously discussed, the term "circuit under test" can be applied to multiple instances of different DUTs (designs under test) that have different complexities and are (completely) independent of each other (e.g., belonging to different subsystems, design units, etc. in a device).
[0051] like Figure 1A As shown on the left side, such a test stimulus (IN_TEST_DATA signal) can be associated with (in a manner known to those skilled in the art): a test mode indicator; SCAN_IN_EN and SCAN_OUT_EN enable signals for scan input and scan output enable; and a test capture signal TEST_CAPTURE.
[0052] like Figure 1B As shown, the circuit under test is collected and compressed in multiple input signature register blocks, collectively represented as 14 (see also 200). Figure 3 (and related discussion below) test results.
[0053] Each such block 14 includes a multi-input signature register (MISR - COMPRESSOR_1, COMPRESSOR_2, ..., COMPRESSOR_N) with associated registers (SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G), configured to store a "gold" value. At the end of a test activity or a single test session, this "gold" value is compared with the contents of the associated MISR: that is, the gold value stored in register SIGNATURE_X is compared with the value stored in MISR COMPRESSOR_X.
[0054] like Figure 1BAs shown, such test results may include (in a manner known to those skilled in the art) corresponding datasets, such as OUT_TEST_DATA_1, OUT_TEST_DATA_2, ..., OUT_TEST_DATA_X1; OUT_TEST_DATA_X1+1, OUT_TEST_DATA_X1+2, OUT_TEST_DATA_X1+X2; ...OUT_TEST_DATA_X1+X2+...XN-1+1, OUT_TEST_DATA_X1+X2+...XN-1+2, ..., OUT_TEST_DATA_X1+X2+...XN-1+XN.
[0055] As shown in Figure 1, the test activities for each instantiated LFSR 12 can be configured at runtime by the associated control logic, LFSR_X_X_CNTRL (i.e., LFSR_1_1_CTRL, LFSR_1_2_CTRL, ..., LFSR_M_NM_CTRL, in...). Figure 1A The common designation is 16) which has an internal control register LBIST_X_X_CTRL_REG (i.e., LBIST_1_1_CTRL_REG, LBIST_1_2_CTRL, ..., LBIST_M_NM_CTRL, in Figure 1A The common value is 18, and it has an associated timer T, which is written via software through the interface APB.
[0056] Based on the configuration written therein, each control logic module LFSR_X_X_CNTRL (i.e. LFSR_1_1_CTRL, LFSR_1_2_CTRL, ..., LFSR_M_NM_CTRL) in the set of 16 is specified to drive all output control signals of a specific LFSR12 (LFSR_1_1, LFSR_1_2, ..., LFSR_M_NM).
[0057] Note that the control signals driven by each block LFSR_X_X_CNTRL (16, i.e. LFSR_1_1_CTRL, LFSR_1_2_CTRL, ..., LFSR_M_NM_CTRL) include TEST_MODE, SCAN_IN, etc., in addition to EN&CLR.
[0058] In short, Figure 1A Therefore, this is an example of circuit 10, comprising: a test stimulus generator group 12, each generator in the group being activating to generate test stimulus information for at least one circuit under test based on test stimulus information loaded into the test stimulus registers LFSR_1_1, LFSR_1_2, ..., LFSR_M_NM in the generator 12. Figure 3The test stimulus signal IN_TEST_DATA in 200); the controller group is collectively designated as 16, namely LFSR_1_1_CTRL, LFSR_1_2_CTRL, ..., LFSR_M_NM_CTRL, each controller in this group is configured to control the loading of test stimulus information in the test stimulus registers LFSR_1_1, LFSR_1_2, ..., LFSR_M_NM in the corresponding generator of the test stimulus generator 12 according to the test control information loaded into the corresponding control registers LBIST_1_1_CTRL_REG, LBIST_1_2_CTRL_REG in a control register group 18 collectively referred to as 18. The test programming interface APB is configured to load test programming information, such as START, MULTI_CYCLE, TIMERMODE, N_CAPTURE_CYCLES, N_TSESSIONS_x_x, and N_TCYCLES_x_x, into the control register 18 as described below. The test stimulus generator 12 can be activated based on the test programming information (e.g., START, MULTI_CYCLE, TIMERMODE, N_CAPTURE_CYCLES, N_TSESSIONS_x_x, and N_TCYCLES_x_x) loaded into the control register 18 via the test programming interface APB.
[0059] In the event of a mismatch between the calculated signature and the expected signature detected in the signature control modules SIGN_1_CTRL, SIGN_2_CTRL, ..., SIGN_N_CTRL, error signals ERR_1, ERR_2, ..., ERR_N can be triggered on the FCU interface FCU Intf at the end of the test activity. Figure 1B The Chinese collectively refer to it as 20.
[0060] In short, Figure 1B An example is provided: input signature register groups SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G, configured to store signature reference signals indicating signature reference values received from the test programming interface (APB), and signature control circuit devices 14, 20, 22, 32 including signature control module groups SIGN_1_CTRL, SIGN_2_CTRL, ..., SIGN_N_CTRL coupled to a corresponding one of the input signature registers SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G.
[0061] As shown in this document, the signature control circuit device is configured to: receive a signature from at least one circuit under test ( Figure 3 The circuit under test (200) receives test result signals OUT_TEST_DATA_1, ..., OUT_TEST_DATA_X1+X2+...+XN-1+XN in response to the excitation signal IN_TEST_DATA applied to it via generator 12, and generates (e.g., at 32) signature comparison signals COMPRESSOR_1, COMPRESSOR_2, ..., COMPRESSOR_N from the test result signals OUT_TEST_DATA_1, ..., OUT_TEST_DATA_X1+X2+...+XN-1+XN, which are compared in the signature control modules SIGN_1_CTRL, SIGN_2_CTRL, ..., SIGN_N_CTRL with the corresponding signature reference signals stored in the input signature register groups SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G, wherein the test result signals are received from one or more circuits under test (200).
[0062] Error signals ERR_1, ..., ERR_N can therefore be generated in response to signature comparison signals COMPRESSOR_1, COMPRESSOR_2, ..., COMPRESSOR_N generated from test result signals OUT_TEST_DATA_1, ..., OUT_TEST_DATA_X1+X2+...+XN-1+XN received by at least one circuit under test 200, which fail to match the corresponding signature reference signals stored in the input signature registers SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G.
[0063] It should be noted that one or more embodiments primarily relate to the (self-test) architecture under discussion, and not to the selection / programming of signature reference signals stored in the input signature registers SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G and / or... Figure 1B The standard used for matching or mismatch checks performed in the signature control modules SIGN_1_CTRL, SIGN_2_CTRL, ..., SIGN_N_CTRL, collectively referred to as 20.
[0064] These standards can be selected based on factors such as the nature and type of the circuit under test, the intended application, and the type of test being performed. It should also be noted that the test architecture discussed herein is largely "transparent" to these standards, allowing for the selection of a variety of possible options known to those skilled in the art.
[0065] As shown in the figure, an internal status register 22 can be provided for more refined error analysis, with one status bit for each test cluster.
[0066] The end of the LFSR test activity can be signaled by using a pulse from the interrupt interface, with one interrupt channel for each exemplified LFSR.
[0067] Each sub-block and associated (static) configuration parameter in the architecture of circuit 10 as discussed herein can be defined in a way that adapts the architecture to a variety of possible test criteria and scenarios (e.g., given the underlying concepts of test sessions, the development of test activities, and / or test clusters adopted for testing purposes).
[0068] The architecture and sub-blocks of circuit 10 discussed in this paper help define a set of static configuration parameters that overcome various shortcomings of traditional solutions.
[0069] Table I below contains a possible list of configuration parameters available to designers.
[0070] Table I - Configuration Parameters
[0071]
[0072]
[0073] In the case of 1D vector parameters, the [] symbol is used to indicate its dimension, while sum() is used to indicate the sum of array elements.
[0074] In detail, in an exemplary embodiment, these parameters may include: an integer N_LFSR_TYPES, representing the number of different LFSR types existing in the architecture; an integer vector LFSR_TYPE[N_LFSR_TYPES], one for each type, encoding the LFSR type information (e.g., 32-bit for a 32-bit LFSR, 16-bit for a 16-bit LFSR, etc.); an integer vector N_LFSR[N_LFSR_TYPES], representing the number of instances of each LFSR type, where the total number of instances is given by the internally derived parameter N_LFSR_TOT = sum(N_LFSR), an internal parameter whose value is automatically calculated by the code and cannot be set by the user; an integer vector LFSR_P[N_LFSR_TOT], one for each LFSR instance, indicating its output parallelism; and an integer vector N_T_CLUSTER[N_LFSR_TOT], one for each LFSR instance, representing the number of test clusters processed in parallel by each LFSR.
[0075] As discussed here, a test cluster is a group of a specific number of CUTs (#N) that are tested consecutively using a public test session repeated #N times. Typically, the CUTs are of the same type, and a dedicated test wrapper is inserted for each test cluster. When the test session is a collection of generated input test data, the total number of test clusters is given by the internally derived parameter: N_T_CLUSTER_TOT = sum(N_T_CLUSTER).
[0076] According to this exemplary embodiment, these parameters may further include: an integer vector SIN_L[N_T_CLUSTER_TOT], one per test cluster, indicating the maximum length of the CUT input scan chain associated with that particular cluster; an integer vector SOUT_L[N_T_CLUSTER_TOT], one per test cluster, indicating the maximum length of the CUT output scan chain associated with that particular cluster; an integer vector #N_TSESSIONS[N_T_CLUSTER_TOT], one per test cluster, indicating the maximum number of test sessions that can be programmed to be executed continuously for that particular cluster; an integer #N_MISR_TYPES, indicating the number of different instantiated signature types within the architecture; an integer vector MISR_TYPE[N_MISR_TYPES], one for each type, encoding signature type information (e.g., 32 for a 32-bit MISR, 16 for a 16-bit MISR, etc.); and an integer vector N_MISR[N_MISR_TYPES], indicating the number of instances of each signature type. The total number of instances is given by the internally derived parameter: N_MISR_TOT = sum(N_MISR) if <= N_T_CLUSTER_TOT, otherwise mark as an error.
[0077] Also according to this exemplary embodiment, these parameters may further include: an integer vector MISR_P[N_MISR_TOT], one for each signature instance, indicating its input parallelism; an integer vector N_TINPUTS_P[N_T_CLUSTER_TOT], one for each input test data signal, representing its parallelism, the number of different input test data equals the total number of test clusters; an integer vector N_MISR_TINPUTS[N_MISR_TOT], one for each signature, indicating the number of input test data signals / test clusters associated with that particular signature, sum(N_MISR_TINPUTS) equals N_T_CLUSTER_TOT, otherwise an error is marked; and a Boolean parameter array TIMER_MODE[N_LFSR_TOT], used to enable / disable the presence of an internal timer for each LFSR.
[0078] Now will provide including, as Figure 1A and Figure 1B A detailed description of the exemplary sub-blocks in the illustrated architecture and a description of the possible impact of the related configuration parameters.
[0079] Used to fill the test package input scan chain (as combined below) Figure 3 The test stimulus (discussed) Figure 1A The left-hand side is generated pseudo-randomly using an internal LFSR such as 12, whose type, number, and output parallelism are statically defined.
[0080] Output parallelism representation is found to be a useful method for adjusting test time because it helps to change the time involved in filling the input scan chain. The choice of LFSR type is related to the coverage objective and CUT complexity.
[0081] Controller module (e.g.) Figure 1A Those that are commonly specified as 18 can be automatically generated and associated with each LFSR instance to drive its control signals and the control signals of the associated external test wrapper / cluster (e.g., TEST_CAPTURE, SCAN_IN_EN, SCAN_OUT_EN, TEST_MODE, etc.).
[0082] Each controller module 16 can be programmed via SW through dedicated control registers (LBIST_1_1_CTRL_REG, LBIST_1_2_CTRL_REG, ..., LBIST_M_NM_CTRL_REG) in registers collectively referred to as register 18, and has Figure 2 The structure of the general-purpose register LBIST_x_x_CTRL_REG is shown.
[0083] like Figure 2 As shown, apart from the START bit, the MULTI_CYCLE and TIMERMODE fields, and the number of N_CAPTURE_CYCLES, for the i-th controller, there are N_TSESSIONS and N_TCYCLES register fields equal to the number of associated test clusters N_T_CLUSTER[i] (suffixes omitted for simplicity).
[0084] Table II shown below contains a detailed description of the fields in the register LBIST_x_x_CTRL_REG.
[0085] Table II – Fields in register LBIST_X_X_CTRL_REG.
[0086]
[0087] The START bit is used to initiate a test activity consisting of a certain number of test sessions via SW. The value of the test session can be programmed using the relative register field N_TSESSIONS. This value does not exceed the statically defined maximum value N_TSESSIONS[i].
[0088] For each test session, the desired number of test loops N_TCYCLES can also be programmed, which helps to adjust test coverage.
[0089] If (and only if) TIMER_MODE[i] is active, the timer mode can also be used to trigger test activities at regular time intervals without software intervention. In this case, the start signal can be obtained from the end-of-counter (EOC) signal of the internal counter programmed by the switch.
[0090] The N_CAPTURE_CYCLES register field is used to generate a configurable number of capture cycles, which helps increase test coverage when the CUT contains sequential elements. The MULTI_CYCLE field, if activated, can be used to insert additional clock cycles into the generation of the test capture signal.
[0091] Advantageously, the control registers LBIST_1_1_CTRL_REG, LBIST_1_2_CTRL_REG, ..., LBIST_M_NM_CTRL_REG can be configured to receive test programming information from the programming interface APB, which includes: the number of test sessions N_TSESSIONS_x_x where the test stimulus generator is activated to generate the test stimulus signal IN_TEST_DATA for at least one circuit under test 200, and / or the number of test cycles N_TCYCLES where the test stimulus generator 12 is activated in the test session for at least one circuit under test 200, and / or the timing test mode activation information TIMER_MODE where the test stimulus generator 12 is activated at the programming time, and / or the capture mode information N_CAPTURE_CYCLES indicating the number of capture cycles for the output test signal of at least one circuit under test 200.
[0092] In this case, the control registers LBIST_1_1_CTRL_REG, LBIST_1_2_CTRL_REG, ..., LBIST_M_NM_CTRL_REG can be configured to receive, from the test programming interface APB, N_CAPTURE_CYCLES indicating the number of capture cycles for the output test signal of at least one circuit under test 200, and information for inserting additional cycles into the capture mode information N_CAPTURE_CYCLES (in the MULTI_CYCLE field), in addition to the test control information containing capture mode information.
[0093] Figure 3 An exemplary test wrapper 200 is shown, which is configured to receive (for each test cluster) data from the associated LFSR (from LFSR_1_1, LFSR_1_2, ..., LFSR_M_NM, ...). Figure 1A The input test data is represented as 12) and passed to the input scan chain, and the generated test vector is provided to the CUT.
[0094] like Figure 3 As detailed herein (and also known in scan chain operations), from, for example Figure 1A and Figure 1B The input test data IN_TESTDATA(0), IN_TEST_DATA(1), etc. of the architecture 10 described herein can be applied to nodes in the logic circuit device LC (HW security mechanism or function block, such as most combinations) that provides the circuit under test or CUT.
[0095] The input test data IN_TEST_DATA(0), IN_TEST_DATA(1), ... can be used as a substitute for some of the "functional" signals IN_0(x), IN_1(x), IN_2(x), ..., IN_n-1(x) in the logic circuit device LC. The test data is applied to the logic circuit device LC via a multiplexer collectively referred to as multiplexer 24, which operates under the control of the test mode signal T_M, which is asserted to activate the test mode operation.
[0096] Signals OUT_0(x), OUT_1(x), OUT_2(x), ..., OUT_n-1(x) from nodes of the logic circuit device LC are applied to a multiplexer 26A in a set of flip-flops 26 connected in a cascaded scan chain arrangement controlled by the SCAN_OUT_EN and TEST_CAPTURE signals (generated in a manner known to those skilled in the art).
[0097] Reference numerals 28 in the figures collectively denote logic gates (e.g., AND gates) controlled by test mode signals T_M (e.g., negative) to transmit extracted “functional” outputs OUT_0(x), OUT_1(x), OUT_2(x), ..., OUT_m-1(x) from the logic circuit device LC.
[0098] like Figure 3 As shown, the output test data OUT_TEST_DATA(0), OUT_TEST_DATA(1)... are obtained from the test wrapper 200 (e.g., at the multiplexer 30 coupled to the scan chain 26).
[0099] In short, the scan chain shown in 26 includes a set of flip-flops connected together to function as a shift register when the design is in shift test mode (i.e., with a declared SCAN_OUT_EN enable signal).
[0100] For simplicity, referencing the input and output parallelism of 1, the first flip-flop in the scan chain is connected to the scan input, and the last flip-flop in the scan chain is connected to the scan output.
[0101] The scan chain operation can be viewed as comprising three phases: scan input (which is the scan input shift mode phase, where the FF in the chain is serially loaded via the scan input pin), capture (the design remains in functional timing mode, and the test mode response is captured), and scan output (which is the scan output shift mode phase, where the FF in the chain is unloaded via the scan output pin); the scan input phase can be performed simultaneously.
[0102] The structure and operation of the scan chain as described above, including the SCA_IN_EN enable signal and the signal derived from one of the flip-flops (e.g., FFn-2) applied to the multiplexer 24, are conventional in the art.
[0103] In this regard, as an example only, see S. Sharma: "Scan Chains: PnR Outlook" (see design-reuse.com), which is incorporated herein by reference.
[0104] For the purposes of this article, it will be understood that, through Figure 3 The selected CUT is identified by signal encoding, one-hot encoding, test session index, and test mode signal T_M driven by the LFSR controller.
[0105] The same signal T_M is used to route the CUT output to the wrapper output scan chain 26, and it is also gated during the test session (via gate 28) to avoid unwanted interference with the rest of the SoC / IP layout.
[0106] The number of FFs in the scan chain of the i-th test wrapper can be automatically changed based on the values for LFSR_P[i] and N_TINPUTS_P[i], which is advantageous in terms of area cost.
[0107] like Figure 1B As shown on the right-hand side, the so-called inner "funnels," FUNNEL_1, FUNNEL_2, ..., FUNNEL_N (collectively referred to as 32), can be used to associate the corresponding datasets, such as...
[0108] OUT_TEST_DATA_1, OUT_TEST_DATA_2,…, OUT_TEST_DATA_X1;
[0109] OUT_TEST_DATA_X1+1, OUT_TEST_DATA_X1+2, OUT_TEST_DATA_X1+X2;
[0110] …
[0111] OUT_TEST_DATA_X1+X2+…XN-1+1, OUT_TEST_DATA_X1+X2+…XN-1+2,…, OUT_TEST_DATA_X1+X2+…XN-1+XN,
[0112] To a single signature register SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G(SIGNATURE_N_G(see Figure 1B (14) has its own parallelism.
[0113] These funnels can be used as follows: Figure 4 The structure shown is used to achieve this.
[0114] exist Figure 4 In the illustrated arrangement, the data from the above set are briefly indicated as X1_0, X1_1, X1_2, ..., X1_p1-1; X2_0, X2_1, ..., X2_p2-1; in the arrangement of... Figure 1B Under the control of the enable signals EN_1, EN_2, ..., EN_n (one for each input signal) generated by the funnel configuration registers (funnel_x_cfg, configured via software through interface APB) labeled 32_1, 32_2, ..., 32_N, Xn_0, ..., Xn_pn-1 are selected via AND gate 320 and then provided to the EX-OR logic circuit 322. The EX-OR logic circuit device 322 generates the signal to be applied to... Figure 1B The funnel-shaped signals s_0, s_1, s_2, ..., s_x of the MISR block COMPRESSOR_X(COMPRESSOR_1, COMPRESSOR_2, ..., COMPRESSOR_N).
[0115] like Figure 4 As shown, each X-OR gate in circuit 322 can receive two "same source" inputs, such as X1_0 and X2_0.
[0116] Following the gating stage (i.e., the AND gates collectively designated as 320), a compression stage is provided, comprising an x-bit X-OR gate collectively designated as 322. Here, the value x represents a funnel 32 ( Figure 1B The compression ratio is the ratio between the total number of input bits and the funnel (p1+p2+…). The total number of output bits from the funnel is also considered.
[0117] This last value is equal to the input parallelism of the associated signature and is statically defined by the MISR_P[N_MISR_TOT] parameter. Figure 4 In the example, by way of a non-restricted example, x = 2: In fact, each X-OR gate 322 is shown as having two inputs.
[0118] As an implementation specification, the ratio x is an integer: for example, in the case of x = 3, an X-OR gate 322 with three inputs is used.
[0119] like Figure 4As shown (illustratively, to avoid overly complex representation), the connection between AND gate 320 and X-OR gate 322 results in the output signal from AND gate 320 being grouped into groups of x elements, each element starting with bit 0 of signal X1, continuing with bit 0 of signal X2, and so on until bit 0 of signal Xn, then continuing with bit 1 of signal X1, then continuing with bit 1 of signal X2, and so on until bit 1 of signal Xn, with all bits from signal X1 to Xn continuing in the same manner.
[0120] When all bits of a signal are connected, the signal is removed from the process and the process jumps to the bits of the first subsequent signal that still needs to be managed. In this way, signals with different amplitudes can be combined together.
[0121] therefore, Figure 4 This is an example of a possible, non-mandatory implementation of a signature control circuitry, which is configured to respond to an excitation signal IN_TEST_DATA applied to at least one circuit under test (...). Figure 3 In circuit 200, multiple instances of circuit 200 (with multiple output groups) receive multiple sets of test result signals. The compressor circuit is configured to generate a corresponding signature comparison signal COMPRESSOR_1, COMPRESSOR_2, ..., COMPRESSOR_N from each of the multiple sets of test result signals from at least one circuit under test 200, for comparison with the corresponding reference signal in the signature control module group SIGN_1_CTRL, SIGN_2_CTRL, ..., SIGN_N_CTRL.
[0122] During testing, in addition to the corresponding MISR processing, potential mismatches between input and output data parallelism can be addressed with or without additional data compression.
[0123] Adding compression may affect test coverage in some way, potentially causing false masking due to aliasing, but it can also reduce test time.
[0124] The dedicated configuration register specifies which funnel input is active. Figure 1B The funnel / signature configuration registers 32_1, 32_2, ..., 32_N in the system have a configuration register for the funnel / signature instance.
[0125] Test output data generated during a test session or test activity is compressed into multiple input signature registers (see...). Figure 1B In section 14), its parallelism is statically defined as the type and number of the inscribed signatures.
[0126] Each MISR block COMPRESSOR_1, COMPRESSOR_2, ..., COMPRESSOR_N is associated with a corresponding register SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G, which can be written via the SW through the interface APB to store the expected / gold signature of a single test session or the entire test activity.
[0127] At the end of a single test session or at the end of the entire test activity of the associated LFSR, a comparison can be configured via the SW using the funnel / signature configuration register as a comparison between the calculated “signature” values generated by the test and stored COMPRESSOR_1, COMPRESSOR_2, ..., COMPRESSOR_N, and the “gold” values stored in the corresponding registers such as SIGNATURE_1_G, SIGNATURE_2_G, ..., SIGNATURE_N_G.
[0128] Note again that the embodiments primarily relate to the (self-test) architecture, rather than to the standards employed to obtain these test signatures and / or perform match or mismatch checks in the signature control module.
[0129] These standards can be selected as a function of factors such as the nature and type of the circuit under test, the intended application, and the type of test being performed. It should also be noted that the test architectures discussed herein are largely “transparent” to these standards, allowing selection from a variety of possible options known to those skilled in the art.
[0130] Therefore, this architecture is suitable for a wide variety of devices, including: Figure 1A and Figure 1B The first circuit 10 illustrated herein, and as shown in the figure Figure 3 At least one second circuit 200, illustrated herein and configured to be brought to a test mode (signal T_M), wherein during the test mode, the at least one second circuit is coupled to: a test excitation generator group 12 in the first circuit 10 to receive test excitation signals therefrom (e.g., IN_TEST_DATA and associated signals, as previously discussed), and signature control circuit devices 14, 20, 22, 32 to provide test result signals thereto in response to the excitation signals applied thereto, such as OUT_TEST_DATA_1, ..., OUT_TEST_DATA_X1+X2+...+XN-1+XN.
[0131] like Figure 3As shown, the at least one second circuit 200 includes: a logic circuit device LC as a test candidate, and scan chain circuits 24, 26, which are configured to: apply test input data IN_0(x), IN_1(x), ..., IN_n-1(x) to the logic circuit device LC during a test mode according to a test excitation signal from the test excitation generator 12 in the first circuit 10, and recover test output signals OUT_0(x), OUT_1(x), ..., OUT_M-1(x) from the logic circuit device LC during a test mode, and apply the test output signals to signature control circuit devices 14, 20, 22, 32 in the first circuit 10 according to test result signals OUT_TEST_DATA_1, ..., OUT_TEST_DATA_X1+X2+...+XN-1+XN.
[0132] The architecture and associated set of RTL configuration parameters discussed here are advantageous when testing various types and configurations of IP and SoC-level cuts, overcoming some limitations of traditional solutions. This is particularly useful when testing a simple cut structure that handles many different types and instances simultaneously without replicating the LBIST controller.
[0133] For example, the various aspects discussed herein have been successfully used in conjunction with EDPA security mechanisms, as disclosed in Italian Patent Application No. 102020000009358 and Italian Patent Application No. 102020000029759 (which were publicly available at the time of filing this application), which comply with the ISO 26262ASIL-D coverage specification for LPF, with reduced area overhead and testing time.
[0134] Without departing from the basic principles, details and embodiments may be changed, even significantly changed, relative to what has been described by example only, without departing from the scope of protection.
Claims
1. A test circuit, comprising: A test stimulus generator group, wherein each test stimulus generator in the test stimulus generator group can be activated to generate a test stimulus signal for at least one circuit under test based on test stimulus information loaded in a test stimulus register in the test stimulus generator; A controller group, wherein each controller in the controller group is configured to control the loading of test stimulus information into the test stimulus register of the corresponding generator in the test stimulus generator group according to test control information loaded into the corresponding control register in the corresponding control register in a control register group; A test programming interface is configured to load test programming information into the control register in the control register group, wherein the test stimulus generator in the test stimulus generator group can be activated according to the test programming information loaded into the control register in the control register group via the test programming interface; An input signature register group is configured to store a signature reference signal indicating a signature reference value received from the test programming interface. as well as A signature control circuit device, comprising a signature control module group coupled to a corresponding signature register in the input signature register group, the signature control circuit device being configured to: In response to the test excitation signal applied to the at least one circuit under test, a test result signal is received from the at least one circuit under test. A signature comparison signal is generated based on the test result signal received from the at least one circuit under test. In the signature control module group, the signature comparison signal generated based on the test result signal received from the at least one circuit under test is compared with the corresponding signature reference signal in the input signature register group, and An error signal is generated in response to a mismatch between the signature comparison signal generated based on the test result signal received from the at least one circuit under test and the corresponding signature reference signal in the input signature register set; The signature control circuitry further includes a compressor circuitry configured to receive a plurality of test result signal groups from the at least one circuit under test in response to a test excitation signal applied to the at least one circuit under test. The compressor circuitry includes: Two AND gates are controlled by corresponding enable signals generated by one or more funnel configuration registers, each of which is configured to associate a corresponding dataset with a single input signature register via software in the test programming interface. as well as The XOR gate is coupled to the corresponding outputs of the two AND gates.
2. The test circuit according to claim 1, wherein the control register in the control register group is configured to receive test programming information from the test programming interface, the test programming information including: The number of test sessions, for which the test stimulus generators in the test stimulus generator group are activated to generate test stimulus signals for the at least one circuit under test. The number of test cycles, for which the test stimulus generator in the test stimulus generator group is activated in a test session for the at least one circuit under test. The timed test mode activation information is used to activate the test stimulus generator in the test stimulus generator group at the programming time, or The capture mode information indicates the number of capture cycles for the output test signal of the at least one circuit under test.
3. The test circuit of claim 2, wherein the control register in the control register group is configured to receive test control information from the test programming interface, the test control information including capture mode information indicating the number of capture loops for the output test signal of the at least one circuit under test, and information for inserting additional loops in the capture mode information.
4. The test circuit according to claim 1, wherein each test stimulus generator in the test stimulus generator group includes a linear feedback shift register as the test stimulus register in the test stimulus generator.
5. The test circuit of claim 1, wherein the test excitation generator group is configured to generate the test excitation signal for the at least one circuit under test, the at least one circuit under test having a signal coupled thereto, including: Test mode indicator signal; Scan input and scan output enable signals; or Test the captured signal.
6. The test circuit of claim 1, wherein the compressor circuit device is configured to generate a corresponding signature comparison signal based on each of the plurality of test result signal groups from the at least one circuit under test, for comparison with a corresponding reference signal in the signature control module group.
7. A testing apparatus, comprising: The circuit according to claim 1; as well as At least one additional circuit is configured to be brought into a test mode, wherein during the test mode, the at least one additional circuit is coupled to: The test excitation generator group in the circuit receives the test excitation signal therefrom, and The signature control circuit device provides the test result signal to it in response to the test stimulus signal applied thereto.
8. The testing apparatus according to claim 7, wherein the at least one additional circuit comprises: The logic circuit device to be tested; as well as The scan chain circuit device is configured as follows: During the test mode, test input data is applied to the logic circuit device according to the test stimulus signal from the test stimulus generator group in the circuit. During the test mode, the test output signal is recovered from the logic circuit device, and The test output signal is applied as a test result signal to the signature control circuit device in the circuit.
9. A test circuit, comprising: A test stimulus generator group is configured to generate test stimulus signals for at least one circuit under test; A controller group, coupled to the test stimulus generator group and configured to control the loading of test stimulus information in the test stimulus generator group; as well as A test programming interface is coupled to the controller group and configured to load test programming information into the controller group, and the test stimulus generator group can be configured by the controller group via software using the test programming interface during runtime; An input signature register group is configured to store a signature reference signal indicating a signature reference value received from the test programming interface. as well as A signature control circuit device, comprising a signature control module group coupled to a corresponding signature register in the input signature register group, wherein the signature control circuit device is separate from the controller group. The signature control circuitry further includes a compressor circuitry configured to receive a plurality of test result signal groups from the at least one circuit under test in response to a test excitation signal applied to the at least one circuit under test. The compressor circuitry includes: Two AND gates are controlled by corresponding enable signals generated by one or more funnel configuration registers, each of which is configured to associate a corresponding dataset with a single input signature register via software in the test programming interface. as well as The XOR gate is coupled to the corresponding outputs of the two AND gates.
10. The test circuit according to claim 9, wherein the signature control circuit device is configured as follows: In response to the test excitation signal applied to the at least one circuit under test, a test result signal is received from the at least one circuit under test. A signature comparison signal is generated based on the test result signal received from the at least one circuit under test. In the signature control module group, the signature comparison signal generated based on the test result signal received from the at least one circuit under test is compared with the corresponding signature reference signal in the input signature register group, and An error signal is generated in response to a mismatch between the signature comparison signal generated based on the test result signal received from the at least one circuit under test and the corresponding signature reference signal in the input signature register set.
11. The test circuit of claim 10, wherein the compressor circuit device is configured to generate a corresponding signature comparison signal based on each of the plurality of test result signal groups from the at least one circuit under test, for comparison with a corresponding reference signal in the signature control module group.
12. The test circuit according to claim 9, further comprising: A control register group is configured to receive test programming information from the test programming interface, the test programming information including the number of test sessions, and to activate the test stimulus generators in the test stimulus generator group for the number of test sessions to generate test stimulus signals for the at least one circuit under test.
13. The test circuit according to claim 9, further comprising: A control register group is configured to receive test programming information from the test programming interface, the test programming information including a number of test cycles, and to activate a test stimulus generator in the test stimulus generator group for the at least one circuit under test in a test session for the number of test cycles.
14. The test circuit according to claim 9, further comprising: The control register group is configured to receive test programming information from the test programming interface, the test programming information including timed test mode activation information for activating the test stimulus generators in the test stimulus generator group at programming time.
15. The test circuit according to claim 9, further comprising: A control register group is configured to receive test programming information from the test programming interface, the test programming information including capture mode information indicating the number of capture cycles for the output test signal of the at least one circuit under test.
16. The test circuit of claim 15, wherein the control register set is further configured to receive test control information from the test programming interface, the test control information including information for inserting additional loops into the capture mode information.
17. A testing method, comprising: A test stimulus signal is applied to at least one circuit under test, the test stimulus signal being generated in the test stimulus generator group according to test stimulus information loaded in the test stimulus register in the test stimulus generator group; Using a controller group, the loading of test stimulus information in the test stimulus register of the test stimulus generator is controlled according to the test programming information in the corresponding control register loaded into the control register group; and the test stimulus generator in the test stimulus generator group is activated according to the test programming information in the control register loaded into the control register group. In response to the test excitation signal applied to the at least one circuit under test via a compressor circuit, a plurality of test result signal groups are received from the at least one circuit under test, wherein the signature control circuit device is separate from the controller group, and the plurality of test result signal groups pass through two AND gates and an XOR gate, wherein the two AND gates are controlled by corresponding enable signals generated by one or more funnel configuration registers, and the XOR gates are coupled to the corresponding outputs of the two AND gates; A signature comparison signal is generated based on the test result signal received from the at least one circuit under test; The signature comparison signal generated based on the test result signal received from the at least one circuit under test is compared with the corresponding programmable signature reference signal stored in the input signature register set; as well as An error signal is generated in response to a mismatch between the signature comparison signal generated based on the test result signal received from the at least one circuit under test and the corresponding programmable signature reference signal stored in the input signature register set.
18. The test method according to claim 17, wherein the test programming information includes: The number of test sessions, for which the test stimulus generators in the test stimulus generator group are activated to generate test stimulus signals for the at least one circuit under test. The number of test cycles, for which the test stimulus generator in the test stimulus generator group is activated in a test session for the at least one circuit under test. The timed test mode activation information is used to activate the test stimulus generator in the test stimulus generator group at the programming time, or The capture mode information indicates the number of capture cycles for the output test signal of the at least one circuit under test.
19. The test method of claim 18, wherein the control register in the control register group is further configured to receive test control information, the test control information including capture mode information indicating the number of capture cycles for the output test signal of the at least one circuit under test, and information for inserting additional cycles in the capture mode information.
20. The test method according to claim 17, further comprising: The compressor circuit generates a corresponding signature comparison signal for comparison with a corresponding programmable signature reference signal from each of the plurality of test result signal groups from the at least one circuit under test.