CN115144725A - Test architecture for electronic circuits, corresponding devices and methods - Google Patents

Abstract

Embodiments of the present disclosure relate to test architectures, corresponding devices and methods for electronic circuits. Test stimulus signals for application to at least one circuit under test are generated in a test stimulus generator set in dependence on the test stimulus information loaded in the test stimulus register. The loading of the test stimulus information in the test stimulus registers is controlled in accordance with the test programming information loaded into the respective control registers in the set of control registers via the programming interface. Activating a test stimulus generator according to test programming information loaded in the control register. The test result signal received from the at least one circuit-under-test is used to generate a signature comparison signal that is compared to a corresponding programmable signature reference signal stored in an input signature register set, the signature comparison signal being generated in response to a mismatch between the signature comparison signal generated from the test result signal and the corresponding reference signal.

Description

Test architecture for electronic circuits, corresponding devices and methods

Cross Reference to Related Applications

The disclosures in italian application No.102021000007856, filed on 30/3/2021, which is hereby incorporated by reference in its entirety, are claimed as priority.

Technical Field

The present application relates to testing electronic circuits, and in particular embodiments, to logic built-in self test (LBIST) architectures.

Background

Today, in fields such as the automotive field, electronic devices are no longer used only for implementing in-vehicle comfort features. Electronics are now widely concerned with implementing passive/active safety systems with the aim of preventing or at least reducing injury to the driver and passengers: the related functions may include functions such as forward collision warning, blind spot monitoring, automatic emergency braking, air bag and ABS features.

This is the basis for adopting specifications such as the ISO 26262 standard, which is applied to design automotive electronics to provide a common basis for evaluating and recording safety levels in electrical and electronic (E/E) systems.

To detect possible faults in the implemented safety mechanisms, potential point faults (LPFs) or Single Point Faults (SPFs) in the functional logic blocks, adequate satisfaction of safety specifications such as ISO 26262 is facilitated by periodic online testing.

Despite the extensive activity in this area, products such as socs, as well as other products for the automotive market, may benefit from the availability of configurable online BIST mechanisms that can test various Hardware (HW) security mechanisms in an efficient manner.

Disclosure of Invention

One or more embodiments of the present application facilitate providing a highly configurable LBIST architecture for online/offline testing of (sub) systems.

One or more embodiments may relate to a corresponding apparatus. A semiconductor device such as an SoC that includes a self-test control architecture as shown herein (possibly in combination with associated scan chain circuitry) may be an example of such a device.

One or more embodiments may be directed to a corresponding method.

One or more embodiments may provide one or more of the following advantages. By selecting (static) configuration parameters, a sufficient trade-off between area cost and performance targets (test coverage, test time) can be achieved. Integration among multiple simple/complex digital subsystems can be achieved for full/partial online LBIST testing of the system and subsystems. A full set of safety designs/circuit devices or only a programmable/configurable subset may be involved in testing. One or more test sessions may be triggered at runtime (e.g., via software) with reduced area overhead. Modules involved in a test session may be tested sequentially or in parallel; this level of configurability helps to achieve a suitable compromise in terms of area, test time and coverage of various conditions. As a by-product, a general "rule of thumb" for correcting system size can be obtained.

Drawings

One or more embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which:

figures 1A and 1B collectively represent a block diagram of a circuit configuration according to an embodiment of the present description,

fig. 2 is an example of fields that may be provided in registers included in the architectures shown in fig. 1A and 1B.

FIG. 3 is a block diagram of a test circuit configured to cooperate with an architecture in accordance with an embodiment of the present specification, an

Fig. 4 is an exemplary circuit diagram of components of the circuit configuration of fig. 1B.

Detailed Description

In the following description, one or more specific details are set forth in order to provide a thorough understanding of the examples of embodiments described herein. Embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.

Reference to "an embodiment" or "one embodiment" within the framework of the specification is intended to indicate that a particular configuration, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, phrases such as "in an embodiment" or "in one embodiment" that may be present in one or more points of the specification do not necessarily refer to the same embodiment.

In addition, in one or more embodiments, a particular conformation, the structures or features may be combined in any suitable manner.

The headings/references used herein are provided for convenience only and thus do not define the scope of protection or the scope of the embodiments.

For the sake of brevity, various abbreviations are used throughout the specification.

Although known to those skilled in the art, many of these acronyms and their meanings are reproduced below for direct reference.

LBIST = logic built-in self-test

SoC = system on chip

IP = intellectual property (core or block: reusable logic, cell or IC layout design unit)

CAD = computer aided design

CUT = measured circuit

LFSR = linear feedback shift register

MISR = multiple input signature register

ECC = error correction code

FCU = fault collection unit

SPF = single point of failure

LPF = latent point fault

EDPA = enhanced data processing architecture

RTL = register transfer level

EOC = end of counter

One or more embodiments provide a (circuit) architecture for periodic online/offline LBIST operations.

The static and dynamic configurability of the architecture makes it suitable for testing various types of digital blocks (combinatorial or sequential).

This also applies to complex blocks (e.g., subsystems with many logic gates and memory elements).

Furthermore, one or more embodiments may handle different types of Circuits Under Test (CUT) and different numbers of instances simultaneously (in an efficient manner by the hardware involved), each type of instance may exist in a single IP or the entire system.

It should be appreciated that as used herein, the name "circuit under test" (hence, the term "at least one" circuit under test) may apply to multiple instances of different DUTs (designs under test) of different complexity and being (completely) independent of each other (e.g., belonging to different subsystems, design units, etc. in a device).

One or more embodiments relate to reduced area overhead. This also facilitates applying run-time LBIST features to small logical blocks, such as ECC checking/correcting and generating a one (1). These are currently present in various automotive IPs and may be affected by potential failures.

Today, various CAD vendors propose proprietary solutions to automatically insert LBIST schemes in SoC or IP.

Despite the flexibility in designing and generating LBIST schemes, an automatically generated and inserted LBIST scheme may not be able to provide concurrent testing for different types of CUTs using a single LFSR and internal controller.

This limitation does not facilitate a satisfactory compromise between parameters such as area overhead, test coverage and time. This may be the case when the CUT is not particularly complex (e.g., a logical block is used to generate and check different types of ECC schemes).

The highly configurable LBIST scheme discussed herein is able to handle complex and simple CUTs that may exist in IP or SoC due to its (static/dynamic) flexibility.

One or more embodiments are based on a hierarchical architecture comprising different types of sub-blocks, each dedicated to a specific function, the number and internal parallelism of which can be configured (statically) via a (static) RTL parameter during a configuration or design phase. Furthermore, the internal connections and their parallelism may vary depending on the values set for the design parameters.

The architecture shown in fig. 1A and 1B is structured around an Advanced Peripheral Bus (APB) and is intended to cooperate with a fault collection unit interface (FCU intf.) and a self-test control unit interface (STCU intf.).

As shown on the left-hand side of FIG. 1A, the test stimulus for (at least) one circuit under test (200-see also FIG. 3 and the related discussion below) is pseudo-randomly generated using a particular number of LFSRs (LFSR _1_1, LFSR _1_2, …, LFSR _ M _ NM), collectively referred to as LFSR _1_1, LFSR _1_2, …, LFSR _ M _ NM) 12.

As discussed previously, the name "circuit under test" may be applied to multiple instances of different DUTs (designs under test) of different complexity and that are (completely) independent of each other (e.g., belong to different subsystems, design units, etc. in a device).

As shown on the left-hand side of fig. 1A, such a TEST stimulus (IN _ TEST _ DATA signal) may be associated therewith (IN a manner known per se to the person skilled IN the art): a test mode indicator; the SCAN _ IN _ EN and SCAN _ OUT _ EN enable signals are used for SCAN input and SCAN output enable; and a TEST CAPTURE signal TEST _ CAPTURE.

As shown in FIG. 1B, test results of a circuit under test (200-see also FIG. 3 and related discussion below) are collected and compressed in a plurality of input signature register blocks collectively denoted 14.

Each such block 14 includes a multiple input SIGNATURE register (MISR-COMPRESSOR _1, COMPRESSOR _2, …, COMPRESSOR _ N) having an associated register (SIGNATURE _1_G, SIGNATURE _2_G, …, SIGNATURE _ N _ G) configured to store a "gold" value therein. At the end of a test activity or a single test session, such "gold" values are compared with the content of the associated MISR: that is, the gold value stored in the register signal _ X is compared with the value stored in the MISR composition _ X.

As shown in fig. 1B, such TEST results may include (in a manner known per se to those skilled in the art) a corresponding set of DATA, 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, OUT _TEST _DATA _X1+ X2+ … XN-1+2, …, OUT _ TEST _ DATA _ X1+ X2+ … XN-1+ XN.

As shown in FIG. 1, the testing activity of each instantiated LFSR12 may be configured at runtime by associated control logic, LFSR _ X _ X _ CNTRL (i.e., LFSR _1_1_CTRL, LFSR _1_2_CTRL, …, LFSR _ M _ NM, collectively designated as 16 in FIG. 1A) has an internal control register LBIST _ X _ CTRL _ REG (i.e., LBIST _1_1_CTRL _REG, LBIST _1_2_CTRL, 3262 zx3262, LBIST _ M _ NM _ REG, collectively designated as 18 in FIG. 1A, and has an associated timer T), which is written via software over interface APB.

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 designated 16 drives all output control signals of the particular LFSR12 (LFSR _1_1, LFSR _1_2, …, LFSR _ M _ NM).

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.

Briefly, fig. 1A is thus an example of a circuit 10, including: a set of TEST stimulus generators 12, each generator IN the set being activatable to generate a TEST stimulus signal IN _ TEST _ DATA for at least one circuit under TEST (200 IN FIG. 3) based on TEST stimulus information loaded into TEST stimulus registers LFSR _1_, LFSR _1_, 2, …, LFSR _ M _ NM IN the generators 12; the group of controllers collectively designated 16, namely LFSR _1_1_CTRL, LFSR _1_2_CTRL, …, LFSR _ M _ NM _ CTRL, each controller in the group is configured to control the loading of test stimulus information in test stimulus registers LFSR _1_1, SR _1_2, LFSR _ M _ NM in a respective one of the test stimulus generators 12 in accordance with test control information loaded into respective control registers LBIST _1_1_CTRL _, LBIST _1_2, …, LFSR _ M _ NM in a group of control registers 18, collectively referred to as 18; a test programming interface APB configured to load test programming information, such as START, MULTI _ CYCLE, timer, N _ CAPTURE _ CYCLEs, N _ TSESSIONS _ x _ x, N _ TCYCLES _ x _ x, as described below, in the control register 18, wherein the test stimulus generator 12 may be activated in accordance with the test programming information (e.g., START, MULTI _ CYCLE, timer, N _ CAPTURE _ CYCLEs, N _ TSESSIONS _ x _ x, N _ TCYCLES _ x _ x) loaded into the control register 18 via the test programming interface APB.

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, signature control modules SIGN _1_ctrl, SIGN _2_ctrl, …, SIGN _ N _ CTRL, which are collectively referred to as 20 in fig. 1B, can be triggered at the end of the test activity on the FCU interface FCU Intf.

Briefly, fig. 1B illustratively provides: an input SIGNATURE register set SIGNATURE _1_G, SIGNATURE _2_G, …, SIGNATURE _ N _ G configured to store therein SIGNATURE reference signals indicative of SIGNATURE reference values received from a test programming interface (APB), the SIGNATURE control circuitry 14, 20, 22, 32 including a SIGNATURE control block set SIGN _1_CTRL, SIGNATURE _2_G, …, SIGNATURE _ N _ G coupled to a respective one of the input SIGNATURE registers SIGNATURE _1_G, SIGNATURE _2_G, …, SIGN _ N _ CTRL.

As shown herein, the signature control circuitry is configured to: the TEST result signals OUT _ TEST _ DATA _1, …, OUT _ TEST _ DATA _ X1+ X2+ … + XN-1+ XN are received from at least one circuit under TEST (200 IN fig. 3) IN response to the excitation signal IN _ TEST _ DATA applied thereto via generator 12 and generated from the TEST result signals OUT _ TEST _ DATA _1, …, OUT _ TEST _ DATA _ X1+ X2+ … + XN-1 XN (e.g., at 32) the SIGNATURE comparison signals COMPRESSOR _1, COMPRESSOR _2, …, COMPRESSOR _ N, which are compared IN SIGNATURE control modules SIGN _1_ctrl, SIGN _2_ctrl, …, SIGN _ N _ CTRL to the corresponding SIGNATURE reference signals stored IN the input SIGNATURE register sets SIGN register _1 u G, SIGN register _2_g, …, SIGN register _ N _ G, with the TEST result signals received from the one or more circuits under TEST 200.

Error signals ERR _1, …, ERR _ N may thus 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 that fail to match the corresponding SIGNATURE reference signals stored in input SIGNATURE registers SIGNATURE _ DATA _1, …, OUT _ TEST _ DATA _ X1+ X2+ … + XN-1 XN _ XN stored in input SIGNATURE registers SIGNATURE _1_G, SIGNATURE _2_ _G, …, SIGNATURE _ N _ G.

It should be noted that one or more embodiments relate primarily to the (self-test) architecture in question, and not to the criteria employed for selecting/programming the SIGNATURE reference signals stored in the input SIGNATURE registers SIGNATURE _1_G, SIGNATURE _2_G, …, SIGNATURE _ N _ G and/or the match or mismatch checks performed in the SIGNATURE control modules SIGN _1_CTRL, SIGN _2_CTRL, …, SIGN _ N _ CTRL, collectively referred to as 20 in FIG. 1B.

These criteria may be selected based on factors such as the nature and type of circuit under test, the intended application, the type of test being performed, and the like. By additionally noting that the test architecture discussed herein is largely "transparent" to these standards, these standards may be selected among a variety of possible options known to those skilled in the art.

As shown, an internal status register 22 may be provided for finer error analysis, with one status bit per test cluster.

The end of the LFSR test activity may be signaled by using a pulse of the interrupt interface, one interrupt channel per the LFSR illustrated.

Each sub-block and associated (static) configuration parameters in the architecture of the circuit 10 as discussed herein may be defined in a manner that adapts the architecture to the various possible testing standards and scenarios (e.g., development of testing activities and/or test clustering employed for testing purposes in view of the underlying concept of testing sessions).

The architecture and sub-blocks of the circuit 10 architecture discussed herein facilitate defining a set of static configuration parameters that overcome various shortcomings of conventional solutions.

Table I shown below contains a possible list of configuration parameters that may be used by the designer.

TABLE I-configuration parameters

In the case of 1D vector parameters, the [ ] notation is used to represent its dimension, while sum () is used to indicate the sum of the array elements.

In detail, in an exemplary embodiment, these parameters may include: an integer N _ LFSR _ TYPES, representing the number of different LFSR TYPES present within the architecture; an integer vector LFSR _ TYPE [ N _ LFSR _ TYPE ], one for each TYPE, encodes LFSR TYPE information (e.g., 32-bit LFSR is 32-bit, 16-bit LFSR is 16-bit, 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 an internal derived parameter N _ LFSR _ TOT = sum (N _ LFSR), an internal parameter being a 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.

As discussed herein, a test cluster is a group consisting of a certain number # N of CUTs tested consecutively using a common 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 set of generated input test data, the total number of test clusters is given by an internal derived parameter: n _ T _ CLUSTER _ TOT = sum (N _ T _ CLUSTER).

According to this exemplary embodiment, the parameters may further include: an integer vector SIN _ L [ N _ T _ CLUSTER _ TOT ], one for each test CLUSTER, indicating the maximum length of the CUT input scan chain associated with that particular CLUSTER; integer vector SOUT _ L [ N _ T _ CLUSTER _ TOT ], one for each 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 for each test CLUSTER, indicating the maximum number of test sessions that can be programmed to execute consecutively 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 _ TYPE ], one of each TYPE, encodes signature TYPE information (e.g., 32-bit MISR of 32, 16-bit MISR of 16, 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 internal derived parameters: n _ MISR _ TOT = sum (N _ MISR) if < = N _ T _ CLUSTER _ TOT, otherwise an error is flagged.

Also according to this exemplary embodiment, these parameters may further include: integer vector MISR _ P [ N _ MISR _ TOT ], one per 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 being equal to the total number of test CLUSTERs; an integer vector N _ MISR _ TINPUTS [ N _ MISR _ TOT ], one for each signature, indicating the number of incoming test data signals/test CLUSTERs associated with that particular signature, sum (N _ MISR _ TINPUTS) equals N _ T _ CLUSTER _ TOT, otherwise an error is flagged; and a Boolean parameter array TIMER _ MODE [ N _ LFSR _ TOT ] for enabling/disabling the presence of an internal TIMER for each LFSR.

A detailed description of exemplary sub-blocks included in the architecture shown in fig. 1A and 1B and a description of possible effects of related configuration parameters will now be provided.

Test stimuli (left-hand side of fig. 1A) used to populate test wrapper input scan chains (as discussed below in connection with fig. 3) are generated pseudo-randomly using an internal LFSR such as 12, whose type, number, and output parallelism are statically defined.

Output parallelism has been found to represent a useful method for adjusting test time, as this helps to change the time involved in filling the input scan chain. The choice of LFSR type is related to the coverage target and CUT complexity.

Controller modules (such as those collectively designated 18 IN fig. 1A) may 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.).

Each controller module 16 may be programmed via SW through a dedicated one of the registers (LBIST _1_1_, CTRL REG, LBIST _1_, 2_, CTRL REG, …, LBIST _ M _ NM _ CTRL _ REG), collectively referred to as registers 18, and has the structure of general purpose registers LBIST _ x _ x _ CTRL _ REG shown in FIG. 2.

As shown in FIG. 2, in addition to the START bit, the MULTIPLE _ CYCLE and TIMEMODE fields, and the number of N _ CAPTURE _ CYCLES fields, for the ith controller, there are N _ TSESSIONS and N _ TCYCLES register fields (suffixes omitted for simplicity) equal to the number of associated test CLUSTERs N _ T _ CLUSTER [ i ].

Table II shown below includes a detailed description of the fields in register LBIST _ x _ x _ CTRL _ REG.

Table II-fields in register LBIST _ X _ CTRL _ REG.

The START bit is used to START a test activity via SW consisting of a number of test sessions whose values can be programmed using the relative register field N _ TSESSIONS. This value does not exceed the statically defined maximum value N _ TSESSIONS [ i ].

A desired number of test cycles N TCYCLES can also be programmed for each test session, which helps to adjust the test coverage.

The TIMER MODE can also be used to trigger test activity at regular intervals without software intervention if (and only if) TIMER _ MODE [ i ] is active. In this case, the start signal may be obtained from a counter End (EOC) signal of an internal counter whose period may be programmed by SW.

The N _ CAPTURE _ CYCLES register field is used to generate a configurable number of CAPTURE CYCLES, which helps to increase test coverage when the CUT contains sequential elements. The multiple _ CYCLE field, if activated, may be used to insert additional clock CYCLEs in the test capture signal generation.

In an advantageous manner, control registers LBIST _1_1_ctrl _REG, LBIST _1_2 _ctrlreg, …, LBIST _ M _ NM _ CTRL REG may be configured to receive test programming information from programming interface APB, the test programming information including: the TEST stimulus generator is activated to generate a number of TEST sessions N _ TSESSIONS _ x _ x for the TEST stimulus signal IN _ TEST _ DATA of the at least one circuit under TEST 200, and/or a number of TEST CYCLES N _ TCYCLES for activating the TEST stimulus generator 12 IN a TEST session for the at least one circuit under TEST 200, and/or a timed TEST MODE activation information TIMER _ MODE for activating the TEST stimulus generator 12 at programming time, and/or an acquisition MODE information N _ CAPTURE _ CYCLES indicating a number of acquisition CYCLES for the output TEST signal of the at least one circuit under TEST 200.

In this case, the control registers LBIST _1_1_ctrl _, LBIST _1_ctrl _, REG, …, LBIST _ M _ NM _ CTRL _ REG may be configured to receive N _ CAPTURE _ CYCLES indicating the number of CAPTURE CYCLES for the output test signal of the at least one circuit-under-test 200 and information (in the MULTI _ CYCLE field) to insert additional CYCLES in the CAPTURE mode information N _ CAPTURE _ CYCLES from the test programming interface APB and in addition to the test control information including the CAPTURE mode information.

FIG. 3 illustrates an exemplary test wrapper 200 configured to receive (for each test cluster) input test data from the associated LFSRs (from LFSR _1_1, LFSR _1_2, …, LFSR _ M _ NM, collectively represented as 12 in FIG. 1A) and transfer them to the input scan chains and provide the generated test vectors to the CUT.

As detailed IN fig. 3 (and otherwise known IN scan chain operation), the input TEST DATA IN _ TEST DATA (0), IN _ TEST _ DATA (1) … from architecture 10 as illustrated IN fig. 1A and 1B may be applied to nodes IN a logic circuit device LC (HW safety mechanism or functional block, e.g., most combinations) that provides a circuit under TEST or CUT.

The input TEST DATA IN _ TEST _ DATA (0), IN _ TEST _ DATA (1), … may be applied to the logic circuit device LC via multiplexers collectively referred to as multiplexers 24 acting under control of a TEST mode signal T _ M asserted to activate TEST mode operation, as a substitute for some of the "function" signals IN _0 (x), IN _1 (x), IN _2 (x), …, IN _ n-1 (x) IN the logic circuit device LC.

The signals OUT _0 (x), OUT _1 (x), OUT _2 (x), …, OUT _ n-1 (x) from the nodes of the logic circuit arrangement LC are applied to multiplexers 26A in a set of flip-flops 26 connected in a cascaded SCAN chain arrangement controlled by SCAN _ OUT _ EN and TEST _ CAPTURE signals (generated in a manner known per se to those skilled in the art).

Reference numerals 28 collectively denote logic gates (e.g., and gates) controlled by the test mode signal T _ M (e.g., negated) to transfer the extracted "functional" outputs OUT _0 (x), OUT _1 (x), OUT _2 (x), …, OUT _ M-1 (x) from the logic circuit device LC.

As shown in FIG. 3, the output TEST DATA OUT _ TEST _ DATA (0), OUT _ TEST _ DATA (1) … is obtained from the TEST wrapper 200 (e.g., at the multiplexers 30 coupled to the scan chains 26).

Briefly, the SCAN chain as shown at 26 includes a set of flip-flops coupled together to serve as a type of shift register when the design is in shift test mode (i.e., with the SCAN _ OUT _ EN enable signal asserted).

For simplicity, referring to input and output parallelism equal to 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.

Scan chain operation can be viewed as including three phases, namely scan-in (which is a scan-in shift mode phase in which FFs in the chain are serially loaded through scan-in pins), capture (the design remains in functional timing mode, test mode responses are captured) and scan-out (which is a scan-out shift mode phase in which FFs in the chain are unloaded through scan-out pins); the scan-in phase may be performed simultaneously).

The structure and operation of the scan chain as described above, including the SCA _ IN _ EN enable signal and a signal derived from one of the flip-flops (e.g., FFn-2) applied to multiplexer 24, is conventional IN the art.

In this regard, by way of example only, reference may be made to s.sharma: "Scan Chains: pnR Outlook" (see design-use. Com), which is incorporated herein by reference.

For purposes of this document, it will be appreciated that the selected CUT (in the network LC) is identified via the signal encoding, one-hot encoding, indexing of the test session, and the test mode signal T _ M driven by the LFSR controller in fig. 3.

The same signal T _ M is used to route the CUT output to the wrapper output scan chain 26 and at the same time gate it (via gate 28) during the test session in order to avoid unwanted interference with the rest of the SoC/IP arrangement.

The number of FFs for the scan chain of the ith test wrapper may be automatically changed according to values set for: LFSR _ P [ i ] and N _ TINPUTS _ P [ i ], are advantageous in terms of area cost

As shown on the right hand side of FIG. 1B, a so-called internal "FUNNEL," FUNNEL _1, FUNNEL _2, …, FUNNEL _ N (collectively 32) may be used to correlate a corresponding data set, 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，

To the single SIGNATURE registers SIGNATURE _1_G, SIGNATURE _2_G, …, SIGNATURE _ N _ G (see 14 in FIG. 1B), with their own parallelism.

These funnels may be implemented with a structure as shown in fig. 4.

In the arrangement illustrated in FIG. 4, the data from the above group is indicated briefly as X1_0, X1_1, X1_2, …, X1_ p1-1; x2_0, X2_1, …, X2_ p2-1; under control of enable signals EN _1, EN _2, …, EN _ N (one for each input signal) generated by a funnel configuration register labeled 32_1, 32_2, …,32 _Nin FIG. 1B (fund _ X _ cfg, configured via software through interface APB), xn _0, …, xn _ pn-1 is gated via AND gate 320 AND then provided to EX-OR logic circuit 322, EX-OR logic circuit device 322 generates "funneled" signals s _0, s _1, s _2, …, s _ X to be applied to MISR block COMPRESSOR _ X in FIG. 1B (COMPRESSOR _1, COMPRESSOR _2, …, COMPRESSOR _ N).

As shown in FIG. 4, each X-OR gate in circuit 322 may receive two "same source" inputs, e.g., X1_0 and X2_0.

After the gating stage (i.e., the AND gates collectively designated as 320), a compression stage is provided that includes an X-bit X-OR gate collectively designated as 322. Here, the value x represents the compression ratio of the funnel 32 (fig. 1B), i.e., the ratio between the total number of input bits and the funnel (p 1+ p2+ …). + pn) and the total number of output bits from the funnel.

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. In fig. 4, by way of non-limiting example, x =2: in practice, each X-OR gate 322 is shown as having two inputs.

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.

As shown in fig. 4 (schematically, to avoid overly complicated representations), the connection between AND gate 320 AND X-OR gate 322 results in grouping the output signal from AND gate 320 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, continuing in the same manner for all bits in signals X1 through Xn.

When all bits of a signal are connected, the signal is excluded from the process and jumps to the bits of the first subsequent signal still to be managed. In this way, signals with different amplitudes can be combined together.

Thus, fig. 4 is an example of a possible, non-mandatory implementation of a signature control circuit arrangement configured to receive multiple sets of TEST result signals from a circuit under TEST (200 IN fig. 3, where multiple instances of the circuit 200 are involved to have multiple output sets) IN response to an excitation signal IN _ TEST _ DATA applied to at least one circuit under TEST, the COMPRESSOR circuit being configured to generate respective signature comparison signals COMPRESSOR _1, COMPRESSOR _2, …, COMPRESSOR _ N from each of the multiple sets of TEST result signals from the at least one circuit under TEST 200 for comparison with respective reference signals IN signature control block sets SIGN _1 \u, SIGN \u2 _ctrl, …, SIGN _ N _ CTRL.

During test activity, possible mismatches between input and output data parallelism can be handled with or without the addition of additional data compression, in addition to the corresponding MISR processing.

Adding compression may affect test coverage in some way, may produce false masking due to aliasing, but at the same time reduces test time.

Given which funnel input is active by the special configuration registers, the funnel/signature configuration registers 32_1, 32_2, …,32 _Nin FIG. 1B have one configuration register for the funnel/signature instance.

Test output data generated during a test session or test activity is compressed in a plurality of input signature registers (see 14 in FIG. 1B), the parallelism of which is statically defined as the type and number of signatures instantiated.

Each MISR block COMPRESSOR _1, COMPRESSOR _2, …, COMPRESSOR _ N is associated with a corresponding register, signalure _1_g, signalure _2_g, …, signalure _ N _ G, which registers signalure _1 u G, signalure _2_g, …, signalure _ N _ G are writable via SW through interface APB to store expected/gold SIGNATUREs for a single test session or for an entire test activity.

At the end of a single test session or at the end of the entire test activity of the associated LFSR, the comparison between the computed "SIGNATURE" values resulting from the test as stored COMPRESSOR _1, COMPRESSOR _2, …, COMPRESSOR _ N and the "gold" values stored in the respective registers such as SIGNATURE _1_g, SIGNATURE _2_g, …, SIGNATURE _ N _ G may be configured by SW using the funnel/SIGNATURE configuration registers.

Note again that embodiments are primarily directed to (self-test) architectures, rather than to the criteria employed to obtain these test signatures and/or to perform match or mismatch checks in the signature control module.

These criteria may be selected as a function of factors such as the nature and type of circuit under test, the intended application, the type of test being performed, etc. By additionally noting that the test architecture discussed herein is largely "transparent" to these standards, these standards may be selected among a variety of possible options known to those skilled in the art.

Thus, such an architecture is applicable to a wide variety of devices, including: a first circuit 10 as illustrated in fig. 1A and 1B, and at least one second circuit 200 as illustrated in fig. 3 and configured to be brought into a test mode (signal T _ M), wherein during the test mode the at least one second circuit is coupled to: the TEST stimulus generator set 12 IN the first circuit 10 to receive TEST stimulus signals therefrom (e.g., IN _ TEST _ DATA and signals associated therewith, as previously discussed), and the signature control circuitry 14, 20, 22, 32 to provide TEST result signals thereto, e.g., OUT _ TEST _ DATA _1, …, OUT _ TEST _ DATA _ X1+ X2+ … + XN-1+ XN, IN response to stimulus signals applied thereto.

As shown in fig. 3, the at least one second circuit 200 includes: a logic circuit arrangement LC as a test candidate, and a scan chain circuit 24, 26 configured to: during the TEST mode, TEST input DATA IN _0 (X), IN _1 (X), …, IN _ n-1 (X) is applied to the logic circuit arrangement LC IN accordance with the TEST stimulus signal from the TEST stimulus generator 12 IN the first circuit 10, and the TEST output signals OUT _0 (X), OUT _1 (X), …, OUT _ M-1 (X) are recovered from the logic circuit arrangement LC during the TEST mode, and are applied to the signature control circuit arrangements 14, 20, 22, 32 IN the first circuit 10 IN accordance with the TEST result signals OUT _ TEST _ DATA _1, …, OUT _ TEST _ DATA _ X1+ X2+ … + XN-1 XN.

The architecture and related RTL configuration parameter set discussed herein are advantageous in testing various types and configurations of CUTs at the IP and SoC levels, overcoming some of the limitations of conventional solutions. This is particularly true where many different types and instances of simple CUTs are processed simultaneously through a test structure without duplicating the LBIST controller.

For example, the various aspects discussed herein are successfully used in conjunction with an EDPA safety mechanism, as disclosed in Italian patent application No.102020000009358 and Italian patent application No.102020000029759 (used by the public at the time of filing this application), which conforms to the ISO 26262ASIL-D coverage specification for LPFs, with reduced area overhead and test time.

Without prejudice to the underlying principles, the details and the embodiments may vary, even significantly, with respect to what has been described purely by way of example, without thereby departing from the scope of protection.

Claims (20)

1. A circuit, comprising:

a set of test stimulus generators, each test stimulus generator in the set of test stimulus generators being activatable to generate a test stimulus signal for at least one circuit-under-test according to test stimulus information loaded in a test stimulus register in the test stimulus generator;

a set of controllers, each controller of the set of controllers configured to control loading of test stimulus information into a test stimulus register of a respective one of the set of test stimulus generators in dependence on test control information loaded into the respective control register of the set of control registers;

a test programming interface configured to load test programming information into the control registers of the set of control registers, wherein the test stimulus generator of the set of test stimulus generators is activatable according to test programming information loaded into the control registers of the set of control registers via the test programming interface;

an input signature register set configured to store therein a signature reference signal indicative of a signature reference value received from the test programming interface; and

signature control circuitry comprising a set of signature control modules coupled to respective signature registers of the set of input signature registers, the signature control circuitry configured to:

receiving a test result signal from the at least one circuit-under-test in response to the test stimulus signal applied to the at least one circuit-under-test,

generating a signature comparison signal from the test result signal received from the at least one circuit-under-test,

comparing, in the signature control block, the signature comparison signal generated from the test result signal received from the at least one circuit under test with a corresponding signature reference signal in the input signature register set, and

generating an error signal in response to the signature comparison signal generated from the test result signal received from the at least one circuit-under-test not matching a corresponding signature reference signal in the input signature register set.

2. The circuit of claim 1, wherein the control registers of the set of control registers are configured to receive test programming information from the test programming interface, the test programming information comprising:

a number of test sessions for which test stimulus generators of the set of test stimulus generators are activated to generate test stimulus signals for the at least one circuit under test,

a number of test cycles for which test stimulus generators of the set of test stimulus generators are activated in a test session for the at least one circuit under test,

timing test pattern activation information for activating test stimulus generators of the set of test stimulus generators at a programmed time, or

Capture mode information indicating a number of capture cycles of the output test signal for the at least one circuit-under-test.

3. The circuit of claim 2, wherein the control registers in the set of control registers are configured to receive test control information from the test programming interface, the test control information including capture mode information indicating a number of capture cycles of an output test signal for the at least one circuit-under-test and information to insert additional cycles in the capture mode information.

4. The circuit of claim 1, wherein each test stimulus generator of the set of test stimulus generators comprises a linear feedback shift register as the test stimulus register in the test stimulus generator.

5. The circuit of claim 1, wherein the set of test stimulus generators is configured to generate the test stimulus signal for the at least one circuit-under-test having a signal coupled thereto, comprising:

a test mode indication signal;

a scan-in and a scan-out enable signal; or

The capture signal is tested.

6. The circuit of claim 1, wherein the signature control circuitry comprises compressor circuitry configured to receive a plurality of sets of test result signals from the at least one circuit-under-test in response to the test stimulus signal applied to the at least one circuit-under-test, the compressor circuitry being configured to generate a respective signature comparison signal from each of the plurality of sets of test result signals from the at least one circuit-under-test for comparison with a respective reference signal in the signature control module set.

7. An apparatus, comprising:

the circuit of claim 1; and

at least one additional circuit configured to be brought into a test mode, wherein during the test mode the at least one additional circuit is coupled to:

the set of test stimulus generators in the circuit to receive the test stimulus signal therefrom, an

The signature control circuitry to provide the test result signal thereto in response to the test stimulus signal applied thereto.

8. The apparatus of claim 7, wherein the at least one additional circuit comprises:

a logic circuit device to be tested; and

scan chain circuitry configured to:

applying test input data to the logic circuit means in accordance with the test stimulus signals from the set of test stimulus generators in the circuit during the test mode,

recovering a test output signal from the logic circuit arrangement during the test mode, an

Applying the test output signal as a test result signal to the signature control circuitry in the circuit.

9. A circuit, comprising:

a test stimulus generator set configured to generate a test stimulus signal for at least one circuit under test;

a controller group coupled to the test stimulus generator group and configured to control loading of test stimulus information in the test stimulus generator group; and

a test programming interface coupled to the controller group and configured to load test programming information into the controller group, the set of test stimulus generators being configurable at runtime by the controller group via software using the test programming interface.

10. The circuit of claim 9, further comprising:

an input signature register set configured to store therein a signature reference signal indicative of a signature reference value received from the test programming interface; and

signature control circuitry comprising a set of signature control modules coupled to respective signature registers of the set of input signature registers, the signature control circuitry configured to:

receiving a test result signal from the at least one circuit-under-test in response to the test stimulus signal applied to the at least one circuit-under-test,

generating a signature comparison signal from the test result signal received from the at least one circuit-under-test,

comparing, in the signature control module group, the signature comparison signal generated from the test result signal received from the at least one circuit-under-test with a corresponding signature reference signal in the input signature register set, and

generating an error signal in response to the signature comparison signal generated from the test result signal received from the at least one circuit-under-test not matching a corresponding signature reference signal in the input signature register set.

11. The circuit of claim 10, wherein the signature control circuit arrangement comprises a compressor circuit arrangement configured to receive a plurality of sets of test result signals from the at least one circuit-under-test in response to the test stimulus signal applied to the at least one circuit-under-test, the compressor circuit arrangement being configured to generate a respective signature comparison signal from each of the plurality of sets of test result signals from the at least one circuit-under-test for comparison with a respective reference signal in the signature control block set.

12. The circuit of claim 9, further comprising:

a set of control registers configured to receive test programming information from the test programming interface, the test programming information including a number of test sessions for which test stimulus generators of the set of test stimulus generators are activated to generate test stimulus signals for the at least one circuit-under-test.

13. The circuit of claim 9, further comprising:

a set of control registers configured to receive test programming information from the test programming interface, the test programming information including a number of test cycles for which test stimulus generators in the set of test stimulus generators are activated in a test session for the at least one circuit-under-test.

14. The circuit of claim 9, further comprising:

a set of control registers configured to receive test programming information from the test programming interface, the test programming information including timed test mode activation information for activating test stimulus generators of the set of test stimulus generators at programming time.

15. The circuit of claim 9, further comprising:

a set of control registers configured to receive test programming information from the test programming interface, the test programming information including capture mode information indicating a number of capture cycles of an output test signal for the at least one circuit-under-test.

16. The circuit of claim 15, wherein the set of control registers is further configured to receive test control information from the test programming interface, the test control information including information to insert additional cycles in the capture mode information.

17. A method, comprising:

applying a test stimulus signal to at least one circuit-under-test, the test stimulus signal being generated in a set of test stimulus generators in dependence on test stimulus information loaded in test stimulus registers in the set of test stimulus generators;

controlling loading of test stimulus information in the test stimulus registers of the test stimulus generator in accordance with test programming information loaded into respective control registers of a set of control registers, activating the test stimulus generator of the set of test stimulus generators in accordance with the test programming information loaded into the control registers of the set of control registers;

receiving a test result signal from the at least one circuit-under-test in response to the test stimulus signal applied to the at least one circuit-under-test;

generating a signature comparison signal from the test result signal received from the at least one circuit-under-test;

comparing the signature comparison signal generated from the test result signal received from the at least one circuit-under-test with a corresponding programmable signature reference signal stored in an input signature register set; and

generating an error signal in response to the signature comparison signal generated from the test result signal received from the at least one circuit-under-test not matching a corresponding programmable signature reference signal stored in the input signature register set.

18. The method of claim 17, wherein the test programming information comprises:

a number of test sessions for which test stimulus generators of the set of test stimulus generators are activated to generate test stimulus signals for the at least one circuit under test,

a number of test cycles for which test stimulus generators of the set of test stimulus generators are activated in a test session for the at least one circuit under test,

timing test pattern activation information for activating test stimulus generators of the set of test stimulus generators at a programmed time, or

Capture mode information indicating a number of capture cycles of an output test signal for the at least one circuit-under-test.

19. The method of claim 18, wherein the control registers in the set of control registers are further configured to receive test control information including capture mode information indicating a number of capture cycles for an output test signal of the at least one circuit-under-test and information to insert additional cycles in the capture mode information.

20. The method of claim 17, further comprising:

receiving, by a compressor circuit, a plurality of resulting test signal sets from the at least one circuit-under-test in response to the test stimulus signal applied to the at least one circuit-under-test; and

generating, by the compressor circuit, a respective signature comparison signal for comparison with a respective programmable signature reference signal for each of the plurality of test result signal groups from the at least one circuit-under-test.

Images