Skip navigation
1 2 3 4 Previous Next

FPGA Group

52 posts

I have been chosen as a roadtester for DEO-NANO P0082 and my kit has arrived. I decided before going roadtest project, it will be nice to give a heartbeat and step into FPGA world. Before you go reading, I want to say I am not an FPGA expert but I want to be one   I just had a course during my master. If you confused something or think something is wrong, please do not hesitate to leave a comment.


Let's start with what is FPGA? To be honest it is a hard question and I will answer in some extent. FPGA stands for Field Programmable Gate Arrays so the name suggests we can program(configure) FPGA after the fabrication. FPGA is not a microcontroller or microprocessor but you can design a microprocessor on FPGA. Basically, it is a reconfigurable device and you can design any digital circuit on FPGA with its hardware limitations.


Let's see how we program an FPGA? Well, when I say programming FPGA, we don't write a software program. We do design a hardware with hardware description languages(HDL). The most two popular languages are Verilog HDL and VHDL (V stands for very high speed integrated circuit). I don't go into which one is better than other because I don't know the answer. I can say it is not easy to program an FPGA as microcontrollers. It is more complicated and harder but this doesn't mean we shouldn't play with it.


Why do we use FPGA we have such a great microcontrollers with affordable prices? Microcontrollers are manufactured for general usage but FPGA is a custom designed.


- Microcontroller is manufactured for general usage but FPGA is a custom designed.

- Microcontroller works instruction by instruction but FPGA works concurrently so it is nature is parallel


I think these two are the main reasons which led other advantages like speed and flexibility. Hence, FPGA is concurrent as nature it will be faster than a microcontroller if designed properly. There for it is used highly in the military, telecommunication, and R&D. My project will be implementing AES on FPGA and see the advantages. I didn't use AES before. I know it can be hard and time is limited. If I can't complete on time, I will represent another project which is different types of multiplier circuits. It is a multiplier, how many types can be? Well, there are different types. Some are optimised for speed some are space. If I have time, I will implement both.


I think I mixed up many things Let's unbox the DEO-NANO P0082.


This is the box of the kit arrived in Element14 cardboard with shiny bags which are at the background. I really like the bags. They are so shiny


It includes DEO-NANO FPGA board, an extendable mini USB cable, and some brochures

. IMG_20170730_131941.jpg

This image can give an idea about the size of the board. It is a little smaller than a credit card.

This is the power-on test. Just unbagging the DE0 nano and plug it to PC, you will see the LEDs are flashing.


Initial thoughts:


The kit looks handy.


The quick start guide says there are two CDs inbox but I think they are not sending CDs anymore but not updated the quick start guide. Actually, I don't want CDs but if it says, they should be inbox.

  If your looking to get into FPGA development and have been following my blogs, this is probably the post that you should pay most attention to as it's likely to make clear the design process.


So far I've followed the quick start guide,  downloaded the recommended software and installed the demo bitstreams onto the deo-nano development board. For clarification, a bitstream (or bit stream) is the name of your compiled project that gets transferred onto the FPGA device.


Now it's time to follow the my-first-fpga guide to create my first ever FPGA project, its a foolproof step by step guide which takes us from the very beginning of making a project through to downloading that compiled project onto the deo-nano development board.


Forget any other software that comes with the board, all were interested in is the Altera Quartus2 design suite, this has everything we need including a compiler and hardware programmer. This one thing does it all.


Here's a quick run through of the steps used to develop an FPGA application:


1) Create a project with the wizard, giving it a name and telling it which FPGA you are using.

2) Add a Block Diagram/Schematic to the project (this is similar to a schematic editor on PCB design software where components can be added, moved and connected with wires)

3) The objects on the schematic are created by using a programming language called Verilog HDL, it has similarities to other programming languages.

4) Once an object has been created in Verilog HDL, it shows up as a symbol on the schematic. Wires can be connected between these objects using inputs and outputs described in the programming.

5) Symbols of input / output pins are created on the schematic to represent the physical pins to allow interaction with the real world. These can be connected to the inputs/outputs of our object.

6) The input/output pin symbols are given names, a pin planner allows us to point those names to the physical pins on the fpga.

7) Compile the project.

8) program the bitstream (the output of the compiler) onto the fpga


Ok, there are a couple of other bits but thats a general overview and hopefully it outlines the process that people new to FPGA's can understand. Its basically very similar to making a circuit diagram in a pcb design package. Where the components have internal functions defined by a programming language. Anybody who used Javabeans and played with the Beanbox will be very comfortable using this!


So lets first look at the Block Diagram/Schematic view







This is the completed schematic for my project, The object in the top right labelled "simple_counter" is an object that I made in Verilog HDL following an example whereas the other two main objects are pre-made objects that Altera provides (A wizard can help set them up and tailor them for your needs).


Coming out of the right hand side of "simple_counter" is a wire labelled "counter", Because the wires going into the left of the "counter_bus_mux" are also labelled "counter" these are all symbollically linked so its as if all of those wires are connected to each other.


The smaller objects labelled "CLOCK_50", "KEY[0]" and "LED[3..0]" are all symbollic of physical pins on the fpga, these get assign or mapped to real life pins later in the process.













Here's the Verilog HDL code that went into making the "simple_counter" object in the schematic above, as you can see it has an input and a output described, you can see these displayed in the schematic above. Notice how the structure is similar to other programming languages and it's pretty easy to follow.


Once this object has been saved we can add it to the schematic and link other objects to it, the design suite draws the object for us, we don't need to do anything like that ourselves.















Once our schematic is complete, its time to launch the Pin Planner. If you look at the table at the bottom of the Pin Planner under node names, we can see the names of the input/output pins in our schematic above. In the location box is where we assign the pin in the schematic to the desired pin on the physical FPGA. In this picture, I double clicked the location box for "CLOCK_50" and a drop down list of all of the pins on our fpga device appeared. I selected PIN_R8 which is a dedicated clock pin, so looking back at the schematic we can see that CLOCK_50 is going to be turned on and off by a clock source on the fpga.

























Heres the completed pin assignment. This can be opened up at anytime during the design process to assign new input/output pins.













Once this is done your project is finished and its simply a case of clicking the compile button, plugging the de0-nano into a USB port and copying the compiled bitstream program onto the fpga using the programmer in the design suite. I have included any pictures for the process as it really is simple and self explanatory. There are pictures and a step by step guide in the my-first-fpga document but I have included a picture of the compiler report that was generated:










As you can see, very few of the fpga's resources were used to make this project.










I'm going to try and explain the schematic (and hopefully get it right).

1) An external clock source is fed into a PLL(phase locked loop) element. This takes a 50mhz clock which is pulsing this pin on/off and slows it down. The output of this PLL goes into the simple counter, the single output of this counter is symbolic of a 32bit bus. The counter element itself increments the 32bit bus like it would a 32bit variable. From that 32-bit bus, just 8 of those bits are fed into the "counter_bus_mux". Im not sure exactly how that part works but it takes the data from those 8-bits and converts it into 4bits then displays it onto 4 led's.


Hopefully I got that right, if not then please feel free to explain better in the comments below!!


Heres a quick video of the results of this project:



And that's it for today! Tomorrow Im going to go Lone Ranger and try to get this binary counter displaying on all 8 LED's rather than just 4 before I get bogged down reading the full user manual.


Oh! Maybe I should mention that I completed this project in under an hour, there appears to be a lot to it but realistically it was easier than I anticipated!!

This post covers my experiences working through the quick start guide and moving on from there.


Installing The Software


All of the required software can be downloaded from I was required to register at to download their software. Downloading the terasic cd and other bits from there was as simple as downloading a regular file. There are links from there to the Altera website where I found the Quartus2 design suite. Of course I had to register with Altera too to download this software.


At the Altera website, there are 3 different packages you can choose from. There's a lite edition which includes support for the cyclone4 that we will be using, theres a web edition which I chose to download for the time being and there's a premium edition which includes a larger range of fpga's and requires people to purchase a license to use. The first 2 options don't require any such license.


The Altera software is available for Windows or Linux, usually I would use a Linux version when there's a choice but the Terasic software has some Windows .exe files only so since I'm learning a new technology I decided to make things easier on myself and boot up my trusty old copy of Windows XP, maybe once I'm more familiar with the device I'll move over to Linux with it.


The final part of installing the software was to install the USB Blaster Driver. This is the device driver that your PC uses to talk to the FPGA board, unfortunately the quick start guide doesn't run through how to do this. After some investigating I found that the driver is included in the Quartus2 software that was downloaded and there are instruction for how to install it here in particular its the "USB-Blaster Cable" links you want to follow.


(later on I also found instructions for installing the device driver in the "my first fpga" document)


Using The Demonstrations


The demonstrations that come with the Terasic cd are easy to install onto the board (once you have the driver installed!). Simply locate the relevant .bat file while the development board is connected to your pc and it flashes automatically, so all of this seems simple enough and were at the end of the quick start guide. I'll need to look further into the documentation to find out how to make such a mysterious .bat file!


The final part of that guides suggests reading the user manual on the cd to learn more, while looking for that I noticed another file in the same directory called "DE0-Nano_My_First_Fpga_v1.0.pdf" and so decided to take a look at that first. I'm sure glad I did!!


Moving On From The Quick Start Guide












Page 1 of this guide really seems to put me at ease, it just explains the process of FPGA design in a simple to understand way. I suppose part of the difficulty of getting into a technology like FPGA's is the fear of the unknown and the assumption that it's going to be really complicated. To have the process explained in such a simplistic and clear way has taken away a lot of my apprehension.


























Page 7 describes what the rest of this guide is all about, its basically a complete step by step guide to making a project with the Quartus2 design suite, it teaches you how to create a counter which displays on the LED's of the development board. Once the project is finished it guides us through the whole compilation process and then shows us how to get this compiled project onto the FPGA development board itself so we can see it in action.












Thats as far as Ive got today, it's time to kill some aliens on XCOM2!!


Positive Comments


So far my experience with this development kit has been greatly enhanced by the documentation which is easy to follow and is filling me with confidence that I will be up and running with FPGA development faster than I originally thought.


Negative Comments


The only negative thing I could say is that there should be more explanation on where from and how to install the device driver in the getting started guide, its impossible to flash the demonstrations onto the development board without it.




The My-First-fpga guide seems to be the valuable document needed towards learning the foundations of how to develop for this board and is a great asset to Terasic. It would be a great advantage if this guide was included in a printed format with the development kit, if using a single monitor it's soon going to get frustrating switching screens to follow the guide. I also believe such a thing would make a useful quick reference manual for people to keep handy.


For now though it's lucky Ive got a tablet to work from!!



Recently I was selected to roadtest the terasIC DEO-NANO P0082 fpga development kit. My application was based around reviewing the P0082 for suitability as an entry level device to simplify the process of people wanting to explore fpga development for the first time.


As part of that roadtest application I offered to post regular blogs here in the fgpa group on element14 documenting my progress, this first post centered around the unboxing and first impressions.

















The Box Contains:

            - P0082 development board

            - Mini USB cable

            - Quick start guide

            - Brochures for other products


I always like getting brochures for other products!!
















Quick start guide


Page 1 has a picture of the P0082 development board with labels to highlight the specific components.

Page 2 contains a brief introduction and a list of relevant software you will need to install to develope with the P0082.

Page 3 is an overview of the pre-loaded demonstration and links of where to download further demonstrations.

Page 4 looks at a control panel demonstration and a system builder tool to enable quick development on the P0082 (I'd imagine a project setup wizard).




The P0082 development board looks well made, comes with a clear acrylic protective top cover and has standoffs to raise the bottom of the board from the surface its stood on which is a nice touch. The main component of the board is an Altera Cyclone 4. From what I understand at the moment, the Altera fpga loses all of it's configuration when power is removed and re-configures itself using an external EEPROM. To the left hand side of the board there is an I2C EEPROM so I'm assuming that this is where your compiled program (is that what you call it?) is downloaded from your computer onto ready for the fpga to read upon next power up.


Positive Comments


The development kit looks reasonably well presented, the quickstart guide is easy to follow and gives me confidence that the product is a worthy contender as an introductory device to the world of fpga's


Negative comments


One of the pins for the external power header is slightly bent, this coupled with the box looking rather worn and the software cd's that are supposed to be included are missing leads me to think this is a pre-used kit. Keep in mind though that this product was sent as a roadtest product and not one that has been purchased as new. Luckily the software packages can be downloaded easily enough so the missing cd's aren't a huge problem. Fingers crossed the board does function, I'll find out in due time!!

(edit) *after a quick power-up test, the P0082 is working fine and preloaded with the flashing led demo.





* Pictures taken with my new general purpose camera Canon EOS 750D

This post is a preparation for my attempt to generate VGA with a XuLA2 FPGA board.

I'm generating an image file that I can upload to the board's SDRAM.

The FPGA will read it from the RAM and convert it into a VGA image.


The example project for the VGA plug-in for the XuLA has an example image.

The latest loader tool for the board (xsload 0.1.31) doesn't support the format of that file.

There's an older version of the loader that supports it but doesn't want to run on my pc.

Not to worry. In this post I convert the image to a supported load format: Intel HEX.


The XuLA FPGA VGA project and the image file are available on the Xess github:



Preparation - Generate Binary Image


The example image is in a proprietary format. Below are a few lines as exampe


+ 10 00000000 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C
+ 10 00000010 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C
+ 10 00000020 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C 7F 2C


10 stands for 0x10 data elements (16 bytes), the second field is the address in ram it has to go, then there's the 16 bytes payload that represent a few pixels of the image.


The easiest path from that file to the somewhat elaborate Intel HEX format is to convert this into a binary file that only contains the pixel data.

There are existing utilities that can convert bin to Intel HEX.


I made a small c++ utility to grab those pixel bytes from that example and write it to a binary file.

The fixed filenames, not using a data buffer and the way I did the ascii-hex to number conversion show that I'm in a holiday mood.


// Name        : xess_file_converter.cpp
// Author      : Jan Cumps
// Version     :
// Copyright   : copyleft
// Description : Convert XES images to BIN files

#include <iostream>
#include <fstream>
#include <string>
#include <sstream>

using namespace std;

int main() {

    ifstream inFile("D:\\users\\jancu\\Documents\\elektronica\\xess\\master\\StickIt\\modules\\Vga\\FPGA\\PixelVgaTest\\img_800x600.xes");
    ofstream outFile ("D:\\users\\jancu\\Documents\\elektronica\\xess\\master\\StickIt\\modules\\Vga\\FPGA\\PixelVgaTest\\img_800x600.bin", ios::out | ios::binary | ios::trunc);
    string subs;
    uint32_t uToken = 0U;
    char c;
    uint16_t uVal;

    string line;
    while (getline(inFile, line))
    uToken = 0U;
        istringstream iss(line);
        while (iss >> subs) {
        if (uToken > 2) {
        stringstream ss;

        ss << hex << uppercase << subs;
            ss >> uVal;
            c = uVal;
            outFile.write(&c, 1);


return 0;


The result is a file that has 800 * 600 * 2 bytes. Checked with the file size:




Generate Intel HEX File


The srecord project supports converting binary files into Intel HEX format.



srec_cat img_800x600.bin -binary -o img_800x600.hex -intel


The output format generated by the utility is as below:





The xsload utility seems (I can't prove it yet because I don't have a VGA cable) to accept the format and load the file to RAM:


xsload  --ram img_800x600.hex




Success: Data in None downloaded to RAM on XuLA2-LX25!





I will know that once I connect the kit to a TV. I've checked the VGA output on an oscilloscope.

I built and loaded the Xess VHDL example (I'll explain the steps in a future blog) and loaded the bitstream:


xsload --fpga pixelvgatest.bit




Success: Bitstream in pixelvgatest.bit downloaded to FPGA on XuLA2-LX25!



Yellow: HSYNC


Magenta: one of the video signals



I hope to be able to show a TV screen with image soon. Hang on ...


XuLA2 FPGA - First Impressions of the Development Tools
XuLA2 FPGA - SD Card Read and Write
XuLA2 FPGA - Rotary Encoder and VHDL
XuLA2 FPGA - PWM with Dead Band in VHDL
XuLA2 FPGA - Up the Clock
XuLA2 FPGA - Utility to Generate Pin Assignments

I purchased a Xess XuLA2 FPGA kit a while ago.

As preparation for a test with its VGA module , I'm trying out one of the utilities to automatically create pin mappings.


You can plug XuLA modules into several connectors. Based on your choice, you have to route your signals to the FPGA balls that are connected to the pins of that connector.

And: Mapping FPGA pins to connector locations can be a dog.



I found out yesterday that there is a utility to perform this much dreaded task: the Pin Assignment Generator.



Manual Pin Mapping

In an FPGA project, you define* the mapping between I/O signals and FPGA balls in a constraint file.

If you are writing for a project with a fixed layout, that's a one-off task.

With flexible kits (like the XuLA and its motherboard, where you can plug modules in different ports) things are different.

You'd have to look up the mapping between the connector you use and the FPGA I/Os. Then adapt the constraint file with the appropriate links.

The documentation has all info that's needed. But it's a tedious job.



Mapping Utility

Tedious work calls for automation. And there's good news.

There's a mapping utility xsconnect available for the XuLA family.

It's a Python script that does  the whole cross-ref. It knows all XuLA products and their pinouts.

Based on your combination (what is plugged where in which motherboard for what FPGA board), it generates a ready-to-go mapping list.


In my case, I'm using a VGA module, plugged in connectors 2 and 3 of a motherboard version 4, running on an FPGA board version 2 .

I throw that combination to the utility, and it kindly creates the entries:


xsconn -p "StickIt! VGA V2" -m "StickIt! V4" -n pm2+pm3 -d "XuLA2"



# StickIt! VGA V2 ==[pm2+pm3]==> StickIt! V4 ==> XuLA2
net b2      loc = c1;
net b3      loc = j4;
net b4      loc = k3;
net g1      loc = b2;
net g2      loc = e1;
net g3      loc = h1;
net g4      loc = r1;
net hsync_n loc = r2;
net r2      loc = f1;
net r3      loc = m1;
net r4      loc = m2;
net vsync_n loc = t4;


You can then paste that in your constraint file and adapt the signal names to your design.

If your design uses the same signal names as the ones in the utility, you can just cut and paste.


Here's the relevant snippet of a constraint file I adapted for the above combination:

# Horizontal & vertical syncs.
net hSync_bo        loc = r2;
net vSync_bo        loc = t4;

# Red, green, blue color components to VGA DACs.
net red_o<1>        FLOAT;
net red_o<2>        loc = f1;
net red_o<3>        loc = m1;
net red_o<4>        loc = m2;
net green_o<0>      FLOAT;
net green_o<1>      loc = b2;
net green_o<2>      loc = e1;
net green_o<3>      loc = h1;
net green_o<4>      loc = r1;
net blue_o<0>       FLOAT;
net blue_o<1>       FLOAT;
net blue_o<2>       loc = c1;
net blue_o<3>       loc = j4;
net blue_o<4>       loc = k3;



Where Next?


To get the utility, execute this command from your Python enabled computer:


easy_install xsconnect


It's open source. The version created by Xess supports all their FPGA boards, motherboards and plug-ins.

But it's extendable if you want. You can add your own designs, or use it in a completely different context where flexible FPGA pin mapping is needed.


* generalisation. There are other options



XuLA2 FPGA - First Impressions of the Development Tools
XuLA2 FPGA - SD Card Read and Write
XuLA2 FPGA - Rotary Encoder and VHDL
XuLA2 FPGA - PWM with Dead Band in VHDL
XuLA2 FPGA - Up the Clock
XuLA2 FPGA - Utility to Generate Pin Assignments

Embedded Vision is one of the most exciting domains in today’s technology. It provides machines the ability to see, sense, intelligence and immediately respond to the real world. As a key and pervasive megatrend, embedded vision is shaping the future of the embedded industry.


RGGBer is a fully open source, low cost and modular development kit that makes embedded vision design easy! It provides user all the necessary hardware resources and accessories to support

1080P@60fps video applications. RGGBer is based on FPGA solution which is the most powerful and mainstream.




The key values of RGGBer Dev Kit:

  • It frees development team from spending time on general, repetitive basic works. You may quickly start with featured things of your embedded vision product.
  • Save money and speed your project schedule. Lower the risk of project.
  • RGGBer is open source platform. Developers are able to contribute or share knowledge with others.


We just set up a campaign page on Crowd Supply site and decide to launch this campaign this Aug. You may sign up on the pre-launch page which shares with same URL to receive updates and be notified when it launches.




We have shared with people some of the features on hacker/maker community.

  1. What is RGGBer Dev Kit?
  2. Machine vision demo
  3. Video processing demo
  4. High speed image network demo
  5. ADAS demo
  6. Wireless control to RGGBer


I had a great opportunity to test and to review the Terasic new flagship, the DE10-Standard FPGA-SoC board.

We will take a look at what this product has to offer, what is its target group and if it is worth its money.

Jan Cumps

XuLA2 FPGA - Up the Clock

Posted by Jan Cumps Top Member Feb 4, 2017

The XuLA2 standard runs on a 12 MHz clock. That's plenty for many things, but not enough for some designs.

In my PWM with DeadBand  project, for instance, the effective signal frequency that the module outputs is halved for each bit of precision of the duty cycle register.

If you want to have 256 steps between 0 and 100% duty cycle, you need 8-bit precision and your maximum PWM output frequency is 47 kHz. When you need higher PWM frequency with the same duty cycle granularity, you can use a Digital Clock Manager to generate a (much!) faster clock signal for the PWM module.

I need a minimum 1 MHz output for the GaN half-bridge that I'm driving (an LMG5200). The deadband should be a in the range of 8 - 10 ns.

Let's assume that we allow for 2 ns steps (we can then set a deadband of 10 ns by skipping 5 ticks.

2ns means that our input frequency has to be 500 MHz. We can't do that - its beyond the capabilities of the Digital Clock Manager of the Spartan-6.

4ns is doable but a stretch. It'll require an up-sample to 250 MHz.


Only 12 MHz! Now what

That's the title of the Xess VHDL Tutorial chapter that covers this concept. Look there for the explanation.

I'll focus on a practical application.



library UNISIM;
use UNISIM.VComponents.all;
-- ...
architecture Behavioral of Rotary_Pwm is
-- ...
  signal clk_fast     : std_logic;

   DCM_SP_inst : DCM_SP
   generic map (
      CLKFX_DIVIDE => 1,                     -- Divide value on CLKFX outputs - D - (1-32)
      CLKFX_MULTIPLY => 22                    -- Multiply value on CLKFX outputs - M - (2-32)
   port map (
      CLKFX => clk_fast,    -- 1-bit output: Digital Frequency Synthesizer output (DFS)
      CLKIN => clk_i,       -- 1-bit input: Clock input
      RST => '0'            -- 1-bit input: Active high reset input

  u0 : PwmDeadBand
    port map (
      clk_i => clk_fast,
  duty_i => accumulator_s,
  band_i => 64,
      pwmA_o => pwmA_o,
      pwmB_o => pwmB_o
-- ...



The DCM_SP_inst is an instance of the Spartan-specific DCM_SP primitive. It's not a standard VHDL construct.

At this point, our design becomes device dependent. You can't just port it to another FPGA.


I've used the following design decisions:

To get the 4ns step rate the minimum frequency is 1/4ns = 250 MHz.

Our output frequency is going to be that frequency divided by 256, so we're just under our   MHz output goal.

We'll have to up it to at least 256 MHz.

With a 12 MHz clock as input, we'll need to multiply that clock with 22 and get 264 MHz.

Each step will have a period of 3.8 ns - close enough to the 4 ns we're aiming for.


We only have to pass that fast clock to the PWM module.

There's no reason to route it to the rotary encoder, it can keep running on the 12 MHz clacker.



photo: Bart Simpson looks over a wall


In the capture above, I've set a deadband of 64 clock ticks (to have something measurable on the scope).

The signal frequency is 1.03127 MHz (theoretical 12 MHz * 22 / 256 = 1.031250 MHz)

The time between the cursors is 244 ns for 64 dead band ticks. So the measured granularity of our deadband is 244ns / 64 = 3.8125 ns.


Here's a capture with 8 clock ticks.


My GaN board will run with 2 or 3 ticks - I'd have to use different probe technique to show that.

Good captures in the neighbourhood of 8 ns (that's the deadband that I'll try to achieve) are hard on a 50 MHz scope



XuLA2 FPGA - First Impressions of the Development Tools
XuLA2 FPGA - SD Card Read and Write
XuLA2 FPGA - Rotary Encoder and VHDL
XuLA2 FPGA - PWM with Dead Band in VHDL
XuLA2 FPGA - Up the Clock
XuLA2 FPGA - Utility to Generate Pin Assignments

A PWM module for FPGAs that supports dead band.


A VHDL project that generates two opposite PWM signals with a dead band. You can change the duty cycle with a rotary encoder.

When you drive half-bridge designs, you need a control signal for both transistors in the circuit.

These signals need to be each other's opposite, because you close one transistor when you drive the other.

At the switching time, you introduce a tiny bit of dead time, to allow one transistor to properly shut before the other opens.

If you don't allow for this stabilisation period, your transistors will get hot and the magic smoke will eventually (sooner rather than later) escape.


I've made a VHDL module that generates these complementary signals, including a configurable deadband.

You decide in your design what the frequency and deadband is.

You can then freely change the duty cycle. The FPGA takes care that the dead time is guaranteed.


PWM VHDL module


My design is 100% based on the Xess XuLA2 PWM library. I've added the complementary signal and introduced that delay for rising edges of both outputs.


entity PwmDeadBand is
  port (
    clk_i  : in  std_logic;             -- Input clock.
    duty_i : in  std_logic_vector;      -- Duty-cycle input.
    band_i : in  natural;               -- number of clock-ticks to keep both signals low before rising edge
    pwmA_o  : out std_logic;            -- PWM output.
    pwmB_o  : out std_logic             -- PWM output inverse.
end entity;


duty_i is a register that holds the desired duty cycle. It's configurable - I've set it to 8 bits.


Your clock speed is dependent on the size of this register.

The clock that you present on the clk_i input of the module will be divided by 2^(number of bits). In this case, 2^8 -> 256.

For the standard 12 MHz clock of the XuLA2, the PWM module will beat at 47 kHz.

There are ways to increase the clock frequency in the FPGA and the XuLA2 libs have support for that.


The dead band, in clock ticks, is passed via the band_i pin. The two complementary signals appear on pwmA_o and pwmB_o.

In the constraint file of your project, you assign that to physical Spartan-6 pins:


# PM1 connections for the pwm outputs
net pwmA_o      loc=m16;
net pwmB_o      loc=k16;


If you use a StickIt! motherboard, you get the signals at PM1, pin D4 and D6.

If you tap them from the XuLA2 directly, they are chan4 and chan6 on the expansion header.


The implementation is just an extension of what the original Xess library does.

We introduce an additional channel that's HI when the other is LO,, and vice versa.

And we hold off driving any of these channels high until we've waited duty_i clock ticks.


architecture arch of PwmDeadBand is
  constant MAX_DUTY_C : std_logic_vector(duty_i'range) := (duty_i'range => ONE);
  signal timer_r      : natural range 0 to 2**duty_i'length-1;


    if rising_edge(clk_i) then
      pwmA_o   <= LO;

      timer_r <= timer_r + 1;
      if timer_r >= band_i + TO_INTEGER(unsigned(duty_i)) then
  pwmB_o <= HI;
  end if;

      if timer_r < TO_INTEGER(unsigned(duty_i)) then
        pwmB_o <= LO;
        if timer_r >= band_i  then
  pwmA_o <= HI;
   end if;
      end if;
    end if;
  end process;
end architecture;


That's really all for the PWM module.


Rotary Encoder module


This section is very short: read the previous blog post.


Patching it together


Also easy. We just have to wire the register that holds the value of the Rotary Encoder to the one that's driving the PWM module.

I just use the same register. That's the simplest way to do this.



entity Rotary_Pwm is
    Port ( clk_i : in  STD_LOGIC;
           rotEncA_i   : in  std_logic;        -- Rotary encoder phase 1 output.
           rotEncB_i   : in  std_logic;        -- Rotary encoder phase 2 output.
           pwmA_o      : out  STD_LOGIC;
           pwmB_o      : out  STD_LOGIC  
end Rotary_Pwm;

architecture Behavioral of Rotary_Pwm is

  signal accumulator_s : std_logic_vector(7 downto 0) := "01111111"; -- 50%


  u0 : PwmDeadBand
    port map (
      clk_i => clk_i,
  duty_i => accumulator_s,
  band_i => 16,
      pwmA_o => pwmA_o,
      pwmB_o => pwmB_o

  u1 : RotaryEncoderWithCounter
    generic map (ALLOW_ROLLOVER_G => true, INITIAL_CNT_G => 127)
    port map (
      clk_i => clk_i,
      a_i   => rotEncA_i,
      b_i   => rotEncB_i,
      cnt_o => accumulator_s

end Behavioral;


So the handover point is the 8-bit register accumulator_s. When you turn the encoder, it changes the value of the register to reflect your action.

In real-time, the duty cycle of the PWM module adapts. There's not a single clock tick between event and action.




I've used PM1 on the StickIt! motherboard, and used these pins:



PM1 pin
XuLA2 pin
Spartan-6 pinpin namedirectionfunction
6 - +3V3+3.3V+3.3Voutpull-up power for encoder
5 - GNDGNDGNDoutground for PWM and Rotary Encoder
4 - D6CHAN6K16pwmB_ooutPWM complementary signal B
3 - D4CHAN4M16pwmA_ooutPWM complementary signal A
2 - D2CHAN2R16rotEncB_iinRotary Encoder pin B
1 - D0CHAN0R7rotEncA_iinRotary Encoder pin A


If you want to wire the encoder inputs or pwm outputs to other pins, you only have to change the constraint file.





The project is attached, together with the PWM library.

I'm going to use this to drive my GaN experiment board. You?


XuLA2 FPGA - First Impressions of the Development Tools
XuLA2 FPGA - SD Card Read and Write
XuLA2 FPGA - Rotary Encoder and VHDL
XuLA2 FPGA - PWM with Dead Band in VHDL
XuLA2 FPGA - Up the Clock
XuLA2 FPGA - Utility to Generate Pin Assignments

How to use a rotary encoder with the XuLA2 and the Spartan-6 FPGA.

Another real world example: I'm checking if the Xess Rotary Encoder library works with the encoder I use in a GaN half-bridge design.

TL;DR: yes it works

Xess has a plug-in board with a rotary encoder. I'm not using that module (called a StickIt!) - but I'm using the sample project that comes with it.




Hat Shield Cape Wing. All names were taken except the coolest one.

StickIt!s are tiny modules that work togethet with the XuLa.

A XuLA board is small. Still it manages to expose loads of FPGA pins. Plug the XuLA in a breadboard and you have access to them.

Alternatively,  you can go StickIt!.


To start using the StickIt! modules, there's a motherboard. You dock the XuLA onto it and the signals become available in a few ways:

  • as a Raspberry Pi Hat (it can be used as a Hat or you can plug hats onto it. Your call).
  • as StickIt! ports where you can you can plug StickIt! modules into. The motherboard can host three modules.


In this blog I'm attaching the rotary encoder contacts to StickIt! port PM1. I just use patch cables to make the connections between my GaN PCB and that connector.

If you don't have the motherboard, you can make the connections directly to the XuLA2. I've pasted the xref tables you need to find out the correct pins.


This is the schematic of my rotary encoder. It's identical to the Xess module - except that I've added debounce capacitors.




The encoder is a Panasonic EVQ-VVD00203B Square SMD Encoder.

That's not the same model as the one on the Xess board but it works the same. This one doesn't have a push-button built in.



I'm plugging it into the PM1 of the motherboard. The power comes from the XuLA board, so you have to populate the XuLA PWR jumper and remove all others.

On this image you can see where you have to insert the jumper wires coming from the encoder.

Pin 6, VCC, goes to the 3V3 of the encoder circuit.

Pin 5, GND, to the circuit's GND

Pin 1, DO, to one of the encoder's switch contacts

Pin 2, D2, to the other switch contact.

The table also shows the channel numbers. Use these if you work without the motherboard. They represent the XuLA2 pins.




In this table you can find the mapping between the channel number and the FPGA signal.

You'll use that to define the pins in your project's constraint file.

For the pins that I've used, this is the constraint info.


# PM1 connections for rotary encoder module.
net rotEncA_i   loc=r7;
net rotEncB_i   loc=r16;


Update your project's .ucf file to reflect that.



I haven't changed a single line of code. I just went trough the typical FPGA build steps and generated the bitfile.


> xsload --fpga rotaryencodertest.bit
Success: Bitstream in rotaryencodertest.bit downloaded to FPGA on XuLA2-LX25!


Then I used the Python test script that's part of the project. It checks the (defined in the VHDL project)  register that holds the accumulated value, and prints it to the command line.

To start the test, execute this command:




Rotate the encoder like a madman and see the results on your command prompt:


If you don't have a rotary encoder, break open an old mouse. The scroll wheel is often an encoder.


XuLA2 FPGA - First Impressions of the Development Tools
XuLA2 FPGA - SD Card Read and Write
XuLA2 FPGA - Rotary Encoder and VHDL
XuLA2 FPGA - PWM with Dead Band in VHDL
XuLA2 FPGA - Up the Clock
XuLA2 FPGA - Utility to Generate Pin Assignments

Let's try to do something real with the Xilinx Spartan-6 FPGA: write a set of data to an SD card.


To boost the FPGA skills, I'm refreshing theory and checking out some real designs.

For a standalone XuLA2 board, talking to SD cards is a good practical example.


There's  a Micro SD slot on the XuLA2 models. The only other component you need is a spare Micro SD card.


Don't use an SD card with your marriage photo shoot on it. You'll very likely loose that when you test this project.


The Xess XuLA2 github has two SD card projects. We'll use the SD Card Control Test example.

In this project, the FPGA has two main duties:

  • Read and Write SD data
  • Communicate with your PC over USB

A python script on your PC will generate test data and send it to the FPGA over USB.

The FPGA writes the data to your SD card. We're using low level protocol here, no filesystem.

When finished, it reads the data back off the SD card and verifies the results.


VHDL Libraries


Xess made a set of common VHDL libraries. The example uses several those libs.

The communication with the SD slot is via :

  • SDCard.vhd

Clocking is handled by these two:

  • ClkGen.vhd
  • SyncToClk.vhd

Talk to the PC over USB happens with this one (and the on-board PIC microcontroller):

  • HostIo.vhd

These libs are not only useful, but also a great source to learn reusable VHDL.



How it Works


The XESS blog explains the example in detail. It explains both the electrical connections and how the Micro SD protocol is handled.

The header comments of the SdCard.vhd source file document many implementation details.

Open that file by double-clicking the u3 - SdCardCtrl node in the Implementation view.

If you've ever tried to understand (or port) a microcontroller SDCard lib - maybe the one from Arduino - you'll recognise much of the logic.


Let's now synthesize the project and generate the programming file.

Insert the SD card, connect the XuLA2 with your laptop and load the bitstream:


xsload --fpga sdcardctrltest.bit


Once you've loaded the bitstream, your XuLA2 board sits idle. You need to tell it to read and write data.

There's a python scrip that does exactly that.

If you have retrieved the latest XuLA2 FPGA sources from GIT, you'll find a python file named in the project directory.

If you're using the examples that were installed by the XESS installer, you can retrieve the testbed from here:


Run the script to write a random set of data to the SD card, read it back and check if everything is correct:



The data is written using low level protocol. You will not be able to read the data when you insert the SD card into your PC.

The design doesn't use a filesystem or any other advanced disk management protocol. It's SD access for real blokes.


Windows 8 and Windows 10 with Xilinx ISE


If you are running WIndows 10 64-bit, you may encounter several ISE problems:


  • Pressing the Open Project button (and several other actions, like selecting the Preferences menu item) crashes ISE.
  • Running the Simulator results in a "failed to link the design" message and the simulator not starting.


Switching to the 32-bit version has solved most of them for me:

To switch,

  • alter the command in the ISE shortcut to
    "<DRIVE>:\Xilinx\14.7\ISE_DS\settings32.bat D:\Xilinx\14.7\ISE_DS\ISE\bin\nt\ise.exe"
  • in "<DRIVE>:\Xilinx\14.7\ISE_DS\ISE\bin\nt", rename fuse.exe to _fuse.exe, and copy the fuse.exe from the "..\nt64" directory over (got that from here)


After that, I still have one issue left: when in Simulator, the Relaunch functionality doesn't work. I have to close iSIM and restart it from within ISE.


I've also tested the design with a known defect card - one that's rejected by any known operating system and can't be formatted.

This test was successful. The test flagged that the FPGA wasn't able to write data, as expected:



The core of the example can be used in your own design as a persistent storage area.

If you want to use it as a data exchange mechanism, you'll have to find a way to read the raw data from the card. That can be done with an Arduino.

Another - advanced - option is to implement a supported file systems (fat32?) in HDL,

Whatever you do, make it a nice design and share your work.



XuLA2 FPGA - First Impressions of the Development Tools
XuLA2 FPGA - SD Card Read and Write
XuLA2 FPGA - Rotary Encoder and VHDL
XuLA2 FPGA - PWM with Dead Band in VHDL
XuLA2 FPGA - Up the Clock
XuLA2 FPGA - Utility to Generate Pin Assignments

I purchased a Xess XuLA2. It arrived this morning.

This post is the story of my first steps



I have a little bit of experience with FPGAs. I learned digital electronics in the early-to-mid 80's.
My VHDL skills are beginner level and I've worked with the Xilinx Spartan 6 and development tools.

This is my experience to run a first design on the XuLA2 board


I have done training work with the Spartan 6 FPGA before. The Xilinx development environment is running on my laptop and works.

I can focus on getting the Xess tools working.

That's not difficult, but I had some issues with Python dependencies that I'll document here.


The USB Driver

Installing the device on a Windows10 laptop was easy. There's the typical 'signed driver' hurdle to jump.

When you plug in the XuLA, it's recognised by the OS, but in the Device Management screen there's a warning next to the device.

The typical Windows " invalid hash signature" warning.


The solution is known. You have to restart Windows in a special mode that allows to install unsigned drivers (use your google-fu to find the instructions for your version and language).

Once Windows is restarted in the 'allow unsigned drivers' mode, right-click on the device in the Device Manager and select Update Driver.

Windows will find the driver for you and install it. From then on, all is good.


The Loader Tool

The XuLA depends on external tools to synthesize your design into an upload file. I'm using the free Xilinx ISE toolset.

The Xess tools come into play when you want to load your designs to the FPGA.

They have command line and GUI applications. I'm testing the command line Loader tool here.


The command line tools are for Python 2.7 - I got synthax errors in the print() and other functions when trying it with 3.x.

The instructions to install the toolkit are here:

Install went fine. But I ran into a dependency conflict.

The tools depend on a Python library called pubsub. The installer nicely reports that the minimum required version is pypubsub >= 3.1.2.

(I don't know anything about python - I learned the deep internals of it today while getting all of this working )

The bad thing is that the latest version of that library, 4.x, doesn't work (either with Python 2.7 or with the current Xess tools release - I don't know that).

So I had to force-replace pubsub 4 with pubsub3 (I've logged an issue on github).


I used these commands:


pip uninstall Pypubsub
pip install -Iv


Finding all of that out took me a half day - don't ask how I did that unless we're in a pub together and you're paying for the drinks.

Once done, all works.


Success: XuLA2-LX25 passed diagnostic test!



Testing the XuLA2

I used the mandatory blinky project. I didn't use an LED though, but an oscilloscope.


The XuLA2 examples are available when you install the Xess XSTOOLS.

I've opened Examples/XuLA2/LX25/blinker in the Xilinx ISE, synthesised it and generated the programming file.

You can also make the project yourself by following the instructions in the Xess tutorial, chapter "Starting a Design in WebPACK"


Then I used the XSTOOLS Loader to beam it to the XuLA2:


xsload --fpga blinker.bit
Success: Bitstream in blinker.bit downloaded to FPGA on XuLA2-LX25!



With my scope attached to the CLK pin at the right lower corner of the PCB, I got the output:



The clock and output setting are defined in blinker.ucf:


net clk_i     loc=a9;  # 12 MHz input clock.
net blinker_o loc=t7 | IOSTANDARD=LVTTL | DRIVE=24 | SLEW=SLOW ;  # Blinker output to LED.




The downcount from 12 MHz clock to approx. 1Hz blink signal is done in the VHDL design:


entity blinker is
    Port ( clk_i : in  STD_LOGIC;
           blinker_o : out  STD_LOGIC);
end blinker;

architecture Behavioral of blinker is
signal cnt_r : std_logic_vector(22 downto 0) := (others=>'0');

process(clk_i) is
  if rising_edge(clk_i) then
    cnt_r <= cnt_r + 1;
  end if;  
end process;

blinker_o <= cnt_r(22);

end Behavioral;


(if only e14 had a VHDL syntax highlighter)



It works




XuLA2 FPGA - First Impressions of the Development Tools
XuLA2 FPGA - SD Card Read and Write
XuLA2 FPGA - Rotary Encoder and VHDL
XuLA2 FPGA - PWM with Dead Band in VHDL
XuLA2 FPGA - Up the Clock
XuLA2 FPGA - Utility to Generate Pin Assignments

This is the summary page for the XXICC (21st Century Co-design) project. XXICC was previously hosted at Google Code, which no longer accepts new projects or edits to existing projects. now links to this page.


The latest XXICC release is XXICC (21st Century Co-design) release 0.0q


XXICC (21st Century Co-design) is a not-for-profit research project which attempts to bring digital hardware/software co-design into the 21st Century using an improved programming language and a Reduced Software Complexity philosophy. Its goal is to make it easier and more enjoyable to write and maintain digital hardware and software. XXICC is pronounced “Chicken Coop”, so-called because it has so many layers.


XXICC’s GalaxC programming language narrows the gap between problem domain and language by allowing programmers to extend GalaxC by adding problem domain notations. Instead of adapting the task to the language, they adapt GalaxC to the task. The key extension mechanism in GalaxC is separation of syntax from semantics, a simple yet powerful way to add new notations. This is directly adapted from the Galaxy programming language developed in the late 1980s.


GalaxC programs may consist of ordinary ASCII characters and white space, like C. However, GalaxC programs may also have executable tables, schematic diagrams, comment blocks containing formatted text and figures (not yet implemented), variable names in different fonts, special symbols, string literals containing formatting, and WYSIWYG dialog boxes. This eliminates the need for separate documentation files (which are very hard to keep synchronized with a program) as well as a separate “resource editor”.


These are all edited using the XXICC Object Editor, a unified program and document editor which combines the features of a document editor, spreadsheet program, figure/schematic editor, dialog box editor, and more into a small, easy-to-use program with a consistent user interface. The XXICC Object Editor is written entirely in GalaxC and is used for editing all XXICC software and documentation. XXICC believes in the “take your own medicine” approach to software engineering.


Why GalaxC?


I created GalaxC to address my dissatisfaction with available programming languages.  I found that I spent a great deal of time “encrypting” ideas into restrictive programming languages, and felt it might be more efficient (and certainly more fun) to have a language that can be taught new notations so that the resulting code would be easier to write, understand, and debug.  GalaxC is an attempt to make this possible, or at least blaze a path in the right direction.


If you are perfectly happy with the programming language(s) you are using then you probably shouldn’t waste time learning about GalaxC, except perhaps out of morbid curiosity.  While it is possible that GalaxC’s ideas will revolutionize computer programming and you’ll need to know it to be competitive, it’s unlikely to happen any time soon with the present experimental versions of GalaxC.  OTOH, if you’re adventurous and dissatisfied with current language offerings, read on.


Getting Started


As with any new project, RTFM.  I try to write good documentation and keep it reasonably up to date.  For an overview of GalaxC, read Chapter 1 (Introduction) of Programming in the GalaxC Language.  GalaxC and XXICC try to follow the Reduced Software Complexity philosophy described in Chapter 1 of The XXICC Anthology.  You might find this interesting.


Programming in the GalaxC Language is primarily the reference for the GalaxC language, but tries to provide enough tutorial examples so you can get started. But it also provides considerable detail of how GalaxC’s compiler is implemented.  This is often TMI on a first reading and can be skimmed.  You’ll probably find Chapters 2 and 3 (Tokens and Expressions) to be pretty much the same as C and will go quickly.  Chapter 4 (Types and Variables) diverges quickly from C and gets into how GalaxC’s type inheritance mechanism implements many program features such as variables.  Some parts are TMI on first reading, but are there for the curious.


Chapter 5 (Functions and Macros) is a lot of fun since GalaxC allows them to have any legal syntax.  Here you will really see the power of the language.  Chapter 6 (The Postfix Stack Interpreter, PSI) describes the intermediate interpretive code which GalaxC executes.  What’s remarkable here is how much of GalaxC is implemented using macros and inline functions instead of building these features into the compiler.


Chapter 7 (Control Statements) looks a lot like C, though more like Pascal.  It’s interesting to see how GalaxC implements looping constructs as macros.  Chapter 8 (Programmer-Defined Types) is primarily concerned with data structures, arrays, and pointers.  These mechanisms are similar to C.


Chapters 9 (Generic Macros and Inline Functions) and 10 (Introduction to Special Functions) go deep into how GalaxC is implemented and are TMI for most users.  However, if you are curious as to how GalaxC is constructed, check out Section 10.1 (A Brief Tour of the GalaxC Compiler).


To compile and/or install XXICC on your computer, look at Installing and Running XXICC.  Then look at Compiling and Running GalaxC Programs to learn how to compile and run GalaxC programs.


When you’re ready to try some user interface programming, look at Chapters 3 and 4 of The XXICC Anthology.  They describe the GalaxC Simplified Window Manager (G-SWIM), an easy way to create portable GUI applications.


We have included some sample programs in  These include many of the sample programs in The XXICC Anthology.




For help with XXICC and GalaxC, please ask in the comments section.  This is much better than sending e-mail to the author as he may be too busy to get back to you quickly and others may be able to help you sooner.  Plus, by writing comments you’ll help future users with similar questions.


XXICC is a not-for-profit research project.  If you find XXICC useful or potentially useful, we can use help.


Reproducible Bugs


The single most useful thing we need is ways to reproduce bugs.  There are some known bugs that are maddening difficult to reproduce, so if you are able to reproduce strange behavior we’d really like to learn how so we can fix the bug.  My motto is “a reproducible bug is half fixed”, because once it is reproducible you can instrument the code and quickly figure out where and why.


For now, describe issues in the comments.  If there's anough activity I’ll make a separate issues list.


I’d also like to know about typos and other problems with the documents.


Regression Testing


This is a nasty problem with all software projects: you make a change and suddenly something that used to work is now broken.  There’s even a song about this:


99 little bugs in the code,

99 bugs in the code...

take one out, compile again,

100 little bugs in the code.

[Repeat until bug count goes to zero.]


The reason GNU/Linux is so stable is that there are so many people all over the world testing all sorts of versions on all sorts of platforms.  We’ll take all the help we can get for XXICC.




Currently XXICC does not have a mechanism for accepting donations.  We suggest instead supporting not-for-profit organizations that help Free Software and the free exchange of ideas such as the Free Software Foundation, Electronic Frontier Foundation, Wikimedia Foundation, and Software Freedom Law Center.




The author would like to renew thanks to the talented individuals who helped make the original version of Galaxy circa 1988.  Foremost he wishes to thank Anne Beetem for her ideas, inspiration, support, and scholarly collaborations.  He would also like to thank Jong-Min Park and Jim Rose for their contributions to the original implementation of the Galaxy compiler and its environment, and Monty Denneau for asking The Question which led to the original conception of Galaxy.


The author would also like to thank his family and friends for their support and encouragement over the years which led to GalaxC and XXICC reaching this point.  He would also like to acknowledge the literary inspirations of Miguel de Cervantes and Edmond Rostand towards putting Quixotic idealism ahead of practicality, Kurt Vonnegut for Cat’s Cradle, and Jan Potocki’s The Saragossa Manuscript which celebrates performing vast projects by oneself.


This text is © 2011 John F. Beetem and licensed under the Creative Commons Attribution-!ShareAlike 3.0 Unported License (CC BY-SA 3.0).  To view a copy of this license, visit  No warranty is expressed or implied.