FR3011108A1 - METHOD FOR MEMORY MANAGEMENT IN HYBRID SIMULATION FOR SYSTEMS-ON-CHIP - Google Patents

Abstract

The invention relates to a method for simulating a digital electronic circuit comprising a host processor (CPU), a peripheral device (CPU), and a memory (MEM) shared between the host processor and the peripheral device by a bus ( B). The method comprises the steps of: partitioning the circuit into a high level modeling domain including functional models (TLMs) and a low level modeling domain including clock-accurate models (RTL); Define the host processor in the high-level domain (TLM) define the shared memory (MEM) and the peripheral device (UC) in the low level domain (RTL); define a phantom memory (10) in the high level domain (TLM); intercepting accesses of the host processor to the shared memory, and redirecting the accesses to the phantom memory (10), without using the bus, by a direct memory interface (DMI) defined for the high-level modeling domain; and when access to the shared memory (MEM) by the host processor relates to data shared with the peripheral device, reproducing that access in the shared memory using the bus.

Description

TECHNICAL FIELD OF THE INVENTION The invention relates to the validation of systems-on-chip using hybrid analysis techniques making it possible to reproduce the behavior of the system. system by jointly using several different analytical tools. Such techniques allow, for example, to simulate certain parts of the system with software and to emulate other parts of the system together with hardware. State of the art The entire digital part of a system-on-chip is generally defined in a low-level functional description language, such as Verilog or VHDL, a language that is generically designated by RTL ( "Register Transfer Level" or register transfer level). RTL languages are accurate to the clock cycle, that is, they describe all the events that occur each cycle of a clock. A file written in such a language allows synthesis tools to automatically generate the logical gates and other elementary components necessary to perform the functions described. A simulator of this level of description reproduces the functionality in a software way, and turns out to be too slow when the circuit is complex. It is preferred an emulator, which can be programmed to perform the logical functions in a material way. However, the clock setting an emulator is noticeably slower than that expected to clock the system-on-chip, emulation also finds its limits when the system-on-chip becomes very complex. In this case we use simulation techniques or hybrid emulation. These techniques consist of partitioning a system into two modeling domains: a low-level modeling domain, from the level of an RTL language, groups the circuits whose end-of-cycle behavior is to be analyzed; and a high level modeling domain groups the circuits whose generic functions are to be used, in particular the processors executing a program.

The SystemC language, as defined in the IEEE 1666-2011 standard, has a class or extension called TLM (Transaction Level Modeling) that can be used in the high-level modeling domain. This extension makes it possible to quickly simulate the functionality of a processor system in the execution of a program. To link the two modeling domains, the high-level domain that will be designated by TLM, and the low-level domain that will be designated by RTL, we have developed a standardized interface called SCE-MI, described in the manual entitled " Standard Co-Emulation Modeling Interface (SCE-MI) Reference Manual ", published on the Internet by the Accellera Systems Initiative consortium. Figure 1 is a block diagram of an exemplary system-on-chip, or SoC, partitioned to implement these techniques. The system includes a CPU general purpose host processor, a shared memory MEM, an IP peripheral device, and an IO input / output interface. All these elements are interconnected by a bus B. The CPU processor, the MEM memory and the IO interface are in the TLM domain, while the IP peripheral device is in the RTL domain. The bus B crosses the domains via an SCE-MI interface, for example.

This configuration makes it possible to analyze in a fine manner the behavior of the IP device, for example a new circuit which has not yet been realized on silicon. This analysis can be done by emulation or simulation of its behavior described in RTL. In general, one places in the TLM domain circuits whose reliability has been verified or which do not need a fine analysis. In particular, as shown, a CPU general purpose processor system is provided with its MEM memory and an interface for providing the program to the processor. In such a configuration, any transaction on the bus B, initiated by the processor CPU or the IP device, is passed from one domain to another by the SCE-MI interface. In the world of simulation or RTL emulation, a transaction on the bus is slower, by several orders of magnitude, compared to the transaction in the actual circuit. Access to the MEM memory, which in practice occupies most of the bandwidth of the bus, would considerably slow the simulation if each transaction was indeed simulated. In order to avoid such a slowdown, the TLM extension provides a DMI direct memory interface, making it possible to short-circuit the bus for the memory accesses made by the CPU processor. The gain in simulation time provided by the DMI interface is considerable, but this requires that the shared memory is placed in the TLM domain. In certain situations, it is desired to place the shared memory in the RTL domain, for example to analyze a new memory structure, or to analyze circuits that have a strong interaction with the memory, such as a memory management circuit or a circuit DMA. FIG. 2 is a block diagram illustrating an exemplary configuration where the shared memory is placed in the RTL domain, with, for example, an MCTRL memory management circuit, and a DMA circuit. The peripheral device (IP) may comprise a microcontroller UC designed to share data with the CPU processor via the MEM shared memory. In this situation, the DMI interface, specific to the TLM domain, is no longer usable, and all the accesses of the processor CPU to the memory pass through the bus B to be taken into account in the RTL domain. This can slow down the simulation by a factor of 50 to 100. Summary of the invention We would like to accelerate the simulation when the shared memory is placed in the RTL domain. This need is met by providing a method of simulating a digital electronic circuit comprising a host processor, a peripheral device, and a shared memory between the host processor and the peripheral device over a bus. The method comprising the steps of: partitioning the circuit into a high level modeling domain including functional models and a low level modeling domain including accurate models at the clock cycle; define the host processor in the high-level domain; define the shared memory and the peripheral device in the low-level domain; define a ghost memory in the high-level domain; intercept host processor accesses to shared memory, and redirect access to phantom memory, without using the bus, through a direct memory interface (DMI) defined for the high-level modeling domain; and when shared memory access by the host processor relates to data shared with the peripheral device, reproducing that access in the shared memory using the bus. According to one embodiment of the method, a program executed by the host processor includes cache memory management instructions having memory locations as parameters. The method then comprises the following steps: defining the phantom memory as a cache memory for the host processor, at least the same size as the shared memory; and identifying the data shared with the peripheral device using the memory location provided for each cache management instruction. According to one embodiment of the method, each cache management instruction is one of: - a cleaning instruction, designed to synchronize the shared memory with the cache memory, - an invalidation instruction, designed to: source for marking cache data as requiring refresh from shared memory upon subsequent access, and - a combined cleanup and disable statement, originally designed to synchronize shared memory with data dirty the cache, and then invalidate data from the cache. According to one embodiment, the method comprises, for processing an invalidation instruction, the step of refreshing the cache memory from the shared memory as soon as the invalidation instruction is processed. According to one embodiment, the method comprises, for processing a combined cleaning and invalidation instruction, the following steps: defining a tracing memory in the high-level modeling domain, at least the same size as the memory shared; when performing a cleanup instruction, duplicate in the tracing memory the resulting data transferred from the cache memory to the shared memory; when executing an invalidation instruction, duplicating in the tracing memory the resulting data transferred from the shared memory to the cache memory; and when performing the combined cleaning and invalidation instruction, comparing the data of the cache memory with the corresponding data of the trace memory. For uneven data, cache data is transferred to shared memory and tracing memory. For equal data, the data in the shared memory is transferred to the cache memory and the tracing memory. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments will be set forth in the following description, given in a nonlimiting manner, with reference to the appended figures in which: FIG. 1, previously described, represents an example of a hybrid simulation configuration in which a memory shared is placed in a high-level modeling domain; FIG. 2, previously described, represents an exemplary hybrid simulation configuration in which the shared memory is placed in a low level modeling domain; FIG. 3 represents a hybrid simulation configuration embodiment making it possible to reduce the simulation time when the shared memory is placed in the low level modeling domain; and FIGS. 4A to 4C symbolize process steps illustrating various possibilities of using the configuration of FIG. 3. DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION Certain RTL code resellers for embedded processors, such as the ARM company, propose models encapsulated at the TLM level for their processors, 15 also making it possible to simulate the cache memory. The provision of a cache memory in the TLM domain makes it possible to reduce the memory accesses by the bus B, which would tend to reduce the simulation time when the shared memory is in the RTL domain (FIG. 2). However, a cache does not provide predictable behavior because its efficiency depends on the processing properties of the processor, and it is not efficient when the processor processes non-repetitive data streams. Thus, it was found that the simulation time did not significantly decrease in most cases, and that it could even increase in some cases, because the simulation of a cache memory is complex. In practice, in a real system, most of the bus bandwidth may be occupied by the CPU that runs a resource-intensive program, such as a graphical user interface. The data actually shared between the CPU and the peripheral device, or microcontroller UC, can thus represent a tiny part of the occupation of the bus. It is proposed below to take advantage of this situation, to make appear on the bus only the transactions concerning the shared data.

FIG. 3 is a block diagram of a hybrid simulation configuration, of the type of FIG. 2, incorporating, in the TLM domain, a phantom memory 10 managed in a particular way: in general, any memory transaction operated by the processor CPU, normally intended for shared memory MEM located in the RTL domain, is intercepted and redirected to the phantom memory 10 using the DMI interface. However, some transactions marked as having to go without delay in MEM shared memory, or being intended for a peripheral device, such as the DMA circuit, are actually placed on the bus B, and therefore directly taken into account by their recipient (MEM or DMA). As a result, the shared memory MEM finally only contains the shared data transmitted either by the peripheral device DMA or by the transactions placed on the bus B. The other data (or program instructions) used exclusively in the TLM domain, in particular by the CPU processor, are contained only in the phantom memory, where they are handled exclusively by the DMI interface.

The phantom memory 10 behaves in fact like a cache memory of unlimited size, or at least of size equal to that of the shared memory, which would be configured to keep a local view of the shared memory in RTL; that is to say, it contains a local copy of the data read or written by the processor in the RTL memory not necessarily instantly coherent with the data thereof, because it does not take into account the modifications made by the internal models to the RTL domain. In each processor architecture that manages a cache, there is a way to identify data that the developer does not want to cache. By marking the data shared in this way, the desired functionality could be achieved because the shared data would still be exchanged for transactions on bus B, and those not shared by DMI transactions. However, this solution would require a modification of program run by the processor, which is not compatible with the desire to test the system with its original program, the source code is not necessarily available.

In order to use the original program, without modification, it is proposed to use cache management instructions, necessarily present in the original program, since any complex processor system now includes a cache memory. These instructions can be: - A "cleaning" instruction, often called "clean", used to force the synchronization of the shared memory with the cache memory. This instruction allows in particular to update the shared memory with data, called "dirty", which have just been written to the cache memory and have not yet been written in the shared memory. Such an instruction is used, for example, when the program executed by the processor has written shared data in memory and is about to signal their availability to the peripheral device. The "clean" instruction thus ensures that this data is up to date in the shared memory before the peripheral device reads it. - An invalidation instruction, often referred to as "invalidate", to mark cached data as invalid and to force the processor to read the shared memory without accessing the cache on the next reading of that data. Following this reading, the cache memory is updated with the contents of the shared memory. Such an instruction is used, for example, when the peripheral device has made available shared data in the memory, and has signaled this fact to the processor by an interrupt. In fact, the data contained in the cache memory no longer corresponds to the content of the shared memory - the invalidation instruction makes it possible to ensure that the processor will read the most recent data in the shared memory. - A combined cleaning and invalidation instruction, often referred to as "clean and invalidate". This instruction performs both previous operations atomically. The cleaning function, however, only affects the data marked as "dirty" in the cache memory. Such an instruction is used, for example, when the processor writes and reads data in the same memory location. The written data may be a command for the peripheral device that returns a result for the processor in the same location.

Each of the above cache management instructions is executed with a parameter identifying a memory location. Depending on the processor architectures, the memory location may be an individual cache line or all cache lines corresponding to a range of addresses.

Each of these instructions thus identifies a memory location that can be considered as corresponding to shared data. The phantom memory 10 may be designed as a cache memory that responds to these instructions more or less diverted, as will be seen below. Since the phantom memory 10 is at least the same size as the shared memory, the mechanisms underlying the complexity of a cache memory, such as the indexing, eviction, and to manage flags in cache lines - this speeds up the simulation. The model of the phantom memory 10 is therefore no longer a conventional cache model - however, we will continue to call it "cache memory" below. The desired functionality with a "clean" instruction is that offered by a conventional cache. However, the "invalidate" and "clean and invalidate" instructions are diverted. To manage the "clean" and "invalidate" instructions, a CCTRL coherence management module is provided. To manage the "clean and 15 invalidate" instruction, provision is also made for a TRK tracing memory of the same size, at least, as the MEM shared memory. The memory 10 is used by the CPU processor via the DMI interface. When required, the CCTRL management module transfers between the memory 10 and the bus B, and between the memories 10 and TRK. Figures 4A to 4C illustrate the use of each of the above three cache management instructions. Figure 4A illustrates a way of processing the "clean" instruction with an example. The cache memory 10 contains a number of data that has been written by the processor, including processor-specific CPU data, and data at the Al address location, to be shared with the peripheral device. UC. The CLEAN (A1) instruction is executed by the processor to prepare the sharing of this data with the peripheral device. This instruction is transmitted to the management module CCTRL which processes it by transferring the content of the location Al from the cache memory to the shared memory MEM by the bus B. The module CCTRL also duplicates this content in the tracing memory TRK, whose role will be described later. The cache read by the CCTRL module and the duplication in the TRK memory do not need to be done according to a standardized simulation procedure - these operations can be done in internal software that does not slow down the simulation. At the end of the processing, the shared memory MEM therefore contains the same data as the cache memory 10; a DMA peripheral device can therefore reliably use this data. Note that the shared memory MEM may contain "UC DATA" data that was written by the microcontroller of the peripheral device by taking the bus B. This data, if they are exclusive to the peripheral device, will never be duplicated in the cache memory . In the actual system, as shown in dashed lines, they would share the same memory with the "CPU DATA" data and the Al location. As a result, the "CPU DATA", "UC DATA", and Al data use of disjoint addresses, as illustrated.

Figure 4B illustrates one way of handling the invalidate instruction with an example. The microcontroller UC of the peripheral device has just written data to be shared in an address location A2 of the memory MEM. This writing was done by the bus B. According to the design of the program, the microcontroller can issue an interruption to the CPU processor to signal the availability of this data, or the processor is responsible for regularly scanning a particular location to find the new data (using transactions to the MEM shared memory.) The processor prepares reading of the A2 location by executing the INVALIDATE (A2) instruction, originally intended to mark the corresponding data in the cache memory as "invalid". ".

In a real system, when the processor reads the A2 slot, the cache emits a "cache miss", causing direct reading of the data from the shared memory, and at the same time, a refresh corresponding cache lines. In the simulated system, to avoid implementing this complex mechanism, the CCTRL module processes the instruction by immediately transferring the data from the location A2 of the shared memory MEM to the cache memory by the bus B. The location A2 is at the same time duplicated in the tracing memory TRK, whose role will be described later. At the end of the processing, the cache memory 10 thus contains the same data as the shared memory MEM; the CPU can therefore reliably use this data with "fast" DMI transactions. Figure 4C illustrates a way of handling the clean and invalidate instruction with an example. The CPU processor and the peripheral device DMA are considered to share the same address location A1. The contents of the different copies of the location Al are illustrated side by side in three successive steps. In a first step, the processor writes CPU-D data to location A1. This data first appears in the cache memory. The slots Al in the shared memory MEM and the memory TRK retain their original contents. The processor executes a CLEAN & INVALIDATE statement (A1). In an actual system, this instruction would check a flag associated with the data in the cache memory and only cause the shared memory to update if the flag indicates that the data is dirty. In any case, the actual system 10 would then indicate that the data is invalid by another flag. In the simulated system, these flags are not implemented - to see if the data is dirty, we compare the contents of the location Al of the cache memory to the contents of the same location in the tracing memory TRK. Indeed, the function of the memory TRK, as it has been defined so far, is to contain the trace 15 of the last shared data exchanged by the bus B to perform this comparison, in fact an image of the shared data such as that they would be in the actual shared memory. In this first step, the contents of the cache memory and the memory TRK are different. This causes the transfer of the CPU-D data from the cache memory to the shared memory by the bus B, and to the TRK memory, as for the processing of a simple "clean" instruction (FIG. 4A). The "invalidation" component of the instruction is not implemented. The different memories then contain the CPU-D data at the location A1, as illustrated. The processor waits for a response in the slot A1. This response may be indicated by an interrupt sent by the peripheral device, or the processor periodically scans a particular location to see if the contents of the slot Al have been modified. Before reading the contents of slot Al, the processor executes a new CLEAN & INVALIDATE statement (A1). This time, the Al locations of the cache and trace memory contain the same CPU-D data - the cached data is considered "clean" and is not written to the shared memory. Instead, the location Al is invalidated in the cache memory, as is done for a "invalidate" instruction alone (FIG. 4B) - the content of the shared memory slot A1 is duplicated in FIG. cache, by the bus B, and in the tracing memory TRK. If the peripheral device has previously modified the contents of this location, the modified content UC-D is thus duplicated in the cache memory and in the tracing memory. The processor can then continue processing.

Many variations and modifications of the method described herein will be apparent to those skilled in the art. The method has been described by way of example in connection with cache management instructions that may be specific to certain processors. The teachings described are, however, applicable to any caching or other management instruction that discriminates between proprietary data and shared data.

Claims (5)

REVENDICATIONS1. A method of simulating a digital electronic circuit comprising a host processor (CPU), a peripheral device (CPU), and a memory (MEM) shared between the host processor and the peripheral device by a bus (B), the method comprising the next steps: - partition the circuit into a high-level modeling domain including functional models (TLMs) and a low-level modeling domain including accurate clock-close models (RTL); - define the host processor in the high-level domain (TLM); - define the shared memory (MEM) and the peripheral device (UC) in the low level domain (RTL); define a phantom memory (10) in the high level domain (TLM); - Intercept access host processor access to shared memory, and redirect access to the phantom memory (10), without using the bus, by a direct memory interface (DMI) defined for the high-level modeling domain; and when shared memory (MEM) access by the host processor relates to data shared with the peripheral device, reproduce that access in the shared memory using the bus. The method of claim 1, wherein a program executed by the host processor includes cache management instructions having memory locations as parameters, the method comprising the steps of: - defining the phantom memory (10) as a memory cache for the host processor, at least the same size as the shared memory (MEM); and - identifying the data shared with the peripheral device using the memory location provided for each cache management instruction. The method of claim 2, wherein each cache management instruction is one of: - a cleanup instruction, designed to synchronize the shared memory with the cache memory, - an invalidation instruction, designed to source for marking cache data as requiring refresh from shared memory upon subsequent access, and - a combined cleanup and disable statement, originally designed to synchronize shared memory with data dirty the cache, and then invalidate data from the cache. 4. Method according to claim 3, comprising, for processing an invalidation instruction, the following step: - refresh the cache memory from the shared memory from the processing of the invalidation instruction. The method according to claim 3, comprising, for processing a combined cleaning and invalidation instruction, the following steps: defining a tracing memory (TRK) in the high level modeling domain of at least the same size as shared memory (MEM); when executing a cleaning instruction, duplicating in the tracing memory the resulting data transferred from the cache memory (10) to the shared memory (MEM); when executing an invalidation instruction, duplicating in the tracing memory (TRK) the resulting data transferred from the shared memory (MEM) to the cache memory (10); and - when executing the combined cleaning and invalidation instruction: comparing the data of the cache memory (10) with the corresponding data of the tracing memory (TRK), for the unequal data, transferring the data of the cache memory in the shared memory and in the tracing memory, and - for the equal data, transfer the data from the shared memory to the cache memory and the tracing memory.