DDR2 EMIF Questions

1) Yes, most of our DaVinci family (DM644X, DM643X, DM6467, DM648) supports 32-bit EMIF for DDR2; this includes DM6446.

2 and 3) using EDMA, DDR2 access is done in 32-byte bursts leading to a theoretical maximum bandwidth of 1296 MBytes/sec.  In practice, we have actually seen about 95% utilization (1240 MBytes/sec) when transferring data from DDR2 to DSP L1/L2.

4) yes

5) This all depends on what your system is doing; for example, if you are capturing HD video data, passing it thru previewer (reads video buffer from DDR2 and writes to DDR2), and thru resizer (again, read data from DDR2 and writes it back out to DDR2) and displaying (read from DDR2) all going at once, you will be pushing the bandwidth limit and may not have much more left for program execution.  However, if all you are doing is displaying NTSC video, then you should have plenty of bandwidth left.

6) This would certainly help.

I hope this helps clear things up a bit, but please feel free to ask more questions if you need further clarity.

BMillikan said:

1) Is there another DaVinci device with 32-bit EMIF port (External Memory I/F)?

Assuming you are referring to the asynchronous EMIF (EMIFA) that is typically used as the flash interface than unfortunately the widest EMIFA used on the modern Davinci devices is 16 bit. The older DM642 device does have a wider interface but I would not generally suggest that device over the more modern Davinci options. They are setup this way to minimize pincount and cost as typically the EMIFA is only used for booting the device from flash.

BMillikan said:

2) If not, what will be the best Bus Bandwidth for the EMIF port?

The EMIFA is driven by the internal SYSCLK5 signal on the DM6446, which is generated based on the DSP clock divided by 6. So for example, with a 594MHz DSP clock as you will have with a 297MHz ARM clock the EMIFA would be driven by a 99MHz clock for all of its timings. Since this is an asynchronous interface it means that you will have multiple clock cycles per access, for a rough estimation of the theoretical maximum speed we could assume you have a setup, hold, and strobe time of a single cycle which means you would get data at a rate of approximately 1/3 of the EMIFA clock or 33MHz, which with a 16 bit bus would give 66MBps as a theoretical max. Typically this would be less based on the timing requirements of your device, as well as additional overhead such as turn around time.

BMillikan said:

3) What is the maximum Bus Bandwidth for DDR2 port?

The DDR2 interface on the DM6446 supports down to a 6nS DDR2 clock as shown in the datasheet, which means the interface can operate at up to 166MHz and with DDR that means transfers happening at a theoretical maximum of 333MHz and with a 32 bit bus this means that translates to a ceiling of 1.33GBps.

EDIT: To be clear on the theoretical maximum DDR2 speed, the value Juan gives above of 1.296GBps which is also correct, this is the maximum value you get with a 27MHz input clock, my number assumes you have a flexible input clock (not true for a normal video application).

BMillikan said:

4) Can we utilize the EDMA to read data from an external memory device through EMIF port and write it into DDR2? How?

Certainly, both the DDR2 and the EMIFA have directly mapped address spaces within the DM6446, so you just have to have your source address in the EMIFA space and the destination addresses in the DDR2 space, essentially you just adjust the source and destination pointers, the rest is the same as most any other EDMA transfer.

BMillikan said:

5) If code were to be executed from DDR2, will DDR2 port have enough Bus Bandwidth to handle both code execution and writing data into DDR2 memory?

This depends on how much data accesses are going on in the DDR2, so this is sort of a system dependent question. Typically the caches within the DM6446 help to alleviate the overhead of accessing external memory for code and data a great deal, so a good portion of how much bandwidth you end up using is not easy to determine without just running the code. As an example if you look at the demos that come with the DVEVM board they are able to run Linux and within Linux run video encoding and decoding examples, which means that you have both processors accessing code and data within external memory at the same time the video drivers are also accessing it, so this proves for sure that you can do both data and code accesses in DDR2. However note that your concern has merit as typically the DDR2 interface is in fact one of the bigger bottlenecks on the part, meaning that you could probably work with much higher video resolutions if the DDR2 interface was faster.

BMillikan said:

6) I think code access to DDR2 should be cache refill, is that true?

Code accesses to DDR2 will typically go into the cache; though this can be disabled it would generally be bad for performance to disable caching unless everything you access fits within the internal memory space you free up by disabling caching.