Program Arty A7 FPGA to be a RISC-V processor - Part III

 Since having lot of problem to follow https://digilent.com/reference/programmable-logic/arty-a7/reference-manual instruction on Windows/WSL/Cygwin, so I moved to do that on Linux/Ubuntu. Most thing goes smoothly. Do need to update several .gitmodules file to get everything synced, i.e. replace git://github.com to https://github.com.

When start to build the toolchain, I hit the first problem is while building riscv-openocd:

Multiple definitions of bitbang_swd originating from jtag/drivers/bitbang.h

Per https://github.com/riscv/riscv-openocd/issues/480, this likely is due to newer GCC 10+ which defaulting to -fno-common. I'm using GCC 11.3.0. So just as suggested, add the 'extern' keyword in front of the const swd_driver struct in bitbang.h. 

Then hit this one for compiling riscv-fesvr ../fesvr/dtm.cc:

'runtime_error' is not a member of std 

According to https://github.com/Azure/azure-storage-fuse/issues/421, it may relate to g++ version: According to https://en.cppreference.com/w/cpp/error/runtime_error, the include should not be exception.h but <stdexcept>. So the fix is adding #include <stdexcept> to dtm.cc.

Similar need to be done for riscv-isa-sim/riscv/devices.h.

With that, the toolchain build is OK. And make for verilog is done without any issue. However, when run

make -f Makefile.e300artydevkit mcs

Seeing this: ERROR: [Synth 8-439] module 'BootROM' not found [/path_of_freedom/builds/e300artydevkit/sifive.freedom.everywhere.e300artydevkit.E300ArtyDevKitConfig.v:242627]

Make -f Makefile.e300artydevkit mcs fails - module BootRom not found · Issue #96 · sifive/freedom · GitHub someone says re-sync repo solved the problem for him. My Vivado is 2022.1 build, and Digilent's instruction is using 2017 build. Hopefully the new version Vivado is not the problem.

By looking into the make log (there is log file under builds folder), the BootROM module is referenced in the .v file, which is coming from the .fir file as 'extmodule BootROM'. So likely a dependency is missing.

Then I went back to check files in the repo, and noticed in the root README.md, it mentioned two things:

• As of March 1 2021, SiFive is archiving the freedom repository. The code here is not being actively maintained, and we can't continue to provide updates while the fpga boards, software ecosystems and other dependencies change.

• Install sbt, varilator (probably typo of verilator) and scala which are required for building from Chisel

Per https://www.chisel-lang.org/: The Constructing Hardware in a Scala Embedded Language (Chisel) is an open-source hardware description language (HDL) used to describe digital electronics and circuits at the register-transfer level that facilitates advanced circuit generation and design reuse for both ASIC and FPGA digital logic designs. Chisel is powered by FIRRTL (Flexible Intermediate Representation for RTL), a hardware compiler framework that performs optimizations of Chisel-generated circuits and supports custom user-defined circuit transformations.

sbt home site: https://www.scala-sbt.org/. Per Wikipedia:

sbt is an open-source build tool for Scala and Java projects, similar to Apache's Maven and Gradle.

And the keyword extmodule is from Chisel. So likely, would need to install them as the README said. The instruction for installing sbt might need to be updated as it doesn't work with new Ubuntu. Refer to https://www.scala-sbt.org/download.html. Not sure why the README.md specified verilator_3_922. Ubuntu has this package, so I run sudo apt install verilator directly, same for scala.

With that, now running make mcs will ask for python. I installed python-is-python3 package, and now seeing a new error, same as described as https://github.com/chipsalliance/rocket-chip/issues/1991:

Traceback (most recent call last):
  File "rocket-chip/scripts/vlsi_rom_gen", line 90, in iterate_by_n
    batch += (next(it),)
StopIteration

As the ticket said, most likely due to I had Python3 but not Python (2.7) installed. Interestingly, the problem is gone after 2nd run of make, and then back to the no BootROM module issue.

Will chasing down the cause. <to be continue>