A method and terminal for automated code generation of FPGA components

Abstract

This application belongs to the field of FPGA technology and relates to an automated FPGA component code generation method and terminal. The invention replaces the manual writing of traditional hardware description languages ​​by defining FPGA application components with interfaces, creating component instances with configuration logic information, and establishing port connections, enabling non-professionals to participate in development. Then, based on the Eclipse PDE configuration trigger mechanism, the model information is collected through action execution classes and the generator is called to automatically create projects, generate configuration files, and complete placeholder replacement, realizing the automated conversion from modeling to code. This avoids the burden of detailed descriptions written manually and errors caused by human negligence, improves development efficiency, and reduces debugging costs. Furthermore, the unified modeling specifications and generation process replace various tools and specifications, ensuring development consistency to improve collaboration efficiency and facilitate subsequent maintenance and iteration. At the same time, it solves the defect of existing visualization tools that can only display but cannot automatically convert code.

Description

Technical Field

[0001] This application belongs to the field of FPGA technology, and more specifically, relates to a method and terminal for automatically generating FPGA component code. Background Technology

[0002] Field-programmable gate arrays (FPGAs) have been widely used in many fields such as communications, industrial control, and aerospace due to their reconfigurability and high performance. The generation of FPGA component code is a core part of the FPGA development process, which directly affects development efficiency and product quality.

[0003] Currently, the mainstream method for generating code for FPGA components mainly relies on manual writing of hardware description languages ​​(such as VHDL, Verilog, etc.). This method requires developers to have a deep understanding of the underlying hardware structure of the FPGA and implement the circuit function design line by line through the hardware description language. It is a relatively mature technical solution in the industry at present.

[0004] However, the aforementioned existing technical solutions have many shortcomings that urgently need to be addressed: First, the professional threshold is high. Hardware description languages ​​have unique syntax structures and significantly different ways of thinking compared to general programming languages. Developers need to have in-depth FPGA expertise and rich experience in using the language, requiring a significant investment of time to learn and master. This makes it difficult for developers without an FPGA background to participate in related development work. Second, development efficiency is low and the error rate is high. Manually writing hardware description languages ​​requires detailed descriptions of each circuit module and port logic, which is not only time-consuming and laborious but also prone to syntax errors or logical vulnerabilities due to human error, resulting in high costs for subsequent debugging and correction. Finally, the development process lacks consistency. Currently, there are various FPGA component design tools and manual writing specifications on the market. Different projects or teams may adopt different design approaches and toolchains, resulting in a lack of unified standards in the development process. This significantly affects team collaboration efficiency and is also detrimental to the subsequent maintenance and iterative upgrades of the project.

[0005] Furthermore, while some visualization modeling tools exist in existing technologies, they are mostly used only for graphical representation of circuit structures and cannot be deeply integrated with the FPGA code generation process. This makes it difficult to achieve automated conversion from modeling to code, still requiring developers to manually convert the modeling results into hardware description language code, thus failing to fundamentally solve the aforementioned shortcomings. Therefore, developing an FPGA component code generation technology that can lower the professional threshold, improve development efficiency, and ensure process consistency has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0006] This invention provides a method and terminal for automated generation of FPGA component code, which aims to solve the technical problems mentioned in the background section.

[0007] An automated code generation method for FPGA components includes the following steps: Visual modeling of FPGA components: Define FPGA application components, each with an interface to support the creation of logic device ports; create FPGA application component instances in the component structure diagram based on the FPGA application components; associate each FPGA application component instance with a corresponding FPGA application component and configure the logic addresses required for code generation; establish the connection relationship between the logic device ports of different FPGA application component instances in the component structure diagram through wiring; Automatic generation of FPGA component code: Based on Eclipse PDE technology, configure the code generation trigger mechanism, specify the action execution class to trigger the code generation process; collect and store the FPGA component model information obtained from visual modeling through the action execution class; call the code generator, create an FPGA project based on the collected model information, generate a project configuration file with placeholders, replace the placeholders and complete the storage of the project file, thus realizing automated code generation.

[0008] This invention replaces the traditional manual writing of hardware description languages ​​by defining FPGA application components with interfaces, creating component instances with configuration logic information, and establishing port connections. This eliminates the need for developers to have in-depth knowledge of the underlying hardware structure and unique syntax, significantly lowering the professional threshold and enabling non-professionals to participate in development. Then, based on the Eclipse PDE configuration trigger mechanism, it collects model information through action execution classes and calls the generator to automatically create projects, generate configuration files, and complete placeholder replacements, achieving automated conversion from modeling to code. This avoids the burden of detailed manual descriptions and errors caused by human error, improving development efficiency and reducing debugging costs. Furthermore, the unified modeling specifications and generation process replace diverse tools and standards, ensuring development consistency to improve collaboration efficiency and facilitate subsequent maintenance and iteration. It also addresses the deficiency of existing visualization tools that can only display but cannot automatically convert code. Overall, it achieves the effects of lowering the threshold, improving efficiency and quality, and ensuring process consistency, thus optimizing the entire FPGA development process.

[0009] Preferably, the FPGA application component inherits the StructuralRealization interface and the SCANamedElement interface of the SCA architecture. By inheriting the above interfaces, the FPGA application component adapts to the SCA architecture, enhancing the SCA framework's ability to manage dynamically configurable FPGA resources. The interface provided by the FPGA application component is BuildInAppCompInterface. The logic device ports are divided into providing ports and using ports according to their functions.

[0010] Preferably, the logical device port inherits the ConjugatedPort interface and the SCANamedElement interface of the SCA architecture; wherein the ConjugatedPort interface supports the definition of port supply and demand relationships; and the SCANamedElement interface implements port naming management. The logical device port also defines the refportName and refPortType attributes, which are used to identify the port name and port type, respectively.

[0011] Preferably, the FPGA application component instance inherits the preset BuildInAppCompPart interface; The BuildInAppCompPart interface inherits the SCANamedElement interface and predefines the LogicDest property corresponding to the logical address. The FPGA application component instance and the AssemblyComponent component have a UML composition relationship, and the AssemblyComponent component manages the lifecycle of the FPGA application component instance.

[0012] Preferably, the connection used to establish the connection relationship is a semantically neutral FreeConnection connection. This connection only graphically displays the connection direction and relationship between ports, does not participate in modeling semantic verification, and does not affect the generation of the original code and descriptor.

[0013] Preferably, the configuration of the code generation triggering mechanism includes: Define the core extension points of the Navigator extension mechanism, and customize the element styles of the resource manager and CNF view through the defined core extension points, and bind code to generate actions and icons; The action execution class is FPGAGenerateActionProvider, which inherits the CommonActionProvider class from Eclipse PDE technology.

[0014] Preferably, the callback method of the action execution class is triggered by the right-click menu option of the FPGA component model element to start the model information collection process.

[0015] Preferably, the code generator is an FPGAGenerator; the project configuration file is an xpr file; the code generator creates an FPGA project using the prepareProject method and predefines a project structure including a top-level module, port declarations, and a clock management module; the key parameters of the xpr file are represented in placeholder form, and the key parameters include the project name, logical address, and port configuration information.

[0016] Preferably, the data set storing model information is FPGAList, and the information stored in FPGAList includes the identification information of FPGA application components, the logical address information of FPGA application components, and the port name, type, and supply and demand attribute information of the logical device ports.

[0017] An FPGA component code automated generation terminal executes the FPGA component code automated generation method described in this invention. It includes a visual modeling module and a code generation module. The visual modeling module provides a visual editing interface, supports the definition of FPGA application components, the creation of FPGA application component instances and the establishment of port connection relationships, and stores modeling information. The code generation module integrates action execution classes and code generators to perform trigger mechanism configuration, information collection, and project file generation operations.

[0018] The beneficial effects of this invention include: This invention replaces the traditional manual writing of hardware description languages ​​by defining FPGA application components with interfaces, creating component instances with configuration logic information, and establishing port connections. This eliminates the need for developers to have in-depth knowledge of the underlying hardware structure and unique syntax, significantly lowering the professional threshold and enabling non-professionals to participate in development. Then, based on the Eclipse PDE configuration trigger mechanism, it collects model information through action execution classes and calls the generator to automatically create projects, generate configuration files, and complete placeholder replacements, achieving automated conversion from modeling to code. This avoids the burden of detailed manual descriptions and errors caused by human error, improving development efficiency and reducing debugging costs. Furthermore, the unified modeling specifications and generation process replace diverse tools and standards, ensuring development consistency to improve collaboration efficiency and facilitate subsequent maintenance and iteration. It also addresses the deficiency of existing visualization tools that can only display but cannot automatically convert code. Overall, it achieves the effects of lowering the threshold, improving efficiency and quality, and ensuring process consistency, thus optimizing the entire FPGA development process. Attached Figure Description

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

[0020] Figure 1 A diagram showing the relationship between FPGAAppComp components and interfaces provided for embodiments of the present invention.

[0021] Figure 2 An example configuration diagram of FPGAAppCompPart provided for an embodiment of the present invention.

[0022] Figure 3 The component structure diagram and FreeConnection connection diagram provided for embodiments of the present invention.

[0023] Figure 4 This is a schematic diagram of the overall process provided for an embodiment of the present invention.

[0024] Figure 5 An inheritance diagram of the FPGAAppComp and LogicDevicePort interfaces provided for embodiments of the present invention.

[0025] Figure 6 A diagram showing the inheritance and combination relationships of the FPGAAppCompPart interface provided for embodiments of the present invention. Detailed Implementation

[0026] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0027] Example 1 See appendix Figures 1 to 6As shown, an automated FPGA component code generation method is presented, which is divided into an FPGA component visualization modeling module and an FPGA component code automation generation module. The two modules work together through a data interaction interface: the visualization modeling module receives graphical operations from the user and generates standardized FPGA component model information, while the code automation generation module reads the model information and generates directly usable FPGA projects and code files through preset project templates and replacement logic; the entire architecture is based on an extended design of the SCA (Software Communication Architecture) architecture, adapting to the management requirements of dynamically configurable FPGA resources, and at the same time, relying on Eclipse PDE (Plugin Development Environment) technology to achieve seamless integration with mainstream development environments, improving user convenience.

[0028] like Figure 4 As shown, the specific steps include: Visual modeling of FPGA components: The complex hardware logic of FPGA components is transformed into intuitive graphical components and interfaces that users can operate. Standardized interface definitions and instance configurations eliminate the professional barriers of hardware description languages. In this embodiment, the modeling process is completed using a custom graphical editor within the Eclipse environment. Specifically: To enable FPGA components to adapt to the standardized management capabilities of the SCA architecture, this implementation first defines an FPGA application component (FPGAAppComp) and makes it inherit the StructuralRealization interface and ScanamedElement interface of the SCA architecture, such as... Figure 1 As shown, the core components of FPGAAppComp are intuitively presented using a UML class diagram—components depend on the Linux operating system and the Processor, and are associated with the LogicDevicePort (providing / using the port) by implementing the BuildInAppCompInterface interface, demonstrating the hierarchical relationship of component-interface-port-dependent environment; for example... Figure 5 As shown, the interface inheritance system is further broken down, clarifying that FPGAAppComp achieves communication and hardware decoupling by inheriting the StructuralRealization interface, and achieves unique identification by inheriting the SCANamedElement interface. LogicDevicePort supports bidirectional communication by inheriting the ConjugatedPort interface. The refPortName and refPortType attributes marked in the figure also explain the implementation of the port identification.

[0029] The StructuralRealization interface is the core paradigm for decoupling communication functions from the hardware platform in the SCA architecture. By inheriting this interface, the hardware logic functions of the FPGA can be transformed into software services under the SCA framework, supporting dynamic configuration and function expansion. The SCANamedElement interface is the core mechanism for unique element identification in the SCA architecture. By inheriting this interface, it can be ensured that each FPGA application component has a unique name in the entire architecture, avoiding component conflicts and improving cross-platform collaboration capabilities.

[0030] To support communication between FPGA components and external devices, a built-in interface BuildInAppCompInterface is defined on FPGAAppComp. This interface is specifically used to create logic device ports. Logic device ports are divided into provide ports and use ports according to their functions. Provide ports are used to expose the service capabilities of FPGA components (such as data processing services), while use ports are used to call the services of other components (such as clock signal reception). This clarifies the supply and demand relationship between components and provides a clear logical basis for subsequent port connections.

[0031] When defining FPGAAppComp, it is necessary to configure its dependent operating system (Linux embedded operating system is selected in this embodiment) and processor (ARM Cortex-A9 processor is selected in this embodiment) to bind the FPGA component's operating environment and ensure that the generated code can be adapted to the target hardware platform, thus avoiding secondary development for environment adaptation in the later stage.

[0032] In this embodiment, the defined FPGAAppComp is specifically a data acquisition FPGA component. Its provided port is a data output port (Provides type), and its used port is a clock input port (Uses type). The operating system it relies on is Linux 5.4, and the processor is ARM Cortex-A9. The component name is defined as DataAcquisition_FPGAAppComp through the SCANamedElement interface to ensure uniqueness.

[0033] The LogicDevicePort is the core unit for interaction between FPGA components and the outside world. To achieve bidirectional communication capability and compatibility with the SCA architecture, this implementation is designed to inherit the ConjugatedPort interface and ScanamedElement interface of the SCA architecture, as follows: Traditional SCA ports are mostly unidirectional communication, while the ConjugatedPort interface provides a reverse binding mechanism. By inheriting this interface, LogicDevicePort can support the dynamic establishment of bidirectional communication links, meeting the bidirectional requirements of data transmission and status feedback between FPGA components and external devices. Inheriting the SCANamedElement interface ensures that each LogicDevicePort has a unique name within the component, avoiding port confusion.

[0034] Two core attributes are defined in LogicDevicePort: refportName and refPortType. refportName identifies the specific name of the port (e.g., Clock_In_01), and refPortType identifies the signal type of the port (e.g., LVDS, CMOS). Through these explicit attribute identifiers, the code generator can accurately identify the port's function and hardware characteristics, ensuring that the generated port configuration code meets hardware requirements.

[0035] This implementation configures two LogicDevicePorts for the data acquisition FPGA component: one is the Clock_In_01 port with refPortType set to LVDS, used to receive external clock signals; the other is the Data_Out_01 port with refPortType set to CMOS, used to output the acquired data.

[0036] FPGA application component instances are key to transforming FPGAAppComp from an abstract definition into an assembleable entity. This implementation achieves instantiation by defining the FPGAAppCompPart interface. The instance configuration process is described in [reference needed]. Figure 2 The instance's two core configuration items—Definition—are used to associate the FPGAAppComp component prototype, and LogicDest is used to configure the logic address. The naming rules and attribute editing entry points marked in the diagram also provide guidance for actual operation; while the instance's interface inheritance and lifecycle management logic are... Figure 6 The BuildInAppCompPart inherits the ScanamedElement interface and defines the LogicDest attribute. The FPGAAppCompPart, inheriting this interface, gains address storage capabilities. Simultaneously, through the UML composition relationship with the AssemblyComponent (represented by "1 includes 0..1" in the diagram), the AssemblyComponent manages the entire lifecycle of the instance. The version, description, and other attributes of the AssemblyComponent in the diagram also reflect the standardized management characteristics of the SCA architecture. Based on the above design, the standardization and controllability of the instantiation process are guaranteed, as detailed below: FPGAAppCompPart inherits the default BuildInAppCompPart interface, which in turn inherits the SCANamedElement interface and predefines the LogicDest property. The LogicDest property is a core design feature, used to store the logical address of the instance (e.g., "0x0001_A000"), providing a hardware address mapping basis for code generation, so that the generated code can accurately associate with the physical resources of the target FPGA.

[0037] By setting the FPGAAppCompPart and the SCA architecture's AssemblyComponent as a UML composition relationship (i.e., FPGAAppCompPart is a part of AssemblyComponent), and leveraging the component assembly capabilities of AssemblyComponent, the entire lifecycle of FPGAAppCompPart creation, initialization, operation, and destruction can be uniformly managed, avoiding instance management chaos and improving the stability and maintainability of the entire system.

[0038] When creating an FPGAAppCompPart instance in the component structure diagram, two key options need to be configured: Definition and LogicDest. The Definition option is used to associate the corresponding FPGAAppComp abstract definition (such as DataAcquisition_FPGAAppComp) to ensure that the instance inherits all the properties and interfaces of the abstract component. The LogicDest option is used to configure the logical address (such as 0x0001_A000) to provide address mapping parameters for subsequent code generation.

[0039] In this implementation, two FPGAAppCompPart instances are created: Instance 1 is associated with DataAcquisition_FPGAAppComp, LogicDest is configured as 0x0001_A000, and named DataAcq_Inst01; Instance 2 is associated with the data processing FPGA component (another defined FPGAAppComp), LogicDest is configured as 0x0001_B000, and named DataProc_Inst01.

[0040] To visually represent the port associations of different instances in the component structure diagram, while avoiding disruption to the original code and descriptor generation process, this implementation uses semantically neutral FreeConnection connections to establish port connections, such as... Figure 3The diagram illustrates a connection scenario between two FPGAAppComp instances. Each instance is configured with a LogicDevicePort and labeled with the logicDest property. The instances are connected via a FreeConnection connection—this connection only uses arrows to indicate the data flow direction and does not include any semantic verification markers. This intuitively reflects the core design principle of only showing the association and not participating in semantic verification. Specific details are as follows: FreeConnection connections are used only for graphically displaying the connection direction and relationships between ports (such as connecting the Data_Out_01 port of DataAcq_Inst01 to the Data_In_01 port of DataProc_Inst01). They do not participate in modeling semantic verification, nor do they embed any business logic. This decouples the display from the semantics, satisfying users' need to intuitively view connection relationships while avoiding errors in the original code generation process caused by introducing additional semantics through connections, thus ensuring compatibility with the existing development process.

[0041] In the visual editor, users can draw FreeConnection lines by dragging and dropping. The system will automatically identify the port type (provided / used) and match the connection rules (e.g., provided ports can only be connected to used ports) to ensure the correctness of the connection logic. In this embodiment, two FreeConnection lines are drawn: one is the connection between Data_Out_01 of DataAcq_Inst01 and Data_In_01 of DataProc_Inst01 to realize data transmission; the other is the connection between Clock_Out_01 of Clock_Inst01 (clock component instance) and Clock_In_01 of DataAcq_Inst01 to realize clock signal supply.

[0042] Automated generation of FPGA component code: A trigger mechanism is built based on Eclipse PDE technology. Modeling information is collected through action execution classes, and then a code generator uses preset templates to complete project creation and code generation. This process completely replaces the manual writing of hardware description languages. The specific implementation chain is as follows: Figure 4 As shown, the trigger is the right-click menu of the Navigator view. When the user selects a component instance, the FPGAGenerateActionProvider action execution class is triggered. Then, the ModelInfoCollector utility class iterates through the component instances, ports, and connection information and stores them in the FPGAList collection. Next, the code generator FPGAGenerator performs three steps in sequence: creating the project structure, parsing template placeholders, and replacing placeholders. Finally, it outputs a directly compileable FPGA project file and refreshes the workspace. The specific steps are as follows: To enable convenient right-click triggering of selected components, this implementation uses Eclipse PDE technology to configure the triggering mechanism, as detailed below: The extension point org.eclipse.ui.navigator.navigatorContent is defined in the plugin configuration file plugin.xml. This extension point is the core of the Eclipse Navigator extension mechanism. It allows you to customize the element styles, context menu actions, and icons in the resource manager and CNF (Common Navigator Framework) view. With the help of Eclipse's plug-in architecture, you can extend the functionality without modifying the Eclipse source code, thus improving compatibility and maintainability.

[0043] In the actionProvider child node of the extension point, configure three key attributes: ① class: specify the action execution class as FPGAGenerateActionProvider; ② id: set to SCA4GenerateAction as the unique identifier of the action; ③ priority: set to highest to ensure that the action is displayed first in the right-click menu. Among them, FPGAGenerateActionProvider inherits the Eclipse CommonActionProvider class, which is the standard interface for providing context actions for CNF views. Custom actions can be quickly added through inheritance.

[0044] When a user selects a modeled FPGA component instance (such as DataAcq_Inst01) in the Navigator view, right-clicks it, and selects the Generate FPGA Code menu option, the system will trigger the fillContextMenu() callback method of the FPGAGenerateActionProvider class to start the code generation process.

[0045] Model information collection is a crucial step connecting modeling and generation, and it is completed by the fillContextMenu() method of the FPGAGenerateActionProvider class. The specific process is as follows: The collected information is stored in the FPGAList collection, including: ① the identification information of the FPGA application component (such as the name DataAcquisition_FPGAAppComp); ② the logical address information of the component instance (such as LogicDest 0x0001_A000); ③ the port information of LogicDevicePort (name, type, supply and demand attributes, such as Data_Out_01, CMOS, Provides); ④ the connection relationship information of FreeConnection (such as DataAcq_Inst01.Data_Out_01 → DataProc_Inst01.Data_In_01). Through full collection and structured storage, it is ensured that the code generator can obtain all necessary parameters, avoiding the generation of code missing key configurations.

[0046] The `fillContextMenu()` method first obtains the selected component instance object through Eclipse's resource interface, then calls the `collect()` method of the `ModelInfoCollector` utility class to iterate through the instance's properties, interfaces, and connection relationships, structuring the information and storing it in `FPGAList`. To ensure the accuracy of the information, the `collect()` method performs secondary verification on the port type and connection relationship (such as verifying whether the provided port is connected to the used port). If an error is found, a prompt box will pop up to prevent error information from flowing into the generation process.

[0047] Project and code generation are implemented using the FPGAGenerator class. The core of this process is template creation and placeholder replacement. The specific steps are as follows: First, create an IProject object in the Eclipse workspace (the standard interface for managing project resources in Eclipse). Then, create the FPGA project structure based on the preset template, including the top-level module folder (src / top), port configuration folder (src / port), clock management folder (src / clock), and project configuration files (.xpr files, the standard configuration files for Xilinx FPGA projects). By standardizing the project structure, it is ensured that the generated project can be directly opened by tools such as Xilinx Vivado without the need for manual adjustments to the structure.

[0048] In the .xpr file and the top-level module code template, a large number of placeholders are set to replace dynamic information, such as ${COMPONENT_NAME} corresponding to the component name, ${LOGIC_DEST} corresponding to the logical address, ${PORT_NAME} corresponding to the port name, and ${PORT_TYPE} corresponding to the port type. Fixed templates ensure project standardization, while placeholder replacements adapt to different modeling information, improving generation efficiency and flexibility.

[0049] The `replaceContent()` method of `FPGAGenerator` is called to read the information in `FPGAList`. The placeholders are replaced with actual parameters using regular expression matching (e.g., `${COMPONENT_NAME}` is replaced with `DataAcquisition_FPGAAppComp`). The `.xpr` file and related code files are then refactored. After the replacement is complete, the `refreshLocal()` method of `IProject` is called to refresh the Eclipse workspace so that the generated project files are visible in real time.

[0050] In this embodiment, the generated project contains the following core files: ①DataAcquisition_FPGAAppComp.xpr (project configuration file, already populated with logic address 0x0001_A000); ②top_module.v (top-level module code, already containing port declarations input LVDS Clock_In_01; output CMOS Data_Out_01;); ③clock_manager.v (clock management module code, adapted to receive LVDS clock signals).

[0051] Example 2 An automated code generation method for FPGA components, wherein the terminal device of the present invention is used to execute the above method, including a visualization modeling module and a code generation module; Visual modeling module: Integrates a custom graphical editor, providing three core functions: Component definition functionality: Supports the creation and property configuration of FPGAAppComp and LogicDevicePort, such as... Figure 1 The diagram showing the FPGAAppComp components and interface relationships, and the attached diagram... Figure 5 The interface design is shown in the FPGAAppComp and LogicDevicePort interface inheritance relationship diagram. Instantiation functionality: Supports the creation of FPGAAppCompPart and the configuration of LogicDest properties, as shown in the attached document. Figure 2 The FPGAAppCompPart instance configuration diagram shown is attached. Figure 6 The example design of the FPGAAppCompPart interface inheritance and composition relationship diagram is shown below; Connection functionality: Supports drawing and verifying FreeConnection connections, such as... Figure 3 The component structure diagram and FreeConnection connection diagram shown are related to the wiring design. The visual modeling module replaces code writing with graphical interaction, reducing the professional threshold for FPGA development through intuitive interface operation, while built-in verification logic ensures the correctness of modeling information.

[0052] Code generation module: Integrates the FPGAGenerateActionProvider action execution class and the FPGAGenerator code generator. Core functions include: Trigger mechanism management: Maintain Eclipse PDE extension point configuration; see the method description for the trigger process. Information collection: Modeling information is stored through FPGAList; Project generation: Create standardized project structures based on templates; Placeholder replacement: Transforms modeling information into actual code parameters.

[0053] This module replaces manual operations with automated processes. Through preset templates and replacement logic, it completely eliminates human coding errors while ensuring the consistency of the project architecture.

[0054] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for automatically generating FPGA component code, characterized in that, Includes the following steps: Visual modeling of FPGA components: Define FPGA application components, each with an interface to support the creation of logic device ports; create FPGA application component instances in the component structure diagram based on the FPGA application components; associate each FPGA application component instance with a corresponding FPGA application component and configure the logic addresses required for code generation; establish the connection relationship between the logic device ports of different FPGA application component instances in the component structure diagram through wiring; Automatic generation of FPGA component code: Based on Eclipse PDE technology, configure the code generation trigger mechanism and specify the action execution class to trigger the code generation process; The action execution class collects and stores the FPGA component model information obtained from the visualization modeling. The code generator is invoked to create an FPGA project based on the collected model information, generate a project configuration file containing placeholders, replace the placeholders, and then store the project file, thus achieving automated code generation.

2. The FPGA component code automated generation method according to claim 1, characterized in that, The FPGA application component inherits the StructuralRealization interface and the SCANamedElement interface of the SCA architecture. By inheriting the above interfaces, the FPGA application component adapts to the SCA architecture, enhancing the SCA framework's ability to manage dynamically configurable FPGA resources. The interface provided by the FPGA application component is BuildInAppCompInterface. The logic device ports are divided into providing ports and using ports according to their functions.

3. The FPGA component code automated generation method according to claim 1, characterized in that, The logical device port inherits the ConjugatedPort interface and ScanamedElement interface of the SCA architecture; The ConjugatedPort interface supports the definition of port supply and demand relationships; the SCANamedElement interface implements port naming management. The logical device port also defines the refportName and refPortType attributes, which are used to identify the port name and port type, respectively.

4. The FPGA component code automated generation method according to claim 1, characterized in that, The FPGA application component instance inherits the preset BuildInAppCompPart interface; The BuildInAppCompPart interface inherits the SCANamedElement interface and predefines the LogicDest property corresponding to the logical address. The FPGA application component instance and the AssemblyComponent component have a UML composition relationship, and the AssemblyComponent component manages the lifecycle of the FPGA application component instance.

5. The FPGA component code automated generation method according to claim 1, characterized in that, The connection used to establish the connection relationship is a semantically neutral FreeConnection connection. This connection only graphically displays the connection direction and relationship between ports, does not participate in the semantic verification of modeling, and does not affect the original code and descriptor generation.

6. The FPGA component code automated generation method according to claim 1, characterized in that, The configuration of the code generation triggering mechanism includes: Define the core extension points of the Navigator extension mechanism, and customize the element styles of the resource manager and CNF view through the defined core extension points, and bind code to generate actions and icons; The action execution class is FPGAGenerateActionProvider, which inherits the CommonActionProvider class from Eclipse PDE technology.

7. The FPGA component code automated generation method according to claim 1, characterized in that, The callback method of the action execution class is triggered by the right-click menu option of the FPGA component model element to start the model information collection process.

8. The FPGA component code automated generation method according to claim 1, characterized in that, The code generator is FPGAGenerator; the project configuration file is an xpr file; the code generator creates an FPGA project using the prepareProject method and predefines a project structure that includes a top-level module, port declarations, and a clock management module. The key parameters of the xpr file are represented in placeholder form, and the key parameters include the project name, logical address, and port configuration information.

9. The FPGA component code automated generation method according to claim 1, characterized in that, The data set storing model information is FPGAList. The information stored in FPGAList includes the identification information of FPGA application components, the logical address information of FPGA application components, and the port name, type, and supply and demand attribute information of the logic device ports.

10. An FPGA component code automated generation terminal, characterized in that, The method for automatically generating FPGA component code according to any one of claims 1 to 9; It includes a visual modeling module and a code generation module. The visual modeling module provides a visual editing interface, supports the definition of FPGA application components, the creation of FPGA application component instances and the establishment of port connection relationships, and stores modeling information. The code generation module integrates action execution classes and code generators to perform trigger mechanism configuration, information collection, and project file generation operations.

Images