Microblaze & Memory DMA operation

Hi!

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.

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)

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)

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,

Agreed.

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.

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:

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.

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

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

Thanks for your help. I have another observation I would like to confirm. It seems that the MSR[29] carry bit, used to determine if the fifo has data, is set by control reads and is not set by data reads. Tbis bit is used by a lot of instructions and as such is not "sticky" like the FSL_Error bit. Has that been your experience?

Terry Fowler ha escrito:

seems that the MSR[29] carry bit, used to determine if the fifo has data, is set by control reads and is not set by data reads. Tbis bit is used by a lot of instructions and as such is not "sticky" like the FSL_Error bit. Has that been your experience?

I have never tried it with control reads, only with data reads, and it works.

Sorry I am late in responding. I have been able to get the FSL to work with the control bits. As mentioned in other posts, the FSL_Error bit is "sticky" and must be manually reset. This can be done with a macro: #define clearmatcherror asm volatile ("msrclr r12,16")

I just upgraded to EDK 7.1 and the new compiler is complaining about the FSL access macros that were working with 6.1?? Has anyone found a fix for this?

Thanks, Terry

Macro problem resolved thanks to Deepesh Shakya. It seems that the assembler syntax changed slightly in going from version 6 to 7 and using the version 7 mb_interface.h fixed my problem.