If the output system is slower than the input system, then buffering can be used - for a time, but obviously at some point it will be necessary to drop data in that case.

In general, if you want your system to run continuously, always design such that you process and output data faster than you take data in. (I realize that is obvious!) In that case, you merely buffer input data until you have a block to process and then output the processed data. Of course, the output system only needs to be faster on-average, but at any specific time it might be slower than the input. In those cases, use a sufficiently large fifo to buffer the input data. The price is more latency, so do consider if that is an issue in your design.

If the output system is sporadically slow, you can also put a fifo before the output, for example put a fifo before the DAC.

Oops. you mentioned FIFOs. That's what I've always used too.

Dear Daryl Wasden,

I think your problem is more or less what got solved by C.A.R. Hoard with Communicating Sequential Processes, where you have Processes (your signal processing blocks) and Channels (your FIFO's, to be precise these would be buffered channels). A Process can only send if the Process wanting to receive is ready to receive, and vice vera a Process can only receive if there is a Process ready to send. With the buffered channel this then depends on the availability of space / data in the FIFO. I've used this scheme to implement signal processing chains in software, it works quite well. Naturally, this is very close to what you're doing in your second scheme already.

What I would try is to generalise the interfaces between the Processing Blocks and the FIFO, to reduce the debugging overhead. Maybe the FIFO can be modified to generate the `clock enable signal' to the next stage. Of course you must spec the system in the right way, meaning the Processing Blocks at the end must be able to handle the load, but that is true for the current approach as well.

Cheers

Bernhard Sputh

Thanks for sharing the ideas Daryl. What I've found useful in DSP implementation on FPGA (usually having ADC, DAC, etc. as you described) is to have a single clock source on the system and synchronize all processes with that clock and enable/disable the fast and slow blocks with an enable flag. In practice, I've noticed that by using DCM units on FPGA systems to up/down convert the clock rates and sometimes redesigning the processing subsystems, it's usually possible to achieve a single clock source that all modules are happy to work with. Anyway, I know the idea is not always applicable; but whenever it is, the timing control becomes crystal clear!

Reza Sameni

Dear Daryl,

In a sampled data systems it is simple to design if all processes are synchronized to the basic sampling clock. All cock can be either multiples or sub-multiples of the sampling clock. As mentioned by others it is easy if the output clock is faster than the input sample rate. If the output is slower then some data is lost in a continuous system as any amount of buffering will not help. Now, if the processor working on a block of samples I use two memory sets operating in 'ping-pong' mode. for example, if I have to compute the DFT of 512 voice samples in real time then one memory block is used to accumulate 512 samples, operating in write mode, another parallel connected memory, operating in read mode, provides the samples to the DFT processor (DSP). Switching of the memory blocks in this case done at sample rate/512. If the processor is faster then we have gap between the processed blocks of data..Hope this helps in some applications.

R.N.Mutagi

I strongly suggest you to design your blocks with the standard “WISHBONE” bus interfaces (http://opencores.org/opencores,wishbone). This standard is extremely flexible and allows you to implement virtually any topology (multi-master, data flow, etc).

For digital signal processing, a typical strategy is: Output Ports are Masters while Input Ports are slaves.

For continuous data flow with point to point connections the implementation is immediate, and each master output port handles directly the corresponding slave input port. For any other topology you would need to define some arbitration strategy.

Using FIFO is a very good idea but don’t forget they are mainly used to cross clock domains and/or to absorb data rate fluctuations when the reader has in average equal or faster reading frequency than the writing one. The depth of the FIFO should be defined according to the magnitude and frequency of the expected data rate fluctuation.

There are many and very good reasons to learn the “wishbone” bus interface standard and any effort done to learn it will be generously paid back.

Thanks to everyone. Especially, for the links. I have some reading to do. Yes, I tend to come up with something that works, but I feel tthat I am trying to re-solve the same problem with each design. I am hoping to eventually clear things up in my mind so that I can just think, "Oh, I solved this situation last month, I should do it the same way..." Hopefully, maybe design some VHDL template files that handle everything except the intermediate processing. I'll look into WISHBONE and I'm very curious about the Communicating Sequential Processes mentioned above. Thanks, again.