Software backward compatibility testing in timing-disrupting modes

Abstract

To provide systems and methods for providing backward compatibility to applications / titles designed for older versions of computer systems.SOLUTION: A method includes: setting up a system to cause a device to run in a timing test mode; changing functionality of an OS to disrupt a timing of processing while an application is running in the timing test mode; and testing for errors while the device is running in the timing test mode.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] This application claims the benefit of priority to commonly assigned U.S. Non-Provisional Application No. 14 / 930,408, filed November 2, 2015, the entire contents of which are incorporated herein by reference.

[0002] Aspects of the present disclosure relate to running computer applications on a computer system, and in particular to a system or method for providing backward compatibility for applications / titles intended for older versions of a computer system. [Background technology]

[0003] Modern computer systems often use several different processors for different computing tasks. For example, in addition to several central processing units (CPUs), a current computer may have a graphics processing unit (GPU) dedicated to certain computational tasks in a graphics pipeline, or a unit dedicated to digital signal processing for audio, all of which are potentially part of an accelerated processing unit (APU), which may also contain other units. These processors are connected to various types of memory using buses, which may be internal to the APU or located externally on the computer's motherboard.

[0004] It is common for a set of applications to be written for a computer system such as a video game console or a smartphone (a "legacy device"), and when a variant or more advanced version of the computer system (a "new device") is released, it is desirable for the applications of the legacy device to run perfectly on the new device without recompilation or any modification to take into account the characteristics of the new device. This aspect of the new device, including its hardware architecture, firmware, and operating system, is often referred to as "backward compatibility."

[0005] Backward compatibility is often achieved through binary compatibility, where a new device can run programs written for a legacy device. On the other hand, when real-time operation of a category of device is critical to its operation, as in the case of a video game console or a smartphone, significant differences in the operating speed of the new device may prevent it from being backward compatible with the legacy device. If the new device is of lower performance than the legacy device, problems that prevent backward compatibility may arise. This is also true when the new device is of higher performance or has different performance characteristics when compared to the legacy device. Summary of the Invention [Problem to be solved by the invention]

[0006] It is within this context that aspects of the present disclosure arise. [Means for solving the problem]

[0007] The teachings of the present disclosure can be readily understood by considering the following detailed description in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a block diagram illustrating an example of a central processing unit (CPU) core that may be configured to operate in a backward compatibility mode, according to aspects of the present disclosure. [Figure 2] FIG. 2 is a block diagram illustrating an example of a possible multi-core architecture for a CPU, according to aspects of the present disclosure. [Figure 3] FIG. 1 is a block diagram of a device having a CPU configured to operate in backward compatibility mode, according to an aspect of the present disclosure. [Figure 4] FIG. 1 is a timing diagram illustrating the concept of "skew." [Figure 5]FIG. 10 is a flow diagram illustrating operation of a device in a timing test mode according to aspects of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0009] Introduction Even if the CPU of a new device is binary compatible with the legacy device (i.e., it can run programs written for the legacy device), differences in performance characteristics between the CPU of the new device and the CPU of the legacy device may cause errors in legacy applications, resulting in the new device not being backward compatible.

[0010] If the CPU of the new device has lower performance than the CPU of the legacy device, many errors in the legacy application can occur due to an inability to meet real-time deadlines imposed by display timing, audio stream-out, etc. If the CPU of the new device has substantially higher performance than the CPU of the legacy device, many errors in the legacy application can occur due to the untested consequences of such high-speed operation. For example, in a producer-consumer model, if the consumer of data (e.g., a CPU) operates faster than originally expected, the consumer may attempt to access the data before the data producer (e.g., some other component of the computer) makes it available. Alternatively, if the producer of data (e.g., a CPU) operates faster than originally expected, the producer may overwrite data that is still in use by the data consumer (e.g., some other component of the computer).

[0011] Furthermore, because the speed at which code is executed by a CPU depends on the characteristics of the particular code being executed, the performance gains of a CPU in a new device over a legacy device may depend on the particular code being executed. This can lead to problems with the producer-consumer model described above, where both the producer and consumer are CPUs, but they are running the code of the legacy application at relative speeds not encountered on the legacy hardware.

[0012] Embodiment Aspects of the present disclosure describe computer systems and methods that may enable applications written for a device to have a high degree of backward compatibility when running on a second device that is binary compatible (in that a program written for a first device executes on the second device) but has different timing characteristics (in that a program written for the first device executes at a different rate on the second device and therefore may experience errors during operation). The second device is potentially a variant or more advanced version of the first device and may potentially be configured in a "backward compatibility mode" in which the features and capabilities of the second device more closely resemble those of the first device.

[0013] In an embodiment of the present disclosure, a timing test mode is created for a first device. This mode creates timings that are not (or typically are not) found on the device, so that when an application runs in this mode, synchronization errors between hardware components (such as the CPU, GPU, audio and video hardware) or software components (such as application processing or OS processing) occur during normal operation in ways that are not possible or common on the device. Once these synchronization errors are detected, the application software is modified to eliminate or mitigate them, increasing the likelihood that the application will run properly on a second device with different timing characteristics. That is, the application will have a higher degree of backward compatibility on the second device relative to the first device. Because the capabilities of the second device may not be known (e.g., it may be a future device that does not yet exist), it is beneficial to have a greater diversity of timings available in the timing test mode.

[0014] In embodiments of the present disclosure, in timing test mode, the operating system may configure the hardware in a certain state (e.g., at a particular operating frequency not found in normal operation of the device). Furthermore, in timing test mode, the operating system may change the hardware configuration while an application is running, or may perform various operations while an application is running (e.g., processes that calculate system resources or preempt application operations).

[0015] In embodiments of the present disclosure, testing may be performed on hardware different from the device, for example, by using an IC selected to operate over a larger operating range than the consumer device, such that test modes are not available on the consumer device.

[0016] 1 shows a generalized architecture of a CPU core 100. The CPU core 100 typically includes a branch prediction unit 102 that attempts to predict whether a branch will be taken and, if taken, the branch's target address. To the extent that these predictions are accurate, the efficiency of speculatively executed code will increase; therefore, more accurate branch predictions are highly desirable. The branch prediction unit 102 may include highly specialized subunits, such as a return address stack 104 that tracks return addresses from subroutines, an indirect target array 106 that tracks the targets of indirect branches, and a branch target buffer 108 and its associated prediction logic that tracks the past history of branches to more accurately predict their resulting addresses.

[0017] CPU core 100 typically includes an instruction fetch and decode unit 110, which in turn includes an instruction fetch unit 112, an instruction byte buffer 114, and an instruction decode unit 116. CPU core 100 also typically includes several instruction-related caches and an instruction translation lookaside buffer (ITLB) 120. These may include an ITLB cache hierarchy 124 that caches virtual addresses to physical address translation information, such as page table entries and page directory entries. This information is used to translate the virtual addresses of instructions to physical addresses so that instruction fetch unit 112 can load instructions from the cache hierarchy. By way of example and not limitation, program instructions may be cached according to a cache hierarchy that includes a level 1 instruction cache (L1 I-cache) 122 residing within the core and other cache levels 176 external to CPU core 100. Using the physical address of the instruction, these caches are first searched for the program instruction. If the instructions are not found, they are loaded from system memory 101. In some architectures, there may also be a micro-op cache 126 containing decoded instructions, as described below.

[0018] Once program instructions are fetched, they are typically placed in an instruction byte buffer 114 to await processing by the instruction fetch and decode unit 110. Decoding can be a very complex process. Decoding multiple instructions each cycle is difficult, and there may be restrictions on instruction alignment or instruction type that limit the number of instructions that can be decoded in one cycle. Decoded instructions may be placed in the micro-op cache 126, depending on the architecture (if one exists on newer CPUs). Thus, the decode stage may be bypassed for later use of program instructions.

[0019] Decoded instructions are typically passed to other units for dispatch and scheduling 130. These units may use a retirement queue 132 to track the state of instructions throughout the remainder of the CPU pipeline. Additionally, due to the limited number of general-purpose and SIMD registers available in many CPU architectures, register renaming may be performed, in which physical registers 140 are allocated to represent logical (also called architectural) registers as they are encountered in the stream of instructions being executed. The physical registers 140 may include a single-instruction-multiple-data (SIMD) register bank 142 and a general-purpose (GP) register bank 144, which may be significantly larger in size than the number of logical registers available on a particular CPU architecture, which can result in significant performance improvements. After register renaming 134 is performed, instructions are typically placed in a scheduling queue 136, from which several instructions may be selected each cycle (based on dependencies) for execution by execution units 150.

[0020] Execution units 150 typically include SIMD pipes 152 that perform several parallel operations on multiple data fields contained in 128-bit or larger SIMD registers contained in SIMD register bank 142, arithmetic logic units (ALUs) 154 that perform several logical, arithmetic, and miscellaneous operations on GPRs contained in GP register bank 144, and address generation units (AGUs) 156 that calculate addresses where memory is to be stored or loaded. There may be multiple instances of each type of execution unit, and the instances may have different capabilities; for example, a particular SIMD pipe 152 may be capable of performing floating-point multiply operations but not floating-point add operations.

[0021] Stores and loads are typically buffered in a store queue 162 and a load queue 164, allowing many memory operations to be performed in parallel. To support memory operations, CPU core 100 usually includes several data-related caches and a data translation lookaside buffer (DTLB) 170. A DTLB cache hierarchy 172 caches virtual addresses to physical address translations, such as page table entries and page directory entries. This information is used to translate virtual addresses of memory operations to physical addresses so that data can be stored in or loaded from system memory. Data is typically cached in a level 1 data cache (L1 D-cache) 174 residing within the core, and in other cache levels 176 external to core 100.

[0022] According to certain aspects of the disclosure, a CPU may include multiple cores. By way of example and not limitation, FIG. 2 illustrates an example of a possible multi-core CPU 200 that may be used in conjunction with aspects of the present disclosure. Specifically, the architecture of the CPU 200 may include M clusters 201-1, ... 201-M, where M is an integer greater than 0. Each cluster may have N cores 202-1, 202-2, ... 202-N, where N is an integer greater than 1. Aspects of the present disclosure include embodiments in which different clusters have different numbers of cores. Each core may include one or more corresponding dedicated local caches (e.g., L1 instruction, L1 data, or L2 caches). Each of the local caches may be dedicated to a specific corresponding core, in the sense that it is not shared with any other core. Each cluster may also include a cluster-level cache 203-1, ... 203-M, which may be shared among cores in the corresponding cluster. In some embodiments, the cluster-level caches are not shared by cores associated with different caches. Additionally, CPU 200 may include one or more upper-level caches 204, which may be shared between clusters. To facilitate communication between cores within a cluster, clusters 201-1, ... 202-M may include corresponding local buses 205-1, ... 205-M coupled to each of the cores and to the cluster-level cache for the cluster. Similarly, to facilitate communication between clusters, CPU 200 may include one or more upper-level buses 206 coupled to clusters 201-1, ... 201-M and upper-level cache 204. In some implementations, upper-level bus 206 may also be coupled to other devices, such as a GPU, memory, or memory controller. In yet other implementations, upper-level bus 206 may be connected to a device-level bus that is connected to various devices in the system. In yet other implementations, upper-level bus 206 may couple clusters 201-1, ... 201-M to upper-level cache 204. The device-level bus 208 may couple the upper-level cache 204 to other devices, such as a GPU, memory, or a memory controller.By way of example and not limitation, an implementation having such a device level bus 208 may occur, for example, when the upper level cache 204 is an L3 for all CPU cores but not for GPU use.

[0023] In CPU 200, OS processing may occur primarily on a core or a subset of cores. Similarly, application-level processing may occur primarily on a particular core or subset of cores. Individual application threads may be designated by the application to run on a core or a subset of cores. Because caches and buses are shared, the speed of processing by a given application thread may vary depending on the processing occurring by other threads (e.g., application threads or OS threads) operating in the same cluster as the given application thread. Depending on the details of CPU 200, a core may be capable of executing only one thread at a time or may be capable of executing multiple threads simultaneously ("hyper-threading"). In the case of a hyper-threaded CPU, the application may also specify which threads can run simultaneously with which other threads. The performance of a thread is affected by the specific processing performed by any other threads running on the same core.

[0024] 3, there is shown an illustrative example of a device 300 configured to operate in accordance with aspects of the present disclosure. According to aspects of the present disclosure, the device 300 may be an embedded system, a mobile phone, a personal computer, a tablet computer, a portable gaming device, a workstation, a gaming console, or the like.

[0025] Device 300 generally includes a central processing unit (CPU) 320, which may include one or more CPU cores 323 of the type shown in FIG. 1 and described above. CPU 320 may include multiple such cores 323 and one or more caches 325, in a configuration similar to that shown for CPU 200 in FIG. 2. By way of example and not limitation, CPU 320 may be part of an accelerated processing unit (APU) 310 that includes CPU 320 and a graphics processing unit (GPU) 330 on a single chip. In alternative embodiments, CPU 320 and GPU 330 may be implemented as separate hardware components on separate chips. GPU 330 may also include two or more cores 332 and two or more caches 334, as well as (in some embodiments) one or more buses to facilitate communication between the cores and caches and other components of the system. The buses may include an internal bus 317 for APU 310 and an external data bus 390.

[0026] Device 300 may also include memory 340. Memory 340 may optionally include a main memory unit accessible to CPU 320 and GPU 330. CPU 320 and GPU 330 may each include one or more processor cores, e.g., a single core, two cores, four cores, eight cores, or more. CPU 320 and GPU 330 may be configured to access one or more memory units using external data bus 390; in some implementations, it may be useful for device 300 to include two or more different buses.

[0027] Memory 340 may include one or more memory units in the form of integrated circuits providing addressable memory, e.g., RAM, DRAM, etc. The memory may include executable instructions configured, when executed, to perform a method, such as the method of Figure 5, for determining to operate device 300 in a timing test mode when running an application originally written for execution on a legacy CPU. Additionally, memory 340 may include dedicated graphics memory for temporarily storing graphics resources, graphics buffers, and graphics data for a graphics rendering pipeline.

[0028] CPU 320 may be configured to execute CPU code, which may include an operating system (OS) 321 or an application 322 (e.g., a video game). The operating system may include a kernel that manages input / output (I / O) requests from software (e.g., application 322) and converts them into data processing instructions for CPU 320, GPU 330, or other components of device 300. OS 321 may also include firmware, which may be stored in non-volatile memory. OS 321 may be configured to implement certain features of operating CPU 320 in a timing test mode, as described in more detail below. CPU code may include a graphics application programming interface (API) 324 for issuing draw commands or draw calls to programs implemented by GPU 330 based on the state of application 322. CPU code may also implement physics simulation and other functions. Portions of the code for one or more of the OS 321 , application 322 , or API 324 may be stored in memory 340 , a cache internal or external to the CPU, or a mass storage device accessible to the CPU 320 .

[0029] Device 300 may include a memory controller 315. Memory controller 315 may be a digital circuit that manages the flow of data to and from memory 340. By way of example and not limitation, the memory controller may be an integral part of APU 310, such as the example shown in FIG. 3, or may be a separate hardware component.

[0030] Device 300 may also include well-known support functions 350, which may communicate with other components of the system, for example, via bus 390. Such support functions may include, but are not limited to, input / output (I / O) elements 352, one or more clocks 356, which may include separate clocks for each of CPU 320, GPU 330, and memory 340, and one or more levels of cache 358, which may be external to CPU 320 and GPU 330. Device 300 may optionally include a mass storage device 360, such as a disk drive, CD-ROM drive, flash memory, tape drive, or Blu-ray drive, for storing programs and / or data. In one example, mass storage device 360 ​​may accept computer-readable media 362 containing legacy applications originally designed to run on systems with legacy CPUs. Alternatively, legacy application 362 (or portions thereof) may be stored in memory 340 or partially in cache 358.

[0031] Device 300 may also include a display unit 380 for presenting rendered graphics 382 prepared by GPU 330 to a user. Device 300 may also include a user interface unit 370 for facilitating interaction between system 100 and a user. Display unit 380 may be in the form of a flat panel display, a cathode ray tube (CRT) screen, a touch screen, a head-mounted display (HMD), or other device capable of displaying text, numbers, graphical symbols, or images. Display 380 may display rendered graphics 382 processed according to various techniques described herein. User interface 370 may include one or more peripherals, such as a keyboard, a mouse, a joystick, a light pen, a game controller, a touch screen, and / or other devices that may be used in conjunction with a graphical user interface (GUI). In some implementations, the state of application 322 and the content underlying the graphics may be determined at least in part by user input through user interface 370, for example, when application 322 comprises a video game or other graphics-intensive application.

[0032] The device 300 may also include a network interface 372 to allow the device to communicate with other devices over a network. The network may be, for example, a local area network (LAN), a wide area network such as the Internet, a personal area network such as a Bluetooth® network, or other type of network. Various of the components shown and described may be implemented in hardware, software, or firmware, or some combination of two or more thereof.

[0033] Aspects of the present disclosure overcome backward compatibility problems that arise as a result of timing differences when running programs written for legacy systems on newer, more powerful or differently configured systems. By running device 300 in timing test mode, developers can determine how software written for a legacy system will perform when run on the newer system.

[0034] According to aspects of the present disclosure, device 300 may be configured to operate in a timing test mode. To understand the usefulness of such an operating mode, consider the timing diagram of FIG. 4. In FIG. 4, during application operation, different computing elements (e.g., CPU cores) A, B, C, and D may perform different tasks, indicated by parallelograms A1...A4, B1...B4, C1...C4, and D1...D4. Certain tasks need to generate data for consumption by other tasks, and the other tasks cannot begin work until the required data is generated. For example, assume that task A2 requires data generated by task A1, and task B2 requires data generated by tasks A1 and B1. To ensure proper operation, applications typically use semaphores or other synchronization strategies between tasks; for example, they should check that tasks A1 and B1 (which generate the source data required by task B2) have executed to completion before task B2 begins execution. Furthermore, assume that the timing shown in FIG. 4 represents the timing of these tasks as implemented on a legacy device. Timing may be different on a new device (e.g., one with more powerful processing capabilities on core B), resulting in task B1 finishing before task A1 produces data needed by task B2. Shifts in the relative timing of tasks on different processors are referred to herein as “skew.” Such skew can expose software errors in applications that only appear on new devices, or that appear with increased frequency on new devices. For example, if task A1 was guaranteed to finish before task B2 on a legacy device, the synchronization code that ensures task A1 finishes before task B2 may never be tested; if the synchronization code is implemented improperly, this may only become apparent when the application runs on the new device.For example, task B2 may begin execution before task A1 has produced data required by task B2, potentially leading to a fatal error in the application. Furthermore, similar problems can arise when an application written to run on a new device is run on a less capable legacy device. To address these issues, a device such as 300 may be operated in a timing test mode. In timing test mode, skew may be deliberately created, for example, between CPU threads, or between CPU 320 and GPU 330, or between processes running on GPU 330, or between any of these and the real-time clock. Testing in this mode may increase the likelihood that an application will run properly on future hardware.

[0035] According to aspects of the present disclosure, in timing test mode, the CPU cores are configured to operate at a different (higher or lower) frequency than for normal operation of the device, or OS 321 may constantly or occasionally modify the frequencies of the CPU cores. This may be done in a way that the CPU cores all operate at the same frequency relative to each other, or in a way that the CPU cores operate at different frequencies relative to each other, or in a way that some may operate at one frequency and others at another frequency.

[0036] By way of example and not limitation, if a legacy device has four cores that operate at 1 GHz in its typical operating mode on a consumer device, in timing test mode a core may be randomly selected to operate at 800 MHz for consecutive 10-second periods, causing the process running on the selected core to run slower, exposing possible errors in synchronization logic between that core and other cores when the other cores attempt to use data prepared by the selected core before the data is fully ready.

[0037] In aspects of the present disclosure, in timing test mode, the clock rates of caches not included in a CPU core may be configured to operate at a different (higher or lower) frequency than their normal operating frequency, or at a frequency different from the normal operating frequency of the CPU core. When there are multiple caches that may be configured in such a manner, they may be configured to operate at the same rate relative to each other, at different frequencies relative to each other, or some at one frequency and others at another frequency.

[0038] In aspects of the current disclosure, in timing test mode, CPU resources may be configured to be limited in a manner that impacts the execution timing of application code. Queues, such as store and load queues, retirement queues, and scheduling queues, may be configured to be reduced in size (e.g., the available portion of the resource may be limited). Caches, such as the L1 I-cache and D-cache, ITLB and DTLB cache hierarchies, and higher-level caches, may be reduced in size (e.g., the number of values ​​that can be stored in a fully associative cache may be reduced, or the available bank or way counts for caches with a limited number of ways may be reduced). The execution rate of all instructions or specific instructions operating on the ALU, AGU, or SIMD pipes may be reduced (e.g., increasing latency and / or decreasing throughput).

[0039] In aspects of the present disclosure, in timing test mode, the OS may temporarily preempt (pause) application threads. By way of example and not limitation, individual application threads may be preempted, or multiple threads may be preempted simultaneously, or all threads may be preempted simultaneously. Preemption timing may be random or systematic. The number and length of preemptions may be adjusted to increase the likelihood that real-time deadlines (such as for display timing or audio stream-out) can be met by the application.

[0040] In aspects of the present disclosure, in timing test mode, when the OS performs processing requested by an application (e.g., servicing an allocation, etc.) or when the OS performs processing independent of an application request (e.g., servicing a hardware interrupt), the time taken by the OS and the processor (e.g., CPU core) used by the OS may differ from the time taken and the CPU core used in the normal mode of operation of the device. By way of example and not limitation, the time taken by the OS to perform a memory allocation may increase, or the OS may service a hardware interrupt using a CPU core used exclusively by an application during normal operation of the device.

[0041] In aspects of the present disclosure, in timing test mode, application threads may be executed on CPU cores different from those specified by the application. By way of example and not limitation, in a system having two clusters (cluster "A" and cluster "B"), each having two cores, all threads designated for execution on core 0 of cluster A may instead be executed on core 0 of cluster B, and all threads designated for execution on core 0 of cluster B may instead be executed on core 0 of cluster A. As a result, the execution timing of thread processing may differ due to sharing the cluster upper level cache with different threads than during normal operation of the device.

[0042] In aspects of the current disclosure, in timing test mode, OS 321 may randomly or systematically write back or invalidate CPU caches or invalidate instruction and data TLBs. By way of example and not limitation, the OS may randomly invalidate and write back the cache hierarchy of all CPU cores, resulting in delays in thread execution during the invalidation and write back, and as threads request data normally found in the cache hierarchy, resulting in timing not encountered during normal operation of the device.

[0043] In aspects of the current disclosure, in timing test mode, the GPU and any GPU sub-units with separately configurable frequencies may be configured to operate at frequencies different from the normal operation of the device, or the OS may constantly or occasionally modify the frequency of the GPU and any of its separately configurable sub-units.

[0044] Additionally, other operations of one or more caches, such as the L1 I-cache and D-cache, ITLB and DTLB cache hierarchies, and higher-level caches, may be modified in a manner that disrupts timing in the timed test mode. One non-limiting example of such a change in cache operation modification is changing whether a particular cache is exclusive or inclusive. A cache that is inclusive in normal mode may be configured to be exclusive in the timed test mode, or vice versa.

[0045] Another non-limiting example of cache behavior modification involves cache lookup operations. In timing test mode, cache lookups may be performed differently than in normal mode. If the new hardware translates virtual addresses to physical addresses before cache lookups and the old hardware does not, memory accesses for some new processor hardware may actually be slowed down compared to the old hardware. For cache entries stored by physical addresses, the virtual address is always translated to a physical address (e.g., in L1 and L2) before performing a cache lookup, as is typically done for multi-core CPU cache 325. By always translating a virtual address to a physical address before performing any cache lookup, a core that writes to a particular memory location can inform other cores not to write to that location. In contrast, cache lookups for cache entries stored according to virtual addresses (e.g., GPU cache 334) may be performed without the need to translate the address. This is faster because address translation only needs to be performed in the case of a cache miss, i.e., if the entry is not in the cache and must be looked up in memory 340. For example, if older GPU hardware stores cache entries by virtual address and newer GPU hardware stores cache entries by physical address, the difference between the cache behavior can result in a delay of 5 to 1000 cycles in the newer hardware. To test application 322 for errors resulting from differences in cache lookup behavior, in a timing test mode, the caching and cache lookup behavior for one or more caches (e.g., GPU cache 334) may be changed from being based on virtual addresses to being based on physical addresses, or vice versa.

[0046] Yet another non-limiting example of behavior modification is disabling the prefetch function of an I-cache in timing test mode for one or more I-caches that have such a function enabled in normal mode.

[0047] In aspects of the present disclosure, in a timing test mode, the OS may replace GPU firmware, if present, with firmware that has different timing than normal operation of the device. By way of example and not limitation, in timing test mode, firmware may be replaced by firmware that has a higher overhead for each object processed, or by firmware that supports a lower count of objects that can be processed simultaneously, resulting in timings not encountered during normal operation of the device.

[0048] In aspects of the current disclosure, in timing test mode, GPU resources may be configured to be limited in a manner that impacts the timing of processing application requests. GPU cache 334 may be reduced in size (e.g., the number of values ​​that can be stored in a fully associative cache may be reduced, or the available bank count or way count may be reduced for a cache with a limited number of ways). The execution rate of all instructions or specific instructions running on GPU core 332 may be reduced (e.g., latency may be increased and / or throughput may be reduced).

[0049] In aspects of the current disclosure, in timing test mode, OS 321 may request GPU 330 to perform operations that reduce the remaining resources available to application 322 for its processing. These requests may be either random or systematic in their timing. By way of example and not limitation, OS 321 may request the rendering of higher priority graphical objects or compute shaders that may preempt lower priority application rendering or other computations. Or, OS 321 may request that its processing occur on specific GPU cores 332, thereby disproportionately impacting application processing designated to occur on those GPU cores.

[0050] In aspects of the current disclosure, in timing test mode, OS 321 may randomly or systematically request that GPU 330 write back or invalidate its caches or invalidate instruction and data TLBs.

[0051] According to aspects of the present disclosure, APU 310 may include an internal clock 316 for internal bus 317. Internal clock 316 operates at a particular clock rate or set of rates referred to herein as the "internal bus clock." Internal bus 317 connects to memory controller 315, which in turn connects to external memory 340. Communication from memory controller 315 to memory 340 may occur at another particular clock rate referred to herein as the "memory clock."

[0052] According to aspects of the present disclosure, when device 300 operates in timing test mode, the memory clock and / or internal bus clock may be configured to operate at a different (e.g., higher or lower) frequency than they operate at during normal operation of the device, or OS 321 may constantly or occasionally modify the frequency of the memory clock and / or internal bus clock.

[0053] In aspects of the present disclosure, in timing test mode, memory controller 315 may be configured to simulate contingencies to properly read data from external memory, increase the latency of certain types of memory accesses performed by the memory controller, or use priorities between various types of memory accesses that differ from the priorities used during normal operation of the device. OS 321 may constantly or occasionally modify these configurations in timing test mode.

[0054] According to aspects of the present disclosure, in a timing test mode, the memory controller 315 may be configured such that the address lines are altered, e.g., a signal normally placed on one address line may be swapped with a signal normally placed on another address line. By way of example and not limitation, if address line A is used to send column information to external memory 315 and address line B is used to send row information to external memory 340, and in timing test mode the signals sent on address lines A and B are swapped, the result will be timing that is very different from that found during normal operation of the device.

[0055] While configuring hardware and performing operations as described above (e.g., configuring CPU cores to operate at different frequencies) may expose errors in synchronization logic, if real-time operation of the device is critical, the timing test mode itself may introduce errors during operation, such as in the case of a video game console, due to a slow CPU core being unable to meet real-time deadlines imposed by display timing, audio stream-out, etc. According to aspects of the present disclosure, in the timing test mode, the device 300 may be operated at a higher than standard operating speed. By way of non-limiting example, higher than standard operating speed may be approximately 5% to approximately 30% faster than the standard operating speed. By way of example and not limitation, in the timing test mode, the CPU clock, CPU cache, GPU, internal buses, and memory may be set to frequencies higher than the device's standard operating frequency (or standard operating frequency range). Because mass-produced versions of device 300 may be configured in a way that precludes setting the clock at the standard operating frequency, specially designed hardware may need to be created, for example, using faster memory chips than the corresponding mass-produced device, or using part of a production run of a system-on-chip (SoC) that allows for faster-than-average operation, or using a higher-spec motherboard, power supply, and cooling system than those used on the mass-produced device.

[0056] By way of example and not limitation, if specially designed hardware enables faster CPU operation than a mass-produced device, and if the mass-produced device has four cores that operate at 1 GHz in its typical operating mode, then in a timing test mode on the specially designed hardware, three cores may be selected to operate at 1.2 GHz and the remaining cores may operate at 1 GHz for consecutive 10-second periods. As a result, processing running on the selected cores will run slower than the other cores, exposing possible errors in synchronization logic, but unlike the previous example where all cores operate at least as fast as they would on the mass-produced device, real-time deadlines (e.g., for display timing) can be met and the timing test mode itself will not be likely to cause errors during operation.

[0057] By way of example and not limitation, if specially designed hardware enables faster CPU operation than a mass-produced device, and the mass-produced device has four cores that operate at 1 GHz in its typical operating mode, then in a timing test mode on the specially designed hardware, all cores may be selected to operate at 1.2 GHz, and OS 321 may randomly write back and invalidate the CPU cache. If the slowdown due to cache write-backs and invalidations is less than the speedup due to the higher CPU frequency, real-time deadlines can be met, as described above, and the timing test mode itself is not likely to cause errors during operation. In other words, the timing test mode may induce skew through cache operations, and testing for synchronization errors can be performed without concern that overall device operation will be slower and therefore more error-prone.

[0058] There are several ways in which application errors can be revealed in timing test mode. According to one embodiment, specially designed hardware can include circuitry configured to determine the number of instructions per cycle (IPC) executed by device 300. OS 321 can monitor changes in IPC to test for errors in the application. The OS can correlate significant variations in IPC to specific modifications to the device's operation in timing test mode.

[0059] According to aspects of the present disclosure, a computing device may operate in a timing test mode. By way of example and not limitation, a computing system such as device 300 may have an operating system, such as operating system 321, configured to implement such a timing test mode in a manner similar to method 500 shown in FIG. 5 and described below.

[0060] The method begins as shown at 501. At 510, it is determined whether the system is to operate in a timing test mode. There are several ways this can be done. By way of example and not limitation, the operating system 321 may prompt the user via a rendered graphic 382 on the display 380 to determine whether to enter the timing test mode. The user may input appropriate instructions via the user interface 370. If it is determined that the system should not operate in the timing test mode, the system may operate in a normal state as shown at 520. If it is determined that the system should operate in the timing test mode, the device may be configured to operate in the timing test mode as shown at 530. Setting up a device to operate in the timing test mode may generally involve the operating system (e.g., OS 321) for the device setting up hardware states, loading firmware, and performing other operations to implement the timing test mode-specific settings.

[0061] The device 300 may be configured to operate in timing test mode in any of a number of possible ways. By way of example and not limitation, in some embodiments, the device may be configured externally, for example, via a network (e.g., a local area network (LAN)). In another non-limiting example, the device may be configured internally through the use of menus generated by an operating system and input from a user interface. In another non-limiting example, the device may be set up to operate in timing test mode through physical configuration of the device hardware, for example, by manually setting the position of one or more dual-in-line package (DIP) switches on the device. The device firmware (e.g., stored in ROM) may then read the DIP switch settings, for example, when the device is powered on. This latter embodiment may be useful, for example, in cases where the device is specially designed hardware rather than a mass-produced version of the device. In such cases, the switches may be conveniently located on the outside of the box or case containing the device hardware.

[0062] Once the device is configured to operate in the timing test mode, the device may run applications in the timing test mode, as shown at 540. There are several ways in which the operation of the system in the timing test mode may differ from normal device operation.

[0063] By way of example and not limitation, while application 322 is running, OS 321 may do one or more of the following while running the application in a timing test: o Modify hardware settings in real time as shown at 542. o Send commands to various hardware components of device 300 in a manner that disrupts timing, as shown at 544. o Run a program that interferes with the application 322, for example, by taking resources away from the application, pausing the application, or competing for resources with the application, as shown at 546. o Change the functionality of OS321 in timing test mode, as shown at 548, to interrupt timing.

[0064] As shown at 550, once the application 322 is running in timing test mode on the device 300, the application may be tested for errors. Such testing may include, but is not limited to, determining whether the application has stalled, encountered an error, or produced unusual results (e.g., significant IPC fluctuations) that do not occur when the device is operating normally.

[0065] As an example of modifying the settings at 542, in a processor architecture of the type shown in Figure 2, two or more CPU cores may operate at different frequencies, which may be higher than the normal operating frequency of the consumer device. Similarly, two or more caches within the device may operate at different frequencies in a timing test mode. Furthermore, different combinations of cores and caches may operate at different frequencies.

[0066] In other embodiments, CPU resources may be reduced when the device operates in timing test mode. Examples of such CPU resource reduction include, but are not limited to, reducing the size of a store queue, load queue, or cache (e.g., L1 or above, I-cache, D-cache, ITLB, or DTLB). Other examples include, but are not limited to, reducing the execution rate of an ALU, AGU, SIMD pipe, or specific instructions. Furthermore, one or more individual cores or application threads may be randomly or systematically preempted. Additional examples include slowing, accelerating, or changing timing when using OS functionality, changing core usage by the OS, changing virtual core allocation to physical core allocation (e.g., inter-cluster contention), exploiting other asymmetries, or writing back or invalidating caches and / or TLBs.

[0067] In other embodiments, modifying the settings at 542 may include changing the functionality of the GPU 330. Examples of such changes include operating the GPU cores 332 at a different frequency, operating one or more of the GPU cores at a different frequency than normal for a consumer device, or replacing the GPU firmware with firmware having different timing than normal operation of the device 300. One or more of the GPU cores 332 may be configured to selectively operate at a higher or lower frequency than that used for the device's normal operating mode. Other examples include suspending the GPU firmware (e.g., suspending object processing) and reducing reduced GPU resources such as cache size or execution rate.

[0068] In other embodiments, when the device is operating in timing test mode, GPU processing may be altered, for example, by altering the wavefront count via a random computation thread, randomly prefetching graphics, or writing back or invalidating caches and / or TLBs.

[0069] An example of sending a command to a hardware component in a manner that disrupts timing at 544 includes modifying the functionality of memory 340 or memory controller 315. Examples of such modifications of memory or memory controller functionality include, but are not limited to, running the memory clock and / or internal bus clock at different frequencies to simulate various channel counts or row breaks, injecting noise into memory operations, adding latency to memory operations, changing the priority of memory operations, and modifying row and / or column channel bits.

[0070] Aspects of the present disclosure allow software developers to test the performance of new applications on previous versions of devices. More specifically, aspects of the present disclosure allow developers to explore the effects of timing interruptions on their applications.

[0071] While the above is a complete description of preferred embodiments of the present invention, various alternatives, modifications, and equivalents are possible. Accordingly, the scope of the present invention should be determined without reference to the above description, but should instead be determined with reference to the appended claims, along with their full scope of equivalents. Any feature described herein, whether preferred or not, may be combined with any other feature described herein, whether preferred or not. In the following claims, the indefinite article "A" or "An" refers to one or more quantities of the item following the article, unless expressly stated otherwise. As used herein, in a list of elements in alternatives, the term "or" is used in an inclusive sense, e.g., "X or Y" includes X alone, Y alone, or both X and Y, unless expressly stated otherwise. Two or more elements listed as alternatives may be combined with each other. The appended claims should not be construed as including means-plus-function limitations unless such limitations are expressly recited in a given claim using the phrase "means for."

Claims

1. one or more processors; a memory storing instructions corresponding to an operating system (OS) configured to operate on at least a subset of the one or more processors, the OS being configured to selectively operate in a normal mode or a timing test mode, wherein in the timing test mode, while running an application on the one or more processors, the device is configured to shift execution timing of operations occurring on the one or more processors to test the application for errors in synchronization of device hardware components, or to test the application for errors in synchronization of software components, or to test the application for errors in synchronization of both device hardware and software components, the one or more processors including one or more central processing unit (CPU) cores, and wherein in the timing test mode, the OS configures the subset of the one or more CPU cores to operate at one or more frequencies that are higher than standard operating frequencies of the one or more CPU cores in the normal mode.

2. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes operating the one or more processors at a frequency different from a normal operating frequency.

3. The device of claim 2 , wherein the OS modifies a frequency of the one or more processors.

4. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes changing cache operations of the one or more processors and cache lookup operations of the one or more processors from being based on virtual addresses to being based on physical addresses.

5. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes changing cache operations of the one or more processors and cache lookup operations of the one or more processors from being based on physical addresses to being based on virtual addresses.

6. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes the OS replacing firmware of at least one of the one or more processors with firmware having a higher overhead for each object processed.

7. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes the OS replacing firmware of at least one of the one or more processors with firmware that can process a smaller number of objects simultaneously than normal firmware.

8. 10. The device of claim 1, wherein shifting execution timing of processing performed on the one or more processors while running an application on the one or more processors includes reducing a size of an available cache.

9. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors comprises reducing an execution rate of all instructions or specific instructions running on the one or more processors.

10. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes the OS requesting at least one of the one or more processors to perform other processing tasks that reduce remaining resources available for the application.

11. The device of claim 10 , wherein the OS randomly requests at least one of the one or more processors to perform the processing task while running the application.

12. 11. The device of claim 10, wherein the OS requests at least one of the one or more processors to render graphical objects or execute shaders at a higher priority than the application while running the application.

13. The device of claim 10 , wherein the OS requests a central processing unit (CPU) or a graphics processing unit (GPU) to process the application on a particular core.

14. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes the OS requesting at least one of the one or more processors to write back or invalidate a cache.

15. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes the OS requesting at least one of the one or more processors to write back or invalidate an instruction translation lookaside buffer (ITLB).

16. 2. The device of claim 1, wherein shifting the execution timing of processing performed on the one or more processors while running an application on the one or more processors includes the OS requesting at least one of the one or more processors to write back or invalidate a data translation lookaside buffer (DTLB).

17. 1. A device comprising one or more processors and a memory that stores instructions executed by said one or more processors, the instructions are configured to selectively operate in a normal mode or a timing test mode, and in the timing test mode, while running an application on the one or more processors, the device is configured to shift the execution timing of operations performed on the one or more processors to test the application for errors in synchronization of device hardware components, or to test the application for errors in synchronization of software components, or to test the application for errors in synchronization of both device hardware and software components, the one or more processors including one or more central processing unit (CPU) cores, and in the timing test mode, a subset of the one or more CPU cores is configured to operate at one or more frequencies higher than a standard operating frequency of the one or more CPU cores in the normal mode.

18. A non-transitory computer-readable medium having computer-readable executable instructions configured to cause a device having one or more processors to perform a method upon execution of the instructions, the method comprising: operating the device in a timing test mode, wherein in the timing test mode the device is configured to shift execution timing of operations performed on the one or more processors while running an application on the one or more processors; testing the application for errors in synchronization of device hardware components, or testing the application for errors in synchronization of software components, or testing the application for errors in synchronization of both device hardware and software components, wherein the one or more processors include one or more central processing unit (CPU) cores, and wherein in the timing test mode a subset of the one or more CPU cores is configured to operate at one or more frequencies that are higher than a standard operating frequency of the one or more CPU cores in a normal mode.

Images