Well, I got nearly the same results for interrupt dispatching both
over OPB & DCR. Eventually I hooked up my high-speed ADC & DAC drivers
to PLB though I'm kinda already overloading my PLB (got some off-chip
SRAM). It seems that every design should be centered around minimizing
memory transactions which implies using buffers intensively and later
communicate results in a bursty manner. Still I think---in some
circumstances---this kinda defeats the purpose of having a powerful 32-
bit uP core at your disposal and reduces it to mere supervisory tasks!

Well, according to my measurements, same applies to the interrupt
dispatching capabilities of both OPB & DCR. Eventually I hooked up my
high-speed ADC & DAC to PLB instead though I'm kinda overloading my
PLB with memory accesses as well (some off-chip SRAMs). It seems that
your design should be centered around minimizing memory transactions
in general. So eventually everything has to go through buffers and
transactions should be bursty. Though it's kinda disappointing as it
defeats the purpose of having a powerful 32-bit uP core and reduces it
to supervisory tasks.

Hi,

You can use a MCH based memory controller like mch_opb_sdram for DMA like 
transfer from your module to the external memory.

The MCH protocol which is based on FSL is fairly simple and will allow to 
cacheline reads from memory.

G�ran Bilski

"Andrew Greensted" <ajg112@ohm.york.ac.uk> wrote in message 
news:f2cj1a$gc5$1@netty.york.ac.uk...
> Antti wrote:
>
>> it all depends how efficient the memory controller and bus arbitration
>> really is.
>> in some cases the memory performance can be rather low.
>>
>> Antti
>>
>
> Antti, thanks for the input. I realise this is a bit difficult to answer
> without some real specific peripheral info, but can you suggest a faster
> method of interfacing a peripheral?
>
> I guess PLB is faster, but this will limit it to PPC use, or microblaze
> via a bus bridge, but I guess that will be slower still.
>
> Is some kind of DMA approach the only way to improve transfer rates?
>
> Thanks
> Andy 

On May 15, 5:19 pm, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> Antti wrote:
> > it all depends how efficient the memory controller and bus arbitration
> > really is.
> > in some cases the memory performance can be rather low.
>
> > Antti
>
> Antti, thanks for the input. I realise this is a bit difficult to answer
> without some real specific peripheral info, but can you suggest a faster
> method of interfacing a peripheral?
>
> I guess PLB is faster, but this will limit it to PPC use, or microblaze
> via a bus bridge, but I guess that will be slower still.
>
> Is some kind of DMA approach the only way to improve transfer rates?
>
> Thanks
> Andy

The PARAMETER C_INCLUDE_BURST_SUPPORT = 1 is  for the OPB_DDR or
OPB_SDRAM peripherals. But I realised that you may not want to write
directly to RAM.
DMA aproach is a right solution if you want a really fast transfer,
especially if you use burst support. Otherwise listen to Zara (he
taught me to design one).

Regards,

Guru

Where

On Tue, 15 May 2007 16:19:01 +0100, Andrew Greensted
<ajg112@ohm.york.ac.uk> wrote:

>Antti wrote:
>
>> it all depends how efficient the memory controller and bus arbitration
>> really is.
>> in some cases the memory performance can be rather low.
>> 
>> Antti
>> 
>
>Antti, thanks for the input. I realise this is a bit difficult to answer
>without some real specific peripheral info, but can you suggest a faster
>method of interfacing a peripheral?
>
>I guess PLB is faster, but this will limit it to PPC use, or microblaze
>via a bus bridge, but I guess that will be slower still.
>
>Is some kind of DMA approach the only way to improve transfer rates?
>

I would design the memory interface myself. OPB_IPIF imposes a great
delay, while designing a direct OPB<->memory interface may speed up
the thing. I tailored my own design to interface OPB to and
synchronous flow-through SRAM, taking the access time downto 2 clock
cycles

Regards,

Zara

Antti wrote:

> it all depends how efficient the memory controller and bus arbitration
> really is.
> in some cases the memory performance can be rather low.
> 
> Antti
> 

Antti, thanks for the input. I realise this is a bit difficult to answer
without some real specific peripheral info, but can you suggest a faster
method of interfacing a peripheral?

I guess PLB is faster, but this will limit it to PPC use, or microblaze
via a bus bridge, but I guess that will be slower still.

Is some kind of DMA approach the only way to improve transfer rates?

Thanks
Andy

On 15 Mai, 15:04, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> It struck me that part of the speed problem with the PPC based system
> was having the main system memory on the PLB bus. By using the OCM
> interface for data and instructions things got slightly faster:
>
> Virtex2Pro + PPC
> cpu Freq: 100Mhz, bus Freq: 100Mhz
> memory write freq about 2.941MHz
> 1 write / 340ns
>
> However, this still seems very slow for a 100MHz bus.
>
> Andy

xilinx memory IP core random access delay may easily be up to 20 clock
cycles.
this would then be 5MHz, you are seing 2.9MHz, this is a bit lower but
adding
some GCC compiler overhead and we come down to the speed you are
seeing.

it all depends how efficient the memory controller and bus arbitration
really is.
in some cases the memory performance can be rather low.

Antti

It struck me that part of the speed problem with the PPC based system
was having the main system memory on the PLB bus. By using the OCM
interface for data and instructions things got slightly faster:

Virtex2Pro + PPC
cpu Freq: 100Mhz, bus Freq: 100Mhz
memory write freq about 2.941MHz
1 write / 340ns

However, this still seems very slow for a 100MHz bus.

Andy

Guru wrote:
>  Try using PARAMETER C_INCLUDE_BURST_SUPPORT = 1 in MHS.
> 
> Guru

As far as I can see, this parameter does not apply to any of the parts
of my system. Can this be used as a global MHS parameter? Or did you
mean it to go in a specific peripheral?

Cheers
Andy

-- 
Dr. Andrew Greensted      Department of Electronics
Bio-Inspired Engineering  University of York, YO10 5DD, UK

Tel: +44(0)1904 432828    Mailto: ajg112@ohm.york.ac.uk
Fax: +44(0)1904 432335    Web: www.bioinspired.com/users/ajg112

On May 15, 1:00 pm, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> Hi All,
>
> I've a simple peripheral with an OPB interface. In a nutshell I've been
> getting some very slow write speeds over the OPB and wanted to see if
> this was normal, or if there was anything I can do to speed things up.
>
> I've tried a number of configurations. Trying PPC and microblaze based
> systems. Using the OPB_IPIF and connecting directly to the bus. The
> results are:
>
> Virtex2Pro + PPC
> cpu Freq: 100Mhz, bus Freq: 100Mhz
> memory write freq about 1.25MHz
> 1 write / 800ns or every 80 clock cylces
>
> Virtex2Pro + microblaze
> cpu Freq: 100Mhz, bus Freq: 100Mhz
> memory write freq about 12.5MHz
> 1 write / 80ns or every 8 clock cylces
>
> Obviously the microblaze approach is faster. Is this simply because the
> PPC system has to use a plb2opb bridge? Including the IPIF doesn't seem
> to slow things down. The peripheral does and immediate acknowledge of
> the data write, so there should be no delays there.
>
> Are them some tricks to speed up access to OPB based peripherals?
>
> For reference, the test code is:
> #include "xparameters.h"
> #include "xutil.h"
> #include "xio.h"
>
> int main(void)
> {
>   print("Starting OPB Test\n");
>
>   Xuint32 dataOut = 0;
>
>   while (1)
>   {
> //  XIo_Out32(XPAR_OPB_TEST_0_BASEADDR, dataOut);       // IPIF
>     XIo_Out32(XPAR_OPB_IPIF_TEST_0_BASEADDR, dataOut);  // Direct
>     dataOut ^= 0x1;
>   }
>
> }
>
> Many Thanks
> Andy

 Try using PARAMETER C_INCLUDE_BURST_SUPPORT = 1 in MHS.

Guru