Systems, apparatuses, and methods for functional testing of one or more structures of a processor

Abstract

In one embodiment, a device includes at least one fabric and a fabric bridge controller. The at least one fabric is for engaging with a plurality of intellectual property (IP) blocks of the device. The at least one fabric includes at least one state storage device. The fabric bridge controller is coupled to the at least one fabric. The fabric bridge controller may be configured to initiate a functional safety test of the at least one fabric in response to a fabric test signal received during functional operation of the device, receive the results of the functional safety test via the at least one state storage device, and send a test report to a destination location based on the results. Other embodiments are described and claimed.

Description

Technical Field

[0001] The embodiments relate to processors with self - testing capabilities. Background Art

[0002] In integrated circuits (ICs), structures and other interconnections serve as the backbone for system data transfer between the core and other intellectual property (IP) logic circuits of the IC. Functional safety requirements in specific industries (e.g., medical and automotive industries) stipulate that silicon manufacturers meet strict requirements for low defects (e.g., 10 - 15 defects per million (DPM)), especially for components integrated into autonomous driving systems. It is difficult to manufacture typical ICs for general - purpose computing systems (e.g., personal computers and server computers) to meet these requirements without significantly increasing the product cost.

[0003] Factors contributing to high DPM in typical ICs include high process defect density of components (e.g., in 14 - nanometer and smaller process nodes), walking dead units, and non - uniform aging. The term "walking dead unit" refers to an IC that passes initial product testing and burn - in but fails during field use. Current product testing schemes include manufacturing - based tests performed by the manufacturer of the IC and / or the platform manufacturer containing the IC within a given platform. However, this testing is insufficient once the IC is placed in the platform and sent to the field for normal operation. Brief Description of the Drawings

[0004] Figure 1 is a block diagram of a part of a computing system according to an embodiment.

[0005] Figure 2 is a block diagram of a structural bridge controller according to an embodiment of the present invention.

[0006] Figure 3 is a high - level view of a method for functional testing according to an embodiment.

[0007] Figure 4A and Figure 4B is a flowchart of a method according to another embodiment of the present invention.

[0008] Figure 5 is a block diagram of an example system that can use an embodiment.

[0009] Figure 6 is a block diagram of a system according to an embodiment of the present invention.

[0010] Figure 7 is a block diagram of a system according to another embodiment of the present invention. Detailed Description

[0011] In various embodiments, techniques for providing periodic triggering and performing on-chip self-tests can be provided to an integrated circuit such as a processor or other system-on-chip (SoC). More specifically, the techniques disclosed herein provide dynamic functional safety testing capabilities for the architecture and other interconnects of a processor. In an embodiment, such on-chip self-tests can be performed according to one or more test patterns that can be obtained in different ways.

[0012] In some cases, these test patterns can be obtained from non-volatile memory coupled to the processor. In other cases, as described herein, the internal circuitry of the processor itself can generate such test patterns. More generally, the self-test patterns are referred to herein as "test programs", which can include such test patterns, as well as additional test information, e.g., operating parameters for the test, indication locations where the test is to be performed, reported characteristics, etc. Other programmable parameters can include whether to send a posted transaction or a non-posted transaction. For a posted transaction, no completion is received from the destination, while the destination responds to a non-posted transaction with completion data. Seed data to be initiated with the transaction can also be included. Using such a seed, the sequence of data commands / data generation can be determined.

[0013] In an implementation where the test program is stored in non-volatile memory, for enhanced security, a security circuit such as a separate component coupled to the processor can obtain the test program, validate its content, and then transfer the test program to the architecture bridge controller of the processor via a package interface. In an implementation where the test program is generated internally, the architecture bridge controller or other circuitry of the processor can be configured to perform test generation itself.

[0014] As further described herein, the programmable fabric bridge controller can be configured to receive test programming, initiate and control such tests, analyze the results, and send information related to the results to one or more destinations (e.g., non-volatile storage devices) for later access by system entities. Further, in the case where one or more faults or other errors are identified, the fabric bridge controller can be configured to convey such error / fault information to a given destination, e.g., an end user or other system entity. For example, the basic input / output system (BIOS) can be configured to read the test result information and, in the instance of an error / fault, notify the system controller of the action to take. Although the embodiments are not limited in this regard, examples of such actions can include shutting down the system until a corrective action occurs. In other cases, particularly where no fault is indicated, the test result information can simply be stored in a given location for later access. For example, the test results can be stored in association with a security circuit that can provide such test result information to non-volatile memory at a later time for later reading by the BIOS for system reporting.

[0015] By using low-cost on-chip hardware, embodiments achieve techniques for meeting functional safety goals by detecting structural defects and error reporting in a given platform such as an autonomous vehicle system. Further, dynamic test capabilities are achieved by periodically triggering on-site tests. Using such tests, various defects can be easily identified, including walking dead zone cells and cells that malfunction due to environmental conditions. Thus, embodiments enhance the ability of semiconductor manufacturers to meet low DPM critical system requirements without a significant increase in cost. Although the scope of the present invention is not limited in this regard, in embodiments, periodic (e.g., key-on / key-off) tests allow specific circuits to be tested periodically to potentially identify fabric-specific defects (e.g., latent faults) and checker circuit defects (e.g., data and command parity errors).

[0016] In different implementations, the fabric bridge controller has multiple programmable options. As a first option, the fabric bridge controller can use a custom test program obtained from non-volatile memory. As a second option, the fabric bridge controller can use built-in capabilities to locally generate tests and initiate transactions on the fabric. In embodiments, the determination of which fabrics to test and the order of testing can be based on criticality.

[0017] Although the embodiments are not limited in this regard, the test program can use different operations to exercise various circuits. For example, the test program can cause reporting transactions to be generated for various intellectual property (IP) blocks and / or inject errors into command / data blocks. Similarly, non-reporting transactions can be sent to various IP blocks that can respond to enable data to be observed in the fabric bridge controller.

[0018] In an embodiment, the structural bridge controller may collect test results and analyze and / or aggregate such results to generate a final state, which may be transmitted to the safety circuit. In turn, the safety circuit may send the test results to a non-volatile storage device. In another case, firmware such as BIOS may also directly read the status from the safety circuit. BIOS may ultimately report this status to the system monitor to determine the action to be taken.

[0019] In some cases, the action to be taken depends on the criticality of the error. For correctable errors, the structural bridge controller may initiate error correction. An example of a correctable error is single error correction based on error correction coding (ECC). Uncorrectable errors may cause a warning to the user (e.g., the driver) to drive the vehicle safely or prompt the driver to switch to manual mode, thus shutting down the autonomous vehicle system until corrective action is taken.

[0020] Now referring to Figure 1 , a block diagram of a portion of a computing system according to an embodiment is shown. As an example, the computing system 100 may be an automotive computing system, an industrial computing system, a medical computing system, etc. Thus, the computing system 100 may be configured to have high availability such that critical mission operations can occur without errors over a long period of time. To this end, the computing system 100 may be configured with components for performing functional safety tests during normal operation of the system, identifying and potentially correcting errors, and reporting uncorrectable (and possibly correctable) errors to an appropriate destination.

[0021] More specifically, as will be described herein, the computing system 100 is configured to perform functional safety tests on one or more structures implemented within the processor 110. As described herein, the processor 110 may be a multi-core processor, a system-on-chip (SoC), or any other computing integrated circuit. To achieve high availability for critical mission applications, the processor 110 is configured to perform functional safety tests on one or more structures included within the processor 110.

[0022] The computing system 100 also includes additional platform components coupled to the processor 110. As seen, the Peripheral Controller Hub (PCH) 180 can be implemented as a separate integrated circuit coupled to the processor 110. Although shown as a separate integrated circuit, in other embodiments, at least some of the circuitry of the PCH 180 can be implemented within the processor 110. Additionally, the computing system 100 also includes a non-volatile storage device 190, which can be implemented as flash memory in an embodiment. In addition to storing various platform information including system firmware, system software, data, etc., the non-volatile memory 190 is also configured to store test information used as described herein.

[0023] Figure 1 Some details of the processor 110 are shown. However, it should be understood that the illustration of the processor 110 is at a relatively high level; a given processor can include more or fewer components and can be configured differently. In any case, the processor 110 includes a plurality of structures 1150 - 1153. It should be understood that although four structures are shown for ease of illustration, a given implementation can include more or fewer structures. In the illustrated embodiment, the structure 115 (generally) can be implemented as a Primary Scalable Fabric (PSF), to which various IP agents (commonly referred to herein as "IP logic" or "IP blocks") such as processor cores, accelerators, fixed function units, security circuits, interfaces, switches, routers, etc. can be coupled. Note that in an embodiment, the PSF can be an Integrated On-Chip Scalable Fabric (IOSF), which can be designed according to a given specification of a semiconductor manufacturer that provides a standardized on-die interconnect protocol for attaching IP blocks within the chip.

[0024] In most cases, Figure 1 such IP blocks are not shown so as not to obscure the structure-based test functionality described herein. However, specific IP blocks are shown coupled to specific structures. Specifically, the structure 1150 can include a plurality of internal ports or other interfaces to enable coupling to the display circuit 150, the image processing unit 152, and the Peripheral Component Interconnect Express (PCIe) circuit 155. In turn, these various IP blocks can be coupled to other components both inside and outside the processor 110. It should be understood that cores and other agents can be coupled to one or more structures 115, for example, via a coherent interconnect.

[0025] As will be further described herein, the processor 110 includes a fabric bridge controller 120. In an embodiment, the fabric bridge controller 120 may be configured to control in-field functional safety testing of the fabric within the processor 110. Further still, the fabric bridge controller 120 is configured to interact with additional circuitry of the computing system 100, including the PCH 180, to implement a secure communication path and further access test information within the non-volatile memory 190.

[0026] As shown, the fabric bridge controller 120 includes a sideband router 122, which may implement communication of sideband information, including results of functional testing as described herein. More specifically, the sideband router 122 may implement communication of, for example, error status information from the fabric 115 (such as stored in a corresponding error status storage device 116 of a given fabric). To this end, each fabric may include a sideband interface for coupling to a corresponding sideband router (1250 - 1253) of the sideband network to implement communication of various sideband information, including error reporting information and other test result information, from each fabric 110 within the fabric 110 to the fabric bridge controller 120. In an embodiment, transactions may occur via this sideband network according to a sideband protocol that is the same IOSF specification applicable to PSF. The fabric bridge controller 120 may process such information to perform error detection, error correction, test reporting, etc.

[0027] Still referring Figure 1 , the display engine (DE) 130 sends a display stream to an external display and is coupled between a switch 160, which may be implemented as a Thunderbolt TM switch in an embodiment, and an input / output (I / O) adapter 170. In one embodiment, the I / O adapter 170 may be a flexible I / O adapter (FIA). The I / O adapter 170 in turn provides an interface to a plurality of physical units (PHY), including PHY1650 - 1651. As further shown, the switch 160 is also coupled to additional components of the processor 110. In the illustrated embodiment, the switch 160 is coupled to a host direct memory access (DMA) circuit 132, and the host DMA circuit 132 is further coupled to the fabric 1153. Additionally, the switch 160 may be coupled to a PCI interface 134 via one or more PHY interfaces for Express PCI (PIPE) interfaces, and the PCI interface 134 is also coupled to the fabric 1153. Further still, the switch 160 is also coupled to an extended host controller interface (xHCI) 140, which is further coupled to the I / O adapter 170 via a PIPE link and to the fabric 1152 via an xHCI link.

[0028] As can be seen, the PCH 180 includes a security circuit 182. In an embodiment, the security circuit 182 can be implemented as a dedicated security processor, e.g., a coprocessor, a security engine, a fused security engine, etc. As will be described herein, the security circuit 182 is coupled to the non-volatile storage device 190 and can receive incoming encrypted and signed test information. The security circuit 182 can authenticate such test information and, upon authentication, decrypt it and provide the decrypted test information to the fabric bridge controller 120 via the sideband router 184. It should be understood that although shown at this high level in the Figure 1 embodiment, many variations and alternatives are possible.

[0029] Now referring to Figure 2 , a block diagram of a fabric bridge controller in accordance with an embodiment of the present invention is shown. More specifically, the fabric bridge controller 200 is a more detailed description of the Figure 1 fabric bridge controller 120. Thus, the fabric bridge controller 200 can communicate with both on-chip sources and off-chip sources. More specifically, via the sideband router 220, the fabric bridge controller 200 can communicate with non-volatile memories (e.g., mediated by a security circuit or other PCH circuits), and similarly can communicate with at least one on-chip sideband router. Additionally, the fabric bridge controller 200 can communicate with at least one on-chip primary fabric via the fabric interface 240.

[0030] The programmability of the fabric bridge controller 200 can include several programmable options. As an example, the programmability includes whether to generate on-die test programs for test circuits (e.g., specific IP logic, fabric, etc.), and programming a seed value to start test content generation. Additional programmability can include the target fabric segments and IP logic to be tested, the order of system fabric testing, etc.

[0031] Furthermore, the programmability can include which information from test results is considered critical and non-critical for the final report. As an example, errors that can be corrected by a fabric having existing redundant hardware are considered non-critical, while uncorrectable errors are reported as critical. Note that this criticality programmability is in addition to the BIOS / software decoding criticality of reported errors. Note that the fabric bridge controller 200 can be configured to communicate with each IP logic and fabric component of the SoC.

[0032] As further shown, the fabric bridge controller 200 includes a programmable register bank 205. The register bank 205 can be configured to host transactions arriving from an external flash memory or generated internally. The register bank 205 can also collect transactions received by the fabric bridge controller 200 from IP blocks. In an embodiment, separate register banks can be allocated within the register bank 205 for reporting transactions, non-reporting transactions, and completed transactions. The programmable register bank 205 can be configured to be programmably controlled to initiate test operations based on, for example, test information received from non-volatile memory. The programmable register bank 205 can also receive test information generated within the fabric bridge controller 200 itself. More specifically, the fabric bridge controller 200 includes a pseudo-random generator 230, which is configured to generate test information that can be used to perform functional safety tests on one or more fabrics.

[0033] The fabric bridge controller 200 also includes a test result analyzer 235, which is configured to receive the results of a fabric test and determine pass / fail status, error messages, etc. The safety analyzer 235 can aggregate the results from multiple fabrics and IP blocks and generate an aggregated test report.

[0034] A safety analyzer 225 is also present within the fabric bridge controller 200 and can be used to perform a safety check on incoming test information received from outside the chip. In an embodiment, this safety information can be in the form of initiator security attribute (SAI) information. Note that when operating in bridge mode, the fabric bridge controller 200 conducts safety information, e.g., the SAI of an external safety circuit, and does not include its own SAI. In other functional safety test modes, the fabric bridge controller 200 can send its own SAI. With this bridge mode, it is ensured that no fabric / endpoint discards test packets initiated by the fabric controller 200 due to an unrecognized SAI. This is the case because the SAI of the safety circuit is considered a trusted SAI, such that all fabrics / endpoints comply with this SAI. The test result analyzer 235 can perform several safety checks during this mode. For each incoming transaction, the SAI will be checked against a set of allowed SAIs, and the operation will be aborted in case of a mismatch. The encrypted test transmitted from the flash memory is decrypted using a stored key, and the checksum of the program is confirmed against an expected value to detect any program tampering.

[0035] To enable structural testing to occur, the programmable register bank 205 is coupled to the main control circuit 212, which may be implemented as a finite state machine (FSM) in an embodiment. In an embodiment, the main control circuit 212 may be configured to push a request to the fabric when an injection command is received from a control register of the programmable register bank 205. The main circuit 212 may also be configured to steer the first-in-first-out (FIFO) unload pointer logic when a corresponding authorization is received from the fabric. In turn, incoming test result information may be received in the target control circuit 215 via the fabric interface 240. In an embodiment, the target control circuit 215 may be configured as an N-state FSM and is responsible for polling the receive signal from the fabric. Note that test transactions obtained or generated within the fabric bridge controller 200 may be transmitted via the fabric interface 240 based on credit information generated within the credit initialization circuit 210. In an embodiment, the credit initialization circuit 210 may be implemented as an FSM such as an idle state machine for controlling when transactions are allowed on the main channel of the interface. The ISM also provides protocols for clock gating and credit initialization.

[0036] Now referring to Figure 3 , a high-level view of a method for functional safety testing according to an embodiment is shown. As Figure 3 shown, the transaction flow 300 for performing fabric functional safety testing may be initiated by the BIOS 305. It should of course be understood that in other embodiments, another system software or firmware agent may initiate the functional safety testing. More specifically, the BIOS 305 may issue a periodic interrupt during normal system operation when performing functional safety testing is feasible or possible. In the autonomous vehicle system example, this interrupt may be triggered when the vehicle is idle, e.g., stopped at a stop light, etc. In other cases, when the vehicle is powered on or off, the functional safety testing may be initiated in response to an interrupt in response to the key-on and / or key-off conditions.

[0037] As shown, these periodic interrupts are provided via the safety circuit 310, which verifies the interrupt received from a trusted source, i.e., the BIOS 305. If this is the case, the safety circuit 310 interacts with the non-volatile memory 315 to initiate the loading of one or more test programs, which may be transmitted to the fabric bridge controller 325 via the sideband network 320. In response to receiving the test program information, the fabric bridge controller 325 may program itself for a given type of functional safety testing. Thus, the fabric bridge controller 325 programs multiple fabrics of the processor, here represented by the main fabric 330 n -330 n+1issue various transactions for functional safety testing. Some of these transaction types include: configuration (Cfg) transactions for configuring various IP blocks; report writes targeting control registers within an IP block (e.g.); and non-report reads for reading data from registers within an IP block (e.g.). Of course, it should be understood that there may be more structures in a particular embodiment. Further, while embodiments for testing the main structure are described herein, it should be understood that the scope of the present invention is not limited to this aspect, and in other cases, the techniques described herein can also be used to test other types of structures or interconnections, such as, secondary structures, etc.

[0038] As shown, structure 330 can transmit the results of the test to structure bridge controller 325 via sideband network 320, which can aggregate the results and take appropriate actions. In an embodiment, bridge controller 325 can send a sideband request message to obtain test result information. Assuming all tests pass, the aggregated test report providing these results can be transmitted to safety circuit 310. Safety circuit 310 can then record the report in non-volatile memory 315 for later access by the system. Note that if a correctable error is identified, structure bridge controller 325 can initiate a mechanism to correct the error, e.g., identify an erroneous memory block within the memory map to disable that memory block. Similar operations can also be performed to identify faulty circuits that can be disabled and replaced with spare circuits. In the case of uncorrectable errors or other faults, structure bridge controller 325 can generate an error report and send the error report via safety circuit 310, which can trigger a system error indicator to enable the system to take appropriate measures. It should be understood that while shown at this high level in the Figure 3 embodiment, many variations and alternatives are possible.

[0039] Now referring to Figure 4A and Figure 4B FIGs. 4A and 4B, a flowchart of a method according to another embodiment of the present invention is shown. More specifically, from the perspective of a structure bridge controller as described herein, method 400 is a high-level view of a functional safety testing process. Thus, method 400 can be performed by hardware circuits, firmware, software, and / or combinations thereof. As shown, method 400 begins by receiving a test interrupt in the bridge controller (block 410). In an embodiment, this test interrupt signal can be received from system software. As an example, system software (e.g., firmware) can issue this test interrupt signal when it identifies an appropriate time when a functional safety test can be performed. Such a time can be an idle period of system operation (e.g., when the vehicle is stopped), key-on or key-off conditions, etc.

[0040] In any case, control is passed next to diamond 415 to determine whether to generate test content internally. In an embodiment, an interrupt signal can identify whether functional safety test content will be generated internally. In other cases, the interrupt signal can be followed by test content to indicate that test content is not generated internally. In different scenarios, internal test generation can occur for more basic tests of the structure, while external test content can be provided instead to test critical features / functions of the structure.

[0041] If it is determined that test content is to be generated internally, control is passed to block 420. At block 420, the bridge controller can generate test content based on a seed value. For example, the seed value can be stored in a register within the bridge controller. In an embodiment, a test writer can program this register using a sideband network. During a test operation, this seed value can be provided to a pseudo-random number generator that generates test content in response to the seed value. Random content generation can involve generating commands from a pre-programmed set of errors (e.g., memory read / write, configuration read / write, IO read / write, etc.) and associated random data. The number of commands may be limited and stored in a register. A linear feedback shift register (LFSR) can be used to generate data associated with the commands. For each operation in the operation, one of the commands is randomly selected, and at the same time, random data can be generated on the die using the LFSR. Thus, relatively deterministic test content (and thus relatively deterministic test results) can be generated by this pseudo-random number generator.

[0042] Conversely, if it is determined that internal test generation does not occur, control advances to block 425, where test content can be received from an external storage device (e.g., a given non-volatile memory of the system). Next, it is determined whether the test content is authenticated (diamond 430). In one embodiment, the bridge controller can verify that the test content is genuine, for example, using SAI information, etc. In an embodiment, the authenticity of the content is checked to ensure that it has not been tampered with. The checksum of the loaded test program is compared with an expected value, and if any differences are found, program execution is terminated. This checksum calculation provides a unique signature that distinguishes one digital footprint from another. If authenticity is not found, control is passed to block 435, where an error can be raised, for example, to the firmware that triggered the self-test.

[0043] Assuming the test content is confirmed, control passes to block 440 where the test content is sent to one or more structures. For example, a fabric bridge controller can issue one or more transactions to various fabrics, such as reporting transactions or non-reporting transactions. To this end, the bridge controller can be configured to generate such a transaction (e.g., a write transaction) that includes the test content, which can be directed to a specific destination (e.g., one or more primary scalable fabrics) by way of identifying the fabric in the destination identification information of the transaction, which enables the transaction to be routed to the appropriate destination.

[0044] Still referring to Figure 4A , at block 445, the test result can be requested via the sideband network. That is, the bridge controller can reduce the traffic on the primary fabric by requesting the test result via the sideband network, which is implemented using multiple sideband routers coupled to various agents and fabrics. In one embodiment, the request can be issued as a non-reporting read transaction. Then at block 450, the test result is received via the same sideband network. In turn, these test results can be processed within the bridge controller (block 455). For example, in an instance where the test content is sent to multiple fabrics (and test results are received from multiple fabrics), the processing can include aggregating the test results from different fabrics into an aggregated result.

[0045] Now referring to Figure 4B , such processing can also include identifying whether one or more errors are detected. Thus, control can proceed to diamond 460 to determine whether an error is detected. If an error is detected, it can be determined whether the error is correctable (diamond 465). If no error is detected, control passes to block 490 where an error report can be generated. Such an error report can include various information about the error, including the location of the error, the type of the error, etc. Thereafter at block 495, the test result including the error report can be sent to the platform component. However, the scope of the present invention is not limited thereto. In one embodiment, the platform component can be a non-volatile storage device. Note, however, that the test result including the error report can be provided to the system controller to take appropriate actions, including raising an error to the user, shutting down some or all of the system, etc.

[0046] Still referring to FIG. 4, conversely, if it is determined that the error is correctable, control passes to block 470 where a request for error correction can be sent to an error correction circuit. As an example, the correction circuit can block a portion of the memory array in which an error has been detected in the memory map so that this portion of the memory array is no longer used. In any case, control then passes to block 480 where the test results can be sent to a platform component. Note that in this instance (either because no error was detected or because a correctable (and corrected) error was detected), the test results can be recorded in, for example, a platform non-volatile storage device for later access by system software. It should be understood that while shown at this high level in the embodiment of FIG. 4, many variations and alternatives are possible.

[0047] Functional safety testing as described herein can be implemented in a variety of system types, ranging from small portable devices to larger and more complex computing devices. Now referring Figure 5 , a block diagram of an example system in which embodiments can be used is shown. In Figure 5 the illustrated example, system 500 can be a mobile system, such as, for example, a tablet computer, a 2-in-1 tablet, a phablet, an in-vehicle system, or other systems. As shown, there is a SoC 510, and the SoC 510 can be configured to operate as an application processor of the device. The SoC 510 can include agents and constructs that can be tested during normal operation as described herein.

[0048] Various devices can be coupled to the SoC 510. In the illustrated example, the memory subsystem includes a flash memory 540 and a DRAM 545 coupled to the SoC 510. Additionally, a touchpad 520 is coupled to the SoC 510 to provide display capabilities and user input via touch, including providing a virtual keyboard on the display of the touchpad 520. To provide a wired network connection, the SoC 510 is coupled to an Ethernet interface 530. A peripheral hub 525 is coupled to the SoC 510 to enable engagement with various peripheral devices, for example, that can be coupled to the system 500 through any of a variety of ports or other connectors.

[0049] In addition to the internal power management circuitry and functions within the SoC 510, a PMIC 580 is coupled to the SoC 510 to provide platform-based power management, e.g., based on whether the system is powered by a battery 590 or AC powered via an AC adapter 595. In addition to this power source-based power management, the PMIC 580 can also perform platform power management activities based on environmental conditions and usage conditions. Further, the PMIC 580 can convey control and status information to the SoC 510 to cause various power management actions within the SoC 510.

[0050] Still referringFigure 5 , to provide wireless capabilities, the WLAN unit 550 is coupled to the SoC 510 and in turn coupled to the antenna 555. In various implementations, the WLAN unit 550 can provide communication according to one or more wireless protocols. As further shown, a plurality of sensors 560 can be coupled to the SoC 510. These sensors can include various accelerometers, environmental and other sensors, including user gesture sensors. Finally, the audio codec 565 is coupled to the SoC 510 to provide an interface to the audio output device 570. Of course, it should be understood that although shown in this particular implementation in Figure 5 , many variations and alternatives are possible.

[0051] Now referring to Figure 6 , a block diagram of a system according to an embodiment of the present invention is shown. As Figure 6 shown, the multiprocessor system 600 is a point-to-point interconnect system and includes a first processor 670 and a second processor 680 coupled via a point-to-point interconnect 650. As Figure 6 shown, each of the processors 670 and 680 can be a multi-core processor, including a first processor core and a second processor core (i.e., processor cores 674a and 674b and processor cores 684a and 684b), but potentially more cores are present in the processors. Each processor in the processors can include fabric (675, 685) or other interconnect circuitry on which functional safety tests can be performed as described herein.

[0052] Still referring to Figure 6 , the first processor 670 further includes a Memory Controller Hub (MCH) 672 and point-to-point (P-P) interfaces 676 and 678. Similarly, the second processor 680 includes an MCH 682 and P-P interfaces 686 and 688. As Figure 6 shown, the MCHs 672 and 682 couple the processors to the respective memories, i.e., memories 632 and 634, which can be part of the system memory (e.g., DRAM) locally attached to the respective processors. The first processor 670 and the second processor 680 can be coupled to the chipset 690 via P-P interconnections 662 and 664 respectively. As Figure 6 shown, the chipset 690 includes P-P interfaces 694 and 698.

[0053] In addition, the chipset 690 includes an interface 692 that couples the chipset 690 to the high-performance graphics engine 638 via a P-P interconnect 639. In turn, the chipset 690 can be coupled to the first bus 616 via an interface 696. As Figure 6As shown, various input / output (I / O) devices 614 can be coupled to a first bus 616, and a bus bridge 618 that couples the first bus 616 to a second bus 620. In one embodiment, various devices can be coupled to the second bus 620, including, for example, a keyboard / mouse 622, a communication device 626, and a data storage unit 628 (e.g., a disk drive or other mass storage device that can include code 630). Additionally, audio I / O 624 can be coupled to the second bus 620. Embodiments can be incorporated into other types of systems, including mobile devices such as smart cellular phones, tablet computers, netbooks, Ultrabooks TM and the like.

[0054] Now referring to Figure 7 , a block diagram of a system according to another embodiment of the present invention is shown. In an Figure 7 embodiment, system 700 is an autonomous driving computing system. Thus, system 700 can be implemented within a vehicle that provides some level of autonomous driving. It should be understood that different levels of workloads can be executed within system 700 to autonomously perform some driving tasks or all driving tasks, utilizing different levels of autonomous driving control.

[0055] In embodiments herein, system 700 can dynamically perform functional safety tests as described herein during functional operation. Such tests can be performed on various components of the system in a fast and reliable manner that minimizes interruptions to normal computing workloads while ensuring a high level of functional safety.

[0056] As shown, system 700 includes a processor 710, which can be a general-purpose multi-core processor or other SoC. In different implementations, multiple such processors can be implemented to flexibly distribute the autonomous driving workload across these processors. Processor 710 receives power controlled by a power management integrated circuit (PMIC) 740. As further shown, functional safety tests as described herein can occur within both processor 710 and PMIC 740, with results being communicated between these components.

[0057] System 700 may also include one or more field programmable gate arrays (FPGAs) 715 or other programmable accelerators to which specific autonomous driving workloads can be offloaded. The processor 710 is also coupled to non-volatile memory 725, which in an embodiment may be implemented as flash memory. As described herein, the non-volatile memory 725 may store a functional safety test mode, which may be used to perform functional safety tests on the processor 710, the PMIC 740, and additional components within the system 700. To provide communication with other components within the vehicle, the processor 710 is further coupled to a switch fabric 720, which in an embodiment may be implemented as an Ethernet switch fabric, which in turn may be coupled to other components within the vehicle, including display components, vehicle infotainment systems, etc. Further still, the processor 710 (and the switch fabric 720) is also coupled to a microcontroller 750, which may also participate in functional safety tests.

[0058] In addition, to enable interaction with other systems (including other vehicles, road systems, over-the-air update sources, infotainment content sources, sensor data communication, etc.), the processor 710 and the MCU 750 may be coupled to one or more radio frequency integrated circuits (RFICs) 760. In an embodiment, the RFIC 760 may be configured to support 5G-based specifications for communication of automotive and other data via various wireless networks. To this end, the RFIC 760 may be coupled to one or more antennas 7700 - 770 of the vehicle n 。

[0059] As Figure 7 further shown, the system 700 may include multiple sensors 7300 - 730 n , which provide sensor information to the processor 710 via a sensor hub 735. While the scope of the present invention is not limited to this aspect in the embodiments, such sensors may include lidar, ultrasonic, radar, and optical sensors, as well as other sensor types. When the vehicle is in operation, such sensors may acquire a large amount of sensor data. The sensor hub 735 may be configured to fuse at least some of this data to provide information about the vehicle's surrounding environment for providing to the processor 710. In turn, the processor 710 and / or the FPGA 715 may use this fused sensor information in conjunction with performing autonomous driving workloads. It should be understood that while shown at this high level in the Figure 7 embodiments, many variations and alternatives are possible.

[0060] The following examples relate to further embodiments.

[0061] In one example, a device includes at least one structure and a structure bridge controller coupled to the at least one structure. The at least one structure interfaces with a plurality of IP blocks of the device, and the at least one structure includes at least one status storage device. The structure bridge controller can be configured to initiate a functional safety test of the at least one structure in response to a structure test signal received during the functional operation of the device, receive the results of the functional safety test via the at least one status storage device, and send a test report based on the results to a destination location.

[0062] In the example, the device further includes a first sideband router coupled to the at least one structure and the structure bridge controller. The first sideband router is configured to receive the results of the functional safety test and send the results of the functional safety test to the structure bridge controller.

[0063] In the example, the structure bridge controller includes a pseudorandom number generator configured to generate one or more test patterns based on a seed value. The structure bridge controller is configured to send the one or more test patterns to the at least one structure.

[0064] In the example, the structure bridge controller is configured to send a first transaction to the at least one structure. The first transaction includes one or more test patterns.

[0065] In the example, the structure bridge controller includes a second sideband router configured to send a second transaction to the first sideband router. The first sideband router is coupled to the at least one structure to receive the results of the functional safety test.

[0066] In the example, the structure bridge controller further includes a test analyzer configured to receive the results of the functional safety test and determine whether an error has occurred.

[0067] In the example, in response to a correctable error, the structure bridge controller is configured to issue a correction request to an error correction circuit so that the error correction circuit can correct the correctable error.

[0068] In the example, the structure bridge controller is configured to receive a test pattern from a non-volatile storage device via a security circuit and, in response to confirmation of security information associated with the test pattern, send the test pattern to the at least one structure.

[0069] In the example, the structure bridge controller is configured to aggregate the results of functional safety tests performed on multiple structures and transfer the aggregated results to a security circuit coupled to the device so that the security circuit can store the aggregated results in a non-volatile storage device.

[0070] In another example, a method includes: in response to receiving a test signal in a bridge controller of a system including a SoC during functional operation of the system, sending test content to one or more fabric structures of the SoC coupled to the bridge controller so that the one or more fabric structures can test the functionality of the one or more fabric structures; requesting test result information of a functional test from the one or more fabric structures via a sideband network coupled between the bridge controller and the one or more fabric structures; processing the test result information in the bridge controller; and transmitting the processed test result information to a non-volatile memory coupled to the SoC for storage and access by the system.

[0071] In an example, the method further includes: receiving the test signal when an autonomous vehicle computing system including the system is in an idle state.

[0072] In an example, the method further includes: generating test content in the bridge controller at least partially based on a seed value.

[0073] In an example, the method further includes: receiving test content from the non-volatile memory and validating the test content before sending the test content to the one or more fabric structures.

[0074] In an example, the method further includes: in response to identifying an error, sending an error message from the bridge controller to a system controller.

[0075] In an example, the method further includes: sending the test content to the one or more fabric structures as a reporting transaction.

[0076] In an example, the method further includes: requesting the test result information via a non-reporting transaction via the sideband network.

[0077] In an example, the method further includes: sending the test content from the bridge controller to the one or more fabric structures using a security identifier of a security circuit coupled to the SoC.

[0078] In another example, a computer-readable medium including instructions is used to perform the method of any of the above examples.

[0079] In another example, a computer-readable medium including data is used by at least one machine to fabricate at least one integrated circuit to perform the method of any of the above examples.

[0080] In another example, a device includes units for performing the method of any of the above examples.

[0081] In yet another example, a system includes a System-on-Chip (SoC) that includes: at least one core for executing instructions; an interconnect coupled to the at least one core; a first fabric coupled to the interconnect to couple a first agent and a second agent, the first fabric including a first storage device for storing test result information related to a functional test of the first fabric and a sideband interface for coupling the first fabric to a sideband network including a plurality of sideband routers; and a fabric bridge controller coupled to the first fabric. The fabric bridge controller can initiate a functional test of the first fabric in response to a test signal during normal operation of the system, receive, via the sideband network, results of the functional test of the first fabric including the test result information, and send a test report at least partially based on the results to a security circuit. The system further includes a security circuit coupled to the SoC, where the security circuit is configured to send a fabric test signal to the fabric bridge controller and provide at least the test report to a non-volatile memory. The system further includes a non-volatile memory coupled to the security circuit, where the non-volatile memory is configured to store the test report and one or more test programs to be provided by the security circuit to the fabric bridge controller.

[0082] In an example, the fabric bridge controller is configured to send a sideband request via the sideband network to request results of a functional test of the first fabric from the first fabric after the functional test is initiated.

[0083] In an example, in response to an error indication in the results, the fabric bridge controller is configured to include the error indication in the test report, and in response to the error indication included in the test report, the security circuit is configured to send a message to a system controller to cause the system controller to perform an action on the system, the system including an autonomous vehicle system.

[0084] In a further example, a device includes: a unit configured to send test content to one or more fabric units of a system-on-chip to enable the one or more fabric units to test functions of the one or more fabric units; a sideband unit configured to request test result information of a functional test from the one or more fabric units; a unit configured to process the test result information; and a unit configured to transfer the processed test result information to a non-volatile storage device unit for storage and access by an autonomous vehicle computing system.

[0085] In an example, the device further includes a unit configured to receive a test signal when the autonomous vehicle computing system is in an idle state, and the unit configured to send the test content is configured to send the test content in response to the test signal.

[0086] In an example, the device further includes a unit configured to generate the test content at least partially based on a seed value.

[0087] In an example, the apparatus further includes a unit configured to send the test content as a reporting transaction to one or more structural units.

[0088] In an example, the sideband unit is configured to request test result information via a non-reporting transaction.

[0089] It should be understood that various combinations of the above examples are possible.

[0090] Note that the terms "circuit" and "circuitry" may be used interchangeably herein. As used herein, these terms and the term "logic" are used to refer, alone or in any combination, to analog circuits, digital circuits, hardwired circuits, programmable circuits, processor circuits, microcontroller circuits, hardware logic circuits, state machine circuits, and / or any other type of physical hardware component. Embodiments may be used in many different types of systems. For example, in one embodiment, a communication device may be arranged to perform the various methods and techniques described herein. Of course, the scope of the present invention is not limited to communication devices, and conversely, other embodiments may be directed to other types of devices that process instructions, or include one or more machine-readable media that include instructions that, when executed on a computing device, cause the device to perform one or more of the methods and techniques described herein.

[0091] Embodiments may be implemented in code and may be stored on a non-transitory storage medium having instructions stored thereon that may be used to program a system to execute the instructions. Embodiments may also be implemented in data and may be stored on a non-transitory storage medium that, if used by at least one machine, causes the at least one machine to fabricate at least one integrated circuit to perform one or more operations. Further embodiments may be implemented in a computer-readable storage medium that includes information that configures a SoC or other processor to perform one or more operations when fabricated into the SoC or other processor. The storage medium may include, but is not limited to: any type of disk, including floppy disks, optical disks, solid state drives (SSD), compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks; semiconductor devices such as read-only memory (ROM), random access memory (RAM) (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM); magnetic or optical cards, or any other type of medium suitable for storing electronic instructions.

[0092] Although the invention has been described with respect to a limited number of embodiments, those skilled in the art will recognize many modifications and variations therefrom. The appended claims are intended to cover all such modifications and variations that fall within the true spirit and scope of the invention.

Claims

1. An apparatus for performing functional safety testing, comprising: at least one structure coupled to a plurality of intellectual property (IP) blocks of the apparatus, the at least one structure including at least one state storage device; and a structure bridge controller coupled to the at least one structure, the structure bridge controller for initiating a functional safety test of the at least one structure in response to a structure test signal received during a functional operation of the apparatus, receiving a result of the functional safety test via the at least one state storage device, and sending a test report based on the result to a safety circuit, wherein the safety circuit is for sending the structure test signal to the structure bridge controller and providing at least the test report to a non-volatile memory.

2. The apparatus according to claim 1, further comprising a first sideband router coupled to the at least one fabric and the fabric bridge controller, wherein, The first sideband router is for receiving the result of the functional safety test and sending the result of the functional safety test to the structure bridge controller.

3. The device according to claim 1, wherein The structure bridge controller includes a pseudo-random number generator for generating one or more test patterns based on a seed value, wherein the structure bridge controller is for sending the one or more test patterns to the at least one structure.

4. The device according to claim 3, wherein, The structure bridge controller is for sending a first transaction to the at least one structure, the first transaction including the one or more test patterns.

5. The device according to claim 4, wherein, The structure bridge controller includes a second sideband router for sending a second transaction to a first sideband router, the first sideband router being coupled to the at least one structure to receive the result of the functional safety test.

6. The device according to claim 1, wherein, The structure bridge controller further includes a test analyzer for receiving the result of the functional safety test and determining whether an error has occurred.

7. The apparatus according to claim 6, wherein, In response to a correctable error, the structure bridge controller is for sending a correction request to an error correction circuit so that the error correction circuit can correct the correctable error.

8. The device according to claim 1, wherein The structure bridge controller is for receiving a test pattern from a non-volatile storage device via the safety circuit and, in response to confirmation of safety information associated with the test pattern, sending the test pattern to the at least one structure.

9. The device according to claim 1, wherein, The structure bridge controller is for aggregating the results of the functional safety tests performed on a plurality of structures and transmitting the aggregated results to a safety circuit coupled to the apparatus so that the safety circuit can store the aggregated results in the non-volatile memory.

10. A method for testing the functionality of one or more structures, comprising: in response to a test signal received in a bridge controller of a system-on-chip (SoC) during a functional operation of a system including the SoC, sending test content to one or more structures of the SoC coupled to the bridge controller so that the one or more structures can test the functionality of the one or more structures; requesting test result information of a functional test from the one or more structures via a sideband network coupled between the bridge controller and the one or more structures; processing the test result information in the bridge controller; and Transmit the processed test result information to a security circuit coupled to the SoC, wherein the security circuit is configured to send the test signal to the bridge controller and provide at least a test report to a non-volatile memory for storage and access by the system.

11. The method according to claim 10, further comprising: Receive the test signal when an autonomous vehicle computing system including the system is in an idle state.

12. The method according to claim 10 further comprises: Generate the test content in the bridge controller based at least in part on a seed value.

13. The method according to claim 10, further comprising: Receive the test content from the non-volatile memory and validate the test content before sending the test content to the one or more fabrics.

14. The method according to claim 10, further comprising: Send an error message from the bridge controller to a system controller in response to identifying an error.

15. The method according to claim 10, further comprising: Send the test content as a reporting transaction to the one or more fabrics.

16. The method according to claim 15 further comprises: Request the test result information via the sideband network via a non-reporting transaction.

17. The method according to claim 10, further comprising: Send the test content from the bridge controller to the one or more fabrics using a security identifier coupled to the security circuit of the SoC.

18. A computer-readable storage medium comprising computer-readable instructions that, when executed, are configured to implement the method of any one of claims 10 to 17.

19. A system for performing a functional test, comprising: A system-on-chip (SoC) including: At least one core for executing instructions; An interconnect coupled to the at least one core; A first fabric coupled to the interconnect to couple a first agent and a second agent, the first fabric including a first storage device and a sideband interface, the first storage device for storing test result information related to a functional test of the first fabric, the sideband interface for coupling the first fabric to a sideband network including a plurality of sideband routers; and A fabric bridge controller coupled to the first fabric, the fabric bridge controller for initiating the functional test of the first fabric in response to a test signal during normal operation of the system, receiving, via the sideband network, the result of the functional test of the first fabric including the test result information, and sending a test report based at least in part on the result to a security circuit; The security circuit coupled to the SoC, wherein the security circuit is configured to send a fabric test signal to the fabric bridge controller and provide at least the test report to a non-volatile memory; and The non-volatile memory coupled to the security circuit, wherein the non-volatile memory is configured to store the test report and one or more test programs to be provided by the security circuit to the fabric bridge controller.

20. The system according to claim 19, wherein, The fabric bridge controller is configured to send a sideband request via the sideband network to request the result of the functional test of the first fabric from the first fabric after the functional test is initiated.

21. The system according to claim 19, wherein In response to an error indication in the result, the structural bridge controller is configured to include the error indication in the test report, and in response to the error indication included in the test report, the safety circuit is configured to send a message to the system controller to cause the system controller to perform an action on the system, where the system includes an autonomous vehicle system.

22. An apparatus for testing the functionality of one or more structures, comprising: a first unit configured to send test content to one or more structural units of a system-on-chip to enable the one or more structural units to test the functionality of the one or more structural units; a sideband unit configured to request test result information of a functional test from the one or more structural units; a second unit configured to process the test result information; and a third unit configured to transmit the processed test result information to a safety circuit, where the safety circuit is configured to send a test signal to the first unit and provide at least a test report to a non-volatile memory for storage and access by an autonomous vehicle computing system.

23. The apparatus according to claim 22, further comprising a unit configured to receive a test signal when the autonomous vehicle computing system is in an idle state, and the unit configured to send the test content is configured to send the test content in response to the test signal.

24. The apparatus according to claim 22, further comprising a unit configured to generate the test content based at least in part on a seed value.

25. The apparatus according to claim 22, further comprising a unit for sending the test content as a reporting transaction to the one or more structural units, and wherein, The sideband unit is configured to request the test result information via a non-report transaction.

Images