This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6678 DDR3 memory issue

Hello,

I am working with Advantech's DSPC-8681E PCIe card. I am working on a simple test program to run on a single DSP on the card. I have run into an issue with writing to DDR3 memory from the DSP and reading this memory incorrectly from the host. The program is slightly more complicated but for the sake of solving this bug I have reduced what actually runs.

Currently, at the start of main(), the DSP writes to a few addresses in DDR3 memory then falls into an infinite while loop. When I try to read these addresses from the host side, the value read does not match to what the DSP wrote. I can read the addresses back on the DSP side and store the value into a local L2SRAM variable and read the address of this variable from the host and the value matches what was originally written. I can also write to a DDR3 memory location from the host and read the data back from that address correctly with the host.

I have tried removing the infinite while loop in the DSP's main() function in order to let BIOS_start() run, but I get the same results.

-Chris

Signalogic

  • To add to Chris' question:

    Other than init.out, is there any additional DDR3 mem init that DSP-side apps need to do?  Any changes to DDR3 initialization for a situation where DSP and PCIe (host) are accessing the same DDR3 mem, at the same time?

    Jeff
    Signalogic

  • I wanted to add that I am able to write to a DDR3 address from the host, read this address on the DSP into a local variable, and read that variable from the host correctly. The only problem is that when I write to a DDR3 address from the DSP and read that address from the host, I do not read the value written by the DSP.

    -Chris

    Signalogic

  • Chris,

    It sounds like you need to perform a Cache Writeback / Invalidate.  Basically, when the cache is turned on, and if you've read (cached in) the DDR memory location and then attempt to write to the DDR memory location, it's only going to be stored into the local cache until you perform a writeback from the cache to the DDR memory.  When accessing this from the DSP core, it's going to grab the 'cached' contents and not what's physically located in the DDR given that the data is cached.  While an external access will actually directly access the DDR memory interface.  And since you haven't written it back to the DDR, it's got stale data.

    Best Regards,

    Chad

  • Chad,

    Thanks, that solved the issue. On the C64x  snooping took care of this, but on the C66x it looks like snooping only maintains L1D Cache coherence. Is there any sort of work around for the C66x so that I don't have to write-back / invalidate L2Cache every time I write to external memory? From reading the DSP Cache user guide it looks like I also have to maintain cache coherence for host writes to external memory that will be read by the DSP. This limits asynchronous use of external memory on the card we are working with and is something we would like to be able to do.

    -Chris

    Signalogic

  • In order to maintain coherency between different masters accessing it, you will be required to perform the writebacks.  For other CorePac's accessing it, you will need to also perform the invalidates so it will fetch the new data when accessing it.  There's no other options.

    Best Regards,

    Chad

  • That's unfortunate. Thanks for the help, Chad.

    -Chris

    Signalogic

  • Chad-

    This means the only fully (transparently) shared host-C66x mem is MSMCSRAM -- only 4 Mbyte.  On C64x, snooping allowed HPI to make transparent, asynchronous access to all of SDRAM while L2 cache remained active, so it looks like in this area, C66x has taken a step backwards.  We can deal with C66x side writes to DDR3 SDRAM, since we know exactly when/where in code to invalidate cache.  However, when host writes to DDR3 SDRAM, how to know?  How to notify C66x code?  It seems unwieldly, if not unworkable.  Do you have some app notes or tutorial on this?

    Is there a technical reason for the situation?  Couldn't the C64x snooping circuitry at least be ported to core0, if not all 8 cores?

    -Jeff

     

  • You can use IPC and some signalling to let the other cores know when you've performed a manual WB for those memory spaces and then on the cores receiving the IPC, they can invalidate that specific memory space, so that the next time it accesses it, it will re-cache.  I'm not aware of an example on this, but you may wish to ask the question in the BIOS forum as that's more likely where it would be handled in SW.

    BTW, which C64x device did you use in the past, that had this capability?  Was it a single core device?  I see this as something that's easy to implement on single core devices w/ other masters on the device, but not so easy to do on a multi-core device.

    I know we've been looking at implementation of Write-through as an option and that would solve the issue, but we don't currently support this.

    Best Regards,

    Chad