Microblaze & Memory DMA operation

Hi,

To get started with Microblaze, I'm attempting to do a simple filtering
application on audio, real-time.  Audio is CD-quality, 44.1 kHz, 16-bits. 
I'm trying to handle multiple audio streams (8 to start with).  I'm
thinking about buffering 16 samples per channel.

I'm trying to figure out what structures to use to facilitate data transfer
of the audio samples from on-board memory into the filtering structure I'm
trying to create.

If this were a normal processor, I would use DMA to transfer from the
external memory to a FIFO and do the processing.

What should I consider doing with Microblaze?  Create an OPB master to
transfer from memory controller to an internal FPGA FIFOs?

Use an FSL?

Suggestions are appreciated.

Ram.

Ram <r_fpga_dev@yahoo.com> wrote:

> Hi,

Hi!

> To get started with Microblaze, I'm attempting to do a simple filtering
> application on audio, real-time.  Audio is CD-quality, 44.1 kHz, 16-bits. 
> I'm trying to handle multiple audio streams (8 to start with).  I'm
> thinking about buffering 16 samples per channel.

You're talking about eight audio channels. This sounds pretty much
like a mixer console ;) Are you sure you really want to use a
Microblaze? Perhaps a DSP would better fit your job. I guess there
are also DSP-SoftIP-cores available at Xilinx's.

> I'm trying to figure out what structures to use to facilitate data
> transfer of the audio samples from on-board memory into the filtering
> structure I'm trying to create.

You mean you don't want to write the filter in C-Code which would
run as normal code on the Microblaze? If not, you can simply use
your normal stack- and heap-commands from C: just initialize a
pointer to some off-stack-memory-area and use it like you'd do
on normal CPUs (without malloc).

The Microblaze is a 32bit-RISC-CPU which has supporting tools like
a C-compiler (mb-gcc) and even some kind of OS (if desired).
AFAIK it is possible to run Linux on the Microblaze (or the
xilinx-kernel). So to say: the Microblaze can handle offchip-memory
via a OPB-sdram-controller (at least that's the way on my S3-Starterkit)

> What should I consider doing with Microblaze?  Create an OPB master
> to transfer from memory controller to an internal FPGA FIFOs?

If you don't want to do the processing with the Microblaze but
use your own VHDL-filters instead, then it would be probably the
best to create an OPB-slave, perhaps with interrupt support.

In this case you can think of your filter as a PCI-audio-processing-card,
except that you replace PCI by OPB ;)

But what would be your Microblaze's purpose anyway?


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Dass der MCSE eine Qualifikation ohne Wert ist, ist mir auch klar.
					  (Detlef Bosau in dcoulm)

Ram wrote:
> Hi,
> 
> To get started with Microblaze, I'm attempting to do a simple filtering
> application on audio, real-time.  Audio is CD-quality, 44.1 kHz, 16-bits. 
> I'm trying to handle multiple audio streams (8 to start with).  I'm
> thinking about buffering 16 samples per channel.
> 
> I'm trying to figure out what structures to use to facilitate data transfer
> of the audio samples from on-board memory into the filtering structure I'm
> trying to create.
> 
> If this were a normal processor, I would use DMA to transfer from the
> external memory to a FIFO and do the processing.
> 
> What should I consider doing with Microblaze?  Create an OPB master to
> transfer from memory controller to an internal FPGA FIFOs?
> 
> Use an FSL?
> 
> Suggestions are appreciated.
> 
> Ram.
> 
> 
> 

Hi,

8 channels with 16 bits data at 44.1 KHz requires 8*(16/2)*44100 = 
705600 Kbyte/s

If you run your external memory as 32-bits you need 176400 transfer/s.

If the system is running at 75 MHz, you need a transfer every 425 clock 
cycle.

I doubt that the memory transfers gonna be your bottleneck in the system.

More important is where is the processing done, in MB or in HW?
What kind of processing of the audio data are you planning to do?

If you would need more bandwidth, I would go for the MCH(FSL) that 
exists on our memory controller now. It's basically a pipe from your 
module to the external memory. MicroBlaze is using 2 of these for 
getting faster cachelines accesses.

G�ran

Hello Adrian, and Göran,

> If the system is running at 75 MHz, you need a transfer every 425 clock
> cycle.
> 
> I doubt that the memory transfers gonna be your bottleneck in the system.

Agreed.

> 
> More important is where is the processing done, in MB or in HW?
> What kind of processing of the audio data are you planning to do?

The current idea is completely in HW.  Simple IIR filtering of each channel
and programmable summing (similar to the mixer idea Adrian mentioned).  MB
is only involved in managing base memory pointers to audio streams, so if
an audio stream is to be changed over, MB controls this.  Some logic (DMA
process?) monitors the base address and continues to fetch and fill the
FIFOs.

The main purpose of MB though is to make it easy to control/alter the
coefficients and do other house keeping chores (display, control, etc).

Getting uCLinux would be great as this adds a network stack and a whole host
of possibilities.

> If you would need more bandwidth, I would go for the MCH(FSL) that
> exists on our memory controller now. It's basically a pipe from your
> module to the external memory. MicroBlaze is using 2 of these for
> getting faster cachelines accesses.

As you pointed out, the bandwidth is probably not the critical issue. 
Really what I was getting at is, with a MB, OPB_Memory_Controller (SDRAM or
DDR), how should I shuffle data from the external memory to my logic?

At first glance, I did not see any traditional DMA type of logic which could
be used to transfer from the external memory (via OPB_Memory_Controller) to
internal FIFOs.  Have I missed something?

Thank you!
Ram.

Ram wrote:
> Hello Adrian, and Göran,
> 
> 
>>If the system is running at 75 MHz, you need a transfer every 425 clock
>>cycle.
>>
>>I doubt that the memory transfers gonna be your bottleneck in the system.
> 
> 
> Agreed.
> 
> 
>>More important is where is the processing done, in MB or in HW?
>>What kind of processing of the audio data are you planning to do?
> 
> 
> The current idea is completely in HW.  Simple IIR filtering of each channel
> and programmable summing (similar to the mixer idea Adrian mentioned).  MB
> is only involved in managing base memory pointers to audio streams, so if
> an audio stream is to be changed over, MB controls this.  Some logic (DMA
> process?) monitors the base address and continues to fetch and fill the
> FIFOs.
> 
> The main purpose of MB though is to make it easy to control/alter the
> coefficients and do other house keeping chores (display, control, etc).
> 
> Getting uCLinux would be great as this adds a network stack and a whole host
> of possibilities.
> 
> 
>>If you would need more bandwidth, I would go for the MCH(FSL) that
>>exists on our memory controller now. It's basically a pipe from your
>>module to the external memory. MicroBlaze is using 2 of these for
>>getting faster cachelines accesses.
> 
> 
> As you pointed out, the bandwidth is probably not the critical issue. 
> Really what I was getting at is, with a MB, OPB_Memory_Controller (SDRAM or
> DDR), how should I shuffle data from the external memory to my logic?
> 
> At first glance, I did not see any traditional DMA type of logic which could
> be used to transfer from the external memory (via OPB_Memory_Controller) to
> internal FIFOs.  Have I missed something?
> 
> Thank you!
> Ram.
Hi,

I would connect the filtering modules as FSL modules to MicroBlaze.
It makes the movement of data much easier.
If the data don't need to be touch/modified after your filtering it can 
pipe the data directly to your audio interface with more FSL channels.

This allows you to build a pipe where MicroBlaze reads data from memory, 
does some mangling with them before sending them to your HW modules over 
FSL connections. Your HW modules would receive data and process them 
before sending them to the FSL based audio module.

This will create a pipe where MB could fetch more data, while the HW 
modules process other data and while your audio module outputs the data.

It also makes it easier to test and debug since you can connect your 
audio module directly to MB and let MB send some test sound to verify 
the functionality.
You can also connect your HW processing modules output back to MB to 
verify that it also functions correctly.

This is exactly what I did for a MP3 player application.

Göran
Göran

Hi Göran:

> I would connect the filtering modules as FSL modules to MicroBlaze.
> It makes the movement of data much easier.
> If the data don't need to be touch/modified after your filtering it can
> pipe the data directly to your audio interface with more FSL channels.

Would this not end up using 100% of the CPU for simple memory move
operations?

Ideally MB should be able to continue executing out of cache (while memory
transfers are occurring) and resume when memory becomes available, no?

The concern is long-term, if more audio channels are added that MB simply
becomes an expensive memory controller.

I am still thinking what other possibilities exist.

Thanks.
Ram.

Ram wrote:
> Hi Göran:
> 
> 
>>I would connect the filtering modules as FSL modules to MicroBlaze.
>>It makes the movement of data much easier.
>>If the data don't need to be touch/modified after your filtering it can
>>pipe the data directly to your audio interface with more FSL channels.
> 
> 
> Would this not end up using 100% of the CPU for simple memory move
> operations?
> 
> Ideally MB should be able to continue executing out of cache (while memory
> transfers are occurring) and resume when memory becomes available, no?
> 
> The concern is long-term, if more audio channels are added that MB simply
> becomes an expensive memory controller.
> 
> I am still thinking what other possibilities exist.
> 
> Thanks.
> Ram.
> 
> 
> 
Hi,

That is a nice thing with FSL.
You could then tie FSL to the memory controller or your DMA controller 
without the need of changing anything in the FSL modules.
The FSL module doesn't know who sends the data.

This will make it fast to get an initial design and also make it easier 
to expand for more performance in the future.

Göran

Has anyone had success in using the FSL Control bit? I have intermixed data read/write and control read/write with the FSL and it seems that once the FSL_Error bit is set in the MSR, it remains set even when the following accesses are matched.

Terry Fowler wrote:
> Has anyone had success in using the FSL Control bit? I have intermixed data read/write and control read/write with the FSL and it seems that once the FSL_Error bit is set in the MSR, it remains set even when the following accesses are matched.

I have a design that uses 3 FSL M/S ports, and I use it without
porblems. But yes, you *must* clear the FSL_Error bit. I use an
instruction "msrclr	r4,0x14" to read all flags into r4 and clear CY and
FSL_error flags simultaneously

Zara

Terry Fowler wrote:
> Has anyone had success in using the FSL Control bit? I have intermixed data read/write and control read/write with the FSL and it seems that once the FSL_Error bit is set in the MSR, it remains set even when the following accesses are matched.

Hi Terry,

The FSL Error bit in MSR is sticky and must be cleared if you want to 
reset it.

G�ran