[sdiy] Digital accumulator VCO core?

Brian Willoughby brianw at audiobanshee.com
Wed Feb 10 00:43:27 CET 2021

It's always good to try out different approaches to similar problems to learn which is the best for a given problem. Visualization of the building blocks (or logic structures) is very helpful.

I recommend that you add full DSP chips to the list, between FPGA and MCU (or softcore). The DSP teams have literally been working with signals problems for decades - audio and other signals. You'd be amazed at how many parallel paths are available that are simply missing from most MCU chips.

For example, the TMS320VC5506 has 128KB of SRAM. Half of that can be accessed on every clock cycle, the other half can be accessed *twice* per clock cycle. Both halves are broken into eight address ranges, where each range can be accessed simultaneously during the same clock cycle. The opcode execution unit has three read busses and two write busses available, meaning that well-written code can shuttle five full words of data in a single cycle. Besides the execution unit, DMA can link timers and other peripherals directly to memory to use some of those pathways that the code isn't utilizing.

As I worked on my '5506 project, I realized that it was exactly like Texas Instruments had been researching all the building blocks / logic structures that I might possibly need, and had already baked them into the hardware in tested modules that were very reliable. Of course, I still managed to find the breaking point of the system. That's always the case.

In case you haven't noticed, I believe that the DSP is the underdog these days, and doesn't get the credit it's due - at least when selected for the right problems.


On Feb 9, 2021, at 15:27, Eric Schlappi wrote:
> The ice40 chips are pretty low power and come in lqfp and you can certainly do all the other things you mentioned.
> Debugging is not fun though, writing testbenches for everything is not as easy as just stepping through the code, though if you put time into learning formal verification it seems to help a lot. I can only speak from the yosys/nextpnr workflow.
> The FPGA opens a lot of options as long as you can visualize the logic structures you are instantiating. Still learning about which things are better to use a microcontroller (or softcore) and which should be built in logic.
> On Tue, Feb 9, 2021 at 3:16 PM Brian Willoughby wrote:
>> Those are good points, Eric.
>> Another downside of FPGA designs is that they can consume a lot more power than a purpose-built DSP. They're certainly all the rage right now, but that doesn't guarantee that they're the best choice.
>> Companies like Texas Instruments make DSP chips like the TMS320 C5000 family that can run quite a while on battery power. They've been fine-tuning the transistor count for signal processing for decades, and you can get quite a lot of parallel processing going on - literally parallel, not just multi-tasking - to solve signal processing challenges. They have timers, DMA, synchronous serial ports for digital audio streams and ADC/DAC/CODEC interfacing, and five separate busses for read and write access to multiple memory banks. It's amazing how much data can be moving around without software interaction, while still having code handling the complex parts.
>> Another positive for DSP chips is that they can be obtained in packages like LQFP that aren't as problematic as BGA or QFN.
>> Personally, I find it much easier to design with a part where I can write in a language that allows stepping through the code and quick iteration of ideas. Texas Instruments has JTAG interfaces that allow you to graph time domain and frequency domain signals within the chip memory in real time. I'm not aware of tools for FPGA that allow so much debugging support.
>> Brian
>> On Feb 9, 2021, at 12:23, Eric Brombaugh wrote:
>> > Interesting idea. The trouble is that there are a few downsides to
>> > typical modern FPGAs that make them hard to integrate as a pre-
>> > programmed drop-in parts. Most FPGAs require some sort of external non-
>> > volatile configuration memory, plus multiple supply voltages, clock
>> > oscillators and are typically only available in SMT packages.
>> > 
>> > The particular Lattice parts I've been using lately do have on-chip NV
>> > memory so they could be delivered pre-programmed, but they require 3.3V
>> > and 1.8V supplies and come only in BGA or QFN packages. For most DIY
>> > folks that means an assembled DIP module would probably be most user-
>> > friendly.
>> > 
>> > One other downside is that it's difficult to do an accurate 12-bit ADC
>> > using only resources on most FPGAs. I have done lower resolution ADCs
>> > using PWM and comparators, but they're pretty slow and noisy so the
>> > control voltage input for a digital oscillator would need an external
>> > accuate ADC for best results.
>> > 
>> > Overall, a pre-engineered FPGA solution can be done, but there would be
>> > some trade-offs.
>> > 
>> > Eric
>> > 
>> > On Tue, 2021-02-09 at 14:11 -0500, Aaron B. wrote:
>> >> 
>> >> I would absolutely buy FPGAs preprogrammed as sawtooth-only DCOs
>> >> like this, and build analog waveshapers around them. Sounds like a good
>> >> compromise across sound quality, tracking/temperature stability, parts
>> >> count, and ease of tuning.

More information about the Synth-diy mailing list