The introduction about FPGA and GPU

Author: Release time:2019-12-20 Source: Font: Big Middle Small View count:325

FPGA is a bunch of transistors, you can connect them to make any circuit you want. It's like a nano breadboard. Using FPGA is like chip streaming, but you only need to buy this chip to build a different design. In exchange, you need to pay some efficiency price.

This is not true literally, because you don't need to reconnect the FPGA, it is actually a lookup table 2D grid connected through a routing network, and some arithmetic units and memory. FPGAs can simulate arbitrary circuits, but they are actually just mimicking them, just like software circuit simulators simulate circuits. What's wrong with this answer is that it oversimplifies how people actually use FPGAs. The next two definitions better describe FPGAs.

Circuit simulation is a classic mainstream use case for FPGAs, which is why FPGAs first appeared. The key to FPGA is that the hardware design is coded in HDL, and buying some cheap hardware can get the same effect as ASIC. Of course, you can't use the exact same Verilog code on FPGAs and real chips, but at least their abstract scope is the same.

This is a different use case from ASIC prototyping. Unlike circuit simulation, compute acceleration is an emerging use case for FPGAs. This is why Microsoft has recently succeeded in speeding up search and deep neural networks. And the point is, the calculation example does not depend on the relationship between FPGA and real ASIC: Verilog code written by developers for FPGA-based acceleration need not have any similarity to the Verilog code used to stream.

These two examples are vastly different in terms of programming, compiler, and abstraction. I pay more attention to the latter, and I call it "Computing FPGA Programming". My argument is that the current programming methods for computing FPGAs draw on traditional circuit simulation programming models, which is wrong. If you want to develop ASIC prototypes, Verilog and VHDL are the right choices. But if the goal is computing, we can and should rethink the entire stack.

Let's open the door and say. FPGA is a very special type of hardware that is used to efficiently execute special software described by analog circuits. FPGA configuration requires some low-level software-it is a program written for ISA.

Here we can use the GPU as an analogy.

Before deep learning and blockchain prevailed, there was a time when GPUs were used to process graphics. At the beginning of the 21st century, people realized that they would also use GPUs as accelerators when processing compute-intensive tasks without graphic data: GPU designers have built more general-purpose machines, and 3D rendering is just one of them.

Definition of FPGA and analogy with GPU

Computing FPGAs follow the same trajectory. Our idea is to use more of this fashionable hardware, of course, not for circuit simulation, but to use computing models suitable for circuit execution, and to look at GPUs and FPGAs by analogy.

In order for the GPU to develop into today's data parallel accelerators, one has to redefine the concept of GPU input. We used to think that GPUs accepted strange, strong, domain-specific descriptions of visual effects. We implemented GPU executives, unlocking their true potential. Such an implementation allows the goal of the GPU to evolve from a single application domain to the entire computing domain.

I think computing FPGAs are in a similar transition, and there is no concise description of the basic computing models that FPGAs excel at. But it has to do with potential irregular parallelism, data reuse, and most static data flows.

Like GPUs, FPGAs also need hardware abstraction that can embody this computing model. The problem with Verilog for computing FPGAs is that it doesn't work well in low-level hardware abstractions, and it doesn't work well in high-level programming abstractions. Let's imagine by contradiction, what it would be like to replace these roles with RTL (register transfer level).

Even RTL experts may not believe that Verilog is a way to efficiently develop mainstream FPGAs. It does not push programming logic to the mainstream. RTL design may seem friendly and familiar to experienced hardware hackers, but the productivity gap between it and software languages is immeasurable.

In fact, for today's computing FPGAs, Verilog is actually ISA. Major FPGA vendor tool chains take Verilog as input, and high-level language compilers take Verilog as output. Vendors generally keep the bitstream format secret, so Verilog stays as low as possible in the abstraction hierarchy.

The problem with using Verilog as an ISA is that it is too far away from the hardware. The abstraction gap between RTL and FPGA hardware is huge. Traditionally, it has to include at least synthesis, technology mapping, and place-and-route—each one is a complex and slow process. As a result, the compilation / editing / running cycle of RTL programming on FPGA takes hours or days, and even worse, it is an unpredictable process. The deep stack of the toolchain may mask changes in RTL, which may affect Design performance and energy characteristics.

A good ISA should directly show the unmodified reality of the underlying hardware. Like assembly language, it doesn't need to be very easy to program. But like assembly language, it needs to be very fast, and the results are predictable. If you want to build more advanced abstractions and compilers, you need a low-level goal that doesn't come up unexpectedly. RTL is not such a goal.

If the computing FPGA is an accelerator of a particular type of algorithm mode, then current FPGAs are not ideal for this purpose. New types of hardware that can defeat FPGAs under this game rule can bring a new level of abstraction. The new software stack should abandon the legacy problems of FPGAs in circuit simulation and RTL abstractions.

Hot News

Hot product