Intelligent DSP chip integrated development environment system and method

Abstract

The application relates to the technical field of integrated circuits and embedded software development tools, and provides an intelligent DSP chip integrated development environment system and method, which is composed of a unified project management module, an intelligent code editor, a heterogeneous compiling optimization engine, a joint debugging simulation module, a performance analysis and optimization tool and a safe and reliable construction module, and realizes support for a CPU core and a DSP core heterogeneous topology, supports a joint debugging function of the CPU core and the DSP core, automatically gives migration / optimization suggestions based on analysis results by adopting fine-grained performance collection across heterogeneous units, greatly reduces manual adaptation errors, is highly compatible with a local heterogeneous platform, reduces manual distribution workload and improves resource utilization, realizes intelligent heterogeneous scheduling, significantly reduces complex system debugging time, shortens an optimization period, reduces a supply chain risk, and is safe and reliable.

Description

Technical Field

[0001] This invention belongs to the technical field of integrated circuits and embedded software development tools, and relates to an intelligent DSP chip integrated development environment system and method. Background Technology

[0002] With continuous breakthroughs in domestic high-end chip design capabilities, heterogeneous intelligent DSP chips have been widely deployed in key scenarios such as communication, radar, vision, and voice. These chips employ an on-chip multi-core heterogeneous design, combining a general-purpose CPU core, a dedicated DSP core, and an NPU / AI acceleration unit. Through an improved Harvard architecture, they achieve parallel processing of instructions and data, significantly improving energy efficiency in various scenarios while maintaining high performance. Some products have achieved peak double-precision floating-point performance exceeding 10 TFLOPS, with efficiency reaching over 50 GFLOPS / W. Their core advantage lies in deep optimization for specific algorithms, such as FFT operations in radar signal processing and convolution operations in visual scenes. Customized instruction sets and multi-level storage architectures meet real-time computing requirements.

[0003] However, the independent design of heterogeneous intelligent DSP chips brings compatibility challenges. To achieve independent control, these chips generally adopt proprietary ISAs (such as LoongISA and other proprietary instruction sets), coupled with special memory mapping mechanisms and customized interrupt and peripheral structures to adapt to multi-master collaborative working scenarios. Existing mainstream integrated development environments (IDEs) are not adapted to local chip architectures in commercial products (such as Keil and IAR), and open-source tools (such as customized environments based on Eclipse) lack in-depth optimization. This results in the inability to directly support proprietary instruction set compilation, special address space debugging, and peripheral driver development, severely restricting chip performance and application deployment efficiency. Therefore, there is an urgent need to develop targeted integrated development environment solutions. Summary of the Invention

[0004] To address the problems existing in the above-mentioned traditional methods, this invention proposes an intelligent DSP chip integrated development environment system and a heterogeneous task partitioning method in the intelligent DSP chip integrated development environment, which can improve the adaptability to local heterogeneous chips, heterogeneous scheduling and cross-core debugging capabilities, and ensure the independent control of the ecosystem and supply chain.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, an intelligent DSP chip integrated development environment system is provided, including: The unified project management module supports project template, board-level configuration selection and version control integration, and is used to automatically generate startup files, linker scripts, partition table files and build configurations for software projects targeting DSP chips under ADF file driving. The intelligent code editor utilizes dedicated keywords for built-in CPU and DSP cores, inline assembly snippet templates, static analysis plugins, and local help documentation to complete software engineering code editing. The intelligent code editor supports mixed use of C, C++, and assembly languages, and supports project-level symbol indexing, cross-file navigation, and rapid refactoring. The heterogeneous compilation optimization engine is designed for software engineering. It is used to generate the underlying virtual machine intermediate representation for the front end, perform intermediate layer task analysis, estimate the cost of execution on different cores based on the performance labels of each core in the ADF file using a cost model, perform task-to-core mapping according to indicators, and generate target code for the cores. When generating target code for the cores, it supports separate image output or multi-image merging strategies. The joint debugging and simulation module is used to perform hardware debugging, simulation debugging, and visualization of the target DSP chip using software engineering. Hardware debugging supports cross-core breakpoints, breakpoint conditions, and watchpoints for CPU cores and DSP cores. Visualization includes multi-core timeline, DMA monitoring, bus transfer monitoring, shared memory access conflict highlighting, and heterogeneous task switching view. The performance analysis and tuning tool is used to perform data acquisition, report generation, and output optimization suggestions during the debugging process of the target DSP chip. The acquired data includes event counters, cache behavior, MAC utilization, NPU computing power usage, and memory bandwidth utilization. The optimization suggestions are based on the cost model and provide suggestions for function migration, loop vectorization, and DMA merge transfer. The secure and trusted building module supports SM2 signatures and SM3 hash verification, and adopts firmware encryption and device binding strategies to provide secure boot configuration files and trusted root generation tools for software engineering.

[0006] In one embodiment, when performing task-to-core mapping according to an indicator, it is supported to force or suggest mapping the task to a DSP core or CPU core via the indicator; the mapping method includes at least one of automatic mapping and manual mapping.

[0007] In one embodiment, the fields of the ADF file include chip model, manufacturer identifier, core topology, memory layout, interrupt vector table mapping, exception vector table mapping, peripheral register base address, peripheral register base address access permissions, performance tag, boot information, and load information.

[0008] In one embodiment, hardware debugging is performed by connecting to the target DSP chip via a JTAG debugging interface, an SWD debugging interface, or a vendor-specific debugging interface.

[0009] In one embodiment, simulation debugging is achieved by providing an accurate instruction-level simulator, and the joint debugging simulation module also supports timing playback and scripting of debugging sessions.

[0010] In one embodiment, the report generates an interactive report that supports filtering by function, thread, core, or time interval.

[0011] In one embodiment, the unified project management module is also configured with plugins and extended application interfaces for executing ADF file extensions, running new chip adaptation plugins, real-time operating system support plugins, and CI / CD access plugins.

[0012] In one embodiment, the static analysis plugin includes a syntax error checking plugin, a type mismatch checking plugin, an out-of-bounds access checking plugin, and a null pointer risk checking plugin.

[0013] In one embodiment, the local help documentation includes documentation on specialized keywords, compiler option descriptions, inline assembly template usage, and sample code.

[0014] On the other hand, a heterogeneous task partitioning method is also provided in an intelligent DSP chip integrated development environment, based on the aforementioned intelligent DSP chip integrated development environment system. This heterogeneous task partitioning method in the intelligent DSP chip integrated development environment includes the following steps: Construct function call graphs and basic block control flow graphs for software engineering of the target DSP chip, and label the computational density and memory access characteristics of each basic block; Based on ADF files and runtime estimation models, the cost of executing a task on CPU cores, DSP cores, and NPU cores is calculated. Solve the approximate optimization problem in multi-core task mapping and output the task mapping scheme; For critical paths or hotspot areas in the task mapping scheme, optimize and adjust them by using developer manual prompts to override automatic strategies. The distribution script and image layout are generated based on the optimized and adjusted task mapping scheme.

[0015] One of the above technical solutions has the following advantages and beneficial effects: The aforementioned intelligent DSP chip integrated development environment system and method, through the design of a new IDE system composed of a unified project management module, an intelligent code editor, a heterogeneous compilation optimization engine, a joint debugging and simulation module, a performance analysis and tuning tool, and a secure and reliable construction module, can automatically generate projects and build processes based on ADF file descriptions. It integrates the cost model and automatic mapping mechanism for heterogeneous task partitioning within the LLVM framework, realizes support for heterogeneous topologies of CPU cores and DSP cores, supports joint debugging functions of CPU cores and DSP cores, and adopts fine-grained performance acquisition across heterogeneous units (CPU, DSP / NPU) and automatically provides migration / optimization suggestions based on analysis results.

[0016] Compared to traditional IDEs, the above solution comprehensively describes platform characteristics and drives project generation through ADF, significantly reducing manual adaptation errors. It is highly compatible with local heterogeneous platforms. The cost model and automatic mapping reduce the workload of manual allocation and improve resource utilization, enabling intelligent heterogeneous scheduling. Cross-core synchronization and timing playback significantly reduce the debugging time of complex systems, enabling efficient joint debugging. Furthermore, it can provide easily executable optimization measures based on hotspot analysis, shortening the tuning cycle and providing actionable performance suggestions. By using national cryptographic signatures and device binding, it ensures the trustworthiness of the firmware source, reduces supply chain risks, and ensures security and reliability. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of the module composition of an intelligent DSP chip integrated development environment system in one embodiment; Figure 2 This is a schematic diagram of the ADF-driven project generation process in one embodiment; Figure 3 This is a schematic diagram of the workflow of a heterogeneous compilation optimization engine in one embodiment; Figure 4 This is a schematic diagram of the interface for joint debugging in one embodiment; Figure 5 This is a schematic diagram of the workflow for performance analysis and optimization recommendations in one embodiment; Figure 6 This is a flowchart illustrating a heterogeneous task partitioning method in an integrated development environment for an intelligent DSP chip, as shown in one embodiment. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention.

[0020] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used herein refers to any combination of one or more of the associated listed items, and all possible combinations, including such combinations.

[0021] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0022] In one embodiment, such as Figure 1 As shown, an intelligent DSP chip integrated development environment system is provided, including a unified project management module 11, an intelligent code editor 13, a heterogeneous compilation optimization engine 15, a joint debugging and simulation module 17, a performance analysis and tuning tool 19, and a secure and reliable construction module 21. The unified project management module 11 supports project template, board-level configuration selection, and version control integration, and is used to automatically generate startup files, linker scripts, partition table files, and build configurations for software projects targeting the DSP chip, driven by ADF files.

[0023] The intelligent code editor 13 utilizes dedicated keywords for built-in CPU and DSP cores, inline assembly fragment templates, static analysis plugins, and local help documentation to complete code editing for software engineering projects. The intelligent code editor supports mixed use of C, C++, and assembly languages, and supports project-level symbol indexing, cross-file navigation, and rapid refactoring. The heterogeneous compilation optimization engine 15 is designed for software engineering, generating low-level virtual machine intermediate representations at the front end, performing intermediate-level task analysis, estimating the cost of execution on different cores based on performance labels in the ADF file using a cost model, mapping tasks to cores according to indicators, and generating target code for cores. When generating target code for cores, it supports individual image output or multi-image merging strategies.

[0024] The joint debugging and simulation module 17 is used to perform hardware debugging, simulation debugging, and visualization of the target DSP chip using software engineering. Hardware debugging supports cross-core breakpoints, breakpoint conditions, and observation points for both CPU and DSP cores. Visualization includes a multi-core timeline, DMA monitoring, bus transfer monitoring, shared memory access conflict highlighting, and heterogeneous task switching views. The performance analysis and tuning tool 19 is used to perform data acquisition, report generation, and output optimization suggestions during the debugging process of the target DSP chip. The acquired data includes event counters, cache behavior, MAC utilization, NPU computing power usage, and memory bandwidth utilization. The optimization suggestions combine cost models to provide function migration suggestions, loop vectorization suggestions, and DMA merge transfer suggestions. The secure and trustworthy construction module 21 supports SM2 signature and SM3 hash verification, and adopts firmware encryption and device binding strategies to provide secure boot configuration files and trusted root generation tools for software engineering.

[0025] It can be understood that the overall architecture of the IDE system designed in this embodiment consists of the following modules: The unified project management module (i.e., Project Manager) is driven by ADF (Architecture Description File) and is used to automatically generate startup files, linker scripts, partition tables, and build configurations for software projects targeting DSP chips; it supports project templates, board-level configuration selection, and version control integration (Git, an open-source distributed version control system).

[0026] ADF uses a structured description format to uniformly describe the architecture information of software engineering that can be built for a specific target DSP chip. The information in the ADF file includes, but is not limited to, the target chip (or processor) model, board-level hardware resource configuration (such as memory distribution, peripheral mapping and interrupt resources), project build parameters (such as the compiler type, compilation options and linking strategy of the heterogeneous compilation optimization engine), and software component module dependencies.

[0027] During the software engineering creation process, the system receives the project template and target board-level configuration selected by the user in the graphical interface, and loads the corresponding ADF file based on the selected template and configuration. The system parses the ADF file, converting the information described therein, such as board-level hardware resource configurations, project build parameters, and software component module dependencies, into a unified internal project description model. This model serves as a unified data source for software engineering configuration, describing the overall structure and build attributes of the software project.

[0028] During the software engineering compilation process, the system automatically generates a build file that matches the current software engineering configuration based on the engineering description model and the engineering build parameters and board-level hardware resource configuration defined in the ADF file. Specifically, the system generates corresponding linker scripts based on the memory region information described in the ADF file (such as, but not limited to, the starting addresses and capacities of FLASH and RAM), and automatically associates these linker scripts with the software engineering build process to ensure that the generated target file is consistent with the actual board-level hardware resource configuration.

[0029] For software engineering projects involving multiple storage regions or firmware partitions, the system further automatically generates a partition table file based on the partition configuration information describing the memory distribution in the ADF file. The partition configuration information includes at least the starting address, size, and type of each partition. During the partition table file generation process, the system verifies the address range of each partition to avoid overlapping conflicts, and uses the generated partition table file as one of the input files for software engineering construction or subsequent firmware deployment. Version control integration can use Git (an open-source distributed version control system) through open-source plugin integration.

[0030] Furthermore, regarding the key specifications of ADF files, ADF files are critical metadata files in the IDE, used to describe the hardware topology and resource mapping of the target chip. Key fields include chip model, manufacturer identifier (including CPU-related information), core topology (listing the number of CPU cores, DSP cores, NPU units, and interconnections), memory layout (including on-chip address segments, off-chip address segments, and memory attributes such as cacheable or non-cacheable for each core), interrupt vector table mapping, exception vector table mapping, peripheral register base addresses, peripheral register base address access permissions, performance tags (including evaluation metrics for each processing unit, such as single-core floating-point operations (GFLOPS), vector width, and MAC per cycle for multiply-accumulate operations), boot information, and load information (including boot order, boot image location, and Boot ROM (Boot Read-Only Memory) constraints).

[0031] ADF files can be provided by the chip manufacturer. The IDE provides an ADF file editor and ADF verifier, and supports a unified project management module to automatically generate buildable software projects and build parameters for specific target DSP chips, such as... Figure 2 As shown.

[0032] The intelligent code editor (Editor) supports mixed use of C, C++, and assembly languages. It includes built-in keywords specific to CPU and DSP cores (e.g., `__vector int v_num` indicates that the variable is a vector variable of the DSP core, and `__vector` is a specific keyword), inline assembly snippet templates, static analysis plugins, and local help documentation. It supports project-level symbol indexing, cross-file navigation, and rapid refactoring. The inline assembly snippet template is a manually written and optimized reusable assembly code template that fully utilizes hardware features to improve code performance; users can generate the required assembly code based on this template. Static analysis plugins include syntax error checking, type mismatch checking, out-of-bounds access checking, and null pointer risk checking to check for potential risks in the code. Local help documentation includes documentation on specific keywords, compiler option descriptions, inline assembly template usage, and sample code. For the aforementioned buildable software engineering, the project-level symbol index is an outline-style index displaying the styles of functions, variables, types, and macros throughout the entire project. Cross-file navigation refers to the ability to quickly jump between project-level symbol indexes of multiple referenced source files. For example, if you quickly refactor and change the name of one of your functions, you can quickly rename other locations that reference this symbol using the project-level symbol index.

[0033] The heterogeneous compiler optimization engine is based on a deeply customized underlying Low-Level Virtual Machine (LLVM) and includes: The front-end (Clang) generates the LLVM Intermediate Representation (IR); the LLVM IR is an intermediate representation generated by the compiler and used for program optimization and target code generation.

[0034] Middle-layer task analysis includes building a call graph, loop analysis, and data dependency analysis. Cost model: used to estimate the cost of execution on different cores based on the performance tags (such as integer throughput, vector unit width, and MAC throughput) of each core in the ADF file; MAC in this paper refers to Multiply-Accumulate, which is a basic and key computing unit or computing instruction type in DSP cores and NPU cores. MAC = a × b + c (that is, perform a multiplication first and then accumulate the result into an accumulator, where a, b, and c are the respective computing parameters).

[0035] Optionally, when performing task-to-core mapping according to the indicator, it is supported to force or suggest mapping the task to the DSP core or CPU core through the indicator; the mapping method includes at least one of automatic mapping and manual mapping.

[0036] Specifically, automatic / manual mapping: supports directives such as #pragma ft_task(target=dsp) to force or suggest mapping tasks to DSP cores or CPU cores; Backend generation: Generates target code for CPU cores and private DSP cores, supporting separate image output or multi-image merging strategies.

[0037] Task mapping is a functional-level description, related to but not identical to the heterogeneous task partitioning algorithm described below, which is a process-level description of implementing this function. The multi-image merging strategy merges multiple functional images into a unified image package according to predetermined rules, which is then parsed during the startup phase and loaded onto the corresponding cores for execution. The workflow of the heterogeneous compilation optimization engine is as follows: Figure 3 As shown.

[0038] The Joint Debugging Simulation Module (Debugger & ISS) is used for hardware debugging, simulation debugging, and visualization. Hardware debugging connects to the target board (i.e., the target DSP chip to be debugged) via the JTAG debugging interface, SWD debugging interface, or vendor-specific debugging interface; it supports cross-core breakpoints, breakpoint conditions, and watchpoints between CPU cores and DSP cores. Simulation debugging provides a periodically accurate instruction-level simulator (ISS) that can be run and debugged offline on the host machine. Visualization includes a multi-core timeline, DMA (Direct Memory Access) monitoring, bus transfer monitoring, shared memory access conflict highlighting, and a heterogeneous task switching view.

[0039] Among them, cross-core breakpoints are collaborative breakpoints across CPU cores and DSP cores, which can support two triggering logics: one is linkage triggering, where the entire chip system is paused only when the CPU core executes instruction A and the DSP core executes instruction B, making it convenient to check the running status of the two cores at the same time; the other is cascading triggering, where when one core triggers a breakpoint, the other core is automatically paused as well (for example, after the CPU core breakpoint is triggered, the DSP core is synchronously stopped at the current instruction), avoiding the execution progress of the two cores from becoming disconnected.

[0040] Breakpoint conditions add trigger thresholds to cross-core breakpoints. Instead of pausing immediately upon meeting an instruction location, a breakpoint is triggered only when a custom condition is met, such as "the value of CPU register R1 is 0x00FF and the data at DSP memory address 0x20000000 is greater than 50". This allows for precise filtering of invalid pauses and pinpointing defects (bugs) in specific scenarios. Watchpoints differ from instruction-triggered breakpoints. Watchpoints are data access-triggered monitoring mechanisms and support cross-core monitoring. For example, a watchpoint can be set to monitor the "shared buffer for data transfer between the CPU core and the DSP core." When this buffer is written to by the CPU core or read by the DSP core, the system automatically pauses, facilitating the tracking of anomalies in cross-core data interaction (such as data transmission loss or tampering).

[0041] Furthermore, the specific functionalities of joint debugging may include: Cross-core breakpoint synchronization: When setting cross-core breakpoints, it supports atomically pausing all relevant cores or pausing as needed based on the order of events.

[0042] Observation points and data assertions: Supports monitoring read and write operations of shared memory regions, triggering breakpoints, or sampling.

[0043] Timing playback: Records important events (such as task switching, interrupts, and DMA startup / completion), and supports visual playback analysis.

[0044] Scripted debugging sessions: Supports reproducing the debugging process via scripts, facilitating automated regression testing; the interface for joint debugging is as follows... Figure 4 As shown, it includes a multi-core call stack view, register window, memory monitoring window, unified timeline waveform graph, debug control and status bar, etc. Core0 and Core1 are the other two processor cores.

[0045] Performance analysis and tuning tools (i.e., Profiler & Advisor) are used to perform data acquisition, report generation, and output optimization suggestions. Data acquisition involves collecting performance data such as event counters, cache behavior, MAC utilization, NPU computing power usage, and memory bandwidth utilization through debug interfaces or simulators. Report generation includes alerts on hot functions, call paths, cycle allocation, resource idleness, and resource saturation periods. Optimization suggestions are provided based on cost models, such as function migration suggestions, loop vectorization suggestions, and DMA merge transfer suggestions.

[0046] Function migration suggestions include, for example: based on cost models, analyzing the expected cost of executing a function on the CPU or DSP / NPU, and providing suggestions on "which core is more suitable for execution." Loop vectorization suggestions include, for example: analyzing whether hot loops meet the conditions for vectorization, and suggesting that performance can be improved through SIMD / DSP vector instructions. SIMD stands for Single Instruction Multiple Data, where a single instruction performs the same action on multiple data elements simultaneously. DMA merge transfer suggestions include, for example: analyzing multiple small-scale, discrete data copy operations, and suggesting merging them into one or a few DMA transfers.

[0047] Key aspects of performance acquisition and analysis include: employing a hybrid approach of lightweight sampling and event-driven methods to minimize interference from online debugging on the target system; using dedicated counters or drivers to report throughput (or latency) data for NPU / AI acceleration units; and generating interactive reports in the IDE after data aggregation, supporting filtering by function, thread, core, or time interval. The workflow for performance analysis and tuning recommendations is as follows: Figure 5 As shown.

[0048] Lightweight sampling involves periodically or randomly sampling the program state during execution, rather than recording every instruction. It can collect information such as function execution time, call frequency, and loop counts. Event-driven sampling, on the other hand, involves sampling triggered by typical events, such as asynchronous interrupts, DMA transfer completions, and MAC unit saturation.

[0049] The NPU / AI acceleration unit is a dedicated hardware unit responsible for neural network inference or AI-intensive computation. Unlike CPU / DSP, its computation mode is mainly matrix (or vector) parallelism and MAC-intensive, with completely different instruction granularity and execution cycle, and high throughput and low latency for data access.

[0050] Traditional CPU sampling struggles to reflect true throughput and latency, and online debugging can be disruptive. Therefore, dedicated counters or drivers are needed to report NPU core performance metrics. These dedicated counters are internal hardware registers provided by the NPU, recording various performance events at runtime, similar to CPU hardware performance counters, but tailored to NPU characteristics. Typical NPU metrics include instruction throughput, MAC utilization, vector unit utilization, and memory bandwidth. Data is acquired in the background or in conjunction with a debugging interface.

[0051] Driver reporting is performed at the system level via the NPU / AI driver software API. It does not directly access hardware counters, but instead obtains them through interfaces provided by the operating system / SDK (Software Development Kit). Drivers report data upon completion of tasks or at specific intervals.

[0052] The Secure Build module supports SM2 signing and SM3 hash verification, employs firmware encryption (SM4) and device binding strategies (such as device certificates / serial numbers), and provides secure boot configuration files and trusted root generation tools. The security and build implementation details are as follows: Both the build server and the local build chain can use national cryptographic algorithms to complete artifact signing; the firmware includes signature metadata and device authorization fields, and the flashing tool verifies the signature and device binding information before allowing writing; it supports verification of intermediate artifacts (such as .o files / .a files) to prevent tampering. These intermediate artifacts refer to target files or library files generated during the build process, used for security verification and final firmware generation.

[0053] Secure Boot Configuration File: This configuration file is used during device startup and stores trusted root information, a list of allowed firmware signatures, and authorized device information (such as certificates or serial numbers). Its main function is to verify the legitimacy of firmware during the system startup phase, determining which firmware can be loaded and executed, and preventing unauthorized or tampered firmware from running.

[0054] Trusted root generation tool: A tool provided by the manufacturer or system integrator to generate trusted root information for the device, such as root key, root certificate, signature template and device authorization information, as the basic source of trust for secure boot and firmware signing.

[0055] Firmware: The executable program or binary image that actually runs on the device's CPU, DSP, and NPU; that is, the product of software engineering built by the integrated development environment.

[0056] Device binding information refers to authentication data included in the firmware or secure boot process that can uniquely identify the target device. It is used to verify whether the firmware and device match, such as device certificate, device serial number, and hardware unique ID.

[0057] The aforementioned intelligent DSP chip integrated development environment system, through the design of a new IDE system consisting of a unified project management module, an intelligent code editor, a heterogeneous compilation optimization engine, a joint debugging and simulation module, performance analysis and tuning tools, and a secure and reliable construction module, can automatically generate projects and build processes based on ADF file descriptions. It integrates the cost model and automatic mapping mechanism for heterogeneous task partitioning within the LLVM framework, realizes support for heterogeneous topologies of CPU cores and DSP cores, supports joint debugging functions of CPU cores and DSP cores, and adopts fine-grained performance acquisition across heterogeneous units (CPU, DSP / NPU) and automatically provides migration / optimization suggestions based on analysis results.

[0058] Compared to traditional IDEs, the above solution comprehensively describes platform characteristics and drives project generation through ADF, significantly reducing manual adaptation errors. It is highly compatible with local heterogeneous platforms. The cost model and automatic mapping reduce the workload of manual allocation and improve resource utilization, enabling intelligent heterogeneous scheduling. Cross-core synchronization and timing playback significantly reduce the debugging time of complex systems, enabling efficient joint debugging. Furthermore, it can provide easily executable optimization measures based on hotspot analysis, shortening the tuning cycle and providing actionable performance suggestions. By using national cryptographic signatures and device binding, it ensures the trustworthiness of the firmware source, reduces supply chain risks, and ensures security and reliability.

[0059] In some implementations, the system is also configured with a plugin and extension mechanism (i.e., a Plugin System): through the plugin and extension application interface (API), it supports ADF file extensions, new chip adaptation plugins, real-time operating system (RTOS) support plugins (such as RT-Thread and SylixOS), and CI / CD access plugins; CI / CD itself is an automated process for software development (implementing code submission, automatic compilation, automatic testing, and automatic deployment).

[0060] The ADF file extension provides a plugin API, allowing developers to register new ADF parsers or extenders, define new board-level configurations or chip resource templates, and generate custom boot files, linker scripts, and partition tables for different chips (or functions). New chip adaptation plugins and real-time operating system (RTOS) support plugins are supported in a similar manner to the ADF file extension.

[0061] The heterogeneous task partitioning algorithm executed by the heterogeneous compilation optimization engine can be as follows: Construct function call graphs and basic block control flow graphs, labeling the computational density and memory access characteristics of each basic block. The function call graph, formed through static analysis of the program, is a structured representation of the call relationships between functions, used to identify computational hotspots and call dependencies, thus providing a basis for the partitioning and mapping of heterogeneous tasks across CPUs, DSPs, and NPUs. A basic block is the smallest consecutive sequence of instructions in a program that does not contain branch jumps. The basic block control flow graph is a diagram showing the control and controlled relationships between these basic blocks. The computational density of a basic block measures the proportion and intensity of effective arithmetic and logical operations within it, describing how "computing" a piece of code is. Memory access characteristics describe the patterns, locality, granularity, and modes of read (Load) and write (Store) ratios within a basic block, describing how a piece of code "reads / writes memory."

[0062] Based on ADF files and runtime estimation models, the costs (such as execution time, energy consumption estimates, and memory usage) of execution on CPU cores, DSP cores, and NPU cores are calculated. The runtime estimation model is an existing computational framework for predicting task execution time, crucial in high-performance computing, grid clusters, and software testing, where its accuracy directly impacts resource scheduling efficiency and system performance. The core of the runtime estimation model lies in capturing key characteristics of user estimation behavior. User estimates of task runtime significantly affect the scheduling performance of parallel systems; therefore, the model must accurately reflect the distribution characteristics of the estimated values.

[0063] Solve approximate optimization problems (such as approximate algorithms based on heuristics or integer linear programming) and output task mapping schemes. Approximate optimization problems refer to the task allocation schemes obtained by using heuristics or approximate algorithms in multi-core (such as CPU, DSP and NPU) task mapping, where there are many objectives (such as time, energy consumption and memory, etc.) and complex constraints, and the computation cost of the exact optimal solution is too high.

[0064] For critical paths or hotspot areas in the task mapping scheme, developers can use manual hints (such as the #pragma directive) to override the automatic strategy for optimization and adjustment. The compiler has a default task mapping strategy. Developer manual hints to override the automatic strategy means that, based on the automatic task mapping results, developers are allowed to manually specify critical functions or hotspot tasks (i.e., areas) through directives (such as #pragma), thereby replacing or correcting the automatic mapping decisions given by the compiler.

[0065] Based on the optimized task mapping scheme, a distribution script and image layout are generated to ensure that the code segment, data segment, and load address of each core meet the startup order. This heterogeneous task partitioning algorithm is executed by a heterogeneous compilation optimization engine, with feedback support provided by performance analysis and tuning tools.

[0066] Each module component in the aforementioned intelligent DSP chip integrated development environment system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of a device with data processing capabilities, or stored in software within the memory of that device, so that the processor can call and execute the operations corresponding to each module. The aforementioned device can be, but is not limited to, various types of computer devices already existing in the field.

[0067] In one embodiment, a heterogeneous task partitioning method is also provided in an intelligent DSP chip integrated development environment, based on the aforementioned intelligent DSP chip integrated development environment system. For example... Figure 6 As shown, the heterogeneous task partitioning method in the intelligent DSP chip integrated development environment may include the following steps S10 to S18: S10: Construct the function call graph and basic block control flow graph for the software engineering of the target DSP chip, and label the computational density and memory access characteristics of each basic block. S12, based on the ADF file and runtime estimation model, calculates the cost of executing the task on CPU cores, DSP cores, and NPU cores; S14, Solve the approximate optimization problem in multi-core task mapping and output the task mapping scheme; S16, optimize and adjust the critical paths or hotspot areas in the task mapping scheme by using the developer's manual prompts to cover the automatic strategy. S18, Generate distribution script and image layout based on the optimized and adjusted task mapping scheme.

[0068] It is understandable that the specific limitations of the heterogeneous task partitioning method in the intelligent DSP chip integrated development environment can be found in the corresponding limitations of the intelligent DSP chip integrated development environment system mentioned above, and will not be repeated here.

[0069] The heterogeneous task partitioning method in the above-mentioned intelligent DSP chip integrated development environment comprehensively describes the platform characteristics and drives the engineering generation through ADF, which greatly reduces manual adaptation errors, can be highly compatible with local heterogeneous platforms, and the cost model and automatic mapping reduce the workload of manual allocation and improve resource utilization, realize intelligent heterogeneous scheduling, and improve the efficiency and quality of multi-core heterogeneous task partitioning.

[0070] It should be understood that, although Figure 6 The steps are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order in which these steps are executed; they can be performed in other orders. Figure 6At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0071] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0072] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of protection of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and all such modifications and improvements fall within the scope of protection of the present invention.

Claims

1. A smart DSP chip integrated development environment system, characterized in that, include: The unified project management module supports project template, board-level configuration selection and version control integration, and is used to automatically generate startup files, linker scripts, partition table files and build configurations for software projects targeting DSP chips under ADF file driving. A smart code editor that utilizes dedicated keywords for built-in CPU and DSP cores, inline assembly snippet templates, static analysis plugins, and local help documentation to complete code editing for software projects; The intelligent code editor supports mixed use of C, C++, and assembly languages, and supports project-level symbol indexing, cross-file navigation, and rapid refactoring. The heterogeneous compilation optimization engine is designed for software engineering, used for front-end generation of underlying virtual machine intermediate representations, execution of intermediate layer task analysis, estimation of execution cost on different cores based on the performance labels of each core in the ADF file using a cost model, execution of task-to-core mapping according to indicators, and generation of target code for cores. When generating target code for the kernel, it supports separate image output or multiple image merging strategies; The joint debugging and simulation module is used to perform hardware debugging, simulation debugging, and visualization of the target DSP chip using software engineering. Hardware debugging supports cross-core breakpoints, breakpoint conditions, and watchpoints for CPU cores and DSP cores. Visualization includes multi-core timeline, DMA monitoring, bus transfer monitoring, shared memory access conflict highlighting, and heterogeneous task switching view. Performance analysis and tuning tools are used to perform data acquisition, report generation, and output optimization suggestions during the debugging process of the target DSP chip. The collected data includes event counters, cache behavior, MAC utilization, NPU computing power usage, and memory bandwidth utilization. The optimization suggestions are to combine the cost model to provide function migration suggestions, loop vectorization suggestions, and DMA merge transfer suggestions. The secure and trusted building module supports SM2 signatures and SM3 hash verification, and adopts firmware encryption and device binding strategies to provide secure boot configuration files and trusted root generation tools for software engineering.

2. The intelligent DSP chip integrated development environment system according to claim 1, characterized in that, When performing task-to-core mapping according to the indicator, it is supported to force or suggest mapping the task to the DSP core or CPU core through the indicator; the mapping method includes at least one of automatic mapping and manual mapping.

3. The intelligent DSP chip integrated development environment system according to claim 1 or 2, characterized in that, The fields in the ADF file include chip model, manufacturer identifier, core topology, memory layout, interrupt vector table mapping, exception vector table mapping, peripheral register base address, peripheral register base address access permissions, performance tags, boot information, and load information.

4. The intelligent DSP chip integrated development environment system according to any one of claims 1 to 3, characterized in that, During hardware debugging, the target DSP chip is connected via the JTAG debugging interface, SWD debugging interface, or manufacturer-specific debugging interface.

5. The intelligent DSP chip integrated development environment system according to claim 4, characterized in that, Simulation debugging is achieved by providing a precise instruction-level simulator. The joint debugging simulation module also supports timing playback and scripting of debugging sessions.

6. The intelligent DSP chip integrated development environment system according to claim 4, characterized in that, The report is interactive and supports filtering by function, thread, core, or time range.

7. The intelligent DSP chip integrated development environment system according to claim 4, characterized in that, The unified project management module is also configured with plugins and extended application interfaces for executing ADF file extensions, running new chip adaptation plugins, real-time operating system support plugins, and CI / CD access plugins.

8. The intelligent DSP chip integrated development environment system according to claim 4, characterized in that, Static analysis plugins include syntax error checking plugins, type mismatch checking plugins, out-of-bounds access checking plugins, and null pointer risk checking plugins.

9. The intelligent DSP chip integrated development environment system according to claim 4, characterized in that, The local help documentation includes descriptions of specialized keywords, compiler option descriptions, inline assembly template usage, and sample code.

10. A method for heterogeneous task partitioning in an intelligent DSP chip integrated development environment, characterized in that, The intelligent DSP chip integrated development environment system according to any one of claims 1 to 9; The heterogeneous task partitioning method in the intelligent DSP chip integrated development environment includes the following steps: Construct function call graphs and basic block control flow graphs for software engineering of the target DSP chip, and label the computational density and memory access characteristics of each basic block; Based on ADF files and runtime estimation models, the cost of executing a task on CPU cores, DSP cores, and NPU cores is calculated. Solve the approximate optimization problem in multi-core task mapping and output the task mapping scheme; For critical paths or hotspot areas in the task mapping scheme, optimize and adjust them by using developer manual prompts to override automatic strategies. The distribution script and image layout are generated based on the optimized and adjusted task mapping scheme.

Images