I’ve been exploring Yosys / NextPnR / Project Trellis on some Lattice ECP5-based boards recently, and I’ve been very impressed and enthused by what I’ve seen. I do have to admit, though, that it’s not “there” yet, especially when it comes to SystemVerilog and VHDL support through the ghdl-yosys-plugin. Yes, you can develop and compile “real” projects with Yosys and friends, but you do have to keep the toolchain’s limitations in mind and design around them.
For this reason I wanted to install and try the “official” software for ECP5 development, namely Lattice Diamond. This left me with a slight problem in that it’s only available on Windows and Redhat Enterprise Linux 6 or 7, with the software distributed in RPM format.
Continuing my experiments with the IceSugar-Pro board, building cores using Yosys and friends, I now have EightThirtyTwoDemos running, using PMODs to provide VGA out, I2S audio out, PS/2 keyboard and mouse, and SD card. (The latter isn’t strictly necessary since the FPGA board already has an SD card slot – but it’s on the underside of the board and impossible to access while the IceSugar-Pro is inserted into the carrier board.)
So how did I go about wiring up the PMODs?
Coping without SignalTap – Part 3 – 2022-04-28
I’ve found the bug which was preventing interrupts from working with the EightThirtyTwo CPU, at least in the EightThirtyTwoDemos projects…
Coping without Signaltap – Part 2 – 2022-04-26
By the end of part 1 I was able to communicate over JTAG with a design running on the IceSugarPro, remotely control the LEDs on the board and read the contents of a wide register through a FIFO queue.
That’s the barebones of a useful debugging subsystem, but to be truly useful we need the ability to set a trigger condition.
2022-04-19 – Part 1: Establishing communication
If I’m going to find the problem with EightThirtyTwo that’s preventing interrupts from working, I’m going to need some way of observing what’s going on. The CPU works in GHDL Simulation, works on Altera/Intel chips, and works on Xilinx chips so there must be something I’m doing which the Open Source toolchain doesn’t like. (Or I may have stumbled upon an actual bug…)
There are basically three problems to solve here:
- Capturing the state of internal signals
- Transporting those signals to the host computer
- Displaying them in a meaningful and readable format.
I’ve been tinkering with the IceSugarPro board recently, which is a nice little SO-DIMM form factor FPGA board containing a Lattice ECP5 FPGA. It’s the successor to the earlier IceSugar board which contained a Lattice iCE40UP5k: despite not having an iCE40 series chip, the IceSugarPro retains the name!
I’ve been experimenting with the QMTech Kintex7 board, which provides a huge FPGA for a less huge amount of money. The one thing that prevents my existing projects from running on it without deep changes is the lack of SDRAM, but since I’ve been wanting to get more familiar with the Xilinx ecosystem for a while, this was a good opportunity to dive in.
I wish I was joking. 2022-01-14
That appalling joke has been doing the rounds for a few years now – but apparently 1024×768 really is my New Year’s Resolution, since I just made the mistake of allowing Linux Mint to update itself, and now it won’t do anything higher.
Oh well, while I’m being old and grumpy, I might as well get something else off my chest:
You know what I miss? Web forums.
Sigma Delta without Math – Part 2 – 2021-12-04
Last time around I talked about strategies for halftoning graphics, and made the key point that “noise” and “objectionable noise” are not the same thing.
I haven’t yet mentioned, though, the class of dither patterns which has been used most commonly since the advent of the desktop printer – namely Error Diffusion.
So I’m still, in between tinkering with FPGAs, trying to settle upon a Linux distro for desktop use. I still keep coming back to Mint Mate edition despite the annoyances I’ve found with the latest version, and having installed both an SSD and some extra RAM in the machine I’m about to migrate to, I figured I’d better run some tests. The Ubuntu (and thus Mint) live install contains Memtest86+ so I booted from USB, selected the test and watched the machine lock up half way through the very first test.
Odd, since the machine actually runs just fine…
It turns out the version of Memtest86+ in the current Ubuntu LTS is completely and horribly broken.
The solution to my problem was to install memtest86+ using apt, then remove it again. The removal doesn’t remove the meta files, so provided there’s an image of the correct name in /boot it remains in the grub menu. Therefore, one can download a non-broken binary, copy it to /boot, run grub-update and *now* the RAM test actually works.
One side-effect, however, is that the grub setup installed by the USB live system when installing Linux is somewhat different from what you get when you subsequently run grub-update from the installed-and-running system – I had to edit some config files to get the menu back..