JP6363297B2 - Simulator, design support system and method for semiconductor circuit device - Google Patents

Description

  The present invention relates to a field-programmable gate array (FPGA), and more particularly to an SRAM (Static Random Access Memory) -based FPGA logic implementation and evaluation technique for constructing a highly reliable and highly secure system for industrial use.

  With the miniaturization of devices, the manufacturing cost of ASIC (application specific integrated circuit) has increased, and FPGA replacement is desired. At that time, in static random access memory (SRAM) -based FPGAs, there is a problem of a firmware error in which the logic configuration changes due to a soft error. In particular, for industrial applications that require high reliability such as transportation, finance, and medical care, in order to utilize SRAM-based FPGAs, high reliability, high availability, and high safety technologies are required.

  Under such circumstances, an FPGA vendor has developed a technique for improving resistance to soft errors (Non-Patent Documents 1 and 2). These are mainly techniques for performing CRC (Cyclic Redundancy Check) on the contents stored in the FPGA configuration memory (CRAM) and for correcting errors in the CRAM.

Altera AN-539-2014.12.15 “Test Methodology of Error Detection and Recovery using CRC in Altera FPGA Devices”, http://www.altera.com/literature/an/an539.pdf Soft Error Mitigation Controller http://www.xilinx.com/support/documentation/ip_documentation/sem/v4_1/pg036_sem.pdf Functional Safety: International Electrotechnical Commission, http://www.iec.ch/functionalsafety/ (international standard IEC61508 second edition)

  Examples of applying electronic parts to industrial applications are increasing year by year, and the international standard IEC61508 has been established to deal with such a situation, and the second edition was issued in 2010 (Non-patent Document 3). According to this standard, a policy for applying LSI to safety-related systems is described.

Important indicators include Safety Integrity Level (SIL) and the average probability of failure of the safety function in the continuous operation mode (Average Frequency of a dangerous failure of the safety function: PFH [unit: 1 / hour] ), Safe Failure Fraction (SFF), and Hardware Fault Tolerant (HFT). SIL is defined in four stages, with SIL1 being the lowest and SIL4 being the highest. PFH is defined according to each SIL, and in the first chapter of IEC61508,
SIL4: 10 ^ -9 ≤ PFH <10 ^ -8
SIL3: 10 ^ -8 ≤ PFH <10 ^ -7
SIL2: 10 ^ -7 ≤ PFH <10 ^ -6
SIL1: 10 ^ -6 ≤ PFH <10 ^ -5
It is defined as

  Chapter 2 of this standard provides guidelines for hardware design, and describes the relationship between SFF and HFT according to the corresponding SIL level. As an example, consider the case of SIL3 level device design. If SFF <60%, the requirement cannot be met even if the hardware redundancy (HFT) is increased, but if 60% ≤ SFF <90%, the equivalent of triple (HFT = 2) can be combined. If the possibility of SIL3 support is shown and 90% ≤ SFF <99%, combining with duplexing (HFT = 1) shows the possibility of SIL3 support and 99% ≤ SFF For example, the possibility of SIL3 compatibility is shown even in the equivalent of single mode (HFT = 0). However, HFT = N is defined to be equivalent to N + 1 multiplexing.

  In this way, it is important to derive the SFF corresponding to the target SIL, and if the value is obtained accurately and confirmed to be high, the hardware multiplicity should be lowered. Can lead to cost reduction.

  We face challenges in applying FPGA to such highly secure devices. In particular, the FPGA integrates the functions that the LSI wants to realize in the configuration memory (hereinafter referred to as CRAM), but in general, the FPGA is provided to the user while the details of the internal structure are kept secret, so detailed implementation It is difficult for the user to judge the structure of Therefore, SFF calculation itself is very difficult.

  Moreover, the SRAM type CRAM has a feature that the frequency of soft errors is very high, unlike the nonvolatile element type CRAM. In recent years, the importance of evaluating the impact of safety against soft errors has become important, and various types of SRAM error resistance vendors have been developed and provided to users. However, as a result of our study, we have concluded that it is difficult to adapt to safety standards simply by reducing the soft error rate of CRAM.

  Specifically, the occurrence state of the CRAM soft error is grasped in relation to the logical connection state described by the user, the failure rate, whether the failure that occurred is dangerous or safe, Therefore, it is necessary to calculate whether or not the failure can be detected by the diagnostic function. In order to apply FPGA to high-safety applications, it is necessary to quantitatively evaluate the safety of the constituent circuits. However, at present, it is difficult to quantitatively evaluate the influence of a configuration memory soft error.

  One aspect of the present invention is a simulator for evaluating an assumed error in an FPGA that retains logic circuit information in a CRAM. The simulator can be configured by an information processing device including a processing device, a storage device, an input device, and an output device. The storage device stores one-to-one correspondence information between a net list that is circuit connection information to be formed in the FPGA and a bit stream that is a bit string stored in the CRAM. The input device accepts an input of a bitstream corresponding to the netlist to be evaluated. The processing apparatus includes an error insertion tool and an expected value comparison tool. The error insertion tool includes means for changing the input bitstream, and means for referring to the correspondence information and reflecting the change of the bitstream in the netlist to be evaluated to generate a fault insertion netlist. Prepare. The expected value comparison tool includes means for applying a predetermined input to the fault insertion netlist to perform a logical simulation, and means for comparing the simulation output result with the output expected value.

  In a specific example, the expected output value may include a true value and a preset dangerous side failure output value.

  In another specific example, the expected value comparison tool outputs an output result that matches the dangerous failure output value as a failure mode list for each simulation.

  In another specific example, the input device has means for instructing the error insertion tool to change a designated portion of the bitstream or to change it randomly.

  Another aspect of the present invention is a field programmable LSI (FPGA) design support system that retains logic circuit information by a rewritable storage means called a configuration memory (CRAM). The system includes a processing device, a storage device, an input device, and an output device. The input device receives input of first bit information corresponding to the first logical connection information stored in the CRAM. The processing device reversely rewrites some bits of the first bit information to generate second bit information, and the second bit information is one-to-one with the first bit information. A second means for converting to the second logical connection information in response to the change of the corresponding first logical connection information, and logical and circuit-like using the second logical connection information; A third means for executing a simple simulation.

  In a more specific configuration example, the third means corresponds to one or more inputs to the second logical connection information and a simulation output result corresponding to each of the plurality of inputs, which is separately determined. Has a means to compare with the expected output value. The expected output value is an expected value composed of a correct result obtained during simulation with the first logical connection information and one or more output results at the time of failure that presuppose the cause of failure in generating the second bit information. It is defined as a table and stored in the storage device. The means for comparing with the expected output value performs a match search between the simulation output result and the expected output value, and if it matches any expected value described in the expected value table, the input and expected value are Correlating means for displaying as a list of failure modes on the output means is provided.

  Still another aspect of the present invention is a design support method for a semiconductor circuit device for evaluating an assumed error for an FPGA that holds logic circuit information by CRAM, and includes a processing device, a storage device, an input device, and This is a method using an output device. The storage device stores one-to-one correspondence information between a net list that is circuit connection information to be formed in the FPGA and a bit stream that is a bit string stored in the CRAM. The input device accepts an input of the bitstream corresponding to the netlist to be evaluated. The processing apparatus includes: a first step of changing the input bitstream; a second step of generating a fault insertion netlist reflecting the change of the bitstream by referring to the correspondence information; A third step of performing a logical simulation by applying a predetermined input to the insertion netlist.

  In a more specific configuration of the present invention, the fourth step of comparing the simulation output result with the output expected value is executed.

  A highly efficient CRAM error injection evaluation method in FPGA design can be provided.

The logic block diagram which shows the relationship between the tool of this application Example, and data. (A) Relationship between LUT configuration and truth table, (B) Logic circuit example designed as an example, (C) Conceptual diagram of a logic circuit example changed during fault insertion simulation. The flowchart which shows conversion from the fault injection | pouring to a CRAM bit by error insertion to logical connection information (net list). The logic block diagram of the Example which shows the method of expected value evaluation after error insertion. The flowchart which shows the Example which shows a design flow. The flowchart of the Example which linked | related this Example with the design flow of IEC61508. The conceptual diagram explaining hierarchy design and hierarchization of design data. Conceptual diagram of integrating functions on an FPGA chip. The conceptual diagram which shows the Example of the isolation | separation part of FIG. The conceptual diagram explaining the bit structure and error injection of CRAM. The top view which shows one Example of GUI (Graphic User Interface) in an Example. An example of circuit change information expressed on a GUI. (A) Example which presents each of error mode, CRAM bit, and error location, (B) Plan view showing error mode and error location presentation. The conceptual diagram of the Example which shows the CRAM structure of a wiring switch part, and expresses a permanent failure by CRAM soft error instead. FIG. 10 is a logical block diagram showing the relationship between tools and data in Embodiment 7. 10 is a flowchart showing a processing flow of Embodiment 7. The conceptual diagram explaining the conversion method from a netlist to RTL.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the present invention is not construed as being limited to the description of the embodiments below. Those skilled in the art will readily understand that the specific configuration can be changed without departing from the spirit or the spirit of the present invention.

  In the structures of the invention described below, the same portions or portions having similar functions are denoted by the same reference numerals in different drawings, and redundant description may be omitted.

  In the present specification and the like, notations such as “first”, “second”, and “third” are attached to identify the components, and do not necessarily limit the number or order. In addition, a number for identifying a component is used for each context, and a number used in one context does not necessarily indicate the same configuration in another context. Further, it does not preclude that a component identified by a certain number also functions as a component identified by another number.

  The position, size, shape, range, and the like of each component illustrated in the drawings and the like may not represent the actual position, size, shape, range, or the like in order to facilitate understanding of the invention. For this reason, the present invention is not necessarily limited to the position, size, shape, range, and the like disclosed in the drawings and the like.

  In general, for functional logic design of a logic LSI, after clarifying the specification of the function to be realized in the target LSI, create a logic specification for realizing the function, and use a logic description language (for example, Verilog HDL (Hardware Description Language)) And VHDL). This logic circuit is described by a technique called RTL (Register Transfer Level).

  Generally, integration from RTL to LSI is performed by the following procedure. In other words, RTL logic connection information is converted into a so-called netlist in consideration of the physical arrangement of transistors integrated in an actual LSI, and further, static timing analysis simulation is performed in consideration of timing constraints of each signal line ( STA) is performed and the layout is optimized, and then integration into the LSI is realized. The same procedure is applied to the FPGA. After designing the RTL, logic synthesis is performed, and the data is stored in the FPGA CRAM while adjusting the timing of the signal lines. This conversion is hereinafter referred to as mapping to CRAM.

  For mapping to CRAM, considering the physical layout of the basic logic circuit and wiring connection switch integrated inside the FPGA, based on transistor level connection information (net list) converted from logic description information, It is realized by converting into a bit string (bit stream) of FPGA configuration memory (configuration memory: CRAM). By storing this bit stream in the CRAM of the FPGA, it can be realized by the FPGA targeting the desired operation.

  The important point here is that the conversion from RTL to netlist, and various simulations using the netlist are performed by a server or other device, and only the final bitstream is stored in the FPGA, which is desired by the user. This is to realize the operation to be performed. In other words, the netlist converted from the RTL for realizing the function in the FPGA and the CRAM data string (bit stream) stored in the FPGA have a one-to-one correspondence. Therefore, each bit of CRAM can be mapped to a circuit in principle. At this time, in order to keep the internal configuration of the FPGA secret, even when the CRAM bit stream is encrypted and stored, the correspondence between the original netlist and the bit stream is always one-to-one.

  By utilizing this fact, it is possible to reflect information in which part of the CRAM bitstream has been changed to the netlist. Therefore, the problem is solved by providing means for confirming the influence of the inversion of each bit of the CRAM by logical simulation.

  Furthermore, by comparing the simulation result with the expected value of the expected dangerous failure output separately set by the user, it is possible to extract the state where the error state becomes the dangerous side. It becomes possible to enumerate all kinds of modes.

  In this technology, correspondence between the circuit netlist and the FPGA configuration memory is important, and it is desirable that this technology be operated in an integrated form with the FPGA design tool.

  Examples will be specifically described below.

  The overall configuration of a specific embodiment of the present invention will be described with reference to FIG. This embodiment may be preferably realized by an FPGA design support tool including an FPGA logic implementation tool, an FPGA failure mode evaluation tool, and an FPGA failure probability calculation tool.

  A specific system configuration may be a form in which hardware such as a server including a processing device, a storage device, and an input / output device is used for information processing by software.

  The FPGA logic implementation tool (100) is an existing FPGA logic implementation tool, and this embodiment is considered to be added to these conventionally known tools. Therefore, a characteristic point of the present embodiment is that an error injection evaluation tool (101) is provided.

  The FPGA logic implementation tool (100) includes a logic synthesis tool (110) and a physical placement tool (111), and includes a timing analysis tool (not shown). The logic synthesis tool (110) receives RTL, which is design data, and outputs a so-called net list (120), which is gate level connection information. The generation of the netlist (120) is designed so as to obtain a desired operation speed through timing analysis and the like. This net list (120) is transferred to a bit string (hereinafter referred to as bit stream (121)) for storage in a so-called configuration memory (CRAM) that controls the LUT and the switch in the FPGA by a physical placement tool. Converted.

  In this embodiment, the net list (120) and the bit stream (121) are used to evaluate the degree of influence when an error is arbitrarily generated for a part of the CRAM bit stream described later by simulation. It is characterized by having means to do.

  The error injection evaluation tool (101) includes an error insertion tool (112) that generates an arbitrary bit reversal error in a part of the bitstream of the CRAM, a SIM / expected value comparison tool (113) that evaluates the influence, And a dangerous failure rate calculation tool (114).

  The error insertion tool (112) receives the designed netlist (120), bitstream (121), and netlist vs bitstream correspondence information (table) (122). The net list vs bit stream correspondence table (122) stores the correspondence between the net list and the bit stream on a one-to-one basis. Such information is owned by the FPGA design or manufacturer and can be provided here. When it is desired to keep the internal connection structure of the FPGA secret from the person who performs the simulation, it is preferable that the correspondence table (122) is black boxed by restricting access to the output. The principle of the correspondence between the netlist and the bit stream will be described later with reference to FIG.

  The error insertion tool (112) performs a bit inversion operation on a part of the bitstream (121), arbitrarily inserts an error, and then uses the netlist vs bitstream correspondence table (122) to generate an error. The insertion result is changed with respect to the net list (120). As a result of changing the net list (120), a fault insertion net list (124) reflecting a fault on the bitstream is obtained. Alternatively, using the net list vs bit stream correspondence table (122), a corresponding net list is generated from the bit stream into which the error is inserted.

  Such an error insertion tool (112) can simulate the effect of radiation on the CRAM or the like in the FPGA. The error insertion method may be changed according to the assumed failure situation.

  The SIM / expected value comparison tool (113) uses the fault insertion netlist (124) generated by the error insertion tool (112) and the SIM input (131) created for the user to evaluate the effect of error insertion. Thus, the failure mode is evaluated by comparing the output result when the logical simulation is performed with the expected output value (132) defined by the user.

  As will be described later with reference to FIG. 4, the output expected value (132) is composed of a true value as a calculation result in a state where no error has occurred for a certain input, and a plurality of dangerous failure values when an error occurs. ing. The SIM / expected value comparison tool (113) can perform a simulation of a state in which a fault is inserted using the fault insertion netlist (124) and the SIM input (131).

  This simulation itself can be carried out by utilizing an existing logical simulation method, and an operation waveform diagram as a simulation result can be output. The output result is accumulated in the database (125) and can be used for analysis. Also, in this embodiment, the most interesting thing is that the evaluation of the influence of error insertion by creating a determination as to which of the expected failure values (132) assumed by the user matches any of the dangerous faults. Can be implemented.

  What we want to confirm as a user is to check whether the error causes a serious situation by inserting the error, and to check which failure mode the failure is supposed to be. The function that is created is useful.

  Moreover, this expected value comparison is an evaluation method that can be easily confirmed even when detailed information of the netlist is difficult to disclose. Therefore, the present embodiment is characterized in that a failure mode list (126) caused by soft error insertion is output as a result of the evaluation.

  Since the failure mode list (126) can cover all possible errors for the target circuit (functional block), the result can be reflected on the circuit design by displaying it on a display device. The simplest form of the failure mode list (126) is an output that matches the output expected value data (132) indicating a dangerous failure among the outputs output from the function block A corresponding to the input. It is a list.

  In addition, as the failure mode list (126), the dangerous failure value of the output expected value (132) and the corresponding bitstream, netlist, or additional information related to the failure (for example, description of failure contents and effects) , Importance level, failure response method, failure type, etc.).

  Or, it does not use the output expected value data (132) of the dangerous failure and fails all combinations of the output that do not match the true value of the output expected value (132) and the corresponding bitstream, netlist, additional information, etc. It may be a mode list. However, in this case, there is a demerit of listing up to a less important failure.

  At this stage, the failure probability cannot be obtained, but all possible failure modes caused by soft error insertion can be listed in principle, and can be used as a failure mode verification tool. Therefore, this tool alone is effective in verifying high safety.

  Furthermore, in this embodiment, a dangerous failure rate calculation tool (114) is provided. The dangerous failure rate calculation tool (114) includes an actual load connection / physical placement data (123) output from the FPGA physical placement tool, a failure insertion net list (124), and an FPGA failure mode list (126). And the dangerous failure rate (127) is output.

  The dangerous failure rate calculation tool (114) identifies the physical location information of the fault location in the fault insertion netlist by associating it with the actual load connection / physical location data (123). Consider the probability, wiring length, usage status of logic circuits such as switch circuits and LUTs, and the failure rate of the hard-wired circuit installed in the FPGA, and the function of the CRAM soft error in the failure mode of interest. The feature is that the failure probability can be obtained.

  Although not particularly limited in FIG. 1, one fault insertion netlist corresponds to one soft error insertion, and a plurality of SIM inputs and a plurality of expected output values corresponding to the inputs are shown. It was expressed as if the SIM execution and failure mode were output. However, this evaluation creates a plurality of failure net lists by sequentially inserting a plurality of errors, and the failure mode list list includes a plurality of corresponding data in a form corresponding to each of the plurality of failure net lists. You may implement | achieve so that it can store.

  Next, in order to clarify the purpose of this embodiment, a specific influence of error insertion into the CRAM will be described. Here, the case of a 4-input lookup table (LUT) will be described as an example. As is well known, a 4-input LUT can represent a logic circuit with four inputs and one output. If each of the inputs is I0, I1, I2, I3, and output O1, 2 ^ 4 = 16 combinations are possible for the inputs. Therefore, if there is a 16-bit memory, one output value is determined by switching according to the values of the inputs I0, I1, I2, and I3.

  This will be specifically described with reference to FIG. As shown in FIG. 2A, when there is a truth table relationship between the input signals I0 to I3 and the output signal O, the correspondence with this output signal is input to the CRAM. In the lookup table, as shown in the example on the right of FIG. 2 (A), the output of the CRAM is input to a four-stage tournament type selector row, and the selectors for each stage are here. As shown, it is selected according to the values of I0 to I3. In this figure, a series of bit strings from the top to the bottom described in the column corresponding to the output O of this truth table corresponds to the CRAM bits constituting the corresponding LUT circuit. This is also the origin of the name of the circuit configuration, but is consistent with a so-called logic truth table, and the data in the CRAM becomes the output signal as it is.

  FIG. 2B shows an input example of the CRAM shown here with a logic circuit diagram. It consists of an AND circuit and an OR circuit. The bit of the CRAM describing this circuit is expressed as “0001000100011111”. This is equal to the output O of the truth table of FIG. 2A, that is, the bit string from the top to the bottom of the CRAM value.

  In this situation, we will explain error injection to CRAM. A case where a bit of the CRAM, in this example, the third bit from the head changes will be described. Here, the third bit of the CRAM bit is changed from “0” to “1”, and as a result, the CRAM bit string is changed to “0011000100011111”. This corresponds to the description of E.I. (error injection) in FIG. This situation is represented by a circuit diagram as shown in FIG. The circuit in FIG. 2B and the circuit in FIG. 2C are logically completely different. In this embodiment, the purpose is to quantitatively evaluate the influence on the circuit operation when one bit of the CRAM is changed by a soft error.

  A method for performing the error injection simulation will be described with reference to FIG. First, logical connection information A (net list A) reflecting the function that the user wants to realize is prepared (S301). Netlist A is the target circuit that you want to configure with FPGA, and is the object of evaluation in this simulation. As will be described later, this may be a part of the FPGA.

  Next, the CRAM bit stream A is generated using the netlist A (S302).

  Thereafter, a process for inverting some of the CRAM bits, that is, error injection, is performed on the CRAM bit stream A to generate a CRAM bit stream B (S303). As will be described later, the inversion portion of the CRAM bit can be selected according to the purpose.

  Thereafter, logical connection information B (net list B) corresponding to the CRAM bit stream B is generated (S304). When the logical connection information B is generated from the bit stream B, information in which the correspondence between the netlist and the bit stream is one-to-one as described above may be used. The error injection simulation is performed on the netlist B using user-specified input data.

  With reference to FIG. 4 and FIG. 1, the expected value evaluation method after error insertion executed by the SIM expected value comparison tool (113) will be described. This section describes the design with confirmation of logical connection conditions in mind. The block to be evaluated is assumed to be a function block A (401). This functional block A is assumed to be composed of a bit stream A generated from the netlist A at the beginning of design. In this bit stream A, the error insertion tool (112) performs error injection according to the procedure described in FIG. Here, it is assumed that the function block A has already been converted into the bit stream B, and the net list has also been converted into the net list B. Netlist B is set to contain errors. A logical simulation is performed in this situation.

  In the simulation, it is first necessary to prepare input data for testing this functional block. Here, it is considered that it is expressed by a na-bit input data bit string (131). That is, the input of the function block A has na input signals. In the evaluation, it is composed of a so-called test vector in which a plurality (0 to NTP) of this na bit signal is prepared. This has the purpose of improving the verification coverage in verifying the functional block. These input data are prepared as the SIM input (131) in FIG.

  In this embodiment, an operation simulation of the functional block A in the state of the netlist B is performed for one input pattern of the test vector. Here, the output of the functional block A is assumed to be nb bits.

  Prior to this simulation, the user reproduces the predetermined data, that is, the output value (true value) when there is no error in the functional block and the situation that becomes dangerous when an error occurs The output value is prepared as output expected value data (132). In this case, an incorrect signal is output due to an incorrect operation. For example, such output is prepared as expected output value data (# e0 to #en) at the time of failure. Depending on the contents of the error, the circuit may not operate as a circuit in the first place and there may be no output. When there is no output, there is a case of a failure on the safe side and a case of a dangerous failure but a latent failure. In particular, it is important for functional safety to quantitatively reduce the latter ratio. In order to confirm the failure mode quantitatively and appropriately using this embodiment, optimization of the evaluation unit by hierarchical design further divided into functional sub-blocks as described later, and a diagnostic circuit of an appropriate internal state By providing it, it is more effective to make it possible to detect a potential failure efficiently.

  In this simulation, for example, the value of the result of the simulation is compared with the above data by the output expected value comparison means (402). As a result, there is a function of extracting a case of a dangerous failure (dangerous failure), and outputting a case of matching with the dangerous failure as a dangerous failure mode list (126). The dangerous failure as the output result may be composed of # e0, # e1,..., #En, and n + 1 patterns. The output data only needs to be able to summarize the expected value comparison evaluation between the input corresponding to the input pattern number (# I0 to #NNTP) and the output result corresponding to the simulation result corresponding to the input pattern number.

  When the input test vector is composed of a plurality of input pattern numbers NTP, it is carried out for each. In addition, the test input test vector does not need to be brute force (2 ^ (na)), and may be implemented with a minimum configuration that reveals the possibility of danger as discussed in advance with safety concepts, etc. Is possible.

  In a normal logic simulation for verifying the operation of the functional block A, such as increase / decrease in the number of input signals to the block A, it is convenient to separate inputs that are not expected in normal logic simulation. For example, the problem is isolated so as to cope with the failure in the preceding stage of block A. By limiting the possible input types of the function block A, it is possible to prevent an increase in the number of inspection items.

  Further, as another embodiment, not only the comparison of the output signal but also the expected value comparison for the internal net information of the functional block is possible. As described above, in order to quantitatively reduce the potential failure on the dangerous side, it is effective to optimize the evaluation unit by hierarchical design and provide a diagnostic circuit of an appropriate internal state. Since it is a feature that simulation evaluation can be performed instead of actual machine evaluation, it is possible to confirm signal line transition operation by designating all nodes in principle for connection of all internal signals. Therefore, by providing a function to monitor the transition of internal signals in the tool and a diagnostic circuit (information processing having a function of a comparator, etc.) to be present on the tool for detecting a failure state more effectively, More effective verification becomes possible. In either case, a computer memory storage area that can be used by the tool, which is necessary for executing the simulation, is provided in the computer and the tool, data is accumulated in the memory, and comparison evaluation is performed.

  Furthermore, in such an evaluation, an actual FPGA device is not required, so that evaluation can be performed even in a so-called cloud. By carrying out in this way, the computing resources can be utilized abundantly, so that the processing speed can be increased. In that case, it is only necessary to download bit stream data to be loaded into the FPGA CRAM after completion of the design to a computer connected to the FPGA and transfer the data from the computer to the FPGA.

  Note that this functional block A can also be handled as a functional sub-block described later. By subdividing functional blocks, there is an effect that the number of test patterns to be examined can be reduced.

  The design flow will be described with reference to FIG. It is one Example of the design flow supposing error injection. First, the logical specifications to be realized by the FPGA are formulated (501). The logic mounted on the FPGA is designed by classifying into safety system functional blocks and safety unrelated functional blocks in consideration of safety (502). Each functional block may be further divided into sub-blocks and designed (503). For safety-related systems, a diagnostic function is added as necessary (504). After a series of studies, logic design is performed (505). When the logic design is completed, logic verification (506) is performed. Thereafter, a gate level netlist is generated (507), timing verification is performed (508), and it is confirmed that the timing violation is not critical, and CRAM bit data is generated (509). In this embodiment, after the bit data of the CRAM is generated, verification (510) by error injection simulation is performed.

  In the error injection simulation, when receiving the input of the net list to be verified and the bit stream corresponding to the net list, the data is blocked or sub-blocked as described above. That is, the simulation is executed by data divided according to functions to be realized by the FPGA, or divided based on a safety concept for realizing those functions.

  FIG. 6 shows an example in which the present embodiment is incorporated in the design flow defined by IEC61508. IEC61508 stipulates that the design / verification flow is designed with a V-shaped flow as shown in FIG. That is, in parallel with the test specification (S600), the design phase and the verification phase are performed separately.

  First, in the design phase, after determining the requirement specifications of the FPGA (S601), the specification of the circuit architecture integrated in the FPGA is determined (S602). Thereafter, functional design (S603) and integration design (S604) of the logic module are performed, and logic synthesis is performed (S605). In order to map the synthesized logic on the FPGA, the placement and routing are synthesized (S606).

  On the other hand, in the verification phase, first, the timing constraints of various signal lines are verified using the result of the placement and routing combination (S607). Thereafter, a simulation assuming an actual load is performed using the gate level netlist (S608). Thereafter, it is converted into a bit stream to be stored in the FPGA CRAM (S609).

  In the present embodiment, at this stage, the state of an error occurring in the CRAM is executed and verified by an error injection simulation (S610). Finally, the validity is checked against the requirement specification for FPGA integration (S611).

  Another embodiment of the present invention will be described with reference to FIG. This embodiment is an embodiment when designing safety-related functional blocks in a hierarchy. In the above embodiment, although the division into sub-blocks is assumed, details of individually designing those sub-blocks are not described. In the present embodiment, the embodiment is designed with the independent design in the sub-block hierarchy in mind.

  When designing safety-related system-wide functional blocks, it may be desirable to design them into appropriate blocks in consideration of the addition of diagnostic functions for design functions and operation management. In order to cope with such a situation, the safety-related overall function block is divided into function sub-blocks, and a diagnostic function (circuit) is added to each. As the diagnostic circuit, diagnostic methods such as lock step correspondence, parity addition, and ECC addition may be taken. At this time, the function sub-block netlist is generated while maintaining the independence of the function sub-blocks with the diagnostic function. Maintaining independence means, for example, that a part of the circuit of the functional block B ′ with diagnosis is not mixed in the part where the functional block A ′ with diagnosis is mounted, including the time of mounting.

  Each of the functional sub-block netlists is converted into a functional sub-block bit stream, and the error injection evaluation can be performed for each functional sub-block.

  FIG. 8 shows an embodiment of FPGA implementation of the functional sub-block A ′ 802, functional sub-block B ′ 803, and functional sub-block C ′ 804 of the FPGA 801 designed by the method of FIG. 7. The functional sub-block A ′, the functional sub-block B ′, and the functional sub-block C ′ are also physically separated.

  Each functional block is divided into large blocks according to the application function. For example, the important part 805 and the non-important part 806. By dividing in this way, it becomes easy to make only the block of the important part 805 a simulation target. Further, these functional blocks are separated by a separation portion 807. As a specific separation method, a separation method as shown in FIG. 9 can be considered.

  FIG. 9A is an embodiment showing physical separation of functional sub-block L and functional sub-block R. FIG. The feature is that the separation between the functional sub-blocks is set at the exit (output) of the flip-flop FF. The functional sub-block L includes the LUT and FF shown here, and the switches and wiring belong to the functional sub-block R. In this way, the output value of the functional block can be compared with the FF data, so that comparison at the time of verification becomes easy.

  In FIG. 9B, as in FIG. 9A, separation is performed at FF which is an output unit from the functional sub-block. Further, the switch (SW) portion and the wiring portion are separated as separate regions, and an intermediate region from the input of the LUT is provided. As a result, the switch SW part is separated from the SIM by using technologies such as layout information at the time of LSI design, circuit connection information (schematic), connection confirmation means (LVS), etc. The impact can be examined. In this case, the time for confirmation by simulation can be saved, so that the time efficiency is improved. As a confirmation method at this time, since it is known from the connection information whether the interconnection between the functional blocks occurs or whether the erroneous connection destination is open or driven by a driver, the scale of the input test vector can be reduced.

  9C, as in FIGS. 9A and 9B, the output from the function sub-block is separated by FF, and the switch (SW) part and the LUT input part of the function sub-block R are separated as in FIG. When configuring an area, it is a feature that an LUT or FF is further included in the intermediate area. The LUT and FF may be composed of a plurality of stages. This clearly makes it possible to configure the separation region of the functional sub-block L and the functional sub-block R to have a degree of freedom, and the verification efficiency is improved by performing verification on this intermediate portion.

  As described above, when the separation between the functional blocks is performed on the FPGA, it is an effective technique to separate at the output unit of the flip-flop (FF) provided at the output of the look-up table (LUT). .

  FIG. 10 conceptually shows a bit string of CRAM. The CRAM bit stream 1001 is represented by a string of bits to be stored in the CRAM in the FPGA. The error injection simulation of this embodiment can simulate the occurrence of an error at an arbitrary position in the FPGA CRAM. However, in actual evaluation, it is only necessary to verify only the area used by the user. Therefore, if the bits that are not used by the user are clarified in the FPGA design, it is effective to generate and evaluate only the bits used by the user when performing simulation by error injection. .

  In FIG. 10, it is assumed that an error has occurred in the position 1102 described as x (the bit is inverted), and this condition corresponds to the error mode e # m corresponding to the dangerous failure. Are to be tied.

  In the FPGA circuit, not all of the integrated LUTs and switches are used by the user, and some of them are unused bits that are not used by the user. In order to efficiently perform error injection, it is effective to classify CRAM bits into important bits that affect the user circuit and non-important bits that do not affect the user circuit. This figure also explains the situation.

  The non-significant bits shown in this figure are not actually used by the user, but are directly or indirectly related to the logic used by the user circuit, as well as unused bits that are not actually assigned to the user circuit. Defined as the circuit part excluding expensive unused LUTs and switches. The important bits include CRAM bits used by the user and CRAM bits related to the LUT and SW that are highly relevant to the user circuit. In this embodiment, since it is important to examine the effect when a soft error occurs for a CRAM bit used by a user, an error is generated only for an important bit related to a user use bit, It is important to verify the effect from the viewpoint of verification efficiency.

  FIG. 11 shows an example of a GUI of a design tool as an embodiment of the present invention. A mounting button 1001 for mounting the analysis result in the circuit, an error insertion button 1102 for executing error injection of the CRAM, a button 1103 for executing a simulation in the error insertion state, and a failure specified by the user An analysis button 1104 for performing comparison with the mode is provided. This button may be a mechanical button or may be in the form of a selection item represented by application software expressed by an electromagnetic image display device.

  As an error to be inserted, a method of changing an arbitrary bit of the bit stream is considered. Moreover, the method of changing a bit at random arbitrary times may be used.

  Further, in this evaluation, it is desirable to display a circuit diagram 1105, a mounting state diagram 1106 on an FPGA, a logical simulation output result (waveform diagram) 1107, and an analysis summary 1108. The analysis summary 1108 displays the contents based on the above-mentioned dangerous failure mode list 126.

  FIG. 12 shows an example of analysis result display. As shown in the analysis result display example 1 in FIG. 12A, the influence of the circuit change can be indicated by the error mode e # m, the change of the bit information of the CRAM, and the state of the circuit change. It is possible that In this example, the example described in FIG. 2 is used. In this way, the influence of the error inserted into the CRAM bit stream can be understood, so that the analysis can be easily performed.

  In another embodiment, as shown in the analysis result display example 2 in FIG. 12B, it is possible to display only the error mode e # m and the error location of the CRAM error injection result. Here, e # m is a dangerous failure mode specified by the user. If the internal connection structure of the FPGA is to be kept secret, the CRAM bit inversion information may not be disclosed to the user. In this case, it becomes difficult to directly associate CRAM bit inversion information and circuit change information. In this case, the error location and the dangerous failure mode specified by the user or additional information included in the failure mode are not included. Display it in an understandable way.

  If the physical CRAM bit information and the circuit connection information are not to be associated with each other in order to keep the internal structure of the FPGA confidential, the physical arrangement of the CRAM is conveniently 1 to disclose to the user. A bit string that has been subjected to the one-to-one correspondence conversion may be used to indicate the error insertion in the bit string and the correspondence of the fault circuit. In other words, by converting the CRAM bit string into a bit string that can be disclosed to the user, it is possible to display and evaluate errors as shown in the analysis result display example 1 in FIG. 12 while keeping the FPGA internal structure confidential.

  This is because it is important that the user designer can check the dangerous failure mode without excess or deficiency, so it is possible to quantitatively find out how errors are inserted in the entire CRAM in the FPGA and how they are reflected in the circuit. This is because it is only necessary. According to the present embodiment, it is not necessary to disclose the detailed structure in the FPGA chip.

  When using the FPGA, in order to check the expected error, it is possible to invert all the bits of the CRAM to be used, and the SIM after the conversion to the logical connection information and the changed part It is important to be able to present.

  Up to now, the evaluation of the effects of FPGA CRAM soft errors has been mainly described. However, it is desirable to be able to evaluate LSI hardware failures, so-called permanent failures. If it is FPGA, the wiring part can be made programmable, so if a part of the permanent failure can be expressed as a soft error instead, the influence of the permanent failure can be evaluated in advance.

  FIG. 13 shows an example. In order to connect the circuit blocks arranged in a plane, the FPGA, in a simple example, has two directions in the vertical direction (N and S directions in this figure) and the horizontal direction (E and W directions in this figure). In order to connect these wires freely, it is expressed by six switches (represented here as N-type MOSFETs).

  For example, in order to express connection in the E and W directions, as shown in FIG. 13A, CB0 = “0”, CB1 = “0”, CB2 = “1”, CB3 = “−”, CB4 = “0”, and CB5 = “0” may be set. Here, “−” indicates that either “0” or “1” may be used. On the other hand, when not connected, as shown in FIG. 13B, CB0 = "0", CB1 = "0", CB2 = "0", CB3 = "-", CB4 = "0", CB5 = “0” may be set.

  This means that the influence of connection and disconnection due to migration or the like on the wiring W-E can be expressed by bit inversion of the CRAM, and the influence of the error mode can be confirmed by simulation. With this method, if the effects of necessary wiring and device failures can be confirmed in advance by simulation, it is possible to quantitatively evaluate various circuit measures to ensure safety. It is possible to increase the opportunities for using FPGAs for safety applications.

  According to the embodiment described above, in order to evaluate the effect of so-called soft error due to the bit reversal of the FPGA CRAM, the bit reversal of the inserted CRAM is converted into a fault insertion circuit netlist, and the failure mode as the effect is converted. By outputting the list, it is possible to list all possible failure modes in principle, so that it can be used as a tool for verifying failure modes. Also, by associating the physical location information on the FPGA of the failure location in the failure insertion netlist with the actual load connection / physical location data, the CRAM in the failure mode of interest, taking into account the probability of disconnection or short-circuit due to wiring migration, etc. There is an effect that the failure probability of the function due to the soft error can be obtained. As a result, there is an effect that verification for applying the FPGA to the high safety application can be realized.

  Thereby, since the safety-side failure probability (SFF) is quantitatively obtained, it is possible to reduce the hardware redundancy for satisfying the safety level, which can contribute to cost reduction.

  In the embodiment, the configuration for executing the simulation can be realized by controlling the hardware of the computer with software. In addition, functions equivalent to those configured by software can be realized by hardware such as FPGA and ASIC. Such an embodiment is also included in the scope of the present invention.

  In the first to sixth embodiments, a method for performing a logical simulation after performing error injection has been described. This is a so-called dynamic verification in semiconductor design, in which an input signal switching pattern is prepared comprehensively to confirm the operation of the designed circuit, and whether the desired operation is realized in all operations. It is a technique called.

  On the other hand, there is also a so-called formal verification method in which connection relations of design data are regarded as a mathematical model and mathematical coincidence verification is performed. In the present embodiment, an embodiment for application to the latter type verification will be described. Formal verification is preferably carried out at an RTL level, which is more abstract than physically connecting elements such as transistors integrated in an LSI called a so-called gate level netlist.

  In the present embodiment, an example in which format verification is performed on the RTL resulting from error injection will be described. In order to facilitate format verification, it is necessary to reflect the error injection results in the RTL description file. Hereinafter, a method of reflecting the error injection result will be described with reference to FIG.

  FIG. 14 is a logical block diagram illustrating the relationship between tools and data in the verification system according to the seventh embodiment. In addition to the configuration in Figure 1, RTL processing unit (1401), RTL vs netlist correspondence table (1402), RTL conversion tool (1403), SIM / expected value comparison and formal verification error evaluation tool (1404), fault insertion It has the structure of RTL (1405), format verification result (1406), and assertion description file (1407). Further, as will be described later, the function of the logic synthesis tool (110) is expanded compared to the example of FIG.

  The RTL vs netlist correspondence table (1402) is a table describing the correspondence of connection information and the like in the conversion from the RTL to the netlist when the logic synthesis tool (110) generates the netlist.

  The RTL conversion tool (1403) receives the fault insertion netlist (124), the user-defined data RTL (130), and the RTL vs netlist correspondence table (1402) as input, and converts and generates the RTL after error insertion Is a tool.

  The SIM / expected value comparison and formal verification error evaluation tool (1404) is a tool whose function is expanded so that formal verification can be performed on the SIM / expected value comparison tool (113) of FIG.

Fault insertion RTL (1405) is an output result of the RTL conversion tool (1403). The format verification result (1406) is an output result of the SIM / expected value comparison and format verification error evaluation tool (1404). It also has an assertion description file (1407) that is user-defined data.
1
Here, the SIM / expected value comparison and formal verification error evaluation tool (1404) is shown as one block for convenience, but this tool does not necessarily have to be a single tool. , A form verification tool and an error evaluation tool may be configured by a plurality of tools.

  Unlike the example of FIG. 1, in this example, since RTL (130) SIM and evaluation / verification are required, the RTL (130) and netlist (120) can be linked. , RTL vs netlist correspondence table (1402) etc. are included. When converting from the netlist (120) to the RTL (130), in order to identify individual information hierarchically in the logical description and terminals in the RTL, a process such as assigning a unique symbol or number to each is performed. It is necessary to add to the RTL information. This is for the purpose of improving the efficiency of the procedures necessary to carry out the conversion of only the changed portion when changing from the net list later. The RTL processing unit (1401) performs such processing as extraction of additional information and renaming so that the description in the RTL is completely unique.

  The RTL (130) is usually designed in units of modules, and information on clock operations and logic operations to be processed is described. The RTL vs netlist correspondence table (1402) has a function for hierarchically holding module names, logical operation clock connection information, etc., and the logic synthesis tool (110) is a pair corresponding to RTL module configuration and logical connection information. A netlist (120) associated with a naming rule that facilitates one correspondence is generated.

  Of course, the logic synthesis tool (110) may not be in one-to-one correspondence due to logic compression, timing adjustment, or the like, but in that case, it may be associated with the minimum corresponding logical unit. The minimum logical unit may be an RTL module unit, but the module may be divided into smaller units. As described above, even if the result of logic synthesis is not one-to-one correspondence with RTL due to logic compression or the like, the correspondence between RTL (130) and netlist (120) can be maintained by limiting the corresponding range. Is possible. Therefore, it is desirable that the logic synthesis tool (110) generates the RTL vs netlist correspondence table (1402).

  The netlist description module corresponds to the RTL description module. Furthermore, since the CRAM address map corresponds to the netlist, the change module is identified from the address where the bit inversion operation of the CRAM is performed, and the netlist vs (CRAM) bitstream correspondence table (122) is used. If the connection change location is specified, the RTL change location can be specified.

  The RTL vs netlist correspondence table (1402) is input to the RTL conversion tool (1403) in the error injection evaluation tool (101). The RTL conversion tool (1403) has a function of converting a netlist part corresponding to a part changed by error injection from the fault insertion netlist (124) into RTL. In the netlist, a comment sentence can usually be described. When the error insertion tool (112) generates the failure net list, it is desirable to add the start part and the end part of the error insertion part in a comment format for the corresponding error insertion part. This is because the RTL conversion tool (1403) may search the above comment sentence from the input failure net list, extract the error insertion portion, and change the RTL of that portion. As a result, the necessary minimum data conversion is performed.

  The RTL conversion tool (1403) receives the RTL (130) designed by the user, the RTL vs netlist correspondence table (1402), and the failure insertion netlist (124) as inputs, and outputs a failure insertion RTL (1405). In this conversion, batch conversion from the netlist is also possible, but it is desirable to define only the error insertion point conversion and the differential update type from the original RTL (130). As a result, for example, if RTL is described in System Verilog, it will be retained in the form that includes assertion description etc., so verification efficiency and man-hour reduction rate at the time of format verification after error injection Has the effect of increasing. In addition, in order to clearly indicate that it is the result of error injection, it is desirable to describe comment text at the change start location and change end location for the RTL for fault insertion. This not only facilitates confirmation when re-verifying using an assertion description file or the like for the changed part, but also has an effect of improving the readability of the RTL.

  FIG. 15 shows a processing flow for implementing this embodiment. Compared with the conversion flow shown in FIG. 3, a flow for performing conversion to logical connection information at the RTL level is added. This shows that conversion from the netlist to RTL can be performed.

  In this embodiment, the configuration information bit information of the CRAM mounted on the FPGA is intentionally bit-inverted, and the influence is evaluated. Unlike a general FPGA design flow, it is characterized by having means for converting a CRAM bitstream to a netlist and a netlist to RTL.

  First, circuit design information (RTL A) reflecting the function that the user wants to realize is prepared (S1501). Next, logical connection information A (net list A) is generated from RTL A through logical synthesis (S1502). Circuit design information (RTL A) is the target circuit that you want to configure with FPGA, and is the target data for this evaluation. This may be a part of the function of the FPGA.

  Next, a CRAM bit stream A is generated using the netlist A (S1503). Thereafter, a process of inverting some of the CRAM bits, that is, error injection is performed on the CRAM bit stream A to generate a CRAM bit stream B (S1504). As will be described later, the inversion portion of the CRAM bit can be selected according to the purpose.

  Thereafter, logical connection information B (net list B) corresponding to the CRAM bit stream B is generated (S1505). When the logical connection information B is generated from the bit stream B, information in which the correspondence between the netlist and the bit stream is one-to-one as described above may be used. Finally, circuit design information (RTL B) is generated from the logical connection information B (net list B) (S1506). Error injection format verification is performed on this RTL B using user-specified assertion data.

  FIG. 16 is a conceptual diagram illustrating a method for converting a netlist to RTL. A netlist to RTL conversion method will be described using an example of evaluating the influence of CRAM bit inversion shown in FIG. RTL A is Verilog HDL code that describes the circuit of FIG. In the flow shown in FIG. 15, the RTL description in the case where the circuit reflecting the influence in the net list as a result of the bit inversion of CRAM in FIG. 2C is the description shown in RTL B in FIG. 15.

  As a result of error injection, the netlist is changed. At that time, the newly generated element name and net name are marked so that the tool automatically generates them (for example, with the identification character x, If the element name is andx01, the net name is netx01, etc., the difference can be clarified. When converting from the netlist to the RTL, the identification character may be used as a search and converted into the logical expression of the corresponding module in the RTL. The modified RTL can be clarified by inserting comment text at the start and end of the change.

  In this embodiment, an example will be described in which format verification, for example, property verification, is performed on the changed RTL.

As an example of property verification, in the following logical expression described in RTL A,
assign o = (I0 & I1 | I2 & I3) (1)
In order to confirm that the expression (1) is satisfied, it is known that a description called an assertion is performed to mathematically confirm that the expression (1) holds. As an example, assume that the following assertion description is performed for RTL A to confirm that Equation (1) holds.
assert property (I0 == 0 & I1 == 0 & I2 == 0 & I3 == 0 |-> o == 0) Expression (2)
When described in this way, it can be confirmed and verified from the model structure that the output o becomes 0 when all of the inputs I0 to I3 are 0 under the conditions that can be assumed by the expression (1). In the case of Expression (1), it can be verified that the output is 0 in the case of the above input.
On the other hand, for RTL after error injection, the logical expression is
assign o = (((I0 & I1) | I1) | ~ (I2 | I3)) | I2 & I3) ... (3)
Therefore, when the property verification of the expression (2) is performed, the value of the output o becomes 1, so the expression (2) does not hold and an error is output.

  In this example, error injection to CRAM is explained with a relatively simple circuit that occurs at the LUT level, but more complex logic changes across modules or multiple modules Even if the error occurs or the effect propagates over a plurality of cycles, if an appropriate assertion statement can be described, an error can be found in principle.

  What is important in the safety design is the probability of a dangerous potential failure, and it is important for the error evaluation tool to detect this dangerous potential failure mode. The dangerous latent failure is a failure mode in which, among failures that cannot be detected by the diagnostic circuit mounted on the FPGA, eventually, the failure is combined with other failures and transitions to a dangerous state. For this reason, it is possible to determine whether the influence of error injection is dangerous or safe by performing assertion description that reproduces a possible dangerous failure mode. Combining error injection evaluation with formal verification has the effect of making it possible to efficiently confirm possible dangerous failure modes.

<Appendix>
The present invention discloses the following invention. Ie;
For an FPGA that holds logic circuit information by CRAM, a simulator that evaluates an expected error, comprising a processing device, a storage device, an input device, and an output device,
The storage device stores correspondence information between circuit design information (RTL) to be formed in the FPGA and a net list which is circuit connection information, and a bit stream which is a bit string stored in the net list and the CRAM. Storing one-to-one correspondence information of
The input device receives an input of the bitstream corresponding to the netlist to be evaluated;
The processing apparatus includes an error insertion tool, an expected value comparison tool, and a format verification evaluation tool,
The error insertion tool is
Means for modifying the input bitstream;
Means for referring to the correspondence information and generating a fault insertion netlist by reflecting the change of the bitstream in the netlist to be evaluated;
Means for generating a fault insertion RTL from the fault insertion netlist;
Formal verification evaluation information for performing formal verification evaluation for fault insertion RTL, and input means,
The expected value comparison tool is:
Means for applying a predetermined input to the fault insertion netlist to perform a logical simulation;
Means for comparing the output result of the simulation with an expected output value;
The formal verification evaluation tool is a simulator comprising means for performing formal verification on the fault insertion RTL using formal verification evaluation information and holding the result.

  The present invention is not limited to the embodiments described above, and includes various modifications. For example, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Moreover, it is possible to add / delete / replace the configurations of the other embodiments with respect to a part of the configurations of the embodiments.

  It is applicable to the field of error evaluation and design support such as FPGA.

FPGA ・ ・ ・ Field Programmable Gate Array,
CRAM ... Configuration Memory, LUT ... Look Up Table, SEL ... Selector, SW ... Switch, FF ... Flip Flop, GUI ... Graphic User Interface, CB ... CRAM Bit,

Claims (15)

It is a simulator that evaluates an expected error for an FPGA that holds logic circuit information by CRAM.
A processing device, a storage device, an input device, and an output device;
The storage device stores one-to-one correspondence information between a net list which is circuit connection information to be formed in the FPGA and a bit stream which is a bit string stored in the CRAM,
The input device receives an input of the bitstream corresponding to the netlist to be evaluated;
The processing apparatus includes an error insertion tool and an expected value comparison tool,
The error insertion tool is
Means for modifying the input bitstream;
Means for referring to the correspondence information and generating a fault insertion netlist by reflecting the change of the bitstream in the netlist to be evaluated;
The expected value comparison tool is:
Means for applying a predetermined input to the fault insertion netlist to perform a logical simulation;
Means for comparing an output result of the simulation with an expected output value;
A simulator characterized by that. The output expected value is
Including true value and preset dangerous failure output value,
The simulator according to claim 1. The expected value comparison tool is:
For each simulation, output an output result that matches the dangerous failure output value as a failure mode list.
The simulator according to claim 2. A dangerous failure rate calculation tool is provided,
The dangerous failure rate calculation tool is:
With the actual load connection and physical placement data of the FPGA, the fault insertion netlist, and the fault mode list as inputs,
The physical location information of the fault location in the fault insertion netlist is identified by associating with the actual load connection and physical location data to estimate the fault probability,
The simulator according to claim 3, wherein the simulator outputs the data in association with the contents of the failure mode list. The input device is:
Means for instructing the error insertion tool to change a specified portion of the bitstream or to change it randomly.
The simulator according to claim 1. The output means includes
A function of prohibiting output of the correspondence information;
When displaying simulation results,
Analysis result information indicating the logical connection state of the FPGA created based on the netlist, and information for specifying a part that affects the change to the bitstream in the analysis result information is displayed,
The simulator according to claim 1. In a field programmable LSI (FPGA) design support system that holds logic circuit information by a rewritable storage means called a configuration memory (CRAM),
A processing device, a storage device, an input device, and an output device;
The input device is:
Receiving the first bit information input corresponding to the first logical connection information stored in the CRAM;
The processor is
A first means for reversing a part of the bits of the first bit information to generate second bit information;
The second bit information is converted into second logical connection information in correspondence with the change of the first logical connection information that has a one-to-one correspondence with the first bit information. Means,
A third means for executing a logical and circuit simulation using the second logical connection information;
Design support system for semiconductor circuit devices. The third means includes
A means for comparing one or more inputs to the second logical connection information and an output result of the simulation corresponding to each of the plurality of inputs with an output expected value corresponding to the input determined separately;
The expected output value is
Defined as an expected value table consisting of correct results obtained during simulation with the first logical connection information and one or more output results at the time of failure assuming the cause of failure in generating the second bit information And stored in the storage device,
The means for comparing with the output expected value is:
A match search is performed between the output result of the simulation and the output expected value, and when the result matches with any one of the expected values described in the expected value table, the output and the expected value are associated with each other and the output means It has a verification means to display as a failure mode list in,
8. A design support system for a semiconductor circuit device according to claim 7. Furthermore, for each failure expressed in the failure mode list, LSI wiring information, physical layout information, defect information in the manufacturing process, and other information necessary for LSI failure calculation are used as a basis. A means for calculating a failure probability corresponding to each failure mode,
9. A design support system for a semiconductor circuit device according to claim 8. A design support method for a semiconductor circuit device that evaluates an assumed error for an FPGA that holds logic circuit information by CRAM,
Using a processing device, a storage device, an input device, and an output device,
The storage device
Storing one-to-one correspondence information between a net list which is circuit connection information to be formed in the FPGA and a bit stream which is a bit string stored in the CRAM;
The input device is:
Receiving the bitstream input corresponding to the netlist to be evaluated,
The processor is
A first step of modifying the input bitstream;
A second step of referring to the correspondence information and generating a fault insertion netlist reflecting the change of the bitstream;
A third step of applying a predetermined input to the fault insertion netlist to perform a logical simulation;
Design support method for semiconductor circuit device for executing A fourth step of comparing the output result of the simulation with an expected output value;
The method of supporting design of a semiconductor circuit device according to claim 10, wherein: The netlist to be evaluated and the bitstream corresponding to the netlist are partial information corresponding to a part of a circuit configured with the FPGA,
In the first to fourth steps, the partial information is processed.
12. A design support method for a semiconductor circuit device according to claim 11. A portion of the circuit is:
A part obtained by dividing the circuit configuration configured by the FPGA according to the function to be realized by the FPGA, or a part divided based on a safety concept for realizing the function,
13. A design support method for a semiconductor circuit device according to claim 12. A portion of the circuit is:
Of the circuit configuration composed of the FPGA, it is a part related to the circuit related to the logic used by the user,
13. A design support method for a semiconductor circuit device according to claim 12. A portion of the circuit is:
When separating the functional blocks on the FPGA,
The functional block separated at the output part of the flip flop (FF) provided at the output of the Look Up Table (LUT), or
The functional block separated by the output unit of the FF provided at the output of the LUT and the output unit of the switch circuit unit, or
Separated by the output part of the FF provided at the output of the LUT and the output part of the switch circuit part, and separated by providing one or more LUTs and FFs between the FF output part and the switch part. Is the functional block,
13. A design support method for a semiconductor circuit device according to claim 12.

Images