1. Home
  2. Field-Programmable Gate Arrays
  3. Xilinx EDK: Slow OPB write speeds

Xilinx EDK: Slow OPB write speeds

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

Reply to
Andrew Greensted
Loading thread data ...

Try using PARAMETER C_INCLUDE_BURST_SUPPORT = 1 in MHS.

Guru

Reply to
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
Reply to
Andrew Greensted

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

Reply to
Andrew Greensted

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

Reply to
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

Reply to
Andrew Greensted

I would design the memory interface myself. OPB_IPIF imposes a great delay, while designing a direct OPBmemory 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

Reply to
Zara

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

Reply to
Guru

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

Reply to
Göran Bilski

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.

Reply to
Manny

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!

Reply to
Manny

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.