A chip simulation memory resource scheduling method, device and equipment and storage medium

Abstract

The application discloses a chip simulation memory resource scheduling method and device, equipment and a storage medium. Including: obtaining the test request of the memory resource in the target simulation platform, generating the request queue according to the test request; using the first adaptive bin packing algorithm to dynamically allocate resources to the request queue; determining the platform type of the target simulation platform, starting the instance of the target request based on the platform type to run the target instance. By constructing the request queue, the scattered test requests can be aggregated in batches, and the frequent interaction overhead of single scheduling is reduced. The first adaptive bin packing algorithm is used for dynamic resource allocation, which can flexibly allocate resources according to the remaining memory of the platform, relieve the memory fragmentation problem, and improve the hardware memory use efficiency. By identifying the simulation platform type and starting the instance differently, the exclusive initialization and resource cleaning process of different hardware devices can be adapted, the hardware resource conflict is avoided, and the instance start failure probability is reduced.

Description

Technical Field

[0001] This invention relates to the field of chip simulation, and in particular to a chip simulation memory resource scheduling method, apparatus, device, and storage medium. Background Technology

[0002] In the integrated circuit chip simulation and verification process, the hardware simulation platform built on field-programmable gate arrays is the core equipment for accelerating chip functional verification. The platform uses design partitions as the smallest resource unit to carry simulation test tasks. Each design partition occupies a fixed amount of board memory, while the total memory resources of a single simulation device have a fixed upper limit. Different R&D projects will continuously submit simulation test requests containing project names, partition layouts, and memory requirements. It is necessary to uniformly complete resource scheduling and instance retrieval for massive discrete test requests to ensure the orderly execution of chip verification tasks.

[0003] Currently, the industry generally adopts a manual co-location and fixed reservation model to manage simulation memory resources. Engineers manually submit and process various test requests without unified aggregation and queuing of scattered test requests. Resource allocation relies on static pre-allocation to divide fixed resource pools, lacking dynamic binning and scheduling logic. At the same time, management tools on the market do not differentiate between different models of heterogeneous simulation platforms. The instance startup process uses a unified fixed script, which cannot adapt to the different environment cleanup and initialization processes of different platforms.

[0004] The existing approach lacks a queue aggregation mechanism for discrete test requests, resulting in fragmented scheduling. Static resource partitioning leads to memory fragmentation and low overall resource utilization. It also lacks a bin packing allocation strategy adapted to simulation memory constraints. Furthermore, it cannot distinguish between different heterogeneous simulation platforms to perform differentiated instance startup operations, which easily leads to hardware resource conflicts, virtual machine startup failures, and other faults. The overall resource scheduling and instance startup process has a low degree of automation and high manual operation costs. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and storage medium for scheduling memory resources in chip simulation, which solves the problem of low resource utilization in chip simulation platforms.

[0006] According to one aspect of the present invention, a chip emulation memory resource scheduling method is provided, the method comprising: Obtain test requests for memory resources in the target simulation platform, and generate a request queue based on the test requests. The test requests include the project name, layout, and memory resource requirements. The first-fit bin packing algorithm is used to dynamically allocate resources to the request queue; Determine the platform type of the target simulation platform, and start the instance of the target request that has been successfully allocated resources based on the platform type to run the target instance.

[0007] Optionally, a request queue is generated based on the test requests, including: storing the test requests in a message queue and polling the message queue at a preset period to obtain requests to be processed; deduplicating the requests to be processed according to the project name and layout to obtain deduplicated requests; determining the memory specifications corresponding to the deduplicated requests and determining the number of requests corresponding to each memory specification; sorting the deduplicated requests in descending order of the number of requests, and sorting them in the order of submission if the number of requests is the same, to generate sorted requests; obtaining a preset request count threshold, and combining the memory specifications corresponding to the sorted requests with the preset request count threshold to supplement the number of instances and generate a request queue.

[0008] Optionally, the first-fit bin packing algorithm is used to dynamically allocate resources to the request queue, including: determining the current available resources and dividing the queue into a running queue and a waiting queue; sequentially selecting requests to be allocated from the request queue and determining the target resource requirement corresponding to the request to be allocated; determining whether the available resources are greater than or equal to the target resource requirement; if so, adding the request to be allocated to the running queue and deducting the target resource requirement from the available resources; otherwise, moving the request to be allocated to the waiting queue.

[0009] Optionally, after moving the pending requests into the waiting queue, the method further includes: continuously polling the running status of the target instance in the running queue; when the running status is execution completed or abnormally terminated, reclaiming the memory resources corresponding to the target instance and updating the available resources; traversing the waiting queue based on the updated available resources and re-executing resource allocation until all pending requests have been processed.

[0010] Optionally, instance startup can be performed on target requests for successfully allocated resources based on platform type, including: using requests in the run queue as target requests for successfully allocated resources; performing differentiated environment initialization and resource cleanup operations according to platform type, and starting instances based on target requests in conjunction with an automatic retry mechanism.

[0011] Optionally, the method further includes: detecting the health status of the target instance based on target dimensions during the execution of the target instance, wherein the target dimensions include network connectivity detection, running component status detection, hardware fault detection, and system kernel log detection.

[0012] Optionally, the method further includes: obtaining a preset timeout threshold and determining the runtime of the target instance; when the runtime exceeds the preset timeout threshold, determining the task execution status; when the task execution status is "in execution", entering a buffer waiting phase and providing a preset buffer time for the target instance to continue running; when the task execution status is "idle", the preset buffer time ends, or a hardware failure is detected, cleaning up the target instance.

[0013] Optionally, the method also includes: when the target instance finishes execution, performing differentiated cleanup operations on the target instance according to the platform type to release memory resources; when the target instance meets the preset restart conditions, restarting the target instance, wherein the preset restart conditions include: the current mode is the post-startup cleanup mode, the remaining available time window is greater than the preset window threshold and the cleanup is not triggered due to idle timeout.

[0014] According to another aspect of the present invention, a chip emulation memory resource scheduling device is provided, the device comprising: The request queue generation module is used to obtain test requests for memory resources in the target simulation platform and generate a request queue based on the test requests. The test requests include the project name, layout, and memory resource requirements. The dynamic resource allocation module is used to dynamically allocate resources to the request queue using the first-fit bin packing algorithm. The instance run management module is used to determine the platform type of the target simulation platform, and to start the instance for the target request that has been successfully allocated resources based on the platform type, so as to run the target instance.

[0015] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute a chip simulation memory resource scheduling method according to any embodiment of the present invention.

[0016] According to another aspect of the present invention, a computer storage medium is provided, the computer storage medium storing computer instructions, the computer instructions being used to cause a processor to execute and implement a chip simulation memory resource scheduling method according to any embodiment of the present invention.

[0017] The technical solution of this invention, by constructing a request queue, can aggregate scattered test requests in batches, reduce the frequent interaction overhead of a single scheduling, and facilitate the unified organization of tasks to be scheduled; by adopting the first-fit bin packing algorithm for dynamic resource allocation, resources can be flexibly allocated according to the platform's remaining memory, alleviating the memory fragmentation problem and improving the overall hardware memory utilization efficiency; by identifying the simulation platform type and starting instances differently, it can adapt to the specific initialization and resource cleanup processes of different hardware devices, avoid hardware resource conflicts, and reduce the probability of instance startup failure.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0020] Figure 1 This is a flowchart of a chip simulation memory resource scheduling method according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of another chip simulation memory resource scheduling method provided in Embodiment 2 of the present invention; Figure 3 This is a diagram of a three-layer cooperative architecture for chip simulation memory resource scheduling provided in Embodiment 2 of the present invention; Figure 4 This is a schematic diagram of the structure of a chip simulation memory resource scheduling device according to Embodiment 3 of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device that implements a chip simulation memory resource scheduling method according to an embodiment of the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] Example 1 Figure 1 This is a flowchart illustrating a chip emulation memory resource scheduling method according to Embodiment 1 of the present invention. This embodiment is applicable to chip emulation scenarios. The method can be executed by a chip emulation memory resource scheduling device, which can be implemented in hardware and / or software and can be configured in a computer device. Figure 1 As shown, the method includes: S110. Obtain test requests for memory resources in the target simulation platform, and generate a request queue based on the test requests. The test requests include the project name, layout, and memory resource requirements.

[0024] The chip simulation memory resource scheduling method refers to the method for automatically allocating and managing the memory resources of DesignBlock (DB) instances in a chip simulation verification platform. This optimizes resource utilization and enables automated management throughout the entire lifecycle. The target simulation platform refers to the hardware platform used for chip simulation verification, such as Synopsys ZeBu or DSIC PRO. Its total memory resources are fixed; for example, a single device typically has 32MB of board memory, which needs to be allocated to multiple DB instances through a scheduling algorithm. A test request refers to a DB resource usage request submitted by a verification engineer, including the project name, layout, and memory resource requirements. The project name refers to the chip design project it belongs to, the layout refers to the hardware mapping configuration of the DB, and the memory resource requirements refer to the board memory required by the DB instance, such as 8MB, 12MB, and 16MB. The request queue refers to a set of test requests arranged according to certain rules, such as time order and priority, used by the scheduler to batch process resource allocation.

[0025] Optionally, a request queue is generated based on the test requests, including: storing the test requests in a message queue and polling the message queue at a preset period to obtain requests to be processed; deduplicating the requests to be processed according to the project name and layout to obtain deduplicated requests; determining the memory specifications corresponding to the deduplicated requests and determining the number of requests corresponding to each memory specification; sorting the deduplicated requests in descending order of the number of requests, and sorting them in the order of submission if the number of requests is the same, to generate sorted requests; obtaining a preset request count threshold, and combining the memory specifications corresponding to the sorted requests with the preset request count threshold to supplement the number of instances and generate a request queue.

[0026] The message queue, such as a Redis queue, is middleware used to temporarily store user-submitted database requests, enabling asynchronous processing and time-based aggregation of requests. Memory specifications refer to the database instance's card memory requirements, such as 8MB, 12MB, and 16MB, extracted from the request layout configuration. The preset request threshold is the number of requests that trigger intelligent scaling, such as 4 requests; different memory specifications correspond to different scaling rules.

[0027] Specifically, the system first receives various test requests submitted by engineers and stores them uniformly in a Redis message queue to aggregate the time dimension of the requests. The DB scheduling trigger pipeline continuously polls the message queue according to a preset cycle. In each scheduling cycle, all pending requests in the queue are retrieved in batches. Then, using the project name and DB layout as a combined unique key, all pending requests are deduplicated. Duplicate requests with the same project and layout are merged, and the total number of requests corresponding to each combination is counted to obtain deduplicated independent request entries. Next, the memory specification bound to each deduplicated request is extracted, and the cumulative number of requests under each memory specification is recorded. Then, sorting logic is executed, and all deduplicated entries are first sorted in descending order of the corresponding request quantity. If two or more request entries have the same cumulative request quantity, they are sorted in ascending order according to the original submission time of the user, generating a sorted ordered request list. The system reads a preset request count threshold of 4 times, iterates through the sorted requests one by one, and applies intelligent expansion rules to supplement the number of instances based on the memory specifications of each request. For 16M and 12M DB requests, an additional instance is added directly when the number of requests is greater than or equal to 4. For 8M DB requests, an additional instance is added every 4 requests, with a maximum of 3 additional instances. After the instance count is supplemented and adjusted, a standardized request queue is generated for subsequent bin packing scheduling algorithms. The above process relies on message queues to achieve batch aggregation of discrete requests, reduces redundant scheduling overhead through deduplication, prioritizes scheduling for large resource demands to optimize resource fragmentation, and intelligent expansion expands instances in advance based on historical request volumes to avoid test tasks queuing, thereby improving the overall utilization rate of chip simulation hardware memory resources from the source.

[0028] S120. The first-fit bin packing algorithm is used to dynamically allocate resources to the request queue.

[0029] The first-fit bin packing algorithm is a greedy resource scheduling algorithm that iterates through the request queue sequentially and allocates resources to the first free resource block that can meet its memory requirements. Dynamic resource allocation refers to dynamically scheduling test requests in the request queue based on real-time resource usage, rather than static pre-allocation. When an instance completes, resources are reclaimed and reallocated to requests in the waiting queue.

[0030] S130. Determine the platform type of the target simulation platform, and start the instance of the target request that has been successfully allocated resources based on the platform type to run the target instance.

[0031] Among them, platform type refers to the hardware model of the simulation platform. Different platforms have differences in virtual machine (VM) startup process, environment configuration and health monitoring methods, which require the execution of differentiated management logic.

[0032] A target request refers to a test request in the request queue that has successfully obtained memory resources through dynamic resource allocation. Instance startup refers to the process of starting a DB instance for the target request, including environment initialization, virtual machine startup, and registration with the Continuous Integration / Continuous Delivery Runner (CI / CD Runner). The startup process needs to be adapted to different platform types. A target instance is a successfully started and running DB instance, representing a synthesized and mapped design partition on the hardware, capable of performing chip simulation and verification tasks.

[0033] Optionally, instance startup can be performed on target requests for successfully allocated resources based on platform type, including: using requests in the run queue as target requests for successfully allocated resources; performing differentiated environment initialization and resource cleanup operations according to platform type, and starting instances based on target requests in conjunction with an automatic retry mechanism.

[0034] The run queue refers to the set of test requests that have successfully acquired memory resources after dynamic resource allocation. Differentiated environment initialization and resource cleanup operations refer to executing environment preparation and resource reclamation steps tailored to the characteristics of different hardware models of the simulation platform; for example, different platforms use different process cleanup commands and different methods for releasing board resources. The automatic retry mechanism refers to the mechanism by which the system automatically cleans up residual environment and retryes startup when an instance fails to start. By configuring the number of retries and the interval, the success rate of instance startup can be improved.

[0035] Specifically, the system first extracts all entries from the run queue generated during the scheduling phase, identifying all entries in the queue as target requests for successful resource allocation. Then, it processes each target request sequentially, first identifying the platform type of the target simulation platform corresponding to the request, and then performing customized environment initialization and resource cleanup operations for different platforms. For example, for a ZeBu platform, it can first terminate residual processes on the platform, release occupied board hardware resources, create a virtual machine through a background session, and repeatedly verify the VM's startup status. It then matches the Internet Protocol (IP) mapping table to obtain the virtual machine address and complete the CI / CD Runner registration. For a DSIC PRO platform adapted for professional chip hardware simulation scenarios, it can first perform board hardware resource verification and reclamation, call the platform-specific startup script to start the virtual machine, and then use a dedicated plugin to deploy the CI / CD Runner inside the virtual machine. The entire instance startup process incorporates an automatic retry mechanism. If resource conflicts, startup timeouts, or connection anomalies occur during VM startup, the system automatically cleans up the abnormal environment created and re-initiates the startup process. The number of retries is controlled by configurable parameters, with a default maximum of 200 retries. The interval between each retry can be customized. Before startup, the system also checks if any other user is using a running VM instance. If so, a notification is sent and the system enters a waiting state. After all pre-process cleanup, platform-specific initialization processes are completed, and the retry logic verification passes, the DB instance corresponding to the target request is officially started, generating a running instance capable of carrying out chip simulation testing tasks. The above process achieves compatible management of multiple types of simulation devices through a unified scheduling layer by differentiating heterogeneous platforms. Pre-process resource cleanup avoids startup failures caused by hardware resource conflicts, and the automatic retry mechanism significantly reduces the probability of instance startup failures due to temporary environmental anomalies, ensuring the stability and reliability of the DB instance startup process.

[0036] Optionally, the method further includes: detecting the health status of the target instance based on target dimensions during the execution of the target instance, wherein the target dimensions include network connectivity detection, running component status detection, hardware fault detection, and system kernel log detection.

[0037] Network connectivity detection involves verifying the network reachability of the virtual machine's IP address corresponding to the target instance using the Ping command to determine if there are any anomalies at the network layer. Component status detection involves querying the CI / CD Runner's `is_busy` workload flag through the CI / CD platform's Application Programming Interface (API) to determine if there are instances where the Runner process is suspended but the virtual machine is still alive. Hardware fault detection primarily monitors for hot reset errors in the Peripheral Component InterconnectExpress (PCIe) standard between the Field Programmable Gate Array (FPGA) board and the host, as these errors directly affect the normal operation of the instance. System kernel log detection involves collecting and analyzing the kernel logs (dmesg) of the virtual machine corresponding to the target instance to identify system-level kernel alarms and errors.

[0038] Specifically, during the target instance's operation, the system performs health status checks from four dimensions simultaneously. First, it performs network connectivity checks, periodically sending ping requests to the virtual machine's IP address. If the ping fails, a network layer anomaly is identified, and the target instance is deemed unhealthy. Simultaneously, it checks the status of running components. The system retrieves the CI / CD Runner's `is_busy` status value by calling the CI / CD platform's API. If the Runner status is empty, it indicates a Runner process hang in the application layer, also indicating the target instance is unhealthy. The system also performs hardware fault detection, obtaining specific flag files from the virtual machine via remote file synchronization to check for PCIe hot reset errors. If such an error is detected, it immediately triggers a cleanup and restart of the target instance, determining it to be unhealthy. Finally, the system performs kernel log checks, connecting to the virtual machine via Secure Shell (SSH) to collect and analyze kernel logs for system-level kernel alarms and errors.

[0039] Furthermore, the system will integrate and judge the detection results of the four dimensions according to priority. The priority from high to low is hardware fault detection, network connectivity detection, running component status detection, and system kernel log detection. If the hardware fault detection is determined to be abnormal, it will immediately trigger a cleanup and restart and return to an unhealthy state. If the network connectivity detection or running component status detection is determined to be abnormal, it will also be directly determined to be in an unhealthy state. When the network and Runner status are normal, the system will return a busy or idle state according to the Runner's is_busy flag, thereby achieving comprehensive and accurate monitoring of the health status of the target instance.

[0040] Optionally, the method further includes: obtaining a preset timeout threshold and determining the runtime of the target instance; when the runtime exceeds the preset timeout threshold, determining the task execution status; when the task execution status is "in execution", entering a buffer waiting phase and providing a preset buffer time for the target instance to continue running; when the task execution status is "idle", the preset buffer time ends, or a hardware failure is detected, cleaning up the target instance.

[0041] The preset timeout threshold is the maximum runtime of a DB instance, pre-set based on DB configuration and business requirements, such as 60 minutes, used to determine whether an instance has entered the timeout phase. Runtime refers to the time difference between the DB instance's startup timestamp and the current timestamp, used to measure the instance's runtime. Task execution status is the CI / CD Runner working status obtained through Runner status detection in the four-dimensional health monitoring, represented by the `is_busy` flag: 1 for executing a task, 0 for idle. The buffer wait phase is an additional wait time, such as 20 minutes, given by the system when the DB instance's runtime exceeds the preset timeout threshold but is still executing a task, to ensure the current task completes. Hardware faults are identified through PCIe hardware fault detection or dmesg kernel diagnostics, including underlying hardware issues such as FPGA board hot reset errors and driver anomalies.

[0042] Specifically, the system continuously calculates the difference between the current timestamp and the instance's startup timestamp to obtain the instance's real-time runtime. When the runtime exceeds the preset 60-minute timeout threshold, it calls the Runner status detection interface in the four-dimensional health monitoring to query the target instance's task execution status. If the Runner's is_busy flag is detected as 1, it indicates that the task is executing, and the system enters a buffering waiting phase, starting a buffer timer and providing a preset buffer time, such as 20 minutes. During the buffering waiting period, the system polls the Runner status every 60 seconds until the task is completed, i.e., is_busy becomes 0, or the buffer time ends. If the task execution status is idle, i.e., is_busy is 0, or the buffer time has ended, or if a hardware fault is detected at any stage through PCIe hardware fault detection or dmesg kernel diagnostics, the system will immediately trigger a cleanup process, releasing board resources and terminating the virtual machine instance to ensure efficient resource reclamation and guarantee stable system operation.

[0043] Optionally, the method also includes: when the target instance finishes execution, performing differentiated cleanup operations on the target instance according to the platform type to release memory resources; when the target instance meets the preset restart conditions, restarting the target instance, wherein the preset restart conditions include: the current mode is the post-startup cleanup mode, the remaining available time window is greater than the preset window threshold and the cleanup is not triggered due to idle timeout.

[0044] The preset restart conditions refer to the rules for triggering the restart of the target instance, including three dimensions: mode judgment, time window judgment, and cleanup reason judgment. The remaining available time window refers to the remaining time remaining between the current time and the preset resource reclamation time point of the instance. The preset window threshold is the minimum remaining available time required to trigger a restart. Idle timeout is an independent instance cleanup trigger mechanism. Specifically, after the target instance completes its simulation task and is in an idle state with no tasks running, the system continuously counts the instance's idle time. When the accumulated idle time count exceeds a preset threshold, the instance is determined to have triggered an idle timeout, thus initiating the instance cleanup process. This is a trigger scenario for proactive resource reclamation of the instance, distinct from the cleanup mechanism for task timeout.

[0045] Specifically, after the chip simulation verification task of the target instance is completed, the system first identifies the platform type corresponding to the instance. If it is a ZeBu type platform, it first terminates the virtual machine process corresponding to the instance through a background session, then releases the board memory resources occupied by the instance, and finally cleans up the related files and configurations remaining on the platform. If it is a DSICPRO type platform, it calls the platform-specific cleanup script to terminate the virtual machine and release board resources, completing differentiated cleanup operations to release memory resources. Then, the system determines whether the target instance meets the preset restart conditions. First, it checks whether it is currently in post-boot cleanup mode; if not, it does not perform a restart. If it is in post-boot cleanup mode, it calculates the remaining available time window of the instance. If the remaining available time window is greater than the preset window threshold (e.g., the preset window threshold is 30 minutes, and the remaining available time window is 40 minutes), it then determines the reason for the instance's cleanup. If the cleanup is not triggered by idle timeout, all preset restart conditions are met, and the system executes the corresponding instance restart process according to the platform type to restart the target instance so that it can subsequently undertake new simulation verification tasks. If the remaining available time window is less than or equal to the preset window threshold, or if cleanup is triggered due to idle timeout, the restart operation will not be performed, and resource reclamation will be completed.

[0046] The technical solution of this invention, by constructing a request queue, can aggregate scattered test requests in batches, reduce the frequent interaction overhead of a single scheduling, and facilitate the unified organization of tasks to be scheduled; by adopting the first-fit bin packing algorithm for dynamic resource allocation, resources can be flexibly allocated according to the platform's remaining memory, alleviating the memory fragmentation problem and improving the overall hardware memory utilization efficiency; by identifying the simulation platform type and starting instances differently, it can adapt to the specific initialization and resource cleanup processes of different hardware devices, avoid hardware resource conflicts, and reduce the probability of instance startup failure.

[0047] Example 2 Figure 2 This is a flowchart of a chip simulation memory resource scheduling method provided in Embodiment 2 of the present invention. This embodiment adds a specific process for dynamically allocating resources to the request queue using the first-fit bin packing algorithm, based on Embodiment 1. The specific content of step S210 is largely the same as step S110 in Embodiment 1, and the instance startup process follows Embodiment 1; therefore, it will not be described again in this embodiment. Figure 2 As shown, the method includes: S210. Obtain test requests for memory resources in the target simulation platform, and generate a request queue based on the test requests. The test requests include the project name, layout, and memory resource requirements.

[0048] Optionally, a request queue is generated based on the test requests, including: storing the test requests in a message queue and polling the message queue at a preset period to obtain requests to be processed; deduplicating the requests to be processed according to the project name and layout to obtain deduplicated requests; determining the memory specifications corresponding to the deduplicated requests and determining the number of requests corresponding to each memory specification; sorting the deduplicated requests in descending order of the number of requests, and sorting them in the order of submission if the number of requests is the same, to generate sorted requests; obtaining a preset request count threshold, and combining the memory specifications corresponding to the sorted requests with the preset request count threshold to supplement the number of instances and generate a request queue.

[0049] S220. Determine the currently available resources and divide them into running queues and waiting queues.

[0050] Available resources refer to the total amount of unused board memory on the target simulation platform. For example, if the platform's total memory is 32MB and 20MB has been allocated, then the available resources are 12MB. The run queue is the set of test requests that have successfully allocated memory resources and are waiting to start instances. The wait queue is the set of test requests that are temporarily unable to be allocated resources and need to wait for idle resources to be released.

[0051] Specifically, the system first calculates the available resources of the target simulation platform, which is the difference between the total memory resources and the allocated memory resources. At the same time, it creates two empty sets as a running queue and a waiting queue. The running queue is used to store requests that have successfully allocated resources, and the waiting queue is used to store requests that cannot be allocated resources temporarily.

[0052] S230. Select requests to be allocated sequentially from the request queue and determine the target resource requirements corresponding to the requests to be allocated.

[0053] Specifically, the system selects requests to be allocated in the order of the request queue. Each request to be allocated contains information such as the project name and layout, and extracts the corresponding memory requirements from the layout configuration, which is the target resource requirement of the request.

[0054] S240. Determine whether the available resources are greater than or equal to the target resource requirement. If yes, execute S250; otherwise, execute S260.

[0055] S250: Add the pending allocation request to the run queue and deduct the target resource requirement from the available resources.

[0056] Specifically, the system can compare the current available resources with the target resource requirement of the request to be allocated. If the available resources are greater than or equal to the target resource requirement, it means that the platform has enough free memory to meet the request. The system will then add the request to be allocated to the running queue and deduct the target resource requirement of the request from the available resources, and update the available resource value of the platform.

[0057] S260. Move the pending allocation request into the waiting queue.

[0058] Specifically, if the available resources are less than the target resource requirement, it means that the current platform does not have enough free memory to meet the request. The system will then move the request to be allocated to a waiting queue, waiting for other instances to complete their tasks and release memory resources before attempting to allocate resources to the requests in the waiting queue.

[0059] Optionally, after moving the pending requests into the waiting queue, the method further includes: continuously polling the running status of the target instance in the running queue; when the running status is execution completed or abnormally terminated, reclaiming the memory resources corresponding to the target instance and updating the available resources; traversing the waiting queue based on the updated available resources and re-executing resource allocation until all pending requests have been processed.

[0060] The running status includes "Executing," "Execution Completed," and "Abnormal Termination," reflecting the current task progress of the instance. Abnormal termination refers to the instance stopping before completing its task due to resource conflicts, hardware failures, or system errors. Memory resource reclamation refers to releasing the memory resources occupied by the target instance, making them available again.

[0061] Specifically, when a pending resource allocation request is moved into the waiting queue, the system initiates a continuous polling mechanism, querying the running status of all target instances in the running queue at set time intervals, such as once every 30 seconds. During the polling process, if the running status of a target instance changes to "execution completed," indicating that the instance has completed the chip simulation verification task, or if the status changes to "abnormal termination," meaning the instance unexpectedly stopped due to hardware failure, resource conflicts, or other issues, the system immediately performs a resource reclamation operation on the target instance, releasing the board memory resources it occupies and synchronously updating the platform's available resource values. For example, if the original available resources were 8MB, after reclamating an instance occupying 16MB of memory, the available resources become 24MB. After completing the resource update, the system iterates through the pending requests in the waiting queue based on the new available resources, re-executing the resource allocation process. That is, it sequentially checks whether the target resource requirement of each pending request is less than or equal to the current available resources. If so, the request is moved from the waiting queue to the running queue, and the corresponding resource requirement is deducted from the available resources to update the available resources. It is known that the traversal and allocation process will continue until all pending requests in the waiting queue have completed resource allocation, or there are no requests that can meet the resource requirements. After that, the system will continue to poll the running queue and repeat the above process of status query, resource reclamation and reallocation to ensure that resources can be used efficiently.

[0062] Optionally, the method further includes: detecting the health status of the target instance based on target dimensions during the execution of the target instance, wherein the target dimensions include network connectivity detection, running component status detection, hardware fault detection, and system kernel log detection.

[0063] Optionally, the method further includes: obtaining a preset timeout threshold and determining the runtime of the target instance; when the runtime exceeds the preset timeout threshold, determining the task execution status; when the task execution status is "in execution", entering a buffer waiting phase and providing a preset buffer time for the target instance to continue running; when the task execution status is "idle", the preset buffer time ends, or a hardware failure is detected, cleaning up the target instance.

[0064] Optionally, the method also includes: when the target instance finishes execution, performing differentiated cleanup operations on the target instance according to the platform type to release memory resources; when the target instance meets the preset restart conditions, restarting the target instance, wherein the preset restart conditions include: the current mode is the post-startup cleanup mode, the remaining available time window is greater than the preset window threshold and the cleanup is not triggered due to idle timeout.

[0065] In one specific implementation method Figure 3 This invention provides a three-layer cooperative architecture diagram for chip simulation memory resource scheduling in Embodiment 2. Figure 3The three-layer collaborative architecture diagram specifically includes: the user access layer, the request aggregation and scheduling layer, and the instance management layer. The user access layer receives test requests submitted by users and writes DB requirements to a message queue; the request aggregation and scheduling layer retrieves requests in batches from the message queue and performs deduplication, sorting, intelligent expansion, and initial adaptation boxing scheduling; the instance management layer manages the entire lifecycle of a single DB instance, including multi-platform adaptation initialization, VM startup and retry, four-dimensional health monitoring, elastic timeout management, and cleanup and recycling. Specifically, the three layers achieve data flow and parallel triggering through message queues. The upper user access layer receives test requests submitted by engineers, parses out resource requirements including project name, design partition, and memory specifications, and writes them into the message queue to complete unified request caching. The intermediate request aggregation and scheduling layer periodically pulls all requests in the queue in batches and executes request deduplication and sorting, intelligent instance expansion, and initial adaptation and boxing scheduling in sequence. At the same time, it is equipped with scheduling status dashboard, polling monitoring and resource reclamation logic. After scheduling is completed, multiple instance management pipelines of the lower instance management layer are triggered in parallel. The lower instance management layer sequentially completes the differentiated environment initialization for different simulation platforms, virtual machine startup with automatic retry mechanism, four-dimensional integrated health monitoring, elastic timeout management, and instance cleanup, reclamation and restart operations. The four-dimensional health monitoring includes network connectivity detection, runtime agent load status detection, hardware bus fault detection, and kernel log diagnosis. The four types of monitoring data are aggregated into the fusion decision module to comprehensively determine whether the instance is in one of three states: busy, idle, or abnormal fault. The entire three-layer pipeline is decoupled to achieve unified collection of simulation test requests, intelligent resource scheduling, and automated management of the entire lifecycle of instances. It is compatible with various heterogeneous hardware simulation platforms and solves various defects caused by traditional manual management and static resource allocation.

[0066] The technical solution of this invention, by constructing a request queue, can aggregate scattered test requests in batches, reduce the frequent interaction overhead of a single scheduling, and facilitate the unified organization of tasks to be scheduled; by adopting the first-fit bin packing algorithm for dynamic resource allocation, resources can be flexibly allocated according to the platform's remaining memory, alleviating the memory fragmentation problem and improving the overall hardware memory utilization efficiency; by identifying the simulation platform type and starting instances differently, it can adapt to the specific initialization and resource cleanup processes of different hardware devices, avoid hardware resource conflicts, and reduce the probability of instance startup failure.

[0067] Example 3 Figure 4 This is a schematic diagram of a chip simulation memory resource scheduling device provided in Embodiment 3 of the present invention. Figure 4 As shown, the device includes: a request queue generation module 310, used to obtain test requests for memory resources in the target simulation platform and generate a request queue based on the test requests, wherein the test requests include the project name, layout and memory resource requirements; The dynamic resource allocation module 320 is used to dynamically allocate resources to the request queue using the first-fit bin packing algorithm. The instance run management module 330 is used to determine the platform type of the target simulation platform, and to start the instance of the target request that has been successfully allocated resources based on the platform type, so as to run the target instance.

[0068] Optionally, the request queue generation module 310 is specifically used for: storing test requests into a message queue, and polling the message queue at a preset period to obtain requests to be processed; deduplicating the requests to be processed according to the project name and layout to obtain deduplicated requests; determining the memory specifications corresponding to the deduplicated requests and determining the number of requests corresponding to each memory specification; sorting the deduplicated requests in descending order of the number of requests, and sorting them in the order of submission if the number of requests is the same, to generate sorted requests; obtaining a preset request count threshold, and combining the memory specifications corresponding to the sorted requests with the preset request count threshold to supplement the number of instances and generate a request queue.

[0069] Optionally, the dynamic resource allocation module 320 is specifically used to: determine the current available resources and divide the running queue and the waiting queue; select requests to be allocated sequentially from the request queue and determine the target resource requirements corresponding to the requests to be allocated; determine whether the available resources are greater than or equal to the target resource requirements; if so, add the requests to be allocated to the running queue and deduct the target resource requirements from the available resources; otherwise, move the requests to be allocated to the waiting queue.

[0070] Optionally, the device further includes: a resource allocation waiting module, used to continuously poll the running status of the target instance in the running queue after moving the request to be allocated into the waiting queue; when the running status is execution completed or abnormally terminated, to reclaim the memory resources corresponding to the target instance and update the available resources; and to traverse the waiting queue based on the updated available resources and re-execute resource allocation until all requests to be allocated have been processed.

[0071] Optionally, the instance run management module 330 is specifically used to: take the requests in the run queue as the target requests for successful resource allocation; perform differentiated environment initialization and resource cleanup operations according to the platform type, and start the instance based on the target request in conjunction with the automatic retry mechanism.

[0072] Optionally, the device further includes a health status detection module, used to detect the health status of the target instance based on target dimensions during the operation of the target instance, wherein the target dimensions include network connectivity detection, running component status detection, hardware fault detection, and system kernel log detection.

[0073] Optionally, the device further includes: a timeout detection module, used to: obtain a preset timeout threshold and determine the running time of the target instance; when the running time exceeds the preset timeout threshold, determine the task execution status; when the task execution status is executing, enter the buffer waiting stage and give a preset buffer time for the target instance to continue running; when the task execution status is idle, the preset buffer time ends, or a hardware failure is detected, clean up the target instance.

[0074] Optionally, the device also includes an instance cleanup and restart module, used to: perform differentiated cleanup operations on the target instance according to the platform type when the target instance finishes execution, so as to release memory resources; and restart the target instance when the target instance meets the preset restart conditions, wherein the preset restart conditions include: the current mode is the post-startup cleanup mode, the remaining available time window is greater than the preset window threshold and the cleanup is not triggered due to idle timeout.

[0075] The technical solution of this invention, by constructing a request queue, can aggregate scattered test requests in batches, reduce the frequent interaction overhead of a single scheduling, and facilitate the unified organization of tasks to be scheduled; by adopting the first-fit bin packing algorithm for dynamic resource allocation, resources can be flexibly allocated according to the platform's remaining memory, alleviating the memory fragmentation problem and improving the overall hardware memory utilization efficiency; by identifying the simulation platform type and starting instances differently, it can adapt to the specific initialization and resource cleanup processes of different hardware devices, avoid hardware resource conflicts, and reduce the probability of instance startup failure.

[0076] The chip emulation memory resource scheduling device provided in this embodiment of the invention can execute the chip emulation memory resource scheduling method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0077] Example 4 Figure 5 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0078] like Figure 5As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) or random access memory (RAM), communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from the storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. Input / output (I / O) interfaces are also connected to the bus 14.

[0079] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0080] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a chip-emulated memory resource scheduling method.

[0081] In some embodiments, a chip emulation memory resource scheduling method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the chip emulation memory resource scheduling method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a chip emulation memory resource scheduling method by any other suitable means (e.g., by means of firmware).

[0082] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0083] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0084] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0085] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0086] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0087] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0088] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0089] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A chip simulation memory resource scheduling method, characterized in that, include: Obtain test requests for memory resources in the target simulation platform, and generate a request queue based on the test requests, wherein the test requests include the project name, layout, and memory resource requirements; The first-fit bin packing algorithm is used to dynamically allocate resources to the request queue; Determine the platform type of the target simulation platform, and based on the platform type, initiate an instance of the target request that has successfully allocated resources to run the target instance.

2. The method according to claim 1, characterized in that, The step of generating a request queue based on the test request includes: The test request is stored in a message queue, and the message queue is polled at a preset period to obtain requests to be processed. The requests to be processed are deduplicated according to the project name and layout to obtain the deduplicated requests. Determine the memory specifications corresponding to the deduplicated requests, and determine the number of requests corresponding to each memory specification; The deduplicated requests are sorted in descending order of the number of requests. If the number of requests is the same, they are sorted in the order of submission to generate the sorted requests. Obtain a preset request count threshold, and combine the memory specifications corresponding to the sorted requests with the preset request count threshold to supplement the number of instances and generate a request queue.

3. The method according to claim 1, characterized in that, The step of dynamically allocating resources to the request queue using the first-fit bin packing algorithm includes: Determine the currently available resources and divide them into run queues and wait queues; Select requests to be allocated sequentially from the request queue, and determine the target resource requirements corresponding to the requests to be allocated; Determine whether the available resources are greater than or equal to the target resource requirement. If so, add the request to be allocated to the running queue and deduct the target resource requirement from the available resources. Otherwise, the pending allocation request is moved to the waiting queue.

4. The method according to claim 3, characterized in that, After moving the pending allocation request into the waiting queue, the method further includes: Continuously poll the running status of target instances in the running queue; When the running status is "execution completed" or "abnormal termination", the memory resources corresponding to the target instance are reclaimed and the available resources are updated. Based on the updated available resources, the waiting queue is traversed, and resource allocation is re-executed until all pending allocation requests have been processed.

5. The method according to claim 3, characterized in that, The step of initiating an instance for a target request that has successfully allocated resources based on the platform type includes: The requests in the running queue are used as target requests for successful resource allocation; Perform differentiated environment initialization and resource cleanup operations based on the platform type, and start the instance based on the target request in conjunction with an automatic retry mechanism.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: During the operation of the target instance, the health status of the target instance is detected based on target dimensions, including network connectivity detection, running component status detection, hardware fault detection, and system kernel log detection.

7. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain the preset timeout threshold and determine the runtime of the target instance; When the running time exceeds the preset timeout threshold, the task execution status is determined. When the task execution status is "in execution", a buffer waiting phase is entered, and a preset buffer time is given for the target instance to continue running. When the task execution status is idle, the preset buffer time has ended, or a hardware failure is detected, the target instance is cleaned up.

8. The method according to claim 7, characterized in that, The method further includes: When the target instance finishes execution, a differentiated cleanup operation is performed on the target instance according to the platform type to release memory resources; When the target instance meets the preset restart conditions, the target instance is restarted. The preset restart conditions include: the current mode is the post-startup cleanup mode, the remaining available time window is greater than the preset window threshold, and the cleanup is not triggered due to idle timeout.

9. A chip-emulated memory resource scheduling device, characterized in that, include: The request queue generation module is used to obtain test requests for memory resources in the target simulation platform and generate a request queue based on the test requests. The test requests include the project name, layout, and memory resource requirements. The dynamic resource allocation module is used to dynamically allocate resources to the request queue using the first-fit bin packing algorithm; The instance run management module is used to determine the platform type of the target simulation platform, and to start the instance of the target request that has been successfully allocated resources based on the platform type, so as to run the target instance.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-8.

11. A computer storage medium, characterized in that, The computer storage medium stores computer instructions that are used to cause a processor to execute the method of any one of claims 1-8.

Images