Tom Gal wrote:
Cell phones are *very* sensitive to power. If it were a win, they would
switch in one generation.
If that was the only thing that mattered.
It is, by and large. Cell phones are *not* price sensitive. The cell
phones are subsidized by the contract. Therefore, it's all about
features. Since an ARM9 is an ARM9, this should be a dead drop-in ie.
no software switching costs.
The problem is most likely talking to other chips. Other chips (like
memory) are synchronous.
Can we get a source for that? Perhaps qualify the class and type of
processor? Sounds like intel netburst architechture to me (if it's
even true.... in fact I KNOW that at the 65nm process node and below
most of the power goes to leakage currents).
GHz clock speed. Obviously, if the clock speed is very slow, the clock
power drops way down.
For 65nm and a slow clock I could believe that the power being leaked
dominates.
This is another case
where clock speed makes a big difference. Power consumption (exclusive
of leakage) rises linearly with core voltage but squared relative to
clock speed
http://www.duke.edu/~kaf3/lowpower/slide4.html
You got it the wrong way around. P = k C V^2 f for CMOS.
It goes with core voltage squared but linearly with frequency.
Your arguments lose a great deal of force when you don't get basic facts
right.
"block" is "on" or "off" in a chip to save power. Notice how all the
chip makers just stop emphasizing megahertz? Now might be a good time
to get off the synchronus bandwagon.
Opinions. No factual correlation shown.
Yeah.......whatever you do....don't think outside the box, cause then
you might be a scientist right? I'm currently working at a company
that has gotten CMOS photonics working 5 years ahead of intel, and
many others, by fusing engineering and science.
And this has exactly what to do with asynchronous logic?
Appeal to authority and argumentum ad hominem.
You're not convincing me.
Doesn't mean the problems are EASIER
with asynch, but the benefits are clear.
No they are *not*. You can claim the benefits all you want; you haven't
*shown* them.
Asynch has a *LOT* of issues. Interfacing to the rest of the world is
the big one. Asynch looks *really* good when everything is on chip at
low speed with weak processing performance. Like, say, an RF powered
smart card. Oh, look, that's exactly the application space they sell
these things into.
Once you have to talk to something off chip, round trips kill
asynchronous. Even if you have a fully asynchronous memory, the
roundtrip ack's required destroy your performance. They also eat up
your mythical power savings.
Let's be straight....clocks are for synchronization, so you know when
the train is going to be there, or when to show up for your meeting.
The firebrigade (common asynch example) just waits for the water
bucket to get put in their hand.
Your analogy cheats. When the bucket shows up, that is the information,
the ack signal, and the reverse ack signal and there is no delay between
any of them.
Make it such that each fireman has to pour his bucket to the next guy
via a firehose. That's a better analogy.
In a clocked circuit, each fireman has two buckets and all of the
firemen pour one bucket into the next hose while leaving one under the
previous hose. Every n seconds, one fireman has to squirt all the
firemen with water. He does so through hoses run from him to each of
the other firemen. The firemen then put the now empty bucket under the
previous hose; they drink some amount from the bucket with water (do a
computation) and then pour the rest of the bucket into the next hose.
As long as the water stops flowing before the next squirt, no water is lost.
In an asynchronous circuit, each fireman has to communicate with the
next. Each fireman pours his bucket with water into the next hose. At
the end of the pour, he puts a bit of water into a communication hose
which squirts the next guy to know that the water is done pouring.
However, the next fireman *can't always remove that bucket immediately*.
He may be tied up pouring his current bucket of water. Whenever he
gets done, he pours a little bit of water into a communication hose to
squirt the previous guy and let the him know that he took the bucket and
is ready for him to send more water.
Oh, and by the way, a bucket brigade analogy is a really rotten argument
for asynchronous logic. Dock workers in the old South used to *sing*
precisely for the benefits derived from global synchronization.
Sorry for the vehmence, it's just passion not angst, and as for why
this issue belongs on a linux list, I don't know.......but it's hard
to let someone make a bunch of unrealistic, unsubstantiated, and
philosophical claims about something you know a lot about. Stating
opinions as fact is not fair, nor helpful to anyone.
I agree. I just find no "facts" in your entire post. And the one you
did use you got wrong.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
