As I’ve been watching students and others request help on the Digilent Forums, it has become apparent to me that there’s quite a difference between the design process college students are using and the one reality has driven me to.

Perhaps pointing this out will serve as a warning to the young FPGA engineer to start their task early, and to not underestimate the amount of work required.

The Student’s FPGA Design Process

Most of the student’s I’ve seen on the forum show up about a week before their project is due. They want to get things done quickly, and they want to take the fastest path they can take to get to the goal. Indeed, they are following the design process shown in Fig. 1.

Figure 1: The Student
Student FPGA Design Process Figure
  1. The student builds his design in Verilog
  2. He then implements it on an FPGA, adjusting his design as necessary to meet timing and build requirements
  3. The design is then placed onto the FPGA for a test, and …
  4. The student can’t figure out why it isn’t working.

Perhaps these students are coming from the software world. When I program software, I can usually debug a program using the “debug by printf” method. If things get difficult, moving to the debugger is easy. Either way, at any point in my program, I can look at and examine any variable at any time and understand what is going on within it.

If you expect to do this with hardware, and particularly with FPGA’s, you are going to end up with the other students in your class at the end of the semester wondering what happened. You just don’t get that much visibility into an FPGA design.

Plan for it.

The Expert’s Design Process

Now, if you instead turn around and ask an expert about their design process, they will discuss something like Fig. 2 with you.

Figure 2: The Expert
The Expert's FPGA Design Process Figure

  1. If you don’t have an instructor, you have to find the specifications for whatever chip you are going to work with. This applies to both the FPGA’s you work with, as well as any peripherals.

  2. Once you think you understand how the device you wish to interface with works, you’ll build your design to interface with that device.

    I make a particular point at this stage in my design process to document, at the top of any Verilog files I build, how that Verilog file is going to connect to the rest of any design. While all of my files tend to use the Wishbone Bus, I still need to define the various registers on that bus, as well as what each of the bits within those registers means, whether the registers are read/write, etc.

    As I build my design, these become my notes and reference. I keep them up to date–especially before any spec sheet is ever written.

  3. The next step is to build a simulator for the device. This will allow your simulated logic to think it is talking to the actual device.

    Have I skipped this step before? Absolutely! What was the result? I’ve almost always had to come back, retrace my steps, and build this simulator. (I’m currently needing to do that with an HDMI interface I’m building.)

  4. Once you have your logic, and a simulator in place, you can now build a test bench that will exercise your logic against the simulator and see whether or not your logic works.

    Have I skipped this step before? You bet! The result? I just got burned this last week.

    The story has to do with a flash controller I had built. I was recently trying to squeeze every last LUT out of my S6SoC design, and made changes to it. I then changed it in another design, and again, and eventually I had four different flash controllers and couldn’t tell which worked and which didn’t. I needed a test bench to prove that my changes still left me with a working controller.

    I had no choice, but to backtrack and build the test bench I should’ve built in the first place.

  5. Only after things work on the test bench, will the expert place them onto the FPGA. Changes made in this process (usually because something just doesn’t quite meet timing) will still be validated through the simulator and the test bench.

  6. Then the expert applies his design for its first Hardware in the Loop (HITL) test. If the hardware he’s working with doesn’t match his simulation, he goes back and adjusts the simulation, his design, and the test bench.

    If I can, I like to use the same software for bench testing as I do for hardware in the loop testing. While this is not always possible, it can be used to save a step … if you can. That’s actually the reason why I like to use a TCP/IP connection to connect to my boards–because you can never tell, then, whether you are connecting to the real thing or a simulation.

  7. Only after any design passes unit testing, is it fully integrated with the rest of whatever the expert wishes to do.

  8. Finally, the entire unit is tested as a whole.

The expert will also firmly scold the student for not following this form exactly. Sorry, students, it always happens.

The Actual Design Process

The problem with this description of the expert’s design process is that the expert isn’t telling the whole story.

Figure 3: Reality
What the Expert actually does

Because this isn’t his first design, he has already built up a small library of routines–most of them surrounding how to communicate with an FPGA and how to get diagnostics from the FPGA. Indeed, his design flow is perhaps more appropriately characterized by Fig 3.

The result is that the expert can draw values and hence insights from the logic running within the FPGA, while the student is still stuck wondering what happened.

In my case, this scaffolding consists of both my open source Wishbone Scope that works with GTK Wave, and 2) my open source UART to wishbone converter which gives you access to that Wishbone Bus, to include the wishbone scope that I place on that bus. Of course, when I first started I didn’t have GTK Wave support–but that just illustrates how an expert’s toolset can grow to become more useful over time.

What the Student should have done

What the student should have done was to take some time, between the simple blinky and UART projects but before the more complex projects, to build some scaffolding. Specifically, he needs to build a means of evaluating logic from within the FPGA, and of learning how to discover whether or not the device he’s working with responds the way he thinks it should or not.

The typical curricula doesn’t lead the student to this approach. Instead, the typical curricula works from blinky to more and more complex projects, but never focuses on how to build scaffolding out of these projects that is necessary to be truly competent at the more complex tasks.

The problem with this approach is that 1) few students know that this is a requirement on their road to success, and 2) few students allocate time for failure along the way.

This is why student’s stumble on their complex FPGA design projects.

If this has been your experience, please write to me. I’d love to share any lessons you’ve learned from your design projects here on this blog.