JP4340139B2 - Test data creation device - Google Patents

Description

  The present invention relates to information held by a conversion tool for creating test data and a method for describing a script to be converted by the conversion tool in a system LSI verification method.

  The test data used for verification of the system LSI is created in accordance with a part to be verified of the designed system LSI, and corresponds to the CPU of the system LSI to be tested. This test data may contain a signal specific to the designed system LSI.

  Since the verification of the designed system LSI was performed by creating test data individually, even in the simulation model used for verification, the interface with the test target part was not unified, and there were many parts to be created individually .

In addition, the design of a system LSI is rarely composed of only new functions, and in most cases, new functions are added to conventional functions.
JP-A-1-250874 JP-A-2-287837 JP-A-5-172903

It is an object of the present invention is to save labor to create the test data used to validate the design the system LSI.

In other words, the invention aims to efficiently create logical verification test data.

The test data creation device according to the present invention is:
A test data creation device for creating test data for verifying the operation of an LSI (Large Scale Integrated Circuit) incorporating a CPU (Central Processing Unit) unit,
CPU unit architecture correspondence table for storing CPU unit specifications having CPU unit system bus operation timing information and memory space addresses, which are used to create test data for operating the CPU unit. When,
Input script for command to input / output data, refer to memory space address in CPU part architecture correspondence table, create test pattern with address and data in correspondence with clock, and support CPU part architecture A conversion tool that refers to the operation timing information in the table, creates control data corresponding to the operation sequence of the system bus in correspondence with the clock, and outputs the test pattern and control data as test data for executing the above command.
It is provided with.

  Test data creation device is a conversion tool for inputting a script corresponding to a different CPU and converting the input script into test data synchronized with the clock of the bus capable of verifying the logic of the block connected to the CPU bus. Therefore, the diversion of data can be improved and the labor for creating test data can be reduced.

Embodiment 1 FIG.
Hereinafter , description will be made based on the embodiments shown in the drawings. FIG. 1 is a diagram illustrating a system configuration example according to the first embodiment. In the figure, 1 is a script corresponding to a different CPU, 2 is a conversion tool for converting a script corresponding to a different CPU into test data, 3 is test data, 3a is a test pattern portion of test data for verifying a test object, 3b is the control data of the test bench part that controls the test object, 4 is the configuration of the simulation model of the system LSI, 4a is the test bench part used for the simulation model, and 4b is a simulated CPU for the simulation model A bus driver, 4c is an internal bus of a system LSI in which a pseudo bus driver for CPU and a test target are connected, 4d is a test target in the simulation model, 4d-1 to 4d-2 are block parts to be tested, 4e is a test controlled by test patterns and control data. It shows a control signal group bets subject.

  FIG. 2 is a diagram illustrating an example of the test pattern 3a. In the figure, 3a-1 is a clock synchronized with the internal bus 4c, 3a-2 is an address value output to the internal bus 4c, 3a-3 is a data value output to the internal bus 4c, and 3a-4 is an internal value. The control signal of the bus 4c is shown.

  Next, the operation will be described. If script 1 has a description of writing 4 bytes of data 0x04030201 at address 0x8000, test pattern 3a and control data 3b of test data 3 are created using a conversion tool.

  In the conversion tool 2, the CPU of the system LSI outputs 3 clocks of the address 3a-2 with respect to the clock 3a-1, outputs 2 clocks of the data 3a-3 with a delay of 1 clock from the start of the address 3a-2, and R / W3a-4 outputs 3 clocks at the same timing as address 3a-2, and holds timing information indicating that it does not return to Read during continuous operation and information operating in little endian.

  The created test data 3 is output from the pseudo bus driver 4b for the CPU by the test bench 4a of the simulation model 4 of the system LSI. That is, the test data 3a is data output to the internal bus 4c.

  Then, according to the contents of the script to be tested described in script 1, verification of block 1 (4d-1) and block 2 (4d-2) is performed.

As described above, in this embodiment , test data is defined as a change in each signal with respect to the clock of the internal bus, a rough operation is described in the script, and converted into each signal with respect to the clock of the internal bus by the conversion tool. . Thereby, it is possible to save labor for creating test data used for verification of the designed system LSI.

  Further, since only a rough operation is described in the script, the same function of a system LSI having a different CPU can be verified using the same script by changing the conversion tool.

  Further, it is not always necessary to describe the test pattern information and the control data information in one script, and the test data may be created by combining two or more scripts. If only the test pattern is to be used, the control data portion may be created separately.

  The content of the data bus when the R / W of the test data is read is notified to the test bench. And when the numerical value is described in the test data, it is checked on the test bench. The checking function may be provided not in the test bench but in the CPU pseudo bus driver.

Embodiment 2. FIG.
In the present embodiment, an example in which a conversion tool that holds an architecture correspondence table is used will be described based on the configuration of the first embodiment.

  FIG. 3 is a diagram illustrating a system configuration example according to the second embodiment. In this embodiment, test data is created by a conversion tool that holds architecture correspondence tables for different CPUs. As a result, the script shown in the first embodiment can be used for function verification of a system LSI incorporating a CPU having a different bus width.

  In the figure, 1 is a script corresponding to a different CPU, 102 is a conversion tool for converting a script corresponding to a different CPU into test data, 102a is an architecture correspondence table for corresponding to a different CPU, 103 is test data, and 103a is The test pattern portion of the test data for verifying the test target, 103b is the control data of the test bench portion for controlling the test target, 104 is the configuration of the simulation model of the system LSI, 104a is the test bench portion used for the simulation model, 104b Is a pseudo bus driver for the CPU used for the simulation model, 104c is an internal bus of the system LSI connecting the pseudo bus driver for the CPU and the test object, 104d is the test object in the simulation model, 1 104d-2 from 4d-1, each block portion being tested, 104e denotes a control signal group to be tested to control the test pattern and control data.

  The configuration of the test data 103 of the CPU and the simulation model 104 of the system LSI of the CPU is the same as the configuration of the test data 3 and the simulation model 4 in the first embodiment.

  FIG. 4 is a diagram illustrating an example of the architecture correspondence table 102a. The architecture correspondence table 102a is roughly divided into a CPU part correspondence table 102a-1 and a block part correspondence table 102a-2. Further, the block part correspondence table 102a-2 is further divided in detail to correspond to each block of the test target 104d of the system LSI. The block 1 part correspondence table 102a-2_1 corresponds to block 1 (104d-1) of the test object 104, and the block 2 part correspondence table 102a-2_2 corresponds to block 2 (104d-2) of the test object 104. An example of the setting contents described in each correspondence table is shown in the figure.

FIG. 5 is a diagram illustrating an example of the test pattern 103a according to the second embodiment.
In the figure, 103a-1 is a clock synchronized with the internal bus 104c, 103a-2 is an address value output to the internal bus 104c, 103a-3 is a data value output to the internal bus 104c, and 103a-4 is an internal value. The control signal of the bus 104c is shown.

  Next, the operation will be described. If script 1 has a description of writing 4 bytes of data 0x04030201 at address 0x8000, test tool 103a and control data 103b of test data 103 are created by conversion tool 102.

  In the architecture correspondence table 102a, the CPU of the system LSI outputs two clocks of the address 103a-2 with respect to the clock 103a-1, outputs two clocks of the data 103a-3 at the same timing as the address 103a-2, and the R / W 103a. -4 also holds timing information indicating that two clocks are output at the same timing as that of the address 3a-2, information operating in little endian, and the like. Then, the conversion tool 102 creates test data 103 according to the contents of this architecture correspondence table 102a.

  The created test data 103 is output from the CPU pseudo bus driver 104b by the test bench 104a of the simulation model 104 of the system LSI. That is, the test data 103a is data output to the internal bus 104c.

  Then, verification of block 1 (104d-1) and block 2 (104d-2) is performed in accordance with the content of the test target script described in script 1.

  As described above, when converting the rough operation described in the script into the test data of the change of each signal with respect to the clock of the internal bus, prepare the conversion table of the system LSI architecture correspondence table corresponding to different CPUs. Thus, conversion becomes easy and verification by diversion of the script can be performed.

Embodiment 3 FIG.
In the present embodiment, a description method of commands used for scripts corresponding to different CPUs shown in the second embodiment will be described.

  FIG. 6 is a diagram showing a list of commands used for the script. In this example, an example of a command character string and argument contents is shown, but a configuration other than this example may be used.

  In the check argument of the script command, a confirmation function name indicating the sequence and signal level specified in the architecture correspondence table 102a, and a logical level state (true / false) corresponding to the confirmation function name can be described.

  In the wait argument of the script command, the confirmation function name indicating the sequence and signal level specified in the architecture correspondence table 102a and the waiting time that can be waited until the state indicated by the confirmation function name can be described.

  In the drive argument of the script command, the control function name indicating the sequence and signal level specified in the architecture correspondence table 102a and the control state (true / false) of the logic level corresponding to the control function name can be described.

  The argument of the script command delay can describe a control function name indicating the sequence and signal level specified in the architecture correspondence table 102a, and a delay time with respect to a clock synchronized with the internal bus corresponding to the control function name.

  In the copy argument of the script command, the name of the copy source and the name of the copy destination specified in the architecture correspondence table 102a and the number of copy bytes can be described. In addition, a file name or a direct numerical value can be designated as the copy source name. A file name can also be specified as the copy destination name.

  In the add_sig argument of the script command, the monitoring condition, the number of monitoring times, and the specified operation specified in the architecture correspondence table 102a can be described.

  The ext_sig_chk argument of the script command corresponds to the confirmation signal in which an LSI-specific signal name is assigned to each bit in the binary display specified in the architecture correspondence table 102a and the bit position of the confirmation signal. It is possible to describe the logic (true / false) of a signal when determining a signal name unique to an LSI.

  The ext_sig_dly argument of the script command includes a control signal in which an LSI-specific signal name is assigned to each bit specified in the binary table specified in the architecture correspondence table 102a, and an internal bus for the specified numerical value. It is possible to describe the specification of the delay time for designating the delay of the clock synchronized with the internal bus by the designation of the synchronized clock or the character string described in the architecture correspondence table 102.

  The ext_sig_drv argument of the script command includes a control signal in which an LSI-specific signal name is assigned to each bit in binary display specified in the architecture correspondence table 102a, and a signal for driving the control signal. Logic (true / false) can be described.

  The ext_sig_add argument of the script command specifies the monitoring condition specified by the character string specified in the architecture correspondence table 102a and the monitoring for the specified numerical value or the number of times specified by the character string described in the architecture correspondence table 102 Number of monitoring to be performed, a control signal in which a signal name unique to the LSI is assigned to each bit in the binary display specified in the architecture correspondence table 102a, and logic (true / false) of the signal when driving the control signal The number of inserted clocks corresponding to the number of clocks synchronized with the internal bus can be described by the designated numerical value or the character string described in the architecture correspondence table 102.

  Next, the operation will be described. The conversion tool generates test patterns (3a, 103a) and control data (3b, 103b) of the test data (3, 103) from the commands described in the script.

  check is a script command for generating test data belonging to the control data. From the architecture correspondence table, the conversion tool creates test data for confirming the signal sequence and signal level corresponding to the confirmation function name specified by this command on the test bench (4a, 104a). The processing for the state indicated by this command is the content described in the architecture correspondence table.

  “wait” is a script command for generating test data belonging to the control data. The conversion tool creates test data for designating the time that can be waited on the test bench from the architecture correspondence table until the signal sequence and signal level corresponding to the confirmation function name designated by this command are reached. The waiting time indicated by this command and the processing after the waiting time have elapsed are the contents described in the architecture correspondence table.

  “drive” is a script command for generating test data belonging to the test pattern. The conversion tool creates a signal sequence and signal level test data corresponding to the control function name and control state specified by this command from the architecture correspondence table.

  “delay” is a script command for generating test data belonging to the test pattern. The conversion tool creates test data according to the architecture using the control function name and delay time specified by this command from the architecture correspondence table.

  copy is a script command for generating test data belonging to a test pattern. The conversion tool creates test data according to the architecture from the architecture correspondence table, using the copy source name and copy destination name specified by this command, and the number of copy bytes. The test data in which this command is expanded will reflect the data bus width, endian, and address space used in the architecture correspondence table. For example, as shown in FIGS. 2 and 5, when the same script can be used to verify the same function, the test data will be different if the bus width and CPU write sequence are different. This can be diverted by describing and sharing the script with a copy of the script, and absorbing different CPU portions with the conversion tool. Also, by describing the copy source data in a separate file, it is easy to verify the same function with a combination of a plurality of data.

  add_sig is a script command for generating test data belonging to the test pattern. When the conversion tool finds add_sig described before the copy command, it uses the monitoring condition specified by this command, the number of monitoring times, and the specified operation from the architecture correspondence table. Create test data with specified actions inserted.

  Ext_sig_chk is a script command for generating test data belonging to the control data. When the conversion tool determines a confirmation signal in which an LSI-specific signal name is assigned to each bit in the binary display shown in the architecture correspondence table, and an LSI-specific signal name corresponding to the bit position of the confirmation signal Test data for confirming the logic (true / false) of the signal on the test bench is created. The processing for the state indicated by this command is the content described in the architecture correspondence table.

  Ext_sig_dly is a script command for generating test data belonging to a test pattern. The conversion tool uses the specified numerical value or the character string described in the architecture correspondence table for the control signal in which the LSI specific signal name is assigned to each bit in the binary display designated in the architecture correspondence table. Create test data by delaying the delay time of the clock synchronized with the specified internal bus. In the architecture correspondence table, the designation of whether or not to continue processing with an error at the time of the conversion tool or disregarding the processing for the signal having no signal name corresponding to each bit is described.

  Ext_sig_drv is a script command for generating test data belonging to the test pattern. The conversion tool uses the logic of the signal at the time of driving the designated control signal for the control signal in which the signal name unique to the LSI is assigned to each bit in the binary display designated in the architecture correspondence table. Test data to be driven by (true / false) is created. In the architecture correspondence table, in the case of a signal for which there is no signal name corresponding to each bit, designation is made as to whether or not the conversion tool process is continued as an error or ignored.

  Ext_sig_add is a script command for generating test data belonging to the test pattern. When the conversion tool finds Ext_sig_add described before the process in which a repetitive operation such as copy is performed, the monitoring condition specified by the character string specified in the architecture correspondence table and the specified numerical value are described in the architecture correspondence table. Check the number of times of monitoring that specifies the number of times of monitoring by specifying the character string, and specify the control signal to which an LSI-specific signal name is assigned to each bit in the binary display specified in the architecture correspondence table The number of inserted clocks corresponding to the number of clocks synchronized with the internal bus specified by the specified numerical value or the character string described in the architecture correspondence table is repeated according to the logic (true / false) of the driving control signal. Create test data inserted between them. In the architecture correspondence table, in the case of a signal for which there is no signal name corresponding to each bit, designation is made as to whether or not the conversion tool process is continued as an error or ignored.

  As described above, by defining a script command, it is possible to describe the script including LSI-specific signals in the system LSIs of different CPUs. When the conversion tool converts the test data of the change of each signal with respect to the clock of the internal bus, the conversion to the processing specific to the system LSI of the different CPU can be performed by referring to the architecture correspondence table of the system LSI corresponding to the different CPU. It becomes easy. As a result, the script can be easily used.

Embodiment 4 FIG.
In the present embodiment, description examples of script commands corresponding to different CPUs shown in the third embodiment will be described.

  FIG. 7 is a diagram showing an example of a script described using the command of the present invention. In this example, an example of a command character string and argument contents is shown, but other examples may be used.

  In the drive argument of the script command, a control function name “BLK1_en” indicating the sequence and signal level specified in the architecture correspondence table 102a and a control state “enable” corresponding to the control function name are described. The add_sig argument of the script command satisfies the monitoring condition “4B_cyc_set” indicating the sequence and the number of occurrences specified in the architecture correspondence table 102a, the monitoring number “1time” for monitoring the occurrence of the monitoring conditions, and the monitoring condition and the number of times. The designated operation “BLK1_buf_en” is described. The copy argument of the script command includes a file name “BLK1_data_1” after the $ mark indicating the file and an address of the copy destination name indicated in the architecture correspondence table 102a, followed by “function1”. ", The number of copied bytes" 8 bytes "is described.

  FIG. 8 is a diagram showing the contents of the data file specified by the copy of the script command. In this example, it is described that there are two pieces of 32-bit data, the first is “0x01020304”, and the second is “0x05060708”.

  FIG. 9 is a diagram showing an example of test data in the fourth embodiment. This test data is created by using the conversion tool having the architecture correspondence table for the script of FIG. 7 and the data file of FIG. In the architecture correspondence table used, the data bus width is 8 bits, the endian is little endian, the write operation uses 4 clocks, the address is output with a delay of 1 clock from the top clock, and the data is delayed by 2 clocks from the top clock. A setting is described in which the output R / W signal during the write operation is output with a delay of one clock from the leading clock. In addition, in the case of continuous write operations, a setting is described in which the leading clock portion of the R / W signal is affected by the previous operation, and the R / W signal during the write operation is not converted from write.

  The BLK1_en signal is driven without depending on the clock. The BLK1_Buf signal is a signal that completes the enable operation in 3 clocks, and is a signal that is enabled only for 1 clock with a delay of 1 clock from the leading clock.

  FIG. 10 is a diagram showing another description example of test data. This test data is also created by using the conversion tool having the architecture correspondence table for the script of FIG. 7 and the data file of FIG.

  The data is mainly composed of four parts, the clock is shown at the head, the address is followed by the data, and the control data is shown at the end. In the control data, each bit corresponds to a signal. In the figure, the control signal is represented by 32 bits, the BLK1_en signal is assigned to the lowest 0th bit (LSB), the BLK1_Buf signal is assigned to the 4th bit, and the R / W signal is assigned to the 16th bit (LSB).

  Next, the operation will be described. The operation of the script shown in FIG. 7 is to first write “BLK1_en” signal to enable and then write 32-bit data to the address of function1 twice. Then, verification is shown in which the operation of enabling the “BLK1_Buf” signal is performed every time 4 bytes are written. By converting this script with a conversion tool, the data of FIGS. 9 and 10 can be created.

  The contents of FIGS. 9 and 10 are substantially the same. The figure shows the change of each signal with respect to the bus clock. Since the data is 32 bits and the bus is 8-bit little endian, it is developed into a sequence in which lower data is stored at lower addresses. The BLK1_Buf signal is validated every 4 bytes of processing.

  As described above, by using the command of the defined script, it becomes possible to describe the script including the LSI-specific signal in the system LSI of a different CPU. When the conversion tool converts the test data of the change of each signal with respect to the clock of the internal bus, the test data can be easily described by converting according to the architecture correspondence table of the system LSI corresponding to the different CPU. In addition, since the signal conversion corresponding to the clock has a large amount of data and is monotonous, mistakes are likely to occur if created manually, which also helps to prevent human error. As a result, good quality scripts can be easily created.

  Note that the data structure of the test data in FIG. 10 does not have to be four blocks, and this example shows that it is composed of one or more data. In addition, the clock is not necessarily required data, and one line may be defined as one clock, and the description may be omitted.

Embodiment 5 FIG.
In the present embodiment, an example will be described in which the address is modified by the description of the copy of the script command corresponding to the different CPU shown in the third embodiment.

  FIG. 11 is a diagram illustrating an example of a script in which address modification is described using a command copy. In this example, the character string of the command and the argument contents are shown, but other examples are possible.

  The copy argument of the script command indicates that the address is the name of the copy source indicated by the architecture correspondence table 102a in parentheses, and “buf_add1” after the & mark is indicated by the architecture correspondence table 102a. "Function1" and the number of copied bytes "2 bytes" are described after the & mark indicating the address of the copy destination name.

  FIG. 12 is a diagram illustrating an example of test data in the fifth embodiment. This test data is created from the script of FIG. 11 using a conversion tool having an architecture correspondence table. In the architecture correspondence table used, the data bus width is 8 bits, the endian is little endian, and 4 clocks are used for both read / write operations. The address is output with a delay of 1 clock from the top clock, and the data is 2 clocks from the top clock. A setting is described in which the output is delayed and the R / W signal is output with a delay of one clock from the leading clock. In the architecture correspondence table 102a, “buf_add1” indicates an address of 0x4000, and “function1” indicates an address of 0x2000.

  The BLK1_en signal is driven without depending on the clock. The Buf_en signal is a signal that completes the enable operation in 3 clocks, and is a signal that is enabled for only 1 clock with a delay of 1 clock from the top clock.

  The address register “r_ad” built in the CPU pseudo bus driver 104b is composed of 32 bits, and in the case of 8-bit units, “r_ad (LL)”, “r_ad (LH)”, “r_ad (HL) in order from the lower order. "R_ad (HH)", in the 16-bit unit, "r_ad (L)" and "r_ad (H)" are displayed in order from the lower order, and in the 32-bit unit, "r_ad" is displayed. A register that temporarily holds bus data built in the pseudo bus driver 104e for CPU is indicated as "reg_data".

  FIG. 13 is a diagram illustrating another description example of test data according to the fifth embodiment. FIG. 12 shows another description method of test data created by using the conversion tool having the architecture correspondence table for the script of FIG.

  The data is mainly composed of four parts, the clock is shown at the head, the address is followed by the data, and the control data is shown at the end. In the control data, each bit corresponds to a signal. In this example, the control signal is indicated by 32 bits, the BLK1_en signal is assigned to the lowest 0th bit (LSB), the BLK1_buf signal is assigned to the 4th bit, and the R / W signal is assigned to the 16th bit (LSB).

  In the architecture correspondence table 102a, “buf_add1” indicates an address of 0x4000, and “function1” indicates an address of 0x2000. The address register “r_ad” built in the CPU pseudo bus driver 104b is composed of 32 bits, and in the case of 8-bit units, “r_ad (LL)”, “r_ad (LH)”, “r_ad (HL) in order from the lower order. "R_ad (HH)", in the 16-bit unit, "r_ad (L)" and "r_ad (H)" are displayed in order from the lower order, and in the 32-bit unit, "r_ad" is displayed. A register that temporarily holds bus data built in the pseudo bus driver 104b for CPU is indicated as "reg_data".

  Next, the operation will be described. The script shown in FIG. 11 indicates that, as an operation, the address value of buf_add1, which is a description part of address modification, is first read, and the read address value data is read by 2 bytes and written to the address of function1.

  The test data of FIG. 12 converted from FIG. 11 by the conversion tool is first read 32 bits of address data 4 times in units of 8 bits from 0x4000 of the address value of buf_add1, which is a description part of address modification. • Store in the driver address register. Next, 8-bit data is read from the address stored in the CPU pseudo bus driver address register and stored in the CPU pseudo bus driver data register. Then, it is written in the address value 0x2000 of function1 that is the copy destination. Since the number of copy bytes of the copy command is 2 bytes, 8-bit data is read from the address value added by +1 to the address stored in the address register of the CPU pseudo bus driver, and the CPU bus driver data is read. Store in register. Then, it is written in 0x2001 by adding +1 to the address value of function1 which is a copy destination.

  FIG. 13 shows test data converted into a format different from that in FIG. 12, and the contents of FIG. 12 and FIG. 13 are substantially the same.

  As described above, by incorporating the address register and data register in the CPU pseudo bus driver, data transfer between blocks to be tested and the memory built in the CPU pseudo bus driver Verification using spatial data becomes possible.

  The script in FIG. 11 can be described in any way other than the display method shown in the figure. In this example, the CPU pseudo bus driver has built-in address registers and data registers. However, an address space for data retention is prepared and used for data retention instead of registers. Also good. The number of data holding registers is not necessarily one, and a plurality of registers may be prepared.

  There are no problems with the number of bytes of the clock, address, data, and control data shown in FIG. 13 other than the number of bytes described. Moreover, there is no problem even if it is described in bit units without being bound by the unit of bytes.

Embodiment 6 FIG.
In the present embodiment, a description example of the architecture correspondence table used for the script according to the fourth embodiment will be described.

  FIG. 14 is a diagram illustrating an example of the CPU part correspondence table of the architecture correspondence table. This table is used to convert the script of FIG. 7 into the test data of FIG. FIG. 15 shows an example of a block part correspondence table. In this figure, an example described in one file is shown, but it may be divided into a plurality of files or other than this example.

  At the top of FIG. 14, “parts = CPU” indicating the described part, “system_bus = 8 bit” indicating the bus width, “Endian = little” indicating endian, and “Address = 32 bit” indicating the bit width of the address. Is described. Then, an operation sequence portion surrounded by “Bus_sig” is described as a portion indicating the bus operation.

  Inside “Bus_sig”, “mono-write” indicating a sequence at the time of single writing, “burst-write” indicating a sequence at the time of continuous writing, and “mono-read” indicating a sequence at the time of single reading “Burst-read” indicating a sequence at the time of single reading is described. For details of the single write sequence “mono-write”, the numerical value “4” immediately after “mono-write” indicates the number of clocks of the sequence, and “add” in the address signal operation sequence and “ It shows that “rw” in the operation sequence of “data” and R / W signals is controlled. Each signal has input / output and operation sequence information.

  In “add” of the single write sequence “mono-write”, the operation sequence of 4 clocks changes from invalid to valid to valid to valid after “o” indicating an output signal to the bus. “0111” indicating this is described. At this time, when the output of the bus changes due to the previous operation, as shown in the operation sequence of 4 clocks of “rw” of the operation sequence of the R / W signal of “burst-write” indicating the sequence at the time of continuous writing, Write “x”.

The control signal part is enclosed in “Ctrl_sig”, the signal name “BLK1_en”, the input / output is “o”, and the number of operation clocks is “0”. The logic level “en” and the signal logic level “dis” when invalid are set.
In “Address” indicating the address of the memory space, the start address “0x4000” of the name “buf_add1” and the continuous area “32 bytes” are described.

  At the top of FIG. 15, “parts = Block1” indicating the described part is described, and “int_condition” indicating the interrupt operation sequence and state is an interrupt generation factor setting condition “set” and an interrupt generation condition “condition” , An interrupt release condition “reset” is described.

  The address “address” described in the example of the CPU correspondence table of the architecture correspondence table of FIG. 14 indicates the start address “0x2000” and the occupied area “8 kbytes” in FIG.

  As the memory map information of the block 1, the used address “func_reg” as a register has an address space “16 bytes” continuous with the leading address “0x2100”, and the used address “func_buf” as a buffer has a leading address “0x2000”. The continuous address space “32 bytes” and the bus specification “func_bus” in the block describe a bus width “8 bits” and an endian “liter”.

  An operation sequence part enclosed by “Bus_sig” is described as a part indicating the operation of the bus. The description is the same as in FIG. 14, but the block is mainly a slave to the bus, so the input / output description is the reverse of FIG.

  The control signal part is enclosed in “Ctrl_sig” and described in the same description method as in FIG. 14, but the notation differs depending on whether only the input / output part is input or the block itself outputs.

  FIG. 16 is a diagram showing an example of the CPU part correspondence table of the architecture correspondence table having different bus widths and operation sequences. The description method is the same as in FIG.

  FIG. 17 is an example of the block part correspondence table connected to the CPU part correspondence table (FIG. 16) of the architecture correspondence table having different bus widths and operation sequences. The description method is the same as in FIG.

  Next, the operation will be described. When the script shown in FIG. 7 is converted into test data by using a conversion tool using the architecture correspondence table having the contents shown in FIGS. 14 and 15, FIG. 9 and FIG. 10 are obtained.

  The operation of the script shown in FIG. 7 is to drive “BLK1_en”, write 32 bytes of data twice to the address indicated by function1, and output “BLK1_buf” every time 4 bytes are written.

  Therefore, when converted according to the description of FIGS. 14 and 15, the data bus is 8 bits, the write operation sequence is 4 clocks, and the operation sequence of “BLK1_buf” is 3 clocks. It becomes FIG.

  On the other hand, when the script shown in FIG. 7 is converted into test data using a conversion tool using the architecture correspondence tables shown in FIGS. 16 and 17, the results shown in FIGS. 18 and 19 are obtained.

  This is because, when converted according to the description of FIG. 16 and FIG. 17, the data bus is 16 bits, the write operation sequence is 3 clocks, and the operation sequence of “BLK1_buf” is 3 clocks, so that different test data can be generated.

  Since these functions are substantially the same, they are effective test data as test data for verifying the same function.

As described above, functions and memory map that is configuration information in the architecture correspondence table, the bus width, endian by providing an operation sequence for the clock of the signal as waveform information, the arrangement of the C PU change or address space It will be possible to respond to changes.

  The architecture correspondence tables in FIG. 14 to FIG. 17 have no problem as long as they can hold information at the time of creating test data, even if the description is not in the notation method shown in the figure. Further, although a character string is used here, there is no problem even if it is a description of only a numerical value corresponding to a line or binary data corresponding to a relative address.

Embodiment 7 FIG.
In the present embodiment, a description example for an LSI specific signal using a script command corresponding to a different CPU shown in the third embodiment will be described.

FIG. 20 is a diagram illustrating a description example of a command for confirming an LSI-specific signal. In the figure, the first argument of the command is 16 bits and a signal is assigned to each bit, and the second argument is also 16 bits and the logical condition at the time of signal confirmation is assigned to each bit.
The meaning of each bit is shown in the “LSI specific signal correspondence table” in FIG.

  Next, the operation will be described. The first argument in FIG. 20 is indicated by 16 bits, and a signal is assigned to each bit. When the signal is set to “1”, the signal is confirmed. The number of bits indicating the first argument and the second argument is the same, and the logical condition at the time of confirmation is indicated for the bits at the same position. The argument in the figure is 16 bits, but it is not necessary to fix 16 bits, and it can be expanded according to the number of signals used. In addition, since a plurality of signals and signal logical conditions can be specified at one time here, the LSI inherent signal portion and the signal condition portion have the same number of bits. There is no problem even if the combination is determined and specified by a numerical value or a character string.

As described above, the LSI unique signal that specified in the script command, by allocating a bit, changed or C PU, it becomes possible diverted to correspond to the arrangement change of the address space.

  In addition, by adding a function to display an error when an incompatible specific signal is generated in the conversion tool, it is possible to check the leakage of information written in the architecture correspondence table at the time of diversion.

If you are no longer using the LSI unique signal which has been conventionally used, so as to ignore that described architecture correspondence table, it allows the creation of test data to continue verifying without confirmation.

Embodiment 8 FIG.
In the simulation model of the system LSI that uses scripts corresponding to different CPUs shown in the second embodiment, only a pseudo bus driver for CPU including the function of the test bench will be described.

  FIG. 21 is a diagram illustrating a system configuration example according to the eighth embodiment. In the figure, 1 is a script corresponding to a different CPU, 102 is a conversion tool for converting a script corresponding to a different CPU into test data, 102a is an architecture correspondence table for corresponding to a different CPU, 103 is test data, and 103a is Test pattern portion of test data for verifying the test target, 103b is control data of the test bench portion for controlling the test target, 204 is a system LSI simulation model configuration, 204c is a CPU pseudo bus driver and test target 204d is a test target in the simulation model, 204d-1 to 204d-2 are block parts to be tested, 204e is a control signal group to be tested controlled by a test pattern or control data, 204f It shows a pseudo-bus driver for the CPU to be used in the simulation model that includes a test bench function to be used in the simulation model.

  Next, the operation will be described. The test data created in the same manner as in the second embodiment is given to the CPU pseudo bus driver 204f having a test bench function. The CPU pseudo bus driver with the test bench function reads the test data and outputs it to the internal bus of the system LSI, or the data on the internal bus of the system LSI and the control signal group to be tested Determine whether. If it is determined that the data is to be output to the internal bus of the system LSI, the data is output to the internal bus of the system LSI. In the case of data such as data confirmation, control signal output, and signal change waiting as functions as a test bench, the system bus is operated according to the command. For example, in the case of a simple wait without driving a signal, only the clock is operated.

  As described above, by incorporating the test bench function in the pseudo bus driver for CPU, it is not necessary to specially create a function for passing data at the time of the bus reading operation to the test bench.

  In this example, the function of the test bench is built in the pseudo bus driver for CPU. Conversely, there is no problem if the function of the pseudo bus driver for CPU is built in the test bench.

  In this way, by using a pseudo bus driver for the CPU with the test bench function, the same function can be realized more easily than when the test bench and the pseudo bus driver for the CPU are created separately. it can. Also, by verifying various combinations of test targets with a CPU pseudo bus driver having the function of a single test bench, the labor for creating a verification environment can be simplified.

Embodiment 9 FIG.
In the system LSI simulation model using scripts corresponding to different CPUs shown in the eighth embodiment, a description will be given of a method for describing control data of test data created using a conversion tool.

  FIG. 22 is a diagram illustrating an example of a script according to the ninth embodiment. The script is described using scripts corresponding to different CPUs shown in the third embodiment. In the drive argument of the script command, the control function name “BLK1_en” indicating the sequence and signal level specified in the architecture correspondence table 102a and the control state “enable” corresponding to the control function name are described. The add_sig argument includes the monitoring condition “4B_cyc_set” indicating the sequence and the number of occurrences specified in the architecture correspondence table 102a, the monitoring number “1time” for monitoring the occurrence of the monitoring condition, and the monitoring condition and the number of times The designated operation “BLK1_buf_en” is described, and the copy argument of the script command includes the $ mark indicating the file followed by the file name “BLK1_data_2” of the data file and the address of the copy destination name indicated in the architecture correspondence table 102a. "Function1" after the show and mark, describes the byte number of "8byte" of the copy.

  FIG. 23 shows the contents of the data file specified by the copy of the script command. The data describes that there are two 32-bit data, the first is “0x01020304”, and the second is “0x05060708”.

  FIG. 24 is a diagram illustrating an example of a control data portion of test data. In this example, the script of FIG. 22 and the data file of FIG. 23 are created using a conversion tool having an architecture correspondence table. “Exec # 0000, # 0038” indicates the clock range of the test pattern output to the internal bus in the converted test pattern, and “wait 0x0001 0x0001” indicates the operation as the test bench after the test pattern is output.

  Next, the operation will be described. When verification is performed using a simulation model of a system LSI, a script is converted by a conversion tool, and a test pattern of test data and control data are created. In order to perform verification, control data is input to a pseudo bus driver for CPU having a test bench function. The test bench function unit analyzes the control data, executes clocks # 0000 to # 0038 of the test pattern, and then waits 15 clocks for the function indicated by the bit position of the confirmation function name to become effective. .

  As described above, by using scripts corresponding to different CPUs, the test data is divided into the test pattern part and the control data part with the conversion tool, and the change of the signal is confirmed in the middle of the continuous test pattern. Can do.

  Note that the test data does not necessarily have to be two, and may be composed of only one or three or more.

Embodiment 10 FIG.
A description will be given of a method for describing test data created using a conversion tool in a mixed manner with test patterns and control data in a simulation model of a system LSI that uses scripts corresponding to different CPUs shown in the eighth embodiment. .

  FIG. 25 shows test data created from the scripts corresponding to the different CPUs of FIG. 22 and the data of FIG. The portion surrounded by the upper dotted line is the test pattern portion, and the portion surrounded by the lower dotted line is the control data portion.

  Next, the operation will be described. When verification is performed using a system LSI simulation model, test data is created using a script conversion tool. In order to perform verification, test data is input to a pseudo bus driver for CPU having a test bench function. The test bench function unit analyzes the test data and executes clocks # 0000 to # 0038 of “#” indicating the test pattern portion, and then confirms that the function indicated by the bit position of the confirmation function name is valid. Wait for 15 clocks.

  As described above, the same operation as in the ninth embodiment can be performed with the information of one file. This facilitates management of test data during logic verification.

  In addition, since the clock notation can be omitted by using one file, the file size of the test data can be made smaller than before when the test data pattern increases or the test data situation increases.

  A test data creation apparatus including a script storage unit, a conversion tool, and a test data storage unit can execute processing by a program as a computer. Further, the program can be stored in a storage medium so that the computer can read the program from the storage medium.

  It is also conceivable to convert test data corresponding to a specific CPU into a script for a different CPU using a conversion tool.

1 is a diagram illustrating an example of a system configuration in a first embodiment. It is a figure which shows the example of the test pattern 3a. 6 is a diagram illustrating a system configuration example in a second embodiment. FIG. It is a figure which shows the example of the architecture correspondence table 102a. 6 is a diagram illustrating an example of a test pattern 103a in Embodiment 2. FIG. It is a figure which shows the list of the commands used for a script. FIG. 20 is a diagram illustrating an example of a script in the fourth embodiment. It is a figure which shows the content of the data file designated by copy of the command of the script. FIG. 10 is a diagram showing an example of test data in the fourth embodiment. FIG. 20 is a diagram illustrating another description example of test data in the fourth embodiment. It is a figure which shows the example of the script which described address modification using copy of command. FIG. 16 is a diagram showing an example of test data in the fifth embodiment. FIG. 20 is a diagram illustrating another description example of test data in the fifth embodiment. It is a figure which shows the example of the CPU part correspondence table of an architecture correspondence table. It is a figure which shows the example of a block part corresponding table. It is a figure which shows the example of the CPU part corresponding | compatible table of the architecture corresponding | compatible table from which a bus width and an operation sequence differ. It is a figure which shows the example of the block part correspondence table connected to CPU part correspondence table (FIG. 16). FIG. 20 is a diagram showing an example of test data in the sixth embodiment. FIG. 20 is a diagram illustrating another description example of test data in the sixth embodiment. It is a figure which shows the example of a description of the command for confirming the signal intrinsic | native to LSI. FIG. 20 is a diagram illustrating a system configuration example according to an eighth embodiment. 209 is a diagram illustrating an example of a script in Embodiment 9. [FIG. It is a figure which shows the example of the data file designated by copy. It is a figure which shows the example of the control data part of test data. FIG. 38 is a diagram showing an example of test data in the tenth embodiment.

Explanation of symbols

  1 Script, 2 Conversion tool, 3 Test data, 3a Test pattern part, 3b Control data, 4 Simulation model, 4a Test bench part, 4b CPU pseudo bus driver, 4c Internal bus, 4d Test target, 4d- 1 block 1, 4d-2 block 2, 4e control signal group, 102 conversion tool, 102a architecture correspondence table, 103 test data, 103a test pattern part, 103b control data, 104 simulation model, 104a test bench part, 104b for CPU Pseudo bus driver, 104c internal bus, 104d test target, 104d-1 block 1, 104d-2 block 2, 104e control signal group, 204 simulation model, 204c internal bus, 204 Tested, 204d-1 block 1,204d-2 block 2,204e control signal group, pseudo bus driver 204f CPU.

Claims (3)

CPU A test data creation apparatus that creates test data to verify the operation of the LSI incorporating a (central processing unit) section (large scale integrated circuit),
CPU unit architecture correspondence table for storing CPU unit specifications having CPU unit system bus operation timing information and memory space addresses, which are used to create test data for operating the CPU unit. When,
Input script for command to input / output data, refer to memory space address in CPU part architecture correspondence table, create test pattern with address and data in correspondence with clock, and support CPU part architecture A conversion tool that refers to the operation timing information in the table, creates control data corresponding to the operation sequence of the system bus in correspondence with the clock, and outputs the test pattern and control data as test data for executing the above command.
Test data generation apparatus characterized by comprising a. The CPU part architecture correspondence table stores a plurality of CPU part architecture correspondence tables corresponding to a plurality of types of CPU parts having different CPU specifications,
The conversion tool creates test data using a CPU part architecture correspondence table corresponding to a CPU part built in an LSI whose operation is verified from among a plurality of CPU part architecture correspondence tables.
The test data creating apparatus according to claim 1, wherein: The LSI further includes one or more block portions,
The test data creation device further stores memory map information of the block portion and operation sequence information indicating an operation sequence of the bus in the block portion corresponding to each block portion of the one or more block portions. With a block part architecture correspondence table,
The above conversion tool inputs a script describing a command for inputting / outputting data to / from the block part, refers to the memory map information of the block part in the block part architecture correspondence table, and uses a test pattern having an address and data as a clock. Create the data corresponding to the operation sequence information in the block part architecture correspondence table, and create the control data corresponding to the operation sequence of the bus in the block corresponding to the clock.
The test data creation device according to claim 1 or 2, wherein

Images