High-Paying Tips for FPGA Engineers Earning 700k Annually

For FPGA engineers looking to earn a high salary, there are several key strategies to consider. First and foremost, honing your skills in FPGA design and development is crucial. Becoming an expert in languages such as Verilog and VHDL, as well as mastering FPGA development tools and platforms, will make you a valuable asset in the field.

It has been more than ten years since I first came into contact with FPGA during my university days. I still remember the excitement of completing experiments such as digital stopwatches, quiz buzzers, and password locks on the EDA platform for the first time. At that time, I had not yet been exposed to HDL hardware description languages, so the designs were built using 74-series logic devices in the MAX+plus II schematic environment. Later, during my postgraduate studies and subsequent work, I used Quartus II, Foundation, ISE, and Libero, and also learned the Verilog HDL language. Through this learning process, I gradually appreciated the cleverness of Verilog. I realized that a small piece of code could complete complex schematic designs, and the portability and operability of the language were much stronger than those of schematic designs.

Importance of Standards in FPGA Logic Design

Friends who have worked in the industry know that companies emphasize standards, especially for large designs (whether software or hardware). It is almost impossible to achieve without following the standards. Logic design is no exception: if you don’t follow the standards, you may find errors when debugging a month later. Looking back at the code you wrote, you may have forgotten many signal functions, let alone error checking. If someone leaves halfway through a project, the successor will probably have to start the design from scratch. If you need to add new features to the original version, you will most likely have to start over, making it difficult to achieve design reusability.

In terms of logic, I think the following standards are important:

1. Design Documentation: Design ideas, detailed implementations, etc., should be written into documents, and only after strict review and approval can the next step of work be carried out. This approach can keep the project in a controllable and achievable state.
2. Code Standardization: Standardize signal naming, use lowercase for signal names and uppercase for parameters, mark low-level effective signals with _n at the end (e.g., rst_n), and arrange port signals with one signal per line for easier error detection in simulation verification.
3. Clock Domain Management: Use only one clock for each module, and use a dedicated module for clock domain isolation in designs involving multiple clock domains to allow the synthesizer to synthesize a more optimal result.
4. Avoid Combinatorial Logic for Latches: In FPGA designs, it is forbidden to use pure combinatorial logic to generate latches. Latches with D flip-flops are allowed, such as configuration registers.
5. Signal Synchronization: Generally, signals entering the FPGA must be synchronized first to increase the system working frequency.
6. Register All Outputs: All module outputs should be registered to increase the working frequency and achieve timing convergence in design.
7. Avoid Gated Clocks: Unless it is a low-power design, do not use gated clocks, as this will increase the design’s instability.
8. Clock Enable Signals: It is forbidden to use signals divided by counters as clocks for other modules. Instead, use clock enable signals.

Timing Design for High Performance

My boss has a background working at Huawei and Junlong, so naturally, he told us about some logic design practices at Huawei and Altera. Our project standards are basically based on the practices at Huawei. In the past few months of work, the deepest impression on me was the saying at Huawei: timing is designed, not simulated or made up. In our company, every project undergoes strict review. Only after the review is passed can the next step of work be carried out. Taking logic design as an example, instead of starting to write code right away, we first need to write the overall design plan and detailed logic design plan. After these plans are reviewed and deemed feasible, coding can begin. Generally speaking, the time spent on these tasks is much greater than the time spent on coding.

The overall plan mainly involves module division, interface signals and timing of first-level and second-level modules, and how to test the design in the future. In this level of plan, it is important to ensure that the timing converges to the first-level module (and finally to the second-level module). What does this mean? When we do detailed design, we will definitely make some adjustments to the timing of some signals. However, these timing adjustments can at most affect the first-level module, not the entire design. I remember when I was in school, because I didn’t understand timing design, I often had to adjust the timing of other module signals because one signal’s timing was not met, which was very frustrating.

In the detailed logic design plan, we have already designed the interface timing of each level of modules, and how each level of modules is implemented is basically determined. Because we have achieved this, coding naturally becomes faster. Most importantly, this approach can keep the design in a controllable state and prevent the need to start the entire design over due to errors in one place.

What are the factors that affect the operating frequency of a circuit?

The working frequency of the circuit is mainly related to the signal propagation delay between registers and clock skew. If the clock in the FPGA runs along long lines, the clock skew is very small and can be ignored. Here, for simplicity, only the factors affecting the signal propagation delay are considered. The signal propagation delay includes the opening and closing delay of the register, the routing delay, and the delay through the combinatorial logic. To increase the working frequency of the circuit, we need to work on these three delays and make them as small as possible.

1. Reduce Delay by Changing Routing: Specify the routing of some important signals, such as clocks and control signals, to make them pass through the FPGA as little as possible. This can effectively reduce the routing delay.
2. Reduce the Number of Combinatorial Logic: Use look-up tables (LUT) as much as possible instead of logic gates. In addition, some people use cascaded registers to reduce the number of gates, but the best way is to use pipelining to reduce the number of gates.

In conclusion, reducing the number of gates and changing the routing are effective ways to increase the working frequency of the circuit. In actual design, it is often a combination of both. However, this is not absolute. In some cases, changing the routing may not reduce the delay, and the most effective way is to reduce the number of gates.

The Challenges of Logic Design: System Architecture and Simulation Verification

When I first joined the company, my boss told me that the difficulty of logic design lies not in the design of RTL-level code, but in system architecture design and simulation verification. Currently, in China, there is more emphasis on synthesizable designs, but there doesn’t seem to be much information on system architecture design and simulation verification, which may reflect the relatively low level of design in China.

When I was in school, I always thought that as long as the RTL-level code was done well, simulation verification was just a formality, so I disdainfully ignored the syntax of HDL behavioral description and was reluctant to learn about testbenches—because I thought drawing waveforms was convenient; I knew nothing about system architecture design. It wasn’t until I encountered some things at the company that I realized it was completely different.

In fact, in foreign countries, the time and manpower spent on simulation verification is probably twice that spent on RTL-level code. Now, simulation verification is the critical path for designing million-gate chips.

Simulation Verification: Modeling and Automation

The difficulty of simulation verification mainly lies in how to model to completely and accurately verify the correctness of the design (mainly to increase code coverage). In this process, the verification speed is also important.

Verification, in simple terms, is how to generate sufficient coverage of stimulus sources and then detect errors. Personally, I think that in simulation verification, the most basic thing is to achieve automation of verification. This is also why we need to write testbenches. In one of my current designs, it takes about an hour for each simulation run (which is actually a small design). Since drawing waveforms cannot achieve verification automation, if we simulate by drawing waveforms, first, the waveform will be drawn to death (especially for designs with complex algorithms and input statistical distribution), second, looking at the waveform will be deadly, and third, the error detection rate is almost zero. So how to achieve automation? My level is still very limited, so I can only briefly talk about BFM (bus function model).

Taking the example of making a MAC core (the backplane is the PCI bus), we need a MAC_BFM, PCI_BFM, and PCI_BM (PCI behavior model). The main function of MAC_BFM is to generate Ethernet frames (stimulus sources), with random lengths and frame headers, and the content is also random. While sending, it also copies it to PCI_BM; the function of PCI_BFM is to simulate the behavior of the PCI bus, for example, when the device under test receives a correct frame, it will send a request to the PCI bus, and PCI_BFM will respond to it and bring the data in; the main function of PCI_BM is to compare what MAC_BFM sends out with what PCI_BFM receives. Since it has the sending information of MAC_BFM and the receiving information of PCI_BFM, as long as the design is reasonable, it can always automatically and completely test whether the device under test is working normally, thus achieving automatic detection.

Huawei is estimated to be doing relatively well in simulation verification in China. They have established a relatively good verification platform, and most of the BFM related to communication are well done. I heard from my friend that now they only need to put the device under test in the test platform and configure the parameters to automatically detect whether the device under test is functioning correctly.

Language Considerations

Regarding HDL languages, many people in China are arguing about which is better between VHDL and Verilog. In fact, I personally think this is not very meaningful. Most big companies outside basically use Verilog for RTL-level code, so I still recommend everyone to learn Verilog as much as possible. In terms of simulation, because VHDL is weaker than Verilog in behavioral modeling, there are very few simulation models done with VHDL. Of course, Verilog is not perfect either. In fact, Verilog’s ability in complex behavioral modeling is also limited. For example, it does not yet support arrays. In some complex algorithm designs, high-level languages are needed for abstraction to describe behavioral models. In foreign countries, many simulation models are done using SystemC and E language, and using Verilog is considered outdated. Huawei’s verification platform in China seems to be written in SystemC.

Future Perspectives

In terms of system architecture design, because the design I am working on is not large enough, I don’t have much experience yet. I just feel that I must have some knowledge of computer system architecture. The primary basis for division is functionality, followed by selecting the appropriate bus structure, storage structure, and processor architecture. The division of system architecture should make each functional module clear and easy to implement. I think I will share some insights after I have a little experience in this part in a while, so I won’t mislead you for now.

Personal Insights

Finally, let me briefly summarize. It all comes down to more practice, more thinking, and more questioning. Practice makes perfect. It’s better to practice it yourself than to read others’ solutions a hundred times. The motivation for practice comes partly from interest and partly from pressure. I personally think the latter is more important. Having requirements will easily create pressure, that is, it is best to practice in actual project development rather than studying for the sake of studying.

In the process of practice, you should think more and think about the reasons for the problems. After solving the problems, ask why a few more times. This is also a process of accumulating experience. If you have the habit of writing project logs, it’s even better. Write down the problems, reasons, solutions, and methods solved in it. Finally, ask more questions. If you can’t solve a problem after thinking about it, ask. After all, individual capabilities are limited. Ask classmates, colleagues, search engines, and netizens. An article or friends’ guidance may help you solve problems quickly.

Conclusion

After functional simulation, since we are designing in FPGA, the RTL-level code is basically guaranteed to be consistent with the synthesis result and the functional simulation result during design. As long as the static timing report after synthesis layout is not warned against violating the timing constraints, we can proceed to debug on the board. In fact, at Huawei and ZTE, they also do not do timing simulation when designing FPGA because timing simulation takes a lot of time and the effect is not necessarily better than looking at the static timing analysis report.

Of course, if it is ASIC design, the workload of simulation verification is greater. When it involves multi-clock domain design, post-simulation is generally done. However, before doing post-simulation, formal verification tools are usually used and the static timing analysis report is used to check for any violations of design requirements. After doing this, the workload of post-simulation can be much smaller.