This video is an introductory presentation about FPGA and programmable logic technology. I delivered this 45 minutes talk at an event hosted by 7 Peaks Software in Bangkok, Thailand, on November 19th, 2019.
Category: Tutorial
Converting the image file to a bitmap format makes for the easiest way to read a picture using VHDL. Support for the BMP raster graphics image file format is built into the Microsoft Windows operating system. That makes BMP a suitable image format for storing photos for use in VHDL testbenches.
In this article, you will learn how to read a binary image file like BMP and store the data in dynamic memory in the simulator.
Reading signal values from file is an alternative way of generating stimuli for the device on test (DUT). The testbench sequence and timing is hard-coded in a stimulus file that is read by the VHDL testbench, line by line. This allows you to easily change the pattern of the waveform that you want to feed to the test object.
Sometimes you have a very specific test pattern or sequence of events that you want to put your DUT through.
A convenient way to populate block RAM with initial values is to read binary or hexadecimal literals from an ASCII file. This is also a good way to create a ROM (read-only memory) in VHDL. After all, RAM and ROM are the same thing in FPGAs, ROM is a RAM that you only read from.
The examples throughout this article will assume that the following constants and RAM type have been declared at the start of the declarative region of the VHDL file.
I was a little annoyed by the peculiarities of the AXI interface the first time I had to create logic to interface an AXI module. Instead of the regular busy/valid, full/valid, or empty/valid control signals, the AXI interface uses two control signals named “ready” and “valid”. My frustration soon changed to awe.
The AXI interface has built-in flow control without using additional control signals. The rules are easy enough to understand, but there are a few pitfalls one has to account for when implementing the AXI interface on an FPGA.
I’m excited to announce that the VHDL and FPGA course that I have been working on for the last six months is starting to become complete. The course is in beta at the moment, and I am planning on launching it for the first time this autumn.
Who is the FPGA course for?
The FPGA course is intended for the developer who has knowledge of other programming languages, but is new to VHDL and FPGAs.
Constrained random verification is a testbench strategy that relies on generating pseudo-random transactions for the device under test (DUT). The goal is to reach functional coverage of a number of predefined events through random interaction with the DUT.
Open Source VHDL Verification Methodology (OSVVM) is a free VHDL library which includes a number of convenient packages for creating constrained random testbenches. We are particularly interested in the RandomPkg and CoveragePck, which we will be using in this article.
Circular buffers are popular constructs for creating queues in sequential programming languages, but they can also be implemented in hardware. In this article, we will create a ring buffer in VHDL to implement a FIFO in block RAM.
There are many design decisions you will have to make when implementing a FIFO. What kind of interface do you need? Are you limited by resources? Should it be resilient to over-read and overwrite? Is latency acceptable?
An interactive testbench is a simulator setup where input to the device under test (DUT) is provided by an operator while the testbench is running. Most often, this would mean you entering commands in the simulator console to provide the DUT with stimulus.
While you should always create a self-checking testbench, an interactive testbench can be a nice supplement. It’s easier to perform ad-hoc testing with an interactive testbench at hand, than it is to change the code of the self-checking testbench.
A self-checking testbench is a VHDL program that verifies the correctness of the device under test (DUT) without relying on an operator to manually inspect the output. The self-checking testbench runs entirely on its own, and prints an “OK” or “Failed” message in the end.
Every VHDL module should have an associated self-checking testbench. It’s important to be able to verify that all modules have the intended behavior at any time. For example,