Skip navigation
2008

We’ve been waiting for the transition to DDR3 memory in embedded chipsets since the new memory became available in 2007. Unlike the move from DDR to DDR2, this transition is expected to be speedy as the performance gains and the lower power requirements outweigh the price differential. I am happy to say the newly released RadiSys Procelerant CEGM45, based on Intel’s Core 2 Duo T9400, has DDR3 memory.

 

Not every COM Express module based on the GM45 Express will have DDR3 memory - the chipset can support DDR2 or DDR3, but not both. The module supplier must choose the memory type during design – something to look for when choosing a next generation

module.

 

RadiSys is big on DDR3. Data rates are twice as fast and use a clock rate of 800-1600 MHz rather than the 400-800MHz on DDR2. The chips run 20-30\% cooler due to the 1.5V supply voltage versus the 1.8V supply on DDR2. These are BIG gains in the

performance/power trade-off of a COM Express module.

 

Price is always an issue – and DDR3 is higher at this point – but we believe that the price crossover point is going to be here soon, likely before you have carrier prototypes in-hand, so now is the time to make the jump. Technology, as you know, moves fast. Half the work is in determining where this price-performance crossover point is ahead of your competitors. We’re betting on DDR3 now.

 

Check out what memory vendors have to say:

 

http://www.micron.com/products/dram/ddr3/

 

http://www.samsung.com/global/business/semiconductor/products/dram/Products_DDR3SDRAM.html

 

http://www.elpida.com/en/products/ddr3.html#No1

 

http://www.qimonda.com/computing-dram/ddr3/DDR3_SO-DIMMs.html

 

Jennifer Zickel

Product Manager, COM Express Product Line

http://www.radisys.com

 


Message Edited by serenajoy on 03-11-2009 08:06 PM

One of the subjects I’m most interested in is how MicroTCA and AMC modules are evolving to open up opportunities in lower cost spaces such as the enterprise and industrial markets.

 

As many people know, the AMC specifications were driven out of the need for hot swappable mezzanines for ATCA blades. The MicroTCA specification was kicked off based on the belief that by plugging the AMCs into a backplane wrapped by a smaller enclosure that the AMC market would be greatly expanded. One of the more contentious issues in the specification discussion was about potential cost targets. At the time, it must have been difficult to imagine how new integrated devices such as the Intel Atom processor would drive system level pricing down when combined with lower cost packaging and other optimizations. Now, a couple of years after the MicroTCA specification was ratified, I am often amazed by some of the applications for which potential customers are thinking of using MicroTCA systems. Maybe I shouldn’t be so surprised, as I started my own career by using open standards-based boards for embedded applications, but that’s another story.

 

Back to the subject, one question I’ve been asked is whether it is possible to remove some of the built-in AMC features such as hot swap, in order to save cost. Most of these questions come from people who have legacy hardware and who believe that hot swap particularly is not of any use to them. I suppose a typical application might be in industrial automation where the system is controlling and/or monitoring a process. Typically, to carry out maintenance the controller is switched off, as well as the equipment or production line, so there is no need for hot swap and therefore it appears irrelevant.

 

As industrial automation becomes more complex, I have seen installations that are complex to shut down and take a long time. Having the ability to add an additional module on the fly, even if only for troubleshooting, can be extremely beneficial.

 

I have also started to see a few instances where one MicroTCA box is used for more than a single function. For example, the ability to add an additional Intel-based processor for monitoring or server functionality without requiring all the existing modules to be powered off is extremely useful. The idea of upgrading these embedded systems while live seems to be gaining a bit of momentum, especially now that other techniques such as virtualization have started to break the mental barrier that one module does a single task in one box.

 

If anyone has similar views on how they envisage hot swapping to be used I would be interested to hear.

Just as we are consistently aware of cost per gallon a

gasoline, IT managers are looking at the cost per gigabyte. Old formulas looked

at the cost per gigabyte of storage since the corporate databases relied on

data storage. Now with the Internet boom and the needs to support remote data

access, Kontron has observed that IT managers are also looking at the cost per

gigabyte of data throughput, blending the system storage and usage costs into a

more accurate number when considering system ROI. Customization

services can maximize storage as needed for emerging system configurations.

 

 

 

 

 

An interesting example of the changing way the world is

looking at cost per gigabyte is the 3G iPhone. The cost in the US of the 8 GB iPhone

went down by 50\%, giving the user a smaller cost per gigabyte of storage, while

the cost of the data service from AT&T went up by 50\% for consumer plans. There

is a 20 month breakeven which should seem pretty attractive to users even with

a 2-year contract. Since data usage charges are for unlimited use – the more

data the lower the ongoing cost per gigabyte.

 

 

 

 

For the IT manager the enterprise Internet access costs and

the equipment costs are an important piece of the overall cost per gigabyte

formula. Kontron has new IU and 2U network platforms, the KNP-1000 and KNP-2000,

that are ideal for minimizing cost per gigabyte by taking advantage of the dual-core

Intel® Xeon 3000 Sequence processorand Intel® 3100 chipset and optional

rear hot-swap SATA hard drives, to help the enterprise accelerate and manage

traffic. Kontron customers have cited that the combined cost per gigabyte on

the system with network access is significantly reduced of late.

 

 

 

 

It may be time to start referring to cost per terabyte.

 

 

 

 

Kontron - Nancy Pantone

 

 

 

 

 

 

 

 

 

Message Edited by serenajoy on 03-11-2009 08:40 PM

Plumbing repairs – Argh! I never have all the parts that I need to complete my project. Even though I keep a supply of valves and fittings in my garage, I always seem to need one more trip to the store to get the job done. At least in my household, the time to fix a sink has more to do with driving to and from the hardware shop than the actual repairing.

 

Strangely, microprocessor performance is a lot like my plumbing repairs. If a processor doesn't have the data or instructions that it needs, it must get the information it requires before it can continue. If the needed information is in its caches (equivalent to the collection of parts in my garage) then the delay will be fairly insignificant. However, if it needs to fetch the information from main memory (a trip to the hardware store) then overall performance will sag. In many applications it is this access timing (or latency) that determines performance more than any other factor.

 

The latency problem becomes even more interesting as we add more processor cores into the mix. Continuing with the plumbing analogy, imagine if seven other do-it-yourselfers arrive at the hardware store at the same time as I do -- this is the same as eight processor cores attempting to access memory at the same time. Chances are pretty good that some of us are going to have to wait in line while the others are paying for their goods. The average time for each of us increases.

 

What if everyone in town decided to visit the same hardware store at the same time as me? I could easily spend days waiting in traffic before I even reached the store parking lot. Of course, this never happens because it’s extremely unlikely that everyone will go the store at the same time. Furthermore, there are many hardware stores in my town – this tends to balance the load during peak hours. The equivalent multiprocessing solution for limiting congestion is to have multiple memory channels. More memory channels help to balance the load and reduce the average access latency.

 

Just to underscore the importance of watching latency, let’s look at a few numbers. For most microprocessors, accessing the L1 cache takes between two and four nanoseconds. Contrast this with main memory latencies of sixty to one hundred eighty nanoseconds. Programs with poor cache utilization (and hence, long latencies) can easily run fifteen to ninety times slower!

 

Okay, latency is important. But where do we go from here? As a starting point I recommend obtaining a copy of “Intel® 64 and IA-32 Architectures Optimization Reference Manual”. This can be freely downloaded from Intel's website and contains a wealth of information about optimizing for memory accesses. Emerson Network Power Embedded Computing also has sophisticated tools for estimating multi-core processing performance. I will gladly address whatever questions you might have. I look forward to hearing from you.

Which is the best embedded multicore processing chip? Let me start by way of analogy.

 

Suppose you are the owner of a car dealership. One day a customer comes in who wants to buy “the best” car on your lot. Smiling, you begin asking questions. One thing you know from experience is that there is no one “best car.” Some customers are looking for no-frills while others want luxury. Customers wanting highest levels of fuel efficiency are only satisfied with hybrid vehicles. When it comes to “performance,” “best” can mean the fastest time from zero to sixty, or the highest towing capacity. Asking the right questions is tantamount to matching a car with each potential driver.

 

The same is true of processor chips. Unfortunately, there is no “best” for all applications. Power consumption, integration, cost, and performance characteristics all come into play. Likewise, application structure, programming model and scalability could also be factors. What is best for your application might not be right for mine.

 

Why then, do we gravitate immediately to the number of processor cores? Assuming that more cores are better is a lot like insisting that a V12 engine is always better than a four cylinder. It’s exciting, but it just isn’t so. Let’s take a break from core counting for a moment and get back to asking questions more relevant to embedded computing. I for one know of several applications that would benefit from something other than ever increasing cores. I suspect you do, too.

Filter Blog

By date: By tag: