I’ve been watching the Digilent Forum’s, and I’ve now seen some very common requests for FPGA help that keep coming back over and over again. I’ll separate these into three groups, and share them here with you. They are actual hardware problems, beginner problems, and Vivado problems.

  • Actual Hardware Problems

    • Device not found. [1] [2] [3] [4] [5] [6] [7]

      User’s seem to have a problem getting their tools set up properly. I certainly did. One particular problem is basically, “I just plugged in my device and my computer doesn’t recognize it.” This is commonly caused by an invalid or incomplete tool-suite setup. However, it can be caused by a bad USB cable. So, usually, if the device was working, it tends to be instead a bad USB cable. Strangely enough, bad USB cables a rather common occurrence on the forums.

      The solution: It depends on the problem

    • Changing the I/O voltage standard [1] [2] [3] [4] [5]

      This question usually starts out when someone notes that you have to specify the I/O standard for each pin within the constraints file, whether UCF or XDC. A reasonable conclusion might be that this standard can be simply changed on a pin for pin basis.

      When the Xilinx tool tells them there’s an error in their code, they write in to Digilent asking how to fix it.

      What they often don’t realize is that all of the pins on a given I/O bank have their voltage standards set in hardware–not by the constraints file. In particular, each I/O bank needs to be passed a “power” wire, at the high voltage level for the bank, which will then be used by the FPGA to connect any of the pins on that bank to “high”. Hence, to change from one standard to another, you need to change this input voltage pin and in doing so you will adjust the voltage of everything on the bank.

      If you know what you are doing, it is possible to rewire a board to change an already wired pin on that board. I say possible. I’ve never done it, but I’ve seen things like this done by those who are greater than I. My answer, therefore, would be that it’s possible, but not recommended. Further, it’s not a “feature” that Digilent supports, and it is likely to void any warrantee you might have on your board.

      If you are dealing with an input wire, and an input wire only, it is also

      The solution: It really requires either a level shifting peripheral, such as the PMod level shifter to swap voltage standards, or a new board design. The good news is that neither of these approaches will void your warrantee.

    • There’s the FTDI request. [1] [2] [3]

      Many individuals have tried, either by accident or on purpose, reflashing the FTDI interface chip on their board and, as a result, have broken their board so badly that it no longer responds to configuration commands. The solution to this problem is that the Digilent staff will send this user a private message with the correct software to reload onto their device.

      The strange part of this request is that [I am aware of one user who has successfully reprogrammed the FT2232 chip on his board, and achieved much higher data throughput as a result.

      The solution: The Digilent staff provides a private message containing instructions and/or data to fix this problem.

      See here for an example. The D2XX drivers are necessary.

  • Beginner problems

    • I need to build (some instructor’s problem statement). Please help me. [1] [2] [3] [4]

      This request gets the least help from members on the forum. The response is usually a kind pointer to where the user documentation is at and nothing more.

      The solution: The student needs to do his own homework.

    • Help me, my design doesn’t work. [1] [2] [3] [4] [5] [6] [7] [8]

      I’ll come back to this in a moment, but many students think that an experienced engineer can just deskcheck their work and find the bug. While I enjoy the challenge, and while I can often do this, it certainly wasn’t how I became an experienced engineer when working with FPGAs. I got there through simulation to make sure my logic worked, and using a scope (or scopes) to make sure my simulation matched the device.

      The solution: The solution is to simulate the design together with a simulated peripheral. This is often how I find bugs in students serial port designs, for example. I’ll connect their design to a serial port simulator, create a .vcd file for viewing in gtkwave, and write back about what I found. There’s no reason why the student couldn’t have done this.

      Perhaps I’ll post these results for the next student I help?

    • Asynchronous Reset [1] [2]

      While Xilinx devices support an asynchronous reset to the logic, it’s so unreliable that they recommend users not use it. This is usually a student’s first project on an actual FPGA, and a beginner’s mistake.

      The solution: Get rid of the negedge reset from any always block dependencies. Replace these with a combination of initial statements and (if necessary) synchronous resets.

    • The logic Clock [1] [2]

      Many new FPGA users aren’t quite aware the clocks are special things. They then create logic wires internal to their design which they wish to use to divide this clock rate. While not a problem, such logic wires don’t have the reliability of a clock, and transitioning on their edges doesn’t produce the result you will want. Where the problem comes into play is when the student wants their logic to transition on the positive (or worse negative) edge of this clock.

      The solution: a logic strobe.

      This solution finds a lot of application in 1. beginning FPGA student designs, and then again in 2. signal processing designs, where the device’s clock speed is not synchronized to the FPGA’s clock, and hence the data comes in from the sensor at a slower speed than the devices clock speed.

    • The student who hasn’t simulated their design [1] [2]

      In this case, someone new to FPGA design has created some design and it doesn’t work. They don’t know why. This one is similar to the Vivado library component problem: they have no idea what’s going on internal to the FPGA to answer the “why won’t my program work” question.

      The solution they want to this problem is not the industry solution. What these students want is for some kind soul on the forum to look at their code and tell them what they are doing wrong.

      The industry solution to this problem is to simulate the code and any peripherals it might be working with, and then as part of that to verify that the logic works as intended.

    • They don’t know how to simulate their problem [1]

      Sometimes the user is trying to work with a piece of hardware they’ve never worked with before. As a result, they have no simulation for this hardware because they just aren’t all that familiar with how it works. (A user button is a good example of this, since bouncing isn’t something most people place into simulators.) In this case, their design doesn’t work on the real hardware and, again, they don’t know why.

      The solution to this problem is twofold. First, build a simulator that encapsulates your understaning of the hardware from the diagrams and specifications you have. Second, when that first part fails, use some form of a scope to measure what is actually going on across the wires to/from the hardware.

    • Crossing clock domains [1]

      Few students have ever heard of metastability problems. As a result, they write code that crosses clock domains realizing that there might be a problem associated with doing so.

      The solution: The simple solution is to clock every input at the new clock twice before using it. This works for some things, though not all. A more complete discussion of how to deal with crossing from one clock can be found in this article.

  • Vivado problems

    • The demo doesn’t build [1] [2] [3] [4]

      Typically this is caused by the user trying to build the demo design using one version of Vivado, while the demo was instead built with another version of Vivado.

      The solution: The Digilent staff share what version of Vivado was used to build the demo. Sometimes the demo has gotten old, and the Digilent staff need to update it.

    • They’ve integrated some component from the Vivado library into their design and “it’s not working” [1] [2]

      Of all the times I’ve seen this problem, it has yet to be that the Xilinx provided IP component doesn’t work. It’s more often that the user isn’t feeding the component properly, or using the results from the component properly. Making the problem worse, rarely has the user taken the time to instrument what is going on, so they have no clue where their problem lies.

      The solution: a good internal scope, such as the wishbone scope or the AXI-Lite scope

    • The user can’t figure out how to add custom IP to the Vivado flow [1] [2]

      The solution: Well, I might be biased here, but … my solution to this problem has been not to use the broken Vivado design flow. I’m sure I’ll discuss more of my problems with there processing flow as time goes on.

      One of the pleasant things about the Digilent forums is that these common requests are dealt with in a friendly manner–even though I’m certain someone must be rolling their eyes at seeing the same request again.

I think I’ll come back to this over time, adding references to this this post of Digilent Forum posts that illustrate my points here.