JP2010039678A - Design support program, design support device, and design support method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce a design period by increasing the speed of design at an early stage. <P>SOLUTION: An architecture 100 is divided by domain. The division is performed in a bus system or/and a clock system. An arbitrary domain is selected among the divided domains 101, 102. The domain 101, for example, is selected. An ESL simulation is performed on the domain 101, and the domain is replaced to a traffic generation device G which generates a traffic equivalent to that of the domain 101. The traffic generation device G and the domain 102 which is not replaced are combined to obtain a new architecture 110. The evaluation result 120 is obtained by performing an ESL simulation again to the new architecture 110. Thereby, the speed of ESL simulation can be increased. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a design support program, a design support apparatus, and a design support method for obtaining an optimum architecture configuration when searching for a system architecture.

  In recent years, a design technique by simulation at the time of development of a system LSI (Large Scale Integration) has been advanced. This technology is mainly called ESL (Electronic System Level) technology, and is a high-speed simulation technology in system upstream process design in which the design of a system LSI is designed while changing the detail (abstraction) at each stage. On the other hand, in a configuration with a low level of abstraction, the processing speed is slow, but it is used at the stage of detailed hardware design close to the actual hardware logic (see, for example, Patent Documents 1 and 2 below).

  In the ESL technology, high-speed operation can be performed by appropriately skipping and concealing detailed clock operations. It is used as a simulation environment capable of operating software by linking with an instruction simulator of a CPU (Central Processing Unit), and is applied to development of a large-scale system LSI such as a SoC (System on a Chip).

  Using this technology, the behavior of the entire system is determined at the initial stage of development, and detailed operations are performed in a later process. The designer can describe the hardware with block diagram configuration level information at the upstream development stage. When hardware is expressed by simulations used in ESL, etc., hardware can be expressed by hardware description using SystemC and XML (Extensible Markup Language) scripts, so that it is possible to easily evaluate the system configuration. . These hardware expressions are similar to general software programs.

  Further, ESL is used as a simulation environment capable of operating software by linking with an instruction simulator of a CPU, and is applied to development of a large-scale system LSI such as SoC. Furthermore, as a technique for speeding up the simulation, a back door model technique that ignores bus and memory access timing and focuses only on execution of a CPU instruction set has been proposed.

  Using these technologies, the behavior of the entire system is determined at the initial stage of development, and detailed operations are performed in a later process. The designer can describe the hardware with block diagram configuration level information at the upstream development stage. When hardware is expressed by simulation used in ESL or the like, hardware description by SystemC and XML (Extensible Markup Language) script is applied. Thereby, since hardware can be expressed in a programmable manner, it is possible to easily perform evaluation with the system configuration changed. In addition, these hardware expressions are similar to general software programs.

  Using the above technology, simulations using actual design models such as RTL (Register Transfer Level), which were implemented at speeds that are several millionths of real time, have been accelerated to several thousandths. Is possible.

Japanese Patent Laid-Open No. 2001-22808 JP 2003-67438 A

  However, in the above-described conventional technology, even in ESL in which a detailed operation trend is omitted by omitting the detailed operation of a transaction or paralleling with an instruction level simulation, a simulation is performed when an analysis system is enlarged. There has been a problem that a phenomenon occurs in which time increases exponentially.

  In addition, when the scale exceeds a certain level, the same problems as the execution time constraint and the execution environment resource constraint in the RTL simulation occur, and it is suitable for performing a rough operation analysis at the upstream design level where the original implementation is desired. There was a problem that no case would occur.

  An object of the present invention is to provide a design support program, a design support apparatus, and a design support method that can shorten the design period in order to solve the above-described problems caused by the prior art.

  In order to solve the above-described problems and achieve the object, the design support program, the design support apparatus, and the design support method evaluate a selected domain selected from a domain group divided into domains from the architecture to be designed. Performing an ESL simulation on the software, generating a single traffic generator that generates traffic equivalent to the traffic of the selected domain based on the execution results, and replacing the selected domain with the generated traffic generator To reconstruct the architecture and output the reconstructed architecture.

  According to the design support program, the design support apparatus, and the design support method, there is an effect that the design period can be shortened.

  Exemplary embodiments of a design support program, a design support apparatus, and a design support method will be described below in detail with reference to the accompanying drawings.

(Outline of this embodiment)
FIG. 1 is an explanatory diagram showing an outline of design support according to the present embodiment. The architecture 100 to be designed is divided into domains. Domain division is performed by a bus system or / and a clock system. Next, an arbitrary domain is selected from the divided domains 101 and 102. Here, it is assumed that the domain 101 is selected. An ESL simulation is executed for the domain 101, and the result is replaced with a traffic generator G that generates traffic equivalent to the traffic of the domain 101.

  While the domain 101 is a set of a plurality of hardware blocks A, B, X, Y, and M, the traffic generator G is a single hardware block. The traffic generator G generates traffic equivalent to the traffic of the domain 101 that is the replacement source, and is unaware of the type of data and the content of the data in the traffic.

  Thereafter, the traffic generator G and the domain 102 that has not been replaced are combined to obtain the replaced architecture 110. An evaluation result 120 is obtained by executing the ESL simulation again for the architecture 110 after the replacement. As a result, high-speed ESL simulation is realized.

(Hardware configuration of design support device)
FIG. 2 is a block diagram showing a hardware configuration of the design support apparatus according to the present embodiment. In FIG. 2, the design support apparatus includes a CPU (Central Processing Unit) 201, a ROM (Read-Only Memory) 202, a RAM (Random Access Memory) 203, a magnetic disk drive 204, a magnetic disk 205, and an optical disk drive. (Flexible Disk Drive) 206, optical disk 207, display 208, I / F (Interface) 209, keyboard 210, mouse 211, scanner 212, and printer 213. Each component is connected by a bus 200.

  Here, the CPU 201 governs overall control of the design support apparatus. The ROM 202 stores a program such as a boot program. The RAM 203 is used as a work area for the CPU 201. The magnetic disk drive 204 controls reading / writing of data with respect to the magnetic disk 205 according to the control of the CPU 201. The magnetic disk 205 stores data written under the control of the magnetic disk drive 204.

  The optical disk drive 206 controls reading / writing of data with respect to the optical disk 207 according to the control of the CPU 201. The optical disk 207 stores data written under the control of the optical disk drive 206, or causes the computer to read data stored on the optical disk 207.

  The display 208 displays data such as a document, an image, and function information as well as a cursor, an icon, or a tool box. As the display 208, for example, a CRT, a TFT liquid crystal display, a plasma display, or the like can be adopted.

  An interface (hereinafter abbreviated as “I / F”) 209 is connected to a network 214 such as a LAN (Local Area Network), a WAN (Wide Area Network), and the Internet through a communication line. Connected to other devices. The I / F 209 controls an internal interface with the network 214 and controls data input / output from an external device. For example, a modem or a LAN adapter may be employed as the I / F 209.

  The keyboard 210 includes keys for inputting characters, numbers, various instructions, and the like, and inputs data. Moreover, a touch panel type input pad or a numeric keypad may be used. The mouse 211 performs cursor movement, range selection, window movement, size change, and the like. A trackball or a joystick may be used as long as they have the same function as a pointing device.

  The scanner 212 optically reads an image and takes in the image data into the design support apparatus. The scanner 212 may have an OCR (Optical Character Reader) function. The printer 213 prints image data and document data. As the printer 213, for example, a laser printer or an ink jet printer can be employed.

(Functional configuration of design support device)
FIG. 3 is a block diagram showing a functional configuration of the design support apparatus according to the present embodiment. The design support apparatus 300 includes an acquisition unit 301, a division unit 302, an execution unit 303, an execution control unit 304, a generation unit 305, a reconstruction unit 306, and an output unit 307. Specifically, the functions (acquisition unit 301 to output unit 307) serving as the control unit are, for example, a program stored in a storage area such as the ROM 202, RAM 203, magnetic disk 205, and optical disk 207 shown in FIG. The function is realized by executing the function or by the I / F 209.

  The acquisition unit 301 has a function of acquiring hardware model information, connection information between hardware models, and evaluation software. Specifically, for example, hardware model information and connection information are read from the storage area or received from the outside. The acquired information is described in SystemC, state description language (XML), or the like.

  FIG. 4 is an explanatory diagram showing hardware model information. The hardware model information 400 is a set of source codes of hardware models constituting the architecture. Here, as an example, source codes of peripherals X, Y, and Z and shared resources M and N are shown.

  FIG. 5 is a block diagram showing an architecture to be designed. FIG. 5 shows an architecture to which the hardware model information 400 shown in FIG. 4 is applied. In the architecture 500 shown in FIG. 5, since connection information of buses and clocks is not given, peripherals X, Y, Z, shared resources M, N, buses, bridges (thick arrows in the figure), and clock supply blocks ( It is only expressed that a block including a waveform diagram) is included.

  FIG. 6 is an explanatory diagram showing connection information, and FIG. 7 is a block configuration diagram showing an architecture to which connection information is given. Reference numeral 601 is connection information of the bus A, reference numeral 602 is connection information of the bus C, and reference numeral 603 is connection information of the bridge B. These pieces of connection information 601 to 603 are referred to as bus system connection information 600. Reference numerals 611 to 614 denote connection information of the clock supply blocks P to S. These pieces of connection information 611 to 614 are referred to as clock system connection information 610.

  In the following description, the clock supply block code is used as the clock code from the clock supply block. For example, the clock P is supplied from the clock supply block P. It should be noted that the hardware model source code can be blocked by an existing structural analysis. Hereinafter, the blocked hardware model is referred to as a hardware block.

  Evaluation software is a benchmark program that causes an architecture to execute. When the evaluation software is not the source code but the design information of the evaluation software, alternative software that generates an assumed load may be used. The target design in this embodiment is an upstream process, the input information itself includes ambiguity, and the obtained result is also a design phase that allows ambiguity to obtain a rough result. Therefore, the problem of using alternative software, error, and accuracy are considered acceptable.

  The dividing unit 302 has a function of dividing the architecture 100 into domains based on the connection information acquired by the acquiring unit 301. Specifically, for example, the architecture 100 is divided into domains based on commonality of buses connecting between hardware models obtained from connection information and commonality of clocks supplied to the hardware models.

  Here, domain division by the dividing unit 302 will be described in detail. In the case of the architecture 100 shown in FIG. 7, the connection state can be obtained by analyzing the connection model description source to the bus. This analysis can be executed, for example, using a technique such as incorporation into an XML parser or Lint (source code inspection program) in a compiler.

  FIG. 8 is an explanatory diagram showing a connection analysis result of the architecture 100 shown in FIG. In the architecture 100 of FIG. 7, the connection analysis result 800 belongs to the group of the bus A because the peripherals X and Y and the shared resource M are connected to the bus A. Since the peripheral Z and the shared resource N are connected to the bus C, they belong to the group of the bus C.

  On the other hand, the clock supply block P supplies the clock P to the peripheral X of the bus group A. The clock supply block Q supplies the clock Q to the shared resource M of the bus group A. The clock supply block R supplies the clock R to the peripheral Y of the bus group A and the peripheral Z of the bus group C. The clock supply block S supplies the clock R to the shared resource N of the bus group C.

  Accordingly, since the peripheral X and the shared resource M are both connected to the bus A, they are classified into the domain Da. Peripherals Y and Z are connected to buses A and C, respectively, but are supplied with the same clock R. Therefore, the hardware configuration of the architecture of FIG. 7 cannot be classified by the commonality of the bus and clock. In such a case, an instruction level ESL simulation related to the evaluation software is performed, and classification is performed again using the execution result.

  FIG. 9 is an explanatory diagram showing a source code group of evaluation software. In the source code group 900, the evaluation software 901 is a benchmark program executed by the architecture 100. Source codes 902 to 904 indicate hardware operations and connection destinations in the evaluation software 901. “Driver X”, “Driver Y”, and “Driver Z” correspond to the peripherals X to Z, respectively. For example, the source code 902 describes that the Driver X (peripheral X) accesses the shared resources M and N.

  The execution unit 303 has a function of executing an ESL simulation related to the evaluation software 901. The execution unit 303 executes an ESL simulation related to the evaluation software 901 by a method specified by the execution control unit 304 described later.

  The execution control unit 304 has a function of controlling the execution unit 303 to execute an ESL simulation related to the evaluation software 901 for a selected domain selected from the divided domain group. Specifically, for example, an instruction level ESL simulation related to the evaluation software 901 is executed for the architecture 100.

  Here, an instruction level ESL simulation will be described. The instruction level ESL simulation is usually used for debugging by executing trace of the evaluation software 901 and is not normally used for evaluating the architecture 100. However, in this embodiment, only the traffic load generated by the architecture 100 is used. To do. By executing the instruction level ESL simulation, the amount of data traffic from the hardware model to the hardware model is revealed.

  In this execution result, a collision phenomenon that occurs due to a plurality of access timings such as the buses A and C and the shared resources M and N cannot be obtained. The instruction level ESL simulation is an ESL simulation based on a backdoor model, and is executed using at least one clock.

  FIG. 10 is an explanatory diagram showing an ESL simulation of the evaluation software 901 in the architecture. In FIG. 10, the arrows on the bus indicate data dependency relationships between hardware blocks. This ESL simulation is a simulation of one clock system. That is, the clocks P to S are ESL simulations based on a backdoor model in which the clocks P to S are not considered (therefore, the symbols of the clocks P to S are not attached in FIG. 10).

  11 and 12 are explanatory diagrams showing the execution results of the instruction level ESL simulation shown in FIG. Based on this execution result, the peripherals Y and Z whose classification has ended indefinitely in FIG. 8 are classified.

  In the execution result 1100 illustrated in FIG. 11, the peripheral Y stores data of 100 [MB] as the access data amount in the shared resource M, and stores data of 10 [MB] in the shared resource N. . Therefore, since the data dependency ratio to the shared resource M is higher, the peripheral Y is classified into the bus A group. Similarly, the peripheral Z stores data of 0 [MB] as an access data amount in the shared resource M, and stores data of 100 [MB] in the shared resource N. Therefore, since the data dependency ratio to the shared resource N is higher, the peripheral Z is classified into the bus C group.

  In the execution result 1200 shown in FIG. 12, the peripheral Y stores 10 [MB] of data as the access data amount in the shared resource M, and stores 100 [MB] of data in the shared resource N. . Therefore, since the data dependency ratio to the shared resource N is higher, the peripheral Y is classified into the group of the bus C. Similarly, the peripheral Z stores data of 0 [MB] as an access data amount in the shared resource M, and stores data of 100 [MB] in the shared resource N. Therefore, since the data dependency ratio to the shared resource N is higher, the peripheral Z is also classified into the group of the bus C.

  As described above, when the classification cannot be performed by the hardware configuration, the classification is performed based on the execution result of the evaluation software 901, particularly the height of the data dependency ratio. By classifying according to the height of the data dependence ratio, when executing the ESL simulation, it is possible to reduce the data access across the blocks and avoid the deterioration of the evaluation accuracy.

  In addition, by reducing the data access data straddling the blocks, when the domain is replaced with the traffic generator G in the next phase, it is possible to suppress the error when the traffic is simulated to the minimum necessary.

  13 and 14 are block configuration diagrams showing domain division results of the architecture 100. FIG. The domain division result in FIG. 13 is a division based on the classification determined by FIGS. 8 and 11. The domain Da1 has peripherals X and Y connected only to the bus A, shared resources M, and clock supply blocks P to R. The domain Dc1 has a peripheral Z, a shared resource N, and clock supply blocks R and S that are connected only to the bus C.

  The domain division result in FIG. 14 is a division based on the classification determined by FIGS. 8 and 12. The domain Da2 includes a peripheral X, a shared resource M, and clock supply blocks P and Q that are connected only to the bus A. The domain Dc2 includes peripherals Y and Z connected to the buses A and C, a shared resource N, and clock supply blocks P, R, and S.

  The execution control unit 304 executes a transaction level ESL simulation for a selected domain selected from the divided domain groups. As a result of this execution, the traffic generator G is generated.

  Returning to FIG. 3, the generation unit 305 has a function of generating a single traffic generator G that generates traffic equivalent to the traffic of the selected domain based on the execution result executed by the execution control unit 304. The traffic generator G is a single hardware block that replaces the corresponding domain. Therefore, since the domain is simplified, the ESL simulation time that increases depending on the number of hardware blocks can be shortened.

  The traffic generator G is a simulation hardware block that creates random data according to given parameters and applies a traffic load to the architecture. Further, an address space for inputting data and an address space for outputting data can be designated.

  Further, the traffic load of the data pattern of the replacement source domain is generated. Specifically, a clock with the same period as the bus to be connected is given, and the load is periodically loaded from the time of startup based on the traffic pattern called scenario data stored in advance along the clock. Can be given. The traffic generator G has a programmable area for generating scenario data, and has a mechanism for inputting a scenario generation program together with hardware blocks when replacing with a domain. Hereinafter, the traffic generator G will be described in detail.

  FIG. 15 is an explanatory diagram showing the traffic generator G. The traffic generator G has four interfaces. The slave terminal 1501 is an interface for inputting a command 1500 for simulating an alternative hardware block. The master terminal 1502 is an interface for processing an input command 1500 and generating desired traffic. The clock terminal 1503 is an interface that captures a basic period for operation. The interrupt terminal 1504 is an interface for reporting the operation status.

  A command 1500 is a sequence of parameters given to the scenario data, and includes an access pattern ap, an interval int, a period f, a data length 1, an access space addr, and an iteration count rpt.

  The command 1500 can be referred to as the register image 1511 from the outside. Since the alternative traffic to be expressed is expressed by a plurality of command strings, the traffic is stored in the command buffer 1512 so that these can be continuously input. The command sequence stored in the command buffer 1512 is sequentially read and output from the master terminal 1502 according to the clock CLK input from the clock terminal 1503 based on the scenario data 1513 prepared in advance.

  That is, it is output in the form of an access pattern ap having the number of iterations rpt for the access space addr specified by the command 1500. The unit access amount with respect to the total access amount corresponds to the packet size of the bus.

  FIG. 16 is an explanatory diagram showing scenario data. In FIG. 16, the scenario data is composed of virtual logic having no parameters of access pattern AP, interval INT, period F, data length L, access space ADDR, and number of repetitions RPT. The reason for selecting these as parameters is as follows.

  In the horizontal (H) direction, vertical (V) direction, and random (R) indicating the access pattern, the continuity of access is shown. In many hardware devices, especially memory devices, performance depends on whether they are consecutive addresses (continuous in the horizontal direction), periodically access to discrete spaces (continuous in the vertical direction), or random. It is known to be different. In actual circuit connection, if access to continuous space or access to space is periodic, latency due to paging switching does not occur by random access using a buffer or cache mechanism. This is because it can be accessed at higher speed.

  However, since the characteristics of the access destination device are unknown from the traffic generator G, only the characteristics indicating what access pattern the originally generated traffic had were extracted. The actual performance change is solved by extracting the characteristics of the connected device.

  The interval INT, the period F, the data length L, the access space ADDR, and the number of repetitions RPT are general expressions indicating temporal and spatial attributes for actual traffic. Hardware used in the ESL simulation of this embodiment is expressed in a description language such as SystemC. This has the same configuration as a software function, and when an operation is actually performed, a function for generating an ESL simulation is called.

  When an access pattern is read from the command buffer 1512 inside the traffic generator G, a function defined as scenario data is linked to a function corresponding to the access pattern shown in FIG. At this point, only a virtual circuit that generates only a pattern is connected. Subsequently, the interval int, the period f, the number of iterations rpt, and the access space addr read from the command buffer 1512 are read, and this parameter is passed as an argument to the linked function, whereby the designated address space ADDR is Traffic of the access data interval INT, period F, and number of repetitions RPT can be generated.

  FIG. 17 is an explanatory diagram of a method of generating an access pattern, a period, the number of repetitions, and an access space when replacing the actual data pattern with the traffic generator G. When actual access data is obtained by one ESL simulation, the simulator generates a detailed access log corresponding to the clock. In the verification evaluation targeted in the present embodiment, since the purpose is to verify not only the detailed data in clock units but also the performance generally shown in the mutual interference of multiple hardware blocks, the clock There is no need to follow detailed patterns in units.

  When the domain Da1 shown in FIG. 13 is replaced with a single traffic generator G, first, a periodic pattern is searched. In the strict periodic pattern search, a method of reading all the characteristics of the measurement interval is used, but in the phase in this embodiment, since it is a simulation to see a general tendency while allowing an error, There is no need to extract a precise periodic pattern. Therefore, the access waveform 1700 obtained by the first ESL simulation for the domain Da1 is divided by N cycle periods. n is a constant, the initial value determined empirically is 1000, and the value can be changed depending on the simulation environment.

  This is important for the analysis of the access pattern generated by each hardware block in the domain Da1 to be replaced. For example, in (A), when the waveform of the pattern is visually periodic, The period can be obtained by an existing mathematical algorithm, but it is difficult to obtain the period if it does not have a periodicity visually. On the other hand, finding the periodicity is not the main purpose of solving this problem. Therefore, for example, by setting n = 1000 as an initial value, the access pattern is simplified at that interval.

  In this way, the initial value of the period n is set to a constant (n = 1000) is a method for model quantification when the periodic pattern cannot be found visually. Whether or not there is a periodic pattern is determined based on a case where an appropriate mathematical value is not obtained by using an existing mathematical method. Then, one pattern when divided by n cycles is averaged. One access unit for the interval averaging is the transfer packet unit of the connection destination. For example, in the case of performing 32-bit access, the unit is 4 bytes, and in the case of 64-bit access, the unit is 8 bytes.

  For example, in FIG. 17A, if all accesses are 1600 bits (200 bytes) and the connection destination is a unit of 32 bits (4 bytes), a simulation obtained by the traffic generator G in FIG. A waveform 1800 is obtained by averaging the total access amount. Since the period n, which is a section, is 1000 cycles, a 4-byte access is sent 50 times in a cycle of 20 cycles. Therefore, 4 bytes are transferred in one cycle and an interval of 19 cycles is provided. As shown in (C), the traffic at this time has a data length L = 4, an interval INT = 19, a period F = 20, and a repetition count RPT = 50.

  In this way, simulated waveforms are generated for the patterns of all the sections, and these values are sequentially given to the traffic generator G as the command 1500, so that the replaced traffic generator G has been originally present in the domain Da1. The data access load (traffic) can be expressed.

  Hereinafter, a specific operation example of the traffic generator G will be described. The output waveform from the domain Da1 is measured by the first ESL simulation for the domain Da1 by the execution control unit 304. An access waveform 1700 in FIG. In FIG. 17, since a periodic pattern is shown instead of a random waveform, the period can be obtained by the existing mathematical algorithm described above.

  The black portion of the access waveform obtained in FIG. 17 is a set of points through which data has actually passed. Regardless of the specific data contents, the access of other hardware blocks is affected by the passage of data, that is, the access load generated from the hardware block to be replaced.

  Actually, three types of clocks P to R are introduced, which is a data access load generated as a result of arbitration. However, if only the access waveform 1700 is viewed, it is just one load band, and the access load can be simplified by schematically representing this band.

  It is assumed that the traffic generator G has the following registers. The register does not need to have the following configuration, and the form can be changed according to the mounting environment.

CTL: Control register A control command 1500 is set in the traffic generator G.
0x00: Control stop 0x01: Start of execution 0x02: Command 1500 input mode

DPR: Data pattern register This specifies how one load pattern accesses.
0x00: Continuous for specified STAR / SBAR / DTAR / DBAR 0x01: Intermittent for specified STAR / SBAR / DATR / DBAR 0x02: Random intermittent data for specified STAR / SBAR / DATR / DBAR In the case of, specify the interval of intermittent data in the upper bits.
If the lower bit is other than 0x01, the upper bit is ignored.

TWR: Traffic wise register Specifies the amount of access to one load pattern as a real number.

ITR: Interval time register The sense of one load pattern is specified by a real number.

RTR: Repeat time register Specifies how many times a pattern is repeated.

STAR: Source top address register (start address of replacement source address space)
SBAR: Source bottom address register (last address of replacement source address space)
DTAR: Destination top address register (first address in the address space other than the replacement destination)
DBAR: Destination bottom address register (last address in the address space other than the replacement destination)

BUF: Command buffer 1512 (buffer for describing the above pattern)
By writing to the registers, they are stacked in order. At the time of execution, FIFO (First-In First-Out) is read.

The traffic generator G in the experimental environment operates with the following specifications.
1. The input mode of the command 1500 is changed to the control register CTL.
2. The value given to each register is described in order in the command buffer BUF.
3. The control register CTL is set to the execution mode.

  The traffic generator G has a programmable area for generating a scenario, and has a mechanism for inputting a scenario generation program together with the hardware block when replacing the actual hardware block. In order to easily express the description of the program in the traffic generator G having the specifications as described in the above 1 to 3, an assembler-like description is given. When “Set XXX, YYY” is described, it means that “XXX” is set to “YYY”. “#” Is a comment line.

Set CTL, 00 # Stop Set CTL, 02 # Command 1500 input mode Set Buf, 00 # Generates a pattern for continuous access.
Set Buf, 04 # Access with data length L = 4. Assigned to the traffic-wise register TWR at runtime.
# Autoincrement Set Buf, 19 # Interval time 19. It is substituted into the interval time register ITR at the time of execution.
# Auto-increment Set Buf, 255 # 255 iterations. Assigned to the repeat time register RTR at the time of execution.
Set Buf, 0xff00 # Peripheral X, Y address space. Assigned to the source top address register STAR when executed
# Auto-increment Set Buf, 0xffff # Peripheral X, Y address space. Assigned to the source bottom address register SBAR at the time of execution.
# Auto-increment Set Buf, 0x0000 # Address space other than peripherals X and Y. It is substituted into the destination top address register DTAR at the time of execution.
# Autoincrement Set Buf, 0x00ff # Address space other than peripherals X and Y. It is substituted into the destination bottom address register DBAR at the time of execution.
# Auto-increment Set CTL, 01 # Start execution

  By starting the execution, the instructions stacked in the Buf are sequentially read, and the actual traffic is generated by reading the values into the respective registers. This is an example of reproducing one pattern. However, in the case where the period of one pattern is once and the access width and interval are different each time, as in the case of periodic random access, it corresponds to “Set Buf”. You can repeat the sentence you want as many times as you want.

  FIG. 18 is an explanatory diagram showing a simulation waveform for the domain Da1. This simulation waveform is measured at bridge B. FIG. 19 is an explanatory diagram showing a comparison between a simulation waveform for the domain Da1 and a traffic waveform from the traffic generator G.

  (A1) is a waveform of actual overall traffic, (A2) is a waveform indicating access other than the replaced hardware block to be measured, and (A3) is a waveform indicating actual access. (B1) is a waveform of the entire traffic affected by the traffic generator G, (B2) is a waveform indicating access other than the replaced block to be measured, and (B3) is generated by the traffic generator G. It is a waveform which shows load.

  In this way, it can be observed that the access affected by the measurement to be measured is affected by the traffic generator G in the same manner as the load caused by the actual peripherals X and Y. As a result, the ESL simulation time can be further shortened by consolidating and simplifying the three processing systems into one.

  Returning to FIG. 3, the reconstruction unit 306 has a function of reconstructing the architecture by replacing the selected domain with the traffic generator G. Specifically, for example, the architecture is reconstructed by combining a traffic generator G and a non-selected domain specific to each selected domain.

  FIG. 20 is an explanatory diagram showing the reconstruction of the architecture. By replacing the domain Da1 (FIG. 13) of the architecture before the reconstruction with the traffic generator Ga1, the architecture 110 after the reconstruction is obtained. The execution control unit 304 obtains the evaluation result 120 shown in FIG. 1 by executing a transaction level ESL simulation for the architecture 110 after the reconstruction.

  Returning to FIG. 3, the output unit 307 has a function of outputting the reconstructed architecture 110 and the evaluation result 120. Output formats include display on a display, transmission to the outside, and writing to a storage area.

(Comparison of ESL simulation time)
FIG. 21 is a graph showing a comparison of ESL simulation times. The horizontal axis is the simulation model, and the vertical axis is the execution time (logarithm). The backdoor model is a result of performing an ESL simulation using a minimum of one system clock necessary for executing the evaluation software 901. The clock system is added as it goes to the right of the graph, and the execution time increases exponentially with this increase.

  In other words, when there are multiple clock-dependent hardware blocks, if there are multiple clock systems, the time within the simulation will also have a time-series result, and if the clock systems are different, synchronization within the simulation will occur. Therefore, the amount of processing increases.

  In the reconstruction of FIG. 20, before the reconstruction, ESL simulation of four clock systems (P to S) and eight types of hardware blocks (X, Y, Z, M, N, A, B, and C) is performed. Will be executed. When converted based on the actual transaction level ESL simulation time in FIG. 21, the execution time is in the order of 10 to the power of 3.5.

  After the reconstruction in FIG. 20, one instruction level simulation for the domain Da1, three system clocks (P, R, S) and five hardware blocks (G, Z, N, B, C) transaction levels This simulation is executed once. When converted based on the ESL simulation time of FIG. 21, an execution time of the order of 10 to the third power is sufficient.

  In this embodiment, since the data traffic pattern is calculated in the execution of the evaluation software 901, the execution corresponding to the back door in FIG. 21 is executed only once. The time required for this execution is at most 10 Is the first power of. Therefore, in this embodiment, the ESL simulation time can be greatly shortened.

(Design support processing procedure)
FIG. 22 is a flowchart showing a design support processing procedure by the design support apparatus according to this embodiment. In FIG. 22, information acquisition processing (step S2201), domain division processing (step S2202), traffic generator G generation processing (step S2203), and architecture reconstruction processing (step S2204) are executed in this order.

  In the information acquisition process (step S2201), the hardware model information shown in FIG. 4, the connection information shown in FIG. 6, and the evaluation software 901 shown in FIG. 9 are acquired. Thereafter, an ESL simulation of the cycle model is executed for the reconstructed architecture (step S2205). Then, the execution result is output (step S2206). Thereby, a series of design support processing ends.

  FIG. 23 is a flowchart showing a detailed processing procedure of the domain division processing (step S2202). First, it is determined whether there is a hardware connection analysis result (step S2301). On the other hand, when there is not (step S2301: No), a structural analysis is performed (step S2302). Then, dependency analysis between hardware blocks is performed (step S2303), and the process returns to step S2301.

  In step S2301, if there is a hardware connection analysis result (step S2301: Yes), it is determined whether there is an ESL execution result (step S2304). If there is not (step S2304: No), an ESL simulation based on the back door model is executed (step S2305), and the process returns to step S2301. If there is an ESL execution result (step S2304: YES), domain division is executed (step S2306). And it transfers to a traffic generator production | generation process (step S2203).

  FIG. 24 is a flowchart showing a detailed processing procedure of the traffic generator generation process (step S2203). First, the evaluation target domain is extracted from the divided domain group (step S2401). The extracted domain may be a domain designated by the designer or all domains.

  Then, it is determined whether or not there is an unprocessed evaluation target domain (step S2402). When there is an unprocessed evaluation target domain (step S2402: Yes), one unprocessed evaluation target domain is selected (step S2403), and an ESL simulation is performed using a cycle model (step S2404). That is, a transaction level ESL simulation is executed.

  Based on the execution result, a traffic generator G equivalent to the traffic in the evaluation target domain is generated (step S2405), and the process returns to step S2402. In step S2402, when there is no unprocessed evaluation target domain (step S2402: No), the process proceeds to the architecture reconstruction process (step S2204).

  FIG. 25 is a flowchart showing a detailed processing procedure of the architecture restructuring process (step S2204). First, a non-evaluation target domain is extracted (step S2501). In the example of FIG. 13, the domain Dc1 is extracted. Then, the traffic generator G unique to the evaluation target domain and the non-evaluation target domain are combined (step S2502). As shown in FIG. 20, the traffic generator Ga1 unique to the domain Da1 and the domain Dc1 are combined to obtain a reconstructed architecture.

  As described above, according to the present embodiment, a part or all of the domain divided from the architecture to be designed is replaced with the traffic generator G that generates traffic equivalent to the traffic of the domain. Can be simplified. As a result, the ESL simulation speed in the upstream design can be increased by executing the transaction level ESL simulation for the simplified architecture. Therefore, the design period can be shortened.

  The design support method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. This program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer. The program may be a medium that can be distributed through a network such as the Internet.

  The following additional notes are disclosed with respect to the embodiment described above.

(Appendix 1) Computer
Execution means for executing ESL simulation on evaluation software;
Execution control means for controlling the execution means to execute an ESL simulation related to the evaluation software for a selected domain selected from a domain group divided from the architecture to be designed;
Generating means for generating a single traffic generator for generating traffic equivalent to the traffic of the selected domain based on the execution result executed by the execution control means;
Reconstructing means for reconstructing the architecture by replacing the selected domain with a traffic generator generated by the generating means;
Output means for outputting the architecture reconstructed by the restructuring means;
Design support program characterized by functioning as

(Appendix 2)
Obtaining means for obtaining connection information between hardware models constituting the architecture;
Based on the connection information acquired by the acquisition means, function as a dividing means for dividing the architecture into domains,
The execution control means includes
The design support program according to appendix 1, wherein the execution means is controlled to execute an ESL simulation related to the evaluation software for a selected domain selected from the domain group divided by the dividing means.

(Supplementary Note 3) The dividing means includes
The design support program according to appendix 2, wherein the architecture is divided into domains based on commonality of buses connecting the hardware models obtained from the connection information.

(Supplementary Note 4) The dividing means includes:
The design support program according to appendix 2 or 3, wherein the architecture is divided into domains based on commonality of clocks supplied to the hardware model obtained from the connection information.

(Supplementary Note 5) The execution control means includes:
Controlling the execution means to execute an instruction level ESL simulation for the evaluation software for the architecture;
The dividing means includes
The architecture according to any one of appendices 2 to 4, wherein the architecture is divided into domains based on a data dependency amount between the hardware models obtained by an instruction level ESL simulation for the evaluation software. Design support program.

(Appendix 6) The execution control means includes:
When there is an indeterminate hardware model that cannot be classified into any of the domains by the dividing means, the execution means is controlled to execute an instruction level ESL simulation for the evaluation software for the architecture;
The dividing means includes
The architecture according to any one of appendices 2 to 4, wherein the architecture is divided into domains based on a data dependency amount between the hardware models obtained by an instruction level ESL simulation for the evaluation software. Design support program.

(Appendix 7) The execution control means includes:
Controlling the execution means to execute an ESL simulation for the evaluation software for the reconstructed architecture;
The output means includes
The design support program according to any one of appendices 1 to 6, wherein an execution result of an ESL simulation related to the evaluation software executed for the reconstructed architecture is output.

(Supplementary Note 8) Execution means for executing ESL simulation related to evaluation software;
Execution control means for controlling the execution means to execute an ESL simulation related to the evaluation software for a selected domain selected from among a group of domains divided from the architecture to be designed;
Generating means for generating a single traffic generator for generating traffic equivalent to the traffic of the selected domain based on the execution result executed by the execution control means;
Reconstructing means for reconstructing the architecture by replacing the selected domain with a traffic generator generated by the generating means;
Output means for outputting the architecture reconstructed by the restructuring means;
A design support apparatus comprising:

(Supplementary note 9)
An execution step of executing an ESL simulation related to the evaluation software for a selected domain selected from a group of domains divided into domains from the architecture to be designed;
A generating step of generating a single traffic generator that generates traffic equivalent to the traffic of the selected domain based on the execution result executed by the executing step;
A rebuilding step of rebuilding the architecture by replacing the selected domain with a traffic generator generated by the generating step;
An output step of outputting the architecture reconstructed by the restructuring step;
A design support method characterized by executing

It is explanatory drawing which shows the outline | summary of the design support concerning this Embodiment. It is a block diagram which shows the hardware constitutions of the design support apparatus concerning this Embodiment. It is a block diagram which shows the functional structure of the design assistance apparatus concerning this Embodiment. It is explanatory drawing which shows hardware model information. It is a block block diagram which shows the architecture used as a design object. It is explanatory drawing which shows connection information. It is a block block diagram which shows the architecture to which connection information was given. It is explanatory drawing which shows the connection analysis result of the architecture shown in FIG. It is explanatory drawing which shows the source code group of evaluation software. It is explanatory drawing which shows the ESL simulation of the evaluation software in an architecture. It is explanatory drawing which shows the execution result (the 1) of the ESL simulation of the instruction level shown in FIG. It is explanatory drawing which shows the execution result (the 2) of the instruction level ESL simulation shown in FIG. It is a block block diagram which shows the domain division | segmentation result (the 1) of an architecture. It is a block block diagram which shows the domain division | segmentation result (the 2) of an architecture. It is explanatory drawing which shows a traffic generator. It is explanatory drawing which shows scenario data. It is explanatory drawing of the system which produces | generates an access pattern, a period, the repetition frequency, and an access space at the time of replacing with a traffic generator from an actual data pattern. It is explanatory drawing which shows the simulation waveform about the domain Da1. It is explanatory drawing which shows the comparison with the simulation waveform about the domain Da1, and the traffic waveform from a traffic generator. It is explanatory drawing which shows the reconstruction of an architecture. It is a graph which shows the comparison of ESL simulation time. It is a flowchart which shows the design assistance processing procedure by the design assistance apparatus concerning this Embodiment. It is a flowchart which shows the detailed process sequence of a domain division | segmentation process (step S2202). It is a flowchart which shows the detailed process sequence of a traffic generator production | generation process (step S2403). It is a flowchart which shows the detailed process sequence of an architecture reconstruction process (step S2204).

Explanation of symbols

DESCRIPTION OF SYMBOLS 300 Design support apparatus 301 Acquisition part 302 Dividing part 303 Execution part 304 Execution control part 305 Generation part 306 Reconstruction part 307 Output part

Claims (5)

Computer
Execution means for executing ESL simulation on evaluation software;
Execution control means for controlling the execution means to execute an ESL simulation related to the evaluation software for a selected domain selected from a domain group divided from the architecture to be designed;
Generating means for generating a single traffic generator for generating traffic equivalent to the traffic of the selected domain based on the execution result executed by the execution control means;
Reconstructing means for reconstructing the architecture by replacing the selected domain with a traffic generator generated by the generating means;
Output means for outputting the architecture reconstructed by the restructuring means;
Design support program characterized by functioning as The computer,
Obtaining means for obtaining connection information between hardware models constituting the architecture;
Based on the connection information acquired by the acquisition means, function as a dividing means for dividing the architecture into domains,
The execution control means includes
The design support program according to claim 1, wherein the execution means is controlled to execute an ESL simulation related to the evaluation software for a selected domain selected from the domain group divided by the dividing means. The execution control means includes
Controlling the execution means to execute an instruction level ESL simulation for the evaluation software for the architecture;
The dividing means includes
3. The design support program according to claim 2, wherein the architecture is domain-divided based on a data dependence amount between the hardware models obtained by instruction level ESL simulation related to the evaluation software for the architecture. Execution means for executing an ESL simulation relating to the evaluation software;
Execution control means for controlling the execution means to execute an ESL simulation related to the evaluation software for a selected domain selected from among a group of domains divided from the architecture to be designed;
Generating means for generating a single traffic generator for generating traffic equivalent to the traffic of the selected domain based on the execution result executed by the execution control means;
Reconstructing means for reconstructing the architecture by replacing the selected domain with a traffic generator generated by the generating means;
Output means for outputting the architecture reconstructed by the restructuring means;
A design support apparatus comprising: Computer
An execution step of executing an ESL simulation related to the evaluation software for a selected domain selected from a group of domains divided into domains from the architecture to be designed;
A generating step of generating a single traffic generator that generates traffic equivalent to the traffic of the selected domain based on the execution result executed by the executing step;
A rebuilding step of rebuilding the architecture by replacing the selected domain with a traffic generator generated by the generating step;
An output step of outputting the architecture reconstructed by the restructuring step;
A design support method characterized by executing

Images