I am inspired by the work Ian Fritz (frijitz) is doing with chaos circuits in the analog domain. I wondered if it might be possible to get useful results using digital methods.

So far, so good. I've written a Lorenz attractor design for FPGA that talks to a DAC and sends the X and Y outputs to an oscilloscope.

My method uses 64 bit fixed point arithmetic and does not seem to suffer.

It does, however, use a large amount of FPGA real estate. Not enough to prevent a monosynth in a small FPGA.

Currently, I'm designing a MIDI FM synth that uses the Lorenz outputs as modulators. The speed of the Lorenz system is controllable from LFO range to well into audio frequency._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

I got involvled with studying the soultion to the wave equation with the finite difference method to implement a string physical model. This has turned out to be more of a math learning experience than a practical exercise. What I discovered is that while the finite difference method can present a more accurate model of piano string (for example), the algorithm requires substantially more computing power and storage than the Karplus-Strong digital waveguide method. It doesn't seem to me that a harp with a large number of strings is possible in a low end FPGA. Perhaps when I get a big fat one...

I'm trying to weigh what would be the best project to do. I don't want to do something that is so complex that it won't fit. I do mental calculations (ok, guesses) as to how much structure and functionality I can implement and I'd like to stay away from marginally large designs because of the shoe-horn tweaking one does to cram it into a device that is almost too small.

It's down to one of several possiblities, an additive flute, a 4 string Karplus-Strong bass synth and a 4 voice FM bell synth._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

My previous Lorenz design used a 64x64=128 bit signed multiplier inferred by ISE for the Lorenz Attractor calculations. Although it could do the multiply in one clock (38.4 MHz), that multiplier used 16 dedicated 18x18=36 hardware multipliers (which also disables the associated BRAMs) and a couple of pretty big adders. That much resource usage would have precluded adding synth hardware to it.

I've just tested new multiplier code that takes 5 clocks instead of 1, but uses only 4 dedicated multipliers for the same precision. I have plenty of clocks per sample, so this isn't a problem. I've got it running on my oscope right now.

The extra FPGA real estate freed up will go to an FM monosynth that will be modulated by the Lorenz outputs.

It's currently running on an Avnet Spartan-3A 400 board. I want to finish development there and then move it to a Spartan-3E board (because the SDRAM echo/delay is way fun and makes a monosynth a lot better)_________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

I've moved the code from the Spartan-3A 400K board to a Spartan-3E Starter Kit. The FPGA is 20% larger and better accomodates the design (so far).

What I have is a version of the 16 voice FM bell synth cut down to monosynth and I added the Lorenz code as a module that the synth can use. As such, the design consumes 74% of slices (which is tight, but appears to compile without timing constraint violations). Because the usage is high, I don't know if I'll be able to apply a lot of external control, but we'll see where it goes. I'm about to attempt a modulation experiment and I'll post a sound file when I get that done.

The Lorenz code is quite fat, using over 30% of slices all by itself. The reason is that this kind of algorithm requires high precision arithmetic. The current design uses a 64x64=128 bit signed multiplier and much of the internal data is stored in 128 bit registers. 10.54 fixed point._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

In fact, the equations themselves don't change, but the implementation at a code level is a little different.

In this case and within the FPGA, I used a 10.54 method. This means that of the 64 bits used, the structure of the fixed point binary is 10 bits of integer and 54 bits of fraction. The integer contains the sign, so 9 of the bits describe the actual integer absolute value magnitude.

Fixed point binary is done using integer arithmetic and there is no prescale bit shifting necessary as is the case with floating point. One must be careful that the radix point (binary point in this case) remains aligned when doing adds and subtracts. This is exactly the same sort of thing you do with a pencil and paper when you do arithmetic. The principal is identical.

There is some good information on the internet regarding fixed point binary arithmetic.

I am attaching Lorenz.c, a file which contains a fixed point implementation in C (using 33.31 fixed point). It also contains a commented out portion of code at the bottom that implements the Lorenz Attractor in floating point. The program was used to determine the maxima and minima of the output variables X, Y and Z. This information was used to decided how many integer bits were necessary to represent the output values in fixed point binary properly.

Note that the fixed point implementation is not directly supported in C. I had to craft the implementation using arithmetic right shifting to keep the magnitude to scale. Comparing the fixed point with the float should give you an idea of what needs to be done to convert a float design to fixed point.

The main advantage to fixed point is that adds and subtracts and sometimes even multiplies can be accomplished in only one clock cycle (in an FPGA). Using floating point would require more clocks depending on the operation.

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessimaLast edited by JovianPyx on Mon Mar 19, 2012 6:02 am; edited 2 times in total

I have a working FPGA design of an FM monosynth (4x2op) with 3 of the carrier to modulation ratio parameters modulated by the output of a Lorenz Attractor digital model.

The synth also has echo/delay, so I used some of that too.

Other attractors could be substituted by replacing the Lorenz module with a state machine that does whatever attractor desired.

Here is a demonstration audio file I made while doing my first tests of the system. I made changes to the h parameter and occasionally to the integer setting of the carrier to modulation ratio (which caused what sounds like new notes). The design was pieced together out of other finished designs. I need to add more control over the parameters of the synth, but as a proof of concept, I think it works.

I found some problems with the synth which I've fixed. I also lowered the range of the h parameter. Most of the upper range produces a noise like character, so I gave up some noise range for more of an LFO range.

Here's another sample, it's a drone using only the 3 operator pairs that are affected by the Lorenz Attractor.

Your idea modulated three band pass filter si great - please make more this great projects. This is very interesting for me.

Kamil

P.S. is possible post me final working lorenz attractor verilog file ? (previous file is only concept - im begginer in verilog and not understand how make final module) - very thanks_________________Sorry my bad English

Here is the Verilog source code for the synth and the VB.NET project for the patch editor.

The patch editor is a modified version of the FM Bell Synth Patch Editor and should work with both synths. The 'h' parameter control (lower left corner of the window) was added for the Lorenz version and controls the speed at which the Lorenz Attractor evolves over time. Lower values are more like an LFO. The 'h' parameter does not affect the bell synth.

The synth design is a proof of concept and is somewhat primitive from a control standpoint. I.e., there is only a control for the h parameter. The a, b and c parameters and starting conditions can be changed directly in the Verilog source code or you can modify the patch editor and Verilog source code to allow controlling these from the patch editor.

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessimaLast edited by JovianPyx on Thu Mar 22, 2012 7:26 am; edited 1 time in total

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.