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 ________________________________ From: Andy Ngo [mailto:[EMAIL PROTECTED] Sent: Thursday, January 18, 2007 4:16 AM To: Griffis, Brad; Azbell, Brandon; [email protected] Subject: Re: Can the ARM and DSP accessing the RAM simulatenously? Brad / Brandon, Thanks for your responses. So basically, what you are saying is that in the current DVEVM DDR memory mapping (the one shown below) which the codec examples are using, if no cache is being used, the application on the ARM (as well as any other application / system process in the Linux kernel that runs in DDR RAM) never runs at the same time (in parallel) as the code server (DSP/BIOS) task on the DSP side, since they both access the same DDR device. Is that correct? It's almost as though it's a single processor system. So, assuming we keep the same single DDR device memory mapping, the only way to fix this contention to allow both sides to run in parallel most of the time is via using cache (assuming we get cache hits most of the time). Where I can fix examples/documents on setting up the cache for the DaVinci and how to split them between the ARM and DSP? I guess for the CE server, it's specified in the *.cfg and *.tcf files, is that correct? Regards, Andy ----- Original Message ---- From: "Griffis, Brad" <[EMAIL PROTECTED]> To: Andy Ngo <[EMAIL PROTECTED]>; [email protected] Sent: Wednesday, January 17, 2007 6:12:07 PM Subject: RE: Can the ARM and DSP accessing the RAM simulatenously? Andy, Perhaps the following info will help you in deciding whether to add a second RAM device. Keep in mind that both the ARM and DSP have cache. The cache greatly reduces the number of DDR2 accesses which also reduces the number of conflicts. Also, the switched central resource has software configurable priorities for the masters such that you can control who you want to have access to the DDR2 in the case of a conflict. This is further documented in "Table 3-12. DM6446 Default Bus Master Priorities" in the data sheet. Brad ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] sp.com] On Behalf Of Azbell, Brandon Sent: Wednesday, January 17, 2007 7:54 PM To: Andy Ngo; [email protected] Subject: RE: Can the ARM and DSP accessing the RAM simulatenously? Andy, The DM6446 has exactly 2 memory interface busses on it. One interfaces to DD2 memories and the other is the EMIFA, which can support Asynchronous SRAM and Flash. These 2 memory interfaces are completely independent of each other. At any given moment in time, one and only one transaction, or access, can/will occur on each bus. The master/initiator of that access for each memory interface can be one of many different masters inside the device, including the ARM, DSP, EDMA, VPSS, EMAC, USB, etc. Due to the Switched Central Resource internal bus architecture, multiple masters can access different targets simultaneously, as long as they are not conflicting for the same resource. If they do conflict, then yes, one of them will be stalled. You really need to make an assessment as to why having a different memory, connected to the EMIFA which the DSP would use, is necessary. What is the motivation? Is the motivation based on something you have measured using the DVEVM, or is it perception? Based on the scenario that you illustrated below: "Since this DDR RAM is physically being shared by both the ARM and DSP, does this mean only one can access the RAM at a time? For example, if the DSP is accessing RAM, does that mean the ARM is put on hold if it trying to use RAM at that time? If this is the case, then the ARM and DSP cannot operate simultaneously and there is a performance issue? I'm asking because my hardware engineer believes that is the case since both the ARM and DSP are using the same bus to access the same DDR RAM chip so only one of them can access the RAM at a given time, regardless of the actual location within the 256 MB space." If both the ARM and DSP are accessing DDR2 memory (for instance) at the same time, one of them will be stalled. You can not physically have 2 accesses occurring at the same time on the same bus. Look at it this way, if both the ARM and DSP were writing a value to DDR2, what would you expect to see on the 32-bit data bus in a given clock cycle: data from the ARM, or data from the DSP? Regards, Brandon Azbell Texas Instruments Senior, Group Technical Staff System Applications [EMAIL PROTECTED] email 847.517.4536 voice 847.517.4576 fax 630.561.9593 mobile ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ngo Sent: Wednesday, January 17, 2007 6:56 PM To: [email protected] Subject: Can the ARM and DSP accessing the RAM simulatenously? I have question that I wanted to ask. The DVEVM board has 256 MB DDR RAM available to the ARM and DSP; according to the document that comes with codec examples, this RAM is partitioned as follows: * 0x80000000 .. 0x87800000 (0-120MB; size 120MB): Linux, booted with MEM=120M * 0x87800000 .. 0x88000000 (120-128MB; size 8MB): CMEM -- shared buffers between Arm, DSP * 0x88000000 .. 0x8FA00000 (128-250MB; size 122MB): DDRALGHEAP (*)-- DSP segment used exclusively for algorithm heaps * 0x8FA00000 .. 0x8FE00000 (250-254MB; size 4MB): DDR (*)-- DSP segment for code, stack, static data, and system dynamic data * 0x8FE00000 .. 0x8FF00000 (254-255MB; size 1MB): DSPLINKMEM (*) memory for DSPLINK * 0x8FF00000 .. 0x8FF00080 (255MB-255MB; size 128B): CTRLRESET (*) memory for reset vectors) * 0x8FF00080 .. 0x8FFFFFFF (255MB-256MB; size 1MB): waste Since this DDR RAM is physically being shared by both the ARM and DSP, does this mean only one can access the RAM at a time? For example, if the DSP is accessing RAM, does that mean the ARM is put on hold if it trying to use RAM at that time? If this is the case, then the ARM and DSP cannot operate simultaneously and there is a performance issue? I'm asking because my hardware engineer believes that is the case since both the ARM and DSP are using the same bus to access the same DDR RAM chip so only one of them can access the RAM at a given time, regardless of the actual location within the 256 MB space. This is most likely not the case but I need to know why so I can convince my hardware engineer. I want him to put a similar 256 MB chip on our custom board, but he insists on putting a 128MB for the ARM and a dedicated tiny 512 Kb for the DSP (which I told him is not enough for CE server I'm trying to run on the DSP). I appreciate your response. Thanks. Regards, Andy
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
