Exploring audio DACs in simulation – Part 2 – 2021-04-02
Having rambled on a little longer than I intended while setting the scene for these experiments, I’m going to set up a simple testbench with verilator to evaluate the performance of several different DACs.
Exploring audio DACs in simulation – Part 1 – 2021-03-21
When I was developing EightThirtyTwo I made good use of GHDL, which allowed me to run the CPU’s VHDL code in simulation and output traces of internal signals for viewing in GTKWave.
Now I’ve started exploring Verilator for simulating Verilog code, and it’s safe to say I’m very impressed!
So a little back-story is in order: [Ok, it turns out there’s so much back-story I didn’t actually talk about Verilator – next time, I promise!]
Some years ago I spent some time trying to improve the audio output on Minimig, and encountered some strange counter-intuitive problems. Originally the DAC used by Minimig was a simple 1st-order Sigma Delta DAC. These have pros and cons:
…three useful things about Quartus – 2021-03-14
Porting a Core, DeMiSTified – Part 6 – 2021-03-12
When I created a ZPU-based control module for the MSX and PC-Engine cores way back when, I created a menu system which used a tree of static menu structures, in which each elements could be one of several types.
I supported function callbacks, checkmarks, cycles and even sliders. It worked fairly well and the footprint was reasonably small – but it doesn’t lend itself to building a menu dynamically.
In order to build an arbitrary menu from a MiST config string using this system I would need to support memory allocation, which means managing a memory pool, and if the menu ever needs to be re-generated, potentially dealing with fragmentation. Doing any of this without bursting through the self-imposed 12k limit is unlikely to happen!
Porting a Core, DeMiSTified – Part 5 – 2021-03-07
I’m not going to go into great depth regarding the substitute controller module which I’m using for this project, since I’ve covered much of that ground in previous posts (see the previous series about the ZPU-based control module, the TG68_MiniSoC project and also EightThirtyTwoDemos) – in all cases I have a soft CPU with a number of memory-mapped hardware registers, and I’m following much the same pattern this time around.
Briefly, I have a UART for serial debugging output, an SPI chip select register which allows one of several SPI channels to be selected, an SPI data transfer register, a simple interrupt controller, PS/2 keyboard and a simple timer in the form of a millisecond counter. I also have a joystick input register, since the controller will be responsible for relaying joystick events into the guest core.
So having created a CPU and peripheral module which we can connect to the guest core, all that remains is porting the firmware, yes?
Porting a Core, DeMiSTified – Part 4 – 2021-03-03
(Before I start this installment, I should say that I have now released the Chameleon port of the NES core – I’m not going to delay the core just to talk about the process!)
So we have a project file for the MiST version of the core, and we need to create project files for other platforms. My scripts and Makefiles will produce these files, so what I need to do is extract a list of components from the .qsf project file for MiST.
Porting a Core, DeMiSTified – Part 3 – 2021-03-01
When an FPGA core is a self-contained standalone project with only one target board, managing the project from within the FPGA vendor’s IDE works fine. However, once there’s a significant amount of shared code between projects, or you’re building for multiple targets, things get more tedious,
EightThirtyTwoDemos currently has targets for nine different boards, and there are another four within easy reach that I could add if I wished. There are nine demo projects in the repo, so I could have to rebuild as many as 81 projects when something changes. Loading each project, one after another, and rebuilding them manually would be ridiculously inefficient – a better solution is needed.
Porting a core, DeMiSTified – Part 2 – 2021-02-25
The goal is to provide an environment in which a MiST core can be included as a submodule, thus porting the core to a new target board without making large-scale changes. To do this, we’re going to need a toplevel for each target board which maps the signals of MiST’s FPGA to board-specific resources.
Let’s take a close look at a MiST core’s toplevel…
Porting a Core, DeMiSTified – Part 1 – 2020-02-24
There are many FPGA cores out there which could be ported to the Turbo Chameleon 64 cartridge. In some cases it’s just a question of somebody doing the legwork, in other cases it gets a little bit more involved – but can we do anything to make the amount of work required more manageable?
Long-time readers will know by now that I don’t ask that kind of question out loud unless I already know that the answer is yes!
I’ve just bought a couple of the ridiculously cheap DECA MAX10 dev boards from Arrow and one of the first projects I attempted to port to it gave me an error message I wasn’t expecting:
Error (276003): Cannot convert all sets of registers into
RAM megafunctions when creating nodes. The resulting number
of registers remaining in design exceeds the number of
registers in the device...
Hmmm, OK, what’s going on here? For some reason the ROM in my project isn’t getting recognised and implemented as initialised block RAM – what gives?