Enginursday: A New Approach to FPGAs!

Embedded Micro's new IDE and the Lucid language.

Favorited Favorite 1

For me, Field Programmable Gate Arrays (FPGAs) have been the penultimate frontier of electrical engineering design (the ultimate would be fabricating our own chips, but once again, that’s a topic for a different blog post). In discussing FPGAs with some of my SparkFun colleagues, we agree that they’re hard to casually tinker with. You don’t just “play around” with them. FPGAs are programmed in their own languages (usually Verilog or VHDL), using techniques based on synchronous hardware, and developed using software that’s extremely sophisticated. Getting into them usually involves a very steep learning curve.

I’ve been on teams that built FPGA based designs a couple of times before, but it’s not a world I’ve comfortably settled into – I get pulled back into regular software design before I’m really up to speed. The FPGA design suites are big, full of menus, pages, tabs and modes, all described in unfamiliar terminology, which takes time to get to know. A lot of my experience was clicking on the wrong option, then having to figure out how to backtrack.

Justin Rajewski, the Founder and CEO of Embedded Micro, came to us earlier this year with an announcement: they were introducing a new language to ease the transition into FPGA development. I was curious to take a closer look – could they lower the learning curve, and perhaps make it possible for a beginner to casually experiment with an FPGA?

Prologue

Embedded Micro successfully Kickstarted the Mojo development board in 2013, and it’s been revised a couple of times since then.

Mojo v3 FPGA Development Board

DEV-11953
74.95
10

The board is currently on version 3, which has:

  • a Xilinx Spartan6 FPGA.
  • 8 user-configurable LEDs
  • 84 I/O Pins.
  • An Atmel AVR 32u4 microcontroller.
  • A flash memory chip to store the FPGA configuration data.

The XC6SLX9 FPGA is the heart of the board, and it has a bunch of goodies under the hood:

  • 9,152 logic blocks.
  • 16 DSP slices.
  • 576 kilobits of RAM.
  • 102 I/O pins.

Developing code for an FPGA is actually describing how the above pieces are configured and interconnected. This could range from a set of simple binary logic operations to a very sophisticated plan for a mathematical algorithm or communication interface. If you want to take a deeper look at the FPGA itself, here is the family datasheet.

In addition to the Mojo hardware, Embedded Micro wrote a series of tutorials that guide the beginner through using the Xilinx tools to develop Verilog code. But, as mentioned above, these tools are cumbersome, and daunting for the beginner.

Enter Lucid

To ease the transition onto the FPGA world, Embedded Micro has now introduced an IDE for the Mojo, and a new FPGA programming language called Lucid.

Mojo IDE Screenshot

The Mojo IDE

The IDE is greatly streamlined in comparison the the Xilinx tools. It’s a single window, with a multi-tab editor, and relatively few buttons and menus. One button builds the code, another loads it on to the board. Since it only supports the Mojo board, a lot of the options present in the Xilinx tools simply aren’t applicable.

Behind the scenes, the Mojo IDE still requires the installation of Xilinx WebpackISE, which is a huge download, and requires navigating a license manager. However, once it’s installed, you don’t need to open it. The Mojo IDE invokes the command line tools in the background (much the same way that the Arduino IDE invokes the GCC compiler).

Lucid itself uses syntax that’s a hybrid of Verilog and C++/Java, with curly braces to denote blocks of code, which will be familiar if you’ve used C++ or Java (as seen in Arduino or Processing). It also includes some higher-level conceptual blocks, such as flip-flips and state machines, which are very useful for FPGA design. Here’s a snippet of Lucid that implements a configurable binary counter.

module counter #(
    SIZE = 8 : SIZE > 0, // Width of the output
    DIV = 0  : DIV >= 0, // number of bits to use as divisor
    TOP = 0  : TOP >= 0, // max value, 0 = none

    // direction to count, use "up" or "down"
    DIRECTION = "up" : DIRECTION == "up" || DIRECTION == "down"  
)(
    input clk,
    input rst,
    output value[SIZE]
) {
    .clk(clk), .rst(rst) {
    dff ctr[SIZE+DIV];
}

const MAX_VALUE = c{TOP, DIVx{1}}; // value when maxed out

always {
    value = ctr.q[SIZE+DIV-1-:SIZE]; // set the output

    if (DIRECTION == "up") { // when this is an up counter
        ctr.d = ctr.q + 1; // increase
        if (TOP != 0 && ctr.q == MAX_VALUE) { // reached the top?
            ctr.d = 0; // reset
        }
    } else { // down counter
        ctr.d = ctr.q - 1; // decrease
        if (TOP != 0 && ctr.q == 0) { // reached the bottom?
            ctr.d = MAX_VALUE; // reset to top
            }
        }
    }
}

The IDE also lets you intermix Lucid and Verilog source files, which can be useful if you’ve already got a Verilog module that you want to include. When you press the “Build Project” button, the IDE translates the Lucid files into Verilog, then passes them to the Xilinx Verilog tools. Those intermediate Verilog files are also saved in the build tree, in case you want to export them to use in a Verilog workflow.

In Use

I’ve been playing with Lucid on the Mojo for about 10 days now. It’s been a slow process, but more productive than 10 days with a traditional FPGA design suite. I’m finding that with fewer menus, options and buttons, I’m a lot less likely to take a wrong turn and wind up in some mode I wasn’t expecting. This has allowed me to focus on troubleshooting my code, rather than the development environment.

I was hoping to have some sort of ambitious project to share for this blog post, but it’s not coming together as quickly as I was hoping. My divisibility by 3 checking hardware isn’t fully functional, and I’m still a ways from building an I2S port from scratch.

Working with the tools, I’ve also found a couple of little issues with the language and IDE. In each instance, Embedded Micro have been quick to respond. They guided me toward better Lucid practices, and updated the IDE with missing features.

Epilogue: Future Developments

Lucid is very new – it was released on April 13th! It’s still in its infancy, and has room to grow. As such, I asked Embedded Micro for a peek at their roadmap. There are some things we can expect to see:

  1. More Lucid tutorials, eventually augmenting the older Verilog tutorials.
  2. Several new hardware shields.
  3. Some extensions to the IDE, adding timing simulation, and interactive debug features. You’ll be able to configure part of the FPGA as timing debugger or logic analyzer.

A New Path Into FPGA Development

If you’re looking to jump from Arduino into FPGA programming, the Mojo has an extra advantage. The 32U4 microcontroller (the same chip as is found on the the Pro Micro) is Arduino-compatible. You can use the Arduino IDE to program the microcontroller, and add your own code that can interact with the FPGA.

Embedded Micro have released the source code for the loader firmware. It exposes some hooks to run additional user code, which are described in their Arduino IDE Tutorial.

My Final Thoughts

Knowing what I know now, if I had to start fresh, I’d probably take a different path through the materials Embedded Micro provides.

  1. I’d start by printing out the Lucid Language Reference. It’s got syntax examples that demonstrate the basic features of the language.
  2. With the guide in hand, I’d work through the basic tutorials. Their current tutorials are for combinatorial logic and synchronous logic.
  3. Before forging ahead on my own, I’d carefully study all of the pieces listed in the ‘project->add components’ menu. These are actually modules written in Lucid, some of which implement non-trivial hardware like multi-channel PWM, or UART serial ports. It turns out that several of these were items that I’d been reinventing on my own.

I’ve also spent enough time playing with Lucid to develop some debugging strategies. If you get stuck, try the following:

  • Check the build output in the lower pane of the IDE. In one instance, I was able to find an error I’d made assigning signals to pins in the constraints file…which directly leads us to the next item:
  • Route internal signals to pins, and observe them with an oscilloscope or logic analyzer. Sometimes, you need to open your own windows into the chip. This might be the equivalent of peppering an Arduino sketch with Serial.print() calls.
  • When things are misbehaving, consider a different approach. Sometimes my initial instinct for implementation isn’t right, and things can be done differently.
  • If you really need help with a Lucid project, reach out to Embedded Micro. They’ve been very helpful, and are eager to see people using the language.


Comments 23 comments

  • A great writeup, but you are missing one thing: SparkFun actually sells the Mojo! You can find it here!

    • Uh, yeah…I’m an engineer, not a salesman.

      Article has been amended with the link - just click on the Mojo photo!

  • “Flip-flips”? I don’t care if it’s a typo - THAT’s what I’m calling them from now on!

    • Just be sure to match them in conjugate pairs with flop-flops.

      I’m pretty sure I’ve seen some old Japanese schematics (possibly Tascam or Roland) that indicated “frip-frops.”

    • I sometimes call them by their given name- Bistable Multivibrator….. Especially when I’m mad at them…

  • Hmm… back in the early 90’s, Popular Electronics published a PEEL (Programmable Electrically Erasable Logic device) programmer. I bought the kit, and built it up. I’d just taken a class in C++ at work (we were starting to transition from C to C++), and as a “toy” program in that class we’d built a simple traffic light controller program – maybe 60 lines of code. I decided to “simulate” this program in hardware, and programmed up a PEEL to control 6 LEDs, and used a 555 timer to generate a clock signal. It was really pretty silly, but it really felt like a major accomplishment when I got it to work! (BTW, the software for the programmer ran under MS-DOS.)

    Too bad I have so many projects already, and don’t have the time to tinker with the Mojo!

  • Most common languages like C/C++, Verilog, VHDL are broadly supported standards you can use anywhere. How does Lucid work, does the Mojo IDE translate it to Verilog, then send it to the Xilinx tool? If I spend some time to learn Lucid, is it going to be a portable skill, or does this only work with one FPGA dev board from one vendor?

  • love your write up. Have been looking at FPGAs for years, but never went there for the reasons you mention. Sorry to be a stickler here, but: https://www.google.com/search?q=penultimate&ie=utf-8&oe=utf-8

    • I’m afraid I don’t see how I misused the word. I meant “one from the last,” so that’s what I said.

  • My first experience with programmable logic was using GAL(PAL) chips. I was amazed at how many logic chips would simply “go away” when you plop one of those on the board. Never really got into FPGAs though. It always seemed to be cost prohibitive in the past. It was just simpler for most projects to grab a micro and just bit bang it to life.

    I think that may be the barrier to entry for FPGAs. Practically all other programmable logic technology has gotten extremely inexpensive for the hobbyist. This has translated to those hobbyists using micros instead of FPGAs in their professional career. Yes, there are times a micro is just not fast enough. However, that is pretty rare.

    Embedded Micro’s approach to the IDE is a good one on the learning curve side. However, when an FPGA is still almost $50 to $100 to get a decent one compared to a $5 micro then the micro is going to win for most projects. Hopefully making them more accessible will spur more development and drive the unit costs down. There are a few projects I would love to experiment with, but never could justify the time and money to “play” with FPGAs.

  • When designing onto FPGAs, I’ve found that treating your implementations as ‘state-machines’ helps you figure out how to set everything up (design onto paper, splitting into a data-path and control unit, identify all states and transition conditions, determine how many registers and operations are needed etc.)

    The following link is a sample video of VHDL tutorials. https://www.youtube.com/watch?v=7N9mygI3A5o

    There are quite a few series of FPGA tutorials on youtube that explain things good. I remember one I used to use which was very helpful but cannot remember the name…so I’ll edit this post later once I find it.

    Going from any form of software design to designing for FPGA has a learning curve, but I think if you put the time into it you will begin to understand why VHDL and Verilog are the way they are. But hey, if all you want is the performance benefits and have a tool do it for you, some day it will exist. Each FPGA company has some version of ‘high level synthesis’ which converts C into verilog/vhdl. Xilinx even has tools for converting Simulink models into verilog (using their blocksets of course).

  • I did a few projects / write ups / tutorials using a Xilinx Spartan 6 to drive the Sparkfun 32x32 RGB LED panels:

    http://bikerglen.com/blog/driving-a-32x32-rgb-led-matrix-with-a-beaglebone-black-and-an-fpga/

    http://bikerglen.com/blog/expanding-the-beaglebone-black-and-fpga-to-drive-6-or-more-panels/

    Edit: meant this as a reply to BadGUI below (above?). Grrr.

  • I suppose one of the turn offs for me,in working with FPGAs has been the lack of projects based around them.

    If you google microcontroller based projects, you can find 1000s of projects. Whereas if you did the same with FPGA projects you would be hard pressed to find a handful.

    At university we only really recieved an introduction to them. It involved designing a traffic light state machine, which is fine as an introduction, but it doesn’t really impress anyone.

    Does anyone know of any impressive FPGA projects?

    • www.fpgas4fun.com

    • You could build one heck of a driver for the WS2812 addressable LEDs.

    • One example that’s inspired me: Scott Gravenhorst has been making FPGA-based audio synthesizers, which seem to get updated every time Xilinx release a new dev board:

      http://scott.joviansynth.com/FPGA_synth/

    • Check out the ones by Carnegie Mellon students; they have an FPGA course where they have to build something useful as a final project. Hackaday often has posts about them around this time of year (which is when they’re done) and has had a few posts on them recently. There are some on Hackaday.io as well.

    • There are a few out there. Check out the ZPUino, which is a 32-bit Arduino-compatible core that runs on the Papilio board (among others).

  • I am excited to see this. In regards to exporting the files to the Xilinx toolchain, I recommend for everyone to use PlanAhead and not ISE for this. The GUI is more intuitive and easier to work with. (I also wrote a quick tutorial on it which is hosted by SFE).

    Everyone should learn the basics of FPGAs to TRULY understand what they’re capable of. Thanks for the write-up Byron!

Related Posts

Recent Posts

Tags


All Tags