Hi,
We are using ConnectCore Wi-i.MX51 board with i.MX515 CPU (Windows CE 6.0, Digi BSP). We are trying to connect it to our own device as pseudo static 16-bit RAM with time write access 20 ns and time read access 30 ns.
We use WEIM engine for CS0 chip select.
We have the following access picture:To view access cycle and other signals we used "endless" loop.
for (i=0;i<0x7FFFFFF;i++) {
OUTREG16 ( p_AsyncRAM_CSx , data16);
/* OR INREG16 ( p_AsyncRAM_CSx ); */
}
Our current register settings:
WEIM_CS0_GCR1, 0002_0081
WEIM_CS0_GCR2, 0000_0000
WEIM_CS0_RCR1, 0202_0000
WEIM_CS0_RCR2, 0000_0000
WEIM_CS0_WCR1, 0204_0040
Also CCM_Base + 0x7C |= 0033_0000
Each individual read / write access cycle is suitable.
But time interval between two subsequent access cycles is 170 ns (marked red). And it is unsuitable (must be zero).
According to settings of register WEIM_CS0_GCR1, WEIM_CS0_RCR1 and WEIM_CS0_WCR1, bits CSREC=0, RCSA=0, RCSN=0, WCSA=0, WCSN=0, this interval must be zero.
According to pictures Asynchronous Read/Write Memory Accesses Timing Diagram, Fig.63.8.3, Fig.63.8.4, Fig. 63.8.5 on page on pages 63-61(3173) - 63-64(3176) of MCIMX51RM, "MCIMX51 Multimedia Applications Processor Reference Manual", Rev. 1, 2/2010, it is possible.
How can we solve this problem?
I tried a lot of variants of settings of BASIC_PRIORITY#1-2 and UNIT_LVEL_ARBITRATION (4) registers.
The following registers settings were modified:
M4IF +0x40 = F_BASIC_PRIORITY#0
M4IF +0x44 = F_BASIC_PRIORITY#1
For every field of master unit I used only 2 values (000 and 011), but in a cycle of each to each (totally 256 combinations).
M4IF +0x74 = I2_UNIT_LEVEL_ARBITRATION
M4IF +0xB0 = F2_UNIT_LEVEL_ARBITRATION
M4IF +0xB4 = S_UNIT_LEVEL_ARBITRATION
M4IF +0xB8 = I_UNIT_LEVEL_ARBITRATION
(M4IF +0xC0 = FAST_DYNAMIC_PRIOR_CTRL)
For every register of unit level arbitration I used only 8 values (for maximum pathway priority of selected channel), but in a cycle of each register to each register (totally 4096 combinations).
Totally 1048576 combinations. Each value written to each register was re-read for check.
The delay between bus cycles was measured by the special engine in Altera logic.
I used 100 - 1000 bus cycles (read or write) for delay measuring.
But no result. The delay for any combination of register values remained 160-170 ns.
It happens for 99 - 99.9 % of measurements, but sometimes the delay is much longer (and let it be so for real-time OS).
When the check was finished, I think that register settings for basic priority and level arbitration do not affect (it's common sense). There are no other active engines except WEIM. The WEIM is monopolist.
The delay between bus cycles is defined by some other on-chip hardware. Which one?
Florent Auger, thank you very much.
You have correct specified in an error with RFL and WFL bit setting. RFL and WFL bit setting error is my typing mismatch. At first these fields had different settings and did not influence our characteristics. Really, in addition the processor is compelled to watch for READY signal of hardware. It can increase the time of bus cycle. But each individual read / write access cycle is suitable.
Our problems are BETWEEN bus cycles.
I agree, that it is impossible to GUARANTEE zero delay between 2 bus accesses.
But we do not need zero delay to be GUARANTEED.
During cycle execution
for (i=0; i <0x7FFFFFF; i ++) { OUTREG16 (p_AsyncRAM_CSx, data16); }
any additional devices - NAND flash, FEC, SD-card, SSI, etc not used. Program is executed from internal cache. WEIM unit does not share bus with anybody.
At least in 90 % of cases the time between bus cycles should be zero.
But between bus cycles there is 160-170 nanoseconds, this figure it is persistently visible on an oscillograph. There are no zeros anywhere.
We do not need zero delay to be guaranteed, we need to eliminate a steady delay of 160-170 nanoseconds between cycles.
Now I'm testing group of registers M4IF+0xB4==S_Unit_Arbitration_Register, M4IF+0xB8 ...
But no result.
What other registers to look? I need any idea...
That's not possible to ensure of a zero delay between 2 accesses. The simple reason is that the internal memory bus is shared between DDR, NAND flash, WEIM,... and nothing guarantees that the WEIM bus will be granted with two consecutive accesses.
Then, RFL and WFL are not set, which makes the WEIM monitor the external WAIT signal instead of using the fixed wait state latency specified in RWSC and WWSC.