make installation error "class Vzipsystem’... has no member named"

[odenj]

I'm following this tutorial to build ZipCPU. After installing Verilator from source and the dependencies to build this project, I'm getting an error while building zipcpu_tb.cpp.

The last couple lines that show the error message are attached. error.txt

[lk-davidegironi]

Same issue for me.

[ZipCPU]

Sigh.

This is what I get for using unsupported Verilator features to get access to signals and registers within my design. At present, it works just fine here using Verilator 5.005 devel rev v5.002-182-g1f58f48c0. My guess is that some Verilator update changed how Verilator is naming its registers (again--this has now happened several times). I'm also a bit at a loss as for what the "right" answer is. If I "fix" this, I'll break it for users of older versions of Verilator.

Perhaps the "right" answer would be to make these various values full and proper outputs of the simulated design, so I don't have to depend upon undocumented features. This particular use case, however, is the only one that would need it, so these extra outputs would need to be enabled for this simulation only and then removed from all other projects that use the CPU. It's doable, but ... not pretty.

The problem is ... I love this demo, and don't really want to get rid of it. I mean, how often do you get to see and visualize the internals of how a CPU works?

Suggestions?

Dan

[ZipCPU]

I just downloaded, built, and installed the current version of Verilator from git. It builds the simulations without problems. Let me assume you have something other than the most recent version from git. Here's how to go about debugging the issue:

1. Start by looking for the rtl/obj_dir/Vzipsystem___024root.h and rtl/obj_dir/Vzipbones___024root.h files. These will tell you what the "correct" naming convention is for the symbols that Verilator can't find.
2. Understand how the VVAR(A) macro works. Key to this macro is the rarely used ## operator. That allows identifiers to be concatenated together. Hence defining VVAR(A) as rootp->base_ ## A will generate references to rootp->base_val any time you use VVAR(val). Notice how the identifier itself is concatenated.
3. Now look for the variable of interest in the .h file above, and adjust VVAR as appropriate.

Hopefully that will help. I can discuss more/further as necessary. I still need a "right" answer to the issue, though, as this is really little more than a bandaid to an underlying problem.

Dan

[lk-davidegironi]

Thank you! Now it's compiling, and working. I've uninstalled the ubuntu stable verilator package (apt remove verilator), and follow the "Git Quick Install" from this guide here to install it (https://verilator.org/guide/latest/install.html) Next step, as you suggested in the linked post above, will be to run the CPU test_program. Hope to be able to use your CPU in one of my project.

I take the opportunity to ask you if it could works like so:

• few input attached to the CPU (some 16bit signals coming from an ADC)
• few output coming out from the CPU (some 16bit signals)
• few config wires to set the program running on the CPU
• a CPU program that is compiled on PC, and runs on the CPU. This program should take the input, do some computation based on the his logit, and set the output.

Regards.

[ZipCPU]

Beware, this is a CPU not an SOC.

1. You will need a bus wrapper. ZipBones is the smallest one.
2. That wrapper will need to be connected to a "bus". ZipBones uses the Wishbone standard. You'll need memory on the bus and you'll want some peripherals. The bus will need to be set up. Peripherals I commonly use include a serial port, debugging bus, and or a GPIO periphera.
3. Most FPGAs, cheap ones included, have flash memory available for configuration storage. This memory can work nicely for booting the CPU. It's not sufficient for running the CPU.
4. If you want to use the standard C library, you'll need an SDRAM of some type. DDR3 seems to be the most common. If you are going to run without the library, a simple block RAM peripheral might work for you. (Digilent's S6 didn't have SDRAM, so getting the O/S running on it was a challenge.)
5. The CPU does not load its own memory. If you choose to use flash, you will need a separate capability to load a CPU program onto the flash. Most FPGA vendors place their configuration starting at the first flash address on any device. If you want to play nicely with them, you'll need to load the CPU's program at a later address and configure it to boot from that later address.

My point is ... there's a lot more to a system than just the CPU. This repository contains the CPU alone. Other repositories I have configure the CPU for particular pieces of hardware--such as Digilent's Arty, their CMod S6, their Nexys Video, Arrow's Max1000, the Black ICE board, TinyFPGA, XulaLX25, or even the iCO board. Don't forget, there's also the necessity of debugging any design you build. While the CPU has (optional) hooks for doing that, it requires external access to the bus.

Hope that helps,

Dan

[lk-davidegironi]

Again... thanks. You clarify many of my doubts and save me lot of time. I mainly work on Xilinx, although I test small modules on Lattice or GoWIN cause their synth is much more faster to me. Because of the main works is on Xilinx I think I'll give a chance to one of the two ARM of the Zynq 7000 SoC. I've previously tested it, but then It comes to my mind that staying on the PL side of the Zynq was better. Or maybe a MicroBlaze which I've never try. You have to excuse my dumbness but It's just my first year of FPGA / HDL programming. I can now interface with ethernet (RAW and UDP), SPI, I2C, I2S and a few others, I've learn a few things on AXI stream, Wishbone, .. I've done some small works on FPGA and I appreciate the potential, but still I don't know so much.

[ZipCPU]

This appears to be a closed issue.