Slow Access to FPGA

jean-Michel Vignolles

Other Parts Discussed in Thread: AM3359, SYSBIOS

Hello,

I am using a am3359 processor interfaced with a fpga.

I have write a fpga driver to initialize the Gpmc bus: Cs0, Nor flash like, asynchronous, 16 bits, address and data multiplexed, no wait pin.

It's ok now to read and write datas. We have improved the timing by using a scope: 60ns for an word read access and 40ns for a write access.

My problem: if i make two consecutly access ( 2reads or 2 write), impossible to decrease the duration between two access: this operation take 250ns.

My code :

volatile unsigned short toto;

toto = (*((volatile unsigned short *)( FPGA_CS0_BASEADDR + offset)));
toto = (*((volatile unsigned short *)( FPGA_CS0_BASEADDR + offset)));

The result (scope), you can the the 'bad' delay : 250ns

It's very important for me to optimize the read access (get a 64 bits value in fpga registers in 4 read access)

I have tried to decrease the GPMC_CONFIG6_0 field value without success..

I have also tried to configure the GPMC in burst mode multiple :

- GPMC_CONFIG1_0 : READMULTIPLE = GPMC_ACCESSTYPE_SINGLE

- GPMC_CONFIG1_0 : ATTACHEDDEVICEPAGELENGTH = GPMC_DEV_PAGELENGTH_FOUR (4*16)

I have tried to decrease, increase - GPMC_CONFIG6_0 field without result: CYCLE2CYCLESAMECSEN, CYCLE2CYCLEDELAY, BUSTURNAROUND...

I dont think that it is due to an interruption who disturb the read code.

Can you help me, have you an idea please ?

Thank you

over 9 years ago

0 Biser Gatchev-XID over 9 years ago

TI__Guru**** 393215 points

Hi,

You can speed up performance if you use DMA. there is a good post on this topic here: e2e.ti.com/.../348712

0 jean-Michel Vignolles over 9 years ago in reply to Biser Gatchev-XID

Intellectual 910 points

Thank Biser,

First : Do you think that this long delay was a standart delay ? Is it a normal behaviour with a 100Mhz clock ?

Secund : Enable the Dma function seems to be a solution, but I need more time to develop It.
A question : If I need to read 1 and 4 words access (small datas), that implies to configure differently the size of the prefetch for each access.
I am not sure that this operation doesn't increase the time, do you think that the code/operation ratio is good and lower than 200ns ?
JM

0 Biser Gatchev-XID over 9 years ago in reply to jean-Michel Vignolles

TI__Guru**** 393215 points

The delay between accesses has nothing to do with the GPMC clock speed, it's due to internal processor latencies. I agree that for small data blocks (1 to 4 words) you will see no big improvement if you use DMA. You might want to try Asynchronous read page access (4-8-16 Word16). See section 7.1.3.3.10.3.3 from the AM335X TRM Rev. L.

0 jean-Michel Vignolles over 9 years ago in reply to Biser Gatchev-XID

Intellectual 910 points

Ok Biser for your answer, I confirm,

At the end of the section 7.1.3.1 GPMC Signals:

"Asynchronous page mode is not supported for multiplexed address and data devices."

The burst mode (multiple access) is only active in synchronous mode, in first we need to configure the gpmc mode.

A question : as you suggest if I configure in synchronous mode, burst mode, 4 words page.

Is it possible to make an long double access (64 bits) or have I to make four unsigned short access ?

volatile unsigned long double tmp = (*((volatile unsigned long *)( FPGA_CS0_BASEADDR + offset)));

tmp1 = (*((volatile unsigned short *)( FPGA_CS0_BASEADDR + offset0)));

tmp2 = (*((volatile unsigned short *)( FPGA_CS0_BASEADDR + offset2)));

tmp3 = (*((volatile unsigned short *)( FPGA_CS0_BASEADDR + offset3)));

tmp4 = (*((volatile unsigned short *)( FPGA_CS0_BASEADDR + offset4)));

And for a single word read without change the page configuration, is it possible to make only one word access by using the code ?

tmp1 = (*((volatile unsigned short *)( FPGA_CS0_BASEADDR + offset)));

Best regards,

0 Biser Gatchev-XID over 9 years ago in reply to jean-Michel Vignolles

TI__Guru**** 393215 points

jean-Michel Vignolles said:
"Asynchronous page mode is not supported for multiplexed address and data devices."

Yes, sorry, I missed that, it will be impossible in async A/D muxed mode.

jean-Michel Vignolles said:
A question : as you suggest if I configure in synchronous mode, burst mode, 4 words page. Is it possible to make an long double access (64 bits) or have I to make four unsigned short access ?

Access types are listed in TRM section 7.1.3.3.6. Also section 7.1.3.3.8.2.2 states:

"System requests with data width greater than the external device data bus width are split into successive accesses according to both the external device data-bus width and little-endian data organization."

0 jean-Michel Vignolles over 9 years ago in reply to Biser Gatchev-XID

Intellectual 910 points

Ok,
In single mode if I try to make an long double access, the Sitara generate an error, I think that's Its ok in multiple read configuration.

I'll configure my GMPC in synchronous mode to validate my needs.

Thank you for ye2e.ti.com/.../1718348 help.
Best regards
JM

0 marcus lu over 9 years ago in reply to jean-Michel Vignolles

Expert 1550 points

Hi Jean :

I have the same problem like yours.

Do you improve the 250ns delay time during two consecutive access?

Could you give me some suggestion?

Best regards,

Marcus

0 jean-Michel Vignolles over 9 years ago in reply to marcus lu

Intellectual 910 points

Hi Marcus,

Sorry, but I don't improve the adc access.

Last years ago with the old tms2812 dsp we have more problem with the internal adc (interférences, calibration...).

To improve it, now with the Sitara we are using an external mono channel: ACPL796J by channel

Good luck.

JMV

0 Wolfgang Muees1 over 9 years ago in reply to jean-Michel Vignolles

Genius 3685 points

The 250ns is the bus arbitration time. Its done for each bus transfer.
You might be able to have this arbitration seldom, by using a FIFO behind your ADC, and using DMA to transfer big chunks of data.

0 marcus lu over 9 years ago in reply to Wolfgang Muees1

Expert 1550 points

Hi Sir :

I appreciate your reply.

I use tool below.

CCS V6, am335x_sysbios_ind_sdk_1.1.0.8, bios_6_41_04_54, ndk_2_24_01_18 and xdctools_3_30_06_67_core

In my platform, GPMC connects FPGA using non-multiplex and 16 bits mode.

I can access FPGA using Synchronous single Access mode and I want to shorten 250ns bus arbitration.

I try use EDMA to shorten bus arbitration and I use source code below for receive.

static unsigned int GPMCNANDRxDmaConfig(unsigned int csBaseAddr, unsigned char *data,unsigned int len)
{
EDMA3CCPaRAMEntry paramSet;
/* Fill the PaRAM Set with transfer specific information */
paramSet.aCnt = GPMC_NAND_PREFETCH_FIFO_THRLD;
paramSet.bCnt = (len/GPMC_NAND_PREFETCH_FIFO_THRLD);
paramSet.bCntReload = 0u;
paramSet.cCnt = 1u;
paramSet.destAddr = (unsigned int )(data);
paramSet.destBIdx = GPMC_NAND_PREFETCH_FIFO_THRLD;
paramSet.destCIdx = 1;
paramSet.linkAddr = 0xFFFFu;
paramSet.srcAddr = csBaseAddr;
paramSet.srcBIdx = 0;
paramSet.srcCIdx = 0;
paramSet.opt = 0x00000000u;
/* Src & Dest are in INCR modes */
paramSet.opt &= 0xFFFFFFFCu;
/* Setting the Transfer Complete Code(TCC). */
paramSet.opt |= (( GPMC_EDMA_TCC_NUM << EDMA3CC_OPT_TCC_SHIFT)
& EDMA3CC_OPT_TCC);
/* Enabling the Completion Interrupt. */
paramSet.opt |= (1 << EDMA3CC_OPT_TCINTEN_SHIFT);
/* Now, write the PaRAM Set. */
EDMA3SetPaRAM(SOC_EDMA30CC_0_REGS, GPMC_EDMA_CHANNEL_NUM, &paramSet);
/* Now enable the transfer */
return EDMA3EnableTransfer(SOC_EDMA30CC_0_REGS, GPMC_EDMA_CHANNEL_NUM,
EDMA3_TRIG_MODE_EVENT);
}

My question is since I use the 16-bit mode for FPGA, is there something wrong with code above?

Because the code above refer nandReadWrite.c which is in starterware directory and it uses 8-bit mode for flash.

Another question is that does EDMA must use page/burst mode for GPMC configuration?

Below is my GPMC configuration.

#define BSP_GPMC_CONFIG1 0x28001000

#define BSP_GPMC_CONFIG2 0x00050500

#define BSP_GPMC_CONFIG3 0x00020202

#define BSP_GPMC_CONFIG4 0x05000500

#define BSP_GPMC_CONFIG5 0x02050505

#define BSP_GPMC_CONFIG6 0x50000000

Please give me some suggestion.

Best regards,

Marcus

Processors

Processors forum

Slow Access to FPGA