Method for automatically designing and verifying programming and simulation tools of processor

Abstract

To provide a method for automatically designing and verifying programming and simulation tools of a processor.SOLUTION: A method for designing programming and / or simulation tools for a processor, the method comprising: developing a single model of the processor from a group, the group consisting of the processor, a hardware description of the processor, and a specification of the processor which has been verified to represent the processor and / or the hardware description; and automatically generating, by an electronic design automation tool, the programming and / or simulation tools for the processor from the single model of the processor and a set of design parameters. The method further includes verifying the programming tool and / or the simulation tools of the processor using the verification application and the reference entity.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] 1. Field The present invention relates to the design of processor programming tools and / or simulation tools. More particularly, the present invention relates to the design and optional verification of programming tools and / or simulation tools for a processor.

Background Art

[0002] 2. Description of Related Art It is common for a processor to be supplied with a collection of programming tools and optionally simulation tools that are specific to that processor and thus facilitate the creation and simulation of applications executed by the processor. During the life of the processor, the collection of programming tools and / or simulation tools can be redesigned by adding new features, functions, and other improvements known to those skilled in the art. Such redesigns are currently performed by human designers manually rewriting parts, for example, a compiler, assembler, simulator, or the entire set of programming tools and / or simulation tools.

[0003] These improvements are intended for an already developed processor whose specifications cannot be changed, so it is prudent to verify that the improvements function correctly on that processor. Such verification is performed by a human designer manually constructing a verification application using the redesigned programming tools 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 verification applicant on the processor and / or simulator.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Redesign and verification are largely carried out by manual, non - automated human designer involvement and are thus susceptible to errors and lack of completeness. Therefore, there is a need for a way to address the problems disclosed above and other problems in the current modes of redesign and verification known to those skilled in the art.

Means for Solving the Problems

[0005] In one aspect of the present disclosure, a method for automating the design and optionally verification of programming tools and / or simulation tools for an existing processor is disclosed in accordance with the appended independent claims. Additional aspects are disclosed in the dependent claims.

[0006] The above - described aspects described herein, when interpreted in conjunction with the accompanying drawings, will become more readily apparent by reference to the following description.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2a

Figure 2b

Figure 3

Figure 4

Modes for Carrying Out the Invention

[0008] Descriptions of similar structural elements between figures are not repeated, and similar elements have reference numbers that differ by integer multiples of 100. That is, the reference number 100 in Figure 1 becomes the reference number 200 in Figure 2a unless differences and / or alternative aspects are clearly shown. The expression "_X" in a reference indicates an instance of an element of a drawing where it is helpful for better understanding. A double line indicates an entity generated by the entity from which the double line originated, and any unlabeled single or double arrowed line indicates a possible flow of information between the illustrated entities.

[0009] Unless otherwise noted, all terms used in this specification (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It should be further understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning associated with the relevant art and this disclosure.

[0010] As used in this specification, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprising", "comprises", and / or "comprising" when used in this specification 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.

[0011] As used in this specification, the term design of a processor is intended to refer to the design of a representation of a physical device, such as a hardware description and programming tools and / or simulation tools.

[0012] The various disclosed aspects may be presented 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 described herein.

[0013] For the various aspects of the present invention, unless otherwise specified, this specification will be described with reference to the drawings which are schematic diagrams of the conceptual configuration of the present invention. The various aspects of this disclosure are provided to enable those skilled in the art to practice the present invention. Changes to the various aspects presented throughout this disclosure will be readily apparent to those skilled in the art, and the concepts disclosed herein can be extended to other applications.

[0014] The concepts of processor design and verification disclosed in the specification of Application No. 17 / 224,898, filed on April 14, 2021, entitled "A METHOD FOR AUTOMATIC PROCESSOR DESIGN, VALIDATION, AND VERIFICATION", which is incorporated herein by reference. Those skilled in the art will understand that the present disclosure, which will hereinafter describe the design and optional verification of programming tools and / or simulation tools for a processor, is for the purpose of understanding the overall concept, and the present invention is applicable to the extent that a hardware description of a processor or a processor specification representing a processor or a hardware description is available.

[0015] As is well known to those skilled in the art, the complex task of processor design has led to the development of electronic design automation (EDA) tools that automate the tasks of processor design, verification, and validation, and generate hardware descriptions according to processor specifications in programming tools and / or simulation tools, such as high-level programming languages (HLLs) and related compilers, assemblers, simulators, debuggers, profilers, and hardware description languages, such as VHSIC Hardware Description Language (VHDL), Verilog®, SystemVerilog, and other languages known to those skilled in the art. To describe the instruction set and microarchitecture of a processor, an Architecture Description Language (ADL) has been developed. ADLs can be classified as ALDs that use templates and general-purpose ADLs. The first category, i.e., ADLs that use templates, allows modification of a limited part of the processor. An example of an ADL that uses a template is Tensilica® Instruction Extension (TIE), which is further restricted to customizing the Xtensa® processor core architecture. The second category, i.e., general-purpose ADLs, allows modification of any part of the processor. Examples of general-purpose ADLs are Instruction Set Architecture Language (LISA), nML, and Codasip Architecture Language (CodAL), versions 1 and 2 of Codasip, GmbH.

[0016] The latter category provides two models or views for the processors being designed with different levels of abstraction. The first level of abstraction is represented by the instruction accurate model (IA), which is simpler and targets design space exploration (DSE), i.e., the exploration of an optimal instruction set. The IA model is mainly aimed at describing the instruction set architecture (ISA) and defines instructions with limited implementation details. Although hardware cannot be generated from the IA model, it is suitable for generating at least some of the programming tools and simulation tools.

[0017] The second level of abstraction, represented by cycle accuracy (CA), targets the microarchitecture design of the target hardware technology. From the CA model, a processor hardware description is generated in a hardware description language.

[0018] Due to the limitations of the ADL, namely, the lack of recognition of at least some details of the IA model in the CA model, the potential differences in instruction implementation between the IA model and the CA model, and the inability to handle programs correctly, a new type of architecture description language has been developed. In such a language, for example, the processor specification 102 can be described as the design of a single processor model 104 that combines two levels of abstraction by interleaving. In other words, the language is designed to be able to integrate the instruction set description with the description of the microarchitecture details. That is, the description of an instruction includes information about when and where the operands of the instruction are provided, which functional unit executes the instruction, the timing of the instruction, and when and where the result is provided. An example of a new type of language that enables the development of a single model is the version 3 of the Codasip Architecture Language (CodAL) developed by Codasip GmbH. Since the identification information of the version can be subject to change, a new type of language that enables the development of a single model is hereinafter referred to as the Codasip Architecture Language.

[0019] FIG. 1 shows a conceptual structure for designing and optionally verifying a programming tool and / or a simulation tool for a processor and the flow of information between the elements of the conceptual structure. The elements include blocks and / or hardware or software entities that implement the functions of the blocks.

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

[0021] The single-processor model 104 is written using an architecture description language, such as the Codasip architecture language, that enables the development of a single model based on the processor specification 102. Once the processor is designed, in one aspect, the single-processor model 104 developed from the final processor specification 102 may already be available.

[0022] In another aspect, if such a single-processor model 104 is not available and the final processor specification 102 specified for the manufacture of the processor, i.e., the processor specification or processor hardware specification that has been confirmed to correctly describe the processor, is available, the single-processor model 104 can be developed from this final processor specification 102.

[0023] In yet another aspect, if the final specification 102 is not available, the single-processor model 104 can generally be developed from available hardware descriptions. In the case of a simple hardware description, such a single-processor model 104 can be directly described in a language that enables the development of a single model, such as the Codasip architecture language. In the case of a hardware description determined to be too complex for such direct description, the processor specification 102 is first developed from the hardware description, and then the processor specification 102 is described in a language to obtain the single-processor model 104.

[0024] In yet another aspect, in the event that neither the final processor specification 102 nor the hardware description is available, reverse engineer the portions of the existing processor necessary to obtain a description of the microarchitecture, instruction set, and semantics, either of the processor specification 102 or the hardware description, and thus it is still possible to develop the single-processor model 104 as described above. The portions to be reverse engineered include, for example, the pipeline depth, handling of control and structural hazards, the number of functional units the processor has, and other portions known to those skilled in the art.

[0025] The Codasip architecture language has been developed by adding new features. Thus, even if a single-processor model 104 is available, it may still be beneficial to redevelop the single-processor model to utilize these new features using a new version of the Codasip architecture language. The developers of Codasip, GmbH, which is the Codasip architecture language, have internal procedures to ensure the correct functionality of the Codasip architecture language.

[0026] Regardless of how the single-processor model 104 is obtained, the single-processor model 104 includes a description of the processor's microarchitecture, instruction set, and semantics. Thus, as described above, the programming tools and / or simulation tools generated by EDA from the single-processor model 104 also recognize the processor's microarchitecture, instruction set, and semantics.

[0027] In addition to the single-processor model 104, the user may specify optional design parameters 106 that affect the behavior of the EDA tool 108. As an example, such parameters may include, for example, parameters that instruct the EDA tool 108 to, e.g., the size of the memory to be simulated, the optimal level to improve the simulation speed, or the default compile flags of the programming tool. The optionality may be implemented in different ways. For example, in one aspect, the EDA tool 108 requires a set of design parameters, which may be empty or may include at least one parameter. In another aspect, the EDA tool 108 may check whether optional design parameters 106 exist and proceed accordingly.

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

[0029] 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, by code size optimization. In another aspect, the linker 114 can be a stand-alone tool common to all different processor models 104. The EDA tool 108 optionally generates additional utility tools (not shown), for example, tools that identify attributes of the compiled executable file, such as information about the size of data, debug information generated by the compiler, such as tools that parse call stack reconstruction and any additional information known to those skilled in the art.

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

[0031] Verification of the redesigned programming tools 110, 112, 114 and / or simulation tool 116 is not strictly necessary but is desirable. The development of the single-processor model 104 is error-prone because it is performed by manual non-automatic coding by a human designer using the Codasip architecture language. Thus, the programming tools 110, 112, 114 and / or simulation tool 116 generated from the single-processor model 104 and optional design parameters 106 may similarly contain errors. Further, 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. As an example, consider a case where the processor microarchitecture is not designed to handle data hazards. That is, the processor microarchitecture does not include a structure for handling data hazards, and instead, it is expected that the handling of data hazards will 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 optionally insert necessary instructions, such as no-operation instructions, so that the executable file 122 does not contain any data hazards with respect to the processor microarchitecture.

[0032] Such an omission of such a structure in the processor microarchitecture may be intentional. For example, a human designer may decide to replace more complex hardware with the need to handle data hazards by software executed by the processor. If not handled, such data hazards will prevent the execution of instruction i2 that depends on the completion of the execution of instruction i1 immediately preceding instruction i2. If instruction i2 does not observe the dependency on the preceding instruction i1, such non-observance may lead to incorrect results.

[0033] The executable file may include any subset of the processor instruction set, including the full set, and the instructions may be in any order to fully authenticate programming 110, 112, 114 and / or simulation tool 116, so it is desirable to test every possible sequence of instructions.

[0034] Programming tools 110, 112, 114 and / or simulation tool 116 are verified by one or more verification applications. The verification application includes a prologue, a body, and an epilogue. The application prologue is the part of the application that sets the initial state of the application, i.e., initializes registers, initializes memory, initializes ports, initializes interrupt or exception routines, and other settings known to those skilled in the art. The body includes at least one sequence of at least one instruction used for verifying the generated programming tools 110, 112, 114 and / or simulation tool 116. The application epilogue is the part of the application that sets the state of the application after the processing of the body, e.g., stops the simulation tool, reads the values of the processor resources, and other states known to those skilled in the art. Processor resources may include, for example, registers, memory, ports, and other resources known to those skilled in the art.

[0035] There are several possible sources of verification applications. In one aspect, a set of pre-prepared verification applications is provided along with the EDA tool 108. In another aspect, a third party provides a set of pre-prepared verification applications. From the user's perspective, the difference is that the former is free, while the latter may require additional arrangements such as licensing, purchasing, etc. In both cases, such a set of verification applications is hand-coded either by the provider of the EDA tool 108 or a third party. In both aspects, the verification application can be written in HLL 118 or assembly language 120. In yet another aspect, an optional random program generator 124 generates the verification application in assembly language 120. In all of the above aspects, the entity providing the verification application needs to ensure that the verification application provides the processor resources in a correct state, i.e., the state of the processor resources resulting from the execution of the verification application. Such an assurance is hereinafter referred to as self-checking.

[0036] The self-checking function is enabled by knowledge of the instruction set and knowledge of the microarchitecture details based on the single-processor model 104 and optional design parameters 106. That is, the state of the processor resources is specified based on the semantics of the instruction set and the microarchitecture. Therefore, during the execution of at least one instruction sequence, it is possible to generate a verification application that is compiled into an executable file 122 that may include at least one sequence of at least one instruction, along with the calculated state of the processor resources at any time. By comparing the state of the processor resources with the calculated state, the accuracy of the programming 110, 112, 114 tools and the simulation tool 116 can be verified.

[0037] The number of instructions in at least one instruction sequence that constitutes a verification application depends on the verification target. As an example, depending on the instruction, some may be verified as a sequence including a single instruction, for example, a LOAD instruction, while others may include a sequence including multiple instructions. For example, an ADD instruction requires a preceding instruction that sets the value on which the ADD instruction to be verified depends. Logically, of course, since it is impossible to actually meet such verification targets, the use of a set of pre-prepared verification applications provided by a human designer's handwritten verification application or an EDA tool 108 will be limited. Therefore, in one aspect of the present invention, using a random program generator 124 to automatically generate at least one instruction sequence (ideally every possible sequence of instructions) utilizes the power of another processor (different from the processor in which the programming 110, 112, 114 and the simulation tool 115 are redesigned) or the power of a computer that can execute the function of the random program generator 124 any number of times. Furthermore, the absence of human involvement ensures the generation of at least one instruction sequence without errors.

[0038] A set including a single verification application including all required instruction sequences can be used, but it may be beneficial to provide a set including multiple verification applications to facilitate easier interpretation of the results and correction of potential errors.

[0039] The state of each processor resource can be characterized by one or more values obtained by each resource during the execution of the verification application. Similarly, the calculated state of each processor resource is characterized by one or more expected values 126. The one or more expected values may be incorporated into the verification application itself or the one or more expected values may be located in a storage 126 separate from the verification application. This also applies if the execution is affected by external events. Thus, as an example, considering an external event including an interrupt as described above, the processor must stop the execution of the instruction sequence, save the state of the resources at the time of the interrupt, process the interrupt, and resume the execution of the instruction sequence in the restored state of the processor.

[0040] The programming tools 110, 112, and 114 generated by the EDA tool 108 need not include a specific microarchitecture structure that is not necessary for the functions of the programming tools 110, 112, and 114. As an example, the functions of the programming tools 110, 112, and 114 do not need to recognize the microarchitecture of the branch predictor, a specific implementation of the protocol for ensuring communication with the memory, and other microarchitecture structures known to those skilled in the art, and thus do not include them. In contrast, the simulation tool 116 includes all microarchitecture structures.

[0041] The EDA tool 108 further generates a verification environment 128 from the single-processor model 014 and optional design parameters 106. The generated environment 128 includes a program that specifies the use of a set of tools, libraries, and / or functions designed to support verification. In particular, the verification environment program 128 creates instances of drivers and computational entities and defines the relationships between them, as disclosed below with reference to FIG. 2a. A driver is a software program that operates and / or controls a particular device / unit within the verification environment that is attached to the driver. And the verification environment 128 instructs the set of tools, libraries, and / or functions on how the driver should access the conceptual entities and how to execute any verification tests. As an example, such a set of tools, libraries, and / or functions may include the tools, libraries, and / or functions supplied by the EDA tool 108. Alternatively, such a set of tools may include third-party tools, such as the Universal Verification Methodology (UVM) libraries and tools provided by Mentor Graphics' ModelSim, and other tools and functions known to those skilled in the art.

[0042] Since the random program generator 124 is generated by the EDE tool 108 as described above, it recognizes the instruction set and semantics as well as the microarchitecture of the processor model 104. Accordingly, the random program generator 124 may generate at least one expected value corresponding to the state of each of the resources 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 yields the at least one expected value.

[0043] The term "expected value" refers to the value of the state of the resources of the processor model 104 when at least one instruction sequence is executed. If at least one sequence contains two or more instructions, the random program generator 124 may 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 as well as the corresponding instruction sequences utilizes a satisfiability modulo theory (SMT) solver, and the values are stored in the expected value 126 storage. Thanks to this approach, a reference model is not necessary. The functionality of the random program generator 124 can be controlled by a parameter set. Thus, by specifying different parameters, the user can influence the content of the verification application, e.g., the number of instruction sequences, the number of instructions in each sequence, and other parameters known to those skilled in the art.

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

[0045] FIG. 2a shows a conceptual diagram of the automatic design and subsequent verification of the programming tools 110, 112, and 114 and / or the simulation tool 116 and the flow of information between the elements of the conceptual structure, according to one aspect of the present disclosure. The elements include hardware or software entities that implement the structure and its functionality. Block references in FIG. 1 are in parentheses to clarify the relationships between specific blocks in FIG. 1 with reference to FIG. 2a and the related text.

[0046] As described above, the verification environment 228 is a program that includes instructions for a set of tools, libraries, and / or functions designed to support verification. In one aspect, the verification environment 228 is communicatively coupled to the structure and receives the expected values and optionally intermediate expected values, shown together as unit 224, and is communicatively coupled to the reference entity 226. In another aspect, the verification environment 228 includes the structure 224 and the reference entity 226. The EDA tool (108) further generates verification support, such as structures 232, 234, or 242, which will be described in detail later. As described above, the expected value (126) is provided by the verification application to the storage within the expected value unit 224, whereby the expected result unit 232 can access the expected value (126). The values of the processor resources generated by the reference entity 226 can be stored in the monitor unit 234 for further evaluation.

[0047] Each of the expected result unit 232 and the monitor unit 234 includes at least one processor resource that characterizes a processor. Such a configuration enables the verification of a single processor resource. FIG. 2a shows only the processor resources: memories 232_2, 234_2, registers 232_4, 234_4 (including a register file), and output ports 232_6, 234_6, which is for illustrative purposes only, and any processor resource or hardware component known to those skilled in the art is contemplated. The memory is a simulated representation of any physical device used to temporarily or permanently store instructions and / or data as implemented by a processor. A register is a simulated representation of a small amount of (fast) storage that is (typically) addressed by a mechanism other than main memory and can thus be accessed more quickly. Registers 232_4, 234_4 represent both architectural registers, i.e., registers exposed to the programmer, and microarchitectural registers, i.e., registers not provided to the programmer but used internally by the processor. A port is a simulated representation of any physical input / output port used to pass information to other components connected to the processor.

[0048] To enable the execution of the executable file (122) by the reference entity 226, the EDA tool (108) further generates an executable file driver 236. Additionally, some executable files require that the values of the input ports provided by the verification application be received by the reference entity 226. Such input port values may include interrupts, data to be processed, and / or any other input known to those skilled in the art. Accordingly, the EDA tool (108) further generates an optional receive port driver 238.

[0049] FIG. 3 shows a flowchart of the programming verification process. To clarify the relationship between the specific blocks of FIGS. 1 and 2 referred to in FIG. 3 and the related text, the block references of FIGS. 1 and 2a are in parentheses.

[0050] In step 300, the verification is started by providing a verification application in the form of an executable file (122) and optional port values. The executable file (122) is provided to the reference entity (226) via the executable file driver (236), and the optional values of the input ports are provided to the reference entity (226) via the input port driver (238), and the expected value (126) is provided to the block (224).

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

[0052] 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 storage (224), takes a snapshot of the value in the memory (232_2), and the monitor unit (234) accesses the reference entity (226) and takes a snapshot of the value in the memory (234_2).

[0053] The comparator (240_2) steps through the values in the memories (232_2) and (234_2), compares the value in the memory (232_2) with the value in the memory (234_2) - at each step - and executes a function that provides the result of the comparison to the verification evaluation unit (242).

[0054] Using the same procedure, the values in registers (232_4) and (234_4) are obtained, and these values are provided to comparator (240_4). Comparator (240_4) steps through the values in registers (232_4) and (234_4), compares the value in register (232_4) with the value in register (234_4) - at each step - and executes a function that provides the result of the comparison to verification evaluation unit (242).

[0055] Using the same procedure, the values in output ports (232_6) and (234_6) are obtained, and these values are provided to comparator (240_6). Comparator (240_6) steps through the values of the corresponding output ports (232_6) and (234_6), compares the value of output port (232_6) with the value of output port (234_6) - at each step - and executes a function that provides the result of the comparison to verification evaluation unit (242). The process continues to step 306.

[0056] In step 306, verification evaluation unit (242) evaluates the result of the comparison. In one aspect, such an evaluation can be a pass / fail report. However, the user may further instruct verification evaluation unit (242) to request a more detailed report from expected value unit (232) and monitor unit (234). Such a report may provide, for example, specific values that differ between expected value unit (232) and monitor unit (234) if the verification fails; 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 instruction sequences not executed; register values and memory values; and other information known to those skilled in the art implemented by verification evaluation unit (242). The process continues to step 308.

[0057] In step 308, the pass / fail report is evaluated. If the report passes, the process proceeds to step 310; otherwise, the process proceeds to step 316.

[0058] In step 310, evaluate whether all verification applications in the form of executable files (122) have been executed. If the evaluation is affirmative, the process continues to step 312; otherwise, the process continues to step 302, where the next verification application in the form of an executable file (122) is executed.

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

[0060] In step 314, the process ends.

[0061] In step 316, the pass / fail results or detailed reports are used to revise the processor specification (102) and change the processor model (104). The process continues to step 318.

[0062] In step 318, the design of the programming tools 110, 112, and 114 with the revised processor model (104) is repeated, and the process continues to step 302.

[0063] FIG. 2b shows a conceptual structure for verifying a simulation tool and the flow of information between the elements of the conceptual structure, according to another aspect of the present disclosure.

[0064] In addition to the structures and entities disclosed with reference to FIG. 2a, which are not repeated here for brevity, the EDA tool (108) further generates support for the reference entities shown in block (226) by providing communication connections with entities 226 and 228.

[0065] FIG. 4 shows a flowchart of the verification process of the simulation tool. To clarify the relationship between specific blocks of FIGS. 1 and 2b referred to in FIG. 4 and the related text, the block references of FIGS. 1 and 2b are in parentheses.

[0066] In step 400, verification is initiated by providing the verification application in the form of an executable file (122) and optional port values to both the reference entity (226) and the simulation tools (116, 230). The executable file (122) is provided to the reference entity (226) and the simulation tools (116, 230) via the executable file driver (236), and the optional values of the input ports are provided to the reference entity (226) and the simulation tools (116, 230) via the input port driver (238).

[0067] In step 402, the simulation tools (116, 230) execute the executable file (122) and the optional values of the input ports, and pass the generated values (232) of the memory (232_2), registers (232_4), and output ports (232_6) to the expected value unit (232). Similarly, the reference entity (226) also executes the executable file (122) and the optional values of the input ports, and passes the generated values of the memory (234_2), registers (234_4), and output ports (234_6) to the monitor unit (234). The process continues to step 404.

[0068] In step 404, upon completion of the execution, 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 tools (116, 230) and takes a snapshot of the values in the memory (232_2), and the monitor unit (234) accesses the reference entity (226) and takes a snapshot of the values in the memory (234_2).

[0069] The comparator (240_2) steps through the values in the memories (232_2) and (234_2), compares the value in the memory (232_2) with the value in the memory (234_2) - at each step - and executes a function that provides the result of the comparison to the verification evaluation unit (242).

[0070] Using the same procedure, the values in registers (232_4) and (234_4) are obtained, and these values are provided to comparator (240_4). Comparator (240_4) steps through the values in registers (232_4) and (234_4), compares the value in register (232_4) with the value in register (234_4) - at each step - and executes a function that provides the result of the comparison to verification evaluation unit (242).

[0071] Using the same procedure, the values in output ports (232_6) and (234_6) are obtained, and these values are provided to comparator (240_6). Comparator (240_6) steps through the values of the corresponding output ports (232_6) and (234_6), compares the value in output port (232_6) with the value in output port (234_6) - at each step - and executes a function that provides the result of the comparison to verification evaluation unit (242). The process continues to step 406.

[0072] At step 406, verification evaluation unit (242) evaluates the result of the comparison. In one aspect, such an evaluation can be a pass / fail report. However, the user may further instruct verification evaluation unit (242) to request a more detailed report from expected value unit (232) and monitor unit (234). Such a report can provide, for example, specific values that differ between expected value unit (232) and monitor unit (234) if the verification fails; 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 instruction sequences that were not executed; register values and memory values; and other information known to those skilled in the art implemented by verification evaluation unit (242). The process continues to step 408.

[0073] At step 408, the pass / fail report is evaluated. If the report is a pass, the process proceeds to step 410; otherwise, the process proceeds to step 416.

[0074] In step 410, it is evaluated whether all verification applications in the form of executable files (122) have been executed. If the evaluation is affirmative, the process proceeds to step 412; otherwise, the process proceeds to step 402, where the next verification application in the form of an executable file (122) is executed.

[0075] In step 412, a verified simulation tool (116) is provided. The process proceeds to step 414.

[0076] In step 414, the process ends.

[0077] In step 416, a fail / pass result or a detailed report is used to revise the processor specification (102) and change the processor model (104). The process proceeds to step 418.

[0078] In step 418, the design of the simulation tool (106) by the revised processor model (104) is repeated, and the process proceeds to step 402.

[0079] Various aspects of the present disclosure are provided to enable those skilled in the art to practice the invention. Various changes to these aspects will be readily apparent to those skilled in the art, and the concepts disclosed therein can be applied to other aspects without departing from the spirit or scope of the invention. Accordingly, the invention is not limited to the aspects shown herein and is intended to be accorded the widest scope consistent with the principles and novel features disclosed herein. As an example, FIGS. 3 and 4 show one aspect in which when each verification application is executed, an evaluation of the comparison result and a subsequent evaluation of the fail / pass report are performed. However, in another aspect, the evaluation of the comparison result and / or the subsequent evaluation of the fail / pass report are performed after all verification applications have been executed.

[0080] Accordingly, as an example, one of ordinary skill in the art will understand that the flowchart is not exhaustive because certain steps may be added or unnecessary and / or may be executed in parallel based on a particular embodiment.

[0081] All structural and functional equivalents of the various exemplary logical blocks, modules, circuits, and algorithm steps described throughout this disclosure that are known or later become known to one of ordinary skill in the art are hereby expressly incorporated herein by reference and are intended to be encompassed by the claims. Such exemplary logical blocks, modules, circuits, and algorithm steps may be implemented as electronic hardware, computer software, or any combination thereof.

[0082] One of ordinary skill in the art will further understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof.

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

Claims

1. A method for designing a programming tool and / or a simulation tool for a processor, comprising: developing a single model of the processor from a group, the group comprising: the processor, a hardware description of the processor, and a specification of the processor that has been confirmed to represent the processor and / or the hardware description; generating, by an electronic design automation tool, the programming tool and / or the simulation tool for the processor automatically from the single model and a set of design parameters of the processor; and a method comprising the above.

2. The developing of the single model of the processor comprises: developing the single model in a language designed to integrate a description of an instruction set and a description of a microarchitecture, the method according to claim 1.

3. The language includes a Codasip architecture language, the method according to claim 2.

4. The set of design parameters is empty, the method according to claim 1.

5. In addition to the programming tool and / or the simulation tool from the single model of the processor by the electronic design automation tool, automatically generating a verification environment; verifying the programming tool by the verification environment, executing at least one verification application and optional port values on a reference entity, thereby generating 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 each of the at least one value characterizing each of the at least one state matches at least one expected value characterizing each of the at least one state; and providing the programming tool for the processor when the determination indicates a match; verifying by doing the above; and the method according to claim 1 further comprising the above.

6. When the determination does not indicate a match, modifying the developed single model of the processor; repeating the method according to independent claim 1; and the method according to claim 5 further comprising the above.

7. The at least one verification application is The method according to claim 5, wherein at least one verification application forms a set of pre-prepared verification applications provided by the electronic design automation tool, and each verification application includes at least one expected value.

8. Automatically generating a random program generator from the single model of the processor by the electronic design automation tool; Generating, by the random program generator, at least one expected value characterizing each of the at least one verification application and the at least one state; The method according to claim 5, further comprising:

9. The method according to claim 5, wherein the reference entity is the processor or a third-party simulator.

10. Automatically generating, by the electronic design automation tool, a verification environment in addition to the programming and / or the simulation tool from the single model of the processor; Verifying the simulation tool by the verification environment, generating, by the simulation tool, at least one state of at least one resource, each of the at least one state being characterized by at least one first value, for verification applications and optional port values in the simulation tool; verifying; executing the at least one verification application and the optional port values on a reference entity, thereby generating 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 at least one first value characterizing each of the at least one state matches at least one second value characterizing the corresponding at least one state; when the determination indicates a match, providing a simulation tool for the processor; The method according to claim 1, further comprising:

11. when the determination does not indicate a match, modifying the developed single model of the processor; repeating the method according to independent claim 1; The method according to claim 10, further comprising:

12. The verification application is The method of claim 10, wherein at least one verification application forms a set of pre-prepared verification applications provided by the electronic design automation tool, and each verification application includes at least one expected value.

13. Automatically generating, by the electronic design automation tool, a random program generator from the single model of the processor; Generating, by the random program generator, the at least one verification application and the at least one expected value characterizing each of the at least one state; The method of claim 10, further comprising:

14. The method of claim 10, wherein the reference entity is the processor or a third-party simulator.

15. A non-transitory computer-readable medium storing instructions that, when executed by a computing device, cause the computing device to perform operations, the operations comprising: Receiving, as an input to an electronic design automation tool, a single model of a processor developed from a group, the group comprising: The processor; A hardware description of the processor; and A specification of the processor that has been confirmed to represent the processor and / or the hardware description Receiving; Automatically generating, by the electronic design automation tool, a programming tool and / or a simulation tool for the processor from the single model of the processor and a set of design parameters; A non-transitory computer-readable medium comprising:

16. The method of claim 15, wherein the set of design parameters is empty.

17. Automatically generating, by the electronic design automation tool, a verification environment in addition to the programming tool and / or the simulation tool from the single model of the processor; Verifying the programming tool by the verification environment; Executing at least one verification application and optional port values on a reference entity, thereby generating 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 at least one value characterizing each of the at least one state matches at least one expected value characterizing each of the at least one state, and providing a programming tool for the processor when the determination indicates a match verifying by performing; The non-transitory computer-readable medium according to claim 15, further comprising.

18. when the determination does not indicate a match, changing the developed single model of the processor, and repeating the method according to independent claim 1; The non-transitory computer-readable medium according to claim 17, further comprising.

19. The non-transitory computer-readable medium according to claim 17, wherein the reference entity is the processor or a third-party simulator.

20. automatically generating a verification environment by the electronic design automation tool in addition to the programming and / or simulation tool from the single model of the processor, and verifying the simulation tool by the verification environment, executing at least one verification application and optional port values on the simulation tool, thereby generating 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; executing at least one verification application and optional port values on a reference entity, thereby generating at least one state of at least one resource, each of the at least one state being characterized by at least one second value, executing; determining whether at least one first value characterizing each of the at least one state matches at least one second value characterizing each of the corresponding at least one state; providing a simulation tool for the processor when the determination indicates a match; The non-transitory computer-readable medium according to claim 15, further comprising.

21. when the determination does not indicate a match, changing the developed single model of the processor, and repeating the method according to independent claim 1; The method according to claim 20, further comprising.

22. The method according to claim 20, wherein the reference entity is the processor or a third-party simulator.

Images