see www.fpga.synth.net
Home page

    This page is about my use of the materials from www.fpga.synth.net which is a very interesting set of working sound synthesizer designs with Open Source verilog and assembly files, which I´m in the process of trying or adding to.

I of course have done work in synthesis myself (Open Source DSP analog simulation with programmable logic, and a complicated string simulator), and also with FPGA´s (like here, but that isn´t sound synthesis).

   Recently there has been discussion since I suggested the Plasma processor to be used in conjunction with specific FPGA synth fabric, about using the eco32 processor (a 32 bit RISC verilog processor) for such purpose.

The previous version of this page contains a lot of info about FPGA synth subjects I sometimes worked on.


A little info about what I've worked with, apart from my previous page on FPGA synthesis of sounds, which used to reside a this URL on my server.  I've had a wiki running, too, but I shut it off because it got used rarely and attracted a strange amount of spam. I could run it and safeguard it, I looked into it, that would be possible, so if there is interest, I could run it again.

I've used the latest Scott Gravenhorst designs with some pleasure testing them, like the FM synthesis with SDRAM delay for instance. I've installed MONO on my Fedora 14/64 computer to also run the patch editor software he wrote in Visual Basic, which works.

Below some recent work regarding the use of Eco32 RISC processor (see also here ) because I thought about using the Plasma processor for that but  ran into difficulties I didn't want to solve by doing quite a bit of work, and Hellwig Geisse proposed to port the working processor to the Xilinx Spartan 3e-500 sk board I have. It appears a neat processor, which already runs, has flash read access, (for me) working assembler and data conversion tools, doesn't use too many resources (yet..) has nice console (VGA output) and goodies like memory management, and of course it is fully Open Source.

In general i like the idea of a processor integrated with a FPGA, like most clearly the future has more usable computer power with a platform like ZiNQ (Xilinx ARM dual core processor on 28 nm with quite big and  fast FPGA around  it on the same chip, with various partial reprogramming options, even secure ones, and vary fast processor connections. Nicer idea than all kinds of Neanderthal machines not able to communicate more than a bit and organized in speedways most people don't know about, so I like this type of experimentation, maybe to create some microprograms, work with multiple (bootup) FPGA configurations, combining various processors and softrare libraries and making sound synthesis fun again. Also I'd really like to get a working, Open Source ethernet interface for the Spartan board.

Early Eco 32 experience

I've looked at all the phases of the port thus far, verlog compiled and assembled the examples and verified on my Spartan 3e-500 starter kit board that things work (this project).

Porting information

All seems to work with little effort (some tools requires the "-m32" compiler directive to be removed from the Makefiles to compile with my gcc 4.5.1), and the verilog importing and silicon compilation posed no problems. I did have 'issues' with the compiler, based on lcc, which in essence doesn't compile on my recent Fedora 64 bit systems. My latest test trying to neatly follow the prescription of the installation still gets me errors in the tests like "cannot find stddefs.h", warnings about incorrect pointer to integer conversions (would seem important to me for a compiler) and two of the tests (amoung which the C test program "paranoia.c") completely bum out.

Also I don't think i understand or like why the include files of the workstation compiler (the one used to compile LCC) must somehow be in the source tree, that might account for the very long list of label number mismatches between the lcc-compiled assembly and the provided "right answers" I appear to get.l

Sjeesh, it would be good to have a well optimizing gnu gcc as an alternative.
The idea of having the compiler somehow in Flash  on the board is interesting though, and of course Open Source does not mean "but you can't compile it"..

Combination Experiments

Two thus far.

adding SDRAM

I've tried to combine the first or second eco32 project from here with the Scot Gravenhorst SDRAM test software, mentioned here. The result of merging the top level code and the UCF file is here:


The guidelines from Scott still aply to get the right pattern (pressing South button and Rotary Knob), while the VGA interface shows the welcome screen.

A combined project with the Xilinx frequency counter

I thought I'd bring together a nice Xilinx project, the Frequency Counter (Ken Chapman) with a picoblaze and clear general usability with a working version of the eco32 project (monitor in flash, console and keyboard). In essence the combination of the vhdl FC and the verilog eco32 worked in my case by making a top level schematic, and instancing both parts after turning their respective top-level design entities into a schematic symbol, and merging the .ucf files.

Of course the display of the FC doesn't really work yet, because the eco32 is in constant flash 16-bit read mode, so there is no time left for the bus to sync in a picoblaze write to the LCD. Feel free to make  it work... I probably will look into it a bit, because I find it interesting to have such designs combined. For those wanting to try it out, here are the project files, minus the frequency counter (copyrighted) files:


Firstget the FC project to run (I switched off the test DCM I think, it'S little work), and put the resulting .vhd file in the subdirectory "Imported/" after which the project (ISE 13.3) should compile.

The result is that when the lowest 4 bits of the upper flash byte output change (I suppose when  the monitor is active) the display sometimes changes, but it doesn't show the frequency counter output, the LEDs do work, and so does the monitor rest (south) button.

Oh for those interested I found that the picoblaze assembler *can* be run on Linux, by using "dosemu -E ./KCPSM3.EXE", the emulator could in my case easily be installed by "yum install dosemu.x86_64". So now I can on one machine develop picooblaze code without having to get a windows machine with shell, etc.

Some Xilinx webpack experience

I still don't know if I can delete the untar-ed ISE distribution files after install, and of course it must be remarked these tools sets and FPGA/CPLD data files are large (about 12 gig after install), but ISE 13.2 and .3.

The linux 64 bit version works good, but it was impossible to get Impact to work except after removing all the (I opted for that, so don't ..) linux drivers like "windriver"  from /usr/local/lib from the the kernel sources (use "find" to search for the libs mentioned in the .xinstall log after havinf used xinstall ), modrm -ed from the kernel (use e.g.  lsmod | grep <driver names>) and following the steps and compiling of this Open Source software , which does work great (on my 3e board, two different machines), fast and thus far appearently no errors, even when switching the board on and off. I've since tried the spartan 3e direct programming many times, the flash programming, and the coolrunner XC2 programming via Impact, all worked.

I suppose it is a commercial option to run the design tools in parallel form (like on my I7s), and the same for partial reconfiguration.. The linux ISE and IMPACT do work on a remote X screen, and the outputs and options set appears to have been improved.

 By Theo Verelst       Home page     email     Updated Dec 19, 2011