Version management method, fault detection method and prototype version compiling system

Abstract

The invention discloses a version management method, a fault detection method and a prototype version compiling system, and relates to the technical field of chip verifier.The version management method comprises the steps that after compiling is started, whether FPGA prototype version information matched with current version information of a local warehouse is contained in a version storage directory or not is searched; updating FPGA prototype version information according to a search result, wherein the FPGA prototype version information comprises current version information and a suffix version number; and generating version feature information according to the updated FPGA prototype version information, and sending the version feature information to a hardware top layer module to perform fault detection on the FPGA prototype version based on the version feature information, so that the problem that the version information cannot be known in the compiling process of the FPGA prototype verification platform can be solved, the version information can be obtained through an interface when a fault occurs, and the reliability of the FPGA prototype verification platform is improved. And whether the fault is caused by the version is judged, so that the technical effects of reducing the fault tracking and positioning difficulty and improving the verification working efficiency are achieved.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, and in particular to a version management method, a fault detection method, and a prototype version compilation system. Background Technology

[0002] With the continuous development and iteration of integrated circuit technology, the ability of chips to process data and tasks is constantly increasing, and their functions and structures are becoming more and more complex, leading to a sharp increase in chip power consumption. In this context, verification using traditional front-end verification methods requires significant computing resources and design effort, and it is difficult to cover all usage scenarios, failing to fully guarantee the effectiveness of ASIC designs and meet the needs of collaborative development of corresponding driver software. Against this backdrop, the emergence of FPGA prototyping platforms offers a solution to these problems. These platforms aim to equivalently simulate the hardware environment of ASIC designs, helping ASIC designers improve design stability and providing software developers with a realistic physical platform to accelerate chip time-to-market.

[0003] However, in the existing technology, the design repository version information corresponding to the FPGA prototype version is not visible during the debugging process of the FPGA prototype verification platform. Once a problem occurs in the configuration process of the debugging environment, it is impossible to confirm whether the problem is caused by the FPGA prototype version or the design repository version, thereby increasing the difficulty of fault tracking and location during the version debugging process and reducing the efficiency of chip verification. Summary of the Invention

[0004] This application provides a version management method, a fault detection method, and a prototype version compilation system to at least solve the problem of not being able to know the version information corresponding to the FPGA verification platform.

[0005] This application provides a version management method applied to a dynamic version number generation engine of an FPGA prototype version compilation system. The FPGA prototype version compilation system further includes a hardware top-level module. The method includes: after starting compilation, obtaining the current version information of the local repository of the design repository, and searching the version storage directory for whether it contains FPGA prototype version information that matches the current version information; updating the FPGA prototype version information according to the search results, wherein the updated FPGA prototype version information includes the current version information and a suffix version number; generating version feature information based on the updated FPGA prototype version information, and sending the version feature information to the hardware top-level module so that the hardware top-level module can perform fault detection on the FPGA prototype version based on the version feature information.

[0006] This application also provides a fault detection method applied to the top-level hardware module of an FPGA prototype version compilation system. The FPGA prototype version compilation system further includes a dynamic version number generation engine. The method includes: receiving version feature information sent by the dynamic version number generation engine, and compiling an FPGA prototype verification platform corresponding to the FPGA prototype version based on the version feature information. The version feature information is determined by the dynamic version number generation engine based on the updated FPGA prototype version information. When a fault occurs in the configuration process of the debugging environment corresponding to the FPGA prototype verification platform, the version feature information is obtained based on the preset interface of the FPGA prototype verification platform. The version feature information is used to determine whether the FPGA prototype version has been successfully loaded. If the loading is successful, the FPGA prototype version is determined to be without fault.

[0007] This application also provides a prototype version compilation system, the system comprising: a dynamic version number generation engine for executing the version management method of the first aspect or any corresponding embodiment thereof; and a hardware top-level module connected to the dynamic version number generation engine for executing the fault detection method of the second aspect or any corresponding embodiment thereof.

[0008] This application describes a method where, after compilation begins, the dynamic version number generation engine in the prototype version compilation system obtains the current version information from the local repository of the design repository and searches the version storage directory for FPGA prototype version information that matches the current version information. Based on the search results, the FPGA prototype version information is updated, including the current version information and a suffix version number. Version feature information is then generated based on this information. This allows the top-level hardware module in the prototype version compilation system to obtain version feature information via a preset interface when the configuration process of the debugging environment fails during compilation. The version feature information is then used to determine whether the FPGA prototype version has malfunctioned. Therefore, this solves the problem of not being able to obtain version information during the compilation process of the FPGA prototype verification platform. By embedding version information into the FPGA's hardware logic, the authenticity and immutability of the version information are ensured, providing a reliable data source for interface queries. The interface provides a standardized channel for external access to version information, enabling the acquisition of version information through the interface when a fault occurs, determining whether the fault is caused by the version, thereby reducing the difficulty of fault tracking and location and improving the efficiency of verification work. Attached Figure Description

[0009] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments 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.

[0010] Figure 1 This is a schematic diagram of the existing compilation process; Figure 2 A flowchart illustrating a version management method provided in an embodiment of this application; Figure 3 A structural block diagram of an FPGA prototype version compilation system provided in this application embodiment; Figure 4 A flowchart illustrating another version management method provided in this application embodiment; Figure 5 A detailed flowchart illustrating another version management method provided in this application embodiment; Figure 6 This is a flowchart illustrating the fault detection method provided in the embodiments of this application. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0012] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0013] Chip verification is a crucial step in ensuring product yield and cost control. It spans the entire chip design process, from defining chip requirements and developing functional designs to physical implementation and manufacturing. Its main purpose is to ensure that the chip fully achieves the functions and performance specifications stipulated in the design specifications before tape-out.

[0014] As SoC designs grow in scale and complexity, their functionality becomes increasingly sophisticated, and their overall size expands significantly. It's not uncommon for a single chip design to require dozens of Xilinx VU440-level FPGAs. Logic simulation tools are proving inadequate for verifying ASICs with millions of gates. To shorten the verification cycle, FPGA-based prototyping technology has been developed based on traditional simulation verification techniques.

[0015] Due to advancements in FPGA technology and processes, its speed, capacity, and density have significantly increased, while power consumption and cost have continuously decreased, leading to the widespread application of FPGA-based prototyping. FPGA prototyping typically follows front-end RTL design and simulation, verifying the functionality and performance of ASICs, ASSPs, and SoCs by porting the RTL to a Field Programmable Gate Array (FPGA).

[0016] The primary application scenario for FPGA prototyping verification is to build an integrated hardware and software system verification environment during the chip design process. Its main purposes include: ① Before the chip is returned to the wafer, it provides the software team with a platform for debugging software such as Driver and Firmware, which effectively supports the pre-development and debugging of software and accelerates the software development speed; ② As an effective supplement to chip simulation verification, the simulation speed is 4 to 6 orders of magnitude faster than the software simulation speed, and it can provide a real hardware verification environment and higher verification accuracy and performance; ③ It can provide more realistic interface simulations, such as commonly used UART, I2C, QSPI, JTAG, etc.

[0017] The advantages of FPGA prototyping mainly lie in its unique, ultra-large-scale hardware structure, which ensures the integrity of RTL design as much as possible. The platform runs at MHz speed, uses general configuration and debugging software, has a debugging environment similar to a simulator, supports network access and multi-user systems, has a fully automated software setup process, requires almost no modification to hardware connection configuration, and has flexible and diverse full-system simulation and debugging capabilities.

[0018] like Figure 1 As shown, following the current FPGA prototype version compilation process, after starting compilation, the compilation task is submitted, and the user enters their personal workspace. Staff manually upgrade the local design repository to the latest release version. Based on this, the compilation environment is configured, including the compiler version, library file paths, baseline usage of various basic hardware resources, design version path, compilation parameter settings, partitioning strategy, timing constraints, etc. After configuration, the version compiler is started. During the compilation process, log files such as version compilation execution process and timing reports are generated, thus completing the compilation task and ending the compilation.

[0019] It is evident that during the debugging process of teams such as CVV, Driver, and Firmware, the design repository version information corresponding to the FPGA prototype version is not visible. If a problem occurs in the configuration process of the debugging environment, it is impossible to confirm whether the FPGA prototype version has been loaded successfully, including the consistency and correctness between the FPGA prototype version and the design version. This increases the difficulty of fault tracking and location during version debugging and reduces the efficiency of verification work.

[0020] Explanation of key terms involved: Product yield: Yield, also known as "pass rate", is one of the product quality indicators, referring to the percentage of qualified products out of all processed products; Tape-out: refers to the manufacturing of chips through a series of process steps, like an assembly line. In the field of integrated circuit design, "tape-out" means "trial production". FPGA prototyping: Used to verify the functionality and performance of ASICs, ASSPs, and SoCs by porting RTLs to field-programmable gate arrays (FPGAs); FPGA: Field Programmable Gate Array, is a product of further development based on traditional programmable devices. FPGA emerged as a semi-custom circuit in the field of Application-Specific Integrated Circuits (ASICs), addressing the shortcomings of custom circuits while overcoming the limitation of the limited gate count of traditional programmable devices. RTL: Register Transfer Level, in integrated circuit design, is an abstract description of the operation of synchronous digital circuits; ASIC: Application Specific Integrated Circuit, refers to an integrated circuit designed and manufactured to meet the specific requirements of a user and the needs of a specific electronic system; ASSP: Application Specific Standard Parts; SoC: System on Chip, refers to a product, an integrated circuit with a specific purpose, which contains a complete system and all the embedded software. Driver: A driver is a software program that enables communication and interaction between the operating system and hardware devices. Drivers act as a bridge between the operating system and hardware devices, enabling them to understand and cooperate with each other. Firmware: Firmware is generally stored in the FLASH chip or electrically erasable programmable ROM (EEPROM) in the device, and can be upgraded by the user through a specific flashing program; CVV: Chip Verification and Validation, is performed during the chip design phase. Its main goal is to ensure the correctness of the design in terms of functionality, performance, timing, and power consumption before tape-out. It is usually performed in a simulation or prototyping environment. Xilinx is a leading global provider of complete programmable logic solutions. UART: Universal Asynchronous Receiver / Transmitter, is a universal serial data bus used for asynchronous communication. This bus enables bidirectional communication and can achieve full-duplex transmission and reception. I2C: Inter-integrated Circuit, is a synchronous, half-duplex communication bus; QSPI: QSPI is short for Quad SPI, which stands for 6-wire SPI. It is an extension of the SPI interface introduced by Motorola. JTAG: Joint Test Action Group, primarily used for internal chip testing; ASCII: American Standard Code for Information Interchange, is a computer encoding system based on the Latin alphabet, primarily used to display modern English and other Western European languages.

[0021] The version management method provided in this application dynamically updates version information during the compilation process to determine whether there are faults caused by the version, thereby reducing the difficulty of fault tracking and location during version debugging.

[0022] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. The specific application environment architecture or specific hardware architecture on which the version management method depends will be described here.

[0023] Embodiments of this application provide a version management method that can be used in the dynamic version number generation engine of an FPGA prototype version compilation system. The FPGA prototype version compilation system further includes: a top-level hardware module. Figure 2 This is a flowchart of a version management method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps: Step S201: After starting compilation, obtain the current version information of the local repository of the design repository, and search the version storage directory for FPGA prototype version information that matches the current version information.

[0024] Specifically, in the embodiments of this application, in the FPGA prototype version compilation system, compilation is the core link connecting software design and hardware implementation. Its essence is to transform abstract design logic and version information into configuration data that can be physically executed by the FPGA, while ensuring the compatibility of the design with hardware resources and version management requirements. To embed version information into the FPGA hardware through the compilation process, it can be viewed during compilation, such as... Figure 3 As shown, a dynamic version number generation engine is built in the FPGA prototype version compilation system, and a version management control unit is built in the top-level hardware module. The dynamic version number generation engine dynamically updates the FPGA version information according to the current version information of the local repository of the design repository, and sends the dynamically updated version feature information to the version management control unit of the top-level hardware module, which then completes the version query.

[0025] In some alternative implementations, such as Figure 3 As shown, the dynamic version number generation engine includes a design repository version information retrieval unit, a design repository version information verification unit, an FPGA version matching unit, a dynamic version number generation unit, a version information encoding unit, and a version information macro definition parameter generation unit. After a user submits a compilation task, the FPGA prototype version compilation system automatically activates the design repository version information retrieval unit. This unit retrieves the current version information of the local design repository. In the FPGA prototype version compilation system, the local design repository refers to the local version control repository for memory chip design-related files (such as RTL code, design constraints, documents, etc.), and is the core carrier for the design team to develop, modify, and manage versions in their local workspace. Therefore, the local design repository is the source of the entire version management. The design repository version information retrieval unit queries the current version information of the local design repository in the workspace (such as the tag "V2.1.0" and the branch "dev") through scripts to determine which design version is currently being used to generate the FPGA prototype verification platform, ensuring a strong version binding between the FPGA prototype verification platform and the design files. For example, if the design repository is based on Git management, a pre-defined script calls the git command: executing `git describe --abbrev=0 --tags` to retrieve the latest tag version. For instance, if the retrieved tag version is V2.1.0, it contains the major version number 2, the branch version number 1, and the patch version number 0. The information from the tag version is then combined according to a pre-defined format to obtain structured current version information, such as: major version number.branch version number.patch version number-branch name (e.g., 2.1.0-dev).

[0026] In some optional implementations, after the design repository version information retrieval unit obtains the current version information of the local design repository, it transmits it to the design repository version information verification unit for version verification. If the verification passes, the current version information is transmitted to the FPGA version matching unit, which searches a pre-set version storage directory to determine if it contains FPGA prototype version information that matches the current version information. The version storage directory contains previously compiled and archived FPGA prototype version information, which in turn contains the version information of the local design repository used during compilation. Therefore, the current version information of the local design repository used in this compilation process is used as key information. The system searches the version storage directory, traversing all archived FPGA prototype version information, extracting the version identifier corresponding to the local design repository, and determining whether the extracted version identifier contains the current version information.

[0027] Step S202: Update the FPGA prototype version information based on the search results. The updated FPGA prototype version information includes: the current version information and the suffix version number.

[0028] Specifically, in this embodiment, chip design is a continuous optimization process. The design repository, as the core carrier for storing design files, needs to be updated synchronously when the chip undergoes functional iterations, bug fixes, branch development, or requirement changes. For example, after the design team adds a new functional module or optimizes the logic structure, they submit new code modifications to the design repository, thereby generating new design repository version information, such as upgrading from V2.1.0 to V2.2.0. During verification, design defects are discovered, fixed, and then modifications are submitted, generating a patch version, such as updating from V2.1.0 to V2.1.1. Therefore, based on the FPGA prototype version information including the local repository version information, a suffix version number is added. This allows the FPGA version matching unit to update the local repository version information or the suffix version number in the FPGA prototype version information according to the search results in the version storage directory, directly reflecting the local repository version used in the current FPGA prototype and reducing the manual involvement in version management.

[0029] Step S203: Generate version feature information based on the updated FPGA prototype version information, and send the version feature information to the top-level hardware module so that the top-level hardware module can perform fault detection on the FPGA prototype version based on the version feature information.

[0030] Specifically, in this embodiment, after the FPGA version matching unit dynamically updates the FPGA prototype version information based on the search results, it transmits the information to the dynamic version number generation unit. The dynamic version number generation unit extracts the core version elements from the updated FPGA prototype version information and generates version feature information according to the compilation requirements of the hardware top-level module. After the version feature information is sent to the compilation environment configuration unit of the dynamic version number generation engine, the version feature information is integrated with the design logic and hardware constraints of the FPGA prototype during the compilation process. It is then written into the version management control unit of the hardware top-level module through RTL code embedding. After the version management control unit is powered on, the version feature information becomes inherent hardware data.

[0031] In some alternative implementations, when the hardware top-level module malfunctions in the debugging environment, developers can read version feature information from the version management control unit through the preset interface of the hardware top-level module, thereby determining the FPGA version used in the compilation process based on the read version feature information, and determining whether the failure is caused by an FPGA version loading error.

[0032] This application describes a method where, after compilation begins, the dynamic version number generation engine in the prototype version compilation system obtains the current version information from the local repository of the design repository and searches the version storage directory for FPGA prototype version information that matches the current version information. Based on the search results, the FPGA prototype version information is updated, including the current version information and a suffix version number. Version feature information is then generated based on this information. This allows the top-level hardware module in the prototype version compilation system to obtain version feature information via a preset interface when the configuration process of the debugging environment fails during compilation. The version feature information is then used to determine whether the FPGA prototype version has malfunctioned. Therefore, this solves the problem of not being able to obtain version information during the compilation process of the FPGA prototype verification platform. By embedding version information into the FPGA's hardware logic, the authenticity and immutability of the version information are ensured, providing a reliable data source for interface queries. The interface provides a standardized channel for external access to version information, enabling the acquisition of version information through the interface when a fault occurs, determining whether the fault is caused by the version, thereby reducing the difficulty of fault tracking and location and improving the efficiency of verification work.

[0033] Embodiments of this application also provide a version management method, which can be used in the dynamic version number generation engine of an FPGA prototype version compilation system. The FPGA prototype version compilation system further includes: a hardware top-level module. Figure 4 This is a flowchart of a version management method according to an embodiment of this application, such as... Figure 4 As shown, the process includes the following steps: Step S401: After starting compilation, obtain the current version information of the local repository of the design repository, and search the version storage directory for FPGA prototype version information that matches the current version information. For details, please refer to [link to relevant documentation]. Figure 2 Step S201 of the illustrated embodiment will not be described again here.

[0034] Step S402: Determine whether the current version information is the latest version information. If not, upgrade the local repository of the design repository to the latest release version corresponding to the latest version information, and use the latest version information as the current version information.

[0035] Specifically, in the embodiments of this application, such as Figure 5 As shown, after obtaining the current version information from the design repository version information retrieval unit, the design repository version information verification unit retrieves the latest version information corresponding to the latest release from the remote repository and compares the current version information of the design repository with the latest version information to determine whether the current design repository local repository is the latest release. If any of the major version number, branch version number, or patch version number differs between the current version information and the latest version information, it proves that the current design repository local repository is not the latest release, and the design repository local repository is upgraded to the latest release. After the upgrade is completed, the process loops back to the design repository version information retrieval unit to query the current version information of the design repository local repository in the workspace again. After passing the verification, the current version information is then transmitted to the FPGA version matching unit.

[0036] Step S403: Update the FPGA prototype version information based on the search results. The updated FPGA prototype version information includes: the current version information and the suffix version number.

[0037] Specifically, step S403 includes: Step S4031: If the version storage directory contains FPGA prototype version information that matches the current version information, then increment the first suffix version number in the FPGA prototype version information.

[0038] Specifically, in this embodiment, if the version storage directory contains FPGA prototype version information that matches the current version information (i.e., the archived FPGA prototype version information contains the current version information), combined with the pre-verification of the design repository version information verification unit, it is proven that the design repository has not undergone version updates (including no functional iterations, bug fixes, or branch changes). Therefore, this compilation is still performed using the design repository on which the previous compilation was based. Based on this, although the version information in the local design repository remains unchanged, in order to dynamically manage the version according to the compilation process and adapt to adjustments in the compilation environment, only the existing first suffix version number in the FPGA prototype version information is incremented, representing multiple compilations using the same version.

[0039] Step S4032: If not included, generate new FPGA prototype version information based on the current version information. The new FPGA prototype version information includes the second suffix version number.

[0040] Specifically, in this embodiment, if the version storage directory does not contain FPGA prototype version information matching the current version information, combined with pre-verification, it proves that the design repository has been updated. In this case, compilation will be performed based on the updated design repository. Therefore, a second suffix version number is generated, and the current version information and the second suffix version number are framed to obtain the new FPGA prototype version information.

[0041] In some optional implementations, step S4032 above includes: Step a1: Obtain the compilation platform information and working repository information, and generate a second suffix version number based on the compilation platform information and working repository information.

[0042] Step a2: Combine the current version information with the second suffix version number to obtain the new FPGA prototype version information.

[0043] Specifically, in this embodiment, the compilation platform information is a key environmental parameter affecting the compatibility and functionality of the FPGA prototype, including: FPGA chip model and hardware configuration, compilation tool version and configuration, operating system and architecture, etc.; the work repository information is used to distinguish the compilation scenarios of different development teams, working directories or project branches, ensuring that prototypes generated under the same design repository version in different working environments are traceable, including: unique work repository identifier, current working branch and developer information, etc. In this embodiment, the FPGA version matching unit obtains some or all of the key information from the compilation platform information and work repository information, and generates a new second suffix version number based on this, with the serial number in the second suffix version number starting from 1.

[0044] For example, in the application embodiment, after obtaining the compilation platform information and workware information, the compilation platform information is abbreviated: the FPGA model is taken from the core characters (e.g., "xc7k325tffg900-2" -> "K325"); the tool version is taken from the major version number (e.g., "Vivado 2023.1" -> "V231"); the operating system is taken from the abbreviation (e.g., "Ubuntu 20.04 x86_64" -> "U20x64"). The workware information is simplified: the workware ID retains the full name (e.g., "WS001"); the branch name is taken from the keyword (e.g., "feature / uart_debug" -> "UART"); the first compilation sequence number starts from 001, resulting in the second suffix version number: K325_V231_U20x64_WS001_UART_001.

[0045] Furthermore, the FPGA version matching unit frames the current version information with the second suffix version number. For example, if the current version information is V2.2.0_release, this is used as a prefix, and an underscore "_" is used as a separator. The current version information is then concatenated with the newly generated second suffix version number to obtain the new FPGA prototype version information: V2.2.0_release_K325_V231_U20x64_WS001_UART_001. This is just an example and is not a limitation.

[0046] Step S404: Generate version feature information based on the updated FPGA prototype version information, and send the version feature information to the top-level hardware module so that the top-level hardware module can perform fault detection on the FPGA prototype version based on the version feature information.

[0047] Specifically, step S404 includes: Step S4041: Determine the main version number, branch version number, patch version number, and suffix version number based on the updated FPGA prototype version information.

[0048] Specifically, in this embodiment, the dynamic version number generation unit receives the information frame transmitted by the FPGA version matching unit and extracts the major version number, branch version number, patch version number, and suffix version number from the information frame using structured parsing rules. Because the updated FPGA prototype version information follows the framing rule of design repository core version + suffix version number, and the two are connected by a preset separator, the FPGA prototype version information is split into the design repository core version and the suffix version number, and further, the major version number, branch version number, and patch version number are extracted from the design repository core version.

[0049] Step S4042: Obtain timestamp information and generate corresponding version feature information based on the timestamp information, main version number, branch version number, patch version number, and suffix version number according to the preset version naming rules.

[0050] Specifically, in this embodiment, in order to dynamically manage version information, it is necessary to further obtain the timestamp information corresponding to the compilation time. The timestamp is a unique identifier that distinguishes different compilation times under the same version number and the same compilation environment. The dynamic version number generation unit calls the system's underlying clock interface to obtain the system's timestamp information. According to the pre-set FPGA prototype platform version naming rules, it generates corresponding version feature information based on the timestamp information, major version number, branch version number, patch version number, and suffix version number.

[0051] Step S4043: Convert the version feature information into a preset base data stream.

[0052] Specifically, in this embodiment, the version information encoding unit converts the version feature information into a hexadecimal data stream of ASCII code, and then passes it to the version information macro definition parameter generation unit. For example, the string "V2.2.0_release_001_20251019143522" corresponding to the version feature information is converted into the corresponding hexadecimal data sequence: 0x56 0x32 0x2E 0x32 0x2E 0x30 0x5F 0x72....

[0053] Step S4044: Generate macro definition parameters according to the preset base data stream, and transmit the macro definition parameters to the hardware top-level module of the FPGA prototype version compilation system.

[0054] Specifically, in this embodiment, the version information macro definition parameter generation unit generates macro definition parameters for VERSION, DATE, and TIME and their corresponding values ​​based on the received stream data, and passes them to the compilation environment configuration module. The version information macro definition parameter generation unit parses the hexadecimal stream data and calls a character mapping function to convert each hexadecimal value into its corresponding ASCII character, then concatenates them to restore the string corresponding to the original version feature information. For example, the stream data fragment 0x56 0x32 0x2E 0x32 0x2E 0x30 is converted into the character sequence 'V', '2', '.', '2', '.', '0', and then concatenated to form V2.2.0.

[0055] In some optional implementations, based on a structured format of version feature information, three parameters—VERSION, DATE, and TIME—are extracted according to fixed rules. VERSION must contain the complete version identifier, DATE is derived from the timestamp at the end of the version feature information, with the first 8 digits representing the year, month, and day, and TIME is derived from the last 6 digits of the timestamp. For example, if the timestamp format is YYYYMMDDHHMMSS, and the timestamp is 20251019143522, the extracted DATE content will be "20251019", and the TIME content will be 14:35:22. This is merely an example and not a limitation. Finally, according to the macro definition format supported by the compilation tool, the extracted content is converted into hardware-recognizable macro definition parameters, and these macro definition parameters are transmitted to the top-level hardware module of the FPGA prototype version compilation system.

[0056] In some optional implementations, macro definition parameters must be passed in a form that the compilation tools can directly read to ensure correct invocation during FPGA compilation. For example, the version information macro definition parameter generation unit writes three macro definition parameters into a preset header file (e.g., version_macros.h) or Tcl script, with the file path pre-configured as the scan path of the compilation environment configuration module. After writing, the version information macro definition parameter generation unit notifies the compilation environment configuration unit that "macro definition parameters have been updated" through inter-process communication or file change monitoring, triggering it to load the new parameters. After loading, the compilation environment configuration unit reads the core design files from the local repository of the design repository: RTL code, IP core configuration files, and submodule logic. It ensures that all dependent files are included in the compilation scope through file path scanning to avoid compilation failures caused by missing files. Next, version_macros.h (containing macro definition parameters corresponding to VERSION, DATE, and TIME) is embedded into the RTL code of the version management control module (e.g., version_control.v) using the include directive. At this time, it is necessary to ensure that the strings in the macro definitions are converted into hardware-storable ASCII codes and bound to the ROM or register group of the version management control unit. Finally, by integrating and compiling, an FPGA bitstream file containing version feature information is generated, thus realizing the hardware solidification of version information.

[0057] Therefore, the embodiments of this application can optimize the FPGA prototype version compilation process, realize the automation of the FPGA prototype version compilation process, and dynamically generate version feature fields according to the design repository version information, integrate them into the FPGA prototype version, realize real-time query of version feature field information and rapid backtracking of version information, facilitate fault tracking and location during version debugging, and greatly improve the efficiency of FPGA prototype verification work.

[0058] This application describes a method where, after compilation begins, the dynamic version number generation engine in the prototype version compilation system obtains the current version information from the local repository of the design repository and searches the version storage directory for FPGA prototype version information that matches the current version information. Based on the search results, the FPGA prototype version information is updated, including the current version information and a suffix version number. Version feature information is then generated based on this information. This allows the top-level hardware module in the prototype version compilation system to obtain version feature information via a preset interface when the configuration process of the debugging environment fails during compilation. The version feature information is then used to determine whether the FPGA prototype version has malfunctioned. Therefore, this solves the problem of not being able to obtain version information during the compilation process of the FPGA prototype verification platform. By embedding version information into the FPGA's hardware logic, the authenticity and immutability of the version information are ensured, providing a reliable data source for interface queries. The interface provides a standardized channel for external access to version information, enabling the acquisition of version information through the interface when a fault occurs, determining whether the fault is caused by the version, thereby reducing the difficulty of fault tracking and location and improving the efficiency of verification work.

[0059] Embodiments of this application also provide a fault detection method, which can be applied to the top-level hardware module of an FPGA prototype version compilation system. The FPGA prototype version compilation system further includes a dynamic version number generation engine. Figure 6 This is a flowchart of a fault detection method according to an embodiment of this application, such as... Figure 6 As shown, the process includes the following steps: Step S601: Receive version feature information sent by the dynamic version number generation engine, and compile the FPGA prototype verification platform corresponding to the FPGA prototype version based on the version feature information. The version feature information is determined by the dynamic version number generation engine based on the updated FPGA prototype version information.

[0060] Specifically, in this embodiment of the application, the version management control unit in the top-level hardware module receives macro definition parameters sent by the version information macro definition parameter generation unit in the dynamic version number generation engine, and compiles the FPGA prototype verification platform corresponding to the FPGA prototype version based on the macro definition parameters. The FPGA prototype verification platform includes a preset interface to view the current version information and / or FPGA prototype version information of the local repository of the design warehouse through the preset interface.

[0061] An FPGA prototyping platform is a hardware carrier used to verify the functionality of a chip design. Its architecture must include three core components: a core design module, a version management and control module, and an interface control module. The compilation process must ensure the logical and physical connections of these three components. First, the core design module consists of RTL code (such as the chip's CPU core and peripheral controllers) read from the local design repository, forming the main functional body of the verification platform and responsible for implementing the core logic of the target chip (such as data processing and protocol interaction). During compilation, synthesis tools are used to map this code to FPGA logic units (LUTs, flip-flops), memory resources (BRAM), etc., ensuring that the functionality conforms to the design specifications. Secondly, the version management control module, acting as the storage and scheduling center for version information, contains version information storage units and command parsing and response logic units in its RTL code (such as version_control.v). The version information storage unit includes ROM or register sets, loading VERSION, DATE, and TIME macro-defined parameters via the include "version_macros.h" instruction to store version strings in ASCII format. The command parsing and response logic unit identifies version query commands sent by external interfaces, such as specific ASCII instructions "GET_VERSION" and "GET_FPGA_VERSION," and triggers read operations from the storage units. The preset interface control module implements physical layer communication between external devices and the verification platform. Common preset interfaces are UART (Universal Asynchronous Receiver / Transmitter) or JTAG (Boundary Scan Interface).

[0062] Step S602: When the configuration process of the debugging environment corresponding to the FPGA prototype verification platform fails, version feature information is obtained based on the preset interface of the FPGA prototype verification platform.

[0063] Specifically, in this embodiment, the compilation process uses three steps—macro definition embedding, logic mapping, and physical binding—to permanently write parameters such as VERSION into the hardware resources of the verification platform, creating an immutable "electronic tag." The preset interface (taking the UART interface as an example) serves as the "physical channel" for external devices to query version information. Its hardware implementation must meet protocol compatibility and timing matching requirements to ensure that query commands are correctly received and version information is accurately returned. Therefore, the user's operation of viewing version information through the preset interface is simple and intuitive, requiring no additional drivers. Developers also do not need to understand the internal logic of the FPGA to quickly obtain the design repository version and the FPGA prototype version, providing direct evidence for fault location during the debugging phase.

[0064] Step S603: Determine whether the FPGA prototype version has been successfully loaded based on the version feature information. If the loading is successful, it is determined that the FPGA prototype version has not encountered any faults.

[0065] Specifically, in this embodiment, when the FPGA prototype verification platform is powered on and the bitstream is loaded, or when a suspected loading anomaly occurs during debugging, the fault detection controller of the top-level hardware module automatically triggers a version information query, or the developer actively initiates the query through an external debugging terminal. Taking manual triggering by the developer as an example, the developer sends a specific query command (ASCII format, such as "CHECK_VERSION") to the FPGA through a preset interface (such as UART). After the command is parsed by the interface control module (such as the UART controller), it is converted into an internal signal that the version management control module can recognize, thereby initiating the query process. After responding to the query command, the version management control module reads the fixed version feature information from the hardware storage unit (ROM or register group) and returns it to the query end through the preset interface. The developer determines whether the version corresponding to the version feature information is the expected version, thereby determining whether the FPGA prototype version has been successfully loaded. If they are completely consistent, all core elements match, and the FPGA prototype version is considered successfully loaded. If they are partially consistent, such as the design repository version being the same but the timestamp being different (loading different compiled versions of the same design), or the suffix version being different (loading compilation results from different environments), the loaded version is considered inconsistent with expectations. If they are completely inconsistent or the reading fails, such as the actual information being empty, garbled, or unrelated to expectations, the loading is considered to have failed.

[0066] In some alternative implementations, the success or failure of loading is directly related to the determination of version loading failures. For example, if loading fails (information read as empty / garbled), it may be due to a corrupted bitstream file, a malfunctioning loading tool, or an FPGA hardware problem, requiring the bitstream to be regenerated and loading to be retried. If the version is incompatible (e.g., loading an older version), it may be due to developer error or a version management database synchronization delay, requiring the loading of a bitstream that matches the expected version. Therefore, if loading is successful, the focus can be on design logic or peripheral issues; if loading fails, the bitstream and loading process should be checked first to reduce blind debugging.

[0067] This application addresses the issue that, during the compilation process, the top-level hardware module in the prototype version compilation system obtains version feature information sent by the dynamic version number generation engine. Based on this version feature information, it compiles the FPGA prototype verification platform corresponding to the FPGA prototype version. When a configuration process of the debugging environment corresponding to the FPGA prototype verification platform fails, the version feature information is obtained based on the preset interface of the FPGA prototype verification platform, and it is determined whether the FPGA prototype version has been successfully loaded, thereby determining whether the FPGA prototype version has failed. Therefore, this solves the problem of not being able to obtain version information during the compilation process of the FPGA prototype verification platform. By embedding the version information into the FPGA's hardware logic, the authenticity and immutability of the version information are ensured, providing a reliable data source for interface queries. The interface provides a standardized channel for external access to version information, enabling the acquisition of version information through the interface when a failure occurs, determining whether the failure is caused by the version, thereby reducing the difficulty of fault tracking and location, and improving the efficiency of verification work.

[0068] Embodiments of this application also provide a prototype version compilation system, the system comprising: a dynamic version number generation engine, used to execute the above... Figure 2 or Figure 4 The version management method shown; the top-level hardware module, connected to the dynamic version number generation engine, is used to execute the above. Figure 6 The fault detection method shown.

[0069] Specifically, in the embodiments of this application, such as Figure 3 As shown, the dynamic version number generation engine includes: a design repository version information retrieval unit, a design repository version information verification unit, an FPGA version matching unit, a dynamic version number generation unit, a version information encoding unit, and a version information macro definition parameter generation unit; the hardware top-level module (HW_TOP) includes: a version management control unit, interface virtual peripherals (such as UART Xtor), and a chip prototype instantiation top-level module (System on Chip Top-level Module, SOC_TOP). Among them, SOC_TOP is the top-level module of the FPGA chip prototype. It instantiates all the core sub-modules of the chip design (such as processor cores, peripherals, version management modules, UART Xtor, etc.) and connects the internal bus with the external interface to build a complete chip prototype verification environment.

[0070] The above provides a detailed description of the serial port baud rate adaptive adjustment method, apparatus, and prototype verification platform provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A version management method, characterized in that, A dynamic version number generation engine is applied to an FPGA prototype version compilation system, the FPGA prototype version compilation system further including: a hardware top-level module, the method comprising: After starting compilation, obtain the current version information of the local repository of the design repository, and search the version storage directory to see if it contains FPGA prototype version information that matches the current version information; The FPGA prototype version information is updated based on the search results. The updated FPGA prototype version information includes: the current version information and the suffix version number. Version feature information is generated based on the updated FPGA prototype version information, and the version feature information is sent to the hardware top-level module so that the hardware top-level module can perform fault detection on the FPGA prototype version based on the version feature information.

2. The method according to claim 1, characterized in that, The step of updating the FPGA prototype version information based on the search results includes: If the version storage directory contains FPGA prototype version information that matches the current version information, then the first suffix version number in the FPGA prototype version information is incremented. If not included, a new FPGA prototype version information is generated based on the current version information, and the new FPGA prototype version information includes a second suffix version number.

3. The method according to claim 1, characterized in that, After obtaining the current version information of the local repository for the design repository, it also includes: Determine whether the current version information is the latest version information. If not, upgrade the local design repository to the latest release version corresponding to the latest version information, and use the latest version information as the current version information.

4. The method according to claim 2, characterized in that, The step of generating new FPGA prototype version information based on the current version information includes: Obtain compilation platform information and working repository information, and generate a second suffix version number based on the compilation platform information and working repository information; The current version information is framed with the second suffix version number to obtain the new FPGA prototype version information.

5. The method according to claim 1, characterized in that, The step of generating version feature information based on the updated FPGA prototype version information includes: Determine the major version number, branch version number, patch version number, and suffix version number based on the updated FPGA prototype version information; Obtain timestamp information and, based on preset version naming rules, generate corresponding version feature information according to the timestamp information, the main version number, the branch version number, the patch version number, and the suffix version number.

6. The method according to claim 5, characterized in that, Sending the version feature information to the top-level hardware module includes: The version feature information is converted into a data stream in a preset base; Macro-defined parameters are generated based on the preset base data stream, and the macro-defined parameters are transmitted to the hardware top-level module of the FPGA prototype version compilation system.

7. A fault detection method, characterized in that, A top-level hardware module applied to an FPGA prototype version compilation system, the FPGA prototype version compilation system further including: a dynamic version number generation engine, the method comprising: The engine receives version feature information sent by the dynamic version number generation engine and compiles the FPGA prototype verification platform corresponding to the FPGA prototype version based on the version feature information. The version feature information is determined by the dynamic version number generation engine based on the updated FPGA prototype version information. When the configuration process of the debugging environment corresponding to the FPGA prototype verification platform fails, the version feature information is obtained based on the preset interface of the FPGA prototype verification platform. Based on the version feature information, it is determined whether the FPGA prototype version has been successfully loaded. If the loading is successful, it is determined that the FPGA prototype version has not encountered any faults.

8. The method according to claim 7, characterized in that, The step of receiving version feature information sent by the dynamic version number generation engine and compiling the FPGA prototype verification platform corresponding to the FPGA prototype version based on the version feature information includes: During the compilation process, macro definition parameters corresponding to version feature information are obtained; The FPGA prototype verification platform corresponding to the FPGA prototype version is compiled based on the macro definition parameters. The FPGA prototype verification platform includes a preset interface to view the current version information and / or the FPGA prototype version information of the local repository of the design warehouse through the preset interface.

9. The method according to claim 8, characterized in that, The preset interface is a general asynchronous transceiver interface.

10. A prototype version compilation system, characterized in that, The system includes: A dynamic version number generation engine is used to execute the version management method according to any one of claims 1 to 6; The top-level hardware module, connected to the dynamic version number generation engine, is used to execute the fault detection method according to any one of claims 7 to 9.

Images