Wonderful. Thanks so much Aman. Great explanation, I’ll have a quick look at this tonight. This is going to be fun ![]()
Ges
Wonderful. Thanks so much Aman. Great explanation, I’ll have a quick look at this tonight. This is going to be fun ![]()
Ges
This is really compelling, and some of this is new to me, so I’m half grokking how all the hardware units work together, really.
But as someone who has a Bela MINI, and enjoys the idea of a dedicated embedded system, esp. a customizable one that might even be bare metal and ultra-efficient, this is exciting work.
I’d love to see this process step-by-step documented at some point as a HOWTO for DSP hobbyists. Having a “hive-mind” of enthusiasts be able to follow in these footsteps and yet add further explorations and customizations is a nice vision of the future, and seems like a great way to enjoy working with these newer embedded system technologies.
In any event, hats off to Aman and Victor for sharing, and Ges and Lovre for chiming in with illuminating knowledge.
Lovre, I learned more about FGPAs in your post than I did from any online searches, thanks for sharing this info.
It’s cool to see so much interest in this.
Well, that was fun.
I fired up my Ubuntu 22.04 dev PC (a Dell optiplex 990 with 8GB ram and a 500GB HDD) that I had previously set up with the Vitis/Vivado 2022.2 tools for my investigation into the Syfala software.
After a couple of failed attempts I realised that the Ubuntu default install had only set up a 2GB swap (virtual memory) and the Vitis tools require much more than that.
So, I created an 8GB swap partition and turned swapping on (if you can afford 32GB of physical RAM then that will be much faster).
I used the system monitor app to view system resources during Vitis runs and sure enough my system crashes went away (at least for now).
For background info:
I then fired up Vivado, created a simple design, imported the ip block and let Vivado automatically connect everything for me. No errors came up, design met timing constraints and I’m ready to start writing baremetal code!
Great work Aman, this is so fast, flexible and powerful and has opened up a world of sonic fun to keep me happy into my dotage :-). IMO this is much quicker, simpler etc than Syfala and just fits so much better into the wide and varied Csound ecosystem.
I’ve attached a pdf of the design as exported from Vivado.
Feel free to contact me on this email address if anyone wants more info on the tools etc. but I’m going to go quiet for a while now and let Aman get on with his work. I’m free to do any testing if needed but I’m sure Aman and Victor have a roadmap to follow.
Cheers
Ges
ReverbSC.pdf (71 KB)
That’s really interesting, Ges. Good to have the code built independently for a different board.
Did you try the baremetal Csound too? I think the interaction between FPGA and Csound is one of the most promising things
in this setup.
best regards
Hi Victor,
Indeed, I’m really excited about the possibilities here.
I haven’t compiled the baremetal yet. I couldn’t see it in the github code I cloned but I’ll take another look.
I was particularly pleased how easy it was to select the Zedboard as a target. I might take a look into how Syfala use the codec chips on the Zybo and see if I can adapt it to the one on the Zedboard. Being able to offload the output to DMA/I2S would be logical for these target boards.
Cheers
Ges
It’s straight Csound from develop, Aman can give instructions.
Cool, thanks.
Ges
Dear Aman,
Could you point me towards some hints on getting started compiling the baremetal code please.
I’m fairly experienced at compiling and debugging on the Zynq platform but this is my first attempt at cross compiling Csound so I want to make sure I get the dependencies right etc.
There’s no hurry for me and I don’t want to be a support headache but I’d love to try and recreate your demo on my Zedboard.
Regards
Ges
Hi Ges,
First you will have to install the arm embedded toolchain:
https://developer.arm.com/downloads/-/gnu-rm
I have put the crosscompile file for the zynq on the github repository I had sent earlier. You can use that along with this cmake command to build csound for bare metal from the develop branch:
cmake -DCMAKE_TOOLCHAIN_FILE=<path_to_crosscompile_file>/crosscompile.cmake -DUSE_ALSA=0 -DUSE_JACK=0 -DUSE_IPMIDI=0 -DUSE_PORTMIDI=0 -DUSE_PORTAUDIO=0 -DUSE_PULSEAUDIO=0 -DDEBUG_ERROR_ON_WARNING=0 -DUSE_DOUBLE=0 -DUSE_LIBSNDFILE=0 -DBUILD_STATIC_LIBRARY=1 -DUSE_PORTMIDI=0 -DBUILD_MULTI_CORE=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE=1 -DBUILD_CSBEATS=0 -DBUILD_CSOUND_COMMAND=0 -DBUILD_PERFTHREAD_CLASS=0 -DREQUIRE_PTHREADS=0 -DBUILD_CPP_OPCODES=0 -DBUILD_DSSI_OPCODES=0 -DBUILD_OSC_OPCODES=0 -DBUILD_PADSYNTH_OPCODES=0 -DBUILD_SCANSYN_OPCODES=0 -DBUILD_DEPRECATED_OPCODES=0 -DBUILD_UTILITIES=0 -DBARE_METAL=1 -DCMAKE_INSTALL_PREFIX=<install_directory> …
Then in Vitis IDE you can point to the libcsound.a installation directory from the properties menu of your software application project. You can also add the include path for csound in that menu.
Once that is done you can use csound through the API in your software application. I will add a complete Vitis software example to the repository soon as well that takes care of sending csound’s audio data to the FPGA via AXI DMA, initializing the I2S transmitter (we use the pre-packaged xilinx I2S transmitter IP), configuring the audio codec, setting control parameters for the modules, midi over UART etc.
Hope this helps!
Thank you,
Aman Jagwani
Thanks Aman, that’s great. Hopefully I’ll get a chance to look at this tomorrow night and over the weekend.
I should have looked to see if there was a Xilinx I2S IP. I’ll incorporate that into my playground block design and look forward to seeing your design when you are ready to share.
I’m new to cross compiling for Arm on an ubuntu PC and I was just stumbling on deciding which compile tools to use so thanks for pointing me at the GNU tools you’re using.
Once I get back to Vitis I’ll be on more familiar ground re: importing the hardware design etc.
Currently reading the fine manuals on the API and I’m impressed with how much work and info has been already done, especially by Victor.
Plenty here to keep me busy for now so I’ll leave you guys to it and I’ll report back if I make significant progress.
Cheers
Ges
Hi Aman,
Sorry to be a pain but I’ve been trying to get libcsound.a cross compiled and have installed (and verified they’re being used) the gnu cc compilers etc. but am just wondering if there is a simple fix to get the libsndfile dependencies resolved
I’ve installed Emscriptem and NPM but still not got to a point where I get no errors compiling the csound sources.
It just feels like I’m missing a crucial step in setting up my project directories, tools, include files etc…
No worries if you’re busy atm, I’m obviously new to cross compiling csound, but part of the journey is to understand the complete toolchain and how to make it work
Once I’ve done that I generally rip-up, repeat, document and then do it all again one more time just so I can recreate easily in future.
Cheers
Ges
Hi Ges,
libsndfile is not used in baremetal. Csound has no dependencies there. Just build libcsound.a with the CMake options Aman gave, that will include one to exclude the use of libsndfile.
best
Prof. Victor Lazzarini
Maynooth University
Ireland
Hi Victor,
Yes, that’s what I thought. For some reason I’m getting a message about not being able to find libsndfile.
OK, I must be doing something dumb. I’ll dig deeper this week. Time’s limited right now so I may go quiet for a few days at a time. Nonetheless it’s been good to learn how the cross compilation works. I’ve always worked exclusively in Xilinx SDK and on Windows before so I’m happy to be building from command line in Ubuntu at last.
Cheers
Ges