Skip navigation
1 2 3 4 Previous Next

FPGA Group

57 posts

Following the mega useful suggestion from aventuri about the existence of this board I bought one because I couldn't find any other way to get hold of a Lattice UP5k FPGA chip in 48 pin QFN.


This is an interesting FPGA in that it has 5k LUTs, the usual block RAM (15kbytes), 4 single port RAMs totaling 128kbytes and 8 16 bit wide multipliers, all this in a 48 pin prototype friendly QFN package and quite cheap - if only anyone had them in stock.


The UPduino board has A UP5k, an absurdly large (32Mbit) flash for program storage, a three colour LED, power regulators and not much else. It is very cheap at $7.99.


The owner of Gnarly grey worked for Lattice for several years and thye are promoting the board on their website.


My board came very quickly from the US to here in the UK, no fancy packaging, just a poly (anti static) bag in a standard envelope.


I got it going today which took way longer than it should have done you can program the FLASH memory using standard Lattice software with an FTDI breakout board or cable I didn't have a board but I did have a  C232HD-DDHSP-0C232HD-DDHSP-0 cable(Farnell 2352017 To cut a long story short the cable won't work unless you reduce its length drastically I cut mine down to about 10cm long This is because neither the FTDI chip in the cable or the FLASH chip on the FPGA board expect to drive cables when the data changes on the output of the FLASH chip it cross couples into the clock signal due to the cable capacitance and the resulting clock glitch breaks the communications Crazily it took a 1GHz scope to debug the comms the FLASH chip is fast and the glitches are short


The hardware design of the board is truly dreadful - OK it was cheap but it is kind of amazing bearing in mind the makers' connections with Lattice. It breaks several of Lattice's design rules for this part.


There is almost no power supply decoupling on the board.

There is no ground plane and the ground is a spidery thin track weaving about the board.

Lattice recommend a filter to the FPGA PLL power pin - the UPduino has the series 100R resistor but does not have a capacitor on the FPGA side of the resistor to ground.



There is no precision oscillator on the board - the UP5k has its own rubbish 48MHz (+/- 10% for 0-85C)) oscillator on chip but this isn't good enough for a great many things. It's worth putting the oscillator on board so the fast clock doesn't have to have long wires.


I'll add to this blog if I do much more with the UPduino - it's tempting just to remove the FPGA and put it on my own board.


The supplied example files are pretty gruesome, possibly below even Lattice's pretty low standard for example code. The LED blink example is quite short but has not one single comment !

There is a Raspberry Pi IO expander example on GG's website - the key file in that is spi_gpio.v - oddly embellished with Lattice copyright stuff and dated 2010 - 310 lines of code - zero comments.


In summary this is great idea done badly: very badly.


It's not much use to pros -  no oscillator, dreadful design practice so won't give a good idea of any device limitations and is hopeless as a reference design. It's not much use for learning either -  the low price is great but the total lack of any kind of decent tutorial stuff is a huge negative.


So unless, like me, you just have to get hold of the UP5K, this isn't a very good buy - even at $7.99.




Multiplication on FPGA

Posted by mbozdal Sep 22, 2017

FPGA gets its power from the flexibility. The design process can be time-consuming but you can design basically anything. In this project, I will give some examples of the multiplication and flexibility of FPGAs.


Multiplication consumes time and sometimes they specify the whole performance of the system. Impulse response or Fourier transform of the discrete signal is calculated by multiplying and adding the massive number of samples because of that the power of the digital signal processor(DSP) chips are compared with their multiplication and addition (MAC) numbers in a second. FPGAs, which provides custom solutions, are used in many applications which require huge MAC operations like military radar applications, adaptive noise cancellations, machine vision, HDTV and etc. The multiplication operation can be performed in many ways on FPGA. Based on the application, it can be implemented parallel or pipelined where the speed is important or it can be implemented to cost small footprint.


The DE0-Nano device 149 configurable pins therefor I will use 32*32 multiplier for the test. You can have more bits to multiply but you can't assign them to the pins. Hence, this is the demonstration of different methodologies, I don't use any other design than the multiplier.


Altera Megafunction

Let's start with the easiest way of multiplication using the libraries   Altera has something called Megafunctions and it is stated like:


As design complexities increase, use of vendor-specific intellectual property (IP) blocks has become a common design methodology. Altera provides parameterizable megafunctions that are optimized for Altera device architectures. Using megafunctions instead of coding your own logic saves valuable design time. Additionally, the Altera-provided functions may offer more efficient logic synthesis and device implementation. You can scale the megafunction’s size by setting parameters.


The Code:

module multiplier(m,q,result);  
  input [31:0]m;  
  input [31:0]q;  
  output [63:0]result;  
  assign result = m * q;  


The Result:


RTL Viewer:


It looks like the Altera EP4CE22F17C6  has built-in hardware multipliers and if use "a * b"  it is automatically done by the dedicated multiplier. The multiplication is done by using lpm_mult  megafunction. It only uses 79 logic elements. It looks like Altera megafunctions are working as expected. They save time and create an efficient logic synthesis. * b


The lpm_mult megafunction can be implemented using either logic resources or dedicated multiplier circuitry in Altera devices. Typically, the lpm_mult megafunction is translated to the dedicated multiplier circuitry when it is available because it provides better performance and resource utilization.


Array Multiplier

Another design method is array multiplier. Multiplier m and multiplicand q are multiplied by using array multiplier as shown in Figure Array Multiplier which is same as the paper and pencil multiplication. Summands are calculated by multiplying m with each bit of the q by BasePPI module at the top layer and PPI modules in other layers. In order to make the code more readable n-bit BasePPI and PPI modules are used and n-1 layer is generated with a loop. The size of the design is controlled by parameters n.


Array Multiplier


The Code:


module multiplier (m, q, result);

parameter n=32;
//assign inputs and outputs
input [n-1:0] m, q;
output  [2*n-1:0] result;


wire [n-1:0]link[n-1];

genvar i;
PPI(link[i-1], m, q[i+1] , link[i], result[i+1]);
assign result[2*n-1:n]=link[n-2];


//higher tier adder cell instantiating full adder

module PPI(PPI_bit, m, q, ,out,px);

//assign inputs and outputs
parameter n=4;
input [n-1:0] PPI_bit, m;
input q;
output [n-1:0]out;
output  px; 

genvar i;

wire [n-1:0]link;

half_adder( (q & m[i]),PPI_bit[i],px,link[i]);
full_adder( (q & m[i]),PPI_bit[i],link[i-1],out[i-1],link[i]);
assign out[n-1]=link[n-1];


//base tier adder cell instantiating full adder

module BasePPI(m, q,out,px);

//assign inputs and outputs
parameter n=4;

input [n-1:0]m;
input [1:0]q;
output [n-1:0]out;
output px;  //product output

genvar i;


wire [n-1:0]link; // for carry link 

half_adder( (q[1]& m[i]),(q[0] & m[i+1]),px,link[i]);
else if (i==n-1)
half_adder( (q[1]& m[i]),link[i-1],out[i-1],out[i]);
full_adder( (q[1]& m[i]),(q[0] & m[i+1]),link[i-1],out[i-1],link[i]);


//full adder
module full_adder( a, b, carry_in, sum, carry_out);

//assign inputs and outputs

input a, b, carry_in;
output reg sum, carry_out;



//half adder
module half_adder( a, b, sum, carry_out);

//assign inputs and outputs

input a, b;
output reg sum, carry_out;




The result:

The output result shows that 251 logic element is used without using any embedded multipliers. It is a little larger than Altera megafunction. The RTL viewer is more complicated but acceptable.


RTL Viewer:

Sequential Multiplier

Assume the multiplicand (A) has N bits and the multiplier (B) has M bits. If we only want to invest in a single N-bit adder, we can build a sequential circuit that processes a single partial product at a time and then cycle the circuit M times.

This is how the sequential multiplier is described. The description depicts it will be space efficient but the implementation doesn't show it is correct. Maybe, my design is not efficient, I am still learning the language.




The Code:

module multiplier (m, q, result);

parameter n=32;

//assign inputs and outputs
input [n-1:0] m, q;
output [n+n-1:0] result;
reg [n-1:0] A,B;
reg [n-1:0]P;
reg carry;

  assign result = {P,B};
integer i;

          {carry, P} = P + (B[0]==1 ? A : 0) ;
{carry, P, B} = {carry,P,B}>>1;





The Result:

This supposed to be a small footprint and slower but the result shows that it has the biggest footprint. It locates 2,046 logic elements which are much more than the other methods.



RTL Viewer:

The RTL viewer is much more complicated. It doesn't look like something understandable in a short time.

Test Code

When you design a circuit, you need to test it. But, the manual test can be time-consuming therefore it is good practice to write a test code for your design. You can test the design I have written up with the following test code. You can use Modelsim-Altera but if you don't want to install EDA tools you can use It has some limitations but easy to use. The following code doesn't test the all the input variables because of the limitations on edaplayground. You only need to change m and q variables in the for loops. The code below only checks for if the output is correct with the current inputs. There is no timing analysis.


module aritmetik_tst();

  // inputs and outputs for test circuit
  reg [31:0] m, q;
  wire [63:0] result;
  reg flag;
  integer i,j;

  // connection between testbench and design        
  multiplier i1 (  
begin                                                                     flag = 1;
  for (m = 1; m < 64; m = m + 1)
      for (q = 1; q < 64; q = q + 1)
         if (result != m * q)
          flag = 0;
          $display("Test failed at %d x %d", q, m );
       end //end of for(m)
    end//end of for(q)
    $display("Test Failed, End of Simulation");
    $display("Test Successful, End of Simulation");




FPGA is so flexible you can almost design everything but it may be time-consuming. It looks like it is better to use Altera functions and trust the vendor. Quartus is so sophisticated software and I think vendor optimise their functions with cooperation between EDA tool and underlying hardware.

Here is the new release 0.0r of XXICC.  I've been horrifically busy with work and family obligations over the last two years so I wasn't able to keep up with XXICC.  Also, 0.0r is a major release since it adds integer nets and operators to GCHD, and can now program Lattice iCE40 FPGAs using the open-source IceStorm tools.  So there was lots of testing and documentation updates.


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.


For an overview of XXICC, see XXICC: 21st Century Co-design.  For details on the GalaxC programming language, XXICC Object Editor, and GalaxC extensions for Hardware Design (GCHD), here are the latest documents and source code:


Release notes for XXICC rev 0.0r

Programming in the GalaxC Language rev 0.0r: reference and user guide for the GalaxC programming language.

The XXICC Anthology rev 0.0r : collection of miscellaneous XXICC topics, including user guides for the XXICC Object Editor, GCHD, Flavia, and IceStorm.

XXICC code release 0.0r : source code for XXICC.

XXICC source code listing rev 0.0r: source code listing as PDF.

XXICC executable binary for Windows rev 0.0r : XXICC executable binary for Microsoft Windows.

GalaxC sample/demo programs rev 0.0r: sample GalaxC programs and GCHD logic libraries.

GalaxC sample/demo program listings rev 0.0r: PDF listing of the sample GalaxC programs and GCHD examples.

Installing and Running XXICC rev 0.0q: Document describing how to install and run XXICC, unchanged for 0.0r.

Compiling and Running GalaxC Programs rev 0.0k: Document describing how to compile and run your own GalaxC programs, unchanged for 0.0r.

Editable XXICC documentation files rev 0.0r: editable XOE files for XXICC documentation.

GCHD examples for IceStorm rev 0.0r: these are for generating Lattice iCE40 FPGAs using IceStorm, using either a Lattice iCEstick or Nandland Go Board as the target.

Data files for FlaviaP40 release 0.0r for Papilio One 250K: Data files for the FlaviaP40 implementation of the Free Logic Array.

Data files for FlaviaP60 release 0.0r for Papilio One 500K: Data files for the FlaviaP60 implementation of the Free Logic Array.

Data files for FlaviaPD59 release 0.0r: Data files for the FlaviaPD59 implementation of the Free Logic Array for Papilio DUO.

Data files for FlaviaLP60 release 0.0r for LOGI-Pi: Data files for the FlaviaLP60 implementation of the Free Logic Array for the ValentF(x) LOGI-Pi.

Data files for FlaviaLB60 release 0.0r for LOGI-Bone: Data files for the FlaviaLB60 implementation of the Free Logic Array for the ValentF(x) LOGI-Bone.

Taming the Wild Bitstream (unchanged for 0.0r): Supplement to Flavia: the Free Logic Array.


I've tested XXICC 0.0r on GNU/Linux (Ubuntu on x86 PCs and ODROID-C1 Ubuntu).  I haven't tested it yet on Raspberry Pi Raspbian or BeagleBone Debian.  I tested it on Windows 2000 and 7.  My main machine is Ubuntu, so the others are more likely to have anomalies.  Constructive comments and suggestions are most welcome.  I'd especially like to find out how to reproduce some of the bugs that have been eluding me.


The previous version of XXICC is: XXICC (21st Century Co-design) release 0.0q

The earliest versions of XXICC are at Google Code:


XXICC is a FLOSS (Free as in Liberty Open Source Software) project.  Software is licensed under GPLv3 and other content is licensed under Creative Commons CC-BY-SA 3.0.

Ive been recently using an M74HC590 binary counter to capture some data from an opto-encoder and thought that since I'd modelled a basic binary counter into the FPGA, why don't I go the whole hog and model this real world component into it too and make a final blog post in this series.


Here's the front page and the pinout  in the datasheet for the M74HC590 that I'll be modelling:












So we know what the inputs and outputs are of the device are but what about the way it functions internally? Well I looked through the datasheet and found a truth table that I could work things out from.





Using this data, I made up the following Verilog file:













As you can see Ive copied the pin labels etc.. and used nested if's to do most of the logic.



























Once were happy with the Verilog file, we generate the board symbol shown here. Theres the corresponding input pins and the output pins QA throught to QG are shown as a single wire representing the 8bit output bus.






In the following schematic, Ive added the symbol for the Verilog file and made some connections to it:






The CCKEN and G pins have been connected to an internal Ground and CCLR has been connecting to an internal voltage source (VCC). These could have been broken out to real pins on the DE0-NANO P0082 board and connected manually but I did it this way for simplicity.


The RCK and CCK pins have both been connected to a push button on the development board.


The QA - QG outputs have all been connected to the LED's on the development board and the RCO pin has been left unconnected for the time being. This output would be connected to another 8-bit counter if they were being cascaded into a 16-bit counter.




From here it was just a case of assigning the LED's and pushbutton to the correct pins and the device is ready to test. The video at the bottom of this shows the final programmed development board. Because the CCK and RCK pins were attached to a push button, simply pressing that button causes the device to count up press by press.


Heres the compiler summary for the above component, very few of the actual resources were used (in most cases less than 1%):





Hopefully this gives an insight into how fpga's can be utilised by modelling existing components that we already know, this is the final blog post in this mini-series but I will be posting occasional updates of my progress on an rgb led matrix driver that Im working towards with the DE0-NANO. I intend to cheat a little bit to start with and initialise some registers with a test pattern while I work out how to drive the signal properly. Once that's done I can work backwards into a more complex design.






So far the DE0-NANO P0082 development board and the associated user guides have given me a basic overview on how to develop with FPGA's and introduced me to a simple Verilog HDL file. To move forwards in FPGA development I would need to learn more about Verilog HDL and while Terasic have done a great job creating resources that teaches the basics of development I wouldn't expect them to provide me with a full Verilog HDL learning resource and so I looked elsewhere.


The first resource I found on Google was at and so I spent some time looking through their tutorials and examples, as with most new things I'm learning I find it useful to learn the basics and take a few days break. When I come back to the subject I find myself more able to understand what I'd learn previously and also learn more as I go.


After having a few days break, I decided to alter the files for the bitstream I made in Part 3 of this blog series. My intention was to create an 8-bit counter that displays on the LED's and the ability to change the direction of counting when one of the user buttons are pressed. Here is my new board layout :




In the board layout you can see I kept the pll to provide the clock source, the simple_counter module now has an additional button input and Ive removed the multiplexer, choosing to output 8 bits from the counter bus straight to LED's.


Before we look at the Verilog file for the simple_counter component lets investigate that counter bus a little bit more in depth. The counter bus is a single trace here but its representing a 32 bit bus with 32 wires, so here we've connected wires 18,19,20,21,22,23,24 and 25 to LED's and left the others disconnected. Its possible to connect a consistent range of 8 wires from anywhere in this bus and the LED's will still show an 8 bit counter.


Whats really going on is that simple_counter actually outputs as a 32-bit counter on that bus and were selecting a range, if we select a range of 0,1,2,3,4,5,6 and 7 the counter will be running so fast as thats where the least significant bits are that we won't see the LED's change (they'll just appear constantly on) and if we select the range 24,25,26,27,28,29,30 and 31 the LED's will count too slowly this is because as we move up the range the speed of the bits changing becomes less frequent.


It's entirely possible to just get the simple_counter component to output an 8-bit bus rather than a 32-bit one and alter the pll to change its counting speed to one that would be more suitable but I just left this one in for well, who knows why I left it in, it was just there already I suppose!


Right lets look at the new Verlog HDL file:




I added an extra button input and a new register component. Registers are similar to variables only you declare the size in bits you would like that register to be. So reg [31:0] is like a 32 bit variable and reg[0:0] is a single bit which Im using here like a Boolean to keep track of the direction.


You'll notice a new section titled "initial begin" this is a place you can initialise the values of the registers at the beginning of the bitstream launching/simulating.


Notice that there's 2 "always" blocks. These are functions that run automatically when their conditions are met. so the statements in the "always @ (posedge BUTTON_1)" block between "begin" and "end" will run automatically whenever a new positive edge is detected on the button (ie. whenever the button is pressed or goes high).


Multiple "always" statements are allowed in a component and can all run simultaneously.


and thats it for today, see the video below to see this in action



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.

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

Filter Blog

By date: By tag: