So, my thought from last week was that I might be able to post something about using push-buttons on an FPGA, and the problems they struggle with. Specifically, I wanted to discuss bouncing.

The debugging bus we just created provides the perfect environment for evaluating button bouncing, and so I started to put a post together on the topic. But … I wanted to add something more on the topic beyond what I had read of this phenomena. I wanted to add scope/traces of signals bouncing, and even share the code so that anyone could download it and try it and see how their own development board responded when a button was pressed.

Sounds neat, right?

But doing this required I run the debugging test bus (with modifications for catching bouncing components), on my hardware. In this case, I was going to use the Digilent Arty, for a demonstration, although the test should run on any FPGA, with a UART and I may try out some others to see if the button performance I am getting is any different.

My first surprise came when I tried building the new/modified project using Vivado: I was quickly reminded that things that work with Verilator may not always always work with your build tools.

What was different

I found a couple differences between Verilator and Vivado this week:

  1. Verilator doesn’t detect when a wire (or register) is being set in multiple places.

  2. Verilator can’t always tell the difference between wires and registers.

  3. I am aware of a third difference as well: in Xilinx, all unspecified flip flops start initially with a value of 1. Verilator starts with what appears to be random values.

Given that Verilator is an open source project, and that posts on the web (like this one) seem to live forever, these differences may be gone by the time you read this post.

I’ve since updated the debugging bus project with these changes, so that it now works. I also found a bug or two in the software support. Those have also been changed, and so the whole now works on real hardware (i.e., on my Digilent Arty).

If you’d like to see the changes, please feel free to browse the project’s GitHub log. There you’ll find a set of six changes that were made to the debugging bus in order to get it to synthesize and work.

I still love Verilator

These differences aren’t deterring me from using Verilator. How could they? Verilator still finds most of the bugs in any design in the time it takes Vivado to start synthesizing my code. It can also find bugs that Vivado doesn’t find (bus width mis-match, for example). So I still love Verilator.

My point is that, as of today, it doesn’t find everything. Things that work in Verilator will usually work in your hardware, but not always.

But … that’s one of the purposes of a logic scope, right? Such a scope will help you debug what’s going on within your design when the simulation and the hardware don’t act the same.