Digital Hardware Implementation: Let’s Make an Ethiopian Drone

By: Eyosias Yoseph Imana, PhD.

I was a middle-schooler when mobile phones were first introduced to Ethiopia, my home country. Besides feeling excited from seeing a mobile phone for the first time, I remember wondering if I will ever be able to understand how the thing works. I also wondered if I would be able to make one “when I grow up.”

If you are reading this blog, I bet you have had such kinds of thoughts at some point. You are not satisfied in being a mere consumer of technology, you want to join the makers club. Well, I hope this blog series will inspire and equip you to convert your ideas into prototypes – and possibly into a viable commercial product. My vision is to see many makers come out of sub-Saharan Africa – and hence, the target audience of this blog series are all the aspiring and current makers/entrepreneurs from the region.

A little about myself; my name is Eyosias Yoseph. I have been with the semiconductor industry in USA for almost 7 years. Before joining the industry, I was first a PhD student, and later a postdoc at Virginia Tech. I completed my MSc from Florida Tech, and BSc from Bahir Dar University. All my degrees are in electrical engineering, and my focus areas include wireless communications, signal processing, and digital system implementation.

In this blog series, I plan to chronicle the journey I am now starting to make a quadruple drone from scratch and teach what I know about digital implementation along the way. I note that making a drone from scratch is not new – folks have successfully built drones from scratch using Arduino (see here and here). The uniqueness of my effort will be in part because instead of Arduino I will be using a custom RISC-V processor implemented on a custom FPGA board. In fact, my goal (at least for now) is to learn and teach how to make things, not to contribute anything novel.

I am not sure if my drone will successfully fly, but I am sure that I will be learning quite a bit along the way and will be sharing those learnings in the upcoming blogs. Besides sharing my updates, I will include a video along with each blog where I cover important concepts/techniques/tools I use to do this project. Stay tuned!!

Block Diagram

The block diagram of the envisioned system is as follows. I plan to custom design and implement much of the yellow block in the middle of the diagram – that is, I will be making a PCB board for the FPGA, a RISC-V processor inside the FPGA, and a flight controller software to run on the processor.

This project involves hardware, software, and mechanical developments. A high-level roadmap of this project is as follows:

1. Hardware development
  • Processor design and implementation: I first plan to paper-design a RISC-V based processor and then implement its RTL using Vivado webpack from Xilinx (it is free). The RTL will be written using System Verilog.
  • RTL verification: I then plan to write unit and integrated testbenches (again using System Verilog) and test the processor design extensively using simulations. I will be using the simulator built in Vivado. To create randomized testing, and automation, I plan to use python scripts which call Vivado’s internal commands (called TCL).
  • Validation using real C program: Once the processor RTL is ready (passes most verification tests), I will make a simple C program and compile it with GNU RISC-V cross-compiler (download here). I will then load the executable binary generated by the compiler into the RTL simulator and run to see if the processor produces the expected results.
  • PCB design and fabrication: I will then make a PCB board containing an FPGA where the processor can be implemented. The PCB board is likely to contain a Xilinx’s Spartan-6 FPGA and will be designed using KiCad (download here).
  • PCB bring-up: Once the board is fabricated it needs to be brought up (may need two or three iterations to get a usable board)
2. Software development
  • Hardware model development: bare-metal programming is bug-prone because the programmer must deal with the hardware details which can be slipped up easily. To facilitate debug during flight controller software development, we will be first developing a C based model for the hardware. This model will be verified against RTL. Once verified, it will be used to bring up the final software.
  • Flight controller software development: The flight controller program will be developed in C on top of the hardware model first, and then on the actual hardware. As mentioned earlier I will be using GNU RISC-V cross-compiler.
  • Bring-up
  • Fly the drone!!!

It can be noted all the tools I plan to use in this project are open-source and/or free. Anyone can follow along and contribute to this project. I will be hosting the project in GitLab with public access. The only monetary expense in this project will be coming from PCB board fabrication, and the purchase of mechanical and electrical parts for the drone.

GitLab Repository

I named this project DESTINY, it is hosted at this GitLab.

Why RISC-V?

Say an Ethiopian company plans to make and sell a portable electronic device that can translate between the local languages in real-time (example, from Afan Oromo to Amharic and vice versa). Such device inevitably has a built-in processor – almost all electronic devices (ranging from a simple digital watch to a space shuttle are build with at least one processor).

The said company can choose one of the following routes to obtain a processor technology to put into its new device:

  1. Using another company’s processor chip: The company can choose to use a third-party processor chip (for example, from Intel, or Texas Instruments, or etc) which may be a good starting place but obviously expensive.
  2. Using another company’s processor IP: The company may license a processor design from a third party (for example, from ARM as every major companies including Apple and Qualcomm are doing) and customize and fabricate the processor chip. But this also comes with a hefty licensing fee.
  3. Making its own processor from scratch: Besides the riskiness of this route, it is not guaranteed to be cheaper than the first two. Making a new processor from scratch would also mean making a new build/compile toolbox which cannot be achieved without a significant Non-Recurring Expense (NRE).

Hence, all the above three options are expensive. The first two routes also indicate a perpetual technological dependence on western companies which may not be a wise choice in the current geopolitical environment. For example, what if a trade war makes it impossible for western companies to supply chip or IP to Ethiopia? Well, that is not an impossibility anymore.

RISC-V is a 4th alternative – and the most optimal choice in my opinion. RISC-V is an open processor instruction set standard. It is an open standard, which means, anyone can make a processor based on this instruction set without paying licensing fees to a third party. Furthermore, there exists GNU compiler toolbox for RISC-V already. It is also new and has the potential to grow and dethrone ARM from its prevalence in the embedded processor world in the coming years. If we are early players in RISC-V, not only we can use it to make our own products, but we may also become key RISC-V chip and IP suppliers for the global market (why not?). For these reasons, I think the nascent Ethiopian computer/software engineering community should take the RISC-V opportunity seriously.

Getting Started with RISC-V

Are you interested to know more about RISC-V? Below are important links to learn further about RISC-V.

Today’s Lesson: Building a Bare-metal C Program

Before I close today’s blog, I invite you to watch the following this video where I teach about bare-metal programming using GNU’s RISC-V toolbox.