A kind of core particle simulation platform design method, device, electronic equipment and storage medium
By designing a chip simulation platform and using a controller and multiple small-capacity FPGAs to perform hardware-level chip simulation, the problems of low simulation efficiency and high cost in existing technologies are solved, and faster and more accurate chip verification is achieved.
Patent Information
- Application Number
- CN202411740598.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-29
- Publication Date
- 2025-10-17
- Estimated Expiration
- 2044-11-29
AI Technical Summary
Existing chiplet testing methods include using architecture simulators or traditional FPGA verification platforms, which make it difficult to simulate multiple chiplets and result in low simulation efficiency. In addition, traditional FPGA verification platforms are expensive and cannot meet the rapid verification requirements of chiplet systems.
A chiplet simulation platform is designed, including determining the topology of a controller and multiple chiplet nodes, using the controller to control the chiplet nodes for hardware-level simulation, and using multiple small-capacity FPGAs for chiplet combination. The platform supports flexible chiplet combination and external design, and realizes monitoring and data interaction at the hardware and software levels.
It achieves more accurate simulation of core particle behavior, improves simulation speed, reduces construction cost, is more suitable for core particle design mode, and supports rapid verification of various types of core particles.
Smart Images

Figure CN119720931B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of integrated circuits, and in particular to a core grain simulation platform design method and device, electronic equipment and storage medium. BACKGROUND
[0002] Existing core grain testing methods include using an architecture simulator or a traditional FPGA verification platform. The architecture simulator usually models the system hardware using a software method, simulates the processor, storage system, network transmission topology, etc. of the architecture, and verifies the function and performance of the system. The FPGA verification platform can restore the real use scene of the chip as much as possible before tape-out, so as to achieve the purpose of fully verifying the function of the chip.
[0003] However, the architecture simulator or the traditional FPGA verification platform is difficult to realize the simulation of multiple core grains, and the simulation efficiency is low. SUMMARY
[0004] The main purpose of the embodiments of the present application is to provide a core grain simulation platform design method and device, electronic equipment and storage medium to design a hardware platform for simulating multiple core grain testing.
[0005] To achieve the above purpose, one aspect of the embodiments of the present application provides a core grain simulation platform design method, which comprises the following steps:
[0006] determining a first topology of a core grain simulation platform; wherein the first topology comprises a controller and a plurality of core grain nodes;
[0007] determining a second topology of the controller; wherein the controller is used to realize the operation control of the core grain simulation platform;
[0008] determining a third topology of each of the core grain nodes; wherein each of the core grain nodes comprises a core grain component and an external component;
[0009] configuring a plurality of core grain nodes to be tested in the core grain simulation platform;
[0010] controlling the plurality of core grain nodes to be tested to perform simulation by using the controller.
[0011] In some embodiments, the step of determining the first topology of the core grain simulation platform comprises the following steps:
[0012] determining the number and topology relationship of each of the core grain nodes;
[0013] determining the type and position of the controller;
[0014] determining the space size and position of the storage chip of each of the core grains;
[0015] determining a control signal and an interconnection mode of each of the core grain nodes.
[0016] In some embodiments, the method further comprises the following steps:
[0017] setting peripheral circuit of each of the core grain nodes in the first topology structure.
[0018] In some embodiments, the determining the second topology structure of the controller comprises the following steps:
[0019] determining an external access channel of the controller; wherein the external access channel comprises a data channel, a monitoring channel, a reset channel and a debugging channel;
[0020] setting the data channel as a first network on chip; wherein the data channel is used for connecting each of the core grain nodes; transmitting an executable file of each of the core grain nodes to a corresponding storage chip; and providing data of the storage chip to the controller after the core grain ends running;
[0021] setting the monitoring channel as a second network on chip; wherein the monitoring channel is used for obtaining data of a monitoring module and transmitting data of a virtual peripheral; the monitoring channel is sent from an upper computer to the controller through Ethernet, and then forwarded to programmable logic through the controller, and the programmable logic is sent to each of the core grain nodes after protocol conversion of the second network on chip;
[0022] setting the reset channel comprising a first reset channel of the core grain simulation platform and a second reset channel of each of the core grain nodes; wherein the controller uses corresponding reset signals to control reset of multiple core grain nodes through the first reset channel and reset of a single core grain node through the second reset channel;
[0023] setting the debugging channel comprising a first debugging channel of a hard core processor and a second debugging channel of a JTAG interface; wherein the debugging channel is used for providing a burning and debugging path for each of the core grain nodes; the first debugging channel is used for realizing transmission of a hardware bitstream file of each of the core grain nodes from Ethernet to a cache of the controller, and then converting the hardware bitstream file to a JTAG signal by programmable logic; and the second debugging channel is used for burning the hardware bitstream file through an external JTAG debugger.
[0024] In some embodiments, the determining a third topology structure of each of the core grain nodes; wherein each of the core grain nodes comprises a core grain component and an external component, comprises the following steps:
[0025] setting a type of the kernel component of each of the kernel nodes and an interface of each type;
[0026] setting a type of the external component of each of the kernel nodes; wherein the external component comprises an interconnection component, an address mapping component, a monitoring component, a peripheral component and a reset component;
[0027] wherein the interconnection component comprises a first network-on-chip router and a second network-on-chip router; the first network-on-chip router is connected with a data path of the kernel node, as an adaptation interface of the kernel component, and communicates with the kernel component in adjacent other kernel nodes; the second network-on-chip router is used for transmitting information of the monitoring component and the peripheral component to the controller;
[0028] the address mapping component is used for recording a physical location identification ID of each of the kernel nodes and a mapping relationship between the physical location identification ID and a physical access address;
[0029] the monitoring component is used for monitoring a running state of each of the kernel nodes and a running state of the kernel component;
[0030] the peripheral component comprises a real peripheral and a virtual peripheral; wherein the real peripheral is preset by the kernel simulation platform at design time; the virtual peripheral simulates input and output of each of the kernel nodes using programmable logic resources in the FPGA;
[0031] the service component is used for connecting a reset path in the controller.
[0032] In some embodiments, the configuring a plurality of the kernel nodes to be tested in the kernel simulation platform comprises the following steps:
[0033] determining an address mapping table according to a location of each of the kernel nodes;
[0034] selecting a kernel component to be tested from each of the kernel nodes and configuring an external component for the kernel component;
[0035] inserting a test probe into each of the configured kernel nodes to generate a kernel project;
[0036] generating a hardware bitstream file according to the kernel project;
[0037] downloading the hardware bitstream file to the kernel simulation platform for testing.
[0038] In some embodiments, the controlling a plurality of the kernel nodes to be tested using the controller for simulation comprises the following steps:
[0039] receiving a load program of each of the core grain nodes;
[0040] loading, by the controller, an executable file corresponding to the load program to a storage chip corresponding to the core grain node;
[0041] starting, by a reset channel of the controller, the executable file in each of the core grain nodes;
[0042] obtaining running information of each of the core grain nodes when running the executable file;
[0043] reading an execution result after each of the core grain nodes ends running the executable file;
[0044] uploading the running information and the execution result to an upper computer, so that the upper computer analyzes simulation results of each of the core grain nodes.
[0045] To achieve the above object, another aspect of the embodiment of the present application provides a core grain simulation platform design device, which comprises:
[0046] a platform design unit configured to determine a first topology structure of a core grain simulation platform; wherein the first topology structure comprises a controller and a plurality of core grain nodes;
[0047] a controller design unit configured to determine a second topology structure of the controller; wherein the controller is configured to realize running control of the core grain simulation platform;
[0048] a core grain design unit configured to determine a third topology structure of each of the core grain nodes; wherein each of the core grain nodes comprises a core grain component and an external component;
[0049] a core grain configuration unit configured to configure a plurality of the core grain nodes to be tested in the core grain simulation platform;
[0050] a core grain simulation unit configured to control the plurality of the core grain nodes to be tested to perform simulation by using the controller.
[0051] To achieve the above object, another aspect of the embodiment of the present application provides an electronic device, which comprises a memory and a processor, the memory stores a computer program, and the processor realizes the above method when executing the computer program.
[0052] To achieve the above object, another aspect of the embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program realizes the above method when executed by a processor.
[0053] The embodiment of the present application at least has the following beneficial effects:
[0054] The application can determine a first topology of a corelet simulation platform; wherein the first topology comprises a controller and a plurality of corelet nodes; determine a second topology of the controller; wherein the controller is used to realize operation control of the corelet simulation platform; determine a third topology of each corelet node; wherein each corelet node comprises a corelet component and an external component; configure a plurality of corelet nodes to be tested in the corelet simulation platform; and use the controller to control the plurality of corelet nodes to be tested to perform testing. The corelet simulation platform and simulation process of the application can perform hardware-level verification, obtain more accurate actual corelet behavior, have higher operation speed than architecture simulators, and are more suitable for various types of corelets. BRIEF DESCRIPTION OF DRAWINGS
[0055] In order to more clearly illustrate the technical solutions in the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.
[0056] Figure 1 A flowchart of a corelet simulation platform design method provided by the embodiment of the application;
[0057] Figure 2 A hardware design flowchart of the corelet simulation platform provided by the embodiment of the application;
[0058] Figure 3 A hardware topology diagram of an exemplary corelet simulation platform provided by the embodiment of the application;
[0059] Figure 4 A topology diagram of a controller provided by the embodiment of the application;
[0060] Figure 5 A schematic diagram of a data path and a monitoring path connection method provided by the embodiment of the application;
[0061] Figure 6 A structure diagram of a corelet node provided by the embodiment of the application;
[0062] Figure 7 A multi-corelet engineering generation and download flowchart provided by the embodiment of the application;
[0063] Figure 8 A control flowchart of corelet operation provided by the embodiment of the application;
[0064] Figure 9A structural schematic diagram of a core particle simulation platform design device provided by an embodiment of the present application is shown in FIG. 1.
[0065] Figure 10 A hardware structural schematic diagram of an electronic device provided by an embodiment of the present application is shown in FIG. 4. DETAILED DESCRIPTION
[0066] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. When the following description refers to the accompanying drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all the implementations consistent with embodiments of the present application. They are only examples of devices and methods consistent with some aspects of the embodiments of the present application as detailed in the appended claims.
[0067] It can be understood that the terms "first", "second", and the like used in the present application can be used herein to describe various concepts, but unless otherwise specified, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of the present application, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to determining".
[0068] The terms "at least one", "multiple", "each", "any", and the like used in the present application include one, two or more than two, multiple includes two or more than two, each refers to each of the corresponding multiple, and any refers to any one of the multiple.
[0069] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as understood by a person skilled in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.
[0070] Before the embodiments of the present application are described in detail, the related technologies involved in the embodiments of the present application are first described as follows:
[0071] With the continuous evolution of semiconductor process nodes, transistors are shrinking to the physical limit, and the pursuit of economic efficiency "Moore's Law" is slowing down. The development cost and complexity of chips under advanced processes have increased significantly, and the development of advanced technology node system on chip (SoC) has also increased significantly, bringing challenges in yield, cost, and development cycle, etc. People are forced to seek more cost-effective technology routes to meet the growing demand for chip performance in the industry, which can achieve larger chip size, break through the current manufacturing area limitations, and promote the continuous improvement of chip integration and computing power. Chiplet (chiplet) heterogeneous integration technology promotes the development of multi-chip packaging, which can effectively extend Moore's Law. The principle of chiplet is to divide the original complex SoC chip into different computing units or functional units from the design, then select the most suitable process to manufacture each unit, and then interconnect these modular dies through advanced packaging technology such as silicon interposer. Finally, different functional and process manufactured chiplets are packaged into an SoC chip. This technology effectively solves the problems of chip development in cost, scale, cycle, etc. In addition, due to the use of advanced packaging technologies such as 2.5D and 3D, chiplets achieve on-chip interconnection, and also have amazing performance in integration, power consumption, delay, and working frequency, etc.
[0072] Chiplet system is a new design pattern, which involves multiple independent small chips with different functions and architectures, and needs to consider the communication and cooperative work between multiple chiplets. This design pattern needs to perform detailed verification and design space exploration on the chiplet system before manufacturing to ensure that the system can meet the functional performance requirements.
[0073] The technical problem to be solved by the present application is:
[0074] The existing chiplet test method includes using architecture simulators or traditional FPGA verification platforms.
[0075] Architecture simulators usually model the system hardware in software, simulating the processor, memory system, network topology, etc. of the architecture to verify the functionality and performance of the system. (1) However, simulators are not based on real hardware, they rely on software to simulate the hardware's circuit and clock frequency, etc. In order to achieve the simplicity and fast execution of the performance model, developers often abstract some detailed features, which may not completely simulate the real hardware behavior, resulting in a deviation between the simulator results and the actual hardware behavior. (2) Architecture simulators also have the problem of slow simulation speed, especially when using cycle-accurate simulation models to better simulate real hardware, which is a very time-consuming process. The chiplet system uses multiple chiplets to splice, which can achieve a larger chip scale. As the size of the chiplet system increases, the running time of modeling the entire chiplet system using a simulator becomes unacceptable, which cannot meet the research and design needs of the chiplet system. (3) The simulator for chiplet systems is not mature at present and still faces many problems. In order to simulate the chiplet system, it is necessary to integrate multiple different types of simulators, such as multiple processor simulators of different architectures, interconnection simulators, and memory models, which involve complex interconnection and synchronization problems between simulators.
[0076] Using RTL simulation is also a verification method, but it also faces the problem of slow simulation speed and long simulation time. FPGA prototype verification technology is used to verify application-specific integrated circuits by porting RTL to FPGAs. FPGA prototype verification technology can restore the real use scenario of the chip as much as possible before tape-out, achieving the purpose of fully verifying the function of the chip.
[0077] (1) Traditional FPGA verification platforms mainly target large SOC designs, aiming to put the entire SOC into a single FPGA chip as much as possible, so they tend to use a small number of large-capacity FPGAs. A single large-capacity FPGA may be more expensive and unstable in supply than multiple small-capacity FPGAs. At the same time, when a large SOC needs multiple FPGA chips to accommodate, complex logic partitioning strategies need to be designed, and the impact of interconnection delay on chip function needs to be considered after logic partitioning. This results in high overall cost of traditional FPGA prototype verification platforms and tools.
[0078] Chiplet is based on the concept of splitting a large chip into small chips, a single small FPGA can accommodate a complete single chiplet design, without the need to consider complex circuit partitioning. Moreover, the communication delay between chiplets is usually considered to take multiple chiplet cycles to complete, so longer communication delay between FPGAs is allowed. Therefore, a large number of small FPGA platforms are more suitable for the simulation of chiplets.
[0079] (2) Traditional FPGA verification platforms are not designed for coreparticle systems. Coreparticle combinations may use larger topologies, more peripherals, and more flexible memory models. Traditional FPGA verification platforms require manual creation of coreparticle external components and manual assembly of multiple coreparticles into a complete coreparticle system, lacking a fast assembly and verification method.
[0080] This application aims to propose a design method for a core particle simulation platform based on multiple FPGAs, which effectively guides the design of the core particle simulation platform. The core particle simulation platform and simulation process designed using this method can perform hardware-level verification compared to simulators, obtain more accurate actual core particle behavior, have a higher running speed than core particle simulators, and are more likely to support various types of core particles. This solution is simpler than the traditional FPGA verification platform construction method and is more suitable for the core particle design model. At the same time, the method proposes a hardware and software design solution for the core particle simulation platform, providing complete hardware and software support for core particle simulation, supporting flexible core particle and external design, supporting the rapid embedding of core particles into the simulation platform to build a core particle system, and supporting hardware and software level monitoring and effective data interaction during core particle operation.
[0081] Therefore, the embodiments of the present application provide a method, device, electronic device and storage medium for designing a chip simulation platform. The technical solution of the present application includes: determining a first topology structure of the chip simulation platform; wherein the first topology structure includes a controller and multiple chip nodes; determining a second topology structure of the controller; wherein the controller is used to realize the operation control of the chip simulation platform; determining a third topology structure of each chip node; wherein each chip node includes a chip component and an external component; configuring multiple chip nodes to be tested in the chip simulation platform; and using the controller to control the multiple chip nodes to be tested for testing. Compared with the architecture simulator, the chip simulation platform and simulation process of the present application can perform hardware-level verification, obtain more accurate actual chip behavior, have a higher operating speed than the architecture simulator, and are more likely to support various types of chips; compared with the traditional FPGA verification platform construction method, it is simpler and more suitable for the design mode of chips.
[0082] The embodiment of the present application provides a core particle simulation platform design method, and relates to the technical field of integrated circuits. The core particle simulation platform design method provided by the embodiment of the present application can be applied to a terminal, can be applied to a server, and can also be software running in the terminal or the server. In some embodiments, the terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle-mounted terminal, and the like, but is not limited thereto; the server end can be configured as a stand-alone physical server, can be configured as a server cluster or a distributed system formed by multiple physical servers, can be configured as a cloud server providing basic cloud computing services such as cloud service, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN, and big data and artificial intelligence platform, and the server can also be a node server in a blockchain network; the software can be an application for implementing the core particle simulation platform design method, and the like, but is not limited to the above forms.
[0083] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in a distributed computing environment, in which tasks are performed by remote processing devices connected by a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.
[0084] The embodiment of the present application provides a core particle simulation platform design method, and relates to the technical field of integrated circuits. The core particle simulation platform design method provided by the embodiment of the present application can be applied to a terminal, can be applied to a server, and can also be software running in the terminal or the server. In some embodiments, the terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle-mounted terminal, and the like, but is not limited thereto; the server end can be configured as a stand-alone physical server, can be configured as a server cluster or a distributed system formed by multiple physical servers, can be configured as a cloud server providing basic cloud computing services such as cloud service, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN, and big data and artificial intelligence platform, and the server can also be a node server in a blockchain network; the software can be an application for implementing the core particle simulation platform design method, and the like, but is not limited to the above forms.
[0085] Specifically, the method of the embodiment of the application comprises a core particle simulation platform hardware design method, a controller design method, a single core particle node design method, a multi-core particle combination generation and download method, and a core particle running control method.
[0086] With reference to Figure 1 , the embodiment of the application provides a core particle simulation platform design method, which can comprise but is not limited to S100 to S140, and specifically as follows:
[0087] S100: determining a first topology of a core particle simulation platform; wherein the first topology comprises a controller and a plurality of core particle nodes.
[0088] Further, S100 can comprise:
[0089] S101: determining the number and topology relationship of each core particle node;
[0090] S102: determining the type and position of the controller;
[0091] S103: determining the space size and position of the storage chip of each core particle;
[0092] S104: determining the control signal and interconnection mode of each core particle node.
[0093] Specifically, in the core particle simulation platform design method of the embodiment, the hardware platform thereof needs to be designed first, and the hardware design flow of the core particle simulation platform is as shown in Figure 2 The hardware of the core particle simulation platform adopts the method of simulating core particles by using a plurality of small-capacity FPGAs, each FPGA can accommodate a single core particle, the interconnection delay between the FPGAs can tolerate a plurality of cycles, and each FPGA can be regarded as a core particle simulation node. The core particle simulation platform built by the method can perform hardware-level verification compared with a simulator, and obtain more accurate actual core particle behavior; compared with the building method of a traditional FPGA verification platform, the method is simpler and more suitable for the design mode of core particles.
[0094] Specifically, the embodiment can summarize the core particle simulation platform hardware design method as Figure 2 flow. Figure 3 A hardware topology diagram of a core particle simulation platform is provided for the embodiment.Figure 2 Each step specifically includes:
[0095] (1) Define the number of corelet simulation nodes and topology. The corelet simulation node topology needs to consider the maximum number of simulating corelets and the physical location layout of the corelets. In order to make the platform compatible with a larger number of corelets, the scalability of the platform also needs to be considered. Each corelet simulation node needs to set its own unique physical location identification ID. For example, the corelet simulation node is designed as a 4x4 array topology, which can simulate most of the corelet layout methods; the peripheral corelet simulation node is designed with a fiber interface (expansion interface in the figure), which can realize the interconnection expansion of multiple corelet simulation platforms. Each corelet simulation node sets a unique location identification ID, which is realized by a multi-bit input bias resistor (not shown in the figure).
[0096] (2) Determine the type and location of the controller. The corelet simulation platform needs a controller as the process control of the platform and the communication with the host computer. The controller needs to be responsible for the corelet node engineering loading of the corelet simulation platform, the corelet running start, process monitoring, result output, etc. The type and location of the controller need to be determined in the hardware design process. The controller is more suitable for using a heterogeneous processor including a hard-core SOC processor part and a programmable logic part. The controller in the example is located in the lower right corner of the platform.
[0097] (3) Define the storage size and the physical location of the storage chip. In a multi-corelet combination, the storage chip location needs to consider the possible memory location in the actual corelet system. The storage chip can be considered as a corelet or a peripheral unit. In the example, an external storage chip is configured for each corelet simulation node, such as the DDR in Figure 2 Therefore, each corelet simulation node can simulate a single storage corelet, or the DDR can be considered as the mounted storage of each corelet (such as 3D stacking), or the peripheral DDR can be considered as the storage peripheral of the corelet periphery.
[0098] (4) Design the control signals of the corelet simulation nodes and the interconnection between the nodes. The control signals and interconnections between the corelet simulation nodes need to meet the communication between the corelet components, the communication between the controller and the corelet simulation nodes, the global reset, and the burning debugging interface of each corelet simulation node.
[0099] The interconnection of the core grain simulation node and the adjacent node requires two paths, a data path responsible for the communication between the core grain components, and a monitoring path responsible for the communication with the controller. The two paths are usually implemented in the form of two independent on-chip networks, which can use serial buses (such as SerDes) or parallel buses in hardware. The data path between the core grain components needs to evaluate the difference between the communication delay (hardware real delay) between the core grain simulation nodes and the actual communication delay (expected delay) of the core grain. It is generally believed that the delay between the core grains is slower than the operating frequency within the core grain, so if the real delay is less than the required core grain communication delay, a delay unit can be inserted in the node engineering to regulate; if the real delay is greater than the required core grain communication delay, the operating frequency of the core grain simulation node is considered to be reduced, and the simulation speed is reduced.
[0100] In addition, each core grain simulation node needs a JTAG path to connect with the controller, and the debugging path can be selected in the form of a daisy chain, or due to the large topology, a daisy chain is selected for each row, and a debugger interface is connected with the controller in each row.
[0101] The core grain simulation node needs a two-bit reset signal, which is responsible for the reset of the core grain simulation node and the reset of the core grain component. All core grain simulation nodes can share a two-bit multiplexing signal output by the controller.
[0102] Further, the S100 can further include:
[0103] S105: setting the peripheral circuit of each core grain node in the first topology.
[0104] Specifically, the embodiment can design the peripheral of the core grain simulation node. The peripheral should meet the needs of node operation, such as the FLASH peripheral required by the clock module and the FPGA solidification. The peripheral needs to provide common general-purpose peripherals for the core grain system, such as GPIO, which can be provided by real peripherals or replaced by virtual peripherals simulated by programmable logic in the core grain simulation node engineering.
[0105] S110: determining a second topology of the controller; wherein the controller is used to realize the operation control of the core grain simulation platform.
[0106] Specifically, by a single controller, the downloading of the hardware bitstream file of the core grain simulation platform and the executable file of the core grain load program can be realized, the running control of the core grain simulation platform can be realized, and the data transmission and monitoring of the core grain simulation platform can be realized during the running process. The controller uses a heterogeneous processor composed of a hard-core SOC processor part and a programmable logic part, compatible with the development of hard-core processors and the interface expansion of programmable logic, such as using Xilinx ZYNQ series chips. The hard-core SOC processor is responsible for communication with the host computer through the Ethernet bus, and the programmable part is responsible for data conversion and path selection functions. The external access of the controller includes data access, monitoring access, reset access and debugging access. The function of each access and the implementation method in the controller are described below.
[0107] Further, S110 can include S111-S115:
[0108] S111: determining the external access of the controller; wherein the external access includes data access, monitoring access, reset access and debugging access;
[0109] S112: setting the data access as a first network on chip; wherein the data access is used to connect each core grain node; transmitting the executable file of each core grain node to the corresponding storage chip; after the core grain ends running, providing the data of the storage chip to the controller;
[0110] S113: setting the monitoring access as a second network on chip; wherein the monitoring access is used to obtain the data of the monitoring module and transmit the data of the virtual peripheral; the monitoring access is sent from the host computer to the controller through the Ethernet, and then forwarded to the programmable logic through the controller, and the programmable logic is sent to each core grain node after protocol conversion through the second network on chip;
[0111] S114: setting the reset access including the first reset access of the core grain simulation platform and the second reset access of each core grain node; wherein the controller uses corresponding reset signals to control the reset of multiple core grain nodes through the first reset access and the reset of a single core grain node through the second reset access;
[0112] S115: The debugging path is set to include a first debugging path of the hard-core processor and a second debugging path of the JTAG interface; wherein, the debugging path is used to provide a burning and debugging path for each of the core grain nodes; the first debugging path is used to realize the transmission of the hardware bitstream file of each of the core grain nodes from Ethernet to the cache of the controller, and then the programmable logic converts the hardware bitstream file into a JTAG signal; the second debugging path is used to burn the hardware bitstream file through an external JTAG debugger.
[0113] For example, referring to Figure 4 This embodiment provides a topological diagram of a controller. Specifically, the steps of designing the external path of the controller may include:
[0114] (1) The data path connects the data path of the multi-chip combination (multiple analog chip nodes). The data path is responsible for transmitting the executable files of the multi-chip combination to the corresponding storage location. After the chip finishes running, the data in the memory is read through the data path. This path is only valid before and after the chip runs, and is closed at other times. Since the data path needs to be connected to all chip simulation nodes, it can be considered to be implemented through on-chip network during design, such as Figure 5 As shown, Figure 5 This is a diagram showing the connection between the data path and the monitoring path. Figure 5 The "R" in the figure represents an on-chip network router. The on-chip network router for a multi-chip assembly is defined in the chip node project. During data path usage, data from the host computer travels via Ethernet to the control system's storage unit. The control system then forwards data to the programmable logic, which converts the data to the on-chip network protocol before sending it to the multi-chip assembly. Similarly, data from the multi-chip assembly undergoes protocol conversion and is sent to the controller's storage unit. The controller then notifies the host computer to read the data.
[0115] (2) Monitoring path: The monitoring path obtains the data of the monitoring module in the core particle project and transmits the data of the virtual peripheral. This path is sent from the host computer to the control system via Ethernet, and then forwarded to the programmable logic through the control system. The programmable logic is sent to the multi-core particle combination after protocol conversion. Since the monitoring path needs to be connected to all core particle simulation nodes, it can be considered to be implemented through the on-chip network during design. In order not to affect the communication between core particle components, a separate set of on-chip networks is used, such as Figure 4 As shown, the on-chip network router composed of multiple chiplets is defined in the chiplet node project.
[0116] (3) Reset path, reset path is divided into core grain engineering reset and core grain assembly reset, the controller uses two reset signals to control the global core grain node engineering and the global core grain assembly reset respectively. The signal can be directly given by the control system of the hard core processor.
[0117] (4) Debug path is responsible for providing burning and debugging path for each analog node. The data of the debug path can be divided into two sources, source one is the hard core processor, the hardware bit stream file of the node is transmitted from the Ethernet to the controller cache, and then converted to JTAG signal by programmable logic. This path cooperates with the host computer to make it easier to realize the burning of multiple nodes. Source two is the JTAG adapter, which can directly burn the bit stream file through the external JTAG debugger. In the multi-core grain combination, the debug path can choose the daisy chain form, or because the topology is too large, choose each row as a daisy chain, so each row will have a JTAG signal connected to the controller. The input and output of the debug path data are connected through multiplexer and demultiplexer. The control signal of the multiplexer and demultiplexer is provided by the control system in the hard core processor.
[0118] S120: determining a third topology of each of the core grain nodes; wherein each of the core grain nodes comprises a core grain assembly and an external assembly.
[0119] Specifically, a single core grain node is composed of a core grain assembly and an external assembly to form a complete core grain engineering, and the method realizes the generation of a single core grain platform. The method includes the interactive assembly design between core grains, flexible peripheral support scheme, core grain control and monitoring method. Because the combination mode of the core grain assembly and the external assembly in this process is relatively fixed, it is more suitable to make configuration software to complete the operation. The configuration software needs to complete the functions of core grain assembly source selection, core grain interface type selection, configuration router parameter and peripheral type selection.
[0120] Further, S120 can include S121-S122:
[0121] S121: setting the type of the core grain assembly of each of the core grain nodes and the interface of each type;
[0122] S122: setting the type of the external assembly of each of the core grain nodes; wherein the external assembly includes an interconnection assembly, an address mapping assembly, a monitoring assembly, a peripheral assembly and a reset assembly;
[0123] The interconnection component includes a first network-on-chip router and a second network-on-chip router; the first network-on-chip router is connected with a data path of the core grain node, serves as an adaptation interface of the core grain component, and communicates with the core grain component in adjacent other core grain nodes; the second network-on-chip router is used for transmitting information of the monitoring component and the peripheral component to the controller;
[0124] The address mapping component is used for recording a physical location identification ID of each core grain node and a mapping relationship between the physical location identification ID and a physical access address;
[0125] The monitoring component is used for monitoring an operating state of each core grain node and an operating state of the core grain component;
[0126] The peripheral component includes a real peripheral and a virtual peripheral; the real peripheral is preset by the core grain simulation platform during design; and the virtual peripheral simulates input and output of each core grain node by using programmable logic resources in the FPGA;
[0127] The service component is used for connecting a reset path in the controller.
[0128] Referring to Figure 6 , the single core grain node project includes the following components:
[0129] (1) Core grain component. The core grain component is a core grain that needs to be simulated and is provided by a user of the core grain simulation platform. The core grain component interface needs to conform to a certain standard protocol interface, such as a CHI interface with cache consistency function or a same network-on-chip interface as the simulation platform. The configuration software selects a source of the core grain component and an interface protocol used by the core grain component.
[0130] (2) Interconnection component. The interconnection component is generally implemented by a network-on-chip router. The interconnection component mainly uses two network-on-chip routers. One router is connected with a data path of the core grain simulation node, serves as an adaptation interface of the core grain component, is responsible for communication with the core grain component in adjacent other nodes, and usually processes a large amount of data. The router has a certain configurable capability, and parameters such as routing algorithm, bandwidth and delay of the interconnection are selected by the configuration software, which makes the core grain simulation platform more flexible. The other router transmits information of the monitoring component and the peripheral component to the controller. The router can use a fixed structure. The interconnection component generally needs to consider how to adapt to real hardware, such as converting network-on-chip data into a SerDes signal to adapt to a serial path between nodes.
[0131] (3) System address mapping component. Each core grain node in the system needs to be assigned a unique node ID, which is the ID of the physical location of the core grain simulation node. The interconnection component needs to obtain the address mapping table of the system address mapping component during use, which converts the physical access address of the core grain component into the target physical location ID, providing the local node ID and target node ID information for the network-on-chip data packet, and then converting the interface protocol into the network-on-chip protocol. The monitoring path also needs to obtain the local node ID and the location of the controller from the system address mapping component. The address mapping table must completely describe the entire system address space, and all core grain simulation nodes must maintain the same address mapping table.
[0132] (4) Monitoring component. The monitoring component can monitor the running state of the core grain node hardware, such as the temperature and power voltage of the FPGA where the node is located; the monitoring module can also monitor the real-time state of the core grain component, such as the number of running cycles of the core grain. The data of the monitoring component is connected to the controller through the monitoring network-on-chip channel, and is processed by the controller or forwarded to the host computer.
[0133] (5) Peripheral component. The peripheral component is set according to the needs of the core grain, including real peripherals, which are pre-set when the core grain simulation hardware platform is designed; virtual peripherals, which use programmable logic resources within the FPGA to simulate the input and output of the core grain. The configuration software provides a general peripheral module, which can also be designed by the user. The virtual peripheral can parse the instruction sequence issued by the controller into peripheral input signals, such as analog GPIO input signals; or package and transmit the peripheral output to the controller, such as through a virtual serial port output. The virtual peripheral is also connected to the controller through the monitoring network-on-chip channel.
[0134] (6) Reset component. The reset path is divided into core grain node engineering reset and core grain component reset, and the core grain node engineering reset resets all components in the node, and the core grain component reset is connected only to the reset pin of the core grain component. The reset signal is globally controlled by the controller.
[0135] S130: configuring a plurality of core grain nodes to be tested in the core grain simulation platform.
[0136] Further, S130 can include S131-S135:
[0137] S131: determining an address mapping table according to the positions of each core grain node;
[0138] S132: selecting a core grain component to be tested from each core grain node and configuring an external component for the core grain component;
[0139] S133: inserting a test probe into each configured core grain node to generate a core grain engineering;
[0140] S134: generating a hardware bitstream file according to the corelet engineering;
[0141] S135: downloading the hardware bitstream file to the corelet simulation platform for testing.
[0142] Specifically, the multi-corelet engineering generation and download process is as shown in Figure 7 The method realizes the configuration and generation of multiple corelet nodes, and how to insert hardware probes during the generation process and hardware debugging during the running process. The method further realizes the automatic download of multiple corelet node executable files through Ethernet. The method can insert hardware probes in single-corelet nodes, and configure the controller to debug the hardware of the corelet nodes during the running process.
[0143] Specifically, the embodiment includes:
[0144] (1) Defining a system address mapping table according to corelet positions. This step needs to determine the corelet positions according to the required number of corelets and topology, obtain the system address mapping table from the actual corelet positions, the address range of the corelets, and the address range of the storage chips, and map the memory access address to the corelet position identification ID. All corelet node engineering shares a unified table, which is stored in the system address mapping component in each corelet node engineering.
[0145] (2) Selecting corelet components and configuring peripheral components. Selecting the source of corelet components, configuring the parameters of corelet external components according to the configurable options provided by the configuration software, and specifically referring to the corelet node engineering design method.
[0146] (3) Integrating single-corelet node engineering and inserting test probes. After the configuration of corelet external components is completed, the corelet components and external components can be integrated by the configuration software, and then test probes can be inserted in the engineering through EDA tools, such as using the ILA tool provided by Xilinx. Finally, the complete corelet engineering is generated.
[0147] (4) EDA tool generates hardware bitstream file. After the single-corelet node engineering is compiled, synthesized, and implemented using EDA tools, a hardware bitstream file that can be downloaded is generated. According to the number of corelets, the above steps need to be performed respectively to generate hardware bitstream files for multiple corelet nodes.
[0148] (5) Multi-corelet node engineering download. The corelet engineering download method can be through Ethernet. The host computer sends multiple hardware bitstream files to the controller, and automatically selects nodes and burns hardware bitstream files through control debugging channels. It can also be downloaded manually through the JTAG interface provided by the controller.
[0149] (6) Real-time hardware debugging. After all hardware bitstream files are downloaded successfully, all core nodes are globally reset. The FPGA hardware can then be debugged during runtime through the JTAG interface provided by the controller. The specific node selection for debugging is controlled by the controller.
[0150] S140: Using the controller to control the plurality of core nodes to be tested to perform simulation.
[0151] Furthermore, S140 may include S141 to S146:
[0152] S141: receiving a load program from each of the core nodes;
[0153] S142: Loading the executable file corresponding to the load program into the storage chip corresponding to the core node through the controller;
[0154] S143: starting the executable file in each of the core nodes through the reset path of the controller;
[0155] S144: Acquire the running information of each of the core-grain nodes when running the executable file;
[0156] S145: After each of the core-grain nodes finishes running the executable file, reading the execution result;
[0157] S146: Uploading the operation information and the execution result to a host computer so that the host computer can analyze the simulation results of each core node.
[0158] Specifically, the control process of the core particle operation is as follows Figure 8 As shown. This embodiment proposes a writing method for multiple core-grain load programs and a communication method between core-grain load programs. This method provides how to load multiple program executable files into corresponding storage locations through data paths, and provides a software monitoring strategy for core-grain runtime. After the operation is completed, the operation data of the core-grain can be further obtained. Specifically, it can be divided into the following steps:
[0159] (1) Write and compile the load program for multiple cores. The writing and compilation of the multi-core load program is completed on the host computer side. Different compilation tool chains may be used to compile separately according to the instruction set architecture of the core. When writing the program, it communicates with other nodes through addresses, and messages can be passed to different core nodes by referring to the address mapping table. When compiling the program, it is necessary to define the starting address and size of the program code memory area of the program, such as by modifying the link script during the compilation process. If multiple cores cannot share the program, the program code memory areas of multiple cores cannot conflict. Multiple cores can also share the same program code and perform different operations by reading the location identification ID.
[0160] (2) Multiple core particle load program is loaded to the core particle platform storage system. According to the above-mentioned core particle program space position, the executable file is loaded to the corresponding core particle storage space in series. The operation is performed by the host computer loading the core particle executable file to the controller, and the controller loads the executable file to the corresponding storage position through the data channel. In this process, the reset channel of the controller keeps each core particle component in a reset non-running state.
[0161] (3) Start the core particle operation. After all the load program executable files are transmitted to the corresponding position, the operation of the core particle component can be started through the reset channel of the controller. After starting, multiple core particle components run in parallel, execute corresponding core particle tasks, and data interaction is generated.
[0162] (4) Operation process monitoring. During the operation of the core particle component, the core particle operation process can be monitored according to the configured core particle peripheral component, such as monitoring the cycle number of the core particle operation. In this process, the core particle can send output information to the controller and the host computer through the virtual peripheral, or receive input information of the controller through the virtual peripheral. The core particle can also write the data it wants to record to the storage space during the operation, and read it after the core particle operation is completed.
[0163] (5) Core particle operation ends. After each core particle operation ends, an end signal can be sent to inform the controller and the host computer, and the process can be realized by the virtual peripheral.
[0164] (6) Read the core particle execution result. When all the core particle operations are completed, the execution result of the core particle can be read, such as exporting the storage space data through the data channel of the controller.
[0165] (7) Analysis of core particle simulation results. According to the process monitoring signal and virtual peripheral information in the process of executing the core particle task, and the exported data after the core particle operation is completed, the simulation results of the core particle are analyzed.
[0166] In summary, the method for designing a core particle simulation platform based on multiple FPGAs provided by the present application effectively guides the design of the core particle simulation platform. Compared with the simulator, the core particle simulation platform and simulation process designed using the method can perform hardware-level verification, obtain more accurate actual core particle behavior, have higher running speed than the core particle simulator, and more easily support various types of core particles. Compared with the traditional FPGA verification platform building method, the method is simpler and more suitable for the design mode of the core particle. At the same time, the method proposes a software and hardware design scheme of the core particle simulation platform, provides perfect software and hardware support for core particle simulation, supports flexible core particles and external design, supports rapid embedding of core particles into the simulation platform to build a core particle system, and supports monitoring and effective data interaction at the software and hardware level during core particle operation.
[0167] The key technical solutions of some embodiments of the present application are as follows:
[0168] 1. A hardware design method of a core grain simulation platform.
[0169] The hardware of the core grain simulation platform adopts a method of simulating core grains by using multiple small-capacity FPGAs. Each FPGA can accommodate a single core grain, and the interconnection delay between the FPGAs can tolerate multiple cycles. Each FPGA can be regarded as a core grain simulation node. The core grain simulation platform built by the method can perform hardware-level verification compared with a simulator, and obtain more accurate actual core grain behavior. Compared with the building method of a traditional FPGA verification platform, the method is simpler and more suitable for the design mode of core grains.
[0170] 2. A controller design method.
[0171] Through a single controller, the hardware bitstream file of the core grain platform and the executable file of the core grain load program can be downloaded, the running control of the core grain platform can be realized, and data transmission and monitoring of the core grain platform can be performed during the running process. The controller uses a heterogeneous processor composed of a hard-core SOC processor part and a programmable logic part. The hard-core SOC processor is responsible for communication with the host computer through an Ethernet high-speed bus, and the programmable part is responsible for data conversion and path selection functions. The external access of the controller includes a data path, a control path, a reset path, and a debugging path.
[0172] 3. A single core grain node design method.
[0173] A single core grain node is composed of a core grain component and an external component to form a complete core grain project. The method realizes the generation of a single core grain platform. The method includes the design of interactive components between core grains, a flexible peripheral support scheme, and a core grain control and monitoring method. Since the combination mode of the core grain component and the external component is relatively fixed in the process, it is more suitable for making configuration software to complete the operation. The configuration software needs to complete the functions of core grain component source selection, core grain interface type selection, configuration router parameter setting, and peripheral type selection.
[0174] 4. A multi-core grain combination generation and download method.
[0175] The multi-core grain project generation and download method realizes the configuration and generation of multiple core grain nodes, and how to insert hardware probes during the generation process and hardware debugging during the running process. The method realizes the automatic download of the executable files of multiple core grain nodes through Ethernet. The method can insert hardware probes in a single core grain node, and the controller can debug the hardware of the core grain node during the running process.
[0176] 5. A core grain running control method.
[0177] The core particle running control method proposes a plurality of core particle load program writing ideas and a communication method between the core particle load programs. The method provides how a plurality of program executable files are loaded to corresponding storage locations through a data path, and provides a software monitoring strategy during core particle running. After running ends, core particle running data can be further obtained.
[0178] Some embodiments of the present application have the following beneficial effects:
[0179] 1. A core particle simulation platform hardware design method.
[0180] Technical solution: a hardware carrier design method suitable for core particle running is provided.
[0181] Beneficial effect: the method of using a plurality of small-capacity FPGAs to simulate core particles is adopted, each FPGA can accommodate a single core particle, and the interconnection delay of the FPGA can tolerate multiple cycles. The core particle simulation platform built by the method has higher running speed than a core particle simulator and is more likely to support various types of core particles. Compared with the traditional FPGA verification platform building method, the method is simpler and more suitable for the design mode of core particles.
[0182] 2. Controller design method.
[0183] Technical solution: a heterogeneous processor is used for implementation, and an upper computer communicates with the controller through Ethernet, and the controller controls the core particle platform. The interaction path of the controller and the core particle platform includes a data path, a monitoring path, a reset path, and a debugging path.
[0184] Beneficial effect: the controller is designed using a heterogeneous processor, which combines the development speed of a hard-core processor and the interface expansion of programmable logic. Through a single controller, the hardware bitstream file of the core particle platform and the core particle load program executable file can be downloaded, the running control of the core particle platform can be realized, and the core particle platform can be controlled and monitored during running.
[0185] 3. Single core particle node design method.
[0186] Technical solution: the design method configures external components for core particle components, including interconnection components, system address mapping components, monitoring components, peripheral components, reset components, etc., and generates a complete single core particle project after configuration. The process can be performed by configuration software.
[0187] Beneficial effect: the method provides a design idea for core particle nodes and realizes the generation of a single core particle platform. The method includes the design of interaction components between core particles, a flexible peripheral support scheme, and a core particle control and monitoring method. The method can be completed by configuration software, and the parameters of peripheral components can be configured. Through the configuration software, the generation of a single core particle platform can be quickly realized.
[0188] 4. A method for generating and downloading multi-core particle combinations.
[0189] Technical solution: The method describes the generation and downloading steps of multi-core particle combinations, and how to insert hardware probes in the generation process, and the hardware debugging method of multi-core particle combinations in the running process.
[0190] Beneficial effects: The method realizes the configuration and generation of multiple core particle nodes. The method can realize the automatic downloading of multiple core particle platform executable files through Ethernet. The method can insert hardware probes in single-core particle engineering and configure the controller to debug the core particle hardware during the running process.
[0191] 5. A core particle running control method.
[0192] Technical solution: The method describes the loading, running strategy and running process monitoring method of the core particle internal program.
[0193] Beneficial effects: The method proposes a writing method for multiple core particle load programs and a communication method between core particle load programs. The method provides how multiple program executable files are loaded to the corresponding storage location through the data path, and provides a software monitoring strategy for the core particle running time. After the running is completed, the running data of the core particle can be further obtained.
[0194] Reference Figure 9 The embodiments of the present application also provide a core particle simulation platform design device, which can realize the above-mentioned core particle simulation platform design method. The device comprises:
[0195] a platform design unit configured to determine a first topology structure of a core particle simulation platform; wherein the first topology structure comprises a controller and a plurality of core particle nodes;
[0196] a controller design unit configured to determine a second topology structure of the controller; wherein the controller is configured to realize running control of the core particle simulation platform;
[0197] a core particle design unit configured to determine a third topology structure of each of the core particle nodes; wherein each of the core particle nodes comprises a core particle component and an external component;
[0198] a core particle configuration unit configured to configure a plurality of core particle nodes to be tested in the core particle simulation platform;
[0199] a core particle simulation unit configured to control the plurality of core particle nodes to be tested to perform simulation by using the controller.
[0200] It can be understood that the contents in the above method embodiments are all applicable to the device embodiments, the device embodiments specifically implement the functions same as those of the above method embodiments, and achieve the same beneficial effects as those of the above method embodiments.
[0201] The electronic device provided in the embodiment of the present application includes a memory and a processor. The memory stores a computer program. The processor implements the above method for designing a core simulation platform when executing the computer program. The electronic device can be any smart terminal including a tablet computer, a vehicle-mounted computer, etc.
[0202] It can be understood that the contents in the above method embodiments are all applicable to the device embodiments, the device embodiments specifically implement the functions same as those of the above method embodiments, and achieve the same beneficial effects as those of the above method embodiments.
[0203] Please refer to Figure 10 , Figure 10 The hardware structure of the electronic device of another embodiment is illustrated, and the electronic device includes:
[0204] The processor 1001 can be implemented in a general-purpose CPU (Central Processing Unit), a microprocessor, an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits, etc., and is used to execute related programs to implement the technical solutions provided in the embodiments of the present application.
[0205] The memory 1002 can be implemented in the form of a ROM (Read Only Memory), a static storage device, a dynamic storage device, or a RAM (Random Access Memory), etc. The memory 1002 can store an operating system and other application programs. When the technical solutions provided in the embodiments of the present application are implemented by software or firmware, the related program codes are stored in the memory 1002 and are called and executed by the processor 1001 to implement the method for designing a core simulation platform.
[0206] The input / output interface 1003 is used to realize information input and output.
[0207] The communication interface 1004 is used to realize the communication interaction between the device and other devices. The communication can be realized in a wired manner (for example, USB, network cable, etc.) or in a wireless manner (for example, mobile network, WIFI, Bluetooth, etc.).
[0208] A bus 1005 transmits information between the various components in the device, such as the processor 1001, the memory 1002, the input / output interface 1003, and the communication interface 1004.
[0209] The processor 1001, the memory 1002, the input / output interface 1003, and the communication interface 1004 are communicatively connected to each other within the device through the bus 1005.
[0210] The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the core particle simulation platform design method.
[0211] It can be understood that the contents in the above method embodiments are applicable to the storage medium embodiments, the storage medium embodiments specifically implement the functions of the above method embodiments, and achieve the same beneficial effects as the above method embodiments.
[0212] The memory is a non-transitory computer readable storage medium, which can be used to store non-transitory software programs and non-transitory computer executable programs. In addition, the memory can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory can optionally include a memory remotely arranged relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.
[0213] The embodiments described in the embodiments of the present application are used to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art can know that, with the evolution of technology and the appearance of new application scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.
[0214] Those skilled in the art can understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and can include more or fewer steps than the figures shown, or combine certain steps, or different steps.
[0215] The device embodiments described above are only schematic, and the units described as separate components can or can not be physically separate, that is, can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of the present application.
[0216] Those skilled in the art can understand that all or some of the steps in the method disclosed above, the function modules / units in the system and the device can be implemented as software, firmware, hardware or appropriate combination thereof.
[0217] The terms "first", "second", "third", "fourth" and the like in the description of the application and in the claims, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the use of these terms herein is to be construed to cover a changeable order, arrangement, grouping, composition or structure.
[0218] It should be understood that, in the present application, "at least one" means one or more, and "multiple" means two or more. "And / or" is used to describe the relationship between the associated objects, which means that there can be three relationships, for example, "A and / or B" can represent three cases: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects. "At least one of the following" or the like means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0219] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the above units is only a logical function division, and actual implementation can have another division manner. For example, multiple units or components can be combined or integrated into another system, or some features can be omitted or not implemented. In addition, the coupling or direct coupling or communication connection between the displayed or discussed objects can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0220] The units described as separate components above can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.
[0221] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.
[0222] If the integrated unit is realized in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application, essentially or the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes multiple instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program storage media.
[0223] The preferred embodiments of the embodiments of the present application are described above with reference to the accompanying drawings, and are not limited to the scope of the embodiments of the present application. Any modifications, equivalent replacements and improvements made by those skilled in the art without departing from the scope and essence of the embodiments of the present application shall be within the scope of the embodiments of the present application.
Claims
1. A method for designing a core particle simulation platform, characterized in that: The method comprises the following steps: Determine a first topology structure of a chiplet simulation platform; wherein the first topology structure includes a controller and a plurality of chiplet nodes; Determining a second topology of the controller; wherein the controller is used to implement operation control of the core particle simulation platform; Determining a third topological structure of each of the core-grain nodes; wherein each of the core-grain nodes includes a core-grain component and an external component; Configuring a plurality of the core-grain nodes to be tested in the core-grain simulation platform; Using the controller to control the plurality of core particle nodes to be tested to perform simulation; Determining the second topology of the controller comprises the following steps: Determining the external paths of the controller; wherein the external paths include a data path, a monitoring path, a reset path, and a debug path; The data path is set as a first on-chip network; wherein the data path is used to connect each of the chip nodes; transmit the executable file of each of the chip nodes to the corresponding memory chip; after the chip ends running, provide the data of the memory chip to the controller; The monitoring path is set as a second on-chip network; wherein the monitoring path is used to obtain data from the monitoring module and transmit data of the virtual peripheral; the monitoring path is sent from the host computer to the controller via Ethernet, and then forwarded to the programmable logic by the controller, and the programmable logic is sent to each of the chip nodes after protocol conversion of the second on-chip network; The reset path includes a first reset path of the chiplet simulation platform and a second reset path of each chiplet node; wherein the controller uses corresponding reset signals to control the reset of multiple chiplet nodes and the reset of a single chiplet node through the first reset path and the second reset path respectively; The debug path is configured to include a first debug path of the hard-core processor and a second debug path of the JTAG interface; wherein the debug path is used to provide a programming and debugging path for each of the chip nodes; the first debug path is used to transmit the hardware bitstream file of each of the chip nodes from Ethernet to the cache of the controller, and then the programmable logic converts the hardware bitstream file into a JTAG signal; the second debug path is used to program the hardware bitstream file through an external JTAG debugger; Configuring a plurality of the chiplet nodes to be tested in the chiplet simulation platform comprises the following steps: Determine an address mapping table according to the position of each of the core grain nodes; Selecting a core particle component to be tested from each of the core particle nodes and configuring an external component for the core particle component; Inserting a test probe into each of the configured core grain nodes to generate a core grain project; Generate a hardware bitstream file according to the core grain project; The hardware bitstream file is downloaded to the chip simulation platform for testing.
2. A method for designing a core particle simulation platform according to claim 1, characterized in that: Determining the first topology of the core particle simulation platform includes the following steps: Determining the number and topological relationship of each of the core particle nodes; determining the type and location of the controller; Determining the spatial size and position of the storage chip of each of the core particles; Determine the control signals and interconnection methods of each of the core particle nodes.
3. A method for designing a core particle simulation platform according to claim 2, characterized in that: The method further comprises the following steps: The peripheral circuits of each of the core nodes are arranged in the first topology structure.
4. The method for designing a core particle simulation platform according to claim 1, wherein: Determining a third topological structure of each of the core-grain nodes, wherein each of the core-grain nodes includes a core-grain component and an external component, comprises the following steps: Setting the type of the core particle component and the interface of each type for each core particle node; Setting the type of the external components of each of the core node; wherein the external components include an interconnect component, an address mapping component, a monitoring component, a peripheral component and a reset component; The interconnection component includes a first on-chip network router and a second on-chip network router; the first on-chip network router is connected to the data path of the chip node, serves as the adapter interface of the chip component, and communicates with the chip components in other adjacent chip nodes; the second on-chip network router is used to transmit information of the monitoring component and the peripheral component to the controller; The address mapping component is used to record the physical location identification ID of each core node and the mapping relationship between the physical location identification ID and the physical access address; The monitoring component is used to monitor the operating status of each of the core grain nodes and the operating status of the core grain components; The peripheral components include real peripherals and virtual peripherals; wherein the real peripherals are preset during the design of the chiplet simulation platform; the virtual peripherals use the programmable logic resources in the FPGA to simulate the input and output of each chiplet node; The reset component is used to connect to the reset path in the controller.
5. A method for designing a core particle simulation platform according to any one of claims 1 to 4, characterized in that: The method of using the controller to control the plurality of core nodes to be tested to perform simulation includes the following steps: receiving a load program from each of the core node; Loading the executable file corresponding to the load program into the storage chip corresponding to the core grain node through the controller; Starting the executable file in each of the core nodes through a reset path of the controller; Obtaining operation information of each of the core grain nodes when running the executable file; After each of the core grain nodes finishes running the executable file, reading the execution result; The operation information and the execution result are uploaded to a host computer so that the host computer can analyze the simulation results of each core particle node.
6. A core particle simulation platform design device, characterized in that: The device is applied to a core particle simulation platform design method according to claim 1, and the device comprises: A platform design unit, configured to determine a first topology of a core particle simulation platform; wherein the first topology includes a controller and a plurality of core particle nodes; A controller design unit, configured to determine a second topology of the controller; wherein the controller is configured to implement operational control of the core particle simulation platform; A core particle design unit, configured to determine a third topological structure of each of the core particle nodes; wherein each of the core particle nodes includes a core particle component and an external component; A core particle configuration unit, configured to configure a plurality of core particle nodes to be tested in the core particle simulation platform; The core particle simulation unit is used to control the plurality of core particle nodes to be tested to perform simulation using the controller.
7. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 5 when executing the computer program.
8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.
Citation Information
Patent Citations
Network-on-chip simulation system for multi-core-particle combined chip
CN115460128A
Multi-core particle interconnection simulation method and device, storage medium and electronic equipment
CN117236263A