JP6326705B2 - Test, verification and debug architecture program and method - Google Patents

Description

  The present invention relates to computer systems, and in particular to providing a test and debug infrastructure for computer systems.

  With the development of semiconductor process and logic design techniques, it has become possible to incorporate a greater number of logic into integrated circuit (IC) devices. As a result, computer systems have evolved from configurations that include one integrated circuit within the system to configurations that include multiple integrated circuits, where multiple cores, multiple hardware threads, and multiple logical processors are integrated into individual integrated circuits. Other interfaces exist in the circuit and are integrated within such a processor. A typical processor or integrated circuit includes one physical processor die, which may include any number of cores, hardware threads, logical processors, interfaces, memories, control hubs, and the like. As both processors and computer systems become more complex, testing and debugging of these systems has become more complex.

  As high-speed, large-capacity logic and miniaturization trends or processor miniaturization progress, it is becoming difficult to debug, verify, and release products in a manner that does not cost as scheduled. Currently, the world of testing and debugging is divided into two parts: the manufacturing side and the consumer / vendor side, where the manufacturing side focuses on the silicon devices that it supplies and the vendor side focuses on other parts that are integrated with the silicon devices. I am focusing. In order to protect silicon devices from malicious damage and accidental damage, manufacturers do not expose hardware debug hooks to vendors at any level, but this provides such access This is because there is no safe way to do this. As the complexity of testing computer systems increases, manufacturers are spending a lot of money and effort on verification, even if the problems found are not directly related to the manufacturing device. In addition, unique tests and debugs may be performed on different devices in the system (processor, control hub, graphics device, motherboard, etc.). In this way, different tests / debugs are performed for each device, resulting in confusion and delay in product verification. In addition, the test method using the conventional probe is based on the physical characteristics of the new integrated circuit. It becomes difficult due to size restrictions.

  In addition, verification tools such as external logic analyzers and oscilloscopes, regardless of manufacturing or vendor side, are very expensive, and even trained employees can connect and verify the tools. It takes time to use it correctly. Furthermore, external tools for performing these verifications can only grasp the protocols exchanged in the interconnection, and it has been difficult to fully elucidate the interconnection and state of the devices.

  Current computer systems do not provide a way to validate different system events under certain conditions without spending a great deal of money and time. Specific examples include device internal tracking, trajectory or state tracking, signal tracking early in the boot process, determination of specific events such as hang events integrated as in-band messages, new fast internal Examples include memory and input / output (I / O) traffic and / or protocol tracking. Basically, there is currently no integrated and effective way to perform verification across various directions (processor test verification, platform debugging, electrical boundaries, motherboard diagnostics, etc.).

  The present invention is illustrated by the following examples and is not intended to be limited by the accompanying drawings.

FIG. 6 illustrates one embodiment of a logical representation of a multi-processing element processor. FIG. 6 illustrates another embodiment of a logical representation of a multi-processing element processor. FIG. 2 illustrates one embodiment of a logical representation of a test architecture having a hierarchical structure. FIG. 6 illustrates one embodiment of a computer system that includes a plurality of processors having an example embodiment of a DFx function. FIG. 2 illustrates one embodiment of a block diagram of a bi-directional connection architecture utilizing a layered interconnect stack structure. It is the figure which showed one Embodiment of the block diagram of the structure which collects the initial stage electric power in signal information. FIG. 6 illustrates one embodiment of a high level block diagram of acquisition logic that acquires an initial signal during boot of an electronic system. It is the figure which showed one Embodiment of the flowchart which showed the acquisition method of the signal information in the initial stage of an electric power sequence. FIG. 6 illustrates one embodiment of logic for signal acquisition of a target in a low power state. FIG. 3 illustrates an embodiment of an example platform having one or more VCUs. FIG. 5 is a diagram illustrating an embodiment of a flowchart illustrating a method for responding to a DFx request from software using a VCU. FIG. 6 illustrates one embodiment of updating a test architecture to reflect changes. It is the figure which showed one Embodiment of the layered laminated structure of a test architecture. FIG. 6 illustrates one embodiment of a flowchart illustrating a method for accessing a DFx function through a layered architecture stack. FIG. 3 illustrates one embodiment of logic that provides secure access to a test architecture. FIG. 6 illustrates one embodiment of a flowchart for providing secure access in a test architecture. FIG. 2 illustrates one embodiment of a universal test access port (UTAP) for a test architecture on a platform. FIG. 5 illustrates an embodiment of an integrated circuit package in an example of a mass production connection mechanism. It is the figure which showed one Embodiment of the heat spreader which has an inconspicuous mounting function which supports an upper surface test pin and probing. FIG. 6 illustrates one embodiment of an exploded view of a small factor thermal tool (SFFTT) design designed to provide thermal margin. It is the figure which showed one Embodiment of the remote access to the unit under test. It is the figure which showed another embodiment of the remote access to the unit under test. FIG. 6 illustrates one embodiment of logic that provides race information when viewed internally via a sideband bus. FIG. 6 illustrates one embodiment of a flowchart illustrating a method for managing internal observation trace (IOT) data. FIG. 6 illustrates one embodiment of a flowchart for reconstructing a trace from IOT data. FIG. 6 illustrates an embodiment of a flowchart of a method for detecting post-processing differences. FIG. 6 illustrates one embodiment of a flowchart that enables an RTL data structure to be accessible to a high level language. FIG. 6 illustrates one embodiment of a infrastructure that enables grid and spatial characteristics and debugging for on-die events, including the ability to correlate test and system events with grid performance.

  Specific processor configurations, controls, specific types of verification / test / debug hooks, component locations, security protocols, extraction methods, information formatting and placement, physical access port settings and locations, power settings, etc. Although specific types are described, these are provided to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without these specific details. Also, specific logic circuits / code to describe specific or alternative processor architectures, functions and algorithms, specific verification control implementation details, other known design verification hooks, known security and access methods, and others Well-known elements or methods, such as specific details of operation, are omitted in order to avoid obscuring the present invention.

  The methods and apparatus described herein provide a computer system test infrastructure. More particularly, the discussion will focus on verification within a typical computer system that includes a processor, such as processor 100. However, the apparatus and methods described herein are not so limited, and the apparatus and methods are implemented in connection with alternative computer architectures and electronic devices that are tested, debugged, verified, etc. . For example, the test infrastructure described herein may be implemented in a communication device or other integrated circuit environment. Alternatively, the test board may be used embedded in small devices such as PDAs and mobile phones.

[Processor architecture embodiment]
FIG. 1 illustrates one embodiment of a processor including multiple cores. The processor 100 includes any processor, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, or other device that executes code. In one embodiment, the processor 100 includes at least two cores, a core 101 and a core 102, which include an asymmetric core or a symmetric core (example shown). However, the processor 100 may include any number of processing elements that are symmetric or asymmetric.

  In one embodiment, a processing element is a thread unit, a thread slot, a processing unit, a context, a logical processor, a hardware thread, a core, and / or other state capable of holding a processor state such as an execution state or an architectural state. Refers to an element. That is, in one embodiment, a processing element refers to any hardware that can be independently associated with code, such as a software thread, an OS, an application, or other code. A physical processor typically refers to an integrated circuit (IC) that includes one or more other processing elements such as cores or hardware threads.

  A core often refers to logic located in an IC that is capable of holding independent architectural states, each of which is independently maintained in an architectural state, associated with at least some dedicated execution resources. For the core, a hardware thread typically refers to logic located in an IC that can hold independent architectural states in which multiple independently maintained architectural states share access to execution resources. . In this way, when certain resources are shared and other resources are occupied by one architectural state, the naming boundaries of hardware threads and cores overlap. However, the core and hardware are separate logical processors from the viewpoint of the OS, and the OS can schedule the operation independently for each logical processor.

  As shown in FIG. 1, the processor 100 includes two cores 101 and 102. Here, the cores 101 and 102 are symmetrical cores, that is, cores having the same configuration, functional unit, and / or logic. In another embodiment, core 101 includes an out-of-order processor core and core 102 includes an in-order processor core. However, cores 101 and 102 may be native cores, software management cores, cores that execute native instruction set architecture (ISA), cores that execute translated instruction set architecture (ISA), co-designed cores, or others May be selected separately from all types of cores, such as The functional units illustrated in the core 101 will be described in detail below, but the functional units in the core 102 operate in a similar manner.

  As shown, the core 101 includes two hardware threads 101a and 101b, which are also referred to as hardware thread slots 101a and 101b. Thus, a software entity, such as an OS, in one embodiment, can also view processor 100 as four separate processors, i.e., see four software threads as four processors or processing elements that can execute in parallel. be able to. The first thread is associated with a plurality of architectural state registers 101a, the second thread is associated with a plurality of architectural state registers 101b, and the third thread is associated with a plurality of architectural state registers 102a. And the fourth thread is associated with a plurality of architecture state registers 102b. As shown in the figure, a plurality of architecture state registers 101a are duplicated in a plurality of architecture states 101b, and individual architecture states / contexts can be stored in the logical processors 101a and 101b. In core 101, other small resources such as instruction pointers and rename logic in rename assignment logic 130 may also be replicated for threads 101a and 101b. Resources and queues such as reorder buffer, ILTB 120, read / store buffer in reorder / retirement unit 135 may be shared through partitioning. The portions of the general purpose internal registers, page-table base registers, low-level data carrier and data-TLB 115, execution unit 140, and out-of-order unit 135 may be fully shared.

  The processor 100 often includes other resources that are fully shared, shared through partitioning, or dedicated to processing elements. FIG. 1 illustrates one embodiment of a processor having logical units / resources of the processor for purposes of illustration only. The processor may include or omit any of these functional units, and may include other well-known functional units, logic or firmware not shown. As shown, the core 101 includes an out-of-order (OOO) processor core that is shown in a simplified manner. The OOO core includes a branch target buffer (BTB) that predicts a branch destination to be executed / selected and an instruction translation buffer 120 (I-TLB) that stores an address translation entry for the instruction.

  The core 101 further includes a decode module 125 coupled to the fetch unit 120 to decode the fetched elements. In one embodiment, the fetch logic includes sequencers associated with slots 101a and 101b, respectively. Typically, core 101 is associated with a first instruction set architecture (ISA) that defines / specifies instructions executable on processor 100. Machine code instructions recognized by the ISA generally include a portion of an instruction called an opcode that references / specifies the instruction or operation to be executed. Decode logic 125 recognizes the instruction from the opcode and passes the decoded instruction to the pipeline for processing as defined by the first ISA. For example, as described in detail below, in one embodiment, the decoder 125 includes logic used or designed to recognize new specific instructions such as conditional commit instructions and predictive checkpoint instructions. . As a result, upon recognition of the decoder 125, the architecture or core 101 takes certain predetermined actions and performs the tasks associated with the appropriate instructions.

  In one example, the allocator and renamer block 130 includes an allocator (allocation routine) that saves resources, such as a register file that stores instruction processing results. However, threads 101a and 101b can execute out of order, and allocator and renamer block 130 also includes other resources, such as a reorder buffer, to track the result of the instruction. . Unit 130 may include a register renamer that renames program / instruction reference registers to other internal registers of processor 100. The reorder / retirement unit 135 includes a reorder buffer, a load buffer, as described above, to support out-of-order execution and retirement of instructions that are executed in the out-of-order order. And elements such as a store buffer.

  In some embodiments, the scheduler and execution unit block 140 may include a scheduler unit that schedules instructions / operations for execution units. For example, floating point instructions are scheduled to be part of an execution unit that has an available floating point execution unit. In addition, a register file associated with the execution unit is included to store the information instruction processing result. Examples of execution units include floating point execution units, integer execution units, jump execution units, load execution units, storage execution units, and other known execution units.

  The lower layer data cache and data conversion buffer (D-TLB) 150 is connected to the execution unit 140. The data cache stores recently used / processed items such as data operands held in memory coherency state in the element. The D-TLB stores recent virtual / linear address to physical address translations. As a specific example, the processor may have a page table structure for dividing physical memory into a plurality of virtual pages.

  Here, the core 101 and the core 102 share access to a cache 110 that is located in a higher layer that caches recently fetched elements or is located further away. Here, the upper layer or a position farther away means that the cache level is higher or further away from the execution unit. In one embodiment, the upper layer cache 110 is a last level data cache that is the last cache in the memory hierarchy of the processor 100, such as a second level (secondary) data cache or a third level (tertiary) data. It is a cache. The upper layer cache 110 is not limited to this, and may be associated with an instruction cache or may include an instruction cache. Alternatively, a trace cache, which is a type of instruction cache, may be concatenated after the decoder 125 to store recently decoded traces.

  In the illustrated configuration, the processor 100 includes a bus interface module 105 that communicates with devices external to the processor 100, such as a system memory 175, chipset, north bridge, or other integrated circuit. The memory 175 may be a memory dedicated to the processor 100 or a memory shared with other devices in the system. Typical examples of memory 175 include dynamic random access memory (DRAM), static RAM (SRAM), non-volatile memory (NV memory), and other well-known storage devices.

  FIG. 1 is shown in a simplified manner, showing a logical representation of an example of a processor including different modules, units and / or logic representations. However, a processor utilizing the methods and apparatus described herein need not necessarily include the units shown. The processor may omit some or all of the units shown. In addition, although only two cores are shown in FIG. 1, the processor may include any number of cores, multiple cores of the same type, or more than two different types. A core may be included.

  FIG. 1 illustrates an embodiment of a processor that is connected point-to-point using an interface with an external memory controller (control hub 170). However, many of today's processors include on-processor memory interface modules, and various interconnect architectures such as a ring structure that interconnects multiple cores and shared caches. And an on-chip module having other interfaces.

  One embodiment of such an interconnect architecture is shown in FIG. As shown, the processor 200 includes a distributed cache, a circular interconnect, a core, a cache, and memory control components. However, the illustrated arrangement is merely an example, and a processor implementing the described method and implemented in the apparatus may be any processing element, any kind or hierarchy of caches and / or memories, a front communicating with an external device. A side bus or other interface may be included.

  In one embodiment, the caching agents 221-224 each manage a distributed and associated cache. The caching agents 221-224 may manage logically shared cache slices, or may manage individual private caches in the same memory hierarchy. As an example, each of the cache components, such as component 221, manages a slice of cache for an aligned core, ie, a core with which a cache agent is associated for the purpose of managing distributed slices. As shown, cache agents 221-224 are referred to as cache slice interface logic (CSIL), but may be cache components, agents, or other logic, units, or slices of caches or caches. Sometimes referred to as a combined module. The cache may be any level of cache, but in this example embodiment, the description will focus on the last level cache (LLC) shared by the cores 201-204.

  The core agents / components 211-214 handle the traffic and interface to the cores 201-204, respectively, like the cache agent that handles the traffic of the circular interconnect 250 and the association with the cache slice. In addition, the illustrated annular structure 250 includes a memory peripheral hub (IMPH) 230 and a graphics hub (GFX) that couple with other modules such as a memory controller (IMC) 231 and a graphics processor (not shown). 240). However, the annular structure 250 may include or omit any of the modules described above, and may include other well-known processor modules not shown. In addition, similar modules may be connected via well-known interconnections such as point-to-point connections or multidrop connections.

[Test platform embodiment]
In one embodiment, a computer system that includes a processor or other well-known processing device as shown in FIGS. 1 and 2 efficiently tests various aspects of the computer system (both cost and complexity). Includes a test infrastructure to assist with verification and debugging. In order to provide this efficient environment, there are multiple layers (eg, physical, communication and software layers), such as the hierarchical structure shown in FIG.

  For example, the physical layer 305 includes test hooks (hardware or firmware provided in a system that provides testing, verification, and / or debugging functions), and the test hooks are a plurality of devices (processors, interconnects) of a computer system. , Control hubs, etc.). In one embodiment, the test hook is by design, at the direction of other hardware / firmware such as a microcontroller, or software such as a user / vendor debug program or code integrated within the computer platform. Collect debug / verification information according to the instructions. Specific examples of hooks include architectural and microarchitecture test / tracking measurement functions in devices, electrical verification tools, in-computer / on-device logic analyzers, connection protocol / trace measurement functions, platform level test functions, Power test functions (which are described in detail in the power verification embodiments section below), power on / boot tracking measurement functions, verification circuits, mass production test functions, and other well-known hardware Base measurement and test functions are included.

  In addition to providing designated test hooks, in one embodiment, communication layer 310 is employed to provide communication between test hooks and test / debug software. The communication layer 310 may simply provide the software with the ability to directly access the test hook (to define test scenarios or obtain test results). However, as noted above, device designers may want to obfuscate the silicon test functionality for access by vendors or users. In that case, the software of the vendor or user is configured to interact with the communication layer 310, and the communication layer 310 provides the software with an obfuscated (abstracted) overview of the hardware test function. The communication layer 310 communicates with the hardware in the physical layer 305 in a manner that is obfuscated when viewed from the customer. In one embodiment, a microcontroller, also referred to as a verification control unit (VCU), controls access to various test hooks. Here, the vendor software programs various breakpoints, micro-breakpoint trigger events, extracts stored traces, provides verification information, and provides various levels of verification. The VCU can be requested to coordinate tasks.

  As shown in the last example, the degree of obfuscation and the level of security with respect to the test infrastructure may vary. Here, the silicon designer may have free access to all of the included test functions and may wish to lower the access level for various vendors, customers and users. Considering such cases, the first stage includes providing an abstraction layer 305 that can blur the hooks in the physical layer 305. And in one embodiment, the second stage includes providing a secure access method that can draw boundaries between different levels of access.

  The communication layer 310 also provides a report of verification information to the software layer 315. For example, the on-die logic analyzer collects trace information from the processor. The communication layer 310 provides trace information in a defined format such that the software layer 315 can access, recognize and manipulate data in a storage structure such as a cache or system memory. A software layer 315, also referred to as an access layer, provides a program / tool that accesses the communication layer 310 and processes the contents of the test data. Returning to the above example, once the trace information is placed in the storage structure, the verification and debug program may perform processing to interpret the trace information (verification and debug).

  In the above description, the logical or abstract access to data from the physical layer 305 has been mainly described. How to access the physical layer 305 will be described below. In one example, such access is performed using physical access. Here, two-way communication (upward communication of extracted debug information, such as a request to the VCU for obfuscated access to the physical hook, and downward communication of the debug request) A dedicated or universal debug / verification port is provided to support. This port can be located or replicated anywhere in the computer system (processor package, chipset, motherboard, or via an existing I / O interface such as a universal serial bus interface) Good.

  In another embodiment, the test infrastructure also provides remote access. For example, suppose a vendor is trying to verify one processor in a computer system, but has a problem due to the complexity of the current computer platform. It is assumed that the vendor is only provided with access to a high-level obfuscated (abstracted) processor debug tool. Instead of the processor manufacturer physically dispatching a verification engineer to assist in the debugging process, the test infrastructure may allow remote access for verification and debugging. In addition, remote manufacturers may attempt to solve problems and debug by making most of the hardware infrastructure accessible via security protocols while keeping the silicon test functionality secret from the vendor. . In addition to the configuration for remote debugging, the layers of FIG. 3 can be updated locally or remotely, providing flexibility in future validation by providing patches that update the code in the firmware or VCU. And can respond appropriately.

  FIG. 3 shows a general hierarchical structure that divides the test architecture into three main categories (physical, communications and software). However, the test architecture hierarchy (stack) may be configured in any manner and may include other layers that provide similar test interfaces. For example, in one embodiment, the hierarchy of the verification architecture includes a target layer (physical unit under Dfx test), a transport layer (a high-level transport mechanism executed on the target DFx unit to perform the test). A layer that employs a non-intrusive stack), an abstraction layer (a layer that provides abstracted communication between an application and a lower layer DFx interface), an application layer (an abstraction layer for combining with DFx services) And layers that include applications, services, tools and other software that communicate with) and presentation layers (layers that associate, visualize, and / or display basic data, protocols and information).

[Embodiment of verification, test and debug hooks]
In one embodiment, the verification, testing and debugging hooks are integrated into the processor and / or computer system / platform silicon to support efficient testing, verification and / or debugging. Verification hooks integrated into the final product are often referred to as designs for debugging, verification and / or testing (hereinafter referred to as DFx). DFx includes all known hooks included in the product (self-verification tools) to support product testing, debugging and / or verification. In the following description, many examples of such hooks are described, but this list of examples is not complete. Further, any or all of the DFx functions described below may be combined with a well-known integrated test / debug function or may be omitted. In addition, with regard to the processor, the description of DFx is mainly made, but similar hooks include other silicon devices such as motherboards, control hubs, embedded processors, graphics processors, input / output devices (I / O devices), etc. It may be.

  FIG. 4 shows an embodiment of a computer system including a plurality of processors for explaining an example of the DFx function. The configuration shown is for illustrative purposes only. Any known computer system configuration may be used, for example, a conventional legacy configuration as shown in FIG. Further, for simplicity of illustration, each of the four processors (410a, b, c, and d) is depicted as having the same components, but may have different asymmetric configurations. Hereinafter, in order to simplify the description, the features of the processor 410a will be mainly described.

  In one embodiment, the computer system 400 comprises one or more verification control units (VCUs) that provide and control access to the silicon DFx. As shown, each of the components (processors 410a-b and peripheral control hub 470) includes its own VCU, but any number or layout of VCUs may be provided to control access to the processor or computer system. May be. The embodiment of the VCU and the functions related thereto will be described in more detail in the section “Embodiment of Verification Control Unit” below. Thus, for purposes of describing an embodiment of the DFx function, in this scenario, the VCU 412a provides access to the DFx function of the processor 410a.

  As a first example of DFx functionality, processor 410a includes an integrated (also referred to as on-die or on-chip) logic analyzer (ODLA or OCLA) 413a. Previous logic analyzers included individual physical devices connected to components through multiple probes or external ports to capture or display the digital signal of the device. However, external devices are very expensive. As the complexity of computers increases, the time difference / delay between the development of a product and the development of a logic analyzer that can be combined with that product has become very large. As a result, in this industrial field, product debugging, verification and sales cannot be performed according to a schedule so as not to incur costs.

  Accordingly, in one embodiment, processor 410a comprises ODLA 413a (configured by hardware, firmware, microcode, or a combination thereof) to support the logic analyzer on-die function. That is, the processor 410a includes an ODLA 413a for acquiring digital signals, states, traces, and the like. As a specific example, processor 410a includes logic to set a breakpoint (or microbreakpoint) that triggers an acquisition point. Here, one event or a combination of a plurality of events that define a scenario to be started is set in an event storage unit such as a control register. As the scenario is encountered (each event occurs in a manner specified in the scenario), the relevant state, signal, trace, etc. in the processor are collected. The trigger condition or scenario may simply be the assertion or deassertion of the test signal, such as when an instruction retirement push occurs a number of times that exceeds a threshold associated only with an instruction that has experienced a level 2 cache miss. Thus, it may be a complex combination of microarchitecture events.

  As shown in FIG. 4, the ODLA 413a may not be physically grouped in a logical block. Alternatively, ODLA 413a may include logic distributed throughout processor 410a that obtains internal or external signals within processor 410a. In one scenario, the ODLA 413a obtains a logic level associated with the architecture or microarchitecture portion of the processor 410a, obtains a logic level of a trace or circuit, obtains logic associated with an internal interconnect that obtains internal traffic, and obtains memory traffic. Logic associated with a memory interface, such as interface 460a, and interfaces 450, 465, an input / output interface, such as a graphics interface (not shown), a legacy or sideband interface (not shown), or a processor Includes logic associated with other well-known interfaces associated with it.

  In previous external logic analyzers, the results were acquired by an external device. On the other hand, in the above scenario, the processor 410a operates its own logic analyzer. Accordingly, in one embodiment, the ODLA 413a retains the acquired information and uses an available computer storage. For example, the ODLA 413a uses a part of the cache memory or the memory 420a as a trace buffer that holds the acquired information. In one embodiment, a portion of memory 420a is isolated from software usage. The acquired information is placed in an isolated part of the memory.

  Here, the acquired information may be arranged in a pre-determined prescribed format, in an unprocessed state, and verified with an appropriate access level (provided by the manufacturer or customer at the application layer) Software can access and manipulate data, for example, convert raw data into timing charts, protocol decodes, trace representations, or perform other well-known manipulations of logic analyzer data To be able to. In another embodiment, ODLA 413a converts raw data (using the programmable logic, code or microcode contained therein) to another format for interpretation by higher level software. Then, the converted data is arranged in the memory.

  In an example embodiment, the software requests a specific breakpoint scenario from the processor 410a via an application program interface (API) provided by the communication layer, such as an abstraction layer provided by the VCU 412a. . If VCU 412a receives the request and the request has mandatory security level access, VCU 412a sets the startup scenario in the control register of processor 410a. A breakpoint is then triggered when a breakpoint scenario defined in the control register is encountered during normal execution or during a test mode of execution. The acquired information is stored in the memory 420a in an area that cannot be read from the operating system (OS). Software can access and manipulate and interpret information via the interface API, thus eliminating the need to use an external logic analyzer or oscilloscope, and at the same time internal and external communication of the silicon device It will be possible to investigate more in detail and thoroughly.

  In addition to setting the startup scenario, other well-known verification techniques may be integrated and / or combined with ODLA 413a. For example, a test case can be set and similar trace information can be acquired by a combination of ODLA 413a and other logic. In reality, it is common for a designer to design for a worst-case scenario that is not easily reproduced during normal execution. As a result, it is useful for verification to activate the processor 410a with factors that cause a particular worst case scenario to identify both the actual response and the correlation between the actual response and a previously performed simulation. it is conceivable that. Therefore, in order to generate a scenario in which the ODLA 413a collects data, a logic that sets a specific logic state or provides a specific input is employed.

  In the above description of DFx, attention was paid to the ODLA 410a to acquire the internal state of the processor 410a. However, as suggested above, in one embodiment, ODLA 413a and / or other logic is used to verify external interfaces and interconnections. Instead of placing picoprobes on electrical traces (wires) to observe communication between devices, as in the case of using an external logic analyzer, the ODLA 413a contained in the silicon is at the actual interface within the device. The same function can be performed.

  Similar interconnect hooks may be included in the on-processor interface. As an example, returning to FIG. 2, DFx hooks may be scattered around the periphery of the annular structure 250 so that the electrical attributes (timing margin, bit rate, error test, cross-coupling, ringing, Undershoot, overshoot, etc.), traffic in ring structure 250, communication protocol of ring structure 250 (ie, cache coherency protocol), traffic / protocol in control interface 230/231, traffic in graphics interface 240, etc. Good.

  As a result, complex interface verification involves hooks integrated with silicon, and by using these hooks, such as physical, electrical properties, logic states / traces, and higher layer protocols Multiple layers of the interconnect architecture stack may be verified. FIG. 4 illustrates such interfaces (QPI interface 450 connecting processors 410a-d, memory interfaces 460a-d connecting processors 410a-d to memory devices 420a-d, and peripheral control hubs of legacy processors 410c, respectively). A configuration is shown in which a PCI-E or other interface connected to 470 includes a hook for verification. Similar DFx hooks may be utilized in other interfaces, such as graphics interfaces or sideband interconnects. However, it should be noted that the illustrated interface is processor-centric. In addition, other devices such as PCH470 include similar DFx hooks, peripheral interface (PCI-E), universal serial bus (USB), serial advanced technology attachment (SATA), direct media Other interfaces such as interfaces (DMI) and other well-known computer interconnect configurations may be verified.

  To provide a specific example, FIG. 5 shows a block diagram of an example embodiment of a bi-directional connection architecture that utilizes a hierarchical interconnect stack. Examples of connection structures shown include PCI Express (PCI-E) and Quick Path Interconnect (QPI). Although the illustrated hierarchical structure will be described primarily with reference to the QPI architecture, the structure also applies to PCI, PCI-E, graphics connections, memory connections, peripheral connections or other well-known connections May be. The layers shown in FIG. 5, for example physical layer 502, include general layer considerations that may be implemented on different agents, such as physical layer 502a and physical layer 502b. As shown in the figure, the interconnect stack is divided into five layers, one or more of which may be selective depending on the implementation of the design. For example, in one embodiment, the routing layer 504 may be embedded in the functionality of the link layer 503, and thus in one embodiment, the routing layer is not provided as a separate layer.

  In some embodiments, the physical layer 502 is responsible for the electrical transfer of information in a physical medium. For example, a physical point-to-point link may be utilized between link layer entities 503a and 503b. In the illustrated example, the physical link includes a differential signaling scheme having bidirectional differential signal pairs 551 and 552. Here, the physical layer can be logically divided into an electrical sub-block and a logical sub-block, and the physical layer is separated from the electrical transfer of information from the remaining layers of the stacked structure, and the link layer 503. Communicate with.

  In one embodiment, the link layer 503 abstracts (obfuscates) the physical layer 502 from the top layer of the stacked structure to provide reliable data transfer and flow control between connected agents / entities and physical Provides link related services such as virtualizing channels / interfaces into multiple virtual channels and message classes. Here, the virtual channel can be regarded as a plurality of virtual networks used by the upper layer of the stacked structure. For example, protocol layer 506 may rely on the abstraction provided by link layer 503 to map protocol messages to message classes and thus to one or more virtual channels.

  In one embodiment, routing layer 504 provides a flexible way to route packets from a source to a destination. As noted above, in a very simplified topology, the routing layer 504 may not be clear and may be integrated into the function of the link layer 503. For example, the routing layer 504 may rely on the abstraction of the link layer 503 to identify the <port, virtual network> pair to route the packet. Here, the routing table information is held so as to provide packet routing information.

  In one embodiment, the transport layer 505 provides an end-to-end reliable transmission service. Similar to the routing layer 504, the transport layer 505 is provided as needed based on the design implementation. As an example, transport layer 505 relies on routing layer 504 to provide reliable transmission support for protocol layer 506. In one embodiment, within the interconnect architecture, the subset of components includes a transport layer 505. As a result, this subset of components may define a subfield of a packet related to the transport layer 505, and other components may not define this subfield.

  In one embodiment, protocol layer 506 implements higher layer communication between nodes / agents, such as cache coherence, ordering, peer-to-peer communication, interrupt delivery, and the like. That is, protocol layer 506 defines allowed messages, requests, responses, phases, coherence states, etc. for nodes or agents such as home nodes, peer nodes, caching nodes and non-caching nodes. Examples of messages such as home node messages, snoop messages, response messages, etc. will be described below.

  The discussion of layers and associated logic may be combined in any manner. For example, protocol logic may be combined with the physical layer, i.e., transmit logic or receive logic. Here, as can be seen from FIG. 5, in one embodiment, the protocol logic is coupled through other layers of logic rather than directly coupled with physical layer logic. Further, in one embodiment, the interconnect stack is combined with internal component logic such as cache control logic or cache memory logic to initiate appropriate cache coherence actions.

  In one embodiment, the QPI-based interconnect includes a Modified Exclusive Shared Invalid Forward (MESIF) protocol, with no restrictions on signal and bus serialization and A similar protocol is provided. Like the snooping cache protocol, MESIF relies on nodes that have a cached copy of data to maintain coherence. Using point-to-point links rather than synchronized and centralized broadcasts causes time-warp problems, ie events occur in a different order when viewed from different nodes It looks like you are doing. As an example, the MESIF protocol addresses this problem by recognizing errors that may be caused by time warping and provides a protocol or software solution.

  A home node is often associated with an uncached copy of data. As a result, the home node may participate in a transaction related to data associated with the home node. However, the home node does not necessarily need to be included in the “critical path” associated with the transaction, and the home node may be inserted into the transaction to solve the conflict and time warp problems. In one embodiment, because of the parallel-broadcast nature of this scheme, MESIF can obtain a cacheable copy of the data while simultaneously reducing the latency associated with protocol snooping, in some cases , Request-response can be minimized with only one round trip.

  In one embodiment, the basic transaction for the MESIF protocol involves broadcasting the initial request to all peer nodes and home nodes. If the copy is cached in state E, F or M coherency state, the copy is included in the response. A second message is then sent to the home node to notify that the request has been satisfied. If the requested line is not cached, or if only a copy of the S state exists, the second request sent to the home node is used to confirm the previous request. The previous request held by the home node is considered to have been fetched from memory by that time. In any case, the home node responds to the second request for the purpose of resolving synchronization and conflicts (and the first request, the first request and the second request may be combined). Here, since the home node may have one or more caches, it may respond to the initial request in the same manner as the other nodes.

  In one embodiment, conflicts are addressed in a distributed manner. Because individual requests can be delayed for any length of time, time warp issues make it difficult to detect conflicts. However, a conflict can be detected if each node monitors the conflict after making a request. Although a plurality of nodes may detect a conflict, as an example, it is assumed that at least one of the plurality of nodes detects a conflict. In this case, in one embodiment, the response from the node may include conflict information.

  In one embodiment, a node that receives a copy of the data from the response can use the data internally as soon as it receives the data, but until that node receives a confirmation. Data usage cannot be visualized in the rest of the system, ie it cannot be made visible globally. The acknowledgment may include instructions that direct the requesting node to transfer the copy to another node and to evict that node from its cache. Then, when a node responds to a request from another node by supplying cached data, in one embodiment, the node responds with a confirmation that the node has transferred the data. Since other requests for the same cache line received are delayed until received from the home node, it can be assumed that all nodes observe the transfer of (writeable) cache lines in the same order.

  As described above, the home node may be a storage location for uncached data, and may include a processor and a cache. When the home node processor misses the cache, the home node broadcasts the request to all other (peer) nodes, and the home node handles the request internally when the other request arrives at the home node. This is a special case where the home node does not explicitly send a message to itself (home node). In addition, when an external request for locally cached data arrives, the home node responds appropriately.

  The disclosed message protocol defines a set of messages that are allowed between coherence (cache and home) agents, non-caching agents, and other agents (memory controllers, processors, etc.). Coherency protocols use messages as a language and grammar in algorithms that express a coherent idea. This algorithm sorts and orders requests, resolves conflicts, and describes the interaction between caching agents. Although the MESIF protocol has been described above, the use of a MESIF cache coherency protocol is not necessarily required. For example, the Forward state may not be used, and a well-known MESI protocol may be used. Furthermore, the above description is up to and including an example of an overview of one embodiment of the MESIF protocol. Accordingly, the various components described above may be different in other embodiments.

  As can be seen from above, verifying and debugging such a complex is a very cumbersome process (both in terms of electrical and protocol). Thus, in one embodiment, the processor 410a of FIG. 4 includes DFx to aid verification across the layered interconnect stack. For example, the ODLA 413a can obtain traffic, traces or states of the interconnect stack in response to a startup scenario or other event. In one embodiment, a state refers to a snapshot of the state of a device, agent, and / or other component of a verification object (subject). A state can also be referred to as an architectural or structural state of a verification object. In another example, a state is defined by a combination of parameter values in a state snapshot. Therefore, if 100 parameters are specified in the interconnect structure, all combinations of different values of these 100 parameters are considered to represent different states.

  As a very simplified example of one state of a cache coherency protocol, one processor has one cache line of shared coherency state, since one state refers to many parameters of a complex protocol. Consider the case where one processor has an invalid state cache line and a snoop is received on one of these processors. Here, there are a plurality of protocol agents, a plurality of cache lines held in a plurality of states, and a request / message received at a specific destination. Only in such a simplified example, there are a small number of parameters. As another example, a write transaction with a data payload can be in multiple states, the write destination, the state of the cache line associated with the data payload being written, the interconnect traffic, and the write response by other agents It is considered that other parameters such as.

  Thus, in one embodiment, a parameter refers to any element in a protocol, physical logic, device, agent, or global state / variable that changes to or is in various states. As a specific example, when enabling a cache coherent interconnect protocol, the parameters for a caching agent such as processor 410a include a cache response to snoop. Here, the first value of the cache response parameter includes transferring the snooped cache line to the requesting device, and the second value of the cache response parameter includes writing to the home node of the cache line. It is. Other common coherency protocol parameters include various types of agents, agent responses, device responses, interconnect responses, message responses, response types, other responses to specific actions, response destinations, messages, message types, Message destination, request, request type, request destination, cache type, cache state, cache location, register state, and the like are included.

  However, since an architecture such as a physical interconnect, communication protocol, or other protocol can be subject to verification, the parameters may include various types of variables. An exemplary and incomplete list of possible protocol-related parameters includes a large number of protocol agents, protocol agent types, cache implementation types for agents, number of different types of protocol agents, protocol agents Type, protocol agent state, protocol agent or bus circuit or state machine state, agent identifier, multiple protocol requests, request type, request source, request destination, request state, referenced operation, source of operation Address referenced, address accessed, address location state, data payload, protocol agent state, cache state, cache line state, voltage, Wave number, include physical protocol state parameter, such as power state, or other physical protocol attribute.

  For the physical layers 502a, 502b, some examples of interconnect physical parameters include voltage, undershoot, overshoot, frequency, period, spread spectrum, jitter, timing margin, noise, and the like. Other parameters include the state of the state machine related to the connection, the type of agent, the state of the agent, the state of the I / O circuit in the agent, and the like. However, any variable in the architecture may be considered a parameter.

  Thus, in one embodiment, ODLA 413a is employed to obtain a state or trace that may include all or a portion of the target interface. In addition to taking a specific snapshot once in response to a defined event such as a startup scenario, ODLA 413a employs to capture traffic (multiple states of communication at the interface) Is done. In this scenario, a protocol exchanged between devices is obtained. After processing the data, the high-level software can generate a protocol diagram that confirms whether the correct protocol exchange occurred at the interface. The continuation of the above example will be described. The DFx silicon may generate or mount a startup scenario associated with the processor 410a that receives a specific snoop message for a cache line in an exclusive coherency state. The ODLA 413a acquires information such as a response to the snoop message from the processor 410a in a certain part of the memory 420a. Via an API provided by VCU 412a, a third party vendor (TPV) with appropriate access can build and define a protocol based on information held in the second part of memory 420a. It is possible to confirm that an appropriate response has been given to a specific snoop message in an environment of a different state.

  As can be seen from this example, it is believed that similar methods and apparatus can be used to verify electrical characteristics and protocols such as the MESIF cache coherent protocol of QPI interconnect 450 introduced above. . Inferences may be made from the QPI interconnect 450 verification example above to show that on-silicon hooks can provide verification of any interface, such as a layered connection structure.

  In addition to the verification hooks for the internal and external interfaces of ODLA 413a and processor 410a, other silicon hooks may be incorporated into processor 410a. For example, in one embodiment, certain microarchitecture hooks are incorporated into the processor 410a. For example, co-pending application Ser. No. 11 / 143,425 “ENHANCEMENTS TO PERFORMANCE MONITORING ARCHITCUTRE for CRITICAL PATH-BASED ANALYSIS” An apparatus and method for monitoring the performance of the system is described. Performance is monitored through simulation, analytical thinking, retirement pushout measurements, overall execution time, and other methods of measuring event costs per instance. And a similar device is included in the silicon, tagging instructions / counting instructions based on microarchitecture events, measuring retirement pushout, measuring total execution time of instructions / programs, and other processor Verification / debugging of known functions is performed.

  As another example, the processor 410a includes a power control unit (PCU) 414a that regulates and controls power, such as the power state of processing elements within the processor 410a. In addition, DFx hooks may be incorporated into the processor along with the PCU 414a so that power consumption levels, duration of various power states, frequency of power state transitions, power state transition protocols, and other well-known power-related measurements. Various power verification metrics, such as criteria, may be obtained. Similar to the operation of ODLA 413a, power information may be collected during normal operation when a factor is supplied or in response to the occurrence of a startup scenario, or a specific worst-case power scenario (ie, , Worst power resonance frequency generated by the worst pattern transmitted to the interface). The power DFx and operation will be described in detail later with reference to FIG.

  It is not limited to the illustration of processor-centric DFx that may be included in any device in the electrical system as well, but is also considered to include DFx at other platform levels. The DFx (debug functionality) described above and below may be implemented separately without using other parts of the test architecture described herein. For example, the collection of signal information in the early stages of the boot process is described in detail below with reference to FIGS. 6-8, but without using a verification control unit or layered abstracted access. May be implemented.

  FIG. 6 shows an embodiment of a block diagram of a configuration for collecting initial power in signal information. In this embodiment, PCH 605 is coupled to processor 640 via direct media interface (DMI) 635. Normally, when the power is on, power is first applied to the PCH 605. Like many silicon devices, PCH 605 is powered on in multiple stages. For example, a specific plurality of wells are powered on in a specific order. For example, purely by way of example, the clock 610 is first powered on, and then the wells 615 and 620 such as the suspend well, active well, real time clock well are powered on. Finally, test logic 625, such as a manageability engine and a test access port (TAP) is enabled.

  Under certain circumstances, initial signals that transition before specific power-up or test logic 625 is enabled are not visible (there is no visibility on the issue of these signals), but this is associated with these signals. This is because the transition information provided is lost before the test logic 625 is enabled in the boot process. However, during verification and debugging, it would be useful if information about such signals could be seen or collected. Examples of such signals include power management control reset signals. In this example, this signal transition instructs the power management controller to start fetching and execution. Thus, it is possible to determine (1) the signal did not transition, (2) the signal transition, and / or (3) when the signal transitioned, and the power management controller hangs scenario (" Helps debug "set up scenarios".

  Thus, in one embodiment, power-up initial state signal acquisition logic (also referred to as initial boost test logic) acquires initial state signal information before the device is fully powered up. To do. Any known method or apparatus for obtaining signal information such as traces may be utilized. Here, the signal acquisition logic 630 includes logic for acquiring specific signal information after the first power-on and storing the signal information. Then, when test logic 625 is enabled, information is read and appropriate debug operations are performed.

  FIG. 7 illustrates one embodiment of a high level block diagram of acquisition logic that acquires an initial signal during booting of an electronic system. As shown, the acquisition logic 700 is a register that acquires / holds information about signals of interest (ie, signals monitored during boot, such as signals 1, 2, 3,... 11). A storage element 720 such as In one embodiment, when powered on, the acquisition logic 700 begins acquiring signal information as a default (without requiring a user trigger or third party access / programming). As another example, the acquisition of information begins when a specific condition occurs, such as a specific signal / clock transition or a specific well enabled. Similarly, when a predetermined time / cycle elapses, a target signal transition is not detected for a certain period of time, a target last signal transitions, a target last signal does not transition for a predetermined period, When a condition occurs, such as when a well is enabled, when test logic is enabled, when a program indicates that acquisition should stop, or when other well-known events occur, It may be stopped.

  Also, any known apparatus or method of signal information acquisition (transition time, number of transitions, transition direction, trace, etc.) may be utilized, and a specific example embodiment will be described with reference to FIG. In this scenario, register 720 records the time when the signal of interest (or each of the signals) transitioned. For example, the register 720 includes a signal name field and a time stamp field. The signal name field holds a bit representation that identifies the signal of interest (ie, holds a recognizable bit pattern to correspond to the particular signal of interest). The time stamp field holds a bit representation of the time corresponding to the signal transition specified in the signal name field. In one scenario, the timestamp value is deterministic across the silicon skew of a device such as PCH 605 of FIG. The time stamp is deterministic over the entire silicon skew used for debugging.

  Further, the register 720 may include a status field that holds a valid value indicating the signal name field and the time stamp field holding valid information. Conversely, an invalid value indicates that the state of the corresponding field in the same register is invalid. In one embodiment, register 720 includes a register array that holds information about all signals of interest, as determined by the designer or later updated by the manufacturer. Further, register 720 may be implemented as a circular buffer having a depth of N (N is a positive integer), obtaining the last set of N entries and the last N power Enables identification of state transition problems.

  To provide a more specific example, assume that the power control unit reset signal (signal 11) is acquired / monitored. In this example, the power in the signal initiates the boot process. A device such as PCH 605 then starts powering up. Register 720 may be initialized to an initial value. In response to other transitions in the power-up signal or the initial activation signal, the counter 725 starts counting. When signal 11 transitions, pulse generation logic 710 generates a pulse. The pulse generation logic also includes edge detection logic for signal 11 (not shown). As a result, a bit pattern (power control unit reset signal) that specifies the signal 11 is stored in the signal name field 735. Other information may be stored, for example, a bit indicating the direction of transition may be stored. In addition, the value of the counter 725 (time stamp) is stored in the time stamp field 730 to update the signal name field. Then, a valid value such as a high logical value indicating that the signal name field 735 and the time stamp field 730 are valid is set in the status field 740.

  This process may be repeated for further signal transitions. As described above, a circular buffer configuration may be used to hold information for the same number of power state transitions as the circular buffer depth. Further, once a signal transition is obtained, in one example, counter 725 continues to count (becomes an absolute time stamp from the first count). In another example, the counter 725 is reset (i.e., the time stamp from the previous signal transition). Further, as described above, the signal acquisition logic 700 generates a predetermined event such as the last signal transition or the last signal transition not detected for a predetermined period (possibility of a scenario in the case of a hang or “set”). Then, signal information acquisition is stopped.

  In one embodiment, once the information acquisition is complete, the register 720 can accept the read (ie, the signal information becomes visible and performs the necessary debugging of the signal transition or signal transition not detected). can do). In one embodiment, legacy systems use legacy test access ports to make physical connections and read register information. In one embodiment, such a read may be performed at any time after a manageability engine or test port is enabled without being masked or protected by a fuse. . In another embodiment, access to register 720 is provided and controlled by a verification architecture as described herein. For example, a verification control unit (VCU) can provide abstract secure access to registers. Here, the software can request information using the API. The VCU can then read the information from the register 720 and provide it to the requesting software. As described herein, the use of the system memory as an ODLA trace buffer may be arranged in the system memory by replacing or combining the registers 720 as described above. Good.

  The above has been described with a focus on obtaining signal traces in the control hub during power up. However, the apparatus and method for obtaining the initial signal trace described herein is not limited thereto. In fact, it is equally applicable to any silicon before the device test module is enabled / ready. For example, a similar device can be implemented in the processor 640 or a processor embedded in a small factor device to obtain signal information before the associated test / verification unit is enabled.

  FIG. 8 shows an embodiment of a flowchart illustrating a method for acquiring signal information at the beginning of a power sequence. In flow 805, a power-on event occurs. The power up event may be as simple as asserting (or deasserting) a power signal. In another example, information acquisition occurs in response to a power-up signal, but the actual start of information acquisition depends on intervening signal transitions. For example, the internal signal of the control hub may transition in response to a power up signal. And acquisition of signal information may be initiated in direct response to intervening internal signals. Here, the power-on event may include a power signal, an internal signal transition, or both.

  In flow 810, signal information in an initial state of power-on (information on a signal that may transition before the test unit is enabled) is acquired. As noted above, any known device or method may be used to obtain such information. For example, a simplified ODLA can be used that is preset to obtain information when a power event occurs. As another example, information acquisition logic as described above may be used. Regardless of the device and method, in flow 815, acquisition of information is stopped / stopped when a predetermined condition occurs. Predetermined conditions include, for example, the passage of a predetermined time / cycle, the transition of the target signal is not detected for a certain period of time, the last signal of the target has transitioned, the last signal of the target has not transitioned for a certain period of time, Other well-known predetermined activation events are included when a particular well is enabled, when test logic is enabled, and when the program instructs to stop acquiring information.

  In flow 820, a test port is available. For example, a manageability engine test access port is enabled during the boot process. As another example, the VCU is enabled with a universal access port, as described below. When the test port is enabled, the signal information obtained in flow 810 may be read out, and the reading is done in a secure manner, such as through the abstraction layer or directly to the test device. May be. Then, the software or the debugger can determine whether a problem or an item to be dealt with has occurred. As a result, conventional signal transitions in the early stages of the boot process, such as before enabling logic that normally provides internal signal visualization, can be debugged without such an integrated hardware hook. Compared with the method, it can be monitored and debugged efficiently and without much effort.

  In addition to the DFx function for obtaining an initial power-up signal as described above, in one embodiment, a hook may be incorporated to obtain a signal trajectory in a very low power domain. FIG. 9 illustrates one embodiment of logic for signal acquisition of a target in a low power state.

  While power states are often defined as product specific, in one embodiment, power states are any state in various power standards, such as the Advanced Configuration and Power interface (ACPI) type of power state. Point to. In the case of a processor, the ACPI standard defines three basic states: C0 (operation / active state), C1 (not executed, but can return to the execution state, halt state), C2 (stop clock state where software visible state is maintained but wake-up may take time) and C3 (sleep state) where processor does not maintain cache coherent but other states remain. In addition, deformation of these states is also considered. For example, the enhanced C1 state can be used when the power consumption is low. C3 / Sleep variants include deep sleep states (ie deeper or deepest sleep state C6) and require a longer time for processing elements to occur. These power states are merely examples and are primarily used to refer to the processor. However, similar states are defined in the ACPI standard for other devices such as control hubs.

  As shown, device 900 may include a processor, control hub, graphics device, or other well-known computer-related device, and may be in a low power state (ie, other than the C0 state of the operational state referred to in the above example). Including logic to obtain signals 901-906 of interest during any state. The first stage of logic (live acquisition 920) acquires a live trace / value of signals 901-906. For example, timing chart 970 shows acquisition of signal 906 based on clock signal 910. An enable signal, such as debug enable, may be used to limit clock 910 when not in debug mode (ie, gate clock 910 flops steps 920, 930). As shown in the figure, the second stage (with stored value 930, the raw (raw) state of signals 901-906 is obtained at the beginning of the power cycle as shown by power cycle signal 925. For example, , In PCH, the power cycle signal is generated in response to assertion (deassertion) of a specific predetermined pin, where in a non-boot state, the verifying engineer switches the pin, Reboot the system, so in this scenario, the latest version / status of signals 901-906 is obtained and stored, and in the example shown, the stored value 930 is shown in the timing chart 970 when booting is successful. As described above, the status 950 of the signals 901 to 906 during the state in which the recent boot (activation) has failed is maintained.

  To provide a specific example illustrating the operation of the logic 900, assume that the device / system 900 is attempted to boot five times. On the first boot, the enable bit is set to enable the logic. Here, a legacy JTAG or other test interface may be used to set the enable bit. In another embodiment, the VCU sets the enable bit. Assuming that the first boot is successful, the power cycle signal 925 goes low and the status of the signals 901-906 is obtained. If the second boot is successful, the status all points to one logical value (success from the previous boot and enable bit is ready). However, if the third boot fails, the system is restarted. In this case, the status of the signals 901-906 when the power cycle signal is toggled (switched), eg, high-low-high, and the power cycle signal 925 is low. Is acquired. Assuming that the fourth boot has also failed, the system is restarted in a similar manner. Subsequently, if the fifth boot is successful, status 950 reports the trace / status of signals 910-906 in the last failed boot attempt (fourth boot). As described above, the status 950 may be read by legacy test equipment. Alternatively, in another embodiment, a VCU that implements a layered test architecture is used to provide and control access to the logic 900.

  Much of the above description has been made with respect to obtaining processor verification information, and some explanations have been directed to obtaining the state of a control hub signal such as a PCH. However, the DFx hook is not limited to these, and may be mounted in other areas via the platform. The other areas briefly mentioned above provide hardware hooks for testing, verification and debugging of power related hardware and power supply networks. For example, it is believed that frequency up / down logic or voltage versus time measurement logic can characterize the power supply network (define impedance profile and / or identify resonant frequency). Alternatively, the measurement logic may be inserted into the motherboard by a voltage regulator (VR) to measure the required amount of current, power consumption, noise, and the like.

  Further, the DFx and verification architecture described herein is not limited to laboratory verification. The DFx functionality may be incorporated into a processor, control hub, motherboard, or other device that couples with mass production (HVM) test equipment. As a result, the well-known HVM test may be routed through the universal access port, as described below. In one embodiment, the manufacturing side, in a secure layered verification architecture, gives the manufacturing tester high access rights (ie, low level access to most or all of the included DFx functions). give.

  By providing a test architecture for a plurality of products, manufacturing defects may be diagnosed (cross-product verification) across all products such as processors and motherboards. It is considered that defects and distortions can be easily identified by providing test results through a layered test architecture and comparing a plurality of products with software. For example, thousands of processors may be tested by HVM accessing DFx via VCU and hierarchical test architecture. Then, the test results can be collected in the software / presentation layer, and the software can analyze the information and summarize it into displayable information such as distortion and defects.

  As another example, previous motherboard diagnostics relied on in-circuit probe testing (circuit board test (ICT)), which uses a dedicated external tester to test multiple on-board test points. . As the form factor becomes smaller and the cost of creating test points becomes higher, it is difficult to continue to support ICT. Thus, in one embodiment, the test architecture described herein, such as APIs provided for VCUs and high level software, is utilized to provide comprehensive diagnostics across multiple devices.

  Previously, devices were returned (no defects returned) even though they were motherboard defects rather than device defects such as processors and chipsets, but the ICT described herein Such a return can be avoided by a simple test method that does not require the. For example, instead of using an external ICT device, it may be possible to reduce the cost of testing by 30% by building DFx and providing DFx support (access and control) via VCU and API.

[Embodiment of verification control unit]
In one embodiment, a verification control unit (VCU) is provided to provide access and control to DFX functions such as hardware testing, verification and debug hooks as described herein. A VCU may include any hardware, firmware, software, code, microcode, or combinations thereof, and may implement control and / or access. FIG. 10 illustrates one embodiment of an example platform having one or more VCUs. As shown, the platform 1000 includes a plurality of VCUs, one in the processor 1010 and one in the processor 1075. In this scenario, the VCU may be included in multiple devices (processor, control hub, graphics device, motherboard or other well-known computer device). Each VCU may then be responsible for accessing and controlling the corresponding silicon DFx function. Here, a VCU, such as VCU 1012, is provided in each processor and can provide access and control to the processor 1010's DFX functionality (architectural and micro-architectural DFX 1015, ODLA 103 and PCU 1014). By distributing to multiple silicon devices within platform 1000, individual part testing (eg, HVM testing of parts here) and platform testing / debugging (eg, multiple parts are integrated into the platform, (This is useful when analyzing the performance of individual parts in the system as well as the analysis of the entire system), allowing access and control of DFx functions.

  In one example, the distributed VCU implementations allow VCUs to communicate with each other. This communication may be made directly using a VCU interconnect (not shown) that couples VCU 1012 and VCU 1080 in platform 1000. Alternatively, VCUs, such as VCU 1012 and VCU 1080, can use existing interconnects (connection 1065, eg, direct media interface (DMI), quick path interface, PCI, etc.) to couple with corresponding devices (processor 1010 and PCH 1075). Communication may be performed via an -E interface or other known connection). Alternatively, the VCUs may communicate with each other via a shared memory space. For example, the VCU 1012 writes to the memory portion 1021 that is obfuscated (abstracted) from the operating system, but is visible to other system devices such as the PCH 1075 / VCU 1080. As a result, the VCU 1080 can read the information written by the VCU 1012 and vice versa. As a specific example, if an integrated port is provided to access the verification architecture, interconnection / communication between VCUs is used to coordinate software access to the platform-wide DFx functionality. This will be described in detail below. Other problems may also be detected and addressed by communication between VCUs and / or manageability engines. Other issues include, for example, livelock, deadlock, patch load synchronization, power / performance state transition synchronization, survivability, trigger and trace settings, dump data post-collection, security, and acquisition / reporting A range is mentioned.

  Although the above description has been made mainly on the distribution of VCUs in the respective parts such as the processor, the control hub, and the motherboard, such distribution is not necessarily essential. Alternatively, one VCU may be placed on one device such as the processor 1010 or PCH 1075. The VCU may control access to the DFx hook of the platform at the same time as controlling access to the DFx hook of the device. Further, if an implementation that distributes VCUs is utilized, the VCUs need not be in contrast. In this case, since the silicon parts may be different, the VCUs may be arranged differently. In addition, one or more VCUs may have a high priority (eg, a headhome or master VCU coordinates access and control by other VCUs in the system). Alternatively, each VCU may be considered as a communication master.

  In one embodiment, VCU 1012 includes a programmable engine or unit that controls access to the DFx functionality of processor 1010. For example, the VCU 1012 includes a microcontroller. Microcontrollers often include devices that have their own processing elements, memory (flash, programmable ROM, SRAM or other well-known memory device) and communication interface. Basically, a microcontroller can be viewed as a small computer embedded or embedded in the processor 1000. Thus, when executed by a processing element, it may have its own code / microcode that implements the interface in software in the higher layer direction and in the DFx function in the lower layer direction. In addition, as described in detail below, the microcontroller is updated (control and operation of the code held in the patched memory via an authenticated patch or update), and other layers (software or DFx functions) New functionality may be provided to adapt to changes in the test and verification architecture. Then, the change is reflected in the DFx function of the platform or high-level software so that the VCU can be applied without replacing hardware (or the entire part).

  The description of a VCU that includes a macro controller is merely a pure example. Similar devices may provide similar control of access to DFx functions and provide similar interfaces to higher layers. For example, programmable logic devices such as programmable array logic devices, general purpose array logic devices, complex programmable logic devices, field programmable gate array devices can be used. In the figure, the VCU 1012 is depicted as one logical block in the processor 1010. However, portions of the VCU 1012 may also be distributed across different portions of the processor 1010 die or package, such that ODLA may be distributed throughout the processor 1010.

  An example of VCU 1012 interaction with a portion of the DFx function is described below. VCU 1012 has access to a channel at on-core interface 1011, such as a message channel coupled to control the registers of processor 1010. The VCU 1012 also has access to scan-out signals and scan signals such as fuses. Thus, the VCU 1012 can program various microbreakpoint triggering events (scenarios) and instruct the ODLA 1013 to store the trace in memory 1020 (or a portion of memory 1021 that is hidden from the operating system) Extract the trace stored in memory 1020 and deliver the trace to high-level software (eg, a debug tool). In addition, the VCU 1010 can control which DFx function is accessed according to the current security (unlock) level. In one embodiment, the VCU 1010 exposes an API with a tool that can program access to the DFx functionality of the processor 1010.

  In one embodiment, one or more layers of the verification hierarchy architecture described in detail below, such as an abstraction layer that obscures or abstracts the hardware details of DFx functionality when viewed from higher level software. VCU 1012 plays a role of implementing. Regardless of whether or not an abstraction layer is used, in one embodiment, the VCU 1012 is responsible for providing secure access to DFx functionality, as described in the verification board security embodiment section below. This will be explained in detail.

  FIG. 11 depicts an embodiment of a flowchart illustrating a method for responding to a DFx request from software using a VCU. In flow 1105, a DRx request is generated in response to execution of a software program, such as a test and debug program, from a third party vendor according to an application programming interface (API). Here, the DRx request may conform to API standards and rules provided to interact with services and routines provided by the VCU. That is, the software program may be written along a “vocabulary” defined by the API, such as a calling rule recognized by the API.

  In flow 1110, the DFx request is interpreted using an API implemented by the VCU. Here, the API operates as an interface or facilitator between the software and the DFx hardware. As an example, code stored in a VCU, such as code stored in the memory of a VCU microcontroller, is executed in response to a DFx request. In this scenario, the code stored in the VCU may include libraries, routines, data structures, object classes, protocols, and the like. Here, it is assumed that the DFx request includes a call to a routine in the VCU, and execution of the routine in the VCU performs some function / operation associated with the DFx hardware.

  In one embodiment, the VCU controls access (security) to the DFx hardware, as described in detail below. Therefore, in flow 1115, it is determined whether the DFx request is permitted based on the security level. Security will be described in detail below, but as a simplified example, it is assumed at this point that the exemplary operation of the VCU is involved. As an example, the VCU includes multiple levels of secure access, each access level allowing a different level of access to the hardware DFx. For example, each level may be associated with an encrypted passcode. When the software program begins execution, a secure passcode that unlocks its security level may be provided, thereby specifying the functions that the software program can access. Then, in flow 1115, a determination is made as to whether the DFx request is allowed within the security level associated with the software program, according to the level of access predefined by the VCU. If the DFx request is not permitted, appropriate processing (rejection, execution is not performed, exception processing is performed, etc.) may be performed in the flow 1120.

  On the other hand, when the DFx request is permitted, the DFx request is accepted in the flow 1125. Continuing the above example, if the DFx request includes a call to a service routine defined by the API, the VCU executes the service routine. Here, the service routine may include any routine for setting, starting or exchanging the hardware DFx function as described above. For example, the VCU may set a micro breakpoint start event that causes the processor to generate a start event and cause ODLA to acquire a trace at the breakpoint. Then, the result (trace) may be extracted in the flow 1130. For example, the result (trace) is written to a memory used as a trace buffer by ODLA. Then, in flow 1135, the result is provided to the software program. In this scenario, the software program can perform a memory read to obtain trace information for later interpretation / debugging. As shown in FIG. 12, in flow 1205, a change to the test architecture is determined. Changes may include changes to any layer of the architecture, such as changes to DFx hardware, changes to how a VCU interacts with another VCU, how a VCU is DFx hardware Changes in service, changes in services provided by the VCU, changes in security level (what each can access), changes in API standards, and the like. In flow 1210, the VCU is updated to reflect changes to the test architecture. Here, patches, authenticated patches or updates may be applied locally or remotely to update the VCU code to accommodate the change. As a result, the manufacturer only needs to provide an update of the VCU software if there is any change at the VCU level or at a lower layer in the layered stack. In this example, the third party vendor does not need to update the vendor's software program or tool because only the API becomes apparent to the high level software. VCU actions are modified based on updates reflecting changes in the test architecture while the API remains the same. As a result, if there is a slight change in the stack structure of the test architecture, it is not necessary to modify all layers of the hierarchical structure, thereby eliminating the expense (cost of redesigning or replacing hardware) and extra time. .

[Verification Hierarchical Architecture Embodiment]
As suggested above, in one embodiment, the test, verification and debug architecture is implemented in a layered stack. One embodiment of a layered stack of test architectures is shown in FIG. The layers shown are merely examples. Other layers may be included, and any of the illustrated layers may be omitted. Further, an example of logic that implements one or more of the illustrated layers, such as the abstraction layer 1315, such as a VCU, is just one example, and the illustrated layers include logic, hardware, firmware, code, It may be implemented in microcode, software, or a combination thereof.

  In one embodiment, the stacked structure 1300 obfuscates the implementation details of the hardware DFx. An abstraction layer 1315 (service layer) is provided to abstract such hardware DFx details and at the same time provides an interface with the client layer (application layer 1320 and presentation layer 1325). As shown, the interface provided to the application layer 1320 includes a plurality of APIs (APIs 1316, 1317 and 1318).

  An API generally refers to a specific set of rules and regulations that a software layer, such as application layer 1320, adheres to for the use and access to services provided. Basically, the API provides an interface between different layers (software, firmware or hardware) and facilitates interaction between different layers. The API may be accessed by layers 1320 and 1325 that may include consoles, tools, software, operating systems, libraries, applications, or other well-known structures that couple or program with the API. As a specific example, the API includes services, routines, functions, data structures, object classes, protocols, or other well-known API-related constructs.

  Although one API may be used, in the illustrated embodiment, different APIs are provided for accessing different services, routines and data structures provided by the abstraction layer 1315. For example, API 1316 may provide core services and data structures used by application layer 1320 for security (discussed in detail below) and abstraction of low-level details, thereby enabling generation It may be possible to reduce tool changes between them (even in next generation processors with different abstraction layer 1315 services and / or different DFx features, the same tools can be used to combine with the same API).

  Also, other APIs such as APIs 1317 and 1318 may provide other services, data, structures and abstractions. As an example, hardware DFx is not the only abstraction provided by layer 1315. Here, APIs 1317 and 1318 provide services and data structures associated with electronic validation (EV), power supply, manageability, security, access, or other well-known test, validation or debug related pillars. provide. In the past, manufacturers have protected certain algorithms, such as electronic verification (EV) algorithms, from being used by tools that exist in the client layer. Currently, no algorithm is provided, or only a subset of the algorithm is provided, often becoming a sub-standard vendor tool for EV.

  In one embodiment, API 1317 includes an API that is a pillar of EV and provides a complete set of abstractions of such algorithms used by tools / software in higher level layers 1320, 1325. Thus, the algorithm may be provided in a secure manner (invisible to the TPV tool), thereby making it a good TPV test tool, while at the same time abstracting the sensitive algorithm into a confidential state. Can be kept. Examples of EV-specific API pillars may be inferred from API pillars that are associated with any individual test, validation and debug and abstract hardware, firmware, software, code, algorithms, protocols, etc. Furthermore, providing an API service module specific to a pillar may facilitate module updates. For example, if you want to modify and update something associated with an EV, a patch of EV code stored in a VCU microcontroller that implements EV API 1317 without updating core services or other API modules Updates are performed.

  In the above example, regarding the API, the interface between the abstraction layer 1315 and the client layer (the application layer 1320 and the presentation layer 1325) has been mainly described. However, any known device or method that provides an interface that obfuscates, abstracts, or blurs the details of the lower layers may be used for the lower layer, such hardware implemented in software / hardware. Hardware or algorithms may be implemented. The example of the abstraction layer 1315 is implemented by the VCU microcontroller as described above. Here, the logic and / or code that implements the API 1316-1318, such as code stored in the memory device of the VCU microcontroller, is incorporated into the VCU. In another embodiment, code, services and data structures that implement the API for the abstraction layer 1315 are maintained in memory and executed by a device under test, such as a processor under test.

  As shown, the bottom layer of the stacked structure includes a target DFx layer 1305, which may include well-known DFx functions such as the hardware functions / hooks described above. The DFx layer 1305 may also include a legacy test / verification function. Thus, in some embodiments, direct access 1350 may allow direct access to some of the hardware DFx functions in layer 1305. In another example, the target DFx layer 1305 includes a unit under test that includes a processor, PCH, graphics device, motherboard or other electronic device.

  The transport layer 1310 adapts information, such as tasks from the services and routines provided by the abstraction layer 1315, to execute in a particular transport vehicle, but the services and routines have a transport mechanism. (Ie, does not know how services / routines are transported to the DFx layer 1305). For example, transport layer 1310 includes transport hardware and associated drivers that obtain information from abstraction layer 1315 and adapt that information to the appropriate packets / information to transport to layer 1305. Here, the transport medium may include interconnections within the platform, connections that couple the console / tester to the platform or device via ports, layer 1305 in the non-test unit located remotely from layer 1315 on the host machine. Network for remote access between or other well-known test-test related devices such as in-target probe (ITP) devices, defined debug ports, third-party vendor (TPV) transport devices Is included.

  As can be inferred from the example network, one or more layers of the laminated structure 1300 may be implemented on various machines and / or components. For example, the target layer 1305 may include a platform under test that is remotely connected to a host platform that implements one or more layers of the remaining stack. As another example, the client layer is implemented in a host system that remotely accesses a platform under test or a portion thereof that implements a service layer and a target layer 1305. Remote access is described in detail in the verification architecture access embodiment below.

  The client layer may include any tool, console, application, or other entity for combining with the abstraction layer 1315 that abstracts the low-level details of the DFx layer 1305 and / or the DFx functionality in the target layer 1305. . When binding to the abstraction layer 1315 is done via one or more APIs such as API 1316-1318, it binds to the API according to rules and rules, including pillar-specific API module rules and rules. The application layer 1320 is designed to be programmed to / API. Further, as described above, even when a new generation of products is supplied, as long as the API communication standard between the client layer and the abstraction layer 1315 is the same, it is necessary to replace the client layer tool with a new version. There is no. Instead, the abstraction layer is updated to provide the same service in a new way for the new product (target DFx layer 1305). Also, third party legacy and non-service applications may be integrated with one or more manufacturer's accessories into one or more tool solutions in the client tier.

  The presentation layer may be integrated with a tool or another entity that correlates, visualizes and / or displays underlying data and protocols. In this case, these tools may be designed according to the preference of the third party so that the final result can be obtained from the DFx test in a manner desired by the third party. In this example, application layer 1320 programs abstraction layer 1315 using the services and routines provided. Results from these services and routines, such as the results of tests at layer 1305 or the output of the algorithm at layer 1315, are passed to the application layer 1325. The application layer interprets (debugs) this data and passes it to the presentation layer that displays the data to a person or for tool interpretation.

  FIG. 14 illustrates one embodiment of a flowchart illustrating a method for accessing DFx functionality through a layered architecture stack. In flow 1405, an application such as a third party vendor tool programs into the abstraction layer. Here, a tool or other entity requests / utilizes a service from the abstraction layer defined by the API associated with the abstraction layer. In a flow 1410, such a service is provided. Here, if the service includes a local algorithm in the abstraction layer, the information / data structure may be provided to the application layer.

  On the other hand, if the service includes communication with the lower layer with the DFx function or the target device under test, in flow 1415, from the stacked structure (abstraction layer and application layer) regardless of the high-level transport method. Information is applied to the transport. For example, this application includes formatting information from the abstraction layer into a transport protocol such as a test port protocol, an interconnection protocol, a network protocol or an internet protocol. In flow 1420, the communication data in the applied format is transported to the DFX unit under test that performs the operation requested by the abstraction layer. Any known DFx operation as described above may be performed. In flow 1425, the results are provided to the application, and in flow 1430, the results are interpreted by the presentation layer.

  As a continuation of one typical example of the flow described above, a test and debug tool requests a unit under test, such as a processor, to program a microbreakpoint, and before reaching the microbreakpoint, Assume that a trace is acquired at or after point. In this example, the application may invoke a service provided by the application layer (flow 1405). The abstraction layer executes the called routine, which includes sending the microbreakpoint definition and the trace collection direction in the stacked structure (flow 1410). The transport layer traces the collection from the transport, such as applying the microbreakpoint definition and making the packet to be transported through the test port (flow 1415). The generated packet is transmitted to the processor (flow 1420). In response, microbreakpoints are set in the processor control registers and trace information is collected on demand. Here, the return of data may include a path returning upward in the stacked structure, or may include a path passing through the abstraction layer and returning to the application layer (flow 1425). As another example, the trace information may be stored in a memory that is used as a trace buffer. The application can read back the trace information from memory (flow 1425). Using the trace information, the presentation tool can reproduce the processor trace in a simulation that interprets the data (flow 1430). Here, the accessibility to functions below the abstraction layer is ensured, that is, the access request to the function that is not unlocked by the application, or the security / authority level of the application. Access to more functions may be denied. Such a security enhancement configuration will be described below.

[Security Embodiment for Verification Architecture]
As noted above, one purpose of the test, verification and debug architecture includes abstracting (obfuscating) details at a lower level (hierarchy) that a designer or manufacturer does not want to reveal. However, in one embodiment, such details abstraction or obfuscation may not be sufficient from a "security" perspective. If only the abstraction layer is used, if the communication method with the abstraction layer API is determined, anyone including the end user can access the test architecture. Thus, in one embodiment, access to the test architecture is kept secure, i.e. requests from higher layers that are not authenticated are not allowed.

  FIG. 15 illustrates one embodiment of logic that provides secure access to a test architecture. Here, the application or console 1515, which may include any of the entities described above with reference to the application layer or the presentation layer, includes a passcode 1520. Passcode 1520, also referred to as a key, includes any known type of value that provides a secure or locked access to a function or level of access. In the initial exchange or the exchange following the request, the application 1515 provides its passcode 1520 to the abstraction layer via an interface 1530, such as an API interface implemented by the VCU 1507. Here, the topology of the application 1515 is shown logically separated from the UUT 1505, but this is merely an example. Alternatively, UUT 1505 may execute an application. VCU 1507 may be implemented in device 1515, which in this scenario is considered as a host system / console accessing UUT 1505.

  Regardless of the physical implementation, when the abstraction layer receives the passcode 1520, the passcode and application stored in the storage element 1510, such as a UUT 1505 general purpose register, control register or model specific register (MSR) Based on the comparison with the passcode, the abstraction layer provides the degree of access to the application 1515. As an example, assume that there is only one level of access (full access or no access). Here, if the application passcode 1520 matches the passcode held in the storage element 1510, the application 1520 is responsible for all services provided to the abstraction layer implemented by the VCU 1507 (to the associated DFx function. Access) may be used. Alternatively, if the passcode is not provided or does not match, the request from the application 1515 to the abstraction layer is not satisfied / allowed.

  In one embodiment, multiple levels of security are provided. For example, a designer may want to give different access levels to algorithms, protocols, data structures, DFx functions, etc. for different customers or vendors. The designer / manufacturer then wants the abstraction layer to have unrestricted access to the low-level details of the DFx function that it abstracts to test, validate and debug the DFx function and associated UUT. Similarly, the designer / manufacturer may provide full access within the abstraction layer.

  In the illustrated embodiment, the storage element 1510 holds three levels of passcodes. One of the passcodes (passcode 1511) is a manufacturer password that provides level 0 access (free or almost unlimited access to DFx functionality). The second level (level 1) represented by passcode 1512 provides partially selective / restricted access to the test architecture. And the Nth level, represented by passcode 1513, provides more selectively restricted access to the test architecture. Here, each passcode is securely supplied so that the passcode 1512 is supplied to a third party vendor (TPV). As described above, when designing the TPV tool, the passcode 1512 can be incorporated or used as the passcode 1520. Thus, level 1 access is provided to the test architecture when the application 1515 passes the authentication process (when the passcode 1520 is provided as an abstraction layer or security implemented by the VCU 1507). In this case, level 1 access is restricted. Accordingly, access from applications 1515 that are not within the security level (DFx functionality or access to restricted implementation details) is denied (not permitted) by the VCU 1507.

  FIG. 16 illustrates one embodiment of a flowchart for providing secure access in a test architecture. In flow 1605, the access level of the application is determined. In one embodiment, any known authentication process is used to associate the application with the access level of the test architecture. In another example, a passcode verification process as described above is used to determine the access level of the application. This determination may be performed at the start of execution of an application (general authentication at the start of a program) or may be performed when a specific request occurs.

  In flow 1610, the application provides a service request to the abstraction layer API. Here, the service request to the API is merely an example, and the request may include any service request or an access request to the DFx function. In flow 1615, it is determined whether the requested service is allowed based on the determined access level regardless of the type or form of the request. In this scenario, certain services, algorithms, protocols, DFx functions, etc. are predetermined as allowed or restricted according to a defined security access level. Thus, if the request is associated with one access level of the application (or one level of more access), the request is granted in flow 1625 and in flow 1630 (part of the service). Transported to the DFx unit under test. Conversely, if the request is not within the access level of the application, it is not allowed in flow 1620.

Embodiment of physical access to verification architecture
As described above, access to hardware test functions is distributed across multiple coupled and unconnected ports that exist throughout the computer platform. This makes the connection to test the platform or cumbersome and expensive (various ports exist and different tools are needed to connect these ports). Accordingly, in one embodiment, a universal test access port (UTAP) is provided instead of multiple platform test interfaces. FIG. 17 illustrates one embodiment of UTAP for a test architecture on a platform.

  Processors 1710a-d include known processors connected together by an interconnect 1750 such as a quick path interconnect, and PCH 1770 communicates with processor 1710c via an interconnect 1765 such as a direct media interface (DMI). Are combined. As shown, VCUs 1712a-e may communicate over an interconnect 1790 such as a test connection or other well-known interface. However, in another embodiment, the VCU can communicate over the interconnects 1750, 1765 as described above. As a result, in this scenario, the VCUs 1712a-e are adapted to communicate with each other, thereby allowing access to the VCU test functionality of the platform 1700 via one integrated port, such as UTAP 1785. Here, the VCUs 1712a-e can interact with each other. Alternatively, a message from UTAP 1785 can be routed to a suitable intended VCU.

  In one embodiment, UTAP 1785 includes a bi-directional port that extracts debug information (from a memory or VCU associated with the processor) and communicates with VCU 1712a-e. As an example, UTAP 1785 includes a dedicated test port. In another embodiment, UTAP 1785 is an existing interface (eg, Universal Serial Bus (USB) interface, Serial Advanced Technology Attachment (SATA) interface, or other well-known interface) or dual-use future Tying together another interface, such as an interface.

  The topology shown is only an example. Any number of processors may be included. Further, PCH may not be included. In addition, UTAP 1785 may include physical ports that couple external devices such as consoles, computers, or testers. As another example, UTAP controls communication with a network interface device (eg, NIC) or host or remote system (the remote system is described in more detail below). Here, the control unit may include a baseboard management control unit (for example, an embedded microcontroller embedded in the motherboard that reports system parameters such as temperature, fan speed, power supply status, etc.). Remote communication may be facilitated.

  By providing a universal test port, platform testing can be simplified (both cost and complexity). However, inefficiencies also exist at current test locations for individual parts such as processors. For example, a typical processor is provided with test and verification pins on the bottom side of the processor, and the pins are limited. Therefore, the package substrate is large and the cost is high. In order to reduce such costs, hook testing and debugging has been largely omitted. As a result, an error may occur in the part that the customer could not debug, and the product may be returned to the manufacturer.

  Accordingly, in one embodiment, an integrated circuit (IC) package substrate (e.g., a processor, a control hub, etc.) on a top surface area where no electronic components are mounted, e.g., a peripheral area of the substrate, etc. Place some or all of the verification pins. As an example, these pins are etched into a metal layer outside the package substrate and exposed by solder resist.

  FIG. 18 illustrates one embodiment of an integrated circuit package in one example of a mass production connection mechanism. In this example, the IC includes a CPU package 1860 that includes upper test and debug pins 1865. These pins can be connected in a variety of ways, depending on the intended purpose of use. If the purpose of use is verification and troubleshooting, a compression type connector mechanism may be used to access the pins, and the connector mechanism may include an alignment feature that aligns the connector directly on the package substrate. This allows maximum tolerances and makes the pin size and connection system as small as possible. These structures often include structures that are received and mated to the socket 1850, allowing the top connector to connect to the IC 1860 substrate.

  In the illustrated connection scenario, such as the HVM connection scenario, it includes a bivalve-shaped hinge fixing portion 1820, whereby an IC fixing probe 1835, such as a pogo pin (probe pin) type connection, is connected to the top surface pin 1865. Can be connected. Then, the fixed probe 1835 is connected to the console / tester 1805 by the IC fixed probe wire 1810. As a result, the bivalve hinge 1820 can open the connection mechanism, and when a new part is inserted and the hinge 1820 closes, the connection between the tester 1805 and the top test / debug pin 1865 is made. . In the case of various mass production test applications, the connection speed of the pins on the top of such a package is maintained at the minimum allowable “beat rates” and the connection method is automated as shown in FIG. And / or one type of highly efficient mechanism is used.

  Similarly, the connection of the mother board 1840 is also illustrated, and the mother board fixing wire 1823 connects the tester 1805 and the MB fixing probe 1825. As illustrated, the base probe 1830 is in contact with the base of the motherboard 1840. The bivalve hinge 1820 shown is merely an example and any known connection scenario for probes, testers, sockets, HVM tools, etc. may be employed. In addition, similar mechanisms may be used for other ICs such as controller hubs or peripheral devices.

  FIG. 18 shows an integrated heat spreader (IHS) 1870, which, in one embodiment, creates an area for providing the top surface pin 1865, in which connection with the fixed probe 1835 is made. It is possible. FIG. 19 shows an embodiment of a heat spreader having a function for inconspicuous mounting that supports upper surface test pins and probing. In this example, integrated circuit 1905 on package 1907 is associated with IHS 1910. In one embodiment, the IHS 1910 includes a “mounting ear” 1911 that protrudes inconspicuously. In the figure, the mounting ear 1911 provides a socket actuation mounting point that enables a socket mounting mechanism, such as a direct socket mounting (DSL) mechanism 1920. By adopting such a design, the area occupying the upper surface can be reduced, and more space for signal pins / pads for verification as described above can be secured.

  A continuous or discontinuous small step along the outer edge of the IHS 1910 may be provided on the outer periphery of the IHS 1910 outside the mounting ear 1911. In another example, the outer edge may not have a step. When the ear 1911 is mounted as shown, the package 1907 is pressed against the socket, the socket is activated, and an electrical connection is made between the socket and the device package. The number of ears depends on the number of specific mounting points for each application (two ears are shown in the figure, but are not limited to this). Furthermore, although the ear 1911 is located below (for example, directly below) a predetermined application mounting point in the drawing, it is not always necessary to be located in the middle of the IHS 1910. The ears 1911 are often (but not always) positioned in such a way that the force applied by the mounting mechanism in the IHS 1910 is an actuating force sufficient to contain the IHS 1910 / package 1907 in the center. In one embodiment, the mounting ear 1910 has a specific length that completely covers the mounting zone of the mounting mechanism. For example, the proposed IHS ear has a length in the range of 1 mm to 50 mm that covers the mounting length of the DSL mounting plate 1920. During IHS 1910 assembly, an IHS sealant can be placed under the ear 1911 to move the mounting force to the package 1907 without bending the ear 1911.

  In the conventional typical IHS, a mounting stage is provided in 90% of the peripheral portion so that the load is sufficiently dispersed to provide a starting force for electrically connecting the socket. On the other hand, by providing the mounting ear as described above, the same mounting process can be achieved using a small number of steps provided on the outer edge, so that the test / debugging can be performed on the upper surface of the IC. Therefore, a wider area for pin arrangement and probing can be secured. Also, by utilizing the widened space, the IHS 1910 may have a selectively shaped shelf with an inconspicuous mounting ear 1911 located in the portion of the IHS 1910 that is heavily loaded. For example, the DSL mounting plate 1920 contacts a small portion of the step in the IHS 1910. Thus, the ears 1911 are strategically placed where the DSL plate 1920 is loaded. As a result, it is possible to provide a new upper surface test pin without increasing the package size or reducing the heat dissipation area of the IHS 1910 by utilizing a newly reserved space where nothing is provided.

  With regard to heat dissipation, the current design with a thermal margin has been increased in size, and a large area has been used, and the margin for maintaining signal reliability has been reduced. Accordingly, FIG. 20 illustrates one embodiment of an exploded view of a small factor thermal tool (SFFTT) design designed to provide thermal margin. In some embodiments, such margining may be considered as one of the DFx functions. SFFTT 2000 includes one or more structures as follows. A custom cold plate 2010 soldered to the bottom of a mini-bulk thermoelectric cooler (TEC) array 2025, attached to the top surface of the bulk TEC array 2025 via a liquid metal thermal interface material (eg, Ga-Sn liquid metal material). Water cooler 2040 with micro-channel cooling technology, unique channel designed water cooler 2040 cover to provide uniform water flow distribution, water inflow / outflow (inflow 2050 and outflow 2060), control at the center of the device Wire harness assembly for the unit, a T-type thermocouple embedded in the center of the cooling plate 2010 that provides temperature feedback to the control unit, and provided between the water cooler 2040 and the cooling plate 2010 to prevent TEC cracking Spacer 2020 and experimental circuit board 2035 are used. To wire stress reduces TEC2025 cable management, and include structures such as the temperature switch.

  Such a structure can provide a useful configuration for SFFTT. For example, a water cooler 2040 that employs microchannel cooling technology can cool more efficiently than a design of diamond fin technology. By placing the inlet and outlet (250, 260) in the center of the SFFTT 2000, along with the unique channel design of the water cooler cover, the cooled water flows from the center to the block, Because it can be passed through the side of the cooler, the length of the cooling channel is half that of other diamond fin-type designs. As a result, the most coolable region can be placed in the center where the heat is typically concentrated by the heat generated by the TEC 2025 and the silicon under test. Finally, the temperature difference in the water cooler can be reduced by about 3 ° C., and the temperature distribution becomes uniform, so that the reliability of the TEC 2025 is increased. In another example, attaching the cold plate 2010 to the mini-bulk TEC 2025 can reduce the layer of thermal resistance. Further, the spacer 2020 between the water cooler 2040 and the cold plate 2010 provides a buffering mechanism that can prevent TEC 2025 cracking problems that occur in the case of bulk TEC. Cable management using the experimental circuit board 2035 can alleviate wire (wiring) stress and reduce the failure rate of TEC lead wires.

  For further explanation, a detailed example of the above structure is described below. As a first example, the mini-bulk TEC array 2025 includes a region having a maximum size of 39 mm × 39 mm with a maximum dissipation temperature of 75 ° C. and an installation area of 15 cm 2. Further, any number of TECs may be connected to the array 2025. As an example, two sets of 11 TECs are connected in series and two other sets of 11 TECs are connected in parallel. The microchannel fin design of the water cooler 2040 provides a vertical (or horizontal) cooling channel rather than a circular cooling pattern of diamond fins. The channels / fins can be any size. For example, the fins may be provided at intervals of 2 mm in height, 0.3 mm in width, and 0.3 mm. A summary of the performance obtained in an example simulation of various designs of the water cooler 2040 is shown in Table 1.

  Similar simulations confirm that the microchannel water cooler technology improves the velocity and temperature distribution. This improvement can provide a similar temperature margin (5 ° C.-100 ° C.) while reducing the size of the SFFTT by 40-50% compared to conventional thermal margin devices. Furthermore, the smaller form factor can reduce the occupied area on the board, thereby enabling the chips to be placed close together, thereby improving the signal quality (SI) margin. it can. With improvements in SI margin, trends in all market segments are expected to accelerate product miniaturization. Also, the unique channel design in the cover of the water cooler can provide a uniform water flow distribution, thereby improving TEC reliability. In addition, fault detection can be speeded up by isolating faults and reducing leakage as part of manufacturer and vendor post-silicon debug / verification activities. By providing vendors with the ability to margin temperature, manufacturers can gain a competitive edge in performance. In addition, items discovered by vendor verification can be useful information for a manufacturer to perform electrical verification more efficiently. And it will be possible to provide more end-user friendly products.

[Embodiment of remote access to verification architecture]
In the past, manufacturers have spent significant resources (time, personnel and money) to help vendors debug. In fact, if the vendor cannot test and debug the problem that occurred, the manufacturer / designer has dispatched an engineer to perform verification to the vendor's factory. With the increasing complexity of parts and platforms, the verification and debugging process has become more difficult for vendors and more complicated for manufacturers. Thus, in one embodiment, the verification architecture allows remote access to assist in the testing, verification and / or debugging process.

  FIG. 21 shows an embodiment of remote access to the unit under test. As described above, the test architecture stack may be implemented across multiple machines (and networks). Here, the remote host 2105 includes / implements a tool 2106 (an application layer having test, verification and debug tools) and an abstraction layer 2107 as described above. Communication information from the layers 2106 and 2017 is provided via an interface 2130 including a well-known interface such as a remote interface, a network interface, and a peripheral device interface. In one embodiment, such communication information is encrypted according to a well-known encryption algorithm 2150. Furthermore, in another embodiment, VPN encryption 2110 is used for the transport. In this scenario, the local host 2115 (i.e., a host that is coupled in some manner with the remote host 2105) is covered by the transport layer 2116 to employ layers 2106, 2107 that are insensitive to the transport method for transport. The test unit (UUT) 2120 is mounted. Therefore, the above test, debug, verification and security operations may be implemented from the remote host to the interface of the unit under test.

  With reference to FIG. 22, another embodiment for remote access to a test under test will be described. In this example, the remote host 2205 includes three layers (2206, 2207, and 2208) and communicates directly with the unit under test (UUT) 2220 via an encrypted channel. Unlike the illustrated layout, any combination or layout may be implemented to remotely interface with the unit under test. Also, any authentication process may be used to set the channel. Various levels of access may be verified using a security protocol (similar to the protocol described above). As a result, the vendor or manufacturer can remotely test, verify, or debug the device without being physically coupled to the unit. In this way, the time and cost associated with remote test / debug can be significantly reduced without physically sending an engineer to perform the verification to the vendor's factory.

Collected information management embodiment
As described in the hook testing, verification and debugging embodiments section, the ODLA of a processor, control hub or other device, in one embodiment, collects on-die and / or interface information such as trace information. Can do. Information may be communicated in any manner, such as using memory as a trace buffer. Alternatively, as described in detail below, the logic may provide such data via an interface such as a sideband communication bus. Information is then provided to tools for management (formatting, manipulation, interpretation, debugging, etc.).

  In addition, as described above, it is complicated and expensive to use an external analysis device that collects and analyzes parts. For example, a complex interface protocol analyzer such as a PCIe interface may cost as much as $ 50,000. As part of in-band messaging over a high-speed serial interface, as legacy signals are integrated, information is not readily available on the motherboard. Thus, FIG. 23 illustrates one embodiment of logic for providing trace information to a host system on a sideband bus such as JTAG or SMBus. Examples of acquired legacy in-band signals include TRDY 2321, INTR 2322, SMI 2323, and STPCLK 2324. In this example, ODLA 2330 in PCH 2320 obtains a trace of the above signal. A trace may be acquired in response to an event such as pin switching or breakpoint event setting according to an instruction from the host system 2360 or the embedding control unit 2340 (for example, a VCU that implements an abstraction layer). The controller 2340 obtains data about the signal and provides it to the host system 2360 via the sideband bus 2350. As an example, the format of this data includes information indicating whether the corresponding signal is kept in a high state, kept in a low state, switched, the switching direction or switching frequency. In this example, the debugging capability can be updated without changing the hardware by using the functions of the embedding control unit 2340 for processing data and the ODLA 2340 for selecting various internal signals to be observed.

  FIG. 24 illustrates one embodiment of a flowchart illustrating a method for managing internal observation trace (IOT) data. In flow 2405, a test is performed on the system. For example, the above-described test may be performed on the unit under test. Then, IOT data is acquired from logic such as ODLA (also referred to as an on-chip logic analyzer or OCLA). The IOT data may include multiple streams / sources (eg, memory, I / O, on-core interface, etc.).

  In flow 2410, IOT data is dumped. For example, the memory associated with the unit under test is used as a trace buffer for IOT data. However, any known interface may be used to dump / provide data to a system such as a console or host system that handles / interprets IOT data.

  In flow 2415, the trace data is reconstructed from the IOT data to allow playback. Any known method of reconstructing the trace and / or formatting the trace data may be utilized. FIG. 25 shows an example of trace construction. In this example, the format of IOT data is decoded. In one scenario, the IOT data includes multiple streams / sources in a specific defined format. In flow 2505, IOT data is decoded according to such a format. As an example, a source is specified for IOT data. Then, in a flow 2510, the IOT data is separated, grouped, and bucketed by the source.

  Module for each source (service), eg memory module for memory source IOT data, internal processor module for processor trace IOT data, quick path module for Quickpath interface IOT data, on for on-core interconnect ring traffic The core module or the like reconstructs a transaction for each corresponding source in flows 2515 and 2520. Further, in one embodiment, in flow 2525, the module reformats the reconstructed trace data for playback. As shown in FIG. 24, the formatted and reconstructed trace data is reproduced. As a result, playback can provide insight into the operation of the unit under test for verification and debugging.

  As a result, the time and cost for debugging can be reduced, and the product development cycle can be increased. Replay also allows the software mechanism to replay bugs in an emulation environment for products that include the same or similar DFx methods, such as the test architecture described above. By reproducing such a bug in the emulation environment, it becomes possible to completely visualize the entire system behavior in the system under test, and to debug quickly. And it helps to solve bugs about logic and path marginality. In addition, similar equipment and methods may be used to develop test content for mass production, providing quick and efficient test content for mass production, increasing product stability. Costs can be reduced, partly from helping inventory management.

  FIG. 26 illustrates one embodiment of a flowchart of a method for detecting post-processing divergence. As described above, when a test is performed on the system under test (flow 2605), data is collected and the exact same test conditions are described in the emulation / simulation environment (similar method described with reference to FIGS. 24-25 above). The collected data can be used to replay in an environment operating in flow 2610-2625). From this process, verification can detect differences between tests performed in hardware and tests in the software model, and these differences are referred to as divergence. Post-processing difference detection uses DFx hardware functions, such as IOT using OCLA, to save the state of the system. When the test is reproduced, the data stored in the IOT in the emulation (reproduced IOT data 2635) is processed after the reproduction and stored in the IOT collected from the system under test (collected IOT data). 2615), the post-process difference detection result 2640 is obtained (that is, the difference between the data 2615 and the reproduction data 2635 is obtained). Since execution requires expensive and special hardware, the execution time during playback is costly. Therefore, calculating such differences between regenerations would be costly execution time. Thus, in one embodiment, the system state stored in an internal location, such as system memory, is used to process the data separately on less expensive hardware after the playback phase is complete.

  FIG. 27 illustrates one embodiment of a flowchart that allows an RTL data structure to be accessed in a high level language. When trace data is collected from the system under test, the specific data fields collected are typically analyzed, and the analysis includes modifications from the trace. Since RTL changes constantly, software designed around RTL needs to be constantly updated. Thus, in one embodiment, when software is released (flow 2705), the RTL model is scanned at the time of software release (eg, taking a snapshot of RTL data in flow 2710). From the snapshot, the RTL data type is recorded in a more general format, such as XML. In this example, in flow 2715, an RTL data structure snapshot database is generated from the RTL snapshot data.

  When RTL data is stored (ie, a database is generated), a software mechanism / service is provided that reads, masks, and modifies trace data packets based on the snapshot RTL data type definition. By selecting the snapshot to be read based on which RTL model the trace is derived from, it may be possible to prevent other software from being affected by the less important RTL changes. As an example, when the software uses the RTL model to interpret or modify the trace data from the test (flow 2720), the software requires a database of RTL data structures (flow 2725), and the information is traced to the trace data. (Flow 2730) is used for the code. As a result, a flexible and adaptable test infrastructure (packet and signal format model) for the RTL data structure is provided instead of relying on a stationary RTL model and modifying the software.

[Power verification embodiment]
As the number of logic increases and the circuit becomes smaller, the problems that occur in the circuit are rapidly increasing. Circuit bugs may not be detected. Also, there is currently no good characteristic evaluation method that makes it possible to regenerate circuit faults as a problem of non-high-speed paths. Thus, in one embodiment, a circuit marginal validation (CMV) method is used to find problems in non-high speed paths and high speed paths. Major factors of circuit boundary are on-die signal reliability (noise due to cross coupling, noise due to droop events), power supply reliability (often due to clock switching) High current generation), clock domain crossing (clock asynchrony), and process, voltage and temperature changes (power state transitions, silicon process changes).

  Based on analysis of platform verification management products over several generations in the past, the power grid is a major factor in circuit margin. Thus, in one embodiment, a platform that enables spatial and temporal characterization and debugging of power grids related to on-die events, including a platform that includes the ability to correlate grid network performance with test and system events. provide.

  FIG. 28 shows one embodiment of such a base. In this example, it is a comprehensive and integrated (on-die) architecture that allows observation of time-based spatial control and on-die voltage regulation, such events as deterministic test content and system events. Provide an architecture with the ability to correlate. As shown, architecture 2810 may be coupled to host 2800 via an abstraction layer 2805 (as described above) that may be implemented by VCU 2815.

  The components of architecture 2800 employ high bandwidth on-die voltage droop monitoring (VDM2830) and droop injection mechanism (ODI2835) (in one embodiment, both of which are configured in time and space. Clock cycle specific test content synchronization infrastructure, deterministic event triggering and infrastructure to monitor the exact time of the clock cycle (DSC2840) (in one embodiment, these configurations allow event timestamping and playback) Dynamic on-die voltage control state acquisition function such as ODLA for VR state acquisition correlated with the event, configurable hardware-based payload correction mechanism (microbreakpoint logic 2830), correction mechanism is system event, Tess Events, and / or the best may be initiated at the transition of the power state in the domain by the predetermined power the domain or user / host 2800.

  For an incomplete list of architectural features, such as ODI / VDM / system (I / O or core) events, snapshots of analog observations via A / D samples and dynamic snapshots of state machine events Ability to correlate with observation of on-die voltage control interval, Ability to definitely initiate hardware-based payload changes, Ability to synchronize ODI and / or VDM start events with internal VR events, Abort internal VR events Functions, function to get timestamp of internal VR event, function to monitor delay between power management command problem and actual VR change, function to observe VDM / ODI change, inbound current behavior and internal event And observe the effects of gear ratio changes and power distribution. Includes the ability to provide a calculation of detection intervals of the duty cycle.

  The incomplete list of architecture applications and modes includes grid characterization, system event-based correlation, and power event-based correlation, which are illustrated below. In the case of a power grid, the characteristic analysis may be performed in any way that the user can flexibly select. Basically, the voltage monitoring circuit in this operation mode is preset so as to acquire the voltage on the time axis. The voltage is measured by counting the frequency of the ring oscillator during a short period of time. When testing or other system operations are performed, the highest peak and lowest valley in the local location of a given power domain are obtained by comparing samples throughout the characterization cycle. Here, characterization may be performed while the system is in hibernation, in the boot cycle, during testing, or during any system event. Feature analysis may be performed simultaneously with any / all domains.

  In the case of system event-based correlation, a failure point or cyclic redundancy check (CRC) using a microbreakpoint infrastructure that synchronizes the start of the test sequence (or the target system event) and the start of grid sampling The elapsed time is obtained at the point of occurrence of a particular system event, such as a fault (as in the example shown). And, to assess on-die voltage control performance in a configurable manner, the test sequence is deterministically replayed, giving the ability to see a given clock cycle before, during or after a given start event. It is done. Data collection of analog points and state data may be acquired dynamically at a predetermined moment in time or at a location based on the subject's start event. As a result, various flexibility can be provided in the architecture, such that startup events and actions may be provided by power control blocks, power management, or test / system specific events.

  In the case of power event-based correlation, the operation is similar to system event correlation. A platform such as a micro breakpoint can be integrated with the voltage control circuit to initiate a number of system events by sampling the grid via VDM2830 and / or injecting droop events via ODI2835 It becomes. A start event in this mode is typically initiated in one embodiment with a specific power event or state.

  As used herein, the term module refers to any hardware, software, firmware, or combination thereof. Module boundaries, shown as separate, usually change often and can overlap. For example, the first module and the second module may share hardware, software, firmware, or a combination thereof, or may have independent hardware, software, or firmware. In one embodiment, the term logic includes hardware that is combined and / or configured to perform tasks such as, for example, transistors, registers. In another embodiment, the term logic includes a programmable logic device or other device such as a programmable logic array. However, in yet another embodiment, the logic also includes software or code integrated with the hardware, such as firmware or microcode.

  Also, as used herein, the term “value” includes any known representation of a number, state, logic state, or binary logic state. Also, a logic level, logic value, or logic value used in the specification may simply mean a binary logic state such as 1 or 0. For example, 1 refers to a high logic level and 0 refers to a low logic level. In one embodiment, a memory cell, such as a transistor or flash cell, may be capable of holding one logic value or multiple logic values. However, other representations of values in computer systems are also used. For example, the decimal number 10 is represented as 1010 in the binary value display, and is represented as A in the hexadecimal display. Thus, one value includes any display format of information held in the computer system.

  Furthermore, the state (state) may be represented by a value or a part of the value. For example, a first value, such as a logical value 1, may represent a default state or an initial state, and a second value, such as a logical value 0, may represent a non-default state. . In addition, the terms reset and set respectively refer to a default value or state and an updated value or state in some embodiments. For example, the default value may include a high logical value, ie reset, and the updated value may include a low logical value, ie set. Any combination of values may be used to represent any number of states.

  Embodiments of the above methods, hardware, software, firmware, code may be implemented using instructions or code stored on a machine-accessible or machine-readable medium and executable by a processing element. A machine-accessible / machine-readable medium includes any mechanism that provides (ie, stores and / or transmits) information in a form readable by a machine, such as a computer or electronic system. For example, tangible machine accessible media include random access memory (RAM) such as static RAM (SRAM) or dynamic RAM (DRAM), ROM, magnetic or optical storage media, flash memory devices, electrical storage devices , Optical storage devices, acoustic storage devices, or other forms of propagation signal (eg, carrier wave, infrared signal, digital signal) storage devices and the like.

  Embodiments of the methods, hardware, software, firmware or code described above may be performed by execution of a compiler stored on a machine-readable medium or as part of execution of code stored on a machine-readable medium compiled by a compiler. May be implemented. A compiler often includes a program or set of programs and translates source text / code into the desired text / code. Normally, when compiling program / application code using a compiler, high-level program language code is executed in a plurality of stages or paths for converting into low-level machine language code or assembly language. However, a simple pass compiler can be used for simple compilation. The compiler may use known compilation techniques to perform known compilation operations such as lexical analysis, preprocessing, parsing, semantic analysis, code generation, code conversion, and code optimization. In one embodiment, the compiler compiles and / or optimizes code that inserts operations, calls, functions, instructions, etc. to perform the method described above.

  Large compilers often include multiple stages, which are largely divided into two stages. (1) The front end, i.e., usually the stage where syntax processing, semantic processing and some transformation / optimization are performed, (2) The back end, i.e. usually the analysis, conversion, optimization and code generation are performed There are two stages to be performed. Some compilers are called middle ends, which is an example of obscuring the boundary between front end and back end compilers. References to inserts, associations, generations or other compiler operations are performed in any of the above stages or passes and other compiler stages or passes. In one embodiment, such a scenario occurs during static and / or entire program compilation. In another embodiment, during dynamic compilation, compiler code or dynamic optimization code inserts such operations / calls and optimizes the code for execution during runtime. In some scenarios, hardware or software such as a compiler program may perform dynamic profiling of program execution.

  In addition, the word “one embodiment” or “a certain embodiment” in this specification means that a specific feature, structure, and characteristic related to the embodiment are included in at least one of the embodiments of the present invention. Means. Thus, the phrases “in one embodiment” or “in an embodiment” as used in various places in the specification do not necessarily indicate the same embodiment. In one or more embodiments, specific configurations, structures, or features may be combined in any suitable manner.

In the foregoing specification, a detailed description has been given with reference to specific illustrated embodiments. However, it will be apparent that various modifications and changes may be made within the scope of the invention as set forth in the appended claims. Accordingly, the specification and accompanying drawings are to be regarded as illustrative rather than restrictive of the invention. Further, the words used in the above embodiment and other examples do not necessarily refer to the same embodiment or the same example, and may refer to different and different embodiments or the same embodiment. May point to.
[Item 1] An integrated circuit including an on-die logic analyzer (ODLA) for acquiring test / trace information related to the integrated circuit, and test / trace information related to the integrated circuit connected to the integrated circuit and acquired by ODLA. The memory used as a test / trace buffer to hold, one or more hardware test hooks providing test / trace information, and one or more hardware test hooks are abstracted to the software layer and the interface is the software layer And the test / trace information is stored in memory in an area obfuscated for one or more operating systems, and the interface provides services associated with one or more hardware test hooks. Equipment to provide.
[Item 2] The integrated circuit obtains test / trace information of the interface of the integrated circuit, and the memory is used as a test / trace information buffer for holding the test / trace information of the interface of the integrated circuit. The device described in 1.
[Item 3] The integrated circuit is connected to one or more control registers in the processor, and includes a processor having a verification control unit that sets one or more control registers to define a breakpoint. Item 3. The apparatus of item 1 or 2, wherein the test / trace information associated with the processor is obtained in response to the processor encountering a breakpoint when one or more control registers define the breakpoint.
[Item 4] The integrated circuit has signal state information of a test port that can access test / trace information related to the integrated circuit and a signal that transitions before the test port is enabled during the power-on sequence of the integrated circuit. 4. The apparatus according to any one of items 1 to 3, further comprising initial power-on signal logic for obtaining
[Item 5] The integrated circuit detects a power-on signal that transitions to indicate the power-on state of the integrated circuit, a count logic that starts counting in response to the transition of the power-on signal, and an edge transition of the target signal And a storage element that holds a signal identification value and a time stamp value of the target signal based on the count of the count logic when the edge detection logic detects an edge transition of the target signal. The apparatus according to any one of 1 to 4.
[Item 6] The integrated circuit is present in an active power state and a plurality of low power states, and the integrated circuit is responsive to a power cycle event associated with one of the plurality of low power states. 6. The apparatus according to any one of items 1 to 5, further comprising low power signal logic for obtaining signal state information of the signal.
[Item 7] The integrated circuit further includes a plurality of hardware design (hardware DFX) functions for testing, and a microcontroller that provides access to the plurality of hardware DFX functions. Then, any one of items 1 to 6 comprising code that provides the microcontroller with access to one or more application programming interface (API) services software associated with a plurality of hardware DFX functions. The device according to item.
[Item 8] A control unit that receives a request related to accessing a hardware test / trace function in an integrated circuit from an application, and security logic that determines an access level of the application among a plurality of access levels. In addition, if the application access level has access to the hardware test / trace function, the security logic allows the request from the application, and the application access level is to the hardware test / trace function. 8. The apparatus according to any one of items 1 to 7, wherein the security logic does not permit a request from an application when access is not allowed.
[Item 9] The device according to any one of Items 1 to 8, wherein the integrated circuit further includes an integrated circuit (IC) package having a signal pin on the lower surface and a test pin electrically coupled to the test probe on the upper surface. .
[Item 10] The integrated circuit is electrically coupled to an integrated circuit (IC) package having a signal pin on the lower surface and a test pin electrically coupled to the test probe on the upper surface, and a test pin on the upper surface of the tester and the IC package. 10. An apparatus according to any one of items 1 to 9, further comprising a mass production (HVM) connection mechanism having a fixed probe.
[Item 11] Any one of Items 1 to 10, further comprising an integrated circuit package and an integrated heat spreader (IHS) that is thermally coupled to the integrated circuit package and has a mounting ear protruding inconspicuously. The apparatus according to item 1.
[Item 12] Small foam having a cooling plate thermally coupled to the integrated circuit, a thermoelectric cooling array, a water cooler having microchannel cooling fins, and an inlet and an outlet provided in the center of the water cooler 12. The apparatus according to any one of items 1 to 11, further comprising a factor / thermal tool.
[Item 13] A target physical layer for implementing a hardware test / trace function in an integrated circuit, a transport layer for transferring information regardless of a transfer mechanism from an abstraction layer to a target physical layer, a target layer An abstraction layer that abstracts the physical layer and provides one or more application programming interfaces (APIs) to the application layer, and services associated with the target physical layer from the abstraction layer according to one or more API standards The integrated circuit includes an on-die logic analyzer (ODLA) that obtains test / trace information associated with the integrated circuit and a test associated with the integrated circuit that is coupled to the integrated circuit and obtained by the ODLA. / Memory used as test / trace buffer to hold trace information and test One or more hardware test hooks that provide trace information, and one or more hardware test hooks that abstract to the software layer and provide abstraction logic to provide an interface to the software layer / Trace information is stored in memory in an area obfuscated for one or more operating systems, and the interface provides a service associated with one or more hardware test hooks.
[Item 14] A plurality of integrated circuits, and a universal test access port that provides access to each of the verification controllers in each of the plurality of integrated circuits, each of the plurality of integrated circuits including a test / An on-die logic analyzer (ODLA) for obtaining trace information, a memory coupled to the integrated circuit and used as a test / trace buffer for holding test / trace information associated with the integrated circuit obtained by ODLA, and a test / One or more hardware test hooks providing trace information, abstract logic for abstracting the one or more hardware test hooks to the software layer and providing an interface to the software layer, and each of the plurality of integrated circuits Verification system that controls access to hardware test functions And a section, test / trace information is stored in the memory area that is obfuscated for one or more operating systems, the interface provides a service associated with one or more hardware test hook system.

Claims (14)

Multiple silicon components,
A verification control unit that provides and controls access to a design for test (DFx) function of silicon of the plurality of silicon components;
A client tier that interfaces with the user;
With
The verification control unit includes:
A target DFx layer including at least a plurality of hardware hooks;
A service layer including an abstraction layer that abstracts the details of the hardware DFx and provides at least one application programming interface (API) to the client layer ;
Having a system.   The system of claim 1, wherein the client layer includes an application layer.   The system according to claim 1, wherein the target DFx layer further includes a unit under test.   The system according to claim 1, wherein at least one API is used by the client layer for security and abstraction of low-level details. At least one of the API, the system according to any one of claims 1-4 to provide electrical verification (EV), the power supply, manageability, related services and data structures in the security or access. Wherein E V provides an abstraction of a complete set of algorithms used by the tool or software in the client layer, thereby according to claim 5, wherein the plurality of algorithms are provided in a secure manner system.   The system according to claim 1, wherein the client layer includes a presentation layer that performs at least one of correlation, visualization, and display of data, a protocol, and information of an underlying layer.   The system according to claim 1, wherein the verification control unit is a circuit.   The system according to claim 1, wherein the verification control unit is firmware.   The system of claim 1, further comprising a universal test access port that provides a plurality of platform test interfaces.   11. The system of claim 10, wherein the universal test access port has a bi-directional port that extracts debug information and communicates with the verification control unit. A method for accessing a design for test (DFx) function, comprising:
And performing programming abstraction layer using the application,
Providing a service from the abstraction layer;
Adapting communications from the abstraction layer to be transported;
Transporting the adapted form of the communication to a DFx unit under test that performs the operation requested by the abstraction layer;
Providing results from the DFx unit under test to the abstraction layer;
Displaying the result.   The method of claim 12, wherein the application is a third party vendor tool.   Micro breakpoints are programmed in the DFx unit under test, and traces acquired up to, at or after the microbreakpoint are traced by the DFx unit under test. 14. A method according to claim 12 or 13 provided.