Goodbye FPGA

Intro

Back in 2019 I started some very interesting and fruitful involvement with FPGAs (Field Programmable Gate Arrays).  They require a significant investment in education and time to master and I haven't done anything with them in the last five years.  Although I have some good development boards, I would need to spend a lot of time updating the complex tools as part of any further work.  With some regret I am now disposing of my FPGA development boards via Ebay which I hope will provide them with good homes.

This post summarises the good times (which were previously blogged) during which I enjoyed some small successes with the boards.

MAX1000

Elektor magazine provided a simplified introduction to FPGA programming using the Arrow MAX1000 development board.  The board only had a button and eight LEDs to control but I was introduced to Altera Quartus Software and the NIOSII microcontroller which is implemented in the MAX1000.  This was a brilliant way of demystifying the intimidating reputation of FPGAs.

Cyclone IV

I needed more power and extra peripherals for interesting FPGA projects so I purchased a Cyclone IV FPGA development board.  I used this and MAX1000 for testing a simulated 8080 processor, testing UARTs and discovering features of the NIOS processor.  I didn't actually make much use of the buttons, switches, matrix display, 7-segment display or VGA.  This didn't stop me buying an even more sophisticated Cyclone IV with Ethernet, which I never used!

Arduino MKR Vidor 4000

I was pleasantly surprised to see that Arduino had an FPGA board and impressed with the contents.  They have a small Cyclone 10 FPGA together with an Arm Cortex M0 processor.

I didn't do much more than follow introductory tutorials for the board but I was able to get it working with Quartus Prime to build designs.

There don't seem to have been any developments or new FPGA boards from Arduino since this one.

 

Atlas DE0-nano-Soc

This is my favorite board.  It contains a Cyclone IV FPGA together with a "hard processor" (HPS) capable of running linux.  It is intended as the basis for FPGA university courses and there are tutorials to program the FPGA, HPS and link them together.  The first tutorial guides you through building a bare metal FFT application in the FPGA.  A second tutorial lets you build a linux system, including a preloader, u-boot and linux kernel, which is quite an undertaking.

Summary

I learned a great deal from these boards.  FPGA programming takes you right down to the level of logic levels and combinations of gates.  The software tools to help you achieve this are the same or similar to those used commercially which means they are large, complex and not necessarily free.  However they are very powerful and enable you to control the hardware.  I found out more about very low level steps to start processors including u-boot and BSP (board support packages).  I never got very far with programming peripherals and honestly I was quite a long way / time from being confident with the software, partly due to availability / compatibility problems.

I am very reluctant to lose these boards but I have put them on Ebay this week.
Update: I sold the boards for £20 (Ethernet), £30 (Cyclone IV) and £50 (Atlas).  I wasn't bothered about the money but I listed them at reasonable prices so that they would go to a good home where they were appreciated.

I have already looked at what I might get instead.  The emphasis must be on getting a board with excellent up to date software and learning resources.  Digilent seem to be the best option I have seen so far.....

Atlas - Kernel Build

WS2

Following success with Rocketboards WS1 tutorial enabling me to write a C program running under linux in two way communication with an FPGA program I was excited by the prospect of WS2.
WS2 describes how to build a preloader (as before) build u-boot and build a kernel.  I was able to build the preloader and build u-boot but kernel build dates from about 2015 and not all the sources are still available.  The installation is very technical and I wasn't able to adapt it for myself.

Digikey

Robert Nelson, a modern day hero at Digikey has published, and kept upto date, a sequence of instructions to build u-boot and linux then create a bootable SDcard.  The instructions explain how to:

• Install the Linaro ARM cross compiler
• Obtain and compile u-boot
• obtain and build kernel
• Obtain Debian 10.3 root filesystem
• SD card creation.

I created a Debian 10.3 linux system on a USB hard drive so I could do the build without affecting my Windows PC configuration and the tutorial worked like a dream. The new SD card boots up on the Atlas system complete with ethernet interface, ssh and nginx.  It used 550MB of the 2GB microSD card I supplied so there is plenty of space.

Atlas Workshop WS1

Introduction

The DE0-nano-SoC documentation provided some great tutorials to get started with FPGA, HPS and then establish links between them.  I can see that there is a lot more to find out about the device, software and working environment.
My efforts with the Golden Hardware Reference Design (GHRD) were eventually successful and the hard work involved was centred around choosing the right versions of software to match the tutorials.
I learned quite a bit through this process of trial and error, in particular Quartus and EDS version 15 (c.2016) are preferred where possible.  If there are bugs, version 16.1 may be more appropriate.  Version 18.1 is my newer favoured release but doesn't include suitable EDS/DS-5 capabilities as they have become chargeable.

Rocketboards.org provides a set of three workshops for familiarisation and they seem to go down a considerable depth into the internals of the product.  I am reasonably happy that I understand enough about FPGAs for my current purposes, I can compile and load a design using my own verilog or Altera IP modules.  However the Linux environment and FPGA-HPS bridges are mysterious.

The WS1 course materials provide an excellent overview of documentation available / required.  The format is a  slide deck so there isn't much detail included but technical areas are summarised.  The Cyclone V boot process is covered in some detail and forms the basis for the four labs within the workshop.

Preparation

In preparation for lab activities we download an SD card image which contains linux and course files.  The card is tailored for Atlas / DE0 and assumes that Quartus 15.1.2 is used.  Once the image is unzipped and burned to card using BalenaEtcher it can be booted.  This is excellent as I now have a known source for an SD card image which is tailored for my board.
We have a general WS1-IntroToSoc folder and device specific hps_isw_handoff, DE0_NANO_SOC.sof, soc_system.sopcinfo.

LAB 1 Generating and compiling the preloader

When you boot the Atlas board from SDcard a very small BootROM program loads the preloader into on-chip memory.  The preloaders job is to setup the FGPA, define HPS I/O and memory and then copy the Linux bootloader into DDR memory which allows the HPS to boot in the usual manner, load the OS etc.

Our first task is to generate a Board Support Package (BSP) which will define various hardware details relating to the FPGA design and HPS interface.  We have a pre-generated QSYS design, whose details are provideed in hps_isw_handoff/soc_system_hps_0. We create a new BSP using the Altera BSP Editor tool, give it a copy of the design and generate a BSP.
The BSP folder contains source code, preloader settings and a Makefile to build the Preloader.

We now run make to compile the preloader and create a image file preloader-mkpimage.bin.

Finally we use the Altera Boot Disk Utility to copy the file to the correct partition on the SDcard so that the Boot Rom program will read it in and execute it.

Inserting the SDcard into the Atlas board we see the preloader booting up the system.  This is great progress but the system doesn't do a lot at this stage so we reset to the original preloader for now.

The lab is very instructive in showing the files required produced and the steps needed to generate a preloader.  We don't need to understand more detail as the design provides details and the BSP Editor interprets them to generate a preloader.

LAB 2 Verifying Hardware with System Console

Quite a short lab showing you how to use the System Console which looks to be hugely powerful.    It allows you see and set values within the FPGA.  Our FPGA demo design runs a Fast Fourier Transform in hardware and sends the results back to HPS.  Using the system console you can provide values to the FPGA, run the algorithm and using scripts, capture and display output.
It requires a far better understanding of the hardware than I have currently so I don't expect to use it in practice.

LAB 3 Bare Metal FFT app

A bare metal C program is provided for us and our mission is to run it.
The file soc_system.sopcinfo which was given to us contains information about the FPGA memory layout. Using sopc-create-header-files utility a number of headers are created from .sopcinfo which are required by our C program.

Now run make to use the provided Makefile to compile our bare metal program fft.bin.
C the executable across to the SDcard FAT partition which is mounted on our PC.

We now boot the SDcard and type "stop" to get to a u-boot prompt.
Commands are used to:
 load the FPGA program
 configure HPS-to-FPGA bridges
 load the bare metal application into memory
 run the application
See the output, Hello world followed by FFT inputs and outputs.

Finally we automate the load of the bare metal application.  This is (intentionally) partially successful, when our application runs it only prints hello world.  This is because we haven't configured or started the FPGA and bridges.

The tutorial covers a lot of ground.  Although I am unlikely to write bare metal programs it is wonderful to set up a working example so that we can see what a program does without an operating system there to help it.

LAB 4 Linux FFT Application

After the complexities of the previous labs this one is quite easy.
The fft app is compiled in EDS and copied to the SDcard.
We can then run the fft program on Atlas linux.
The linux configuration includes a lighttpd web server which can be used to specify input parameters and graph the output from the FFT.
It is deceptively simple as the C program looks complex and has a lot of code concerned with sending fft values to the FPGA, controlling it and reading back results before formatting them for the web server.

Atlas - First designs

Introduction

The DE0-nano-SoC documentation on CD-ROM (contents available here) is the best way to get started using the Atlas SoC.  Three step by step guides are available to build an FPGA design (using Quartus), an HPS design (using C and EDS) and a combined FPGA-HPS deisgn.

After completing these projects I wanted to test the Golden Hardware Reference Design (GHRD) which combines all the hardware components and pins.  This should help with starting any future computer project.

My First FPGA

This is a good project to familiarise yourself with Quartus.  A simple counter is implemented in verilog and a schematic created integrating the counter with a clock and a multiplexor.  A button input is used to control the speed of LED output pattern flashing.
The tutorial clearly shows you how to use a number of Quartus features without introducing more complexity than necessary.

My First HPS

The purpose of this tutorial is to allow you to compile and run a C program on the linux system.
A cross-compiler is required and should be provided following a successful install as described in the getting started guide.
Initially my Altera toolchain didn't work so I installed arm-linux-gnueabihf-gcc under wsl and compiled / copied it across to atlas_sockit using winscp.
It wasn't particularly informative but good preparation for the combined FPGA-HPS test.
For further tutorials it was important that the compiler works as expected and I could use EDS (Embedded development software).  Generally I am using v18.1 software but licensing has changed so EDS isn't included.  I installed Quartus and EDS v16.1, the last release including EDS, and this worked exactly as expected.

My First HPS-FPGA

The third tutorial guides you to create a QSYS design based on the GHRD (Golden Hardware Reference Design) which includes a PIO module for the LEDs.  An interface between FPGA and HPS is configured so LEDs can be controlled from a linux program.  

An HPS C program is written to map the appropriate memory locations so that the C program can use them.  It is quite complex and I couldn't write it from scratch.

Once we have loaded the FPGA image and copied the compiled C program to Linux we can run the program and control LEDs.  This is a leap forward in using these devices.
I am not convinced I will go far along this route.  I don't want to spend too much time writing C programs.


Again software was a bit of an issue but once I standardised on Quartus / EDS 16.1 I could follow the tutorial easily.

Compiling Hardware Design

Having completed basic tutorials I wanted to compile the Golden Hardware Reference Design (GHRD) as this would provide me with a template for using all the FPGA components.  It also seemed to provide a way to build an SD card image.  Instructions were simple, an intricate Makefile script is provided to create a Quartus project, build it and add all the necessary files for an SD card image. Unfortunately they didn't work well.
Eventually I was able to compile the GHRD and download it to Atlas.  It required me to start the creation process on Quartus web edition 15.0 + EDS, then continue in Quartus 16.1 and finalise/download in Quartus 18.1.
I am pleased that I have a "working" reference design and I did learn quite a lot along the way but it wasn't enjoyable.

Arduino MKR Vidor 4000 - Getting Started

At the Arduino site there are a couple of tutorials by Daniel Hertz which show you how to build / download a (pre-existing) design for the Vidor Cyclone10 FPGAand how to create a Quartus project  from scratch.  The best example to use is provided by Al Williams in a Hackaday article and can be downloaded from github.

Building and Loading an FPGA design

The first thing to do is to set up Quartus, I haven't used a Cyclone 10 processor previously so I needed to download and install the appropriate Quartus repository. I then downloaded Al Williams example code which includes a Quartus project file (.QPF) so that I could synthesise an image straightaway.

Normally I would then download a .SOF file to the FPGA using a USB Blaster.  A confusing wrinkle with the arduino setup is that the .TTF file created during Quartus synthesis needs to be converted - its nibbles are in the wrong order - before downloading to the FPGA.  Al Williams provides a simple C program vidorcvt which converts this file to one called app.h.

The second part of the design is an Arduino sketch (provided) which sets up the FPGA and runs SAMD code which interfaces with the FPGA.  When this sketch is compiled and loaded we have a working SAMD/Cyclone implementation running on the Vidor.

Al Williams example is a simple blink program which runs on the FPGA.  A 28 bit counter is used to determine the blink speed.  Bit 27 is used for a 1 second blink and bit 21 gives quicker flashing.  The FPGA code is stored in user.v.  Arduino pin D6 is used for the LED output.  If the user sends a character using the serial monitor, the Arduino sketch toggles pin D5.  user.v then toggles which counter bit is used, i.e. it changes the flashing speed.  This demonstrates simple inter-communication using shared GPIOs.

Creating a Quartus Project

There are a number of things you need to create a Quartus project:

• pin outs for the various components (.QSF)
• system constraints file (.SDC)
• IP code for all the peripheral components
• Top level Verilog code to initialise the system

These are provided in EmptyVidorProject folders so that it is quick to start writing your own code.
It is instructive to build your own project using the tutorial, although in practice you could copy a skeleton quartus project structure.

It is particularly useful to have the pinouts and SDC as I usually need to spend a lot of time trying to get them right.
The top level verilog code is setup as a boiler plate - you can add your own code in a user.v include file.

Baby Steps

As a check that I can change the code myself I changed the LED output used for blinking.

Copy the blink Quartus project directory to blink2
In user.v assign counter value to bMKR_D[4]  (pin D4) instead of bMKR_D[6] (pin D6)
Synthesise the project
Convert .TTF output to app.h and save in the blink-sketch folder
Compile and upload blink-sketch to Vidor
Now pin D4 blinks instead of D6

This demonstrates that I only need to change code in two places user.v and blink-sketch.

Arduino MKR Vidor 4000

Intro

After the excitement of the Atlas-SoC I saw that Arduino have come up with similar hardware.  The Arduino MKR range provides low cost/power 32-bit micro-controllers.  The Vidor 4000 contains an Intel Cyclone 10 FPGA together with an Arm Cortex M0+ MCU.  So we have an Altera FPGA which we can program/configure with Quartus and a Microchip SAMD21 Arm processor which we can program with the Arduino IDE.  Arduino simplicity and the size of the user community should make this potentially widespread in its appeal.  It is also new in late 2018 so its use is just beginning to evolve. It is so exciting that I asked Harry to buy me one for Christmas.

Install

Getting Started is straightforward, as you would expect.  In board manager I needed to add SAMD beta boards then add the Vidor 4000 board in the Arduino IDE.  As usual I connected a microUSB cable to the PC and, after installing a driver, I was able to see the device and load a standard blink "hello world" program.  Next I downloaded VidorGraphics, VidorPeripherals libraries and could then try the Vidor specific examples. The first one of interest is to display an Arduino logo on an HDMI screen.  Initially this didn't work on my HDMI monitor but when I connected to a HDMI TV port it worked fine.

Familiarisation

The best explanation I have found for the Vidor 4000 is provided by Philippe at systemes-embarques.fr who also provides some tutorials.  Components on the card are:

• ATSAMD21G18A microcontroller with 256 kB of Flash and 32 kB of RAM.
• a Cyclone 10CL016 FPGA with 15408 logic elements, 504kbits of RAM and 56 multiplier 18 × 18.
• a 16 Mbits FLASH SPI.
• a 64 Mbits SDRAM (4M x 16 bits)
• a NINA W102 WiFi / BLE module incorporating an ESP32 dual-core microcontroller.
• an ATECC508A cryptographic chip improving the processing speed for secure connections.
• MiniPCIe, USB, battery, I2C, MKR, MIPI for a camera, HDMI for video output connectors.

Most resources are attached to the FPGA but can be routed to SAMD21 or ESP32.

When Vidor is switched on MCU and ESP32 are initialised from non-volatile memory and the FPGA configuration is loaded from the Flash memory.

If you use Arduino IDE to upload the example "blink" sketch it is loaded via USB cable to MCU and run without touching FPGA.

If however you upload Examples>VidorPeripherals>VidorTestSketch one part of the .HEX file is loaded to MCU and the rest (app.ttf), is loaded via JTAG into FPGA and saved in SPI FLASH as shown in the diagram below.

When FPGA.begin() is executed on SAMD21 it enables FPGA clock, initialises JTAG port and sends a command to FPGA telling it load app.ttf from flash.  The JTAG port is used for subsequent MCU - FPGA intercommunication.

Atlas SoC

Purchase

One problem with buying an FPGA card from ebay is that it is difficult to find appropriate tutorials which are designed for similar configurations.  I regularly see tutorials for Altera development boards but initially I thought the boards were all terribly expensive.  However when I saw the Atlas-SoC board for about £100 at Mouser I had to buy one.  It comes as a specific learning package, it is based on a cyclone V, has an ethernet port, and runs linux from an SD-Card.  That seems like nirvana and without a trace of indecisiveness I sent off for one.

Getting Started

The board arrives with some instructions (a pleasant novelty) and when I plug the micro-USB connector in to the PC and power it up I see a new F: drive!  This tells me to install a driver  then I can open a browser session to the board!  I did have a little bit of faffing about to get the driver to work, perhaps because the package was put together in 2015, but soon I had a welcome screen on the FPGA IP address.  A wonderful start to the experience!

The board comes in two flavours:
Atlas-SoC - targetted at Embedded software developers
DE0-Nano-SoC - targetted at Hardware developers

Both have exactly the same hardware but the getting started instructions are different.

Having followed the "software" instructions initially I wanted to understand a little bit about the hardware so followed the DE0-Nano-SoC Getting started guide.  This took me through 5 steps:

1 Add Cyclone V device support to Quartus (I previously had Cyclone IV and MAX1000)
2 Install SoC FPGA EDS (Embedded Development Suite)
3 Setup the board, including configuration switches
4 FPGA System Test - use Quartus to load and run an LED counter sketch
5 Run Linux on the board - format an SD card for linux, boot up and connect via Putty.

This provided an even more wonderful experience.  We are now able to program the FPGA part of the board and have Linux running on the HPS (Hardware Processor System) part.

Altera Cyclone IV Ethernet development board

There is always a need to hava an FPGA which will do more.  The Cyclone IV board is great for simple output and testing my NIOS processor.  Matrix LED and 7 Segment output provide physical output in addition to screen I/O using the UART.  What I really need is a network connected FPGA.  Ebay provides the answer with a powerful cyclone IV development board complete with gigabit ethernet, an SD card and audio i/o suitable for DSP.  It also has plenty of memory, lots of I/O and a VGA port.

After a few weeks the board duly arrived from Aliexpress in China.
I was able to run LED and KEY test programs provided to check that it is working.
There was also a good QPF project to test Audio input output.

Unfortunately (maybe) the test programs for Ethernet and SD card dont work so I have some investigation, learning and programming work to do before I can use it properly.  My aim is to build a web-server which serves files from the SD card.  A secondary (stretch) goal is to build an audio processor to show waveforms and signals on an attached VGA display.  It may be some time before I can report back on progress.

MAX1000 NIOS

SYSIN and SYSOUT
With a working NIOS processor available to us, thoughts turn more to software.  Programs are written in C and compile by Eclipse.  The first requirement for C programs is to have SYSIN and SYSOUT available.  If we have a single serial port, for example MAX1000 JTAG UART SYSIN/OUT are assigned by default to JTAG.  If we have multiple serial ports we can choose (in BSP) which ones to use.

Hello World
The simplest way to create C applications is to "create new application and BSP " in Eclipse.  There is a basic "Hello World" program which sends a SYSOUT message.  Tutorials generally instruct you to ensure you are using small C library and reduced device drivers to save space and the "Hello World small" causes these to be used.

Typically C "Hello World" specifies <stdio.h> and calls printf for terminal output.
If you select the small option you use an alternative library and functions.

Our first processor has about 40KB on-chip memory defined which is just about enough for printf output but not for input as well.  To have a program including input and output we use the small libraries and alt_putstr/alt_getchar.  These can use as little as 800B program memory.

SDRAM
The physical Altera FPGA chip has 64kB on-chip RAM and 64MB SDRAM so it makes sense to use SDRAM for our C programs and data.A tutorial from University of Las Vegas suggests that you can simply add SDRAM and directly replace on-chip memory with it.
I ran into difficulties when I tried to add SDRAM as it requires lots of pins to be defined.  I found that the test_board project provided with CycloneIV documentation checks SDRAM so I used the pin assignments from this for my SDRAM.

Once I had added SDRAM in platform designer I removed on-chip memory and pointed reset and exception vectors to SDRAM.
Now when I download programs from Eclipse to NIOS I can make them as large as I like.  A simple C program with printf and scanf takes about 100KB.

MICRIUM
There is a third variant Hello World program provided in Eclipse which uses MicroC-OS/II  RTOS.  It seems sensible to me to have an RTOS in an embedded processor.  I could compile the RTOS Hello World quite easily and it only took 60KB.  In fact it started two threads which run simultaneously.  It will be useful for multi-tasking but it doesn't have a user shell (unless I write it myself).

Cyclone IV NIOS

Introduction
Whilst building CycloneIV 8080 CPU I checked out a NIOS processor, in particular to determine how it used serial I/O.
Altera have provided NIOS as their ready-made processor for a number of years.  One reason for using FGPAs is to combine bespoke digital logic together with embedded uProc in the same chip and not many customers would want to build these features from scratch.[November 2019]

Overview
To specify hardware Altera provide Platform Designer so that you can choose components for you processor including a NIOS II core.  When you have working hardware software build tools (SBT) for Eclipse (IDE) enable you to specify, compile and download C Programs to the processor.
If you need extra functionality / peripherals you simply add the to the hardware design and utilise them in your program.

Samples
CycloneIV development kit came with some NIOS samples.  To check out the LED example I simply downloaded the SOF file and it ran.  Similarly for the Bell.  Unfortunately TFT examples didn't work directly.

Simple Processor
It is very easy to create a simple processor in Platform Designer.  The minimal components needed are a clock, somoe on-chip memory, a NIOS core and parallel IO for some LED outputs.  I wanted to add terminal I/O to the solution as I was researching that facility for my 8080 CPU and also being a bit fed up with using LEDs for debugging.
Using LEDs for output was easy but, try as I might I couldn't use JTAG USB as a serial port.  I feel that it may not be supported, or perhaps my USB blaster doesn't support that function.  Along the way I found it is much easier to debug NIOS problems using command in the NIOS2 shell

Once I used the DB9 serial port the process became a lot simpler.  Having tried a number of tutorials, mainly on youtube, my favourite was from Labbook pages. This helped me understand what we are creating at each step of the process.  

Useable Processor

The labbook processor included the C executable in its image. I used a youtube tutorial to create my useable processor which contained LEDs and serial I/O as well as the ability to load programs through Eclipse.

Extending Functionality

I could now add a Seven Segment display to my processor.  I chose to do this by specifying a 16-bit number to output from the CPU and then utilise previously written verilog to convert this to a number of hex digits and display them.  The display works by refreshing each digit in turn every millisecond so that all the digits appear to remain lit.  

I could have put this functionality in the NIOS processor and output 7SEG pin signals, but that was more work.

Cyclone IV 8080 CPU

When I have successfully (re-constructed) the 8080 CPU on  MAX10000 it should be straightforward to build the same functionality into CycloneIV.  We can use project stages from MAX1000 build and amend the project for CycloneIV pins and hardware components.[October 2019]

Stage 1
Create a project and use a generic verilog program (LEDwater) to check that LEDs are are setup.  The Top Level module becomes Board.v which we will use as a "PCB" for our processor.
We can then add CPU functions in the increments:
test states
Add data memory
Add ALU

Stage 2
CycloneIV provides RS232 UART for I/O.  I had an old PL23203 DB9 cable which I could plug in to the connector and PC-USB.  Unfortunately it was too old; although I persuaded it to do output I couldn't do input until I bought a new cable.
It was then straightforward to implement keyboard input and screen output via a Putty terminal emulation session.

Stage 3
In addition to the DB9 UART CycloneIV allows terminal communication via USB for a NIOS console and this same feature worked fine for my 2nd MAX1000 serial interface. I wasn't able to get the inbuilt port to work on CycloneIV so I added an FTDI RS232 interface for the serial port.  Once the corresponding CPU verilog functions had been added I had a working CycloneIV 8080 development environment complete with program load capabilities.

Elektor processor dissection and reconstruction

To understand how a machine works you can, perhaps, take it apart and put it back together again.  Whilst Elektor exp5 is great to see and you can look at the code to get a general idea of its construction, something more is needed to become familiar and understand it better.[October 2019]

Dissection

Stage 1
The processor has a debug serial input allowing you to type in single character commands and get text output.  I checked that I could add commands myself to look at the processor

Stage 2
I removed unwanted peripherals from Top.v, the top level function:  DAC, accelerometer, SPI.
I then took out UART processing as this requires a lot of code.  Subsequent stages use LEDs for output.

Stage 3
I slowed down the CPU to 16Hz (400 ticks) so that LED changes appear in real time - ie without needing to insert delays.
At the end of this stage Top.v is small but we still have a working CPU running C programs and producing output.

Stage 4
Firstly we remove the code for LED output from the processor and use LEDs for debugging output instead.
We can see, in Icarus each opcode being processed.
We can remove the special states div1, div2, readmemat3 without affecting processing.
Finally we can remove all the opcodes from the CPU except for jumps.  A test program now loops but other codes are treated as NOP.
The end product is a processor with a clock, program counter and jump instructions.

Construction

1 Clock

We start a new MAX1000 project and add ALTPLL clock and LPM_COUNTER IP.  In a skeleton top level program Board.v we incorporate these components and output appropriate bits from the counter to LEDs so that we can see binary values being incremented.

In Quartus we need to add LED, clock pins and timing (SDC) information.

2 States

Add a skeleton Cpu.v which just switches between the states fetch, decode, readmem etc.

Add Testbench.v so that we can run tests in icarus first.

Add USR_BTN which stops the processor when pressed, we can use this for single stepping.

Use LEDs to see the processor cycles through instructions and states.

3,4 Codemem, datamem

We implement JMP and NOP instructions.

We use a program copied from stage 4 above and can see the program counter increasing until the JMP and then looping round.

We can now implement instructions ST (store), LD (load) to access memory and LDIND, STIND.  We setup a stack at the end of datamem  and implement CALL, RET. Add stack operations e.g. PUSHR0, ADDSP,....

We also add HALT to finish the program.

5 Arithmetic

Add arithmetic, logic and comparison instructions:

IADD

XOR, OR, AND, COM, NEG, MUL

CMPEQ/NE/LT/LE/GT/GE, CMPULT/ULE/UGT/UGE

Also add conditional jumping

A few more optimiser instructions (added to C by the author to decrease number of instructions) were also added.

At this stage it is possible to compile and run a c program containing code like result=i+i;

6 Output

All peripheral output is directed by the OUTA instruction. Initially we implement channel 5 to set LED values.  We then add channels 9 (output character), 8 set output speed and input channel 5 (determine bits left to transmit).  The CPU needs code to process the channels and Top.v needs corresponding details for physical hardware processing.

We have to add TXuart.v to do the bit-banging.

We can then run compiled programs including the C putchar() function.

7 Input, debug and load

Add RXuart.v module
Add, irq processing to CPU

Add bootload/standalone parameter to switch program load.

This was quite an extensive step at the end of which we had most C instructions available to us.

Quite a lot of code 

8 RTC, DAC, LIS

Finally we add other peripheral functions to the processor so we are confident we have a complete working system.

Conclusion

This was a time-consuming and very worthwhile exercise which allowed me to understand how the Elektor-provided verilog code creates an 8080 processor.  I kept variable names and formatted code the same so that the final result doesn't look radically different from the starting version but I understand content a lot better.

MAX1000 FPGA UARTs

UARTs are particularly useful for FPGA embedded processors as it quickly becomes very tedious using LEDs for debugging and for program output.  The Elektor 8080 embedded processor experiment 5 requires two UARTs one for terminal I/O and the other for program load and debug statements.

As an introduction to UARTs I used an electronoobs tutorial which provides a clear explanation of the verilog required to send and receive bits.  I used MAX1000 pins A4/B4 to utilise the internal UART for testing.

For the second UART Elektor I used an FTDI RS232 cable attached to pins M2/M1. I could have used any available GPIO and if I wanted I could add more terminals using more FTDIs/GPIOs.

Initially, in Elektor experiments 1 and 2,  executable 8080 C programs are loaded into the image which is downloaded to MAX1000.  Changing a program requires you to compile a program and put the executable in the Quartus project folder then running synthesis and loading using Programmer, which very quickly becomes very tedious.  Elektor experiment 5 uses Processing (a C environment on PC equivalent to arduino) to transmit executable 8080 C programs to MAX1000 via a serial interface.  The interface also provides some basic commands to be be used for debugging.

Our first serial interface (built-in B4/A4) is required for SYSIN/SYSOUT terminal I/O and we use the second one (FTDI M2/M1)  for program loading. [August 2019]

8-bit MicroController

The driver for my FPGA familiarisation is to experiment with processors.  As a starting point I looked for a small easy microcontroller to implement using verilog.  I found a perfect example at FPGA4student.com. It is an 8 bit MicroController which has 8-bit registers, 12-bit instructions and five core components: MicroController, ALU, Control Unit, Program Memory and Data Memory.

The three articles provide a full specification, design and implementation for this MCU which greatly enhances the building process.  The MCU has 256 (8-bit address) 12-bit instructions and 16 (4-bit address) 8-bit data locations.  The two inputs for the ALU typically come from the Accumulator and data memory although the capability to load immediate values from instructions is provided.  Each instruction requires 3 clock cycles for Fetch, decode and execute phases.

My verilog coding isn't very good but when I was struggling I could look at the code provided for guidance.  I started by implementing the Program memory and Program counter (PC) for the fetch phase.  Initially these were developed using Icarus simulation, but once it worked 'on paper' I transferred it to Quartus for download to the MAX1000 which required plenty of debugging.  MAX1000 LEDs were used to display PC and partial instruction contents.  I felt at this stage that the MCU was alive, even though it was just stepping through the instructions.  

Implementing an ALU is very straightforward as it requires purely combinatorial logic.  Adding the control logic is rather more challenging.  It would be possible to work from the design and implement all the logic at one time but I felt this could prove hard to debug so I added instructions in groups.  Load and store instructions using data memory came first, followed by ALU operations and finally status registers were set and jump instructions implemented.

As the instruction set and data is rather limited and output is restricted to LEDs I chose a Fibonacci series as a first program.  This requires minimal processing and output can be displayed as binary on LEDs.

Cyclone IV FPGA Development Board

Intro

My favourite thing about ebay is that it has a wide variety of development boards which provide great functionality at prices far lower than branded products.  Looking for an FPGA board I was very excited when I saw this one.

It has a great specification:

FPGA core board: Power input DC5V FPGA:EP4CE10F17C8N SDRAM:256M SPI FLASH: 64M 50 MHz CLK input  Bottom board: PC PS/2 port VGA port ,can display picture or video, 16 bit 65536 colours SD card LCD12864/1602 ,can display number or English character LCD TFT ,can display number or English character, or video LED 7seg display 1x8, can display number LED 1X8 COM port 8X8 LED dot matrix 3X3 key input pad 1X4 key input switch 1X8 input ADCTLC549, you can analogue signal acquisition DAC7512, digital signal to analogue signal IR input DS18B20 temperature sensor

So three days later we have lots of inputs and outputs to play with.
In fact the FPGA board is detachable so one could theoretically use all the board IOs for other purposes.

I experienced problems initially as my usb blaster programmer turned out to be a clone and I had to install old WIN7 unsigned drivers to make it work.  Once I was able to load software the board was great.  The vendor provided Quartus programs to test the main features and it was a pleasure to load and run them so that I could be sure my subsequent efforts utilised working hardware.  Update: Life became much easier when I bought a real usb blaster (£16 instead of £6), which works perfectly.

MAX1000 FPGA

I have always been somewhat in awe of FPGAs and nervous of the challenges they present.  Recently, in the March/April edition of Elektor, I saw an instructional article to create a processor on  an Altera/Intel MAX1000 which reminded me of a study of Computer architecture, based on Nand2Tetris.com, which I enjoyed immensly .  The web-site (and book) leads you through all the important steps involved in building a computer starting from a collection of Nand gates and ending with  processor, assembler, compiler and Operating System to run your own programs.
Nand2tetris provided a hardware simulator based on building an increasingly complex hierarchy of components but naturally enough it was too slow to deal with running non-trivial programs.

I went through the following stages to find out more.

1) Purchase a $30 MAX1000 from Arrow Computers

2) Elektor 8080 + Small-C compiler part 1 : LED pattern

Following the instructions in Elektor magazine I built the 8080 simulator FPGA program and was able to run the C program which generates a MAX1000 LED pattern.

3) MAX1000 User Guide Tutorial : LED counter

When delivered the MAX1000 runs an LED counter program, using the tutorial I was able to recreate and download to the FPGA.

4) Quartus, Hello World : NAND gate LED

I wanted to write the simplest possible program and decided on a Nand gate.  Unfortunately only one button is easily available on the MAX1000 so I implemented a NOT gate instead.  When a button is pressed an LED goes out.
This exercise simplified technical work into two tasks:
a) a very simple HDL program to implement a NOT gate.
b) assignment of two MAX1000 pins to a button and an LED

5) Altera NIOS II Hardware Development Tutorial

NIOS II is an FPGA microcontroller developed provided by Altera.  A tutorial is provided which goes through a significant number of steps to build the solution.  It helps you become familiar with the Quartus Prime environment and the specific MAX1000 hardware.

By the end of this investigation I had a very basic idea how to use Quartus Prime and a MAX1000 board.  Clearly 1 usable button and 8 LEDs are insufficient to maintain an interest in programming.  Rather than adding my own devices by breadboarding the MAX1000 and various peripherals I decided to buy a board which already has them built in.