Used to manage transaction timeouts in critical domains.

Abstract

A processing system and associated methods are provided for managing tasks and handling errors based on criticality levels assigned to individual processing circuit blocks. The system includes multiple processing circuit blocks, each assigned a criticality level by a criticality domain manager, such that errors occurring in relation to these blocks are handled according to their assigned criticality levels. The system is characterized by timers assigned to tasks initiated by the processing circuit blocks, where the timeout duration is determined by the criticality levels assigned to the processing circuit blocks and the tasks initiated by them. When a timeout expires before a task is completed, various error handling procedures are selected and executed based on the assigned criticality level.

Description

Background Technology

[0001] Car audio systems typically include a System-on-Chip (SOC), which centralizes audio processing functions for a variety of in-vehicle applications. These SOCs are designed to handle a wide range of audio-related tasks, from basic media playback to more complex operations such as voice recognition, hands-free calling, and emergency communication systems.

[0002] Traditionally, the System of Charge (SOC) in car audio systems has been designed to treat all audio processing tasks with equal priority for both safety-critical and non-safety-critical tasks. This conventional design lacks the flexibility to differentiate between tasks with varying degrees of criticality. For example, playing music or streaming media is often considered less critical than making an emergency call or alerting the driver to external hazards. The inability to prioritize these initiated tasks based on their criticality can lead to inefficient resource allocation and potential delays when performing high-priority tasks.

[0003] Therefore, the current state of automotive audio processing necessitates a more sophisticated approach that dynamically manages these tasks based on their criticality. This approach would ensure that high-priority tasks are given the necessary resources and attention, while lower-priority tasks are managed in a manner that does not compromise the overall efficiency and reliability of the system. Summary of the Invention

[0004] In one implementation, a processing system includes: a plurality of processing circuit blocks; a critical domain management circuit for assigning a criticality level to each of the processing circuit blocks; and an error handling circuit for monitoring the processing circuit blocks and for handling errors at least in part based on the assigned criticality level.

[0005] The critical domain management circuitry can assign task timers to tasks initiated by these processing circuit blocks, and each task timer can have a timeout duration based at least in part on the assigned criticality level associated with the processing circuit block that initiated the task.

[0006] The critical domain management circuitry can assign task timers to tasks initiated by these processing circuit blocks, and each task timer can have a timeout duration that is at least in part based on the assigned criticality level associated with the processing circuit block assigned to perform the task.

[0007] Error handling may include initiating a soft reset protocol for a task based on a timeout associated with the task expiring before the task's completion. The soft reset protocol may include providing a false indication that the task has successfully completed to the initiating processing circuit block that initiated the task associated with the timeout. In response to the soft reset protocol failing to correct the error condition, the error handling circuitry may be configured to initiate a hard reset protocol for the processing circuit block. The hard reset protocol may include initializing the initiating processing circuit block. The task associated with the timeout may be initiated by a processing circuit block assigned an elevated criticality level, and handling these errors may include initiating the soft reset protocol at least in part based on the elevated criticality level assigned to that processing circuit block.

[0008] The critical domain management circuit can further assign a first task timer timeout value to a task initiated by a first processing circuit block, which is assigned a first criticality level; and assign a second task timer timeout value to a second task initiated by a second processing circuit block, which is assigned a second criticality level higher than the first criticality level, such that the second task timer timeout value is greater than the first task timer timeout value.

[0009] The critical domain management circuitry can further dynamically modify the criticality level assigned to at least one processing circuit block based on one or more changes in the operating state of the processing system.

[0010] The plurality of processing circuit blocks may include a plurality of digital signal processors (DSPs), and at least one of the plurality of DSPs may be assigned a higher criticality level than one or more of the other DSPs.

[0011] In an implementation, a method for managing a processing system includes: assigning a criticality level to each of a plurality of processing circuit blocks; monitoring the execution of tasks initiated by these processing circuit blocks; and, in response to an error associated with the execution of the initiated task, performing one or more error handling procedures, at least in part based on the assigned criticality level.

[0012] The method may also include assigning task timers to tasks initiated by these processing circuit blocks, each task timer having a timeout duration based at least in part on an assigned criticality level associated with the processing circuit block that initiated the task.

[0013] The method may also include assigning task timers to tasks initiated by these processing circuit blocks, each task timer having a timeout duration based at least in part on an assigned criticality level associated with the processing circuit block assigned to perform the task.

[0014] Performing the one or more error handling procedures may include initiating a soft reset protocol for the task associated with the timeout in response to the expiration of a timeout associated with the task before task completion. The soft reset protocol may include providing a false indication that the task has been successfully completed to the initiation processing circuit block that initiated the timeout. In response to the soft reset protocol failing to correct the error condition, the method may further include initiating a hard reset protocol for the processing circuit block. The hard reset protocol may include initializing the initiation processing circuit block.

[0015] The task associated with the timeout may be initiated by a processing circuit block assigned an elevated criticality level, and performing the one or more error handling procedures may include initiating the soft reset protocol at least in part based on the elevated criticality level assigned to the initiating processing circuit block. The method may also include assigning a first task timer timeout value to a task initiated by a first processing circuit block assigned a first criticality level; and assigning a second task timer timeout value to a second task initiated by a second processing circuit block assigned a second criticality level higher than the first criticality level, wherein the second task timer timeout value is greater than the first task timer timeout value.

[0016] The method may also include dynamically modifying the criticality level assigned to at least one processing circuit block based on one or more changes to the operating state of the processing system.

[0017] The plurality of processing circuit blocks may include a plurality of digital signal processors (DSPs), and assigning a criticality level to each processing circuit block may include assigning at least one of the plurality of DSPs a higher criticality level than one or more of the other DSPs.

[0018] In one implementation, a non-transitory computer-readable medium stores instructions that, when executed by one or more processors, cause the one or more processors to: assign a criticality level to each of a plurality of processing circuit blocks; monitor the execution of tasks initiated by the processing circuit blocks; and, in response to an error associated with the execution of the initiated task, perform one or more error handling procedures, at least in part based on the assigned criticality level. Attached Figure Description

[0019] This disclosure can be better understood by referring to the accompanying drawings, and its many features and advantages will be apparent to those skilled in the art. The same reference numerals are used in different drawings to denote similar or identical items.

[0020] Figure 1This is a block diagram of a task error handling system based on the criticality level of the assigned task, according to some implementation schemes.

[0021] Figure 2 Component views of an automotive audio processing system according to some implementation schemes are partially illustrated.

[0022] Figure 3 A partial component view of an audio coprocessor (ACP) according to some implementation schemes is shown.

[0023] Figure 4 Examples illustrate the composition and functionality of key domains and error managers configured according to some implementation schemes.

[0024] Figure 5 Examples of error handling processes based on some implementation schemes and scenarios are provided.

[0025] Figure 6 This illustrates another error handling process based on some implementation schemes and scenarios. Detailed Implementation

[0026] As noted above, conventional System-on-Chip (SOC) configurations in automotive audio systems are designed to treat all audio processing tasks with equal priority, regardless of whether they are safety-critical or not. As part of this approach, such systems typically utilize a generic timeout mechanism to manage task execution time, again failing to consider the different nature and criticality of various audio tasks. This uniform timeout approach may lead to the premature termination of critically initiated tasks or the unnecessary continuation of non-critically initiated tasks, impacting the overall performance and reliability of the audio processing system.

[0027] The embodiments described herein provide an improved audio processing system for automotive and other applications, capable of dynamically managing multiple tasks with different criticality levels. In some embodiments, the audio processing system assigns different criticality levels to various task initiators and / or to tasks from such initiators, thereby assigning a customized task timer timeout value (a threshold duration limiting the expected execution time) to each task based on its criticality, and providing both soft and hard reset options to effectively handle task timer timeouts. In various embodiments, the audio processing system may be implemented as an audio coprocessor (ACP), such as handling audio processing and related tasks in a system including one or more central processing units (CPUs), graphics processing units (GPUs), or other hardware processors.

[0028] In various implementations, unlike previous methods where the scope of critical domains is fixed in hardware, audio processing systems operating according to the techniques described herein utilize software-controlled assignment of individual digital signal processors (DSPs) or other functional circuit blocks of the audio processing system to critical domains (initiators assigned to a critical domain are considered to have an elevated criticality level relative to initiators not in the critical domain). In such implementations, individual DSPs and other task initiators can be dynamically assigned critical or non-critical based on software configuration that can be adjusted according to the specific requirements of different scenarios or applications. For example, in an automotive context, the telephone circuit block responsible for emergency phone calls (e.g., 9-1-1 calls) may always be assigned to a critical domain, while other circuit blocks may only be assigned an elevated criticality level under specific circumstances. In this way, in various implementations and scenarios, at least one DSP can be assigned a higher criticality level than one or more other DSPs (and / or other circuit blocks). As another example, in some implementations and scenarios, one or more alarms and alert tones can be designated as safety critical and thereby assigned an elevated criticality level. By defining critical and non-critical domains using software, the ACP architecture can respond to changing operational requirements, thus providing a more resilient and adaptable system compared to systems with critical domains that have fixed hardware definitions.

[0029] While the examples discussed herein are described within the specific context of automotive audio processing, it should be understood that implementations of the technologies described herein are not limited to that specific context. As additional, non-limiting examples, aspects of such technologies can be used in: home entertainment systems where prioritizing audio tasks such as voice commands over background music enhances the user experience; industrial, aerospace, and marine applications, such as for managing audio alarms in noisy environments and for improving the reliability and effectiveness of audio processing; and other environments and scenarios. Furthermore, such technologies can be used in non-audio processing applications, such as any activity where the flexible allocation of criticality among subsystems is useful.

[0030] Figure 1 This is a block diagram of a processing system 100 according to some implementation schemes. The processing system includes an advanced task management system for managing and prioritizing initiated tasks based on the criticality of the initiated tasks and initiator-specific parameters. Figure 1 In the example shown, the processing system 100 is a system-on-chip (SoC) device capable of implementing one or more of the technologies described herein. In at least some specific embodiments, the SoC device includes multiple functional circuit blocks (also referred to herein as circuit blocks or simply blocks), which are Figure 1The components of the illustrated computing system 100 may be separate from or related to the computing system 100. For illustrative purposes, the processing system 100 is implemented as a System-on-a-Chip (SoC). However, in other specific implementations, any suitable computing device, such as a personal computer, server, smartphone, tablet computer, etc., is used. In some specific implementations, such devices are implemented using SoCs, discrete system components, or both. It should be understood that, for clarity and ease of description, Figure 1 Descriptions of the various components of the processing system 100 are omitted. According to some embodiments, the processing system 100 is configured for one or more applications in a vehicle, such as an automotive infotainment system. As an example, in some embodiments, the processing system 100 includes an audio coprocessor for automotive applications.

[0031] In at least some embodiments, the processing system 100 includes components such as a central processing unit (CPU) 102, an input / output (I / O) data texture 104, a peripheral component interconnect enhancement (PCIe) controller 106, a system memory 108, an audio coprocessor (ACP) 110, an audio codec 112, and so on. In at least some embodiments, one or more of these and other components include intellectual property (IP) blocks / cores, which are reusable units of logic, battery, or integrated circuit (IC) layouts.

[0032] In at least some embodiments, CPU 102 is a CPU core complex including one or more suitable CPU cores. In at least some embodiments, each core in the complex includes a dedicated cache, and all cores in the complex communicate with a shared cache. In at least some embodiments, processing system 100 includes multiple CPU core complexes. In at least some embodiments, CPU 102 is a parallel processor, such as any suitable parallel processor (e.g., a graphics processing unit (GPU), a machine learning (ML) application-specific integrated circuit (ASIC), etc.) or a combination of parallel processors. In other embodiments, in addition to CPU 102, processing system 100 also includes one or more parallel processors (not shown).

[0033] In at least one embodiment, data texture 104 includes circuitry for providing communication interconnections between various components of processing system 100. Any suitable interconnect hardware can be used in the various embodiments. In some embodiments, from a physical point of view, data texture 104 is implemented at a central location within processing system 100, or distributed across multiple hubs within processing system 100 and interconnected using a suitable communication medium (e.g., a bus). From a logical point of view, data texture 104 is located at the center of the data flow, and idle information about the different components of processing system 100 (including IP blocks) is centralized (e.g., stored) in data texture 104.

[0034] PCIe controller 106 is an example of one type of I / O controller implemented by processing system 100. PCIe controller 106 includes circuitry for managing the PCIe interface between I / O devices and I / O data texture 104. Other examples of I / O controllers include Universal Serial Bus (USB), Non-Volatile Memory Host Controller Interface (NVMe) bus, Serial Advanced Technology Attachment (SATA) bus, Gigabit Ethernet (xGBE), Secure Digital (SD) interface, General Purpose Input / Output (GPIO) connectivity, Sensor Fusion I / O connectivity, and / or any other suitable I / O hardware.

[0035] A memory controller (not shown) manages access to system memory 108. For example, requests to read from or write to system memory 108 from CPU 102 or other devices are managed by the memory controller. In some embodiments, one or more applications 114 within system memory 108 include various programs or commands for performing calculations also executed at CPU 102. In at least some specific embodiments, system memory 108 also includes an operating system (not shown) and a kernel-mode driver 116. The kernel-mode driver 116 controls the operation of ACP 110 by providing, for example, an application programming interface (“API”) to software (e.g., application 114) executing on the audio coprocessor (ACP) 110 to access various functionalities of ACP 110. In at least some embodiments, the kernel-mode driver 116 also includes a just-in-time (JIT) compiler that compiles programs for execution by the processing components of ACP 110.

[0036] In at least some embodiments, system memory 108 includes non-persistent memory, such as dynamic random access memory (not shown). In various embodiments, system memory 108 stores processing logic instructions, constant values, variable values ​​during the execution of various parts of an application or other processing logic, or other required information. For example, in various embodiments, during a respective portion of an operation performed by CPU 102, portions of control logic for performing one or more operations on CPU 102 reside in system memory 108. During execution, the corresponding application, operating system functions, processing logic commands, and system software reside in system memory 108. Control logic commands that form the basis of the operating system typically reside in system memory 108 during execution. In some embodiments, other software commands (e.g., instructions or sets of instructions for implementing device drivers) also reside in system memory 108 during the execution of processing system 100.

[0037] In at least some embodiments, the audio coprocessor 110 is a dedicated coprocessor device configured to perform calculations on audio data. In at least some embodiments, the audio coprocessor 110 includes one or more digital signal processors (DSPs) 118, multiple controllers 126 (such as integrated inter-chip audio (I2S) controllers or time-division multiplexing (TDM) controllers), and memory 122 (e.g., dynamic random access memory (DRAM) or any other suitable type or memory). I2S is a digital audio serial bus interface transmission standard used to connect digital audio devices together. For example, I2S is used to transmit digital audio data, such as pulse-code-modulated (PCM) audio data, between internal devices of an electronic device, such as codecs, digital signal processors (DSPs), digital-to-analog converters (DACs), analog-to-digital converters (ADCs), digital input / output interfaces, digital filters, etc. Time-division multiplexing (TDM) is an interface that allows multi-channel audio data transmission over a single data line, thus increasing the amount of data that can be transmitted over a single line.

[0038] It should be understood that, for clarity and ease of illustration, the additional components of the audio coprocessor 110 have been omitted. Additionally, in at least some embodiments, the functionality of the ACP memory 122 is partially incorporated into or replaced by one or more of the system memory 108 or the DSP memory 124. In some embodiments, the ACP memory 122 includes one or more buffers 130 for the controller 126. In other embodiments, one or more buffers 130 are included in the respective controller 126, such that, for example, each controller 126 includes a buffer 130.

[0039] In the depicted implementation, DSP 118 includes memory 124 (e.g., static random access memory or SRAM) and a multiplexer (not shown). In some specific implementations, the multiplexer is implemented as a software audio component / plugin initiated by one of the DSPs in DSP 118. As described in more detail elsewhere herein, in various implementations, DSP 118 may include multiple DSPs, each associated with a corresponding DSP memory or memory range. DSP 118 is configured to perform digital signal processing algorithms (e.g., for audio processing). Examples of such algorithms include finite impulse response (FIR) filtering algorithms, etc. Typically, DSPs perform such algorithms more efficiently (e.g., faster and / or using less power) than CPUs or other processors in a computing system. Therefore, in some specific implementations, a host OS (not shown) implemented on processing system 100 transmits data to DSP 118 to perform such calculations and retrieves or receives the results after DSP 118 has completed its calculations. In some implementations, each DSP in DSP 118 includes firmware running on audio coprocessor 110 and one or more ring buffers (i.e., loop buffers), which in this example are implemented in DSP memory 124 or in other hardware in other specific implementations.

[0040] In the depicted embodiments, each I2S controller in I2S controller 126 includes a direct memory access (DMA) controller / engine 128. It should be understood that additional components of the I2S controller 126 have been omitted for clarity and ease of description. In some embodiments, each I2S controller 126 uses its DMA engine 128 to extract audio data from any of a plurality of audio data sources in the processing system. For example, in some embodiments, the DMA engine 128 extracts audio data from ACP memory 122, from DSP memory 124, or from system memory 108 based on commands issued by the respective I2S controller 126. Each I2S controller 126 includes a buffer (not shown) filled with the DMA engine 128 associated with it.

[0041] The Critical Domain Error Manager (CDEM) 120 includes circuitry and / or software configured to oversee error management and detect a variety of system anomalies, including uncorrectable or other ECC errors in memory components and task timer timeout errors. The CDEM 120 monitors watchdog task timers associated with the DSP and other initiators, as well as the execution of tasks initiated by those initiators. In some implementations, upon detecting an error, the CDEM 120 is configured to initiate a series of predefined response actions tailored to the specific nature of the detected fault. In various implementations, such actions include isolating affected components to prevent system impact and executing soft and hard reset commands for the individual DSP or ACP 110. This granular level in the response protocol allows for a nuanced approach to error handling, ensuring rapid restoration of system stability with minimal disruption to ongoing operations.

[0042] In some implementations, CDEM 120 operates as: a critical domain manager, which is configured to assign criticality levels to each of a plurality of processing circuit blocks (e.g., DSPs and other processing blocks) (initially assigned, or to modify existing criticality levels previously assigned), and to assign timers to tasks initiated by those processing blocks; and / or an error handling manager configured to monitor the execution of processing blocks and tasks initiated by those processing blocks, and to handle errors at least in part based on the assigned criticality level. In other implementations, critical domain management and error handling functions are managed separately, such as through different critical domain management circuits and error handling circuits, or through different sets of processor-executable instructions embodied in hardware, software, firmware, or some combination thereof.

[0043] In various implementations, CDEM 120 manages the delineation of critical and non-critical domains within ACP 110, thereby ensuring that components within critical domains (those assigned or modified to have an elevated criticality level relative to non-critical components) are protected from failures occurring in non-critical domains (those identified as not having an elevated criticality level). In some implementations, CDEM 120 additionally handles error logging.

[0044] In some implementations, the management of initiated tasks and the handling of errors are differentiated based on the criticality level assigned to each processing block and the tasks initiated by those processing blocks. For example, CDEM 120 assigns different criticality levels to processing blocks and corresponding tasks for those processing blocks, such as assigning longer timeout durations to tasks initiated from within a critical domain, thereby reflecting a higher tolerance for latency.

[0045] In some implementations, CDEM 120 may function in a manner designed to maintain continuous operation in response to the detection of one or more errors in a task initiated by a critical domain block. For example, in various scenarios, CDEM 120 may attempt multiple soft reset protocols or employ other measures designed to minimize interference with these critical functions. For instance, in some implementations, CDEM 120 may execute a soft reset protocol (potentially, one of several such protocols attempted sequentially prior to the execution of one or more hard reset protocols), in which a task that has exceeded its assigned task timer timeout value is falsely reported by CDEM 120 as having been successfully completed. By providing this false indication, CDEM 120 provides the processing circuit block that initiated the timeout task (the initiating processing circuit block) with an opportunity to continue uninterrupted operation based on the increased criticality level of that processing circuit block.

[0046] In contrast, tasks initiated by non-critical domain initiators can withstand a more immediate and comprehensive reset protocol (often referred to as a hard reset). In scenarios where soft resets fail (such as when a soft reset protocol fails to correct an error condition), the CDEM 120 can quickly escalate to initiating a hard reset against the non-critical initiator, thus prioritizing rapid error resolution over operational continuity. Generally, as used herein, a hard reset is a hard reset that includes the initialization of some or all of the functionality of the task initiator.

[0047] In some implementations, each initiator within the system is associated with one or more watchdog task timers. The management of errors detected by these task timers varies based on the criticality of the associated initiator. While critical initiators may continue operating under certain error conditions, non-critical initiators may experience pauses or resets, reflecting the prioritization of critical operations.

[0048] In some implementations, this differentiation approach extends to error logging, where critical errors trigger more immediate and high-priority responses. In contrast, errors from non-critical initiating tasks can be logged for later analysis, indicating their lower immediate impact on overall system operations.

[0049] Figure 2 A component view of an automotive audio processing system 200 according to some embodiments is illustrated in part. System 200 includes a variety of components designed to handle a variety of different audio processing tasks, some of which are identified as safety critical.

[0050] Media playback block 201 serves as the primary input source, handling different types of audio input 203. In various implementations, such audio input 203 includes one or more connections from audio sources, such as streaming audio sources, Bluetooth or other wired / wireless local sources, wireless power, multi-channel audio sources, etc. Audio input 203 is first directed to source selection 204, then through volume tone control 205, tempo-dependent equalizer 206, and finally to upmixer 212. Upmixer 212, which enhances the audio in various ways (e.g., by generating three-dimensional audio based on one-dimensional or two-dimensional audio input data), outputs to audio mixer 220. As used herein, tempo-dependent equalizer refers to an audio equalization system that adjusts its settings based on the speed of the vehicle, such as to optimize or otherwise improve audio quality and intelligibility at different vehicle speeds.

[0051] Both the alert tone block 215 and the acoustic vehicle warning system (AVAS) 218, both identified as "safety-critical" components, provide necessary auditory alerts and notifications: the AVAS is a safety feature in electric and hybrid vehicles that generates artificial noise to warn pedestrians of the vehicle's presence, particularly at low speeds; the alert tone block 215 generates auditory alerts or signals for various vehicle notifications, such as seatbelt warnings, half-open door warnings, or other important vehicle status updates. The space mixer 220, identified as safety-critical, integrates audio inputs from various sources, including the media playback block 201, the alert tone block 215, the AVAS 218, and the telephone receiver 229. The telephone receiver 229 processes incoming telephone signals, routing them to the space mixer 220 and / or the telephone block 230. The telephone block 230 (another safety-critical component) handles telephone processing and transmits outgoing signals via the telephone transmitter 231.

[0052] Microphone input 234 provides input to telephone block 230 for call functionality. Effects block 224 (labeled 'EQ, delay, gain, DRC' to illustrate the various functions that can be performed by those effects blocks) receives input from spatial mixer 220 and provides output via audio output 250.

[0053] As used herein, an initiator refers to a component, block, or subsystem located within or outside the audio processing system 200 that requests or initiates a specific process or task. This may include initiating audio signal processing, generating control commands, or activating specific functions in response to various inputs or predefined conditions. Therefore, in various embodiments, some or all of the components depicted in the audio processing system 200 may act as initiators at different times. Furthermore, although simplified for ease of illustration... Figure 2The examples are provided, but it should be understood that in some embodiments, the various depicted components of the audio processing system 200 (e.g., any or all of the volume tone control 205, speed-dependent equalizer 206, upmixer 212, audio mixer 220, effects block 224, and telephone block 230) include one or more digital signal processors (DSPs), each of which may operate as an initiator at different times.

[0054] The architecture of the automotive audio processing system 200 prioritizes critical audio tasks within the automotive environment, thereby prioritizing the execution of audio functions with an enhanced level of criticality, such as emergency alarms and communications. Furthermore, although in Figure 2 In some implementations, each of the prompt tone block 215, AVAS 218, telephone block 230, and spatial mixer 220 is designated as having the same elevated criticality level (“safety critical”), but in various implementations, the automotive audio processing system 200 and... Figure 1 The audio processing system 100 and Figure 1 and Figure 3 The implementation of the Audio Coprocessor (ACP) 110 supports several key levels of enhancement, as described in more detail elsewhere in this document.

[0055] Figure 3 A partial component view of an audio coprocessor (ACP) 110 according to some implementation schemes is illustrated. The main texture 301 serves as a logical connection texture and a central hub, thereby providing a connection similar to that described above. Figure 1 The data texture 104 interconnects various components of the ACP 110 in a manner described herein, and includes circuitry for providing interconnection between the various components of the ACP 110.

[0056] In the depicted implementation, the main texture 301 is connected to the Audio Video Bridging (AVB) network interface 302 and a corresponding dedicated memory 303, thereby facilitating network communication and data processing. As used herein, Ethernet AVB refers to a set of technical standards that enhance the capabilities of Ethernet networks to achieve improved synchronization, low latency, and reliable data transmission. AVB standards typically support: timing and synchronization for time-sensitive applications, also known as the Generalized Precise Time Protocol (gPTP); Forwarding and Queuing for Time-Sensitive Streams (FQTSS); Quality of Service standards; delivery of real-time content; and bandwidth reservation.

[0057] ACP 110 includes multiple DSPs (collectively referred to herein as DSP 118), which, in the depicted embodiments, include an alarm / tone / telephone DSP 304 with memory 305, an audio mixer / post-processing DSP 306 with memory 307, an active noise cancellation (ANC) DSP 308 with memory 309, and media playback DSPs 310 and 312, respectively coupled to corresponding memories 311 and 313. In various embodiments, each DSP in DSP 118 may include a hardware architecture that is different from, similar to, or the same as each other; similar or the same hardware architecture may be implemented via software or firmware to provide different corresponding functionalities.

[0058] The critical domain error manager 120 is also connected to the main texture 301, thereby overseeing error management within ACP 110. The control interface 316 facilitates interaction and command processing within the system. For data transfer, Direct Memory Access (DMA) 318 is integrated, enabling efficient data movement within the system. The security component 320 ensures the integrity and protection of data and system operations.

[0059] System timing and control register 330 is incorporated to manage system timing, reset, and power gating functionality. GPIO 332 implements general-purpose input / output interaction. Ethernet controller 334 supports network communication, while I2C controller 336 handles serial communication tasks. Normally open shared memory 338, characterized by error correction and access control, provides persistent and reliable storage. I / O interface 340 accommodates various audio and data interfaces, including time-division multiplexing (TDM), etc. High-definition (HD) audio controller 342 manages high-quality audio processing. Enhanced memory interface 344 supports robust memory interaction, and control / status register 346 is included for system monitoring and control functions. It should be understood that the specific configuration depicted for ACP 110 is merely exemplary, and in various implementations and scenarios, any number of interfaces, memories, memory controllers, and other components can be utilized based on the techniques described herein.

[0060] Figure 4 The composition and functionality of CDEM 120 as configured in some implementations are illustrated. CDEM 120 encompasses a series of registers and function blocks that together contribute to the CDEM's comprehensive error management capabilities within ACP.

[0061] In the depicted implementation, CDEM register block 401 includes various settings and registers for the operation of CDEM 120 and ACP 110. Error logging register 402 maintains a record of system anomalies, such as those used for diagnostic purposes. DSP criticality settings 404 allow individual DSPs to be marked as critical or non-critical. In some implementations, DSPs marked as critical do not access system memory, while those marked as non-critical are allowed to access system memory. Memory criticality settings 406 enable the configuration of memory components based on their importance in system operation. Register security settings 408 provide an added layer of security to control access to CDEM registers. DSP TCM access settings 410 manage access to tightly coupled memory of the DSPs, ensuring controlled memory sharing consistent with system criticality. CDEM interrupt control 412 regulates the CDEM's response to system interrupts. DSP non-critical domain reset settings 414 govern the reset protocol for DSPs in non-critical domains. Reset control 416 manages the overall reset functionality of the CDEM. DSP pause control 418 enables specific DSPs to pause as a response to certain error conditions.

[0062] In addition to the register blocks, the CDEM 120 also includes a series of function blocks 420. These blocks store data and instructions related to various error management functions. Among these blocks, the AVB interface reset unit 430 and the DSP 0 reset unit 432 to the DSP are noteworthy. N Reset unit 433, this AVB interface reset unit supervises resets related to the AVB interface, these DSP 0 reset units to DSP N The reset unit represents the reset unit corresponding to any number of DSPs in the ACP 110. The non-critical domain reset 435 handles reset signals within the non-critical domains of the ACP. Error logging 440 supplements the error logging register 402 by providing logging capabilities. DSP pause control 442, DSP TCM access control 444, memory access control 446, system hub access control 448, register access control 450, auto-fill DMA trigger 452, gateway alarm generation 454, and clock monitoring 456 are additional function blocks, each contributing to a specific aspect of error management within the CDEM 120.

[0063] CDEM 120 also receives a variety of input signals indicating various system states (e.g., one or more operating states of the processing system incorporated into CDEM 120) and error conditions. These input signals include a memory ECC error signal 462, a bus (e.g., Advanced Scalable Interface or AXI) timeout error signal 464, an interconnect error signal 466, and a CPU error signal 470. These inputs allow CDEM 120 to dynamically respond to different error scenarios within ACP 110.

[0064] In addition, the CDEM 120 outputs a series of signals based on its internal processes and error assessment. These outputs include a critical DSP reset signal 482, a non-critical DSP reset signal 484, a non-critical domain reset signal 486, a CPU interrupt 488, a DSP interrupt 490, and a DSP pause signal 492. Each output signal serves a specific purpose in managing the CDEM's response to system errors.

[0065] The CDEM 120 provides flexible and robust error handling. Each function block in function block 420 can be utilized independently or in combination with one or more other function blocks in those function blocks in various implementations and scenarios. As a non-limiting example, the CDEM 120 may utilize one or more function blocks in function block 420 to: provide a watchdog task timer for monitoring and error detection for each DSP and / or other initiator; support hardware-driven CPU and system memory error handling, including detection and logging of soft and hard error conditions, and automatic DSP pause upon encountering a configured error condition (e.g., expiration in response to an assigned timeout); and provide watchdog and NIC hang monitoring, as well as interconnect parity or bus fault detection.

[0066] Figure 5 An operational flow is illustrated for a reset procedure 500 initiated by a DSP or other initiator in a non-critical domain (such as in response to a task initiated by the DSP or other initiator exceeding a task timer timeout value). In the depicted embodiment, the reset procedure 500 is initiated by a DSP that does not have any enhanced criticality level (e.g., Figure 3 The critical domain error manager on the media playback DSP310 (e.g., Figure 1 , Figure 3 and Figure 4 Execute CDEM 120.

[0067] The process begins in an idle operating state (505), where the CDEM waits for a condition requiring a soft reset. Upon detection of such a condition, the CDEM proceeds to assert a DSP soft reset request (510), where the CDEM asserts a soft reset request for a specific DSP.

[0068] Following the assertion, the reset procedure 500 moves to wait for acknowledgment (515), where CDEM waits for an acknowledgment signal from the DSP. If no acknowledgment is received within a specified time (ack_timer_expired), the procedure escalates in response to triggering a DSP and non-critical domain reset (520), where CDEM asserts a more comprehensive reset procedure for the specific non-critical DSP.

[0069] In contrast, if an acknowledgment (dsp_sft_rst_ack_rcvd) is received before the assigned task timer timeout value expires, the process proceeds to the application DSP reset (525), where a reset for the DSP is initiated. Depending on the configuration (dsp_sft_rst_auto_cmplt), the reset process may be performed automatically by hardware (540 - hardware deassertion of SFT_RST), or the reset process may require software intervention to complete the reset (530 - software deassertion of SFT_RST). In either case, once the reset is complete, the process returns to the idle operation state (505).

[0070] Figure 6 The operational flow for a reset procedure 600, which may be performed by a critical domain error manager, is illustrated according to some implementation schemes. The reset procedure 600 is typically suitable for scenarios where a soft reset is required for all external interfaces and initiators within the ACP 110. Figure 6 The reset procedure in the context represents a comprehensive system-wide reset and typically addresses a broader range of scenarios compared to reset procedures for individual DSPs or initiators within non-critical domains.

[0071] The reset process 600 begins in an idle operating state (605), where the CDEM 120 is in monitoring mode, waiting for a condition requiring a system-wide soft reset. Upon detection of such a condition, indicated by SFT_RESET_REQ=1, at block 610, the CDEM 120 asserts a soft reset signal across all external interfaces and the initiator (“assert soft reset to all ACP external interfaces and DSP”).

[0072] At box 615, CDEM 120 applies a reset to the non-critical initiator of the ACP, thereby avoiding undue impact on critical operations. Depending on the completion status of the reset process (as indicated by sft_rst_auto_cmplt), the process can take two paths. If the reset does not complete automatically (sft_rst_auto_cmplt=0), CDEM 120 proceeds to software deassertion of the SFT_RST (620), where software intervention is required to manually deasserte the soft reset signal, thus ending the reset process. Alternatively, if the reset process completes automatically (sft_rst_auto_cmplt=1), the reset process 600 proceeds to hardware deassertion of the SFT_RST (625).

[0073] In both scenarios, the process returns to the idle operation state (605) after the soft reset signal is de-asserted.

[0074] In some implementations, the apparatus and techniques described above are used in systems including one or more integrated circuit (IC) devices (also referred to as integrated circuit packages or microchips) (such as those described in the above references). Figure 1 This is implemented in the audio processing system described in Figure 7. Electronic design automation (EDA) and computer-aided design (CAD) software tools can be used in the design and manufacture of these IC devices. These design tools are typically represented as one or more software programs. One or more software programs include code executable by a computer system to manipulate the computer system to operate on code representing one or more IC devices to perform at least a portion of the process for designing or adapting a manufacturing system to manufacture the circuit. The code may include instructions, data, or a combination of instructions and data. Software instructions representing design or manufacturing tools are typically stored in a non-transitory computer-readable storage medium accessible to the computing system. Similarly, code representing one or more stages of the design or manufacture of an IC device may be stored in and accessed from the same computer-readable storage medium or different computer-readable storage media.

[0075] One or more of the elements described above (e.g., CDEM 120 and / or ACP 110, as non-limiting examples) are circuits designed and configured to perform the corresponding operations described above. In at least some embodiments, this circuit is any one or a combination of the following: hard-coded circuitry (e.g., a corresponding portion of an application-specific integrated circuit (ASIC) or a set of logic gates, memory elements, and other components selected and arranged to perform the described operations), programmable circuitry (e.g., a corresponding portion of a field-programmable gate array (FPGA) or a programmable logic device (PLD), or one or more processors executing software instructions that cause one or more processors to perform the described actions. In some embodiments, the circuitry of a particular element is selected, arranged, and configured by one or more computer-implemented design tools. For example, in some embodiments, the sequence of operations for a particular element is defined in a specified computer language (such as register-transfer language), and the computer-implemented design tools select, configure, and arrange the circuitry based on that defined sequence of operations.

[0076] Within this disclosure, in some instances, different entities (which are referred to differently as “components,” “units,” “devices,” “circuits,” etc.) are described or claimed to be “configured” to perform one or more tasks or operations. This way of describing (i.e., an [entity] configured to [perform one or more tasks]) is used herein to refer to a structure (i.e., a physical structure, such as an electronic circuit). More specifically, this way of describing indicates that the physical structure is arranged to perform the one or more tasks during operation. A structure may be referred to as being “configured” to perform a task even if the structure is not currently operating. “Memory device configured to store data” is intended to cover, for example, an integrated circuit having circuitry for storing data during operation, even if the integrated circuit in question is not currently in use (e.g., power is not connected to the integrated circuit). Therefore, an entity described or stated as being “configured” to perform a task refers to a physical structure, such as a device, circuit, memory storing program instructions that can be executed to perform the task, etc. This phrase is not used herein to refer to an intangible structure. Furthermore, the term “configured to” is not intended to mean “configurable as.” For example, an unprogrammed field-programmable gate array will not be considered "configured" to perform a particular function, but it may be "configurable" to perform that function after programming. Additionally, the statement in the appended claims that a structure is "configured" to perform one or more tasks is not expressly intended to be interpreted as having components plus functional elements.

[0077] Computer-readable storage media may include any non-transitory storage medium or a combination of non-transitory storage media that can be accessed by a computer system during use to provide the computer system with instructions and / or data stored by the non-transitory computer-readable storage medium. Such storage media may include, but are not limited to, optical media (e.g., optical discs (CDs), digital versatile optical discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tapes, or magnetic hard disks), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical systems (MEMS) based storage media. Computer-readable storage media may be embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard disk drive), removably attached to a computing system (e.g., an optical disc or a USB-based flash memory), or coupled to a computer system via a wired or wireless network (e.g., a network accessible storage device (NAS)).

[0078] In some implementations, certain aspects of the above-described techniques may be implemented by one or more processors of a processing system executing the software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, manipulate one or more processors to perform one or more aspects of the above-described techniques. The non-transitory computer-readable storage medium may include, for example, disk or optical disc storage devices, solid-state storage devices such as flash memory, cache, random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executable by one or more processors.

[0079] It should be noted that not all activities or elements described above in the general description are essential. A particular activity or part of the apparatus may not be essential, and one or more additional activities may be performed, or elements may be included in addition to those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Additionally, these concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and changes can be made without departing from the scope of this disclosure as set forth in the following claims. Therefore, the specification and drawings are to be considered illustrative rather than restrictive, and all such modifications are intended to be included within the scope of this disclosure.

[0080] The benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and any features that may lead to or make any benefit, advantage, or solution appear or become more significant should not be construed as key, essential, or fundamental features of any or all claims. Furthermore, the specific embodiments disclosed above are merely illustrative, as the disclosed subject matter can be modified and practiced in different but equivalent ways that will be apparent to those skilled in the art who benefit from the teachings herein. No limitation is intended on the details of the constructions or designs shown herein, except as described in the following claims. Therefore, it will be apparent that the specific embodiments disclosed above can be changed or modified, and all such changes are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is as set forth in the following claims.

Claims

1. A method for managing a processing system, the method comprising: Assign a criticality level to each of the multiple processing circuit blocks; Monitor the execution of tasks initiated by the processing circuit block; as well as In response to an error associated with the execution of the initiated task, one or more error handling procedures are performed, at least in part based on the assigned criticality level.

2. The method of claim 1, further comprising assigning task timers to tasks initiated by the plurality of processing circuit blocks, each task timer having a timeout duration based at least in part on an assigned criticality level associated with the processing circuit block that initiated the task.

3. The method of claim 1 or 2, further comprising assigning a task timer to a task initiated by the plurality of processing circuit blocks, each task timer having a timeout duration based at least in part on an assigned criticality level associated with the processing circuit block assigned to perform the task.

4. The method of any one of claims 1 to 3, wherein performing the one or more error handling procedures includes initiating a soft reset protocol for the task associated with the timeout in response to the expiration of a timeout associated with the task prior to task completion.

5. The method of claim 4, wherein the soft reset protocol includes providing a false indication that the task has been successfully completed to the initiation processing circuit block that initiated the task associated with the timeout.

6. The method of claim 4 or 5, further comprising initiating a hard reset protocol for the processing circuit block in response to the failure of the soft reset protocol to correct the error condition.

7. The method according to any one of claims 4 to 6, wherein the hard reset protocol includes initializing the initiation processing circuit block.

8. The method of any one of claims 4 to 7, wherein the task associated with the timeout is initiated by a processing circuit block assigned an elevated criticality level, and wherein performing the one or more error handling procedures includes initiating the soft reset protocol based at least in part on the elevated criticality level assigned to the initiating processing circuit block.

9. The method according to any one of claims 1 to 8, further comprising: The timeout value of the first task timer is assigned to the task initiated by the first processing circuit block, which is assigned the first critical level. The timeout value of the second task timer is assigned to the second task initiated by the second processing circuit block, which is assigned a second criticality level higher than the first criticality level; and The timeout value of the second task timer is greater than the timeout value of the first task timer.

10. The method according to any one of claims 1 to 9, the method further comprising dynamically modifying the criticality level assigned to at least one processing circuit block based on one or more changes to the operating state of the processing system.

11. The method of any one of claims 1 to 10, wherein the plurality of processing circuit blocks comprises a plurality of digital signal processors (DSPs), and wherein assigning a criticality level to each processing circuit block comprises assigning at least one of the plurality of DSPs a higher criticality level than one or more other DSPs among the plurality of DSPs.

12. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 11.

13. A processing system, the processing system comprising: The processing system comprises multiple processing circuit blocks, critical domain management circuitry, and error handling circuitry, and is configured to perform the method according to any one of claims 1 to 11.

Images