Evaluation device and storage medium storing evaluation program for system LSI

According to one embodiment, an evaluation device includes one or more processors. The one or more processors performs detecting a process of activating a hardware of a system LSI from an application, interrupting execution of the application when the process of activating the hardware is detected, setting, as a load, a memory access pattern of the hardware estimated by simulating performance of the hardware, adding the load to resume the execution of the application, and collecting a profile related to a memory access during the execution of the application, including the load when the execution of the application is resumed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority from the Japanese Patent Application No. 2019-055861, filed Mar. 25, 2019, the entire contents of which are incorporated herein by reference.

FIELD

Embodiments described herein relate generally to an evaluation device and a storage medium storing an evaluation program for a system LSI.

BACKGROUND

In order to rapidly develop a complicated system LSI, it is important to proceed with the study on the architecture of the system LSI and the study on applications in parallel and to start software development at an early stage. On the other hand, when evaluating system LSI for which addition of new functions is planned, hardware corresponding to the new functions has not been developed, and it is difficult to make a highly accurate evaluation.

DETAILED DESCRIPTION

In general, according to one embodiment, an evaluation device includes one or more processors. The one or more processors performs detecting a process of activating a hardware of a system LSI from an application, interrupting execution of the application when the process of activating the hardware is detected, setting, as a load, a memory access pattern of the hardware estimated by simulating performance of the hardware, adding the load to resume the execution of the application, and collecting a profile related to a memory access during the execution of the application, including the load when the execution of the application is resumed.

Hereinafter, embodiments will be described with reference to the drawings.FIG. 1is a block diagram illustrating a configuration of an evaluation system of a system LSI according to an embodiment. As illustrated inFIG. 1, an evaluation system1includes a system LSI2and a computer3. The system LSI2and the computer3are connected so as to be able to communicate. The communication may be performed by wire, or may be performed by wireless. In addition, a communication method is not particularly limited.

The system LSI2includes a processor21, a memory22, an interface23, and a hardware24. The processor21, the memory22, the interface23, and the hardware24are connected so as to be able to communicate with each other via a bus25.

The processor21is, for example, a central processing unit (CPU). The processor21controls various processes of the system LSI2. The processor21may be a multi-core processor configured by a plurality of CPUs and the like.

The memory22includes a random access memory (RAM) and a read only memory (ROM). The RAM is a readable and writable semiconductor memory. The RAM is a working memory configured to temporarily store various data used by the processor21, the hardware24, and the like. The ROM is a read only semiconductor memory. The ROM stores a program necessary for the operation of the system LSI2. This program includes an operating system (OS) and an application. In addition, the program includes a hypervisor. The hypervisor is a control program configured to operate directly on hardware. The OS operates on the hypervisor.

The interface23is an interface on the system LSI2side for communication between the system LSI2and the computer3. The interface23is, for example, a PCI. The interface23is not particularly limited.

The hardware24is a variety of hardware mounted on the system LSI2. The hardware24is not particularly limited. For example, a memory area for a control register is allocated to the memory22for each hardware mounted as the hardware24. For example, when there is a request for access to a memory area allocated to a specific hardware while the application is executed, a process for activating the corresponding hardware is performed. Note that, in the embodiment, a memory area for hardware not yet mounted on the system LSI2is also allocated.

The computer3is, for example, a personal computer. The computer3includes a processor31, a memory32, a storage33, and an interface34. The processor31, the memory32, the storage33, and the interface34are connected so as to be able to communicate with each other via a bus35.

The processor31is, for example, a CPU. As the processor31, a graphic processing unit (GPU) can also be used. The processor31controls various processes of the computer3. The processor31may be configured by a plurality of CPUs and the like.

The memory32includes a RAM. The RAM is a readable and writable semiconductor memory. The RAM is a working memory configured to temporarily store various data used by the processor31and the like.

The storage33is, for example, a hard disk. The storage33stores a program necessary for the operation of the computer3. This program includes an operating system (OS) and the like. In addition, the storage33stores a simulation model configured to simulate the performance of the hardware of the system LSI2.

The interface34is an interface on the computer3for communication between the system LSI2and the computer3. The interface34is, for example, a PCI. The interface34is not particularly limited.

FIG. 2is a functional block diagram of the evaluation system1. Here, bold arrows inFIG. 2indicate a request for hardware. In addition, thin arrows inFIG. 2indicate a request for software.

In the embodiment, the application201of the system LSI2operates under the control of the OS. The OS of the system LSI2is, for example, a real-time OS (RTOS)202. In addition, the application201includes not only a process (existing process)201ausing an existing hardware (HW)24athat is the hardware24already mounted on the system LSI2, but also a process (new process)201busing a virtual new hardware (HW)24bthat is a new hardware24to be mounted, which is virtually prepared in the system LSI2. In addition, the application201includes a profiler201cfor evaluating the system LSI. The profiler201ccollects a profile of the application201while referring to a hardware timer mounted as the hardware24. The profile of the application201includes, for example, a profile related to a memory access, such as a memory access bandwidth at the time of executing the application201, a memory access amount, a ratio of a calculation amount to a memory access amount (operation strength). As a method of the profiler201c, a sampling method, an entrance and exit monitoring method, and the like may be used. The profile collected by the profiler201ccan be analyzed by, for example, the hypervisor203. The profiler201cmay be in the hypervisor203.

On the other hand, virtualization of hardware for evaluating the system LSI2is performed under control of the hypervisor203. The hypervisor203operates directly on the hardware of the system LSI2including the processor21and the hardware24. The hypervisor203includes a memory access trap203a, a virtual hardware control register model203b, a virtual timer controller203c, and a virtual load controller203d. The hypervisor203performs operations as the memory access trap203a, the virtual hardware control register model203b, the virtual timer controller203c, and the virtual load controller203dby using the processor21and the like as necessary. That is, the hypervisor203operates as the evaluation device of the system LSI2.

When an access to a specific address of the memory22is detected by using a memory management unit (MMU) of the processor21, the memory access trap203atransfers the subsequent processes to the hypervisor203.

The virtual hardware control register model203bis a model configured to reproduce a process specific to each virtual hardware. The process specific to each virtual hardware includes, for example, an operation as a control register for each hardware and a process as a hardware when the control register is accessed.

The virtual timer controller203ccontrols virtual timers configured to be viewed by the application201and the RTOS202. As described above, the profiler201cof the application201basically collects the application profile while referring to the hardware timer. When the virtual timer controller203csets the virtual timer, the application201and the RTOS202refer to the virtual timer. For example, when the virtual timer controller203coperates the virtual timer so that the processing time performed on the hypervisor203is set to zero, the profile of the process performed on the hypervisor203is not collected by the profiler201c.

The virtual load controller203dis configured to apply a constant memory access load based on the simulation result of the hardware. The virtual load controller203dapplies a load by using a hardware for a memory access, such as a direct memory access controller (DMAC). The load may be applied by using a dedicated hardware configured to apply a load.

When the computer3receives a request from the hypervisor203, the computer3simulates the performance of the hardware by using the simulation model301. The simulation model301operates on the OS302. The simulation model301includes a performance reproduction unit301a, a memory access range determination unit301b, and a memory access pattern estimation unit301c. The simulation model301performs operations as the performance reproduction unit301a, the memory access range determination unit301b, and the memory access pattern estimation unit301cby using the processor31and the like as necessary.

The performance reproduction unit301areproduces the performance of the hardware24of the system LSI2by the virtual hardware. The performance reproduction unit301ais configured to be able to reproduce, for example, the performance of the virtual new hardware24b. Here, the performance of the hardware includes, for example, to read input information from the memory, to perform hardware-specific calculation, and to write the calculation result to the memory. In addition, the performance reproduction unit301amay be configured to be able to reproduce the performance of the existing hardware24a.

The memory access range determination unit301bdetermines, based on the set value to the virtual control register, which range of address the hardware reproducing the performance refers to so as to write or read.

The memory access pattern estimation unit301cestimates by what access pattern the actual hardware24accesses the memory. The memory access pattern includes, for example, a temporal change of a memory access bandwidth when it is assumed that the virtual hardware performs the memory access (write/read) as the actual hardware24, a temporal change of a memory access amount, and a total memory access amount within the time when the virtual hardware has performed the memory access as the actual hardware24.

Hereinafter, the operation of the evaluation system1will be described in detail.FIG. 3is a flowchart illustrating the flow of processing of the evaluation system1. The process ofFIG. 3is started when the application201is activated by the user so as to evaluate the system LSI2.

In step S1, when the application201is activated, the application201performs a process in accordance with a pre-programmed procedure. At this time, the profiler201cof the application201acquires a running profile of the application201.

Here, when it is necessary to activate the specific hardware, the application201issues the memory access to the control register allocated to the hardware. As described above, the control register includes a control register for the virtual new hardware24bnot yet mounted on the system LSI2. That is, when the new process201bis performed, the application201issues the memory access to the control register allocated to the virtual new hardware24b((1) ofFIG. 2).

In step S2, the hypervisor203determines, by using the memory access trap203a, whether the memory access to the specific hardware has been issued from the application201. Here, the specific hardware is, for example, the virtual new hardware24b. When it is determined in step S2that the memory access to the specific hardware has not been issued, the process proceeds to step S12. When it is determined in step S2that the memory access to the specific hardware has been issued, the process proceeds to step S3.

In step S3, the hypervisor203determines whether the memory access trapped by the memory access trap203ais an access for activating the hardware. The memory access to the hardware includes an access for setting the hardware and an access for activating the hardware. When it is determined in step S3that the memory access is not the access for activating the hardware, that is, when it is determined in step S3that the memory access is the access for setting the hardware, the process proceeds to step S4. When it is determined in step S3that the memory access is the access for activating the hardware, the process proceeds to step S5.

In step S4, the hypervisor203receives the memory access issued from the application201. Then, the hypervisor203updates the setting of the virtual new hardware24bcorresponding to the new hardware set in the virtual hardware control register model203bin response to the request from the application201((2) ofFIG. 2). After that, the process proceeds to step S12.

When it is determined in step S3that the memory access is the access for activating the hardware, in step S5, the hypervisor203simulates a response based on the virtual hardware control register model203bby outputting the setting of the virtual new hardware24bset in the virtual hardware control register model203bwith respect to the application201((3) ofFIG. 2). In subsequent step S6, the hypervisor203stops the operation of a processor other than the processor used by the hypervisor203itself. For example, the hypervisor203uses a cross trigger to stop the operation of another processor ((4) ofFIG. 2). Therefore, the application201is stopped.

In step S7, the hypervisor203requests the simulation model301for simulation by transmitting the contents set in the virtual hardware control register model203bto the simulation model301of the computer3((5) ofFIG. 2).

In step S8, the hypervisor203determines whether the simulation result has been transmitted from the simulation model301. In step S8, the hypervisor203waits for process until it is determined that the simulation result has been transmitted from the simulation model301. When the simulation result has been transmitted from the simulation model301in step S8, the process proceeds to step S9.

In step S8, while the hypervisor203is waiting for the process, the simulation model301simulates the performance of the hardware based on the contents set in the virtual hardware control register model203b.

Specifically, in the simulation model301, the memory access range determination unit301bspecifies a memory block to be referred to for simulating the performance of the hardware. Then, the simulation model301copies the specified memory block to the RAM of the memory32.

After that, the performance reproduction unit301aof the simulation model301simulates the performance of the hardware. The simulation result is written to the copied memory block in the memory32.

After that, the simulation model301reads the rewritten memory block in the memory32and writes the same to the memory22. At this time, the memory access pattern estimation unit301cof the simulation model301estimates the memory access pattern. After that, the simulation model301transmits the estimated memory access pattern to the hypervisor203as the simulation result.

Here, it returns to the description ofFIG. 3. In step S9after the simulation result is transmitted from the simulation model301((6) ofFIG. 2), the virtual load controller203dof the hypervisor203sets the access pattern estimated by the simulation model301as a virtual load. For example, the strength of the virtual load can be acquired by dividing the total memory access amount of virtual hardware by the time when virtual hardware virtually accesses the memory.

In step S10, the hypervisor203releases the cross trigger to resume the process by another processor ((7) ofFIG. 2). Therefore, the application201resumes the process. At the same time, the hypervisor203actually applies the load set as the virtual load to the bus25. For example, the hypervisor203issues a dummy memory access by using the DMAC to apply the load to the bus25((8) ofFIG. 2). Furthermore, the virtual timer controller203cof the hypervisor203sets the virtual timer to zero, thereby eliminating the time required for the simulation measured by the timer of the hardware24((9) ofFIG. 2). After the virtual load is applied, the hypervisor203notifies the application201that the process of the virtual new hardware24bhas been completed ((10) ofFIG. 2). After that, the process proceeds to step S11.

In step S11, the hypervisor203virtually receives an interrupt at the time of completing the execution of the virtual load. Therefore, the interrupt is reproduced from the virtual hardware.

In step S12, the application201determines whether the process has been completed. When it is determined in step S12that the process has not been completed, the process returns to step S1. When it is determined in step S12that the process has been completed, the process ofFIG. 3is ended.

FIGS. 4A and 4Bare diagrams for describing the effect of the embodiment.FIG. 4Ais a diagram illustrating an example of operations of the processor21and the hardware24assumed in the application201.FIG. 4Bis a diagram illustrating an example of operations of the processor21and the hardware24according to an embodiment. The bar graphs ofFIGS. 4A and 4Billustrate the progress of the operations of the processor21and the hardware24over time. CPU0is the processor21used by the hypervisor203. In addition, CPU1is the processor used by the application201. In addition, HWA, HWB, and HWC are the existing hardware24a, and HWX is the virtual new hardware24b.

First, as illustrated inFIG. 4A, the application201activates the HWA to perform the process on the memory22, activates the HWX after activating the HWA to perform the process on the memory22, activates the HWB after activating the HWX to perform the process on the memory22, and activates the HWC after activating the HWB to perform the process on the memory22. Among these, the processing time zones of the HWA and the HWX overlap, the processing time zones of the HWX and the HWB overlap, and the processing time zones of the HWB and the HWC overlap.

Here, the HWX is not yet mounted as the actual hardware. Therefore, the HWX cannot actually access the memory22. Therefore, the hypervisor203performs the process as illustrated inFIG. 4Bso as to operate the HWX as the virtual hardware.

That is, the hypervisor203(CPU0) causes the cross trigger to stop the operation of the CPU1at a timing t1at which the application201accesses the memory for activating the HWX. Therefore, the hypervisor203interrupts the process of the application201. While the process of the application201is being interrupted, the hypervisor203causes the simulation model301of the computer3to simulate the performance of the HWX. During simulation by the computer3(Sim in the drawing), the CPU0is on standby, and the CPU1stops the operation by the cross trigger.

When the load assumed during the activation of the HWX is applied to the bus25from the memory access pattern acquired as the simulation result, the influence on the bus25of the HWX can be collected by the profiler201c. Here, assuming that a timing at which the simulation is completed and the simulation result is transmitted to the hypervisor203is t2, since the simulation takes time (t2-t1), the profiler201creferring to the timer of the hardware24collects a profile different from the profile of the original application201illustrated inFIG. 4A.

Therefore, in the embodiment, the hypervisor203sets the time required for the simulation to zero by controlling the virtual timer by the virtual timer controller203c. As described above, when the virtual timer is set, the profiler201crefers to the virtual timer, and thus the elapsed time from the start to the completion of the simulation for the profiler201cis zero. Therefore, the profiler201cdoes not collect profiles during the time required for simulation.

In this manner, the behavior of the HWX, which does not exist as the actual hardware24, is reproduced in software, and the profile can be collected by the profiler201cbased on the overall behavior of each hardware in the process of the original application201in which such HWX and other HWA, HWB, and HWC existing as the actual hardware24are combined.

In addition, in the embodiment, the hypervisor203performs a hardware virtualization process. Therefore, the profile of the application201can be evaluated without changing the application201and the RTOS202.

Hereinafter, modifications of the embodiment will be described. In the embodiment described above, the strength of the virtual load is a value obtained by dividing the total memory access amount of the virtual hardware by the time when the virtual hardware virtually accessed the memory, that is, an average value of the memory access amount. In practice, the memory access bandwidth and the memory access amount may not be uniform in the time axis, and may have a bias. Therefore, when the memory access pattern is estimated by the memory access pattern estimation unit301c, it is preferable to divide data into segments in the time axis direction to estimate the memory access pattern. The segments may be divided at equal intervals, but are preferably divided at a time point when the ratio of memory access bandwidth or the calculation amount to the memory access amount (calculation strength) changes. The virtual load controller203dof the hypervisor203sets the virtual load for each segment. This allows the profiler201cto collect a profile that is more in line with the process of the actual application201.

In the embodiment, the operation of the processor other than the processor used by the hypervisor203is stopped by the cross trigger. Therefore, the process of the application201can be interrupted. Since only the processor is stopped by the cross trigger, the hardware24activated before the cross trigger is applied does not stop its operation until its process is completed. For example, inFIG. 4B, the HWA continues to operate even after the cross trigger is applied. In this case, since the memory access is not performed by the HWA after the cross trigger is released, the process is different from the process of the original application201illustrated inFIG. 4A.

Here, the hypervisor203can use the processor that has been cross-triggered and stopped. Therefore, the hypervisor203(CPU0) measures the bus load of the HWA during simulation as illustrated inFIG. 5. The bus load can be measured by a performance meter provided in the hardware24. When the cross trigger is released, the hypervisor203applies a virtual load1, which is the load of the HWA measured by the performance meter or the like, and a virtual load2, which is the load of the HWX acquired based on the simulation result, to the bus25as the virtual loads. This allows the profiler201cto collect a profile that is more in line with the process of the actual application201. The measurement of the bus load of the HWA may be performed by using the CPU1.

In the embodiment described above, it is assumed that the specific hardware to be virtualized is the virtual new hardware24bnot mounted on the system LSI2. However, the specific hardware to be virtualized may be the existing hardware24amounted on the system LSI2.

In addition, in the embodiment, the simulation for virtualization is assumed to be the computer3outside the system LSI2. However, the simulation for virtualization may be performed by the system LSI2.

In addition, in the embodiment, the hardware virtualization process is performed by the hypervisor203. However, the hardware virtualization process may not be performed by the hypervisor203. For example, the hardware virtualization process may be performed by the RTOS202.