Method and system for multiplexing JTAG (joint test action group) interface based on FPGA (field programmable gate array)

Abstract

The invention relates to the technical field of FPGA development, and discloses a method and system for multiplexing a JTAG interface based on FPGA, and the method comprises the steps: receiving a plurality of JTAG task requests; creating an independent virtual JTAG interface logic channel for each JTAG task; calculating a dynamic scheduling score for each JTAG task based on a preset comprehensive scoring model; determining an execution sequence of the JTAG tasks; and circularly connecting a communication link of the physical JTAG interface to a virtual JTAG interface logic channel corresponding to the current JTAG task to be executed according to the execution sequence so as to execute the task. According to the method and the device, the independent virtual JTAG interface logic channel is created for each JTAG task and is decoupled from the physical interface, so that parallel management of multiple tasks on a logic level and ordered scheduling on a physical level are realized, and the overall processing capability of the interface in a multi-task concurrent scene is remarkably improved.

Description

Technical Field

[0001] This disclosure relates to the field of field-programmable gate array (FPGA) development technology, and specifically to a method and system for multiplexing a JTAG interface based on FPGA implementation. Background Technology

[0002] FPGAs are now widely used in many fields, and the Joint Test Action Group (JTAG) interface, as the core channel for communication between the host computer and the FPGA, undertakes a variety of key tasks.

[0003] However, FPGA development boards in related technologies are often equipped with only one JTAG interface, supporting only serial task processing. This leads to problems such as the inability to perform multi-task parallel processing, the inability to prioritize critical tasks, and insufficient communication efficiency. Therefore, how to achieve multi-task parallel processing under a single JTAG interface to meet the data transmission efficiency requirements of industrial applications has become an urgent problem to be solved. Summary of the Invention

[0004] In view of this, this disclosure provides a method and system for reusing JTAG interfaces based on FPGA to solve the problem of how to achieve multi-task parallel processing under a single JTAG interface, thereby meeting the data transmission efficiency requirements of industrial applications.

[0005] This disclosure provides a method for multiplexing a JTAG interface based on FPGA implementation, the method including: Receive multiple JTAG task requests from the host computer; Create an independent virtual JTAG interface logical channel for each JTAG task to decouple each JTAG task from a unique physical JTAG interface; Based on a pre-defined comprehensive scoring model, a dynamic scheduling score is calculated for each JTAG task; the comprehensive scoring model is calculated based at least on the priority attributes and historical request information of each JTAG task. The execution order of each JTAG task is determined based on the dynamic scheduling score. According to the execution order, the communication link of the physical JTAG interface is cyclically connected to the virtual JTAG interface logical channel corresponding to the currently executing JTAG task in order to execute the task.

[0006] This disclosure also provides a system for multiplexing a JTAG interface based on FPGA implementation, the system comprising: The receiving module is used to receive multiple JTAG task requests from the host computer. The virtual interface creation module is used to create an independent virtual JTAG interface logical channel for each JTAG task, so as to decouple each JTAG task from the unique physical JTAG interface; The scoring calculation module is used to calculate a dynamic scheduling score for each JTAG task based on a preset comprehensive scoring model; wherein the comprehensive scoring model is calculated based at least on the priority attributes and historical request information of each JTAG task. The scheduling and sorting module is used to determine the execution order of each JTAG task based on the dynamic scheduling score; The task execution module is used to connect the communication link of the physical JTAG interface to the virtual JTAG interface logical channel corresponding to the currently executed JTAG task in a cyclical manner according to the execution order, so as to execute the task.

[0007] This disclosure also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described FPGA-based multiplexed JTAG interface methods when executing the computer program.

[0008] This disclosure also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described methods for multiplexing a JTAG interface based on an FPGA.

[0009] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for implementing a multiplexed JTAG interface based on an FPGA.

[0010] In the FPGA-based method and system for reusing JTAG interfaces disclosed above, by creating an independent virtual JTAG interface logical channel for each JTAG task and decoupling it from the physical interface, parallel management of multiple tasks at the logical level and orderly scheduling at the physical level are achieved, thereby significantly improving the overall processing capability of the interface in multi-task concurrent scenarios. By calculating dynamic scheduling scores for tasks based on a comprehensive scoring model and determining the execution order accordingly, differentiated priority responses and scheduling for different types of tasks are achieved, ensuring that critical tasks are executed first, thus optimizing the task execution order. By dynamically connecting the communication links of the physical JTAG interface to the virtual channel corresponding to the highest priority task in a cyclical manner according to the optimized execution order, the sequential and alternating execution of multiple tasks by a single physical interface in the time dimension is realized, thereby completing time-division multiplexing of JTAG interface resources at the physical layer and improving the overall utilization rate of the JTAG interface. Attached Figure Description

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

[0012] Figure 1a A schematic diagram of the system architecture of the FPGA-based multiplexed JTAG interface used in the method of multiplexing JTAG interface based on FPGA provided in the embodiments of this disclosure. Figure 1b A flowchart illustrating a method for reusing a JTAG interface based on FPGA, provided in an embodiment of this disclosure; Figure 2 A state machine diagram illustrating a method for multiplexing a JTAG interface based on FPGA implementation, provided in an embodiment of this disclosure; Figure 3 A schematic diagram of the internal architecture and data flow of a JTAG resource scheduling module 114 in a system implementing a multiplexed JTAG interface based on FPGA, provided for embodiments of this disclosure; Figure 4 A schematic diagram of the structure of a system for multiplexing a JTAG interface based on FPGA provided in this disclosure embodiment; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

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

[0014] FPGA, as a programmable logic device, has been widely used in fields such as communications, image processing, and aerospace. During the development, debugging, and maintenance of FPGAs, the JTAG interface is the core communication channel between the host computer and the FPGA, undertaking key tasks such as device status monitoring, bitstream file loading, and hardware logic debugging.

[0015] However, in existing technologies, FPGA development boards are typically equipped with only one JTAG interface, which has the following obvious drawbacks: 1. Traditional methods in related technologies only support "sequential execution" or "forced interruption," and cannot achieve parallel processing of multiple tasks. For example, when debugging hardware, if it is necessary to monitor the device connection status simultaneously, the existing mechanism cannot meet this requirement, resulting in reduced development efficiency.

[0016] 2. Different tasks have significantly different real-time requirements. For example, bitstream loading tasks directly determine whether the FPGA enters normal operating mode and should be executed first. However, current technology does not distinguish priorities, and low-priority tasks may occupy JTAG resources for a long time, affecting the response of critical tasks.

[0017] 3. The related technical solutions are inefficient when transmitting large-volume bitstream files, and do not encrypt or verify the integrity of communication data, which poses security risks such as data tampering and unauthorized access, making it difficult to meet the dual requirements of data security and transmission efficiency for industrial applications.

[0018] Therefore, how to achieve efficient, secure, and prioritized scheduling of multiple tasks under a single JTAG interface has become a technical problem that urgently needs to be solved.

[0019] To address the aforementioned issues, various embodiments of this disclosure provide a method for reusing a JTAG interface based on an FPGA. The method includes: receiving multiple JTAG task requests from a host computer; creating an independent virtual JTAG interface logical channel for each JTAG task to decouple each JTAG task from a unique physical JTAG interface; calculating a dynamic scheduling score for each JTAG task based on a preset comprehensive scoring model; wherein the comprehensive scoring model is calculated based at least on the priority attributes and historical request information of each JTAG task; determining the execution order of each JTAG task according to the dynamic scheduling score; and, according to the execution order, cyclically connecting the communication link of the physical JTAG interface to the virtual JTAG interface logical channel corresponding to the currently executed JTAG task to execute the task.

[0020] It should be noted that, in the description of this disclosure, 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 disclosure are used to distinguish similar objects and are not used to describe a particular order or sequence.

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

[0022] Please refer to Figure 1a , Figure 1a A schematic diagram of the system architecture for the FPGA-based multiplexed JTAG interface method provided in this disclosure embodiment is shown below. Figure 1a As shown, the FPGA-based multiplexed JTAG interface system 100 (hereinafter referred to as system 100) includes: a host computer module 11 and an FPGA module 12. The host computer module 11 includes a human-machine interface module 111, a task allocation module 112, a task scheduling module 113 and a JTAG resource scheduling module 114.

[0023] In this embodiment, the host computer module 11 can be a collection of software functional modules running on the host, which can be used for the management, scheduling, and resource allocation of JTAG tasks. The host can refer to the main control computing device connected to the FPGA chip via a physical link in the FPGA development and debugging environment. For example, the host can include, but is not limited to, a computer, an embedded host, or a server.

[0024] Specifically, the host computer module 11 may mainly include the following sub-modules: The human-machine interface module 111 can be used to provide a user operation interface to receive and translate the user's debugging, configuration or monitoring intentions and generate initial JTAG task instructions. The task allocation module 112 is communicatively connected to the human-machine interface module 111. It can be used to receive initial JTAG task instructions, split composite JTAG tasks, calculate the initial priority weight of each task, and generate structured JTAG task requests. The task scheduling module 113 is communicatively connected to the task allocation module 112. It is used to manage the task execution process through a state machine and maintain the task queue. It calculates a dynamic scheduling score for each task based on a preset comprehensive scoring model and determines the execution order accordingly. JTAG resource scheduling module 114 is communicatively connected to task scheduling module 113 and FPGA module 12. It is used to manage the logical mapping relationship between virtual JTAG interface and unique physical JTAG interface, and dynamically allocate physical JTAG link resources according to the execution order.

[0025] Furthermore, FPGA module 12 can refer to hardware logic or firmware deployed inside or closely coupled to the FPGA chip, which can be used to directly drive the physical JTAG interface pins according to the commands issued by the host computer module 11, and complete the actual operation inside the FPGA.

[0026] Please refer to further information. Figure 1b , Figure 1bA flowchart illustrating a method for reusing a JTAG interface based on FPGA, provided in this embodiment of the disclosure, is applied to the above-mentioned... Figure 1a In the system 100 shown, the method may include the following steps: Step S101: Receive multiple JTAG task requests from the host computer.

[0027] In this embodiment, this step can be performed by the task allocation module 112 in system 100.

[0028] The host computer can refer to the main control computing device running the aforementioned host computer module 11 software. A JTAG task request can refer to a structured task description unit initiated by the human-machine interface module 111 and encapsulated by the task allocation module 112. Each JTAG task request must contain at least a task type identifier and necessary operation parameters.

[0029] Depending on the task objective, JTAG task requests can include, but are not limited to, the following categories: bitstream loading tasks, hardware debugging tasks, and device monitoring tasks.

[0030] The bitstream loading task can be used to download the user-designed circuit configuration file (i.e., bitstream file) to the configuration memory of the FPGA module 12, enabling its internal logic to run according to the design. The hardware debugging task can be used for real-time interaction with the loaded FPGA module 12, including but not limited to: reading and writing internal registers, setting breakpoints, and triggering signal acquisition. The device monitoring task can be used to query the status of the FPGA module 12 and the JTAG link itself, such as connection status, chip temperature, and power supply voltage.

[0031] These different types of tasks have varying requirements in terms of real-time performance and criticality, thus creating concurrent competition for JTAG interface resources.

[0032] The aforementioned JTAG task requests can be initiated by the user through the graphical user interface (GUI) of the host computer module 11 (i.e., through the GUI module 111). In a development or debugging session, the user may concurrently initiate multiple JTAG task requests of different types or targets.

[0033] For example, during system startup, a user may simultaneously request to load the bit stream (bit stream loading task) and start monitoring the chip status (device monitoring task). This scenario typically demonstrates the shortcomings of the traditional single JTAG interface serial processing mechanism.

[0034] Step S102: Create an independent virtual JTAG interface logical channel for each JTAG task to decouple each JTAG task from the unique physical JTAG interface.

[0035] In this embodiment, this step can be performed by the task allocation module 112 in system 100. By assigning a unique identifier to the task and establishing its binding relationship with the task, the creation of a virtual JTAG interface logical channel (hereinafter referred to as the virtual interface) is completed. The created virtual interface will be provided to the task scheduling module 113 for status management and will serve as the object of the physical resource mapping operation of the JTAG resource scheduling module 114.

[0036] A virtual interface can refer to an independent communication proxy entity created at the system logic level for each JTAG task. The purpose of creating a virtual interface is to logically separate the execution environment of each JTAG task from the unique physical JTAG interface hardware resource, that is, to achieve decoupling.

[0037] By creating an independent virtual channel for each JTAG task, the system can achieve task isolation, establish scheduling media, and support time-division multiplexing.

[0038] Each JTAG task can have its own independent communication state, data buffer, and protocol context, and they do not interfere with each other, logically allowing multiple tasks to exist in parallel. The virtual interface can serve as a unified operation object and intermediate carrier for the task scheduler (i.e., task scheduling module 113) to manage task states and for the JTAG resource scheduler (i.e., JTAG resource scheduling module 114) to allocate physical resources.

[0039] Furthermore, through the aforementioned virtual interfaces, the system can use scheduling strategies to determine when to map or switch the logical communication flow of which virtual interface to a single physical JTAG link for execution, thereby achieving time-based resource reuse at the physical level.

[0040] Furthermore, the decoupling in this embodiment can be specifically manifested as follows: the task execution lifecycle management and the real-time occupancy of the physical JTAG link are separated. JTAG tasks therefore do not need to directly compete for or be aware of the physical JTAG interface, but interact with the JTAG resource scheduling module 114 through their respective virtual interface; the JTAG resource scheduling module 114 is responsible for arbitrating the virtual interface's access rights to the physical JTAG link.

[0041] Step S103: Calculate a dynamic scheduling score for each JTAG task based on a preset comprehensive scoring model.

[0042] In this embodiment, this step can be performed by the task scheduling module 113 in system 100.

[0043] A comprehensive scoring model can be a set of predefined, quantifiable calculation rules, with the goal of transforming the diverse attributes and states of JTAG tasks into a unified dynamic scheduling score.

[0044] Among them, dynamic scheduling score can be used to measure which JTAG task is more worthy of priority to occupy physical JTAG interface resources at a certain moment.

[0045] Furthermore, the comprehensive scoring model is calculated based at least on the priority attributes of each JTAG task and historical request information.

[0046] The priority attribute can be used to reflect the urgency and importance of a JTAG task. For example, bitstream loading tasks related to system function setup typically have the highest inherent priority, while device monitoring tasks may have a relatively lower inherent priority.

[0047] Historical request information can reflect the behavior patterns and resource demands of JTAG tasks. For example, a JTAG task that is frequently requested but fails to execute multiple times due to resource constraints may have its score appropriately increased.

[0048] In addition, the comprehensive scoring model can also be calculated based on the estimated execution time. The estimated execution time can be used to characterize the expected execution duration of a JTAG task.

[0049] Understandably, through the comprehensive scoring model, the system can achieve dynamic and adaptive intelligent scheduling, and the calculated dynamic scheduling score will become the sole quantitative basis for determining the task execution order in subsequent steps, thereby ensuring that the scheduling decision not only responds to the criticality of the task, but also takes into account the overall efficiency and fairness of the system.

[0050] Step S104: Determine the execution order of each JTAG task based on the dynamic scheduling score.

[0051] In this embodiment, this step is performed by the task scheduling module 113 in system 100.

[0052] This step can be the core of the scheduling decision-making process. Its purpose is to transform the dynamic scheduling score calculated in step S103 into a clear execution sequence that can guide the allocation of physical resources.

[0053] Determining the execution order of each JTAG task can be a decision-making process.

[0054] The task scheduling module 113 compares and sorts the dynamic scheduling scores of all JTAG tasks to be scheduled according to preset sorting rules (such as descending order of scores), thereby generating an ordered task list.

[0055] This list can define the priority of JTAG tasks. That is, the higher the dynamic scheduling score of a JTAG task, the higher its position in the list, and the higher its priority in obtaining access to physical JTAG interface resources.

[0056] This step ensures that the most urgent and important tasks (such as the highest-rated bitstream loading task) are prioritized for execution, thereby optimizing the overall utilization efficiency of JTAG interface resources and meeting the real-time response requirements of critical tasks.

[0057] Step S105: According to the execution order, the communication link of the physical JTAG interface is cyclically connected to the virtual JTAG interface logical channel corresponding to the currently executed JTAG task in order to execute the task.

[0058] In this embodiment, this step can be primarily executed by the JTAG resource scheduling module 114 in system 100.

[0059] This step can serve as the final execution stage for physical JTAG resource reuse in the entire method. Its core lies in transforming the execution sequence into actual operations on the unique physical JTAG interface hardware, and achieving the orderly execution of multiple tasks through time-division multiplexing.

[0060] The cyclical connection in this step can be a dynamic iterative process, which may include the following steps: Step a1: JTAG resource scheduling module 114 obtains the highest priority task from task scheduling module 113, that is, the task ranked first in the execution order list; JTAG resource scheduling module 114 maps the communication link of the physical JTAG interface to the virtual JTAG interface identifier bound to the task.

[0061] Here, the mapping can establish a path from the logical context of the task to the physical JTAG pin.

[0062] In step a2, after the mapping is established, the instructions or data cached by the current highest priority task can be sent to the FPGA module 12 via the physical JTAG interface through the above communication link; the FPGA module 12 responds to the above instructions or data and completes the specific operation.

[0063] Step a3: After the current task is completed, the JTAG resource scheduling module 114 disconnects the mapping between the physical link and the virtual interface, releasing the physical resources. Subsequently, the JTAG resource scheduling module 114 retrieves the next JTAG task to be executed from the execution order list and repeats the above allocation, execution, and release process, thus forming a loop.

[0064] In the aforementioned dynamic iteration process, the virtual interface allows the physical JTAG interface to be unaware of complex task contexts and only needs to process the data stream from the currently mapped virtual interface; the task scheduling module 113 also only needs to be concerned with the sorting and updating of task states, without directly operating the hardware.

[0065] In the FPGA-based method and system for reusing JTAG interfaces disclosed above, by creating an independent virtual JTAG interface logical channel for each JTAG task and decoupling it from the physical interface, parallel management of multiple tasks at the logical level and orderly scheduling at the physical level are achieved, thereby significantly improving the overall processing capability of the interface in multi-task concurrent scenarios. By calculating dynamic scheduling scores for tasks based on a comprehensive scoring model and determining the execution order accordingly, differentiated priority responses and scheduling for different types of tasks are achieved, ensuring that critical tasks are executed first, thus optimizing the task execution order. By dynamically connecting the communication links of the physical JTAG interface to the virtual channel corresponding to the highest priority task in a cyclical manner according to the optimized execution order, the sequential and alternating execution of multiple tasks by a single physical interface in the time dimension is realized, thereby completing time-division multiplexing of JTAG interface resources at the physical layer and improving the overall utilization rate of the JTAG interface.

[0066] In one possible implementation of step S101 above, multiple JTAG task requests are received from the host computer, including: Receive JTAG task requests initiated by the host computer, including at least one of the following types: bit stream loading, hardware debugging, and device monitoring; In response to receiving a composite JTAG task request, the composite JTAG task request is split into multiple subtasks with different priorities.

[0067] In this embodiment, this implementation method can be specifically executed by the task allocation module 112 in system 100.

[0068] A composite JTAG task request can refer to a task request that contains multiple independently executable or operation units with different properties.

[0069] For example, a hardware debugging task is a composite JTAG task request, which may include write operations to write configuration or control instructions to the FPGA, or read operations to read status or acquired data from the FPGA.

[0070] When the task allocation module 112 receives such a composite task, it parses and splits it. The core principle of splitting can be to assign different initial priorities to subtasks based on their operational nature or degree of influence on the system state.

[0071] For example, the hardware debugging task mentioned above can be divided into high-priority subtasks and low-priority subtasks.

[0072] Here, writing configuration instructions is a high-priority subtask because write operations usually directly affect the FPGA's operating status or the establishment of the debugging process, and need to be executed first to ensure the correctness of subsequent operations; while reading acquired data is a priority subtask because read operations mainly obtain the existing state and have little immediate impact on the system's operation, and can be executed when resources are idle.

[0073] Preferably, the bit stream loading task can be referred to as task A, the hardware debugging task as task B, and the device monitoring task as task C; the write configuration instruction in the hardware debugging task can be referred to as subtask B1, and the read acquisition data can be referred to as subtask B2.

[0074] By breaking down a complex JTAG task into multiple subtasks with finer granularity and clearer priority definitions, these subtasks can serve as independent scheduling units and enter the subsequent virtual interface creation and scheduling process. This allows the system to perform more refined resource management, preventing a large complex task from monopolizing the JTAG interface for an extended period due to inefficient internal operations.

[0075] In the FPGA-based method and system for reusing JTAG interfaces disclosed above, the composite task is split into multiple independent subtasks, enabling the system to schedule and manage tasks at a finer granularity, thereby optimizing task granularity. By identifying and distinguishing the priorities of different operation units within the composite task and reflecting them during splitting, the subsequent task scheduling module 113 can make decisions based on more accurate priority information, ensuring that critical operations are executed first and improving the system's ability to respond to critical requests.

[0076] In one possible implementation of step S102 above, an independent virtual JTAG interface logical channel is created for each JTAG task, including: Assign a unique virtual JTAG interface identifier to each JTAG task or subtask; Each virtual JTAG interface identifier is bound to its corresponding JTAG task or subtask, and the bound JTAG task or subtask is placed in the preparation list of the task queue.

[0077] In this embodiment, this implementation method can be executed by the task allocation module 112 in system 100.

[0078] A virtual JTAG interface identifier can be a unique logical identifier assigned by the system to each JTAG task or subtask. This identifier can be used to uniquely identify and distinguish the logical channel associated with the task within the system.

[0079] Here, the assignment of identifiers ensures the distinguishability and addressability of each task or subtask entity within the system.

[0080] Furthermore, binding identifiers to tasks or subtasks establishes a fixed association between the task or subtask and its virtual interface. After binding, all state information of the task or subtask (e.g., including but not limited to instructions or data to be sent, JTAG state machine position, expected response, etc.) can be maintained and managed within the context of this virtual interface, isolated from other tasks.

[0081] Furthermore, the bound tasks or subtasks can be placed in a preparation list of a uniformly managed task queue.

[0082] The preparation list can be an initial state container in the task queue, used to store all tasks that have completed virtual interface creation but have not yet met the subsequent execution conditions (e.g., waiting for the scheduler to perform qualification checks and scoring calculations).

[0083] Here, placing a task or subtask into the preparation list indicates that the task or subtask has completed initialization and thus enters the system's scheduling and management scope.

[0084] Through the above process, each JTAG task or subtask has its own independent virtual interface, and these virtual interfaces are uniformly identified and managed in the system. This achieves decoupling between tasks or subtasks and physical JTAG interfaces, because the task scheduling module 113 only needs to operate on the virtual interface identifier, while the JTAG resource scheduling module 114 is responsible for mapping virtual interfaces to physical interfaces.

[0085] In the FPGA-based method and system for reusing JTAG interfaces disclosed above, by assigning an independent virtual interface identifier to each task and incorporating it into a unified queue for management, the management and scheduling of tasks are completely independent of the actual state of the physical JTAG interface, thereby achieving complete decoupling between tasks and the physical JTAG interface. Binding task identifiers and placing them uniformly in a preparation list allows all scheduled tasks to be in a centralized and uniformly managed state, ensuring the controllability and predictability of the entire scheduling process. Since each task or subtask has an independent virtual interface identifier and is in the preparation list, the task scheduling module 113 can make independent scheduling decisions on a per-task or per-subtask basis. This allows the system to more finely differentiate and process tasks of different priorities, avoiding the situation where a large task blocks the entire scheduling channel, and significantly improving the system's processing capacity and response flexibility in multi-task concurrent scenarios.

[0086] In one possible implementation of step S103 above, a dynamic scheduling score is calculated for each JTAG task based on a preset comprehensive scoring model, including: Obtain the priority score, estimated execution time, and historical request count for each JTAG task; Priority score, estimated execution time, and historical request count are input into the comprehensive scoring model for calculation to obtain the dynamic scheduling score for each JTAG task.

[0087] In this embodiment, the implementation can be executed by the task scheduling module 113 in system 100, and its core lies in building and applying a comprehensive scoring model.

[0088] Priority scores can be static integers used to comprehensively reflect the criticality of task type and internal operations.

[0089] The estimated execution time refers to the time the system predicts will be required for the task to fully utilize the physical JTAG interface for execution. This data can be obtained from the historical task-duration statistics table maintained by the system.

[0090] Introducing this parameter here can give shorter tasks a certain scheduling advantage, thereby avoiding excessive blocking of the communication link by long-running tasks such as large file transfers.

[0091] Historical request counts can refer to the cumulative number of times a task (or similar tasks) has requested JTAG resources throughout its history. By incorporating historical request counts into the model, the system can dynamically improve the scores of tasks that have been delayed multiple times, thereby ensuring fairness for all tasks in long-term scheduling.

[0092] Preferably, the priority score can be represented by P, the estimated execution time can be represented by E, and the number of historical requests can be represented by F.

[0093] Since P, E, and F have different dimensions, they need to be normalized to the 0-1 interval to eliminate the influence of dimensions. The specific formula is as follows:

[0094] in, Identify the nth task or subtask. The preset maximum weight value within the system, for example, .

[0095]

[0096] in, The optimal time is 20 seconds. If the execution time exceeds 20 seconds, it will be truncated to the maximum of 20 seconds.

[0097]

[0098] in, The maximum number of requests can be 10. If the number of historical requests is greater than 10, the request will be truncated to the maximum of 10.

[0099] Furthermore, the normalized priority scores Estimated execution time Number of historical requests Input the comprehensive scoring model and use a weighted geometric average to calculate the dynamic scheduling score for each JTAG task.

[0100] The comprehensive scoring model can be as follows:

[0101] Among them, the exponential coefficient , and It can be preset offline, for example, .

[0102] For example, assuming task A has a priority score P=30, the normalized priority score is calculated. If the number of historical requests F = 2, then the normalized number of historical requests is... If the estimated execution time E = 10s, then the normalized estimated execution time is... The dynamic scheduling score S was calculated to be 48.

[0103] In the FPGA-based method and system for reusing JTAG interfaces disclosed in the above embodiments, a three-dimensional quantitative model that simultaneously considers task priority, execution efficiency, and scheduling fairness is constructed to generate a dynamic score that comprehensively and objectively reflects the real-time scheduling value of tasks. This can effectively solve the problem that low-priority tasks may occupy JTAG resources for a long time, affecting the response of critical tasks, and improve the communication efficiency of task scheduling.

[0104] In one possible implementation of step S103 above, the priority score for each JTAG task is obtained, including: Determine the primary weight of each JTAG task based on its task type. If the JTAG task is a hardware debugging task that includes read and write operations, then the secondary weight is determined according to the operation type of the hardware debugging task. Priority scores are generated based on primary and secondary weights.

[0105] In this embodiment, the task types of JTAG tasks may include task A (i.e., bit stream loading task), task B (i.e., hardware debugging task), and task C (i.e., device monitoring task). The composite task B can be further divided into subtask B1 (i.e., reading acquisition data) and subtask B2 (i.e., writing configuration instructions).

[0106] Preferably, assuming that the first-level weight of task A is 3, the first-level weight of task B is 2, and the first-level weight of task C is 1, then the first-level weight of task A > the first-level weight of task B > the first-level weight of task C.

[0107] Furthermore, assuming that the secondary weight of subtask B1 is 1 and the secondary weight of subtask B2 is 2, then the secondary weight of subtask B1 is 2 > the secondary weight of subtask B2 is 1.

[0108] Furthermore, the priority score of task A is 30, the priority score of task B2 is 22, the priority score of task B1 is 21, and the priority score of task C is 10. Therefore, the execution order is A→B2→B1→C, that is, task A is executed first, followed by subtask B2, then subtask B1, and finally task C.

[0109] In the FPGA-based method and system for reusing JTAG interfaces disclosed in the above embodiments, by introducing a two-level weighting approach, the qualitative judgment of task priority is transformed into structured quantitative calculation. This allows for more accurate identification and labeling of truly critical sub-modules within a task, thereby achieving refined and structured differentiation of task priorities. Even within tasks of the same type, the system can clearly distinguish and prioritize operations that have an immediate and critical impact on system operation and debugging processes, effectively ensuring the absolute priority response of critical operations and fundamentally alleviating resource congestion.

[0110] In one possible implementation of step S104 above, the execution order of each JTAG task is determined based on the dynamic scheduling score, including: Select a JTAG task or subtask that meets the preset execution conditions from the preparation list of the task queue, and move the JTAG task or subtask to the waiting list of the task queue. Based on the dynamic scheduling score of each JTAG task or subtask in the waiting list, the tasks in the waiting list are sorted to generate the execution order of each JTAG task or subtask.

[0111] In this embodiment, this implementation can be performed by the task scheduling module 113 in system 100.

[0112] The task scheduling module 113 can maintain a state machine for controlling the execution flow of system tasks. This state machine can contain multiple states corresponding to various JTAG tasks. For example, the states can include, but are not limited to: Reset, Init_B, Process, Monitor_Wait, Monitor_Run, Monitor_Exit, Prog_Wait, Prog_Run, Prog_Exit, User Mode, Dhub_Wait, Dhub_Run, Dhub_Exit, etc.

[0113] Before the FPGA is powered on, the state machine is in the Reset state. After power-on, the state machine automatically switches to the Init_B state. After the Init_B signal goes high (detecting that the FPGA is powered on normally), it switches to the Process state.

[0114] Here, after the system is powered on and initialized, the state machine enters the Process state, and this step begins execution.

[0115] Meeting preset execution conditions can be the filtering criteria for a task to move from the preparation list to the waiting list, and its core can include state dependency conditions.

[0116] The preset execution condition may refer to the requirement that certain types of JTAG tasks can only be executed when the system (or FPGA) is in a specific operating mode or state. The task scheduling module 113 determines whether a task meets its state dependency condition by querying the current state of the state machine.

[0117] Preferably, the management process for state dependency conditions can be as follows: Task scheduling module 113 checks the execution prerequisite states required for each task in the preparation list. For example, hardware debugging tasks may require the FPGA to have a bitstream loaded and to be in user working mode (corresponding to the UserMode state of the state machine). Only when the state machine is currently in the UserMode state is such a task deemed to meet the state dependency condition and thus eligible to be moved to the waiting list. For tasks such as bitstream loading tasks or device monitoring tasks that may not require specific mode prerequisites, the conditions are considered met once the state machine enters the Process state.

[0118] All tasks that are determined to meet the execution conditions (including state dependency conditions and other basic conditions) will be moved from the preparation list to the waiting list of the task queue by the task scheduling module 113. After entering the waiting list, the task is in a ready state, waiting to be scheduled for execution.

[0119] Subsequently, the task scheduling module 113 sorts all tasks in the waiting list according to the dynamic scheduling score (for example, sorting them in descending order of score). This sorting result generates the execution order at the current moment. This order is dynamic and will be recalculated as new tasks are added or task scores are updated.

[0120] By introducing a state machine for condition checks, this implementation can intelligently manage the dependencies between tasks, ensuring that only tasks that truly meet the execution prerequisites will enter the resource competition phase. This avoids ineffective scheduling and potential errors, and provides a reasonable and reliable task sequence for subsequent steps.

[0121] In the FPGA-based method and system for reusing JTAG interfaces disclosed in the above embodiments, by combining state machine condition checks, the system can identify and manage the dependencies between tasks. Only tasks that truly meet the execution prerequisites will enter the waiting queue for competing resources, avoiding invalid scheduling and potential execution errors, and improving the accuracy of scheduling decisions and system stability. Real-time sorting of tasks in the waiting list based on dynamic scheduling scores ensures that the execution order accurately reflects the real-time urgency of tasks, guaranteeing the timeliness and rationality of scheduling responses, and providing the optimal sequence input for efficient reuse of physical resources.

[0122] In one possible implementation of step S105 above, the communication links of the physical JTAG interface are cyclically connected to the virtual JTAG interface logical channel corresponding to the currently executed JTAG task, according to the execution order, including: Based on the generated execution order, the JTAG task or subtask that is first in the waiting list is moved into the run list of the task queue in turn; Map the virtual JTAG interface identifier bound to a JTAG task or subtask in the run list to the communication link of the physical JTAG interface to execute the task.

[0123] In this embodiment, the implementation is carried out collaboratively by the task scheduling module 113 and the JTAG resource scheduling module 114 in system 100, forming a closed loop from scheduling decision to physical execution.

[0124] Specifically, the loop process can be executed as follows: Step b1: The task scheduling module 113 moves the task with the highest score (first in the order) in the waiting list to the running list of the task queue according to the currently valid execution order. At the same time, the system control state machine jumps from the current state to the running state corresponding to the task type (for example, for a bitstream loading task, it jumps to the Prog_Run state). This jump can mark that the task has officially obtained the right to execute.

[0125] Step b2: In response to a task entering the run list and a state machine transition, the JTAG resource scheduling module 114 performs the core operation: dynamically mapping the communication link of the physical JTAG interface to the virtual JTAG interface identifier bound to the running task. After the mapping is established, all communication data of the task is transmitted through this exclusive physical link, and the hardware logic of the FPGA module 12 performs specific bit stream loading, debug access, or status monitoring operations.

[0126] Step b3: After the current task is completed, the task scheduling module 113 removes it from the running list. Simultaneously, the state machine exits the running state and transitions to the appropriate state based on system conditions (e.g., transitioning to the UserMode state after successful bitstream loading). The JTAG resource scheduling module 114 then disconnects the mapping between the virtual interface and the physical JTAG link, releasing physical resources.

[0127] Step b4: After the physical resources are released, the JTAG resource scheduling module 114 immediately notifies the task scheduling module 113. The task scheduling module 113 then moves the next highest-ranked task into the run list according to the latest execution order, repeating the above process of state transition-resource mapping-execution-release, thereby realizing the looping of physical JTAG interface resources.

[0128] Optionally, during task execution (especially during critical operations such as bitstream loading), data security and efficiency enhancement mechanisms can be further integrated. For example, compression can be performed before data transmission to improve efficiency, and digital signatures can be used to verify the source and integrity of the data before loading, thereby improving transmission efficiency while ensuring communication security.

[0129] In the FPGA-based method and system for reusing the JTAG interface disclosed in the above embodiments, by coupling queue state transitions (i.e., from the waiting list to the running list), state machine state transitions, and physical resource mapping operations, it is ensured that scheduling decisions can be translated into actual hardware actions without errors and in a timely manner, forming a closed loop from decision-making to execution, which greatly improves the reliability and determinism of the system. By using a state machine to identify and drive changes in key stages of the system, subsequent tasks that depend on this stage can be correctly activated. This ensures the logical correctness and timing rationality of the system state evolution in multi-task scenarios, effectively solving the deadlock or out-of-order problems caused by dependencies between tasks. Through a digital signature authentication mechanism, source verification and integrity checks are performed before data transmission, effectively preventing data tampering and forgery, and significantly enhancing the security of the communication process.

[0130] In one possible implementation of step S105 above, the method further includes, in the process of mapping the virtual JTAG interface identifier bound to the JTAG task or subtask in the run list to the communication link of the physical JTAG interface to execute the task: When a new JTAG task or subtask is received, calculate the dynamic scheduling score of the new JTAG task or subtask. If the dynamic scheduling score of the new JTAG task or subtask is higher than the dynamic scheduling score of the currently executing JTAG task or subtask, then perform the following steps: Pause and save the communication state of the currently executing JTAG task or subtask; Move the currently executing JTAG task or subtask from the run list of the task queue back to the wait list of the task queue; The communication link of the physical JTAG interface is switched and mapped to the virtual JTAG interface identifier bound to the new JTAG task or subtask, and the new JTAG task or subtask is moved into the run list of the task queue for execution. After a new JTAG task or subtask is completed, based on the saved communication state, the previously suspended JTAG task or subtask is remapped to the communication link of the physical JTAG interface to resume execution, and the task is moved back into the task queue's run list.

[0131] In this embodiment, the implementation method can be jointly executed by the task scheduling module 113 and the JTAG resource scheduling module 114 in the system 100 to realize the dynamic preemption and recovery mechanism of high-priority tasks.

[0132] Specifically, when the system is executing the current task normally, the task allocation module 112 may receive a new JTAG task request. The task scheduling module 113 can understand that the dynamic scheduling score of the new task is calculated based on the comprehensive scoring model and compare it with the dynamic scheduling score of the current task in real time.

[0133] At this point, if the dynamic scheduling score of the new task is higher than that of the current task, the following preemption process is triggered: JTAG resource scheduling module 114 first suspends the data transmission of the current task through the physical JTAG interface, and fully saves the communication state maintained by the current task through its virtual JTAG interface logical channel.

[0134] For example, the communication state may include, but is not limited to: the current position of the JTAG protocol state machine, the pointer to the data buffer that has not yet been transmitted, and the context of a command that has been issued but not yet read back.

[0135] Subsequently, the task scheduling module 113 removes the current task from the running list and adds it back to the waiting list. At this time, the task's status flag in the queue may be updated to the corresponding waiting status.

[0136] JTAG resource scheduling module 114 switches the communication link of the physical JTAG interface from the virtual interface identifier of the original task to the virtual interface identifier of the new task. Simultaneously, task scheduling module 113 moves the new task to the run list and triggers the state machine to transition to its corresponding running state. Subsequently, the system begins executing this high-priority new task.

[0137] After the high-priority new task is completed, the system performs the following recovery operation: Task scheduling module 113, based on the previously saved communication state, notifies JTAG resource scheduling module 114 to remap the physical JTAG link to the virtual interface identifier of the suspended task, and resumes the execution of the task from the saved state point. The task is then moved back from the waiting list to the running list to continue completing its remaining operations.

[0138] Through the above mechanism, the system can immediately respond to higher priority emergency tasks without waiting for the current task to complete naturally, and seamlessly resume the original task after the emergency task is handled, thus achieving a balance between scheduling flexibility and task execution integrity.

[0139] As a specific embodiment, assuming that subtask B2 is being executed, the host computer module 11 initiates an emergency task D for bit stream update, and the dynamic scheduling score of the emergency task is higher than the dynamic scheduling score of the current task B2.

[0140] At this point, save a snapshot of the current state of task B2; pause task B2 and release JTAG resources; execute task D and load the new bitstream; after task D completes, restore the snapshot of task B2 and continue executing the remaining configuration instructions.

[0141] In the FPGA-based method and system for reusing the JTAG interface disclosed in the above embodiments, by comparing the dynamic scheduling scores of new tasks and currently executing tasks in real time and triggering preemption accordingly, this scheme enables tasks with higher urgency to immediately interrupt lower-priority tasks and acquire JTAG resources, achieving true dynamic priority scheduling and completely solving the problem of critical tasks being blocked. By saving and restoring the complete communication state, it can ensure the integrity of task states and the accuracy of execution logic while supporting preemption, and also greatly improves the system's responsiveness and flexibility in the face of urgent tasks.

[0142] In one embodiment, please refer to Figure 2 , Figure 2 A state machine diagram illustrating a method for multiplexing a JTAG interface based on FPGA implementation, as provided in this disclosure embodiment, is shown below. Figure 2 As shown, a state machine defines all possible states and transition logic of the system during the entire process of task scheduling and execution. The state machine can mainly include the following five types of states: system basic state, task waiting state, task execution state, task exit state, and user mode state.

[0143] The system's basic states can include: Reset, Init_B, and Process. After power-on, the system transitions from Reset to Process via Init_B, and thereafter, task condition checks and scheduling decisions are made based on this state.

[0144] Task waiting states can include: Prog_Wait (bitstream loading wait), Dhub_Wait (hardware debugging wait), and Monitor_Wait (device monitoring wait). A task enters the corresponding waiting state when the scheduler determines that it meets the execution conditions but has not yet acquired physical JTAG resources.

[0145] Task execution states can include: Prog_Run (bitstream loading run), Dhub_Run (hardware debugging run), and Monitor_Run (device monitoring run). When a task acquires physical JTAG resources and begins execution, the state machine switches to the corresponding running state.

[0146] Task exit states can include: Prog_Exit (bitstream loading exit), Dhub_Exit (hardware debugging exit), and Monitor_Exit (device monitoring exit). After task execution is complete, it enters a brief exit state to release resources and clean up its state.

[0147] User Mode: Once the bitstream loading task (Prog_Run) has successfully completed, the state machine switches to User Mode, indicating that the FPGA has entered the user-designed operating mode. Only then are hardware debugging tasks (Dhub_Wait / Dhub_Run) allowed to execute.

[0148] In one embodiment, please refer to Figure 3 , Figure 3 A schematic diagram illustrating the internal architecture and data flow of a JTAG resource scheduling module 114 in a system implementing a multiplexed JTAG interface based on FPGA, as provided in this disclosure embodiment, is shown below. Figure 3 As shown in the figure, this diagram can represent the key logical relationships implemented internally by the JTAG resource scheduling module 114, which serves as the core hub connecting the upper-layer task scheduling and the lower-layer physical interface.

[0149] The input to the JTAG resource scheduling module 114 can come from the task queue managed by the task scheduling module 113. Each JTAG task in the queue (e.g., task 1, task 2, ..., task n) is uniquely bound to a virtual interface (e.g., virtual interface 1, interface 2, ..., interface n).

[0150] The core function of the JTAG resource scheduling module 114 is to maintain and execute a dynamic mapping strategy. Based on the execution order issued by the task scheduling module 113, at any given time, the logical access right of the unique physical JTAG interface is dynamically allocated and mapped to the virtual JTAG interface corresponding to the current highest priority task.

[0151] Through the mapping operations described above, a physical JTAG link serves only one virtual interface and the task it represents at any given time. When the task is completed or preempted according to the scheduling policy, the module will remove the current mapping and immediately establish the next mapping according to the new execution order.

[0152] In one embodiment, a system 400 for multiplexing a JTAG interface based on an FPGA is provided. This system 400 corresponds one-to-one with the method for multiplexing a JTAG interface based on an FPGA in the above embodiments. Figure 4 As shown, the system includes: The receiving module 401 is used to receive multiple JTAG task requests from the host computer; The virtual interface creation module 402 is used to create an independent virtual JTAG interface logical channel for each JTAG task, so as to decouple each JTAG task from the unique physical JTAG interface. The scoring calculation module 403 is used to calculate a dynamic scheduling score for each JTAG task based on a preset comprehensive scoring model; wherein the comprehensive scoring model is calculated based at least on the priority attributes and historical request information of each JTAG task. The scheduling and sorting module 404 is used to determine the execution order of each JTAG task based on the dynamic scheduling score. The task execution module 405 is used to cyclically connect the communication link of the physical JTAG interface to the virtual JTAG interface logical channel corresponding to the currently executed JTAG task according to the execution order, so as to execute the task.

[0153] In one embodiment, the receiving module 401 is specifically used to receive a JTAG task request initiated by the host computer, which includes at least one of the following types: bit stream loading, hardware debugging, and device monitoring. In response to receiving a composite JTAG task request, the composite JTAG task request is split into multiple subtasks with different priorities.

[0154] In one embodiment, the virtual interface creation module 402 specifically assigns a unique virtual JTAG interface identifier to each JTAG task or subtask. Each virtual JTAG interface identifier is bound to its corresponding JTAG task or subtask, and the bound JTAG task or subtask is placed in the preparation list of the task queue.

[0155] In one embodiment, the scoring calculation module 403 is specifically used to obtain the priority score, estimated execution time and historical request count for each JTAG task. The priority score, the estimated execution time, and the number of historical requests are input into the comprehensive scoring model for calculation to obtain the dynamic scheduling score corresponding to each JTAG task.

[0156] In one embodiment, the scoring calculation module 403 is specifically used to determine the first-level weight of each JTAG task based on the task type of each JTAG task. If the JTAG task is a hardware debugging task that includes read and write operations, then the secondary weight is determined according to the operation type of the hardware debugging task. The priority score is generated based on the primary weight and the secondary weight.

[0157] In one embodiment, the scheduling and sorting module 404 is specifically used to select JTAG tasks or subtasks that meet preset execution conditions from the preparation list of the task queue, and move the JTAG tasks or subtasks into the waiting list of the task queue. Based on the dynamic scheduling score of each JTAG task or subtask in the waiting list, the tasks in the waiting list are sorted to generate the execution order of each JTAG task or subtask.

[0158] In one embodiment, the task execution module 405 is specifically used to move the JTAG task or subtask ranked first in the waiting list into the running list of the task queue according to the generated execution order. The virtual JTAG interface identifier bound to the JTAG task or subtask in the run list is mapped to the communication link of the physical JTAG interface to execute the task.

[0159] In one embodiment, the system further includes an interrupt execution module 406, wherein: The interrupt execution module 406 is used to calculate the dynamic scheduling score of the new JTAG task or subtask when a new JTAG task or subtask is received. If the dynamic scheduling score of the new JTAG task or subtask is higher than the dynamic scheduling score of the currently executing JTAG task or subtask, then the following steps are performed: Pause and save the communication state of the currently executing JTAG task or subtask; Move the currently executing JTAG task or subtask from the run list of the task queue back to the wait list of the task queue; The communication link of the physical JTAG interface is switched and mapped to the virtual JTAG interface identifier bound to the new JTAG task or subtask, and the new JTAG task or subtask is moved into the run list of the task queue for execution. After the new JTAG task or subtask is completed, the previously suspended JTAG task or subtask is remapped to the communication link of the physical JTAG interface to resume execution, based on the saved communication state, and the task is moved back into the running list of the task queue.

[0160] It should be noted that the above embodiments of the FPGA-based multiplexed JTAG interface system, when implementing the corresponding FPGA-based multiplexed JTAG interface method, only illustrate the division of the above program modules. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the above system can be divided into different program modules to complete all or part of the processing described above. Furthermore, the system provided in the above embodiments and the corresponding... Figure 1b The embodiments of the methods shown belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0161] This disclosure also provides an electronic device having the above-described features. Figure 4 The system shown is based on an FPGA and reuses the JTAG interface.

[0162] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure.

[0163] The following is a detailed reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from memory 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device. The processor 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0164] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0165] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a memory 508, or installed from a ROM 502. When the computer program is executed by the processor 501, it performs the functions defined in the network data stream hardware offloading method for heterogeneous descriptor unified processing of embodiments of this disclosure.

[0166] Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0167] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the network data stream hardware offloading method for unified processing of heterogeneous descriptors shown in the above embodiments is implemented.

[0168] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0169] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for reusing a JTAG interface based on FPGA implementation, characterized in that, The method includes: Receive multiple JTAG task requests from the host computer; Create an independent virtual JTAG interface logical channel for each JTAG task to decouple each JTAG task from a unique physical JTAG interface; Based on a preset comprehensive scoring model, a dynamic scheduling score is calculated for each JTAG task; wherein the comprehensive scoring model is calculated based at least on the priority attributes and historical request information of each JTAG task. The execution order of each JTAG task is determined based on the dynamic scheduling score. According to the execution order, the communication link of the physical JTAG interface is cyclically connected to the virtual JTAG interface logical channel corresponding to the currently executed JTAG task in order to execute the task.

2. The method according to claim 1, characterized in that, The receiving of multiple JTAG task requests from the host computer includes Receive JTAG task requests initiated by the host computer, including at least one of the following types: bit stream loading, hardware debugging, and device monitoring; In response to receiving a composite JTAG task request, the composite JTAG task request is split into multiple subtasks with different priorities.

3. The method according to claim 1, characterized in that, The step of creating an independent virtual JTAG interface logical channel for each JTAG task includes: Assign a unique virtual JTAG interface identifier to each JTAG task or subtask; Each virtual JTAG interface identifier is bound to its corresponding JTAG task or subtask, and the bound JTAG task or subtask is placed in the preparation list of the task queue.

4. The method according to any one of claims 1-3, characterized in that, The preset comprehensive scoring model calculates a dynamic scheduling score for each JTAG task, including: Obtain the priority score, estimated execution time, and historical request count for each JTAG task; The priority score, the estimated execution time, and the number of historical requests are input into the comprehensive scoring model for calculation to obtain the dynamic scheduling score corresponding to each JTAG task.

5. The method according to claim 4, characterized in that, The process of obtaining the priority score for each JTAG task includes: Determine the primary weight of each JTAG task based on its task type. If the JTAG task is a hardware debugging task that includes read and write operations, then the secondary weight is determined according to the operation type of the hardware debugging task. The priority score is generated based on the primary weight and the secondary weight.

6. The method according to claim 1 or 3, characterized in that, The step of determining the execution order of each JTAG task based on the dynamic scheduling score includes: Select a JTAG task or subtask that meets the preset execution conditions from the preparation list of the task queue, and move the JTAG task or subtask into the waiting list of the task queue. Based on the dynamic scheduling score of each JTAG task or subtask in the waiting list, the tasks in the waiting list are sorted to generate the execution order of each JTAG task or subtask.

7. The method according to claim 6, characterized in that, The step of cyclically connecting the communication link of the physical JTAG interface to the virtual JTAG interface logical channel corresponding to the currently executed JTAG task according to the execution order includes: Based on the generated execution order, the JTAG task or subtask that is first in the waiting list is moved into the run list of the task queue in turn; The virtual JTAG interface identifier bound to the JTAG task or subtask in the run list is mapped to the communication link of the physical JTAG interface to execute the task.

8. The method according to claim 7, characterized in that, In the process of mapping the virtual JTAG interface identifier bound to the JTAG task or subtask in the run list to the communication link of the physical JTAG interface to execute the task, the method further includes: When a new JTAG task or subtask is received, a dynamic scheduling score for the new JTAG task or subtask is calculated. If the dynamic scheduling score of the new JTAG task or subtask is higher than the dynamic scheduling score of the currently executing JTAG task or subtask, then the following steps are performed: Pause and save the communication state of the currently executing JTAG task or subtask; Move the currently executing JTAG task or subtask from the run list of the task queue back to the wait list of the task queue; The communication link of the physical JTAG interface is switched and mapped to the virtual JTAG interface identifier bound to the new JTAG task or subtask, and the new JTAG task or subtask is moved into the run list of the task queue for execution. After the new JTAG task or subtask is completed, based on the saved communication state, the previously suspended JTAG task or subtask is remapped to the communication link of the physical JTAG interface to resume execution, and the task is moved back into the running list of the task queue.

9. A system for multiplexing a JTAG interface based on FPGA implementation, characterized in that, The system includes: The receiving module is used to receive multiple JTAG task requests from the host computer. The virtual interface creation module is used to create an independent virtual JTAG interface logical channel for each JTAG task, so as to decouple each JTAG task from the unique physical JTAG interface. The scoring calculation module is used to calculate a dynamic scheduling score for each JTAG task based on a preset comprehensive scoring model; wherein the comprehensive scoring model is calculated based at least on the priority attributes and historical request information of each JTAG task. The scheduling and sorting module is used to determine the execution order of each JTAG task based on the dynamic scheduling score. The task execution module is used to cyclically connect the communication link of the physical JTAG interface to the virtual JTAG interface logical channel corresponding to the currently executed JTAG task according to the execution order, so as to execute the task.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for multiplexing a JTAG interface based on an FPGA as described in any one of claims 1 to 8 when executing the computer program.

11. 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 method for multiplexing a JTAG interface based on an FPGA as described in any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for multiplexing the JTAG interface based on FPGA as described in any one of claims 1 to 8.

Images