Arty-S7-Rover (summary)

Disclaimer

Write a summary blog, 7 Ways to Leave Your Spartan-6 FPGA challenge.

The Arty-S7-Rover is a small functional autonomous vehicle based on the Digilent Arty S7-50 board. The project was done for the 7 Ways to Leave Your Spartan-6 FPGA challenge.

All the files are open-source, MIT license and can be downloaded from -dramoz

Summary

• What I learned about the Spartan-7 FPGA
• What I learned about VexRiscv
• What's next?

Arty S7 - Spartan-7

When I started this journey, my knowledge of the Xilinx Spartan devices was what I got from my University courses, back in the day. I do most of my work at as an HDL Verification Engineer, with Xilinx and open source tools like CoCoTB/Verilator.

The devices we target are Ultrascale+ (Virtex/Kintex), with hundreds of thousands of logic resources - which are not "cheap" (as compared to a Spartan-7, but you can always find something bigger and pricier VERSAL - hopefully one day I can put my hands on one of this). As for my own projects, I switch between ESP32 boards or the ZynQ Ultrascale+.

The Spartan-7 was something I did not know I was missing. I was impressed by the available logic resources. DSP blocks and plenty of LUTs/FFs to have several RISC-V implementations in one small FPGA.

In terms of tools, Vivado ML is definitely a huge improvement over the old ISE. Things are easier to do and the results are acceptable.

The Arty S7 development board is a great starting point. It comes with a lot of IO ports and the necessary LEDs, and buttons, ... to do some productive work.

VexRiscv

Working with RISC-V, a different soft-processor core like Xilinx MicroBlaze was interesting and challenging. It was a long slow slope learning curve, but worth the time spent. There were a lot of concepts I have forgotten over time, principally as these days, most works on microcontrollers or microprocessors are done with the aid of IDE that already provided required bare metal startup code, register space and "complete" C/C++ std support functions.

HDL

Using the VexRiscv instead of other soft cores alternatives, gave me the opportunity to get a better understanding of the RISC-V ISA (Instruction Set Architecture). Also, the need to implement some basic RTL blocks was a good task to refresh some gone knowledge in Verilog and HDL.

One interesting challenge what the use of two different but similar languages for design. The Verilog syntax was based on C. Therefore, sometimes while coding RTL some C/C++ constructs were mixed or vice-versa.

 Although I have not compared yet my current implementation against a Microblaze soft core with Vivado IP integrator, I think the current implementation requires less logic and interconnections resources. Without taking into account the soft core processors, the extra logic and paths when using the AXI4 to connect peripherals would require extra resources that can be costly. Note, that I think that it should be possible to use a Microblaze without AXI4, but I have not gone there yet. Nevertheless, I think that with Vivado IP Integrator aid it would be faster to deploy an application - if no experience or resource reuse is available.

CoCoTB/Verilator

When working with FPGAs, simulating first is key. Debugging time of untested RTL code directly on an FPGA is costly and a long task. Fortunately, there are free available tools to speed up the first debugging stages. Using the Vivado simulator is a good starting point, but for complex designs simulation time becomes prohibitive. Most of the errors I have were easy to debug with CoCoTB/Verilator by using Python to generate the testcases.

 Improving your testing skills while working with embedded systems (with or without FPGAs) is a key to successfully deploying projects.

Future work

This is an ongoing project, and there are several features coming later. Among them, the next ones are:

• Arty-S7-Rover

  • RTL

    • Move the whole DC motor control to an RTL IP
    • Add one PWM for each RGB colour
    • Add an LCD

  • VexRiscv

    • add JTAG support for debugging and programming
    • add DDR support
    • add FPU (floating point unit)
    • Connect to WiFi (ESP32)
    • Implement INT (interrupts) handling to remove polling
    • Multi-core with FreeRTOS VexRiscv implementation could be in the planning.

  • UART: add TX/RX FIFOs + improve handshaking (e.g. remove TX bit set)

  • Hardware

    • Add battery sensors
    • Check other DC motor drivers' options
    • Improve DC motors control with a PID - HW/RTL vs FW/C++ implementation

• Tools

  • Better integration of verification tools: currently the verification process is a two-step, involving compiling the firmware (FW) and then running the simulation / or generating the bitstream. Both should be integrated into a single Makefilethat check for FW changes and compile as required/generates a new bitstream as required.
  • Check the Vivado IP Integrator flow: I decided not to follow the usual IP integrator flow as I wanted to keep things as simple as possible given the allocated time for this project and the short deadline (~8 weeks when you only have nights and a couple of hours on weekends is not that much)

 As a side note, I recently got a Spartan Edge Accelerator Board which has a Spartan-7 XC7S15. The XC7S15 has fewer resources than the Arty S7, but it comes with an ESP32 (WiFi/Bluetooth) and is also Arduino compatible (at 5Vdc)- so the plan is to port the current HDL implementation and see how it goes in terms of resources.

Final Remarks

This was an interesting journey. As my work mostly goes around HDL Verification, I usually have little time to explore HDL and RTL coding. The experience was fruitful - I remembered and learned a lot during the process and it was interesting to see how much FPGAs have grown over the decades - especially in the low-cost devices. Having free tools is a plus, relatively cheap FPGA boards like the Arty-S7 are great not only for hobbyists but for any competent project.

I would like to thank , and | for making these projects a possibility.

I would also like to thank the Open Community | , and . It would have not be possible to do any of this without the many hours spend on coding and debugging the tools.

dramoz

© Danilo Ramos, 2022