
March 18, 2011
Building a Better Bridge To Tomorrow
Multi-core, Microservers and NASA’s Open Source Summit
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.
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
Microchip Technology's PICkit 3 Debug Express
Comments:
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)
Posted on March 25, 2011 at 2:10 AM
Nerdy GiveawayPICkit 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