An EFUSE model and method for FPGA validation boot

Abstract

The application relates to the technical field of chip verification, in particular to an EFUSE model for FPGA verification starting and a method for FPGA verification starting. The EFUSE model for FPGA verification starting and the method for FPGA verification starting, the model comprising a ROM model and signal terminals; the ROM model is embedded in FPGA; each signal terminal of the EFUSE model corresponds to each signal terminal of EFUSE in a chip to be verified, and is respectively connected to a terminal matched with the function in the ROM model; the ROM model is used for storing the EFUSE value corresponding to the starting mode of the chip to be verified. The EFUSE model is built on the basis of the ROM model, the compatibility with FPGA is realized, and when the chip is started in different modes, multiple FPGA engineering is not needed, time is saved, and efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and in particular to an EFUSE model for FPGA verification startup and a method for FPGA verification startup. Background Technology

[0002] Before chip tape-out, its design needs to be verified. FPGA (Field Programmable Gate Array) can almost completely map the logic design of the chip. It has advantages such as high speed and wide coverage of scenarios for chip verification, and has now become an indispensable and important means in chip verification.

[0003] EFUSE (electronic fuse, one-time programmable memory) is a non-volatile memory that can be programmed only once and used to store information related to chip startup. When verifying the chip startup process using an FPGA, values ​​in EFUSE are often used. However, EFUSE manufacturers often only provide Verilog (a hardware description language) models on the front end, which contain many non-synthesizable statements, leading to incompatibility between EFUSE and FPGA.

[0004] In verification, FPGA is an important verification method. Chip startup has multiple different modes, each requiring a different EFUSE value. Because EFUSE is incompatible with FPGA, when verifying different startup modes using an FPGA, the EFUSE value corresponding to the mode to be verified must be pre-written into the FPGA before FPGA synthesis. Verifying different modes requires multiple FPGA synthesis processes, which is time-consuming. With increasingly larger chips today, this process is becoming increasingly time-consuming, impacting the efficiency of chip verification. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide an EFUSE model and an FPGA verification startup method for addressing the above-mentioned deficiencies of related technologies, so as to solve the problem that the incompatibility between EFUSE and FPGA leads to the need for multiple FPGA engineering processes for verification startup, which is time-consuming and inefficient.

[0006] The technical solution adopted by the present invention to solve its technical problem is as follows: an EFUSE model for FPGA verification startup is provided, the EFUSE model including a ROM model and signal terminals; the ROM model is embedded in the FPGA; the signal terminals of the EFUSE model correspond to the EFUSE signal terminals in the chip to be verified; each signal terminal of the EFUSE model is connected to a terminal in the ROM model whose function matches that of the signal terminal; the ROM model is used to store the EFUSE value corresponding to the current startup mode of the chip to be verified.

[0007] A preferred embodiment is that the EFUSE model includes a read / write control signal terminal, the ROM model includes a clock signal terminal, and the read / write control signal terminal is connected to the clock signal terminal.

[0008] A preferred embodiment is that the EFUSE model includes a main power switch signal terminal, the ROM model includes a reset signal terminal, and the main power switch signal terminal is connected to the reset signal terminal.

[0009] A preferred embodiment is that the EFUSE model includes a programming power switch signal terminal and a mode selection signal terminal; the ROM model includes a read enable signal terminal.

[0010] The EFUSE model also includes a combinational logic model, and the programming power switch signal terminal and the mode selection signal terminal are connected to the read enable signal terminal through the combinational logic model.

[0011] A preferred embodiment is that the combinational logic model is used to determine whether the EFUSE model is currently in read mode based on the programming power switch signal and the mode selection signal.

[0012] A preferred embodiment is that both the EFUSE model and the ROM model include address signal terminals, and the address signal terminals of the EFUSE model and the address signal terminals of the ROM model are connected accordingly.

[0013] A preferred embodiment is that both the EFUSE model and the ROM model include data signal terminals, and the data signal terminals of the EFUSE model and the ROM model are connected accordingly.

[0014] The technical solution adopted by this invention to solve its technical problem is: to provide a method for FPGA verification startup, comprising:

[0015] Integrate the aforementioned EFUSE model into the FPGA project;

[0016] The EFUSE value corresponding to the current boot mode of the chip to be verified is stored in the ROM model;

[0017] The FPGA is powered on and the current EFUSE value in the EFUSE model is read to perform the startup verification of the chip to be verified in the current startup mode.

[0018] A preferred embodiment is that the steps for integrating the EFUSE model into the FPGA project include:

[0019] When compiling the FPGA, the original EFUSE model of the chip to be verified is replaced with the EFUSE model described above.

[0020] The replaced EFUSE model is then merged into the FPGA's filelist.

[0021] A preferred embodiment is that the step of storing the EFUSE value corresponding to the current boot mode of the chip to be verified into the ROM model includes:

[0022] Design the current boot mode of the chip to be verified and its corresponding EFUSE value;

[0023] The corresponding EFUSE value is written into the ROM model.

[0024] The beneficial effect of this invention is that, compared with related technologies, this invention builds an EFUSE model on the basis of an FPGA-compatible ROM model, and matches and connects the signal terminals of the EFUSE model and the ROM model, enabling the EFUSE model to achieve normal communication with the FPGA through the ROM model. After performing FPGA synthesis based on the above-mentioned EFSUSE model, before each verification of different modes, the EFUSE value corresponding to that mode is stored in the ROM model, which can then be read and used by the FPGA during verification, eliminating the need to perform FPGA synthesis for each mode, saving verification time and improving verification efficiency. Attached Figure Description

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings:

[0026] Figure 1 This is a schematic diagram of the EFUSE model structure according to an embodiment of the present invention;

[0027] Figure 2 This is a timing diagram of the EFUSE model readout in one embodiment of the present invention. Detailed Implementation

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

[0029] The following is an explanation of the English terms that may be used in the embodiments:

[0030] FPGA: Field Programmable Gate Array;

[0031] EFUSE: Electronic Fuse, a one-time programmable memory;

[0032] Verilog: A hardware description language;

[0033] ROM: Read-Only Memory;

[0034] SRAM: Static Random-Access Memory;

[0035] filelist: Simulation files.

[0036] FPGA programming uses a hardware description language (HMR) to design the hardware circuit's functionality. This circuit description is then mapped to the actual circuit, a process known as synthesis, resulting in a hardware circuit with the intended function. Using an FPGA to verify a chip leverages these characteristics to simulate the chip's functionality. Simulating the EFUSE function within the chip requires a Verilog model provided by the EFUSE manufacturer. However, Verilog models are not compatible with FPGAs. Therefore, the common practice is to directly write the EFUSE values ​​as constants into the FPGA's configuration file during programming, and then perform FPGA synthesis based on this. Different chip startup modes correspond to different EFUSE functions and require different EFUSE values. Since FPGAs need to cover all modes, the EFUSE values ​​for each mode must be rewritten before simulating different startup modes, and then synthesis must be performed again to form the corresponding hardware circuit. This undoubtedly increases the burden on developers. Therefore, there is a desire for an EFUSE model that is both compatible with FPGAs and can simulate the EFUSE function.

[0037] FPGAs have their corresponding ROM (Read-Only Memory) models, which allow for rapid reprogramming of internal values ​​without recompiling the FPGA project, ensuring full compatibility with the FPGA's logic design. Furthermore, they are non-volatile, meaning the internal contents are not lost when power is off; they cannot be programmed by the chip itself; and their ports typically include clock, reset, read enable, read address, and read data.

[0038] Furthermore, during the FPGA chip startup verification process, the EFUSE programming can be disregarded. This process is typically completed during ATE testing or when the user first receives the chip. In the startup scenario, verifying the EFUSE programming function is unnecessary, and since the EFUSE programming timing is difficult to verify on the FPGA, this verification is generally not performed on the FPGA. Verifying the EFUSE programming requires a separate method, which will not be elaborated here. Therefore, when using an FPGA to verify chip startup, only the EFUSE reading function needs to be verified.

[0039] ROM has an existing FPGA model and the ability to modify initial values ​​without recompiling the project, which fully meets the requirements of the read function. Therefore, the FPGA model of EFUSE can be built based on the ROM's FPGA model.

[0040] Furthermore, ROM and EFUSE have signals with similar functions. For example, ROM has clock and reset signals, while EFUSE, although lacking these signals, typically has a PD (powerdown) signal, which can be used as a ROM reset. There are also direct enable signals such as STROBE or others; pulling this signal high after selecting the read mode allows data at the corresponding address to be read, and it can be used as a clock. The address can be used directly as an address, and other mode selection signals can collectively generate the ROM's chip select signal.

[0041] Specifically, please refer to Figure 1 As shown, the present invention provides a preferred embodiment of an EFUSE model 100 for FPGA verification startup.

[0042] The EFUSE model 100 includes a ROM model 200 embedded in the FPGA, and signal terminals corresponding to the EFUSE signal terminals in the chip under test. Each signal terminal of the EFUSE model 100 is connected to a corresponding terminal in the ROM model 200. The ROM model 200 can store the EFUSE value corresponding to the current boot mode of the chip under test. Since the EFUSE model 100 needs to replace the original EFUSE of the chip under test to implement its function, the EFUSE model 100 has various signal terminals corresponding to the EFUSE in the chip under test. The ROM model 200 has various signal terminals required for communication with the FPGA. The signal terminals of the EFUSE model 100 are connected to corresponding terminals in the ROM model 200, enabling the EFUSE model 100 to communicate with the FPGA based on the ROM model 200.

[0043] The logic design of ROM model 200 is compatible with the logic design of the FPGA, and the FPGA can read data from ROM model 200 at any time. Therefore, after the FPGA engineering is mapped to form a physical circuit with the chip to be verified and its EFUSE function, as long as the EFUSE value corresponding to the current mode to be verified is stored in ROM model 200 before verification, the FPGA can directly read this data during chip verification to simulate the startup process in that mode. To verify the startup in different modes, it is only necessary to rewrite the corresponding EFUSE value before each verification, without having to re-engineer the FPGA, saving verification time and improving efficiency.

[0044] When using an FPGA to verify the chip, the simulation content must be as consistent as possible with the actual product to ensure the accuracy of the verification results. Therefore, this embodiment uses the ROM model embedded in the FPGA to build the EFUSE model.

[0045] FPGAs have various memory models. Besides the ROM model, other common memory models are SRAM (Static Random-Access Memory), which is volatile and cannot guarantee that the expected data is already stored upon power-up. In contrast, the data within a ROM model can be quickly rewritten and cannot be programmed by the chip itself; its data is non-volatile, meaning it is not lost when power is off, making it closest to the EFUSE operating mode. Similarly, since the chip to be verified has an embedded EFUSE, the ROM model 200 is an embedded type, which is closest to the actual product, thus ensuring that the verification process is as close to the real process as possible.

[0046] In a preferred embodiment, the signal terminals required for communication between the ROM model 200 and the FPGA include clock, reset, read enable, read address, and read data. The EFUSE signal terminals typically include: a main power switch signal PD (powerdown), a programming power switch signal PS (power switch), a mode selection signal, an address selection signal, and a read / write control signal STROBE. The EFUSE model 100, corresponding to the EFUSE of the chip to be verified, also possesses the aforementioned signal terminals.

[0047] Please see Figure 2 Since EFUSE model 100 does not have clock and reset signals, the following steps should be taken when building EFUSE model 100 using ROM model 200:

[0048] In read mode, EFUSE model 100 reads data a certain period after the rising edge of the read / write control signal STROBE, while ROM model 200 reads data on the rising edge of the clock. Therefore, the read / write control signal STROBE of EFUSE model 100 is connected to the clock signal of ROM model 200. When the read / write control signal STROBE of EFUSE model 100 goes high, ROM model 200 receives a clock signal and begins reading the data corresponding to its specific address.

[0049] The EFUSE model 100 is completely inactive when the main power switch signal PD is off. Therefore, the main power switch signal PD of the EFUSE model 100 is connected to the reset terminal of the ROM model 200. When the main power switch signal PD of the EFUSE model 100 is off, the ROM model 200 is in a reset state.

[0050] The EFUSE model 100 is in write mode when the programming power switch signal PS is on, and in read mode when the programming power switch signal PS is off. The mode selection signal includes multiple signal terminals. The programming power switch signal PS and the mode selection signal of the EFUSE model 100 are connected to the read enable signal of the ROM model 200 through the combinational logic model 300.

[0051] Different manufacturers provide different EFUSE mode selection logics, but they are all the result of combinations of multiple signals. To illustrate the simplest case, there may be a chip select enable signal CEN, a write mode control signal WEN, and a read mode control signal REN. When CEN is not selected, WEN and REN signals are ineffective; when CEN and WEN are selected, it is write mode; when CEN is selected and WEN is not selected, it is read mode. There may also be a test mode enable signal TEST.

[0052] The combinational logic model 300 has different specific implementations for different EFUSE mode selection logics, but it is basically AND, OR, NOT logic or combinations thereof. All are used to determine whether the EFUSE model is currently in read mode based on the programming power switch signal PS and the mode selection signal, that is, to control the read / write enable of the ROM model according to different read / write mode requirements. For example, when the programming power switch signal PS is off, if CEN is selected, WEN is not selected, REN is selected, and TEST is not selected, then it is determined that the current mode is read, and a read enable signal is given. That is, the ROM read enable signal is the result of the above signals combined by AND logic. This enables the reading of data from the ROM model 200.

[0053] The EFUSE model 100 and ROM model 200 also include address signal terminals and data signal terminals. The address signal terminals of the EFUSE model 100 and the address signal terminals of the ROM model 200 are connected accordingly, and the data signal terminals of the EFUSE model 100 and the data signal terminals of the ROM model 200 are connected accordingly. When a read command is received, the address and data of the two can be synchronized.

[0054] As shown above, after the signal terminals of EFUSE model 100 and ROM model 200 are connected to match their functions, the communication of commands and data between the two can be realized. Upon receiving a read command, EFUSE model 100 will read data according to its timing sequence. Since EFUSE model 100 and ROM model 200 have established a connection, EFUSE model 100 actually reads data from ROM model 200 according to its timing sequence.

[0055] For example, secure boot mode is a type of chip boot mode. During secure boot, the hash value of the key needs to be read from a specific location in EFUSE for verification. Therefore, this information needs to be read from EFUSE during the boot phase. This value is stored at the address corresponding to ROM model 200. When the FPGA verifies the boot process, it reads this information from a specific bit in EFUSE model 100, which is actually reading this information from the address corresponding to ROM model 200.

[0056] In summary, this invention replaces the EFUSE of the chip to be verified with the EFUSE model 100. For the startup process, the behavior is completely consistent with the real situation, and the replaced EFUSE model 100 is fully compatible with the FPGA.

[0057] Based on the above EFUSE model 100, another preferred embodiment of the present invention provides a method for FPGA verification startup, the method comprising:

[0058] Integrate the EFUSE model 100 into the FPGA project;

[0059] Store the chip EFUSE value corresponding to the current startup of the chip to be verified into ROM model 200;

[0060] The FPGA is powered on and the current EFUSE value in EFUSE model 100 is read to perform startup verification of the chip under the current startup mode.

[0061] That is, when compiling the FPGA, the original EFUSE model 100 of the chip to be verified is replaced with the EFUSE model 100 built based on the ROM model 200 mentioned above. In other words, the EFUSE model 100 of the present invention is used to replace the Verilog model provided by the EFUSE manufacturer, and it is merged into the FPGA filelist (simulation file). On this basis, the FPGA project is integrated and mapped to form a physical circuit containing the EFUSE model 100 of the present invention.

[0062] Next, we can proceed to the verification phase. Before verification begins, we design the expected EFUSE values, that is, we design the current mode to be verified and the corresponding EFUSE values ​​required in this mode. For example, a specific bit of EFUSE indicates the initial configuration of PCIe (Peripheral Component Interconnect Express). During the FPGA verification process, this bit needs to be set to different configuration options before power-on. This value is then programmed into ROM model 200.

[0063] Once the verification begins, the FPGA is powered on and reads the value from EFUSE model 100, which can then simulate the startup of the corresponding mode, thus verifying the chip's startup in that mode.

[0064] Based on the EFUSE model 100 verification chip startup of this invention, the required EFUSE values ​​for the mode to be verified are programmed into the ROM model 200 before verification, and the relevant information can be read upon FPGA power-up. Therefore, verifying different modes no longer requires re-integrating the FPGA project, resulting in a significant improvement in efficiency.

[0065] The above description is merely the preferred embodiment of the present invention and is not intended to limit the scope of the present invention. All equivalent changes or modifications made in accordance with the claims of the present invention are covered by the present invention.

Claims

1. An EFUSE model for FPGA verification startup, characterized in that: The EFUSE model includes a ROM model and signal terminals; The ROM model is embedded in the FPGA; The signal terminals of the EFUSE model correspond to the signal terminals of the EFUSE in the chip to be verified. Each signal terminal of the EFUSE model is connected to a terminal in the ROM model that matches the function of the signal terminal. The ROM model is used to store the EFUSE value corresponding to the current boot mode of the chip to be verified; The EFUSE model includes a read / write control signal terminal, and the ROM model includes a clock signal terminal, with the read / write control signal terminal connected to the clock signal terminal; the EFUSE model includes a main power switch signal terminal, and the ROM model includes a reset signal terminal, with the main power switch signal terminal connected to the reset signal terminal.

2. The EFUSE model according to claim 1, characterized in that: The EFUSE model includes a programming power switch signal terminal and a mode selection signal terminal; the ROM model includes a read enable signal terminal. The EFUSE model also includes a combinational logic model, and the programming power switch signal terminal and the mode selection signal terminal are connected to the read enable signal terminal through the combinational logic model.

3. The EFUSE model according to claim 2, characterized in that: The combinational logic model is used to determine whether the EFUSE model is currently in read mode based on the programming power switch signal and the mode selection signal.

4. The EFUSE model according to claim 1, characterized in that: Both the EFUSE model and the ROM model include address signal terminals, and the address signal terminals of the EFUSE model and the ROM model are connected accordingly.

5. The EFUSE model according to claim 1, characterized in that: Both the EFUSE model and the ROM model include data signal terminals, and the data signal terminals of the EFUSE model and the ROM model are connected accordingly.

6. A method for FPGA verification startup, characterized in that, include: Integrate the EFUSE model described in any one of claims 1-5 into the FPGA project; The EFUSE value corresponding to the current boot mode of the chip to be verified is stored in the ROM model; The FPGA is powered on and the current EFUSE value in the EFUSE model is read to perform the startup verification of the chip to be verified in the current startup mode.

7. The method according to claim 6, characterized in that, The steps for integrating the EFUSE model into an FPGA project include: When compiling the FPGA, the original EFUSE model of the chip to be verified is replaced with the EFUSE model described above. The replaced EFUSE model is then merged into the FPGA's filelist.

8. The method according to claim 6, characterized in that, The step of storing the EFUSE value corresponding to the current boot mode of the chip to be verified into the ROM model includes: Design the current boot mode of the chip to be verified and its corresponding EFUSE value; The corresponding EFUSE value is written into the ROM model.

Images