Built-in self-test methods, circuits and apparatus for concurrent test of RF modules with a dynamically configurable test structure

A testable integrated circuit chip (80, 100) includes a functional circuit (80) having modules (IP.i), a storage circuit (110) operable to hold a table representing sets of compatible tests that are compatible for concurrence, and an on-chip test controller (140, 150) coupled with said storage circuit (110) and with said functional circuit modules (IP.i), said test controller (140, 150) operable to dynamically schedule and trigger the tests in those sets, whereby promoting concurrent execution of tests in said functional circuit modules (IP.i). Other circuits, wireless chips, systems, and processes of operation and processes of manufacture are disclosed.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is related to India Patent Application 191/CHE/2011 “Built-In Self-Test Methods, Circuits and Apparatus for Concurrent Test of RF Modules with a Dynamically Configurable Test Structure” (TI-69655IndiaPS) filed Jan. 20, 2011, for which priority is claimed under the Paris Convention and 35 U.S.C. 119 and all other applicable law, and which is incorporated herein by reference in its entirety.

Not applicable.

COPYRIGHT NOTIFICATION

Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears in the United States Patent and Trademark Office, but otherwise reserves all copyright rights whatsoever.

BACKGROUND

The field of the invention pertains to integrated circuits (ICs), system on a chip (SOC) ICs, and processes and circuits for making and testing them.

In a mixed-signal SOC, a significant portion of the overall test time (and hence the test cost) is spent on testing the non-digital modules or IPs in the device. “IP” refers to an internal circuitry core or module (internal details not necessarily known to tester), and may generally refer to a circuit module hardware core or a soft core defined in design code. RF (radio frequency) circuit test time can even dominate SOC test time and be much higher compared to structural circuit test time and power management PM test/calibration time. When test time is in a production flow, it can limit achievable rates of production, which is expensive and problematic for manufacturers and consuming public alike.

RF testing is expensive because high pin count SoCs entail more test resources. Transmit tests may call for a complex demodulator to do tests for various modulation types EVM and standards coverages as in 802.11 (WiFi), and to do tests for BER (bit error rate) and other performances. Receive tests can call for RF test sources to test Sensitivity, Noise Figure, etc. Both TX and RX tests are even more complicated when multiple radios are integrated, such as Bluetooth, GPS, WLAN, FM, etc. Ports on the SoCs and on testing devices are likely to be limited in number. With multiple radios, co-existence tests are also likely to be called for.

This inconvenient and expensive test-time problem is further accentuated in devices with RF radios, wherein the tests require sophisticated instrumentation on the tester (in the form of stimuli sources and response loggers), further impacting the test cost. While highly accurate performance and specification tests could be intelligently replaced with coarser defect catching tests, (hence alleviating the need for expensive instrumentation on the tester), the test time still remains a bottleneck due to the need for applying these tests individually for the different radio IPs in an integrated SOC.

Consequently, new departures are needed to somehow address the above problems, and new types of circuits, devices and systems and processes of manufacturing and testing them would be most desirable.

SUMMARY OF THE INVENTION

Generally, and in one form of the invention, a testable integrated circuit chip includes a functional circuit having modules, a storage circuit operable to hold a table representing sets of compatible tests that are compatible for concurrence, and an on-chip test controller coupled with said storage circuit and with said functional circuit modules, said test controller operable to dynamically schedule and trigger the tests in those sets, whereby promoting concurrent execution of tests in said functional circuit modules. Other circuits, wireless chips, systems, and processes of operation and processes of manufacture are disclosed.

Generally, and in another form of the invention, a wireless chip includes mixed-signal cores for at least two different radios, wherein at least one of the radios has a transmitter and/or a receiver, and a test circuit coupled with the radios, the test circuit including a configurable controller operable to trigger compatible tests and to dynamically create a schedule responsive to test completions for concurrent tests on the radios.

Generally, and in a manufacturing process form of the invention, a manufacturing process includes downloading tests and a table identifying different sets of the tests that are compatible, executing at least two of the tests concurrently on an integrated circuit to be tested whereby the tests complete at different times, and dynamically scheduling concurrency among at least some of the different tests depending on the table and the actual order of test completion.

Generally, and in a process of operation form of the invention, an electronic process of dynamic scheduling includes accessing different compatibility classes, selectively triggering tests from at least one of the compatibility classes, and electronically executing a repeated conditional determination of whether tests represented by another accessed compatibility class are a superset of all triggered still-active tests from any such accessed compatibility class, and if so then triggering any tests in said another compatibility class that are yet to be triggered.

Generally, and in a further form in the invention, an integrated circuit includes a control storage having an address input to access any of plural test lists and having a test list output, an address generator operable for changing an address to said control storage, a sequential control logic operable coupled to said address generator to cause said address generator to effect a change or reverse a change on command, said sequential control logic having a stop input that receives a stop active from the address generator when a predetermined address is reached, and a test list updating logic coupled with said control storage test list output to receive at least one test list addressed by said address generator, said test list updating logic operable to compare such test lists and coupled with and actuated by said sequential control logic to select one of such test lists based on such comparison and generate test trigger output signals based on the selected test list.

Generally, and in an additional form of the invention, a testable apparatus includes a first modem for a first type of radio, a second modem for a second type of radio, a processor coupled with said first and second modems, and a storage circuit operable to hold a configurable table representing sets of compatible tests that are compatible for concurrency, and to hold self test control instructions accessible by said processor to dynamically schedule the tests in those sets of tests for at least some concurrency of test of said modems.

Generally, and in yet another form of the invention, an electronic test circuit includes a storage with a test identification table having entries selectively representing compatibility between different test identifications, a processing circuit operable to access a first portion of said storage so that two or more tests that are compatible can be triggered for execution, and further to access a second portion of said storage for additional entries if all tests in the first portion are completed.

Generally, and in another further form of the invention, an electronic circuit includes a storage circuit that is loadable with sets of data bits, and a sequential logic circuit coupled with said storage circuit and operable to respond to the sets of data to issue test triggers for compatible tests in a coordinated manner that executes faster than executing the tests seriatim, while tests that are incompatible are prevented from executing in an overlapping manner.

Generally, and in a testing system form of the invention, a multi-site system includes a test storage, at least two dies, one or more testers, and a test line gateway operable to distribute test codes for various tests and compatibility data as between tests from said test storage to one or more of said testers.

Generally, and in a tester form of the invention, a tester includes a storage having a first storage area representing various tests and a second storage area representing instructions to generate a test scheduling table, an electronic interface connectable to convey the various tests in the test scheduling table externally to the tester, a tester processor coupled with said storage and with said electronic interface, said tester processor operable in response to said instructions to generate the test scheduling table to represent sets of the tests that are compatible with each other, said tester processor further operable to deliver the test scheduling table to said electronic interface.

Generally, and in a still further form of the invention, portions of the test controller and test storage lie even within the die or device under test (DUT). The external tester provides the start of test indication and optional clocks, and the whole test operation is performed using the storage and control mechanisms embedded inside the die as an enhanced built-in self-test (BIST) tester function that is inventively embedded inside the die embodiment. The external tester performs a high-level role having built-in storage, processors and interfaces and instructions to schedule various tests. Such an external tester controls the test of multiple dies in a multi-site system. With the whole test operation embedded inside the die, the external tester provides data on the various tests and their compatibility to fill the test storage inside the die, in turn directing a test schedule. If the test schedule is fixed, an embedded ROM for such data on the various tests and their compatibility suffices in some embodiments, and the external tester provides the start signal and the clock and the die or DUT does the rest.

Other circuits, devices and systems, and processes of manufacturing and operation are also disclosed and claimed.

Corresponding numerals in different Figures indicate corresponding parts except where the context indicates otherwise. A minor variation in capitalization or punctuation for the same thing does not necessarily indicate a different thing. A suffix .i, .j, .k, .m, or .n refers to any of several numerically suffixed elements having the same prefix, or any of these letters may be used as an index.

DETAILED DESCRIPTION OF EMBODIMENTS

Some of the embodiments address the various problems by providing hardware for dynamically-scheduled concurrent testing of individual modules, of which radio IPs are a good example, in an SOC. Radios likely have dedicated processors or at least dedicated local control circuitry, and it is recognized herein that tests on different radio modules should and can be run concurrently under on-chip dynamic scheduling control. Not all tests are compatible, since they compete either for same tester/board resources or they result in interference. However, several of such tests still are compatible. Compatible tests are run in parallel using dynamic scheduling herein to fully exploit this opportunity for parallelism.

Some of the embodiments provide a type of electronic circuit for test that includes a functional circuit having modules and a radio core, as well as a configurable hardware built-in self test (BIST) controller sub-combination embodiment integrated with the functional circuit. The BIST controller embodiment creates a dynamic schedule for a set of concurrent tests wherein concurrency is based on a parallel application of identical test stimuli to the different modules of the functional circuit and on parallel execution of individual and different firmware sequences as multiple tests on the functional circuit. Various levels and types of concurrency of tests for the functional circuit are thus provided. Further, a combining circuit and a load execute dump interface are included. The combining circuit is coupled to the hardware BIST controller to combine results of the multiple tests and transfer the results through the load execute dump interface.

Among other remarkable process and structure features, various embodiments may involve any one, some or all of the following:(a) Concurrent test of non-digital modules, and more specifically radio IPs, is provided effectively with an embedded processor that performs the dynamic scheduling or with some other scheduling circuit like a state machine to do so.(b) The concurrency is based suitably on parallel application of identical test stimuli to different modules, and/or on parallel execution of individual (and different) firmware sequences on individual processors or other local control circuits for the modules.(c) The concurrency goes beyond statically configured and can be dynamically controlled.(d) The generation of concurrent tests is handled by a built-in hardware controller in some embodiments. No specific tester interaction is required. Different test schedules can also be created without having to manually generate the corresponding test sequence (across IPs) and then apply it from the tester.(e) The level of concurrency and the level of multi-site test are independent.

Among other advantages and benefits, various embodiments may have any one, some or all the following:(a) Parallelism is possible across different load-execute-dump phases, as well as within the execute phase.(b) The test schedule can be dynamically configured to take into account the tradeoffs in parallelism and tester characteristics (resources available for independent stimuli and resources) and device characteristics (correlation between different tests and IPs due to co-existence issues, variation across different lots). The BIST control not only permits the concurrent test of individual RF modules, but also allows the tests to be dynamically scheduled in the individual modules to account for any issues arising due to concurrency, (e.g. tester resources, power, co-existence, yield fallout etc.). Test vectors corresponding to different test schedules do not have to be manually generated and applied externally from the tester. A BIST embodiment, therefore, permits tradeoffs in the test time and test quality to be exploited for maximizing production yield and test throughput. This flexibility is important since RF tests are developed and certified iteratively, from the first time they are applied to adequate levels of characterization until they are finalized for production test. Creating the right schedule for concurrent application of such tests is an iterative process (where different static configurations can be considered), and hence the ability to create a dynamic schedule and built-in test vector generation is a significant advantage.(c) Different parallel test schedules can be created based on the individual Test IDs for each IP and their linkage within the test scheduler.(d) The level of concurrency achieved is in addition to the level of multi-site that is possible for a given DUT-tester configuration.(e) The embodiments can also be extended to support concurrency of different tests within an IP (core or module).(f) The theoretical test time with a concurrent schedule can be computed as the sum of (i) initialization time, (ii) execution time of the longest test in each set of compatible tests across all IPs, (iii) execution time of the longest test in each set of incompatible tests. As indicated earlier, the execution time is the dominant component of a DMLED test. Analysis on an SOC with four radio modules (BT, FM, GPS and WLAN) points to a potential of 56% saving in the concurrent schedule, as against a serial schedule. The test time reduction is from 9980 ms to 4338 ms, i.e. about 5642 milliseconds in concurrent process embodiment approach over serial approach.

A Glossary of terms is provided for reference.

GLOSSARY

ATE: Automatic Test EquipmentATPG: Automatic Test Pattern Generation. Uses tools to generate patterns to check the quality of silicon during production. Generally refers to the stuck-at fault test pattern generation. Also can refer to IDDQ(static current into chip) and delay test pattern generation.BIST: Built-In Self Test. Controller logic internal to a chip and designed to apply stimulus to test a block of logic without applying test vectors (software).BT: BluetoothCDR, prefix ‘Cdr_’: Core Data Register or programmable register for test mode control.DFT: Design for Test.DUT: Design Under Test (functional IC)FM: Frequency ModulationGPS: Global Positioning SystemIC: Integrated CircuitI/O: I=Input, O=Output.IP: Intellectual property core or module (internal details not necessarily known to tester). General reference in the industry to a circuit module hardware core or to a soft core defined in design code.IR/DR: Instruction Register/Data Register.JTAG: Joint Test Action Group, or the IEEE 1149.1 Standard, which defines a Test Access Port (TAP) and boundary scan design at the chip level.NFC: Near Field CommunicationPE: Product engineersScan: Structural test methodology places the chip in a special scan state where virtually all functional flops are connected into one or more shift registers accessible to the tester, permitting test stimuli to be applied, and responses to be collected.Setup/Header content: Control bits to configure the TAP controller (not the bits for a scan chain) or equivalent logic for test mode and ATPG setup.SI/SO: Scan In/Scan OutSOC: System on ChipTDL: Test Description Language.TAP: Test Access Port. Defines I/O and state machine for test mode access.WLAN: Wireless Local Area NetworkIEEE 1500: Standard for core based testing, similar to JTAG 1149.

InFIGS. 1-3, a built-in self-test (BIST) controller embodiment100in a SOC80is used both for scheduling the tests for multiple RF modules and for actual test control180for the IP modules themselves. This provides the ability to create a dynamic test schedule structure that can be changed if required without having to less-efficiently re-create test vectors externally and apply them through the tester5and a test interface15. Thus, hardware100is coupled with DMLED10and is implemented to run IP-specific tests simultaneously or concurrently on different IPs. Different tests, or sets of tests, are assigned unique Test IDs to which IP-specific control circuits180locally respond, and they can be selected and results of individual tests can be observed. Some embodiments provide a hardware scheduler140on-chip that permits and creates dynamic test execution schedules without the need to create distinct TDL (test description language of an external tester) sets for different test schedules. The hardware scheduler enables different configurations easily, based on known or newly-observed incompatibilities.

DMLED10control by the special controller100in some embodiments supports parallelization across all the phases of DMLED (load, execute, dump) across multiple IPs. The DMLED control is arranged in a process embodiment to overlap an execute phase in one IP with a download phase in another IP, seeFIGS. 10 and 12. Download parallelism is controlled through tester controlled sequences and represented by compatibility classes in a scheduling table called Test ID Table110inFIG. 3. A sequence is repeated for different sets of compatible sets of tests. A top level combiner (e.g., inFIGS. 8 and 9) brings out IP-specific test status onto SOC pins.

As an example, different tests can be included in one firmware image, which is loaded into the memory, and the processor runs the tests (identified by the Test ID) by correspondingly indexing into the memory, as determined by the test schedule. Being a BIST embodiment, in which the tests are run by the on-chip processor from the internal memory, higher multi-site test (FIG. 21) such as of multiple die on the same wafer is also accommodated or enabled, and hence in this way embodiments can further reduce test costs.

In furtherance of various solutions to the problems noted earlier hereinabove, consider also that a radio IP (intellectual property) core, as inFIGS. 1 and 19, has two main parts, an embedded processor which provides the control, and the RF (radio frequency) plus MS (mixed-signal) circuit which does the signal processing, including the transmission and reception. A conventional RF test might directly drive the RF+MS circuit providing the continuous wave source and doing RF signal+power measurements. A test applied herein using a low cost tester (without such source and measurement capabilities) runs on an embedded processor of a SOC, which in turn controls the operation and sequencing of the RF+MS modules to run a functional radio (transmit and/or receive) sequence. Such sequence is enabled through built-in (die level) or external (board level) loopback between the transmit and receive channels within or across radio modules. The DMLED test, (DMLED means Direct Memory Load-Execute-Dump), includes three parts:(i) Download of the code into the memory before the processor starts executing it.(ii) Code execution.(iii) Dumping the result of the test to ascertain the pass/fail status.

Some of the embodiments parallelize (FIGS. 10 and 12) all the three phases across multiple IPs, i.e. the LED sequence in one radio IP can be carried out in parallel with that of another radio IP. Since the download and the status dump times are small as compared to the test execution times, parallelizing the execution provides maximum gains. Therefore, this type of embodiment is most effective, from a hardware overhead and design complexity point of view, when the same test interface is re-used across all IPs to provide for both test download and result-dump operations for all of them. Moreover, such embodiments can parallelize all the three phases of the DMLED tests as well.

InFIG. 1, an organization of individual IP cores inside a SOC80, as well as the structural configuration of embedded processor and loop-back, are shown. InFIG. 1andFIG. 19, RF loop-back testing is controlled by software running hardware BIST. RF loop-back testing is done by connecting transmitter output to receiver input so as to avoid need for external RF source and sink capability. The different operations for these RF components are controlled by registers programmable through the software/firmware as inFIG. 2. An IEEE 1500 interface15(see alsoFIG. 18) couples test signals and controls from a tester5for a DMLED10and controller100and for the individual IP cores inside SOC80, one of which cores is depicted. In an IP core as illustrated a core processor, memory, control of interfaces are coupled to DMLED10and controller100. Software and tests-specific dedicated hardware180couple the processor with a transmitter and a receiver for the type of IP core radio to be tested. In this way, transmitter TX controls and data are coupled from the processor to the transmitter and the dedicated hardware performs the tests on command. Analogously, receiver RX controls and data are coupled from the processor to the receiver and the dedicated hardware performs the tests on command. By RF loopback, some tests involve both the transmitter and receiver in coordination.

FIG. 2depicts how the DMLED controller10ofFIG. 1interfaces with the SOC80and IPs. TheFIG. 2hardware is provided at the SOC level to enable parallel test across multiple radio modules. Test execution (test_exec) and test_status signals from different IPs are combined at a device level pin inFIGS. 2,8and9.

The DMLED controller overall circuit shown inFIG. 2includes a DMLED controller block10and100with interfaces to the Tester5externally (off-chip as inFIG. 18) and internally as inFIG. 2to the test mode controls and IPs internal to SOC80. InFIG. 2, that DMLED controller block10,100is provided as part of the integrated circuit, and some background on a type of DMLED controller10is found in “Testing of Integrated Circuits Using Test Module”, U.S. Patent Application Publication US 20080320347 dated Dec. 25, 2008, which is hereby incorporated herein by reference. In addition, to address multiple IPs inside the SOC, the DMLED controller10also interfaces to memories inside each IP by memory read/write operations on lines11and by operations on lines12for configuration (control as well as status) registers85inside each IP. DMLED controls14for individual IP's are coupled from DMLED10. Pin-muxing logic90has bi-directional test configuration lines92to SOC test mode registers20. SOC test mode registers20in turn are coupled via lines22and24to SOC80and DMLED controller10respectively. Lines22convey test mode controls for individual IP's, and lines24bi-directionally convey test mode controls for DMLED controller10. The firmware inside each IP core in SOC80controls the sequence of operation of how the individual tests for each IP are loaded, executed and status generated. This firmware is configured using the tester5by writing into the SOC test mode registers20inFIG. 2. Firmware download and status is coupled from the pin-muxing logic90via bidirectional bus lines94to DMLED controller10and at least some of this firmware is coupled via DMLED controller10and lines11and12to provide or update the firmware inside each IP in SOC80. Bus lines94suitably also are used to download and convey configuration values or entries for Test ID Table110.

FIGS. 3-4show two embodiments of structures and methods by which a dynamic scheduler controller100is added toFIG. 2DMLED10and controls the execution of the tests. The tests are listed according to a format as shown in a user (tester) filled Test ID Table110ofFIG. 3or4. Various dynamic scheduler states and controls in a controller finite state machine FSM ofFIG. 25or other circuit for Test Execution Control and Test ID Issue Logic140are shown and described. A test list updating logic150receives information from test ID Table110and, under control of, e.g., FSM140converts that information into trigger signals for circuits180in the IP cores.

InFIG. 3, the test circuitry embodiment100includes a storage with a Test ID Table110that is processed such as according to the flow description ofFIGS. 10 and 17. Table entries for Test ID Table110are generated beforehand as described in any ofFIGS. 22,23,24, and/or TABLE 6A. All tests in a given row (compatibility class) can be triggered for execution (unless block140has been arranged for some other type of operation as for TABLE 1A). InFIG. 3, the compatibility class is replaced with a new row if all tests in the existing row are completed, or the compatibility class is conditionally augmented by ORing the contents of the next compatibility class if all tests in the existing row are not yet complete. (See Steps3,4and5of, e.g., a process embodiment in TABLE 4 later hereinbelow). InFIG. 3, the Test ID Table110is accessed by a pointer circuit or Address Generator130via address bus135and the row corresponding to that address is fetched or transferred via data bus115to the Test List Updating Logic150. The triggering of tests that is output from Test List Updating Logic150is illustrated inFIG. 3A. Trigger enable bits in a test trigger enable register NWT or152ofFIG. 3Athat are active (1) indicate compatible tests that are ready for execution. Trigger enable bits that are inactive (0) indicate non-existent or incompatible tests.

InFIG. 3A, an output circuit portion for theFIG. 3test list updating logic150has a set of OR gates155that receive respective bits from the test trigger enable register NWT152from preceding circuitry in logic150, such as in portion250ofFIG. 6or as variously described in connection withFIG. 17and pseudocode example Tables. Three of the OR-gates155have their outputs routed to IP core IP1inFIG. 9and are qualified by an enable line IP1_Enable connected to their second inputs in tandem. Another five of the OR-gates155have their outputs routed to IP core IP2and are qualified by an enable line IP2_Enable connected to their second inputs in tandem. This illustrated output circuit portion is useful, for instance, to override some of the zero (0) bits in test trigger enable register152, and instead activate all the triggers for a given IP core from their respective configuration register bit fields158.1,158.2, etc. Some embodiments either additionally or alternatively provide AND gates connected in the manner of the OR-gates155, and the IP enable bits are suitably used to disqualify/prevent all the tests in a given IP core or conversely to enable such tests under the control of test trigger enable register152.

InFIG. 3A, some embodiments have a further circuit157that issues a respective actual multi-bit identification code for the test that is triggered by its corresponding bit in register NWT or its corresponding gate155. That circuit157can be a set of configurable registers having outputs respectively enabled or disabled by the applicable bit from register NWT152or the applicable gate155individually. Alternatively circuit157is a small memory circuit addressed by the ones and zeros from register NWT152or the gates155collectively. A configurable counterpart decoding circuit portion in each circuit180.iin the IP cores IP.i ofFIG. 9checks each multi-bit identification code supplied by circuit157and only enables its IP core IP1, or IP2, etc. for that test provided the multi-bit identification code checks out as valid, by decoding valid for its IP core.

InFIG. 4, the test circuitry embodiment100is extended and includes a Test ID Indexing Table170between an Address Generator130and the Test ID Table110. This facilitates Test ID indexing for access to the Test ID Table110. In some embodiments, Test ID Indexing Table170is an efficiently-small programmable or configurable logic structure that facilitates access to the Test ID Table110to effectively introduce one or another particular permutation of table rows in Test ID Table110. Such permutation can effectively alter the resulting dynamic schedule of tests to consume less test time and thereby more nearly optimize a test process.

Differences between a static schedule and dynamic schedule are noted as follows: In a static schedule (FIG. 11), the tests are configured for concurrent execution before the start of the execution. As a result, the sets of compatible tests apparently would need to be ascertained upfront. Also, the scheduling order of the tests themselves apparently would need to be created before the start of the execution. On the other hand, the tests according to a dynamic schedule ofFIGS. 3,4and12are configured herein for parallel execution as inFIGS. 3-7in a more flexible form in two ways: (i) By changing the entries in the Test ID Table110inFIG. 3. The Test Execution Control and Test ID Issue Logic140(such as an FSM) automatically executes the test in the new order, since it reads the updated table entries. (ii) If the Test ID Table110is not desired to be changed, a Test ID Indexing Table170can be provided, as shown inFIG. 4. The FSM140inFIG. 25now accesses the Test ID Indexing Table170ofFIG. 4and hence indirectly accesses the Test ID table110, wherein the order of entries in Test ID Table110are indirectly accessed as if they had been over-written, hence providing for a dynamic configuration. The individual test IDs can also be selectively set or reset to change the test schedule. Moreover, the dynamic scheduling can respond to particular lengths of actual time of test execution for each test to establish the actual schedule of tests on the fly, as described forFIGS. 7 and 17and elsewhere herein. Further description of the blocks inFIGS. 3-4is provided especially in connection withFIG. 17.

The scheduler operation for a hardware BIST controller is additionally discussed and illustrated inFIGS. 5-7.

InFIGS. 5-7, operations commence with Test Pointer set to first active row R1of TABLE 1A or row C1of Test ID Table110, either of which is instantiated, for instance, by a register file210filled in by user or tester5with entries for one example of a Scheduling Table. TABLE 1A is simplified relative to Test ID Table110ofFIG. 3to simplifyFIG. 7and the introductory description. Also, TABLE 1A has values based on a particular interpretation called a Test Association Table that can be compared with values entered under an interpretation inFIG. 3called a Test Compatibility Table. A processing example for the more extensive entries in Test ID Table110ofFIG. 3and TABLE 7 is then compactly shown in detail using TABLE 8 later herein.

InFIG. 5and detailing inFIG. 6, a Hardware Scheduler200embodiment has 2Xx reference numerals with middle digits X applied for comparing withFIGS. 1-4. Hardware Scheduler200has a Register File210to hold a Scheduling Table and a Control Logic220coupled to a DUT280for executing concurrent tests on various modules of DUT280using the Scheduling Table in Register File210. Control Logic220has Address Control Logic230coupled with a Next-Address Generator234which in turn is coupled with an Address Register238that itself is coupled to supply a latest address to access Register File210. Control Logic220also has a Test List Control Logic250coupled with a Test Execution, Control and Test ID Issue Logic240, which in turn is coupled with a Test List Register248. Test List Register248is coupled to receive a latest Test List (row of Scheduling Table) access from Register File210in response to the address from Address Register238.

User-filled register file210, for a second different example analogous to TABLE 1, has five (5) tests and three (3) compatible groups as shown in TABLE 2. Notice that different Scheduling Tables can be symmetric in their entries as in TABLE 1A or asymmetric in their entries as in TABLE 2. Also, different Scheduling Tables can have equal numbers of rows and columns and thus be square as in TABLE 1, or have unequal numbers of rows and columns and thereby be rectangular as in TABLE 2.

TABLE 1 and TABLE 2 thus provide examples of a format of the input provided by the user to load the Scheduling Table in Register File210. In effect, loading of a Scheduling Table creates an electronic representation of a matrix with number of columns equal to the total number of tests and number of rows equal to the total number of different compatible test sets (groups).

Next,FIG. 7illustrates an operational example of the hardware100operation, which can result from using a decision-making process as inFIGS. 3-6and17on TABLE 1A or TABLE 7 for creating a dynamic schedule to drive the IPs ofFIG. 9.FIG. 7shows a snapshot of a tree-shaped relationship of various possible sequences from which one concurrent and dynamic test execution schedule actually evolves. The economical hardware scheduler embodiment more time-efficiently executes a given schedule independent of the sum total of times required for individual tests. The schedule can be dynamically re-configured. Examples of pseudocode to dynamically schedule the narratedFIG. 7process are provided in any of TABLES 10, 11A, and 11B, each of which is described later hereinbelow underFIG. 17.

Notice thatFIG. 3Test ID Table110(TABLE 7) and the distinct TABLE 1A discussed next are suitably used by two different embodiments wherein the table values represent unrelated examples. TABLE 7 is called a Test Compatibility Table herein, while TABLE 1A is called a Test Association Table herein. In TABLE 1A, tests T2and T3are not compatible because Row R2does not have an entry for test T3and Row R3does not have an entry for Test T2. In the Test ID Table110inFIG. 3, tests T2and T3are designated to be compatible, since they are included in compatibility class C1.

The number of columns in a compatibility table like TABLE 7 (values inFIG. 3) can be different from the number of rows. If the rows indicate the Test ID associations as in TABLE 1A, however, the number of rows is equal to the number of columns by definition herein. So, if the rows indicate the compatibility classes as in TABLE 7, the number of rows is unrelated to the number of columns. In TABLE 1A the number or rows equals the number of columns, and it means that both the rows and columns contain the Test ID numbers in such a way that, in that case, the actual entries are symmetric. This is because Test N being compatible to Test M also implies that Test M is compatible to Test N.

InFIG. 7, tree-organized sequences between various nodes A to K represent possible sequences in which the schedule can be executed depending upon which tests are compatible and which tests finish earlier. A set of tables 1A-1K based on TABLE 1A are entitled in a manner corresponding to each node A-K so as to show an example of the possibilities for dynamic scheduling. Some of the tables are the same for different nodes, as indicated by their combined table titles. InFIG. 7, the execution starts at node A, see TABLE 1A. The process sets a Test Pointer (e.g., counter234) to first active row R1. Either a pair of tests (T1, T2) or another pair of tests (T1, T3) can run in parallel. The process example chooses the first pair of tests (T1, T2) to run in parallel. Tests T1and T2are executed time-efficiently because they are in parallel, and then the process proceeds toFIG. 7node B if test T1finishes first or instead to node C if test T2finishes first. Suppose test T1completes first, so the process proceeds to node B. At node B and TABLE 1B, circuit and process operations in effect remove column T1and row R1, or make them inapplicable (N/A) as in TABLE 1B. At node B, circuit and process operations advance Test Pointer to go to the next active table row (R2), see TABLE 1B; and test T2runs to completion, whence node D is reached.

In the tree ofFIG. 7, suppose instead that test T2completed first at node A, so the process proceeds to node C instead of node B. At node C and TABLE 1C, circuit and process operations in effect remove column T2and row R2, or make them inapplicable (N/A). The process adjusts the Test Pointer to go to the first active row, which is still R1. The pair of tests (T1, T3) run in parallel instead of T3waiting for test T1to complete, thus further avoiding undesirable time-consuming seriatim testing. Similarly, the execution proceeds through the subsequent steps. Tests can start and end asynchronously, and thus the on-chip scheduling is dynamic and time efficient. All control is built-in inside the scheduler100for true BIST.

The process is further described node by node by supposing that the process has reached such node. At node D and TABLE 1D after completing process node B, the process removes Column T2and Row R2and goes to the next active row R3whereupon a pair of tests (T3, T4) run in parallel. Suppose test T3completes first, and so the process proceeds to node G. At node G and TABLE 1G, the process in effect removes Column T3and Row R3, and thereupon proceeds to the next active row R4. Test T4is the only test remaining to complete, so test T4runs to completion. However, if test T4turned out to be the one to complete first at node D, then operations go from node D to node H. At node H and TABLE 1H, the process in effect removes Column T4and Row R4, and proceeds to the next active row R3. There, test T3is the only remaining test, and test T3runs to completion.

Alternatively, suppose the process has instead reached node E because of test T1completing before test T3at node C. At node E and TABLE 1E, the process effectively removes the Column T1and Row R1, see TABLE 1E, and the process proceeds to the next active row R3. Test T4is triggered and the pair of tests (T3, T4) run in parallel. Suppose test T3completes first, so operations move to node ‘I’. At node ‘I’ and TABLE 1I, the process effectively removes Column T3and Row R3, and thereupon proceeds to the next active row R4. There, test T4is the only remaining test, and test T4runs to completion. However, if test T4turns out to be the one to complete first at node E, then operations go to node J. At node J and TABLE 1J, the process in effect removes Column T4and Row R4, and proceeds to the next active row R3. There, test T3is the only remaining test, and test T3runs to completion.

In another alternative part of the tree ofFIG. 7, suppose the process has instead reached node F because of test T3completing first at node C. Test T1is still running At node F and TABLE 1F, the process effectively removes the Column T3and Row R3, see TABLE 1F, and the process proceeds to the first active row, still R1. Test T1runs to completion, and operations move to node ‘K’. At node ‘K’ and TABLE 1K, the process effectively removes Column T1and Row R1, and thereupon proceeds to the next active row R4. There, test T4is the only remaining test, and test T4runs to completion.

TABLE 1BSCHEDULING TABLE 1 AT NODE BT1T2T3T4R1N/AN/AN/AN/AR2N/AYR3N/AYYR4N/AYY

TABLE 1CSCHEDULING TABLE 1 AT NODE CT1T2T3T4R1YN/AYR2N/AN/AN/AN/AR3YN/AYYR4N/AYY

TABLE 1FSCHEDULING TABLE 1 AT NODE ‘F’T1T2T3T4R1YN/AN/AR2N/AN/AN/AN/AR3N/AN/AN/AN/AR4N/AN/AY

TABLE 1G/1I/1KSCHEDULING TABLE 1 AT NODE ‘G’ OR ‘I’ OR ‘K’T1T2T3T4R1N/AN/AN/AN/AR2N/AN/AN/AN/AR3N/AN/AN/AN/AR4N/AN/AN/AY

The hardware scheduler permits co-existence studies without generating new TDL scripts, and is at least applicable to all RF SOCs with more than one radio module. A sample set of concurrent TDLs can be generated and validated, and aligned with product engineering group on silicon test.FIG. 7thus illustrates a forking of tests in the sense of dynamically organizing them according to an hierarchical tree-shaped process. The lettered nodes inFIG. 7are thus organized in a forked, tree form. Each different row or column of N/A cells in the corresponding TABLES 1A-1K represents those rows and columns that have been removed from eligibility, up to that point in time, for determining a next test or set of tests that are to be executed. Incrementing the Test Pointer (row index j) in effect removes a row from eligibility (i.e., makes all the cells N/A in that row j). Each time the row index j is incremented, columns are also removed or made inapplicable (N/A) for all tests i that have completed execution. Some embodiments, as discussed later hereinbelow forFIG. 17, accomplish this by ANDing the latest row vector, e.g. C(j) or R(j), by ‘&!Tn’ for all tests Tn that have completed execution.

InFIG. 7, the hierarchical tree-shaped process is shown without extensive legends and even more explicitly in tree form to emphasize the forking in the legended forking of tests inFIG. 7. Possible sequences inFIG. 7are whichever of sequences ABDG, ABDH, ACEI, ACEJ, or ACFK is selected by the dynamic scheduler depending on which tests are compatible as indicated by the entries in TABLE 1 and depending on which tests finish earlier than others. Notice that each single node-letter like “A” in a sequence refers to a whole row to which the Test Pointer points in TABLE 1 and thus can issue concurrent tests appropriate to its moment in the process. The tree arises from the conditional outcomes of the looping process ofFIG. 17as more fully described there. Notice that the process ofFIG. 17operates on whatever table like TABLE 1A or TABLE 2, or otherwise is presented, and the particular schedule of tests that results is determined on-the-fly.

The scheduling control process ofFIG. 17is implemented in the hardware scheduler140. The hardware scheduler140executes one trace based on the order of the Compatibility Classes in the Test ID Table and the actual durations of the tests that determine which test ends first. The hardware scheduler140does not execute all the conceivable traces represented byFIG. 7, sinceFIG. 7represents a tree of many scheduling possibilities based on the tabulated compatibility classes but without knowledge of which test might end first for purposes of any given decision point.

InFIG. 8, a combiner circuit embodiment300supports a DMLED circuit by providing an economical interface for many tests and signals. Combiner circuit300has AND gates310.1-310.4that each receive a pair of signal lines—a respective qualifying or masking line Cdr_XX_dmled test from a Core Data Register360ofFIG. 9, and a corresponding line XX_dmled_test_exec that when active represents completion of execution of a test in a given IP core ofFIG. 9. The placeholder symbolism XX represents wl: IP1(WLAN), fm: IP2(FM radio), bt: IP3(Bluetooth), gps: IP4(GPS satellite positioning receiver). A multi-input OR gate320is fed with the output from each of the AND gates310.1-310.4. OR gate320output is coupled to the pin muxing logic90ofFIGS. 2 and 9.

InFIG. 9, SOC80is fed from test pin mux circuit90with respective processor core Reset lines for the cores or sub-chips IP1-IP4of SOC80. A pad350carries signals to or from test pin mux circuit90. Respective core test execute (completion) and test status lines convey their signals from the sub-chips IP1-IP4to the DMLED Combiner300as detailed inFIG. 8. DMLED Combiner300supplies a combined output330representing the various test executes (completions) and test statuses from the various cores IP1-IP4, all as qualified or masked by test enable lines from CDR360.

InFIGS. 8 and 9, one SOC level test interface is sufficient and confers economy of structure in a SOC embodiment. TEST_EXEC and TEST_STATUS output signals from the different IPs are combined into a device pin350. These output signals are also registered and contents can be read out to obtain IP-specific status. Tests running concurrently in different IPs (IP1-IP4) can result in co-existence issues. A list of compatible test cases (see, e.g.,FIG. 14) is identified herein to eliminate false fails.

InFIG. 10, a process embodiment400for Test Sequencing has overlapping load and execute as inFIG. 12. Simultaneous execution commences once loading is done for all IPs for which tests are triggered. Pass and fail status results of the testing are observed at step470at the end. InFIG. 10, software-based serialized and/or concurrent RF testing involves functional tests on RF IP ofFIG. 9. The tests are executed through DMLED (Direct Memory Load-Execute-Dump) operation controlled through ATE. Tests are loaded and results observed through DMLED interface10ofFIGS. 1,2,9. Tests are executed on an embedded host processor on-chip that communicates with internal memory. Process steps or components of RF tests inFIG. 10include:0) Wafer/dice fabrication410.1) Initialization415(power-up, E-Fuse shift, PLL lock for all IPs in parallel, ROM/RAM boot up420for all IPs for which tests are triggered by controller100).2) Firmware (FW) download+execution time. FW code is loaded sequentially into each IP at step430. Once code download is complete, the processor reset is lifted inFIG. 9and execution starts at step440inFIG. 10.3) TheFIG. 9multiple radios on a single chip at decision step450have some or even all of them tested concurrently herein. Such process and structure embodiments provide capability to initiate new test download into another IP when earlier test is being executed in one IP. Level of concurrency depends upon L-E-D duration (for Load-Execute-Dump).

The process inFIG. 10introduces a given one or more tests as soon as compatibility (e.g. TABLE 1A) and test completions detected by controller100permit so that the process in controller100dynamically schedules, triggers and thus packs the tests together with as much parallelism and time-efficiency as the table permits. Triggering is suitably in response to a trigger register NWT152in logic150ofFIGS. 3 and 3A, where e.g., 10100 means to trigger tests T1and T3(i=1, i=3) or 00010 means to trigger test T4(i=4). Each bit position of NWT152represents a Test ID, and a Test ID=1 at that bit position qualifies the circuitry180distributed in the individual IP cores ofFIG. 9so that the test can be performed if otherwise permitted to the given IP core by a configuration register such as CDR360. InFIG. 10, the dynamic scheduling is diagrammatically represented by a loop on triggered values of index i from a decision step455via increment step460back to step430inFIG. 10. Compare this with the description and pseudocode forFIG. 17that describes a set-based looping process in still further detail.FIG. 17step550triggers one or more tests and can use the process ofFIG. 10to load and execute the thus-triggered tests. As the tests are completed, Pass-fail status470for each of the tests is output as inFIGS. 8-9. The SOC chip80is suitably passed to delivery472, subjected to a software or hardware remediation process474, or scrapped476, depending on the test results.

FIG. 11depicts various phases of operation of a DMLED test and how the conventional serial operation ofFIG. 11is performed.FIG. 11illustrates serial testing of multiple IPs across a same or shared interface. Test cases are executed sequentially. The device test time is greater than or equal to sum total of individual IP test times. Such extended time is recognized as undesirably inefficient herein.

FIG. 12shows waveforms for a process embodiment that provides parallel operations that are performed instead of those ofFIG. 11.FIG. 12illustrates parallel testing of multiple IPs across a same or shared interface ofFIG. 9. Notice that the same initialization preamble is used for all the IPs, before the execution is permitted to start. The test-case DMLED Load operation of download is serial, for example, legended inFIG. 12as Download test in IP1, IP2, IP3. Execution and power-up/loading are suitably carried out in parallel, as illustrated by overlapping, different-length pulses of width 200 ms, 120 ms, 110 ms. ComparingFIG. 12withFIG. 8, the signals test_exec_ip1,2,3generally correspond with the signals XX_dmled_test_exec ofFIG. 8that when active represent completion of execution of a test in a given IP core ofFIG. 9. Also notice the 220 ms-wide signal test_exec_all ofFIG. 12generally corresponds with the execution status signal on the output line330ofFIG. 8. Further flip-flop logic forFIG. 12signal test status all, is reset on power up and toggled active on the trailing edge of signal test_exec_all. A DMLED Dump operation is activated immediately on the earliest trailing edge of any test completion, in this case test_exec_ip2, and Dump or upload to tester5proceeds until the results of the tests on all the IP's have been dumped.

In its operation in a SOC, the scheduler140(e.g., state machine FSM) operates inFIG. 12and Case 2 ofFIG. 13to perform the Load operations for each test in the first compatibility class one after the other. Scheduler140is also suitably arranged to respond to the test completion signals so that as soon as all the tests in a compatibility class are launched, then Dump is initiated for the first test to complete, and the Load operation is initiated when the first test in the next compatibility class is triggered. Such Dump occurs between steps450and470inFIG. 10and is shown at step590ofFIG. 17. Dumps from test(s) in one compatibility class and Loads for test(s) in the next compatibility class are interspersed for efficiently high usage of a serial line between SOC80and tester5.

Some embodiments provide Software BIST-based concurrent test of RF cores (IPs). Design considerations (interfaces, test control operation) are described. In one complex SOC embodiment, four radio modules are to successfully co-exist. Concurrent test accommodates high levels of multi-site test with a low-cost tester platform, expected to result in an about 50% reduction in test time.

Design and test considerations for an embodiment for parallel execution herein may include: 1) providing ability to allocate transmit/receive channels in loop-back modes ofFIGS. 1,9and19within and across RF modules (see dotted lines952,954,956from power amplifier, PPA inFIG. 19). 2) checking for frequency and power level compatibility. 3) supporting loop-back either internally to the die or externally on the board. 4) providing additional amplifiers and attenuators in some cases. If additional CW (continuous wave) sources from tester5are used with desired strength, concurrency may be impeded. A common interface across all IPs is desirable and provided on chip instead herein.

Test grouping of compatible tests is discussed next. Test groups are formed as follows:RX tests with external CW source.RX tests with internal signals.RX tests with external loop-back for compatible test.TX tests with external measurement support on board/tester5.TX internal loop-back tests—No signal outside IP boundary.

Examples include: DCO (Digital Crystal Oscillator) tests, LDO (low dropout regulator) tests, TX-DAC (Transmitter Digital to Analog Converter) and PPA pre-power amplifier tests. RX tests which uses same frequency CW (continuous wave, a single tone on-off) source are also clubbed or test-grouped for running concurrently. Additionally, RX tests can also be run concurrently since interference is low between the radios when tested on receive.

FIG. 13comparatively illustrates conventional sequential operation (Case 1) and advantageous parallel operation (Case 2) of an embodiment with specific tests T1, T2, T3, T4. For purposes ofFIG. 13, the different Test IDs are understood asIP1_T1, IP1_T2;IP2_T1, IP2_T2, IP2_T3, IP2_T4;IP3_T1, IP3_T2, IP3_T3.
In other words, tests IP1_T1, IP2_T1, IP3_T1are different tests adapted for different cores, even though they might in some cases be somewhat analogous in their test objectives.

Note how the time-extended serial schedule in Case 1 ofFIG. 13is converted to a much more compact and time-efficient parallel schedule in Case 2. Different directions of crosshatching are applied to time intervals for Load and for Dump that respectively bound the test-legended intervals of Execute operation inFIG. 13. Different bars for the different enumerated IP cores depict their serial (Case 1) or desirably parallel (Case 2) operations over time.

InFIG. 14, compatible tests are shown. As an illustration, this analysis has been performed on devices with BT, FM, GPS and WLAN radio modules. Criteria of test compatibility can specify that tests are compatible if: 1) Frequencies across TX and RX channels match. 2) Different RF modules can be clocked together. 3) Device can supply power for concurrent execution. 4) Tester can provide source and measurement support for desired level of multi-site testing.

FIG. 14illustrates an example of possible parallelism amongst compatible tests for an SOC with four radio IPs. Tests are grouped in compatibility classes approximately column-wise. Compatible tests can be run in parallel. Incompatible tests are run serially, i.e. those tests which cannot be run concurrently for different reasons, namely, requiring the same set of tester5resources, causing co-existence or coupling between the different RF modules, etc.

The illustration inFIG. 14is one schedule; while a compatibility table like Test ID Table110ofFIG. 3or test association table like TABLE 1A implies various possible schedules depending on the order in which tests complete and are initiated on a dynamic basis. The hardware scheduler140need not guarantee the generation of an optimal schedule to provide quite substantial and desirable test time reductions, but see description ofFIG. 23for an optimization process embodiment. The hardware scheduler140automates the scheduling process in hardware given a user supplied Test ID Table110inFIG. 3. Also the tests within an IP core inFIG. 14need not all be compatible, such as when only one test can run on an IP at a given time.

InFIG. 14, the tabular example (reading generally timewise from left to right) results from a process that first identifies and establishes parallelism of tests across Rx (receiver chain) to reduce receiver chain test time. Then the process identifies and establishes parallelism across Tx (transmitter chain) to reduce transmitter chain test time. Thereafter, concurrency amongst internal tests (e.g. PLL, DAC) is identified and established. The hardware scheduler can deliver the tests in the manner shown inFIG. 14given a particular ordering of the compatibility classes in a Test Id Table110. Accordingly, suppose a table such as that ofFIG. 14is arrived at manually, or by off-line optimization is described elsewhere herein, or otherwise prior to operation of the scheduler140. Then the scheduler can be made or forced as inFIG. 24to deliver tests in the manner represented by such table as ofFIG. 14by generating and delivering the appropriate particular ordering of the compatibility classes in a Test ID Table110.

FIG. 14illustrates a parallel test schedule across four IP modules for WLAN, BT, FM, and GPS. Explanations for tests inFIG. 14are listed next. The reader parses the lettered-designations of different tests with the help of the list here to best understandFIG. 14.

WR: WLAN tests which are independent of external input and do not send any data out of the IP. These tests are treated as WLAN RX tests. Tests with internal loop-back are also treated under this category.

BT: BT tests which are independent of external input and do not send any data out of the IP. These tests can run in parallel with WLAN and FM in RX mode.

FM: FM tests which are independent of external input and do not send any data out of the IP. There is no effect on these tests. If BT and WLAN are being tested in TX mode, i.e. these tests can run in parallel with BT and WLAN RX tests. (These tests have internal loop back and this distinguishes them from FMRX and FMTX tests).

WTX: WLAN tests which are in transmit mode. These tests transmit signals outside the SoC.

WTXRX: WLAN tests in transmit and receive modes. They transmit signals outside the SoC and there is loop back in receive path through wired connection. The direct feed in RX input reduces the risk of co-existence and inter-IP interference issues.

BTWR: BT RX tests. These BT tests can be run only when WLAN is in RX mode. Any WLAN tests in TX mode will affect the result of the tests.

T_BTWR: TX tests of BT which can affect WLAN RX tests. So while running these tests, WLAN should not be in RX mode. However, WTXRX tests can be run in parallel because they use wired loop-back connection.

G: GPS specific tests. These tests are receive path specific. Hence they can be run when all other IPs are in receive mode. G7is DAC test and can be scheduled with any other IP tests. Hence it can be separated out.

FMRX: FM tests in receive mode. The results of these tests are affected if these tests run in parallel with BT/WLAN in TX mode.

FMTX: FM tests in transmit mode. These tests can run in parallel with other IP tests in TX mode.

FIG. 15andFIG. 16show Test Time Estimations. Test time calculation examples based onFIG. 15follow. In serial mode, the test time mentioned for each IP, which includes power-up time, is =2367+3103+2412+2098=9980 milliseconds.

In concurrent mode, the SoC power-up corresponding to 300 ms will occur only once. IP tests running in parallel, i.e. time for TDL1(T2.ims)+time for TDL2(T3.ims)+time for TDL3(T4.ims) which is =300+1055+1137+846=3338 milliseconds. (Note: The legends like T2.irepresent designations of test time variables in milliseconds, not decimal milliseconds.) Additional scheduling overhead of 1000 milliseconds is taken into account to avoid inter-IP RF interference in WTXRX tests. The total time in concurrent mode therefore =3338+1000=4338 milliseconds.

Overall, the saving is 9980−4338=5642 milliseconds, which is around 56%.

FIG. 15is a bar chart of the test time savings statistics for the concurrent tests shown inFIG. 14, and shows the test time savings (4338 vs. 9980) for tested SOC with four radio IPs—WLAN, BT, FM, and GPS. In a test composition framework as inFIG. 14herein, compatible tests are grouped together, and different sequences of test cases can alter these groups. Incompatible tests lie in different groups, and incompatibility may be due to different initialization, different resources, co-existence, etc. Test time varies based on combinations of these groups. Automated embodiments for test grouping and scheduling are shown herein. Test composition framework automation embodiments to automatically compose tests inside a group, are suitably provided herein to allow for different test case combinations to be included, excluded, and/or sequenced to minimize test time and create final production test package(s).

InFIG. 15, a single power-up sequence (300 ms) is provided across all IPs for concurrent test operation. Individual IP specific power-up is considered for serial operation and the power-up time is included inside the IP test time. For the purpose of illustration, this component (as well as the component of scheduling overhead of 1000 ms) is removed inFIG. 16. Here both the serial and concurrent test times are lower than those inFIG. 15. This difference also highlights the usefulness of embodiments herein that provide circuitry to support a comprehensive power-up mode to realize the benefits of test concurrency across different IPs.

InFIGS. 15 and 16, Total Test Time (height of each histogram bar) is the sum of Initialization time+test time of longest test case (within concurrent set)+test time for non-compatible test cases. A test time reduction of over half or over 50% is projected in the case of a SOC embodiment with four internal radio IPs. This concurrency process can also be used for burn-in test of all IPs for maximum stress and test time reduction. (The example numbers are indicative of the benefits. The actual test times will vary based on composition of IPs, types of tests, and specific implementation for DFT and concurrent testing).

InFIG. 17, an embodiment of process of control operation forFIGS. 3-6is shown.FIG. 17is also suitably used to prepare hardware design code that then is used by a tool to generate circuits forFIGS. 3-6.FIG. 5Test List Control Logic150operations500inFIG. 17are listed as follows:Modify test list to reset bit corresponding to completed test. (590)Fetch new test list (530)If new test list is super-set (540) of present test list, merge test lists to trigger new tests (550). (Existing tests will continue.)If new test list is not a super-set of present test list, discard new test list. Continue with existing tests in present test list in step560.Wait (580) for another test to complete and repeat steps.

FIG. 5Address control logic130,234,238operations inFIG. 17:Upon completion of one test, increment address (520).Obtain next test list (530).If compatible, merge with existing test list (at step550, test list updating logic150).If not, decrement address (570). (Point to same test list).

Narratively, in the flow diagram ofFIG. 17, operations commence with a BEGIN510with a test list, such as the one in TABLE 1A or Test ID Table110. A row address variable j is initialized to zero, and present test list PT is initialized to empty (or all zeroes depending on manner of electronic representation). A number Jmax is loaded with the number of Table rows representing non-null compatibility classes. The row address j is incremented at a step520. A step530fetches a next test list NT to which the Test Pointer or row address thus incremented currently points. Test list NT is analogous to a compatibility class C(j), i.e. all tests compatible with test T#=j, or as specified in a row j of TABLE 1A. Step530resets NT to empty (all zeroes) if j>Jmax, which may occur in a later loop through the process.

A decision step540determines whether test list NT is a superset (includes at least all the elements, if any) of the currently existing present test list PT that is also called the modified test list. Put another way, let test list NT have ones and zeros representing whether each test is in the list or not; and same format for test list PT. If Test list NT at least has ones wherever PT has ones or if PT is null, then NT is a superset of PT. In set notation, if NT∩PT)=PT, then NT is a superset of PT. If Yes at step540, operations proceed to a step550that identifies any new tests NT&!PT (i.e., NT AND NOT PT), merges test lists NT and PT, and triggers any new tests thus identified. Notice that since merger of test lists depends on NT being a superset of PT in step540, the merger of test lists is the same as the set NT itself, so some embodiments have a simpler code PT=NT instead of explicit merger code PT=NT U PT. Steps520-550operate analogous to making a previous table row inapplicable (or over-writing “N/A” entries into a row) in an earlier-hereinabove described particular table among TABLEs 1A-1K. Existing tests in progress are continued. On the other hand, if No at decision step540, operations instead branch to a step560that continues executing existing tests in progress. Moreover, after step560, a step570decrements the address (j=j−1) to restore the value of the address as it was just prior to incrementing step520, analogous to staying at a particular table row j.

Further inFIG. 17, after either of steps550or570, operations go to a decision step580that determines whether any of the tests now in progress is newly completed. If not, operations branch back to step580itself until a test is completed whereupon the operations proceed to a step590. Step590resets an n-th bit Tn in test list PT, and resets the bit Tn for that n-th test in all the compatibility classes C(j), thereby electronically representing that the test is completed. This step590is analogous to making an n-th column inapplicable (or over-writing “N/A” entries into a column) in an earlier-hereinabove described particular table among TABLEs 1A-1K, and prevents triggering the same test possibly again on a subsequent pass through step550. (Some embodiments, however, may omit such resets in compatibility classes for which it is actually intended to repeat a particular type of test.) Some embodiments accomplish the step590resets by ANDing the latest row vector C(j) by ‘& !Tn’ for all tests Tn that have completed execution. Step590also initiates a Dump of test results from the just-completed Test Tn. From step590, operations go to a decision step595that determines whether all the tests are Done as indicated by both NT=0 and PT=0 (both all zeroes). If not Done at step595(No), operations loop back to step520that increments the address j. Otherwise, if Done (Yes) at step595, then operations are completed and reach a RETURN599. See also pseudocode of TABLE 3 below.

ForFIGS. 3-7, Test Execution Control and Test ID Issue Logic140(240) in some embodiments is represented by the following hardware design pseudocode and/or operational steps enumerated in the legends ofFIG. 3and listed below. Below, NT means new test list. PT refers to the present test list in the operations ofFIG. 17. Test Tn means a particular test that is a member of (one of) the set of tests NT. Note that pseudocode can be used to prepare various embodiments such as in hardware by interpreting the pseudocode as representing hardware design code, or such as in firmware by interpreting the pseudocode as representing a program listing, or otherwise in an appropriate manner for preparing embodiments.

The symbol Φ signifies Null Set. The symbol U signifies set union, bit-wise logical ORing of test lists, or merging test lists. The symbol ∩ signifies set intersection, or bit-wise logical ANDing (&) of test lists. (The symbols ∩ and & are essentially equivalent as used here, even as they have slightly different connotations from set theory and Boolean logic.) The symbol “!” signifies the logical complement, NOT. The symbol “=” signifies equality in a truth evaluation such as a conditional argument, and otherwise “=” signifies replacement (←) to the left from the right. A maximum row number is designated Jmax. Let the address index be j. See pseudocode of TABLE 3 below for introduction to the more detailed form of the pseudocode ofFIG. 4for an embodiment.

A somewhat more detailed form of the pseudocode ofFIG. 3for an embodiment is listed in TABLE 4 below. The symbolism

⋂n⁢!Tn
represents a bit field having bit positions corresponding to each of the tests, and each respective bit being zero (0) if its test has completed and otherwise one (1) if its test is still in progress or has not yet been triggered. Multiplication by

⋂n⁢!Tn
effectively makes respective columns inapplicable (N/A) for the completed tests.

An alternative form of the pseudocode for an embodiment is listed in TABLE 5 below, and tracks the narration ofFIG. 17wherein the decision Step4, or step540ofFIG. 17, is arranged to decide Yes if NT is a superset of PT.

ComparingFIG. 3with the above steps, such as from TABLE 3 or 4, note that Test Execution Control and Test ID Issue Logic140has a Stop input (‘Result of 2’) that receives Stop active from Address Generator130when step2condition is met in TABLE 3. Test Execution Control and Test ID Issue Logic140provides outputs to Address Generator130to cause it to effectuate address-related parts of steps1,2,5,6as legended inFIG. 3. Test Execution Control and Test ID Issue Logic140provides outputs to cause Test List Updating Logic150to list-update according to various parts of steps1,3,4,5, and8also as legended inFIG. 3and blocked out inFIG. 6for there-designated Test List Control Logic250. Test List Updating Logic150inFIG. 3or4delivers the output from step4,5to Test Execution Control and Test ID Issue Logic140. (Step4signals whether a superset relationship was found or not, so that aFIG. 25FSM in control140transitions to an appropriate state. States can be arranged straightforwardly, such as to correspond to step numbers in the pseudocode.) Test List Updating Logic150provides the Test List as Test IDs (NWT register bits) to the qualifying circuitry180for individual IPs in the SOC. Test ID=1 means a bit in NWT152is set to Execute the Test to which the bit position corresponds, else Ignore Test. In Step8, completion of the test by an IP sends a Test Complete signal back to Test Execution Control and Test ID Issue Logic140. SeeFIG. 9for Test exec signal lines that provide suitable Test Complete signals.

The tree of particular example operation shown byFIG. 7arises from the dynamically determined conditional outcomes of the hereinabove-listed looping process of the pseudocode listed or other processes tabulated forFIG. 17andFIG. 3.

TABLE 6 shows an example result of deriving a Test Compatibility Table (TABLE 6) from a Test Association Table (TABLE 1A). Each type of Table is suitably used with a type of circuitry140,150or firmware arranged to process it properly, such as by examples of tabulated pseudocode as taught herein. TABLE 6 is derived from TABLE 1A by the following procedure in TABLE 6A or any other appropriate procedure. Various embodiments can run the conversion in TABLE 6A or reverse-conversion in TABLE 6B either on the DUT chip, or off-chip beforehand, or not at all. For conciseness of expression in TABLES 6A and 6B, the column index n is omitted from matrices R(m, n) and C(j, n), which are instead referred to as R(m) and C(j).

TABLE 6TEST COMPATIBILITY TABLE DERIVED FROM TABLE 1A BYPROCEDURE ‘CONVERT’ OF TABLE 6AT1T2T3T4C1YYC2YYC3YY

TABLE 6B shows a procedure for a conversion in reverse, i.e., from a Test Compatibility Table to a square, symmetric Test Association Table.

Next, the discussion turns to the more complex Test ID Table entries ofFIG. 3that are shown there as Yes (Y) or blanks TABLE 7 shows the same entries in digital 1/0 form.

TABLE 7TEST ID TABLE 110 EXAMPLE FROM FIG. 3 IN DIGITAL FORM Cj)T1T2T3T4T5C111101C211010C301010C400111C500101C600010

TABLE 8 shows the evolving sets PT and NT as one example of a process embodiment performs its dynamic scheduling operations using TABLE 7 rows C(j) and TABLE 4 pseudocode. Set NT is replaced from the Test ID Table110(compatibility table) row-by-row, one row at a time, when the row address increments (j=j+1) in accordance with the flow inFIG. 17. Notice additional TABLE 7 rows and columns “ . . . ” that can have further possible entries inFIG. 3are omitted to simplify TABLE 8. This simplification may affect some of the last three rows of TABLE 8, which are nevertheless shown to facilitate some further comparison with the pseudocode of TABLE 4.

Different definitions of “compatibility class” lead to different sets of values for Test ID Table110and different embodiment Categories, as discussed next for at least four Categories. Different process embodiments can be applied to such sets of values and affect the manner of triggering new tests inFIG. 17step550and of executing other steps.

CATEGORY 1—Compatibility classes on table rows represent all largest distinct sets of tests that can execute concurrently. A formal definition for Category I is: ‘A given set of tests forms a compatibility class if every test in that set is compatible with all other tests in that set.’ In this type of embodiment, a latest table row is reached by the process provided that any tests that have been previously triggered from an earlier table row and are still running are all found in the latest table row. Then all remaining tests, if any, specified in that table row that have not already been triggered previously are triggered as quickly and concurrently with each other as possible. Put another way, all remaining tests, if any, specified in that latest set that have been up to that time yet to be triggered, are triggered approximately concurrently with each other.

Example 1: Compatibility class is {T1, T2, T3} if all three tests can execute concurrently.

Example 2: If T1can only execute with T2or execute with T3but not both, the compatibility classes are {T1, T2} and {T1, T3}.

Example 3: InFIG. 3, the rows show the compatibility classes and the leftmost column shows the Compatibility Class Id C(j) and not the Test ID. This example inFIG. 3corresponds with the formal definition just provided. The compatibility classes inFIG. 3are: C1: <T1,T2,T3,T5>, C2: <T1,T2,T4>, C3: <T2,T4>, C4: <T3,T4,T5>, C5: <T3,T5> and C6: <T4>. In some examples, the last compatibility class, e.g. C6, also is defined to include some or all Test IDs greater than those entered in the number of columns provided in the table, so that C6:<T4,Tests greater than Id 5>.

InFIG. 17step550, a type of suitable logic for this Category 1 triggers one or more tests out of the current compatibility class C(j). For purposes of comparing this Category 1 triggering logic with the Category 2 logic described in the next paragraph, note that compatibility class C(j) can also be identically represented by a bit-wise Boolean logic expression or function Tj U [C(j) & !Tj], this being a Boolean logic identity, where the notation “Tj” corresponds to all zeros except for a logic one in the j-th bit position.

CATEGORY 2: The table rows indicate sets of tests, each called a test association herein, that respectively comprise each test that is compatible (can execute concurrently) with the test signified by the Test ID in the leftmost column. Test associations on table rows represent at least one set of tests with any one of which a given test can execute concurrently. Table rows R(m) represent all largest sets of tests that can execute concurrently with the test signified by the Test ID in the leftmost (labeling) column. The rows do not directly indicate compatibility classes. This is because test compatibility “c” is intransitive, where (T2c T1) AND (T1c T3)—/→(T2c T3), meaning that if a test is compatible with each of two other tests, the other two tests are not necessarily compatible with each other. In some embodiments, the Test ID is entered down the main diagonal of the table as in TABLE 1A, and in some other embodiments the Test ID is regarded as implicit, or already represented by a row index, and is omitted from the main diagonal. In some Category 3 forms, the table represents a symmetric array because when test Ti is compatible with test Tj, then test Tj is compatible with test Ti; and vice versa. In some other Category 3 forms, the table represents a triangular array to represent the same information but save space.

Example 1: In TABLE 1A, for test T1, T2, T3are compatible. For test T2, the test T1is compatible. For test T3, Tests T1, T4are compatible. For test T4, the test T3is compatible.

Example 2: Test association is also {T1, T2, T3} if T1can only execute with T2or execute with T3. But at least one additional test association like {T1, T2} is specified if not all three tests can execute concurrently. When {T1, T2, T3} is the current test association, logic compares {T1, T2, T3} with the next-listed (or an elsewhere-listed) test association {T1, T2} and triggers tests appropriately out of the current test association. More generally, a subset of tests are triggered represented by a subset of data bits in one set of test association bits, and the control for the triggering is remarkably also based on data bits in another such set.

The tabular example in TABLE 1A is based on Category 2, Example 2—see row pairs (1,2) cut away as TABLE 9. Given intransitivity in TABLE 1A, TABLE 6 is an example of a test compatibility table that corresponds to the test association table TABLE 1A. WithFIG. 9in mind, a first type of logic embodiment under Category 2 interprets the next-listed test association as specifying tests to be launched together as a subset out of the current test association. InFIG. 7hardware scheduler operations, test T1and T2are chosen at “A” to run in parallel instead of all three tests T1, T2, T3in the test association of the first row R1. In the interpretation recognized by the type of embodiment of Category 2, Example 2, it may be noted from the first two rows that test T1is compatible to T2, T3, and T2is compatible to T1. Hence T2and T3are mutually not compatible. As a result, tests T1and T2or tests T1and T3can be parallelized, but not tests T2and T3. More than two tests could be allowed to run concurrently, e.g., if in the Table 1A, all pairs <T1,T2>, <T1,T3> as well as <T2,T3> were compatible. This can be indicated either by omitting the qualifying test row2(T2: Y, Y) and leaving the first test row (T1: Y, Y, Y) or by making each of these two test row entries (Y, Y, Y).

TABLE 9TWO TEST ROW ENTRIES FROM FIG. 1AT1T2T3T4R1YYYR2YY

A first type of suitable logic for Category 2 is represented by bit-wise Boolean logic expression or function Tj U [(R(j) & !Tj)& (R(j+1) & !T(j))], where the notation “Tj” corresponds to all zeros except for a logic one in the j-th bit position. Boolean simplification of the logic expression yields a logically equivalent but simpler expression Tj U [R(j) & !Tj & R(j+1)]. For example, logic at test row1(Tj=10000) compares {T1, T2, T3}=‘11100’ with the next-listed test association {T1, T2}=‘11000’ by that logic, and computes 10000 U [11100 & 01111 & 11000], which evaluates to 11000 and identifies tests T1and T2but not T3out of the current test association {T1, T2, T3}. Thus, detailed flow steps and logic circuitry specifically determine which two tests out of T1, T2, T3in the row R1test association are actually triggered at step550ofFIG. 17.

For an embodiment that operates in a way like Category 2 above and as narrated forFIG. 7, another example of pseudocode is listed in TABLE 10 below.

Another type of logic embodiment is somewhat like TABLE 10 but instead interprets a test association table like TABLE 1A by looking at a table row R(j) and then a next-listed (or some other) table row R(j+1) as telling what tests should not be launched together out of the current table row R(j). This second type of logic uses the logic function Tj U [(R(j) & !Tj)& !(R(j+1) & !T(j))], which simplifies to Tj U [R(j) & !Tj & !R(j+1)]. For example, logic at test row1(Tj=10000) compares {T1, T2, T3}=‘11100’ with the next-listed table row R(j) {T1, T2}=‘11000’ by that logic, and computes 10000 U [11100 & 01111 & 00111], which evaluates to 10100 and identifies tests T1and T3but not T2out of the current table row R(j)={T1, T2, T3}. Thus, detailed flow steps and logic circuitry specifically determine which two tests out of T1, T2, T3in the row R1table row R(j=1) are actually triggered at step550ofFIG. 17. More generally, in this type of embodiment a subset of tests are triggered represented by a subset of data bits in one set of test association bits, and the control for the triggering is also based on data bits in another such set representing at least one other of the tests in that other set, wherein that at least one other of the tests is not in that foregoing subset.

Accordingly, determination of which tests can be triggered from a given table row R(j) depends on information outside of that table row R(j). For instance in some of these embodiments, both the current table row R(j) and the next-listed table row R(j) are used as input to logic that determines what tests can be launched from the current table row R(j). Relative to the previous table row, though, the operation is as described for Category 1, i.e., a latest table row is reached by the process provided that any tests that have been previously triggered from an earlier table row and are still running are all found in the latest table row. However, an important difference is that one or more remaining tests, if any, that are specified in that table row and that have not already been triggered previously or are still running, are triggered now subject to the determination by the logic that consults not only a latest table row R(j) but also the next-listed table row R(j+1) at step550ofFIG. 17. Put another way, all remaining tests, if any, specified in that latest set that have been up to that time yet to be triggered, are triggered approximately concurrently with each other.

Other distinct embodiments of this type may be arranged, if the relationship among the various tests might call for it, by applying a logic function not only to the current test row and the next-listed one, but also the one after that—so that the logic function involves three or more test rows to determine what test(s) to trigger or launch out of a current test table row. For example, such a triggering logic function for step550ofFIG. 17in one such embodiment can be: Tj U [(R(j) & !Tj) & !(R(j+1) & !T(j)) & !Tj)& !(R(j+2) & !T(j))].

Referring now to TABLE 11A note that, in theFIG. 7narration of TABLE 1F, one type of embodiment monitors all active rows (i.e., NT≠Φ) of TABLE 1F on each pass and can go all way back to the first row if necessary. TABLE 11A shows pseudocode to execute that kind of monitoring all active rows of the table on each pass and executes an overall two-step that works with each row differently in a superset-subset pair of rows.

Referring now to TABLE 11B, still another embodiment is represented in pseudocode for an overall process based onFIG. 7. That TABLE 11B pseudocode combines a CONVERT procedure of TABLE 6A to convert a test association table R(m) forFIG. 7into a test compatibility table C(j) together with pseudocode that then triggers the tests based on the test compatibility table C(j) or any desired permutation of the rows therein (such as supported by Test ID Indexing Table170). The combined pseudocode in some embodiments is partitioned into a DUT on-chip portion, and an off-chip portion for CONVERT such as in tester5.

The description of some Categories of embodiments turns now to Category 3:

CATEGORY 3: Some embodiments are designated Category 3 when they have some kind of sequential logic circuit coupled with a storage circuit that can be loaded in some way with data bits and to which the sequential logic circuit responds in a manner that issues test trigger signals so that tests that are incompatible are prevented from executing in an overlapping manner. Notice how the various Categories and varieties of embodiments indicate the robustness and breadth of the technology covered.

Example 1: Test ID Table might have a given pair of tests indicated as compatible in one table row, and not indicated as compatible in another table row; or a pair of table rows might have logically inconsistent information according to some definitional interpretation and yet can still support concurrent testing of modules in actuality without issuing actually-incompatible tests. This example also relates to various forms that would be in Category 3 but that represent an array that is neither symmetric nor symmetric implemented triangular.

Example 2: Some sets of register file test IDs might not readily admit of consistent definition and yet deliver at least some concurrent operation of various tests that are not incompatible with one another. Put another way, various sets of pseudocode described herein, and other sequential logic circuit designs that can be prepared based on the teachings herein, are likely able to respond to various sets of data, whether or not illustrated in any of the TABLES herein, that don't fully fit any of the other Category descriptions and yet like them can usefully issue, initiate or trigger test triggers or commands for tests in a coordinated manner that executes faster than executing the tests seriatim, while preventing tests that are incompatible from executing in an overlapping manner.

Testing for proper operation of the dynamic scheduler ofFIGS. 3-7is done through access to SOC/IP production testing.

Compatibility classes exist between tests within an IP as well as across IPs. Hence, the embodiments in another type of applicability can provide support for multiple tests to be executed in parallel within an IP as well as across IPs. Note from a practical viewpoint, parallelism of tests within an IP may involve circuits wherein the test resources within an IP, namely, DMLED interface and other test mode control, and/or the processor inside are replicated or otherwise can support some parallelism (e.g., multiple circuits or processor CPUs). Also, a single DMLED interface at the SOC level may prohibit parallelism of tests within an IP unless that DMLED interface has sufficient parallelism itself. To the extent that some types of ICs may benefit from such embodiments, this support for multiple tests to be executed in parallel within an IP is pointed out.

Returning to the test schedule, it can be dynamically created, i.e. a set of tests can be moved across compatibility classes, since the scheduler100can combine the tests based on their unique Test IDs and as per the compatible test list, as inFIGS. 3-4and the merging operation inFIG. 17. This parallelism in test execution across multiple IPs is independent of the overall multi-site test solution created at the wafer/dies level. So, even though multiple dies are being tested in parallel, within a die multiple IPs can be tested in parallel.

Test concurrency for multiple IPs inside an SOC is provided and enhanced or extended in two forms herein: (i) An implementation structure operates for forking multiple tests and combining their results through the DMLED interface. (ii) A process of concurrent test is extended to include support for creating a dynamic schedule for the set of concurrent tests, through a hardware BIST controller, thereby providing various levels and types of concurrency amongst different radio IPs and the individual tests therein, which can be configured inside the SOC itself.

InFIG. 18, an interface15compatible with IEEE 1500 is used to setup/control many of the test related features within the functional integrated circuit80according to embodiments combiningFIG. 18with circuits and processes of any of the other Figures. In this way, tester5inFIG. 1communicates with an interface820,830,840,875that couples chip-level test pins with a functional integrated circuit80and provides a test wrapper to allow access to the functional integrated circuit80. The test wrapper has a Wrapper Shift Register820for serial entry of instructions and data via a Wrapper Shift Input WSI and can scan out resulting information at Wrapper Shift Output WSO. A Wrapper Instruction Register830is coupled and controlled to receive the test instructions from Wrapper Shift Register820. A Wrapper Data Register840is coupled and controlled to receive the test data from Wrapper Shift Register820or conversely to deliver resulting data to Wrapper Shift Register820for serial scan out at WSO. A set of control signals NRESET, CLKREF, WRCK, WRSTN, SELECTWIR, SHIFTWR, UPDATE WR, AND CAPTUREWR control these operations.

Further inFIG. 18, an 8-wide input WPI[7:0] feeds a Decompressor860as well as a Load Execute Dump LED interface10and a programmable BIST or PBIST, interface and improved as inFIGS. 2-6and the other Figures herein. Decompressor860provides and sets up a bit-image for functional integrated circuit80to operate upon. LED10and PBIST interface100are coupled to control what operations are to occur and be tested as taught herein. Decompressor860cooperates with scan chains in circuit80, and Compactor870, as well as IR drop monitoring circuits if desired, and any or all of them are included in combination embodiments with the test wrapper ofFIG. 18. A mux875has three inputs respectively fed by a Compactor870, by an output from the Load Execute Dump LED interface10, and by an output from the PBIST interface100. Mux875delivers test results to an output designated WPO[7:0]. Functional integrated circuit80also has boundary scan registers that provide functional I/O and also have a serial input WBI[(W−1):0] and a serial output WBO.FIG. 18is one illustration of a particular on-chip test interface15to tester5, and various embodiments may use some other test interface or none at all.

InFIG. 19, an RF transmit/receive TX/RX circuitry section is tested in a given one of the IP cores ofFIGS. 1,9and20. The transmit TX and receive RX circuits are in approximately the upper and lower halves respectively ofFIG. 19.FIG. 19depicts a Cartesian coordinates-based implementation, and various tests herein may also be performed on a Polar coordinates (‘r’ and theta θ) implementation of a radio. Various tests include 1) TX DACs linearity. 2) DCO (digitally controlled oscillator) circuit scan checks performance of all capacitances (varactors) and inductances. 3) Phase Noise BiST PHE in TX means possible transmissions into unintended frequency channels. 4) Loopback gain BIST covers the Pre-Power Amplifier (PPA). 5) Signal paths may be impaired due to IC defects in either the RX or TX paths. 6) RX DACs linearity, sensitivity. 7) RX Phase Error PHE can lead to reduced sensitivity. 8) Loopback gain BiST to cover Low Noise Amplifier (LNA), and cover Transconductance Amplifier (TA) and mixers. Test multiplexer MUX910operates on some tests to couple either I-DAC or Q-DAC (Digital analog converter from the in-phase (I) channel or quadrature (Q) channel) of the transmitter circuit path back to either the I-ADC or Q-ADC (analog to digital converter for I or Q) of the receiver circuit path. A test multiplier MUX920couples various test sources such as LDOs or PDET to test the I-ADC and Q-ADC and further circuitry farther down the receive chain. In other tests for testing still more of the circuitry, as shown by dashed lines, external loopback952goes between PPA and LNA, and/or internal loopback954goes between PPA and TA. In this way, an up-converter960, and down converter970, as well as PPA, LNA, and TA, are conveniently tested too. In still other tests, such as for coexistence or non-interference between radios, external loopback956goes from PPA of one radio to the LNA of another radio in the system or in SOC80.

Effectively, these embodiments are applicable for the concurrent test of any suitable type integrated circuit with any kind and suite of tests. Radio modules provide a particularly interesting case of a type of integrated circuit that calls for such a variety of tests in that it makes test scheduling difficult. This is because (i) the test schedule is often dynamic, since the impact of one test on another (co-existence amongst IPs) may force a re-grouping of these tests, (ii) it is statically difficult to create these tests, since tests across multiple IPs have to be packaged together keeping in mind the exact number of test execution cycles, and (iii) inherently these tests often change based upon the pass/fail criteria associated with specific performance parameters for the individual radio modules. As a result, a one-time schedule as part of the overall SOC test plan is increasingly difficult to fix. Hence, a hardware scheduler embodiment herein provides the flexibility to dynamically configure these tests. Numerous implementations of the hardware scheduler100are possible relating to the structure of the Test ID Table110, and regarding Test Execution Control and Test ID Issue Logic140and Test List Updating Logic150, among other structures shown or possibly used in still other embodiments.

As noted, the embodiments in this disclosure are applicable, among other things, to all classes of digital circuits where concurrent testing can be used and to all types of systems using such circuits. Another system context is depicted inFIG. 20, by way of example and not of limitation.

It is contemplated that the skilled worker uses each of the integrated circuits shown inFIG. 20, or such selection from the complement of blocks therein provided into appropriate other integrated circuit modules, or provided into one single integrated circuit module, in a manner optimally combined or partitioned between the modules, to the extent needed by any of the cellular telephones, radios and televisions, Internet audio/video content players, fixed and portable entertainment units, WLAN gateways, routers, pagers, personal digital assistants (PDA), organizers, scanners, faxes, copiers, household appliances, office appliances, microcontrollers coupled to controlled mechanisms for fixed, mobile, personal, robotic and/or automotive use, combinations thereof, and other application products now known or hereafter devised for increased, partitioned or selectively determinable advantages. For some background on system on chip technologies, see U.S. Patent Application Publication 20080307240 (TI-60478) “Power Management Electronic Circuits, Systems, and Methods and Processes of Manufacture,” which is incorporated herein by reference in its entirety.

InFIG. 20, a cell phone modem1100,1200,1300is suitably interfaced with an applications processor1400and various radios for WLAN1500, Bluetooth1430, GPS1495, FM1720, and others. Applications processor1400, for example, can include a RISC processor1422(such as MIPS core(s), ARM core(s), or other suitable processor), a digital signal processor (DSP)1424such as from the TMS320C55x™ DSP generation and/or the TMS320C6x™ DSP generation from Texas Instruments Incorporated or other digital signal processor(s), and a shared memory controller1426with DMA (direct memory access), and a graphic accelerator for a 2D or 3D (two/three-dimensional display)1266. The RISC processor1422and the DSP1424suitably have access via an on-chip extended memory interface (EMIF/CF) to off-chip memory resources1435including as appropriate, mobile DDR (double data rate) DRAM, and flash memory of any of NAND Flash, NOR Flash, and Compact Flash. On-chip RAM/ROM1440provides on-chip storage, and interfaces1410couple the processors1422and1424to the off chip peripherals. A USIM (universal subscriber identification module)1195is coupled with an interface portion of DBB/IF1200.

InFIG. 20, circuitry for digital baseband DBB/IF1100, analog baseband/power management ABB/PM1200, and RF TX/RX1300supports and provides wireless modem interfaces for any one or more of GSM, GPRS, EDGE, UMTS, and OFDMA/MIMO (Global System for Mobile communications, General Packet Radio Service, Enhanced Data Rates for Global Evolution, Universal Mobile Telecommunications System, Orthogonal Frequency Division Multiple Access and Multiple Input Multiple Output Antennas) wireless, with or without high speed digital data service HSDPA/HSUPA (High Speed Downlink Packet Access, High Speed Uplink Packet Access) (or 1xEV-DV, 1xEV-DO or 3xEV-DV), via an analog baseband chip and GSM/CDMA transmit/receive chip (in cell modem). SDRAM1024and flash memory1025suitably provide memory support for DBB/IF1100.FIG. 19provides a representative detail of parts of RF TX/RX for any of the wireless modems such as RF TX/RX1310/1370, WLAN RF1540, Bluetooth1430, and others. A switchplexer or circulator1350couples RF power amplifier1330and RX1370with bandpass filter1360to a cell phone antenna1015.

An audio/voice block in ABB/PM1200is suitably provided to support audio and voice functions and interfacing. A microphone1224and an audio output transducer1222are coupled with ABB/PM1200. Speech/voice codec(s) and speech recognition are suitably provided in memory space in an audio/voice block in ABB/PM1200for processing. Applications processor1400in some embodiments is coupled to location-determining circuitry for satellite positioning such as GPS (Global Positioning System)1190or1495and/or to a network-based positioning (triangulation) system, to an accelerometer, to a tilt sensor, and/or other peripherals to support positioning, position-based applications, user real-time kinematics-based applications, and other such applications.

ABB/PM1200includes a power conversion block, power save mode control, and oscillator circuitry based on crystal1290for clocking the cores. A display1266is provided off-chip. Batteries1280such as a lithium-ion battery provide power to the system and battery data.

Further inFIG. 20, chip (or core)1400interfaces to high-speed WLAN 802.11a/b/g/n (Wi-Fi) MAC (media access controller)1510, PHY1520, AFE1530, WLAN RF1540and a WLAN antenna1545. Other data wireless interfaces are suitably provided for co-existing IEEE 802.15 (Bluetooth and low and high rate piconet, Zigbee, and personal network communications) wireless circuit. Other interfaces suitably include a MCSI voice interface, a UART interface for controls and data to position unit GPS and otherwise, and a multi-channel buffered serial port (McBSP) for data. FM radio front end1720is coupled with a DVB front end1810, and they are together coupled with ABB/PM mixed signal chip1200and/or applications processor1400by control line1625and input lines1619. A configurable Doppler MPE/FEC circuit1620supports the DVB. Further in peripherals, a MicroWire (u-wire 4 channel serial port), and USB, and a multi-channel buffered serial port (McBSP) to Audio codec, a touch-screen controller, and audio amplifier1480to stereo speakers. External audio content and touch screen (in/out) and LCD (liquid crystal display), organic semiconductor display, and DLP™ digital light processor display from Texas Instruments Incorporated, are suitably provided in various embodiments and coupled to interface of core1400for fixed, portable, mobile and/or vehicular use. An interface provides EMT9 and Camera interfacing to one or more off-chip still cameras or video cameras1490, and/or to a CMOS sensor of radiant energy. PRCM1470(power, resets and control module) provides power management.

InFIG. 20, in some embodiments, GPS1495operates in close coordination with any one, some, or all of WLAN, WiMax, DVB (digital video broadcasting), or other network, to provide positioning, position-based, and user real-time kinematics applications. Still other additional wireless interfaces such as for wideband wireless such as IEEE 802.16 WiMAX mesh networking and other standards are suitably provided and coupled to the applications processor integrated circuit and other processors in the system.

Various production-testable and/or field-testable system embodiments with one or more SOCs are provided on a printed circuit board (PCB), a printed wiring board (PWB), and/or in an integrated circuit on a semiconductor substrate.

InFIG. 21, a multi-site (multi-die) system and process are shown. As described herein, one level of test concurrency is within the SOC device. Hence if the SOC has N radio modules (e.g., as inFIG. 2,9or20) and the tests amongst them are compatible, then each SOC80.M can effectively have up to N tests running in parallel, one in each IP core or module IP1, IP2, . . . IP-N. Likely values for N are in the range 3 to 5 and other values are possible. Multi-site test capability can also provided by the tester5ofFIG. 1, or by each or any of several testers1,2, . . . R. For a by-M (i.e. xM) multi-site capability, M devices are tested in parallel, wherein M dies (SOCs80.1k, .2k, . . . Mk of a given SOC type k) are contacted simultaneously by the tester5. Some values of M for one type of tester5(VLCT) are 2, 4, 8, and 16. The ×16 multi-site can be attained by some devices, and some can go to ×32 and ×64. Hence in this case, N*M tests are run in parallel, where M and N are mutually independent. It may, however, be noted that the VLCT has finite resources to support the test of M devices with N IPs in each. These are number of power supplies, number of signal generators, number of PLLs and clocks, number of measurement channels, etc. Nevertheless, the embodiments do not restrict M and N from a capability point of view. The number M of devices tested in parallel need not be considered by the controller100in each SOC80, while the number N of parallel tests only increases the size of the Test ID Table110, (and possibly Test ID Indexing Table170) with no impact on theFIG. 25FSM or other controller140for the hardware scheduler. Moreover, inFIG. 22, designate the SOCs80.ikof type k SOC die individually indexed i within type k. Each particular tester5.k, in one kind of manufacturing system embodiments, suitably tests multiple dice i of one type k of a SOC80. Each tester5.kis provided with the appropriate Test ID Table110like TABLE 1A, to test SOCs of type k, or the tester is provided with sufficient information inFIG. 22data storage2530to generate and download the Test ID Table to each die i for one type k of SOC. In another kind of system embodiment, a tester R is provided with sufficient information inFIG. 22data storage2530to generate the Test ID Tables for two or more types k of SOC, and the tester communicates via multiple probe assemblies with different dice i of each type k of SOC80.ikunder test.

InFIG. 21, higher levels of sourcing and control are also shown. Production test or production lines L1, L2, . . . LX are suitably provided in a wafer fabrication facility, or an assembly/test facility or in different ones of such facilities. Each of the X test lines has a test line gateway for appropriately distributing test code for various tests from a test storage or library to one or more testers1,2, . . . R like tester5ofFIGS. 1-2. At an even higher level, a number S of Test Sources1,2, . . . S, such as at different remotely located design sites, originate electronic packages having one or more test codes to any one, some or all of the facilities having the production test lines L1-LX. The distribution between levels is suitably either wired or wireless. The various levels have numerousness values S, X, R, M, N that are independent and allow any amount of replication and concurrency of tests suitable to different products, technologies of SOCs and the modules, and varying volume of production or facility loading in ongoing manufacturing operations.

FIG. 22shows an example of a test sub-process2500that generates, e.g., values for TABLE 1A or Test ID Table110inFIG. 3. InFIGS. 1-2, this sub-process2500is suitably stored as instructions in tester storage and executed by a tester processor in tester5and conveyed by a tester interface to the DUT SOC80. The instructions may alternatively be stored and executed in a test line gateway or at a remote original source or elsewhere inFIG. 21. Recall that Test Table110is processed according to the flow description ofFIG. 7or ofFIG. 17.FIG. 22describes how that Test Table is generated or loaded in the first place. Test ID Table110has a Number of columns NCequal to a Total number Tn of tests (marked as T1-T5, etc). Number of rows NR=Jmax equals a Total number Cn of compatibility classes (marked as C1-C4, etc). Operations inFIG. 22commence with a BEGIN2510and proceed to a step2520to fetch Test IDs j of the particular tests to be applied to a given type of SOC80.ito be tested as DUT. Step2520accesses a storage2530that has a space2534for a list of types of SOCs i, a space2536for a list of the Test IDs j applicable to each type of SOC i, and a space2538specifying the tests in each of the compatibility classes C(j) for each of the Test IDs j. A succeeding step2540fetches only the particular compatibility classes C(j) for each of the Test IDs j actually found or determined in step2520to be used in testing SOC i. (In some embodiments, the space2538may itself provide compatibility classes C(i, j) specific to each particular SOC i.) A further step2550for each of the Test IDs j eliminates, from each compatibility class C(j) that was fetched, all Test IDs except those Test IDs j actually found or determined in step2520to be applicable for use in testing SOC i. (In some process embodiments, step2550is omitted if the compatibility classes have been prepared with only SOC i in mind.)

In a succeeding step2560, the embodiment sorts the Test ID Table110with a descending order of test cardinality, i.e. rows with more number of tests are ordered before rows with fewer number of tests. Then in a step2570operations re-order the rows such that all tests for a given test are adjacent. See the example tables inFIG. 3or TABLE 1A. Put another way, steps2560and2570together re-order the rows so that the leftmost active entry in the first row is the test T1in the first column. In succeeding rows, these steps2560and2570together arrange the rows so rows with the same leftmost active entry are grouped together in descending order of cardinality, and then the test represented by the leftmost active entry increments in an increasing order. So, for example, inFIG. 3, the leftmost active entries row-by-row are: T1, T1, T2, T3. In TABLE 1A, the leftmost active entries row-by-row are: T1, T1, T1, T3.

A step2580downloads resulting table data to constitute Test ID Table110in each of one or more integrated circuit dice i of SOC type k, whereupon operations go to and branch back from a decision step2590via a step2595that selects the next SOC type k for support at step2520, and so on. Decision step2590detects (Yes) when all the one or more types k of SOC have had their Test ID Table generated and downloaded, whereupon operations reach RETURN2599.

Turning toFIG. 23, note also that the order of execution of the same tests Tn may change depending on their order of enumeration in Test ID Table110ofFIG. 3or4. For example, if the tests T1-T6were instead designated so that T1is called ‘T6’, T2is called ‘T5’, . . . and T6is called ‘T1’, then the Test ID Table110would be arranged in a different order of rows by the process ofFIG. 22. In general, the dynamic scheduling process provides a more efficient schedule of concurrent or overlapping tests when at least one pair of the tests are compatible (i.e., feasibly and more efficiently run concurrently, compared with a static schedule that runs all the tests one after the other). Moreover, some embodiments predetermine the length of time that each test takes to run on the DUT as a set of respective duration values Dj, such as by running each test individually in simulation or on a prototype of the SOC as DUT. Then the total length of time is optimized off-line according to the process flow ofFIG. 23. One way of doing this is to execute the process ofFIG. 23for all N! permutations F(j) of the N Test ID designations j, determine a dynamic schedule according toFIG. 17and calculate the total length of time (instead of actually executing production tests yet on the DUT) based on the dynamic schedule for each Test ID Table permutation, and then determine which total time is minimum and issue the Test ID Table permutation to the DUT as an optimized Test ID Table110inFIG. 3or4. Alternative optimization embodiments can likely smartly reduce the amount of off-line calculations below N! by taking advantage of any symmetries or interchangeabilities for scheduling purposes among the tests. The schedule ofFIG. 14represents an example of a relatively compacted schedule for particular tests and types of IP cores as illustrated. Some embodiments then specifically cause or enforce the order by ordering the compatibility classes in a Test ID Table suitably and downloading them from the tester5to DUT Test ID Table110.

InFIG. 23, this off-line looping process embodiment2600commences with a BEGIN2610and then proceeds to a step2620that gets the test identifications j and durations Dj from an area2634of a storage2630. On the first time through step2620, a permutation function F(j) is an identity function F(j)=I or identity matrix I that leaves the vector of test identifications j unchanged (not permuted). Then by accessing a storage area2638, a step2640obtains the compatibility classes C(F(j)) for the tests in their current order F(j). A succeeding step2650sorts and reorders the compatibility classes C(F(j)) to make a scheduling table as described forFIG. 22steps2560and2570. A succeeding step2660inFIG. 23then computes a total test time TT that would be consumed by executing the tests in an overlapping manner based on the particular scheduling table generated by step2650. A further step2670performs a determination of whether that test time TT value is less than any TT value thus far found, and if so, stores the particular permutation F(j) and the latest TT value as TTmin in area2639of storage2630. Until all permutations have been checked, operations loop back via a step2685that systematically applies the next different permutation function F(j) out of the N! possibilities and then goes to step2640again, and so on. Step2685applies the permutation function F(j) such as by entering F(j) or otherwise suitably programming inFIG. 4Test ID Indexing Table170. Eventually, all the permutations are evaluated, and operations go from decision step2680to a step2690. At step2690, the scheduling table that yielded the minimum total time TTmin is generated by A) retrieving the permutation function F(j) that was involved in obtaining TTmin, B) executing steps2640and2650to generate that scheduling table, and C) downloading the resulting scheduling table to the tester5if not already there. Tester5downloads that scheduling table to the DUTs for production test. Following the step2690, a RETURN2699is reached.

InFIG. 24, a process embodiment2700generates a particular ordering of compatibility classes C(m) for a Test ID Table starting from a schedule such as ofFIG. 14in case that schedule has been arrived at beforehand. Basically, the overall process2700scans across the schedule and assembles compatibility classes as it goes. Process2700commences with a BEGIN2710and then a step2720initializes a compatibility class index m to one (1) and accesses the storage2730for the various test IDs j and their durations (area2734), and for times Ts(j) of starting execution and times Te(j) of ending execution (area2736). A further step2740repeatedly scans or accesses the schedule in timewise order. A first compatibility class C1, or C(m=1) is the set union or accumulation in step2750of all tests that execute compatibly. Process2700assembles the compatibility classes C(m) and stores them in area2738usingFIG. 14as follows:C1={T1, T2, T3, T4} whereT1is WLAN tests WR1+WR2+WR3+WR4+WR7+WTXRX11+WTX8,T2is BT tests BTWR2+BTWR3+BTWR4+BTWR1+BT9,T3is FM tests FMRX2+FM7+FM6+FM4+FM5,T4is GPS tests G1+G2+G3+G4+G5+G6+G8+G9+G10.C2={T5, T6, T7, T8} whereT5is WLAN tests WTX9+WTXRX12,T6is BT tests T_BTWRS+T_BTWR6+T_BTWR7+T_BTWR8.T7is FM tests FM3+FM8+FM9+FM10,T8is GPS test G7.C3={T9, T10} whereT9is WLAN test WTX10, andT10is FM test FMTX1.

In TABLE 12, the appropriate particular ordering of those compatibility classes for a Test ID Table110is correspondingly derived using the flow ofFIG. 24and the particular schedule ofFIG. 14.

Suppose, for another example and to more fully describe the process ofFIG. 24, that process is applied to the schedule represented by Case 2 ofFIG. 13. The process at step2750accumulates in the same compatibility class C(m) any test(s) that starts executing while all the others are still in progress, i.e. concurrently with one another whether or not they are somewhat staggered. After step2750, a decision step2760determines whether any test in a current compatibility class C(m) has just ended. If so (Yes) at step2760, then operations go to a decision step2770that waits and determines whether a test that is not in the current compatibility class C(m) has just started. If Yes at step2770, then a new compatibility class m=m+1 is established at a step2775. Operations loop back from step2775to steps2740and2750so that new C(m) includes any test(s) from the just-previous compatibility class that are still in progress plus the test that just started. Over successive loops back, the following compatibility classes C1-C6based on Case 2 ofFIG. 13are progressively evolved according to the process2700ofFIG. 24as follows:C1={IP1_T1, IP2_T1, IP3_T1}C2={IP2_T2, IP1_T2}C3={IP1_T2, IP3_T2}C4={IP1_T2, IP2_T3}C5={IP2_T3, IP3_T3}C6={IP2_T4}.

Process2700includes a branch from decision step2770(No) back to decision step2760as long as no new test is starting outside the current compatibility class C(m). Also, until a test ends inside C(m) at step2760, operations branch from step2760(No) to a decision step2780the checks whether there are any more tests indicated in the schedule obtained from storage2730. If so (Yes), then operations branch from decision step2780to the decision step2760. At some point, no more tests exist and operations instead go from decision step2780to an output step2790that downloads a Test ID Table110comprised of compatibility classes C1-C6to the SOCs80.ik.

Notice that some embodiments can operate on lists or sets as written out as records in the above example, and some other embodiments operate on a storage table110as in TABLE 13 equivalently as follows:

Some additional embodiments explicitly recognize in a data structure which IP cores the tests run on. SeeFIG. 12, Case 2. For instance, suppose test T1can run on cores2and3concurrently, and test T2can run on cores1and2concurrently. Suppose test T1and test T2cannot run on the same core concurrently, however. Test T2could be launched on core1concurrently with test T1commencing on cores2and3. As soon as test T1completes on core2, perhaps prior to completing on core3, then test T2can be launched on core2in parallel with the ongoing test T1in progress on core3. An embodiment of a dynamic test process and structure is thus contemplated that uses all three of the dimensions of compatibility class, test type, and IP cores.

Where each IP core has unique tests, Test N may be uniquely associated to a particular IP core M. For example, one can arrange a full set of 10 tests for IP1numbered T1to T10, a full set of 8 tests for IP2numbered T11to T18, and a full set of 7 tests for IP3numbered T19to T25, etc. This unique numbering is applicable such as when a given test cannot run on any IP core other than the one it is associated with. DMLED operation involves a processor and memory. Each core has its dedicated processor. Hence a test may likely be uniquely associated with a processor and IP. Some embodiments recognize or perform a generalization wherein identical tests across IP cores are considered in compatibility classes. In some other embodiments or their Test ID Table, one can choose instead to just enumerate and number similar tests uniquely as well, in systems or SOCs wherein the tests are dedicated to a processor inside a radio module.

Turning toFIG. 25, a finite state machine FSM embodiment is shown for Test Execution Control and Test ID Issue Logic140(240) ofFIGS. 3-6. FSM executes the process represented by TABLES 3, 4 hereinabove. This FSM is represented by theFIG. 25state transition diagram that has an IDLE state to which all any currently active FSM state implicitly goes upon test circuit Reset or system Reset. FSM operations commence at the IDLE state when such Reset is lifted from the scheduling logic. Any unmarked transition arrow transitions on test clock. A combined state, or states between which transitions occur on test clock, can be indicated by multiple numerals in a circle. An FSM control register142has output bits wherein a respective bit in register142is set active (e.g., 1) when its corresponding state is entered by FSM140, and reset inactive (0) upon exit from that state. These register142bits act as enables for the logic circuits in Address Generator130and Test List Updating Logic150that perform their enumerated operations. The operations of FSM as illustrated inFIG. 25relate to TABLES 3-4 and the descriptions ofFIGS. 3-6,10and17. The FSM state transition diagram is readily rearranged to correspond to intended operations for other embodiments, such as indicated by the various different TABLES of pseudocode herein.

The test circuitry herein also facilitates testing of operations in cores or modules having any of RISC (reduced instruction set computing), CISC (complex instruction set computing), DSP (digital signal processors), microcontrollers, PC (personal computer) main microprocessors, math coprocessors, VLIW (very long instruction word), SIMD (single instruction multiple data) and MIMD (multiple instruction multiple data) processors and coprocessors as cores or standalone integrated circuits, and in other integrated circuits and arrays. The diagnostic circuitry is useful in other types of integrated circuits such as ASICs (application specific integrated circuits) and gate arrays and to all circuits with structures and analogous problems to which the advantages of the improvements described herein commend their use.

In addition to inventive structures, devices, apparatus and systems, processes are represented and described using any and all of the block diagrams, logic diagrams, and flow diagrams herein. Block diagram blocks are used to represent both structures as understood by those of ordinary skill in the art as well as process steps and portions of process flows. Similarly, logic elements in the diagrams represent both electronic structures and process steps and portions of process flows. Flow diagram symbols herein represent process steps and portions of process flows in software and hardware embodiments as well as portions of structure in various embodiments of the invention. Steps in flow diagrams may in some cases be changed in their order, supplemented or deleted to form still further process embodiments. The embodiments may have logic circuits that are high-active (active=1) as primarily used in the description, or may employ low-active logic (active=0), or mixtures of both. Some embodiments can include multiple bits and error correcting logic instead of using a one-hot single bit (such as the trigger bit for each test) in the description hereinabove.

ASPECTS (See Notes paragraph at End of This Aspects Section)

17A. The wireless chip claimed in claim 17 wherein at least one of said cores has a RF (radio frequency) plus MS (mixed-signal) circuit, and said test circuit has an embedded processor that is operable to provide controls to said RF plus MS circuit including transmission and reception, so that a test runs on said embedded processor that in turn controls the operation and sequencing of such RF+MS circuit in at least one of said cores to run a transmit and/or receive sequence through loopback between the transmit and receive channels within or across radios.

41A. The electronic process claimed in claim 41 wherein when the condition is met that said another compatibility class takes the place of the one such accessed compatibility class in the conditional determination.

41B. The electronic process claimed in claim 41 wherein when at least one test completes, the electronically executing step is then repeated.

42A. The integrated circuit claimed in claim 42 further comprising functional modules responsive to the test trigger output signals to selectively perform one more test represented by the test trigger output signals and to supply a test completion signal indicating which test is completed to said sequential control logic.

42A1. The integrated circuit claimed in claim 42A wherein said sequential control logic is responsive to said test completion signal to update a command signal to said address generator.

42A2. The integrated circuit claimed in claim 42A wherein said test list updating logic is operable to reset one or more bits in at least one such test list in response to the test completion signal for each test that is completed.

42A3. The integrated circuit claimed in claim 42A wherein said sequential control logic is responsive to said test completion signal to again actuate said test list updating logic.

42A4. The integrated circuit claimed in claim 42A wherein said sequential control logic is responsive to said test completion signal to initiate a Dump for each newly-completed test.

42B. The integrated circuit claimed in claim 42 wherein said test list updating logic is operable to signal said sequential control logic with a determination whether one test list is a superset of another test list or not, and said sequential control logic is responsive to that determination to signal said address generator to change or effectively maintain an address to said control storage.

42C. The integrated circuit claimed in claim 42 wherein said sequential control logic is responsive to said test list updating logic to signal said address generator to change or effectively maintain an address to said control storage, the address when effectively maintained being the result of said address generator reversing a change to the address.

42D. The integrated circuit claimed in claim 42 wherein the test trigger output signals initiate a Load operation for each newly-triggered test.

42E. The integrated circuit claimed in claim 42 wherein said test list updating logic includes further logic coupled to operate on at least two of the tester output signals in tandem.

42F. The integrated circuit claimed in claim 42 wherein said test list updating logic includes a structure to associate a first group of one or more of the tests to a particular functional module and to associate a second different group of one or more of the tests to a different functional module.

43A. The testable apparatus claimed in claim 43 further comprising a user interface coupled with said processor and operable to actuate operations involving said first modem and said second modem.

43B. The testable apparatus claimed in claim 43 further comprising a printed wiring board coupling said storage circuit and said processor.

43C. The testable apparatus claimed in claim 43 wherein said modems, processor, and storage circuit are adapted for an article selected from the group consisting of 1) cellular telephone, 2) internet content player, 3) wireless gateway, 4) television, 5) automotive wireless entertainment unit.

44A. The electronic test circuit claimed in claim 44 wherein said processing circuit is further operable to conditionally access the second portion of said storage for the additional entries before all tests in the first portion are completed on the condition that the remaining tests in the first portion are included in the second portion.

44A1. The electronic test circuit claimed in claim 44A wherein said processing circuit is operable to issue test trigger signals based on the second portion of said storage depending on a condition.

44B. The electronic test circuit claimed in claim 44 further comprising an address generator operable to actuate said storage with at least one address to access said first portion and at least another address to access said second portion of said storage.

44C. The electronic test circuit claimed in claim 44 further comprising a test updating logic circuit having a trigger enable register and coupled with said storage and operable to update said trigger enable register based on information from a least one said portion of said storage and information already in said trigger enable register.

44C1. The electronic test circuit claimed in claim 44C further comprising a functional circuit operable in response to said trigger enable register to execute a test and to signal completion of the test to said processor circuit.

44C2. The electronic test circuit claimed in claim 44C further comprising a functional circuit operable in response to said trigger enable register for a test execution and to signal completion of the test, said test updating logic circuit operable to update said trigger enable register after the signal occurs.

44C3. The electronic test circuit claimed in claim 44C wherein said trigger enable register has bits indicating compatible tests that are ready for execution.

44C4. The electronic test circuit claimed in claim 44C further comprising at least two functional cores, a set of logic gates coupled to receive respective bits from the trigger enable register, and a second register indicating functional core enables coupled to plural ones of the logic gates in said set of logic gates, said logic gates having outputs coupled to said functional cores.

45A. The electronic circuit claimed in claim 45 wherein said storage circuit holds data bits representing compatibility classes that represent all largest distinct sets of tests that can execute concurrently such that every test in that set is compatible with all other tests in that set.

45B. The electronic circuit claimed in claim 45 wherein said sequential logic circuit logic forms a logic function based on plural sets of the data bits and triggers tests out of a selected set of the data bits based on a selection condition involving the logic function.

45B1. The electronic circuit claimed in claim 45B wherein the selection condition involving the logic function includes a superset relationship between at least one pair of the sets.

45C. The electronic circuit claimed in claim 45 wherein a latest set is accessed from said storage circuit by said sequential logic circuit provided that any tests that have been previously triggered from an earlier-accessed such set and are still running are all represented in the latest set.

45C1. The electronic circuit claimed in claim 45C wherein all remaining tests, if any, specified in that latest set that have been up to that time yet to be triggered by said sequential logic circuit, are triggered approximately concurrently with each other.

45D. The electronic circuit claimed in claim 45 wherein said sequential logic circuit is operable to launch a subset of tests represented by data bits in one set based on data bits in another set.

45E. The electronic circuit claimed in claim 45 wherein said sequential logic circuit is operable to launch a subset of tests represented by data bits in one set based on data bits representing at least one other of the tests outside that subset and in another set.

45F. The electronic circuit claimed in claim 45 wherein said sequential logic circuit is operable to effectively make one or more particular data bits inapplicable in one or more of the sets.

45G. The electronic circuit claimed in claim 45 wherein said sequential logic circuit is operable to effectively make one or more particular sets inapplicable.

45H. The electronic circuit claimed in claim 45 wherein said storage circuit holds data bits representing only a triangular portion of a symmetric array.

46A. The multi-site system claimed in claim 46 wherein the distribution is wireless.

46B. The multi-site system claimed in claim 46 further comprising wafer probe assemblies respective to each of the testers, at least one said wafer probe assembly adapted for manufacturing multiple die per wafer.

46C. The multi-site system claimed in claim 46 wherein each of said testers is operable in response to the test codes and the compatibility data to run multiple tests in parallel in each of multiple die.

46D. The multi-site system claimed in claim 46 further comprising wafers with multiple die per wafer, the testers operable each to download at least a portion of the test codes and compatibility data as between tests into each die under test.

46D1. The multi-site system claimed in claim 46D wherein each of the multiple die has a scheduling circuit operable to run at least some of the tests concurrently and dynamically schedule them based on the compatibility data and actual completion events of at least some of the tests in each such die.

47A. The tester claimed in claim 47 wherein the first storage area in said storage includes a space for a list of types of integrated circuits and a space for a list of test identifications applicable to each such type of integrated circuit, and a space specifying the test identifications in respective compatibility classes, and wherein said tester processor is operable to fetch the particular compatibility classes applicable to a given integrated circuit.

47B. The tester claimed in claim 47 wherein the first storage area in said storage includes a space for a list of test identifications, and a space specifying the test identifications in respective compatibility classes, and wherein said tester processor is operable to use the particular compatibility classes to generate the test scheduling table.

47B1. The tester claimed in claim 47B wherein the test identifications are orderable and said tester processor is operable to fetch compatibility classes from said storage and re-order the compatibility classes in order of test identification therein.

47B2. The tester claimed in claim 47B wherein the test identifications are orderable and said tester processor is operable to fetch compatibility classes from said storage and re-order the compatibility classes in order of test identification therein and in descending order of cardinality within groups of the compatibility classes having the same first test identification therein.

47C. The tester claimed in claim 47 wherein said tester processor is operable to fetch particular compatibility classes from said storage and sort those compatibility classes so that compatibility classes with a larger number of tests are ordered before compatibility classes with a fewer number of tests.

47C1. The tester claimed in claim 47C wherein the first storage area in said storage includes a space for a list of test identifications and the test identifications are orderable and said tester processor is operable after fetching and sorting particular compatibility classes from said storage to re-order the sorted compatibility classes in order of test identification therein.

47D. The tester claimed in claim 47 for manufacturing a particular type of integrated circuit wherein said tester processor is operable to fetch compatibility classes from said storage applicable to that particular type of integrated circuit, said tester processor further operable to effectively permute the particular compatibility classes and estimate a predicted test time for each such permutation and identify a particular permutation that corresponds to a predicted test time that is no greater than for other such permutations and then store information specifying the identified particular permutation.

48. A process of dynamic scheduling comprising:

providing a test list;

initializing a row address variable;

incrementing the row address;

fetching a next test list NT to which the row address currently points wherein test list NT indicates a compatibility class C(i) of tests compatible with test T#=i;

determining whether test list NT is a superset of a currently existing test list PT, and if so, merging test lists NT and PT to trigger execution of at least one new test, but if not then discarding the new test list NT and decrementing the address to restore the value of the address as it was just prior to the incrementing; and

continuing existing tests in progress so that as soon as any of the tests now in progress is completed, then resetting a T# bit associated with the test list PT, where that T# bit represents that the test is completed; and

looping back to the incrementing.

48A. The process claimed in claim 48 further comprising terminating the process when the rows of the test list are exhausted by the incrementing of the row address.

48B. The process claimed in claim 48 further comprising progressively applying the tests to different radio cores in a system.

48C. The process claimed in claim 48 wherein the at least one of the compatibility classes is selected from the group consisting of 1) receive tests with external source, 2) receive tests with internal signals, 3) receive tests with external loop-back, 4) transmitter tests with external measurement support, 5) transmitter internal loop-back tests.

Notes about Aspects above: Aspects are paragraphs which might be offered as claims in patent prosecution. The above dependently-written Aspects have leading digits and internal dependency designations to indicate the claims or aspects to which they pertain. Aspects having no internal dependency designations have leading digits and alphanumerics to indicate the position in the ordering of claims at which they might be situated if offered as claims in prosecution.

Processing circuitry comprehends digital, analog and mixed signal (digital/analog) integrated circuits, ASIC circuits, PALs, PLAs, decoders, memories, and programmable and nonprogrammable processors, microcontrollers and other circuitry. Internal and external couplings and connections can be ohmic, capacitive, inductive, photonic, and direct or indirect via intervening circuits or otherwise as desirable. Process diagrams herein are representative of flow diagrams for operations of any embodiments using any one, some or all of hardware, software, or firmware, and processes of manufacture thereof. Flow diagrams and block diagrams are each interpretable as representing structure and/or process. While this invention has been described with reference to illustrative embodiments, this description is not to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the invention may be made. The terms including, includes, having, has, with, or variants thereof are used in the detailed description and/or the claims to denote non-exhaustive inclusion in a manner similar to the term comprising. The appended claims and their equivalents should be interpreted to cover any such embodiments, modifications, and embodiments as fall within the scope of the invention.