Oct 10, 2022 People always ask me, "Which one is better, a prototyping system or a hardware emulator?"
Why is there such a difficult choice? It's just because that today's chips are too large and too complex.
With the continuous advancement of new technologies such as AI and 5G, under the beautiful life created by the "Internet of Everything", the applications are becoming more and more diverse, which has also brought about tremendous promotion and changes in the entire chip design industry. And Moore's Law continues to evolve. A chip looks small, but it is the size of a fingernail, but it carries tens of billions of transistors. The integration level is getting higher and higher, and the complexity of the whole chip is also increasing exponentially, which has also spawned the requirements for larger-scale SoC design. Ultimately, the requirements and dependence of the entire chip design on EDA tools are also getting higher.
In the entire chip design process, no chip engineer can bypass the verification process. For this large-scale SoC design, the most mentioned are prototyping systems and hardware emulators.
Going back to the question at the beginning, I have always believed that there is no better choice, but only more suitable one. The results of selection are often based on our own needs. Ask yourself, what are the application scenarios, design goals, design scale, debugging requirements when designing the chip? Pay attention! Choose the verification tool that suits you after evaluating all the aspects.
Before we start, dear friends, doing popular science is not easy, please don’t forget to thumb up, recommend and collect my video.
Prototype verification system is a chip verification platform based on FPGA, which verifies chip function by transplanting RTL to field programmable gate array. It will help engineers build a system verification environment that integrates software and hardware in the chip design process. That is to say, with it, engineers can start driver development immediately after the basic functional verification of the chip is passed before tape-out. It is even possible to demonstrate chip demonstrations and pre-sale to customers in need before tape-out. This greatly shortens the entire validation cycle and accelerates product launch.
In addition, because the internal processing of the prototype verification system is the same as the real chip, it can perform parallel operations, and its high performance can find more hidden bugs by connecting the real data with the hardware daughter card. In contrast, there is a certain difference between the excitation source model used in the simulation and the real data.
The hardware emulator is to accelerate the simulation and debugging of the complete and closed chip design. When the development of IP sub-modules is basically mature, it needs to be spliced into an overall system to check whether there are deep errors or performance bottlenecks in the system. At this time, a hardware emulator is required to have an acceptable high inspection speed. The hardware emulator can host the entire system for system-level debugging.
According to the architecture, hardware accelerators are divided into two types: FPGA-based prototype verification platforms and CPU-based hardware simulators. This time, we mainly talk about FPGA-based hardware simulators.
The hardware emulator contains a large number of detection instruments, signal recorders, etc. to record the data of each clock cycle of the system circuit operation in order to find design errors, so the full visibility of signals is a key feature of the hardware emulator.
The main positioning difference between a hardware emulator and the prototype verification system is that it can perform a hardware emulator that is consistent with the timing behavior of the entire chip, including the extraction of the entire chip signal, and the system-level verification and debugging of the function, performance, and power consumption of the entire chip.
The prototype verification system is more suitable for some small and medium-scale designs, with capacities ranging from tens of millions to one billion gates, which can meet the diverse needs of different chip design scales and design scenarios.
Compared with the prototype verification system, the design capacity of the hardware emulator is larger, and it can support the ultra-large-scale design capacity of more than 1 billion gates, so the price is also very expensive.
The hardware emulator has a fully automated software setting implementation process, basically no need to modify the hardware connection configuration, and flexible and diverse system-wide simulation debugging capabilities, including: deeper signal tracking depth (up to billions of simulation cycles), signal condition triggering, Dynamic probe insertion, offline debugging, etc. It usually only takes a few weeks to run a large project.
From this point of view, the advantages of a prototyping system are less obvious, it often takes months to run a large project, and only a few products support faster automated processes.
Another key traditional difference between emulators and prototyping systems is debugging. The hardware emulator has large-capacity and full-system emulation-level debugging, consisting of hundreds or thousands of custom processors, providing a rich debugging environment, such as signal traceability, waveform saving, setting breakpoints, etc.
The prototype verification system is equipped with dedicated DDR memory, supports the debugging capabilities of multiple FPGAs, and achieves efficient debugging comparable to the emulator. It mainly supports static probes, and only a few products support deep debugging capabilities such as full signal visibility. In addition, the prototyping system is equipped with interfaces via dedicated protocols such as JTAG, Ethermet, PCle or other high-speed interfaces.
The compilation time of a prototyping system varies depending on the size of the design, and compilation of large designs is usually slow. If the compilation produces errors, after fixing the errors, you need to recompile from scratch. This can cause serious delays.
The hardware emulator has a much faster compilation time on large designs, not only because it is more efficient and utilized than FPGA in general routing, but also because its software is equipped with a special place and route algorithm, making The overall compilation time is greatly accelerated.
However, the execution speed of the prototyping system is unmatched by hardware emulators. When verifying, the more test programs you run, the better your design reliability will be. The prototype verification system can run a large number of test vectors in a short time, easily reaching the 10Mz-100MHz level, while the hardware emulator is only 1MHz or below.
Although, for small and medium-scale chip designs, the execution speed of the prototype verification system can be said to be an order of magnitude faster than that of the hardware emulator. However, once the ultra-large-scale design of more than 1 billion gates is encountered, if the prototype verification system still wants to maintain the original speed, it will inevitably impose higher requirements on its software tools and hardware design.
Especially with the prosperity of new technologies such as AI and 5G today, more and more chips and electronic devices are integrated into the same system to obtain higher computing power. These ultra-large and complex chip designs are bound to pose greater challenges for verification.
For such very large-scale designs, hardware emulators are more advantageous. Because of its unique and large-scale hardware structure, the integrity of RTL design is guaranteed as much as possible. Some hardware emulator suppliers also provide software development kits with various functions to help accelerate the overall verification efficiency, such as multi-chip automatic partitioning tools, synthesis tools optimized for the platform, in-circuit debugging tools, and so on.
In the face of large-scale design, the prototype verification system will choose to use multiple FPGA chips if it wants to verify the whole system without affecting the overall performance and speed. However, problems arising from the interconnection of multiple FPGAs follow, such as low-latency parallel I/O interfaces, high-bandwidth Serdes interfaces, automatic segmentation, signal debugging of multiple FPGAs, various software and hardware interface expansion schemes, and so on. All these determine that the prototype verification system needs more specialized design, especially the corresponding automation tools.
Because for medium and large-scale designs with more than two or three FPGAs, the investment in manual segmentation and optimization is too large, and there will be potential human errors. This is like a car with an automatic transmission that cannot be driven and has to use a manual transmission. It is time-consuming and labor-intensive for engineers, and also requires considerable experience, which is quite worthless.
At present, on the market, the prototype verification solution of Xinshentong, like Guowei Sierxin, has both netlist-level and RTL-level automatic segmentation capabilities, which can well help engineers solve such problems. Even equipped with a complete prototype tool chain, it can be optimized in combination with other point tools such as logic synthesizers to achieve better optimization strategies.
The scalability of the physical interface is often a concern for engineers. Prototype verification systems are generally equipped with dedicated interfaces, which can expand various functional daughter cards, build a more realistic environment, and help find bugs that cannot be detected by software emulators/hardware emulators. And because of its high performance, it can also support high-speed physical interfaces of around 1Gbps-26Gbps, and some support drop-speed bridges. Hardware emulators are limited in performance and cannot support high-speed physical interfaces. In most cases this will be achieved through a speed matching bridge device or virtual device model.
All points are comparable, and finally we have to look at the prices of the two.
Compared to prototyping systems, hardware emulators are relatively less competitive in price. The multi-million dollar hardware cost is often prohibitive for some small and medium-sized design companies. In addition, the maintenance cost of hardware emulators is also quite high, and some additional costs are often unavoidable, including full machine maintenance, library models for verification, transaction-level models, additional enhancement tools, peripheral simulators, etc.
(put a comparison picture)
In fact, prototyping system VS hardware emulator is never a choice between the two. More often, at different nodes of chip design, engineers use different tools. After watching the short video, I believe that everyone can use the right tool in the right application scenario at the right time according to their actual situation!
Back to list