Process-invariant hardware metric: hash-meters per second (η-factor)

[eldentyrell]

This η factor calculation doesn't take power consumption into consideration. It is simply a measure of the efficiency of the silicon design itself. (still very valuable IMHO)

I'm starting to think that a process-invariant metric of power efficiency isn't possible -- at least not one that can be determined by testing (i.e. without the circuit schematics and layout parasitics, neither of which any vendor is ever going to release).

Bitcoin mining chips' power consumption is mostly dynamic power; there's no reason for a mining chip to have any idle circuitry.  Dynamic power is determined by voltage, activity factor, and capacitance.  Although voltage can be observed, figuring out the mix of activity factor vs. capacitance isn't really possible.  At the very least you'd have to know the circuit style (bang-bang-CMOS, Domino, or MCML, for example).

But the biggest problem by far is that parasitic capacitance scales in really funny ways across process nodes an even between fabs.  The ratios between gate capacitance, sidewall capacitance, and gate-to-source/drain capacitance all change in unpredictable ways across generations.  Pretty much the only thing that scales predictably is parasitic capacitance due to metal routing, but a in a well-routed mining chip this is a very small component of the overall parasitic capacitance (except maybe the sigma-function rotation wires).  The vast bulk of your power ought to be going towards charging and discharging diffusion+gate capacitance.

So I don't really think we'll ever be able to independently estimate how well a design's power efficiency will scale across generations of fabrication processes.

[1713585883]

1713585883

[1713585883]

1713585883

[2112]

But the biggest problem by far is that parasitic capacitance scales in really funny ways across process nodes an even between fabs.

Also, the parasitic capacitance may not be entirely parasitic. Check out bitfury's post where he describes how he used 1/4 of the chip area to place bypass capacitors close to the sources of the current spikes:

unfortunately 26%-28% of DIE AREA is just capacitors not transistors... not logic... that's big sacrifice and it won't be stable especially in low voltage without that... capacitors placed near flip-flops;

After I read above I started thinking about using the Miller effect with additional large transistors and an additional higher supply voltage to multiply the filtering capacitance. I don't think thats feasible without the additional steps to produce thicker gate oxide than the one used in the normal logic transistors.

[eldentyrell]

But the biggest problem by far is that parasitic capacitance scales in really funny ways across process nodes an even between fabs.

Also, the parasitic capacitance may not be entirely parasitic. Check out bitfury's post where he describes how he used 1/4 of the chip area to place bypass capacitors close to the sources of the current spikes:

Er, decoupling capacitance (what you describe) doesn't affect power consumption -- at least not anywhere near as much as parasitic capacitance does.  Decoupling capacitance smooths out spikes in the supply, but it doesn't increase power consumption (except for leakage).

The industry's been doing this for a while now.. the Alpha 21264 had a crazy 320nF of on-chip decoupling capacitance.  I think that was also the one that had two solid sheets (not grids!) of metal for power+ground (EDIT: no, that was the 21164).

unfortunately 26%-28% of DIE AREA is just capacitors not transistors... not logic... that's big sacrifice and it won't be stable especially in low voltage without that... capacitors placed near flip-flops;

Ah yes, one of the many downsides of synchronous chips.  They're so fragile when it comes to power supplies...

[2112]

Er, decoupling capacitance (what you describe) doesn't affect power consumption -- at least not anywhere near as much as parasitic capacitance does.  Decoupling capacitance smooths out spikes in the supply, but it doesn't increase power consumption (except for leakage).

I agree with you on power, but disagree with you on what it means "process invariant". The way I understand you, you use "process invariant" as "process feature-size invariant", but you disregard the number and the composition of layers.

Bitfury used some cheap digital-only process and laid out the bypass capacitors beside the flip-flops. Hypothetically he could have used some more expensive mixed-signal process which provides for much thicker metal layers and high-k dielectric between the metal layers (not for the gates). Then he could've laid the bypass capacitors on top of the flip-flops.

All in all, I think the good definition of "process invariant" metrics is still an open research question. E.g. how we are going to account for the future Intel technologies where they have on-chip buck voltage regulators including planarized magnetics?

[eldentyrell]

I agree with you on power, but disagree with you on what it means "process invariant". The way I understand you, you use "process invariant" as "process feature-size invariant", but you disregard the number and the composition of layers.

Yes, you have a good point there; I suppose it ought to be "ITRS process node invariant" or "bulk-CMOS process node invariant".  If people start selling mining chips based on exotic non-bulk-CMOS technology I will definitely add a disclaimer, but I'm not sure that's going to happen.

Bitfury used some cheap

Hey, at 55nm nothing's "cheap"

digital-only process

Nowadays the "analog" process at all the major foundries is the same as the digital process, you just get more processing steps (MiMcaps, inductor metal, deep n-well, native fet, etc).

and laid out the bypass capacitors beside the flip-flops.

Well, the bypass caps are filler… they're tiny and they don't need any signals routed to/from them, so any unused space in your layout can (and usually is) devoted to bypass cells.  If 20% of the area in his layout was bypass caps I really doubt he could fit 20% more hashers if he left them out.

Hypothetically he could have used some more expensive mixed-signal process which provides for much thicker metal layers and high-k dielectric between the metal layers (not for the gates).

An even more extreme example: measurements taken from an SOI chip would unfairly have a higher η-factor than the same design on a bulk CMOS process with the same feature size.  In that case "more money has been thrown" at the product in the form of more-expensive SOI wafers.

Then he could've laid the bypass capacitors on top of the flip-flops.

Hrm, I've never heard of people using the MiMcaps for decoupling.  Interesting idea…  Although you usually have to use one or two of your thick-metal layers in order to make a MiMcap, so the metal used there would be taken away from the best layers of the power distribution grid.  I'm not sure if that's a net win.

[gmaxwell]

Yes, you have a good point there; I suppose it ought to be "ITRS process node invariant" or "bulk-CMOS process node invariant".  If people start selling mining chips based on exotic non-bulk-CMOS technology I will definitely add a disclaimer, but I'm not sure that's going to happen.

I don't know— miners seem like a pretty ideal target for exotic process stuff. The circuit is simple and regular enough that you don't have a ton of other distractions or risk points and it's a superb commodity: build a more power efficient miner and business should flock to your door, unlike a lot of other things which have huge IPR and market force effects that can keep a technically good product from being a success. The simplicity of it also means that your improvement won't be diluted by a bunch of idle circuitry that doesn't get the benefit.

[Ytterbium]

I'm starting to think that a process-invariant metric of power efficiency isn't possible -- at least not one that can be determined by testing (i.e. without the circuit schematics and layout parasitics, neither of which any vendor is ever going to release).

yeah, that's what I was trying to say

This might work for FPGA designs, but not true ASICs.

A crappy layout done with a better process, or even a better packaging that allows for more heat transfer might do better then a great design done with a crappy process or have some flaw that makes it run hot.  A company might spend it's R&D money improving the yield, figuring out the best thermodynamics, etc.

Think about it this way, lots of people used to rag about how x86 was an inferior Instruction set compared to RISC designs, but x86 always ended up having better performance in the end because Intel and AMD competed with each-other, and had a lot more money to throw at working around the 'problems' with x86 (like using RISC internally and translating the instructions it)

The most pure way of doing, the designs that are closest to perfection don't always win out in the end. All that matters is the real-world performance.

[el_rlee]

Sorry for not reading all the pages so far...

• Nobody knows the figures for ASICMiner?
• Doesn't a Bitfury chip make 2.7GH/s?

[eldentyrell]

I don't know— miners seem like a pretty ideal target for exotic process stuff.

.. if you don't care about cost.

The semiconductor business is insanely capital-intensive; any time you stray even a tiny bit from whatever manufacturing process everybody else is doing, your fixed costs skyrocket and you'd better have the volume to make up for that.  Just look at gallium arsenide, the second-most-popular semiconductor after silicon.  Their wafer prices are insanely high and their production fabs are still at only 180nm (last time I checked, at least); unless you need insane radiation tolerance or microwave RF it simply isn't worth the cost.  Same goes for non-optical wavelength lithography -- it won't be cost-effective until it's the only option left and everybody has to "jump off the cliff" at the same time.  In a certain sense that's what ITRS is all about -- it's a cliff-jumping synchronization mechanism.

[eldentyrell]

(like using RISC internally and translating the instructions it)

Hrm, doesn't that mean that RISC won out in the end, even though the companies that first introduced it didn't?  So from the standpoint of a product manager deciding whether to fund a RISC project or a CISC project, the right thing to do was to listen to the debates.

All that matters is the real-world performance.

To the end-user, and to the blockchain, of course!

But if you're the company that has money to spend and are trying to figure out which design to spend money on, you want something like the η-factor.  Just like how the project managers at Intel listened carefully to the RISC-CISC debate and made the right decision in the end even though, at the time they made that decision, RISC chips were overpriced and performing poorly.

[Ytterbium]

(like using RISC internally and translating the instructions it)

Hrm, doesn't that mean that RISC won out in the end, even though the companies that first introduced it didn't?  So from the standpoint of a product manager deciding whether to fund a RISC project or a CISC project, the right thing to do was to listen to the debates.

Well, I guess RISC won out in a way when you look at ARM dominating the cellphone market.  However, what I meant was that the instruction set that programmers/compilers used, as opposed to the chips designs themselves that didn't matter.

All that matters is the real-world performance.

To the end-user, and to the blockchain, of course!

But if you're the company that has money to spend and are trying to figure out which design to spend money on, you want something like the η-factor.  Just like how the project managers at Intel listened carefully to the RISC-CISC debate and made the right decision in the end even though, at the time they made that decision, RISC chips were overpriced and performing poorly.

Well, the problem is that you can have hand-routed designs and other optimizations that only apply at certain feature sizes. Most analogue design work won't carry directly over in a die shrink.

[eldentyrell]

Well, the problem is that you can have hand-routed designs and other optimizations that only apply at certain feature sizes. Most analogue design work won't carry directly over in a die shrink.

Very true.

But if process migration is a high priority from day one, it is possible to make easily-scalable layout.  As in, migrating the layout takes ~10% of the time required to create the first version.  But you have to design the original with this capability in mind, and most people don't do that.

[DeathAndTaxes]

It is only announced but here is some details on Hashfast chip
https://bitcointalk.org/index.php?topic=270384.msg2975145#msg2975145

[HashFast_CL]

Hello eldentyrell,

Please update your nifty list with HashFast's confirmed info.

We're using 4 9x9mm chips (18x18mm total) to produce 500GH+.   

What are the die size, package type, core voltage, transistor count, operating frequency, and projected TDP of the chip? 

The package is a BGA, containing a multi chip module. There are 4 dies, each 9mm x 9mm, spaced out by 5mm. The core voltage and frequency vary according to the cooling available to the chip. The chip contains a temperature sensor on die, and increases or decreases the operating voltage and frequency to maintain a target operating temperature at the die. The allows the maximum possible performance to be achieved, given the cooling that is available. In a colder environment the chip will operate at a slightly higher voltage and frequency, and return a higher hash rate than in a warm environment. Simulation runs show that the best silicon will have a TDP of 250W when operating at the name plate (nominal) 400GH/s. Worst case silicon will consume a few % more power to reach this nominal 400GH/s. Note - simulation results can be out by +/- 20%, although they typically come in high (expect lower numbers in real silicon).

I'd like to write today about a small piece of why we are confident our product is better than KnCs.

So today's topic: Our silicon design is superior.

Both are 28nm designs, but HashFast's is far more powerful and energy-efficient.

Let's look at KnC's 28nm ASIC, and some basic details as we can pull from their documentation. https://www.kncminer.com/news/news-25

First let's calculate the hash rate per square millimeter of silicon. This is a measure of the efficiency of the design.

Honestly, we don't need much to estimate this. The lid size for their chip is enough to make some good estimates.
 
KnC's diagram shows their chip has a 41.2mm lid, and implies that the silicon under that lid may be between 30mm x 30mm, and 36mm x 36mm. (The additional space is needed for decoupling capacitors and such.)
    Let's use those two numbers as bounds for the size of the silicon under the lid. If the die(s) take up just 30x30mm of the space under the lid, then:
     30x30mm = 900mm^2
     100 GHash / 900 mm^2 = 0.11 GHash/mm^2

    Or if the die takes up a bit more of the space under the lid,
      36x36mm = 1296mm^2
      100 GHash / 1296mm^2 = 0.077 GHash/mm^2

HashFast's Golden Nonce chip: I don't have to estimate the size because I work at HashFast.
   One 18x18mm die is able to do 400 GHash (nominal - more overclocked**)
   Hashing per square mm:
      18x18mm = 324mm^2
      400 GHash / 324mm^2 = 1.23 GHash/mm^2
   
Let's compare those numbers, for the high and low values for KnC's chip:

      1.23 / 0.11 = 11.2
      1.23 / 0.077 = 16

So HashFast's chip is between 11 and 16 times more efficient, in hashing per square mm, than KnC's chip.

This has an impact on how fast we can deliver units to customers. One wafer of HashFast's chips has the same capacity as 11 to 16 wafers of KNCs. For each silicon wafer delivered by the foundry, KNC will be able to satisfy 11 to 16 times fewer customers than HashFast will be able to. You'll get your units faster once production starts from us.

In addition, the HashFast chip operates much more efficiently. You get four times the hash rate for the same amount of power (250W). (Based on 250W for 100 GHash from KnC, and 250W for 400 GHash from HashFast.)

Calculations such as this are a small part of why we are confident that we are delivering a quality product to our customers.

We figure it's time to start sharing.

Amy Woodward

VP Engineering
HashFast

** P.S. Simon made me put in the line about overclocking. But as per the 'warranty' thread, no one would ever do that to our beautiful chips, right?

https://hashfast.com/hashfast-announces-fastest-bitcoin-mining-chip-in-the-world/


HashFast Announces Fastest Bitcoin Mining Chip in the World!

    Posted on December 13, 2013
    by Janielle Denier   
    in Baby Jet, Blog, Development, Golden Nonce ASIC, News, Rig Assembly   

HALF A TERRAHASH/s (500GH/s) on a single chip.

HashFast ASIC Golden Nonce- Half a Terrahash Complete bitcoin mining system as found in the BabyJet

This result was achieved during the bringup process of HashFast’s GN chip and module. The engineering team are progressively testing the system, and have not yet reached the full speeds the system was designed for. We expect to see better results over the next few days.
This milestone represents a breakthrough in Bitcoin mining technology and is several times faster than existing Bitcoin mining chips. We are starting volume production of mining systems now.
Stay tuned for further speed results.