Patent Description:
The complexity of integrated circuits (ICs) has increased steadily in recent years. Some ICs include a plurality of circuits. For example, a system-on-a-chip (SoC) may integrate all components of a computer or another electronic system on a chip to, e.g., perform a number of functions, such as receiving and sending data, receiving and making phone calls, playing virtual games, etc. For example, a microcontroller IC may include, in addition to a central processing unit (CPU) and associated registers, a plurality of memories for, e.g., software storage, analog-to-digital converters (ADCs), digital-to-analog converters (DACs), communication interface modules, such as serial peripheral interface (SPI) and inter-integrated circuit (I<NUM>C), internal oscillators, as well as other digital and analog circuits. Other examples of complex ICs include field programmable gate arrays (FPGAs), power management ICs (PMICs), processors (such as ARM or x86 processors), digital signal processors (DSPs), etc..

Some applications are considered safety critical and demand self-test and/or real time monitoring of its circuits during mission mode (during normal operation), or during start/stop of the application in the field. An example is an automotive grade application controlling safety mechanism such as Braking, Parking, Lane change, etc..

Complex ICs may include one or more built-in-self-test (BIST) circuits. A BIST circuit, (also referred to as built-in test circuit, or BIT circuit), is a test circuit included in the complex IC that allows such complex IC to test itself. For example, logic BIST (LBIST) is used for testing logic circuits of the complex IC by applying test patterns, e.g., generated by a pseudo-random generator, using a scan circuit of the complex IC.

BIST circuits may be used to assist automatic test equipment (ATE), e.g., by testing logical or memory functions, or improve coverage or other test performance during manufacturing (production) of the IC.

BIST circuits may also be used in the field (e.g., during start/stop). For example, an automotive grade microcontroller that is compliant with ISO <NUM>, such as compliant with automotive safety integrity level (ASIL) D, may use one or more BIST circuits to test different components of the microcontroller each time the car is started, and report any detected faults to a central processing unit of the car. For example, a microcontroller for automotive applications that is compliant with ISO <NUM>, such as compliant with automotive safety integrity level (ASIL) D, may use a memory BIST (MBIST) to test the integrated memories for faults each time the car starts, as well as when the car is on (e.g., while driving).

Document <CIT> discloses an integrated circuit with a circuit under test. The integrated circuit includes a clock generation circuit that receives a reference clock from a tester and generates a corresponding core clock. The integrated circuit may have a built-in self-test circuit and a clock synthesizer that receives the core clock. The built in self-test circuit may provide clock synthesizer control signals that direct the clock synthesizer to produce test clock signals at various test clock frequencies. The test clock at the test clock frequencies may be applied to the circuit under test during circuit testing. The circuit under test may assert a pass signal when the circuit tests are completed successfully. The built in self test circuit may inform the tester of the maximum clock frequency at which the circuit under test successfully passes testing.

In accordance with an embodiment as claimed in claim <NUM>, a method for managing self-tests in an integrated circuit, IC, wherein the integrated circuit comprises:.

In accordance with an embodiment as claimed in claim <NUM>, an integrated circuit, IC comprising:.

The making and using of the embodiments disclosed are discussed in detail below. It should be appreciated, however, that the present invention provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific ways to make and use the invention, and do not limit the scope of the invention. The description below illustrates the various specific details to provide an in-depth understanding of several example embodiments according to the description. The embodiments may be obtained without one or more of the specific details, or with other methods, components, materials and the like. In other cases, known structures, materials or operations are not shown or described in detail so as not to obscure the different aspects of the embodiments. References to "an embodiment" in this description indicate that a particular configuration, structure or feature described in relation to the embodiment is included in at least one embodiment. Consequently, phrases such as "in one embodiment" that may appear at different points of the present description do not necessarily refer exactly to the same embodiment. Furthermore, specific formations, structures or features may be combined in any appropriate manner in one or more embodiments. Embodiments of the present invention will be described in a specific context, a self-test controller (also referred to as self-test controller unit, or STCU) of an SoC, and associated methods, e.g., in automotive applications. Embodiments of the present invention may be used in other applications, such as other safety critical applications, such as space applications, for example. Some embodiments may be used in non-safety critical applications. Some embodiments may be implemented in software or firmware, e.g., using a general purpose computing core configured to run programming instructions from a coupled memory.

In an embodiment of the present invention, a comprehensive programmable self-test controller is utilized to control self-test execution of a plurality of BIST controllers during boot-time and during run-time. In some embodiments, the programmable self-test controller performs BIST scheduling, BIST setup, fault management, phase-locked-loop (PLL) management, and/or self-integrity check monitoring, e.g., via cyclic redundancy check (CRC), and /or includes a debug/diagnostic interface to assist in scheduling BIST operations. In some embodiments, the plurality of BIST controllers includes one or more MBIST controllers, one or more LBIST controllers, and/or one or more custom BIST (CBIST) controllers.

Safety critical circuits of an IC may employ BIST as a mechanism to test itself, e.g., to enhance safety and increase reliability. MBIST and LBIST are examples of common BIST circuits. Other BIST circuits may also be used. For example, CBIST circuits, e.g., such as BIST circuits that may employ custom techniques for testing one or more digital and/or analog circuits, may also be used.

When testing an IC using a plurality of BIST circuits, it may be desirable to achieve a target test coverage with a short test time, and without exceeding a maximum peak transient power consumption and without exceeding a maximum average power consumption. For example, in automotive safety critical products, the BIST circuits may perform testing of the IC at start-up (e.g., each time the car is turned on) during boot time. Thus, it may be desirable to achieve the target test coverage with a short test time so that the full start-up of the car is not delayed for too long. A way to reduce test time is to run multiple BIST circuits in parallel. However, running multiple BIST circuits in parallel may increase the peak and/or average power consumption of the IC, which should be kept lower than the rated power consumption specification of the IC. Thus, in some ICs, there is a trade-off between test coverage, test time, and power consumption. For example, higher test coverage may result in higher test time. Reducing the test time while keeping the same test coverage may result in higher power consumption. Reducing power consumption may be achieved by reducing coverage and/or delaying execution of one or more BIST tests.

In an embodiment of the present invention, a single self-test controller is used to setup and schedule the triggering of a plurality of BIST tests so as to minimize test time while achieving a target test coverage with a peak power consumption lower than a maximum peak power level, and with an average power consumption lower than a maximum average power level.

<FIG> shows SoC <NUM> including a plurality of BIST controllers, according to an embodiment of the present invention. SoC <NUM> includes self-test controller <NUM>, clock/reset circuit <NUM>, computing core <NUM>, configuration loader <NUM>, fault aggregator <NUM>, L MBIST controllers <NUM>, M LBIST controllers <NUM>, and N CBIST controllers <NUM>.

During self-test, self-test controller <NUM> schedules the triggering of the L MBIST controllers <NUM>, M LBIST controllers <NUM>, and N CBIST controllers <NUM> for executing respective MBIST, LBIST and CBIST tests. Faults detected by any of the BIST controllers (<NUM>, <NUM>, <NUM>) are transmitted (e.g., synchronously or asynchronously) to self-test controller <NUM>. Self-test controller <NUM> transmits the received faults to fault aggregator <NUM>. Fault aggregator <NUM> aggregates the detected faults and transmits them to an external circuit (e.g., such as a central processing unit of a car).

In some embodiments, self-test controller <NUM> schedules the triggering of some of the L MBIST controllers <NUM>, M LBIST controllers <NUM>, and N CBIST controllers <NUM> in a staggered manner so as to keep peak power consumption lower than a maximum peak power consumption while scheduling the triggering of some others of the L MBIST controllers <NUM>, M LBIST controllers <NUM>, and N CBIST controllers <NUM> in parallel so as to minimize test time.

In some embodiments, self-test controller <NUM> determines the sequence of triggering events, as well as the sequence and configuration of other tasks (e.g., BIST setup, PLL setup) based on a state of SoC <NUM> or event associated with SoC <NUM>. For example, during boot time (e.g., before the car is allowed to fully turn on), computing core <NUM> may be in an off state, sleep state, or another state different from an active state. Thus, during boot time, self-test controller <NUM> may determine the BIST trigger schedule, and any other task based on an input from configuration loader <NUM> and trigger execution of BIST testing. In some embodiments, configuration loader <NUM> provides such input to self-test controller <NUM> upon request (e.g., via a conventional or custom communication channel between self-test controller <NUM> and configuration loader <NUM>) by loading a configuration file from non-volatile memory (NVM) <NUM>. Thus, in some embodiments, self-test controller <NUM> is advantageously capable of performing the setup, scheduling and triggering of the BIST circuits (e.g., <NUM>, <NUM>, <NUM>) in an autonomous manner (e.g., offline -without input from a computing core of SoC <NUM>).

During runtime (e.g., when the car is fully turned on, such as while driving), computing core <NUM> may be in an active state and may provide BIST setup and/or BIST scheduling input to self-test controller <NUM>. Thus, in some embodiments, self-test controller <NUM> may perform the setup, scheduling, and triggering of the BIST circuits (e.g., <NUM>, <NUM>, <NUM>) based on input from one or more computing cores of SoC <NUM>. In some embodiments, during runtime, self-test controller <NUM> may perform the setup, scheduling, and triggering of the BIST circuits (e.g., <NUM>, <NUM>, <NUM>) based on input from configuration loader <NUM> (e.g., which may be coupled to a memory) and/or a memory coupled to self-test controller <NUM>, in addition to an input from one or more computing cores of SoC <NUM>.

In some embodiments, self-test controller <NUM> may determine the state of SoC <NUM> based on an input from a register (not shown), computing core <NUM>, and/or clock and reset circuit <NUM>. For example, in some embodiments, clock and reset circuit <NUM> may assert a signal (e.g., via a register bit, or via an IRQ node) to indicate that SoC <NUM> is undergoing a reset process, thus prompting a boot of SoC <NUM>, which may prompt the execution of BIST tests during boot time. As another non-limiting example, self-test controller <NUM> may determine the state of computing core <NUM> based on a response or lack of response from computing core <NUM>, and may determine whether to run a boot time BIST testing or a runtime BIST testing based on the determined state of computing core <NUM>.

In some embodiments, a single self-test controller <NUM> is used to setup and schedule the triggering of L MBIST controllers <NUM>, M LBIST controllers <NUM>, and N CBIST controllers <NUM>. By using a single self-test controller, some embodiments advantageously achieve a target test coverage, test time, and power consumption during BIST tests with a lower silicon area when compared to implementations using a plurality of controllers for managing the L MBIST controllers <NUM>, M LBIST controllers <NUM>, and N CBIST controllers <NUM>.

NVM <NUM> is configured to store data corresponding to scheduling and/or other type of BIST configuration data. As will be described in more detail later, the data stored in NVM <NUM> may be arranged in files, such as pointer files. Each pointer file may include information about when to perform a particular BIST test, as well as BIST setup information.

In some embodiments, NVM <NUM> may be pre-configured by the SoC manufacturer. In some embodiments, an SoC user (e.g., a human, an external controller, etc.) may configure NVM <NUM> (e.g., via self-test controller <NUM>). In some embodiments, NVM <NUM> may be internal to SoC <NUM>. In some embodiments, NVM <NUM> may be external to SoC <NUM>. NVM <NUM> may be implemented in any way known in the art.

In some embodiments, L may be an integer greater than or equal to <NUM>, such as <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or more. In some embodiments, M may be an integer greater than or equal to <NUM>, such as <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or more. In some embodiments, N may be an integer greater than or equal to <NUM>, such as <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or more. In some embodiments, L, M, and N may all be equal. In some embodiments, L, M, and N may be all different. Other implementations are also possible. For example, in some embodiments, L is greater than or equal to <NUM>, M is greater than or equal to <NUM>, and N is <NUM>.

Clock and reset circuit <NUM> is configured to provide one or more clocks to computing core <NUM> and/or to self-test controller <NUM>. Clock and reset circuit <NUM> is also configured to reset SoC <NUM> (e.g., upon an internal or external event). In some embodiments, clock and reset circuit <NUM> includes a PLL (not shown) that is configurable, e.g., by self-test controller <NUM>. Clock and reset circuit <NUM> may be implemented in any way known in the art.

Computing core <NUM> is configured to perform computing tasks of SoC <NUM>. In some embodiments, computing core <NUM> may be implemented as an ARM core, such as an ARM Cortex® core. Some embodiments may implemented computing core <NUM> in other ways, such as using an x86, or RISC architecture. Other implementations are also possible.

In some embodiments, SoC <NUM> may include a single computing core <NUM>. In other embodiments, SoC <NUM> may include a plurality of identical computing cores <NUM>. In some embodiments, SoC <NUM> may include a plurality of different computing cores.

Configuration loader <NUM> is configured to load data (e.g., from a file) stored in NVM <NUM> and transmit the loaded data (e.g., including BIST setup and/or BIST scheduling information) to self-test controller <NUM>. In some embodiments, configuration loader <NUM> may be implemented with a finite state machine (FSM). Other implementations are also possible.

Fault aggregator <NUM> is configured to aggregate faults detected by the BIST circuits (<NUM>, <NUM>, <NUM>), and transmit the aggregated faults, e.g., to an external controller. In some embodiments, fault aggregator <NUM> receives the faults asynchronously from self-test controller <NUM>. Other implementations are also possible. For example, in some embodiments, fault aggregator <NUM> may receive the detected faults asynchronously directly from the BIST controllers (<NUM>, <NUM>, <NUM>). In some embodiments, fault aggregator <NUM> may receive the detected faults synchronously (e.g., from self-test controller <NUM> or directly from the BIST controllers).

In some embodiments, fault aggregator <NUM> may be implemented with an FSM.

Other implementations are also possible.

In some embodiments, self-test controller <NUM> is advantageously independent of processor architecture. For example, in some embodiments, self-test controller <NUM> may be implemented with a custom or generic controller or processor configured to execute programming instructions stored in a memory coupled to the controller or processor. For example, in some embodiments, self-test controller <NUM> may be implemented based on an ARM, x86, or RISC architecture. In some embodiments, self-test controller <NUM> may be implemented with an FSM. Other implementations are also possible.

MBIST controller <NUM> is configured to setup and trigger execution of MBIST tests to test memories <NUM> using collar <NUM> (a wrapper around memories <NUM>). MBIST controller <NUM> also collects faults detected in memories <NUM> and transmits the detected faults to fault aggregator <NUM> (e.g., via self-test controller <NUM>). The MBIST tests may be implemented in any way known in the art.

MBIST controller <NUM> may be implemented, e.g., with an FSM. Other implementations are also possible.

Memories <NUM> may be implemented in any way known in the art. Collar <NUM> may be implemented in any way known in the art.

Some embodiments may implement L MBIST controllers <NUM>, were each of the L MBIST controllers has the same architecture. In some embodiments, one or more of the L MBIST controllers may have a different architecture than another of the L MBIST controllers.

LBIST controller <NUM> is configured to setup and trigger execution of LBIST tests to test logic circuits of SoC <NUM>. LBIST controller <NUM> also collects faults detected in logic partitions and transmits the detected faults to fault aggregator <NUM> (e.g., via self-test controller <NUM>). The LBIST tests may be implemented in any way known in the art. For example, in some embodiments, pseudo-random pattern generator (PRPG) <NUM> is used to generate test patters. The test patterns are fed to scan chain <NUM> to test the logic circuits of SoC <NUM>. Multiple-input signature register (MISR) <NUM> is used to detect the response of the logic circuits under test to determine faults. LBIST controller <NUM> may be implemented, e.g., with an FSM. Other implementations are also possible.

Pseudo-random pattern generator <NUM>, scan chain(s) <NUM>, and MISR circuit <NUM> may be implemented in any way known in the art.

Some embodiments may implement M LBIST controllers <NUM>, were each of the M LBIST controllers has the same architecture. In some embodiments, one or more of the M LBIST controllers may have a different architecture than another of the M LBIST controllers. For example, in some embodiments, a given LBIST controller may have a serial programming interface and another LBIST controller may have a parallel programming interface.

CBIST controller <NUM> is configured to setup and trigger execution of CBIST tests to test analog and/or digital circuits of SoC <NUM> using custom techniques. Examples of custom techniques for BIST testing analog and/or digital circuits include techniques for BIST testing comparators, analog-to-digital converters (ADC), digital-to-analog converters (DAC), etc., to obtain parametric performance data.

CBIST controller <NUM> may be implemented, e.g., with an FSM. Other implementations are also possible.

Some embodiments may implement N CBIST controllers <NUM>, were each of the N CBIST controllers has the same architecture. In some embodiments, one or more of the N CBIST controllers may have a different architecture than another of the N CBIST controllers.

<FIG> shows a flow chart of embodiment method <NUM> for performing setup and scheduling of a plurality of BIST tests in a car, according to an embodiment of the present invention. Method <NUM> may be performed, e.g., in SoC <NUM>.

During step <NUM>, a car may begin a startup process. For example, in some embodiments, introducing a key into the car may trigger the beginning of the car startup process.

During step <NUM>, data from a non-volatile memory (such as NVM <NUM>) is loaded. In some embodiments, loading the data comprises loading pointers to data location, and accessing the data comprises reading data from NVM <NUM> based on the loaded pointers. In some embodiments, loading the data comprises reading the data and storing the loaded data in a temporary memory location, such as a cache, registers, or other, e.g., volatile memory.

During step <NUM>, BIST tests, such as BIST tests associated with BIST controllers <NUM>, <NUM>, and/or <NUM>), are setup and scheduled for execution based on the data loaded during step <NUM>.

During step <NUM>, the BIST tests are executed based on the schedule determined during step <NUM>.

In some embodiments, steps <NUM> and <NUM> may be performed in parallel. For example, a first BIST test may be setup and triggered during step <NUM>, and while the first BIST test is being executed during step <NUM>, a second BIST test may be setup during step <NUM>, etc..

If critical faults are detected during step <NUM>, a critical fault action may be performed. If no critical faults are detected during step <NUM>, the car operates normally during step <NUM>.

During step <NUM>, BIST tests, such as BIST tests associated with BIST controllers <NUM>, <NUM>, and/or <NUM>), are setup and scheduled for execution based on the data from a memory (such as NVM <NUM>) and/or from input from a computing core (e.g., <NUM>). During step <NUM>, the BIST tests setup and scheduled during step <NUM> are executed. In some embodiments, steps <NUM> and <NUM> may be performed in parallel.

If critical faults are detected during step <NUM>, a critical fault action may be performed. If no critical faults are detected during step <NUM>, the car waits during steps <NUM>, and then proceeds to execute step <NUM>.

In some embodiments, critical faults are faults that are capable of producing a safety hazard. In some embodiments, possible critical fault actions (e.g., from step <NUM> and/or <NUM>) are: preventing the car from fully turning on, turning on a light in the dashboard to indicate the presence of a critical fault, turning off one or more features of the car, and changing the mode of operation (e.g., to a safety mode) of one or more features of the car.

In some embodiments, setting up BIST tests (e.g., during steps <NUM> and <NUM>) includes configuring the frequency of clock signals associated with BIST controllers, configuring whether a particular portion of a BIST testing is to be bypassed or not, and/or setting initial parameters of the BIST.

<FIG> shows a possible implementation of a portion of self-test controller <NUM>, and a possible arrangement of data stored in NVM <NUM>, according to an embodiment of the present invention. As shown in <FIG>, self-test controller <NUM> includes master FSM <NUM>, MBIST FSM <NUM>, LBIST FSM <NUM>, and CBIST FSM <NUM>. During BIST testing (e.g., during step <NUM>), master FSM <NUM> may receive from NVM <NUM> pointer files <NUM>, <NUM>, and <NUM> associated with MBIST, LBIST, and CBIST respectively. In some embodiments, pointer files <NUM>, <NUM>, and <NUM> include BIST scheduling information as well as BIST setup information for their respective BIST circuits.

Master FSM <NUM> triggers (e.g., during step <NUM>) operation of MBIST FSM <NUM>, LBIST FSM <NUM>, and CBIST FSM <NUM> based on pointer files <NUM>, <NUM>, and <NUM>, respectively. In response to respective triggers, MBIST FSM <NUM>, LBIST FSM <NUM>, and CBIST FSM <NUM>, respectively trigger MBIST controller(s) <NUM>, LBIST controller(s) <NUM>, and CBIST controller(s) <NUM> to perform respective MBIST, LBIST, and CBIST tests according to respective pointer files <NUM>, <NUM>, and <NUM>.

In some embodiments, master FSM <NUM> reads the pointer files (e.g., <NUM>, <NUM>, and <NUM>) and configures the BIST FSMs (e.g., <NUM>, <NUM>, and <NUM>) based on the respective pointer files.

In some embodiments, the BIST FSMs (e.g., <NUM>, <NUM>, and <NUM>) configure their respective BIST controllers (e.g., <NUM>, <NUM>, <NUM>), e.g., with static information, before triggering the BIST controllers to perform the BIST testing.

In some embodiments, FSMs <NUM>, <NUM>, <NUM>, and <NUM> may be implemented in hardware with combinatorial logic. In some embodiments, FSMs <NUM>, <NUM>, <NUM>, and <NUM> may be implemented in software or firmware, e.g., in a generic or custom controller or processor coupled to a memory.

<FIG> shows a possible implementation of pointer files <NUM>, <NUM>, and <NUM>, according to an embodiment of the present invention. As shown in <FIG>, in some embodiments, NVM <NUM> may include three pointer files (e.g., <NUM>, <NUM>, and <NUM>) for LBIST, MBIST, and CBIST respectively. Each pointer file (e.g., <NUM>, <NUM>, and <NUM>) includes a plurality of fields (e.g., DELAY_EN, NEXT_BIST TYPE, BIST_CTLR_IDX, BIST_PTR_VAL, and BIST_EXE_TYPE), and a plurality of rows. Each row, when executed, causes the triggering of an associated BIST controller so that a corresponding BIST test is performed.

The DELAY_EN field is used to specify a delay between triggering a BIST controller (e.g., <NUM>, <NUM>, <NUM>) and the execution of the associated BIST. For example, no delay or a delay of zero causes the execution of a BIST test, e.g., simultaneously, with reception of the trigger by the respective BIST controller. A delay greater than zero causes the BIST controller to wait for the specified delay amount before executing the associated BIST test. In some embodiments, the delay is managed by respective BIST FSM (e.g., <NUM>, <NUM>, <NUM>). In some embodiments, the delay is managed by master FSM <NUM>. By managing the delay using self-test controller <NUM> instead of the BIST controllers (e.g., <NUM>, <NUM>, <NUM>), some embodiments are capable of staggering execution of BIST tests without modifying or adding complexity to the BIST controller(s).

In some embodiments, the delay specified in DELAY_EN field is applied before execution of the respective row (e.g., as illustrated in <FIG>). In some embodiments, the delay specified in DELAY_EN field is applied after execution of the respective row (e.g., as illustrated in <FIG>).

The NEXT_BIST_TYPE field indicates which pointer file should select the next BIST controller to be triggered. For example, if row <NUM> of the LBIST pointer file includes MBIST in the NEXT_BIST_TYPE, then the next row of the MBIST pointer file to be executed (e.g., row <NUM>) is executed next.

The BIST_CTRL_IDX field indicates which BIST controller is to be triggered. For example, if row <NUM> of the LBIST pointer file includes a <NUM> in the BIST_CTRL_IDX field, then the LBIST controller <NUM> associated with an identification number of <NUM> is triggered when row <NUM> of the LBIST pointer file is executed.

The BIST_PTR_VAL field is used for cascade operation (to indicate the memory index, e.g., in implementations in which a given controller is associated with a plurality of memories). For example, if row <NUM> of the MBIST pointer file includes a <NUM> in the BIST_PTR_VAL, then the memories of collar <NUM> associated with the identification number of <NUM> is selected for performing the MBIST test. In some embodiments, a value of <NUM> or null is indicative that parallel operation (for testing a plurality of memories in parallel) is not applicable.

The BIST_EXE_TYPE field is used to specify whether execution of the BIST is to be performed sequentially (serially) or concurrently (in parallel) with the next BIST. For example, if:.

then, when row <NUM> of the LBIST pointer file is executed, LBIST controllers <NUM> associated with identification <NUM> and <NUM> are triggered concurrently (e.g., simultaneously). Once the BIST testing associated with LBIST controller <NUM> associated with identification number <NUM> finishes, then LBIST controller <NUM> associated with identification number <NUM> is triggered.

In some embodiments, performing BIST testing in parallel advantageously allow for reducing test time.

In some embodiments, performing BIST testing serially advantageously allow for reducing peak power consumption. In some embodiments, performing BIST testing serially advantageously allows for finalizing the testing of a given circuit before testing a further circuit that depends on the given circuit. For example, in some embodiments, an LBIST test is performed on the logic associated with a given memory and/or associated MBIST controller, and such LBIST test is finalized before executing an MBIST test to test the given memory.

A pointer file pointer (e.g., LBIST_ptr, MBIST_ptr, and CBIST_ptr) is used to keep track of the next row of the pointer file to be executed. For example, if MBIST_ptr is pointing to row <NUM> of MBIST pointer file <NUM>, and if row <NUM> of LBIST pointer file <NUM> is currently being executed and has MBIST in the NEXT_BIST_TYPE field, then row <NUM> of the MBIST pointer file <NUM> is executed next.

In some embodiments, an initial pointer INIT_PTR points to the first pointer file (or to the BIST pointer file pointer of the first BIST pointer file) to be executed. For example, if INIT_PTR points to the MBIST pointer file <NUM>, then the first BIST to be executed is the BIST corresponding to the location in which MBIST_ptr is pointing to. In some embodiments, the initial pointer INIT_PTR is stored in bits of a register, which is loaded during step <NUM> from NVM <NUM>. In some embodiments, the location to which the INIT_PTR points to is a location in NVM <NUM> corresponding to the first pointer file (e.g., which may be programmed to be, e.g., pointer files <NUM>, <NUM>, or <NUM>).

In some embodiments, NVM <NUM> may include a plurality of MBIST pointer files, LBIST pointer files, and/or CBIST pointer files, which may be used at different points in time based, e.g., on the state of SoC <NUM>. For example, an MBIST pointer file specifying a particular sequence may be used during boot-time, and a second MBIST pointer file may be used when the SoC <NUM> is in the active state.

It is understood that some embodiments may include a single pointer file, two pointer files, or more than three pointer files. For example, in an embodiment in which SoC <NUM> implements MBIST but not LBIST or CBIST, NVM <NUM> may include an MBIST pointer file and not include an LBIST pointer file or CBIST pointer file. As another non-limiting example, in an embodiment in which SoC <NUM> implements LBIST and MBIST but not CBIST, NVM <NUM> may include an LBIST pointer file and an MBIST pointer file and not include a CBIST pointer file. As another non-limiting example, in an embodiment in which SoC <NUM> implements LBIST, MBIST, and two types of CBIST, NVM <NUM> may include an LBIST pointer file, an MBIST pointer file, and two CBIST pointer files.

As shown in <FIG>, LBIST pointer file <NUM> may include L rows, MBIST pointer file <NUM> may include M rows, and CBIST pointer file <NUM> may include N rows. However, a different number of rows may be used, and may be programmatically changed, e.g., by a user. For example, in some embodiments, the BIST pointer file may include less rows than the number of associated controllers. For example, in some embodiments, some of the BIST controllers may not be triggered.

In some embodiments, the pointer file may include more rows than the number of associated BIST controllers. For example, a particular BIST controller may be triggered in different rows, so that the associated BIST tests are performed at different times.

<FIG> illustrated an example of a populated MBIST pointer file, and corresponding BIST testing execution timeline, respectively, according to an embodiment of the present invention.

As shown in <FIG>, the initial pointer INIT_PTR points to the MBIST pointer file pointer MBIST_ptr, which in turn points to row <NUM> of MBIST pointer file <NUM>. In some embodiments, the loading of initial pointer INIT_PTR so that it points to the MBIST pointer file pointer MBIST_ptr may be performed during step <NUM>. In some embodiments, MBIST pointer file <NUM> is processed by MBIST FSM <NUM> and MBIST FSM <NUM> triggers execution of the associated MBIST controllers <NUM>.

When row <NUM> of the MBIST pointer file <NUM> is executed, the MBIST controller associated with identification number <NUM> is triggered (based on the BIST_CTRL_IDX field). Since the BIST_EXE_TYPE field of row <NUM> is set to "PARALLEL" and the NEXT_BIST_TYPE is set to MBIST, pointer MBIST_ptr is incremented so that it points to the next row of MBIST pointer file <NUM>), and such row (in this example, row <NUM>) is executed immediately. Since row <NUM> has the BIST_CTRL_IDX field with a value of <NUM>, the MBIST controller associated with identification number <NUM> is triggered. As shown in <FIG>, MBIST controllers associated with identification numbers <NUM> and <NUM> are triggered and begin execution of their respective MBIST tests at time t<NUM>.

Since row <NUM> has the BIST_EXE_TYPE field set to "SERIAL," execution of row <NUM> finishes before the next BIST is executed. Since the NEXT_BIST_TYPE is set to MBIST, pointer MBIST_ptr is incremented so that it points to the next row of MBIST pointer file <NUM>), and such row (in this example, row <NUM>) is executed once row <NUM> finishes execution.

Since the BIST_EXE_TYPE field of row <NUM> is set to "PARALLEL" and the NEXT_BIST_TYPE is set to MBIST, pointer MBIST_ptr is incremented so that it points to the next row of MBIST pointer file <NUM>), and such row (in this example, row <NUM>) is executed immediately. However, since row <NUM> has DELAY_EN field set to <NUM>, a corresponding delay (as shown by the delay between times t<NUM> and t<NUM> in <FIG>) is applied before the MBIST controller associated with identification number <NUM> is triggered. In some embodiments, the duration of the delay is configurable, and may cause, e.g., the MBIST controller associated with identification number <NUM> to start before, at the same time, or after the MBIST controller associated with identification number <NUM> finishes.

After the delay time, the MBIST controller associated with identification number <NUM> is triggered (based on data from row <NUM>). Since the BIST_EXE_TYPE field of row <NUM> is set to "PARALLEL" and the NEXT_BIST_TYPE is set to MBIST, pointer MBIST_ptr is incremented so that it points to the next row of MBIST pointer file <NUM>), and such row (in this example, row <NUM>) is executed together with row <NUM>. As shown in <FIG>, MBIST controllers <NUM> and <NUM> are triggered and begin execution of their respective BIST tests at time t<NUM>.

Since row <NUM> has the NEXT_BIST_TYPE field with a null value, the BIST testing is considered finished.

In some embodiments, the BIST pointer files (e.g., <NUM>, <NUM>, <NUM>) may be implemented with different number and/or type of fields. For example, <FIG> shows MBIST pointer file <NUM>, according to an embodiment of the present invention. MBIST pointer file <NUM> operates in a similar manner as MBIST pointer file <NUM>, and produces a similar result (e.g., as shown in <FIG>). MBIST pointer file <NUM>, however, applies the DELAY_EN field after execution of the respective row instead of before execution of the respective row. Thus, row <NUM> of MBIST pointer file <NUM> having a value of <NUM> achieves the same result as row <NUM> of MBIST pointer file <NUM> having a value of <NUM>.

Advantages of some embodiments include the ability to configure the BIST schedule to optimize one or more parameters (e.g., reduce test time, reduce peak or average power consumption, increase or change test coverage, etc.) without modifying the circuit design. In some embodiments, such optimizations may advantageously be performed by a consumer using the IC in a bigger system (e.g., a car) so that the coverage is targeted specifically for the set of features used by such consumer). In some embodiments, such optimizations may advantageously be performed in the field, e.g., via a firmware update of the product (e.g., a car), e.g., to fix bus or improve/optimize performance after the product has been delivered (e.g., sold) to the consumer).

In an embodiment of the present invention, a self-test controller includes a plurality of BIST interfaces operating based on clocks having frequencies independent from functional clocks. In some embodiments, BIST interfaces operating based on clocks having frequencies independent from functional clocks advantageously allows for optimizing BIST test time and power consumption by allowing the adjustment of the frequency of operation of one or more BIST controllers to adjust (increase/decrease) the BIST test speed without impacting clock signals provided to functional circuits of the SoC.

<FIG> shows a clock distribution architecture SoC <NUM>, according to an embodiment of the present invention. SoC <NUM> may be implemented as SoC <NUM>.

During a programing step (e.g., <NUM>, or the configuration of a BIST interface during steps <NUM> or <NUM>), programming interface <NUM> may access a memory (e.g., <NUM>) to load configuration instructions and/or may receive configuration instructions from functional circuit <NUM>, or another internal or external circuit. Programming interface <NUM> then configures one or more BIST interfaces (e.g., <NUM>, <NUM>) based on the received configuration instructions.

The BIST interfaces (e.g., <NUM>, <NUM>) configure their associated BIST controllers (e.g., during steps <NUM>, <NUM>). The BIST controllers (e.g., <NUM>, <NUM>, <NUM>, <NUM>), once triggered, perform their respective BIST testing (e.g., during steps <NUM>, <NUM>). As shown in <FIG>, the BIST interfaces may be LBIST interfaces or MBIST interfaces. In some embodiments, other types of BIST interfaces, such as CBIST interfaces, may also be used.

As shown in <FIG>, SoC <NUM> may include multiple clock domains (e.g., <NUM>, <NUM>). For example, in the embodiment of <FIG>, functional circuits <NUM> and <NUM> are in different clock domains (<NUM>, and <NUM>, respectively) and operate based on a respective plurality of clocks. Programming interface operates based on a clock (e.g., <NUM>) that is also used by functional circuit <NUM>.

Clock divider <NUM> provides one or more clock signals to LBIST interface <NUM>. Clock divider <NUM> also provides clock signals to a plurality of LBIST controllers <NUM>, such as LBIST controllers <NUM> and <NUM>. Clock divider <NUM> provides one or more clock signals to MBIST interface <NUM>. Clock divider <NUM> also provides clock signals to a plurality of MBIST controllers <NUM>, such as MBIST controllers <NUM> and <NUM>. Clock dividers <NUM> and <NUM> are capable of generating one or more divided clocks, e.g., at different frequencies. Thus, some embodiments are advantageously capable of adjusting the frequency of operation of one or more BIST controllers to adjust (increase/decrease) the speed of respective BIST testing to optimize test time, and power consumption. For example, in some embodiments, the frequency of a BIST controller (e.g., <NUM>) may be increased, and a frequency of another BIST controller (e.g., <NUM>) may be decreased, e.g., so that both BIST tests are performed in parallel (e.g., thus decreasing test time) while keeping peak power consumption below a maximum peak power level.

As shown, programming interface <NUM>, and one or more BIST interfaces (e.g., <NUM>, <NUM>) may operate based on different clocks. In some embodiments, clock synchronizers may be used to allow communication between circuits <NUM>, <NUM>, and <NUM>. Clock synchronizers may be implemented in any way known in the art.

Some embodiments may include a plurality of BIST interfaces <NUM> and <NUM>. For example, in some embodiments, a first LBIST interface <NUM> may control a first set of one or more LBIST controllers <NUM>, and a second LBIST interface <NUM> may control a second set of one or more LBIST controllers <NUM>. In some embodiments, the first set of controllers <NUM> may include a parallel programming interface and the second set of controllers <NUM> may include a serial programming interface.

Some embodiments may include a BIST interface (e.g., <NUM>, <NUM>) for each BIST controller (e.g., <NUM>, <NUM>, <NUM>, <NUM>). In some embodiments, a BIST interface (e.g., <NUM>/<NUM>) may control more than one BIST controllers (e.g., <NUM>/<NUM>).

In some embodiments, a plurality of BIST interfaces (e.g., <NUM> and/or <NUM>) may share the same clock signal. In some embodiments, each BIST interface may operate based on a dedicated clock. For example, in some embodiments, clock divider <NUM> may produce <NUM> clock signals, which are supplied to <NUM> LBIST interfaces <NUM> and <NUM> respective LBIST controllers <NUM>.

In some embodiments, each clock signal produced by a clock divider (e.g., <NUM>, <NUM>) is programmable with an independent value. For example, in some embodiments, <NUM> bits per clock divider (e.g., <NUM>, <NUM>) are used to select the division factor of the respective clock signal (e.g., for <NUM> possible clock frequencies). For example, in some embodiments, the clock dividers may perform a frequency division of a source clock (e.g., at <NUM>) between <NUM> and <NUM>/<NUM>. A different number of bits may be used for selecting the clock frequency produced by the clock divider.

In some embodiments, BIST controllers <NUM> and <NUM> are configured to perform BIST testing on circuits of clock domain <NUM>. In some embodiments, BIST controllers <NUM> and <NUM> are configured to perform BIST testing on circuits of clock domain <NUM> (e.g., clock monitors).

In some embodiments, programming interface <NUM> may be implemented as master FSM <NUM>.

In some embodiments, the configuration instructions received by programming interface <NUM> may include information associated with one or more BIST pointer files (e.g., <NUM>, <NUM>, <NUM>).

In some embodiments, LBIST interface(s) may be implemented by respective LBIST FSMs (e.g., <NUM>). In some embodiments, MBIST interface(s) may be implemented by respective MBIST FSMs (e.g., <NUM>).

In some embodiments, functional cores may be two independent computing cores (e.g., <NUM>). In some embodiments, functional circuits <NUM> and <NUM> may have the same architecture (e.g., functional circuit <NUM> may be a replica of functional circuit <NUM>).

Clock domain <NUM> includes one or more clocks (e.g., <NUM>, <NUM>, <NUM>, <NUM>) which are synchronized and may be derived from the same PLL (e.g., <NUM>), e.g., simultaneously. In some embodiments, clocks <NUM>, <NUM>, <NUM>, and <NUM> have frequencies of <NUM>, <NUM>, <NUM>, and <NUM>, respectively. Other frequencies may also be used.

In some embodiments, clock/reset circuit <NUM> includes clocks <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, PLLs <NUM> and <NUM>, clock dividers <NUM> and <NUM>. In some embodiments, self-test controller <NUM> includes clock dividers <NUM> and <NUM>.

In some embodiments, PLL <NUM> and <NUM> are different PLLs. Thus, although clocks on the clock domains <NUM> and <NUM> may operate at a similar frequency (e.g., clocks <NUM> and <NUM> may both operate at <NUM>), such clocks may not be synchronized. In some embodiments, clocks in multiple clock domains may be derived from the same PLL. For example, in some embodiments, clocks <NUM>, <NUM>, <NUM>, <NUM>, may be derived from PLL <NUM>. Other implementations are also possible.

As shown in <FIG>, SoC <NUM> may include a plurality of clock domains (e.g., <NUM>, <NUM>). Although <FIG> shows <NUM> clock domains only (<NUM>, <NUM>), some embodiments include more than <NUM> clock domains, such as <NUM>, <NUM>, <NUM>, <NUM>, or more. In some embodiments, SoC <NUM> includes a single clock domain.

By using a single self-test controller for controlling BIST testing in different clock domains, some embodiments advantageously achieve lower silicon area dedicated for BIST testing when compared to using a dedicated self-test controller for each clock domain.

In some embodiments, a single self-test controller is advantageously capable of controlling BIST controllers synchronously and asynchronously.

By using a self-test controller that has a frequency independent from the functional clocks (clock signals provided to functional circuits, such as <NUM> and <NUM>), some embodiments are advantageously capable of adjusting BIST frequency without impacting functional performance, and without increasing complexity of the SoC design associated with clock considerations.

In some embodiments, a self-test controller is advantageously capable of controlling the frequency of one or more PLLs of the SoC. For example, in some embodiments, self-test controller <NUM> is capable of enabling/disabling PLLs using configuration bits (per PLL) as well as enabling/disabling PLL lock monitoring, e.g., during runtime. By controlling the enabling/disabling of PLLs and/or their respective frequencies, some embodiments re advantageously capable of adjusting power consumption and test time to achieve an optimum performance.

<FIG> shows a portion of SoC <NUM>, according to an embodiment of the present invention. SoC <NUM> may be implemented as SoC <NUM>.

As shown in <FIG>, SoC <NUM> includes P computing cores, a plurality of volatile and non-volatile memories, and additional circuits, such as communication interfaces (I/F), direct memory access (DMA) circuits, peripheral channels, etc. In some embodiments, P may be a positive integer greater than or equal to <NUM>.

As shown, Q virtual machines may be implemented using the hardware of SoC <NUM>. In some embodiments, Q may be a positive integer greater than or equal to <NUM>.

In some embodiments, self-test controller <NUM> is configured to test memories and logic circuits of SoC <NUM> during boot-time, and runtime. In some embodiments, the BIST testing performed by self-test controller <NUM> on SoC <NUM> complies with ISO <NUM> ASIL-D requirements, such as the ASIL-D requirements as listed in version ISO <NUM>:<NUM> of the ISO <NUM> standard.

SoC <NUM> may be implemented in safety critical applications, such as a car. For example, <FIG> shows car <NUM> implementing SoC <NUM>, according to an embodiment of the present invention. Car <NUM> may include an electronic control unit (ECU) having an error management logic. In some embodiments, the error management logic of the ECU receives faults detected by one or more BISTs (e.g., LBIST, MBIST, CBIST) of SoC <NUM>.

As described herein, in some embodiments, a self-test controller of an SoC (e.g., SoC <NUM>, <NUM>, <NUM>) may be dynamically programmed to adjust which BIST test to perform, when to perform the BIST test, whether to perform the BIST test sequentially or in parallel with another BIST test, and at what speed to perform the BIST test. For example, <FIG> shows a flow chart of embodiment method <NUM> for dynamically programming BIST testing, according to embodiments of the present invention. Method <NUM> may be implemented, e.g., by self-test controller <NUM>, e.g., of SoCs <NUM>, <NUM>, or <NUM>.

During step <NUM>, a self-test controller (e.g., <NUM>) configure first and second clocks (e.g., clocks from clock divider <NUM> and/or <NUM>) to first and second frequencies, respectively. For example, in some embodiments, the self-test controller configures the first and second clocks to the first and second frequencies by adjusting first and second dividing factor of respective clock dividers (e.g., <NUM>, <NUM>), e.g., by using one or more registers. In some embodiments, the self-test controller configures the first and second clocks to the first and second frequencies by adjusting a frequency of a PLL (e.g., <NUM>).

In some embodiments, the first and second frequencies are different frequencies. For example, in some embodiments, the first frequency is at <NUM> and the second frequency is at <NUM>.

In some embodiments, the first and second frequencies are higher than <NUM>. Lower frequencies, such as <NUM> (<NUM> divided by <NUM>) or lower may also be used for the first and/or second frequencies.

In some embodiments, the first and second frequencies are the same frequency. For example, in some embodiments, the first and second frequencies are at <NUM>. In some embodiments, the first and second clocks may not be synchronized even though the first and second clocks may have the same frequency. For example, in some embodiments, the first and second clocks have a phase difference. In some embodiments, the first and second clocks are synchronized.

During step <NUM>, BIST configuration data is received, e.g. by the self-test controller. For example, in some embodiments, BIST configuration data includes one or more BIST pointer files (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).

In some embodiments, step <NUM> may be performed after step <NUM>. For example, in some embodiments, the configuration data includes data associated with the first and second frequencies, and the first and second clocks are configured based on the configuration data.

During step <NUM>, first and second BIST tests are configured based on the received BIST configuration data. For example, in some embodiments, a BIST FSM (e.g., <NUM>, <NUM>, <NUM>) configures one or more associated BIST controller (e.g., <NUM>, <NUM>, <NUM>) based on the received BIST configuration data.

During step <NUM>, the first and second BIST tests are scheduled for execution. During step <NUM>, the first and second BIST controllers are triggered to execute the first and second BIST tests, respectively. For example in some embodiments, a master FSM (e.g., <NUM>) schedules a BIST FSM(s) for execution, and the BIST FSM(s) triggers the associated BIST controllers based on the schedule.

During step <NUM>, the first and second BIST tests are executed in parallel at the first and second frequencies, respectively. In some embodiments, the first and second BIST tests may be of the same BIST type, such as MBIST (e.g., as shown in <FIG>). In some embodiments, the first and second BIST tests may be of different type (e.g., one may be MBIST and the other LBIST; one may be MBIST and the other CBIST; or one may be LBIST and the other CBIST).

In some embodiments (as illustrated in <FIG>), the first and second BISTs are executed in parallel (e.g., as MBIST#<NUM> and MBIST#<NUM> in <FIG>). In some embodiments, the first and second BISTs are executed in sequentially.

In some embodiments, method <NUM> is implemented as part of steps <NUM>, <NUM>, <NUM> and/or <NUM>. For example, in some embodiments, step <NUM> is performed as part of step <NUM>, steps <NUM>, <NUM>, <NUM>, and <NUM> are performed as part of step <NUM>, and step <NUM> is performed as part of step <NUM>. In some embodiments, steps <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> are performed as part of step <NUM>, and step <NUM> is performed as part of step <NUM>.

<FIG> shows a flow chart of embodiment method <NUM> for dynamically programming BIST testing, according to embodiments of the present invention. Method <NUM> may be implemented, e.g., by self-test controller <NUM>, e.g., of SoCs <NUM>, <NUM>, or <NUM>.

During step <NUM>, a self-test controller (e.g., <NUM>) configures a first clock (e.g., a clock from clock divider <NUM> and/or <NUM>) to a first frequency. For example, in some embodiments, the self-test controller configures the first clock to the first frequency by adjusting a dividing factor of a clock divider (e.g., <NUM>, <NUM>), e.g., by using a register. In some embodiments, the self-test controller configures the first clock to the first frequency by adjusting a frequency of a PLL (e.g., <NUM>).

In some embodiments, step <NUM> may be performed after step <NUM>. For example, in some embodiments, the configuration data includes data associated with the first frequency, and the first clock is configured based on the configuration data.

During step <NUM>, a first BIST test is configured based on the received BIST configuration data. For example, in some embodiments, a BIST FSM (e.g., <NUM>, <NUM>, <NUM>) configures one or more associated BIST controller (e.g., <NUM>, <NUM>, <NUM>) based on the received BIST configuration data.

During step <NUM>, the first BIST test is scheduled for execution. During step <NUM>, the first BIST controller is triggered to execute the first BIST test. For example in some embodiments, a master FSM (e.g., <NUM>) schedules a BIST FSM for execution, and the BIST FSM triggers the associated BIST controller based on the schedule. During step <NUM>, the first BIST test is executed at the first frequency.

During step <NUM>, the first clock is configured to a second frequency. In some embodiments, the first clock may be configured in a similar manner as during step <NUM>.

During step <NUM>, the first BIST test is scheduled for execution. In some embodiments, the first BIST test is scheduled for execution in a similar manner as during step <NUM>.

During step <NUM>, the first BIST controller is triggered to execute the first BIST test.

In some embodiments, the first BIST controller is triggered in a similar manner as during step <NUM>.

During step <NUM>, the first BIST test is executed at the second frequency.

In some embodiments, the first frequency is higher than the second frequency. For example, in some embodiments, step <NUM> is performed during boot-time and step <NUM> is performed during runtime. Thus, in some embodiments, the first frequency is faster (e.g., to cause a faster boost-time) and the second frequency is slower (e.g., to consume less peak power). In some embodiments, the first frequency may be slower than the second frequency (e.g., based on execution time requirements).

Claim 1:
A method for managing self-tests in an integrated circuit, IC (<NUM>, <NUM>, <NUM>), wherein the integrated circuit comprises:
a plurality of built-in-self-test, BIST controllers (<NUM>, <NUM>, <NUM>);
a self-test controller circuit (<NUM>) configured for controlling said plurality of BIST controllers;
said self-test controller circuit (<NUM>) comprising:
a master finite state machine (<NUM>);
a BIST finite state machine set (<NUM>, <NUM>, <NUM>), coupled to the master finite state machine;
the method comprising:
receiving (<NUM>, <NUM>), through said master finite state machine (<NUM>), built-in-self-test, BIST configuration data;
configuring (<NUM>, <NUM>), through said master finite state machine (<NUM>), said BIST finite state machine set (<NUM>, <NUM>, <NUM>) and, through said BIST finite state machine set (<NUM>, <NUM>, <NUM>), at least one BIST controller in said plurality of BIST controllers (<NUM>, <NUM>, <NUM>) based on the BIST configuration data;
scheduling (<NUM>, <NUM>, <NUM>), through said master finite state machine (<NUM>), instructions for execution on said BIST finite state machine set (<NUM>, <NUM>, <NUM>);
triggering (<NUM>, <NUM>, <NUM>), through said BIST finite state machine set (<NUM>, <NUM>, <NUM>), the execution of said instructions on the at least one BIST controller in said plurality of BIST controllers (<NUM>, <NUM>, <NUM>);
executing (<NUM>, <NUM>, <NUM>), through operations of the at least one BIST controller in said plurality of BIST controllers (<NUM>, <NUM>, <NUM>), said instructions;
said executing comprising:
configuring (<NUM>, <NUM>), through said master finite state machine (<NUM>, <NUM>), at least one clock signal of a plurality of clock signals (<NUM>, <NUM>, <NUM>) to a first frequency based on the BIST configuration data;
performing (<NUM>, <NUM>), through a BIST controller in said plurality of BIST controllers (<NUM>, <NUM>, <NUM>), a first BIST test at the first frequency;
configuring (<NUM>, <NUM>), through said master finite state machine (<NUM>, <NUM>), at least one clock signal of said plurality of clock signals (<NUM>, <NUM>, <NUM>) to a second frequency that is different from the first frequency, based on the BIST configuration data; and
performing (<NUM>, <NUM>), through a BIST controller in said plurality of BIST controllers (<NUM>, <NUM>, <NUM>), a second BIST test at the second frequency.