Virtual prototype deployment system and method, electronic equipment and storage medium

Abstract

The invention discloses a virtual prototype deployment system and method, electronic equipment and a storage medium, and relates to the technical field of chip emulation.The method comprises the steps that a root node maintains a shared file locally; the main node locally stores a virtual prototype mother disk mirror image and a service code file in the shared file, and accesses other files in the shared file by mounting a root node path; the slave node locally stores a virtual prototype mother disk mirror image, accesses a service code file by mounting a main node path, and accesses other files by mounting a root node path; the root node sends the virtual prototype deployment request to a target node based on a preset lightweight message transmission protocol so as to respond to the virtual prototype deployment request based on the target node; and the root node is also used for configuring service types of the master nodes and the slave nodes, so that the master nodes and the slave nodes call service starting interfaces, and target service modules are started according to the service types. The technical effects of realizing the virtual prototype deployment system which is simple in deployment process and low in operation and maintenance cost are achieved.

Description

Technical Field

[0001] This application relates to the field of chip simulation technology, and in particular to virtual prototype deployment systems, methods, electronic devices and storage media. Background Technology

[0002] In the field of chip design verification, the integration of virtualization technology and cloud architecture has brought revolutionary breakthroughs to Virtual Prototype (VP) simulation. Researchers can leverage virtual simulation environments to complete software ecosystem verification and optimization before physical chip samples are put into production, significantly shortening product development cycles. The introduction of cloud-native technologies further strengthens this advantage, enabling simulation tasks from multiple project teams to achieve parallel computing through distributed clusters. This improves hardware resource utilization and meets the throughput requirements of complex System-on-Chip (SoC) chips for massive test cases. OpenStack, as an open-source cloud computing platform, can be used for the deployment of virtual prototypes.

[0003] However, OpenStack has a complex deployment process and high maintenance costs, making it unsuitable for deploying small to medium-sized virtual prototypes. Summary of the Invention

[0004] This application provides a virtual prototype deployment system, method, electronic device, and storage medium to at least solve the problems of complex deployment processes, high operation and maintenance costs, and unsuitability for deploying small and medium-sized virtual prototypes in related technologies.

[0005] This application provides a virtual prototype deployment system, including a root node and multiple master-slave clusters, wherein the master-slave clusters include a master node and multiple slave nodes; The root node is used to maintain shared files locally; shared files include virtual prototype master image, business code files, basic service dependency packages, and user data packages; The master node is used for local storage of the virtual prototype master disk image and business code files in the shared files, and accesses the basic service dependency packages and user data packages by mounting the root node path; The slave node is used for local storage of the virtual prototype master disk image in the shared files. It accesses business code files by mounting the master node path and accesses basic service dependency packages and user data packages by mounting the root node path. The root node is also used to obtain the virtual prototype deployment request sent by the user, and based on the preset lightweight message transmission protocol, send the virtual prototype deployment request to the target node in the target master-slave cluster whose subscribed topic matches the topic of the virtual prototype deployment request, so as to respond to the virtual prototype deployment request based on the target node. The root node is also used to configure the business types of each master node and slave node, so that each master node and slave node can determine the target business code in the business code file according to the business type and run the target business code to start the target business module.

[0006] This application also provides a virtual prototype deployment method, applicable to any of the above-mentioned virtual prototype deployment systems, comprising: Based on the root node, shared files are maintained locally; the shared files include the virtual prototype master image, business code files, basic service dependency packages, and user data packages; Based on the master node, the virtual prototype master disk image and business code files in the shared files are stored locally, and the basic service dependency packages and user data packages are accessed by mounting the root node path. Based on the slave node, the virtual prototype master disk image in the shared files is stored locally. Business code files are accessed by mounting the master node path, and basic service dependency packages and user data packages are accessed by mounting the root node path. Based on the root node, the virtual prototype deployment request sent by the user is obtained. Based on the preset lightweight message transmission protocol, the virtual prototype deployment request is sent to the target node in the target master-slave cluster whose subscribed topic matches the topic of the virtual prototype deployment request, so as to respond to the virtual prototype deployment request based on the target node. Based on the root node, configure the business types of each master node and slave node so that each master node and slave node can determine the target business code in the business code file according to the business type, and run the target business code to start the target business module. This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the virtual prototype deployment method described above when executing the computer program.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described virtual prototype deployment method.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described virtual prototype deployment method.

[0009] Through this application, the system includes a root node and multiple master-slave clusters, with each master-slave cluster consisting of a master node and multiple slave nodes. The root node is used to maintain shared files locally. These shared files include a virtual prototype master image, business code files, basic service dependency packages, and user data packages. The master node is used to locally store the virtual prototype master image and business code files in the shared files, and access the basic service dependency packages and user data packages by mounting the root node path. The slave nodes are also used to locally store the virtual prototype master image in the shared files, and access the business code files by mounting the master node path, and access the basic service dependency packages and user data packages by mounting the root node path. The root node is also used to obtain virtual prototype deployment requests sent by users, and based on a preset lightweight message transmission protocol, to send the virtual prototype deployment requests to target nodes in the target master-slave cluster whose subscription topics match the topic of the virtual prototype deployment request, so that the target nodes can respond to the virtual prototype deployment requests. The root node is also used to configure the business types of each master node and slave node, so that each master node and slave node can determine the target business code in the business code file according to the business type, and run the target business code to start the target business module. By integrating traditional distributed nodes into a system with root, master, and slave nodes, and combining mounting and local storage mechanisms, users only need to maintain shared files through the root node to achieve automatic data synchronization between master and slave nodes, significantly reducing operational complexity and technical barriers. Based on a pre-defined lightweight message transmission protocol, precise allocation of virtual prototype deployment requests is achieved, flexibly responding to sudden high-concurrency simulation demands. Therefore, this solution addresses the technical problems of complex deployment processes, high operational costs, and unsuitability for deploying small to medium-sized virtual prototypes in related technologies, achieving a virtual prototype deployment system with a simple deployment process, low operational costs, and suitability for small to medium-sized virtual prototypes. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the structure of a virtual prototype deployment system provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the implementation of shared file sharing in an embodiment of this application; Figure 3 A schematic diagram illustrating the principle of MQTT shared subscription provided in the embodiments of this application; Figure 4 A flowchart illustrating the workflow of the service startup interface provided in this application embodiment; Figure 5 A schematic diagram of the structure of yet another virtual prototype deployment system provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of another virtual prototype deployment system provided in an embodiment of this application; Figure 7 A flowchart illustrating a virtual prototype deployment method provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] In the field of chip design verification, the integration of virtualization technology and cloud architecture has brought revolutionary breakthroughs to VP simulation. VP is a rapid simulation platform for electronic systems, used for software development, integration, testing, and verification. R&D personnel can leverage the virtualized simulation environment to complete software ecosystem verification and optimization before physical chip samples are put into production, significantly shortening product development cycles. The introduction of cloud-native technologies further strengthens this advantage, enabling simulation tasks from multiple project teams to achieve parallel computing through distributed clusters. This improves hardware resource utilization and meets the throughput requirements of complex system-on-chips for massive test cases.

[0016] OpenStack, as an open-source cloud computing platform, aims to provide software for the construction and management of public and private clouds, and is used for the deployment of virtual prototypes in related technologies. The OpenStack architecture includes several independent projects, such as Manlina (shared file management), Glance (image file management), Neutron (network services), Octavia (load balancing), and Cinder (block storage services). Manlina is OpenStack's shared file storage service component, used to create and manage shared file systems; Glance is OpenStack's image management service component, responsible for storing, discovering, and managing virtual machine images; Octavia is OpenStack's load balancing service component, providing a highly available and scalable load balancing solution for the OpenStack platform; Neutron is OpenStack's network service component, responsible for managing virtual networks; and Cinder is OpenStack's block storage service, providing persistent storage for virtual machine instances.

[0017] Because the Open Stack architecture comprises multiple independent projects, each with unique configuration and management requirements, it performs exceptionally well in large-scale virtual prototyping deployment scenarios. However, due to the complexity of the deployment process and high operational costs associated with multiple independent projects, it results in redundant projects in small to medium-sized virtual prototyping deployment scenarios, making it less cost-effective and inefficient. Therefore, it is not suitable for small to medium-sized virtual prototyping deployment scenarios.

[0018] To address the aforementioned issues, this application provides a virtual prototype deployment system, method, electronic device, and storage medium. The system includes a root node and multiple master-slave clusters, each cluster comprising a master node and multiple slave nodes. The root node maintains shared files locally. These shared files include a virtual prototype master image, business code files, basic service dependency packages, and user data packages. The master nodes locally store the virtual prototype master image and business code files within the shared files and access the basic service dependency packages and user data packages via the root node's path. The slave nodes also locally store the virtual prototype master image within the shared files and access the business code files via the master node's path and the basic service dependency packages and user data packages via the root node's path. The root node further acquires virtual prototype deployment requests sent by users and, based on a preset lightweight messaging protocol, sends these requests to target nodes in the target master-slave cluster whose subscription topics match the virtual prototype deployment request's topic, thus responding to the virtual prototype deployment request based on the target node's response. The root node also configures the business types of each master node and slave node, enabling each master node and slave node to determine the target business code in the business code file according to the business type and run the target business code to start the target business module. The system provided by the above solution integrates traditionally distributed nodes into a system with distinct roles: root node, master node, and slave node. Combined with mounting and local storage mechanisms, users only need to maintain shared files through the root node to achieve automatic data synchronization between master and slave nodes, significantly reducing operational complexity and technical barriers. Based on a preset lightweight message transmission protocol, it achieves precise allocation of virtual prototype deployment requests, flexibly responding to sudden high-concurrency simulation demands. Therefore, it solves the technical problems of complex deployment processes, high operational costs, and unsuitability for deploying small and medium-sized virtual prototypes in related technologies, achieving a system with a simple deployment process, low operational costs, and suitability for deploying small and medium-sized virtual prototypes.

[0019] Embodiments of this application provide a virtual prototype deployment system. Figure 1 This is a schematic diagram of the structure of the virtual prototype deployment system provided in the embodiments of this application, as shown below. Figure 1 As shown, the virtual prototype deployment system includes a root node and multiple master-slave clusters, with each master-slave cluster consisting of a master node and multiple slave nodes.

[0020] The root node is used to maintain shared files locally; shared files include virtual prototype master image, business code files, basic service dependency packages, and user data packages.

[0021] The root node serves as the global management center, used to maintain shared files locally. That is, shared files are stored locally on the root node. The virtual prototype master image is used for the initial loading and running of the virtual prototype. Business code files include various applications and scripts that support system operation. Basic service dependency packages include the basic software packages and libraries required for system operation. User data packages include user personal data and configuration information.

[0022] The master node is used for local storage of the virtual prototype master disk image and business code files in the shared files, and accesses the basic service dependency packages and user data packages by mounting the root node path.

[0023] Figure 2 This is a schematic diagram illustrating the implementation of shared file sharing in an embodiment of this application, as shown below. Figure 2 As shown, the root node locally stores shared files. Basic service dependency packages and user data packages in these shared files are infrequently accessed data. The master node uses a Network File System (NFS) to mount the root node's path, enabling access to these packages. The VP master disk image and business code files are frequently accessed data. To improve system efficiency and reduce the load on the root node, the master node copies the VP master disk image and business code files from the root node's shared files and caches them locally. This ensures data consistency and integrity between the master and root nodes.

[0024] NFS is a distributed file system protocol primarily used for sharing files and directories between different computers over a network.

[0025] The slave node is used for local storage of the virtual prototype master disk image in the shared files. It accesses business code files by mounting the master node path and accesses basic service dependency packages and user data packages by mounting the root node path.

[0026] like Figure 2 As shown, the slave node uses NFS to mount the root node path, enabling access to basic service dependency packages and user data packages in the shared files stored on the root node. The slave node copies the VP master disk image from the root node's shared files and caches it locally. Since the master node bears the primary responsibility for business traffic distribution, the slave node uses NFS to mount the master node path, enabling access to the business code files stored on the master node. This ensures data consistency and integrity between the slave node and the root node.

[0027] The root node is also used to obtain virtual prototype deployment requests sent by users, and based on a preset lightweight messaging protocol, send the virtual prototype deployment requests to the target nodes in the target master-slave cluster whose subscribed topics match the topic of the virtual prototype deployment requests, so as to respond to the virtual prototype deployment requests based on the target nodes.

[0028] The default lightweight message transmission protocol is Message Queuing Telemetry Transport (MQTT), a lightweight, publish / subscribe-based message transmission protocol. In MQTT, the Broker is the core component of the message middleware, responsible for receiving messages from clients and distributing them to other clients subscribed to the corresponding topics. In this embodiment, the Broker is the root node. The root node receives virtual prototype deployment requests (i.e., messages) sent by users through clients and, based on the shared subscription function in the MQTT protocol, sends the virtual prototype deployment request to the target node in the target master-slave cluster whose subscribed topic matches the topic of the virtual prototype deployment request, so that the target node can respond to the virtual prototype deployment request.

[0029] Shared subscriptions are an important feature introduced in MQTT 5.0, allowing multiple clients to share the same subscription topic. In this embodiment, the master and slave nodes in each master-slave cluster share a single subscription topic. Different master-slave clusters will have different subscription topics.

[0030] Understandably, multiple nodes form a consumer group by subscribing to the same shared group name (e.g., group1). The MQTT Broker (root node) distributes messages to the nodes within the group according to a load balancing strategy. Shared subscription topics are typically named... The name of the shared group starts with `share / {group} / {topic}`, where `{group}` is the name of the shared group (e.g., `group1`) and `{topic}` is the actual topic subscribed to (e.g., `topic_x`). Example: "share / group1 / topic_x". The Broker distributes messages according to the configured strategy, common strategies include round-robin, random, etc. Figure 3 This is a schematic diagram illustrating the principle of MQTT shared subscription provided in the embodiments of this application, as follows: Figure 3 As shown, the publisher published three messages, msg1, msg2, and msg3, to the topic topic_x. Nodes a, b, and c subscribed to the topic. The message "share / group1 / topic_x" received messages msg1, msg3, and msg2 respectively. This ensures that each message is received and processed by only one node, thereby achieving message load balancing.

[0031] The root node is also used to configure the business types of each master node and slave node, so that each master node and slave node can determine the target business code in the business code file according to the business type and run the target business code to start the target business module.

[0032] All nodes adhere to the UNIX file standard, establishing a unified resource configuration system. / home / system / ├── 80_local / # Node-specific configuration area │└── service.conf# Business module configuration file └── 20_business / # Platform Business Processing Module (NFS Mount) │├── MODULE_A#Business Processing Module A │├── MODULE_B#Business Processing Module B │├── ... └── ... The root node configures the service type of the master and slave nodes by modifying the service module identifier in the service module configuration files of the master and slave nodes, specifically by modifying the service module identifier in 80_local / service.conf. The service type of the master and slave nodes in each master-slave cluster is the same.

[0033] The master node and slave node call the business startup interface, determine the target business code in the business code file according to the business type, and run the target business code to start the target business module, so that different nodes can focus on different simulation tasks.

[0034] It provides a unified business startup interface for all nodes. By abstracting the coupling relationship between business logic and startup configuration, it achieves a modular design that allows changes to business code files to avoid refactoring the startup framework, enabling rapid expansion of business types and computing nodes.

[0035] The virtual prototype deployment system provided in this application adopts a root-master-slave (RMS) architecture. By integrating traditionally distributed nodes into a system with roles for root, master, and slave nodes, and combining mounting and local storage mechanisms, users only need to maintain shared files through the root node to achieve automatic data synchronization between master and slave nodes, significantly reducing operational complexity and technical barriers. Meanwhile, the master node, as the core of business traffic distribution, significantly reduces the IO pressure on the root node by caching frequently accessed VP master disk images and business code files locally, exceeding 40%. Combined with an NFS shared mounting strategy for low-frequency data, it optimizes the load on the root node while improving resource utilization. Based on the dynamic horizontal scaling capability of slave nodes and a preset lightweight message transmission protocol, it achieves precise allocation of virtual prototype deployment requests, flexibly responding to sudden high-concurrency simulation demands. Therefore, it solves the technical problems of complex deployment processes, high operational costs, and unsuitability for deploying small and medium-sized virtual prototypes in related technologies, achieving a virtual prototype deployment system with simple deployment processes, low operational costs, and suitability for deploying small and medium-sized virtual prototypes. The RMS architecture uses a root node as the core hub, multiple master nodes for collaborative processing, and multiple slave nodes for elastic scaling. Through intelligent service traffic routing, hierarchical data management, and dynamic scaling, it achieves high availability, high performance, and scalability. The master nodes, acting as the shared NFS hub, can independently support slave node operation even in the event of a root node failure, forming a multi-level disaster recovery capability and comprehensively improving system availability. High-frequency and low-frequency access data employ different data synchronization mechanisms, balancing performance and storage efficiency.

[0036] In some alternative implementations, the root node is specifically used for: Based on the virtual prototype deployment request, determine the target topic in the virtual prototype deployment request.

[0037] Based on the target topic, determine the target business type corresponding to the target topic.

[0038] Based on the target business type, update the target topic in the virtual prototype deployment request to the subscription topic of the target master-slave cluster corresponding to the target business type.

[0039] Based on a preset polling strategy, virtual prototype deployment requests are sent to target nodes in the target master-slave cluster, where the target node can be either the target master node or the target slave node.

[0040] For any master-slave cluster, the master and slave nodes in the cluster have the same subscribed topics and the same business types; different master-slave clusters have different subscribed topics.

[0041] Understandably, the root node identifies the target topic in the virtual prototype deployment request to achieve business-level and module-level message routing, that is, to determine the target master-slave cluster and the target node in the target master-slave cluster that match the message.

[0042] The root node is also used to validate virtual prototype deployment requests via JSON format to intercept illegal messages.

[0043] It should be noted that the master and slave nodes are also used to identify the target topic in the virtual prototype deployment request upon receiving it, and to perform topic verification to ensure that the target topic of the received virtual prototype deployment request is consistent with the subscribed topic. They are also used to verify the virtual prototype deployment request via JSON format to intercept illegal messages.

[0044] It should be noted that an AI prediction model can also be embedded in the root node. This AI prediction model is used to dynamically adjust the allocation strategy of virtual prototype deployment requests based on historical virtual prototype deployment requests and their corresponding allocated nodes.

[0045] The virtual prototype deployment system provided in this application ensures that deployment requests are accurately distributed to the corresponding master-slave clusters by using a single-layer mapping of topics, business types, and clusters. Deployment requests are allocated within the cluster based on a round-robin strategy, ensuring load balancing, avoiding single-node overload, and improving resource utilization. Different master-slave clusters subscribe to different processing methods to handle different business types, achieving logical isolation between services and enhancing system stability. Nodes within the same cluster subscribe to the same topic, handling similar businesses; newly added nodes can quickly connect and take over tasks, simplifying the expansion process.

[0046] In some alternative implementations, the target node is specifically used for: Receive a virtual prototype deployment request and determine whether the target virtual prototype master disk image corresponding to the virtual prototype deployment request is stored locally.

[0047] If the target virtual prototype master image corresponding to the virtual prototype deployment request is not stored locally, the target virtual prototype master image is obtained from the shared file of the root node and stored locally.

[0048] Determine whether the hash value of the target virtual prototype master disk image stored locally is consistent with the hash value of the target virtual prototype master disk image stored in the image index table.

[0049] The image index table records the mapping relationship between the virtual prototype master image and the virtual prototype. The image index table also records the business type of each virtual prototype master image, the type identifier of the corresponding virtual prototype, the image file name, and the hash value.

[0050] If they match, then create the target virtual prototype based on the target virtual prototype master image.

[0051] It should be noted that the hash value of the target virtual prototype master image stored locally can be determined using the MD5 function. MD5 (Message-Digest Algorithm 5) is a hash function that can convert task-length data into a fixed-length hash value (such as 128 bits, or 32 hexadecimal characters).

[0052] Understandably, a target virtual prototype is created based on the target virtual prototype master image stored locally.

[0053] The virtual prototype deployment system provided in this application embodiment ensures data consistency and achieves second-level synchronization efficiency through the verification mechanism of the VP master disk image, thereby improving the deployment efficiency of VP.

[0054] In some alternative implementations, the target node is also used for: If the target virtual prototype master disk image corresponding to the virtual prototype deployment request exists in local storage, then determine whether the hash value of the target virtual prototype master disk image stored locally is consistent with the hash value of the target virtual prototype master disk image stored in the image index table.

[0055] If they match, then create the target virtual prototype based on the target virtual prototype master image.

[0056] Understandably, if they don't match, the latest target virtual prototype master image is retrieved from the shared files of the root node and stored locally. It is then determined whether the hash value of the latest target virtual prototype master image stored locally matches the hash value of the target virtual prototype master image stored in the image index table. If they match, the target virtual prototype is created based on the latest target virtual prototype master image.

[0057] The virtual prototype deployment system provided in this application accelerates the virtual prototype creation process by prioritizing the use of locally stored images, eliminating repeated downloads, reducing network transmission and root node access pressure, and strictly verifying the consistency between the local image and the baseline version through hash value comparison, thus avoiding errors in chip simulation results due to differences in image versions.

[0058] In some optional implementations, the root node is also used to respond to an update of any virtual prototype master image by sending an update message of the virtual prototype master image to each master node and slave node. The update message includes the service type of the virtual prototype master image, the type identifier of the corresponding virtual prototype, the image file name, and the hash value.

[0059] Understandably, technicians create or update the virtual prototype master image at the root node. When the root node sends the update message of the virtual prototype master image to each master and slave node, it uses an agreed-upon image update publication topic to ensure that each master and slave node receives the update message of the virtual prototype master image.

[0060] The mirror update release topic can be as follows: Mirror update release topic: Notice / Update / VP_IMG Message content: { Action: "Update VP Images" VP_IMG_List:[ { Project: "Project_A" VP_Type: "A_daily_16disk", IMG_Name: "A_VP_Base.img", Hash: "7f8b9a2d3e4c5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a", ... }, { Project: "Project_B" ... } ] } The master and slave nodes are also used to receive update messages and determine whether the update messages conform to the preset specifications. If the update message conforms to the preset specifications, the local mirror index table is updated based on the update message. If the update message does not conform to the preset specifications, it is discarded directly.

[0061] The preset specification can be an update message in the form of key-value pairs.

[0062] It should be noted that a mirror update evidence storage chain can be built using blockchain to ensure the immutability of data changes and the ability to audit and trace the source.

[0063] The virtual prototype deployment system provided in this application embodiment synchronizes key image information through update messages at the root node, and updates the local image index table based on the update messages at the master and slave nodes. This allows for real-time alignment with the base image version of the root node, avoiding deviations in chip simulation results due to differences in node image versions and ensuring cluster data consistency. The master and slave nodes first verify whether the update messages conform to preset specifications, discarding non-compliant messages. This prevents invalid or erroneous update instructions from interfering with the local image index table, preventing index chaos and erroneous image updates caused by abnormal messages, and enhancing the system's anti-interference capability.

[0064] In some optional implementations, the root node is also used to respond to updates to the business code files by uploading the updated business code files to the target repository and sending business code update messages to each master node and slave node.

[0065] The target repository can be a Git repository. Git is an open-source distributed version control system used to track changes to files and directories. It allows teams to collaborate on project development, manage code version history, and support various workflows.

[0066] When the root node sends the business code update message to each master node and slave node, it uses the agreed business code update publication topic to ensure that each master and slave node receives the business code update message.

[0067] For example, a business code update release topic looks like this: Business code update release topic: Notice / Update / Code Message content: { Action: "Update Code" Module_List:[Module_A, Modeule_B,...] } The master and slave nodes are also used to receive business code update messages, retrieve the updated business code files from the target repository, and restart the corresponding target business module based on the updated business code files.

[0068] Understandably, each master node and slave node determines the updated target business code in the updated business code file according to the business type, and runs the updated target business code to restart the corresponding target business module.

[0069] The virtual prototype deployment system provided in this application embodiment ensures data consistency between nodes through Git-MQTT linkage updates of business code files.

[0070] In some alternative implementations, the master node and slave node are also used for: Call the business startup interface to clean up the environment of the master and slave nodes.

[0071] Start the basic services of the master and slave nodes based on the basic service dependency packages.

[0072] Figure 4 The flowchart of the service startup interface provided in the embodiments of this application is as follows: Figure 4 As shown, calling the business startup interface first cleans up the environment. This cleanup process includes: obtaining the process kill table, polling the process kill table, killing processes, and ending the process kill process. Next, basic services are started, including MQTT and MySQL services, through their dependencies. Then, the local configuration file is read to obtain the business type, and the relevant business modules are started. Essentially, by reading the business module configuration file from the local configuration file, the business type is obtained; based on the business type, the target business code is determined in the business code file; and the target business code is run to start the target business module.

[0073] The virtual prototype deployment system provided in this application can clear historical residual data, old configurations, or abnormal processes by cleaning the node environment, avoiding interference from preceding tasks with the operation of new services, ensuring that virtual prototype simulation starts in an environment free of redundant interference, and reducing business anomalies caused by environmental conflicts. Starting basic services based on basic service dependency packages ensures that the underlying software versions required for node operation are consistent and functionally complete, providing a stable operating foundation for upper-layer chip simulation services and avoiding service startup failures due to missing dependencies or version incompatibility. The system automates "environment cleanup + basic service startup" through a unified business startup interface, eliminating the need for manual operation, improving node startup efficiency, and lowering the operational threshold.

[0074] In some alternative implementations, the root node is also used for: Real-time monitoring of the heartbeat status of each master node and slave node.

[0075] If a heartbeat timeout is detected on any node, that node is marked as faulty, and any virtual prototype deployment requests being executed on that node are migrated to other normal nodes within the same master-slave cluster.

[0076] After migrating the virtual prototype deployment request currently being executed on that node to another normal node within the same master-slave cluster, a restart command is sent to that node to restart it. If the node restarts successfully, its ability to process virtual prototype deployment requests is restored.

[0077] The virtual prototype deployment system provided in this application embodiment promptly detects faulty nodes through real-time heartbeat monitoring, preventing faulty nodes from continuously occupying task resources and ensuring uninterrupted virtual prototype deployment tasks. Tasks on the faulty node are migrated to normal nodes in the same cluster to prevent chip simulation tasks from failing or data loss due to single-node failure. A restart command is automatically sent to the faulty node, restoring its task processing capability upon successful restart, reducing manual intervention, lowering operation and maintenance costs, and improving the level of automated operation and maintenance of the cluster.

[0078] This application also provides a virtual prototype deployment system. Figure 5 This is a schematic diagram of the structure of the virtual prototype deployment system provided in the embodiments of this application, as shown below. Figure 5 As shown, the virtual prototype deployment system includes a root node and multiple master-slave clusters. The diagram uses two master-slave clusters, cluster A and cluster B, as an example. Each master-slave cluster includes a master node and multiple slave nodes. The master and slave nodes in each cluster are used to handle the same type of business, such as... Figure 5 As shown, master-slave cluster A is used to handle business type A, and master-slave cluster B is used to handle business type B.

[0079] The root node, acting as the global management center, is responsible for the centralized maintenance of shared files, data persistence in the database cluster, and MQTT message routing. See the preceding description of the root node for details, which will not be repeated here. The root node determines the target master-slave cluster for processing virtual prototype deployment requests (tasks) based on the business type. Using a load balancing strategy, namely the aforementioned pre-defined round-robin strategy, it identifies the target node within the target master-slave cluster to distribute the virtual prototype deployment request to the target node, thus responding to the virtual prototype deployment request based on the target node's response. In other words, the node processing the virtual prototype deployment request can be either a master node or a slave node.

[0080] The master node, as the business processing unit, is used to share more than 40% of the I / O load with the root node. See the preceding description of the master node for details, which will not be repeated here.

[0081] Slave nodes serve as elastic computing units, used for parallel computing (i.e., executing simulation tasks in parallel), and also to provide a simulation sandbox environment for each simulation task. Slave nodes support horizontal dynamic scaling to extend cluster capabilities.

[0082] The virtual prototype deployment system provided in this application integrates traditionally distributed nodes into a system with root, master, and slave nodes, combining mounting and local storage mechanisms. Users only need to maintain shared files through the root node to achieve automatic data synchronization between master and slave nodes, significantly reducing operational complexity and technical barriers. Simultaneously, the master node, as the core of business traffic distribution, significantly reduces the IO pressure on the root node by caching frequently accessed VP master disk images and business code files locally, exceeding 40%. Combined with an NFS shared mounting strategy for low-frequency data, it optimizes the root node load while improving resource utilization. Based on the dynamic horizontal scaling capability of slave nodes and a preset lightweight message transmission protocol, it achieves precise allocation of virtual prototype deployment requests, flexibly responding to sudden high-concurrency simulation demands. This results in a virtual prototype deployment system with a simple deployment process, low operational costs, and suitability for small to medium-sized virtual prototypes.

[0083] This application provides a virtual prototype deployment system. Figure 6 This is a schematic diagram of the structure of the virtual prototype deployment system provided in the embodiments of this application, as shown below. Figure 6 As shown, this virtual prototype deployment system includes a root node, multiple master nodes, and multiple slave nodes. The root node, master nodes, and slave nodes share data through a data sharing layer. This data sharing layer includes a database and network files. These two layers work together to provide efficient data sharing services for the system's nodes, ensuring real-time data synchronization and consistency. The database stores structured data generated during the virtual prototype deployment process. The network files are the aforementioned shared files. As mentioned earlier, the root node maintains the database and network files in the data sharing layer, serving as the source for all files. Master nodes and slave nodes employ different synchronization strategies based on file types to ensure data consistency and efficient system operation; see the previous descriptions of master and slave nodes for further details. The database can be a MySQL database.

[0084] The root node, master node, and slave nodes communicate through a network communication layer, including message communication. This network communication layer includes a network configuration module, an MQTT service, and a load balancing module. The network configuration module enables initial network communication between nodes. The MQTT service ensures accurate message routing. The load balancing module optimizes resource allocation, ensuring that each message is assigned to a single node for processing, thus guaranteeing the system's efficient and stable operation.

[0085] The root node, master node, and slave nodes utilize a business proxy layer to configure business types and rapidly deploy and expand business functions. This business proxy layer includes a business routing module and a business startup interface. The business routing module configures the business types for the master and slave nodes and ensures accurate message routing to achieve business processing and optimize resource utilization. The business startup interface provides standardized interfaces for rapid deployment and expansion of business functions; it forms the foundation for nodes to implement business functions. Details regarding the business startup interface are provided above and will not be repeated here.

[0086] The root node is used to maintain and control the data sharing layer, network communication layer, and business proxy layer. Understandably, the virtual prototype deployment system interacts with clients to receive and process virtual prototype deployment requests sent by users through the clients.

[0087] The virtual prototype deployment system provided in this application adopts a root-master-slave (RMS) architecture, combining a data sharing layer, a network communication layer, and a business proxy layer to achieve efficient collaboration between nodes. Based on MQTT's shared subscription function, it enables dynamic load balancing of consumer groups, supplemented by standardized message formats, supporting elastic scaling and precise routing of master and slave nodes.

[0088] It should be noted that the RMS architecture provided in this application can break through the limitations of the chip simulation field and extend to high-performance computing, i.e., edge-cloud collaborative scenarios. It adapts to computationally intensive tasks through elastic slave node clusters and constructs a three-level architecture of "cloud root node - edge master node - terminal slave node" to optimize the real-time response capability of the edge side.

[0089] The virtual prototype deployment system provided in this application embodiment can use distributed consensus algorithms (such as Raft / Paxos) to achieve multi-master node autonomy, eliminate single-point dependency of the root node, and design a hybrid cloud root node deployment framework that is compatible with the elastic resources of public cloud and the data management and control requirements of private cloud.

[0090] This application also provides a virtual prototype deployment method, applicable to the virtual prototype deployment system in any of the above system embodiments. Figure 7 This is a flowchart illustrating the virtual prototype deployment method provided in the embodiments of this application, as shown below. Figure 7 As shown, the process includes: Step S701: Based on the root node, maintain shared files locally; the shared files include the virtual prototype master disk image, business code files, basic service dependency packages, and user data packages.

[0091] Step S702: Based on the master node, the virtual prototype master disk image and business code files in the shared files are stored locally, and the basic service dependency packages and user data packages are accessed by mounting the root node path.

[0092] Step S703: Based on the slave node, the virtual prototype master disk image in the shared files is stored locally. The business code files are accessed by mounting the master node path, and the basic service dependency packages and user data packages are accessed by mounting the root node path.

[0093] Step S704: Based on the root node, obtain the virtual prototype deployment request sent by the user, and based on the preset lightweight message transmission protocol, send the virtual prototype deployment request to the target node in the target master-slave cluster whose subscribed topic matches the topic of the virtual prototype deployment request, so as to respond to the virtual prototype deployment request based on the target node.

[0094] Step S705: Based on the root node, configure the service types of each master node and slave node so that each master node and slave node can determine the target service code in the service code file according to the service type and run the target service code to start the target service module.

[0095] The virtual prototype deployment method provided in this application integrates traditionally distributed nodes into a system with root, master, and slave nodes, combining mounting and local storage mechanisms. Users only need to maintain shared files through the root node to achieve automatic data synchronization between master and slave nodes, significantly reducing operational complexity and technical barriers. Simultaneously, the master node, as the core of business traffic distribution, significantly reduces the IO pressure on the root node by caching frequently accessed VP master disk images and business code files locally, exceeding 40%. Combined with an NFS shared mounting strategy for low-frequency data, it optimizes the root node load while improving resource utilization. Based on the dynamic horizontal scaling capability of slave nodes and a preset lightweight message transmission protocol, precise allocation of virtual prototype deployment requests is achieved, flexibly responding to sudden high-concurrency simulation demands. Therefore, it solves the technical problems of complex deployment processes, high operational costs, and unsuitability for deploying small and medium-sized virtual prototypes in related technologies, achieving a virtual prototype deployment system with a simple deployment process, low operational costs, and suitability for small and medium-sized virtual prototypes.

[0096] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0097] Embodiments of this application also provide an electronic device, such as... Figure 8As shown, it includes a processor 801 and a memory 802, in which a computer program is stored. The processor 801 is configured to run the computer program to perform the steps in the above-described virtual prototype deployment method embodiment.

[0098] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute the steps described in the above-described virtual prototype deployment method embodiments at runtime.

[0099] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0100] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the above-described virtual prototype deployment method embodiments.

[0101] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the above-described virtual prototype deployment method embodiments.

[0102] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0103] The virtual prototype deployment system, method, electronic device, and storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A virtual prototype deployment system, characterized in that, It includes a root node and multiple master-slave clusters, wherein the master-slave clusters include a master node and multiple slave nodes; The root node is used to maintain shared files locally; the shared files include a virtual prototype master image, business code files, basic service dependency packages, and user data packages; The master node is used to locally store the virtual prototype master disk image and business code files in the shared files, and access the basic service dependency packages and user data packages by mounting the root node path. The slave node is used to store the virtual prototype master disk image in the shared file locally, access the business code file by mounting the master node path, and access the basic service dependency package and user data package by mounting the root node path. The root node is also used to obtain the virtual prototype deployment request sent by the user, and send the virtual prototype deployment request to the target node in the target master-slave cluster whose subscription topic matches the topic of the virtual prototype deployment request, based on a preset lightweight message transmission protocol, so as to respond to the virtual prototype deployment request based on the target node. The root node is also used to configure the service types of each master node and slave node, so that each master node and slave node can determine the target service code in the service code file according to the service type and run the target service code to start the target service module.

2. The system according to claim 1, characterized in that, The root node is specifically used for: Based on the virtual prototype deployment request, determine the target topic in the virtual prototype deployment request; Based on the target topic, determine the target business type corresponding to the target topic; Based on the target business type, update the target topic in the virtual prototype deployment request to the subscription topic of the target master-slave cluster corresponding to the target business type; Based on a preset polling strategy, the virtual prototype deployment request is sent to the target node in the target master-slave cluster, where the target node is either the target master node or the target slave node. For any master-slave cluster, the master and slave nodes in the cluster have the same subscribed topics and the same business types; different master-slave clusters have different subscribed topics.

3. The system according to claim 1, characterized in that, The target node is specifically used for: Upon receiving the virtual prototype deployment request, determine whether the target virtual prototype master disk image corresponding to the virtual prototype deployment request is stored locally; If the target virtual prototype master disk image corresponding to the virtual prototype deployment request is not stored locally, the target virtual prototype master disk image is obtained from the shared file of the root node and stored locally. Determine whether the hash value of the target virtual prototype master disk image stored locally is consistent with the hash value of the target virtual prototype master disk image stored in the image index table; If they match, then create the target virtual prototype based on the target virtual prototype master image.

4. The system according to claim 3, characterized in that, The target node is also used for: If the target virtual prototype master disk image corresponding to the virtual prototype deployment request is stored locally, then determine whether the hash value of the target virtual prototype master disk image stored locally is consistent with the hash value of the target virtual prototype master disk image stored in the image index table. If they match, then create the target virtual prototype based on the target virtual prototype master image.

5. The system according to claim 1, characterized in that, The root node is also used to respond to any update of the virtual prototype master disk image by sending the update message of the virtual prototype master disk image to each of the master nodes and slave nodes. The update message includes the service type of the virtual prototype master disk image, the type identifier of the corresponding virtual prototype, the image file name and the hash value. The master node and slave node are also used to receive the update message and determine whether the update message conforms to the preset specification; if the update message conforms to the preset specification, the local mirror index table is updated based on the update message; if the update message does not conform to the preset specification, it is discarded directly.

6. The system according to claim 1, characterized in that, The root node is also used to respond to the update of the business code file by uploading the updated business code file to the target repository and sending a business code update message to each of the master nodes and slave nodes. The master node and slave node are also used to receive the business code update message, obtain the updated business code file from the target repository, and restart the corresponding target business module based on the updated business code file.

7. The system according to claim 1, characterized in that, The master node and slave node are also used for: Call the business startup interface to clean up the environment of the master and slave nodes; Start the basic services of the master node and slave node based on the basic service dependency package.

8. A method for deploying a virtual prototype, characterized in that, Applied to the system according to any one of claims 1 to 7, comprising: Based on the root node, shared files are maintained locally; the shared files include virtual prototype master disk image, business code files, basic service dependency packages, and user data packages; Based on the master node, the virtual prototype master disk image and business code files in the shared files are stored locally, and the basic service dependency packages and user data packages are accessed by mounting the root node path. Based on the slave node, the virtual prototype master disk image in the shared file is stored locally. The business code file is accessed by mounting the master node path, and the basic service dependency package and user data package are accessed by mounting the root node path. Based on the root node, the virtual prototype deployment request sent by the user is obtained. Based on a preset lightweight message transmission protocol, the virtual prototype deployment request is sent to the target node in the target master-slave cluster whose subscription topic matches the topic of the virtual prototype deployment request, so as to respond to the virtual prototype deployment request based on the target node. Based on the root node, configure the service types of each master node and slave node so that each master node and slave node can determine the target service code in the service code file according to the service type, and run the target service code to start the target service module.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the steps of the virtual prototype deployment method as described in claim 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the virtual prototype deployment method as described in claim 8.

Images