electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » Developers' Corner
FPGA designs
Post new topic   Reply to topic Moderators: DrJustice
Page 2 of 2 [38 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Goto page: Previous 1, 2
Author Message
jksuperstar



Joined: Aug 20, 2004
Posts: 2489
Location: Denver
Audio files: 1
G2 patch files: 18

PostPosted: Tue Jan 29, 2008 2:32 pm    Post subject: Reply with quote  Mark this post and the followings unread

Do you do any time multiplexing of logic Scott?

IE - With an operating frequency of 100MHz, and your own internal sample rate of 1MHz, you could generate 100 sine waves without any added latency or logic (other than some needed to mux the data/control going in & out).
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1249
Location: West Red Spot, Jupiter
Audio files: 161

PostPosted: Tue Jan 29, 2008 2:52 pm    Post subject: Reply with quote  Mark this post and the followings unread

jksuperstar wrote:
Do you do any time multiplexing of logic Scott?

IE - With an operating frequency of 100MHz, and your own internal sample rate of 1MHz, you could generate 100 sine waves without any added latency or logic (other than some needed to mux the data/control going in & out).


The system clock on my board is 50 MHz. So I have 50 clocks per sample. I use a state machine since my NCOs and noise generators are RAM based. Each NCO requires several clocks because of the features. The reason 4 NCOs takes up so much space is that it's 4 NCOs that have a lot of features. A lot of that hardware is shared by with the state machine, tradeoffs - either more NCOs and fewer features or more features and fewer NCOs, plus a high sample rate. The synth has synch, 4 waveforms including PWM, noise modulation of pitch, summed and fed to an SVF and an NCA with 2 ADSRs. For that design, I wanted a richer feature set and didn't really care about lots of NCOs - it was sort of a digital transmogrification of a PAiA FatMan.
Back to top
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2049
Location: Morokulien
Audio files: 3

PostPosted: Tue Jan 29, 2008 3:38 pm    Post subject: Reply with quote  Mark this post and the followings unread

ScottG wrote:
I think much of that is constrained by the platform...

One thing about an FPGA is that while it's big, it's also finite.

Yes, unfortunately the resources aren't unlimited. But still, an interface doesn't have to take up that much space, there would be some redundancy here and there, but that might not be a killer - or am I missing something? If one would want a standardised interface, one would have to make it, after all, even if it takes some real estate. While it would certainly not be as optimal as a monolithic system or specially adapted interfaces, it might be worth it for the experimenters out there. I must add that I haven't designed a synth on an FPGA previously (I have designed other non trivial stuff though, with common module interfaces), so I might be talking out of my nether regions Shocked

Quote:
the things you listed above have to be decided on a per project basis.

Well, for the sake of the discussion, and if you can bear with me, lets hypothesise that we would want a standardised interface....

DJ

P.S. New in-browser spell checker suggest English spelling with less use of 'z'... Laughing
--
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1249
Location: West Red Spot, Jupiter
Audio files: 161

PostPosted: Tue Jan 29, 2008 4:02 pm    Post subject: Reply with quote  Mark this post and the followings unread

For me, one of the useful things about an FPGA is that you're not limited to N bits. You can make 12 bit phase accumulators or you can me them 56 bits. It depends on the pitch precision you need for a particular purpose. To get really nice slow phasing between sawtooth signals, you want high precision. If that's not what this synth needs to do, then you can use smaller bit width.

A standard bus size causes much of the freedom to evaporate. To constrain designs to 16 bit datapaths for example would cause me to "waste" two bits of precision because my multipliers are signed 18 bit.

Perhaps a standard could be made where things like bit width aren't specified, or where they are specified as a minimum value, or max and min. That would force the module to be able to deal with variable bit widths and would restore the freedom of selection back to the designer.

The sample clock, IMO, also has to be adjustable because when you deal with lots of things contributing to the sample data, it takes clocks which affect the sample rate.
Back to top
View user's profile Send private message Visit poster's website
jksuperstar



Joined: Aug 20, 2004
Posts: 2489
Location: Denver
Audio files: 1
G2 patch files: 18

PostPosted: Tue Jan 29, 2008 4:33 pm    Post subject: Reply with quote  Mark this post and the followings unread

Well, one way is to code your modules with parameterized everything (in the verilog). Then, some other tool (even possibly a human), stitches together these modules. It's possible to have these parameters then scale based on the "output" of another module. This isn't dynamic or real-time at all, but it does make your building blocks very generic and re-usable from one design to another. And that's half the battle right there.

So, make a front-end tool that abstracts the RTL, makes things look like a software modular synth. This is converted to a top-level RTL file, that's generated by the tool, and links up all these modules behind the scenes, and kicks off a compilation for you. It's not real-time, but it would still be efficient and allow for architectures that simply aren't possible yet in software based systems (like very high sample rates, truly parallel modules, etc).
Back to top
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2049
Location: Morokulien
Audio files: 3

PostPosted: Tue Jan 29, 2008 5:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

Right, my first instinct was to make something that resembles a classical modular in that each module is hiding all things other than the systems standard signals, using e.g. IIS as the signal standard. In other words, nothing that would allow as fine a granularity as Scott suggests, if understand correctly; letting you mix and match the internal building blocks of the modules themselves (meaning "module" in the classical sense, e.g. a complete oscillator with modulation inputs and signal outputs) ) . That is, building a complete oscillator from, say a phase accumulator module, some mixer and scaler modules etc.. In this case things certainly aren't as straightforward.

JK, are you thinking along the same lines as Scott, only with an abstraction layer and the required tools?

DJ
--
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1249
Location: West Red Spot, Jupiter
Audio files: 161

PostPosted: Tue Jan 29, 2008 6:48 pm    Post subject: Reply with quote  Mark this post and the followings unread

Yes, parameterized modules is the way to do it, I think it may require trying to actually create the standard and see if it can be implemented by hand.
Back to top
View user's profile Send private message Visit poster's website
jksuperstar



Joined: Aug 20, 2004
Posts: 2489
Location: Denver
Audio files: 1
G2 patch files: 18

PostPosted: Wed Jan 30, 2008 1:37 am    Post subject: Reply with quote  Mark this post and the followings unread

I think I left a few blanks in there. My point was an attempt to maintain the bus and accumulator widths without normalizing output data from a module to a standard, yet also allow the blocks to be used in a modular fashion. When I say modular fashion, I don't think it's like an analog synth that can be repatched at any point in time, but more like a compile time, that you stick blocks together, compile, then play.

The front end software I mentioned would be a nice way to make this type of system accessible to many users, not just logic jockeys. Much like Reaktor or the Clavia G2 make virtual modular synths accessible.
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1249
Location: West Red Spot, Jupiter
Audio files: 161

PostPosted: Wed Jan 30, 2008 6:14 am    Post subject: Reply with quote  Mark this post and the followings unread

jksuperstar wrote:
I think I left a few blanks in there. My point was an attempt to maintain the bus and accumulator widths without normalizing output data from a module to a standard, yet also allow the blocks to be used in a modular fashion. When I say modular fashion, I don't think it's like an analog synth that can be repatched at any point in time, but more like a compile time, that you stick blocks together, compile, then play.

The front end software I mentioned would be a nice way to make this type of system accessible to many users, not just logic jockeys. Much like Reaktor or the Clavia G2 make virtual modular synths accessible.


Yes, same here, "modular" at compile time, not in the sense of repatchable (like the Nord). Repatchable is possible, but that also requres logic which would take real estate away from additional features.

As I think more, I discover some small flies in the oinment. For example, ROM type tables - these would have to be filled with data before/at compile, but that's not impossible, just requires fill algorithms that can deal with any width ROM. Two examples I can think of immediately are a tuning table and a sine table.
Back to top
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2049
Location: Morokulien
Audio files: 3

PostPosted: Wed Jan 30, 2008 6:54 am    Post subject: Reply with quote  Mark this post and the followings unread

I'm with you as far as the issues of efficiency are concerned, but this is really logic design with macros, almost at the level of shift registers and adders. I fear it's not likely that a standard for synth building will emerge anytime soon at this level, mainly due to the design software that would have to be made. When I mentioned interfacing at the module i/o signal level, I didn't mean run time patchable. That would best be left to each synth design where mux modules would be used to select signal routing where applicable. Such an approach could be geared for little redundancy, e.g. an oscillator could be very basic, just phase accumulator with a ramp output and one frequency and phase control input. Any further dressing such as multiple modulation inputs or further waveform generation could be added on by small mixers modules, transfer functions modules or lookup table modules. It may seem simplistic from a hardened logic designer viewpoint, I know, but it would be something that anybody can understand, design for and patch together, without any specialised tools. I.e. it could all get going "from day one".

DJ
--
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1249
Location: West Red Spot, Jupiter
Audio files: 161

PostPosted: Wed Jan 30, 2008 7:04 am    Post subject: Reply with quote  Mark this post and the followings unread

If you're thinking of a level of design that completely avoids digital design nerdism, so that any nontechnical musician can create an instrument, then yeah, a -LONG- time I think... But if I win the Cal State Lotto (over $50million now), I'll start right away Wink

Time is such a precious commodity, day job, children, wife, fix the plumbing, take the dog to the vet, and then there's hobbies, I have music (composition, performance and recording) as well as trying to design synths to use as musical instruments in my musical works.

BIG FRIGGIN SIGH.
Back to top
View user's profile Send private message Visit poster's website
jksuperstar



Joined: Aug 20, 2004
Posts: 2489
Location: Denver
Audio files: 1
G2 patch files: 18

PostPosted: Wed Jan 30, 2008 4:17 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hey Scott...If you want a clock higher than 50MHz, I can help set you up with the onboard PLL...then you can get any clock you'd like (100Mhz, etc). So, you could see what your synthesis results are for clock rate, then set the clock somewhere up near that frequency, so you can increase voices, etc.
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1249
Location: West Red Spot, Jupiter
Audio files: 161

PostPosted: Wed Jan 30, 2008 5:02 pm    Post subject: Reply with quote  Mark this post and the followings unread

jksuperstar wrote:
Hey Scott...If you want a clock higher than 50MHz, I can help set you up with the onboard PLL...then you can get any clock you'd like (100Mhz, etc). So, you could see what your synthesis results are for clock rate, then set the clock somewhere up near that frequency, so you can increase voices, etc.


The Spartan-3E has built in DCMs (Digital Clock Managers). They use a DLL (not the kind you find in hell) Delay Locked Loop which will produce a set of frequency multiplied outputs and goes to 200 MHz driven by the XTAL clock of 50 MHz.

While this can be used, it does have a caveat. Any jitter found in the XTAL clock will also be found in the DLL output, so your timing contraints have to be set tighter than normal when using a DCM. It is something that I wouldn't use unless I needed the additional system clocks per sample clock to reach my design goal. I've not yet encountered a situation where I _need_ that, so I don't use it and save myself the timing headaches. My 4 NCO monosynth runs at a sample rate of 1 MHz, and it's 4 NCOs because I don't want any more for that synth (it's state machine is fast enough to do 8 NCOs at 1 MHz with a 50 MHz system clock if I wanted that many). My 32 NCO sine synth runs at 250 KHz SR (high enough to use an SVF) and again, it's 32 NCOs because I don't need to play with more than 32 harmonics - in fact, so far, I've only used 16 of the 32 in sounds I've created. The 8 voice polysynth has a sample rate of 250 KHz and it's 8 voice limitation is because of lack of any more RAM in the FPGA. At that sample rate, external RAM could be used to get 12 voices. If I had lots of SRAM (there is only SDRAM on the board and it's more of a timing headache than I want to deal with at the moment), I could probably get 12 voices out of it. Even that synth wouldn't benefit from higher system clock rates unless I had lots of SRAM. Then I _might_ be able to get 24 voices (at 100 MHz sys clk) - but I'd have to add the SRAM as an external plug in board.

EDIT ADD: Smile My source code, posted at http://www.fpga.synth.net/ is open as long as what you do with it is also made available free to the public. I've looked at the timing reports on those projects and the way they are designed, they pass the 50 MHz test, but will never pass 100 MHz. Things would have to be redesigned to use the higher clock speed.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: DrJustice
Page 2 of 2 [38 Posts]
View unread posts
View new posts in the last week
Goto page: Previous 1, 2
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Developers' Corner
Jump to:  

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

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


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use