In a previous post I optimistically set out to reproduce the
switch/button/LED demo from
Digilent, but using
AXI. I quickly had some LEDs lighting up, but reading out the push buttons and the switches proved to be a bit more
difficult than I anticipated. Probably because I’m not using VDHL and AXI on a daily (or any) basis, so this was a lot
of learning. The things I will outline below are maybe obvious to the experts, but as it was not obvious to me, I’m
imagining it is not obvious to other beginners either, so hopefully this is useful.
After getting a Digilent Arty-A7, I quickly found
this programming
tutorial. It is a very
simple demo where the switches and push buttons are OR’ed into the LEDs. The implementation is a single Verilog source
file:
This issue seems to come back to me every time I provision a virtual machine for working with Digilent boards: I
install libftdi and libusb, and then download and install the Digilent Adept
2 runtime and utilities and think I’m done. But every time:
In a previous post I explained how to deploy a
softcore LEON3 processor on a Digilent Arty-A7
35T development board. Now it is time to run some
code on it.
The LEON3 processor is a space-grade processor. Its VHDL sources are open source, which means you can have your own
space-grade processor running on a FPGA board, at home.
The mandatory example to try when learning any new language is a “Hello, world” program. So let’s do one in ARM
assembly. You can find a similar one for C
here, including some useful
informat on compiling and linking that I’ve also used here.
QEMU is a machine emulator. It is capable of emulating a lot of
targets, among them a variety of ARM-based boards. When
developing for Linux on ARM boards, you need a Device Tree to tell the operating system
where all the hardware is. But also when you’re doing bare-metal programming, you need to know where the hardware is.
However, there’s no such documentation for the boards that QEMU can emulate.