Bitcoin Forum

UPDATED 21-Jul-2013: added column showing delivery/verification status.  "Verified" means by an independent third party.  "Delivered" means at least a few have been sold in arm's-length transactions (i.e. not special favors to developers or reviewers).
UPDATED: 22-Jun-2013 changed BFL numbers from post-tapeout claim (7.5GH/s) to actual measurement (4GH/s).
UPDATED: 21-Jun-2013 added Bitfury 65nm 55nm figures (and fixed arithmetic error).

Known Figures


I will list a chip in the table above when we have all of the following data:

• Hashrate either in a claim from the manufacturer or measurement by a third party
• Die size either in an unambiguous claim by the manufacturer or die photo from a third party
• Process node in an unambiguous claim by the manufacturer
• A plausible date by which independent verification will be possible.

Summary

As more and more announcements about bitcoin-specific chips come out, it would be useful to have a metric that compares the quality of the underlying design. I recommend "hash-meters per second" as a metric.  This is calculated by dividing the hashrate (in H/s) by the die area in square meters and then multiplying by the cube of the process's feature size in meters (half of the process node's "name", so a 90nm process has a 45nm feature size).  If you use hash-picometers instead of hash-meters you wind up with reasonable-sized numbers.

Current GPUs and FPGAs get 8-24 H*pm/s; the three ASICs we have numbers for have η-factors around 2,400-2,800 H*pm/s -- 100 times more efficient use of silicon than FPGAs and GPUs.

Migrating a design from one process to another by direct scaling -- when possible -- will not change this metric.  Therefore it gives you a good idea of how the "rising tide" of semiconductor process technology will lift the various "boats".



Details

Process-invariant metrics factor out the contribution of capital to the end product, since the expenditure of capital can overwhelm the quality of the actual IP and give misleading projections of its future potential.  A 28nm mask set costs at least 1000 times as much as a 350nm mask set, but migrating a design from 350nm to 28nm is not going to give you anywhere near 1000 times as much hashpower.

This metric probably does not matter for immediate end-user purchasing decisions -- MH/$ and MH/J matter more for that -- but for investors, designers, and long-range planning purposes it gives a better idea of how much "headroom" a given design has to improve simply by throwing more money at it and using a more-expensive IC process.  Alternatively, this can be seen as a measure of how much of its performance is due to money having been thrown at it.  That is important for investors -- and the line between presale-customers and investors is a bit blurry these days with all the recent announcements.

As semiconductor processes become more advanced, two important things happen:

  1. The transistors get smaller (area).

  2. The time required for transistors to turn on gets shorter (speed).


Area

Generally #1 (area) is indicated by the process name.  For example, in a 90nm process the smallest transistor gates are 90nm long.

Chip designers refer to half of this length (i.e. 45nm on a 90nm process) as the feature size.  The feature size is half of a gate length because you can always place transistors on a grid whose squares are at least half the length of the smallest gate.  Usually you get an even finer grid than that, but it's not universally guaranteed.

Therefore, to get an area-independent measure of the size of a circuit, measure the circuit's area (units: square meters) and divide that by the square of the feature size (units: square meters) to get a unitless quantity.  Well, almost unitless.  Technically the units for a process's feature size are "meters per lambda" rather than meters, meaning the units for the final quantity should be (hash-meters) per (second*lambda-cubed).


Speed

Semiconductor processes are also characterized by a measure called "tau", which is the RC time constant (http://en.wikipedia.org/wiki/Time_constant) of the process.  This is the time it takes a symmetric inverter to drive a wire high or low, assuming the wire has no load.

The raw tau factor ignores the load presented by wires and other gates, so instead some desginers prefer to use This is also called the FO4 (http://en.wikipedia.org/wiki/Fanout_of_4) or the normalized gate delay.  FO4 is the same measurement, but each gate drives four copies of itself.

Unfortunately the tau and FO4 numbers can be hard to come by, and they frequently get mixed up with each other (one is listed where the other ought to be).  Also, there is a bit of "wiggle room" in exactly how the RC circuit or loading is done, so it's common to see inconsistent numbers cited by different sources for the same process.  Because of this, using tau or FO4 directly in a competitive metric is a bad idea: people will fight over which tau or FO4 numbers to use.  A previous proposal (https://bitcointalk.org/index.php?topic=113338.0) used gate delays as part of the metric, but I no longer recommend that metric since if it were to gain popularity it would inevitably lead to people playing games with the tau/FO4 numbers, picking and choosing whichever number cast their favorite product in the best light.

Fortunately, there is a fix.  All we need here is a relative comparison of two circuits.  It turns out that both tau and FO4 scale more or less linearly with the gate length (and therefore with the feature size).  So instead of converting hashes/sec into hashes/tau or hashes/FO4 we can use the feature size as a proxy for the gate delay time and multiply the measure of hashes/sec by the feature size instead of multiplying by the tau/FO4 time.  The resulting number will be totally meaningless as an absolute quantity, but the ratio of this metric for two different circuits will still give the ratio of their performance on equivalent processes.


Formula

So the forumla is:


The units for this number are simply "hashes" (or "hashes per square lambda").

However remember that we're using feature_size (measured in meters per lambda) as a proxy for gate_switching_time since there is less wiggle room in how feature_size is measured and the two values tend to scale proportionally.  This substitution gives us:


Since area_in_square_lambda is (area_in_square_meters / feature_size²) we can substitute to get:


which is equivalent to


collecting the occurrences of feature_size gives us:


or alternatively:




Example

The Bitfury hasher gets 300MH/s:


It runs on a Spartan-6, which a 300mm² or 300*10^-6m²die.  Dividing the
hashrate by the area in meters gives:


This is why the Bitfury hasher a convenient example -- out of coincidence its hashrate in H/s just happens to be the same as its die area in square millimeters.  This makes the numbers simpler.

Multiplying the number above by the feature_size (22.5*10^-9) cubed (11390.625*10^-27 meters) gives


which is:


The SI units for 10^-12 are "pico", so the Bitfury hasher gets




Summary

To compute the metric, take the overall throughput of the device (hashes/sec), divide by the chip area measured in square meters and multiply by the cube of the process's feature size.  Shortcut: take the hashrate in gigahashes per second, divide by the area in mm², multiply by the feature size (half the minimum gate length) in nanometers three times.

This number can then be used to project the performance of the same design under the huge assumption that the layout won't have to be changed radically.  This assumption is almost always false, but assuming the design is ported with the same level of skill and same amount of time as the original layout, it's unlikely to be wrong by a factor of two or more.  So I would consider this metric to be useful for projecting the results of porting a design up to roughly a factor of 2x.  That might sound bad, but at the moment we don't have anything better.  It also gives you an idea of how efficiently you're utilizing the transistors; once I get the numbers I'm looking forward to seeing how huge the divergence is between CPUs/GPUs/FPGAs/ASICs.

I propose to denote this metric by the greek letter η, from which the latin letter "H" arose.  "H" is for hashpower, of course.  Here is a table of some existing designs and their η-factor (I will update this periodically):

This metric does not take power consumption into account in any way.  I believe there ought to be a separate process-independent metric for that.

If anybody can add information to the table, please post below.  Getting die sizes can be difficult; I know the Spartan-6 die size above is a conservative estimate (it definitely isn't any bigger or it wouldn't fit in the csg484).[/list][/list]

Nice concept, but you've messed the SI units a bit. Do edit the text.
First you are multiplying by area, than in example you divide by it. (I assume the latter is correct.)


For the above you would get Hm/s.


For the above you get H/m³s  rather than H/ms.

If you want to see how efficiently the transistors are utilized, you have to multiply by lambda (in meters) rather than divide by it.
In effect the units will be actually H/ms, but the calculated values will be a dozen orders of magnitude smaller.

Yes, I swapped the multiplication and division in the instructions.  Thanks for catching this!  I've fixed it.

I've also added figures for the ATI 5870 since it seemed to be the popular card (I've never mined with GPUs so I'm probably wrong here).  I was initially surprised to find that it is has an η-factor that is actually on par with most Spartan-6 bitstreams.  Three reasons for this:

1. We have an exact die size for the 5870 but only an upper bound for the Spartan-6.  The Spartan-6 is definitely smaller than 300mm², but Xilinx won't say how much smaller and I haven't gotten around to grinding the top off of one of my dead chips yet.

2. If you think about it, FPGAs have an enormous amount of routing, and any given design uses only a tiny fraction of it (probably under 5%).  Since η measures only how efficiently the silicon is used and has no bearing on power efficiency, it shouldn't be all that surprising that the unused routing on an FPGA accounts for about the same amount of silicon as the architecture-task mismatch on a GPU.  The main difference is that on an FPGA that unused routing sits idle and consumes no power.

3. The $/(MH/s) for 5870's and volume-priced Spartan-6's using a high-end bitstream is nearly identical -- 2 $/(MH/s).  Unfortunately the mining-hardware market is a lot smaller than the GPU market, so FPGA mining board vendors' markups have to be a lot higher than ATI's.


Edit: it turns out that my estimate of the die size for Spartan-6 was wildly off -- wrong by 250%.  See below for actual measurements from a demolished chip.

Updated to list BFL as 65nm.  Still no die size.

Updated with die size for BFL SC.  We now have the first ASIC η-factor figures!  Thanks for the transparency, BFL.  Hopefully your competitors will follow suit.

So ... reading through the first post ... I've not spotted where it says what use this is.

When firstly it ignores the majority of the non-GPU devices currently mining
BFL Singles, Icarus, Lancelot, ModMiner, Cairnsmore ...

and secondly you forgot to multiply by the colour :P

I'm also not sure how a Bitfury FPGA can come up ~5,192.7 times higher than a BFL SC.
22.5 MH/s/nm vs 4,333 H/s/nm
Makes it seem meaningless.

Here, I'll put it in red for you:




None of these mine without a bitstream.  The bitstream affects the hashrate (and therefore the η-factor) a lot while the particular board has very little impact aside from the number of chips on it.  That's why the η-factor is listed by bitstream, per chip -- just like hashrates.



I can't calculate that because I don't know the die size for the chip in the BFL Single.  If BFL or somebody else posts this information I'll be happy to update it.



The "M" was a typo (fixed).  All the numbers in that column have the same units.

i want to go to heaven now. will you take me home with soft wings?

i want to see for myself how many angels can dance up on the head of a pin

we can quantify them in units hash-yoctometers per second

So you're saying your metric isn't much use since you can't list the most common mining FPGA's?

There are bitstreams and devices used WAY more than anything you listed (ignoring GPUs)

https://bitcointalk.org/index.php?topic=79825.0 <- 6 months ago

Please go troll somewhere else.  That isn't even remotely close to what I said.

All but one of the boards you listed use the exact same chip.



https://bitcointalk.org/index.php?topic=79825.0 <- The die size is not listed in that thread.

Again, please go troll in another thread.

No problem.  That's my specialty.

Updated with info for the BFL SC card, thanks to BFL themselves (hint to their competitors: maybe you might want to consider releasing figures like they have?)


This increases the urgency of getting an exact die size for the Spartan-6.  We've always known the die size is less than 300mm^2: for one, the package cavity is square but the chip is rectangular: in FPGA editor it's almost twice as tall as it is wide.  There's no guarantee that aspect ratio matches the silicon, but it's unlikely to be off by so much that it's square in real life.

I really doubt that BFL is squeezing nearly 2x the eta-factor out of their chips as anybody else, so I now suspect that the Spartan-6 die is substantially smaller than the 300mm^2 package cavity.  Unfortunately I seem to have lost the two dead chips I had… argh.  I'm almost tempted to sacrifice one of the occasionally-flaky-but-mostly-working ones.

Also keep in mind that there's a substantial amount of per-die overhead for I/O pads and clocking infrastructure, so using two huge chips (like BFL does) instead of five tiny ones (like Bitfury would to get the same hashrate) is inherently a more efficient use of silicon -- but not 2x more efficient.  Sadly there aren't any bitstreams for Virtex-class devices that have had as much care put into them as the Bitfury/Tricone/BFL bitstreams for their respective devices.


Edit: the die size estimate for the Spartan-6 was off by 250%; I have actual measurements now (see below).

A moment of silence, please, for the XC6LX150 pictured below.  He gave his life (and his 224MH/s -- slowest chip in the cluster) in the name of science:

http://www.tricone-mining.com/images/deadchip1.jpeg

http://www.tricone-mining.com/images/deadchip2.jpeg

http://www.tricone-mining.com/images/deadchip3.jpeg

Apologies for the low-tech measuring equipment and misaligned ruler.

It turns out that my estimate of the size of the Spartan-6 was an overestimate by more than a factor of 2!  The die itself is 10mm on one side and between 11mm and 12mm on the other side.  Let's call it 10x12 = 120mm².  I've updated the η-factors for all the Spartan-6 bitstreams; these are now final numbers using actual measurements (not estimates) for all of the parameters.

PS: this means that Xilinx's "CS" package, which is suppose to stand for "Chip Scale" is not actually a Chip Scale Package (http://en.wikipedia.org/wiki/Chip_scale_package).  I had assumed it was.

ftfy

Paging Mr eldentyrell!

Avalon chip count and power usage are available. You can now update your comparison table.

chip count:

https://bitcointalk.org/index.php?topic=141300.0

chip power:

https://bitcointalk.org/index.php?topic=140539.msg1497127#msg1497127

Thanks.

Thanks, but I need the actual die measurements, not the number of chips-per-wafer.

Please let me know if/when they are posted by either the Avalon manufacturers (I'll take their word for it) or some third party (must include a photo).

Updated with Bitfury numbers.

Holy insteresting. Watching. Can you add AVALON and ASICMINER?

That information was available since last year.

https://bitcointalk.org/index.php?topic=120184.msg1294431#msg1294431

Quite possible!  I can't keep up with the tangled mess of threads this forum has become…  Case in point, I cannot find Avalon's statement on the hashrate per chip.  If you can post a link to that I'll add them.



That's weird, I wonder if he edited his post, the very next one is a post by me complaining that he posted the packaged size instead of the die size (in Oct 2012).

(21-Jun) Oh my, this is terribly embarrassing.  When calculating the η-factor for bitfury last night I used the gate length instead of the feature size.  I have corrected this; please see above.  No wonder his numbers came out so high.

Any additional checking of my arithmetic would be welcome.

I found a bunch of random third-party sites tossing around the figure of 282 (MH/s)/chip.  If somebody can post a link to someplace where Avalon or one of their employees verifies this, I can finish adding them.  Either hashrate per chip or hashrate for a specific product along with the number of chips in the product (which is the other number that's way too hard to find…)

At 282 (MH/s)/chip they would be η=2,909 slightly better than bifury but still behind BFL.

Sure, as soon as they post their die size, process node, and hashrate per chip.

The way you describe it its not "hash meters per second", its "hash per metersecond".

In post #1: "divide by area and then multiply with length":

(H/s / m^2) * m

= H/(s*m)

NOT Hm/s


Edit: Sorry, i missed the cube. You are right.
its (H/s / m^2) * m^3

I think you mean 10^-12*H*m/s

I think BFL numbers should be counted with 4GH/s per chip: https://products.butterflylabs.com/homepage-subproducts/65nm-asic-bitcoin-mining-chip.html

The original post date is 2012-10-24, with last edit on 2012-12-22. The code block with the process data is quoted exactly on 2012-12-13.
I gave you already the link to the thread with posted photos of the hashing module.

Avalon advertised 3-module 66Ghash/s and 4-module 88Ghash/s device. The picture clearly shows that each module has 80 QFN chips. What else is missing?

I'm somewhat experienced with human factors in the technology education and businesses. Anytime I see PhD-level personnel unable or unwilling to do GED-level arithmetic problem there's always an interesting human story behind that situation. I can't stop wondering what is the story here.

Or maybe it is just my sense of humour failing?

Thanks, you're right.  The current BFL numbers were calculated before they got their chips back, using the 7.5GH/s/chip they were quoting at the time.  I have updated their numbers.  Thanks!

Edit: this puts bitfury back on top by a hair.  I think it's really interesting how close the numbers for the three different first-gen custom chips are (BFL, bitfury, and Avalon) despite a wide range of fabrication processes -- especially compared to the huge difference between them and the FPGAs/GPUs.  I think that partially validates the hash-meters/sec metric.

What's missing is enough of my free time to dig through a 42-page thread.



Calm down dude.

No worries, man.  I've made a ton of these mistakes too…

You're quite right.  Thanks for pointing this out.

Fair enough. But I gave you a link to a two page thread where all the relevant information was in the first half of the first page.
I'm calm, just confused, like many others here. I see you writing posts then almost immediately deleting them, it only adds to the confusion.

Anyway, here's the available Block Erupter a.k.a. ASICMINER information.


There are still no definite information about the die size. There are two posts that predate the tape-out.

I'm also positive that friedcat made other posts that he subsequently deleted, at least one in direct response to my post. It must have been commercially sensitive at that time.

You seem to get needlessly upset/confused/emotional about the fact that people can revise their posts.

I don't see anything wrong with it, although I would favor a 60-minute limit (can't edit posts more than 60 minutes old).  If I had to painstakingly triple-check everything I wrote here before it became engraved in stone this would feel a lot more like work, and I probably wouldn't be inclined to post here.

I have my email client set to sequester outbound messages for 60 minutes, so I guess I've become accustomed to being able to do this.



Hrm, well, in the face of conflicting information I think we're going to just have to wait.  Please let me know if anybody from ASICMINER authoritatively clarifies the situation.

Also, last I heard they were not planning on selling any chips or any products including their chips, which would mean there will never be independent verification.  Maybe the situation has changed; I don't follow the business end of this stuff too closely.  Anyways, if that's still the case I'd be uneasy about including those numbers… they could be fudged quite a bit at zero risk of getting caught.

I fully understand that you don't want to consider the pre-tape-out numbers for the inclusion in your table. But out of three columns there only one is unknown.

But fudging isn't zero-risk for those who ship their hardware to the end-users. It is only a matter of time until one of the Block Erupters that were sold gets accidentaly damaged and the chip will get decapped.

Check out this thread: https://bitcointalk.org/index.php?topic=231400.0 and the recent post of this user: https://bitcointalk.org/index.php?action=profile;u=23585 . For now it is just a re-confirmation of the Avalon data.

What I don't want to include is numbers that will never be independently verified, ever.



Yes, that's the idea.

I thought ASICMINER's plan was to never sell any chips to any third parties and sell stock instead.  Has this changed?



Oh, neat.  I wasn't expecting anybody to actually have a proper die photo setup.  Way cool.

The stock Avalon firmware comes with settings for 282 and 300. Third-party firmwares are overclocking to 350 and above.

Not to add to the table yet, until the chip is working. The calculated value however explains much.

KnC Promised Figures

The area is package area, actual chip area will be significantly smaller, so the η value will be higher.
Edit: The die area is exact (55 mm x 55 mm), the package is 90 mm x 90 mm. Source: https://www.youtube.com/watch?v=by-je8XRCdY

Second edit: I must had misunderstood the video when I had been watching it for first time. There they stated quite clearly, the chip (the package) would be the size shown, about 60 mm x 60  mm,
not the die, which will be much smaller.
The conclusion:  η  should be significantly greater than 90.

I was seriously wondering how his numbers were possible!

Okay, now do KNC's numbers!

If I understand this metric correctly, it gives us some measure of how much design/development team optimized the performance onto the given die size.
I see the best use of it when comparing ASIC technology chips, since they are 'application specific' chips for bitcoin mining (GPU developers had different goals when designing their products).
KnC's chips don't stand well here. They just took some fpga desing, converted it to asic with some manufacturer's standard technique, and are going to put as many cores on a die as they can.
If they did the optimization in a range as Bitfury, Avalon or BFL, they would have a chip capable of 3,000 Ghash.

So you gather it's a structured ASIC (https://en.wikipedia.org/wiki/Structured_ASIC_platform)?

EDIT: Yes, they themselves state it as such.  No, Marcus from KnC said: "this specific design is standard cell ASIC 28nm"  (https://bitcointalk.org/index.php?topic=232852.msg2468045#msg2468045 (https://bitcointalk.org/index.php?topic=232852.msg2468045#msg2468045))

BTW: Optimizing it to get a chip capable of 3 TH/s is of no use, because it would need to take and dissipate 6000-7000 W of power.

Thanks. Forgot about power and heat. I just reversed the formula...

Can we try to figure out this metric for the Block Erupter chips? I can't find the die area, but here are the other figures:


Judging by these pictures, it looks really small:

These are some numbers derived from the RTL design.


We know that the chips ended up hashing at around a third of that (336 MH/s), but the power estimate seems accurate (6-8 J/GH).

Kano, remember the BFL chips are artificially limited to 4 GH/s because of problems with power and heat density. In different circumstances (bigger boards, one good heatsink per chip) they possibly could reach 10 GH/s or more.
I think we will see such results when people start DIY with BFL chips. There can be of course problems with clock/capacitances/etc. in higher frequencies but the η metric will be quite higher than for current revision of Avalon chips.


As to figuring out η for Block Erupter chips:
(0.336 GH/s / 21.7 mm[su]2[/su]) * (130 nm / 2)[su]3[/su] = 4252.25

It seems the current formula attaches too much importance to the process node (the path width). I think it should be counted with power of 2 not 3.
(The path height is not directly proportional to its width - I think it can even be comparable between the processes in range 28-130 nm. I've found no exact info. I someone knows more, let us know.)
Relevant η' values would be:

The above values are more consistent with the technologies used.

No, they specifically said it's not a structured ASIC.

Do you have enough info to do KNCMiner yet?

Right. I was wrong.
Marcus from KnC said: "this specific design is standard cell ASIC 28nm"  (https://bitcointalk.org/index.php?topic=232852.msg2468045#msg2468045 (https://bitcointalk.org/index.php?topic=232852.msg2468045#msg2468045))

Maybe it's just me, but when you tell me Bitfury has a 2800 score and KNC a score of 90, that really seems odd. Especially considering KNC's gigahash/watt is better than Bitfury's or BFL's. It really makes me question the relevance of this metric to me. Are you saying KNC, or someone, if they had access to KNC's design could replace it with a design that's 30 times more efficient? Are we saying KNC's design is basically one giant fuckup? Doesn't seem to make sense or accord with known facts.

I'm gonna assume that we simply just don't have enough technical details to make a determination and that's why KNC still hasn't been added to the OP list.

KNC's chip is purely theoretical.

Area is taken into account in this metric. In theory, a gigantic die size could cram tonnes of hash power on a single "chip" and thus compare favorably with Avalon when measured per chip. When you measure using area, it normalizes for this and gives you a "better idea" about efficiency. I am not sure I am a fan yet, but it is an interesting way to measure ASICs ;)


That makes more sense.

All I see if you trying to make an excuse to pick some useless number to say the crappy tiny ASIC chips are good when in fact they suck.
The metric is useless except it seems to apparently show the low tech chips pretending to look better than the low tech crap they are.

Clearly the progress is zero.

Again, compare the functionality, design and performance of the two chips in questions and you see the metric is pointless.

I guess we could even take it a step further and look at the implementations of 2 certain chips and see it's even worse ... but that's off topic.

The metric is basically ... "If we could actually get the manufacturers to produce chips at the nm size they should have and also parallelised them how many time they should have then here is a magic multiplier (that will get the answer wrong) to say how they compare"
Again the number is pointless and meaningless.

We even have someone ranting about the number of devices delivered so far ... well ... there have been WAY more BFL devices delivered than AVALON devices ... but that is again off topic.

Nothing has really changed since my first comments about the metric and the results even prove that.

I think KANO would detest and argue against any metric that would compare Avalons favorably to BFL whether or not they were valid. That is what I would call bias. So we can disregard him and let the thread get back on track. Measuring things not posting personal opinions about chips and companies. Please post elsewhere Kano we get it you don't want to explore this metric. Can you guys take your bickering elsewhere please!

Bumping my question for the OP to the front again:

Data for many old and new CPUs, author colected most data we need here (die size, process node, benchmarks). I will try to put some of those in a spreadsheet.
http://www.alternatewars.com/BBOW/Computing/Computing_Power.htm

EDIT: Even better page:
http://www.x86-guide.com/en/marques/Intel.html

Maybe just looking at AMD vs Intel over the past few years be an interesting gauge right? There is a clear "winner" in those two designs... I wonder if this metric would agree with the market?

So ... who gave a moderator a blowjob to remove this particular post of mine?

It is indeed directly on topic and valid unless the moderator was a moron?


Yeah good on removing all the other crap, but no reason at all to remove this one.

It wasn't deleted, it was moved to offtopic: https://bitcointalk.org/index.php?topic=250364.0

And it _is_ offtopic:  This whole thread is about a _process invariant_ metric. Its an approximation of the performance if fabricated on a similar process with a similar die size.  The absolute performance of the devices as fabricated are available all over (and even in the OP, at least in per-chip form).

You can yabber on about how BFL is "pure custom" and avalon is a "dirty hack"— but thats irrelevant to the thread, the thread is about the proposed process invariant number and your message was not, so it got moved with all the other off-topic dicksizing which it had inspired.

And how would a consumer buying ASIC based product use this metric for choosing which product to buy?
Sounds to me like it's a calculation for the sake of calculation.
Not useful in any shape or form to anyone.

There are only 2 metric that are useful:
1) Cost in $/GH for manufacturer to make - only few know what it is exactly and can vary by 200%-500%
2) Cost in $/GH for consumer to buy.
2.1) Cost in $/GH of running the system

You wouldn't— perhaps you've confused this for a thread in a marketplace section? Products are part of the subject of this subforum, but they're not the only part.

This is a technology thread, not a what to buy thread. You'll note that there is no mention of prices in the original post: any what-to-buy thread would be useless with them.

Ha. On the contrary, I think both of those metrics are irrelevant. What matters— when it comes to buying mining products at this time— is what is available when. ... but all three of these are offtopic for _this thread_. Please keep further discussion here to the subject of set out in the first post.

Obviously price goes hand in hand with availability.
But you still didn't answered how is this (hash-meters per second (η-factor)) useful to anyone?

EldenTyrell, on the website Bitfurystrikesback.com Mr. Bitfury claims a hash rate of 2.7 GH/s per chip. In this thread, you claim 2.0 GH/s per chip. Please explain and/or correct this discrepancy. Thank you.

The highlighted part is incorrect. At least based on the announced specs for the KNC chip.

The power usage of the Bitfury chip is around 1 GH/J: https://bitcointalk.org/index.php?topic=228677.msg2635052#msg2635052

The power usage of the KNC chip is 400 Mhash/J: https://www.kncminer.com/categories/miners

They did some tests at 2.7 GH/s, but probably chip wasn't stable - even their 25 GH/s boad uses 16 chips!

Collecting data for CPU comparison takes time, there are so many models.
In the meantime, I put together a table calculating how many GH/s can be put on a wafer with chips we know:

wafer (mm)    chip       process (nm)     die(mm^2)   chip GH/s     dpw       wafer GH/s
----------------------------------------------------------------------------------------
300           avalon         110            16,13         0,282     4214      1188,35
300           bitfury         55            14,44         2         4717      9434,00
300           bfl             65            56,25         4         1167      4668,00
300           KnC             28          3025,00       100           11      1100,00

EDIT: KnC die size is not known. In the early stage of the KnC website, I remember reading die size of 55x55mm. On the 'openday', they were talking about package size of 70x70mm or more. Latest info on website is for 55x55mm package size.

How do you calculate that, exactly?

Is it simply wafer_area/die_area*GH_per_chip? When I try that my numbers don't quite match up with yours (although they're close).

Also, what is the figure for ASICMINER's chips?

'dpw' (die count estimation) is calculated by the formula (http://en.wikipedia.org/wiki/Wafer_(electronics)#Analytical_die_count_estimation):

dwp = PI * wafer_diammeter * (wafer_diammeter/(4*die_size) - 1/sqrt(2*die_size))

Don't know the exact die size for ASICMiner chip - is it 17,5 or 21,7 mm^2?
17,5: dwp = 3877, GH/s per wafer = 1291,04
21,7: dwp = 3112, GH/s per wafer = 1036,30

(over here, we are using ',' for 'decimal point')

Cool, thanks. I don't think ASICMINER has published the die size of their chip. We only have estimates. But it's probably in that area, perhaps even smaller.

Ujka, bitfurry?

http://2.bp.blogspot.com/-QltUgaIclVo/UZNw6uw0NJI/AAAAAAAAExs/L0ZMfsCbl3Q/s640/Joanna-Pybus_Furry-Clutch_Orange-Front_Bengt-Fashion-460x654.jpg

In prev. (erased) post I hardly noticed that strike over 'r'! Now I see  ;D

You put the package size instead of KNC's die size (which is currently unknown I think).
https://www.kncminer.com/news/news-22

Yes, I must had misunderstood the video when I had been watching it for first time. There they stated quite clearly, the chip (the package) would be the size shown, about 60 mm x 60  mm,
not the die, which will be much smaller.
The conclusion:  η should be significantly greater than 90, and  η' quite higher than 6.5.

We've got info on KNC's die size (https://www.kncminer.com/news/news-25) and the like, how about an update to the OP?

That has the package size, not the die size. Or if it does, I did not see it.

Od the package, there is also a die rectangle shown - 43 x 43mm, quad core (multi-chip package). Then each die is 21 x 21mm.

I apologize for not responding over the last few days; catching up now….

Thanks RHA, I appreciate you collecting this data and putting it in table form.  Please let me know when the vendor confirms these numbers (hopefully in something other than a video…) and gives a ship date so we have know when we can reasonably expect third-party verification.



I can't comment on KnC's specific case, but this sort of situation is exactly what the eta-factor is designed to detect -- crappy designs which have simply had gobs of money thrown at them in the form of super-expensive masksets.  Products like that do not have much of a future, but you can fool investors with them for a while...

Unfortunately we absolutely need the die area… there's no way around that.

No, it shouldn't… please re-read the original posting.  The feature size is counted to a power of 3 to account for reduction in area (factor of two) and the decrease in gate delay due to decreased channel length (an additional factor of one).  Please provide some sort of justification, other than:


What the heck is the "path height"?  Are you talking about the channel oxide thickness?  That decreases too.  Either way, since silicon is dirt cheap the goal here is not to estimate the cost of the physical silicon required as a bulk material -- nobody cares about that.

I agree.  That would show another large gap (CPU-GPU) in addition to the GPU-to-FPGA and FPGA-to-VLSI gaps.  Illuminating these sorts of generational gaps is one of the goals of the eta-factor.

That website didn't exist the last time I updated the table.  If you click the "2GH/s" link you'll get the most recent posting by him at the time I added him to the table; it shows 2GH/s at nominal vdd and 2.26 when overvolted.  2GH/s is also the figure he gave me via private email.

I will be happy to update the entry if he confirms 2.7GH/s/chip; please just send me the link.  I'm a bit leery of switching to information from his distributors (who probably don't even have the chips yet!)

FWIW I'm still a bit mystified by the photos on his vendors' site showing a QFN chip with "5 GH/s" silkscreened onto it.

I've been thinking a bit about a process-invariant metric of power efficiency.  This is harder because it's so easy to game the power efficiency by playing with the supply voltage -- as it decreases you get a quadratic improvement in joules/op, so in theory the measurement ought to be (ops/(sec*joules²)), but even that isn't going to be constant across all operating voltages -- there are a lot of second order effects.

On top of all this, some designs have vastly larger ranges of operating voltage than others.  Some chips only work across a narrow band of voltages, others will keep working right up to the point you fry them (my last 90nm chip did this) and all the way down to the point where the chip is consuming less than half the overall system power.

So I'm starting to think that any sort of sensible measure of power efficiency is going to have to be a graph.  A good first try might be a plot of eta-factor versus joules/op across all voltages in 25C ambient temperature.

I doubt that is the die size on the package diagram. For comparison, the Tahiti version of the AMD GPUs which was one of the largest ever chips ever had 4.31 billion transistors. Tahiti was only 398mm2 in size. If you are saying the package has 4 x 441 mm2 dies on it, then it would have a heat density higher than a nuclear reactor.

I doubt such a thing could be engineered, but if it was, it would have a hash rate far in excess of KNC's claims.

Why not graph it along a set range and then use the area of that graph as the metric.

Hmm, yeah.

You didn't read the thread carefully enough, did you? :)
Just four posts earlier:


The link links to KnC's own news with fresh technical details and especially 43 mm x 43 mm die size.
So:

KnC Promised Figures

Design	MH/s	Device	Process node, $\lambda$	Area	η    (H*p (http://en.wikipedia.org/wiki/Pico-)m/s)
KnCMiner	100.0GH/s (https://www.kncminer.com/news/news-22)	Custom	28nm, 14nm (https://www.kncminer.com/categories/miners)	1849mm2 (https://www.kncminer.com/news/news-22)	148.40

I just can't believe the die will turn out to be that large. Nobody builds 43x43mm dies.

I have made this point several times, but it seems to just fall on deaf ears. Plus, the schematic that people are pointing at and saying "die size" is the package schematic not the die schematic. The package is usually several times larger than the die.

For instance:
https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcRHTRDg1bdkbBr6zAfkNVFMnzx5ah877VPz7BHHxmHHR7Se_RpX

The outer dimension is the package size, the inner brownish square is the die size.

I think accounting for decrease in gate delay kind of duplicates accounting for reduction in area.
We can prepare any metric and keep to it, but a metric is useful if it gives us results conforming to real world values.
The η-factor definition implies that simply going from 130 nm to 65 nm we get 8-fold speed increase (keeping die size constant). Is it real?
My impression is the η' (using power of 2) better represents what we get. However, we have too little samples yet, to be able to decide which one actually is better.

You didn't follow the link, did you?
That's a quad solution: four dies on one chip. Each one is 21.5 x 21.5 mm and should have 25 GH/s, but it gives us the same η value as one 43 x 43 mm die outputting 100 GH/s..

I don't really think this is actually process invariant if the limiting factor is thermal, rather then purely a signal propagation delay. I mean, Avalon chips ship at 300Mhz, but are known to run at 450 and theoretically even more if it were only a transistor transition time.


Actually the link shows one die with four 'quads'.  For all we know, each quad is independently wired to the package, and the other three will work if one is flawed.  However, the diagram clearly shows all four units on the same die.  There is literally a single grey box with the label 'die' inside the package and containing the four 'quads'

Also 43x43 is only the size of the 'bump' on the package, it isn't necessarily the actual size of the die at all.  It could be much smaller.

All the multi-die packages I've seen leave a few mm of space between dies. So the actual die size is likely to be under 20x20

Everyone has followed the link. You are measuring the package area not the die area. There are no measurements associated with the ASIC section of that series of pictures. It is bizarre accounting to use the package size for one chip but the die sizes for all the others.

I don't see a die size on that webpage.  Please refer to the table critera in the first post -- "Die size either in an unambiguous claim by the manufacturer or die photo from a third party".  I'm not going to go about guessing the die size based on the package.

Thermals are a power issue.  I've been pretty clear and up-front about the fact that this metric does not account for power consumption in any way.



I don't list theoretical results.

If Avalon are willing to stake their reputation on a public claim that their product provides 450mh/s with heroic cooling, and a third party verifies that using a few randomly chosen chips, I'll list them at 450mh/s.

I think there's important information in the curve that isn't captured in any sort of scalar summary of it.

For example, somebody who's renting space in Douglas County (http://www.douglaspud.org/Service/2011Rates.aspx) cares more about the eta-factor at very power-inefficient points on the curve, while people mining at home as a hobby (are there any left?) in, say, California, care more about the eta-factor at the very power-efficient point on the curve.

Others (like me) care about the steepness and width of the curve since it's a form of insurance against future difficulty increases, which are impossible to estimate to the sort of accuracy needed for major investments.  Burn more power today to get the equipment paid off as quickly as possible, burn less power later on to keep running for as long as possible.  I'll probably be undervolting my Spartan-6 mine (which I'm amazed is still profitable) soon in order to squeeze out an extra month or two before it becomes unable to pay for its own electricity.

The firmware they ship has a setting for 300 mh/s, so it's safe to include that speed in the chart.

Most miners are using a custom firmware that autoclocks. 350 mh/s is typically about where the autotuning settles for Avalon-supplied boards. I would consider that overclocking, and not appropriate to include in the chart.

To get the chips to go to 450, custom boards need to be used.

I said 450Mhz, not 450MHash/s, but that would would be about 439MHash, maybe.

Here's a quote from Bitsyncom referencing the 450Mhz figure:


The 300Mhz the unit shipped with was based on the PSU and cooling, not the chip.

I wouldn't call "the number you are all aiming for" staking their reputation... or even a claim.  Vague comment is vague.

Let me put it another way: is it their stated policy to replace any customer chips which won't go above 300mhz as part of the warranty?  If I bought 1,000 chips from them and tried to return the ones that wouldn't go above 300mhz would they take them back promptly for a full refund?  Has someone tried this?  These are the sorts of things to look for.  There will always be significant chip-to-chip variation; since you can't test their unsorted wafers yourself you have to rely on their public statements and returns policy (i.e. staking of reputation) to figure out what counts as "typical".

I disagree. Bitfury's power consumption is actually better than KNC's current published specs.
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)

John
HashFast

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.

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:
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.

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 (http://users.ece.gatech.edu/~scotty/pdf/Deb02-TVLSI.pdf).  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).



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

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?

Yes, you have a good point there; I suppose it ought to be "ITRS (http://en.wikipedia.org/wiki/International_Technology_Roadmap_for_Semiconductors) 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.



Hey, at 55nm nothing's "cheap" :)



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).



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.



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.



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.

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.

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.

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

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

.. 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. :)

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.



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, 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.


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.

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

Hello eldentyrell,

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

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