We are interfacing an FPGA as a 16bit wide memory device ising the GPMC.
We have used the info as indicated below to have our system work, but we have some issues.
The configuration of the GPMC is rather involved, and we have tweaked it in order to satify our timen requirements.
We have not optimized the timings yet.
Our test software produces two 16 bit wide writes, and we are OK with this.
In the case of read operations, a single 16 bit wide read transaction is produced,
and to actually receive the correct data, we need two reads.
Could any one please suggest what is happening here , and a way to resolve it ?
My impression is that we have a GPMC parameter wrong.
I'll post the configuration parameters in a follow up post.
Thanks, Jure Z.
=======================================================================================
We used the info in the thread:
http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/p/176492/643640.aspx#643640http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/t/190352.aspx
which points to the example file:
1641.GPMC_DRAM_example.zip
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
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
20-16 RDACCESSTIME : 0xA GPMC_FCLK cycles
12-8 WRCYCLETIME : 7 GPMC_FCLK cycles
4-0 RDCYCLETIME : 0xA GPMC_FCLK cycles
7.1.5.16 GPMC_CONFIG6_i
Table 7-70. GPMC_CONFIG6_i Field Descriptions
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?
---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------
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.
Jure Zaninovichon 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:
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...
Jure Zaninovich 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.