HPI memory access issue

Hi

The issue is ARM cannot write data sometimes/randomly to DDR of C6746. We have been investigating that DDR usage ratio of DSP core can corrupt HPI communication. When I check technical manual I see that HPI has the highest priority and can be read/write in any case.

Can you elaborate further on "sometimes/randomly" and the nature of failure (missing data, corrupted data)? How are you isolating whether it is a board stability, software stability or purely throughput / contention issue?

Please also note that HPI on c6746 by default is at priority 6. Refer to the TRM, SYSCFG chapter MSTPRIx control registers.

Recommend

1) Checking if the interface speed makes a difference between pass/fail. If it is feasible to increase / decrease speed of the interface to see if the problem becomes more or less prominent

2) Recommend ensuring that your DDR design is robust, by running some stress test on DDR

3) Recommend ensuring your GPMC/HPI link is robust and no software issues on data communication.

4) If you think it is a priority/DDR contention issue, can you see if changing the ARM access over HPI from DDR to say Shared RAM or DSP internal memory makes it more stable?

Hope this helps some.

Regards

Mukul

4) If you think it is prioritization/contention issue

Hi Mukul,

We suspect for DDR contention issue based on the result we got from the following experiments.

Dsp core running nothing or just while 1 loop. In this condition arm is able to read/write the data to dsp over hpi, also read/write operation are correct and consistent.

A data pattern was written to dsp's ddr known location and on arm side in while loop around 500msecs delay, the data was read. when dsp core is idle or running just while 1 loop, we see the data read from dsp is correct. This we have testing for more than an hour.

say, when dsp core is accessing the ddr, like, writing and reading from ddr. we see inconsistency in the reading the data from arm. say my data pattern was 0x2222222211111111 , 64 bit pattern. we see randomly read as 0x222222211110000 or 0x2222222200000000 or 0x1111000000000000 or 1111111100000000.Sometimes while writing the data, we see the data written from arm is not been latched on dsp's ddr memory location.

Here gpmc is configured as Non Multiplexed Address Data 16-Bit Device. gmpc timing for read cycle is 110 ns and write cycle is 60 ns secs. I have tried by improving the read/write cycle upto max. i.e 310ns. But still, no luck. The behaviour is same, not able to read consistently, when dsp core is accessing ddr.

Hi Mukul,

Thanks for advising on making arm access as highest priority by writing to MSTPRIx register. I need to try that. 

By the way, about the link. Yes i have seen the link earlier. Infact, my timings for read and write cycle is almost similar to which the link suggests.

About HRDY., it is connect to gpmc_wait0. But I have observed that, hrdy signals are observed only on writing to HPIA registers and 2 half or higher order bits on read cycle. I dont see these signals when I do write operations. Even TRM explains the same. So I thought of not using hrdy signal.

If you insist me to use the hrdy(gpmc_wait0) signal ? Should I need to configure the gpmc_wait0 only for read access ?

Please let me know ur thoughts....

Regards

Chaitanya

To rule out traffic contention issues, tests conducted:
1) Try to put HPI at highest priority 0 (via MSTPRIx) registers , this will give higher priority for ARM accesses to DDR over HPI compared to DSP
2) Ensure that DDR BPRIO/PBBR setting is reduced from default 0xff to something lower like 0x20.
3) Try to do a temp test, if feasible, to see what happens if DSP accesses are routed to Shared RAM instead of DDR or if ARM accesses are routed to Shared RAM instead of DDR.

1) checked the MSTPRI2 register bit 20-22 UHPI priority, its seems to be 0 by default. 0 says highest priority and 7 says lowest priority . In my case its 0 by default

2) DDR PBBR is set to less 0x20. but no change in behaviour

3) We have been doing this as a workaround. Since writing  to internal ram of dsp doesn’t have problem, we face issues only with ddr access. Also we try to transfer about 1Mbytes/sec, so it not possible for us to use the internal ram, since its only 256kbytes.

I have used the hrdy signals earlier and tried. but that did not improve or helped me in resolving the issues.

As per TRM,  Depending on the type of write operation (HPID without autoincrementing, HPIA, HPIC, or HPID with autoincrementing) and the state of the FIFO, transitions on UHPI_HRDY may or may not occur. Based on this, I asked, will the hrdy really help me in write operations. Since i dont see the hrdy occurring on write operations.


Regards,

Chaitanya.R

I tried reducing the ddr frequency from 150mhz to 132Mhz and 102mhz. but no change, also what I observed was, when ddr frequency was reduced, i used to see some corrupted data read randomly from dsp ddr . When ddr configured for 150mhz, I don’t see issues in reading.

Meanwhile, I have configured the gpmc side to use the gpmc_wait for both read and write operation.

can u tell me, is hpi_hcs line edge triggered  or level triggered ?