GPMC interface to external memory device (FPGA)

These are the parameters, sniping some of the code:

//## GPMC_CONFIG1 // configure for NOR and granularity x2

temp = 0x01200; // device type 16 bit wide

HWREG(SOC_GPMC_0_REGS + GPMC_CONFIG1(csNum)) = temp;

//## GPMC_CONFIG2

temp = 0x070B00;

HWREG(SOC_GPMC_0_REGS + GPMC_CONFIG2(csNum)) = temp;

//## GPMC_CONFIG3

temp = 0x020200;

HWREG(SOC_GPMC_0_REGS + GPMC_CONFIG3(csNum)) = temp;

//## GPMC_CONFIG4

temp = 0x07050606;

HWREG(SOC_GPMC_0_REGS + GPMC_CONFIG4(csNum)) = temp;

//## GPMC_CONFIG5

temp = 0x08070A;

HWREG(SOC_GPMC_0_REGS + GPMC_CONFIG5(csNum)) = temp;

//## GPMC_CONFIG6

temp = 0x07040000;

HWREG(SOC_GPMC_0_REGS + GPMC_CONFIG6(csNum)) = temp;

//## GPMC_CONFIG7

temp = 0x0F49;

HWREG(SOC_GPMC_0_REGS + GPMC_CONFIG7(csNum)) = temp;

and here is a more detailed table using the TRM table format:

7.1.5.11 GPMC_CONFIG1_i

The configuration 1 register sets signal control parameters per chip select.

Table 7-65. GPMC_CONFIG1_i Field Descriptions

31 WRAPBURST: 0 Synchronous wrapping burst not supported

30 READMULTIPLE: 0 single access

29 READTYPE: 0 Read Asynchronous

28 WRITEMULTIPLE: 0 Single access

27 WRITETYPE: 0 Write Asynchronous

26-25 CLKACTIVATIONTIME : 0 First rising edge of GPMC_CLK at start access time

24-23 ATTACHEDDEVICEPAGELENGTH : 0 4 Words

22 WAITREADMONITORING :0 WAIT pin is not monitored for read accesses

21 WAITWRITEMONITORING : 0 WAIT pin is not monitored for write accesses

20 Reserved 0 Reserved

19-18 WAITMONITORINGTIME : 0 WAIT pin is monitored with valid data

17-16 WAITPINSELECT :0 WAIT input pin is WAIT0

15-14 Reserved 0 Reserved

13-12 DEVICESIZE 1h 16 bit

11-10 DEVICETYPE :0 NOR Flash like, asynchronous and synchronous devices

9-8 MUXADDDATA : 2h Address and data multiplexed attached device

7-5 Reserved 0 Reserved

4 TIMEPARAGRANULARITY : 0 ×1 latencies

3-2 Reserved : 0 Reserved

1-0 GPMCFCLKDIVIDER : 0 GPMC_CLK frequency = GPMC_FCLK frequency

------------------------------------------------

7.1.5.12 GPMC_CONFIG2_i

Chip-select signal timing parameter configuration.

Table 7-66. GPMC_CONFIG2_i Field Descriptions

31-21 Reserved 0 Reserved

20-16 CSWROFFTIME : 7 GPMC_FCLK cycles

15-13 Reserved 0 Reserved

12-8 CSRDOFFTIME :0xB GPMC_FCLK cycles

7 CSEXTRADELAY : 0 CS i Timing control signal is not delayed

6-4 Reserved 0 Reserved

3-0 CSONTIME 0 0 GPMC_FCLK cycle

-----------------------------------------------------

7.1.5.13 GPMC_CONFIG3_i

ADV# signal timing parameter configuration.

Table 7-67. GPMC_CONFIG3_i Field Descriptions

31 Reserved 0 Reserved

30-28 ADVAADMUXWROFFTIME : 0 0 GPMC_FCLK cycle

27 Reserved 0 Reserved

26-24 ADVAADMUXRDOFFTIME : 0 0 GPMC_FCLK cycle

23-21 Reserved 0 Reserved

20-16 ADVWROFFTIME : 2 GPMC_FCLK cycles

15-13 Reserved 0 Reserved

12-8 ADVRDOFFTIME : 2 GPMC_FCLK cycles

7 ADVEXTRADELAY : 0 ADV Timing control signal is not delayed

6-4 ADVAADMUXONTIME : 0 0 GPMC_FCLK cycle

3-0 ADVONTIME : 0 0 GPMC_FCLK cycle

---------------------------------------------------------

7.1.5.14 GPMC_CONFIG4_i

WE# and OE# signals timing parameter configuration.

Table 7-68. GPMC_CONFIG4_i Field Descriptions

 31-29 Reserved 0 Reserved

28-24 WEOFFTIME : 7 GPMC_FCLK cycles 

23 WEEXTRADELAY : 0 WE Timing control signal is not delayed

22-20 Reserved 0 Reserved 

19-16 WEONTIME : 5 GPMC_FCLK cycles

15-13 OEAADMUXOFFTIME : 0 0 GPMC_FCLK cycle 

12-8 OEOFFTIME : 6 GPMC_FCLK cycles

7 OEEXTRADELAY : 0 OE Timing control signal is not delayed 

6-4 OEAADMUXONTIME : 0 0 GPMC_FCLK cycle

3-0 OEONTIME : 6 GPMC_FCLK cycle

 ------------------------------------------------

7.1.5.15 GPMC_CONFIG5_i

RdAccessTime and CycleTime timing parameters configuration.

Table 7-69. GPMC_CONFIG5_i Field Descriptions

31-28 Reserved 0 Reserved

27-24 PAGEBURSTACCESSTIME : 0 0 GPMC_FCLK cycle

23-21 Reserved 0 Reserved

20-16 RDACCESSTIME : 0xA GPMC_FCLK cycles

15-13 Reserved 0 Reserved

12-8 WRCYCLETIME : 7 GPMC_FCLK cycles

7-5 Reserved 0 Reserved

4-0 RDCYCLETIME : 0xA GPMC_FCLK cycles

---------------------------------------------------------

7.1.5.16 GPMC_CONFIG6_i

Table 7-70. GPMC_CONFIG6_i Field Descriptions

31-29 Reserved 0 Reserved

28-24 WRACCESSTIME : 7 GPMC_FCLK cycles

23-20 Reserved 0 Reserved

19-16 WRDATAONADMUXBUS : 4

15-12 Reserved 0 Reserved

11-8 CYCLE2CYCLEDELAY :0 0 GPMC_FCLK cycle

7 CYCLE2CYCLESAMECSEN :0 No delay between the two accesses

6 CYCLE2CYCLEDIFFCSEN :0 No delay between the two accesses

5-4 Reserved 0 Reserved

3-0 BUSTURNAROUND : 0 0 GPMC_FCLK cycle

-----------------------------------------------------

7.1.5.17 GPMC_CONFIG7_i

Chip-select address mapping configuration.

Table 7-71. GPMC_CONFIG7_i Field Descriptions

31-12 Reserved 0 Reserved

11-8 MASKADDRESS 0xF Chip-select size of 16 Mbytes

7 Reserved 0 Reserved

6 CSVALID : 1 CS enabled

5-0 BASEADDRESS : 9 Chip-select base address.

========================================================= 

bump

no answer...

What happens on the bus?  You'll need to look at the resulting transfers/timing to understand the root of the issue.  For starters, are you seeing both accesses on the bus?  Is the FPGA returning invalid data for the first read, but valid data for the second read?

on the read cycles, the processor drives the bus with stale data, data being correct for the previous access.

a workaround would be to do double reads, (ignoring side effects).

Write cycles, as stated , are just fine.

Thanks, Jure Z.

Jure Zaninovich said:

on the read cycles, the processor drives the bus with stale data, data being correct for the previous access.

What makes you think the processor is driving the bus with stale data?  For the case of a read my expectation is for the external device to do the driving of the bus.  Are you using the GPMC in a muxed or non-muxed mode?

we are capturing the data with chipscope ( Xilinx built in logic analyzer device probing the pins)

yes we are configuring the GPMC in muxed mode as listed in earlier post:

7.1.5.11 GPMC_CONFIG1_i

9-8 MUXADDDATA : 2h Address and data multiplexed attached device

Key: 

0 Non-multiplexed attached device

1h AAD-multiplexed protocol device

2h Address and data multiplexed attached device

3h Reserved

I'll have to withdraw my statement  "the processor drives the data bus" , now that I think again, after you mentioned it.

A better statement would be, " the data bus assumes the values that correspond to the previous read cycle".

This clarification may lead into the posibility of something being wrong with the FPGA design itself...

Thanks, Jure Z.

Jure Zaninovich said:

I'll have to withdraw my statement  "the processor drives the data bus" , now that I think again, after you mentioned it.

A better statement would be, " the data bus assumes the values that correspond to the previous read cycle".

Aside from driving the address onto the pins, the processor would not be driving the bus.  It sounds to me like either you don't have the correct timing to talk to the FPGA or else something is wrong inside the FPGA itself.  If there is some kind of delay internal to the FPGA upon receiving the address you might need to implement a WAIT pin so the FPGA can temporarily stall the transfer until it has the data ready.