Patent Application
20140089899
The invention relates to a method for the computer-assisted analysis of buggy source code in a hardware description language and also a corresponding computer program product and a corresponding computer program.
The invention lies in the technical field of simulating integrated circuits with the aid of hardware description languages. Hardware description languages have been known from the prior art for a long time. Using these languages, a source code is generated on the basis of a corresponding syntax, which specifies the design of the circuit and the operations carried out therewith. Using such a source code, the behaviour of the integrated circuit can be simulated by means of corresponding input sequences. Corresponding outputs are generated by the circuit in the course of the simulation. If the generated outputs deviate from expected outputs that should be generated with the circuit design, a bug is present in the source code. Manually locating such bugs by the designer of the integrated circuit (also termed debugging) is generally very time-consuming and there is a requirement to support the designer in detecting bugs in the source code with an automated method.
A method is described in document U.S. Pat. No. 5,862,361 A, in which a source code is generated in the hardware description languages VHDL or Verilog from a functional description of a hardware component. This source code can then be simulated efficiently.
Document DE 102 43 598 A1 discloses a method for functionally verifying integrated circuits, by which errors in the circuit design can be detected.
Document US 2009/0125766 A1 discloses diagnostic methods for hardware debugging. The computation of possible bug locations is described on the basis of Boolean satisfiability. Furthermore, additions are specified based on quantified Boolean formulae, hierarchical knowledge, abstraction and unsatisfiable cores.
It is the object of the invention to create a method for the computer-assisted analysis of buggy source code in a hardware description language, with which the location of the bugs in the source code is simplified.
This object is achieved by means of the method according to Patent Claim 1. Preferred embodiments of the invention are defined in the dependent claims.
The method according to the invention is used for the computer-assisted analysis of buggy source code in a hardware description language, the structure and the operation of an integrated circuit being described using the hardware description language and the buggy source code leading to an incorrect output of the integrated circuit. That is to say a simulation of the integrated circuit carried out with the source code leads to an output which deviates from an expected set-point value.
In the course of the method, a correction model is provided, which comprises a hierarchical structure of nodes arranged in a plurality of hierarchical levels, the nodes being transformation instructions, a transformation instruction describing a group of transformations which are to be applied to at least one type of a source code section and hereby change the source code section and a transformation instruction, which is a child node of another transformation instruction, constituting a subset of the group of transformations of the other transformation instruction. In a preferred variant, the hierarchical structure is realised by one or a plurality of hierarchy trees. Preferably, the set of transformations for the respective transformation instruction is determined by the functions which can be realised for the transformation instruction.
The correction model therefore constitutes a refining model of a multiplicity of transformation instructions, by which a set of transformations is specified in an ever finer manner, the refinement being represented in the hierarchical structure by means of a parent/child relationship (i.e. by a corresponding edge). The above term source code section is to be understood widely in this case and can comprise any elements in the source code, e.g. closed loops or syntactic statements, such as individual program lines, or any other desired elements.
In the course of the method according to the invention, the transformation instructions (i.e. the transformations from the corresponding group of transformations) from the hierarchical structure are applied to the buggy source code and those transformation instructions, which change the source code in such a manner that the changed source code leads to a correct output of the integrated circuit, are determined. A transformation instruction leads to a correct output if there is a transformation in the group of transformations specified by the transformation instruction, which leads to a correct output. At least a subset of the determined transformation instructions together with the associated source code section(s) to which the determined transformation instructions were applied are output as (possible) corrections. Preferably, the transformations are specified explicitly with their parameters which have led to the correct output. In a preferred variant, those determined transformation instructions, to which determined transformation instructions are not attached as child nodes, are output as corrections for each source code section, to which the transformation instructions are applied.
The method according to the invention stands out in that possible bug sources in the source code of an integrated circuit simulated by a hardware description language are described precisely by means of a self-refining correction model. The corrections determined by the method give the designer of the integrated circuit valuable indications as to the location in the source code at which a corresponding bug could be located, and with which change in the source code, this bug may possibly be corrected.
In a particularly preferred embodiment of the method according to the invention, the corrections are output with assigned priorities, the corrections for those determined transformation instructions to which no determined transformation instructions attach as child nodes having a higher priority. In this manner, the designer of the integrated circuit is informed about which transformation instructions are particularly relevant or concise, i.e. which transformation instructions relate to a particularly small subset of transformations.
In a particularly preferred embodiment of the invention, the determination of the transformation instructions which lead to a correct output of the integrated circuit takes place in such a manner that the transformation instructions are applied successively from the higher to the deeper hierarchical levels to the buggy source code, it being verified after the application of a transformation instruction whether the source code changed thereby leads to a correct output of the integrated circuit, transformation instructions which form child nodes of the applied transformation instruction only being applied to the buggy source code in the event of a correct output. In this case, the method can begin in the uppermost hierarchical level, but the method can also start in deeper hierarchical levels. In this embodiment, one makes use of the insight that in the event that a transformation instruction does not lead to a correct output, all transformation instructions which form child nodes of this transformation instruction also cannot lead to a correct output, as the child nodes are a subset of the transformations according to the transformation instruction of the parent node.
The transformation instructions can be defined on the basis of various criteria. In a preferred embodiment, a distinction is made between deterministic and non-deterministic transformation instructions. A deterministic transformation instruction is given by a deterministic function which depends on one or a plurality of parameters of the integrated circuit and in particular on the content of the source code section to which the deterministic transformation instruction is applied. By contrast, a non-deterministic transformation instruction designates an instruction which is independent of a deterministic function and thus comprises transformations with any desired parameters which can be used within the transformation instruction. It results from this definition of the deterministic and non-deterministic transformation instructions that a deterministic transformation instruction can be the child node of a non-deterministic transformation instruction, as a deterministic transformation instruction can be seen as a special variant of a non-deterministic transformation instruction. The inverse case, that a non-deterministic transformation instruction is a child node of a deterministic transformation instruction, is not possible.
In a further embodiment of the method according to the invention, the hierarchical structure comprises local transformation instructions, the respective transformations of which are always only applied to an individual source code section, it being possible however to apply each transformation in the transformation instruction to various source code sections of the same type. If appropriate, the hierarchical structure can also comprise global transformation instructions, the transformations of which can be applied to a plurality of source code sections simultaneously and e.g. change data structures. The hereinafter explained transformation instructions preferably constitute local transformation instructions.
In a preferred embodiment of the method according to the invention, the hierarchical structure in the uppermost hierarchical level comprises a non-deterministic transformation instruction, which replaces a source code section with a new source code section. Preferably, this non-deterministic transformation instruction comprises at least one of the following non-deterministic transformation instructions as child node:
An assignment is to be understood here and in the following to mean an expression with an equals sign, the assigned value of the assignment constituting the right side of the equals sign. The term syntactic statement is to be understood broadly here and in the following and can comprise any type of closed content in the source code. Preferably, the syntactic statement relates to a closed expression, such as a basic block, an assignment or a condition.
In a further preferred embodiment of the method according to the invention, the above-defined non-deterministic single-replacement transformation instruction comprises at least one of the following transformation instructions as child node:
The term “taking a condition into account” is to be understood here and in the following to mean that the transformation instruction is only applied if the condition is satisfied. Analogously to the non-deterministic transformation instruction, “a non-deterministically determined value” is to be understood here and in the following to mean a value which is determined independently of a deterministic function.
In a further embodiment of the method according to the invention, the deterministic single-replacement transformation instruction comprises the following transformation instruction as child node:
In a further variant of the invention, the deterministic conditional single-replacement transformation instruction comprises at least one of the following transformation instructions as child node:
The current or the previous states and the current or the previous inputs of the integrated circuit arise as a result in the course of the simulation of the integrated circuit by the source code.
In a further embodiment of the method according to the invention, a non-deterministic multiple-replacement transformation instruction comprises the following transformation instruction as child node:
In a further variant, the non-deterministic conditional deactivation transformation instruction comprises at least one of the following transformation instructions as child node:
In a further variant of the method according to the invention, the non-deterministic additive transformation instruction comprises the following transformation instruction as child node:
In a further variant of the method according to the invention, the non-deterministic additive transformation instruction comprises at least one of the following transformation instructions:
The method according to the invention can be applied to buggy source code in any desired hardware description languages. In preferred variants, the method is used for the hardware description languages Verilog and/or VHDL and/or SystemC, which have been known for a long time from the prior art.
In addition to the previously described method, the invention further comprises a computer program product with a program code stored on a machine-readable carrier for carrying out the method according to the invention or one or a plurality of preferred variants of the method according to the invention when the program code is executed on a computer. The invention furthermore relates to a computer program with a program code for carrying out the method according to the invention or one or a plurality of variants of the method according to the invention when the program code is executed on a computer.
Exemplary embodiments of the invention are described in detail hereinafter on the basis of the attached
In the following, the method according to the invention is described on the basis of the hardware description language Verilog, by which a corresponding integrated circuit or a chip is designed and by which the behaviour of the integrated circuit can be simulated temporally on the basis of a specification of an input sequence. The method according to the invention is not limited to the hardware description language Verilog however, but rather can also be used for other description languages, if necessary.
It is the aim of the invention to localise bugs in a buggy source code in a hardware description language, the buggy source code leading to an output deviating from the expected correct output for a predetermined input sequence on the basis of the simulation of the integrated circuit. The method according to the invention uses a refining correction model CM for localising bugs in the source code, which as a hierarchy tree is built up from a multiplicity of transformation instructions which combine groups of transformations in a suitable manner. The transformations change the source code in a suitable manner.
In the following, the above-described transformation instructions are also referred to as generic transformations, whereas the transformations contained therein constitute the actual transformations. In Table 1 shown below, the generic transformations shown in
The generic transformations shown in the Table 1 are merely exemplary and further modifications and additions of transformations can also be used. It is essential to the invention however, that the transformations are described by a hierarchical structure, a child node constituting a subset of the group of transformations of the corresponding parent node. In this manner, an efficient localisation of bugs in the source code of the hardware description language is achieved. In
A source code section in the form of a syntactic statement designates a predetermined type of statement in the source code and relates e.g. to an isolated program line, which is normally terminated by a semicolon. A set of syntactic statements comprises a plurality of such statements. Special cases of syntactic statements are expressions in the form of variable assignments (e.g. a=b), wherein a corresponding condition is also to be understood as a variable assignment which constitutes the argument of an if instruction. A plurality of syntactic statements of a source code block are designated with stmt_block in the pseudocode in the third and fourth columns of Table 1. An individual statement is designated with stmt or stmt1 or stmt2.
In Table 1, a further distinction is made between deterministic generic transformations and non-deterministic generic transformations. A deterministic generic transformation is given by a deterministic function which is designated in Table 1 with DET and depends on one or a plurality of parameters of the integrated circuit, particularly on the content of the source code section which is modified by the transformation and/or on current or on previous states or inputs of the simulated integrated circuit. In the case of otherwise identical parameters, a deterministic generic transformation instruction always describes a subset of the transformations of a non-deterministic generic transformation, i.e. a non-deterministic transformation instruction comprises transformations of all corresponding deterministic transformation instructions. Generally, in the present application the term “deterministic” designates a dependence on one or a plurality of parameters of the integrated circuit, whereas “non-deterministic” represents the independence from parameters of the integrated circuit. The syntax of the third and fourth columns of Table 1 can be understood by a person skilled in the art and is not explained in detail. The expression a=VAR?d: b+c means that the variable a is assigned the value of (b+c) if VAR contains the value “false” or “0”. Otherwise, the variable a is assigned the value of the variable d. The expression if (VAR) means that the subsequent transformation is only carried out if VAR assumes a particular value (e.g. 1, if VAR represent one bit).
In the following, a process of a variant of the method according to the invention is explained by way of example on the basis of the following pseudocode. In this variant, in the hierarchy tree of
In the above pseudocode, a queue R is formed in line 2, which comprises all generic transformations which do not refine any other generic transformations in the correction model CM, i.e. the queue R consists of the transformations in the uppermost hierarchical level which is the hierarchical level H1 of the hierarchy tree of
An example of the process of an embodiment of the method according to the invention is explained hereinafter for clarification on the basis of the hardware description language Verilog. The following Verilog source code is considered in the process:
As Verilog is known per se as a hardware description language, the above commands of the source code are not explained in detail. It is just relevant that the source code contains a bug in line 27. A subtraction should be calculated there, as is indicated by the comment lines 25 and 26. Actually, however an addition, namely tmp=a+b, is calculated. In the course of the simulation of the integrated circuit based on the above source code, three input sequences A, B and C are considered, which are indicated in the following table:
In the above table, the first column designates the identity of the input sequence and the second to fourth columns reproduce the values of the operands op, a and b. Further, the actual output value of tmp is indicated in the fifth column and the (correct) set-point output value of tmp is indicated in the sixth column. In the input sequence A, the operand op assumes the value 0 according to the above Verilog source code, whereas the operand a has the value 7 and the operand b has the value 5. As op=0, this leads in accordance with the case instruction in line 23 to tmp=a+b being calculated, so that in line 30 for {oflow, c_high, c_low}=tmp, the value 12 is finally output. The input sequence A therefore leads to a correct output (actual value=set-point value), which is indicated in the sixth column by “ok”. By contrast, the input sequence B leads to the output value 12 of tmp, which is not the correct output of tmp=2, however. The input sequence C leads in turn to a correct output value.
Starting from this Verilog source code and the corresponding input sequences, transformations from the above transformation instructions according to
NDET replaces the assignment with a new, non-deterministically assigned variable. By applying this generic transformation to line 30 of the above source code, an actual transformation is obtained, which leads to the following code:
{oflow, c_high, c_low}=NEWVAR;
The transformation instruction DET replaces an assignment with a deterministic function which depends on the variables in the expression. By applying this transformation instruction to line 30 of the above source code, an actual transformation is obtained, which modifies line 30 as follows:
{oflow, c_high, c_low}=DET(tmp);
The transformation instruction OP_op replaces an operator on the right side of an assignment with another operator. In the example described here, by applying this transformation instruction to line 30, a negation instead of the identity function is carried out, which leads to an actual transformation, which corresponds to the following code in line 30:
{oflow, c_high, c_low}=OP(!, tmp);
In the embodiment described here, the transformation instruction NDET is initially applied to line 30, and subsequently the refining transformations are carried out. By applying NDET to line 30 of the above source code, it is possible to create a correct output in that the expected set-point output value is assigned to the new variable NEWVAR. Consequently, the refining transformation instruction DET is then applied to line 30 of the source code. However, for the input sequence A and the input sequence B, the internal signal tmp has the value 12, whereas the output signal in both cases should be different. This cannot be realised with a deterministic function. Thus, the bug in the source code cannot be overcome by means of the transformation instruction DET which is applied to line 30. Nevertheless, the less refining transformation NDET in the higher hierarchical level was successful. Consequently NDET, which is applied to line 30, constitutes a correction C1=(NDET, 29) for the buggy source code.
The method can then be continued in that the transformation instruction NDET is applied to line 27 of the above source code, which leads to the following modification:
1: tmp=NEWVAR;
This transformation in turn enables the generation of a correct output for all input sequences. Consequently, the refining transformation instruction DET is then applied to line 27, which leads to the following modified program line:
1: tmp=DET(a, b);
With these transformations also, a correct output can be generated for all input sequences a to c. If the transformation instruction OP_op is then applied to line 27, where the operator “+” is replaced with the operator the following modified program line results:
1: tmp−op(−, a, b);
This transformed Verilog source code also generates the correct output value for all input sequences. As there are no further refining transformations for OP_op, a further possible correction is C2=(OP_op, 26). According to the refining relation based on the hierarchy tree of
According to the invention, a prioritised output of possible corrections for a buggy source code in a hardware description language can be created in a suitable manner, so that the designer of the integrated circuit hereby receives information, with which he can locate the bug in the source code in a fast manner.
The determination according to the invention of corresponding transformation instructions can be implemented in various ways, wherein different implementation variants are outlined briefly hereinafter. The realisation of a corresponding implementation forms part of the expertise of a person skilled in the art and is therefore not described in detail.
Two resource intensive steps are required for implementing the method. On the one hand, the transformation instructions must be applied to the various source code sections and on the other hand, the validity of the transformed source code must be checked with respect to the correspondingly expected output. These two steps can be carried out independently of one another or interwoven. The following technologies can be used for implementing these steps:
All of these methods require a few modifications in order to carry out and to check the actual transformations. This is explained hereinafter for simulation-based approaches, formal techniques and hybrid techniques.
In a simulation-based approach, the actual transformation from the corresponding transformation instructions is applied to the source code, which leads to a modified description, on the basis of which the integrated circuit can be simulated. The checking of the validity of the output of the simulated circuit is readily possible for those actual transformations which replace a logical section of the source code with a new logic. In this case, a standard simulation is carried out, in order to check the behaviour of the integrated circuit on the basis of the transformed design. In the event that no logic is inserted, e.g. by the generic transformation NDET or DET from
Alternatively, the simulation-based method can be carried out on a netlist. To this end, the source code is synthesised in a netlist. During this synthesis step, the relations between source code and elements in the netlist are obtained. As a result, possible corrections on the netlist can be mapped onto the source code. Then, one or a plurality of transformation instructions are applied directly to the netlist and the result is checked for each simulation as above.
When using formal techniques, an actual transformation can be applied in such that the source code is changed directly and a formal model is generated from the transformed source code, which is subsequently processed by a reasoning engine. Alternatively, a plurality of actual transformations can be symbolically added to the formal model which was generated from the original source code. As a result, a plurality of actual transformations is analysed in a single pass of the reasoning engine. For simple logic replacements, the transformation can in turn be inserted directly into the source code. For the generic transformation NDET, new symbolic variables are inserted, value assignments being undertaken by the reasoning engine. For the generic transformation DET, additional limitations are added to the formal model, in order to guarantee the deterministic behaviour. Some reasoning engines provide direct mechanisms in order to formulate such limitations, for example SMT solvers model so-called “uninterpreted functions”.
Checking the validity of a transformed design can be achieved in the case of formal techniques by comparing the specification of a corresponding input sequence with the transformed integrated circuit. The reasoning engine in this case finds contradictions between the specification and the transformed circuit design. If the specification is for example given by means of expected values for input sequences which lead to an incorrect output, an individual input sequence or a plurality of input sequences can be processed simultaneously by a single formal model.
Within the method according to the invention, hybrid techniques can also be used, which are based both on simulations and on formal techniques. These techniques typically reduce the cardinality of the proof method compared to a formal reasoning engine, which leads to less computing complexity. Which parts of the problem are processed by formal methods and which are processed by simulation-based methods can essentially be adjusted via heuristics.
In the worst case, each generic transformation must be applied to every possible source code section in the circuit design. The number of actual transformations therefore becomes very large. Therefore, if necessary, further optimisation techniques can be used in order to reduce this number. In this case, structural approaches are known, which analyse the structure of control and data flow graphs. As a result, the number of source code sections for which e.g. NDET has to be applied can be reduced.
The method according to the invention described in the foregoing has a range of advantages. In particular, the method allows the analysis of buggy source code of a hardware description language so that possible corrections are determined using a hierarchically built correction model comprising a plurality of transformation instructions. The hierarchical structure of the transformation instructions is built such that a transformation instruction, which is the child node of a transformation instruction of a higher hierarchical level, constitutes a subset of the transformations according to the transformation instruction of the higher hierarchical level. That is to say the cause of the bug is ever more constrained in a suitable manner by means of the use of the hierarchical structure. By means of a prioritised output of possible corrections, in which the corrections from deeper hierarchical levels receive a higher priority, the designer of the integrated circuit is also informed about which transformation instructions and thus linked corrections were particularly concise in the sense that they already specify small subsets of transformations.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10 2011 077 177.8 | Jun 2011 | DE | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2012/060585 | 6/5/2012 | WO | 00 | 11/20/2013 |
