[Fpga-synth] Modular approach

[Veronica Merryfield]

On 26-Jan-09, at 1:21 PM, Theo Verelst wrote:

> Veronica Merryfield wrote:
>> Hi all
>> A recent off SDIY list discussion has got me thinking about FPGA   
>> implementation.
>> One way to implement a software based modular, the Nord being the   
>> starting point for the discussion, would be to have a list of  
>> elements  where each element is a structure that contains an ID for  
>> the  processing element to be used, pointer to inputs (audio and  
>> control),  outputs (for the pointer to pointer too) and element  
>> storage,  parameters and so on. The processing is simply to run  
>> down the list  passing a pointer to the entry to the processing  
>> element. A  configuration editor would create the list being  
>> separated from the  software creation task.
>> Over the last few days I have been trying to conceive an FPGA  
>> based  equivalent. The above processing method does not lend itself  
>> to FPGA  deployment but as yet I can not really see an FPGA version.
>> I would appreciate some input. I like the concept of processing   
>> elements that get implemented once and used a number of times,   
>> configured at runtime rather than at build time. Perhaps this  
>> concept  is not really suited to FPGAs.
>> Thanks everyone
>> Veronica in foggy Port Alberni, 0ºC
>
>
> To me it would seem clear it is *possible*.
>
> I seem to recall the Nord Modulars´ facilities come from DSP  
> processing,
> I wouldn´t know how they make this work, there are various  
> possibilities for sure, using variables with functions and pointers  
> to them and some
> code to decide on which functions are called in sequence being one  
> of them.
>
>
> If you´d take the effort to look at mr. Gravenhorsts´ code, you could
> see the state machine contains functions which in principle could be
> connected up to various parts of the state. Having sufficient verlog
> skills could let you make a connection ´data get and put´ block to
> transfer parts of the state to other parts as in patching connections,
> and somehow fit this in the round-robin scheme of the state machine.
>
>
> Of course nothing (except money, I´m sure) should stop you from making
> for instance a microblaze in a FPGA and connect some special functions
> to it (like from the Gateman Poly) and make the DSP code in the
> microplaze (or PLASMA or others processors a but more powerfull than
> the picoblaze, though maybe that could hack some of it, too), simulate
> connections between those processing blocks at sample rate.
>
> A third possibility is to use a compiler of some kind or possibly a
> hardware scheme to evaluate a repeated function call, like here http://wiki.tcl.tk/22249 
>  , though that´s NOT on a FPGA, and in this
> case the compile of the ´connections´ is not done in runtime, but  
> fixed
> at compile time, which in principle can be carried over to a FPGA  
> design
> with nested function calls in a HDL that allows it, probably by  
> repeated instancing.
>
> Wether it is reasonable to keep doing all such as open source is
> questionable, but then again, UNIX is already for over 35 years...
>

Theo, it struck me that my wording may not have been too clear.

In a DSP, it is relatively easy to use one processing object multiple  
times to create a complete system. DSPs and processors are good at  
doing this as they are essentially sequentially machines. FPGAs are  
not. Whislt one can shoe horn sequential operation into an FPGA like  
you can shoe horn parallel operation into a DSP/COU system, it would  
be better to use the FPGA in it's natural way and it is this I am  
looking for but with the flexibility of a modular system (like the  
Nord) that is not set at build time.

Did that come out any better?

Veronica, Port Alberni, -3C and snowing!