Simulation system, simulation method, and control method for the simulation system

Abstract

This simulation system comprises: a Field Programmable Gate Array (FPGA) board on which an FPGA is mounted and which can perform serial communication with an external device; and a control device which controls the FPGA board by transmitting actual device verification test data for actual device simulation to the FPGA board via serial communication with the FPGA board, such transmission performed using a console application capable of macro operation. The control device includes a conversion unit that converts logic verification test data, which is for executing logic simulation of a logic circuit to be verified, into actual device verification test data for continuously executing actual device simulation on the FPGA board. The FPGA board executes actual device simulation of the FPGA in which the logic circuit is configured on the basis of the actual device verification test data.

Description

Simulation system and simulation method

[0001] The present disclosure relates to a co-verification technique for executing a real-device simulation and a logic simulation.

[0002] Traditionally, when designing an integrated circuit, simulation is used to verify whether the functions and performance of the integrated circuit will meet the designer's expectations. This simulation is performed using a hardware description language (HDL), which describes the circuit's structure and simulates its operation on a computer. HDL simulation has the advantage of being highly debuggable because it allows verification while monitoring the circuit's internal structure. However, when multiple functions are incorporated into a circuit, such as a system-on-a-chip (SOC), the circuit size increases, and the amount of verification pattern data and programs required for comprehensive HDL simulation increases, resulting in a long simulation time. In addition, it is difficult to verify the operating system (OS) and comprehensive verification items, making it difficult to verify all circuit operations using HDL simulation. To address these issues, a technique known as co-verification has come into use. This involves configuring part of the logic of the circuit under verification into a field programmable gate array (FPGA), and then combining an actual FPGA simulation with an HDL simulation to perform verification.

[0003] In Patent Document 1, a collaborative verification device has a CPU (Central Processing Unit) in a programmable circuit (such as an FPGA) that performs a real-machine simulation, and an FPGA board on which the user logic to be verified is realized by the FPGA. Application data and a test bench are stored in a read-only memory (ROM), and collaborative verification is performed in accordance with instructions from an external control PC, thereby increasing the verification speed.

[0004] In Patent Document 2, the data of the verification results of the logic simulation is converted into a predetermined format and expanded into a ROM present on the FPGA, and the verification work of the user logic that is the target of verification present on the FPGA is automated to perform the verification.

[0005] JP 2015-11363 A JP 9-36237 A

[0006] However, the method of Patent Document 1 requires that an OS such as LINUX (registered trademark) be installed on the FPGA and that logic simulation software, test applications, etc. be installed on the OS, which requires large resources such as memory and circuit area that are originally present in the FPGA. Therefore, this is a collaborative verification method that is difficult to implement on small-scale FPGAs.

[0007] Furthermore, the method of Patent Document 2 uses a unique format for automatically generating test data, which makes development difficult, and it is expected that the number of development steps will increase if the same verification method is to be realized.

[0008] The present disclosure has been made to solve the above-mentioned problems, and aims to provide a simulation system and a simulation method that can efficiently execute comprehensive collaboration verification in a simple manner.

[0009] A simulation system according to one disclosure includes an FPGA board equipped with an FPGA (Field Programmable Gate Array) and capable of serial communication with an external device, and a control device that controls the FPGA board by transmitting real-device verification test data for real-device simulation to the FPGA board via serial communication using a macro-operable console application. The control device includes a conversion unit that converts logic verification test data for executing a logic simulation of a logic circuit to be verified into real-device verification test data for executing the real-device simulation on the FPGA board. The FPGA board executes a real-device simulation of an FPGA whose logic circuit is configured based on the real-device verification test data.

[0010] Another disclosed simulation method is a simulation method for an FPGA board equipped with an FPGA (Field Programmable Gate Array) and capable of serial communication with an external device, and includes the steps of: converting logic verification test data for executing a logic simulation of a logic circuit to be verified into real-device verification test data for executing a real-device simulation on the FPGA board; transmitting the real-device verification test data to the FPGA board via serial communication with the FPGA board using a console application capable of macro operation; and executing a real-device simulation of an FPGA whose logic circuit has been configured based on the real-device verification test data.

[0011] The simulation system and simulation method of the present disclosure are capable of efficiently performing comprehensive co-verification in a simple manner.

[0012] FIG. 1 is a diagram illustrating a configuration of a simulation system according to a first embodiment. FIG. 2 is a diagram illustrating functional blocks of an external PC 100 according to a first embodiment. FIG. 3 is a diagram illustrating a logic simulation executed by a simulation unit 12 according to a first embodiment. FIG. 4 is a diagram illustrating a real machine simulation according to a first embodiment. FIG. 5 is a diagram illustrating automatic generation of test data according to a first embodiment. FIG. 6 is a diagram illustrating an example of conversion of category CA according to a first embodiment. FIG. 7 is a diagram illustrating an example of conversion of category CB according to a first embodiment.

[0013] Hereinafter, embodiments will be described with reference to the accompanying drawings. In the following description, identical parts are designated by the same reference numerals. Since the names and functions of these parts are also the same, detailed description thereof will not be repeated.

[0014] First Embodiment. Fig. 1 is a diagram illustrating the configuration of a simulation system 1 according to a first embodiment. Referring to Fig. 1, the simulation system 1 includes an external PC (Personal Computer) 100, a serial communication cable 101, and an FPGA board 102. The FPGA board 102 is configured with four components: a CPU 103, a serial communication control circuit 104, user logic 105 to be verified, and on-chip RAM (Random Access Memory) 106. The CPU 103, the serial communication control circuit 104, the user logic 105 to be verified, and the on-chip RAM 106 are all connected via buses. In Fig. 1, the user logic 105 to be verified is shown as being configured in an FPGA.

[0015] The FPGA board 102 is connected to an external PC 100 via a serial communication cable 101. The external PC 100 is provided with general open source software (OSS) called a macro-operable console application (such as Tera Term or Putty). The external PC 100 uses a serial communication function included in the console application to transmit and receive data for verifying the user logic 105 and data on the verification results from the external PC 100 to the FPGA board 102.

[0016] The CPU 103 has the role of executing a software program that accesses the user logic 105 based on an instruction code included in data transmitted via the serial communication control circuit 104. If the instruction code is an ASCII character string, the software program includes a function for decoding the ASCII character string into the content for accessing the user logic 105. The on-chip RAM 106 stores the software program. The software program can easily be customized to allow the user to customize the content they wish to verify.

[0017] The CPU 103 transmits a signal to the user logic 105 to be verified in accordance with the instruction code to execute the operation to be verified, and receives the verification result from the user logic 105 to be verified. If the instruction from the external PC 100 is an instruction to send a signal from the user logic 105 to be verified to the external PC 100, the CPU 103 transmits the signal to the external PC 100 via the serial communication control circuit 104 and the serial communication cable 101. This makes it possible to display the result on a console application provided in the external PC 100.

[0018] FIG. 2 is a diagram illustrating functional blocks of the external PC 100 according to the first embodiment. Referring to FIG. 2, the external PC 100 includes a simulation unit 12, a test data generation unit 14, a conversion unit 16, and a transmission / reception unit 18. Each functional block is implemented by a CPU (central processing unit) provided in the external PC 100 executing a software program. The simulation unit 12 performs logic simulation verification using logic simulation software within the environment of the external PC 100. The test data generation unit 14 generates logic verification test data used in the logic simulation verification performed by the simulation unit 12. As an example, the test data generation unit 14 designs test data using Verilog-HDL or the like. The conversion unit 16 converts logic verification test data for performing a logic simulation of a logic circuit to be verified into real-device verification test data for real-device simulation. The transmission / reception unit 18 transmits the converted real-device verification test data to the FPGA board 102 and receives test results from the FPGA board 102.

[0019] 3 is a diagram illustrating logic simulation executed by simulation unit 12 according to the first embodiment. Referring to Fig. 3, simulation unit 12 generally executes logic simulation verification using logic simulation software 201 in the environment of external PC 100 before RTL (Register Transfer Level) 202 to be verified, which is designed in Verilog-HDL or the like, is written to FPGA board 102.

[0020] The test data generator 14 generates test data 203 for verifying whether the RTL 202 designed to be verified operates according to the design specifications in a logic simulation. The test data 203 is written in Verilog-HDL.

[0021] The simulation unit 12 starts verification by inputting the RTL 202 to be verified and test data 203 using logic simulation software 201, and verifies whether the operation is identical to the design specifications based on the execution results (waveforms, etc.) output by the logic simulation software 201.

[0022] FIG. 4 is a diagram illustrating a real-machine simulation according to the first embodiment. Referring to FIG. 4 , the external PC 100 typically configures the RTL 202 to be verified, for which logic simulation has been completed, in the FPGA as the user logic 105 of the FPGA board 102, and then performs real-machine simulation verification assuming that the FPGA board 102 will actually be used. The real-machine simulation of the present disclosure uses, as an example, a console application with a serial communication function. In this example, an example using Tera Term 301, one of the console applications, will be described. Tera Term provides various communication and control commands, and these commands can be used to send ASCII characters to the FPGA board 102 via serial communication. Furthermore, by writing a TTL 302 in which these commands are scripted, a series of command operations can be automatically executed.

[0023] For example, "sendln("mw 0 47")" is written in TTL 302. The "sendln" command converts the character string ""mw 0 47"" into ASCII characters and transmits them serially to FPGA board 102 via serial communication cable 101.

[0024] For example, when the character string "mw 0 47" is converted into ASCII characters, the result is "6d 77 20 30 20." These ASCII characters are transmitted to the serial communication control circuit 104 via the serial communication cable 101. The serial communication control circuit 104 then transmits the ASCII character string "6d 77 20 30 20" to the CPU 103 via the bus. The CPU 103 converts the ASCII character string received from the serial communication control circuit 104 into alphanumeric characters "mw 0 47" and executes software that decodes the character string as an instruction code. Since the decoding process separates the received character string into spaces, in this example, the decoding process is performed by dividing the received character string into three parts: "mw," "0," and "47." The first "mw" indicates a write instruction to memory, the second "0" indicates the write address in memory, and the third "47" indicates the data to be written to memory. Therefore, "mw 0 47" is a command to write 47 to address 0 of memory. Based on the decoded result, the CPU 103 transmits a signal to the user logic 105 to be verified to execute a write access to the memory. If the verification operation is successful, the CPU 103 outputs the verification result to the external PC 100. As an example, the CPU 103 sets the character string "o" to indicate that the write operation from the user logic 105 to be verified to the memory was successful. The CPU 103 transmits "6f", which is the ASCII character for "o", from the serial communication control circuit 104 via the serial communication cable 101. The external PC 100 displays the result "6f" on the Tera Term 301 in accordance with the transmitted data. This makes it possible to confirm that the verification operation on the user logic 105 to be verified was successful. A program to execute a predetermined test operation on the user logic 105 to be verified is stored in advance in the on-chip RAM 106.

[0025] The second line of the TTL 302 describes "sendln("md 0 10")". When this command is decoded, it is divided into three parts: "md", "0", and "10". The first "md" indicates a read instruction to memory, the second "0" indicates the memory read start address, and the third "10" indicates the number of pieces of data to read from memory. Therefore, "md 0 10" is a command to continuously read data from memory addresses 0 to 10. The data read from the user logic 105 under verification is displayed on the external PC 100 from the serial communication control circuit 104 via the serial communication cable 101.

[0026] Therefore, the above two commands complete a series of verification operations, writing "47" to memory address 0 of the user logic 105 to be verified and reading data from addresses 0 to 10. This series of verification operations is created by TTL 302 and executed by Tera Term 301 in accordance with TTL 302, eliminating the need to manually input commands during verification and enabling automatic verification. The same applies to other commands.

[0027] FIG. 5 is a diagram illustrating automatic generation of test data according to the first embodiment. With reference to FIG. 5 , the present disclosure describes a conversion unit 16 that automatically generates real-machine verification test data to be used in a real-machine simulation from logic verification test data to be used in a logic simulation. As an example, a case will be described in which the conversion unit 16 converts test data 203 written in Verilog-HDL into TTL 302, a macro language used in Tera Term 301. The content verified in the logic simulation must also be verified in the real-machine simulation. Since the user does not need to rewrite the content of the test data used in the logic simulation into test data to be used in the real-machine simulation, the initial cost of verification can be reduced. Furthermore, since the content of the verification is guaranteed to be the same between the logic simulation and the real-machine simulation, it is possible to separate the verification and debugging. For example, assume that the content of the logic verification test data is rewritten into real-machine verification test data without using the conversion unit 16. If the expected results are not obtained in the real-machine simulation, debugging becomes difficult because it is necessary to consider the possibility that an error may have occurred during the rewriting. On the other hand, it is assumed that real-machine verification test data is created using the conversion unit 16 and that the real-machine simulation is performed using the test data. If the expected results are not obtained in the real-machine simulation, errors in rewriting can be prevented, and it is possible to determine that the logic simulation was incorrect, making debugging easier.

[0028] The conversion unit 16 is also configured to convert the actual machine verification test data used in the actual machine simulation into logic verification test data used in the logic simulation. In other words, bidirectional conversion is possible. This function is designed to ensure that the verification content of the logic simulation and the actual machine simulation is the same, assuming that the user modifies only the actual machine verification test data. This function can also handle cases where no logic verification test data exists and only actual machine verification test data exists, making it possible to verify whether a defect that occurred in the actual machine also appears in the logic simulation when debugging.

[0029] The following describes the processing of conversion unit 16 according to embodiment 1. Conversion unit 16 reads input test data and performs language conversion based on the language specification of output test data so that the verification content is equivalent to the read verification content.

[0030] First, the algorithm for reading input test data will be described. Input test data is first read by dividing it into phrases through lexical analysis, and then syntactic analysis is performed using the divided phrases. Lexical analysis is an analytical method for dividing character strings described in test data into meaningful units of phrases. As an example, the conversion unit 16 of the present disclosure classifies the test data into the following five phrases. Note that this classification example is merely an example, and since the phrases differ depending on the language of the input test data, this can be handled by appropriately creating a database for phrases corresponding to each language.

[0031] Specifically, as an example of lexical analysis, a case will be described in which classification is performed into (1) identifiers, (2) reserved words, (3) constants, (4) delimiters, and (5) operators.

[0032] (1) Identifiers are alphanumeric strings such as variable and function names. Examples include "hoge," "hoge123," and "hoge_foo." (2) Reserved words are strings with specific meanings used in input test data. For example, in the case of Verilog-HDL, "if," "for," "wire," "reg," and "begin" are classified as reserved words. (3) Constants are consecutive integers or strings enclosed in "" or "'." For example, phrases such as "123," ""hoge," and "'foo" are classified as constants. (4) Delimiters are symbols with specific meanings used in input test data. For example, in the case of Verilog-HDL, delimiters include ";," "[," and "("). (5) Operators are symbols that represent operations such as arithmetic operators, logical operators, and inequality signs. Examples include "+," "-," "*," "<=", and "&&."

[0033] Next, syntactic analysis is an analysis method that uses software to understand the written content (syntax) of test data from the lexical parts separated by lexical analysis. The syntax varies depending on the language of the input test data, and is analyzed based on the BNF notation (Backus-Naur Form) for each language. The following is an example of BNF notation, which indicates that the identifiers analyzed by lexical analysis are composed of either variables or functions. It indicates that the constituent variables and functions are composed of alphanumeric characters. In this way, by building up syntax from the lexical parts separated by lexical analysis, it becomes possible to understand the input test data. Since the BNF notation for each language is defined and is a common technology, it can be created appropriately by obtaining the BNF notation for each language. Note that even if the test data uses a unique language that is not commonly used, creating the BNF notation makes it possible to apply the language conversion disclosed herein.

[0034] As an example, an example of BNF notation will be described. Identifier::=Variable | Function Variable::=Alphanumeric Function::=Alphanumeric Next, after lexical analysis and syntactic analysis are completed, language conversion is performed based on the language specifications of the converted output test data. Note that during language conversion, if the verification content described in the input test data does not conform to the language specifications of the output test data, it may be addressed by commenting out the content so that it is clear that it is not supported. Furthermore, the user may check the converted output test data and confirm that it has not been converted, and then delete it or verify it using another method.

[0035] An example of conversion from Verilog-HDL to TTL will be described below. As a conversion specification when converting from Verilog-HDL to TTL, a case will be described in which processing is divided into the following two categories CA and CB.

[0036] Category CA covers functions that are common to TTL and Verilog-HDL. Category CB covers reserved words other than those in category CA (<Verilog-HDL>) and reserved words other than those in category CA (<TTL>).

[0037] The following explanation is divided into categories. FIG. 6 is a diagram illustrating an example of conversion for category CA according to the first embodiment. Referring to FIG. 6, when converting from Verilog-HDL to TTL, if the prefix "ttl." is used, the prefix is ​​removed, and the output is a result in which parentheses "()" and semicolons ";" are removed in accordance with the TTL LRM (Language Reference Manual). Note that the function name "waitttl" is used for the wait function, as it overlaps with a reserved word in Verilog-HDL.

[0038] On the other hand, when converting from TTL to Verilog-HDL, for example, the prefix "ttl." is added, and the result is output with parentheses () and semicolons added in accordance with the Verilog-HDL LRM. However, since "wait" overlaps with a reserved word in Verilog-HDL, it is converted to the function name "waitttl".

[0039] FIG. 7 is a diagram illustrating an example of conversion of category CB according to the first embodiment. Referring to FIG. 7, when converting from Verilog-HDL to TTL, the following conversion process is performed. Because TTL is a language that does not use variable declarations, variable declarations are deleted. For example, the portion written in area A1 is deleted in order to declare variables. Because TTL is a language that executes code in order from the first line, for example, "initial begin ~ end" in area A2 is deleted. For example, the conditional branching and repetitive processing in area A3 are transformed into a form that complies with LRM. As an example, the converted contents of area A3 are written in area B3.

[0040] On the other hand, when converting from TTL to Verilog-HDL, the following conversion process is performed. Specifically, since Verilog-HDL is a language that declares variables, a variable declaration is added. Since Verilog-HDL is a language that executes processing enclosed in "initial begin ~ end", the processing up until the first label appears is clearly indicated with "initial begin ~ end". Conditional branching, repetitive processing, etc. are converted into a format that conforms to LRM. The label ":" and call are converted into task syntax, making it possible to call processing.

[0041] Note that this conversion example is just an example and can be applied to other test data as well. Also, in this example, the language conversion between TTL and Verilog-HDL has been described, but this is not limiting and a person skilled in the art can make appropriate changes to other language conversions in accordance with the LRM of each language.

[0042] In the configuration of the FPGA 102 disclosed herein, the FPGA utilizes a CPU (e.g., NIOS in the case of Intel) and a communication protocol control circuit provided by the FPGA vendor, and is implemented on the FPGA together with the user logic 105 to be verified. Test data is transmitted to and received from an external PC via the serial communication function of common open source software (OSS) called a console application (e.g., Tera Term or Putty) so that the FPGA board 102 does not require a separate CPU 013 and serial communication control circuit 104. Furthermore, the test data can be automatically converted from the HDL used in logic simulation to a script language used in the console application, thereby reducing the man-hours required for test data development. In this example, as an example, when Tera Term is used in a console application, a method for automating input to Tera Term using TTL (Teraterm Language), a macro language that can be used in Tera Term, has been described. Furthermore, using a general console application eliminates the need to embed simulation software or test applications into the FPGA. This eliminates the need for extensive FPGA resources, since only the minimum necessary circuit configuration (CPU, serial communication control circuit, and user logic to be verified) is required. Furthermore, using OSS eliminates the need to develop PC-side control software for communicating with the FPGA, reducing development time. Furthermore, in collaborative verification, the person performing the logic simulation may be different from the person performing the actual simulation. In such cases, the verification content of the logic simulation and the verification content of the actual simulation must be defined in a verification specification or other document, and the verification items must be standardized between the two parties. However, incomplete verification specifications or differences in understanding can lead to incorrect verification between the two parties, resulting in overlooking defects. Using the method disclosed herein, the HDL used in the logic simulation is automatically converted to test data used in the actual simulation, ensuring that the verification content is equivalent, thereby reducing debugging time during collaborative verification.

[0043] The configurations exemplified as the above-described embodiments are examples of the configurations of the present disclosure, and may be combined with other known technologies, or may be modified, such as by omitting some parts, within the scope of the gist of the present disclosure. Furthermore, the above-described embodiments may be implemented by appropriately adopting the processes and configurations described in other embodiments.

[0044] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present disclosure is defined by the claims, not by the above description, and is intended to include all modifications within the meaning and scope of the claims.

[0045] 1 Simulation system, 12 Simulation unit, 14 Test data creation unit, 16 Conversion unit, 18 Transmitting / receiving unit, 101 Serial communication cable, 102 FPGA board, 104 Serial communication control circuit, 105 User logic, 106 On-chip RAM, 201 Logic simulation software, 203 Test data.

Claims

1. An FPGA board equipped with an FPGA (Field Programmable Gate Array) that can communicate serially with external devices, The system includes a control device that controls the FPGA board by transmitting actual verification test data for actual simulation to the FPGA board via serial communication using a macro-operable console application, The control device includes a conversion unit that converts logic verification test data for performing logic simulation of the logic circuit to be verified into actual device verification test data for performing actual device simulation on the FPGA board. The FPGA board executes a real-world simulation of the FPGA, with the logic circuits configured based on the real-world verification test data. The data from the aforementioned actual machine verification test includes instruction code, The FPGA board is a simulation system comprising a CPU that executes a program that accesses the logic circuit based on the instruction code, obtains verification results from the logic circuit, and transmits the verification results to the control device.

2. The control device further includes a simulation unit that performs a logic simulation of the logic circuit, The simulation system according to claim 1, wherein the conversion unit is provided capable of converting the actual machine verification test data into the logical verification test data.

3. An FPGA board equipped with an FPGA (Field Programmable Gate Array) and capable of serial communication with an external device, The system includes a control device that controls the FPGA board by transmitting actual verification test data for actual simulation to the FPGA board via serial communication using a macro-operable console application, The control device includes a conversion unit that converts logic verification test data for performing logic simulation of the logic circuit to be verified into actual device verification test data for performing actual device simulation on the FPGA board. The FPGA board executes a real-world simulation of the FPGA, with the logic circuits configured based on the real-world verification test data. The control device further includes a simulation unit that performs a logic simulation of the logic circuit, The conversion unit is provided in a simulation system capable of converting the actual machine verification test data into the logical verification test data.

4. A simulation method for an FPGA board equipped with an FPGA (Field Programmable Gate Array) and capable of serial communication with an external device, The steps include: converting logic verification test data for performing logic simulation of the logic circuit to be verified into actual device verification test data for performing actual device simulation on the FPGA board; The steps include: transmitting the actual hardware verification test data to the FPGA board via serial communication using a macro-operable console application; The system includes the step of performing a real-world simulation of the FPGA configured with the logic circuit based on the aforementioned real-world verification test data. The data from the aforementioned actual machine verification test includes instruction code, A simulation method further comprising the steps of performing access to the logic circuit based on the instruction code, obtaining verification results from the logic circuit, and transmitting the verification results to the external device.

5. A control method for a simulation system comprising an FPGA (Field Programmable Gate Array) mounted on an FPGA board capable of serial communication with an external device, and a control device that controls the FPGA board by transmitting actual verification test data for actual simulation to the FPGA board via serial communication using a macro-operable console application, The steps include: converting logic verification test data for performing logic simulation of the logic circuit to be verified into actual device verification test data for performing actual device simulation on the FPGA board; The steps include: transmitting the actual hardware verification test data to the FPGA board via serial communication using a macro-operable console application; The steps include: executing a real-world simulation of the FPGA configured with the logic circuit based on the aforementioned real-world verification test data; The steps include modifying the aforementioned actual device verification test data, The steps include converting the modified actual device verification test data into logical verification test data, A control method for a simulation system, comprising the step of performing a logic simulation of the logic circuit based on the converted logic verification test data.