Imagine that the processor, instead of executing a set of instructions, will be rebuilt for each program and turn the algorithm directly into hardware. This is exactly how FPGAs work! In this article I will tell you how this is possible and introduce you to different ways FPGA design.
Maybe you know how to hack devices on the other side of the world or code cool web applications, but do you understand how your computer works? And we are not talking about what the operating system does, how the garbage collector functions in Java, or how the C++ compiler works. I'm talking about the lowest, hardware level, below assembly language: how the hardware works.
What happens in the microcircuit network card when does the Ethernet packet arrive? How is this packet passed on to RAM computer via PCI bus Express? How do the most fast systems image recognition in hardware?
To answer these questions, you need to understand a little about the digital logic of ASICs, but starting with them is very difficult and expensive, and it is better to start with FPGAs instead.
INFO
FPGA stands for field-programmable gate array, in Russian - user-programmable gate arrays, FPGA. More generally, they are called FPGAs - programmable logic integrated circuits.
With the help of FPGAs, you can literally design digital microcircuits while sitting at home with an available debug board on the table and developer software for a couple of kilobucks. However, there are also free options. Note: it is designing, not programming, because the output is a physical digital circuit that executes a specific algorithm at the hardware level, and not a program for the processor.
It works something like this. There is a ready-made printed circuit board with a set of interfaces that are connected to an FPGA chip installed on the board, like a cool board for a data center or a debug board for training.
Until we configure the FPGA, there is simply no logic inside the chip to process data from the interfaces, and therefore nothing will work, obviously. But as a result of the design, firmware will be created, which, after loading into the FPGA, will create the digital circuit we need. For example, this way you can create a 100G Ethernet controller that will receive and process network packets.
An important feature of FPGA is its reconfigurability. Today we need a 100G Ethernet controller, and tomorrow the same board can be used to implement four independent 25G Ethernet interfaces.
There are two large manufacturers of FPGA chips: Xilinx and Intel, which control 58 and 42% of the market, respectively. The founders of Xilinx invented the first FPGA chip back in 1985. Intel entered the market recently - in 2015, having absorbed Altera, which was founded at the same time as Xilinx. Xilinx and Altera technologies are similar in many ways, as are their development environments. I worked more often with Xilinx products, so don't be surprised by its constant mention.
Imagine that the processor, instead of executing a specific set of instructions, will be rebuilt for each program and turn the algorithm directly into hardware. This is exactly how FPGs work. In today's article, I will tell you how this is even possible and introduce you to various FPGA design methods.
To begin with, you need to understand a little about the digital logic of ASIC chips, but starting with them is very difficult and expensive, and it is better to start with FPGAs instead.
What is FPGA?
FPGA stands for field-programmable gate array (user-programmable gate arrays, FPGA). More generally, they are called FPGAs - programmable logic integrated circuits.
Using an FPGA, you can literally design digital microcircuits while sitting at home with an available debug board on the table and developer software for several thousand green rubles. But there are also free options. Please note: it is to design, not to program, because at the output we will get a physical digital circuit that performs a certain algorithm at the hardware level, and not a program for the processor.
It works as follows. There is a ready-made printed circuit board with a set of interfaces that are connected to an FPGA chip installed on the board, something like this cool board for a data center or this debug board for training.
Until we configure the FPGA, there is simply no logic inside the chip to process data from the interfaces, and therefore, of course, nothing will work. But as a result of the design, firmware will be created, which, after loading into the FPGA, will create the digital circuit we need. In this way, you can create a 100G Ethernet controller that will receive and process network packets.
An important feature of FPGA is its reconfigurability. Let's say now we need a 100G Ethernet controller, and in a week the same board can be used to implement four independent 25G Ethernet interfaces.
There are two leading manufacturers of FPGA chips on the market: the well-known Intel and Xilinx. They control 58 and 42% of the market. The founders of Xilinx invented their first FPGA chip back in 1985. Intel entered the market quite recently - in 2015, having absorbed Altera, which was founded at the same time as Xilinx. The Altera and Xilinx technologies are similar in many ways, as are the development environments. I worked more often with Xilinx products, so don’t be surprised by its constant mention in the article.
FPGAs are widely used in various fields: consumer electronics, telecom equipment, accelerator boards for use in data centers, robotics, prototyping ASIC chips. I'll look at a couple of examples below.
We will also look at the technology that provides hardware reconfiguration, get acquainted with the design process, and look at a simple example of implementing a hardware counter in Verilog. If you have any FPGA development board, you should be able to replicate this yourself. If there is no board, you can still get acquainted with Verilog by simulating the operation of the circuit on your computer.
Working principle of FPGA
An FPGA chip is the same custom ASIC chip, consisting of the same transistors from which flip-flops, registers, multiplexers and other logic elements for conventional circuits are assembled. Of course, it is impossible to change the order in which these transistors are connected. But architecturally, the microcircuit is built in such a clever way that it is possible to change the switching of signals between larger blocks: they are called CLBs - programmable logic blocks.
It is also possible to change the logical function that the CLB performs. This is achieved due to the fact that the entire chip is permeated with Static RAM configuration memory cells. Each bit of this memory either controls some kind of signal switching key, or is part of the truth table of a logical function that the CLB implements.
Since the configuration memory is built using Static RAM technology, firstly, when the FPGA is turned on, the chip must be configured, and secondly, the chip can be reconfigured an almost infinite number of times.
Very simplified 2D chip structure without configuration memoryCLBs are located in a switch fabric that defines the connections between the inputs and outputs of the CLBs.
Switching matrix diagramAt each intersection of conductors there are six switching switches controlled by their own configuration memory cells. By opening some and closing others, you can provide different signal switching between CLBs.
CLBCLB very simply consists of a block that defines a Boolean function from several arguments (it is called a Look Up Table, LUT) and a trigger (flip-flop, FF). In modern FPGAs, the LUT has six inputs, but the figure shows three for simplicity. The output of the LUT is fed to the CLB output either asynchronously (directly) or synchronously (via an FF flip-flop running at the system clock).
LUT implementation principleIt is interesting to look at the principle of LUT implementation. Let us have some Boolean function y = (a & b) | ~ c . Its circuit diagram and truth table are shown in the figure. The function has three arguments, so it takes 2^3 = 8 values. Each of them corresponds to its own combination of input signals. These values are calculated by the FPGA firmware development program and written to special cells configuration memory.
The value of each cell is fed to its input of the output multiplexer LUT, and the input arguments of the Boolean function are used to select one or another value of the function. The CLB is the most important hardware resource of the FPGA. The number of CLBs in modern FPGA chips can vary and depends on the type and capacity of the chip. Xilinx has dies with CLB counts ranging from about four thousand to three million.
In addition to the CLB, there are a number of other important hardware resources inside the FPGA. For example, hardware multiply-accumulate units or DSP units. Each of them can perform multiplication and addition operations on 18-bit numbers every clock cycle. In top-end crystals, the number of DSP blocks can exceed 6000.
Another resource is blocks internal memory(Block RAM, BRAM). Each block can store 2 KB. The total capacity of such memory, depending on the crystal, can reach from 20 KB to 20 MB. Like CLBs, BRAMs and DSP blocks are connected by a switch fabric and extend throughout the die. By interconnecting CLB, DSP and BRAM blocks, very efficient data processing circuits can be obtained.
Advantages of FPGA
The first FPGA chip created by Xilinx in 1985 contained only 64 CLBs. At that time, the integration of transistors on chips was much lower than it is now, and digital devices often used "scattered logic" chips. There were separate microcircuits for registers, counters, multiplexers, and multipliers. Under specific device we created our own printed circuit board on which these low-integration microcircuits were installed.
The use of FPGA made it possible to abandon this approach. Even a 64 CLB FPGA saves significant space on printed circuit board, and the availability of reconfiguration added the ability to update the functionality of devices after manufacturing during operation, as they say “in the field” (hence the name - field-programmable gate array).
Due to the fact that any hardware digital circuit can be created inside an FPGA (the main thing is that there are enough resources), one of the important applications of FPGAs is prototyping ASIC chips.
ASIC development is very complex and expensive, the cost of error is very high, and the issue of logic testing is critical. Therefore, one of the development stages, even before starting work on the physical topology of the circuit, was its prototyping on one or more FPGA chips.
For ASIC development, special boards are produced containing many FPGAs connected to each other. The prototype microcircuit operates at significantly lower frequencies (maybe tens of megahertz), but allows saving on identifying problems and bugs.
However, in my opinion, there are more interesting applications of FPGAs. The flexible structure of the FPGA allows the implementation of hardware circuits for high-speed and parallel data processing with the ability to change the algorithm.
Comparison of hardware platforms Let's think about how CPU, GPU, FPGA and ASIC fundamentally differ. The CPU is universal, you can run any algorithm on it, it is the most flexible, and it is the easiest to use thanks to the huge number of programming languages and development environments.
At the same time, due to the versatility and sequential execution of CPU instructions, the performance decreases and the power consumption of the circuit increases. This happens because for every useful arithmetic operation The CPU performs many additional operations related to reading instructions, moving data between registers and cache, and other movements.
On the other side is the ASIC. On this platform, the required algorithm is implemented in hardware by direct connection transistors, all operations are related only to the execution of the algorithm and there is no way to change it. From here maximum performance and the lowest power consumption of the platform. But it is impossible to reprogram ASIC.
To the right of the CPU is the GPU. These chips were originally designed for graphics processing, but are now also used for mining computing. general purpose. They consist of thousands of small computing cores and perform parallel operations on an array of data.
If the algorithm can be parallelized, then the GPU can achieve significant acceleration compared to the CPU. On the other hand, sequential algorithms will be implemented worse, so the platform turns out to be less flexible than the CPU. Also, to develop for GPU you need to have special skills, know OpenCL or CUDA.
Finally, FPGA. This platform combines the efficiency of ASICs with the ability to change the program. FPGAs are not universal, but there is a class of algorithms and tasks that will show them better performance than on a CPU or even a GPU. The complexity of developing for FPGAs is higher, but new development tools are making this gap smaller.
The decisive advantage of FPGAs is the ability to process data as it arrives with minimal response delay. As an example, you can imagine a smart network router with a large number of ports: when an Ethernet packet arrives on one of its ports, many rules must be checked before selecting an output port. You may need to change some fields in the package or add new ones.
Using an FPGA allows you to solve this problem instantly: the bytes of the packet have just begun to arrive on the chip from the network interface, and its header is already being analyzed. The use of processors here can significantly slow down the speed of processing network traffic. It's clear that routers can have a custom ASIC that performs the most efficiently, but what if the rules for processing packets have to change? Only FPGAs can achieve the required flexibility combined with high performance.
Thus, FPGAs are used where high data processing performance, shortest response time, and low power consumption are needed.
FPGA in the cloud
In cloud computing, FPGAs are used for fast calculations, acceleration of network traffic and access to data arrays. This also includes the use of FPGAs for high-frequency trading on exchanges. FPGA boards with PCI Express and an optical network interface manufactured by Intel (Altera) or Xilinx.
FPGAs are great for cryptographic algorithms, DNA sequence comparison, and scientific tasks like molecular dynamics. Microsoft has been using FPGAs for acceleration for a long time search service Bing, as well as for Software Defined Networking within the Azure cloud.
Boom machine learning FPGA has also not been spared. Xilinx and Intel offer FPGA-based tools for working with deep neural networks. They allow you to obtain FPGA firmware that implements a particular network directly from frameworks like Caffe and TensorFlow.
Moreover, you can try all this without leaving home and using cloud services. For example, from Amazon you can rent a virtual machine with access to an FPGA board and any development tools, including machine learning.
FPGA on the edge
What else interesting things do FPGAs do? Why don’t they do anything! Robotics, self-driving cars, drones, scientific instruments, medical equipment, custom mobile devices, smart CCTV cameras and so on.
Traditionally, FPGAs have been used for digital processing one-dimensional signals (and competed with DSP processors) in radar devices, radio signal transceivers. With increasing chip integration and performance, FPGA platforms have become increasingly used for high-performance computing, such as 2D signal processing at the edge of the cloud.
This concept is most easily understood using a traffic camera with license plate recognition as an example. You can take a camera with the ability to transmit video over Ethernet and process the stream on a remote server. As the number of cameras increases, the load on the network will also increase, which can lead to system failures.
Instead, it is better to implement license plate recognition on a computer installed directly in the video camera body and transmit license plate numbers to the cloud in text format. To do this, you can even take relatively inexpensive FPGAs with low power consumption to make do with a battery. At the same time, it remains possible to change the operating logic of the FPGA, for example, when changing the license plate standard.
As for robotics and drones, in this area it is especially important to fulfill two conditions - high performance and low energy consumption. The FPGA platform is ideal and can be used, in particular, to create flight controllers for drones. They are already making UAVs that can make decisions on the fly.
Project development on FPGA
There are different levels of design: low, block and high. Low level involves using languages like Verilog or VHDL, in which you control development at the register transfer level (RTL). In this case, you form registers like in a processor and define logical functions, changing the data between them.
FPGA circuits always operate at specific clock speeds (typically 100-300 MHz), and at the RTL level you define the circuit's behavior down to the system clock frequency. This painstaking work results in designs that are as efficient as possible in terms of performance, FPGA die resource consumption, and power consumption. But this requires serious skills in circuit design, and even with them the process is slow.
At the block level, you are mainly engaged in connecting ready-made large blocks that perform certain functions to obtain the system-on-chip functionality you need.
On high level design, you will no longer control the data at every clock cycle; instead, you will concentrate on the algorithm. There are compilers or translators from C and C++ to the RTL level, for example Vivado HLS. It is quite smart and allows you to translate a wide class of algorithms to the hardware level.
The main advantage of this approach over RTL languages is the acceleration of development and especially testing of the algorithm: C++ code can be run and verified on a computer, and this will be much faster than testing algorithm changes at the RTL level. Of course, you have to pay for convenience - the scheme may not be as fast and will take up more hardware resources.
Often we are willing to pay this price: if we use the translator correctly, then the efficiency will not suffer much, and modern FPGAs have enough resources. In our world with a critical time to market indicator, this turns out to be justified.
Often you need to combine all three development styles in one design. Let's say we need to make a device that we could build into a robot and give it the ability to recognize objects in a video stream - for example, road signs. Let's take a video sensor chip and connect it directly to the FPGA. For debugging we can use hdmi monitor, also connected to the FPGA.
Frames from the camera will be transmitted to the FPGA via an interface that is clearly defined by the sensor manufacturer (USB is not useful here), processed and displayed on the monitor. To process frames you will need a framebuffer, which is usually located in external memory DDR installed on a printed circuit board next to the FPGA chip.
Typical block diagram of an FPGA design If the video sensor manufacturer does not provide Interface IP for our FPGA chip, then we will have to write it ourselves in RTL, counting clock cycles, bits and bytes in accordance with the data transfer protocol specification. We will most likely take ready-made blocks Preprocess, DDR Controller and HDMI IP and simply connect their interfaces. And we can write the HLS block, which searches and processes incoming data, in C++ and broadcast it using Vivado HLS.
Most likely, we will still need some kind of ready-made library of a detector and classifier of road signs, adapted for use in an FPGA. In this example, of course, I present a highly simplified design flowchart, but it reflects the logic of operation correctly.
Let's look at the design path from writing RTL code to getting a configuration file to load into the FPGA.
Design pathSo you write RTL code that implements the circuit you want. Before testing it on real hardware, you need to make sure that it is correct and correctly solves the required problem. To do this, RTL modeling is used in a simulator on a computer.
You take your circuit, presented only in RTL code for now, and place it on a virtual bench, where you apply sequences of digital signals to the inputs of the circuit, record the output diagrams, the time dependences of the output signals, and compare them with the expected results. Usually you find errors and go back to writing RTL.
Next, the logically verified code is fed as input to the synthesizer program. It converts a textual description of the circuit into a linked list of digital elements from the library available for a given FPGA die. This list will display items such as LUTs, triggers, and the connections between them. At this stage, elements are not yet tied to specific hardware resources. To do this, you need to impose Constraints on the circuit - in particular, specify which physical I/O pins of the FPGA chip the logical inputs and outputs of your circuit are connected to.
These constraints also require that you specify at what clock speeds the circuit must operate. The synthesizer output and constraint file are sent to the Implementation processor, which, among other things, handles Place and Route.
The Place process binds each still anonymous element from the netlist to a specific element inside the FPGA chip. Next, the Route process begins its work, which tries to find the optimal connection of these elements for the corresponding configuration of the FPGA switching matrix.
Place and Route operate based on the constraints we have placed on the circuit: I/O pins and clock speed. The clock period has a very strong influence on Implementation: it should not be less than the time delay on the logic gates in the critical circuit between two successive flip-flops.
Often it is not possible to immediately satisfy this requirement, and then you need to go back to the initial stage and change the RTL code: for example, try to reduce the logic in the critical chain. Once Implementation has completed successfully, we know which elements go where and how they are connected.
Only after this the process of creating a binary FPGA firmware file starts. All that remains is to load it into real hardware and check whether it works as expected. If problems arise at this stage, it means that the modeling was incomplete and all errors and shortcomings were not eliminated at this stage.
You can return to the simulation stage and simulate an emergency situation, and if this does not work, as a last resort, a debugging mechanism is provided directly in the working hardware. You can specify which signals you want to track over time, and the design environment will generate additional logic analyzer circuitry that sits on the chip next to your design, connects to the signals you're interested in, and stores their values over time. The saved timing diagrams of the desired signals can be downloaded to a computer and analyzed.
The article makes an attempt to determine the composition of the accompanying documentation for the developed digital modules for programmable logic integrated circuits (FPGAs). Developers must provide this accompanying documentation to the consumer/customer for the successful further use of the developed digital module in their projects at the stage of designing digital devices on the FPGA.
Introduction
So, what kind of design documentation should the developer be asked if the customer company or enterprise or another developer will subsequently use a “foreign” developed device in their projects? This article can serve as a “cheat sheet” in order to first correctly issue technical specifications for the development of a digital device for FPGAs, and then ask the developer for design documentation for an already developed digital device. Based on previous experience working with design documentation, an enterprise or firm usually uses the following standards and regulatory documents:
- GOST 2.102-68 ESKD. Types and completeness of design documents.
- GOST 15.101-98. System for developing and putting products into production. The procedure for carrying out research work.
- GOST R 15.201-20-00. System for developing and putting products into production. Products for industrial and technical purposes. The procedure for developing and putting products into production.
As a rule, these were firmware files and a program (description of a digital device in VHDL/Verilog or a set of digital circuits developed in a circuit editor using library elements of digital logic, such as flip-flops, registers, counters, decoders, etc.) on CD or DVD and programming instructions. That's all.
The author, for example, faced the following problem. One of the employees developed a complex multi-module digital device. I described all the modules in VHDL, and looked at the cyclograms of the operation of these modules and the digital device as a whole on a good and expensive oscilloscope. He did not know about Test Bench files and the possibility of conducting simulations or did not know how to write them; by the way, there were also no comments on the project and on the module descriptions. The situation can be even worse if the modules are represented by digital circuits designed in a circuit editor using library elements. Here lies one of the main drawbacks: besides the developer himself, it is unlikely that anyone else will understand this digital device, especially if the project is multi-module, and the description of each module is more than 100 lines or more than one monitor screen. This means that if another developer wants to implement new development or the project is such, an already developed digital device for the FPGA, he again needs to spend time developing this digital device.
History of the design issue for FPGAs
Currently, the FPGA market is one of the most dynamically developing. FPGAs are used in many industries. On this moment There is no unambiguous methodology for obtaining the FPGA configuration based on the functional model of the device at the system level that satisfies all hardware developers. The most popular approach to solving this problem is the use of IP core technology (Intellectual Property Cores). IP cores are ready-made components that make it easy to incorporate them into your own project to create a more complex system. This approach has one significant drawback - the attachment of IP nuclei to the elemental basis. Each IP core is optimized for a specific series of chips from a specific manufacturer, which significantly impairs the ability to transfer already created devices from one element base to another. The closed nature of commercial CAD architectures makes it impossible to add your own functional device models at the system level to derive device models at the register transfer level (RTL) based on them. The development of a digital module is carried out in the form of a digital circuit drawn in a circuit editor using the manufacturer’s built-in CAD library of basic circuit elements, such as flip-flops, decoders, counters, adders, etc.
Another popular approach that allows the transition from a functional model at the system level to a device model at the register transfer level is the use of system-level design languages (SLDLs). Such languages include SystemC, Handel-C, VHDL, Verilog, System Verilog. The main advantage is the independence from the hardware base in which the device will be implemented.
Thus, on the one hand, when using IP core technology, the hardware developer receives a high-quality solution, but strictly tied to the hardware basis in which the device is implemented. On the other hand, when using hardware description languages at the system level, the device implementation is hardware independent. From the above it follows that currently it is important to jointly use the hardware description language and IP cores of the manufacturer (Xilinx, Altera, Actel, etc.) and third-party development companies to speed up the design process of digital modules. When using digital modules from third-party manufacturers, sometimes there is a lack of information in the accompanying documentation.
Providing information about the developed digital module for FPGA
Depending on the methodology for obtaining the FPGA configuration based on the functional model of the device at the system level, the developer can distinguish the following types of digital module for the FPGA:
- Software - a developed digital module, transmitted to the consumer in the form of a description in the hardware description language (VHDL, Verilog) and/or developed in the Schematic Editor for further use in programs for automated synthesis of logic circuits and optimized for functional parameters.
- Firmware - a digital module developed by a third-party development company, called an IP core, transmitted to the consumer in the form of a logical circuit (netlist) based on the FPGA manufacturer’s logical element library and optimized for functional and electrical parameters.
At the documentation development stage, based on personal experience, it is necessary to draw up, in addition to the usual design documentation and technical specifications, carried out in accordance with GOST 15.101, GOST 15.201, GOST 2.102, GOST 2.114, documentation for all types of models (system, logical, circuitry) created at the stages of designing digital devices on FPGAs.
In other words, the set of design documentation for a digital device for FPGAs, in addition to the firmware file, programming instructions and a recorded project on CD/DVD, must also include accompanying documentation.
Table. List of sections of accompanying documentation
| Section title | View | |
| Software | Firmware | |
| General information | ||
| Purpose and scope | ABOUT | R |
| Specifications | ABOUT | ABOUT |
| Description of reset signals | ABOUT | ABOUT |
| Description of synchronization signals | ABOUT | ABOUT |
| Description of interfaces | ABOUT | R |
| Timing diagrams | R | ABOUT |
| Description of control registers | ABOUT | ABOUT |
| Structural (functional) diagram | R | R |
| Programming Guide | ABOUT | ABOUT |
| FPGA model or family, company manufacturer |
R | ABOUT |
| Digital Module Presentation for logic design on FPGA |
||
| RTL model | ABOUT | No |
| Logic model | No | ABOUT |
| Design Constraints | ABOUT | ABOUT |
Here is a list of sections (table) that should be included in the accompanying documentation for a digital module project for FPGAs. For each section, signs of the need to include the section in the set of documents are shown:
- “O” is a required section;
- “P” is the section recommended for delivery.
Recommended file formats for submitting accompanying documentation are MS Word, PDF ( best format), HTML. Description files in the hardware description language (VHDL, Verilog) and/or developed in the Schematic Editor are provided in the form required by the CAD software for development. An exception may be the additional provision in graphic format (JPEG, BMP) of digital circuit files developed in the Schematic Editor.
General information
This section describes general information about the developed digital module in the form of a description:
- functional diagram and its component blocks/parts;
- reset signals, synchronization;
- applied interfaces;
- control registers;
- time diagram;
- programming.
Purpose and scope
The purpose of the digital module and its areas of application are determined.
Specifications
A description of its main technical characteristics, such as performance, power consumption for a specific FPGA die, number of occupied gates, type of FPGA die used. Additionally, the FPGA manufacturer's CAD software used in the development of the digital module and the software used for modeling and verification are indicated. For all programs used, the version and installed updates are indicated. A graphical representation of the digital module in the form of a “black box” is provided with the designation of external inputs/outputs and given short description their destinations.
Description of reset signals
Provided detailed information about reset signals:
- List of external and internal reset signals.
- Timing parameters and timing diagrams of reset signals.
- Circuits for generating internal reset signals, if any, are part of the digital module.
- Relationships with other signals (especially synchronization signals).
Description of synchronization signals
Here are the details about the synchronization signals:
- description external signals synchronization;
- timing parameters of synchronization signals;
- description of internal synchronization signals and the scheme for their generation;
- timing relationships between synchronization signals from different sources;
Description of interfaces
Features of the use of all interfaces that are part of the developed digital module are given, preferably unified for organizing interaction with other nodes of the system on a chip. Additionally, an Internet link to a full description is provided. standard interface or the interface description itself is provided. At the moment, AMBA, PLB, and Wishbone bus interfaces are accepted as unified interfaces for digital modules.
Timing diagrams
The necessary information is provided for organizing data exchange through interfaces and other inputs/outputs of the digital module: graphical representation of timing diagrams, description of data transfer protocols, requirements for external signals supplied to the digital module (duration, frequency, etc.), and other information .
Description of control registers
A description of all control registers of the digital module is provided. A typical control register description contains the register name, the register address in the internal address space, the initial value after the reset signal is removed, the access type (read/write), and a description of the internal fields.
Structural (functional) diagram
An image of the internal structure of the connections of the main internal nodes/blocks of the digital module is provided, as well as their brief text description. Additionally, a description of the main internal blocks of the digital module is given. The purpose of this document is to provide the consumer with the information necessary to understand the principles of operation of the digital module.
The number of blocks described and the scope of the description are determined by the developer of the digital module. It is preferable that the minimum number of modules described correspond to the number of elements of the structural (functional) diagram of the digital module.
A typical description of the indoor unit contains:
- purpose of the block;
- structural (functional) diagram of the block (if necessary);
- operating modes and algorithms;
- work time diagrams;
- organization of block management;
- organization of communication with other blocks;
- any other information.
Programming Guide
Provides all necessary information about the programming process using the CAD software of the manufacturer of the digital module in the FPGA, the required tools for development and debugging software, software libraries.
FPGA model or family, manufacturer
For Firmware of a digital module, the FPGA manufacturer, model or family of FPGA and its speed characteristics are indicated. For the Software digital module, information is provided on the amount of resources occupied and the requirements for the used FPGA.
Representation of a digital module for logic design
The article discussed the difficulties in using a “foreign” project in VHDL - the lack of suitable guidelines for naming and rules for writing programs. Also given were general guidelines on names, good manners for writing programs, and guidelines for synthesis. These issues should be discussed in as much detail as possible with the developer if in the future you plan to continue development or upgrading on your own, before he starts developing the RTL model of the digital module on the FPGA. This especially applies to the type of Software digital module on FPGA. This part of the article describes the general requirements for the entire project of the developed digital module on FPGA. Here are the issues that you should pay attention to when drawing up technical specifications for the development of a digital module on an FPGA, and this especially concerns the transfer of work results.
RTL model
A digital module, described in a synthesized subset of the Verilog or VHDL language and/or developed in the Schematic Editor, is intended for use at the stage of FPGA logic synthesis. Delivered to Software in the form of an assembled digital module project in the CAD software of the FPGA manufacturer. For the digital Firmware module, the RTL model is provided under a separate agreement.
In addition to the RTL model files, the following are transmitted:
- Instructions for using the model.
- Description of the memory blocks included in the model, including memory type, size, number of memory blocks, hierarchical name of the memory block.
- Description of the process of creating ready-made kernels using programs to create them (for example, CoreGenerator for Xilinx ISE). In the absence of descriptions, there may be limitations for re-design and application due to technology and manufacturer dependence.
- In the case of using a microprocessor from a manufacturer (for example, from Altera - Nios processor; from Xilinx - Microblaze, PowerPC microprocessors), a description of the process of configuring the processor core and its peripherals is required.
- A set of tests (Test Bench files) for verification and simulation of a digital module, written in Verilog and/or VHDL and/or System Verilog.
- Any other additional information.
Logic model
The model is a list of circuits described using Verilog or VHDL languages in the basis of the FPGA manufacturer's library, and is supplied for the Firmware of the digital module.
In addition to the logical model files, the following are transmitted:
- Instructions for using this model.
- A set of tests (Test Bench files) for verification and simulation of a digital module, written in Verilog and/or VHDL and/or System Verilog.
- Guide to working with a set of tests for modeling and verification of a digital module.
- Any other additional information.
Design Constraints
Design constraints are provided as a file describing a set of constraints imposed on the digital module when it is included in the system-on-chip logic model. This set includes clock constraints, timing constraints, restrictions on the interaction of the digital module with other modules, and operating conditions for the digital module. The Synopsis Design Constraints (SDC) format or the FPGA manufacturer's CAD format is preferred.
A sample list of restrictions for synchronization signals:
- time diagram (Clock waveform);
- clock frequency instability (Jitter);
- changing the clock frequency phase;
- duration of switching times (Transition times);
- timing diagrams of derived clock waveforms;
- any other additional information.
A set of restrictions for synchronization signals is required for Software and Firmware digital modules.
Sample list of time restrictions:
- Arrival times at inputs;
- time of appearance of signals at outputs (Required times at outputs);
- Multi-cycle paths;
- false paths;
- duration of data signal switching times (Data signal transition times);
- any other additional information.
Conclusion
The following set of accompanying documentation for the developed digital modules for FPGAs is provided by agreement between the consumer and the developer. Most often, the developer simply provides a digital module described in VHDL, Verilog, System Verilog and/or developed in a circuit editor. Regarding additional documentation, the developer’s answer is most often the following: “The digital module works, so take it and use it. There is nothing complicated in describing the circuit in hardware language: you can figure it out yourself.”
In the author’s opinion, you can figure out anything, it all depends on the desire and time spent, and the time spent on understanding “someone else’s” project for an already developed digital module is directly proportional to the experience of describing equipment in VHDL, Verilog and knowledge digital and microprocessor circuitry. This can be avoided if you initially agree with the developer on the composition of the accompanying documentation, then the use of the digital module in your project becomes easier, and its implementation will happen faster.
To summarize, the author would like to note that when formulating the task of developing a digital device on an FPGA, one should adhere to the recommendations given in the article, then problems with reuse or when upgrading a previously developed digital device will not arise.
Literature
- Denisov A. Some tips for designing digital devices on VHDL for FPGAs // Components and Technologies. 2009. No. 12.
- GOST 2.102-68 ESKD. Types and completeness of design documents.
- GOST 2.114-95 ESKD. Technical conditions.
- GOST 15.101-98. System for developing and putting products into production. The procedure for carrying out scientific research work.
- GOST R 15.201-20-00. System for developing and putting products into production. Products for industrial and technical purposes. The procedure for developing and putting products into production.
USING FPGAs IN MODERN DEVICES
Tupikov Pavel Andreevich
5th year student, Department of ART, Omsk State Technical University, Russian Federation, Omsk
Today, programmable logic integrated circuits (FPGAs) are increasingly used in various modern devices, This is due to the fact that FPGAs have significant advantages over conventional digital chips. These advantages include:
· Temporary characteristics of the product are improved.
· The price of the product decreases.
· Product dimensions are reduced.
· Product reliability increases (the number of discrete chips decreases)
Increases product flexibility (FPGAs can always be reprogrammed)
The FPGA architecture has a complex structure (Fig. 1)
Figure 1. Internal structure of the FPGA
As can be seen from Figure 1, the main part of the FPGA consists of programmable logic blocks and programmable internal connections.
The process of programming (firmware) of the FPGA consists of forming the necessary connections between the inputs and outputs of the device.
Today there are two world leaders in the production of FPGAs. These are American companies Xilinx and Altera.
Each company offers its own CAD software for working with FPGAs. Xilinx offers the Xilinx Software Development Kit (SDK). Altera offers Max+Plus II and Quartus II, as well as the ModelSim modeling system.
To create firmware programs, languages for describing the operation of hardware are usually used; the most common languages today are the following:
Verilog HDL.
The VHDL language is the most difficult to learn, but at the same time it has the greatest capabilities at the functional and behavioral levels of abstraction, but has fewer capabilities at the structural level of abstraction compared to Verilog HDL; the VITAL library was developed to expand the capabilities of the VHDL language (Fig. 2).
Figure 2. Levels of abstraction Verilog And VHDL
An example of the work of the Verilog HDL language is a program implemented on the FPGA CYCLONE III EP3C5E1444C8N of the Mini-DiLab stand, a general view of which is shown in Fig. 3.
Figure 3. General view of the board Mini - DiLab
This program implements sequential switching of led0-led7 LEDs, with the choice of increasing the movement of the “light” using the pba and pbb buttons, as well as controlling the switching speed using the sw0, sw1 switches.
//Program text
module project( output led, input clk_25mhz, input pba input pbb
input sw);
// Purpose of internal project connections
wire s1;
wire s2;
wire s3;
// Call other files (subroutines) connected to the project
Tr tr_1 (.out(s2), .set(pba), .res(pbb));
Counter counter_1 (.q(s1), .clk(clk_25mhz), .up(s2));
Mx mx_1 (.a(s3), .in(s1), .load(sw));
Dc3_8 dc3_8_1 (.out(led), .in(s3));
endmodule// end of program
Subroutine tr
module tr(out, set, res); // Create a program
// Assignment of inputs/outputs
outputreg out;
input set;
input res;
// Initialization
initial
begin
Out<= 1"d0;
// Main program code
always @(negedge set or negedge res)
begin
if(~(set))
Out<= 1"d1;
else
Out<= 1"d0;
endmodule // End of the program
Subroutine counter
module counter(con, q, clk,up); // Start of the program
outputreg con;
output q = con;
input up, clk;
// Main program code
always @(posedge clk)
begin
if(clk)
if(up)
Con<= con - 1"d1;
else
Con<= con + 1"d1;
endmodule//End of program
Subroutine mx(multiplexer)
module mx( output reg a, input in, input load);
// Main program code
always @*
begin
case(load)
2"b00: a = in;
2"b01: a = in;
2"b10: a = in;
2"b11: a = in;
endcase
endmodule // End of the program
Subroutine dc3_8 (multiplexer)
module dc3_8(out, in); // Start of the program
// Assignment of inputs/outputs
output reg out;
input wire in;
// Main program code
always @*
begin
case(in)
3"d0: out = 8"b11111110;
3"d1: out = 8"b11111101;
3"d2: out = 8"b11111011;
3"d3: out = 8"b11110111;
3"d4: out = 8"b11101111;
3"d5: out = 8"b11011111;
3"d6: out = 8"b10111111;
3"d7: out = 8"b01111111;
endcase
endmodule // End of the program
The program was implemented in Quartus II CAD software.
After compiling the program, the compiler did not generate errors or comments in the program related to the analysis and syntax of the program (Fig. 4).
Figure 4. Project message window
The comments made by the compiler indicate that there is no license for Quartus II (the free version of the program was used for training) and the absence of files necessary for modeling the project.
RTL The structure of this project is shown in Fig. 5.
Figure 5. Project implementation ( RTL structure)
As shown in Fig. 6 in this program only a small part of the capabilities of this FPGA is used.
Figure 6. Part of the FPGA involved in the project
Conclusions: Programmable logic integrated circuits can be used in many devices. To learn to work with them, familiarity with hardware description languages (Verilog HDL and VHDL) should be introduced into the educational program of specialties related to the design and construction of electronic equipment.
Bibliography:
1. Grushevitsky R.I. Design of systems on program logic chips / R.I. Grushevitsky, A.X. Mursaev, E.P. Gloomy. St. Petersburg: BHV Petersburg, 2002. - 608 p.
2. Kolomov D.A. Altra MAX+plus II and Quartus II computer-aided design systems. Brief description and tutorial / D.A. Kolomov, R.A. Myalk, A.A. Zobenko, A.S. Filippov. M.: IP RadioSoft, 2002. - 126 p.
3. Maxfield K. Design on FPGA. Course for a young fighter./ K. Maxfield. M.: Publishing house "Dodeka-XXI", 2007. - 408 p. (translation from English).
FPGA (Programmable Logic Integrated Circuit) is an integrated circuit designed to build digital circuits from a description in a special programming language. In other words, an FPGA is a chip that seems to contain a bunch of elements like 74HCxx. What exactly these logical elements will be, what connections there will be between them, and what connections the resulting circuit will have with the outside world are determined at the FPGA programming stage.
Note: As far as I could find out, in Russian today the terms FPGA and FPGA (Field-Programmable Gate Array, User-Programmable Gate Array) are considered to be interchangeable, which will be used further in the text. However, it is worth knowing about the existence of an alternative point of view, according to which FPGA (FPGA) is one of the varieties of FPGA (PLD, Programmable Logic Device).
FPGA Basics
To program FPGAs, hardware description languages (HDL, Hardware Description Language) are used. Among them, the most popular are Verilog (and its dialects, in particular SystemVerilog), as well as VHDL. The languages are similar in many ways, but have different syntax and differ in some details. If Verilog is the C of the world of hardware description, then VHDL is, accordingly, Pascal. As far as I know, VHDL is somewhat less popular, particularly due to its verbosity compared to Verilog. Among the advantages of VHDL (or disadvantages, depending on whom) we can name strict static typing. Verilog sometimes allows implicit type casting. To continue the analogy with C and Pascal, the languages are not so different that you can’t learn them both.
Currently, the leading FPGA manufacturers are Altera (now owned by Intel) and Xilinx. According to information from various sources, together they control at least 80% of the market. Other players worth noting are Actel (acquired by Microsemi), Lattice Semiconductor, Quicklogic and SiliconBlue. You can work with Xilinx hardware only from the Xilinx development environment (called Vivado), and the Altra development environment (called Quartus) understands only Altera hardware. That is, full vendor lock, and by choosing a specific FPGA for your project, you automatically select the development tools of the corresponding manufacturer, their technical support, documentation, software licensing conditions, policy regarding the termination of hardware support, and so on.
FPGAs are often used in tasks where you want to significantly speed up certain calculations by implementing them directly in hardware. For example, FPGAs have found wide application in the field of signal processing, say in oscilloscopes, spectrum analyzers, logic analyzers, signal generators, Software Defined Radio and even some monitors. In particular, LimeSDR uses Altera Cyclone IV, and the Rigol DS1054Z oscilloscope uses Xilinx Spartan-6, as well as ProASIC 3 from Actel. Other applications that I have heard about include computer vision, speech recognition and bioinformatics. There are other projects, in particular for the development of web servers and DBMS running on FPGA. But, as far as I know, this direction is still very experimental.
Xilinx or Altera?
As they say, the best Linux is the one your fellow Linux guru uses.
My friend, an FPGA guru in the person of Dmitry Oleksyuk, advised me to start with the Arty Artix-7 development board from Digilent. The FPGA used in it is Artix-7 from Xilinx. Digilent itself does not deliver to Russia, but the device is also available on AliExpress, although with a noticeable markup (the official price is $99). It is also sold on eBay. This is a fairly powerful board, which, nevertheless, costs quite reasonable money.
Fun fact! If you just want to program in Verilog or VHDL, strictly speaking, you don't need to buy any FPGA board. At first, you can limit yourself to a simulator, the work with which will be discussed below.
One of the interesting features of the board is the arrangement of the sockets in a manner compatible with Arduino shields. Also included with the board is an insert with which you can obtain a license for Vivado, which opens up all its capabilities. The license is valid for one year from the moment of activation, and is also tied to one computer by OS type and MAC address.
Upon delivery. I've heard that devices with FPGAs on board have a high chance of not going through customs. The AliExpress store, the link to which I provided above, delivers boards to Russia through the SPSR courier service. To clear customs, it was necessary to fill out an online form with passport data (data only, no photo) and contact phone number, as required by current Russian legislation. After this, the board was delivered by courier directly to the door without any questions asked.
Installing Vivado
The Vivado development environment is available for download from the Xilinx website. Be mentally prepared for the fact that before downloading you will have to register and fill out a fairly detailed form about yourself. Download the archive called “Vivado HLx 2017.2: All OS installer Single-File Download”. Don’t accidentally confuse it with some “Vivado Lab Solutions”, this is absolutely not what you need. The archive weighs more than 20 GB, so we must be patient.
Unpack the archive and run the installer. Install Vivado HL System Edition. Its full version will take up 47 GB of disk space. Personally, I unchecked the Software Development Kit and left support for only 7 Series devices, which reduced the size to 12 GB. Looking ahead a little, I’ll note that this configuration turned out to be quite sufficient.
Before launching Vivado, you need to add Arty Artix-7 support to it, since out of the box it doesn’t know anything about this board. It's done something like this:
cd ~/ opt/ xilinx/ Vivado/ 2017.2 / data/ boards/ board_files
wget https:// github.com/ Digilent/ vivado-boards/ archive/ master.zip
unzip master.zip
mv vivado-boards-master/ new/ board_files/* ./
rm -r vivado-boards-master
rm master.zip
We also download and save the Arty_Master.xdc file somewhere. We will need it later. The file contains a description of the LEDs, switches, and so on located on the board. Without it, blinking LEDs on Verilog will not be easy.
First project on SystemVerilog
In Vivado we say File → New Project... Select RTL Project as the project type, check the Do not specify sources at this time checkbox. In the board type selection dialog, find Arty in the list.
First of all, add the previously downloaded XDC file to the project. Copy it to the directory with the project. Then we say File → Add Sources... → Add or create constraints → Add Files, find a copy of the file, click Finish. In the project file tree (Sources), in the Constraints group, the file Arty_Master.xdc, or whatever you named the copy, will appear. Open it and uncomment all the lines in the Clock signal, Switches and LEDs groups.
Next we say File → Add Sources… → Add or create design sources → Create File. In the file type, select SystemVerilog, enter something like hello in the file name. We say Finish. Next, the Define Module dialog will appear, which will prompt you to click on the module interface. The dialog is quite useless, because it is more convenient to do the same thing directly in the code, so click Cancel.
In the source tree we find a new file hello.sv, it will be in the Design Sources group. Open and write the following code:
`timescale 1ns/1ps
module hello(
input logic CLK100MHZ,
input logic [ 3 : 0 ] sw,
output logic [3:0] led
)
;
always @ (posedge CLK100MHZ)
begin
if (sw[ 0 ] == 0 )
begin
led<=
4"b0001
;
end
else
begin
led<=
4"b0000
;
end
end
endmodule
If everything was done correctly, at this stage Vivado will look something like this (clickable, PNG, 71 KB):
Program compilation is carried out in two stages - synthesis and implementation. At the synthesis stage, the program is translated into an abstract circuit of logical gates and other elements. At the implementation stage, a decision is made on how to flash this circuit into a specific piece of hardware.
Let's start the synthesis by saying Flow → Run Synthesis, or simply pressing F11. In the upper right corner you will see an indication that the process is in progress. It can take quite a long time, depending on your computer and the complexity of the program. On my laptop, the synthesis of the above program was completed in about 10 seconds. If you now say Flow → Open Synthesized Design, you can see a beautiful picture like this:
It's time to flash our board. We say Flow → Run Implementation, then Flow → Generate Bitstream. We connect the board to the computer via USB, in Vivado we say Flow → Open Hardware Manager → Open target → Auto Connect → Program device. You will need to specify the path to the bit file. For me it was as follows:
./first-project.runs/impl_1/hello.bit
We say Program. Now the LD4 LED on the board is lit if the SW0 switch is lowered (see the photo of the board above). If the switch is raised, the LED does not light up. Simple, of course, but it’s “hello, world”, what did you expect? :)
Simulation
Simulation is the virtual execution of Verilog or VHDL code directly on your computer, without any FPGAs. It is both a debugging tool and a kind of framework for covering code with tests.
When I tried the simulation, the first thing I discovered was that it didn't work for me. The logs were simple:
ERROR: Failed to compile generated C file [...]xsim_1.c.
For this error, Google found only all sorts of nonsense in the style of “try disabling your antivirus.” As a result, adding the -v 2 flag to the script ~/opt/xilinx/Vivado/2017.2/bin/xelab helped solve the problem. With its help, I found out that Clang, the binary of which Vivado carries with it, crashes with the following error:
/a/long/path/to/clang: error while loading shared libraries:
libncurses.so.5: cannot open shared object file: No such file or
directory
And this error and its solution are already described on Arch Wiki. Personally, I just copied an already existing file from the Vivado_HLS directory:
cp ~/opt/xilinx/Vivado_HLS/2017.2/lnx64/tools/gdb_v7_2/libncurses.so.5\
~/opt/xilinx/Vivado/2017.2/lib/lnx64.o/libncurses.so.5
... after which everything worked. So, now, actually, an example of the simulation.
By analogy with how we created hello.sv earlier, we create a new file hello_sim.sv in the Simulation Sources group. In the file we write the following code:
`timescale 1ns/1ps
module hello_sim() ;
logic clck_t;
logic [ 3 : 0 ] sw_t;
logic [ 3 : 0 ] led_t;
Hello hello_t(clck_t, sw_t, led_t) ;
initial begin
clck_t<=
0
;
sw_t<=
4"b0000
;
#
1
;
clck_t <=
1
;
#
1
;
clck_t <=
0
;
#
1
;
assert (led_t === 4"b0001 ) ;
Sw_t<=
4"b0001
;
#
1
;
clck_t <=
1
;
#
1
;
clck_t <=
0
;
#
1
;
assert (led_t === 4"b0000 ) ;
end
endmodule
In the source tree, right-click on the file and select Source Node Properties. In the Used In section, uncheck the Synthesis and Implementation boxes. We don’t want any tests to clog our far from rubbery FPGA, do we?
Now we say Flow → Run Simulation → Run Behavioral Simulation. As a result, you will see something like this:
It can be seen that when sw is zero, led is one and vice versa. In this case, all changes occur on the edge of the clock signal. The program appears to be working correctly. Well, nothing fell on the assertions, which seems to hint.
Conclusion
The archive with the project described above can be downloaded. I would recommend the following as additional sources of information:
- If you are interested in details on hardware, pay attention to
Loading...
