Many years ago, I often wondered: why do we work overtime in FPGA design, constantly debugging and maintaining bugs, feeling exhausted. It wasn’t until I worked in IC design that I truly understood: after looking at the differences between FPGA design and IC design, you will understand too.

1. Design Differences (Whether There is Final Hardware Before Design)

Although both FPGA and IC design belong to hardware design, there are significant differences in their designs. FPGA is a programmable logic array, so FPGA design involves programming the logic inside the FPGA chip using software to implement different application developments, while IC is an integrated circuit (chip), and IC design involves creating a chip. Therefore, the essential difference is:

• FPGA design is application development on the FPGA chip, that is, developing on the final hardware (FPGA chip);

• IC design is creating a chip, that is, there is no final hardware (the designed chip).

2. Verification Differences (Can Final Hardware Be Used for Verification)

The design differences mentioned above indicate that FPGA design has final hardware (FPGA chip) available before design, thus verification:

• Can directly use FPGA for verification, that is, download to the FPGA chip, run it, check it, modify it, download again, run it, modify again……

• Verify through customer usage on FPGA products; if customers find bugs, we locate and solve them; if customers find bugs again, we locate and solve them again……

• Because there is final hardware (FPGA chip) for verification, we generally only need a few runs to pass, which is not sufficient.

However, in IC design, there is no final hardware (the designed chip) before the design, and if verification is inadequate, it can lead to the failure of a tape-out, which can result in hundreds of millions in losses. Therefore, verification needs to:

• Use verification methodologies like UVM to verify the functions of various modules as thoroughly as possible, pre-simulation, and post-simulation;

• Use FPGA, hardware simulators, etc., to verify various functions as closely as possible to the final chip;

• Since there is no final hardware (the designed chip) for verification, our verification will be very thorough.

3. Differences in Standard Processes (Whether Standard Processes Are Required)

The verification differences mentioned above show that in FPGA design, you can make multiple attempts on the final hardware (FPGA chip) and even make multiple attempts at the customer site. Therefore, in terms of standard processes:

• Non-standard is also acceptable: Making multiple attempts is not a problem, issues can be resolved, spending 20% on design and 80% on debugging, and needing to work overtime for maintenance is also acceptable; if it can be resolved with overtime, it’s not a problem. Why is it not important to resolve, as long as the final hardware (FPGA chip) runs without issues, that’s OK;

• Standard is better: writing code in a standardized manner, having detailed design documents, paying attention to the reports from EDA tools for synthesis and layout, doing some simulations before going to the board, which allows you to spend 80% on design and 20% on debugging, reducing overtime, and continuously upgrading and iterating the design, resulting in fewer bugs that require little maintenance, and any bugs can be resolved quickly.

However, in IC design, there is no final hardware (FPGA chip) to make multiple attempts, so it is essential to strictly follow the design process, simulate the final hardware as much as possible for verification, and ensure that the chips returned from tape-out do not have issues. Therefore, in terms of standard processes:

• Must strictly adhere to standards, ensure thorough verification, and if bugs arise, they need to be traced back to the root cause in the design and resolved, after which they need to be re-verified.

So, why do we work so much overtime in FPGA design? I believe it is because we do not pay enough attention to standards and verification. As for how to understand and implement the emphasis on standards and verification in FPGA design?