Patent Publication Number: US-2003229740-A1

Title: Accessing resources in a microprocessor having resources of varying scope

Description:
BACKGROUND  
       [0001] 1. Field of the Invention  
       [0002] The present invention relates to integrated circuit design and, more particularly, to the design of multi-thread and/or multi-core microprocessors.  
       [0003] 2. Related Art  
       [0004] Computer processors historically have been limited to executing a single instruction stream—referred to as a “thread”—at a time. Execution of multiple threads simultaneously in hardware has typically required the use of multiple processors configured in a multi-processing (MP) architecture. It typically has been necessary for operating systems and other software to be specially programmed to take advantage of the performance gains made possible by multi-processing.  
       [0005] Recently, processor architectures have been developed which enable a single processor to execute multiple threads concurrently (referred to herein as “hardware multi-threading”). For example, Intel Corporation&#39;s Hyper-Threading technology allows a single processor to execute multiple threads concurrently, thereby acting as if it were two physical processors. Processors enabled with Hyper-Threading technology can manage incoming instructions from different software applications and continuously switch from one set of instructions to the other, every few nanoseconds, without losing track of the state of each set of instructions. Hyper-Threading Technology complements symmetric multi-processing (SMP) by allowing more threads to execute simultaneously per processor. Hyper-Threading technology is implemented, for example, in Intel&#39;s Xeon™ line of server processors.  
       [0006] More specifically, a processor based on Hyper-Threading technology implements two architectural states on a single processor core. Although each of the two logical processors has a distinct architectural state, they both share the processor core&#39;s single set of execution resources. The two logical processors may execute distinct threads concurrently. The architectural state that is duplicated for each logical processor includes data registers, segment registers, control registers, debug registers, Advanced Programmable Interrupt Controller (APIC) registers, and some machine-specific registers (MSRS). The execution resources shared by the logical processors include the execution engine, the caches, the system bus interface, and the firmware. After power-up and initialization, each logical processor may be individually halted, interrupted, or directed to execute a specific thread, independently of the other logical processor on the chip.  
       [0007] A single processor implementing Hyper-Threading technology will appear to operating systems and other software as if it were two distinct physical processors. Operating systems and other software may therefore interact with (e.g., schedule threads on) the two logical processors in the same way that they interact with physical processors in conventional multi-processing systems. Software that is already designed to run on a conventional multi-processing system may therefore run unmodified on a Hyper-Threading platform. In such a platform, the threads that would be dispatched to two or more physical processors in a conventional multi-processing system are dispatched to the two logical processors. Because two threads executing in two logical processors on a single physical processor share one set of execution resources, one thread may use execution resources that would otherwise be idle if only one thread were executing on the physical processor. The result is an increased utilization of the execution resources within each physical processor. Modern operating systems (such as Microsoft Windows® and Linux®) and other high-performance software which is already optimized for multi-threading and multi-processing environments may especially benefit from technologies such as Hyper-Threading.  
       [0008] Similarly, multi-core processors include multiple processor cores in a single chip package. A multi-core processor acts as if it were multiple processors. Each of the multiple processor cores may essentially operate independently, while sharing certain common resources, such as a cache. Multi-core processors therefore provide additional opportunities for increased processing efficiency. A single processor chip may include multiple cores, each of which may provide hardware multi-threading.  
       [0009] Various electronic design automation (EDA) software tools exist for designing microprocessors and other circuitry. Such tools allow circuit designers to create and modify virtual models of the circuit being designed. A circuit designer may, for example, specify a circuit design using a textual description written in a hardware description language (HDL), such as Verilog or VHDL, or by using a graphical user interface to manipulate a graphical representation of the circuit design.  
       [0010] Software tools are also used frequently for testing circuit designs. Circuit testing tools typically simulate the operation of the circuit design; the portion of the testing tool that performs this simulation is therefore called a “simulator.” To test a microprocessor design, for example, the circuit designer typically creates one or more “test cases.” A test case typically specifies a set of initial values for machine resources (such as registers, caches, and main memory) and a set of test microprocessor instructions for the simulator to execute. The test case may also include the outputs that are expected to result from performing the test instructions based on the initial values.  
       [0011] A software program called an “initializer” reads the test case and modifies the initial state of the simulated processor design to reflect the initial state values specified by the test case. Once the processor design is initialized, the simulator simulates the execution of the instructions specified by the test case and verifies that the expected output is produced as a result. A significant advantage of using such simulators for testing is that they may detect errors prior to the costly and time-consuming fabrication of the circuit itself.  
       [0012] In a multi-core and/or multi-thread architecture, certain resources—such as registers, caches, and main memory—may be shared by multiple cores and/or multiple threads. The “scope” of a resource refers to the extent to which the resource is shared among cores and/or threads. For example, a particular machine-specific register (MSR) may be shared (available for use) by all processor cores on a chip (and by all threads within all of the cores). Such a resource is therefore said to have a “chip-wide” or “chip-specific” scope. An MSR may also be specific to (i.e., only available for use by) a particular one of the processor cores (including all of the threads in that core). Such an MSR is said to have a “core-wide” or “core-specific” scope. Similarly, an MSR may be specific to (i.e., only available for use by) a particular thread in a particular one of the processor cores. Such an MSR is said to have a “thread-wide” or “thread-specific” scope. Different resources within the same processor may have different scopes. This is referred to herein as a “mixed-scope machine resource” environment.  
       [0013] Computer resources are typically referred to by resource identifiers. A test case, for example, typically specifies initial values for machine resources by providing, for each resource, a resource identifier and an initial value for the resource. The identifier may, for example, be a label or other resource identifier, such as a register number in the case of a register or a memory address in the case of a memory location.  
       [0014] In a single-core, single-thread architecture, a single resource identifier (such as a register number) uniquely refers to a single resource. In a multi-core and/or multi-thread architecture, however, it may be necessary to use a combination of a core identifier, thread identifier, and resource identifier (e.g., register number) to uniquely identify a particular resource (e.g., register) within a particular core and thread.  
       [0015] When a test case refers to a resource, such as an MSR, the test case may “under-specify” the resource. For example, the test case may refer to an MSR using only a core number, rather than using a combination of core number, thread number, and MSR number. Such a reference may be ambiguous, because it may not be clear whether the reference is intended to refer to a core-specific MSR (and hence to that MSR in all threads) or to an MSR in a particular thread in that core. Conversely, a test case reference may “over-specify” a resource, such as by specifying a combination of core number, thread number, and MSR number even though no thread-specific MSR matching the reference exists. In both of these cases it is necessary for tools such as initializers and simulators to interpret the test case reference so that appropriate resource values may be initialized for the simulator. Existing tools do not provide automated techniques for performing such interpretation.  
       [0016] What is needed, therefore, are improved techniques for interpreting references to computer resources in mixed-scope computer architectures.  
       SUMMARY  
       [0017] A system is disclosed which includes a microprocessor design having a plurality of representations of machine resources of varying scope. The microprocessor design may, for example, have multiple cores and/or be capable of executing multiple threads in hardware. Machine resource representations in the microprocessor design may be limited in scope to a particular thread in a particular core, be shared by multiple threads within a core, or be shared by all threads in all cores. A software routine is provided which allows machine resource representations of varying scopes to be referenced with a fixed number of parameters. When the routine is called with a particular set of parameters, the resource scope referenced by the parameters is determined, and any machine resource representations that are referenced by the parameters are identified. A value may be read from or A written to the machine resource representation.  
       [0018] For example, in one aspect, a method is provided for use in a system including a plurality of representations of machine resources in a microprocessor design, such as a multi-core and/or multi-thread microprocessor design. The plurality of machine resource representations have a plurality of scopes. The method includes steps of: (A) identifying a scope specified by a machine resource reference; (B) identifying a scope of one of the plurality of machine resource representations; (C) determining whether the scope specified by the machine resource reference is the same as the scope of the identified machine resource representation; and (D) assigning to the identified machine resource representation a value specified by the machine resource reference if the scope specified by the machine resource reference is determined to be the same as the scope of the identified machine resource representation.  
       [0019] The machine resource reference may include a value of a first parameter which specifies, for example, a thread or a core in the microprocessor design. The step (A) may include a step of determining whether the first parameter value is a NULL value. If the first parameter value is determined to be a NULL value, the method may identify the scope specified by the machine resource reference as a first scope; otherwise, the method may identify the scope specified by the machine resource reference as a second scope which is broader than the first scope. For example, if the first parameter is a “thread” parameter and the first parameter value specifies a particular thread in the microprocessor design, the method may identify the machine resource reference&#39;s scope as a thread-specified scope. If the first parameter value is a NULL value, the method may identify the machine resource reference&#39;s scope as a core-specific scope or a chip-specific scope.  
       [0020] The machine resource reference may include a value of a second parameter which specifies, for example, a core in the microprocessor design. The method may use techniques similar to those described above to identify the scope of the machine resource as a core-specific scope or a chip-specific scope.  
       [0021] The method may further include steps of: (E) determining whether the scope specified by the machine resource reference is broader than the scope of the identified machine resource representation; and (F) assigning to the identified machine resource representation the value specified by the machine resource reference if the scope specified by the machine resource reference is determined to be broader than the scope of the identified machine resource representation.  
       [0022] Alternatively or additionally, the method may further include steps of: (E) determining whether the scope specified by the machine resource reference is narrower than the scope of the select one of the plurality of machine resource representations; and (F) signaling an error if the first scope is determined to be narrower than the second scope. Other features and advantages of various aspects and embodiments of the present invention will become apparent from the following description and from the claims. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0023]FIG. 1 is a data flow diagram of a system for initializing and testing a simulated microprocessor design according to one embodiment of the present invention;  
     [0024]FIG. 2 is a diagram of a machine resource database according to one embodiment of the present invention;  
     [0025]FIG. 3 is a block diagram of a test case according to one embodiment of the present invention;  
     [0026]FIG. 4A is a flow chart of a method performed by an initializer for resolving the machine resource scopes specified by a test case and for initializing machine resource values according to one embodiment of the present invention;  
     [0027]FIG. 4B is a flow chart of a method for assigning a value to a machine resource according to one embodiment of the present invention;  
     [0028]FIG. 4C is a flow chart of a method for ascertaining the machine resource scope specified by a machine resource reference according to one embodiment of the present invention; and  
     [0029]FIG. 5 is a block diagram of simulator input according to one embodiment of the present invention.  
    
    
     DETAILED DESCRIPTION  
     [0030] Referring to FIG. 1, a system  100  is illustrated for initializing and testing a simulated microprocessor design  110  according to one embodiment of the present invention. The microprocessor design  110 , also referred to as a hardware model under test or design under test (DUT), is a software (simulated) model of a microprocessor. The microprocessor design  110  models both the operation of the microprocessor (e.g., the functional relationship between inputs and outputs of the microprocessor) and the state of the microprocessor&#39;s machine resources, such as its registers, cache(s), and main memory, at a particular point in time. The term “machine resource representation” refers herein to models of particular machine resources contained within the microprocessor design  110 .  
     [0031] The microprocessor design  110  may have a multi-core and/or multi-thread microprocessor architecture, in which case the microprocessor design  110  models the state of each core and/or thread in the architecture. The microprocessor design  110  may be implemented, for example, in a data structure in the memory of a computer or in a file stored on a hard disk or other computer-readable medium.  
     [0032] The system  100  also includes a resource database  104 , which both defines the scope of each of the microprocessor design&#39;s machine resources and provides default values for each such resource. An example of the contents of the resource database  104  are described in more detail below with respect to FIG. 2.  
     [0033] The system  100  includes a test case  102 , which includes test vectors that specify both initial values for the (simulated) machine resources of the microprocessor design  110  and test instructions to be executed (in simulation) by the microprocessor design  110 . The test case  102  may, for example, be implemented in a file stored on a computer-readable medium or as a data structure in the memory of a computer. Examples of initial machine resource values provided by the test case  102  are described in more detail below with respect to FIG. 3.  
     [0034] The system  100  also includes an initializer  106  and a simulator  112 , both of which may be implemented as software programs written in any appropriate programming language, such as the C programming language. The initializer  106  initializes the state of the microprocessor design  110  based on the initial machine resource values provided in the test case  102  and the machine resource definitions provided in the resource database  104 . In one embodiment, for example, the initializer  106  receives the test case  102  and the resource database  104  as inputs and produces simulator input  108  as an output. The simulator input  108  specifies the initial values of the microprocessor&#39;s machine resources, the test instructions to be executed, and the expected output produced by executing such instructions, in a format suitable for input to the simulator  112 .  
     [0035] The simulator  112 , in conjunction with the microprocessor design  110 , provides an independent architectural reference model of the microprocessor. The simulator  112  receives the simulator input  108  and initializes the (simulated) machine resources of the microprocessor design  110  with the initial values specified in the simulator input  108 .  
     [0036] Once the microprocessor design  110  has been initialized (whether by the initializer  106  or the simulator  112 ), the simulator  112  simulates execution of the instructions specified in the simulator input  108  on the microprocessor design  110 . The simulator  112  modifies the state of the microprocessor design  110  accordingly as the simulation progresses. The simulator  112  produces test case results  114  which indicate, for example, whether the output produced by executing the test instructions matches the expected output specified by the simulator input  108 .  
     [0037] Operation of the system  100  will be described in more detail with respect to particular embodiments of the various elements of the system  100 . For example, referring to FIG. 2, one embodiment of the resource database  104  is illustrated. The resource database  104  is illustrated in the form of a table having columns  202   a - g  and rows  204   a - l.  In practice, the resource database  104  may be implemented in any of a variety of forms, such as a table generated by word processing or spreadsheet software, a header file or other source code file written in a programming language such as C, or a database file.  
     [0038] For purposes of example, the table illustrated in FIG. 2 defines properties of some of the machine-specific registers (MSRs) in the microprocessor design  110 . In particular, each of the rows  204   a - l  defines a particular MSR (or sub-part thereof) and will therefore be referred to herein as an “MSR definition” or, more generally, as a “machine resource definition.” The machine resource definitions  204   a - l  are examples of machine resource representations, as that term is used herein.  
     [0039] In practice, the resource database  104  will typically define properties of all of the machine resources in the microprocessor design  110 , such as the cache(s) and main memory. The techniques described herein with respect to the embodiment illustrated in FIG. 2 may therefore be applied similarly to any other kind of machine resource. Only a small number of MSR definitions are illustrated in FIG. 2 for ease of illustration and explanation. Furthermore, the particular values illustrated in FIG. 2 are chosen for illustrative purposes only.  
     [0040] Each of columns  202   a - g  represents a particular field in the machine resource definitions  204   a - l.  Columns  202   a - g  will therefore also be refereed to herein as “fields.” Scope field  202   a  indicates the corresponding MSR&#39;s scope. Values for the scope field  202   a  include CHIP (indicating chip-wide scope), CORE (indicating core-wide scope), and THREAD (indicating thread-wide scope).  
     [0041] Core field  202   b  indicates the specific core (if any) with which the corresponding MSR is associated. Thread column  202   c  indicates the specific thread (if any) with which the corresponding MSR is associated. The value of the core field  202   b  may either be a core number, indicating the core with which the corresponding MSR is associated, or the value NULL if the MSR is not associated with any single core. Similarly, the value of the thread field  202   c  may either be a thread number, indicating the thread with which the corresponding MSR is associated, or the value NULL if the MSR is not associated with any particular thread.  
     [0042] As described in more detail below, the value of an MSR definition&#39;s thread field  202   c  is NULL if the MSR has core-wide or chip-wide scope, and the value of an MSR definition&#39;s core field  202   b  is NULL if the MSR has chip-wide scope. The value NULL may be represented by any value, such as −1, which does not represent a valid core and/or thread number.  
     [0043] Index column  202   d  indicates the index (i.e., register) number of the corresponding MSR. A single MSR may be subdivided into multiple parts (referred to herein as “subparts”) of varying bit lengths, each of which may have a distinct scope. A particular MSR sub-part may be identified by a combination of its index number and an offset (in bits) within the register specified by the index number. Each of the machine resource definitions  204   a - l  may, therefore, definition a particular sub-part of an MSR rather than an entire MSR.  
     [0044] Offset column  202   e  indicates the offset (in bits) of the corresponding MSR sub-part within the MSR specified by the index column  202   d.  Note that the division of MSRs into subparts, and the consequent use of offsets, is provided herein merely for purposes of example and is not a limitation of the present invention.  
     [0045] Number of bits column  202   f  indicates the number of bits in the corresponding MSR (or sub-part). Default value column  202   g  which indicates a default value for the corresponding MSR (or sub-part). For purposes of example, default values of zero are shown for all of the machine resource definitions  204   a - l  in FIG. 2.  
     [0046] Although the description herein may refer to “core numbers,” “thread numbers,” “index numbers,” and “offset numbers,” these and other numbers that may be used to identify machine resources may more generally be considered to be resource identifiers, which may be numeric or non-numeric. Machine resources may, for example, be referred to by textual labels in any combination of the test case  102 , the resource database  104 , and the simulator input  108 .  
     [0047] The resource database  104  will now be described in more detail with respect to representative examples of the machine resource definitions  204   a - l.  Consider, for example, machine resource definition  204   a,  which may correspond to a particular MSR in the microprocessor design  110 . Scope field  202   a  of row  204   a  defines the scope of this MSR as “CORE,” indicating that the MSR has core-wide scope. The fact that the MSR defined by machine resource definition  204   a  has core-wide scope indicates that it is shared by all threads in its core (i.e., the core specified in core field  202   b ).  
     [0048] Core field  202   b  of row  204   a  specifies that the core number of the corresponding MSR is zero. The MSR is therefore specific to core zero. In the present example, assume that the microprocessor design  110  includes two cores, numbered 0 and 1. Thread field  202   c  of row  204   a  specifies that the thread number of the corresponding MSR is NULL. The value of the thread field  202   c  of definition  204   a  is NULL because the corresponding MSR has core-wide scope and is therefore not specific to any particular thread.  
     [0049] The value of the index field  202   d  of definition  204   a  is zero. In the present example, the value of the index field  202   d  specifies the register number of the corresponding MSR. MSRs and other registers are typically numbered sequentially beginning with zero. Therefore, definition  204   a  corresponds to an MSR having core-wide scope (column  202   a ) within core zero (column  202   b ) and having MSR number zero (column  202   d ).  
     [0050] Offset field  202   e  indicates that the corresponding MSR sub-part begins at bit zero of its MSR. Column  202   f  indicates that the MSR sub-part defined by definition  204   a  is 8 bits long. This MSR sub-part therefore occupies bits 0-7 of the corresponding MSR. Default value column  202   g  indicates that the default value of the MSR (sub-part) defined by definition  204   a  is zero.  
     [0051] Now consider the MSR sub-part defined by definition  204   b.  This MSR sub-part also has core-wide scope (column  202   a ) within core zero (column  202   b ). This MSR sub-part, however, is 24 bits long (column  202   f ), beginning at bit 8 (column  202   e ) of the MSR having index number zero (column  202   d ). This MSR sub-part therefore, occupies bits 8-31 of the corresponding MSR.  
     [0052] The next two definitions  204   c - d  also correspond to MSR sub-parts having core-wide scope (column  202   a ) within core number zero (column  202   b ), except that one of the MSR sub-parts (definition  204   c ) has an MSR number (column  202   d ) of one, while the other (definition  204   d ) has an MSR number (column  202   d ) of two. Definitions  204   e - f  define MSR sub-parts having core-wide scope (column  202   a ) within core number one (column  202   d ).  
     [0053] Definitions  204   g - i  define MSR sub-parts having thread-wide scope (column  202   a ). In other words, each of these MSR sub-parts is only available for use by a particular thread within a particular core of the microprocessor design  110 . For example, definition  204   g  defines an MSR sub-part having MSR number three (column  202   d ) that is specific to thread number zero (column  202   c ) within core number zero (column  202   b ). The properties of the MSR sub-parts defined by definitions  204   h - i  should be apparent from inspection of FIG. 2 based on the explanation provided above.  
     [0054] Finally, definitions  204   j - l  define MSR sub-parts having chip-wide scope (column  202   a ). In other words, each of these MSR sub-parts is available for use by all threads in all cores of the microprocessor design  110 . Note that the value of the core field  202   b  and the thread field  202   c  is NULL in all of these definitions  204   j - l,  because none of the corresponding MSR sub-parts is specific to any particular core or thread. The remaining properties of the MSR sub-parts defined by definitions  204   j - l  should be apparent from inspection of FIG. 2 based on the explanation provided above.  
     [0055] Referring now to FIG. 3, one embodiment of the test case  102  is illustrated. The test case  102  is illustrated in the form of a table having columns  302   a - e  (alternatively referred to as fields) and rows  304   a - f.  In practice, the test case  102  may be implemented in any of a variety of forms, such as a table generated by word processing or spreadsheet software, a header file or other source code file written in a programming language such as C, or a database file.  
     [0056] For purposes of example, the table illustrated in FIG. 3 provides initial values to be used by the initializer  106  to initialize some of the machine-specific registers (MSRs), or sub-parts thereof, in the microprocessor design  110 . In practice, the test case  102  will typically include initial values for all of the MSRs (and sub-parts thereof) in the microprocessor design  110 , initial values for other machine resources in the microprocessor design  110  (such as the cache(s) and main memory), and test instructions to be executed by the simulator  112 . The techniques described below with respect to the embodiment illustrated in FIG. 3 may therefore be applied similarly to any other kind of machine resource. Only a selection of initial MSR values are illustrated in FIG. 3 for ease of illustration and explanation. Furthermore, the particular values illustrated in FIG. 3 are chosen for illustrative purposes only.  
     [0057] Each of the rows  304   a - f  specifies an initial value for particular MSR sub-part. The rows  304   a - f  are therefore referred to herein as “machine resource initialization records.” Each of the machine resource initialization records  304   a - f  includes: (1) a “machine resource reference,” which refers to one or more MSR sub-parts in the microprocessor design  110 , and (2) an initial value for the referenced MSR sub-part.  
     [0058] The combination of values in fields  302   a - e  define a machine resource reference. For example, core field  302   a  indicates the core number (if any) of the corresponding MSR sub-part, thread field  302   b  indicates the thread number (if any) of the corresponding MSR sub-part, index field  302   c  indicates the index number of the corresponding MSR sub-part, and offset field  302   d  indicates the offset of the corresponding MSR sub-part. As described above, the combination of particular core, thread, index, and offset numbers uniquely specify a particular MSR sub-part within the microprocessor design  110 . Initial value field  302   e  specifies an initial value for the corresponding MSR sub-part.  
     [0059] The test case  102  will now be described in more detail with respect to representative examples of the machine resource initialization records  304   a - f.  Consider, for example, initialization record  304   a,  which refers to an MSR sub-part having core number zero (column  302   a ), thread number zero (column  302   b ), index number three (column  302   c ), and offset zero (column  302   d ). In the present embodiment, the combination of the core number (column  302   a ) and thread number (column  302   b ) of a particular machine resource reference is referred to herein as the scope specified by the reference, or more simply as the reference&#39;s “specified scope.” For example, initialization record  304   a  (which includes a machine resource reference defined by the values in columns  302   a - d ) specifies a thread-specific scope that is limited to core zero (column  302   a ) and thread zero (column  302   b ).  
     [0060] Machine resource initialization record  304   a  refers unambiguously to the MSR sub-part defined by machine resource definition  204   i  (FIG. 2). To understand why this is true, consider again the resource database  100  illustrated in FIG. 2. Machine resource initialization record  304   a  (FIG. 3) refers unambiguously to the MSR sub-part defined by definition  204   i  (FIG. 2) because the values of the core fields ( 202   b  and  302   a ), thread fields ( 202   c  and  302   b ), index fields ( 202   d  and  302   c ), and offset fields ( 202   e  and  302   d ) in initialization record  304   a  and definition  204   i  match exactly. The initializer  106  may therefore initialize this MSR sub-part with the value one (FIG. 3, row  304   a,  column  302   e ) in the simulator input  108 .  
     [0061] Consider now initialization record  304   b  (FIG. 3), which specifies an MSR sub-part having core number zero (column  302   a ), thread number one (column  302   b ), index number zero (column  302   c ), and offset eight (column  302   d ). The specified scope of initialization record  304   b  is therefore core zero, thread one, which is a thread-specific scope. Note, however, that by referring to FIG. 2 it may be seen that the MSR sub-part having index zero and offset eight (row  204   b ) has a core-specific scope (column  202   a ). The scope of an MSR sub-part (or more generally, any machine resource) as defined by the resource database  104  is referred to herein as the MSR subpart&#39;s “actual scope.” The (thread-specific) scope specified by initialization record  304   b,  therefore, is more specific than the (core-wide) scope of the MSR sub-part to which it refers (FIG. 2, row  204   b ). A machine resource reference is said to “over-specify” a machine resource when the specified scope of the reference is narrower (more specific) than the actual scope of the referenced machine resource. Initialization record  304   c  includes another example of a machine resource reference which over-specifies an MSR subpart.  
     [0062] In cases where a reference over-specifies an MSR subpart, the initializer  106  may select a scope—referred to herein as a “resolved scope”—to which the corresponding initial value (FIG. 3, column  302   e ) is to be applied. Examples of techniques for selecting a resolved scope are described in more detail below with respect to FIG. 4B.  
     [0063] Consider now machine resource initialization record  304   d  (FIG. 3), which refers to an MSR sub-part having core number zero (column  302   a ), a thread number of NULL (column  302   b ), an index number of four (column  302   c ), and an offset of zero (column  302   d ). The specified scope of initialization record  304   d  is therefore core zero, which is a core-specific scope. Note, however, that by referring to FIG. 2 it may be seen that the MSR sub-part having index four and offset zero (row  204   h ) has a thread-specific scope (column  202   a ). The (core-specific) scope specified by initialization record  304   d,  therefore, is broader than the (thread-specific) scope of at least one MSR sub-part (FIG. 2, row  204   h ) to which it refers. A machine resource reference is said to “under-specify” a machine resource (e.g., an MSR) when the reference&#39;s specified scope is broader than the actual scope of the machine resource. Initialization records  304   c  and  304   f  include other examples of machine resource references which under-specify MSR sub-parts. Examples of techniques that the initializer  106  may use to select a resolved scope in cases where an MSR sub-part is under-specified are described in more detail below with respect to FIG. 4C.  
     [0064] Note that the mere presence of a NULL value in the core field  302   a  and/or thread field  302   b  of a machine resource reference does not necessarily mean that the reference under-specifies a particular resource. Rather, NULL values may exactly specify the scope of a resource having multi-core and/or multi-thread scope. For example, consider initialization record  304   e,  which specifies an MSR sub-part having core number one (column  302   a ), a thread number of NULL (column  302   b ), index number zero (column  302   c ), and offset zero (column  302   d ). The specified scope of initialization record  304   e  is therefore core one, which is a core-specific scope. Initialization record  304   e  exactly specifies the MSR sub-part defined by definition  204   e  (FIG. 2), which has a core-specific scope (column  202   a ) of core one (column  202   b ), an index (column  202   d ) of zero, and an offset (column  202   e ) of zero.  
     [0065] Referring to FIG. 4A, a flowchart is shown of a method  400  that is performed by the initializer  106  in one embodiment of the present invention to resolve the scopes specified in the test case  102  and to provide initialized resource values in the simulator input  108 . The purpose of the initializer  106  is to define initial values for all of the machine resources in the microprocessor design  110  prior to execution of the simulator  112 .  
     [0066] The method  400  enters a loop over each resource initialization record R in the test case  102  (step  402 ). The method  400  identifies the following values in initialization record R: the core number R C , the thread number R T , the index R I , the offset R O , and the initial value R V  (step  404 ). The method  400  may perform step  404  by extracting these values from the corresponding columns  302   a - e  in the row of the test case  102  containing resource initialization record R (FIG. 3).  
     [0067] The method  400  calls a subroutine named SetResource with the input parameters R C , R T , R I , R O , and R V  (step  406 ). As described in more detail below with respect to FIG. 4B, the SetResource subroutine  406  initializes the resource(s) referenced by R C , R T , R I , and R O  with the initial value R V . The method  400  repeats steps  404 - 406  for each resource initialization record R (step  408 ).  
     [0068] Referring to FIG. 4B, a flowchart is shown of the SetResource subroutine  406  according to one embodiment of the present invention. Although the SetResource subroutine  406  is described herein as a subroutine that is called by the method  400  (FIG. 4A), performed by the initializer  106 , the SetResource subroutine  406  may be used in other contexts to set the value of a machine resource. For example, the simulator  112  may call the SetResource subroutine  406  to set the values of machine resources while simulating the operation of the microprocessor design  110 .  
     [0069] The subroutine  406  identifies the scope R S  that is specified by the combination of the core number R C  and the thread number R T  by calling a subroutine named GetScope (step  410 ). One embodiment of the GetScope subroutine  410  is described in more detail below with respect to FIG. 4C.  
     [0070] The subroutine  406  enters a loop over each resource definition D in the resource database  104  (step  412 ). The subroutine  406  identifies the following values in resource definition D: the core number D C , the thread number D T , the index D I , the offset D O , and the scope D S  (step  414 ).  
     [0071] The subroutine  406  determines whether both the index and offset numbers of the resource initialization record R and the resource definition D are the same (step  416 ). If they are not, then the resource initialization record R does not refer to the resource defined by resource definition D and the subroutine  406  does not initialize the resource defined by resource definition D. For example, consider resource initialization record  304   a  (FIG. 3) and resource definition  204   a  (FIG. 2). The index and offset numbers specified by resource initialization record  304   a  are 3 and 0, respectively, while the index and offset numbers specified by resource definition  204   a  are 0 and 0, respectively. Resource initialization record  304   a,  therefore, does not refer to the resource defined by resource definition  204   a.    
     [0072] If both the index and offset numbers of the resource initialization record R and the resource definition D are the same (step  416 ), the subroutine  406  determines whether the specified scope R S  is the same as the actual scope D S  of the resource defined by resource definition D (step  418 ). For example, consider resource initialization record  304   a  (FIG. 3) and resource definition  204   i  (FIG. 2), both of which have the same index and offset numbers. The actual scope of the resource defined by resource definition  204   i  is THREAD and, as explained in more detail below, the scope specified by resource initialization record  304   a  is also THREAD. The scope specified by resource initialization record  304   a  is therefore the same as the actual scope defined by resource definition  204   i.    
     [0073] If the scopes R S  and D S  are the same, then resource initialization record R refers exactly to the resource defined by resource definition D, and the subroutine  406  initializes the value D V  of the resource defined by resource definition D with the initial value R V  specified by resource initialization record R (step  422 ). This may be performed, for example, by storing the initial value R V  in the value field  202   g  of the corresponding resource in the resource database  104  (FIG. 2), storing the initial value R V  in the simulator input  108 , or storing the initial value R V  directly in the microprocessor design  110 .  
     [0074] For example, referring to FIG. 5 illustrates a portion of the simulator input  108 , in which the initial machine resource values specified in the test case  102  have been applied by the initializer  106  (using method  400 ) to the resources defined in the resource database  104 . Simulator input  108  includes machine resource representations  504   a - g,  each of which represents the initial state of a particular machine resource (in this example, an MSR sub-part). Columns  502   a - e  are equivalent to columns  202   a - e  of the resource database  104  (FIG. 2), while value column  502   f  indicates the current value of the corresponding machine resource.  
     [0075] Machine resource representation  504   a,  for example, represents the MSR sub-part defined by machine resource definition  204   i  (FIG. 2), which is the machine resource that is referenced by machine resource initialization record  304   a  (FIG. 3). The current (initialized) value  502   f  of resource representation  504   a  is one, which is the initial value  302   e  specified by initialization record  304   a  (FIG. 3). This is the result of step  422  (FIG. 4B).  
     [0076] Returning to FIG. 4B, if the specified scope R S  is not the same as the actual scope D S  of the resource defined by resource definition D, the subroutine  406  determines whether the specified scope R S  is broader than the actual scope D S  (step  420 ). In other words, in step  420  the subroutine  406  determines whether resource initialization record R under-specifies the resource defined by resource definition D. In this embodiment, CHIP scope is broader than both CORE and THREAD scope, CORE scope is broader than THREAD scope only, and THREAD scope is broader than neither CHIP scope nor CORE scope.  
     [0077] If resource initialization record R under-specifies the resource defined by resource definition D, the subroutine  406  initializes the value D V  of the resource defined by resource definition D with the initial value R V  specified by resource initialization record R (step  422 ). For example, consider resource initialization record  304   d  (FIG. 3), which has a specified scope of CORE, and which under-specifies the resource defined by resource definition  204   h  (FIG. 2), which has an actual scope of THREAD. Therefore, if R were resource initialization record  304   d  and D were resource definition  204   h,  in step  422  the subroutine  406  would initialize the value D V  (column  202   g ) of the resource defined by resource definition  204   h  with four (as specified in the value field  302   e  of resource initialization record  304   d ). This initial value assignment is illustrated by machine resource representation  504   d  in FIG. 5.  
     [0078] The effect of steps  420  and  422  is that each resource initialization record which under-specifies one or more machine resources is used to initialize all of the machine resources (e.g., cores and/or threads) within its scope. For example, if only a core number is specified for a machine resource having thread-specific scope, the specified initial value is applied to all threads within the specified core. Similarly, if a core number is not specified for a machine resource having core-specific scope, the specified initial value is applied to all cores within the specified scope.  
     [0079] For example, consider resource initialization record  304   f,  which under-specifies the resources defined by both resource definition  204   c  and resource definition  204   f.  Subroutine  406  would therefore use the initial value (6) specified by resource initialization record  304   f  to initialize both resource definition  204   c  and resource definition  204   f.  This assignment of initial values is illustrated by machine representations  504   f  and  504   g  in FIG. 5. A single resource initialization record may therefore be used to initialize multiple resource representations if the resource initialization record has a broader scope than the resources it references and the same index and offset as the referenced resources.  
     [0080] If the specified scope R S  is not greater than or equal to the actual scope D S  of the resource defined by resource definition D, the specified scope R S  must be narrower than the actual scope D S . In other words, resource initialization record R over-specifies the resource defined by resource definition D. In this case, the subroutine  406  alerts the user (step  424 ), and then assigns the initial value R V  to the value D V  (step  422 ). The user is alerted based on an assumption that an over-specified reference is the result of an error on the part of the designer of the test case  102 . Alternatively, the subroutine  406  may terminate the subroutine  406  at step  424  or issue a warning to the user but allow the subroutine  406  to continue without assigning the initial value R V  to the value D V .  
     [0081] Upon completion of step  416 ,  422 , or  424 , steps  412 - 424  are repeated for each of the remaining resource definitions D (step  426 ). Upon completion of the subroutine  406 , any and all resources specified by resource initialization record R will have been initialized with the initial value R V . If all resources are defined properly in the resource database  104  and all resource initialization records are defined properly in the test case  102 , each resource initialization record R should always reference at least one resource defined by the resource database  104 . The subroutine  406  may, however, be provided with a step (after step  426 ) for issuing an error message if resource initialization record R does not reference any resource defined by the resource database  104 .  
     [0082] As mentioned above, the SetResource subroutine  406  “resolves” the scope specified by the machine resource initialization record R to determine a resolved scope. The meaning of the “resolved scope” may be better understood with respect to the embodiment of the SetResource subroutine  406  illustrated in FIG. 4B. A machine resource reference which has the same scope, index, and offset as exactly one machine resource has a resolved scope which encompasses only that machine resource (steps  416 ,  418 , and  422 ). A machine resource reference which has the same index and offset as, but a broader scope than, one or more machine resources, has a resolved scope which encompasses all of those machine resources (steps  416 ,  418 ,  420 , and  422 ). A machine resource reference which has the same index and offset as, but a narrower scope than, one or more machine resources, has an undefined resolved scope (steps  416 ,  418 ,  420 ,  424 ). This particular set of techniques for resolving machine resource scopes, however, is only one example and does not constitute a limitation of the present invention.  
     [0083] Referring to FIG. 4C, a flowchart is shown of the GetScope subroutine (FIG. 4B, step  410 ) according to one embodiment of the present invention. The GetScope subroutine  410  takes as inputs two parameters: R C , a specified core number, and R T , a specified thread number. The GetScope subroutine  410  determines the scope that is specified by the core number R C  and the thread number R T . The subroutine  410  stores the specified scope in a variable named Scope, which is initialized to a value of THREAD (step  430 ). If the value of R T  is NULL (step  432 ), the subroutine  410  assigns a value of CORE to the variable Scope (step  434 ). If the value of R C  is NULL (step  436 ), the subroutine  410  assigns a value of CHIP to the variable Scope ( 438 ). The subroutine  410  returns the value of Scope to the calling routine, i.e., to the SetResource subroutine  406  (step  440 ).  
     [0084] The effect of the GetScope subroutine  410  is the following: (1) a non-NULL value for both the thread and core numbers R T  and R C  is interpreted as specifying a thread-specific scope (THREAD); (2) a non-NULL value for the core number R C  and a NULL value for the thread number R T  is interpreted as specifying a core-specific scope (CORE); and (3) a NULL value for both the thread and core numbers R T  and R C  is interpreted as specifying a chip-specific scope (CHIP).  
     [0085] In one embodiment, the resource database  104  is implemented as a source code file in the C programming language. In this embodiment, each of the machine resource definitions in the resource database  104  is implemented as a function call to a function which adds a machine resource representation to an internal data structure (not shown) that is maintained by the initializer  106  to represent MSR S  and other resources defined by the resource database  104 . Such a function may have the same parameters and be similar in operation to the SetResource function  406  illustrated in FIG. 4B, except that the function may create a new machine resource representation rather than set the value of an existing machine resource representation. Those of ordinary skill in the art will appreciate how to implement such a function based on the description of the SetResource function provided herein.  
     [0086] The initializer  106  and the simulator  112  may be implemented as software programs written in the C programming language or any other programming language. The method  400 , the SetResource subroutine  406 , and the GetScope subroutine  410  may be implemented as functions in the C programming language or any other programming language. The microprocessor design  110  may be implemented as a data structure stored in the memory of a computer or on a storage medium such as a hard disk.  
     [0087] Among the advantages of the invention are one or more of the following.  
     [0088] One advantage of the techniques disclosed herein is that they may be implemented straightforwardly and efficiently in non-object-oriented programming languages, such as the C programming language. For example, tools such as initializers (e.g, initializer  106 ) and simulators (e.g., simulator  112 ) are typically implemented as software programs. Such programs need to have access to the resource database  104  and/or the microprocessor design  110  so that they may modify the state of machine resource representations (FIG. 5) by reading the existing values of machine resource representations and writing new values to machine resource representations. For example, as described above, the initializer  106  reads initial machine resource values from the test case  102  and may write such values to the microprocessor design  110 , either directly, or indirectly through the simulator input  108  and the simulator  112 .  
     [0089] Software tools such as the initializer  106  and simulator  112  typically use functions (also referred to as procedures and subroutines) implemented in computer programming languages to read and write machine resource values. Such functions are referred to herein generally as “machine resource access functions.” The SetResource subroutine  406  illustrated in FIG. 4B may be implemented as such a function. In a mixed-scope architecture, resources having varying scope may be referenced using different numbers of identifiers. For example, an MSR having thread-specific scope requires four identifiers—a core number, thread number, offset, and index—to be uniquely referenced, while an MSR having chip-specific scope requires only two identifiers—an offset and index—to be uniquely referenced.  
     [0090] One way to implement machine resource access functions for accessing machine resource representations of varying scope would be to provide a distinct set of functions for each scope. For example, in place of the single SetResource subroutine illustrated in FIG. 4B, one could provide a SetChipResource function to set the value of a resource having chip-specific scope, a SetCoreResource function to set the value of a resource having core-specific scope, and a SetThreadResource function to set the value of a resource having thread-specific scope. Each of these functions would take a different number of parameters as inputs. For example, the SetChipResource function would take as inputs three parameters (index, offset, and value), the SetCoreResource function would take as inputs four parameters (core, index, offset, and value), and the SetThreadResource function would take as inputs five parameters (core, thread, index, offset, value).  
     [0091] Use of such multiple functions would be redundant and inefficient, particularly because it is desirable for tools such as the initializer  106  and simulator  112  to be able to access machine resources of varying scope in the same way. The SetResource subroutine  406  described herein allows machine resources of varying scope to be accessed using a single subroutine, which simplifies the process of designing and maintaining tools such as the initializer  106  and the simulator  112 .  
     [0092] In an object-oriented programming language, such as C++, a distinct class could be defined for each scope of machine resource, and a different version of the SetResource subroutine  406  (referred to as a “method” in object-oriented programming) could be implemented for each such class. Each version of the SetResource subroutine could have a different number of parameters. Such an approach would still, however, require that different versions of the SetResource subroutine be coded (one for each resource scope). Furthermore, the techniques described herein enable machine resource representations of varying scope to be accessed through a single software interface even when a non-object-oriented programming language, such as C, is used.  
     [0093] A further advantage of the techniques described herein is that they enable a single data structure (e.g., a data structure having the fields  202   a - g  illustrated in FIG. 2) to represent machine resources of varying scopes. In particular, the use of the NULL value as a place-holder in the case of values which are not needed for particular resources enables a single data structure type to represent resource definitions of varying scope. Similarly, the use of the NULL value as a place-holder in the resource initialization records  304   a - f  enables all of the resources initialization records  304   a - f  in the test case  102  to be implemented using a single data structure type.  
     [0094] Another advantage of techniques described herein is that they interpret and apply the probable intent of the initialization records in the test case  102  during the initialization process. For example, alternative approaches to handling machine resource references in the test case  102  that either over- or under-specify machine resources in the resource database  104  include ignoring such references and halting the initializer  106  with an error message. Although either of these approaches may be acceptable in particular circumstances, in the embodiments described herein the initializer  106  resolves the scope specified by the resource initialization records in the test case  102  in an attempt to identify the machine resources to which such records are likely intended to refer.  
     [0095] The method  400 , for example, incorporates certain assumptions about the probable intent behind resource references that over- and under-specify machine resources. If, for example, a resource initialization record under-specifies a particular defined resource, the SetResource subroutine  406  (FIG. 4B) assumes that the resource initialization record is intended to apply to the defined resource (step  420 ), and therefore initializes the defined resource with the initial value specified by the resource initialization record. Embodying this assumption in the initializer  106  allows the initialization process to proceed (rather than terminate) even when resources are under-specified.  
     [0096] Furthermore, embodying this assumption in the initializer  106  allows the test case designer to initialize all resources within a particular scope using a single initialization record. For example, the test case designer may initialize all threads within a particular core by providing a single initialization record which specifies that core but which does not specify a particular thread. In this way, the techniques disclosed herein may save the test case designer time and effort.  
     [0097] It should be appreciated, however, that the initializer  106  may be implemented to embody alternative assumptions. For example, in an alternative embodiment, the SetResource routine  406  may alert the user (step  424 ) if a resource initialization record under-specifies a defined resource, rather than initialize the defined resource using the resource initialization record.  
     [0098] Similarly, the embodiment of the SetResource routine  406  illustrated in FIG. 4B alerts the user (step  424 ) if the resource initialization record R over-specifies the resource defined by resource definition D, based on an assumption embodied in the SetResource routine  406  that an over-specified resource is the result of an error on the part of the designer of the test case  102 . Alternatively, however, the SetResource routine  406  may be implemented to initialize the resource defined by resource definition D (step  422 ) if the resource is over-specified by resource initialization record R. It should therefore be appreciated that, more generally, the initializer  106  may be implemented to interpret the test case  102  in any of a variety of ways and to produce the simulator input  108  based on the interpretation(s) applied in each particular case.  
     [0099] Although the particular examples described herein relate to the initializer  106  and simulator  112 , it should be appreciated that the techniques described herein may be applied more generally to accessing (i.e., reading and/or writing) machine resources having varying scopes. For example, automated circuit design analysis tools are commonly used to analyze properties of simulated circuit designs, such as the microprocessor design  110 . Design analysis tools are therefore another example of tools which may incorporate the techniques described herein.  
     [0100] Furthermore, although the examples above are described with respect to machine-specific registers (MSRs), this is merely an example and not a limitation of the present invention. Rather, the techniques disclosed herein may be applied to any kind of machine resource, such as caches, main memory, and other kinds of registers. Furthermore, although MSRs are described herein as being specified by a combination of core, thread, index, and offset numbers, this is merely an example and not a limitation of the present invention. Rather, a particular resource type may be specified by any number and combination of identifiers. Different kinds of resources in the microprocessor design  110  may be specified by different numbers and/or types of identifiers. Furthermore, although in the examples described above, two identifiers (core number and thread number) are capable of having NULL values, this is not a limitation of the present invention. Rather, any number of identifiers may be capable of having NULL values.  
     [0101] It is to be understood that although the invention has been described above in terms of particular embodiments, the foregoing embodiments are provided as illustrative only, and do not limit or define the scope of the invention. Various other embodiments, including but not limited to the following, are also within the scope of the claims.  
     [0102] The description herein refers to the use of a NULL value, for example, with respect to the resource definitions  204   a - l  in the resource database  104  (FIG. 2), the resource initialization records  304   a - f  in the test case  102  (FIG. 3), and the parameters passed to the SetResource subroutine  406  (FIG. 4B) and the GetScope subroutine  410  (FIG. 4C). The NULL value may be implemented in any of a variety of ways. For example, the NULL value may be represented by a value, such as −1, which does not represent a valid parameter value in the context in which it is used. Such a value may not be valid, for example, because it is out of range or because it is an undefined value. For example, in a system in which cores are numbered sequentially beginning with zero, a core number of −1 is out of range and may therefore represent the NULL value. Alternatively, some computer programming environments define non-numeric values (such as values indicating an arithmetic overflow) which may be used as the NULL value.  
     [0103] The NULL value may be represented by the same or different values in different contexts. For example, the NULL value in the resource database  104  (FIG. 2) may be represented by −1, while the NULL value in the test case  102  (FIG. 3) may be represented by −1 or another value, such as 999. The GetScope subroutine  410  (FIG. 4C) may determine whether the thread number R T  and/or the core number R C  is equal to NULL using any of a variety of techniques. For example, if elements of the system  100  are implemented using the C programming language, a common C header file may be provided which defines the NULL value for use in the resource database  104 , the test case  102 , and the GetScope subroutine  410 .  
     [0104] Although in the embodiment described above with respect to FIG. 4A, the initializer  106  applies under-specified machine resource references to all machine resource representations within their scope, this is not a requirement of the present invention. The initializer  106  may, for example, prohibit one or more resources and/or resource types from being under-specified. For example, the initializer  106  may maintain a list of exceptions which lists individual machine resources and/or machine resource types (e.g., cache, register, or main memory) for which under-specification is not allowed. In such a case, the SetResource routine  406 , for example, may be modified to alert the user, terminate with an error, or perform another appropriate action if it is determined in step  420  that the specified scope R S  is greater than the actual scope D S  and the resource defined by resource definition D is on the initializer&#39;s exception list.  
     [0105] Elements and components described herein may be further divided into additional components or joined together to form fewer components for performing the same functions.  
     [0106] Although the examples described herein are described in relation to the microprocessor design  110 , it should be appreciated that the techniques described herein may be applied more broadly to any kind of circuit design.  
     [0107] The techniques described above may be implemented, for example, in hardware, software, firmware, or any combination thereof. The techniques described above may be implemented in one or more computer programs executing on a programmable computer including a processor, a storage medium readable by the processor (including, for example, volatile and nonvolatile memory and/or storage elements), at least one input device, and at least one output device. Program code may be applied to input entered using the input device to perform the functions described and to generate output. The output may be provided to one or more output devices.  
     [0108] Each computer program within the scope of the claims below may be implemented in any programming language, such as assembly language, machine language, a high-level procedural programming language, or an object-oriented programming language. The programming language may, for example, be a compiled or interpreted programming language.  
     [0109] Each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps of the invention may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the invention by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions include, for example, all forms of non-volatile memory, such as semiconductor memory devices, including EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROMs. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits). A computer can generally also receive programs and data from a storage medium such as an internal disk (not shown) or a removable disk. These elements will also be found in a conventional desktop or workstation computer as well as other computers suitable for executing computer programs implementing the methods described herein, which may be used in conjunction with any digital print engine or marking engine, display monitor, or other raster output device capable of producing color or gray scale pixels on paper, film, display screen, or other output medium.