You finally finish writing the Verilog for that amazing new DSP function that will revolutionize human society and make you rich. Does it work? Your first instinct, of course, is to blow it into your FPGA of choice and see if it works. If it does, that was a great idea. If it doesn’t, it was a terrible idea because — typically — it is hard to look inside the FPGA. That’s why you’ll typical simulate your logic on a desktop computer before you commit it to the FPGA. But that means you have to delay gratification long enough to write a testbench — a piece of hardware description language (HDL) code that exercises the function you wrote. In this post I’ll show you a small piece of software that can read your Verilog module and automatically create most of a testbench for you. The code originally came from GitHub, but I wanted to make some changes to it, so I forked it and I’ll tell you about the changes I made. This isn’t specific to a particular FPGA. Any Verilog project can use the tool to generate a simple starter testbench.
Writing a testbench isn’t that hard. You usually use the same language you wrote the original code in but since it won’t reside in silicon, you can do things in the simulator that you can’t get away with in code that you’ll synthesize. However, it is a bit painful to have to always write more or less the same code, especially if you have a lot of modules you want to test. But it is a good idea to test small modules before linking them together and then test them linked together, too. With this little Python script, it is very easy to generate a simple testbench and then further elaborate it. It isn’t life-changing, but it does save some time. If you want to try this out, you’ll need something to run the Python script on, of course. You also need a Verilog simulator or you can use EDA Playground to try all this out in your browser.
Continue reading “FPGA Testbenches Made Easier”
Last time I talked about how I took the open source Verifla logic analyzer and modified it to have some extra features. As promised, this time I want to show it in action, so you can incorporate it into your own designs. The original code didn’t actually capture your data. Instead, it created a Verilog simulation that would produce identical outputs to your FPGA. If you were trying to do some black box simulation, that probably makes sense. I just wanted to view data, so I created a simple C program that generates a VCD file you can read with common tools like
gtkwave. It is all on GitHub along with the original files, even though some of those are not updated to match the new code (notably, the PDF document and the examples).
If you have enough pins, of course, you can use an external logic analyzer. If you have enough free space on the FPGA, you could put something like SUMP or SUMP2 in your design which would be very flexible. However, since these analyzers are made to be configurable from the host computer, they probably have a lot of circuitry that will compete with yours for FPGA space. You configure Verifla at compile time which is not as convenient but lets it have a smaller footprint.
Continue reading “X-Ray Vision for FPGAs: Using Verifla”
All of the tools you need to work with the FPGA Arduino — the Vidor — are now in the wild!
We reported earlier that a series of French blog posts finally showed how all the pieces fit together to program the FPGA on the Arduino MKR4000 Vidor board. Of course, I wasn’t content to just read the Google translation, I had to break out the board and try myself.
I created a very simple starter template, a tool in C to do the bitstream conversion, required, and bundled it all together in one place. Here’s how you can use my starter kit to do your own FPGA designs using the Vidor. I’m going to assume you know about FPGA basics and Verilog. If you don’t, why not check out the FPGA boot camps first?
The first thing you’ll want to do is grab my GitHub repo. You’ll also need the Arduino IDE (a recent copy) and Intel’s Quartus software. Inside, you’ll find three directories, two of which contain slightly modified copies of original Arduino files. But before you start digging in, let’s get the high-level overview of the process.
Continue reading “Hands on with the Arduino FPGA”
If you speak French and you have an Arduino Vidor 4000, you are in luck because there’s some good news. The good news is there’s finally some inside information about how to configure the onboard FPGA yourself. The bad news though is that it is pretty sparse. If your high school French isn’t up to the task, there’s always Google Translate.
We knew some of this already. You’ll need Quartus, the FPGA design tool from Altera — er, Intel — and we know about the sample project on GitHub, too. Instead of using conventional Verilog or VHDL, the new information uses schematic capture, but that’s OK. All the design entry winds up in the same place, so it should be easy to adapt to the language of your choice. In fact, in part 2 they show both some schematics and some Verilog. Google Translate does have a little trouble with code comments, though. If you want something even stouter, there’s an example that uses Verilog to output a video frame.
Continue reading “Flash: Arduino Vidor FPGA Instructions Hit France”
Sometimes you start something simple and then it just leads to a chain reaction of things. I wanted to write a post about doing state machines in Verilog and target the Lattice iCEstick board that we often use for quick FPGA projects. That led to a small problem: how do you show what’s going on inside? In this series of posts, we’ll look at building a logic analyzer into an FPGA to help debug itself, instantiating memory, and — finally — state machines.
Logic analysis is a common tool in FPGA development. If you use Altera, they have Signal Tap available that lets you build a simple logic analyzer into the FPGA that talks back to your PC. Xilinx has ChipScope which is about the same. Sometimes those tools either cost money or are limited in some way in the free versions. I have my sights set on a tool that can be used with the Lattice architecture.
Sure, you can ship data out on I/O pins and then use a regular logic analyzer to pick up the data. But that isn’t very handy. So I thought about writing a generic logic analyzer component. But before I did I decided to check to see if someone else had already done it.
Spoiler alert: they did, but I wanted something a little different so I wound up extending the program significantly. What I wound up with is a reasonably portable Verilog logic analyzer that can produce traces like this one:
Keep in mind, this isn’t a simulation. This is real data pulled off the actual FPGA. Yes, that is gtkwave producing the plots, but the input data is a VCD file generated from samples taken inside the FPGA.
Continue reading “Logic Analyzers for FPGAs: A Verilog Odyssey”
We were contacted by [morbo] to let us know about a project on the AdaCore blog that concerns programming a PicoRV32 RISC-V softcore with Ada. The softcore itself runs on a Lattice ICE40LP8K-based TinyFPGA-BX FPGA board, which we have covered in the past.
The blog post describes how to use the Community edition of the GNAT Ada compiler to set up the development environment, before implementing a simple example project that controls a strip of WS28212b RGB LED modules. There are two push buttons changing the animation and brightness of the lights.
The source can be found at the author’s Github repository, and contains both the Ada source and the Verilog source for the PicoRV32 softcore. To build the project one needs the GNAT compiler, as well as the open-source iCE40 development tools to compile the softcore.
There is a video demonstrating the finished example project, that we’ve placed below the break.
Continue reading “Programming A RISC-V Softcore With Ada”
Ok, we’ll admit it. We like FPGAs because it reminds us of wiring up a 100-in-1 kit when we were kids. But the truth is, many projects are just as well off to have a CPU. But there’s a real sweet spot when you have a CPU and an FPGA together. Intel (or Altera, if you prefer) has the NIOS II CPU core, but that’s hard to configure, right? Maybe not, thanks to a project by [jefflieu] over on GitHub. He’s assembled some basic definitions and libraries to easily — relatively speaking — use NIOS II on the MAX1000 as well as a few other boards. The MAX1000 is a pretty nice board for about $30, so this is a very inexpensive way to get into “System on Chip” (SOC) development.
[jeff] goes into more detail in a blog post, but the idea is pretty simple. We tried it, and it works very well, although we found a few things hard to follow so read on to see how we managed.
The idea behind SoC development is you define your CPU configuration and then your hardware devices. Then you write software to talk to those custom hardware devices and — of course — write your actual application code. So you don’t just write a program, you also define the CPU the program will run on and the hardware that it will talk to.
There are several ready-to-go I/O devices included in the project, but the real fun will be writing your own. The Intel tools have the C compiler and everything else you need. You could also do everything from scratch, but these tools make it much easier to get started.
Continue reading “Easy FPGA CPU with MAX1000”