Method and device for online editing of FPGA (Field Programmable Gate Array) memory

Abstract

The embodiment of the invention provides a method and device for online editing an FPGA memory, and the method comprises the steps: obtaining first configuration data of a physical memory BRAM of the FPGA when the FPGA is in a working state of a user mode, and the first configuration data comprises the physical layout position of the physical memory BRAM and the size of an occupied space; mapping the first configuration data to second configuration data in a logic EMB format according to the physical layout position of the physical memory BRAM and the size of the occupied space; in response to an online editing operation of a user on the second configuration data, acquiring edited third configuration data in the logic EMB format; mapping the third configuration data in the logic EMB format into fourth configuration data of the updated physical memory BRAM; and writing fourth configuration data of the updated physical memory BRAM back to the FPGA, and performing testing and verification after covering the first configuration data.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and device for online editing of FPGA memory. Background Art

[0002] As the complexity of modern electronic design continues to increase, FPGAs (Field-Programmable Gate Arrays), as reconfigurable integrated circuits, have gained widespread application in various electronic systems. FPGAs contain a large number of programmable logic cells, memory cells, and interconnect resources. Block random access memory (BRAM), a key storage resource within FPGAs, is often used to store user program data, lookup tables, and other information. Configuring and modifying BRAM contents is a common and important task in FPGA design.

[0003] Currently, the design process for FPGA chips typically includes steps such as design input, synthesis, layout and routing, bitstream generation, and configuration download. In the traditional FPGA development process, when the data content of the FPGA's internal BRAM needs to be modified, it is usually necessary to first modify the RTL (Register Transfer Level) code or initialization file, then re-synthesize and re-layout, generate a new bitstream file, and finally re-download the entire bitstream to the FPGA chip. For example, CN115017851A discloses a netlist processing method and device. This method pre-stores resource information on the FPGA chip in memory. When the FPGA chip needs to be edited, the module to be queried can be directly compared with the pre-stored information, reducing processing time. During the debugging process of the FPGA chip, CN115221050A proposes a debugging method that adds a debugging process constraint file in the second layout phase, re-layouts the FPGA chip, and obtains the status of the internal module debug port signal without modifying the user design. Although this method improves debugging efficiency, it still requires a complete layout and routing process and cannot directly modify the contents of the internal memory while the chip is operating normally.

[0004] In summary, in the related art, when the data content of the BRAM inside the FPGA needs to be modified, it is usually necessary to exit the user mode, and the modification cannot be performed when the chip is in normal working condition; moreover, the modified memory data needs to regenerate the bitstream file (also called code stream data) of the entire chip and download it in full, which takes a long time to download, seriously affecting work efficiency. Summary of the Invention

[0005] The embodiments of the present application provide a method and device for online editing of FPGA memory, which can modify memory data online when the chip is in normal working state without re-downloading the code stream data of the entire chip, thereby improving the efficiency and flexibility of FPGA development.

[0006] To this end, the following technical solutions are provided in the embodiments of the present application:

[0007] In a first aspect, an embodiment of the present application provides a method for online editing of FPGA memory, comprising: when the FPGA is in a user mode working state, obtaining first configuration data of the physical memory BRAM of the FPGA, the first configuration data including the physical layout position and occupied space size of the physical memory BRAM; the user mode indicates that the FPGA enters an operating state for executing a configured function; mapping the first configuration data to second configuration data in a logical EMB format according to the physical layout position and occupied space size of the physical memory BRAM; in response to a user's online editing operation on the second configuration data, obtaining edited third configuration data in the logical EMB format; mapping the third configuration data in the logical EMB format to updated fourth configuration data of the physical memory BRAM; writing the updated fourth configuration data of the physical memory BRAM back to the FPGA, overwriting the first configuration data, and then testing and verifying.

[0008] In this embodiment, when the FPGA is operating in user mode, first configuration data of the FPGA's physical memory BRAM is obtained. This data includes the physical layout location and occupied space size of the BRAM. The physical configuration data is mapped to second configuration data in a logical EMB format. This mapping process maps the hardware's physical resource configuration to a logical format that better meets design requirements, making it easier for users to understand and edit. The user can edit the logical EMB format data online, i.e., modify the data content in the BRAM. This editing operation does not affect the normal operation of the FPGA, so the modification process does not require interrupting FPGA operation. In response to the user's editing operation, edited third configuration data is obtained. This data is based on the user-modified logical EMB format data. The edited logical EMB data is mapped back to the fourth configuration data of the physical memory BRAM, and the configuration of the physical memory BRAM in the FPGA is updated. The updated physical BRAM configuration data is written back to the FPGA, overwriting the original configuration data. Finally, testing and verification are performed to ensure that the modification has taken effect correctly.

[0009] Unlike traditional FPGA development processes, this solution enables real-time modification of BRAM contents while the FPGA chip is operating normally. This avoids the tedious steps of regenerating the bitstream and re-downloading the entire chip after data modifications. Furthermore, by directly editing BRAM data without exiting user mode, development and debugging time is significantly reduced. Developers can quickly modify BRAM contents for verification and testing, shortening the development cycle. Removing the need to re-perform synthesis, place-and-route, and other steps not only improves work efficiency but also reduces hardware resource consumption and waste. By mapping the logical EMB format to the physical BRAM configuration data, users can more intuitively understand and edit the required data content. This mapping mechanism effectively simplifies user operations and reduces the complexity of FPGA design. Since modifications can be made while the chip is operating normally, without restarting or reloading the entire FPGA configuration, potential system interruptions or instability can be effectively avoided, effectively improving overall system reliability. This technical solution is particularly suitable for applications that require frequent modification and debugging of BRAM contents. FPGA developers can flexibly modify internal memory contents without affecting other FPGA operations, providing greater flexibility and debugging capabilities.

[0010] As an achievable implementation, obtaining the first configuration data of the physical memory BRAM of the FPGA includes: in response to the user selecting the physical memory BRAM to be edited in the chip editor, obtaining the first configuration data of the physical memory BRAM according to the Jtag interface.

[0011] In this embodiment, within the FPGA's chip editor, developers select the physical memory BRAM module to be edited online. The chip editor provides a graphical interface that allows developers to intuitively select and locate internal FPGA storage resources, such as BRAMs. Once the physical memory BRAM to be edited is selected, the system communicates with the FPGA via the JTAG interface to obtain the physical configuration data for the selected BRAM. The JTAG interface is a commonly used debugging and testing interface for FPGAs, enabling real-time access to the FPGA's internal resources and providing relevant configuration data. The data obtained from the JTAG interface is the first configuration data for the physical BRAM, including the BRAM's physical layout and occupied storage space. This data provides the basis for subsequent online editing, helping to map the physical memory BRAM configuration to a more easily modifiable logical format. By directly selecting the physical memory BRAM to be edited within the chip editor, developers can precisely locate the storage resource to be modified, avoiding the tedious steps of manual search and configuration. The graphical interface intuitively displays the FPGA's internal resources, reducing operational complexity. Real-time acquisition of physical memory BRAM configuration data via the JTAG interface ensures accurate and timely data acquisition. As a standard debugging tool, the JTAG interface can quickly access the internal state of the FPGA without stopping the FPGA, ensuring non-interfering access to the BRAM during development. By combining the chip editor with the JTAG interface, the entire configuration data acquisition and editing process becomes simpler and more efficient. The integration of the user interface and interface makes operation more intuitive and easier to master, eliminating the need to manually operate the hardware or delve into the underlying code.

[0012] As an achievable implementation, the obtaining of the first configuration data of the physical memory BRAM of the FPGA also includes: loading the layout and routing results after the original FPGA project running process in the chip editor, displaying the actual physical layout position and occupied space size of the resources used by the layout and routing results after the original FPGA project running process; searching for all instance names containing the physical memory BRAM keyword and instance name in the original FPGA RTL design.

[0013] In this implementation, by loading the original FPGA project and displaying the physical layout of the resources, developers can clearly understand the distribution of various resources in the FPGA, including the specific location and occupied space of the BRAM. This intuitive layout display reduces the developer's guesswork and complex calculations regarding resource distribution, thereby improving development efficiency. By searching for all instance names containing the physical memory BRAM keyword and instance alias in the original RTL design, the system can accurately identify and locate all BRAM instances. This ensures that no physical memory BRAM is missed and avoids incorrect modifications due to inconsistent naming or design errors. In complex FPGA designs, the original RTL code and resource layout often change as the design evolves. Capturing and displaying configuration data in this way can help developers better understand and maintain the design. Especially in multi-person collaboration or long-term projects, this clear resource layout and instance search method can greatly improve the maintainability and scalability of the design.

[0014] This technical solution provides developers with a more intuitive and precise way to locate BRAMs by loading the original FPGA project in the chip editor and displaying the physical resource layout. This solution, combined with the ability to find BRAM instantiation names in the RTL design, also provides developers with a more intuitive and precise way to locate BRAMs. By integrating with the JTAG interface, real-time access to physical memory BRAM configuration data improves development efficiency and facilitates debugging and verification. This overall solution enhances flexibility, accuracy, and maintainability during FPGA development, making it particularly suitable for projects with complex designs and long-term maintenance.

[0015] As an achievable implementation, mapping the first configuration data to the second configuration data in a logical EMB format according to the physical layout position and the occupied space size of the physical memory BRAM includes: mapping the first configuration data of the physical memory BRAM to the logical EMB instantiated in the RTL design through conversion logic; wherein the conversion logic indicates the mapping relationship between the first configuration data and the second configuration data, and the logical EMB instantiated in the RTL design indicates the second configuration data.

[0016] In this implementation, the conversion logic is a key part of the mapping process, converting the first configuration data of the physical memory BRAM into the second configuration data in the logical EMB format. The EMB (Embedded Memory Block) format is a configuration format defined at the logical level, suitable for describing the logical behavior and configuration of the BRAM. The conversion logic needs to consider the mapping relationship between the physical BRAM and the logical BRAM to ensure data consistency between the two.

[0017] The conversion logic consists of two parts:

[0018] Mapping relationship: It defines the conversion rules between the configuration of physical memory BRAM and the logical EMB format, such as how to map the storage depth and width from physical description to logical description.

[0019] Instantiation information: In RTL design, logical EMBs are usually defined by specific BRAM instantiation names. These instantiated logical EMBs correspond to the mapped secondary configuration data, ensuring that the configuration in the logical design is consistent with the physical hardware configuration.

[0020] In RTL design, BRAMs are defined and used through instantiation. Through conversion logic, the first configuration data (physical BRAM configuration) is mapped to the logical EMB instantiated in the design, ultimately generating second configuration data. This data reflects the logical configuration of the BRAM in the FPGA design and conforms to the EMB format. Accurately mapping the physical BRAM configuration to the logical EMB format through conversion logic ensures consistency between the FPGA hardware implementation and the design description. This prevents functional errors or performance issues caused by mismatches between the physical and logical configurations. Mapping the physical BRAM configuration to the EMB format improves modularity and readability of the entire design. This makes it easier for developers to understand and manage different levels of the design, reducing complexity during subsequent maintenance and optimization. Through conversion logic, developers can debug the BRAM configuration at the logical level without frequently modifying the physical hardware or recompiling the entire design. This saves debugging time and accelerates design iteration and deployment. This mapping allows developers to more effectively manage BRAM configurations in FPGA designs, improving overall design efficiency and system performance.

[0021] In an achievable implementation, the first configuration data further includes a BRAM type identifier and an index number of the BRAM in the chip.

[0022] In this embodiment, the first configuration data includes not only the physical configuration parameters of the BRAM such as the storage depth and width, but also the BRAM type identifier and the index number of the BRAM in the chip. Among them, the BRAM type identifier is used to distinguish different types of BRAM. For example, different BRAM types may have different storage methods, access modes or functional requirements, such as single-port BRAM, dual-port BRAM, etc. The identifier can help the design tool understand the nature of the BRAM and adopt appropriate configuration strategies. The index number of the BRAM in the chip: Each BRAM instance will have a unique index number in the FPGA chip to identify its specific location. This information is very important in the design because it can ensure that the BRAM is correctly instantiated and connected to other modules. This technical solution aims to ensure that the BRAM in the FPGA design can be correctly instantiated and configured by mapping the configuration data of the physical memory BRAM (including the BRAM type identifier and index number) to the EMB format configuration data at the logical level. Specifically, the role of the conversion logic is to convert the first configuration data (including the BRAM type identifier, index number and other configuration data) into the second configuration data in the logical EMB format. The conversion logic needs to handle the following tasks:

[0023] BRAM type mapping: Based on the BRAM type identifier, the conversion logic determines the characteristics and behavior of the BRAM and generates the corresponding EMB format configuration.

[0024] Index number mapping: Using the index number of the BRAM in the chip, the conversion logic determines the location of the BRAM in the logic design and ensures that the data is correctly mapped to the instantiated BRAM.

[0025] Physical to logical mapping: Mapping the configuration of the physical BRAM (such as memory depth, width, access mode, etc.) to a logical configuration suitable for instantiation in the FPGA.

[0026] Through mapping logic, the first configuration data is converted into second configuration data suitable for instantiating the BRAM, ensuring that the logical BRAM configuration in the FPGA design meets the requirements of the physical BRAM. At the same time, by introducing BRAM type identifiers and BRAM index numbers, this technical solution not only enhances the flexibility and scalability of hardware design, but also improves the efficiency and stability of resource management during the design process. The introduction of conversion logic makes the mapping from physical BRAM configuration to logical BRAM configuration more accurate and efficient. The application of this solution in complex systems can effectively reduce design conflicts, improve design quality and maintainability, and provide a convenient path for future hardware expansion and adjustment.

[0027] In one achievable embodiment, mapping to the logical EMB instantiated in the RTL design includes extracting hexadecimal data of the physical memory BRAM to be edited from the third configuration data according to the logical EMB format of the third configuration data, where each row of data corresponds to an address of the physical memory BRAM. For example, the first row corresponds to address 0 of the physical memory BRAM, and the second row corresponds to address 1 of the physical memory BRAM.

[0028] In this implementation, by mapping the hexadecimal data in the third configuration data to the physical BRAM address space, this technical solution achieves efficient and accurate BRAM configuration. This solution is particularly suitable for large-scale hardware design projects that require frequent configuration adjustments and management of multiple BRAM instances, significantly improving design efficiency and hardware system stability.

[0029] As an achievable implementation, in response to the user's online editing operation on the second configuration data, obtaining the edited third configuration data in the logical EMB format includes: adjusting the arrangement order of the hexadecimal data according to the order of each physical memory BRAM edited by the user, so that it correctly corresponds to the physical actual storage order in the first configuration data of the physical memory BRAM, so that it can be used when updating the first configuration data.

[0030] In this embodiment, the core is to obtain the updated third configuration data in the logical EMB format after responding to the user's online editing operation on the second configuration data. The process includes adjusting the arrangement order of the hexadecimal data according to the physical memory BRAM order edited by the user, so that it matches the actual storage order in the first configuration data of the physical memory BRAM, ensuring that when the first configuration data is updated, the data is correctly reflected in the physical memory BRAM. By responding to the user's online editing operation, the arrangement order of the hexadecimal data is automatically adjusted to be consistent with the actual storage order of the physical memory BRAM. This technical solution has significant advantages in flexibility, accuracy and efficiency. It not only supports real-time configuration updates and simplifies the design and configuration management process, but also ensures the accuracy of the physical memory BRAM data in the hardware design and the reliability of the system. Therefore, this solution is very suitable for hardware design that requires dynamic configuration and optimization of memory data, especially in FPGA or ASIC design, improving the efficiency and quality of the overall design.

[0031] In one achievable implementation, writing the updated fourth configuration data of the physical memory BRAM back to the FPGA includes: writing the fourth configuration data back to the physical memory BRAM of the FPGA through a Jtag interface.

[0032] In this embodiment, the fourth configuration data is updated data generated through the aforementioned steps (such as user editing of configuration data and adjustment of data order). This data may involve modification, updating, or reconfiguration of the BRAM contents to improve the system's functionality or performance. The Jtag interface provides a standardized, reliable data transmission channel that can accurately write the fourth configuration data into the physical memory BRAM within the FPGA. Once the data is successfully written to the BRAM, the FPGA's logic circuits will begin using this updated data to perform real-time calculations or functional operations. The new data configuration enables the FPGA to perform tasks based on user needs or new design requirements. Writing the updated fourth configuration data back to the FPGA's physical memory BRAM via the Jtag interface is a flexible, efficient, and reliable configuration update solution. This technology not only supports real-time updates and debugging on-site, but also ensures the accuracy and efficiency of data transmission, avoids hardware downtime, and improves system availability and stability. It is suitable for FPGA designs that require frequent configuration data modifications or dynamic adjustments, and is particularly suitable for application scenarios such as the development phase, system debugging, field deployment, and system maintenance.

[0033] In one achievable implementation, the Jtag interface uses the IEEE 1149.1 protocol for communication, and the Jtag interface uses four signal lines, TCK, TMS, TDI, and TDO, to communicate with the FPGA chip.

[0034] In this embodiment, the IEEE 1149.1 (also known as JTAG, Joint Test Action Group) protocol is a standard protocol for testing, debugging, and programming electronic devices (particularly integrated circuits such as FPGAs and ASICs). It defines how to communicate between devices using four standard signal lines (TCK, TMS, TDI, and TDO). TCK (Test Clock): This signal line provides clock pulses and controls the data transmission rhythm during JTAG communication. TMS (Test Mode Select): This signal line is used to select different test modes within the FPGA, determining whether the FPGA is in test mode or normal operating mode. TDI (Test Data In): This signal line is used to input data sent by an external controller or device into the FPGA or other chip. TDO (Test Data Out): This signal line is used to output data from the FPGA or other chip to an external device, typically used to read data or transmit status information. Through these four signal lines, the JTAG interface enables testing, configuration, debugging, and fault diagnosis of the FPGA. Using the IEEE 1149.1 JTAG interface for communication, connecting to the FPGA chip via four signal lines: TCK, TMS, TDI, and TDO, this solution is efficient, standardized, flexible, and reliable. It not only simplifies hardware design and accelerates development and debugging, but also enables configuration and troubleshooting during normal device operation, improving system reliability and availability. This technical solution allows developers to easily implement real-time FPGA programming, testing, and maintenance, while reducing system complexity and development costs.

[0035] In a second aspect, an embodiment of the present application further provides a device for online editing of FPGA memory, comprising an acquisition module and a processing module. The acquisition module is configured to acquire first configuration data of the physical memory BRAM of the FPGA, the first configuration data including the physical layout position and occupied space size of the physical memory BRAM; the processing module is configured to map the first configuration data to second configuration data in a logical EMB format based on the physical layout position and occupied space size of the physical memory BRAM; in response to a user's online editing operation on the second configuration data, acquire the edited third configuration data in the logical EMB format; map the third configuration data in the logical EMB format to updated fourth configuration data of the physical memory BRAM; and write the updated fourth configuration data of the physical memory BRAM back to the FPGA, overwriting the first configuration data and performing testing and verification.

[0036] In a third aspect, an embodiment of the present application further provides a computing device comprising at least one memory for storing programs; and at least one processor for executing the programs stored in the memory; wherein the memory is coupled to the processor, and when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0037] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions in the computer-readable storage medium are executed by a computing device, the computing device executes the method involved in the first aspect and its possible implementation methods.

[0038] In a fifth aspect, an embodiment of the present application further provides a computer program product, which includes computer instructions. When the computer instructions are executed by a computing device, the computing device executes the method described in the first aspect and its possible implementation methods.

[0039] It can be understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

[0040] The technical solution of this application, by introducing a method and apparatus for online editing of FPGA memory, not only addresses the limitations of modifying BRAM content in traditional FPGA development, but also significantly improves development efficiency and flexibility. By mapping physical BRAM data to the logical EMB format, users can edit the required data more intuitively and conveniently, avoiding the lengthy process of regenerating and downloading the bitstream. This speeds up FPGA development, debugging, and optimization, and enhances the flexibility and efficiency of FPGA applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 : shows a schematic diagram of an application scenario architecture of a method for online editing of FPGA memory provided by an embodiment of the present application;

[0042] Figure 2 : is a flow chart of a method for online editing of FPGA memory provided by an embodiment of the present application;

[0043] Figure 3 A schematic diagram of a data mapping process of an FPGA chip H3 provided in an embodiment of the present application is shown;

[0044] Figure 4 A flowchart of a method for online editing of FPGA memory provided in Example 1 of the present application is shown;

[0045] Figure 5A structural diagram of a device for online editing of FPGA memory provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0046] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0047] In the description of the embodiments of the present application, words such as "exemplary," "for example," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary," "for example," or "for example" in the embodiments of the present application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0048] In the description of the embodiments of this application, the term "and / or" is simply a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent the following three situations: A exists alone, B exists alone, and A and B exist at the same time. In addition, unless otherwise specified, the term "plurality" means two or more. For example, "multiple systems" refers to two or more systems, and "multiple terminals" refers to two or more terminals.

[0049] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly identifying the technical features being referred to. Thus, features specified as "first" or "second" may explicitly or implicitly include one or more of such features. The terms "include," "comprising," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0050] In the description of the embodiments of the present application, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

[0051] In the description of the embodiments of the present application, the terms "first\second\third, etc." or module A, module B, module C, etc. are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0052] In the description of the embodiments of the present application, the numbers representing the steps, such as S101, S102, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the previous and next steps can be interchanged, or they can be executed simultaneously.

[0053] Related terms involved in the embodiments of this application:

[0054] An FPGA (Field-Programmable Gate Array) chip is an integrated circuit that can be programmed and configured by the user on-site. Unlike traditional ASICs (Application-Specific Integrated Circuits), the hardware architecture of an FPGA chip is reconfigurable after manufacturing, and users can customize the design as needed to meet specific application requirements. FPGAs contain a large number of logic blocks (Logic Blocks), lookup tables (LUTs), triggers, I / O units, and programmable connections. Users configure these modules to implement complex logic functions, even microprocessors, controllers, algorithm acceleration, etc. Through programming, FPGAs can implement hardware logic related to specific applications and provide efficient parallel processing capabilities at runtime.

[0055] Block random access memory (BRAM) is a general term for programmable memory blocks used in FPGA chips. Users can combine multiple block RAMs to create a specific size of memory for data storage and access operations. Block RAM is often used to implement functions such as data cache, FIFO queues, and memory.

[0056] A logical EMB (Logical Embedded Memory Block, also known as a Logical EBM) is a logic component used for memory in an FPGA design and is mapped to physical BRAM (Block RAM). Logical EBMs represent memory blocks defined by users in the RTL (Register Transfer Level) code of an FPGA design. These memory blocks do not directly correspond to actual hardware memory units, but are instead mapped to physical BRAMs based on design requirements. In other words, logical EBMs refer to the memory logic defined in the RTL code of an FPGA design. They represent a logical memory structure, not actual physical hardware memory. Designers typically use logical EBMs in RTL to describe memory functional requirements, but these do not directly correspond to the physical BRAMs in the FPGA. Physical BRAMs are memory resources provided by the FPGA hardware itself and are typically directly accessed by design tools. During the actual design process, tools map the logical EBMs in the design to physical BRAMs to ensure efficient memory resource utilization. In summary, logical EBMs primarily describe the memory structure in a design, while physical BRAMs are the actual hardware resources in the FPGA.

[0057] EDA (Electronic Design Automation) refers to the process of automating the design, analysis, and verification of electronic systems (such as integrated circuits and printed circuit boards) using computer software and hardware tools. EDA software helps designers complete a range of complex electronic design tasks, from circuit design, simulation, layout, routing, to final verification. Common EDA tools include Cadence, Mentor Graphics, and Synopsys.

[0058] RTL (Register Transfer Level) design is an abstract level of Hardware Description Language (HDL) design that focuses on the transfer of data between clock cycles and data processing between registers. RTL design describes the transfer of signals and registers in digital circuits and the operating logic between them, and is typically used to describe and design the structure and behavior of digital circuits. In FPGA design, RTL design is one of the core stages of the design process. Designers describe the functions of the chip by writing RTL code (such as Verilog or VHDL), and then convert it into FPGA hardware resources through synthesis tools for verification and implementation. FPGA prototype verification usually loads the RTL design onto the FPGA development board for actual functional verification and performance testing to ensure that the design meets the requirements.

[0059] JTAG interface: The JTAG interface is a standardized hardware debugging and testing interface widely used for testing, programming, and debugging electronic components on circuit boards. For example, JTAG can be used to program or burn programmable logic devices such as FPGAs and CPLDs, and can also be used to update firmware on microcontrollers (MCUs).

[0060] Bitfile: The full name is bitstream file, which is the configuration file of the FPGA (Field-Programmable Gate Array) chip. It is used to describe the file containing the complete internal configuration state of the FPGA, including wiring, logic resources and I / O settings.

[0061] ChipEditor: When developing FPGA chips, ChipEditor is often used to design on the FPGA chip. ChipEditor integrates multiple tools, allowing users to quickly and efficiently modify designs on the chip. Among them, ChipEditor's underlying layout allows users to check the resource usage of the designed FPGA chip. ChipEditor is primarily used to modify the layout and routing information and parameters corresponding to the chip design, such as changing the location of certain resources. After the modification, the layout and routing will be rerun, the bitstream will be regenerated, and then downloaded to the chip.

[0062] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0063] In related technologies, the typical FPGA chip development process includes software analysis and design, synthesis, place and route, software bitstream generation, downloading the bitstream to the chip, and debugging using an oscilloscope. Synthesis compiles the design into a logical connection netlist (not the actual gate-level circuit) consisting of basic logic cells. The generated logical connections are then optimized according to goals and requirements to flatten the hierarchical design for implementation by the FPGA place and route software. Place and route involves configuring the logic netlist onto a specific FPGA chip. Placement involves assigning the cells in the logic netlist to the chip's inherent hardware structure, choosing between optimizing speed and area. Routing involves rationally and correctly connecting components using the chip's internal wiring resources based on the layout topology. After place and route, timing simulation, also known as post-simulation, is performed. This involves back-annotating the delay information from the place and route back into the design netlist to detect timing violations. This is the most accurate delay measurement and best reflects the actual operation of the FPGA chip.

[0064] However, in traditional FPGA development, when modifying the data content of the FPGA's internal BRAM, it is typically necessary to first modify the RTL (Register Transfer Level) code or initialization file, then re-synthesis and place-and-route, generate a new bitstream file, and finally re-download the entire bitstream to the FPGA chip. Therefore, when modifying the data content of the FPGA's internal BRAM, it is usually necessary to exit user mode, making it impossible to modify the data while the chip is operating normally. Furthermore, the modified memory data requires regenerating the entire chip's bitstream file (also known as bitstream data) and downloading it in its entirety, which takes a long time and seriously impacts work efficiency. Furthermore, related BRAM editing tools typically operate directly on the physical BRAM without considering the mapping relationship between the logical EBM instantiated in the RTL and the physical BRAM, making it difficult for users to intuitively understand and modify the desired data content. These limitations are particularly prominent in application scenarios that require frequent debugging and modification of BRAM content, severely restricting the efficiency and flexibility of FPGA development.

[0065] The method and device for online editing of FPGA memory proposed in this application are intended to solve the limitations of modifying BRAM data in the current FPGA development process, especially the complex process of regenerating the bitstream and downloading it to the FPGA during the modification process. Specifically, the method of online editing of FPGA's BRAM is to directly operate the storage unit through the hardware programmable interface, breaking through the limitations of the solidified configuration in the traditional synthesis stage. Exemplarily, the hardware programmable interface supports multi-protocol access such as Jtag / Ethernet. For example, a communication link between the chip editor ChipEditor and the FPGA chip memory is established through the Jtag interface to achieve dynamic mapping of the target BRAM address and online access and editing and modification, ensuring that online operations do not interrupt the chip operation. This solution can edit the contents of BRAM online in real time when the FPGA chip is in normal working condition, without the need to regenerate and download the entire bitstream, thereby improving the efficiency and flexibility of FPGA development.

[0066] First, the architecture of an application scenario of a method for online editing of FPGA memory provided in an embodiment of the present application is introduced.

[0067] Figure 1 The figure shows an application scenario architecture diagram of a method for online editing of FPGA memory provided by an embodiment of the present application. Figure 1 As shown, the application scenario includes online editing of the FPGA memory device 100 and the FPGA chip 200, wherein the online editing of the FPGA memory device 100 and the FPGA chip 200 are communicatively connected via a JTAG interface.

[0068] Among them, the FPGA chip is the core hardware in the entire application scenario. It contains physical memory BRAM and other hardware modules, such as logic units, DSP modules, etc. In this embodiment, the FPGA chip is in a working state in user mode and communicates with the outside through the JTAG interface. The BRAM in the FPGA is a key element in this method, and can be edited and configured online through the method for online editing of FPGA memory provided in this application. It should be noted that the BRAM in the FPGA chip refers to a physical memory block for storing data. Each BRAM has its own physical layout and configuration, and is usually allocated different storage locations and sizes. The configuration data of the BRAM includes information such as address, capacity, and storage content. Through the chip editor, the user can edit the BRAM online. In this embodiment, the BRAM configuration data can be modified online without affecting the operation of the FPGA.

[0069] The JTAG interface, a standard interface for communicating with FPGA chips, connects the FPGA chip to the chip editor. It is used to retrieve configuration data from the FPGA's BRAM, write data, and provide debugging capabilities. The JTAG interface remains connected during the editing process, supporting data transfer, configuration, and modification operations.

[0070] It can be understood that in this application scenario, a method for online editing of FPGA memory provided in an embodiment of the present application is executed by an online editing FPGA memory device 100. Optionally, the online editing FPGA memory device 100 is internally configured with a software program for executing the method for online editing of FPGA memory. Exemplarily, the software program is a chip editor ChipEditor, which provides users with a visual user interface in ChipEditor, and an online editing tool is provided in the user interface of ChipEditor. In other words, in this embodiment, the chip editor ChipEditor is a tool for loading and editing FPGA project files, which is responsible for displaying the physical layout and configuration data of the FPGA chip. It provides a graphical interface through which users select and edit data in BRAM. During the editing process, the chip editor obtains the first configuration data of the FPGA chip through the JTAG interface and supports online editing operations.

[0071] After obtaining the first configuration data, the online editing tool maps the configuration data of the physical memory BRAM to the logical EMB (Embedded Memory Block) format through data mapping logic. This process ensures data consistency between the physical BRAM and the logical BRAM, allowing users to precisely modify BRAM data in the editing interface. Exemplarily, the data mapping logic includes converting the data in the physical memory BRAM into a mapping relationship for the logical EMB instantiated in the RTL design. The first configuration data is mapped and converted to the second configuration data, which is the first configuration data in the logical EMB format (the logical EMB instantiated in the RTL design). The logical EMB format is used to describe the structure and content of memory data, facilitating data storage and management, especially when dynamic editing is required. Specifically, the logical EMB format is a file format that describes the layout and physical location information of memory in an FPGA chip. It is typically used to extract the location information of the BRAM used in the design during FPGA prototyping and is used when updating the BRAM initialization value (first configuration data). The online editing tool interface serves as a BRAM editing tool, allowing users to edit the second configuration data in the online editing tool interface. For example, the configuration data that can be modified in the second configuration data in the logical EMB format includes, but is not limited to, the memory instance path, memory size, BRAM type, BRAM location in the FPGA chip, the start and end bit widths, depth, and address space of the BRAM corresponding memory. The second configuration data can be used to determine the physical location and occupied space of various physical memory storage devices in the FPGA chip.

[0072] The online editing tool provides a user interface that allows users to view and modify the data in the BRAM. On this interface, users can choose to view the data in hexadecimal or binary format and perform online editing operations. Users modify the BRAM content by clicking on cells, area selection editing, etc., and all modifications will be updated and stored in real time. During the editing process, the second configuration data is edited and changed to the third configuration data, and then through data logic mapping, the third configuration data is mapped to the fourth configuration data that can be used to update the initial value of the FPGA chip. It can be understood that the fourth configuration data is used to initialize the first configuration data in the BRAM. The fourth configuration data can be in binary format or hexadecimal format, each row contains a data value, and the bit width of each data value can be specified. In the BRAM initial value update, the fourth configuration data is used to store the BRAM configuration data with adjusted arrangement order.

[0073] It should be noted that when a user modifies the second configuration data through the online editing interface, the second configuration data typically contains data from the physical memory BRAM, but the order of this data does not necessarily match the actual storage order of the physical memory BRAM. The editing operation may involve adjusting or rearranging data to meet design requirements. The user's editing operation ultimately modifies the logical EMB data. The order of the hexadecimal data is adjusted based on the physical memory BRAM storage order specified by the user. That is, the edited data is rearranged according to the actual physical memory storage order, ensuring that the hexadecimal data in the logical EMB data is consistent with the storage order in the physical memory BRAM. The first configuration data is the initial configuration of the physical memory BRAM, defining the BRAM storage structure and its initial values. After the adjusted third configuration data is mapped and converted into the fourth configuration data, the modified fourth configuration data is written back to the BRAM in the FPGA chip via the JTAG interface, overwriting the first configuration data (the BRAM initialization value) and performing verification to ensure that the new physical memory BRAM data is accurately reflected in the hardware.

[0074] It is worth mentioning that during the verification process, the editing tool reads the BRAM data in the FPGA chip and ensures that it is consistent with the user's expected data. If the verification is successful, the modified content is permanently saved to the FPGA chip.

[0075] The architecture in this application scenario can implement the online editing process in FPGA design and debugging, realize online configuration of FPGA chips through the JTAG interface, avoid the process of re-downloading the bitstream, and provide flexible data editing and verification functions.

[0076] Next, a method for online editing of FPGA memory provided in an embodiment of the present application is introduced.

[0077] Figure 2 Shown in the figure is a flow chart of a method for online editing of FPGA memory provided by an embodiment of the present application. It can be understood that the method can be executed by any device, equipment, platform, or computing device cluster with computing and processing capabilities. Exemplarily, the method can be executed by a device for online editing of FPGA memory (Chip Editor), wherein the device can be implemented by software and / or hardware, and can be, but is not limited to, configured in a computing device cluster comprising at least one computing device, typically, it can be configured in a server. For ease of description, this embodiment will be described as taking any one computing device in the computing device cluster as the execution subject. As Figure 2 As shown, the method may include the following steps:

[0078] S101. When the FPGA is in user mode, obtain first configuration data of the FPGA's physical memory BRAM, where the first configuration data includes the physical layout position and occupied space size of the physical memory BRAM; user mode indicates that the FPGA enters an operating state to execute configured functions.

[0079] It is understandable that before starting online editing, the following working scenario is required: the user uses the current project, has used EDA software to generate a bitstream (also called a bitstream file), and downloaded the bitstream to the FPGA chip, and the FPGA chip is in normal working condition.

[0080] Exemplarily, in this step, the user first launches EDA software, such as ChipEditor, and loads a completed layout and routing FPGA project file. It should be noted that the JTAG interface remains connected during online editing in the ChipEditor. The physical memory BRAM to be edited is selected in the ChipEditor; and first configuration data for the physical memory BRAM is obtained via the JTAG interface.

[0081] Specifically, within the EDA software's main interface, users can click the "Layout View" button to open the layout UI (user interface). The UI displays the physical layout of various resources on the FPGA chip, including logic units, DSP modules, I / O modules, and storage resources such as BRAM. Users can zoom and pan to locate the BRAM area they want to edit.

[0082] In the layout UI tool, BRAM resources are typically displayed with a specific color or icon. Users can select the target BRAM by clicking the mouse. After selecting a BRAM, the system highlights the BRAM and displays its detailed information (primary configuration data) in the properties panel. This primary configuration data includes the physical layout location and occupied space of the physical memory BRAM, such as physical location coordinates, BRAM type, and capacity. After the user confirms that the BRAM to be edited is selected, they can access the online BRAM editing tool interface through the right-click menu or the "Online Edit" option in the toolbar. The Chip Editor then retrieves the first configuration data of the selected BRAM from the FPGA chip via the Jtag interface. Optionally, the first configuration data also includes the BRAM type identifier and the BRAM's index number within the chip. This allows the original FPGA project to be loaded into the Chip Editor, displaying the actual physical layout location and occupied space of the resources used in the original FPGA project. The Chip Editor can also locate all instance names containing the physical memory BRAM keyword and instance name in the original FPGA RTL design. This information is used to accurately locate and access the target BRAM via the Jtag interface.

[0083] In the chip editor, load the original FPGA project layout and routing results file. This file contains descriptions of various resources used in the FPGA design (such as logic cells, memory, inputs and outputs, etc.). After loading the original project, the chip editor automatically displays the actual physical layout location of the FPGA resources and the space they occupy. Developers can clearly see the distribution of various resources in the FPGA design, allowing them to more accurately locate the location and size of the physical memory BRAM. In the original RTL design, developers need to search for all instance names containing the physical memory BRAM keyword and instance name. In RTL (Register Transfer Level) designs, hardware modules (such as BRAM) are typically identified by keywords or specific instance names. By searching these instance names, the system can accurately identify all relevant physical memory BRAM modules. After finding the target BRAM instance, combined with the physical layout information displayed in the chip editor, the system retrieves the corresponding physical memory BRAM's first configuration data through the JTAG interface. This data includes the BRAM's specific configuration, occupied memory space, storage content, access methods, and other information. This data provides the basis for subsequent modification, optimization, and debugging.

[0084] S102 : Map the first configuration data to second configuration data in a logical EMB format according to the physical layout position and occupied space size of the physical memory BRAM.

[0085] In this step, the first configuration data of the physical memory BRAM is mapped to the logic EMB instantiated in the RTL design through conversion logic; wherein the conversion logic indicates a mapping relationship between the first configuration data and the second configuration data, and the logic EMB instantiated in the RTL design indicates the second configuration data.

[0086] Specifically, the BRAM editing tool reads the entire physical block of data currently in the BRAM via JTAG. Through conversion logic, the data in the physical BRAM is mapped to the logical EMB instantiated in the RTL, ensuring that the BRAM capacity displayed in the editing interface is consistent with the actual logical EMB instantiated by the user. It is worth noting that in FPGA design, the actual instantiated logical EMB (Block RAM) refers to the BRAM module that is actually instantiated and configured in the RTL (Register Transfer Level) design. In hardware, BRAM is a specific type of memory cell, typically used for data storage, cache, or temporary variables during calculations. The actual instantiated logical EMB refers to the BRAM cell explicitly created in the design and configured for use in the design tool or hardware. During the instantiation process, the BRAM configuration is also determined. For example, parameters such as the BRAM size, bit width, and number of address bits are set during instantiation. These parameters determine how the BRAM is implemented in hardware. Configuration can be specified based on design requirements: Size, for example, defines the BRAM depth (i.e., the number of data cells it can store) and width (the number of bits per data cell). Initialization content: BRAMs can be configured to initialize with certain initial data or remain empty. Timing parameters: These parameters include clock frequency, read and write timing, and so on. During synthesis and implementation, design tools map the actual instantiated logical EMBs to physical resources in the FPGA. Layout tools select appropriate hardware resources to implement these BRAMs based on the size and configuration of the BRAM instances.

[0087] Optionally, mapping to the logical EMB instantiated in the RTL design includes extracting hexadecimal data of the physical memory BRAM to be edited from the third configuration data according to the logical EMB format of the third configuration data, with each row of data corresponding to an address in the physical memory BRAM. For example, the first row corresponds to address 0 in the physical memory BRAM, and the second row corresponds to address 1 in the physical memory BRAM. The third configuration data is stored in EMB format and contains hexadecimal data to be written to the physical memory BRAM. Each data item corresponds to a storage cell (typically a storage address) in the BRAM. The hexadecimal value of each row is extracted from the configuration data. Each row represents a BRAM address and its corresponding data value. Each extracted row of data is mapped to a specific address in the physical memory BRAM. For example, the first row of data in the configuration file (e.g., 0xABCD1234) is mapped to address 0 in the BRAM, the second row to address 1, and so on. This mapping method ensures that each BRAM address in the RTL design is accurately configured, ensuring data accuracy and efficiency.

[0088] For example, Figure 3 FIG. 1 shows a schematic diagram of a data mapping process of an FPGA chip H3 provided in an embodiment of the present application. Figure 3 For example, in chip H3, the physical structure is a BRAM36KV1 (36KB capacity). Assume that the user's RTL actually uses four independent EMBs (data width: 16, depth: 512) and instantiates them using EMB9K (EMB9K represents a logical embedded memory block with a capacity of 9KB). After layout, the four EMB9Ks are combined into a single BRAM36KV1 based on capacity. In ChipEditor, the user can map the EMB instance names (e.g., emb_inst0, emb_inst1, etc.) to the EMBs instantiated in the RTL.

[0089] Specifically, after the BRAM editing tool is started, it first establishes a JTAG connection with the FPGA chip. The JTAG connection uses the standard IEEE 1149.1 protocol and communicates with the FPGA chip through four signal lines: TCK, TMS, TDI, and TDO.

[0090] Based on the BRAM location information obtained in step 1, the BRAM editing tool constructs a JTAG instruction sequence, specifying the BRAM address to be accessed. It then sends a read command via the JTAG interface to read all data from the target BRAM in the order in which it is physically stored. For BRAM36KV1, the tool reads all 36K bits of data.

[0091] After reading, the BRAM editing tool needs to perform data format conversion to map the physical BRAM data back to the logical EMB format used in the user's RTL design. This conversion process is based on the mapping relationship recorded in the layout results. Figure 3 In the example, the data in the physical BRAM36KV1 needs to be split into 4 logical EMB9K data.

[0092] During the conversion process, the BRAM editing tool identifies which bits in the physical BRAM correspond to which logical EMB based on the layout information and reorganizes the data according to the data width and depth of the logical EMB. For example, for four 16-bit wide and 512-bit deep EMB9K, the tool will reorganize the 36K bits of physical data into four independent 16×512-bit data blocks.

[0093] The read data is displayed according to the original data bit width and depth of EMB. For example, in this example, EMB is 16×512, and binary display is 16 columns and 512 rows of data; hexadecimal display is 4 columns and 512 rows of data.

[0094] Specifically, after completing data mapping, the BRAM editing tool displays the contents of each logical EMB in a table format on the interface. Users can select the data display format, such as binary or hexadecimal. For an EMB with a width of 16 bits and a depth of 512 bits, if binary display mode is selected, a 16-column, 512-row table will be displayed on the interface, with each cell displaying a 0 or 1; if hexadecimal display mode is selected, a 4-column, 512-row table will be displayed, with each cell displaying a hexadecimal digit (0-F).

[0095] The editing interface also displays each EMB's identification information, such as the instance name, data width, and depth in the RTL, to help users identify the logical EMB currently being edited. Row and column numbers are also provided to facilitate locating specific data locations.

[0096] The horizontal splicing of EMB9K is achieved by sharing address lines and control signals. The address range of each EMB9K is mapped to the continuous address space of BRAM36KV1, for example:

[0097] emb_inst0: Address 0x0000-0x01FF

[0098] emb_inst1: Address 0x0200-0x03FF

[0099] And so on.

[0100] ChipEditor parses the netlist and chip architecture database (such as netlist files) in EDA tools, associates RTL instance names with physical unit coordinates, and provides a visual interface to display data distribution.

[0101] S103 : In response to the user's online editing operation on the second configuration data, obtain edited third configuration data in a logical EMB format.

[0102] Specifically, users can modify data directly in the table interface of the BRAM editing tool. Users can select the cell to be modified by clicking the mouse and then enter the new value. In binary display mode, users can only enter 0 or 1; in hexadecimal display mode, users can enter characters 0-9 and A-F.

[0103] The editing tool provides a variety of editing functions, including single cell editing, range selection editing, copy and paste, and filling with specific values. Users can select a range and perform batch operations, such as setting the entire selected range to a specific value or performing bit operations (such as bit inversion, bitwise AND, bitwise OR, etc.).

[0104] The editing tool also provides data validation to ensure that the data entered by the user complies with the format requirements. For example, in hexadecimal mode, if the user enters an illegal character (such as GZ), the system will prompt an error and refuse to accept the input.

[0105] Users can switch to different EMBs for viewing and editing at any time. The editing tool will maintain the editing status of each EMB until the user confirms and submits the changes.

[0106] S104: Map the third configuration data in the logical EMB format into the updated fourth configuration data of the physical memory BRAM.

[0107] In this step, after the editing is completed, each logical EMB is spliced ​​into the physical storage order according to the splicing logic order of EMB to BRAM36KV1, and then the data is written back to the chip memory through JTAG.

[0108] Specifically, after the user completes all data modifications and confirms submission, the BRAM editing tool first performs data conversion from the logical EMB to the physical BRAM. This process is the reverse process of the data mapping in step S102, recombining the modified multiple logical EMB data into the storage format of the physical BRAM.

[0109] In this example, the editing tool needs to reassemble the four modified 16×512-bit EMB9K data into a 36K-bit BRAM36KV1 data block according to the mapping relationship recorded in the layout results. This process requires accurately placing each bit of data in each logical EMB to the correct location in the physical BRAM.

[0110] S105 , writing the updated fourth configuration data of the physical memory BRAM back to the FPGA to overwrite the first configuration data and then performing testing and verification.

[0111] In this step, after the data conversion is complete, the editing tool sends a write command to the FPGA via the JTAG interface. First, the tool sends a JTAG instruction sequence, specifying the BRAM address to be written, followed by the complete converted data block. The JTAG controller writes the data to the specified physical BRAM, overwriting the original contents.

[0112] During the write process, the editing tool displays a progress indicator to let the user know the completion status of the write operation. After the write is complete, the tool performs a verification operation, reading the BRAM contents again and comparing them with the expected value to ensure that the data has been written correctly.

[0113] Optionally, when the Jtag write operation is completed and verified to be correct, the BRAM editing tool will display a message to the user indicating that the operation was successful. At this point, the BRAM content in the FPGA chip has been updated, but the chip remains in normal working condition without interrupting the operation of the user application. In one embodiment, the editing tool will record detailed information about the editing operation, including the modification time, the modified BRAM location, the data before and after the modification, etc. The user can choose to save this information as a log file for future reference. The user can choose to close the BRAM editing tool, return to the ChipEditor interface, or continue to select other BRAMs for editing. The entire online editing process does not require the regeneration of the bitstream or the reconfiguration of the entire FPGA chip, which greatly improves the efficiency of debugging and modification.

[0114] The method for online editing of FPGA memory provided by this application has the following advantages: users can modify the data in BRAM online without exiting user mode. The data can be modified under normal working conditions to ensure the current working status of the chip; users do not need to use JTAG to re-download the code stream data of the entire chip, saving download time.

[0115] The above is an introduction to a method for online FPGA memory editing provided by an embodiment of the present application. Based on the above, the technical solution of this application is described in detail below using specific embodiments. The following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0116] Example 1

[0117] Figure 4 The flowchart of a method for online editing of FPGA memory provided by Example 1 of the present application is shown. Before starting online editing, the method requires the following working scenario: the user uses the current project, has used EDA software to generate a code stream, and has downloaded the code stream to the chip, and the chip is in normal working condition; ensure that the Jtag is always connected during the online editing process. Figure 4 As shown, the method may include the following steps:

[0118] Step 1: Select the BRAM to be edited in ChipEditor.

[0119] Specifically, after launching the EDA software and opening the current project, the user enters the ChipEditor interface. In ChipEditor, various FPGA chip resources are graphically displayed, including logic units, DSPs, I / O, and BRAMs. Users can zoom and pan to navigate the chip layout and locate the BRAM resources they need to edit.

[0120] ChipEditor provides multiple search methods. Users can filter by resource type to display only BRAM resources, or directly search for a specific BRAM by RTL instance name. Once the user finds the target BRAM, click it to select it. The system will highlight the selected BRAM and display its detailed information in the Properties panel.

[0121] Step 2: Read the data in the physical memory through Jtag.

[0122] Specifically, after selecting the target BRAM, the user launches the BRAM editing tool through the right-click menu or the "Online Edit" option in the toolbar. The editing tool first checks the Jtag connection status to ensure normal communication with the FPGA chip.

[0123] The editing tool then sends a specific instruction sequence to the FPGA via the Jtag interface, placing the FPGA in a special access mode. In this mode, data in the internal BRAM can be directly read without affecting the normal functioning of the chip. This specific instruction sequence is known from the prior art and will not be described here.

[0124] The editing tool constructs a Jtag read command based on the physical location information of the selected BRAM, specifying the BRAM address to be accessed. Then, the read command is sent through the Jtag interface to read all the data in the target BRAM in the physical storage order.

[0125] The amount of data read varies for different BRAM types. For example, for a BRAM36KV1, the tool reads all 36K bits of data; for a BRAM18K, it reads only 18K bits. During the read process, the editing tool displays a progress indicator to let the user know the completion status of the read operation.

[0126] Step 3: Based on the layout result, map the data in the physical memory to the logical EMB format.

[0127] Specifically, after reading the physical BRAM data, the editing tool needs to perform data format conversion to map the physical BRAM data back to the logical EMB format used in the user's RTL design. This conversion process is based on the mapping relationship recorded in the layout results.

[0128] In FPGA design, the embedded memory blocks (EMBs) instantiated in the RTL code may be organized differently from the physical BRAMs. For example, the user may instantiate multiple small-capacity EMBs in the RTL, but in the physical implementation, these EMBs are merged into one or more large-capacity physical BRAMs.

[0129] The editing tool (ChipEditor) first reads the mapping relationship from the layout database to determine which bits in the physical BRAM correspond to which logical EMB. Then, the tool reorganizes the read physical data into data for multiple logical EMBs according to these mapping relationships.

[0130] For example, if a BRAM36KV1 physically contains four user-instantiated EMB9Ks (each EMB9K is 16 bits wide and 512 bits deep), the editing tool will split the 36K bits of physical data into four independent 16×512-bit data blocks, each corresponding to a logical EMB.

[0131] After conversion, the editing tool displays the contents of each logical EMB in a table format on the interface. Users can choose to view the data in binary or hexadecimal format. The interface also displays identification information for each EMB, such as the instance name in RTL, data width, and depth, to help users identify the logical EMB they are currently viewing.

[0132] Step 4: In response to the user editing the data in the EMB online, the logical EMB is mapped into the physical memory BRAM format through the online tool.

[0133] Specifically, after the user modifies the data in the editing interface, when the user confirms and submits the modification, the editing tool needs to perform data conversion from the logical EMB to the physical BRAM. This process is the reverse process of the data mapping in step 3.

[0134] The editing tool first collects all modified logical EMB data and then reassembles this data into the storage format of the physical BRAM based on the mapping relationship recorded in the layout results. This process requires accurately placing each bit of data in each logical EMB into the correct location in the physical BRAM.

[0135] For example, given four modified 16×512-bit EMB9K data blocks, the editing tool needs to reassemble them into a 36K-bit BRAM36KV1 data block in a specific order and position. This reassembly process may involve bit rearrangement and splicing, depending on the internal structure of the physical BRAM and the implementation of the layout tool.

[0136] During the conversion process, the editing tool performs data validity checks to ensure that the converted data meets the requirements of the physical BRAM. If any problems are found, the tool will prompt the user with an error message and allow the user to correct them and submit again.

[0137] Step 5: Rewrite the chip memory through Jtag.

[0138] Specifically, after the data conversion from the logical EMB to the physical BRAM is completed, the editing tool sends a write command to the FPGA through the JTAG interface. First, the tool sends a JTAG instruction sequence, specifies the BRAM address to be written, and then sends the complete converted data block.

[0139] The JTAG controller writes the data to the specified physical BRAM, overwriting the original contents. During the writing process, the editing tool will display a progress indicator to let the user know the completion status of the write operation.

[0140] After writing is complete, the editing tool will perform a verification operation, reading the BRAM contents again via JTAG and comparing them to the expected value to ensure that the data has been written correctly. If the verification passes, the tool will display a message to the user indicating that the operation was successful; if the verification fails, the tool will prompt an error message and allow the user to choose to retry or cancel the operation.

[0141] After the write operation is completed, the BRAM content in the FPGA chip has been updated, but the chip remains in normal working state without interrupting the operation of the user application. The user can immediately observe the impact of the modified BRAM content on the application behavior.

[0142] It is understandable that the size of the serial number of each step in the above-mentioned embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, the steps in the above-mentioned embodiments can be selectively executed according to actual conditions, and can be partially executed or fully executed, which is not limited here. In addition, all or part of any features of any of the above-mentioned embodiments can be freely and arbitrarily combined without contradiction; the combined technical solutions are also within the scope of this application.

[0143] like Figure 5 As shown, an embodiment of the present application further provides an apparatus 300 for online editing of FPGA memory, comprising: an acquisition module 301 and a processing module 302. The acquisition module 301 is configured to acquire first configuration data of the physical memory BRAM of the FPGA, the first configuration data including the physical layout position and occupied space size of the physical memory BRAM; the processing module 302 is configured to map the first configuration data to second configuration data in a logical EMB format according to the physical layout position and occupied space size of the physical memory BRAM; in response to a user's online editing operation on the second configuration data, acquire the edited third configuration data in the logical EMB format; map the third configuration data in the logical EMB format to updated fourth configuration data of the physical memory BRAM; and write the updated fourth configuration data of the physical memory BRAM back to the FPGA, overwriting the first configuration data, and then performing testing and verification.

[0144] In one possible implementation, the acquisition module 301 is used to obtain the first configuration data of the physical memory BRAM of the FPGA, specifically for: in response to the user selecting the physical memory BRAM to be edited in the chip editor, obtaining the first configuration data of the physical memory BRAM according to the Jtag interface.

[0145] In one possible implementation, the acquisition module 301 is used to obtain the first configuration data of the physical memory BRAM of the FPGA, and is also specifically used to: load the original FPGA project in the chip editor, display the actual physical layout location and occupied space size of the resources used by the original FPGA project; and search for all instance names containing the physical memory BRAM keyword and instance name in the original FPGA RTL design.

[0146] In one possible implementation, the processing module 302 is used to map the first configuration data to second configuration data in a logical EMB format based on the physical layout position and occupied space size of the physical memory BRAM, specifically to: map the first configuration data of the physical memory BRAM to the logical EMB instantiated in the RTL design through conversion logic; wherein the conversion logic indicates a mapping relationship between the first configuration data and the second configuration data, and the logical EMB instantiated in the RTL design indicates the second configuration data.

[0147] In one possible implementation, the processing module 302 is used to map to the logical EMB instantiated in the RTL design, specifically to: extract the hexadecimal data of the physical memory BRAM to be edited from the third configuration data according to the logical EMB format of the third configuration data, where each line of data corresponds to an address of the physical memory BRAM.

[0148] In one possible implementation, the processing module 302 is used to respond to the user's online editing operation on the second configuration data, obtain the edited third configuration data in the logical EMB format, and is specifically used to: adjust the arrangement order of the hexadecimal data according to the order of each physical memory BRAM edited by the user, so that it correctly corresponds to the physical actual storage order in the first configuration data of the physical memory BRAM.

[0149] In one possible implementation, the processing module 302 is configured to write the updated fourth configuration data of the physical memory BRAM back to the FPGA, specifically to write the fourth configuration data back to the physical memory BRAM of the FPGA through a Jtag interface.

[0150] It should be understood that both the acquisition module 301 and the processing module 302 can be implemented by software or hardware. For example, the implementation of the acquisition module 301 will be described below using the acquisition module 301 as an example. Similarly, the implementation of the processing module 302 can refer to the implementation of the acquisition module 301.

[0151] As an example of a software functional unit, the acquisition module 301 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the acquisition module 301 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0152] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0153] As an example of a hardware functional unit, acquisition module 301 may include at least one computing device, such as a server. Alternatively, acquisition module 301 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a CPLD, FPGA, GAL, or any combination thereof.

[0154] The multiple computing devices included in acquisition module 301 can be distributed in the same region or in different regions. The multiple computing devices included in acquisition module 301 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in acquisition module 301 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0155] It should be understood that the above-mentioned device is used to execute the method in the above-mentioned embodiment. The implementation principle and technical effect of the corresponding program module in the device are similar to those described in the above-mentioned method. The working process of the device can refer to the corresponding process in the above-mentioned method and will not be repeated here.

[0156] The present application also provides a computer-readable storage medium. The computer-readable storage medium is used to store computer program instructions. When the computer program instructions are executed on a computing device, the computing device executes the data processing method involved in the above embodiment. The computer-readable storage medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive).

[0157] The present application also provides a computer program product comprising instructions. The computer program product may be software or a program product comprising instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the data processing method.

[0158] Finally, it should be noted that the above embodiments are merely illustrative of the technical solutions of the present application. Those skilled in the art should understand that, although the present application has been described in detail with reference to the aforementioned embodiments, the technical solutions described in the aforementioned embodiments may be modified or some of the technical features thereof may be replaced with equivalents. However, such modifications or replacements do not deviate from the spirit and scope of the technical solutions in the various embodiments of the present application.

Claims

1. A method for online editing of FPGA memory, characterized in that: include: When the FPGA is in a user mode, first configuration data of a physical memory BRAM of the FPGA is obtained, where the first configuration data includes a physical layout position and an occupied space size of the physical memory BRAM; the user mode indicates that the FPGA enters an operating state for executing a configured function; Mapping the first configuration data to second configuration data in a logical EMB format according to the physical layout position and occupied space size of the physical memory BRAM; In response to a user's online editing operation on the second configuration data, acquiring edited third configuration data in a logical EMB format; Mapping the third configuration data in the logical EMB format into the updated fourth configuration data of the physical memory BRAM; The updated fourth configuration data of the physical memory BRAM is written back to the FPGA to overwrite the first configuration data and then tested and verified.

2. The method according to claim 1, characterized in that The obtaining of first configuration data of a physical memory BRAM of the FPGA includes: In response to a user selecting a physical memory BRAM to be edited in a chip editor, first configuration data of the physical memory BRAM is acquired according to a Jtag interface.

3. The method according to claim 2, characterized in that The obtaining of first configuration data of the physical memory BRAM of the FPGA further includes: Load the layout and routing result file after the original FPGA project runs, and display the actual physical layout position and occupied space size of the resources used in the layout and routing result file after the original FPGA project runs. Find all instance names that contain the physical memory BRAM keyword and instance name in the original FPGA RTL design.

4. The method according to any one of claims 1 to 3, characterized in that The mapping of the first configuration data to second configuration data in a logical EMB format according to the physical layout position and the occupied space size of the physical memory BRAM includes: The first configuration data of the physical memory BRAM is mapped to the logic EMB instantiated in the RTL design through the conversion logic; wherein the conversion logic indicates the mapping relationship between the first configuration data and the second configuration data, and the logic EMB instantiated in the RTL design indicates the second configuration data.

5. The method according to claim 4, characterized in that The first configuration data also includes a BRAM type identifier and an index number of the BRAM in the chip.

6. The method according to claim 4, characterized in that The mapping to the logic EMB instantiated in the RTL design includes: According to the logical EMB format of the third configuration data, hexadecimal data of the physical memory BRAM to be edited is extracted from the third configuration data, and each line of data corresponds to an address of the physical memory BRAM.

7. The method according to claim 6, characterized in that The step of obtaining the edited third configuration data in the logical EMB format in response to the user's online editing operation on the second configuration data includes: According to the order of each physical memory BRAM edited by the user, the arrangement order of the hexadecimal data is adjusted so as to correctly correspond to the actual physical storage order in the first configuration data of the physical memory BRAM.

8. The method according to claim 1, characterized in that Writing the updated fourth configuration data of the physical memory BRAM back to the FPGA includes: The fourth configuration data is rewritten into the physical memory BRAM of the FPGA through the Jtag interface.

9. The method according to claim 2 or 8, characterized in that The Jtag interface uses the IEEE 1149.1 protocol for communication, and the Jtag interface uses four signal lines, TCK, TMS, TDI, and TDO, to communicate with the FPGA chip.

10. A device for online editing of FPGA memory, characterized in that: include: An acquisition module, configured to acquire first configuration data of a physical memory BRAM of the FPGA, wherein the first configuration data includes a physical layout position and an occupied space size of the physical memory BRAM; A processing module is configured to map the first configuration data to second configuration data in a logical EMB format based on the physical layout position and occupied space size of the physical memory BRAM; obtain edited third configuration data in the logical EMB format in response to a user's online editing operation on the second configuration data; map the third configuration data in the logical EMB format to updated fourth configuration data of the physical memory BRAM; and write the updated fourth configuration data of the physical memory BRAM back to the FPGA to overwrite the first configuration data and then perform testing and verification.

Images