Sunday, 29 September 2019

More counters with ULX3S and using modules, simulators etc...

Last post covered creating a one second counter in verilog and making an LED flash. In this post I wanted to cover how to make multiple counters. I mentioned in the previous post that multiple counters can be made without a degradation in speed or efficiency and they can be totally independent of each other - bold claims...lets see it done!

Lets make a counter module but unlike before lets make it standalone code that can be used and modified without affecting the inputs and outputs - that way when we need a counter we can just re-use the counter module code and not have to re-write it every time...unless we have a specific requirement to do so.

Here is a simple diagram of what I hope to achieve:


We will have four LEDS changing state depending on the counter output. The clock is our input and the LEDS are the outputs. The part we need to write is the counter module, before we do that though lets think about what we would want in a counter - Lets discuss counter requirements:

Range of the counter - How big a value will we need to count to before we need the count to reset and start again.

Resolution of the counter - What units do we want to count in: Units, Tens, Hundreds, Thousands, Binary???

Count direction - Do we want to count up from a value or count down from a value?

Load - Do we want to be able to start counting from a value other than zero??

Reset - Do we want to be able to reset the count at any time?

Overflow - Do we want to be able to detect if the count reached the maximum value and then started again?

What we are describing here is the behaviour of the counter. This is one way of coding in a hardware description language - The other method is known as structural where the structure of the logic gates needed to realise the function is described.

Before the advent of microcontrollers and FPGA there was (and still is) a very popular integrated circuit that I used called the 74LS163. It was a four bit binary counter with a ripple carry output. That means it could count from zero to fifteen in binary when a positive edged pulse was detected at the CLK pin. Each time an edge is detected the count increased by 1. When the count reached 16 an output was set known as the ripple carry output or RCO. This allowed a designer to cascade the devices together to make a 32 bit counter or a 48 bit counter, or even a 64 bit counter. I'm going to write some verilog code which reproduces the behaviour of the 74LS163 just as an exercise.
The datasheet for a 74LS163 is here just in case people are interested:

74LS163 Datasheet

The inputs for a 74LS163 are:

Here is the verilog code to describe the 74LS163:

// 74LS163 Binary counter module

binary_counter(input a, b, c, d, enp, ent, load, clear, clk,

output qa, qb, qc, qd, rco );

always @(posedge clk)

	begin//start the count on the rising clock edge

	if (!clear)

		begin

			{qd, qc, qb, qa} <=4'b0; //if clear is low, set the count outputs to 0

		end

	if (clear &&!load)

		begin //if load is set low, set count output to match the input

			{qd, qc, qb, qa} <= {d,c,b,a};

		end

	if (clear && load && enp && ent)

		begin//if clear, load, ent and enp are set high, increment the count by one

		{qd, qc, qb, qa} <= {qd, qc, qb, qa} +1;

		end

	end

assign rco = ent ? qa && qb && qc && qd :0; // if the count has reached 15 and ent set high set rco high

endmodule

Lets explain the code:

We have made a module called binary_counter. It has inputs called a, b, c, d, enp, ent, load, clear and clk. It also has outputs called qa, qb, qc, qd and rco. The module section details the inputs and the outputs of the module and their types.

The next section always @(posedge clk) is similar to the main loop in a high level language. This is the description of the circuit that will be free running forever:

When a positive clock edge is detected on the clk input the follwing checks are performed:

Is the clear low? If it is low then set all the outputs to zero.

Is the clear high and the load low? If this is true then set the outputs qa, qb qc and qd to match the inputs a, b, c, d.

Is the clear high, load high enp high and ent high? If this is true then add one to the count value of bits on the outputs qa, qb, qc and qd.

Has the count reached 15 and has there been another clock edge? If this is true set the outputs to zero and set rco high.

If we were to flash this code to the ulx3s it would work...there is a little more code to write before we could use it. It isn't particularly practical though...If we needed a 4 bit binary counter we could just buy one and use it....not recreate it in FPGA fabric...that would be a bit of a waste of resources. The reason I've mentioned it is I want to illustrate the method of describing what is required.

I have found two methods for writing verilog code. The first method is to calculate the logic function required, then draw a diagram of it (structural implementation) and then write verilog code.

The other way is to draw a diagram which describes the behaviour of what is required and then write verilog code. Either method can be applied...I find the latter behavioural method easier.

Going back to our requirements:

Range of the counter - How big a value will we need to count to before we need the count to reset and start again.

It actually doesn't matter. We can decide when to start, stop and reset the count!

Resolution of the counter - What units do we want to count in: Units, Tens, Hundreds, Thousands, Binary???

Again, it doesn't matter. We can decide what increments we use!

Count direction - Do we want to count up from a value or count down from a value?

This time it matters, we can write code which describes both behaviours but we will need an input to set the count direction.

Load - Do we want to be able to start counting from a value other than zero??

This function was useful when using discrete devices with fixed range and resolution. We don't need this anymore as we can have any range and resolution we like.

Reset - Do we want to be able to reset the count at any time?

Yes! We will need an input to be able to start the counter from zero.

Overflow - Do we want to be able to detect if the count reached the maximum value and then started again?

This function was useful when using discrete devices with fixed range and resolution. We don't need this anymore as we can have any range and resolution we like.

Here is a diagram of what our counter would look like:
From this we can write the module statement for our counter:

module up_down_counter(
    input clk,                      // 25 MHz clock input from the top module
	input reset,			  	    // reset input from the top module
	input up_down,				    // count up or down from the top module
    output [24:0] count_output         	// counter output to be passed to top module
);

Next we need an internal signal to act as a register which stores the result of the count process depending on whether the count is up or down, whether the reset is active (high) or a clock edge has been detected...

reg [24:0] count = 0;

Now we need to write the code that describes the actual counting process:

begin
	if(reset)
		count <= 0;
	else if(~up_down)
		count <= count + 1;
	else
		count <= count - 1;
end     

assign count_output = count;

endmodule

Here is the entire code for the module just in case it is needed:

module up_down_counter(
    input clk,                      // 25 MHz clock input from the top module
	input reset,			  	    // reset input from the top module
	input up_down,				    // count up or down from the top module
    output [24:0] count_output         	// counter output to be passed to top module
);
    reg [24:0] count = 0;         // Register for the counter
	
always @(posedge clk or posedge reset)
begin
	if(reset)
		count <= 0;
	else if(~up_down)
		count <= count + 1;
	else
		count <= count - 1;
end     

assign count_output = count;

endmodule

So we have written a module which will count up or down to any value in unit increments...Copy and paste the code into a text file and call it up_down_counter.v

I used this folder:

C:\msys64\src\Alex\ulx3s\Multiple Counters

Now we need to write some code that calls our new counter module and supply the modules with the inputs needed and then couple the outputs to something we can physically see...LEDS!
Before we do that though we should really update our original diagram to reflect the module code we have written because it will help us write our top module.

The up_down counter module looks like this in diagram form:


Now we are going to use this information to update the top level diagram to implement some verilog code which flashes the LEDS at different rates. Here is the diagram:
From the diagram we can now work out what our top module inputs will be:

Clock, Reset, Up / Down

The outputs are LED 0, LED 1, LED 2 and LED 3

From here we are going to write the top.v code which will call the counter module we wrote earlier and attach the inputs and outputs. Before we do that though it is a good idea to simulate the module code to make sure it works as intended.

There are many simulation programs available for verilog. I decided to use the iverilog program which is well documented. The software is written and maintained by Stephen Williams and it is released under the GNU GPL license. I should also mention that I'm using the Windows 10 operating system...

I downloaded it from here: http://bleyer.org/icarus/

I then followed the instructions and read up some tutorials on how to use it. It wasn't too complicated!

I used the instructions from here:

https://www.swarthmore.edu/NatSci/mzucker1/e15_f2014/iverilog.html

Make sure that iverilog is added to your path in Windows! Now we need to write some code which tests the module.

This is known as a test bench and it is some more verilog code:

// Testbench Verilog code for up-down counter
//`timescale 1ns/100ps

`include "up_down_counter.v"  //include the file which contains the module to be tested

// create a test bench module with the inputs and the output(s)
module up_down_counter_testbench(); 
reg clk, reset,up_down;
wire [24:0] count_output;

// instantiate the module to be tested with inputs and output(s)
up_down_counter counter_one
(clk, reset, up_down, count_output);

// tell the simulator what we want the simulation file to be called
// and to get data for all variables
initial begin

	$dumpfile("test.vcd");
	$dumpvars;	
	
end

// monitor the variables so we can see some text output from the simulation
  initial
     $monitor("At time %t, count_output = %h (%0d)",
              $time, count_output, count_output);

// create a clock running for 10 seconds high and 10 seconds low
initial begin 
	clk=0;
	forever #10 clk=~clk;	
end

//exercise the inputs at suitable points in time and finish the simulation

initial begin
	reset=1;
	up_down=0;
	#20;
	reset=0;
	#120;
	up_down=1;
	#500
		
	$finish;
end

endmodule

Create a text file called up_down_counter_tb.v and paste the above code into it. Save the file in the same directory as the other verilog code already written...I used:

C:\msys64\src\Alex\ulx3s\Multiple Counters

The comments for the code should be fairly self explanatory. Now it is time to run the simulation:

Open a command prompt window and navigate to the folder:



Next type the following command:

iverilog -o up_down_counter_tb.vvp up_down_counter_tb.v

The command creates an iverilog simulation file with a vvp extension from our test bench code.
Next type the command:

vvp up_down_counter_tb.vvp

You should see the following output:


A file test.vcd has been created and we can now use this to look at the results of the simulation using a piece of software called GTKWave...

Type the following command:

gtkwave test.vcd

The GTKWave program should load:


Click on the module in the SST box in the top left corner to add the signals:


Double click on each signal to display it's simulated waveform:
Click on the magnifying glass icons to expand the traces to see the output!


Our code works! We can see that while the reset is high no counting occurs. When the reset is low and up_down is low the count increases, when up_down is high the count reduces...

Simulation is a very useful tool to check that the code we have written works as intended...Lets get on with writing the top module code to complete what we set out to do in the first place. It will be quite similar to the test bench code already written.

Create a text file called top.v and save it in the same folder as the other files:

C:\msys64\src\Alex\ulx3s\Multiple Counters

Here comes the code:

module top(
    input clk_25mhz,                // 25 MHz clock input
	output [3:0] led, 				// 4 Bit LED Output register
    output wifi_gpio0			    // Output for Wifi enable	
);
  
  //internal signals
  
  reg [24:0] counter_one_output;    	// Register for the first counter output
  reg reset_counter_one;				// Register for the reset on the first counter
  reg up_down_counter_one=0;			// Register for the up_down on the first counter
  
  reg [24:0] counter_two_output;    	// Register for the second counter output
  reg reset_counter_two;				// Register for the reset on the second counter
  reg up_down_counter_two=0;			// Register for the up_down on the second counter
  
  reg [24:0] counter_three_output;    	// Register for the third counter output
  reg reset_counter_three;				// Register for the reset on the third counter
  reg up_down_counter_three=0;			// Register for the up_down on the third counter
  
  reg [24:0] counter_four_output;    	// Register for the fourth counter output
  reg reset_counter_four;				// Register for the reset on the fourth counter
  reg up_down_counter_four=0;			// Register for the up_down on the fourth counter 

//first counter module instantiation

up_down_counter one_sec_counter(
	.clk(clk_25mhz),
	.reset(reset_counter_one),
	.up_down(up_down_counter_one),
	.count_output(counter_one_output)
);

//second counter module instantiation

up_down_counter half_sec_counter(
	.clk(clk_25mhz),
	.reset(reset_counter_two),
	.up_down(up_down_counter_two),
	.count_output(counter_two_output)
);

//third counter module instantiation

up_down_counter quarter_sec_counter(
	.clk(clk_25mhz),
	.reset(reset_counter_three),
	.up_down(up_down_counter_three),
	.count_output(counter_three_output)
);

//fourth counter module instantiation

up_down_counter eighth_sec_counter(
	.clk(clk_25mhz),
	.reset(reset_counter_four),
	.up_down(up_down_counter_four),
	.count_output(counter_four_output)
);

// initial settings
// resets all high to start counts at same time
// up_down all low to ensure we count up not down

initial begin

reset_counter_one = 1;
reset_counter_two = 1;
reset_counter_three = 1;
reset_counter_four = 1;

up_down_counter_one = 0;
up_down_counter_two = 0;
up_down_counter_three = 0;
up_down_counter_four = 0;

end

always @(posedge clk_25mhz) // react on the positive clock edge

begin
	
	//counter one set to count for one second 
	
	if (counter_one_output == 25000000)    // If the count register has reached 25 million 
                begin
                    led[0] <= ~led[0];      // toggle the LED[0] 
					reset_counter_one = 1;	// set counter one back to zero	
	            end
				
	else reset_counter_one = 0;				// allow counter one to continue
	
	//counter two set to count for 0.5 seconds 
	
	if (counter_two_output == 12500000)    // If the count register has reached 12.5 million 
                begin
                    led[1] <= ~led[1];      // toggle the LED[1] 
					reset_counter_two = 1;	// set counter two back to zero	
	            end
	
	else reset_counter_two = 0;				// allow counter two to continue	
	
	//counter three set to count for 0.25 seconds
	
	if (counter_three_output == 6250000)    // If the count register has reached 6.25 million 
                begin
                    led[2] <= ~led[2];        // toggle the LED[2] 
					reset_counter_three = 1;  // set counter three back to zero		
	            end
	
	else reset_counter_three = 0;			// allow counter three to continue
	
	
	//counter four set to count for 0.125 seconds			
				
	if (counter_four_output == 3125000)    // If the count register has reached 3.125 million 
				begin
                    led[3] <= ~led[3];      // toggle the LED[0] 
					reset_counter_four = 1;	// set counter four back to zero	
	            end
	
	else reset_counter_four = 0;			// allow counter four to continue
	
end

assign wifi_gpio0 = 1'b1; //set the wifi_gpio High
	
endmodule

Copy and paste the above code into top.v and save it in the same directory as before.
Hopefully the code is fairly easy to understand...Here are the critical sections:

module top(

 input clk_25mhz, // 25 MHz clock input
 output [3:0] led, // 4 Bit LED Output register
 output wifi_gpio0// Output for Wifi enable

);

The first part is the module statement with the inputs and the outputs - this module is called top because it is the top module and it has a clock input, an eight bit register called led and a single bit output for the wifi enable.

 //internal signals

 reg [24:0] counter_one_output; // Register for the first counter output

 reg reset_counter_one; // Register for the reset on the first counter

 reg up_down_counter_one=0; // Register for the up_down on the first counter

The above section details the internal signals that are needed to be passed to and from the up_down counter
module:

A 24 bit counter register is needed to take and store the output from the up_down counter module

A reset register is needed to set the reset input inside the up_down counter module

An up_down_counter register is needed to set the up_down input inside the up_down counter module

This is repeated four times as there are four counter modules instantiated. The code for instantiating the module is below:

up_down_counter one_sec_counter(
.clk(clk_25mhz),
.reset(reset_counter_one),
.up_down(up_down_counter_one),
.count_output(counter_one_output)
);

The above code works like this:

Make a counter from the code already written in up_down_counter.v - call it one_sec_counter

connect the clk input inside up_down_counter.v to clk_25mhz (the main clock source on the board)

connect the reset input inside up_down_counter.v to the internal register reset_counter_one

connect the up_down input inside up_down_counter.v to the internal register up_down_counter_one

connect the count_output output inside up_down_counter to the internal register counter_one_output

Because we want the reset and up_down inputs to react at the same time we set them initially:

initial BEGIN reset_counter_one = 1; reset_counter_two = 1; reset_counter_three = 1; reset_counter_four = 1; up_down_counter_one = 0; up_down_counter_two = 0; up_down_counter_three = 0; up_down_counter_four = 0; END

Finally we have the code which makes the FPGA react when the counters have reached a defined count:

always @(posedge clk_25mhz) // react on the positive clock edge

begin

//counter one set to count for one second

if (counter_one_output == 25000000) // If the count register has reached 25 million

 begin

 led[0] <= ~led[0]; // toggle the LED[0]

 reset_counter_one = 1; // set counter one back to zero

 end

else reset_counter_one = 0; // allow counter one to continue

When counter one has reached twenty-five million (one second) toggle led[0] to its alternative state, reset the count

If counter one hasn't reached twenty-five million don't reset the count...
Why twenty-five million? Well....25 MHz is the external clock frequency...that means the external clock oscillates twenty-five million times per second so if we want a count every second we need to count twenty-five million clock edges...

Lets upload the code to the board -  fire up ConEmu.exe (Windows) and navigate to the folder:

C:\msys64\src\Alex\ulx3s\Multiple Counters

Remember that the board I'm working with has an ECP5 45F Lattice Semiconductor FPGA so the commands are tailored to it. If you are working with a ECP5 12F board or an ECP5 85F board you will need to change to commands appropriately:

Type the following command into the console:

apio build --board ulx3s-45f


Ignore the warnings ;)

Make sure you have the ULX3S development board connected via USB!

Now lets upload the bitstream to the ULX3S development board:

apio upload --board ulx3s-45f


Finally clean up the directory:

apio clean


If all went according to plan you should see the leds on the ULX3S board flashing!


Well...that was a lot of work! Apologies for the really long post. There was a lot to get through! Next post will be something simple and more fun hopefully!

Cheers for now - Langster!

Sunday, 8 September 2019

Counters in Verilog with the ULX3S

It's time for another learning experience with the ULX3S.  When using FPGAS or Microcontrollers in general it's very useful to generate and use counters.  Counters as their name suggest are ways time can be added to logic circuits.  If you wanted an LED to flash once a second use a counter.  If you want several LEDS to flash at different rates independently use several counters...If you want to ensure an event occurs at a specific point in time...use a counter.

Counters in FPGA are particularly cool as you can have as many of them as you like or need, unlike microcontrollers.  The other thing is that the counters are all independent of each other in an FPGA.  So multiple counters can be used to control things without affecting the operating of anything else...that's very hard to achieve with a microcontroller...the program flow is always linear.

Lets make a counter flash an LED once a second. In order to do that we need to know a couple of things:

What is the clock speed of the oscillator used on the ULX3S development board?
What is the control logic for the LEDS (active high or active low)?

We can find these answers either from the schematic of the ULX3S or from the constraints file.  Both of which are helpfully available here:

https://github.com/emard/ulx3s

https://github.com/emard/ulx3s-examples/blob/master/README.md

The schematic is broken down into several pages and was created in KiCad.  There is also a PDF version here:

https://github.com/emard/ulx3s/blob/master/doc/schematics.pdf

We are interested in page 4 called 'Blinkey' and page 6 called 'USB'.  Blinkey shows the eight LEDS referenced from zero to seven in the centre of the page four in cell B,3.  The LEDS are common ground connected which means they are 'active high' - A control signal from 'Bank 7' the FPGA needs to be high in order to get an LED to turn on.  The current limiting resistors used are 549 ohms so with 3.3 Vdc logic the current flowing through each LED when on will be 6 mA - bright enough! I've used FPGA development boards in the past where the IO was active low so its useful information to know.


The oscillator is in cell A, 3 on the top middle of the page and it is referenced as being 25 MHz - also useful to know.  It is of course possible to use phase lock loops to generate faster clock signals if that is what is required.


The User Constraints File or UCF as it is sometimes referred to is a list of information which tells the software which pins on the FPGA are connected to what and more usefully how they are referred to.  We could write our own UCF file if we wanted to and for complicated designs or if we had created our own circuit with an FPGA we would have to write our own. Helpfully the board designer of the ulx3s (EMARD) has written one for us. When we come to write the verilog code we can use the same naming convention and that way we don't have to write our own UCF file.

The sections we are interested in are:

# The clock "usb" and "gpdi" sheet
LOCATE COMP "clk_25mhz" SITE "G2";
IOBUF  PORT "clk_25mhz" PULLMODE=NONE IO_TYPE=LVCMOS33;
FREQUENCY PORT "clk_25mhz" 25 MHZ;

and

## LED indicators "blinkey" and "gpio" sheet
LOCATE COMP "led[7]" SITE "H3";
LOCATE COMP "led[6]" SITE "E1";
LOCATE COMP "led[5]" SITE "E2";
LOCATE COMP "led[4]" SITE "D1";
LOCATE COMP "led[3]" SITE "D2";
LOCATE COMP "led[2]" SITE "C1";
LOCATE COMP "led[1]" SITE "C2";
LOCATE COMP "led[0]" SITE "B2";
IOBUF  PORT "led[0]" PULLMODE=NONE IO_TYPE=LVCMOS33 DRIVE=4;
IOBUF  PORT "led[1]" PULLMODE=NONE IO_TYPE=LVCMOS33 DRIVE=4;
IOBUF  PORT "led[2]" PULLMODE=NONE IO_TYPE=LVCMOS33 DRIVE=4;
IOBUF  PORT "led[3]" PULLMODE=NONE IO_TYPE=LVCMOS33 DRIVE=4;
IOBUF  PORT "led[4]" PULLMODE=NONE IO_TYPE=LVCMOS33 DRIVE=4;
IOBUF  PORT "led[5]" PULLMODE=NONE IO_TYPE=LVCMOS33 DRIVE=4;
IOBUF  PORT "led[6]" PULLMODE=NONE IO_TYPE=LVCMOS33 DRIVE=4;
IOBUF  PORT "led[7]" PULLMODE=NONE IO_TYPE=LVCMOS33 DRIVE=4;

Just for reference a hash ( '#' ) symbol before a line means that the text after that is a comment

LOCATE COMP means to locate the drive logic to a particular section within the FPGA fabric.
IOBUF  PORT means the line is to be configured as a buffered input or output..
PULLMODE=NONE means the line will not have an internal pull up or pull down resistor enabled.
IO_TYPE=LVCMOS33 means the line will be configured to be low voltage CMOS at 3.3 Vdc.
DRIVE=4 means the line will be able to source 16 mA of current.  Drive 1 = 4 mA, Drive 2 = 8 mA, Drive 3 = 12 mA and finally drive 4 - 16 mA

When we write the verilog code we need to refer to the clock as clk_25mhz and the individual leds as led[0]

I was really hoping to use a program called IceStudio to program the ulx3s as it is essentially a graphical front end for apio which collates the usage of Yosys, Ptrellis and NextPNR.  Unfortunately the developers of IceStudio do not wish to add the ulx3s to the list of supported development boards.  They have their reasons for doing that.  I suspect it would be possible to fork IceStudio to work with ULX3S but I'm not going to do that as:
  1. I don't have the skill!
  2. I don't have the time to learn the skill!
  3. I don't want to annoy the IceStudio developers because they are nice guys and have worked hard.
I can use the program to demonstrate what we are going to do though...very useful. I find graphical information easier to pick up over seeing lines of HDL Syntax.



The diagram is meant to show that we have one input called clk_25mhz, we have two outputs called LED and wifi_gpio.

The blue box labelled PrescalerN is some pre-written code which basically is a verilog counter module.  It will take the clock input, count how many clock pulses there are and when it has reached 25 000 000 counts it will send a signal to the LED output.  The wifi_gpio output will be set high.

In verilog code this looks like this:

module top (
    input clk_25mhz,            // 25 MHz clock input 
    output reg led [7:0] = 1'b0,   // 8 Bit LED Output register, set LED[0] to be in a predefined state
    output wifi_gpio0     // Output for Wifi enable 
);
    reg [24:0] count = 0;          // Register for the counter
 
    always @(posedge clk_25mhz)    // Interrupt at the positive 25 MHz clock edge
    begin
       if (count == 25000000)    // If the count register has reached 25 million
                begin
                    led0 <= ~led0; // toggle the LED[0] On and OFF with a one second interval.
                    count <= 1'b0; // and reset the count to 1 (binary) 
                end
            else                   // else
                begin    
                    count <= count + 1'd1; // increment the count by 1
                end
    end

    assign wifi_gpio0 = 1'b1; //set the wifi_gpio High

endmodule

The code should be fairly easy to follow. The wifi_gpio input is only needed if your board has an ESP32. The command enables the ESP32 so code can be pushed over wifi. I haven't been doing that at the moment although I should! I'm fairly certain the code will work, I would like to have tested it and in later posts I will be looking into open source verification software like verilator and GTKwave. These programs allow one to simulate verilog code and show how the inputs and outputs will respond.

Lets save the text file (call it top.v) somewhere sensible I chose: C:\msys64\src\Alex\ulx3s\One Second Counter

 Next copy in the constraints file and apio.ini and fire up ConEmu.exe (Windows) and navigate to the folder we just made. It's also at this point that I should state that the board I'm working with has an ECP5 Lattice Semiconductor FPGA so the commands are tailored to it. If you are working with a ECP 12F board or an ECP 85F board you will need to change to commands appropriately.

 

Type the following command to turn the verilog code in top.v into the bit file ready for uploading to
the ulx3s development board: 

apio build --board ulx3s-45f 

The output should look like this:
 
Ignore the warnings... Plug in the ulx3s into your computer using a microUSB cable - exciting times! 

Next lets upload to the ulx3s development board: 

apio upload --board ulx3s-45f 

The output should look like this:
 

Finally its good practice to remove unnecessary files from the build process: 

 apio clean 

 As everything worked you should be able to see an LED flash like in the video below: 


Again not the most exciting thing in the world but it is the hello world of FPGAS and from a tiny acorn an mighty oak tree grows ;) 

That is all for now - Langster!

Thursday, 5 September 2019

ULX3S Open Source FPGA Development Board

I have made no secret of the fact that I am interested in FPGA technology and have been trying to relearn VHDL for some time.  I am also very keen on using open source programs and development tools.

Recently (sometime in the last couple of years) I heard about project IceStorm by Clifford Wolfe.  Mr Wolfe has reverse engineered Lattice Semiconductor's bit-stream files and written a software tool called Yosys which is used to convert verilog files into mapping files which can then be loaded onto a lattice semi-conductor FPGA.  At the moment proprietary FPGA development tools are very large pieces of software which take a lot of space on a hard disk, are feature heavy and not free to use (require licence files), often unsupported (Xilinx WEBise anyone) and I found difficult to use.  I'm not saying they aren't good but if I can use open source software tools I will...I like the idea behind the licensing models.  I'll donate what I can afford and assist wherever I can.

The Yosys Website is here: http://www.clifford.at/yosys/

Project ICE Storm: http://www.clifford.at/icestorm/

Until recently I didn't have a Lattice Semiconductor FPGA development board but that changed when I was offered a ULX3S open source board from the very clever guys at the Radiona Hackspace.  I had come into contact with these gentlemen when I was trying to learn to use the Elbert V2 and Mimas V2 Xilinx based FPGA development boards.  They developed a very cool piece of kit to make use of the open source tools for teaching a Digital Logic course at their local university.

The ULX3S with 3D printed case and buttons!
The board arrived in very good order with a 3D printed case, buttons and some pre-built examples.  I had a quick play with it and intended to write up my experiences and get started on using it.  That was probably this time last year...I am attempting to get back into blogging my experiences, trials and tribulations outside of work as I find it quite useful and I find it forces me to improve on my electronics and development skills.  Anyway...back to the board:

The board is in my opinion, very well designed and implemented.  I particularly like the addition of the ESP32 so files can be uploaded over wifi.

Here are some photos of the board:

The top side of the PCB with buttons, microSD card and display
The underside of the PCB with the ESP32 module
Here is the website for the project: https://radiona.org/ulx3s/

Here is a Hackaday write up: https://hackaday.com/2019/01/14/ulx3s-an-open-source-lattice-ecp5-fpga-pcb/#more-340565

I'll be honest, I bought the board to support the project, I haven't got a project or use in mind.  To be even more honest I still want to re-learn a hardware description language so that when I do have a project in mind I'll be able to make use of the technology.  I do have ideas for a piece of instrumentation but that is a way off and requires a lot more than just the FPGA!

The first thing I did with the board was use it to emulate an Amiga 500 computer using the pre-loaded Minimig project which came ready to play on the board.  All I had to do was grab some amiga disk images and I could play all the games from my misspent youth.  Retro gaming with FPGA devices is a very popular hobby as the hardware is not being emulated but actually realised within the fabric of the device which leads to a more realistic experience.

Playing Lotus Turbo Challenge 2 and Utopia are fun diversions but not quite what I had in mind for the device.

The open source tools all appear to be for linux operating systems only at the moment so I installed Linux Mint on my main PC and got to work installing all of the pieces of software needed from project Ice storm.  

My LinuxFu is not that strong so I may have messed this up somewhere along the way.  I know I have downloaded, and compiled the following pieces of software:

IceStudio
prjtrellis
Yosys
nextPNR

I was then pointed towards the apio project by a colleague and downloaded the windows version of that software along with all the other bits and pieces needed by following the instructions here:

https://github.com/ulx3s/fpga-odysseus

It installed fine although I would ensure that if following the instructions that you don't upgrade the apio software.

Once presented with the command prompt by loading the ConEmu.exe program it is pretty easy to get started:


This screen brought my back to my days of the DOS prompt.  I know the linux command prompt is fairly similar but I just don't use linux enough to be comfortable with it...I am slowly improving though...

I made a folder called Alex and then a sub folder called ulx3s, you could use any folder names you like.  I then copied two files into the folder:

apio.ini - found from the folder C:\msys64\src\fpga-odysseus\tutorials\01-Basics\01-LED
ulx3s_v20.lpf - found from the folder C:\msys64\src\fpga-odysseus\tutorials\01-Basics\01-LED

The apio.ini file is a text file that tells the apio software everything needed to prepare files for upload to the ulx3s board and ulx3s_v20.lpf is the constraints file for the board, it tells apio and all of the other software which pins are connected to what and where between the FPGA and the external peripherals.

I next created a simple text file in notepad++ - you could use any text editor to be honest.  I called it top.v and typed out the following simple program:

//Hello world LED program

//create a module called top
module top (
    output [7:0] led, //create an output vector called 'led' with 8 bits
    output wifi_gpio0 //create an output for the wifi gpio
);
    assign led = 8'b10101010; //set the state of the bits in the vector to the number 170
 // this sets the bits on and off alternately

    assign wifi_gpio0 = 1'b1; // set the wifi gpio wifi high 
endmodule //end the module

Save the file in the directory made previously:

C:\msys64\src\Alex\ulx3s

Next jump to the ConEmu command prompt and make sure all of the files we need are there by typing ls and hit enter :


next type the following: apio build --board ulx3s-45f'

You should see the following displayed, ignore the warning messages:


  The following files will have been created in the directory:

Exciting times....now it is time to upload the program to the FPGA.  Make sure the ULX3S board is plugged into a suitable USB port and powered up.

Type the following command:

apio upload --board ulx3s-45f

If all goes according to plan you should see the following:


Next type the following:

apio clean

This removes all of the unnecessary files created during the processes.  Finally its time to admire your work.  If everything went according to plan you should see the following LED pattern on your ULX3S!


Ok so its nothing special but it's a start. I'm hoping soon to do a bit more with it.  I hear good things about something called ICE Studio:

https://icestudio.io/

It doesn't have support for the ulx3s yet but I'm hopeful it can be added soon!

That's all for now - Langster!