Juan is discussing this from a Linux threads perspective, not the actual interface. As Brandon mentioned, there is only one bus and it is impossible for two sets of data to be on the pins simultaneously.
________________________________ From: Andy Ngo [mailto:[EMAIL PROTECTED] Sent: Thursday, January 18, 2007 1:50 PM To: Griffis, Brad; Azbell, Brandon; davinci-linux-open-source@linux.davincidsp.com Subject: Re: Can the ARM and DSP accessing the RAM simulatenously? Hmm..., I just received an answer from a TI expert that says that the ARM and DSP can still access the DDR simultaneously as long each is accessing the DDR memory partition dedicated to it (in other words, as long as they are not accessing CMEM at the same time). Here's the response I received from TI. From what he said, the ARM and DSP don't block each other if they access their own dedicated DDR space, even from the same physical chip. Am I missing something? Regards, Andy Ngo ---------------------------------------------------------------------------------------------------------------------------------------------------------- Hi Andy, To answer your question, let me point out that the DDR2 controller has a theoretical maximum data throughput of 1296 MByte/sec; tests we have conducted actually show ~95% utilization ( 1240 MBytes/sec). That said, ARM, DSP, EDMA, VPSS and master peripherals can access DDR2 (not all may be used in your particular design). There is default prioritization scheme as to which client gets it, but you can alter this via DM6446 registers. As your hardware engineer pointed out, all accesses to DDR2 will go through one controller and a common bus. However, I do not believe this will cause a bottleneck issue for you. To answer your specific question, Linux (on ARM) is a multithreaded system and BIOS (on DSP) is a single threaded system. We already know that calls to DSP are queued, must be done from a common Linux thread, and are blocking (meaning specific Linux thread is blocked until DSP finishes processing call). However, you can have other Linux threads free to access DDR2 in the mean time. In part, the memory map you described serves to separate ARM DDR2 space from DSP DDR2 space and also defines CMEM (contiguous DDR2 memory shared by both ARM and DSP). This means that any DSP algorithm can access DSP DDR2 space without ARM caring about it and similarly ARM can access ARM DDR2 space without DSP caring about it. The only time they block each other is when ARM calls on DSP to process buffer from CMEM space and only the Linux thread calling DSP is blocked. In all other cases, so long as there is DDR2 bandwidth left (and chances are there will be), both ARM and DSP can access DDR2 without concern. That said, how much DDR2 bandwidth do you estimate you will need to access at peak loading? Let me know if this helps clear things up and if there is anything else we can assist you with. Best Regards, Juan Gonzales DSP Applications Texas Instruments Semiconductor Technical Support http://www-k.ext.ti.com/sc/technical_support/pic/americas.htm ----- Original Message ---- From: "Griffis, Brad" <[EMAIL PROTECTED]> To: Andy Ngo <[EMAIL PROTECTED]>; davinci-linux-open-source@linux.davincidsp.com Sent: Thursday, January 18, 2007 9:27:36 AM Subject: RE: Can the ARM and DSP accessing the RAM simulatenously? Andy, You are correct that if you didn’t use any cache that only one processor could do an instruction fetch at a given time. For that very reason having the cache disabled would be a poor design decision. In general you shouldn’t need multiple external memories to run both ARM and DSP code. We have plenty of examples that do it, e.g. H.264 encode at D1 res and 30fps. The ARM and the DSP each have their own cache. In fact, the DSP has two-level cache (L1P, L1D, and L2). Of course there are limits to what the cache will buy you. It works the best when you have a lot of re-use of code/data. Brad
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
