SDRAM for linux system

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm currently considering two SDRAM chips.
http://www.samsung.com/Products/Semiconductor/common/product_list.aspx?family_cd=MDR0104
The K4M281633H or the K4M283233H. One has a 16bits bus and the other 32bits. But then the power consuption increases from 65 to 80mA between the different chips. Anyone know if the total power consumption will be less with the 32 bits version that comsumes 15 mA more?

Life's to short for waiting on slow CPU's

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well the trade-off is that you get twice as much data per unit time. It's a speed vs power trade off, 16 bit will run theoretically half the speed but uses less power. What's the design goal you're working to in this project? Of course the speedup isn't anything like 2x once you take in to account caching and depends on the workload you're putting the device under.

What do you mean, total power? The power per unit capacity is worse, but the power per unit speed is (potentially) better, as outlined above.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The system will in the critical fase ( conserning power cunsumption ) problably be active for 200mS and sleep/hybernnate for 800mS as a repeating process. Getting the active time as low as posible for aceiving less power comsumption is importent. From 60mA to 80mA there is a power increase of 25%. Will I see an increase of efficiency or excpect a drop of prosessing time of 25% or will there be less time that the SDRAM consumes max power that with a 16bit bus? The application processes about 5kb of data with a variable set at the same size for then storing to a flash disk.

Life's to short for waiting on slow CPU's

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kay, I see what you're saying.

In the real world I doubt you'd see a 25% reduction in actual execution time. There just isn't that much time spent accessing SDRAM.

That being said, a workload where you're processing a big chunk of data, pretty ram-intensive and dcache-painful is where you're likely to see the biggest improvement.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The <25% decrease of processing time presumes that you are doing no waiting for external events. It wouldn't take much wait time to negate the modest speed improvement.

I would look at it from the perspective of can a 16 bit system meet your computing needs. If so, then the answer is 16bit. Of course you should factor in future needs and enhancements.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you. I also think that the 16bit version will fullfill my needs. It would probably just be waithing for other devices as you say. Thanx for the input. 8)

Life's to short for waiting on slow CPU's