Method for automated generation of interrupt system and related device

Abstract

The application discloses an interrupt system automatic generation method and related equipment, and relates to the technical field of electronic design automation. The method comprises the following steps: in response to an interrupt system automatic generation instruction, a standardized interrupt configuration table filled by a user is acquired; an interrupt parameter extraction operation is performed on the interrupt configuration table to obtain a plurality of groups of interrupt parameters, wherein the interrupt parameters comprise an interrupt number, a trigger type, a domain and a destination; interrupt arbitration logic and a register description file are generated based on the plurality of groups of interrupt parameters; and based on the interrupt arbitration logic and the register description file, the code of each module, a verification file, an integration file and a software-driven interrupt vector table are generated to generate an interrupt system. The application automatically extracts interrupt arbitration logic, a register address mapping relationship and a register description file based on a standardized interrupt configuration table, further automatically generates various files in the interrupt system, and thus automatically generates the interrupt system.

Description

Technical Field

[0001] This application relates to the field of electronic design automation technology, and in particular to a method and related equipment for the automated generation of interrupt systems. Background Technology

[0002] In related technologies, current System-on-Chip (SoC) interrupt systems are becoming increasingly complex, involving numerous design elements such as registers, priority control, and cross-chip routing. Traditional interrupt system development often employs manual coding methods, which presents the following prominent problems: long development cycles, with manual coding and debugging being extremely time-consuming, and later modifications having far-reaching consequences; difficulty in ensuring design consistency, as different modules are written by different engineers, resulting in inconsistent coding styles and logic sources; and low system reliability, with manual implementation prone to logical errors, address conflicts, and other problems, especially in critical paths such as cross-chip interrupts where the risk of failure is high.

[0003] The aforementioned problems result in low development efficiency, high integration risk, and poor maintainability of interrupt systems, making it difficult to meet the high-quality and rapid iteration requirements of complex SoC designs. Therefore, there is an urgent need for a method that can automatically generate interrupt systems to improve design efficiency and ensure consistency and reliability. Summary of the Invention

[0004] The main purpose of this application is to provide an automated method and related equipment for generating interrupt systems, aiming to solve the technical problem of how to automatically generate interrupt systems.

[0005] To achieve the above objectives, this application proposes an automated interrupt system generation method, which includes: In response to the interrupt system's automatic generation instructions, obtain the standardized interrupt configuration form filled in by the user; An interrupt parameter extraction operation is performed on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination; Based on the multiple sets of interrupt parameters, an interrupt arbitration logic and register description file are generated; Based on the interrupt arbitration logic and the register description file, code, verification files, integration files, and software-driven interrupt vector tables for each module are generated to create an interrupt system.

[0006] In one embodiment, the step of performing an interrupt parameter extraction operation on the interrupt configuration table to obtain multiple sets of interrupt parameters further includes: The interrupt configuration table is parsed, and the parameter information of each interrupt channel is extracted row by row to form a structured set of multiple interrupt parameters.

[0007] In one embodiment, the step of parsing the interrupt configuration table, extracting parameter information for each interrupt channel row by row, and forming a structured set of multiple interrupt parameters further includes: The interrupt configuration table is parsed to perform data verification operations on the interrupt configuration table and obtain data verification results. The data verification operations include field integrity verification, interrupt number uniqueness verification, address conflict verification, and domain validity verification. If the verification fails, an error message is generated and fed back to the user so that the user can correct the interrupt configuration table; if the verification passes, the parameter information of each interrupt channel is extracted row by row to form a structured set of multiple interrupt parameters.

[0008] In one embodiment, the step of generating interrupt arbitration logic and register description files based on the multiple sets of interrupt parameters further includes: Based on the multiple sets of interrupt parameters, an interrupt arbitration logic and register address mapping relationship are generated. Based on the aforementioned register address mapping relationship, a register description file is generated.

[0009] In one embodiment, the step of generating a register description file based on the register address mapping relationship further includes: Based on the aforementioned register address mapping relationship, an initial register description file is generated; Based on a preset register description language compiler, the initial register description file is compiled and syntax checked to obtain the check results; If the check result is a compilation failure, adjust the generation logic corresponding to the register description file. Based on the adjusted generation logic, return to the step of generating the initial register description file based on the register address mapping relationship, until the check result is a successful compilation, and obtain the register description file used to build the interrupt system.

[0010] In one embodiment, the step of generating the interrupt system by generating the code, verification file, integration file, and software-driven interrupt vector table for each module based on the interrupt arbitration logic and the register description file further includes: Based on the interrupt arbitration logic and the register description file, synthesizable register transfer level code is generated for each interrupt module. The interrupt module includes a distributed interrupt controller, a pre-distributor, an on-chip interrupt forwarding module, and an inter-chip interrupt forwarding module. Based on the interrupt parameters, a verification file, an integration file, and an interrupt vector table for software driving are generated. An interrupt system is formed based on the synthesizable register-transfer level code, the verification file, the integration file, and the interrupt vector table for software driving.

[0011] Furthermore, to achieve the above objectives, this application also proposes an automated interrupt system generation device, which includes: The acquisition module is used to acquire the standardized interrupt configuration table filled in by the user in response to the automatic generation instruction of the interrupt system. An extraction module is used to perform an interrupt parameter extraction operation on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination. The first generation module is used to generate interrupt arbitration logic and register description files based on the multiple sets of interrupt parameters; The second generation module is used to generate the code, verification file, integration file, and software-driven interrupt vector table of each module based on the interrupt arbitration logic, the register address mapping relationship, and the register description file, so as to generate the interrupt system.

[0012] In addition, to achieve the above objectives, this application also proposes an automated interrupt system generation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the automated interrupt system generation method described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the interrupt system automatic generation method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the interrupt system automatic generation method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application discloses an automated interrupt system generation method and related equipment, relating to the field of electronic design automation technology. Compared to traditional interrupt system development methods that often rely on manual coding, this method suffers from several problems: long development cycles, significant time consumption for manual coding and debugging, and the potential for system-wide disruptions from minor modifications; difficulty in ensuring design consistency, with different modules written by different engineers resulting in inconsistent coding styles and logic sources; and low system reliability, with manual implementation prone to logical errors and address conflicts, especially in critical paths such as cross-chip interrupts where the risk of failure is high. In this application, firstly, in response to an automated interrupt system generation instruction, a standardized interrupt configuration table filled in by the user is obtained. Then, an interrupt parameter extraction operation is performed on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination. Further, based on these multiple sets of interrupt parameters, interrupt arbitration logic and register description files are generated. Finally, based on the interrupt arbitration logic and register description files, code, verification files, integration files, and software-driven interrupt vector tables for each module are generated to create the interrupt system.

[0016] It is understood that this application is based on a standardized interrupt configuration table, automatically extracts interrupt arbitration logic, register address mapping relationship and register description file, and further automatically extracts various files in the interrupt system, thereby realizing the automatic generation of the interrupt system. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating an embodiment of the automated interruption generation method of this application. Figure 2 This is a flowchart illustrating the automated generation process of an interrupt system, as provided in Embodiment 1 of the automated interrupt system generation method of this application. Figure 3 This is a flowchart illustrating Embodiment 2 of the automatic generation method for interrupt systems in this application. Figure 4 This is a schematic diagram of the module structure of the automatic interruption generation device in the embodiments of this application; Figure 5This is a schematic diagram of the device structure of the hardware operating environment involved in the automatic interrupt system generation method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution in this application's embodiments is: In this embodiment, for ease of description, the following description will focus on the automatic generation device of the interrupt system.

[0024] Due to the relevant technologies, traditional interrupt system development often relies on manual coding, which presents the following prominent problems: long development cycles, huge time consumption for manual coding and debugging, and subsequent modifications can have far-reaching consequences; difficulty in ensuring design consistency, with different modules written by different engineers, resulting in inconsistent coding styles and logic sources; and low system reliability, as manual implementation is prone to logical errors, address conflicts, and other problems, especially in critical paths such as cross-chip interrupts where the risk of failure is high.

[0025] This application provides a solution in which: first, in response to an automatic interrupt system generation instruction, a standardized interrupt configuration table filled in by the user is obtained; then, an interrupt parameter extraction operation is performed on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination; further, based on the multiple sets of interrupt parameters, interrupt arbitration logic and register description files are generated; finally, based on the interrupt arbitration logic and the register description files, code, verification files, integration files, and software-driven interrupt vector tables for each module are generated to generate an interrupt system.

[0026] It is understood that this application is based on a standardized interrupt configuration table, automatically extracts interrupt arbitration logic, register address mapping relationship and register description file, and further automatically extracts various files in the interrupt system, thereby realizing the automatic generation of the interrupt system.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or an automated interrupt system generation device capable of performing the above functions. The following description uses an automated interrupt system generation device as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide an automated interrupt system generation method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the automatic generation method for the interrupt system of this application.

[0029] In this embodiment, the automatic generation method for the interrupt system includes steps S10 to S40: Step S10: In response to the interrupt system's automatic generation instruction, obtain the standardized interrupt configuration form filled in by the user; For details, please refer to Figure 2 , Figure 2 This is a flowchart illustrating the automated generation process of the interrupt system provided in Embodiment 1 of the method for automated generation of interrupt systems in this application.

[0030] It should be noted that the interrupt system automated generation instruction refers to the start command triggered by the user or the upper-level script, which is used to instruct the automation tool to start executing the interrupt system generation process.

[0031] It should be noted that a standardized interrupt configuration table refers to configuration information filled in using a uniform template (such as an Excel spreadsheet), which includes fields such as interrupt name, interrupt number (index), merged interrupt number (merged_int_num), trigger type (trigger type), domain (domain), default domain (default_domain), destination (destination), and register base address (intc_reg_base). This table is the single data source for automated processes.

[0032] In this embodiment, after receiving the generation command triggered by the user, the tool reads the standardized configuration table from the specified path, loads it into memory, and prepares it for subsequent parsing. This table is filled in by the user according to the interrupt requirements of the current chip design.

[0033] Step S20: Perform an interrupt parameter extraction operation on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination; It should be noted that the interrupt parameter extraction operation refers to parsing the fields row by row from the standardized table, transforming the text or numerical information in the table into structured data that can be used in subsequent generation logic.

[0034] It should be noted that the interrupt number is a unique identifier for each interrupt, used for interrupt arbitration, routing, and software identification.

[0035] It should be noted that the trigger type refers to the interrupt triggering method, including level triggering or edge triggering.

[0036] It should be noted that a domain refers to the security domain or power domain to which the interrupt belongs, and is used to achieve domain isolation and security control.

[0037] It should be noted that the destination refers to the processing unit to which the interrupt is ultimately sent, such as a core within this chip or a remote core across chips.

[0038] In this embodiment, the tool traverses each row of the interrupt configuration table, extracts key parameters such as interrupt number, trigger type, domain, and destination for each interrupt, and stores them in an internal data structure (such as a hash table or object array). At the same time, it verifies the validity of the fields (such as whether the interrupt number is duplicated and whether the destination is valid).

[0039] Understandably, this step is used to transform the information entered by the user into a structured set of parameters for use in subsequent automated logic generation.

[0040] Specifically, the step of performing an interrupt parameter extraction operation on the interrupt configuration table to obtain multiple sets of interrupt parameters further includes step S21: Step S21: Parse the interrupt configuration table, extract the parameter information of each interrupt channel row by row, and form a structured set of multiple interrupt parameters.

[0041] It should be noted that an interrupt channel refers to an independent interrupt path from the interrupt source (such as a peripheral device or cross-chip interrupt) to the interrupt controller. Each channel corresponds to an independent interrupt signal and has a unique interrupt number (index).

[0042] It should be noted that structuring refers to converting flat, unformatted data in a table (such as row and column text in Excel) into an internal data structure (such as object arrays, dictionaries, and data tables) with clear field names, data types, and hierarchical relationships, so that subsequent program logic can automatically read and process it.

[0043] In this embodiment, after the automated script reads the standardized interrupt configuration table, it performs the following operations: First, identify the table header and establish a mapping relationship between fields such as "interrupt name", "interrupt number (index)", "trigger type (triggertype)", "domain (domain)", "default domain (default_domain)", "destination (destination)", and "register base address (intc_reg_base)" and internal program variables.

[0044] Then, traverse the table row by row, treating each row of data as an interrupt channel, and extract all field values ​​corresponding to that channel.

[0045] Furthermore, the extracted field values ​​are encapsulated according to a predefined data structure (such as a struct, class, or dictionary) to form a complete set of interrupt parameters.

[0046] Finally, combine the parameters of all interrupt channels into a set (such as a list or array) for use in subsequent steps.

[0047] Understandably, this step converts the standardized forms filled out by the user into structured data that the program can directly process, completing the transformation from "design intent" to "machine-readable parameters." This provides clear and reliable data input for subsequent steps such as interrupt arbitration logic, register mapping, and code generation. Row-by-row extraction and structured encapsulation ensure that the parameters of each interrupt channel are complete and independent, facilitating the generation of hardware logic channel by channel. During the extraction process, field existence checks can be performed simultaneously (e.g., whether required fields are empty), identifying omissions in advance and preventing errors from being propagated to downstream processes.

[0048] Specifically, the step of parsing the interrupt configuration table, extracting the parameter information of each interrupt channel row by row, and forming a structured set of multiple interrupt parameters further includes steps S211~S212: Step S211: Parse the interrupt configuration table to perform a data verification operation on the interrupt configuration table and obtain the data verification result. The data verification operation includes field integrity verification, interrupt number uniqueness verification, address conflict verification, and domain validity verification. It should be noted that data validation refers to the automated process of checking the configuration forms filled in by users to find errors, omissions or conflicts in the forms and ensure the correctness and consistency of the input data.

[0049] It should be noted that field integrity verification refers to checking whether all required fields in the table have been filled in, in order to avoid subsequent generation failures or logical errors due to missing key information.

[0050] It should be noted that the interrupt number uniqueness check refers to checking whether there are duplicate interrupt numbers (index) for all interrupt channels, ensuring that each interrupt has a unique identifier, and preventing routing conflicts and software identification confusion.

[0051] It should be noted that address conflict checking refers to checking whether there is overlap in the register address spaces of different interrupt modules or interrupt controllers to avoid hardware access conflicts.

[0052] It should be noted that domain validity verification refers to checking whether the domain configured for each interrupt and the default domain are within the preset set of valid domains, ensuring the validity of the domain isolation configuration.

[0053] In this embodiment, after the tool reads the standardized interrupt configuration table, it performs the following verification logic before extracting parameters row by row: Field integrity check: Traverse each row of the table and check whether key fields such as "interruption number (index)", "interruption name (name)" and "destination (destination)" are empty; if they are empty, record the error message.

[0054] Interruption ID Uniqueness Verification: Collect all entered "interruption IDs" and check for duplicate IDs using a set or hash table; if duplicates are found, record the duplicate ID and its row.

[0055] Address conflict verification: Based on the "register base address (intc_reg_base)" and the required register space of the module, calculate the address range of each interrupt module and check whether there is an overlap of addresses between different modules; if there is an overlap, record the conflicting address and the corresponding module.

[0056] Domain validity check: Compare the "domain" and "default domain" filled in for each interrupt with the preset list of valid domains (such as the list of security domains and power domains defined by the chip architecture); if it is not within the valid range, record the error.

[0057] Finally, all validation results are summarized into a single data validation result (e.g., validation passed / failed, with an error list attached).

[0058] Understandably, a comprehensive check of the input data is necessary before parameter extraction to ensure the accuracy and consistency of the configuration table. Intercepting configuration errors before code generation prevents errors from propagating to RTL code, verification files, and software header files, reducing rework costs. Uniqueness checks and address conflict checks prevent hardware design flaws such as interrupt number conflicts and address overlaps from the outset.

[0059] In step S212, if the verification fails, an error message is generated and fed back to the user so that the user can correct the interrupt configuration table; if the verification passes, the parameter information of each interrupt channel is extracted row by row to form a structured set of multiple interrupt parameters.

[0060] It should be noted that error messages refer to structured prompts that include the error type, error location (such as line number and field name), and error description, which are used to guide users to quickly locate and correct problems in the configuration table.

[0061] It should be noted that providing feedback to the user means presenting error information to the user through command line output, log files, pop-up prompts, or graphical interfaces, so that the user can correct the error and re-execute the automated process.

[0062] It should be noted that, in this embodiment, the tool performs branch processing based on the data verification result obtained in step S211: Verification failed: All error messages collected during the verification process are formatted to generate highly readable error messages. The error messages are output (e.g., printed to the console, written to the error log, or highlighted in the graphical interface), and the subsequent generation process is terminated. After the user corrects the interrupted configuration table based on the error messages, the automated generation command is triggered again, and step S10 is resumed.

[0063] Verification passed: Continue with the line-by-line extraction operation, encapsulating each line of data into a structured interrupt parameter object, forming a set of multiple interrupt parameters for use in subsequent steps (such as interrupt arbitration logic generation and register description file generation).

[0064] Understandably, in this embodiment, the process flow is determined by the verification results, ensuring that only correctly configured data can proceed to the subsequent automated generation stage. Detailed error messages help users accurately locate and identify errors in the configuration table, significantly reducing debugging time. Verification failures are promptly terminated to prevent the generation of invalid or erroneous hardware files based on incorrect data, thus preventing design flaws from spreading downstream. Users can re-execute after correcting the configuration, ensuring that automated generation always starts with correct and complete input, improving overall design quality and efficiency.

[0065] Step S30: Based on the multiple sets of interrupt parameters, generate an interrupt arbitration logic and register description file; It should be noted that interrupt arbitration logic refers to the hardware logic used to handle priority determination, interrupt merging, enable control, and status management when multiple interrupts arrive simultaneously. It is usually implemented in register transfer level (RTL) code.

[0066] It should be noted that a register description file refers to a structured language (such as RDL, SystemRDL, XML) that describes the address mapping, bit field definition, and access attributes of interrupt-related control registers, status registers, enable registers, etc., and is used to generate register transfer level code and software header files.

[0067] In this embodiment, the tool automatically generates the following content based on the extracted interruption parameters: Interrupt arbitration logic: Generates interrupt merging circuit, priority encoding circuit, interrupt enable and status register read / write logic for each interrupt merging point (such as the intc module).

[0068] Register address mapping: Automatically allocate the control register address corresponding to each interrupt based on the register base address and the number of interrupts.

[0069] Register description file: An RDL file is generated based on the address mapping result, and then compiled and syntax checked by the RDL compiler to output an intermediate register description file for use in the generation of subsequent modules.

[0070] Understandably, in this embodiment, the core hardware logic and register descriptions of the interrupt system are automatically generated, replacing the manual writing of RTL and register documentation. This avoids logic errors and address conflicts caused by manual coding. Syntax checks are performed using an RDL compiler to identify design problems early. Register descriptions and hardware logic are generated from the same source, ensuring consistency.

[0071] Step S40: Based on the interrupt arbitration logic and the register description file, generate the code, verification file, integration file, and software-driven interrupt vector table for each module to generate the interrupt system.

[0072] It should be noted that the code of each module refers to the synthesizable RTL code of each sub-module in the interrupt system, including the distributed interrupt controller (intc), the pre-distributor, the on-chip interrupt forwarding module (interrupt controller), and the inter-chip forwarding module (int_to_iic / iic_to_int), etc.

[0073] It should be noted that verification files refer to test cases, assertions, coverage models, etc., used to verify the correctness of the interrupt system, and can be integrated with simulation environments (such as UVM).

[0074] It should be noted that integration files refer to connection files or scripts used to instantiate interrupt modules into the top-level design, such as SystemVerilog instantiation templates, XML integration descriptions, etc.

[0075] It should be noted that the interrupt vector table driven by software refers to the interrupt entry address table or data structure used by software (such as drivers and operating systems) to describe the correspondence between interrupt numbers and interrupt service routines (ISRs).

[0076] In this embodiment, based on the register description intermediate file and interrupt arbitration logic generated in step S30, the tool calls the template engine or code generator to automatically output: synthesizable RTL code for each interrupt module; test files and basic test points for simulation verification; instantiated code or scripts required for top-level integration; and interrupt vector table header files (such as C language header files) for software use. Finally, all generated files are output according to a preset directory structure to form a complete interrupt system deliverable.

[0077] Understandably, in this embodiment, starting from a single configuration table, all hardware, verification, integration, and software files required by the interrupt system are automatically output. This multi-device synchronous generation completely eliminates inconsistencies between hardware, verification, and software. It significantly improves design efficiency, compressing work that previously took several person-weeks to minutes. It reduces verification costs by automatically generating basic verification concerns, allowing the verification team to focus on boundary and abnormal scenarios. Software development is moved forward, enabling the software team to develop in parallel based on the early-generated, behaviorally accurate interrupt vector table and register header files, shortening the project cycle.

[0078] Specifically, the step of generating the interrupt system based on the interrupt arbitration logic and the register description file, including the code, verification file, integration file, and interrupt vector table of each module, further includes steps S41 to S43: Step S41: Based on the interrupt arbitration logic and the register description file, generate synthesizable register transfer level code for each interrupt module. The interrupt module includes a distributed interrupt controller, a pre-distributor, an on-chip interrupt forwarding module, and an inter-chip interrupt forwarding module. It should be noted that synthesizable register-transfer level code refers to RTL code written in hardware description languages ​​(such as Verilog and SystemVerilog) that describes the behavior of digital circuits at the register-transfer level. It can be converted into a gate-level netlist by logic synthesis tools and ultimately used for chip physical implementation.

[0079] It should be noted that the distributed interrupt controller (intc) refers to the interrupt controller located inside each submodule, which is responsible for preprocessing interrupt sources inside and outside the module, including interrupt merging, domain isolation, interrupt enable control, and interrupt status recording.

[0080] It should be noted that the pre-distributor refers to receiving the merged interrupts output from each intc and the remote interrupt status from the inter-chip interrupt forwarding module (iic_to_int), and distributing the interrupts to the interrupt controller of this die or the inter-chip transmission module according to the interrupt number and destination configuration.

[0081] It should be noted that the on-chip interrupt forwarding module (interrupt controller) refers to the interrupt controller located within this die, which receives interrupts forwarded by the pre-distributor and further forwards them to the corresponding core according to the interrupt configuration.

[0082] The inter-die interrupt forwarding module (int_to_iic / iic_to_int) is responsible for forwarding interrupts across dies. int_to_iic encapsulates the interrupt of the local die and sends it to the remote die through the IIC interface. iic_to_int receives the interrupt from the remote die and converts it into a local interrupt status for processing by the pre-distributor.

[0083] In this embodiment, the tool performs the following operations based on the interrupt arbitration logic and register description file generated in step S30: Load the predefined RTL template library, which contains the standard structural framework for each interrupt module (such as module interface definitions, register read / write logic, clock reset handling, etc.). For each interrupt module type (intc, pre_distributor, interrupt controller, int_to_iic, iic_to_int), populate the template according to the interrupt parameters and register description file: The intc module generates interrupt merging circuits based on merged interrupt information, generates read / write logic for enable registers and status registers based on interrupt parameters, and generates domain isolation logic based on domain information.

[0084] The pre_distributor module generates routing table logic based on interrupt number and destination information, generates interrupt distribution control circuitry, and generates remote interrupt status record logic.

[0085] Interrupt controller: Generates interrupt forwarding logic based on interrupt information destined for the local core, and supports configurable interrupt target core selection.

[0086] Inter-die forwarding module: Based on cross-die interrupt information, it generates interrupt packing and unpacking logic and IIC interface control logic.

[0087] Furthermore, the template engine or code generator is invoked to output the populated template as a synthesizable RTL file (such as a .v or .sv file). All generated RTL files are then categorized and stored by module to form a complete hardware code library.

[0088] Understandably, in this embodiment, the interrupt arbitration logic and register description are transformed into hardware RTL code that can be directly used for chip design and logic synthesis. This replaces the original line-by-line writing of RTL code by engineers with automated generation, significantly shortening development time. It also avoids problems such as logic errors, signal connection errors, and bit width mismatches that are prone to occur when writing code manually.

[0089] Step S42: Based on the interrupt parameters, generate a verification file, an integration file, and an interrupt vector table for software driving; It should be noted that the verification file refers to the simulation file used for verifying the interrupt system function, including test cases, assertions, coverage models, register models (such as the UVM register abstraction layer), etc., to help verification engineers quickly build a simulation environment and verify the correctness of the interrupt function.

[0090] It should be noted that integration files refer to auxiliary files used to instantiate interrupt modules into the top-level design, such as SystemVerilog instantiation templates, wiring scripts, XML integration description files, etc., which simplify the integration work at the chip's top level.

[0091] It should be noted that the interrupt vector table used for software drivers refers to the interrupt mapping table used by software (such as drivers and operating system kernels). It is usually provided in the form of a C language header file and contains the correspondence between interrupt numbers and interrupt service routine (ISR) entry addresses, register address macro definitions, bit field definitions, etc.

[0092] In this embodiment, the tool performs the following generation operation based on the interrupt parameters extracted in step S20 and the register description file generated in step A20: Generate verification files: Generate basic test case templates based on interrupt parameters, covering basic functions such as interrupt enabling, interrupt status query, interrupt triggering, and interrupt masking. Generate UVM register models (e.g., .svh files) based on register description files for direct use in the verification environment. Generate assertion files to check the correctness of key logic such as interrupt arbitration, routing, and merging. Generate coverage collection configurations to guide the verification team in covering all interrupt channels for interrupt parameters.

[0093] Generate integration files: Based on interrupt parameters and module definitions, generate a top-level integration template, containing instantiation code for each interrupt module, port connection definitions, clock reset connections, etc. Generate integration scripts (such as Python or Tcl scripts) to automatically integrate interrupt modules into the chip's top-level design. If XML or IP-XACT format is used, generate corresponding integration description files for EDA tools to read automatically.

[0094] Generate an interrupt vector table: Traverse all interrupt channels and extract information such as interrupt number (index) and interrupt name (name). Generate a C language header file containing: interrupt number macro definitions (e.g., #define UART0_IRQ32), register address macro definitions (e.g., #define INTC0_ENABLE_REG0x40010000), and bit field manipulation macros (e.g., #define INTC0_ENABLE_UART0(1<<32)). Generate an interrupt vector table array (e.g., const irq_handler_t irq_vector[]={...}) for use by the interrupt controller driver or startup code.

[0095] Understandably, starting from the same set of interrupt parameters, all necessary supporting files for verification, integration, and software are generated synchronously, enabling multi-terminal collaboration between hardware, verification, and software. Hardware, verification, and software use files generated from the same source, completely eliminating inconsistencies caused by manually maintaining multiple files.

[0096] Step S43: Based on the synthesizable register-transfer level code, the verification file, the integration file, and the interrupt vector table for software driving, an interrupt system is formed.

[0097] It should be noted that forming an interrupt system refers to organizing and packaging all the files generated in steps S41 and S42 according to a predetermined directory structure to form a complete interrupt system deliverable, which can be directly used by the chip design team, verification team, and software team. The deliverable includes hardware RTL code, verification environment files, top-level integration files, software driver header files, etc.

[0098] In this embodiment, after generating all files, the tool outputs all generated files to a specified path according to a pre-defined directory structure. A design report (such as a .txt or .pdf file) is generated, summarizing key design information for easy user review and subsequent maintenance. Upon completion, a complete interrupt system design package is formed, ready for direct delivery to downstream teams.

[0099] In essence, all automatically generated files are organized into a complete, deliverable interrupt system design package, achieving end-to-end automation from configuration tables to the complete interrupt system. Users no longer need to manually organize scattered generated files, directly obtaining a complete, usable interrupt system. The standardized directory structure and design reports facilitate quick team adoption and use, reducing communication and organization costs.

[0100] This application discloses an automated interrupt system generation method and related equipment, relating to the field of electronic design automation technology. Compared to traditional interrupt system development methods that often rely on manual coding, this method suffers from several problems: long development cycles, significant time consumption for manual coding and debugging, and the potential for system-wide disruptions from minor modifications; difficulty in ensuring design consistency, with different modules written by different engineers resulting in inconsistent coding styles and logic sources; and low system reliability, with manual implementation prone to logical errors and address conflicts, especially in critical paths such as cross-chip interrupts where the risk of failure is high. In this application, firstly, in response to an automated interrupt system generation instruction, a standardized interrupt configuration table filled in by the user is obtained. Then, an interrupt parameter extraction operation is performed on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination. Further, based on these multiple sets of interrupt parameters, interrupt arbitration logic and register description files are generated. Finally, based on the interrupt arbitration logic and register description files, code, verification files, integration files, and software-driven interrupt vector tables for each module are generated to create the interrupt system.

[0101] It is understood that this application is based on a standardized interrupt configuration table, automatically extracts interrupt arbitration logic, register address mapping relationship and register description file, and further automatically extracts various files in the interrupt system, thereby realizing the automatic generation of the interrupt system.

[0102] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 The step of generating interrupt arbitration logic and register description files based on the multiple sets of interrupt parameters further includes steps A10 to A20: Step A10: Based on the multiple sets of interrupt parameters, generate the interrupt arbitration logic and register address mapping relationship; It should be noted that interrupt arbitration logic refers to the hardware circuit logic used to handle the priority determination, interrupt merging, interrupt enable control, and interrupt status recording when multiple interrupt sources request interrupts simultaneously. It is usually implemented in register transfer level (RTL) code form.

[0103] It should be noted that the register address mapping relationship refers to the process of assigning a unique physical address to each interrupt control register (such as interrupt enable register, interrupt status register, interrupt priority register, etc.), determining the offset of each register relative to the module base address, and forming an address allocation table.

[0104] In this embodiment, the tool performs the following generation operation based on the multiple sets of interrupt parameters extracted in step S20: The system generates interrupt arbitration logic: Based on the interrupt merging information (merged_int_num), an interrupt merging circuit is generated for each intc module to merge multiple interrupt sources into a single merged interrupt output. Priority encoding logic is generated for each interrupt channel, supporting configurable priority arbitration (such as fixed priority or polling priority). Read / write control logic for the interrupt enable register and interrupt status register is generated, enabling software to dynamically enable / disable interrupts and query interrupt status. Isolation logic is generated for interrupts from different domains based on domain information, ensuring correct handling and safe isolation of cross-domain interrupts. Interrupt routing logic is generated based on destination information, directing interrupts to the core of this die or the int_to_iic module across dies.

[0105] Generate register address mappings: Traverse all interrupt channels and their corresponding register requirements (e.g., each interrupt requires at least an enable register and a status register). Based on the preset register bit width (e.g., 32 bits) and register organization method (e.g., one group of registers for every 32 interrupts), automatically calculate the offset of each register relative to the module base address. Generate an address mapping table, explicitly recording the base address of each interrupt controller, the offset address of each register, and the correspondence between each field in each register and the interrupt channel.

[0106] Understandably, in this embodiment, interrupt parameters are transformed into specific hardware logic structures and address allocation schemes, laying the foundation for subsequent register description file generation and RTL code generation. Arbitration logic and address mappings are automatically generated, eliminating logical errors and address conflicts that are prone to occur when manually writing RTL. The arbitration logic and address mappings of all interrupt modules are generated based on the same set of parameters, ensuring consistent style and behavior across different modules.

[0107] Step A20: Generate a register description file based on the register address mapping relationship.

[0108] It should be noted that a register description file is a file written in a structured language (such as SystemRDL, IP-XACT, XML, etc.) to describe in detail the addresses, bit field definitions, access attributes (read / write / read-write / read-only / write-only, etc.), reset values, and field meanings of all registers in the interrupt system. This file is both part of the hardware design and a direct input for software driver development.

[0109] In this embodiment, the tool performs the following operations based on the register address mapping relationship generated in step A10: Select a predefined register description template (such as a SystemRDL template), which contains standard register structure definition syntax. Iterate through each register in the address mapping table, filling its name, base address, offset address, bit width, and other information into the template. For each bit field within a register, generate the bit field definition based on the interrupt parameters. Interrupt Enable Register: Each bit corresponds to an interrupt channel and describes the enable control function of that bit.

[0110] Interrupt Status Register: Each bit corresponds to an interrupt channel and describes the interrupt status query function of that bit.

[0111] Priority register: Allocates corresponding priority bit fields according to the number of interrupts.

[0112] Domain control register: Generates the domain selection bit field based on the domain information.

[0113] Furthermore, set the access attributes (e.g., enable register for read / write, status register for read-only) and reset values ​​(e.g., enable register reset value is 0, status register reset value is 0).

[0114] Finally, a complete register description file (such as a .rdl file) is output for subsequent compilation and syntax checking by the RDL compiler.

[0115] It is understood that in this embodiment, the register address mapping relationship is converted into a standard format register description file to achieve unified management and reuse of register information.

[0116] Specifically, the step of generating a register description file based on the register address mapping relationship further includes steps A21 to A23: Step A21: Generate an initial register description file based on the register address mapping relationship; It should be noted that the initial register description file refers to the register description file generated for the first time based on the register address mapping relationship, and has not yet been compiled and verified. This file is written in a structured description language (such as SystemRDL, IP-XACT, etc.) and contains information such as register addresses, bit field definitions, access attributes, and reset values, but may contain syntax errors or incompatibility issues with compiler requirements.

[0117] In this embodiment, the tool performs the following operations based on the register address mapping relationship generated in step A10: Load a predefined register description template (such as a SystemRDL template), which contains the basic framework including a file header, namespace, and register structure definition. Iterate through each register in the address mapping table, filling the template with information such as register name, base address, offset address, and bit width. Generate specific definitions for the bit fields within each register. Interrupt enable register: Generates a corresponding enable bit field for each interrupt channel.

[0118] Interrupt status register: Generates a corresponding status bit field for each interrupt channel.

[0119] Priority register: Generates the corresponding priority bit field based on the number of interrupts.

[0120] Domain control register: Generates the corresponding domain selection bit field based on the domain information.

[0121] Configure the access attributes (such as read_write, read_only) and reset value for each register and each bit field. Output the filled content as an initial register description file (such as a .rdl file) for use in the next compilation step.

[0122] Understandably, this step transforms the register address mapping into a preliminary register description file that can be recognized by the compiler, thus realizing the transformation from "address allocation" to "standardized description".

[0123] Step A22: Based on the preset register description language compiler, the initial register description file is compiled and syntax checked to obtain the check results; It should be noted that the pre-built register description language compiler refers to a compiler (such as the SystemRDL compiler or IP-XACT parser) that is pre-integrated into the automation toolchain. It is used to perform syntax analysis, semantic checks, and integrity verification on register description files, and can identify problems such as syntax errors, missing fields, and type mismatches in the files.

[0124] It should be noted that the check result refers to the compilation status output by the compiler, which usually includes "compilation successful" or "compilation failed", and provides detailed error information (such as error line number, error type, and error description) when compilation fails.

[0125] In this embodiment, after the tool generates the initial register description file in step A21, it automatically calls the preset register description language compiler to perform the following operations: The initial register description file is passed as input to the compiler. The compiler performs lexical analysis, syntax analysis, and semantic analysis on the file, checking: Does the grammar conform to the standards (e.g., is the keyword spelling correct, and is the nesting of structures correct)?

[0126] Are the fields complete (e.g., required address, bit width, and access attributes are missing)?

[0127] Check if the data types match (e.g., whether the address range is within a valid range).

[0128] Is the reference valid (e.g., does a cross-register reference exist)?

[0129] The compiler outputs the check results: if the file is correct, it returns "Compilation successful"; if there are errors, it returns "Compilation failed" with error details.

[0130] Understandably, a standardized compiler automatically verifies the initial register description file to ensure it conforms to specifications, has correct syntax, and is logically complete. Before the register description file enters downstream code generation, the compiler intercepts syntax errors and specification issues. Only files that pass compilation can be used in subsequent RTL generation, software header file generation, and other stages, ensuring the correctness of downstream input.

[0131] Step A23: If the check result is compilation failure, adjust the generation logic corresponding to the register description file. Based on the adjusted generation logic, return to the step of generating the initial register description file based on the register address mapping relationship, until the check result is compilation success, and obtain the register description file used to build the interrupt system.

[0132] It should be noted that adjusting the generation logic of the register description file refers to modifying the template, padding rules, or parameter configurations used when generating the initial register description file based on the error information returned by the compiler, in order to resolve the problems causing compilation failures. The adjustments may include correcting template syntax errors, adding missing fields, adjusting bit field definitions, and modifying access attribute values, etc.

[0133] It should be noted that the register description file used to build the interrupt system refers to the final version of the register description file that has been compiled, verified, and confirmed to be error-free, and can serve as a reliable input for subsequent steps (such as RTL code generation, software header file generation, and verification model generation).

[0134] In this embodiment, the tool performs branching processing based on the inspection results obtained in step A22: If the check results in compilation failure: Analyze the error information returned by the compiler, extracting the error type, error location (e.g., line number, field name), and error description. Based on the error type, locate the corresponding step in the generation logic: if it's a template syntax error, correct the template file. If it's a missing field, adjust the padding logic to add the missing field. If it's a data type mismatch, correct the bit width calculation or field assignment method. If it's an invalid reference, check if the reference in the address mapping relationship is accurate. After completing the adjustments, automatically return to step A21, and regenerate the initial register description file based on the adjusted generation logic. Repeat steps A21 and A22, forming a loop, until compilation succeeds.

[0135] If the check result indicates successful compilation: mark the current version of the register description file as "Register description file for building interrupt systems" and output it to the specified directory for use in subsequent steps.

[0136] Understandably, establishing a closed-loop correction mechanism, through automatic iterative adjustments to the generation logic, ensures that the final output register description file passes compilation verification and achieves deliverable quality. By analyzing compiler feedback and automatically adjusting the generation logic, manual intervention is reduced, increasing the degree of process automation. Through iterative verification until successful compilation, the final file is ensured to be completely correct at the syntactic and specification levels, preventing errors from being propagated downstream.

[0137] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the automatic generation method of the interrupt system in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0138] This application also provides an automated interrupt generation device; please refer to [reference needed]. Figure 4 The automatic interruption system generation device includes: The acquisition module 10 is used to acquire the standardized interrupt configuration table filled in by the user in response to the automatic generation instruction of the interrupt system. Extraction module 20 is used to perform an interrupt parameter extraction operation on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination; The first generation module 30 is used to generate an interrupt arbitration logic and register description file based on the multiple sets of interrupt parameters. The second generation module 40 is used to generate the code, verification file, integration file, and software-driven interrupt vector table of each module based on the interrupt arbitration logic, the register address mapping relationship, and the register description file, so as to generate the interrupt system.

[0139] In one embodiment, the extraction module further includes: The first parsing unit is used to parse the interrupt configuration table, extract the parameter information of each interrupt channel row by row, and form a structured set of multiple interrupt parameters.

[0140] In one embodiment, the extraction module further includes: The second parsing unit is used to parse the interrupt configuration table to perform data verification operations on the interrupt configuration table and obtain data verification results. The data verification operations include field integrity verification, interrupt number uniqueness verification, address conflict verification, and domain validity verification. The correction unit is used to generate an error message and feed it back to the user if the verification fails, so that the user can correct the interrupt configuration table; if the verification passes, it extracts the parameter information of each interrupt channel row by row to form a structured set of multiple interrupt parameters.

[0141] In one embodiment, the first generation module further includes: The first generation unit is used to generate an interrupt arbitration logic and register address mapping relationship based on the multiple sets of interrupt parameters; The second generation unit is used to generate a register description file based on the register address mapping relationship.

[0142] In one embodiment, the first generation module further includes: The third generation unit is used to generate an initial register description file based on the register address mapping relationship; The checking unit is used to compile and perform syntax checks on the initial register description file based on a preset register description language compiler, and obtain the check results. The fourth generation unit is used to adjust the generation logic corresponding to the register description file if the check result is a compilation failure, and based on the adjusted generation logic, return to the step of generating an initial register description file based on the register address mapping relationship, until the check result is a compilation success, and obtain the register description file used to build the interrupt system.

[0143] In one embodiment, the second generation module further includes: The fifth generation unit is used to generate synthesizable register-transfer level code for each interrupt module based on the interrupt arbitration logic and the register description file. The interrupt module includes a distributed interrupt controller, a pre-distributor, an intra-chip interrupt forwarding module, and an inter-chip interrupt forwarding module. The sixth generation unit is used to generate a verification file, an integration file, and an interrupt vector table for software driving based on the interrupt parameters. A forming unit is used to form an interrupt system based on the synthesizable register-transfer level code, the verification file, the integration file, and the interrupt vector table for software driving.

[0144] The interrupt system automated generation apparatus provided in this application, employing the interrupt system automated generation method in the above embodiments, can solve the technical problem of automated interrupt system generation. Compared with related technologies, the beneficial effects of the interrupt system automated generation apparatus provided in this application are the same as those of the interrupt system automated generation method provided in the above embodiments, and other technical features in the interrupt system automated generation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0145] This application provides an automated interrupt system generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the automated interrupt system generation method in Embodiment 1 above.

[0146] The following is for reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing an automated interrupt system generation device according to embodiments of this application. The automated interrupt system generation device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The interrupt system automated generation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0147] like Figure 5As shown, the interrupt system automation generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the interrupt system automation generation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the interrupt system automation generation device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows an interrupt system automation generation device with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0148] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0149] The interrupt system automated generation device provided in this application, employing the interrupt system automated generation method in the above embodiments, can solve the technical problem of automated interrupt system generation. Compared with related technologies, the beneficial effects of the interrupt system automated generation device provided in this application are the same as those of the interrupt system automated generation method provided in the above embodiments, and other technical features in this interrupt system automated generation device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0150] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0151] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0152] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the interrupt system automatic generation method in the above embodiments.

[0153] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0154] The aforementioned computer-readable storage medium may be included in the interrupt system automation generation device; or it may exist independently and not assembled into the interrupt system automation generation device.

[0155] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the interrupt system automation generation device, cause the interrupt system automation generation device to: In response to the interrupt system's automatic generation instructions, obtain the standardized interrupt configuration form filled in by the user; An interrupt parameter extraction operation is performed on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination; Based on the multiple sets of interrupt parameters, an interrupt arbitration logic and register description file are generated; Based on the interrupt arbitration logic and the register description file, code, verification files, integration files, and software-driven interrupt vector tables for each module are generated to create an interrupt system.

[0156] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0157] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0158] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0159] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described automated interrupt system generation method, thereby solving the technical problem of automated interrupt system generation. Compared with related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the automated interrupt system generation method provided in the above embodiments, and will not be repeated here.

[0160] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described automatic interrupt system generation method.

[0161] The computer program product provided in this application can solve the technical problem of automated interrupt system generation. Compared with related technologies, the beneficial effects of the computer program product provided in this application are the same as those of the automated interrupt system generation method provided in the above embodiments, and will not be repeated here.

[0162] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A method for automated generation of an interruption system, characterized in that The automated interrupt system generation method includes: In response to the interrupt system's automatic generation instructions, obtain the standardized interrupt configuration form filled in by the user; An interrupt parameter extraction operation is performed on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination; Based on the multiple sets of interrupt parameters, an interrupt arbitration logic and register description file are generated; Based on the interrupt arbitration logic and the register description file, code, verification files, integration files, and software-driven interrupt vector tables for each module are generated to create an interrupt system.

2. The automated generation of interruption system method of claim 1, wherein, The step of performing an interrupt parameter extraction operation on the interrupt configuration table to obtain multiple sets of interrupt parameters further includes: The interrupt configuration table is parsed, and the parameter information of each interrupt channel is extracted row by row to form a structured set of multiple interrupt parameters.

3. The automated generation of interruption system method of claim 2, wherein, The step of parsing the interrupt configuration table, extracting parameter information for each interrupt channel row by row, and forming multiple sets of structured interrupt parameters further includes: The interrupt configuration table is parsed to perform data verification operations on the interrupt configuration table and obtain data verification results. The data verification operations include field integrity verification, interrupt number uniqueness verification, address conflict verification, and domain validity verification. If the verification fails, an error message is generated and fed back to the user so that the user can correct the interrupt configuration table; if the verification passes, the parameter information of each interrupt channel is extracted row by row to form a structured set of multiple interrupt parameters.

4. The automated generation of interruption system method of claim 1, wherein, The step of generating interrupt arbitration logic and register description files based on the multiple sets of interrupt parameters further includes: Based on the multiple sets of interrupt parameters, an interrupt arbitration logic and register address mapping relationship are generated. Based on the aforementioned register address mapping relationship, a register description file is generated.

5. The automatic generation method for interrupt systems as described in claim 4, characterized in that, The step of generating a register description file based on the register address mapping relationship further includes: Based on the aforementioned register address mapping relationship, an initial register description file is generated; Based on a preset register description language compiler, the initial register description file is compiled and syntax checked to obtain the check results; If the check result is a compilation failure, adjust the generation logic corresponding to the register description file. Based on the adjusted generation logic, return to the step of generating the initial register description file based on the register address mapping relationship, until the check result is a successful compilation, and obtain the register description file used to build the interrupt system.

6. The automatic generation method for an interrupt system as described in claim 1, characterized in that, The step of generating the interrupt system based on the interrupt arbitration logic and the register description file, including the code, verification file, integration file, and interrupt vector table of each module, further includes: Based on the interrupt arbitration logic and the register description file, synthesizable register transfer level code is generated for each interrupt module. The interrupt module includes a distributed interrupt controller, a pre-distributor, an on-chip interrupt forwarding module, and an inter-chip interrupt forwarding module. Based on the interrupt parameters, a verification file, an integration file, and an interrupt vector table for software driving are generated. An interrupt system is formed based on the synthesizable register-transfer level code, the verification file, the integration file, and the interrupt vector table for software driving.

7. An automated interrupt generation device, characterized in that, The automated interruption system generation device includes: The acquisition module is used to acquire the standardized interrupt configuration table filled in by the user in response to the automatic generation instruction of the interrupt system. An extraction module is used to perform an interrupt parameter extraction operation on the interrupt configuration table to obtain multiple sets of interrupt parameters, including interrupt number, trigger type, domain, and destination. The first generation module is used to generate interrupt arbitration logic and register description files based on the multiple sets of interrupt parameters; The second generation module is used to generate the code, verification file, integration file, and software-driven interrupt vector table of each module based on the interrupt arbitration logic, the register address mapping relationship, and the register description file, so as to generate the interrupt system.

8. An automated interrupt generation device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the interrupt system automated generation method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the automatic generation method for the interrupt system as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the interrupt system automated generation method as described in any one of claims 1 to 6.

Images