Verification of the Hardware Design of Data Transformation Pipeline

Abstract

A method and system for verifying a hardware design of a data transformation pipeline by formal verification, the data transformation pipeline comprising one or more data transformation elements that perform data transformations on one or more inputs, wherein the formal verification is performed under conditions that simplify the data transformation calculations that a formal verification tool must perform. In one embodiment, the hardware design of the data transformation pipeline is verified by replacing one or more of the data transformation elements in the hardware design with functional elements that are treated by the formal verification tool as unevaluated functions of their combined inputs such that during formal verification, the functional elements produce the same outputs for the same inputs; and formally verifying that, for each transaction in a set of transactions, an instantiation of the modified hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs for the transaction.

Description

Background Art

[0001] Many electronic devices, such as system on chip (SoC), include hardware to implement data transformation pipeline. As known to those skilled in the art, the pipeline includes a set of processing elements, wherein the output of the processing elements in the set is the input to the processing elements in the set. A data transformation pipeline is a pipeline configured to perform data transformation on a set of one or more inputs. The term "data transformation" is used herein to represent any operation (e.g., mathematical operation, such as but not limited to arithmetic operation, including addition, subtraction, multiplication, division, etc.) that can be performed or applied to a data set to generate new data. Therefore, the data transformation pipeline receives a set of one or more inputs and outputs the result of performing data transformation on the set of inputs. The data transformation pipeline includes at least one data transformation element, which is configured to perform data transformation on a set of inputs, but it may also include other types of processing elements. When a pipeline generates output for a set of inputs, the pipeline is said to perform a "transaction". Therefore, if a pipeline generates output for the same set of inputs, the pipeline is said to perform the same transaction.

[0002] The data transformation pipeline may be a linear or non-linear pipeline and may have a single processing element or multiple processing elements. Figure 1-3 An example data transformation pipeline is shown that is configured to perform arithmetic calculations on a set of inputs. Figure 1 A first example data transformation pipeline 100 is shown that is configured to compute the sum of eight inputs (a0+a1+a2+a3+a4+a5+a6+a7). Figure 1 The data transformation pipeline 100 includes a single data transformation element 102, a register 104, and a control logic 106. The data transformation element 102 receives an input a in each of eight cycles (numbered 0 to 7). i , and compare this input with the previous input b i The control logic 106 is configured to provide the value of the register 104 to the data transformation element 102 in each cycle and output the value of the register 104 after the eighth cycle (i.e., after the sum a0+a1+a2+a3+a4+a5+a6+a7 has been generated). The control logic 106 is also configured to set the value of the register 104 to 0 when reset and after the value of the register 104 is output. The data transformation element 102 is configured to generate two inputs (a1+a2+a3+a4+a5+a6+a7) in a single cycle. i and b i), the output of the pipeline can be expected to be output after eight cycles. However, there may be random external events, such as stalls or interrupts, which can affect the movement of data through the pipeline by one or more clock cycles.

[0003] Figure 2 A second example data transformation pipeline 200 configured to calculate (a+b)*c is shown. The data transformation pipeline 200 includes two data transformation elements 202, 204, a register 206, and a control logic 208. The first data transformation element 202 is configured to calculate the sum of inputs a and b and store the sum y in the register 206. The second data transformation element 204 is configured to calculate the product of the value of the register 206 (i.e., the output y of the first data transformation element 202) and the input c. The control logic 208 controls the operation of the register 206 to ensure that the value of the register 206 is provided to the second data transformation element 204 at the correct time.

[0004] Figure 3 A third example data transformation pipeline 300 is shown configured to calculate (a+b). The data transformation pipeline 300 includes two processing elements 302, 304, a register 306, and control logic 308. The first processing element 302 is a data transformation element configured to calculate the sum of inputs a and b. The second processing element 304 is not a data transformation element because it does not transform the data input to it, it only stores the value of the register 306 (i.e., the output of the data transformation element 302) y until the downstream component requests the result. The control logic 308 controls the operation of the register 306 to ensure that the value of the register 306 is provided to the second processing element 304 at the correct time.

[0005] Generating hardware to implement a data transformation pipeline typically includes developing a hardware design that describes the structure and / or functionality of an integrated circuit that implements the data transformation pipeline; verifying or testing the hardware design to ensure that an integrated circuit manufactured according to the design will operate as expected; and once verified, manufacturing the integrated circuit in an integrated circuit manufacturing system according to the hardware design.

[0006] In some cases, verifying the hardware design of the data transformation pipeline can include verifying that an instantiation of the hardware design produces correct results for the data transformation regardless of when the transformation is performed. Specifically, because the data transformation pipeline can execute the transformation at any time after reset (e.g., immediately after reset, or, for example, 10,000 cycles after reset) and with a variable amount of latency (e.g., due to stalls or interruptions), it is important to verify that the instantiation of the hardware design produces correct results for the transformation regardless of when the transformation is performed.

[0007] In other cases, verifying the hardware design of the data transformation pipeline may include verifying that an instantiation of the hardware design always (regardless of when the transformation is performed) produces the same results as an instantiation of another similar hardware design. This type of verification may be referred to as verifying that the hardware designs are functionally equivalent. This type of verification may be used when modifying an original hardware design to verify that the modified hardware design produces the same results as the original hardware design.

[0008] A hardware design can be verified, for example, by formal verification or simulation-based verification. Formal verification is a systematic process of verifying a hardware design using a mathematical model of the hardware design and mathematical reasoning. In contrast, simulation-based verification is a process in which a hardware design is tested by applying a stimulus to an instantiation of the hardware design and monitoring the output of the instantiation of the hardware design in response to the stimulus.

[0009] In formal verification, the hardware design is converted into a mathematical model (e.g., a state transition system or a flow chart), thereby providing an instantiation of the hardware design that can be tested to verify the hardware design, using mathematical logic, using a precise syntax, or using a language with precise mathematical syntax and semantics, to express the formal properties to be verified.

[0010] Formal verification is performed using a formal verification tool (i.e., a software tool capable of performing formal verification of hardware designs). Formal verification tools include, but are not limited to: formal equivalence checkers such as OneSpin 360DV TM 、Mentor Graphics Formal Verification, VC Formal, Enterprise Verifier and and formal property checkers (also called formal model checkers), such as HECTOR, and other logical equivalence checkers (LECs) and sequential logic equivalence checkers (SLECs). Some formal verification tools (which may be referred to herein as arithmetic formal verification tools) are good at verifying properties related to data transformations (such as arithmetic operations), but can usually only be used to prove properties within a limited period of time. Other verification tools (which may be referred to herein as infinite time formal verification tools) are good at verifying properties within an infinite period of time, but are not good at verifying properties related to data transformations (such as arithmetic operations).

[0011] Because existing formal verification tools are good at verifying properties related to data transformation or good at verifying properties in infinite time, but not both, it is difficult to use existing formal verification tools to verify the output of an instantiation of a hardware design of data transformation in infinite time. Therefore, it is difficult to use existing formal verification tools to verify that an instantiation of a hardware design of a data transformation pipeline will always transform data correctly, or will always transform data in the same way as an instantiation of another hardware design, regardless of when the transformation is performed.

[0012] The embodiments described below are provided by way of example only and are not intended to limit implementations that overcome any or all of the disadvantages of known methods and systems for verifying hardware design of data transformation pipelines. Summary of the invention

[0013] This Summary is provided to introduce some concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0014] Methods and systems are described herein for verifying a hardware design of a data transformation pipeline via formal verification, the data transformation pipeline comprising one or more data transformation elements that perform data transformations on one or more inputs, wherein the formal verification is performed under one or more conditions that simplify the data transformation computations that the formal verification tool must perform. In one embodiment, the hardware design of the data transformation pipeline is verified by: formally verifying that the output of an instantiation of the hardware design produces the same output as an instantiation of the hardware design of another data transformation pipeline for a predetermined set of transactions, under the constraint that substantially equivalent data transformation elements between the data transformation pipelines produce the same output in response to the same input. In another embodiment, the hardware design of the data transformation pipeline is verified by: replacing one or more of the data transformation elements in the hardware design with functional elements that are treated by the formal verification tool as unevaluated functions of their combined inputs, such that during formal verification, the functional elements produce the same output for the same input; and formally verifying that for each transaction in the set of transactions, the instantiation of the modified hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs for the transaction.

[0015] A first aspect provides a computer-implemented method for verifying a hardware design of a data transformation pipeline, the data transformation pipeline comprising one or more data transformation elements that perform data transformation on one or more inputs, the method comprising performing the following operations at one or more processors: generating a version of the hardware design of the data transformation pipeline, wherein data transformation elements in the one or more data transformation elements have been replaced with or linked to functional elements, the functional elements being treated by a formal verification tool as unevaluated functions of their inputs, so that during formal verification, the functional elements produce the same set of one or more outputs in response to the same set of one or more inputs; and formally verifying that, for each transaction in a transaction set, an instantiation of the version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs of the transaction.

[0016] A second aspect provides a system for verifying the hardware design of a data transformation pipeline, wherein the data transformation pipeline includes one or more data transformation elements that perform data transformation on one or more inputs, and the system includes: a memory, wherein the memory is configured to store: a version of the hardware design of the data transformation pipeline, wherein the transformation elements in the one or more data transformation elements have been replaced with functional elements, and the functional elements are regarded as unevaluated functions of their inputs by a formal verification tool, so that during formal verification, the functional elements produce the same set of one or more outputs in response to the same set of one or more inputs; and a formal verification tool; and one or more processors, wherein the one or more processors are configured to: for each transaction in a transaction set, use the formal verification tool to formally verify that an instantiation of the version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs of the transaction.

[0017] The hardware design of the data transformation pipeline, when processed in an integrated circuit manufacturing system, configures the system to manufacture the data transformation pipeline. A non-transitory computer-readable storage medium may be provided, having stored thereon a hardware design of the data transformation pipeline, which, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying the data transformation pipeline.

[0018] An integrated circuit manufacturing system can be provided, the integrated circuit manufacturing system comprising: a non-temporary computer-readable storage medium on which a hardware design for a data transformation pipeline is stored; a layout processing system, the layout processing system being configured to process a computer-readable description to generate a circuit layout description of an integrated circuit embodying the data transformation pipeline; and an integrated circuit generation system, the integrated circuit generation system being configured to manufacture an integrated circuit embodying the data transformation pipeline based on the circuit layout description.

[0019] Computer program code for performing the method as described herein may be provided.A non-transitory computer readable storage medium having computer readable instructions stored thereon may be provided, which when executed at a computer system causes the computer system to perform the method as described herein.

[0020] As will be apparent to those skilled in the art, the features described above may be combined as appropriate and may be combined with any aspects of the examples described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Examples will now be described in detail with reference to the accompanying drawings, in which:

[0022] Figure 1 is a block diagram of a first example data transformation pipeline;

[0023] Figure 2 is a block diagram of a second example data transformation pipeline;

[0024] Figure 3 is a block diagram of a third example data transformation pipeline;

[0025] Figure 4 is a flow chart of a first example method for verifying a hardware design of a data transformation pipeline;

[0026] Figure 5 is a block diagram of a first set of instances of a first data transformation pipeline and a second data transformation pipeline, wherein the first data transformation pipeline and the second data transformation pipeline are different;

[0027] Figure 6 is a block diagram of a second set of instances of a first data transformation pipeline and a second data transformation pipeline, wherein the first data transformation pipeline and the second data transformation pipeline are identical;

[0028] Figure 7 It is a block diagram of an example system for verifying the hardware design of the data transformation pipeline;

[0029] Figure 8 Is implemented Figure 4A flowchart of an example method of formal verification steps of a method to verify that a hardware design of a data transformation pipeline is functionally equivalent to a hardware design of another data transformation pipeline;

[0030] Fig. 9 Is implemented Figure 4 A flowchart of an example method of formal verification steps for verifying the consistency of the hardware design of the data transformation pipeline;

[0031] Fig.10 is a block diagram of a first set of instances of a first data transformation pipeline and a second data transformation pipeline, wherein data transformation elements have been replaced by black box elements;

[0032] Fig.11 is a block diagram of a first data transformation pipeline and a second set of instances of a second data transformation pipeline, wherein the data transformation elements have been replaced by black box elements;

[0033] Fig.12 is a flow chart of a second example method for verifying a hardware design of a data transformation pipeline;

[0034] Fig.13 is based on Fig.12 The block diagram of the example system for verifying the hardware design of the data transformation pipeline by the method;

[0035] Fig.14 is a block diagram of an exemplary computing-based device;

[0036] Fig.15 is a block diagram of an example computer system in which a data transformation pipeline may be implemented; and

[0037] Fig.16 is a block diagram of an example integrated circuit manufacturing system that may be used to produce an integrated circuit embodying a data transformation pipeline.

[0038] The accompanying drawings show various examples. It will be appreciated by the skilled person that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the accompanying drawings represent an example of boundaries. In some examples, it may be the case that an element can be designed as multiple elements, or multiple elements can be designed as one element. Where appropriate, common reference numerals are used throughout the accompanying drawings to indicate similar features. DETAILED DESCRIPTION

[0039] The following description is given by way of example to enable those skilled in the art to make and use the invention. The invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art. The embodiments are described by way of example only.

[0040] A "hardware design" is a description of the structure and / or functionality of an integrated circuit that, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to generate the integrated circuit described by the hardware design. Fig.16 As described in more detail, when a hardware design is processed in an integrated circuit manufacturing system, the integrated circuit manufacturing system may generate an integrated circuit by synthesizing the hardware design into silicon or by loading configuration data into a field programmable gate array (FPGA).

[0041] The hardware design may be implemented in a high-level hardware description language (HDL), such as, but not limited to, a register transfer level (RTL) language. Examples of register transfer level languages ​​include, but are not limited to, VHDL (VHSIC Hardware Description Language) and It will be apparent to those skilled in the art that other high-level hardware description languages, such as proprietary high-level hardware description languages, may be used.

[0042] An "instantiation of a hardware design" is a representation of the hardware and / or hardware functionality defined by the hardware design. An instantiation of a hardware design includes, but is not limited to: a simulation model of the hardware design that simulates the behavior of the hardware defined by the hardware design; a synthesized version of the hardware design (e.g., a netlist); a hardware implementation of the hardware design (e.g., an integrated circuit or a field programmable gate array (FPGA)); and a mathematical model of the hardware design generated by a formal verification tool. An instantiation of a hardware design embodies the hardware design in a form that can be tested to verify the hardware design.

[0043] Therefore, the hardware design of the data transformation pipeline is a description of the structure and / or function of the integrated circuit that implements the data transformation pipeline, which, when processed at the integrated circuit manufacturing system, causes the integrated circuit manufacturing system to generate the integrated circuit that implements the data transformation pipeline. As described above, the data transformation pipeline includes at least one data transformation element, which is configured to perform data transformation on a set of one or more inputs. Therefore, the hardware design of the data transformation pipeline includes a description of the structure and / or function of each data transformation element of the pipeline.

[0044] As described above, because existing formal verification tools are generally good at verifying properties related to data transformation (such as arithmetic operations) or good at verifying properties in infinite time, but not both, it is difficult to use existing formal verification tools to verify the output of an instantiation of a hardware design for data transformation in infinite time - for example, verifying that an instantiation of a hardware design for a data transformation pipeline always produces the correct result of a transaction regardless of when the transformation is performed after a reset; or verifying that an instantiation of a hardware design for a data transformation pipeline always produces the same result as an instantiation of a hardware design for another data transformation pipeline.

[0045] For example, a formal verification tool (i.e., an arithmetic formal verification tool) that is good at verifying data transformations may be able to formally verify that an instantiation of a data transformation pipeline will produce the correct results of data transformations (i.e., transactions performed) performed on a set of inputs from a predetermined state of the pipeline (e.g., a state that occurs after a reset) under one or more predetermined conditions (e.g., no stops or interruptions). For example, this can be achieved by formally verifying via the arithmetic formal verification tool that the results of the transformations performed on a set of inputs from a predetermined state (e.g., a state that occurs after a reset) under one or more predetermined conditions by an instantiation of a hardware design match the results of a test bench component configured to simulate the behavior of a data transformation pipeline. Because the formal verification tool verifies that the output matches all possible input sets, this verifies that the instantiation of the hardware design will produce correct results for any set of inputs. However, this only verifies that when the transformation is performed from a predetermined state (e.g., a state that occurs from a reset), the instantiation of the hardware design will produce correct results. If the transformation is performed on a set of inputs from another state of the pipeline (e.g., a state that occurs after the first transaction and a stop or a state that occurs after two transactions and two stops), it is impossible to verify that the instantiation of the hardware design will produce correct results.

[0046] In order to verify that an instantiation of a hardware design produces correct results for transformations (i.e., transactions performed) performed on a set of inputs from another state (e.g., a state that occurs some time after a reset), a formal verification tool can be configured to verify the results of transformations performed by the instantiation of the hardware design on the set of inputs from another predetermined state (e.g., a state that occurs after a reset, a first transaction, and a stop). Although verifying the results of transformations performed from multiple states of the pipeline increases the chance of encountering obscure errors or vulnerabilities, this still only verifies that the instantiation of the hardware design produces correct results for transformations (i.e., transactions performed) performed from predetermined states that are explicitly tested (e.g., states that occur from a reset, and states that occur after performing a first transaction on a set of inputs and a stop), and not from any other state of the pipeline.

[0047] However, the inventors recognized that if it has been verified, for example via an arithmetic formal verification tool, that an instantiation of a hardware design in a predetermined set of states (e.g., a computation that is not stopped or interrupted once it has begun) produces correct results for transformations performed on any set of inputs from a predetermined state (e.g., a state that occurs after a reset), verifying that an instantiation of the hardware design always produces correct results for transformations performed on any set of inputs regardless of when the transformations are performed can be accomplished by verifying that the results of transformations performed by the instantiation of the hardware design on the set of inputs from a predetermined state (e.g., a state that occurs from a reset) match the results of the same transformations (i.e., the same inputs) performed by the instantiation of the hardware design from any other state.

[0048] However, this cannot be accomplished simply by using a formal verification tool that excels at proving properties in infinite time (i.e., an infinite-time formal verification tool) to verify that the results of a transformation performed from a predetermined state by an instantiation of a hardware design for a set of inputs match the results of a transformation performed from any other pipeline state by an instantiation of a hardware design for the same set of inputs. This is because formal verification tools that excel at verifying properties in infinite time are generally not able to effectively verify the results of data transformations, and therefore cannot verify the outputs of data transformation elements.

[0049] Because arithmetic formal verification tools can be used to verify that the pipeline will produce the correct results for the transformations performed on any set of inputs from a predetermined state, what remains to be verified is that the pipeline will produce the same results regardless of when the transformations are performed on the set of inputs. In other words, what remains to be verified is that the pipeline is consistent. To verify this, it is not necessary to verify that the results of the transformations performed by an instantiation of the hardware design from any other state of the pipeline are absolutely correct, only that the pipeline will produce the same output given the same inputs. In other words, what remains to be verified is that when the same inputs are provided to the pipeline, the data will move through the pipeline in the same way regardless of the state of the pipeline - that is, the control logic of the pipeline functions as expected. Therefore, what remains to be verified is that when the pipeline performs the same transaction (i.e., processes the same input), it will produce the same output.

[0050] Thus, methods and systems are described herein for verifying a hardware design of a data transformation pipeline via formal verification, the data transformation pipeline comprising one or more data transformation elements that perform data transformations on one or more inputs, wherein the formal verification is performed under one or more conditions or constraints that simplify the data transformation computations that a formal verification tool must perform, thereby increasing the likelihood that the formal verification will converge. The one or more conditions or constraints are configured to restrict control of the data transformation pipeline, but not the inputs to the data transformation pipeline.

[0051] about Figures 4 to 11 A first embodiment of verifying a hardware design of a first data transformation pipeline is described. In this embodiment, the method includes formally verifying that an output of an instantiation of the hardware design of the first data transformation pipeline matches an output of an instantiation of the hardware design of a second data transformation pipeline for a predetermined set of transactions. The second data transformation pipeline also includes one or more data transformation elements that perform data transformations on one or more inputs. At least one of the data transformation elements of the second data transformation pipeline is substantially identical to a data transformation element of the first data transformation pipeline. Formal verification is performed under a constraint that the substantially identical data transformations of the first data transformation pipeline and the second data transformation pipeline produce identical outputs in response to identical inputs.

[0052] In the case where the second data transformation pipeline is different from the first data transformation pipeline, the method can be used to verify that the hardware designs for the first data transformation and the second data transformation are functionally equivalent. Conversely, in the case where the second data transformation pipeline is the same as the first data transformation pipeline, the method can be used to verify that the hardware design is consistent (i.e., an instantiation of the hardware design generates the same output in response to the same input, regardless of when the input is processed). Note that this does not verify that an instantiation of the hardware design always produces the correct results, only that an instantiation of the hardware design produces the same results. However, this verification combined with the verification that an instantiation of the hardware design produces the correct results for data transformations performed on any set of inputs from a specific state of the pipeline (which, as described above, can be performed using an arithmetic formal verification tool) exhaustively verifies that an instantiation of the hardware design always produces the correct results of the transformation.

[0053] Reference below Figure 12 to Figure 13 A second embodiment of verifying a hardware design for a data transformation pipeline is described. In this embodiment, the method includes: generating a version of the hardware design for the data transformation pipeline in which a selected set of data transformation elements are replaced with or linked to a functional element that is treated by a formal verification tool as an unevaluated function of its input, such that during formal verification the functional element will produce the same output for the same input; and formally verifying that an instantiation of the version of the hardware design for the data transformation pipeline produces a set of one or more outputs for any transaction, and that the set of one or more outputs matches a reference set of one or more outputs for the transaction.

[0054] In some cases, verifying that an instantiation of a version of a hardware design for a data transformation pipeline produces, for any transaction, a set of one or more outputs that matches a reference set of one or more outputs for the transaction may include formally verifying that the instantiation of the version of the hardware design is consistent (i.e., it always produces the same results for the transaction regardless of when the transaction is executed). In other cases, verifying that an instantiation of a version of a hardware design for a data transformation pipeline produces, for any transaction, a set of one or more outputs that matches a reference set of one or more outputs for the transaction may include formally verifying that the instantiation of the version of the hardware design is functionally equivalent to an instantiation of the hardware design for another data transformation pipeline.

[0055] Reference now Figure 4 , which shows a first example method 400 for verifying the hardware design of a first data transformation pipeline. The method 400 can be performed by a computing-based device, such as but not limited to the following reference Fig.14For example, there may be a computer-readable storage medium having computer-readable instructions stored thereon, which when executed at a computing-based device causes the computing-based device to perform Figure 4 Method 400.

[0056] The method 400 begins at block 402, where, for a predetermined set of transactions, it is formally verified that an output of an instantiation of a hardware design for a first data transformation pipeline matches an output of an instantiation of a hardware design for a second data transformation pipeline (i.e., the hardware designs of the two data transformation pipelines are functionally equivalent). As described above, a data transformation pipeline includes at least one data transformation element that is configured to perform a data transformation on a set of one or more inputs, but it may also include other types of processing elements. Thus, each of the first data transformation pipeline and the second data transformation pipeline includes at least one data transformation element that performs a data transformation (e.g., an arithmetic operation) on one or more inputs.

[0057] At least one of the data transformation elements of the second data transformation pipeline is substantially equivalent or functionally equivalent to at least one data transformation element of the first data transformation pipeline. If two data transformation elements produce the same output in response to the same input, they are said to be substantially equivalent. For example, the first data transformation pipeline and the second data transformation pipeline may each include a data transformation element configured to calculate the product of two inputs. Formal verification is performed under the constraint that the substantially equivalent data transformation elements of the first data transformation pipeline and the second data transformation pipeline produce the same output in response to the same input. For example, if data transformation element A in the first data transformation pipeline is substantially equivalent to data transformation element B in the second data transformation pipeline, formal verification is performed under the constraint that data transformation element A and data transformation element B produce the same output in response to the same input.

[0058] A data transformation element in one data transformation pipeline may be substantially equivalent to more than one data transformation element in other data transformation pipelines. In these cases, formal verification may be performed under the constraint or set of constraints that each pair of substantially equivalent data transformation elements produces the same output in response to the same input. For example, if a first data transformation pipeline includes data transformation elements A and B, and a second data transformation pipeline includes data transformation elements C and D. Data transformation element A may be substantially equivalent to data transformation elements C and D, and data transformation element B may also be substantially equivalent to data transformation elements C and D. In this example, formal verification may be performed under the following constraints: (i) data transformation elements A and C produce the same output in response to the same input; (ii) data transformation elements A and D produce the same output in response to the same input; (iii) data transformation elements B and C produce the same output in response to the same input; and (iv) data transformation elements B and D produce the same output in response to the same input.

[0059] In the examples described herein, it is assumed that substantially equivalent data transformation elements are combined (i.e., have no stored data), however, the methods and techniques described herein may also be applied to situations where substantially equivalent data transformation elements are non-combined, as long as the state of the non-combined elements is also taken into account.

[0060] In some cases, the first data transformation pipeline and the second data transformation pipeline may be different. In other words, in some cases, the hardware design of the first data transformation pipeline and the second data transformation pipeline is a different hardware design. Figure 8 As described in more detail, verifying the outputs of instantiations of two different hardware designs can be used to verify that the instantiations of the two hardware designs are functionally equivalent (i.e., they always produce the same outputs in response to the same inputs). In other cases, the first data transformation pipeline and the second data transformation pipeline can be the same. In other words, in some cases, the hardware designs of the first data transformation pipeline and the second data transformation pipeline can be two copies of the same hardware design. As described below with respect to Fig. 9 Described in more detail, verifying the output of instantiations of two copies of the same hardware design can be used to verify that the instantiations of the hardware design are consistent (i.e., they always produce the same output in response to the same input, regardless of when the input is processed (i.e., regardless of the state of the pipeline when the input is processed)).

[0061] Formal verification that an instantiated output of the hardware design of the first data transformation pipeline and the second data transformation pipeline matches a predetermined set of transactions may include: generating one or more assertions to be verified; linking the one or more assertions to the hardware design of the first data transformation pipeline and the second data transformation pipeline; and using a formal verification tool to formally verify that the one or more assertions are correct (or hold) for the hardware design of the first data transformation pipeline, and outputting one or more signals to indicate whether the one or more assertions have been successfully verified.

[0062] An assertion is a statement that indicates that a specific property is expected to apply to the hardware design (i.e., always be true). An assertion of the form "assert property [evaluable expression]" is said to "assert" the property specified by "evaluableexpression". If the asserted property (e.g., evaluable expression) evaluates to false for the hardware design for any valid input, then the hardware design will not function as expected and an error will occur. For example, in the example assertion "assert property a = b"; if at any time a is not equal to b, then it indicates that the hardware design will not function as expected and an error will occur.

[0063] Assertions are used to capture the desired temporal and combinatorial behavior of a hardware design in a formal and unambiguous way. The hardware design can then be verified to determine that it meets the requirements captured by the assertions. Because assertions capture instantiated behavior cycle by cycle, they can be used to verify intermediate behavior.

[0064] Assertions are typically expressed in an assertion language. Assertion languages, which may also be referred to as characterization languages, capture the behavior of a hardware design across multiple hardware design cycles (e.g., clock cycles) in a concise, unambiguous manner. Traditional hardware description languages ​​(HDLs), such as RTL languages, have the ability to capture single cycle behavior, but they are too detailed to describe characteristics at a higher level. Specifically, assertion languages ​​provide a means to express temporal relationships and complex hardware design behaviors in a concise manner. Assertion languages ​​include, but are not limited to, System Verilog Assertions (SVA), Characterization Specification Language (PSL), Sharp Assertion Library (IAL), Synopsys OVA (OpenVera Assertions), Symbolic Trace Evaluation (STE), SystemC Verification (SCV), O-In, Specman, and OpenVera Library (OVL).

[0065] To verify that instantiations of the first hardware design and the second hardware design produce the same output for a predetermined set of transactions, one or more assertions may be generated that, if proven to be true, can determine that the output of the instantiation of the hardware design for the first data transformation pipeline when executing any one of the predetermined set of transactions matches the output of the instantiation of the hardware design for the second data transformation pipeline when executing the same transaction. The one or more assertions may compare the output of the transactions executed by the two instantiations from the same state. For example, as described below with respect to Figure 8 As described, when the method is used to verify that two different instantiations of a hardware design always produce the same output, the one or more assertions can be configured to compare the outputs of the instantiations of the hardware design when they execute the same transaction from the same state. Fig. 9 As described, when the method is used to verify that an instantiation of a hardware design is consistent (i.e., it always produces the same output of a transaction regardless of when the transaction is executed), the one or more assertions can be configured to compare the output of the instantiation of the hardware design when the same transaction is executed from different states. For example, the output of the instantiation of the hardware design of the second data transformation pipeline when executing a transaction from a predetermined pipeline state can be compared with the output of the instantiation of the hardware design of the first data transformation pipeline when executing the same transaction from any other pipeline state. The following describes instance assertions that can be used in these cases.

[0066] Once one or more assertions are generated, the one or more assertions are linked to the hardware designs of the first data transformation pipeline and the second data transformation pipeline. The one or more assertions can be linked to the hardware designs of the first data transformation pipeline and the second data transformation pipeline by: merging the one or more assertions into a hardware design and binding or linking the hardware designs; or binding the one or more assertions to the hardware designs of the first data transformation pipeline and the second data transformation pipeline. Specifically, the one or more assertions can be bound to relevant signals of the hardware designs of the first data transformation pipeline and the second data transformation pipeline to determine when a predetermined transaction is executed by the instantiation, and to determine whether the output matches when any predetermined transaction is executed.

[0067] Once the one or more assertions are linked to the hardware designs of the first data transformation pipeline and the second data transformation pipeline, the hardware designs of the first data transformation pipeline and the second data transformation pipeline, the one or more assertions, and the bindings are loaded into a formal verification tool, and the formal verification tool is configured to verify that the one or more assertions are true for the hardware design of the first data transformation pipeline.

[0068] An assertion is verified by searching the entire reachable state space of an instantiation of a hardware design (e.g., a state transition system or flow chart) without explicitly traversing all states. The search is done, for example, by encoding the states using efficient Boolean encodings using binary decision diagrams (BDDS) or using advanced SAT (bounded model checking based on satisfiability) based techniques. In some cases, tools can be used to implement techniques such as, but not limited to, abstraction, symmetry, symbolic indexing, and invariants to improve performance and enable scalability. Because formal verification of a property exhaustively explores all valid input values ​​through an algorithm over time, verifying the property in this way allows the property to be exhaustively proved or disproven for all valid states.

[0069] As mentioned above, in Figure 4 In the method 400, formal verification is performed under one or more constraints, wherein the constraint is that substantially identical data transformation elements of the first data transformation pipeline and the second data transformation pipeline produce the same output in response to the same input. For example, if the first data transformation pipeline and the second data transformation pipeline each include a data transformation element configured to calculate the product of two inputs, the two data transformation elements can be considered to be substantially equivalent, and formal verification can be performed under the constraint that the two data transformation elements produce the same output in response to the same input. The inventors recognize that performing formal verification under such constraints greatly increases the likelihood that the formal verification will converge (i.e., produce a conclusive answer, such as yes, an assertion holds, or no, at least one assertion does not hold). This is because the constraints act as hints that can simplify the calculations performed by the formal verification tool.

[0070] In some cases, constraints can be implemented through one or more assumption statements. As known to those skilled in the art, assumption statements are interpreted by formal verification tools as constraints on the instantiation behavior of the hardware design during formal verification. Specifically, when a certain property is assumed, the formal verification tool constrains the input so that the property holds. Therefore, the assumption defines an environment in which the property of the hardware design can be verified.

[0071] As described in more detail below, when the method is used to verify that two hardware designs are functionally equivalent (i.e., instantiations of the two hardware designs will always produce the same outputs in response to the same inputs), it is assumed that it can be shown that whenever substantially identical data transformation elements of a first data transformation pipeline and a second data transformation pipeline receive the same inputs at the same time or at relevant points in time, their outputs are the same. Conversely, when the method is used to verify that hardware designs are consistent (i.e., instantiations of the hardware designs will produce the same outputs for any transaction regardless of when the transaction is executed), it is assumed that it can be shown whether substantially identical data transformation elements of a second data transformation pipeline receive a set of inputs and produce a set of outputs as part of a transaction executed from a predetermined state, and whether substantially identical data transformation elements of a first data transformation pipeline receive the same set of inputs for which they produce the same set of outputs. In these cases, the substantially identical data transformation elements will be equivalent. In conjunction with the following, Figure 8 and Fig. 9 Describe example assumptions that can be used in these situations.

[0072] When a formal verification tool is used to verify an assertion, the formal verification tool may output an indication of whether the assertion is valid (i.e., the asserted property is true for all valid states or sequences of states), which may also be referred to as the assertion being successfully verified. The output may be "yes", the assertion is valid or has been successfully verified; "no", the assertion is invalid (i.e., the asserted property is not true or has failed for at least one valid state or sequence of states) or has not been successfully verified; or the formal verification is inconclusive. Formal verification may be inconclusive, for example, because the memory of the computing-based device running the formal verification tool has been exhausted, or because the formal verification tool has determined that a certain amount of progress has not been made after a predefined period of time.

[0073] In the event that an assertion is invalid or has not been successfully verified, the formal verification tool may also output information to indicate the hardware design state or sequence of states that caused the asserted feature to fail. For example, the formal verification tool may output a trace of the verification to indicate at what point, state, or sequence of states the failure occurred.

[0074] Once formal verification is complete, method 400 may end, or the method may proceed to block 404 .

[0075] At block 404, it may be determined whether verification of the first version of the hardware design for the data transformation pipeline was successful. As described above, when a formal verification tool is used to verify assertions for a hardware design, the formal verification tool may output a signal or a set of signals indicating whether the assertion is valid (i.e., the asserted property is true for all valid states or state sequences). In these cases, a determination as to whether verification was successful may be made based on the output signal.

[0076] If it is determined that the verification is successful (indicating that the instantiation of the hardware design works as expected), the method 400 can proceed to block 406, where an integrated circuit embodying the data transformation pipeline described by the hardware design is manufactured. However, if it is determined that the verification of the hardware design of the first data transformation pipeline is unsuccessful (indicating that an error exists in the hardware design), the method 400 can proceed to block 408, where the hardware design of the first data transformation is modified to correct the hardware design error that caused the unexpected behavior. Once the hardware design is modified, the modified hardware design can be re-verified (e.g., blocks 402-408 can be repeated for the modified hardware design).

[0077] In some cases, before performing formal verification, substantially equivalent data transformation elements of at least one of the first data transformation pipeline and the second data transformation pipeline can be replaced with simpler logic. Specifically, because formal verification is verifying that the outputs of the hardware design instantiations of the first data transformation pipeline and the second data transformation pipeline match, rather than verifying that both are "correct", it is important that the movement of data through the control logic of the pipeline is correct, and thus the substantially equivalent data transformation elements can be replaced with simpler logic. Specifically, the substantially equivalent data transformation elements of the first and / or second data transformation pipelines can be black-boxed (i.e., replaced with black-box elements).

[0078] For example, Figure 5 and Figure 6 As examples, a first data transformation pipeline and a second data transformation pipeline 502, 504, 602, 604 are shown, each of which includes a plurality of data transformation elements 506, 508, 510, 512, 606, 608, 610, 612. Figure 5 In the example of , the first data transformation pipeline and the second data transformation pipeline 502, 504 are different, but include substantially identical data transformation elements 506, 510. Therefore, in this example, one or both of the substantially identical data transformation elements 506, 510 may be black-boxed (i.e., replaced with black-box elements). Figure 6 In the example of , the first data transformation pipeline and the second data transformation pipeline 602, 604 are identical, so each of the data transformation elements 606, 608 of the first data transformation pipeline 602 has the same data transformation element 610, 612 in the second data transformation pipeline 604. Therefore, all data transformation elements in this example have substantially identical data transformation elements. Figure 6 In the example of , any or all of the data transformation elements 606, 608, 610, 612 may be black-boxed (ie, replaced with black-box elements).

[0079] The process of replacing a component in a hardware design with a black box element is known as black boxing the component. As is known to those skilled in the art, when a component in a hardware design is black boxed, it cuts out the logic that drives the component output and makes the output "free," meaning that the output can take on any value, regardless of the input. Therefore, even if the black box element receives the same input value at two different times, it can generate different output values. Black box processing can alternatively be described as replacing the logic that drives the output of a data transformation element with a cutoff or stop point.

[0080] Because black-boxing the data transformation elements of a data transformation pipeline removes the transformation logic from the pipeline (which is typically not handled by an infinite-time formal verification tool), the more data transformation elements that are black-boxed, the more likely it is that formal verification will converge (i.e., produce a conclusive answer). This is because black-boxing the data transformation elements means that the formal verification tool does not have to calculate the results of the data transformation elements. However, the more data transformation elements that are black-boxed, the higher the likelihood of false negatives (i.e., the higher the likelihood that formal verification will fail even if there are no errors in the hardware design). This is because removing the driving logic of certain signals may mean that one or more previously unreachable states of the hardware design become reachable. Some of these states may cause formal verification to fail, but they cannot be reached in the actual hardware design, so this is a false failure (i.e., a false negative).

[0081] Specifically, if substantially equivalent data transformation elements are not black-boxed, formal verification is more likely to converge but less likely to converge than formal verification performed without constraints if substantially equivalent data transformation elements of the first data transformation pipeline and / or the second data transformation pipeline are black-boxed. However, the probability of false negatives is zero. On the contrary, if substantially equivalent data transformation elements of both the first data transformation pipeline and the second data transformation pipeline are black-boxed, the probability of convergence of formal verification will be greatly improved. This is because the formal verification tool performs fewer data transformations. However, the probability of false negatives increases. This is because false negatives may now occur (i.e., unreachable states are now reachable). However, if only the substantially equivalent data transformation elements of one of the first data transformation pipeline and the second data transformation pipeline are black-boxed - that is, if the substantially equivalent data transformation elements of the first data transformation pipeline are black-boxed and the substantially equivalent data transformation elements of the second data transformation pipeline are not black-boxed, or if the substantially equivalent data transformation elements of the second data transformation pipeline are black-boxed and the substantially equivalent data transformation elements of the first data transformation pipeline are not black-boxed - then formal verification is more likely to converge if no data transformation elements are black-boxed, but less likely to converge if the substantially equivalent data transformation elements of both data transformation pipelines are black-boxed. However, the likelihood of a false negative is lower if the substantially equivalent data transformation elements of both data transformation pipelines are black-boxed. This is summarized in Table 1 shown below.

[0082] Table 1

[0083]

[0084]

[0085] However, an important benefit of the verification method described in this article is that no matter which or how many data transformation elements are black-boxed, no false positives will occur (i.e., if there is an error in the hardware design, the formal verification will not succeed because the first data transformation pipeline will cause the instantiation of the hardware design to function in the wrong way).

[0086] If the substantially equivalent data transformation element of the first data transformation element is black-boxed, the constraint control replaces the output of the black-box element of the corresponding data transformation element. This is because the constraint controlling the output of the black-box element is still controlled in the same way based on the input (i.e., the output signal of the substantially equivalent data transformation element based on its input, if the substantially equivalent data transformation element is replaced by the black-box element, the output (i.e., the output signal)). This causes the black-box element to function in a deterministic manner. In the absence of constraints, the output of any black-boxed element of the first data transformation pipeline is "free", which means that they can take any value independently of the input, so that different outputs can be generated for the same input. Therefore, if the output of the black-box element of the first data transformation element is not controlled by constraints, formal verification may fail because it is inevitable that the instantiation of the hardware design receives the same pipeline input but produces different outputs, even if the design is properly configured.

[0087] If the data transformation elements of the first data transformation pipeline are not black-boxed and the data transformation elements of the second data transformation pipeline are black-boxed (i.e., method 2 in Table 1), and the earlier transactions of the second data transformation pipeline are compared with the later transactions of the first data transformation pipeline, the assumption is called backward propagation. Specifically, when there is no assumption that satisfies up to and including cycle n but the assertion in cycle n fails, the formal verification tool considers the assertion evaluated under one or more constraints (e.g., assumptions) to be valid in cycle n. This means that any state that inevitably led to the failure of the assumption in the past will now (or in the past) be excluded. This can cause the assumption to propagate backward.

[0088] If the verification method used has the possibility of false negatives (i.e., a method that black-boxes one or more data transformation elements), restrictions or constraints can be replaced on the output of one or more black box elements to ensure that the black box element does not generate unexpected outputs or outputs with unexpected characteristics (i.e., outputs that cannot be effectively generated by the corresponding data transformation element). For example, such restrictions can be imposed on the black box element by generating an assumption and linking the assumption to the hardware design of the first data transformation pipeline. For example, if the data transformation element is configured to generate the square of the input, the downstream component can expect the data transformation element to output a number greater than or equal to zero. In this example, an assumption can be generated for the black box element, which replaces the data transformation element, and the data transformation element indicates that the output of the black box element is greater than or equal to zero. Similarly, if the data transformation element is configured to output the sine of the input, an assumption can be generated for the black box element, which replaces the data transformation element, and the data transformation element indicates that the output of the black box element is between -1 and 1. Typically, a characteristic is not assumed during formal verification until it is proven to be true. For example, before generating a hypothesis that the output of a data transformation element (or a black box element that replaces it) is equal to or greater than zero, it is typically verified (through formal verification or other verification methods) that the output of the data transformation element is always greater than or equal to zero. It will be apparent to those skilled in the art that these are merely examples, and that other restrictions or constraints may be imposed on the output of the black box element. In some cases, if it is not possible to remove false positives associated with a particular verification method by imposing constraints or restrictions on the output of the black box element, then that particular method may not be considered a viable verification method.

[0089] Reference now Figure 7 , which shows an example system 700 for verifying the hardware design of the first data transformation pipeline according to the first embodiment. The system 700 can be composed of one or more computing-based devices, such as those described below. Fig.14 The described computing-based device 1400 is implemented. For example, Figure 7 One or more components of system 700 may be implemented as computer-readable instructions that, when executed by a computing-based device, cause the computing-based device to perform the functions of the components described below.

[0090] The system 700 includes a hardware design for a first data transformation pipeline 702 , a hardware design for a second data transformation pipeline 704 , one or more assumptions 706 , one or more formal assertions 708 , and a formal verification tool 710 .

[0091] The hardware design of the first data transformation pipeline 702 and the second data transformation pipeline 704 includes a description of the structure and / or function of the first data transformation pipeline or the second data transformation pipeline, respectively. The first data transformation pipeline and the second data transformation pipeline each include one or more data transformation elements, and the one or more data transformation elements are configured to perform data transformation on a set of one or more inputs. The first data transformation pipeline and the second data transformation pipeline are intended to be functionally equivalent (that is, they are intended to produce the same pipeline output in response to the same pipeline input). The first data transformation pipeline and the second data transformation pipeline can be the same or different. In either case, at least one data transformation element in the first data transformation pipeline is substantially equivalent to the data transformation element in the second data transformation pipeline. In some cases, the substantially equivalent data transformation elements of the first and / or second data transformation elements can be black-boxed. The advantages and disadvantages of black-boxing the substantially equivalent data transformation elements of one or both of the first data transformation pipeline and the second data transformation pipeline are described above.

[0092] One or more assumptions 706 constrain the behavior of substantially identical data transformation elements (or corresponding black box elements) of the first data transformation pipeline to function in the same manner as corresponding data transformation elements of the second data transformation pipeline. In other words, the one or more assumptions constrain the behavior of substantially identical data transformation elements of the first data transformation pipeline so that substantially identical data transformation elements of the first data transformation pipeline produce identical outputs when receiving the same inputs as their corresponding data transformation elements of the second data transformation pipeline. The one or more assumptions are linked to the hardware design of the first data transformation pipeline and the second data transformation pipeline so that the inputs of substantially identical data transformation elements of the first data transformation pipeline and the second data transformation pipeline are linked.

[0093] As described in more detail below, when the system is used to verify that two hardware designs are functionally equivalent (i.e., an instantiation of the hardware designs will always produce the same outputs in response to the same inputs), an assumption can be made that whenever substantially identical data transformation elements of a first data transformation pipeline and a second data transformation pipeline receive the same inputs at the same time or at relevant points in time, their outputs are the same. Conversely, when the system is used to verify that a single hardware design is consistent (i.e., an instantiation of the hardware design will produce the same outputs for any transaction regardless of when the transaction is executed), an assumption can be made that if substantially identical data transformation elements of a second data transformation pipeline receive a set of one or more inputs and produce a set of one or more outputs as part of a transaction executed from a predetermined state, if substantially identical data transformation elements of a first data transformation pipeline receive the same set of inputs at any time, they will produce the same set of outputs. In these cases, because the two hardware designs are identical, the substantially identical data transformation elements will be identical.

[0094] Assertions 708 include one or more assertions that, if verified to be true for the hardware design of the first data transformation pipeline, prove that the instantiation of the first hardware design and the second hardware design will produce the same output for a predetermined set of transactions. As known to those skilled in the art, an assertion is a statement that expects a specific characteristic to apply to the hardware design (i.e., always true). As described in more detail below, when the system 700 is used to verify that the instantiation of two different hardware designs always produces the same output, the one or more assertions can be configured to compare the output of the instantiation of the hardware design when the same transaction is executed from the same state. Conversely, when the system 700 is used to verify that the instantiation of the hardware design is consistent (i.e., the same output of the transaction will always be produced regardless of when the transaction is executed), the one or more assertions can be configured to compare the output of the instantiation of the hardware design of the second data transformation pipeline when executing the transaction from a predetermined pipeline state with the output of the instantiation of the hardware design of the first data transformation pipeline when executing the same transaction from any other pipeline state. Example assertions that can be used in these cases are described below.

[0095] The one or more assertions 708 are linked to the hardware designs of the first data transformation pipeline and the second data transformation pipeline, so that the one or more assertions are connected to relevant signals of the hardware designs so that the asserted characteristics can be evaluated. As described above, the one or more assertions 708 can be linked to the hardware designs by binding them to the hardware designs of the first data transformation pipeline and the second data transformation pipeline.

[0096] As described above, the formal verification tool 710 is a software tool capable of formally verifying a hardware design. Because formal verification ideally verifies the one or more assertions in an infinite time, using an infinite time formal verification tool may be advantageous.

[0097] The hardware design of the first data transformation pipeline 702, the hardware design of the second data transformation pipeline 704, the one or more assumptions 706, the one or more assertions 708 and bindings (if any) are loaded into the formal verification tool 710. The formal verification tool 710 is then configured to formally verify that the one or more assertions are true for the hardware design of the first data transformation pipeline.

[0098] When the formal verification tool 710 is used to verify an assertion, the formal verification tool 710 may output an indication of whether the assertion is valid (i.e., the asserted property is true for all valid states or sequences of states), which may also be referred to as the assertion being successfully verified. The output may be "yes", the assertion is valid or has been successfully verified; "no", the assertion is invalid (i.e., it is not true or has failed for at least one valid state or sequence of states) or has not been successfully verified; or the formal verification is inconclusive. Formal verification may be inconclusive, for example, because the memory of the computing-based device running the formal verification tool 710 has been exhausted, or because the formal verification tool 710 has determined that a certain amount of progress has not been made after a predefined period of time.

[0099] When an assertion is invalid or has not been successfully verified, the formal verification tool 710 can also output information to indicate the state or state sequence of the hardware design that caused the assertion to fail. For example, the formal verification tool 710 can output a verification trace to indicate at what point, state, or state sequence the failure occurred.

[0100] Reference now Figure 8 , which shows the implementation Figure 4 The embodiment method 800 of step 402 of method 400 is used to verify that the hardware design of the first data transformation pipeline is functionally equivalent to the hardware design of the second data transformation pipeline (i.e., the instantiation of the hardware design of the first data transformation pipeline and the instantiation of the hardware design of the second data transformation pipeline will always produce the same output in response to the same input).

[0101] exist Figure 8In method 800, a first data transformation pipeline and a second data transformation pipeline are different (i.e., they are not identical), but there is at least one pair of substantially identical data transformation elements in the first data transformation pipeline and the second data transformation pipeline. Specifically, at least one data transformation element of the first data transformation pipeline is substantially identical to at least one data transformation element of the second data transformation pipeline. Two data transformation elements are "substantially identical" if they are identical or functionally equivalent. Two data transformation elements are functionally equivalent if they always produce the same output in response to the same input. The pairs of substantially identical data transformation elements in the first data transformation pipeline and the second data transformation pipeline can be identified manually (e.g., by a person) or can be identified automatically. For example, a computing-based device (such as a Fig.14 The computing-based device 1400 is configured to automatically identify substantially identical data transformation elements by identifying identical code segments in hardware designs of a first data transformation pipeline and a second data transformation pipeline.

[0102] exist Figure 8 In method 800, functional equivalence of the hardware designs of the first data transformation pipeline and the second data transformation pipeline is verified by formally verifying that instantiations of the hardware designs of the first data transformation pipeline and the second data transformation pipeline produce the same output for any pipeline set input. The formal verification is performed under the constraint that substantially identical data transformation elements of the first data transformation pipeline and the second data transformation pipeline produce the same output in response to the same input. As described above, the inventors have recognized that performing formal verification under such constraints can significantly increase the likelihood that the formal verification will converge.

[0103] The method 800 begins at block 802 where a formal verification tool is used to formally verify that instantiations of hardware designs of a first data transformation pipeline and a second data transformation pipeline produce the same set of outputs for any set of pipeline inputs.

[0104] Formal verification that instantiations of the hardware design of the first data transformation pipeline and the second data transformation pipeline produce the same set of outputs for any set of pipeline inputs may include generating one or more assertions and formally verifying the one or more assertions. For example, in some cases, inputs to the instantiations of the hardware design of the first data transformation pipeline and the second data transformation pipeline may be tied together so that the instantiations receive the same inputs during formal verification. In these cases, an assertion may be generated indicating that for any set of inputs, the corresponding set of outputs is the same.

[0105] In the case where the first data transformation pipeline and the second data transformation pipeline are configured to process transactions (i.e., pipeline input sets) in the same number of cycles (e.g., the first data transformation pipeline and the second data transformation pipeline are both configured to process transactions in 5 cycles), the assertion can simply state that the output of the instantiation of the hardware design of the first data transformation pipeline and the second data transformation pipeline is the same. The following is an example SV assertion that can be used in this case, where first_pipe_output is the output of the instantiation of the hardware design of the first data transformation pipeline, and second_pipe_output is the output of the instantiation of the hardware design of the second data transformation pipeline:

[0106] assert_output:assert property(first_pipe_output==second_pipe_output)

[0107] It will be apparent to one skilled in the art that the assertion states that the output of the instantiation of the hardware design for the first data transformation pipeline (first_pipe_output) is equal to the output of the instantiation of the hardware design for the second data transformation pipeline (second_pipe_output). Formal verification tools verify the assertion by determining whether there is a state of the instantiation of the hardware design for the first data transformation pipeline when the assertion is false (i.e., the outputs do not match). If there is no such state, the assertion is said to be successfully verified. Therefore, if there is at least one state of the instantiation of the hardware design for the first data transformation pipeline, and the outputs of the instantiation of the hardware design do not match, then the assertion will fail.

[0108] In the case where the first data transformation pipeline and the second data transformation pipeline are not configured to process transactions (i.e., pipeline input sets) in the same number of cycles (e.g., the first data transformation pipeline may be configured to process transactions in 5 cycles, while the second data transformation pipeline may be configured to process transactions in 7 cycles), the assertion takes into account the delay or skew between the outputs. For example, the following is an example SV assertion that can be used in the following case: the first data transformation pipeline produces the output of the transaction n cycles after the second data transformation pipeline produces the output of the second transaction, where first_pipe_output is the output of the instantiation of the hardware design of the first data transformation pipeline, and second_pipe_output is the output of the instantiation of the hardware design of the second data transformation pipeline. As known to those skilled in the art, $past(a, b) is an SV operator that returns the value a, b cycles ago (or b cycles in the past).

[0109] assert_output:assert property(first_pipe_output==$past(second_pipe_output,n))

[0110] It will be apparent to those skilled in the art that this assertion states that the output of the instantiation of the hardware design of the first data transformation pipeline (first_pipe_output) is equal to the output of the instantiation of the hardware design of the second data transformation pipeline n cycles ago (second_pipe_output).

[0111] The formal verification is performed under the constraint that if substantially identical data transformation elements of the first data transformation pipeline and the second data transformation pipeline receive the same input at the same time or at relevant points in time, they will produce the same output in response to the input. For example, Figure 5 The first data transformation pipeline 502 and the second data transformation pipeline 504 as examples may include a pair of substantially identical data transformation elements 506 and 510. In this example, formal verification may be performed under the constraint that the data transformation element 506 and the data transformation element 510 produce the same output when receiving the same input at the same time or at a relevant point in time. In the case where there are multiple pairs of substantially identical data transformation elements, the constraints may be applied to any combination of substantially identical pairs of data transformation elements. For example, the constraints may be applied to: only one pair of substantially identical data transformation elements; more than one pair of substantially identical data transformation elements; or all pairs of substantially identical data transformation elements.

[0112] In some cases, one or more pairs of substantially identical data transformation elements may be time-aligned. When two substantially identical data transformation elements receive the same input at the same time (i.e., in the same cycle) for the same transaction, it is referred to as "time alignment". In these cases, the constraint associated with those substantially identical pairs of data transformation elements may be when the substantially identical data transformation elements receive the same input while they produce the same output. In some cases, one or more pairs of substantially identical data transformation elements may be time-shifted. When two data transformation elements receive the same input at related points in time (e.g., a fixed number of cycles apart) for the same transaction, it is referred to as "time-shifted". For example, data transformation element 510 may always receive the input of a particular transaction two cycles after data transformation element 506 receives the input of the transaction. In these cases, the constraint associated with those substantially identical pairs of data transformation elements may be that when the substantially identical data transformation elements receive the same input at related points in time (e.g., a fixed number of cycles apart), they produce the same output. In some cases, one or more pairs of substantially identical pairs of data transformation elements may not have a fixed time relationship, but a limited set of shifts may occur. For example, substantially identical data transformation elements may be offset by one of 5, 7, and 9 cycles. In these cases, the constraint associated with those substantially identical data transformation pairs may be that the substantially identical data transformation elements produce identical outputs when they receive identical inputs at one of a predetermined set of relevant points in time (e.g., at one of a predetermined set of cycle offsets).

[0113] As mentioned above, constraints can be implemented as one or more assumption statements. Figure 5 An example assumption of substantially identical data transformation elements 506, 510 written in SV, wherein the substantially identical data transformation elements 506, 510 are time-aligned (i.e., they will receive inputs of the same transaction at the same time). In this example assumption, input_DTE_first_pipe is the input of the data transformation element (DTE) 506 of the first data transformation pipeline 502, input_DTE_second_pipe is the input of the data transformation element (DTE) 510 of the second data transformation pipeline, output_DTE_first_pipe is the output of the data transformation element (DTE) 506 of the first data transformation pipeline 502, and output_DTE_second_pipe is the output of the data transformation element (DTE) 510 of the second data transformation pipeline.

[0114] assume property((input_DTE_first_pipe==input_DTE_second_pipe)|->(output_DTE_first_pipe==output_DTE_second_pipe));

[0115] As will be appreciated by those skilled in the art, this example assumes that if the inputs to the substantially equivalent data transformation elements 506, 510 of the first data transformation pipeline and the second data transformation pipeline are the same (input_DTE_first_pipe == input_DTE_second_pipe), then the corresponding outputs of the substantially equivalent data transformation elements 506, 510 of the first data transformation pipeline and the second data transformation pipeline are the same ((output_DTE_first_pipe == output_DTE_second_pipe)).

[0116] Testing has shown that performing formal verification under such constraints increases the likelihood that the formal verification will converge. Once formal verification is complete, method 800 ends.

[0117] In some cases, one or more of blocks 804 through 812 may be performed before performing the formal verification of block 802. For example, before performing the formal verification of block 802, a list of potentially substantially equivalent pairs of data transformation elements in the first data transformation pipeline and the second data transformation pipeline may be identified at block 804. Potentially substantially equivalent pairs of data transformation elements in the first data transformation pipeline and the second data transformation pipeline may be identified manually (e.g., by a person) or may be identified automatically. For example, a computing-based device (such as a computer) may be used to identify the potentially substantially equivalent pairs of data transformation elements in the first data transformation pipeline and the second data transformation pipeline. Fig.14 The computing-based device 1400 is configured to automatically identify substantially equivalent data transformation elements by identifying identical code segments in the hardware design of the first data transformation pipeline and the second data transformation pipeline. Once a list of potential substantially equivalent data transformation element pairs is identified, the method 800 can proceed to block 806.

[0118] At block 806, it is determined whether any potential pairs of substantially equivalent data transformation elements identified in block 804 are not identical (i.e., not formed from the same code or defined by the same code in the respective hardware designs). If it is determined that at least one pair of substantially equivalent data transformation elements are not identical, then the method 800 may proceed to block 808, otherwise the method 800 may proceed directly to block 802, where the potential list of substantially equivalent pairs of data transformation elements is used as a list of substantially equivalent pairs of data transformation elements in formal verification of the hardware design of the first data transformation pipeline.

[0119] At block 808, where at least one pair of substantially identical data transformation elements identified in block 804 are not identical, then for each pair of substantially identical data transformation elements that are not identical, verify that the substantially identical data transformation elements are functionally equivalent. Verifying that a pair of data transformation elements are functionally equivalent may include formally verifying (e.g., by formally verifying one or more assertions) that the two data transformation elements always produce the same output in response to the same input. Once verification of the functional equivalence of different pairs of data transformation elements is complete, method 800 proceeds to block 810.

[0120] At block 810, it is determined whether the verification in block 808 is successful. If all verifications are successful, the method 800 proceeds directly to block 802, where the list of potential substantially equivalent data transformation element pairs is used as the list of substantially equivalent data transformation element pairs in the formal verification of the hardware design of the first data transformation pipeline. However, if at least one of the verifications in block 808 is unsuccessful, the method 800 proceeds to block 812, where the list of potential substantially equivalent data transformation element pairs is updated to exclude any pairs for which the verification in block 808 is unsuccessful. The method 800 then proceeds to block 802, where the updated list of potential substantially equivalent data transformation element pairs is used in the formal verification of the hardware design of the first data transformation pipeline. In this way, constraints (e.g., assumptions) will only be applied to data transformation element pairs that are identical or have been proven to be functionally equivalent. This is because, during formal verification, it cannot be safely assumed that two non-identical data transformation elements will produce the same output in response to the same input unless it is proven to be correct.

[0121] Reference now Fig. 9 , which shows the implementation Figure 4 The example method 900 of step 402 of method 400 is used to verify that the hardware design of the first data transformation pipeline is consistent (i.e., an instantiation of the hardware design always produces the same results for the same transaction (i.e., the same set of pipeline inputs), regardless of when the transaction is executed). In the method 900, the first data transformation pipeline and the second data transformation pipeline are the same (i.e., they are identical). In other words, in the method 900, the hardware design of the first data transformation pipeline and the second data transformation pipeline are two copies of the same hardware design.

[0122] exist Fig. 9In the method 900, the consistency of the hardware design of the first data transformation pipeline is verified by the following operations: verifying whether the instantiation of the hardware design of the data transformation pipeline executes the transaction from a predetermined state, the instantiation of the hardware design will produce the same output, and whether the instantiation of the hardware design of the data transformation pipeline executes the same transaction from any other state. This is accomplished by the following operations: when the instantiation of the hardware design of the second data transformation pipeline executes a transaction (referred to as an observed transaction herein) from a predetermined pipeline state (i.e., a state that occurs after the instantiation of the hardware design is reset), the input and output of the pipeline and the input and output of one or more data transformation elements are recorded. The recorded data can be collectively referred to as observed transaction data. Then formally verify that if the instantiation of the hardware design of the first data transformation pipeline executes the observed transaction, it will produce the recorded pipeline output. The formal verification tool will verify that when the observed transaction is executed from any state, the output of the instantiation of the hardware design of the first data transformation pipeline matches the recorded pipeline output for each possible observed transaction (i.e., each possible input set). This verifies that for any observed transaction (ie, for any set of pipeline inputs), an instantiation of the hardware design produces the same output for the observed transaction regardless of when the observed transaction is executed.

[0123] The method 900 begins at block 902, where a hardware design for a capture module is generated. The capture module is configured to capture observed transaction data of a second data transformation pipeline. The observed transaction data includes: a record of pipeline inputs and outputs of observed transactions (i.e., transactions executed from a predetermined state of the pipeline); and a record of inputs and outputs of one or more data transformation elements from the observed transactions. In the case where the output of a data transformation element represents a pipeline output, then the pipeline output may not be recorded separately from the input and output of the data transformation element, but may be derived from the output of the relevant data transformation element. Similarly, in the case where the input of one or more data transformation elements represents a pipeline input, then the pipeline input may not be recorded separately from the input and output of the data transformation element. In some cases, the capture module may be configured to record the inputs and outputs in one or more storage elements (e.g., one or more registers).

[0124] Thus, the hardware design of the capture module defines the functionality and structure of logic that is configured to monitor input and output signals of at least one data transformation element (or corresponding black box element) of the instantiation of the hardware design of the second data transformation pipeline, and store the value of each input and output signal of a transaction executed from a predetermined state of the pipeline in one or more storage elements (e.g., one or more registers). In other words, the logic is configured to capture inputs and outputs of at least one data transformation element (or corresponding black box element) of a transaction executed from a predetermined state of the pipeline by the instantiation of the hardware design of the second data transformation pipeline.

[0125] Such as, Figure 1 The example data transformation pipeline 100 is configured to compute the sum of eight inputs (a0+a1+a2+a3++a4+a5+a6+a7). Figure 1 The data transformation pipeline 100 includes a single data transformation element 102 that is configured to output the sum of two inputs. To execute a transaction (calculating the sum of eight inputs), the data transformation element 102 is used in eight cycles—in each of the eight cycles, the data transformation element 102 receives two inputs—a new input value and an input representing the sum of the previous inputs—and outputs the sum of the two inputs. Thus, capturing the input and output signals of the data transformation element 102 of the instantiation of the hardware design of the second data transformation pipeline for a transaction executed from a predetermined state includes capturing the input and output signals of the data transformation element 102 for eight consecutive cycles starting from the predetermined state (assuming no stalling or other events that extend the computation). In this case, because the pipeline inputs (a0, a1, a2, a3, a4, a5, a6, a7) are a subset of the inputs of the data transformation element 102, and the pipeline output (y7) is equal to one of the outputs of the data transformation element 102, the pipeline inputs and outputs can be derived from the inputs and outputs recorded for the data transformation element without the need for separate storage or recording.

[0126] Similarly, Figure 2 The example data transformation pipeline 200 is configured to calculate (a+b)*c. Figure 2The example data transformation pipeline 200 includes two data transformation elements—a first data transformation element 202 configured to calculate the sum of inputs a and b, and a second data transformation element 204 configured to calculate the product of the output y of the first data transformation element and the input c. Therefore, to execute a transaction, the data transformation element 202 is used in a first cycle, and the second data transformation element 204 is used in a second cycle. Therefore, capturing the input and output signals of the data transformation elements 202, 204 of the instantiation of the hardware design of the second data transformation pipeline for a transaction executed from a predetermined state includes: capturing the input and output signals of the first data transformation element 202 in the first cycle starting from the predetermined state, and capturing the input and output signals of the second data transformation element 204 in the second cycle starting from the predetermined state of the pipeline.

[0127] Where transactions are performed from a predetermined state of a pipeline as described herein, the term "state" of the pipeline is used herein to describe variable elements of a hardware design and their current values. In some cases, the predetermined state may be the state that occurs immediately after a reset. However, it will be apparent to one skilled in the art that this is merely an example and that other states of the pipeline may be used as the predetermined state. For example, in other cases, the predetermined state may be the state that occurs after a reset, the first random transaction, and a stop.

[0128] The hardware design of the capture module may be implemented, for example, in a hardware description language (HDL) such as VHDL, or may be implemented in an assertion-based language such as, but not limited to, SVA. Figure 1 The example SVA code of the hardware design of the capture module of the hardware design of the example data transformation pipeline 100 is shown in FIG. 1 . In this example, add.a is the input a of the data transformation element 102, add.b is the input b of the data transformation element 102, add.y is the output y of the data transformation element 102, stored_add_a is a register for storing the value of input a to the data transformation element 102, stored_add_b is a register for storing the value of input b to the data transformation element 102, stored_add_y is a register for storing the value of output y to the data transformation element 102, cycles_since_reset is the number of cycles since reset, and MAX_CYCLES is the maximum number of cycles for recording the input and output of the data transformation element 102 (for Figure 1 , when the count starts from 0, it can be 7).

[0129] always@(posedge clk)

[0130] begin

[0131] if(cycles_since_reset<=MAX_CYCLES)

[0132] begin

[0133] stored_add_a[cycles_since_reset]<=add.a;

[0134] stored_add_b[cycles_since_reset]<=add.b;

[0135] stored_add_y[cycles_since_reset]<=add.y;

[0136] end

[0137] end

[0138] It will be apparent to those skilled in the art that this example capture module causes the inputs (a and b) and output (y) of the data transformation element 102 to be added to stored_add_a, stored_add_b, and stored_add_y, respectively, each cycle after reset, until MAX_CYLES (for Figure 1 , if the first cycle is cycle 0, it may be cycle 7). Tables 2 to 4 show examples of what may be stored in registers (stored_add_a, stored_add_b, and stored_add_y), where a i 、b i ,y i Denotes the input and output in cycle i after reset. The data stored in the registers together form the observed transaction data.

[0139] Table 2

[0140]

[0141] Table 3

[0142]

[0143] Table 4

[0144]

[0145] Once the hardware design for the capture module is generated, method 900 proceeds to block 904 .

[0146] At block 904, the hardware design of the capture module is linked to the hardware design of the second data transformation pipeline so that: (i) the capture module is connected to appropriate signals of the second data transformation pipeline so that the inputs and outputs of the relevant data transformation elements can be monitored and acquired; and (ii) the hardware design of the capture module and the hardware design of the second data transformation pipeline are considered as one hardware design for the purpose of formal verification. Thus, once the hardware design of the capture module is linked to the hardware design of the second data transformation pipeline, when the formal verification tool creates an instance of the hardware design of the second data transformation pipeline, it includes an instance of the capture module.

[0147] In some cases, the hardware design of the capture module can be linked to the hardware design of the second data transformation pipeline by merging the hardware design of the capture module into the hardware design of the second data transformation pipeline. In other cases, the hardware design of the capture module can be linked to the hardware design of the second data transformation pipeline by binding the capture module to the hardware design of the second data transformation pipeline. For example, where the hardware design of the second data transformation is implemented in VHDL and the hardware design of the capture module is implemented in SV, the VHDL example can be bound to the SV example. Once the hardware design of the capture module is linked to the hardware design of the second data transformation pipeline, the method 900 proceeds to block 906.

[0148] At block 906, a formal verification tool is used to formally verify that if an instantiation of the hardware design of the first data transformation pipeline executes the observed transaction from any state of the pipeline, it produces the pipeline output recorded in the observed transaction data. As described above, transactions are defined by the inputs to the pipeline. Thus, if an instantiation of the hardware design of the first data transformation pipeline executes a transaction on the same pipeline inputs recorded in the observed transaction data, it is said to execute the observed transaction. For example, Figure 1 The pipeline inputs of the transactions executed by the instance data transformation pipeline 100 may be a0, a1, a2, a3, a4, a5, a6, and a7. If the observed transaction data records pipeline inputs 3, 4, 2, 6, 8, 3, 9, 10 for a0, a1, a2, a3, a4, a5, a6, and a7, respectively, then formal verification proves that if the instantiation of the first version of the hardware design of the data transformation pipeline receives 3, 4, 2, 6, 8, 3, 9, 10 from any state of the pipeline a0, a1, a2, a3, a4, a5, a6, and a7, respectively, then the output of the instantiation of the hardware design of the first data transformation pipeline matches the pipeline output recorded in the observed transaction data. Note that this is only an example, and during formal verification, the formal verification tool will verify the property for all possible observed transactions (i.e., for all possible sets of pipeline inputs).

[0149] Verifying that if an instantiation of the hardware design of the first data transformation pipeline executes the observed transaction from any state of the pipeline, it produces the pipeline output recorded in the observed transaction data may include generating one or more assertions and verifying the one or more assertions. For example, an assertion may be generated that determines that if the instantiation of the hardware design of the first data transformation pipeline receives the same pipeline inputs in the same order as the pipeline inputs recorded in the observed transaction data, it produces the pipeline output recorded in the observed transaction data. The following is an example SV assertion that may be used, where when the instantiation of the hardware design of the first data transformation pipeline executes the observed transaction (i.e., processes the same set of pipeline inputs in the same order as recorded in the observed transaction data), expect_watched_output_on_first_pipe is high, and it is now expected that the transaction has been completed and the results are ready to be output, first_pipe_output is the output of the instantiation of the hardware design of the first data transformation pipeline for the observed transaction, and stored_output is the pipeline output recorded in the observed transaction data:

[0150] assert_output:assert property(expect_watched_output_on_first_pipe|->(stored_output==first_pipe_output)

[0151] It will be apparent to one skilled in the art that this assertion states that if an instantiation of the hardware design for the first data transformation pipeline executes the observed transaction, then the output of the instantiation of the hardware design for the first data transformation pipeline is equal to the pipeline output recorded in the monitored transaction data.

[0152] Formal verification is performed under the constraint that if one or more data transformation elements of a first data transformation pipeline that records inputs and outputs in the observed transaction data receive a set of inputs recorded in the observed transaction data, the data transformation element outputs a recorded set of outputs.

[0153] As mentioned above, constraints can be implemented as one or more assumption statements. Figure 1 The data transformation element 102 of the data transformation pipeline 100 is written in SV. In this example, stored_add_a[i] is in the i-th th The first input a recorded in the observed transaction data of the data transformation element 102 in the cycle, stored_add_b[i] is in the i-th thThe second input b recorded in the observed transaction data of the data transformation element 102 in the cycle, stored_add_y[i] is in the i-th th The output y in the observed transaction data of the data transformation element 102 is recorded in the cycles, first_pipe_add_a is the first input a of the data transformation element 102 instantiated by the hardware design of the first data transformation pipeline, first_pipe_add_b is the second input b of the data transformation element 102 instantiated by the hardware design of the first data transformation pipeline, first_pipe_add_y is the output y of the data transformation element 102 instantiated by the hardware design of the first data transformation pipeline, and in this instance MAX_CYCLES is 7.

[0154] Generate

[0155] for(i=0;i<=MAX_CYCLES;i=i+1)begin:add_assumptions

[0156] assume_add:assume property((stored_add_a[i]==first_pipe_add_a)&&(stored_add_b[i]==first_pipe_add_b)|->(stored_add_y[i]==first_pipe_add_y));

[0157] end

[0158] end

[0159] As will be apparent to those skilled in the art, this example assumes that if, for any cycle (i) (stored_add_a[i] == first_pipe_add_a) && (stored_add_b[i] == first_pipe_add_b), the first input and second input of the data transformation element 102 of the hardware design of the first data transformation pipeline match the set of first inputs and second inputs recorded in the observed transaction data of the data transformation element, then the output of the instantiated data transformation element 102 of the hardware design of the first data transformation pipeline is equal to the output recorded in the observed transaction data of the data transformation element 102 in that cycle (i) (stored_add_y[i] == first_pipe_add_y)).

[0160] Testing has shown that performing formal verification under such constraints greatly increases the likelihood that the formal verification will converge. Once the formal verification is complete, the method 900 ends.

[0161] As described above, in some cases, prior to performing the formal verification of block 906, one or more of the substantially equivalent data transformation elements of the first data transformation pipeline and the second data transformation pipeline may be black-boxed to increase the likelihood that the formal verification will converge. Fig. 9 In method 900, the first data transformation pipeline and the second data transformation pipeline are identical, so each data transformation element in the first data transformation pipeline has the same data transformation element in the second data transformation pipeline. Therefore, all data transformation elements of the first data transformation and the second data transformation are "substantially equivalent" to the data transformation elements in the other data transformation pipelines. This means that, as described above, any data transformation element in the first data transformation pipeline or the second data transformation pipeline can be black-boxed as long as the output of the data transformation element or the corresponding data transformation element in the first data transformation element is constrained during formal verification.

[0162] As described above, in the case where the data transformation element of the first data transformation pipeline is black-boxed, the constraint on its output causes the black box element to function in a deterministic manner during formal verification. As described above, the constraint can be implemented by one or more assumption statements. As known to those skilled in the art, the assumption statement in the hardware design is interpreted by the formal verification tool as a constraint on the instantiation of the behavior of the hardware design during formal verification. Specifically, when a certain characteristic is assumed, the formal verification tool will limit the input so that the characteristic is established. Therefore, the assumption defines an environment in which the characteristics of the hardware design can be verified. Therefore, the assumption that the output of the black box element acts in a certain way relative to the stored input effectively causes the black box element to function in a deterministic manner during the formal verification of the stored input. Specifically, the assumption can show that if the input of the black box element matches the input set recorded in the observed transaction data of the corresponding data transformation element, the output of the black box element is the output of the corresponding data transformation element recorded in the observed transaction data for the input set. This effectively causes the black box element to respond to the input data recorded in the observed transaction data in the manner proposed in the observed transaction data.

[0163] For example, in the case where the first data transformation pipeline 1002 and the second data transformation pipeline 1004 are data transformation pipelines such as Figure 1 As shown, it includes a single data transformation element 102 that receives two inputs and outputs the sum of the two inputs - the data transformation element 102 for each data transformation pipeline 1002, 1004 in the hardware design can be replaced by a black box element 1006, such as Fig.10As shown, it receives two inputs and generates a single output. By black-boxing the data transformation element 102, the logic to perform the addition (a+b) is removed from the hardware design.

[0164] As described above, in this example, the hardware design of the second data transformation pipeline is linked to a capture module that is configured to capture the input and output signals (a) of the instantiated black box element 1006 of the hardware design of the second data transformation pipeline from a predetermined state (assuming no other events that stop or extend the computation). i , b i ,y i ). Then, formal verification is performed that when the instantiation of the hardware design of the first data transformation pipeline 1002 receives the pipeline inputs recorded by the capture module in the same order, it produces the pipeline outputs recorded by the capture module.

[0165] Formal verification is performed under a constraint (e.g., assumption 1008), wherein the constraint is that if the input (a and b) of the instantiated black box element 1006 of the hardware design of the first data transformation pipeline 1002 matches the input set recorded by the capture module, then the output (y) is equal to the output recorded by the capture module for the input set. This effectively causes the black box element 1006 to function according to the observed transaction data. For example, if the observed transaction data records the input a=2 and b=7 and output y=26 of the instantiated black box element 1006 of the hardware design of the second data transformation pipeline 1004, then when the instantiated black box element 1006 of the hardware design of the first data transformation pipeline 1002 receives input a=2 and b=7, it will output y=26. Thus, while the black box element 1006 of the second data transformation pipeline is considered to have "free" outputs during formal verification, the black box element 1006 of the first data transformation pipeline is considered to have deterministic outputs during formal verification with respect to the storage inputs of the black box element.

[0166] In another example, wherein the first data transformation pipeline 1102 and the second data transformation pipeline 1104 are data transformation pipelines, such as Figure 2 The data transformation pipeline 200 includes a first data transformation element 202 that receives two inputs and outputs the sum of the two inputs, and a second data transformation element 204 that receives two inputs and outputs the product of the two inputs. Each data transformation element 202, 204 in the hardware design of the first data transformation pipeline and the second data transformation pipeline can be replaced by a corresponding black box element 1106, 1108, as shown in FIG. Fig.11Specifically, each first data transformation element 202 can be replaced with a black box element 1106 that receives two inputs and has a "free" output, and the second data transformation element 204 can be replaced with a black box element 1108 that receives two inputs and has a "free" output. By black-boxing the data transformation elements 202 and 204, the logic for performing addition (a+b) and multiplication (y*c) is removed from the hardware design.

[0167] As described above, in this example, the hardware design of the second data transformation pipeline is linked to a capture module that is configured to capture the input and output signals of the first black box element 1106 from a predetermined state of the pipeline in a first cycle, and to capture the input and output signals of the second black box element 1108 from a predetermined state of the pipeline in a second cycle. Then, formal verification is performed that when the instantiation of the hardware design of the first data transformation pipeline 1102 receives the pipeline inputs recorded by the capture module in the same order, it produces the pipeline outputs recorded by the capture module.

[0168] Formal verification is performed under a first constraint (e.g., assumption 1110), wherein the first constraint is that if the inputs (a and b) of the first black box element 1106 of the instantiation of the hardware design of the first data transformation pipeline 1102 match the input set recorded in the observed transaction data of the element, then the output (y) is equal to the corresponding output recorded in the observed transaction data of the element; and formal verification is performed under a second constraint (e.g., assumption 1112), wherein the second constraint is that the inputs (y and c) of the second black box element 1108 of the instantiation of the hardware design of the first data transformation pipeline match the input set recorded in the observed transaction data of the element, then the output (z) is equal to the corresponding output recorded in the observed transaction data of the element. This causes each black box element 1106, 1108 in the instantiation of the hardware design of the first data transformation pipeline 1102 to produce a recorded output when receiving a recorded input set, otherwise the output is "free". For example, if the observed transaction data records the set of inputs 4 and 6 and output 8 of the data transformation element, when the corresponding black box element in the instantiation of the hardware design of the first data transformation pipeline receives inputs 4 and 6, it will output 8.

[0169] although Fig. 9The method 900 is described as being implemented using two copies of the hardware design of the data transformation pipeline under test—namely, the input / output of the instantiated data transformation elements of the hardware design of the second data transformation pipeline (i.e., the second copy of the hardware design of the first data transformation pipeline) is recorded for transactions executed from a predetermined state of the pipeline and compared with the input / output of the instantiated data transformation elements of the hardware design of the first data transformation pipeline (i.e., the first copy of the hardware design of the first data transformation pipeline) for transactions executed from any state of the pipeline—but in other instances, the method may be implemented using a single copy of the hardware design of the data transformation pipeline under test. In these cases, the hardware design may first be configured to execute transactions from a predetermined state, and the capture module records the input / output of the instantiated relevant data transformation elements of the design; then, the hardware design may be reconfigured to execute transactions from any state, and the input / output of the instantiated relevant data transformation elements of the hardware design is compared with the recorded input / output. In this way, when the hardware design is configured to execute transactions from a predetermined state, the hardware design acts as the hardware design of the second data transformation pipeline, and when the hardware design is configured to execute transactions from any state, the hardware design acts as the hardware design of the first data transformation pipeline, as the terms first data transformation pipeline and second data transformation pipeline are used above.

[0170] Reference now Figures 12 to 13 , which describes a second embodiment of verifying a hardware design for a data transformation pipeline. In this embodiment, a version of the hardware design for the data transformation pipeline is generated in which a selected set of data transformation elements are replaced with or linked to functional elements that are treated by a formal verification tool as unevaluated functions of their inputs, such that during formal verification, the functional elements will produce the same outputs in response to the same inputs; and formal verification is performed to verify that for each transaction in a set of transactions, an instantiation of the version of the hardware design for the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs for the transaction.

[0171] In some cases, verifying that, for each transaction in the set of transactions, an instantiation of the version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs for the transaction may include formally verifying that the instantiation of the version of the hardware design is consistent (i.e., it always produces the same result of the transaction regardless of when the transaction is executed). In these cases, the reference set of one or more outputs for the transaction may be the set of one or more outputs generated by the instantiation of the version of the hardware design of the data transformation pipeline when the instantiation executes the transaction from a predetermined state of the pipeline.

[0172] In other cases, verifying that, for each transaction in the set of transactions, an instantiation of a version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs for the transaction may include formally verifying that the instantiation of the version of the hardware design is functionally equivalent to an instantiation of the hardware design of another data transformation pipeline. The other data transformation pipeline includes at least one data transformation element that is substantially equivalent to the data transformation element of the data transformation pipeline under test. In these cases, the reference set of one or more outputs for the transaction may be the set of one or more outputs generated by the instantiation of the version of the hardware design of the other data transformation pipeline when the transaction is instantiated for execution.

[0173] Reference now Fig.12 , which illustrates a second example method 1200 for verifying a hardware design of a data transformation pipeline. The method 1200 begins at block 1202, where a version of the hardware design of a data transformation pipeline is generated in which a selected set of data transformation elements of the pipeline (which may be all data transformation elements or a subset of data transformation elements) are replaced by functional elements that are considered unevaluated functions of the inputs of the data transformation elements. The unevaluated function F is a symbolic object such that This means that the formal verification tool will be able to verify that F(x) = F(x), but the formal verification tool cannot verify that F(x) = anything else, which will fail.

[0174] The specific set of data transformation elements that are replaced with functional elements can be based on whether the method is being used to verify that the hardware design of the data transformation pipeline is consistent, or whether the method is being used to verify that the hardware design of the hardware data transformation pipeline is functionally equivalent to the hardware design of another data transformation pipeline. In the case where the method is used to verify that the hardware design of the data transformation pipeline is consistent (i.e., it always produces the same results for transactions regardless of when the transaction is executed), then any combination of data transformation elements of the data transformation pipeline can be replaced with functional elements. Conversely, in the case where the method is used to verify that the hardware design of the data transformation pipeline is functionally equivalent to the hardware design of another data transformation pipeline (i.e., instantiations of the two hardware designs produce the same results for the same inputs) and at least one data transformation of the other data transformation pipeline is substantially equivalent to the data transformation element of the data transformation pipeline under test, then any combination of substantially equivalent data transformation elements can be replaced with functional elements.

[0175] For example, to verify Figure 1In accordance with the hardware design of the example data transformation pipeline 100 of , a version of the hardware design used in formal verification can be generated by replacing the data transformation element 102 with a functional element that is treated as an unevaluated function F(a, b)=y, so that whenever the same set of a and b is received, the output y will be the same, but no other properties of F are assumed. Similarly, to verify Figure 2 In accordance with the hardware design of the example data transformation pipeline 200, a version of the hardware design for formal verification can be generated by replacing one or both of the first data transformation element 202 and the second data transformation element 204 with corresponding functional elements. For example, the first data transformation element 202 can be replaced with a functional element that is treated as an unevaluated function F(a, b) = y, so that whenever the same set of a and b is received, the output y will be the same; and the second data transformation element 204 can be replaced with a functional element that is treated as an unevaluated function G(y, c) = z, so that whenever the same set of y is received, the output z will be the same.

[0176] On the contrary, to verify Figure 5 The hardware design of the first data transformation pipeline 502 as an example is functionally equivalent to Figure 5 The hardware design of a second data transformation pipeline 504 as an example, in which there is only a pair of substantially identical data transformation elements (i.e., data transformation elements 506, 510), only the first data transformation element 506 in the hardware design of the first example data transformation elements can be replaced by a functional element that is considered as an unevaluated function of its input, so that the output will be the same whenever the same set of inputs is received.

[0177] Replacing data transformation elements with functional elements means that if at any time the same set of inputs passes through the same functional elements, the data transformation pipeline should produce the same results (assuming the control logic works as expected).

[0178] Once a version of the hardware design for the data transformation pipeline has been generated, the method 1200 proceeds to block 1204 .

[0179] At block 1204, it is formally verified that, for each transaction in the set of transactions, instantiation of the version of the hardware design of the data transformation pipeline generated in block 1202 produces a set of one or more outputs that matches the reference set of one or more outputs. The set of transactions may include all valid transactions that may be executed by the data transformation pipeline, or may include only a subset of valid transactions that may be executed by the data transformation pipeline.

[0180] In some cases, formally verifying that, for each transaction in a set of transactions, an instantiation of a version of the hardware design for a data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs for the transaction may include formally verifying that the instantiations of the version of the hardware design for the data transformation pipeline are consistent (i.e., the instantiations of the version of the hardware design for the data transformation pipeline produce the same results (or outputs) for the same transaction regardless of when the transaction is executed (i.e., regardless of the state of the pipeline when the transaction is executed)). In these cases, the reference set of one or more outputs of the transaction may be the set of one or more outputs generated by the instantiation of the version of the hardware design for the data transformation pipeline when the instance executes the transaction from a predetermined state of the pipeline. As described above, transactions are defined by their inputs. Thus, if instantiations of a version of the hardware design for a data transformation pipeline process the same set of inputs, they are said to execute the same transaction. For example, Figure 1 The inputs to a transaction of an instance of data transformation pipeline 100 are a0, a1, a2, a3, a4, a5, a6, and a7. In this example, an instantiation of a version of the hardware design of the data transformation pipeline is said to execute the same transaction if it executes the transaction for a0, a1, a2, a3, a4, a5, a6, a7=3, 4, 2, 6, 8, 3, 9, 10 from one state of the pipeline (i.e., the state emerging from reset) and executes the transaction for a0, a1, a2, a3, a4, a5, a6, a7=3, 4, 2, 6, 8, 3, 9, 10 from another state of the pipeline.

[0181] Formal verification of the consistency of instantiation of the version of the hardware design of the data transformation pipeline may include: comparing the output of the instantiation of the version of the hardware design of the data transformation pipeline when the data transformation pipeline executes a transaction from a predetermined state with the output of the instantiation of the version of the hardware design of the data transformation pipeline when the data transformation pipeline executes a transaction from any state. This can be achieved using two copies of the version of the hardware design of the data transformation or a single copy of the version of the hardware design of the data transformation pipeline. For example, formal verification of the consistency of instantiation of the version of the hardware design of the data transformation pipeline may include: when the same transaction is executed by two instantiations, formal verification that the output of the instantiation of the first copy of the version of the hardware design configured to execute the transaction from the predetermined state matches the output of the instantiation of the second copy of the version of the hardware design configured to execute the transaction from any state. Optionally, formal verification of the consistency of instantiation of the version of the hardware design of the data transformation pipeline may include: first configuring the version of the hardware design of the data transformation pipeline to execute the transaction from the predetermined state, and recording the output of the instantiation of the version of the hardware design; then configuring the version of the hardware design of the data transformation pipeline to execute the transaction from any state, and comparing the output of the instantiation of the version of the hardware design with the recorded output.

[0182] In other cases, formally verifying that, for each transaction in the transaction set, an instantiation of a hardware-designed version of a data transformation pipeline produces a set of one or more outputs, the set of one or more outputs matching a reference set of one or more outputs of the transaction may include: formally verifying that an instantiation of a hardware-designed version of a data transformation pipeline is functionally equivalent to an instantiation of a hardware-designed version of another data transformation pipeline. The other data transformation pipeline includes at least one data transformation element that is substantially equivalent to a data transformation element of the data transformation pipeline under test. In these cases, formal verification may compare the output of the hardware-designed version of the data transformation pipeline with the output of the hardware-designed version of the other data transformation pipeline, wherein one or more of the substantially equivalent data transformation elements in the other data transformation pipeline has been replaced with a functional element that is used to replace the substantially equivalent data transformation element in the data transformation pipeline under test. Thus, in these cases, the reference set of one or more outputs of a transaction may be a set of one or more outputs generated by an instantiation of a hardware-designed version of the other data transformation pipeline when the instantiation executes the transaction.

[0183] In either case, for each of the multiple transactions, formally verifying that an instantiation of a version of the hardware design for the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs for the transaction, may include: generating one or more assertions, linking the one or more assertions to the version of the hardware design for the data transformation pipeline, formally verifying, using a formal verification tool, that the one or more assertions are true (or applicable) for the version of the hardware design for the data transformation pipeline, and outputting one or more signals to indicate whether the one or more assertions are successfully verified.

[0184] Once formal verification is complete, method 1200 may end, or method 1200 may proceed to block 1206 .

[0185] At block 1206, it may be determined whether verification of the version of the hardware design of the data transformation pipeline was successful. As described above, when a formal verification tool is used to verify assertions for a hardware design, the formal verification tool may output a signal or a set of signals indicating whether the assertion is valid (i.e., the asserted property is true for all valid states or sequences of states). In these cases, the determination of whether verification was successful may be based on the output signal of the formal verification tool.

[0186] If it is determined that verification of the version of the hardware design for the data transformation pipeline is successfully completed—indicating that an instantiation of the hardware design will produce, for any transaction, a set of one or more outputs that matches a reference set of one or more outputs for the transaction (i.e., the instantiation is consistent, or the instantiation is functionally equivalent to an instantiation of another design)—then method 1200 can proceed to block 1210, where an integrated circuit embodying the data transformation pipeline described by the hardware design is fabricated. However, if it is determined that verification of the version of the hardware design for the data transformation pipeline is unsuccessful—indicating that an error exists in the hardware design—then method 1200 can proceed to block 1208, where the hardware design is modified to correct the error caused by the unexpected behavior in the hardware design. Once the hardware design is modified, the modified hardware design can be re-verified (e.g., blocks 1202-1210 can be repeated for the modified hardware design).

[0187] Fig.12 The verification method 1200 described above Figure 4 The verification method 400 for verifying the hardware design consistency of the data transformation pipeline is much simpler because it does not involve storing observed transaction data or controlling the output of the data transformation element or black box element based on the observed transaction data. However, Fig.12 The verification method 1200 is generally feasible only for formal verification tools that interpret such functional elements in the above manner. Specifically, Fig.12 The verification method 1200 is typically only feasible for formal verification tools that interpret these functional elements as unevaluated functions as their inputs.

[0188] In some cases, constraints or restrictions may be imposed on the output of one or more of the functional elements to ensure that the functional element does not generate an unexpected output or an output with an unexpected characteristic (i.e., an output that cannot be effectively generated by the corresponding data transformation element). For example, such restrictions may be imposed on the functional element by adding assumptions in a version of the hardware design of the data transformation pipeline. For example, if the data transformation element is configured to generate the square of the input, the data transformation element cannot effectively output a negative number. Therefore, the downstream component may expect the data transformation element to output a number greater than or equal to zero. In this example, an assumption that replaces the data transformation element may be generated for the functional element, which assumption indicates that the output of the functional element is greater than or equal to zero. Similarly, if the data transformation element is configured to output the sine of the input, an assumption that replaces the data transformation element may be generated for the functional element, which assumption indicates that the output of the functional element is between -1 and 1. It will be apparent to those skilled in the art that these are only examples, and other constraints or restrictions may be imposed on the functional element.

[0189] Reference now Fig.13, which shows an example system 1300 for verifying the hardware design of a data transformation pipeline according to the second embodiment, wherein a verified version of the hardware design of the data transformation pipeline - in which one or more data transformation elements of the pipeline are replaced by functional elements - generates, for each transaction in a set of transactions, a set of one or more outputs that matches a reference set of one or more outputs of the transaction.

[0190] The system 1300 includes: a version 1302 of a hardware design for a data transformation pipeline, in which one or more data transformation elements have been replaced with functional elements; one or more formal assertions 1304; and a formal verification tool 1306. In the case where the system 1300 is used to verify that two hardware designs for different data transformation pipelines are functionally equivalent, the system 1300 may also include versions of the hardware design for other data transformation pipelines, in which one or more data transformation elements have been replaced with functional elements. In general, the formal verification tool 1306 is configured to formally verify that the one or more assertions 1304 are true for the version 1302 of the hardware design for the data transformation pipeline, to verify that an instantiation of the data transformation pipeline generates, for any transaction, a set of one or more outputs that matches a reference set of one or more outputs for the transaction.

[0191] The version 1302 of the hardware design of the data transformation pipeline is a version of the hardware design of the data transformation pipeline in which the description of the structure and / or function of each of the selected set of data transformation elements of the data transformation pipeline has been replaced with a description of the structure and / or function of a functional element that is treated by the formal verification tool as an unevaluated function of its input. In other words, the version of the hardware design of the data transformation pipeline describes the data transformation pipeline of the initial hardware design, except that each of the selected set of data transformation elements has been replaced with a corresponding functional element.

[0192] Similarly, if there is a version of the hardware design of the other data transformation pipeline, then this version of the hardware design of the other data transformation pipeline is a version of the hardware design of the other data transformation pipeline: wherein the description of the structure and / or function of each of the selected set of data transformation elements of the data transformation pipeline has been replaced with a description of the structure and / or function of a functional element that is treated by the formal verification tool as an unevaluated function of its input. In these cases, the selected set of data transformation elements replaced by functional elements are substantially equivalent data transformation elements (i.e., data transformation elements that have substantially equivalent data transformation elements in the other data transformation pipeline), and each pair of substantially equivalent data transformation elements is replaced with the same functional element.

[0193] Assertions 1304 include one or more formal assertions that, if verified as true for a version of the hardware design for the data transformation pipeline, can determine that an instantiation of the hardware design for the data transformation produces, for any transaction, a set of one or more outputs that matches a reference set of one or more outputs for the transaction. As described above, an assertion is a statement that a particular property is expected to hold for the hardware design (i.e., is always true).

[0194] In the case where an instantiation of a version of the hardware design for a data transformation pipeline produces, for any transaction, a set of one or more outputs that matches a reference set of one or more outputs for that transaction, if the instantiation of the version of the hardware design for the data transformation pipeline produces the same outputs for transformations performed on the same inputs regardless of when the transaction is executed (i.e., regardless of the state of the pipeline when the changes are executed), then one or more assertions 1304 may assert that if the instantiation of the version of the hardware design for the data transformation pipeline executes the transaction it has ever seen, the outputs are the same.

[0195] In the case where an instantiation of a version of a hardware design for a data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs for any transaction, if the instantiation of the version of the hardware design for the data transformation pipeline is functionally equivalent to the instantiation of another version of the hardware design for the data transformation pipeline, then the one or more assertions 1304 may assert that the outputs of the instantiations of the two versions of the hardware design are always the same.

[0196] The one or more assertions 1304 are linked to the versions 1302, 1308 of the hardware design of the data transformation pipeline, so that the one or more assertions are connected to the relevant signals of the version of the hardware design of the data transformation pipeline to be able to evaluate the characteristics of the assertions. As described above, the one or more assertions can be linked to the version of the hardware design by the following operations: merging the one or more assertions into the version of the hardware design of the data transformation pipeline, or binding the one or more assertions 1304 to the version of the hardware design of the data transformation pipeline.

[0197] Formal verification tool 1306 is a software tool capable of performing formal verification on a hardware design. Because formal verification ideally verifies assertions in infinite time, it may be advantageous to use an infinite time formal verification tool.

[0198] A version 1302, 1308 of the hardware design of the data transformation pipeline; one or more assertions 1304; and bindings (if any) are loaded into a formal verification tool 1306. The formal verification tool 1306 is then configured to formally verify that the one or more assertions 1304 are true for the version of the hardware design of the data transformation pipeline.

[0199] As described above, formal verification tool 1306 may output information to indicate whether an assertion was successfully verified and / or whether one or more assertions were not successfully verified, thereby indicating a state or sequence of states of the hardware design that caused the assertion to fail.

[0200] although Fig.12 and Fig.13 The method 1200 and system 1300 are described as including: generating a data-transformed version of the hardware design (in which at least one data-transformed element is replaced with a functional element), and then formally verifying for each transaction in a transaction set that a set of outputs of an instantiation of the version of the hardware design matches a reference set of outputs of the transaction, but in other instances, instead of replacing the data-transformed element with a functional element, the version of the hardware design can be generated by linking the data-transformed element to the functional element so that during formal verification, the functional element provides hints about the outputs of the data-transformed element. In this way, the functional element is replaced with a reference set of outputs of the data-transformed element. Figures 4 to 11 The constraints of the methods and systems of formal verification work in the same way. Specifically, a formal verification tool can use the functional element abstraction to simplify formal verification by avoiding the full complexity of using a data transformation element, regardless of the fact that the property being verified does not depend on the details of the data transformation, but only on the fact that it will always give the same output in response to the same input. For other properties that do depend on the details of the data transformation, this abstraction may not help with verification, but other properties of the data transformation (e.g., squaring only produces positive outputs) can be imposed on the functional element (e.g., as one or more assumptions) to improve convergence. In some cases, the full details of the data transformation may be required for verification, and the functional element abstraction will not provide any help, but this is very rare.

[0201] In other examples, the two uses of functional elements can be combined to verify the hardware design of the data transformation pipeline. In particular, in some examples, one or more data transformation elements can be linked to the functional element so that the functional element provides hints about the output of the data transformation element during formal verification; and one or more other data transformation elements can be replaced with the functional element.

[0202] In addition, despite Figures 4 to 11 Methods and systems and Fig.12 and Fig.13The methods and systems are described above as separate and distinct, but in other instances, a combination of the two methods can be used to verify the hardware design of a data transformation pipeline. In particular, in other instances, the hardware design of a first data transformation pipeline can be verified by formally verifying that a set of one or more outputs of an instantiation of the hardware design of the first data transformation pipeline matches a set of one or more outputs of an instantiation of the hardware design of the second data transformation pipeline for a predetermined set of transactions, wherein (i) the formal verification is performed under the constraint that a pair of substantially identical data transformation elements of the first data transformation pipeline and the second data transformation pipeline produce the same output in response to the same input; and (ii) another pair of substantially identical data transformation elements of the first data transformation pipeline and the second data transformation pipeline can be replaced with or linked to a functional element prior to formal verification. In these instances, as described above, one or more of the constrained pair of substantially identical data transformation elements can be replaced with a black box element prior to formal verification.

[0203] Fig.14 Various components of an exemplary computing-based device 1400 are shown, which may be implemented as any form of computing and / or electronic device and in which embodiments of the methods and systems described herein may be implemented.

[0204] The computing-based device 1400 includes: one or more processors 1402, which may be microprocessors; a controller or any other suitable type of processor for processing computer executable instructions to control the operation of the device in order to verify the hardware design of the data transformation pipeline. In some instances, for example, where a system-on-chip architecture is used, the processor 1402 may include one or more fixed functional blocks (also referred to as accelerators) in hardware (rather than software or firmware) that implement a portion of the method of verifying the hardware design of the data transformation pipeline. Platform software including an operating system 1404 or any other suitable platform software may be provided on the computing-based device to enable application software such as a formal verification tool to be executed on the device.

[0205] Computer executable instructions can be provided using any computer-readable medium accessible by computing-based device 1400. Computer-readable media may include, for example, computer storage media, such as memory 1406 and communication media. Computer storage media (i.e., non-temporary machine-readable media) such as memory 1406 include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, or program modules or other data. Computer storage media include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical storage, cassettes, tapes, disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information for access by a computing device. In contrast, communication media can embody computer-readable instructions, data structures, program modules or other data in modulated data signals such as carrier waves or other transmission mechanisms. As defined herein, computer storage media do not include communication media. Although computer storage media (i.e., non-transitory machine-readable media, such as memory 1406) are shown within computing-based device 1400, it should be understood that the memory may be distributed or remotely located and may be accessed via a network or other communications link (e.g., using communications interface 1408).

[0206] The computing-based device 1400 also includes an input / output controller 1410, which is arranged to output display information to a display device 1412, which can be separate from or integrated with the computing-based device 1400. The display information can provide a graphical user interface. The input / output controller 1410 is also arranged to receive and process input from one or more devices, such as a user input device 1414 (e.g., a mouse or keyboard). The user input can be used to initiate verification. In one embodiment, if the display device 1412 is a touch-sensitive display device, it can also serve as the user input device 1414. The input / output controller 1410 can also output data to a device other than the display device, such as a locally connected printing device ( Fig.14 not shown).

[0207] Fig.15 15 shows a computer system in which any data transformation pipeline described herein may be implemented. The computer system includes a CPU 1502, a GPU 1504, a memory 1506, and other devices 1514, such as a display 1516, a speaker 1518, and a camera 1520. The data transformation pipeline 1510 (such as but not limited to the above referenced) is implemented on the GPU 1504. Figures 1 to 31502). In other examples, the data transformation pipeline 1510 can be implemented on the CPU 1502. The components of the computer system can communicate with each other via the communication bus 1522.

[0208] In general, any of the functions, methods, techniques or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry) or any combination thereof. The terms "module", "function", "component", "element", "unit", "block" and "logic" may be used herein to generally represent software, firmware, hardware or any combination thereof. In the case of a software implementation, a module, function, component, element, unit, block or logic represents a program code that performs a specified task when executed on a processor. The algorithms and methods described herein may be performed by one or more processors that execute code, which causes the processor to perform the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disk, flash memory, hard disk storage, and other memory devices that can use magnetic, optical and other technologies to store instructions or other data and can be accessed by a machine.

[0209] As used herein, the terms computer program code and computer readable instructions refer to any kind of executable code for execution by a processor, including code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, byte code, code that defines an integrated circuit (such as a hardware description language or netlist), and code expressed in programming language code such as C, Java, or OpenCL. Executable code can be, for example, any kind of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, run in a virtual machine or other software environment, causes a processor of a computer system supporting the executable code to perform the tasks specified by the code.

[0210] A processor, computer or computer system may be any kind of device, machine or special purpose circuit, or a collection or part thereof, which has processing capabilities so that instructions can be executed. A processor may be any kind of general or special purpose processor, such as a CPU, GPU, system on a chip, state machine, media processor, application specific integrated circuit (ASIC), programmable logic array, field programmable gate array (FPGA), etc. A computer or computer system may include one or more processors.

[0211] The present invention is also intended to cover software that defines the configuration of hardware as described herein, such as hardware description language (HDL) software for designing integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided on which is encoded computer-readable program code in the form of an integrated circuit definition data set (i.e., a hardware design) that, when processed (i.e., run) in an integrated circuit manufacturing system, configures the system to manufacture an apparatus (e.g., a processor or other computing-based apparatus) that includes any of the devices (e.g., a data transformation pipeline) described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0212] Thus, a method of manufacturing a data transformation pipeline as described herein in an integrated circuit manufacturing system may be provided. In addition, an integrated circuit definition data set (e.g., a hardware design) may be provided that, when processed in an integrated circuit manufacturing system, enables the method of manufacturing a data transformation pipeline to be performed.

[0213] An integrated circuit definition data set (e.g., a hardware design) may be in the form of computer code, for example as a netlist, code for configuring a programmable chip, as a hardware description language that defines hardware suitable for fabrication at any level in an integrated circuit, including as register transfer level (RTL) code, as a high-level circuit representation such as Verilog or VHDL, and as a low-level circuit representation such as OASIS (RTM) and GDSII. Higher-level representations that logically define hardware suitable for fabrication in an integrated circuit, such as RTL, may be processed on a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining those elements to generate a manufacturing definition of the integrated circuit defined by the representation. As is typically the case with software executed at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate a manufacturing definition of the integrated circuit to execute code that defines the integrated circuit to generate the manufacturing definition of the integrated circuit.

[0214] Now refer to Fig.15 An example of processing an integrated circuit definition data set (eg, a hardware design) at an integrated circuit manufacturing system to configure the system into a manufacturing data transformation pipeline is described.

[0215] Fig.16An example of an integrated circuit (IC) manufacturing system 1602 is shown, which is configured to manufacture a data transformation pipeline as described in any example herein. In particular, the IC manufacturing system 1602 includes a layout processing system 1604 and an integrated circuit generation system 1606. The IC manufacturing system 1602 is configured to receive an IC definition data set (such as a hardware design that defines a data transformation pipeline as described in any example herein), process the IC definition data set, and generate an IC (e.g., which embodies a data transformation pipeline as described in any example herein) based on the IC definition data set. By processing the IC definition data set, the IC manufacturing system 1602 is configured to manufacture an integrated circuit that embodies a data transformation pipeline as described in any example herein.

[0216] The layout processing system 1604 is configured to receive and process an IC definition data set (e.g., a hardware design) to determine a circuit layout. Methods for determining a circuit layout based on an IC definition data set are known in the art and may, for example, involve synthesizing RTL code to determine a gate-level representation of a circuit to be generated, such as in terms of logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining location information for the logic components, the circuit layout may be determined based on the gate-level representation of the circuit. This may be done automatically or with user involvement in order to optimize the circuit layout. When the layout processing system 1604 has determined the circuit layout, it may output the circuit layout definition to the IC generation system 1606. The circuit layout definition may be, for example, a circuit layout description.

[0217] As is known in the art, IC generation system 1606 generates an IC according to the circuit layout definition. For example, IC generation system 1606 may implement a semiconductor device manufacturing process to generate the IC, which may involve a multi-step sequence of photolithography and chemical processing steps during which electronic circuits are gradually formed on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask that can be used in a photolithography process to generate the IC according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 1606 may be in the form of a computer readable code that IC generation system 1606 may use to form a suitable mask for generating the IC.

[0218] The different processes performed by IC manufacturing system 1602 may all be performed at one location, such as by one party. Alternatively, IC manufacturing system 1602 may be a distributed system such that some processes may be performed at different locations and by different parties. For example, some of the following stages may be performed at different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition data set to form a gate-level representation of a circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0219] In other examples, processing of the integrated circuit definition data set at the integrated circuit manufacturing system may configure the system to manufacture a data transformation pipeline in which the IC definition data set is not processed to determine a circuit layout. For example, the integrated circuit definition data set may define a configuration of a reconfigurable processor such as an FPGA, and processing of the data set may configure the IC manufacturing system to generate (e.g., by loading the configuration data into the FPGA) a reconfigurable processor having the defined configuration.

[0220] In some embodiments, when processed in an integrated circuit manufacturing system, the integrated circuit manufacturing definition data set can enable the integrated circuit manufacturing system to generate an apparatus as described herein. Fig.16 The configuration of an integrated circuit manufacturing system in the described manner can be used to manufacture the devices described herein.

[0221] In some examples, the integrated circuit definition data set may include software that runs on, or in combination with, the hardware defined at the data set. Fig.16 In the example shown in , the IC generation system can be further configured by the integrated circuit definition dataset to load firmware onto the integrated circuit according to the program code defined in the integrated circuit definition dataset when manufacturing the integrated circuit, or otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0222] Compared to known implementations, the implementation of the concepts set forth in this application in devices, apparatuses, modules and / or systems (and in the methods implemented herein) can cause performance improvements. Performance improvements can include one or more of improved computing performance, reduced waiting time, increased throughput and / or reduced power consumption. During the manufacture of such devices, devices, modules and systems (e.g., in integrated circuits), a trade-off can be made between performance improvements and physical implementations to improve manufacturing methods. For example, a trade-off can be made between performance improvements and layout area to match the performance of known implementations, but using less silicon. For example, this can be accomplished by reusing functional blocks in a serial manner or sharing functional blocks between elements of devices, devices, modules and / or systems. On the contrary, the concepts of improvements (e.g., reduced silicon area) that cause physical implementations of devices, devices, modules and systems set forth in this application can be weighed against performance improvements. For example, this can be accomplished by manufacturing multiple instances of a module within a predefined area budget.

[0223] Applicants hereby independently disclose each individual feature described herein and any combination of two or more such features, to the extent that such feature or combination can be implemented according to the common general knowledge of a person skilled in the art based on the specification as a whole, regardless of whether such feature or combination of features solves any problem disclosed herein. In view of the foregoing description, it will be clear to a person skilled in the art that various modifications can be made within the scope of the invention.

Claims

1. A computer-implemented method for verifying a hardware design of a data transformation pipeline, the data transformation pipeline comprising one or more data transformation elements that perform data transformations on one or more inputs, the method comprising performing the following operations at one or more processors: generating a version of the hardware design of the data transformation pipeline, wherein: a data transformation element of the one or more data transformation elements has been replaced with or linked to a function element, the function element being treated by a formal verification tool as an unevaluated function of the one or more inputs of the data transformation element that has been replaced with or linked to the function element, such that during formal verification, whenever the same set of one or more inputs is received, the function element produces the same set of one or more outputs; as well as For each transaction in the set of transactions, formally verifying that an instantiation of the version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs of the transaction.

2. The method of claim 1, wherein: For each transaction in the transaction set, formally verifying that the instantiation of the version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs of the transaction, including: formally verifying that the instantiation of the version of the hardware design of the data transformation pipeline produces the same set of one or more outputs for the same transaction regardless of the state of the data transformation pipeline executed from the transaction.

3. The method of claim 1, wherein: The reference set of one or more outputs of a transaction is a set of one or more outputs produced by the instantiation of the version of the hardware design of the data transformation pipeline when the instantiation of the version of the hardware design of the data transformation pipeline executes the transaction from a predetermined state of the pipeline.

4. The method of claim 2 or claim 3, further comprising: Formally verifying that an instantiation of the hardware design of the data transformation pipeline produces correct output for any transaction executed from a predetermined state of the pipeline.

5. The method of claim 1, wherein: For each transaction in the transaction set, formally verifying that the instantiation of the version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs of the transaction, including: formally verifying that the instantiation of the version of the hardware design of the data transformation pipeline produces the same set of one or more outputs in response to the same set of one or more inputs as an instantiation of a version of the hardware design of another data transformation pipeline.

6. The method of claim 1, wherein: The reference set of one or more outputs of a transaction is a set of one or more outputs produced by an instantiation of a version of a hardware design of another data transformation pipeline when the instantiation of the version of the hardware design of another data transformation pipeline executes the transaction.

7. The method of claim 5 or claim 6, wherein: The other data transformation pipeline includes one or more data transformation elements that perform data transformation on one or more inputs, and the data transformation elements of the data transformation pipeline that are replaced by or linked to the functional elements are substantially identical to the data transformation elements of the other data transformation pipeline.

8. The method of claim 7, further comprising: The version of the hardware design of the other data transformation pipeline is generated from the hardware design of the other data transformation pipeline by replacing substantially equivalent data transformation elements of the other data transformation pipeline with or linking to the functional elements.

9. The method according to any one of claims 1 to 3 or 5 to 6, wherein: The version of the hardware design of the data transformation pipeline is generated by replacing each of the one or more data transformation elements of the data transformation pipeline with or linking to a functional element.

10. The method according to any one of claims 1 to 3 or 5 to 6, wherein For each transaction in the transaction set, formally verifying that the instantiation of the version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs of the transaction, including: formally verifying that one or more assertions are true for the hardware design of the data transformation pipeline.

11. The method according to any one of claims 1 to 3 or 5 to 6, wherein: The formal verification is performed under the constraint that the functional element does not generate outputs that cannot be effectively generated by the data transformation element.

12. The method of claim 11, wherein: The constraints are implemented as assumption statements.

13. The method of any one of claims 1 to 3 or 5 to 6, wherein: The version of the hardware design of the data transformation pipeline is generated by replacing the data transformation elements with the functional elements.

14. The method of any one of claims 1 to 3 or 5 to 6, wherein: The version of the hardware design of the data transformation element is generated by linking the data transformation element to the functional element such that the functional element provides hints related to the output of the data transformation element during formal verification.

15. The method of any one of claims 1 to 3 or 5 to 6, further comprising outputting one or more signals indicating whether the formal verification was successful.

16. The method of any one of claims 1 to 3 or 5 to 6, further comprising: In response to a determination that the formal verification is unsuccessful, the hardware design of the data transformation pipeline is modified to generate a modified hardware design of the data transformation pipeline.

17. The method of claim 16, further comprising: generating a version of the modified hardware design of the data transformation pipeline in which the data transformation elements are replaced with or linked to the functional elements; and repeating the formal verification of the version of the modified hardware design of the data transformation pipeline.

18. The method of any one of claims 1 to 3 or 5 to 6, further comprising: In response to a determination that the formal verification was successful, an integrated circuit embodying the data transformation pipeline is fabricated using an integrated circuit fabrication system according to the hardware design.

19. The method of claim 18, wherein: Manufacturing an integrated circuit embodying the data transformation pipeline using an integrated circuit manufacturing system according to the hardware design, including: processing the hardware design of the data transformation pipeline using a layout processing system to generate a circuit layout description of an integrated circuit embodying the data transformation pipeline; and An integrated circuit embodying the data transformation pipeline is manufactured using an integrated circuit fabrication system according to the circuit layout description.

20. The method of any one of claims 1 to 3 or 5 to 6, wherein: When processed in an integrated circuit manufacturing system, the hardware design of the data transformation pipeline configures the integrated circuit manufacturing system to manufacture integrated circuits embodying the data transformation pipeline.

21. A system for verifying a hardware design of a data transformation pipeline, the data transformation pipeline comprising one or more data transformation elements that perform data transformations on one or more inputs, the system comprising: A memory configured to store: a version of the hardware design of the data transformation pipeline, wherein a data transformation element of the one or more data transformation elements has been replaced with or linked to a functional element, the functional element being viewed by a formal verification tool as an unevaluated function of the one or more inputs of the data transformation element that has been replaced with or linked to the functional element, such that during formal verification, whenever the same set of one or more inputs is received, the functional element produces the same set of one or more outputs; and Formal verification tools; and One or more processors configured to: For each transaction in the set of transactions, formally verifying, using the formal verification tool, that an instantiation of the version of the hardware design of the data transformation pipeline produces a set of one or more outputs that matches a reference set of one or more outputs of the transaction.

22. The system of claim 21, wherein: The one or more processors are also configured to: when the verification is successful, provide the hardware design of the data transformation pipeline to an integrated circuit manufacturing system, and when the hardware design of the data transformation pipeline is processed by the integrated circuit manufacturing system, cause the integrated circuit manufacturing system to manufacture an integrated circuit embodying the data transformation pipeline.

23. The system of claim 22, further comprising the integrated circuit manufacturing system, wherein: The integrated circuit manufacturing system comprises: a layout processing system configured to process the hardware design to generate a circuit layout description of an integrated circuit embodying the data transformation pipeline; and An integrated circuit production system is configured to manufacture an integrated circuit embodying the data transformation pipeline according to the circuit layout description.

24. A computer readable storage medium having computer readable code encoded thereon, the computer readable code being configured to cause the method according to any one of claims 1 to 3 or 5 to 6 to be performed when the code is run.

Images