February 23, 2023

EBAZ4205 - A "cheat sheet" in 2023

I last worked with this in June of 2022. Now after 8 months have passed I am diving in (or at least sticking my toe in) yet again. The idea here is that as I "rediscover" how I work with my Ebaz and Vivado, I will record key aspects of my workflow for the future.

Setup

My "development" system is all ready to go, with the Ebaz mounted on a slab of wood along with various connectors and the two USB gadgets I use.

One USB gadget is a CP2104 USB to serial "dongle" that I have connected to the console serial port. The port runs at 115200, so a CP2102 would do just as well, but apparently this is the first thing I found in my drawer.

The other USB gadget is a Pi Pico with firmware installed so it functions as a XVC (Xilinx Virtual Cable) device. This is connected to the JTAG port on the Ebaz. More on this below. This does not have to be plugged in unless you actually intend to download bitstreams from vivado (or via the openFPGALoader utility).

I have a "pigtail" connected to the power pins with the usual coaxial power connector soldered to it. This allows a variety of "wall warts" to be used. I am current using a Netgear badged 12 volt, 1200 mA unit and it seems to work fine. I am told that any voltage from 6 to 12 volts (and perhaps beyond?) will work, but lower voltages will need to supply more current. I dug around and found a 6 volt 2100 mA supply and tried it. It seems to work just fine.

Network and booting

My unit has been "fixed" (as described in detail elsewhere) so that U-boot does a network boot rather than booting unix. It boots "bitcoin.bin" from /var/lib/tftpboot on my linux server.

If you start up the unit without a network cable attached it will try to run whatever random rubbish is in ram after the network boot times out and typically get an undefined instruction exception and go into a boot loop. The same will happen if the network is misconfigured or if the DHCP server is not set up properly, and so forth.

There is no reset button unfortunately, but what I do is to have a button wired up to interrupt power, which yields the same effect as a reset. There is an issue however. Somehow the USB to serial device powers the board and I do not always get a clean reset (or any reset) when I interrupt power. The solution is to unplug the USB cable to the USB/serial device. This is unfortunate, but what can you do.

The blink2 demo

This is the last bit of work I did. This is bare metal code. It has a bitstream compiled into it, and it loads that bitstream each time it boots. Currently the bitstream for this demo is my "fancy" ledio.bit bitstream which allows access to the two LED via writes to an AXI gpio port. This is described in comments in the demo itself.

Vivado

I am currently still using 2019.1, though Xilinx has notified me on countless occasions that there are new versions available.

Vivado "remembers" all of my projects. The code and files for them resides in /home/tom/vivado. The "fancy" ledio project is actually "ebaz_blink_4" in the Vivado world and the verilog is at: 

/home/tom/vivado/ebaz_blink_4/ebaz_blink_4.srcs/sources_1/new/fancy.v

XVC and xvc-pico

This is "bonus information" you don't actually need.

I flashed xvc-pico and use the Pico as a Xilinx Virtual Cable (which is one of the options that Vivado understands to access the FPGA over JTAG. My notes are here:

Along with connecting this and plugging in the USB cable, you also need to run a server. This is "xvcd-pico" and I usually set aside a terminal for this, and type this on the command line. 
[tom@trona tom]$ xvcd-pico
xvc-pico listening on port 2542
I made the trivial hack to the code so it tells me it is listening on port 2542.

I can then do this: 

[tom@trona blink2]$ make pl
openFPGALoader -c xvc-client --file-type bit ledio.bit
detected xvcServer version v1.0 packet size 1024
It has a progress bar and takes quite a while. While it is loading, the green LED (LED1) next to the Zynq goes out, and it comes back on when the bitstream is loaded.

In the current state of the blink2 demo, this is useless and actually counterproductive. It works, but then software needs to be told to write to the GPIO port to configure the blink state. It is both faster and simpler just to compile the bitstream into the software and let software load it and then do the write to configure it.

Conclusion

This is enough (and a bit more) to enable me to run one of my old demos. Another "cheat-sheet" that explains how to use Vivado would be a worthwhile but additional task.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org