Systems and methods for identifying erroneous transactions

Disclosed are systems and methods for identifying erroneous transactions. In one embodiment, a system and a method pertain to monitoring an interface, determining information related to termination of a test case, and after the test case has terminated, identifying an incomplete transaction that should have completed prior to termination of the test case.

BACKGROUND

Computer processor design is an extremely complex and lengthy process. The design process includes a range of tasks from high level tasks such as specifying the architecture down to low level tasks such as determining the physical placement of transistors on a silicon substrate. Each stage of the design process also involves extensive testing and verification of the design through that stage. One typical stage of processor design is to program the desired architecture for the processor using a register transfer language (RTL). The desired architecture is represented by an RTL specification that describes the behavior of the processor in terms of step-wise register contents. The RTL specification models what the processor does without describing the physical circuit details. Thus, the processor architecture can be verified at a high level with reference to the RTL specification, independent of implementation details such as circuit design and transistor layout. The RTL specification also facilitates later hardware design of the processor.

Manually verifying the RTL specification of the processor architecture is prohibitively complex during the design of a modern microprocessor. Therefore, multiple test cases are typically generated to test the design. Each test case contains input instructions and may also contain the desired results or outputs. Rather than running test cases through a simulation of the RTL specification and manually verifying the results, the test cases may be executed both on a simulation of the RTL specification (often compiled to increase speed) and on a “golden simulator” and the results compared. The golden simulator (GSIM) is a relatively-high level simulation of the processor architecture and therefore has a higher likelihood of accurately implementing the desired architecture than the RTL specification. The golden simulator may be implemented in any desired manner, such as a custom program written using a high-level programming language. Although the golden simulator is often a higher-level implementation of the processor architecture than the RTL specification, the golden simulator typically does go into enough detail to match the major structures in the RTL specification. For example, if the RTL specification describes a translation look aside buffer (TLB), the golden simulator may also implement a TLB to enable full testing and comparison of the RTL specification.

Test cases may thus be executed both on the RTL specification and the golden simulator, so that the results can be compared. Any difference in the results indicates an error in the RTL specification, the golden simulator, or both, although in theory the golden simulator is more likely to be error-free than the RTL specification.

In an actual processor, processing continues without end until the processor is powered down. In the case of processor verification testing, however, the test case must terminate at some point in time. Once the test case so terminates, there may be various transactions that are still pending. In particular, there may be transactions that were initiated during the testing but that did not complete as defined by finish criteria established for the given transactions. Although such pending transactions may be legitimate transactions, for instance transactions that were initiated after termination was asserted but during execution of a code sequence that is performed before all processing ceases, other pending transactions may comprise erroneous transactions that should have completed but did not due to an error. Therefore, a system and method for identifying such erroneous transactions is needed so that the existence of such errors can be identified to the processor designer.

SUMMARY

Disclosed are systems and methods for identifying erroneous transactions. In one embodiment, a system and a method pertain to monitoring an interface, determining information related to termination of a test case, and after the test case has terminated, identifying an incomplete transaction that should have completed prior to termination of the test case.

DETAILED DESCRIPTION

Disclosed are systems and methods for identifying erroneous transactions of a simulated processor architecture. Referring toFIG. 1, a processor architecture verification system1is illustrated that verifies processor architecture by executing at least one test case10on both a register transfer language (RTL) simulator12that comprises a compiled version of the RTL specification, and a golden simulator14that comprises a relatively high-level program that emulates operation of the processor. The RTL simulator12and the golden simulator14both simulate the desired architecture16and20, respectively, of the processor. However, because the output of the RTL simulator12and the golden simulator14are in different formats, as will be discussed below, a translator22translates the output of the RTL simulator to match the format of the golden simulator. Notably, the output of the golden simulator14may instead be translated to match the format of the RTL simulator12.

The translated output of the RTL simulator12(translated by the translator22) is compared with the output of the golden simulator14in a comparator24. If any differences in the outputs are detected by the comparator24, the processor designer is alerted to the fact that an error may exist in the RTL simulator12or the golden simulator14or both. This enables test cases to be applied to the processor architecture quickly while minimizing required designer attention.

In the exemplary embodiment described herein, the golden simulator14is designed with a front side bus (FSB) output interface, while the RTL simulator12is designed with a point-to-point (P2P) link network output interface, as will be described in more detail below. The translator22comprises a virtual bus interface (VBI18) that translates transactions from the RTL simulator12from P2P link network format to FSB format for comparison with the FSB format output of the golden simulator14.

In some cases, the same golden simulator14may be used in the design of more than one processor, such as a family of processors all sharing the same underlying architecture. For instance, if the golden simulator14is designed with a given output interface in mind and a new processor is designed with a different output interface, the translator22enables the same golden simulator14to be used with the RTL simulator12for the new processor.

In some embodiments, the translator22de-pipelines the output of the RTL simulator12for comparison with the output of the golden simulator14. In such an embodiment, the translator22may be referred to as a “depiper” for de-pipelining the output of the RTL simulator12. The output of the RTL simulator12is de-pipelined in such an embodiment because the golden simulator14is more abstract than the RTL simulator12. In particular, the golden simulator14does not include the same level of detail about the processor architecture being verified as does the RTL simulator12. For example, the architecture, as simulated by the RTL simulator12, may be superscalar and highly pipelined, while the golden simulator14simulates the architecture without this level of detail. The result is that many, e.g.,20or30, instructions may be acting on the RTL simulator12simultaneously such that the output of the RTL simulator does not match the output of the golden simulator14directly, even though the underlying architecture is the same and the test case is identical.

The RTL simulator12and the golden simulator14are operated relative to information specified by the test case10. In one exemplary embodiment, the test case10comprises a program to be executed on the processor architecture16and20in the RTL simulator12and golden simulator14. The test case program is a memory image of one or more computer executable instructions, along with an indication of the starting point, and may comprise other state specifiers such as initial register contents, external interrupt state, etc. Accordingly, the test case10defines an initial state for the processor that is being simulated and the environment in which it operates. The test case10may be provided for execution on the RTL simulator12and golden simulator14in any suitable manner, such as an input stream or an input file specified on a command line.

The RTL specification used to generate the RTL simulator12is, for example, implemented using the iHDL hardware description language, from the Intel Corporation of Santa Clara, Calif. Alternatively, the RTL specification may be implemented using any suitable tool for modeling the processor architecture16, such as any register transfer language description of the architecture, which may be interpreted or compiled to act as a simulation of the processor. The RTL simulator12of an exemplary embodiment contains an application program interface (API) that enables external programs, including the translator22, to access the state of various signals in the simulated processor such as register contents, input/outputs (I/Os), etc. Thus, the output of the RTL simulator12may be produced in any of a number of ways, such as an output stream, an output file, or as states that are probed by an external program through the API. The RTL simulator12may simulate any desired level of20architectural detail, such as a processor core, or a processor core and one or more output interfaces.

As noted above, the golden simulator14of the exemplary embodiment is a relatively abstract, higher-level simulation of the processor architecture20, and therefore may be less likely to include faults or errors than the RTL simulator12. The golden simulator14is written using a high level programming language such as C or C++. Alternatively, the golden simulator14may be written using any other suitable programming language, whether compiled, interpreted, or otherwise executed. Whereas the RTL simulator12actually matches the details and reality of the processor being simulated to a great degree, the golden simulator14is a conceptual model without concern for timing considerations arising from physical constraints.

The tasks to be performed in the architecture verification system may be divided as desired. For example, in an alternative embodiment illustrated inFIG. 2, a processor architecture verification system2includes a golden simulator26that contains a comparator30. In the embodiment ofFIG. 2, the test case10is executed by the RTL simulator12and the golden simulator26. The results of the RTL simulator12are translated by the translator22, and are fed into the golden simulator26. The comparator30in the golden simulator26then compares the results of the golden simulation and the translated results from the RTL simulator12, and the results32are made available by the golden simulator.

The translator design depends on the output formats of the RTL simulator12and golden simulator14or26. In one exemplary embodiment, the output of the RTL simulator12and golden simulator14,26differs due to pipeline differences in the models as well as due to different output interfaces. The RTL simulator12includes architectural details such as the highly-pipelined, superscalar nature of the processor. Thus, a large number of instructions may be acting on the processor at one time. In contrast, the golden simulator14,26, although based on the same architecture being verified, is modeled without pipelines as a simple in order machine that processes a single instruction at a time. As described above, the translator22, in some embodiments, includes a depiper that de-pipelines the data and events in the RTL simulator12. The output of the RTL simulator12is thus simplified to appear as if it were generated by a simple in-order machine, thereby enabling the comparator (e.g.,24or30) to compare the translated results of the RTL simulator with the results of the golden simulator14,26. An exemplary depiper is described in U.S. Pat. No. 5,404,496, which is incorporated by reference herein for all that it discloses.

When provided, the depiper tracks instructions as they flow through the RTL simulator12and notes their effects on the simulated processor. The depiper may generate a retire record for each instruction that indicates when the instruction started executing and when it completed or retired, along with the states that changed during execution. In some cases, if state changes cannot be tracked to a single instruction, the depiper may generate a generic report identifying an altered state and the instructions that may have caused the change. Thus, the output of the RTL simulator12is simplified for comparison with the golden simulator14,26.

In embodiments in which the translator22includes a depiper the VBI18works in parallel with the depiper in the translator, with the depiper producing state change records such as depiper retire records, and the VBI producing state change records in the form of synthesized FSB transactions. Although the VBI18may read the P2P packets directly from the P2P interface on the RTL simulator12and may access information about the RTL simulated processor via the API, the VBI may also access information about the RTL simulated processor that is stored in the depiper. In some embodiments, the depiper contains structures that monitor the simulated processor core's states. In such cases, it may be convenient for the VBI18to access some information from the depiper for use in reporting or synthesizing fields used in the FSB phases.

In other embodiments in which the translator22includes a depiper, the depiper first reads the P2P output of the RTL simulator12and de-pipelines the P2P transactions, generating a de-pipelined version of the P2P transactions. The VBI18then reads the depipelined version of the P2P transactions from the depiper and generates corresponding FSB transactions for the comparator24or30. The de-pipelined P2P transactions may be transferred from the depiper to the VBI18in any suitable manner, such as across a virtual P2P link or in a file containing depiper retire records.

The VBI18is not limited to use with verification systems including a depiper. Verification systems having the same level of pipelining detail in both the RTL simulator12and the golden simulator14,26may not need a depiper, but a VBI18still enables processor simulators with different output interfaces to be used together. If the translator22includes a depiper, the VBI18may access information stored in the depiper as described above, or may be implemented as a module in the depiper for convenience. In embodiments in which the translator22does not include a depiper, the VBI18in the translator22still directly connects to the P2P output of the RTL simulator12, but obtains other information about the state of the simulated processor from the RTL simulator via the API. The VBI18uses the resulting P2P packets and other information to produce translated FSB transactions in whatever manner required by the comparator24,30, such as generating a virtual FSB connection to the comparator, or generating output reports containing records of FSB format transactions that may be read by the comparator.

Exemplary output interfaces of the RTL simulator12and the golden simulator14,26will now be described in more detail, as will the VBI18in the translator22.FIG. 3illustrates an example output interface33for the golden simulator14,26. As shown in that figure, the golden simulator14,26uses a front side bus34(FSB) In the embodiment ofFIG. 3, a simulated processor core36, Core1, based on the desired architecture20and simulated in the golden simulator14,26, is connected to the FSB34and therefore to external components such as other simulated processor Cores2and3(40and42), a memory44, etc. Those external components40,42, and44may comprise actual physical devices. For example, the memory44may be a portion of the memory of the computer executing the golden simulator14,26. Alternatively, one or more of the external components40,42, and44may be simulated components that are either simulated by the golden simulator14,26or by an external simulator. Alternatively, one or more of the external components40,42, and44may be virtual components represented by pre-programmed responses in the test case10that are issued by the golden simulator14,26in response to transactions from the simulated Core1(36).

The FSB34is a broadcast bus in which bus traffic is visible to each component connected to the FSB and each component monitors the traffic to determine whether the traffic is addressed to them. An exemplary operation or “transaction” performed by Core1(36), such as a memory read operation, may comprise multiple phases. For example, consider an exemplary read operation performed by the Core1(36) using the FSB34to read data from the memory44. The exemplary transaction comprises an arbitration phase, a request A, a request B, a snoop phase, and a data phase. Each of these five phases is performed by transmitting or receiving a block of information over the FSB34. The comparator24or30expects to see a report for each of the five phases that acts as a state input to be compared against inputs generated by the golden simulator14,26. The different phases are defined in the FSB output format and place the system into various states. For example, during the snoop phase, the transaction becomes globally visible so that the transaction is visible to each core36,40, and42, thereby facilitating a shared memory architecture (SMA).

In contrast, the RTL simulator12of the exemplary embodiments uses one or more ports into a point-to-point (P2P) link network46shown inFIG. 4. With reference toFIG. 4, the P2P link network46is a switch-based network with one or more crossbars48acting as switches between components such as processor cores36,40, and42, memory44, or other devices. Transactions are directed to specific components and are appropriately routed in the P2P link network46by the crossbar48. This operation of the crossbar48reduces the load on the system components because they do not need to examine each broadcast block of information as with the FSB34. Instead, each component ideally receives only data meant for that component. Use of the crossbar48also avoids bus loading issues that can plague FSB systems. Therefore the P2P link network46facilitates better scalability. Transactions on the P2P link network46are packet-based, with each packet containing a header with routing and other information. Packets containing requests, responses, and data are multiplexed so that portions of various transactions may be executed with many others at the same time. Transmissions are length limited, with each length-limited block of data called a “flit.” Thus, a long packet will be broken into several flits, and transactions will typically require multiple packets. Therefore, the P2P link network46is monitored over time to collect the appropriate P2P packets until enough information exists for a corresponding FSB phase to be generated by the translator22.

The translator VBI18translates entire transactions by reading the P2P packets and generating corresponding FSB phases for the transaction so that the transactions can be compared by the comparator24,30with transactions from the golden simulator14,26. The translator22may be designed to only monitor packets passing in and out of the simulated Core1(36), and/or may monitor other packets in the P2P link network46if desired. In the exemplary embodiment illustrated inFIG. 4, the translator22monitors the port50on the crossbar48that is connected to the simulated Core1(36) in the RTL simulator12.

An exemplary read operation in a P2P link network is illustrated inFIG. 5. The P2P link network52in this example comprises three simulated processor cores54,56, and60(i.e. Cores1,2, and3), a memory62, and a simple memory agent64. (Note that the diagram ofFIG. 5illustrates logical data flow, not physical connections, and that a crossbar through which all packets flow is not shown.) The first core54(Core1) is simulated in an RTL simulator, although the other components56,60,62, and64may also be simulated as discussed above. The term “data line” refers to a line of data, such as a computer-executable instruction line, which is stored in the memory62and copies of which may also be temporarily stored in caches in one or more of the cores54,56, and60. The term “simple” with respect to the simple memory agent56indicates that no directory of data line locations exists, such that the simple memory agent56is unaware of which component in the system is holding the controlling version of any given data line.

During the read operation, Core1(54) sends a packet66to the simple memory agent64requesting a line of data. Because the system does not include a directory, the simple memory agent64does not know where the controlling version of the line being read is located. Therefore, the simple memory agent64sends packets74and72to each of the other cores56and60(i.e. Cores2and3), respectively, inquiring as to whether those cores contain a controlling copy of the line. Assuming in this example that they do not, each core56,60responds with a packet70and76, respectively, indicating that they do not have a copy of the line. The simple memory agent64then sends a packet80to the memory62, which responds with a packet82containing the line to the simple memory agent64. The simple memory agent64then sends a packet84containing the line to the requesting core54.

Each of the packets described in the above example may be divided into multiple flits. Furthermore, depending on the particular protocol of the P2P link network, additional packets may be transmitted over the P2P link network52during the transaction, for example to indicate that the transaction is complete. Thus, packets in the P2P link network format are formatted and divided much differently than corresponding FSB phases of a transaction, and each may include information not provided in the other format.

An example of the operation of the translator22will now be described. It is noted that multiple P2P packets and FSB phases may be involved in a single transaction such as a read or write operation. Furthermore, a transaction may be divided differently in the P2P and FSB formats. Therefore, the translator22translates by transaction rather than by P2P packet in the following exemplary operation. However, not all P2P packets for a given transaction need be received before beginning to generate corresponding FSB phases for the transaction. For example, after receiving the second P2P packet in a five-packet transaction, it may be possible to generate the second corresponding FSB phase if sufficient information has been received.

The translator22monitors each virtual channel, both incoming and outgoing, on each selected P2P port. For example, the translator22may be configured to monitor all input and output ports on the simulated processor core. The translator22tracks the ports clock tick by clock tick. The clock may be a source clock in the P2P output interface of the simulated core, a clock signal in the virtual P2P link network wires, etc. The translator22first assembles transmissions into packets, which may comprise receiving multiple flits to form a packet, as described above.

When a packet has been received, its header is examined to see if the packet type is one that indicates that the packet should be translated or discarded. Only P2P packets corresponding to an FSB phase in a transaction are translated. For example, flow control packets or bus status packets relating to the P2P link network46that have no analogue in the FSB protocol are not translated. When the first packet of a transaction has been received, a packet list for that transaction is created to contain or identify all received packets for that transaction. When additional packets for that transaction are received, they are added to the appropriate packet list. The transactions being translated are managed and accessed by an associative array containing pointers to the packet lists for each transaction. Each transaction is assigned a transaction identifier or ID, “txnid,” which is used as an index into the associative array, as follows: transactionx {txnid}. The first entry in the packet list for each transaction contains information about the transaction, such as the transaction type (e.g., read, write, interrupt) and location, whether the packet is incoming or outgoing, timing information, and the port and channel. Each transaction that has had some activity during the current clock tick is marked as active using another associative array as follows: active{txnid}=1.

Once all monitored channels have been processed as described above for the current clock tick, the list of active transactions for this clock tick is processed to determine if an FSB phase may be generated based on the information received to this point. The type of each active packet list is noted, and each active packet list is scanned to determine whether, based on the packet type, an FSB phase for the transaction can be generated. If an FSB phase is generated based on packets in the packet list, the packet list is annotated to indicate that the FSB phase has been generated, preventing later generation of a duplicate FSB phases. Lookup tables are used in the exemplary translator22to generate FSB phases corresponding to one or more P2P packets. Meta-informational values in the FSB phases are translated from the packet list as well, such as request step time, a unique FSB transaction number, etc. FSB fields such as transaction type, address, code, write-snoop, lock, drv_ads, length, attribute, hit, hitm, etc., may be filled in with default values, or using a lookup table to translate from values in the packet list, or synthesizing new information. This synthesizing may be performed by using the transaction/packet type in the translation function, reading signals from other parts of the simulation, or from other information. For example, the signal delay from a data bus to a control path may be added to an observability time. Packets other than those triggering a reporting event may also be examined to determine proper field contents. It is also noted that some information may not need to be included in FSB phases if the information is not needed by the comparator24for verifying the simulated core. In such cases, dummy values may be inserted. The translator22,30may also perform any other appropriate functions such as rearranging the byte/word order in a line of data because of critical-chunk differences in the output interfaces, or changing the reported “completion time” based on the type of transaction. Once a transaction has been completely translated, it is removed from the active list of transactions being processed. The active transaction list is also cleared at the end of translation processing for a clock tick to prepare for the next clock tick.

As discussed above, translation details are dependent upon the differences between the golden simulator14,26and the RTL simulator12, such as the output interfaces and the level of architectural detail included in each. It will therefore be understood that the translator22may be adapted by one skilled in the art based upon the differences between the golden simulator14,26and the RTL simulator12.

In summary, the architecture of a processor design may be verified by simulating the processor architecture with a first process90(FIG. 6) to produce a first output in a P2P link network format and with a second process92to produce a second output in a FSB format. For example, as described above with respect to one exemplary embodiment, the first process may comprise an RTL simulation of a highly pipelined processor with a P2P link network output, the second process may comprise a golden simulation of a simple in-order machine that processes a single instruction at a time, with an FSB output, both based on the same architecture. The first output is translated94from the P2P link network format to the FSB format, and the translated first output is compared96with the second output.

As noted above, certain transactions that are pending when a test model is terminated may comprise erroneous transactions that should have completed but did not due to an error, for example in the processor design. Such erroneous transactions may not be detected in P2P interfaces, such as that used in the RTL simulator12. Unfortunately, the golden simulator14,26is unlikely to identify such erroneous transactions given its relatively high-level nature. Therefore, the processor designer may not be alerted to the fact that a given transaction did not complete and, therefore, that there may be a flaw in the processor design. As is described below, however, such erroneous transactions can be detected if the VBI18is configured to analyze the transactions that are pending when termination of the test case is asserted.

FIG. 7provides an example of operation of the VBI18in identifying transactions that are pending after termination of the test case is asserted. More particularly,FIG. 7provides an example of the VBI18in identifying erroneous transactions that are pending on a P2P interface, such as that of the RTL simulator12. Beginning with block100ofFIG. 7, the VBI18monitors the P2P interface. In particular, the VBI18examines all channels on each interface port of the P2P interface so as to identify all traffic that is transmitted over the interface. Therefore, as indicated in block102, the VBI18can detect a break signal. By way of example, such a signal can be asserted by the translator depiper after the depiper detects a break command having been issued by observing a case-ending sequence being executed. Once having detected that signal, the VBI18determines the clock step time when the break signal arrived on the interface, as indicated in block104.

As noted above, processing does not immediately cease upon issuance of the break command. Instead, one or more code sequences may be executed to implement the cessation analogous to a computer shut-down sequence. Once such code sequence(s) has/have been executed, the VBI18receives an indication that the test model, e.g., RTL simulator12, has stopped processing, as indicated in block106. By way of example, that indication can also be provided to the VBI18by the translator depiper.

At this point, the VBI18identifies all pending transactions that are contained in the pending transaction list, as indicated in block108. As noted above, one or more of those pending transactions may be legitimate. Therefore, as indicated in block110, the VBI18filters out pending transactions that appear to be legitimate, i.e. are not likely to indicate an error, prior to making any determinations as to erroneous transactions. An example of transactions that are not likely to indicate an error include transactions that were initiated at the time the break was asserted or thereafter in that such transactions would not be expected to terminate in such a short period of time (i.e. number of clock ticks). Also unlikely to indicate an error are, for example, code fetches, port read line code (PRLC) operations, port read line code with self-snoop (PRLCSS) operations, and the like in that such transactions may pertain to the code sequence(s) that is/are executed after issuance of the break command. Accordingly, the VBI18may filter the transactions contained in the pending transaction list by disregarding (i) transactions having a start time on or after the clock step time determined in block104(i.e. the time at which the break signal arrived on the interface), (ii) all code fetches, and (iii) any other transaction that, due to the configuration and/or operation of the test model (e.g., RTL simulator12), may legitimately not have completed after issuance of the break command.

Once the above-described filtering has been performed by the VBI18, any remaining pending transactions may be considered suspect in that, at least in theory, all transactions other than those filtered out by the VBI should have completed by the time the break command was issued or by the time processing ceased. Accordingly, with reference to block112, the VBI18flags all remaining pending transactions as erroneous. Notably, the existence of an erroneous transaction may indicate an error in the processor design (and the RTL specification), the VBI18, or a tool used to simulate a system component (e.g., a memory or a core). Alternatively or in addition, such an erroneous transaction may simply indicate that the transaction is otherwise spurious.

Irrespective of the cause of the erroneous transaction, flagging the transaction alerts the processor designer (or other user) as to the potential problem, as well as provides the user with information that can be used to determine the reason for the erroneous transaction(s). Therefore, the flagging of the erroneous transaction may comprise one or more of providing (e.g., printing out) all completed packets associated with the transaction, and/or providing (e.g., printing out) a summary of the entire transaction which describes all processing associated with that transaction (e.g., arrival of packets, contents of packets, etc.). From the provided information, the processor designer may be able to identify what conditions and/or system agents caused the transaction to not complete and, potentially, how to remedy the problem.

In view of the above, a method for identifying erroneous transactions can be summarized as shown inFIG. 8. Such a method comprises monitoring an interface (block116), determining information related to termination of a test case (block118), and after the test case has terminated, identifying an incomplete transaction that should have completed (block120).

Various computer-readable or executable code or electronically-executable instructions have been described herein. Such code or instructions may be implemented in any suitable manner, such as software, firmware, hard-wired electronic circuits, as the programming in a gate array, etc. Software may be programmed in any programming language, such as machine language, assembly language, or high-level languages such as C or C++. The computer programs may be interpreted or compiled.

Computer-readable code, executable code, or electronically-executable instructions may be tangibly embodied on any computer-readable storage medium or in any electronic circuitry for use by or in connection with any instruction-executing device, such as a general purpose processor, software emulator, application specific circuit, a circuit made of logic gates, etc. that can access or embody, and execute, the code or instructions.

Methods described and claimed herein may be performed by the execution of computer readable or executable code or electronically executable instructions, tangibly embodied on any computer-readable storage medium or in any electronic circuitry as described above.

A storage medium for tangibly-embodying computer readable code, executable code, or electronically-executable instructions includes any means that can store, transmit, communicate, or in any way propagate the code or instructions for use by or in connection with the instruction-executing device. For example, the storage medium may include (but is not limited to) any electronic, magnetic, optical, or other storage device, or any transmission medium such as an electrical conductor, an electromagnetic, optical, infrared transmission, etc. The storage medium may alternatively comprise an electronic circuit, with the code or instructions represented by the design of the electronic circuit. Specific examples include magnetic or optical disks, both fixed and removable, semiconductor memory devices such as memory cards and read-only memories (ROMs), including programmable and erasable ROMs, non-volatile memories (NVMs), optical fibers, etc. Storage media for tangibly-embodying code or instructions also include printed media such as computer printouts on paper which may be optically scanned to retrieve the code or instructions, which may in turn be parsed, compiled, assembled, stored and executed by an instruction-executing device. The code or instructions may also be tangibly embodied as an electrical signal in a transmission medium such as the Internet or other types of networks, both wired and wireless.