Quantcast
Channel: Processors
Viewing all articles
Browse latest Browse all 124323

Forum Post: RE: Multicore handling DDR3 data parallelly result in conflict !

$
0
0

Wei,

A couple of questions here:

[quote user="wei he1"]As we known, the size of DDR3's bank is 16MB[/quote]

Can you share the formula you used to come to 16MB?

[quote user="wei he1"]8 core can read/write data from DDR3_i without interference theoretically, am I right ?[/quote]

The DDR3 controller can keep 16 banks over two chip selects open at the same time. For a single chip select, we can have 8 banks open at the same time. So you could have each bank dedicated to a core and there would be no need to constantly deactivate and re-activate banks and reduce this overhead.

Using this information and the address mapping provided in the DDR3 users guide, please share the address blocks used by each core in order to confirm there is no overhead.

Please keep in mind that also that there is page switch and read-write turnaround inherent in the DDR3 system.

(1) Page switch: A page switch occurs when command arbitration decides to access different pages in the same bank. This will involve deactivating the currently open page in the bank and reactivating the next desired page in the same bank -> this adds overhead (I believe tRP is the memory datasheet parameter).

(2) Turnaround: Please see the section on turnaround time in the DDR3 users guide. Certain conditions can add turnaround overhead.

The likelihood of both (1) and (2) increases with increase in DDR3 traffic. As you keep adding cores you will load the DDR more and more and consequently your overall benchmark will be affected.

After analyzing that you truly are using different banks for each core, you can start with one core and keep on adding a core (or perhaps have something like 1, 2, 4, 6 and 8 cores) to plot the trend.


Viewing all articles
Browse latest Browse all 124323

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>