LSTM Task Context Mapping and Inference State Switching Methods and Electronic Devices

Abstract

This application provides an LSTM task context mapping and inference state switching method and electronic device, belonging to the field of LSTM state calculation technology. The method includes: acquiring context information for each task; constructing a task context mapping table based on the context information of each task; freezing the updated LSTM inference state of the current task after inference is completed, and updating the task context mapping table based on the frozen LSTM inference state; and restoring the LSTM inference state of the task when scheduling the next task, based on the state buffer address corresponding to the task retrieved from the updated task context mapping table. This application's solution can improve the prediction accuracy of LSTM.

Description

Technical Field

[0001] This application relates to the field of LSTM state computation technology, specifically to an LSTM task context mapping and inference state switching method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] In recent years, in order to improve the ability of navigation receivers to perceive timing features, more and more systems have introduced LSTM (Long Short-Term Memory) into GNSS (Global Navigation Satellite System) chips to model the evolution of various signal states.

[0003] In practical navigation systems, multiple LSTM tasks typically exist simultaneously, run concurrently, or are frequently triggered alternately. As a model with temporal memory characteristics, the prediction accuracy of LSTM is highly dependent on the continuity and consistency of the inference state of the previous frame.

[0004] However, the LSTM structure in traditional GNSS chips, designed for single-task operation, suffers from a break in the continuity of inference states when multiple tasks coexist, resulting in low prediction accuracy. Therefore, improving the prediction accuracy of LSTM remains an unsolved problem. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, electronic device, and computer-readable storage medium for LSTM task context mapping and inference state switching, which can solve the problem of low prediction accuracy of LSTM in the prior art.

[0006] In a first aspect, embodiments of this application provide an LSTM task context mapping and inference state switching method, the method comprising:

[0007] Obtain the context information for each task;

[0008] Based on the context information of each task, construct a task context mapping table;

[0009] After the current task inference is completed, the updated LSTM inference state of the current task is frozen, and the task context mapping table is updated based on the frozen LSTM inference state.

[0010] When scheduling the next task, the LSTM inference state of the task is restored based on the state buffer address corresponding to the task retrieved from the updated task context mapping table.

[0011] In one possible implementation of the first aspect, the method further includes:

[0012] Based on the current task's identification code, read the corresponding status buffer address from the task context mapping table;

[0013] Based on the state buffer address, the corresponding LSTM inference state is loaded into the LSTM register, and the inference of the current task's preset number of sliding window data is performed, updating the corresponding LSTM inference state.

[0014] In one possible implementation of the first aspect, updating the task context mapping table based on the updated LSTM inference state includes:

[0015] Write the frozen LSTM inference state to the state buffer address corresponding to the current task in the task context mapping table;

[0016] When the LSTM inference state after writing the state buffer address corresponding to the current task satisfies the integrity requirement, update the state buffer address corresponding to the current task in the task context mapping table.

[0017] In one possible implementation of the first aspect, when scheduling the next task, the LSTM inference state of the task is restored based on the state buffer address corresponding to the task retrieved from the updated task context mapping table, including:

[0018] Based on the state buffer address corresponding to the next task, load the corresponding LSTM inference state;

[0019] When the integrity of the LSTM inference state is satisfied, it is restored.

[0020] In one possible implementation of the first aspect, the method further includes:

[0021] If the LSTM inference state in the next task does not meet the integrity requirement, roll back to the last frozen point.

[0022] In one possible implementation of the first aspect, the method further includes:

[0023] During the execution of the current task, a task switch is triggered based on a preset task switch triggering method, and the updated LSTM inference state of the current task is frozen. The task context mapping table is then updated based on the frozen LSTM inference state.

[0024] The next task is activated based on task priority and preemptive execution strategy. The LSTM inference state of the task is restored based on the state buffer address corresponding to the task found in the updated task context mapping table.

[0025] Load the restored LSTM inference state into the current inference path and execute LSTM inference; the current inference path is the inference path corresponding to the LSTM computation precision of this task.

[0026] After the LSTM inference is completed, freeze the LSTM inference state of the task.

[0027] In one possible implementation of the first aspect, the method further includes:

[0028] If the next task has not been run, the LSTM inference state of that task is configured as a zero vector, or an initialization template is configured to fill it.

[0029] Secondly, embodiments of this application provide an LSTM task context mapping and inference state switching device, the device comprising:

[0030] The acquisition unit is used to acquire context information for each task;

[0031] The building unit is used to construct a task context mapping table based on the context information of each task;

[0032] The first processing unit is used to freeze the updated LSTM inference state of the current task after the current task inference is completed, and update the task context mapping table based on the frozen LSTM inference state.

[0033] The second processing unit is used to restore the LSTM inference state of the task based on the state buffer address corresponding to the task retrieved from the updated task context mapping table when scheduling the next task.

[0034] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the LSTM task context mapping and inference state switching method described in the first aspect above.

[0035] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the LSTM task context mapping and inference state switching method described in the first aspect above.

[0036] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the LSTM task context mapping and inference state switching method described in the first aspect above.

[0037] The proposed solution first constructs a task context mapping table based on the acquired context information of each task. Then, it freezes the updated LSTM inference state of the current task after inference is completed and updates the task context mapping table based on the frozen inference state. Finally, when scheduling the next task, it restores the inference state of the task based on the state buffer address of the task obtained by querying the updated mapping table.

[0038] The proposed solution does not require interrupting the current LSTM inference during task switching. Instead, task switching occurs after the current task completes its inference. It also does not require clearing the current task's inference state but rather freezing it. Furthermore, it does not require re-initializing the inference state but rather restoring the inference state of the next task based on the state buffer address. Therefore, the continuity of the inference state is not broken, thereby improving the prediction accuracy of LSTM and demonstrating strong ease of use and practicality.

[0039] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

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

[0041] Figure 1 This is a schematic diagram illustrating the steps of the LSTM task context mapping and inference state switching method provided in the embodiments of this application;

[0042] Figure 2 This is a schematic diagram of the LSTM inference state switching control provided in an embodiment of this application;

[0043] Figure 3 This is a schematic diagram of the state mapping and LSTM interface path during task switching provided in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram of the GNSS-LSTM task context mapping system architecture provided in the embodiments of this application;

[0045] Figure 5 This is a schematic diagram of the structure of the LSTM task context mapping and inference state switching device provided in the embodiments of this application;

[0046] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0047] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0048] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or photovoltaic modules, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, photovoltaic modules and / or combinations thereof.

[0049] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0050] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0051] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [the described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [the described condition or event] is detected," or "in response to detection of [the described condition or event]."

[0052] Furthermore, in the description of this application, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0053] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in some other embodiments," "in other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0054] In recent years, in order to improve the ability of navigation receivers to perceive timing features, more and more systems have introduced LSTM into GNSS chips to model various signal state evolution processes, including but not limited to: satellite signal loss prediction, GNSS broadband / narrowband interference trend modeling, multipath reflection trajectory identification, satellite channel state estimation and error compensation, and GNSS and IMU fusion state filtering.

[0055] In practical navigation systems, these tasks typically exist simultaneously, run concurrently, or are frequently triggered alternately. As a model with temporal memory, the prediction accuracy of LSTM is highly dependent on the continuity and consistency of the previous frame's state (Cell state, Hidden state). However, the LSTM structure in traditional GNSS intelligent navigation chips, designed for single tasks, faces the following core technical challenges when dealing with multiple tasks coexisting (running in parallel or alternately):

[0056] (1) The state context cannot be switched or the switching cost is high, and the state continuity is broken: The common LSTM deployment method is a fixed model + continuous execution of the state. If the task is switched, the current LSTM inference needs to be interrupted, the state is cleared or reinitialized, which seriously affects the prediction continuity and system real-time performance.

[0057] (2) Shared task states, mutual interference, and context confusion: When multiple tasks share a set of LSTM cores but there is no context isolation mechanism, pollution may occur between different task states, causing prediction errors, model drift, and affecting the stability of the core navigation function.

[0058] (3) High cost of task state reconstruction and high switching delay: If modeling starts from scratch every time a task is switched, the input sequence needs to be re-accumulated to restore model stability, which leads to interference detection delay and slow response to loss of lock, seriously affecting the robustness of the system.

[0059] (4) Hardware resource configuration is difficult to balance and hardware resource utilization is low: In order to achieve multi-task isolation, some solutions configure a separate LSTM model for each task, resulting in logical redundancy and excessive on-chip resource consumption, which makes it difficult to meet the area and power consumption budget of SoC (System on Chip).

[0060] (5) Lack of scheduling mechanism and recovery logic for task switching: The current model framework does not have a runtime “task context management table” or “state freeze-recovery control”. Task management mainly relies on external master control software switching, which has a large response delay and does not have hardware-level task wake-up efficiency.

[0061] To address the aforementioned shortcomings, this application provides an LSTM task context mapping and inference state switching method. First, a task context mapping table is constructed based on the acquired context information of each task. Then, the updated LSTM inference state of the current task after inference is completed is frozen, and the task context mapping table is updated based on the frozen inference state. Finally, when scheduling the next task, the inference state of the task is restored based on the state buffer address of the task obtained by querying the updated mapping table.

[0062] The proposed solution does not require interrupting the current LSTM inference during task switching. Instead, task switching occurs after the current task completes its inference. It also does not require clearing the current task's inference state but rather freezing it. Furthermore, it does not require re-initializing the inference state but rather restoring the inference state of the next task based on the state buffer address. Therefore, the continuity of the inference state is not broken, thereby improving the prediction accuracy of LSTM and demonstrating strong ease of use and practicality.

[0063] The specific process implemented in this application is described below through specific embodiments.

[0064] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating the steps of the LSTM task context mapping and inference state switching method provided in an embodiment of this application. For example... Figure 1 As shown, the method includes the following steps:

[0065] S101, obtain the context information of each task.

[0066] In one embodiment, this application can be applied to a GNSS system, and the task can be a navigation-related task, such as loss-of-lock prediction, interference modeling, multipath analysis, etc.

[0067] It's important to note that in natural language, "context" refers to the semantic environment (before and after) of a sentence, determining the meaning of a word or sentence. In LSTM or any recurrent neural network (such as RNNs), this concept is directly borrowed: the LSTM inference model relies on the hidden state of the previous step at each inference step, much like a sentence depends on its preceding context for understanding. Therefore, the sequence of hidden states in an LSTM equals the model's "semantic context." Here, "before" and "after" are no longer language, but rather historical inference information for time-series tasks (e.g., changes in satellite signals, noise trends, temporal correlations of motion trajectories, etc.).

[0068] S102, construct a task context mapping table based on the context information of each task.

[0069] In one embodiment, a unique task ID is assigned to each navigation-related task (e.g., Task0: lockout prediction, Task1: interference modeling, Task2: multipath analysis). Each task ID is bound to a set of context information, including: the state buffer address of the current task's LSTM inference state (LSTM internal states, including Cell state c(t) and Hidden state h(t)); the configuration parameters of the LSTM inference model (input length, bit width, gating structure, etc.); and the task priority and switching strategy configuration. The context information of all tasks is stored in an on-chip context table and is indexed and managed by the context controller.

[0070] In one embodiment, taking a GNSS smart receiver chip as an example, it is assumed that the chip integrates a shared LSTM inference core and needs to run two typical navigation perception tasks: Task A: Predicting satellite signal loss trend (high priority); Task B: Modeling GNSS interference evolution (periodic execution). Both are based on LSTM networks for time series modeling and run alternately or in parallel, ensuring that their respective state contexts are independent and supporting fast switching and continuous inference.

[0071] In one embodiment, after the GNSS chip starts up, the navigation system scheduler registers the context information of the two tasks mentioned above with the context mapping control module, and initializes the task context mapping table as shown in Table 1. Table 1 is as follows:

[0072] Table 1

[0073]

[0074] In this context, 0x01 corresponds to Task A; 0x02 corresponds to Task B. LSTM-32 indicates an LSTM with H = 32 hidden units. The context mapping control module is a functional part or alternative name of the context controller. The difference is that the context controller is the general term for the entire control unit; the context mapping control module is a sub-module specifically responsible for managing and registering context entries corresponding to task IDs.

[0075] In one embodiment, the system loads only one set of shared LSTM inference circuit resources, and the state space is provided by the on-chip SRAM (Static Random Access Memory) space allocated by the task context mapping table.

[0076] It's important to note that the correspondence between the input length, bit width, and gating structure in the context information and the entries in the task context mapping table is as follows: the input length corresponds to the sliding window length, determining the number of time steps in each LSTM processing cycle; the bit width corresponds to the computational precision configuration, controlling the LSTM's computation and storage precision, such as INT8, FP16, etc.; the model structure includes the gating structure type (e.g., standard LSTM, GRU (Gated Recurrent Unit), simplified gating, etc.), used to indicate the internal gating form of the LSTM. In other words, the input length corresponds to the time steps, the bit width corresponds to the precision, and the model structure corresponds to the LSTM gating topology.

[0077] S103 After the current task inference is completed, the updated LSTM inference state of the current task is frozen, and the task context mapping table is updated based on the frozen LSTM inference state.

[0078] According to one embodiment of this application, the method further includes: reading the corresponding state buffer address from the task context mapping table according to the identification code of the current task; loading the corresponding LSTM inference state into the LSTM register according to the state buffer address, and performing inference of the preset number of sliding window data of the current task to update the corresponding LSTM inference state.

[0079] In one embodiment, during the Task B (interference trend modeling) execution phase: the navigation system scheduler starts Task B and loads ID=0x02; the context controller reads the state buffer address 0x1100 from the task context mapping table based on 0x02, and loads the corresponding c(t) and h(t) states into the LSTM registers based on this address; interference trend modeling inference is performed on 6 frames of sliding window data. During the inference process, the LSTM updates its internal state at the time of each frame calculation: c(t) (memory cell state) and h(t) (hidden state) are dynamically updated according to the gating formula based on the current input frame and the state of the previous step.

[0080] In short, each time LSTM processes a frame of sliding window data, it generates new c(t+1) and h(t+1). After inference is completed, this latest state is written back to the state buffer address or frozen for later inference.

[0081] According to one embodiment of this application, updating the task context mapping table based on the updated LSTM inference state includes:

[0082] Write the frozen LSTM inference state to the state buffer address corresponding to the current task in the task context map table; when the LSTM inference state after writing to the state buffer address corresponding to the current task satisfies the integrity requirement, update the state buffer address corresponding to the current task in the task context map table.

[0083] In one embodiment, after the current task (Task B) completes its inference, a freeze operation is automatically triggered, freezing the updated LSTM inference state of the current task. The frozen LSTM inference state (the output state of the current frame, the updated c(t) and h(t) in the state register) is written to the state buffer address of Task B (binding address, state buffer slot 0x1100). This process takes only one state switching cycle, and the switching delay does not exceed one clock cycle.

[0084] It should be noted that the updated c(t) and h(t) states are written back to the 0x1100 state buffer. After the inference of the current frame ends, the LSTM has completed the state update, and the latest c(t+1) and h(t+1) will be written to this state buffer so that they can be directly read and used when the task resumes or continues inference.

[0085] It is understood that this embodiment describes that after task B is completed, the system actively triggers state freezing and writes the frozen c(t+1) and h(t+1) of task B back to the cache.

[0086] In one embodiment, updating the task context mapping table means updating the new state buffer address (i.e., the storage location after the frozen c(t+1) and h(t+1) are written) to the entry of the corresponding task ID in the mapping table. After the updated c(t) and h(t) states are frozen, they are written to the buffer (the area corresponding to the state buffer address). After verification (confirming state integrity), the state address information (state buffer address) of the task is updated in the mapping table.

[0087] For example, the frozen c(t+1) and h(t+1) of task B are written to the state buffer address 0x1100. After confirming the integrity of the state, the state buffer address is updated. The specific update value is customizable.

[0088] S104, when scheduling the next task, the LSTM inference state of the task is restored based on the state buffer address corresponding to the task retrieved from the updated task context mapping table.

[0089] According to one embodiment of this application, when scheduling the next task, the LSTM inference state of the task is restored based on the state buffer address corresponding to the task retrieved from the updated task context mapping table, including:

[0090] Based on the state buffer address corresponding to the next task, load the corresponding LSTM inference state; when the integrity of the LSTM inference state is satisfied, restore it.

[0091] In one embodiment, when a new task (task A) is scheduled, the state recovery control module (a submodule within the context controller) queries the updated task context mapping table based on the task A's ID (0x01) to obtain the state buffer address 0x1000, and loads the c(t) and h(t) states of task A based on this address. If the c(t) and h(t) states of task A satisfy integrity, they are restored and loaded into the current inference path.

[0092] It should be noted that task A has already run before, and its c(t) and h(t) states were saved to the state cache at address 0x1000 when it was last interrupted. Now, when the context controller reschedules task A for execution, it reads and restores the c(t) and h(t) states from this address and continues reasoning from the point where task A was last interrupted.

[0093] In one embodiment, a "Restore" and "Preload Buffer" mechanism is supported to ensure that the LSTM inference state switching delay does not exceed 1 frame period.

[0094] According to one embodiment of this application, the method further includes: rolling back to the last frozen point when the LSTM inference state of the next task does not satisfy integrity.

[0095] In some embodiments, incomplete LSTM inference state usually occurs in the following situations: (1) interruption timing is too early: interrupted before the LSTM has completed the current step inference; (2) write exception: data loss or verification failure occurs during the state write buffer process; (3) cache conflict or out of bounds: multiple tasks access the state area at the same time, causing partial overwriting; (4) power or clock fluctuation: causing the state register data to be not fully latched.

[0096] In summary, incomplete LSTM inference states occur when frozen data (c(t), h(t)) is not properly saved or is corrupted, requiring a rollback to the last frozen point.

[0097] According to one embodiment of this application, the method further includes: if the next task has not been run, configuring the LSTM inference state of the task as a zero vector, or configuring an initialization template for filling.

[0098] In one embodiment, the initialization template is a default initial value configuration provided for the LSTM inference state during the first run of the task. It includes the initial values ​​of the hidden state h(t) and the memory state c(t), which can be a zero vector, the training mean vector, a small random perturbation, etc. When the context controller detects the first run of the task, it reads these values ​​from the initialization template and writes them to the LSTM state register, thus achieving state filling.

[0099] According to one embodiment of this application, the method further includes:

[0100] During the execution of the current task, a task switch is triggered based on a preset task switch triggering method, and the updated LSTM inference state of the current task is frozen. The task context mapping table is updated based on the frozen LSTM inference state. The next task is activated based on the task priority and preemptive execution strategy. The LSTM inference state of the task is restored based on the state buffer address corresponding to the task found in the updated task context mapping table.

[0101] Load the restored LSTM inference state into the current inference path and execute LSTM inference; the current inference path is the inference path corresponding to the LSTM computation precision of this task; after the LSTM inference is completed, freeze the LSTM inference state of this task.

[0102] In one embodiment, the preset task switching triggering methods include: timed scheduling, event interruption, task request wake-up, and master control command. The preemptive execution strategy can be: a high-priority task interrupts the execution of a low-priority task and loads its context information.

[0103] In one embodiment, during the preemptive execution phase of Task A (Lockout Prediction): During the execution of Task B, the navigation system scheduler receives a lockout warning interruption signal from the channel monitoring module, interrupting the scheduling and triggering the task priority preemption mechanism; the current state of Task B is frozen and marked as "recoverable"; Task A is activated, the context controller loads the state buffer address 0x1000, and restores its c(t) and h(t) states; the LSTM enters continuous inference with FP16 computational precision to determine the current signal lockout risk; after the inference is completed, the LSTM inference state is frozen again, and the main control processing module is notified.

[0104] It should be noted that, since the inference state is already stored in the mapping table slot, task A can be immediately restored with the original context information, the prediction error is controlled within 0.5%, and the continuity of the inference state is guaranteed.

[0105] It is understood that this embodiment describes a situation where, during the execution of task B, the channel monitoring module issues a "lack of lock warning interruption," the scheduler immediately causes task A to preempt execution, and the context controller saves the current running state of task B.

[0106] Please see Figure 2 , Figure 2 This is a flowchart illustrating the LSTM inference state switching control provided in an embodiment of this application. LSTM inference state switching includes: inference state freezing, task switching, and inference state restoration. Figure 2 As shown, the process includes the following steps:

[0107] S201, During the current task execution, a task switch is triggered based on a soft interrupt, external task scheduling, or internal trigger event, and a state freeze is triggered.

[0108] S202, write the frozen c(t+1) and h(t+1) into the corresponding task slots in the task context mapping table;

[0109] S203, The context controller loads the next task (new task) ID;

[0110] S204. Based on the task ID, look up the state buffer address corresponding to the task in the task context mapping table;

[0111] S205, restore the LSTM inference state of the task and load the restored LSTM inference state into the LSTM core.

[0112] S206, Update inference parameter configuration and perform input channel mapping;

[0113] S207, a new task has begun.

[0114] In one embodiment, a soft interrupt corresponds to an "event interrupt", an external task scheduler corresponds to a "task request wake-up" and a "timed scheduler", and an internal trigger event corresponds to a spontaneous switch triggered by the internal state or threshold of the LSTM (such as confidence decrease, error exceedance, etc.).

[0115] In one embodiment, inference parameters include: the dimension of the input features, the dimension of the hidden layer states, and the number of LSTM stacked layers. Input channels refer to the dimensions of the input data or signal paths; input channel mapping refers to the LSTM mapping the input channels to the hidden state space through a linear transformation.

[0116] It should be noted that state freezing is a write operation and state restoration is a read operation; switching occurs at the LSTM frame boundary to avoid state inconsistency; three switching modes are supported: soft interrupt, external task scheduling, and internal trigger event.

[0117] Please see Figure 3 , Figure 3 This is a schematic diagram of the state mapping and LSTM interface path during task switching provided in an embodiment of this application. For example... Figure 3 As shown, the current state is frozen, and c(t) and h(t) in the status register are written to the mapping table slot (Task_ID=0x02, address: 0x1100). The scheduler receives the lockout warning interrupt, the state switches, the status register is reloaded (new task), the mapping table slot (Task_ID=0x01, address: 0x1000) is read, and the new task inference process is entered.

[0118] It should be noted that, Figure 3 The implementation examples and the above-described implementation examples of preemptive execution of task A refer to the same sequence of events, only with different emphases: In Figure 3 In the embodiment, the focus is on the signal flow of the series of actions: "state freeze, write to cache, receive interrupt"; in the embodiment where task A preemptively executes, the focus is on the logical sequence of "task B receives interrupt during execution, triggering state freeze". Therefore, they are the same process, only described in different orders.

[0119] The actual logic is as follows: When task B receives a lock loss warning interrupt during execution, the scheduler triggers a state freeze, writes c(t) and h(t) to the state buffer address, and switches to task A.

[0120] In one embodiment, the LSTM interface path refers to the data and control signal path between the context controller (or scheduling system) and the LSTM state calculation unit, including: (1) Input interface: input features, control signals, task ID, configuration parameters; (2) State interface: read and write channels of c(t) and h(t) (used for freezing and recovery); (3) Output interface: inference results and state update output; (4) Control signal path: start, pause, interrupt, state write back and other control lines.

[0121] In one embodiment, the configuration of task lock states can be supported to prevent critical task states from being overwritten or accidentally woken up. The switching operation is driven by a dedicated context controller (Finite State Machine), avoiding reliance on the main controller for intervention.

[0122] It should be noted that in multi-task parallel execution, task switching can be: single-task switching: pausing one task and loading another; multi-task switching: simultaneously freezing or resuming the context of multiple tasks. The specific decision is made by the scheduler based on task priority and resource allocation.

[0123] According to one embodiment of this application, the task context mapping table structure field diagram of the three tasks is shown in Table 2, as follows:

[0124] Table 2

[0125]

[0126] It should be noted that Task_ID is a unique identifier for each task, the state buffer address corresponds to the on-chip storage address of the current LSTM inference state c(t) and h(t) of the task, the input configuration includes the sliding window length, the number of input channels, etc., the accuracy level is the accuracy level used during task execution (configurable), and the priority strategy determines the preemption priority or execution time limit during task scheduling.

[0127] It should be noted that the number of input channels is not mentioned in Table 2 because the number of input channels is usually fixed in the model structure and does not need to be registered separately. The execution time limit refers to the maximum time limit; that is, if a task runs for longer than this time limit, the scheduler switches to another task to prevent a single task from occupying resources for an extended period.

[0128] According to one embodiment of this application, in order to avoid frequent preemption causing state inconsistency, the system supports task switching protection and rollback mechanism: (1) Minimum running cycle protection: Each task must run for at least N frames to avoid high-frequency switching; (2) Freeze buffer double write mechanism: When the LSTM inference state is frozen, it is first written to the state buffer, and the task context mapping table is updated after confirming the integrity; (3) Failure rollback mechanism: If the new task state is incomplete, it can be rolled back to the last freeze point.

[0129] According to one embodiment of this application, the GNSS chip retains only one or a small number of shared LSTM core computing resources (LSTM inference general execution path); the inference module connects to the context data area of ​​the current task through a state mapping interface to ensure instant response to input and state switching; different tasks share hardware but do not share state data to avoid mutual interference.

[0130] According to one embodiment of this application, an LSTM computation precision scheduling strategy control mechanism is constructed: a computation precision is set for each task in the task context mapping table, and when switching tasks, the corresponding computation precision is switched. However, this computation precision is not fixed. During the execution of each task, the computation precision can be switched according to the current input state of the LSTM inference model.

[0131] It should be noted that the "precision" field in the task context mapping table is the basic precision configuration of the task, that is, the default computation bit width used by the task during runtime (e.g., INT8, FP16). Dynamic precision switching during task execution is done within the task itself, adjusting the precision dynamically based on the input and model states. For example, the precision may be temporarily increased when there are large changes in signal complexity, noise level, or gradient amplitude, and decreased in stable segments to save energy.

[0132] In other words, when switching tasks, the default precision of the task is loaded first, and during task execution, the control logic adaptively switches the sub-path precision based on the real-time input state of the LSTM inference model.

[0133] Please see Figure 4 , Figure 4 This is a schematic diagram of the GNSS-LSTM task context mapping system architecture provided in an embodiment of this application. The system manages task states, such as... Figure 4 As shown, the task context mapping table includes: Task_ID, state buffer address, model configuration parameters, and task priority; current task input: GNSS input signal x(t) and Task_ID; context controller execution: state freeze control, state recovery instruction generation, and switch trigger management; LSTM execution path involves: gating unit, Cell / Hidden state, and MAC+ activation calculation.

[0134] It should be noted that each task registers a record in the task context mapping table; the context controller completes the state read / write switching based on the task ID; all LSTM inference logic reuses the same execution unit, but the state and input configuration are determined by the task context.

[0135] According to one embodiment of this application, a comparison of deployment resources and operating efficiency is performed. Taking a certain 28nm GNSS SoC as an example, it is assumed that the original solution uses dual LSTM cores to process two tasks respectively. The comparison between the original solution and the solution of this application is shown in Table 3, as follows:

[0136] Table 3

[0137]

[0138] According to one embodiment of this application, in hardware implementation: the context mapping table can be implemented using a register file or a small-capacity SRAM, supporting concurrent mapping of 8 to 32 tasks; the state buffer adopts a Bank (memory library) grouping structure to avoid read / write conflicts; the Context FSM adopts a 4 to 5 state automaton to manage states such as freeze, restore, and schedule; when integrated and deployed with TFLite (TensorFlow Lite, a deep learning inference framework) Micro, the delegate interface can be extended to support runtime dynamic mapping of task IDs and states.

[0139] The LSTM task context mapping and inference state switching method provided in this application first constructs a task context mapping table based on the acquired context information of each task, then freezes the updated LSTM inference state of the current task after inference is completed, and updates the task context mapping table based on the frozen inference state. Finally, when scheduling the next task, the inference state of the task is restored based on the state buffer address of the task obtained by querying the updated mapping table.

[0140] The proposed solution does not require interrupting the current LSTM inference during task switching. Instead, task switching occurs after the current task completes its inference. It also does not require clearing the current task's inference state but rather freezing it. Furthermore, it does not require re-initializing the inference state but rather restoring the inference state of the next task based on the state buffer address. Therefore, the continuity of the inference state is not broken, thereby improving the prediction accuracy of LSTM and demonstrating strong ease of use and practicality.

[0141] This application proposes a GNSS-LSTM task context mapping and inference state switching method that addresses issues such as state continuity disruption, context confusion, high switching latency, and low hardware resource utilization encountered when multiple LSTM tasks run in parallel or alternately in GNSS intelligent navigation chips. The method supports task awareness, state mapping, and fast switching.

[0142] This application's solution enables multiple LSTM tasks to switch inference states as needed during runtime by constructing a task ID binding context mechanism, a state freeze and restore control module, and a dynamic mapping interface for LSTM execution paths. This ensures that the states of different tasks are independent and the context is complete, and supports shared inference units and low resource deployment requirements. It is particularly suitable for fast switching and concurrent management when performing multiple navigation perception tasks (such as signal loss prediction, interference judgment, multi-path identification, etc.) in a single-chip system.

[0143] The proposed solution ensures that the state contexts of different tasks are independent and securely switchable, and reuses shared LSTM computing resources as much as possible to improve chip energy efficiency and real-time response capabilities.

[0144] Compared with the prior art, the solution of this application has the following significant technical advantages:

[0145] (1) Independent and reliable state context: Each task is bound to an independent state cache and parameter configuration. The switching process will not cause state pollution between tasks, ensuring inference accuracy and model logic integrity.

[0146] (2) High efficiency of state switching: State freezing and recovery only involve data reading and writing operations. With the help of the pipeline scheduling structure, task switching can be completed within 1 to 2 system cycles, which meets the real-time requirements of GNSS system;

[0147] (3) Support shared execution units and reduce resource overhead: multiple tasks share one or a small amount of LSTM core logic, avoid repeatedly building independent paths, greatly reduce chip area and power consumption burden, and adapt to 28nm / 32nm SoC platforms;

[0148] (4) Supports parallel and preemptive execution strategies: LSTM tasks can be dynamically scheduled according to task priority, and preemption, interruption, and task-level state protection are supported to improve the flexibility of multi-task execution and system intelligence.

[0149] (5) Adaptable to various GNSS intelligent task structures: It can be widely applied to typical tasks such as navigation signal state modeling, interference perception, pseudorange prediction, path history construction, and sensor fusion, and supports the coexistence of channel parallelism and cross-band tasks;

[0150] (6) Facilitates automatic model deployment and TFLite mapping: The context table structure and runtime state can be bound to the model compiler / scheduler, supporting automatic generation of configuration instruction streams, which facilitates one-click model deployment and debugging.

[0151] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0152] Corresponding to the method in the above embodiments, Figure 5 This is a schematic diagram of the LSTM task context mapping and inference state switching device provided in an embodiment of this application. For ease of explanation, only the parts relevant to the embodiment of this application are shown.

[0153] Please see Figure 5 The device includes:

[0154] Acquisition unit 501 is used to acquire context information for each task;

[0155] Construction unit 502 is used to construct a task context mapping table based on the context information of each task;

[0156] The first processing unit 503 is used to freeze the updated LSTM inference state of the current task after the current task inference is completed, and update the task context mapping table based on the frozen LSTM inference state.

[0157] The second processing unit 504 is used to restore the LSTM inference state of the task based on the state buffer address corresponding to the task queried from the updated task context mapping table when scheduling the next task.

[0158] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0159] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0160] Figure 6 This is a schematic diagram of the structure of the electronic device 6 provided in an embodiment of this application. Figure 6 As shown, the electronic device 6 of this embodiment includes: at least one processor 601 ( Figure 6 Only one is shown in the diagram), memory 603, and computer program 602 stored in memory 603 and executable on at least one processor 601, wherein processor 601 executes computer program 602 to implement the steps in the above method embodiments.

[0161] Electronic device 6 can be a computing device such as a desktop computer, laptop, handheld computer, or mobile phone. This electronic device 6 may include, but is not limited to, a processor 601 and a memory 603. Those skilled in the art will understand that... Figure 6 This is merely an example of electronic device 6 and does not constitute a limitation on electronic device 6. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0162] The processor 601 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware photovoltaic modules, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0163] In some embodiments, memory 603 may be an internal storage unit of electronic device 6, such as a hard disk or memory of electronic device 6. In other embodiments, memory 603 may be an external storage device of electronic device 6, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on electronic device 6. Furthermore, memory 603 may include both internal and external storage units of electronic device 6. Memory 603 is used to store operating system, application programs, boot loader, data, and other programs, such as program code of computer programs. Memory 603 may also be used to temporarily store data that has been output or will be output.

[0164] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, when implementing all or part of the processes in the methods of the above embodiments, this application can use a computer program to instruct related hardware. This computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps applied in the method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium can include at least: any entity or device capable of carrying computer program code to a computing device / electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, such as a USB flash drive, a portable hard drive, a magnetic disk, or an optical disk.

[0165] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the various method embodiments described above.

[0166] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the steps described in the various method embodiments above.

[0167] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0168] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0169] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. The device / electronic device embodiments described above are merely illustrative, and the division of modules or units described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or photovoltaic modules may be combined or integrated into another system, and some features may be ignored. Furthermore, the indirect coupling, direct coupling, or communication connection shown or discussed between them can be through some interfaces, devices, or units, and can be electrical, mechanical, or other forms.

[0170] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0171] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the above embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for LSTM task context mapping and inference state switching, characterized in that, The method includes: Obtain the context information for each task; Based on the context information of each task, construct a task context mapping table; After the current task inference is completed, the updated LSTM inference state of the current task is frozen, and the task context mapping table is updated based on the frozen LSTM inference state. When scheduling the next task, the LSTM inference state of the task is restored based on the state buffer address corresponding to the task retrieved from the updated task context mapping table. During the execution of the current task, a task switch is triggered based on a preset task switch triggering method, and the updated LSTM inference state of the current task is frozen. The task context mapping table is then updated based on the frozen LSTM inference state. The next task is activated based on task priority and preemptive execution strategy. The LSTM inference state of the task is restored based on the state buffer address corresponding to the task found in the updated task context mapping table. Load the restored LSTM inference state into the current inference path and execute LSTM inference; the current inference path is the inference path corresponding to the LSTM computation precision of this task; After the LSTM inference is completed, freeze the LSTM inference state of the task. The LSTM computation precision is determined by the constructed LSTM computation precision scheduling strategy control mechanism. The LSTM computation precision scheduling strategy control mechanism is as follows: set the LSTM computation precision for each task in the task context mapping table, switch to the corresponding LSTM computation precision when switching tasks, and switch the LSTM computation precision according to the current input state of the LSTM inference model during the execution of each task.

2. The LSTM task context mapping and inference state switching method according to claim 1, characterized in that, The method further includes: Based on the current task's identification code, read the corresponding status buffer address from the task context mapping table; Based on the state buffer address, the corresponding LSTM inference state is loaded into the LSTM register, and the inference of the current task's preset number of sliding window data is performed, updating the corresponding LSTM inference state.

3. The LSTM task context mapping and inference state switching method according to claim 1, characterized in that, Updating the task context mapping table based on the updated LSTM inference state includes: Write the frozen LSTM inference state to the state buffer address corresponding to the current task in the task context mapping table; When the LSTM inference state after writing the state buffer address corresponding to the current task satisfies the integrity requirement, update the state buffer address corresponding to the current task in the task context mapping table.

4. The LSTM task context mapping and inference state switching method according to claim 1, characterized in that, When scheduling the next task, the LSTM inference state of the task is restored based on the state buffer address corresponding to the task retrieved from the updated task context mapping table, including: Based on the state buffer address corresponding to the next task, load the corresponding LSTM inference state; When the integrity of the LSTM inference state is satisfied, it is restored.

5. The LSTM task context mapping and inference state switching method according to claim 4, characterized in that, The method further includes: If the LSTM inference state of the next task does not meet the integrity requirement, roll back to the last frozen point.

6. The LSTM task context mapping and inference state switching method according to any one of claims 1-5, characterized in that, The method further includes: If the next task has not been run, the LSTM inference state of that task is configured as a zero vector, or an initialization template is configured to fill it.

7. An LSTM task context mapping and inference state switching device, characterized in that, The device includes: The acquisition unit is used to acquire context information for each task; The building unit is used to construct a task context mapping table based on the context information of each task; The first processing unit is used to freeze the updated LSTM inference state of the current task after the current task inference is completed, and update the task context mapping table based on the frozen LSTM inference state. The second processing unit is used to restore the LSTM inference state of the task based on the state buffer address corresponding to the task queried from the updated task context mapping table when scheduling the next task. The first processing unit is further configured to trigger task switching based on a preset task switching triggering method during the current task execution process, freeze the updated LSTM inference state of the current task, and update the task context mapping table based on the frozen LSTM inference state. The second processing unit is further configured to: activate the next task based on task priority and preemptive execution strategy; restore the LSTM inference state of the task based on the state buffer address corresponding to the task queried from the updated task context mapping table; load the restored LSTM inference state into the current inference path and execute LSTM inference; the current inference path is the inference path corresponding to the LSTM computation precision of the task; after the LSTM inference is completed, freeze the LSTM inference state of the task. The LSTM computation precision is determined by the constructed LSTM computation precision scheduling strategy control mechanism. The LSTM computation precision scheduling strategy control mechanism is as follows: set the LSTM computation precision for each task in the task context mapping table, switch to the corresponding LSTM computation precision when switching tasks, and switch the LSTM computation precision according to the current input state of the LSTM inference model during the execution of each task.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the LSTM task context mapping and inference state switching method as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the LSTM task context mapping and inference state switching method as described in any one of claims 1-6.

Images