SoC Projects
Background: Tiliqua SoC designs
Many Tiliqua projects contain an SoC alongside the DSP logic, in an arrangement like this:
Overview
At a very high level, we have a vexriscv RISCV softcore running firmware (written in Rust), that interfaces with a bunch of peripherals through CSR registers. As the Vex also runs the menu system, often there is a dedicated peripheral with CSRs used to tweak parameters of the DSP pipeline.
PSRAM
PSRAM bandwidth is important to keep under control. For this reason, the SoC only interfaces with the PSRAM for text/line draw operations. Normal instruction and data fetches are to a local SRAM and so do not touch external PSRAM (which is usually hammered with video traffic).
TODO: describe each peripheral in detail
All Projects
polysyn
8-voice polyphonic synthesizer with video display and menu system.
The synthesizer can be controlled through touching jacks 0-5 or using a MIDI keyboard through TRS midi. The control source must be selected in the menu system.
In touch mode, the touch magnitude controls the filter envelopes of each voice. In MIDI mode, the velocity of each note as well as the value of the modulation wheel affects the filter envelopes.
Output audio is sent to output channels 2 and 3 (last 2 jacks).
Input jack 0 also controls phase modulation of all oscillators, so you can patch input jack 0 to an LFO for retro-sounding slow vibrato, or to an oscillator for some wierd FM effects.
A block diagram of the core components of this polysynth:
xbeam
Vectorscope and 4-channel oscilloscope with menu system.
In vectorscope mode, rasterize X/Y (audio channel 0, 1) and color (audio channel 3) to a simulated CRT.
In oscilloscope mode, all 4 input channels are plotted simultaneosly in classic oscilloscope fashion.
macro_osc
‘Macro-Oscillator’ runs a downsampled version of the DSP code from a famous Eurorack module (credits below), on a softcore, to demonstrate the compute capabilities available if you do everything in software.
All 24 engines are available for tweaking and patching via the UI. A couple of engines use a bit more compute and may cause the UI to slow down, however you should never get audio glitches. A scope and vectorscope is included and hooked up to the oscillator outputs so you can visualize exactly what the softcore is spitting out.
The original module was designed to run at 48kHz. Here, we instantiate a powerful (rv32imafc) softcore (this one includes an FPU), which is enough to run most engines at ~24kHz-48kHz, however with the video and menu system running simultaneously, it’s necessary to clock this down to 12kHz. Surprisingly, most engines still sound reasonable. The resampling from 12kHz <-> 48kHz is performed in hardware below.
Jack mapping:
In0: frequency modulation
In1: trigger
In2: timbre modulation
In3: morph modulation
Out2: ‘out’ output
Out3: ‘aux’ output
There is quite some heavy compute here and RAM usage, as a result, the firmware and buffers are too big to fit in BRAM. In this demo, the firmware is in memory-mapped SPI flash and the DSP buffers are allocated from external PSRAM.
Credits to Emilie Gillet for the original Plaits module and firmware.
- Credits to Oliver Rockstedt for the Rust port of said firmware:
The Rust port is what is running on this softcore.
sid
selftest
Collect some information about Tiliqua health, display it on the video output and log it over serial. This is mostly used to check for hardware issues and for bringup.