Embedded

March 18, 2011

Building a Better Bridge To Tomorrow

Multi-core, Microservers and NASA’s Open Source Summit

by Amelia Dalton

In my Fish Fry this week, I debate the nature of multi-core and examine some new standards that will hopefully make multi-core implementation easier in the future. I also dig into the newest Intel/ARM battle in the world of servers, investigate some fuzzy TSA math and look forward to the first annual NASA Open Source Summit. Also this week, I offer up a new way to create energy (coming to a pond near you) and serve up a brand new nerdy giveaway.

If you like the idea of this new series, be sure to drop a comment in the box below. I appreciate all of your comments so far, and we will be working to enhance the Fish Fry each week - as long as you're watching.


 

Watch Previous Fish Frys

Fish Fry Links - March 18, 2011

Bryon Moyer's article: What’s Yours Is Mine - MRAPI Lets You Manage Embedded Resources

Dick Selwood's article: Fair Trading

Intel and SeaMicro collaboration

More Information on SeaMicro

TSA Math Error

NASA's Open Source Summit

Duckweed used as fuel

Microchip Technology's PICkit 3 Debug Express

Comments:


rejohnson3

Total Posts: 1
Joined: Sep 2010

Posted on March 20, 2011 at 9:20 AM

Amelia - A concept appeared in my brain a while ago that you Amelia, may be in the perfect position to run with (and completely alter the pricing structure of FPGAs).

Ready? Here goes.

I once heard that faster parts are faster because the transistors have a higher static leakage; they are naturally biased a bit more toward the "on" state. Faster FPGAs cost more, but consume more power. Slower FPGAs cost less and consume less power. Static power, I believe, is also a complicated function of the core voltage.

I created an FPGA circuit to explore some of these ideas by creating a free running oscillator (a delay chain feedback to itself through an inverter). By measuring this frequency with a fixed clock, I could read out an indication of the silicons' inherent speed. I could in fact using SignalTap, capture a sequence of the speeds which when plotted, showed the core speed exactly following the ripple on the core voltage pins.

The idea then is to control the core voltage with a real-time measurement of the parts speed to either 1) Lower the core voltage of faster parts to keep power consumption as low as possible; or 2) Raise the core voltage of slower parts to obtain a higher operating frequency.

The hope is to find out that a "slower" device, when run at a higher core voltage, dissipates roughly the same power as a faster device run at the proscribed core voltage.

The FPGA vendors would claim, "OH NO! You can't run outside of the published core voltage range. It will damage the device". Well maybe in fact, it would only damage the faster devices with the naturally higher static leakage.

If this is true, then FPGA users could always buy slower devices and run them "hotter" which really would not be hotter at all.

The FPGA vendors by claiming the need to run within the published core voltage range, are really just trying to maintain their pricing advantage which allows them to charge more $ for the faster devices.

Maybe they should charge more for the slower devices because they run cooler.

The apparent absurdity of this last statement supports my idea.

Robert E. Johnson
161 Reservoir Avenue
Randolph, NJ 07869

908 546-4536 (w)

srentz57

Total Posts: 19
Joined: Jan 2010

Posted on March 25, 2011 at 2:10 AM

Nerdy Giveaway
PICkit 3 Debug Express
Microchip toolbox

Collecting pieces
Not everything is here
Waiting for Bluetooth

Need some time to code
Mechanical work ahead
Spirits running high

Amelia PIC
Awesome nerdy giveaway
Fish Fry feed again.

Steve
You must be logged in to leave a reply. Login »

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register