Method for automatic design and verification of processor programming and simulation tool

Abstract

A method of designing a programming and / or emulation tool for a processor includes developing a single model of the processor from a group including: the processor; hardware description of the processor; and a specification of the processor that is confirmed to represent the processor and / or hardware description; and automatically generating, by the electronic design automation tool, a programming and / or simulation tool of the processor from the single model of the processor and the set of design parameters. The method also includes validating a programming and / or emulation tool of the processor using the one or more validation applications and the reference entity.

Description

Background Art 1. Technical Field

[0001] The present invention relates to the design of processor programming and / or simulation tools. More particularly, the present invention is directed to the design and optional verification of processor programming and / or simulation tools. 2. Description of Related Art

[0002] Generally, a processor is provided with a set of programming and optionally simulation tools specific to that processor, and thus facilitates the creation and simulation of applications executed by the processor. During the life cycle of a processor, the set of programming and / or simulation tools can be redesigned by adding new features, functions, and other improvements known to those of ordinary skill in the art. Such a redesign is currently performed by human designers manually rewriting parts of the programming and / or simulation tools, such as compilers, assemblers, simulators, or the entire set of programming and / or simulation tools.

[0003] Since these improvements are intended for a processor that has already been developed and the specification of the processor cannot be changed, it is prudent to verify that the improvements do indeed operate correctly on the processor. Such verification is performed by human designers manually constructing a verification application using the redesigned programming and / or simulation tools, executing the verification application on the processor and / or simulator, and comparing the results thus obtained with the expected values. The expected values include results determined independently of the execution of the application on the processor and / or simulator by the verification applicant.

[0004] Since the redesign and verification are largely performed by manual, non-automated human designers, errors are prone to occur and integrity is lacking. Therefore, a method is needed to address the problems disclosed above and other problems with the current redesign and verification methods known to those of ordinary skill in the art. Summary of the Invention

[0005] In one aspect of the present disclosure, a method for the automated design and optional verification of programming and / or simulation tools for an existing processor is disclosed according to the appended independent claims. Other aspects are disclosed in the dependent claims. Brief Description of the Drawings

[0006] The foregoing aspects described herein will become more readily understood by reference to the following description when taken in conjunction with the accompanying drawings, in which:

[0007] Figure 1 depicts a conceptual structure for the automated design and optional verification of programming and / or simulation tools for an existing processor according to one aspect of the present disclosure and the information flow between the elements of the conceptual structure; and

[0008] Figure 2aDepicts a conceptual structure for validating a programming tool and the information flow between the elements of the conceptual structure according to one aspect of the present disclosure.

[0009] Figure 2b Depicts a conceptual structure for validating a simulation tool and the information flow between the elements of the conceptual structure according to another aspect of the present disclosure.

[0010] Figure 3 Depicts a flowchart of a process for validating a programming tool.

[0011] Figure 4 Depicts a flowchart of a process for validating a simulation tool.

[0012] The descriptions of similar structural elements in the figures are not repeated, and the reference numbers of similar elements are distinguished by integer multiples of 100, i.e., Figure 1 the reference number 100 in Figure 2a becomes the reference number 200 in Detailed Description

[0013] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the technical field to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the relevant field and the context of the present disclosure.

[0014] As used herein, the singular forms "a", "an", and "the one" are also intended to include the plural forms unless the context clearly indicates otherwise. It will be further understood that when used in this specification, the terms "comprises", "comprising", and / or "includes" specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The term "and / or" includes any and all combinations of one or more of the associated listed items.

[0015] As used herein, the term processor design means a design represented by a physical device, such as a hardware description, and the design of programming and / or simulation tools.

[0016] The various aspects disclosed may be described with reference to one or more exemplary configurations. As used herein, the term "exemplary" means "serving as an example, instance, or illustration" and should not necessarily be construed as preferred or advantageous over other configurations disclosed herein.

[0017] Aspects of the present invention will be described with reference to the accompanying drawings, which are schematic illustrations of exemplary configurations of the inventive concept, unless otherwise specified. The aspects of the present disclosure are provided to enable a person of ordinary skill in the art to practice the present invention. Modifications to the aspects presented throughout the present disclosure will be apparent to a person of ordinary skill in the art, and the concepts disclosed herein can be extended to other applications.

[0018] Concepts of processor design and verification are disclosed in a co-pending application entitled "A METHOD FOR AUTOMATIC PROCESSOR DESIGN, VALIDATION, AND VERIFICATION", application number 17 / 224,898, filed on April 14, 2021, which is incorporated herein by reference. A person of ordinary skill in the art will understand that the following disclosure regarding the design and optional verification of programming and / or simulation tools for a processor is for understanding the overall concept; the present invention is applicable as long as there is a hardware description of the processor or a specification of the processor, and the confirmation represents the processor or the hardware description.

[0019] A person of ordinary skill in the art is aware that the complex task of processor design has led to the development of electronic design automation (EDA) tools that automate the tasks of processor design, checking, and verification, and has resulted in programming and / or simulation tools such as high-level programming languages (HLLs) and related compilers, assemblers, simulators, debuggers, profilers, as well as hardware descriptions in hardware description languages such as VHSIC Hardware Description Language (VHDL), Verilog, SystemVerilog, and other languages known to a person of ordinary skill in the art based on processor specifications. To describe the instruction set and microarchitecture of a processor, architecture description languages (ADLs) have been developed. ADLs can be classified into two categories: ALDs that use templates and general ADLs. The first category, i.e., ALDs that use templates, allows for modification of a limited part of the processor. An example of an ALD that uses templates is Tensi1ica Instruction Extension (TIE), which is further limited to customization of the Xtensa processor core architecture. The second category, i.e., general ADLs, allows for modification of any part of the processor. Examples of general ADLs are Instruction Set Architecture Language (LISA), nML, and versions 1 and 2 of the Codasip Architecture Language (CodAL) of Codasip Corporation.

[0020] The latter provides two models or views of the designed processor, with different levels of abstraction. The first level of abstraction is represented by the Instruction Accurate model (IA), which is simpler and aimed at Design Space Exploration (DSE), i.e., exploring the optimal instruction set. The IA model is mainly for the description of the Instruction Set Architecture (ISA) and defines instructions with limited implementation details. Hardware cannot be generated from the IA model, but it is suitable for generating at least some of the partial programming and simulation tools.

[0021] The second level of abstraction is represented by the Cycle Accurate (CA), which is aimed at the microarchitecture design for the target hardware technology. From the CA model, a processor hardware description is generated in a hardware description language.

[0022] Due to the limitations of the ADL, i.e., the IA model lacks awareness of at least some details of the CA model, there are potential differences in instruction implementation between the IA model and the CA model, and programs cannot be correctly processed. A new type of architecture description language has been developed. Such a language enables the processor specification 102 to be described as the design of a single processor model 104, which combines the two levels of abstraction in an interleaved manner, for example. In other words, the language is designed in such a way that it allows the unification of the instruction set description and the microarchitecture detail description. That is to say, the description of an instruction contains information about when and where to provide the operand(s) for the instruction(s), which functional unit executes the instruction, the timing of the instruction, and when and where to provide the result. The Codasip Architecture Language (CodAL) version 3 developed by Codasip Corporation is an example of this new type of language, which enables the development of a single model. Since the version identification may change, this new type of language that enables the development of a single model is hereinafter referred to as the Codasip Architecture Language.

[0023] Figure 1 Depicts the conceptual structure of the programming and / or simulation tools for designing and optionally verifying a processor and the information flow between the elements of the conceptual structure. These elements include hardware or software entities that implement blocks and / or block functions.

[0024] The processor specification 102 summarizes the requirements that the processor design must meet. Such a processor specification 102 includes the description of a unified instruction set specification and a microarchitecture specification and can be in the form of one or more text files. For example, one file includes the specification for the instruction set, and another file includes the specification for the microarchitecture, drawings, or any other file form known to those of ordinary skill in the art.

[0025] The single-processor model 104 is written in an architecture description language that enables the development of the single model based on the processor specification 102, such as the Codasip architecture language. Since the processor has been designed, in one aspect, the single-processor model 104 developed according to the final processor specification 102 may already be available.

[0026] On the other hand, if there is no such single-processor model 104, but there is the final processor specification 102 for manufacturing the processor (i.e., the processor specification that is confirmed to correctly describe the processor) or the processor hardware specification, the single-processor model 104 can be developed according to the final processor specification 102.

[0027] In yet another aspect, if there is no final specification 102, the single-processor model 104 can be developed based on the hardware description, which is generally available. For a simple hardware description, such a single-processor model 104 can be directly described in a language capable of developing a single model, such as the Codasip architecture language. For a hardware description that is determined to be too complex for such a direct description, the processor specification 102 is first developed based on the hardware description, and then the processor specification 102 is described in that language to obtain the single-processor model 104.

[0028] In yet another aspect, if there is neither the final processor specification 102 nor the hardware description, it is still possible to reverse engineer those parts of the existing processor that are necessary for describing the (multiple) parts of the microarchitecture, instruction set, and semantics, necessary for obtaining the processor specification 102 or the hardware description, and thus develop the single-processor model 104 as disclosed above. Reverse engineering the (multiple) parts includes, for example, the pipeline depth, the handling of control and structural hazards, the number of functional units the processor has, and other parts known to those of ordinary skill in the art.

[0029] The Codasip architecture language is developed by adding new features. Therefore, even if the single-processor model 104 may be available, it may still be profitable to re-develop the single-processor model using the new version of the Codasip architecture language to utilize these new features. Codasip Corporation, the developer of the Codasip architecture language, has an internal program to ensure the correct functionality of the Codasip architecture language.

[0030] Regardless of the way the single-processor model 104 is obtained, the single-processor model 104 includes a description of the microarchitecture, instruction set, and semantics of the processor. Thus, as described above, the single-processor model 104 formed by the programming and / or simulation tools generated by EDA is also aware of the microarchitecture, instruction set, and semantics of the processor.

[0031] In addition to the single-processor model 104, the user can specify optional design parameters 106 that affect the behavior of the EDA tool 108. For example, such parameters can include, for instance, a parameter that instructs the EDA tool 108 to affect the simulated memory size, an optimization level that improves simulation speed, or default compilation flags for programming tools. The optionality can be implemented in different ways. For example, in one aspect, the EDA tool 108 requires a set of design parameters, which can be empty or can contain at least one parameter. In another aspect, the EDA tool 108 can check whether the optional design parameters 106 exist and process accordingly.

[0032] Then, the single-processor model 104 and the optional design parameters 106 are used as inputs to the EDA tool 108. After receiving the single-processor model 104 and the optional design parameters 106, in one aspect, the EDA tool 108 at least automatically generates programming tools, such as an HLL compiler 110, an assembler 112, a linker 114, and simulation tools, such as a simulator, a profiler, and a debugger (collectively identified by reference numeral 116), as well as a verification environment 128. In another aspect, the EDA tool 108 additionally automatically generates a random program generator 124.

[0033] In one aspect, the linker 114 generated by the EDA tool 108 is unique to the single-processor model 104. The uniqueness of the linker 114 can further improve the generated executable file 122, for example, through code size optimization. In another aspect, the linker 114 can be a stand-alone tool that is common to all different processor models 104. The EDA tool 108 can optionally generate additional utility tools (not shown), for example, a tool for determining information about the properties of the compiled executable file (such as data size), a tool for parsing the debug information generated by the compiler (such as call stack reconstruction), and any additional information known to those of ordinary skill in the art.

[0034] Similar to the development of the Codasip architecture language, the EDA tool 108 is also developed by adding new features, improving the functionality of the generated programming 110, 112, 114, and / or simulation tools 116, and ensuring the correct functionality of the EDA tool 108 via internal programs.

[0035] Although not strictly necessary, it is desirable to verify the redesigned programming 110, 112, 114, and / or simulation tool 116. Since the development of the single-processor model 104 is performed by a human designer manually, non-automatically coding in the Codasip architecture language, like all coding processes, it is error-prone. Thus, the programming 110, 112, 114, and / or simulation tool 116 generated from the single-processor model 104 and the optional design parameters 106 may likewise contain errors. Additionally, verification is useful when some processor functions, such as data hazards, control hazards, or structural hazards, are offloaded from the processor microarchitecture to the HLL compiler 110. For example, consider the case when the processor microarchitecture is not designed to handle data hazards. That is, the processor microarchitecture does not include the (s) structure(s) for data hazard handling, but rather, data hazard handling is expected to be handled by the HLL compiler 110. Thus, the EDA tool 108 must generate an HLL compiler 110 that can create a correct output assembler file and insert any necessary instructions (such as no-operation instructions) such that the executable file 122 does not contain any data hazards related to the processor microarchitecture.

[0036] The omission of such (s) structure(s) in the processor microarchitecture may be intentional. For example, a human designer may decide to trade off simpler hardware for the need for the software executed by the processor to handle data hazards. If not addressed, such data hazards will prevent the execution of instruction i2, the execution of which depends on the completion of the execution of instruction i1 immediately preceding instruction i2. If instruction i2 does not respect the dependency on the previous instruction i1, such non-compliance may result in (s) incorrect result(s).

[0037] Since the executable file can contain any subset of the processor instruction set, including the entire set of instructions, and the instructions can be in any order, it is desirable to test any and all instruction sequences for a comprehensive verification of the programming 110, 112, 114, and / or simulation tool 116.

[0038] The programming tools 110, 112, 114 and / or the simulation tool 116 are verified by means of one or more verification applications. The verification applications include a prologue, a body, and an epilogue. The application prologue is the part of the application that sets the initial conditions of the application, such as register initialization, memory initialization, port initialization, and initialization of interrupt or exception routines, as well as other settings known to those of ordinary skill in the art. The body includes at least one sequence of at least one instruction for verifying the generated programming tools 110, 112, 114 and / or the simulation tool 116. The application epilogue is the part of the application that sets the conditions of the application after processing the body, such as stopping the emulator tool, reading the values of the processor resources, and setting other conditions known to those of ordinary skill in the art. The resources of the processor can include, for example, registers, memory, ports, and other resources known to those of ordinary skill in the art.

[0039] (Multiple) verification applications can have several possible sources. In one aspect, a set of pre-prepared verification applications is provided together with the EDA tool 108. On the other hand, a third party provides a set of pre-prepared verification applications. From the user's perspective, the difference between the two is that the former is free, while the latter may require additional arrangements such as licensing, purchasing, etc. Such two sets of verification applications are hand-coded by the provider of the EDA tool 108 or a third party. In both aspects, the verification applications can be written in HLL 118 or assembly language 120. In yet another aspect, the optional random program generator 124 generates (multiple) verification applications in assembly language 120. In all of the above aspects, the entity providing the (multiple) verification applications needs to ensure that the (multiple) verification applications provide the correct state of the processor resources, that is, the state of the processor resources resulting from the execution of the (multiple) verification applications. Such a guarantee will be referred to as self-checking hereinafter.

[0040] Knowledge of the instruction set and microarchitecture details based on the single-processor model 104 and the optional design parameters 106 makes the self-checking function possible. That is to say, based on the semantics of the instruction set and microarchitecture, the state of the processor resources is determined. Therefore, at any time during the execution of the at least one instruction sequence, (multiple) verification applications can be generated that are compiled into an executable file 122, which can contain at least one sequence of at least one instruction together with the computational state of the processor resources. By comparing the processor resource state with the computational state, the correctness of the programming tools 110, 112, 114 and the simulation tool 116 can be verified.

[0041] In the at least one instruction sequence including the verification application, the number of instructions depends on the verification objective. For example, some instructions can be verified as a sequence including a single instruction (e.g., a LOAD instruction), while other instructions include sequences including multiple instructions. For example, an ADD instruction requires prior instructions to set values, and the ADD instruction to be verified depends on the values. Logically, the use of a (multiple) verification application handwritten by a human designer or a pre-prepared (multiple) set of verification applications provided by the EDA tool 108 is limited because it is practically impossible to meet such verification objectives. Therefore, in one aspect of the present invention, a random program generator 124 is used to automatically generate the at least one instruction sequence (ideally any and all instruction sequences), leveraging the power of another processor (different from the processors of the programming 110, 112, 114 being redesigned and the simulation tool 116) or a computer that can execute the functions of the random program generator 124 any number of times. Additionally, the lack of human participation ensures that the generation of the at least one instruction sequence is error-free.

[0042] Although a set including a single verification application containing all necessary instruction sequences can be used, it may be beneficial to provide a set including multiple verification applications to facilitate easier interpretation of results and correction of potential errors.

[0043] The state of each processor resource can be characterized by one or more values reached by each resource during the execution of the verification application. Similarly, the computational state of each processor resource can be characterized by one or more expected values 126. The one or more expected values can be embedded in the verification application itself, or the one or more expected values can be placed in a separate storage 126 from the (multiple) verification applications. This is the case even if the execution is affected by external events. Thus, for example, considering that the external events include the interrupts mentioned above, the processor must stop the execution of the instruction sequence, save the resource state at the time of the interrupt, handle the interrupt, and resume the execution of the instruction sequence in the retrieved state of the processor.

[0044] The programming tools 110, 112, and 114 generated by the EDA tool 108 do not need to include certain microarchitecture structures that are unnecessary for the functions of the programming tools 110, 112, and 114. For example, the functions of the programming tools 110, 112, and 114 do not need to know the microarchitecture of the branch predictor, the specific implementation of the protocol for ensuring communication with the memory, and other microarchitecture structures known to those of ordinary skill in the art, and thus do not include these. In contrast, the simulation tool 116 does include all microarchitecture structures.

[0045] The EDA tool 108 further generates a verification environment 128 from the single-processor model 104 and the optional design parameters 106. The generated verification environment 128 includes programs that specify the usage of tools, libraries, and / or collections of functions designed to support verification. In particular, the verification environment program 128 creates instances of drivers and conceptual entities and defines the relationships between them, as Figure 2a disclosed. A driver is a software program that operates and / or controls a particular device / unit within the verification environment attached to the driver. The verification environment 128 then instructs the collection of tools, libraries, and / or functions how to access the drivers, conceptual entities, and how to perform verification tests and what verification tests to perform. For example, such a collection of tools, libraries, and / or functions can include tools, libraries, and / or functions supplied by the EDA tool 108. Alternatively, such a collection of tools includes third-party tools such as the Universal Verification Methodology (UVM) libraries and tools provided by Mentor Graphics in ModelSim, and other tools and functions known to those of ordinary skill in the art.

[0046] As disclosed above, since the random program generator 124 is generated by the EDE tool 108, the random program generator 124 understands the instruction set and semantics of the processor model 104 and the microarchitecture. Thus, the random program generator 124 can generate at least one expected value corresponding to the state of each resource of the processor model 104 to be verified. The random program generator 124 then generates at least one instruction sequence that includes at least one instruction that produces the at least one expected value.

[0047] The term expected value refers to the state value of the resources of the processor model 104 when the at least one instruction sequence is executed. In the case where the at least one sequence includes more than one instruction, the random program generator 124 can generate intermediate expected values, i.e., the values of the resources of the processor model 104 when each intermediate instruction of the sequence is executed. The generation of the expected values and optional intermediate expected values and the corresponding instruction stream utilizes a Satisfiability Modulo Theories (SMT) solver, and these values are stored in the expected value 126 memory. Thanks to this scheme, a reference model is not required. The functionality of the random program generator 124 can be controlled by a set of parameters. Thus, by specifying different parameters, the user can affect the content of the verification application(s), such as the random values of resources, the number of instruction sequences, and the number of instructions in each sequence, as well as other parameters known to those of ordinary skill in the art.

[0048] To verify programming tools 110, 112, and 114 and / or simulation tool 116, verification environment 128 needs a reference entity (not shown), i.e., an entity that ensures that the verification application compiled into executable file 122 produces the correct processor resource state. In one aspect, the reference entity includes a processor. In another aspect, the reference entity includes an emulator that is verified to produce the correct processor resource state. The emulator is not provided by the developer as part of EDA tool 108 and is thus referred to hereinafter as a third-party emulator.

[0049] Figure 2a Depicts a conceptual structure for automatically designing and subsequently verifying programming 110, 112, and 114 and / or simulation tool 116 and the information flow between the various elements of the conceptual structure. The elements include hardware or software entities that implement the structure and its functionality. To further clarify Figure 2a references made in Figure 1 and the relationship between certain blocks and the associated text, Figure 1 the reference designations of the blocks of

[0050] As disclosed above, verification environment 228 is a program that includes a set of instructions for tools, libraries, and / or functionality designed to support verification. In one aspect, verification environment 228 is communicatively coupled to a structure (collectively shown as unit 224) that accepts expected values and optional intermediate expected values and to a reference entity 226. In another aspect, verification environment 228 includes structure 224 and reference entity 226. EDA tool (108) further generates verification support, such as structures 232, 234, or 242, as disclosed in detail hereinafter. As disclosed above, expected values (126) are provided by the (multiple) verification applications into the memory within expected value unit 224 such that expected result unit 232 can access expected values (126). Processor resource values generated by reference entity 226 can be stored in monitoring unit 234 for further evaluation.

[0051] Each of expected result unit 232 and monitoring unit 234 includes at least one processor resource that characterizes the processor. Such an arrangement enables verification of the resources of a single processor. Although Figure 2aOnly the processor resources are depicted: memories 232_2, 234_2, registers 232_4, 234_4 (including the register file), and output ports 232_6, 234_6, but this is for illustrative purposes only, and any processor resources or hardware components known to those of ordinary skill in the art are contemplated. A memory is an analog representation of any physical device for temporarily or permanently storing instructions and / or data as would be implemented in a processor. A register is an analog representation of a small amount of (fast) storage that is (typically) addressed by a mechanism other than the main memory and can thus be accessed more quickly. Registers 232_4, 234_4 represent architectural registers, i.e., registers that a programmer can use, and microarchitectural registers, i.e., registers that a programmer cannot use but that are used internally by the processor. A port is an analog representation of any physical input / output port for passing information to other components connected to the processor.

[0052] To enable the reference entity 226 to execute the executable file (122), the EDA tool (108) further generates an executable file driver 236. Additionally, some executable files require that the input port values provided by the (one or more) verification applications be input into the reference entity 226. Such input port values can include interrupts, pending data, and / or any other inputs known to those of ordinary skill in the art. Thus, the EDA tool (108) further generates an optional input port driver 238.

[0053] Figure 3 Depicts a flowchart of a process for verifying programming. To further clarify Figure 3 references in Figure 1 and Figure 2a the relationship between certain blocks and the associated text, Figure 1 and Figure 2a the reference labels of the blocks in

[0054] In step 300, verification begins by providing the (one or more) verification applications in the form of the (one or more) executable files (122) and the (one or more) optional port values. The executable file (122) is provided to the reference entity (226) via the executable file driver (236); the (one or more) optional values of the (one or more) input ports are provided to the reference entity (226) via the input port driver (238); and the expected value (126) is provided to block (224).

[0055] In step 302, the executable file (122) starts to execute. Throughout the execution process, the values of the memory (234_2), registers (234_4), and output ports (234_6) generated by the reference entity (226) are stored by the reference entity (226) and passed to the monitoring unit (234), and the expected value stores (224) of the memory (234_2), registers (234_4), and output ports (234_6) are passed to the expected value unit (232), as disclosed in detail below.

[0056] In step 304, when the execution ends, the values from the memories (232_2) and (234_2) are provided to the comparator (240_2). The expected value unit (232) accesses the expected value memory (224), takes a snapshot of the value in the memory (232_2), and the monitoring unit (234) accesses the reference entity (226) and takes a snapshot of the value in the memory (234_2).

[0057] The comparator (240_2) performs the following functions: stepping through the values in the memories (232v2) and (234_2), comparing the values between the memories (232_2) and (234_2) in each step, , and providing the comparison result to the verification evaluation unit (242).

[0058] The values in the registers (232_4) and (234_4) are obtained using the same process and provided to the comparator (240_4). The comparator (240_4) performs the following functions: stepping through the values in the registers (232_4) and the register (234_4), comparing the values between the registers (232_4) and the register (234_4) in each step, and providing the comparison result to the verification evaluation unit (242).

[0059] The values of the output ports (232_6) and (234_6) are obtained using the same process and provided to the comparator (240_6). The comparator (240_6) performs the following functions: stepping through the values of the corresponding output ports (232_6) and (234_6), comparing the values between the output ports (232_6) and (234_6) in each step, and providing the comparison result to the verification evaluation unit (242). This process continues in step 306.

[0060] In step 306, the verification evaluation unit (242) evaluates the comparison result. In one aspect, such evaluation can be a pass / fail report. However, the user can further instruct the verification evaluation unit (242) to request more detailed reports from the expected value unit (232) and the monitoring unit (234). Such reports can provide, for example, in the case of a verification failure, the specific values of the differences between the expected value unit (232) and the monitoring unit (234); the coverage of the instruction set, i.e., the number and / or list of executed instructions; the number and / or list of executed instruction sequences, and the number and / or list of unexecuted instruction sequences; register and memory values, and other information known to those of ordinary skill in the art implemented by the verification evaluation unit (242). The process continues in step 308.

[0061] In step 308, the pass / fail report is evaluated. If the report is a pass, the process continues in step 310, otherwise the process continues in step 316.

[0062] In step 310, it is evaluated whether all verification applications have been executed in the form of (one or more) executable files (122). If the evaluation result is affirmative, the process continues in step 312, otherwise the process continues in step 302, where the next verification application in the form of an executable file (122) is executed.

[0063] In step 312, the verified programming tools (110, 112, and 114) are provided. The process continues in step 314.

[0064] In step 314, the process ends.

[0065] In step 316, the processor specification (102) is modified using the pass / fail result or the detailed report, and the processor model (104) is changed. The process continues in step 318.

[0066] In step 318, the programming tools 110, 112, and 114 are redesigned according to the modified processor model (104), and the process continues in step 302.

[0067] Figure 2.b depicts a conceptual structure for verifying simulation tools and the information flow between the various elements of the conceptual structure according to another aspect of the present disclosure.

[0068] In addition to referring to Figure 2a the structures and entities disclosed (not repeated here for brevity), the EDA tool (108) further generates support for the reference entities depicted in block (226) by providing communication connections to entities 226 and 228.

[0069] Figure 4A flow chart of the validation process for simulation tools is depicted. Figure 4 Cited in Figure 1 and Figure 2b The relationship between certain blocks and related text, Figure 1 and Figure 2b The reference numbers of the blocks are in brackets.

[0070] In step 400, verification is initiated by providing verification application(s) in the form of executable(s) (122) and optional port(s) values ​​to both a reference entity (226) and a simulation tool (116, 230). The executable(s) (122) are provided to the reference entity (226) and the simulation tool (116, 230) via an executable driver (236); the optional value(s) of the input port(s) are provided to the reference entity (226) and the simulation tool (116, 230) via an input port driver (238).

[0071] In step 402, the simulation tool (116, 230) executes the executable file (122) and the optional value (s) of the input port, and passes the generated values ​​(232) of the memory (232_2), the register (232_4) and the output port (232_6) to the expected value unit (232). Similarly, the reference entity (226) executes the executable file (122) and the optional value (s) of the input port (s), The values ​​generated by the memory (234_2), the register (234_4) and the output port (234_6) are passed to the monitoring unit (234). The process continues at step 404.

[0072] In step 404, when execution is complete, the values ​​from the memories (232_2) and (234_2) are provided to the comparator (240_2). The expected value unit (232) accesses the simulation tool (116, 230) to take a snapshot of the values ​​in the memory (232_2), and the monitoring unit (234) accesses the reference entity (226) and takes a snapshot of the values ​​in the memory (234_2).

[0073] The comparator (240_2) performs the following functions: steps through the values ​​in the memories (232_2) and (234_2), compares the values ​​between the memories (232_2) and (234_2) at each step, and provides the comparison result to the verification evaluation unit (242).

[0074] Use the same process to obtain the values in registers (232_4) and (234_4), and provide them to comparator (240_4). Comparator (240_4) performs the following functions: Step through the values in register (2324) and register (234_4), compare the values between register (232_4) and register (234_4) in each step, and provide the comparison result to verification evaluation unit (242).

[0075] Use the same process to obtain the values of output ports (232_6) and (234_6), and provide them to comparator (240_6). Comparator (240_6) performs the following functions: Step through the values of the corresponding output ports (232_6) and (234_6), compare the values between output port (232_6) and output port (234_6) in each step, and provide the comparison result to verification evaluation unit (242). This process continues in step 406.

[0076] In step 406, verification evaluation unit (242) evaluates the comparison result. On the one hand, such evaluation can be a fail / pass report. However, the user can further instruct verification evaluation unit (242) to request a more detailed report from expected value unit (232) and monitoring unit (234). Such a report can provide, for example, in the case of a verification failure, the specific values of the differences between expected value unit (232) and monitoring unit (234); the coverage of the instruction set, i.e., the number and / or list of instructions executed; the number and / or list of executed instruction sequences and the number and / or list of unexecuted instruction sequences; register and memory values, and other information known to those of ordinary skill in the art implemented by verification evaluation unit (242). This process continues in step 408.

[0077] In step 408, the fail / pass report is evaluated. If the report is a pass, the process continues in step 410, otherwise the process continues in step 416.

[0078] In step 410, it is evaluated whether all verification applications have been executed in the form of (one or more) executable files (122). If the evaluation result is affirmative, the process continues in step 412, otherwise the process continues in step 402, where the next verification application in the form of executable file (122) is executed.

[0079] In step 412, a verified simulation tool (116) is provided. The process continues in step 414.

[0080] In step 414, the process ends.

[0081] In step 416, the processor specification (102) is modified using the fail / pass results or the detailed report, and the processor model (104) is changed. The process continues in step 418.

[0082] In step 418, the design simulation tool (116) is repeated according to the modified processor model (104), and the process continues in step 402.

[0083] Aspects of the present disclosure are provided to enable those of ordinary skill in the art to implement the present invention. Various modifications to these aspects will be apparent to those of ordinary skill in the art, and the concepts disclosed herein can be applied to other aspects without departing from the spirit or scope of the present invention. Accordingly, the present invention is not intended to be limited to the aspects shown herein, but rather should be accorded the broadest scope consistent with the principles and novel features disclosed herein. By way of example, Figure 3 and Figure 4 One aspect depicts the evaluation of comparison results during the execution of each verification application and subsequent evaluation of the fail / pass report. However, in another aspect, the evaluation of comparison results and / or subsequent evaluation of the fail / pass report is performed after all verification applications have been executed.

[0084] Accordingly, by way of example, those of ordinary skill in the art will understand that the flowcharts are not exhaustive, as certain steps may be added or unnecessary, and / or may be implemented in parallel depending on the particular implementation.

[0085] All structural and functional equivalents of the various illustrative logical blocks, modules, circuits, and algorithm steps described throughout this disclosure, whether known or later developed by those of ordinary skill in the art, are hereby expressly incorporated herein by reference and are intended to be covered by the claims. Such illustrative logical blocks, modules, circuits, and algorithm steps can be implemented as electronic hardware, computer software, or a combination of both.

[0086] Those skilled in the art will appreciate that information and signals can be represented using any of a variety of different technologies. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0087] Moreover, nothing disclosed herein is dedicated to the public, whether or not such disclosure is expressly recited in the claims. No claim element can be construed under the provisions of 35 U.S.C. § 112, paragraph 6, unless the claim element is expressly recited using the phrase "means for" or, in the case of a method claim, the phrase "step for".

Claims

1. A method for programming and / or simulating tools for designing a processor, comprising: Develop a single model of a processor from a grouping including the following: A processor; A hardware description of the processor; And A processor specification that has been confirmed to represent the processor and / or the hardware description; And Automatically generate programming and / or simulation tools for the processor from the single model of the processor and a set of design parameters by means of electronic design automation tools.

2. The method as claimed in claim 1, wherein developing a single model of the processor comprises: Develop the single model in a language that is a description of a unified instruction set and a description of a microarchitecture.

3. The method as claimed in claim 2, wherein the language comprises: Codasip Architecture Language.

4. The method as claimed in claim 1, wherein the set of design parameters is empty.

5. The method as claimed in claim 1, further comprising: Automatically generate a verification environment other than programming and / or simulation tools from the single model of the processor by means of electronic design automation tools; And Verify the programming tool through the verification environment by: Executing at least one verification application and one or more optional port values on a reference entity, thereby resulting in at least one state of at least one resource, each of the at least one state being characterized by at least one value; Determine whether the at least one value characterizing each of the at least one state is consistent with at least one expected value characterizing each of the at least one state; And When it is determined that there is consistency, provide the programming tool for the processor.

6. The method as claimed in claim 5, further comprising: When it is determined that there is no consistency, modify the single model of the developed processor; And Repeat the method as claimed in independent claim 1.

7. The method as claimed in claim 5, wherein the at least one verification application comprises: At least one verification application forms a set of pre-prepared verification applications provided by electronic design automation tools, where each verification application includes at least one expected value.

8. The method as claimed in claim 5, further comprising: Automatically generate a random program generator from the single model of the processor by means of electronic design automation tools; And Generate the at least one expected value and the at least one verification application characterizing each of the at least one state by means of the random program generator.

9. The method as claimed in claim 5, wherein the reference entity is a processor or a third - party emulator.

10. The method as claimed in claim 1, further comprising: Automatically generate a verification environment other than programming and / or simulation tools from the single model of the processor by means of electronic design automation tools; And Verify the simulation tool through the verification environment by: A verification application and one or more optional port values on the simulation tool, thereby resulting in at least one state of at least one resource, each of the at least one state being characterized by at least one first value; Execute the at least one verification application and one or more optional port values on a reference entity, thereby resulting in at least one state of the at least one resource, each of the at least one state being characterized by at least one second value; Determine whether the at least one first value characterizing each of the at least one state is consistent with the at least one second value characterizing each of the corresponding at least one state; And When it is determined that there is consistency, provide the simulation tool for the processor.

11. The method as claimed in claim 10, further comprising: When it is determined that there is no consistency, modify the single model of the developed processor; And Repeat the method as claimed in independent claim 1.

12. The method as claimed in claim 10, wherein verifying the application comprises: At least one verification application forms a set of pre-prepared verification applications provided by electronic design automation tools, where each verification application includes at least one expected value.

13. The method as claimed in claim 10, further comprising: Automatically generate a random program generator from the single model of the processor by means of electronic design automation tools; And Generating, by a random program generator, the at least one expected value and the at least one verification application that characterize each of the at least one state.

14. The method as claimed in claim 10, wherein the reference entity is a processor or a third - party emulator.

15. A non - transitory computer - readable medium having instructions stored thereon that, when executed by a computing device, cause the computing device to perform operations including: Receiving, as an input to an electronic design automation tool, a single model of a processor developed from a group consisting of: A processor; Hardware description of a processor; And A processor specification that is confirmed to represent the processor and / or the hardware description; And Automatically generating, by an electronic design automation tool, programming and / or simulation tools for the processor from a single model and a set of design parameters of the processor.

16. The non - transitory computer - readable medium as claimed in claim 15, wherein the set of design parameters is empty.

17. The non - transitory computer - readable medium as claimed in claim 15, further comprising: Automatically generating, by an electronic design automation tool, a verification environment other than programming and / or simulation tools from a single model of the processor; And Verifying the programming tool through the verification environment by: Executing at least one verification application and one or more optional port values on a reference entity, thereby resulting in at least one state of at least one resource, each of the at least one state being characterized by at least one value; Determining whether the at least one value that characterizes each of the at least one state is consistent with at least one expected value that characterizes each of the at least one state; And Providing the programming tool for the processor when it is determined that there is consistency.

18. The non - transitory computer - readable medium as claimed in claim 17, further comprising: Modifying the single model of the developed processor when it is determined that there is no consistency; And Repeating the method as claimed in independent claim 1.

19. The non-transitory computer-readable medium as claimed in claim 17, wherein the reference entity is a processor or a third-party emulator.

20. The non-transitory computer-readable medium as claimed in claim 15, further comprising: Automatically generating, by an electronic design automation tool, a verification environment other than programming and / or simulation tools from a single model of the processor; And Verifying the simulation tool through the verification environment by: Executing at least one verification application and one or more optional port values on the simulation tool, thereby resulting in at least one state of at least one resource, each of the at least one state being characterized by at least one first value; Executing the at least one verification application and one or more optional port values on a reference entity, thereby resulting in at least one state of the at least one resource, each of the at least one state being characterized by at least one second value; Determining whether the at least one first value that characterizes each of the at least one state is consistent with the at least one second value that characterizes each of the corresponding at least one state; And Providing the simulation tool for the processor when it is determined that there is consistency.

21. The non-transitory computer-readable medium as claimed in claim 20, further comprising: Modifying the single model of the developed processor when it is determined that there is no consistency; And Repeating the method as claimed in independent claim 1.

22. The non-transitory computer-readable medium as claimed in claim 20, wherein the reference entity is a processor or a third-party emulator.

Images