OMAP-L137 shared memory and DSPLink design question

Hello?  Anybody out there?  I would love to hear if it's possible to share a buffer between the gpp and dsp in as simple a fashion as possible.

Thanks,
Chris

You should be able to allocate a buffer using the POOL module. You could use NOTIFY or MSGQ to share the address with the remote processor (may require some address translation). You could use NOTIFY to synchronize buffer access and/or MPCS (multi-processor critical section) to protect access to same buffer. You probably want to disable caching to eliminate the cache overhead.

~ Ramsey

Hi,

Please see here for more information on some of the modules that Ramsey has mentioned:

http://processors.wiki.ti.com/index.php/Category:DSPLink

Also, recorded DSPLink webex trainings are available here:

http://processors.wiki.ti.com/index.php/DSPBIOS_LINK_WebEx_Presentations

Regards,
Mugdha

HI Mugdha,

I've already read through this stuff, but thanks for the links anyway.  I've also read the SDK documentation and looked at the sample programs that comes with DSPLink and DSPBios.  None of it seems to give a clear answer my to my question: Can I have a buffer of memory that is accessible by both processor and DSP at the same time?  I don't want mutual exclusion or notifies of read/writes of large chunks of buffer space.  I simply want the DSP to be able to read / write to one shared pool of memory as fast as it can, and I want the GPP to read /write to that same shared memory pool as fast as it can.  Assuming there is some bus managing this process, and assuming that the atomicity of reads/writes is a certain word size (4 bytes would be ok, 8 bytes would be the best), then this would be a model we'd like to explore.

What I don't know, however, is if DSPLink is capable of providing that method of operation.  I hope that helps clarify my question.  Please let me know if it does not.

To Ramsey,

What you said intrigues me.  I was kind of thinking down that same path (using pool to allocate and then share the buffer, and thought i might have to pass an address down somehow.)  Since you've verified that train of thought I'll give it a shot.  What about this caching thing?  How would I go about disabling it?

Thanks,
Chris

Hey Ramsey,

I have a app that allocates a buffer from the pool on the gpp, translates the address to a DSP address, and then sends that as an argument during proc load.  Then on the DSP side it uses that memory address to attempt to write data to the buffer.  It doesn't seem that it's working, and I'm wondering if this cache thing couldn't be the cuplrit.  I've been looking, but haven't found, how to disable this cache.

Do you know how to disable it?  Is there some documentation I should be looking at?

Thanks,
Chris

Some details on BIOS 5 and cache settings here - you should review the MAR bits in your BIOS .tcf config script:

http://processors.wiki.ti.com/index.php/Enabling_64x%2B_Cache

Chris

I'm not sure why Chris' post is marked as the answer to this thread.  Yes, it answers part of my question, but not the entire thing.  I'm not done with this line of thought yet, and some random TI employee marking my thread "this question has been answered" seems a little hasty.  What is that all about?

That said: Chris, thanks for the help.  I read through that and I'll take it under advisement.   I was able to get the program working by using HAL_cacheInv and HAL_cacheWbInv() in the DSP code, which I copied from a sample program (I think it was mpcsxsfer.)

That seems to work for me... are there any caveats I should be aware of?

Also: what is the atomic size of reads and writes to internal memory between the DSP?  Is it 32 bit?  I am assuming it is not possible to read a word get it corrupted because a write is being done to it at the same time.

Thanks,

Chris

Ah.  I see, I have the ability to reject an answer.... must have not been logged in before, because the buttons weren't there.   Right, so Chris Ring, I'm rejecting your answer only because it's not a full answer to all my questions.  The link was useful, though!

Thanks,
Chris

Hi Chris,

I am the "random TI employee" that marked this as answered.  As the forum moderator, I try to maintain some semblance of order and make sure threads get answered, and we use the color codes to help with that process.  I hadn't seen any response to Chris' answer in a week, so by our agreed criterion I moved it to "answered".  You were well within your rights and quite correct to mark it back as unanswered and we'll certainly continue to work on getting the help you need in order for you to be successful.  If at any point you think the thread can be terminated in favor of opening up a new one, I would advise you do so in order to keep it understandable and searchable by others.

Sorry for the perturbation.

Dave

Chris, If you haven't already done so, it would probably be helpful to look at the ReadWrite example in DSPLINK.