I'm going to just preserve this here for future reference, so people won't need to dig through some archives or caches.

Cointerra/Team
 
Cointerra boasts a highly experienced engineering team of semiconductor architects and designers who have previously designed some of the world’s highest performance CPUs, GPUs and chipsets for Nvidia, Intel, Samsung, Qualcomm and Nortel. Having worked on several generations of low-power mobile devices, our team brings tremendous experience in power efficient circuitry, design methodology and implementation to the exciting new frontier of Bitcoin mining.

Executive team

The architecture, design and development effort is lead by : Ravi Iyengar, Dr. David Tannenbaum, and Jim O’Connor. The Advisory Board is headed by Dr. Naveed Sherwani.
 
Ravi Iyengar
FOUNDER & CEO

http://www.linkedin.com/in/ravidiyengar

Before founding Cointerra, Ravi was a Lead CPU Architect at Samsung Corporation. Ravi brings with him 15 years of industry experience in Architecture, Design and Verification in CPU, GPU, Desktop/Server Chipsets and ASIC Cores, and years of leadership experience in top Semi-conductor companies like Samsung, Qualcomm, NVIDIA, and Intel. Ravi has a Master’s Degree in Computer Engineering from Wright State University and a Bachelor’s Degree in Electrical Engineering from National Institute of Technology, India.
 
Dr. David Tannenbaum
Chief Architect

http://www.linkedin.com/pub/david-tannenbaum/12/4b6/647

David works as a Consultant Architect & Designer at Cointerra. He is a Principal Engineer at NVIDIA Corporation and has over 25 years of experience in the industry. He brings with him vast experience in the design of arithmetic intensive logic including single, double precision floating-point, custom floating-point, IEEE formats, transcendental support, fused multiply-add, integer operations, conversions, logical operations, custom instructions, exponentiation, logarithms. Inventor on 20+ patents. David has a Ph.D in Electrical and Electronics Engineering from  Rensselaer Polytechnic Institute.

Jim O’Connor
VP of Engineering

http://www.linkedin.com/in/jgoconnor

Over 35 years of experience in design and management. Jim has held management positions at Altior Inc(now Exar), SMSC(now Microchip), iVivity, Zagros Networks and Orologic(now Vitesse Semiconductor), Nortel Semiconductor and BroadBand Technologies.  

Jim has also held lead design positions at BroadBand Technologies, Star Technologies, General Electric, and Teledyne. His experience includes SOC design and verification, Assertion-Based Verification, physical design, systems design, software and firmware in graphics, datacom, telecom and security.

Jim is a graduate of General Electric’s Edison Engineering program and holds B.S. and M. Eng. Degrees in electrical engineering from the University of Louisville’s Speed Scientific School.
 
Dr. Naveed Sherwani
Advisor

http://www.linkedin.com/pub/naveed-sherwani/0/89/2a7

http://en.wikipedia.org/wiki/Open-Silicon

Co-Founder, President & CEO of Open Silicon. Prior to co-founding Open-Silicon, Dr. Sherwani was the founder and General Manager of Intel Microelectronics Services where he led efforts to promote the use of disciplined ASIC methodologies to improve design efficiency and time-to-market. He currently chairs the GSA (Global Semiconductor Association) Technical Steering Committee.

Dr. Sherwani co-architected the Intel microprocessor design methodology and environment that has been used in several leading microprocessors. Prior to joining Intel, he worked as a consultant for various telecommunications and computer companies, mainly focusing on ASIC design flow and cell library design to improve time-to-market.

Dr. Sherwani is the author of textbook on Physical Design, which is widely used as the main textbook at major universities around the world. In addition, he has authored or co-authored three books and over 100 articles on various aspects of Physical Design Automation and ASICs.

And I need to make a correction to your correction. The power efficiency increase is achievable, just not by Cointerra, simply because Cointerra doesn't have the required expertise in the back-end of the IC design. This still leaves the room for improvements made either by a new entrant or one of the existing vendors.

I thought a bit about how to answer this question without jumping into jargon and nitpicking. It will not be a direct answer, but an open ending line of thought.

Go into the miner software threads that have the longest history: cgminer and bfgminer. Note what was the allowable and optimum value for the hardware error rate reported as the technologies changed: CPU, GPU, FPGA & ASIC. Do you notice the trend? Which way is moving? What is the allowable error margin for some of the digital and analog devices that you know? You can make up your own mind after answering those questions.

Based on the past experience this subforum will soon be flooded by the posts from the professional bologna slicers. Would you like some NDA with your bologna?

You know, I tried to understand your question in the context of the currently publicly available information and came up the following answer.

It seems like you are looking for the advice about investing in the hands of the poker players who keep their cards very close to their vests. My engineering advice is a referral to a professional poker player. On this board that would be Brian Micon.

It may look like a blow-off, but it really isn't. I feel ethically obliged to urge people to learn how to distinguish between gambling and investing.

On this occasion I'd like to post a good advice that reeses had given about a year ago:
I read that book, and although it was written between the world wars, it is very pertaining to Bitcoin. Here's a short excerpt:

• Locating and investigating a well-to-do victim. (Putting the mark up.)
• Gaining the victim’s confidence. (Playing the con for him.)
• Steering him to meet the insideman. (Roping the mark.)
• Permitting the insideman to show him how he can make a large amount of money dishonestly. (Telling him the tale.)
• Allowing the victim to make a substantial profit. (Giving him the convincer.)
• Determining exactly how much he will invest. (Giving him the breakdown.)
• Sending him home for his amount of money. (Putting him on the send.)
• Playing him against a big store and fleecing him. (Taking off the touch.)
• Getting him out of the way as quietly as possible. (Blowing him off.)
• Forestalling action by the law. (Putting in the fix.)

Which side of the cellular? In the pocket or on the tower?

If you can answer the above question you can deduct my answer based on my previous post.

I'm not going to fight with your strawmen about Nvidia/ATI. Just quoting for the future reference.

There's no need to bullshit here about "optimising datapaths". SHA-256 is basically just a pair of 32-bit-wide shift registers with some cobinatorial logic thrown in the feedback loops. The cryptographers at NIST/NSA/etc. worked really hard to make sure that this logic is not minimisable in any meaningfull way because that would make it susceptible to cryptoanalysis. The "architectural" tricks would've already been exploited by the cryptoanalysts. There isn't any way to optimize power by e.g. not clocking parts of the circuit when not in productive use, which is where the most of modern CPUs and GPUs save power. So please no further low-power bullshit unless you can tell us how your low-power strategy applies to a circuit with 50% signal toggle probability. Nobody's going to run a pocket bitmine on a battery power.

There are some implementation tricks possible that minimize the critical timing paths, but they are all already published in an open literature or at most behind the ACM/IEEE paywalls. Other designers already took advantage of them, bitfury even sort-of republished the information behind the paywall.

Anyone who implemented SHA-256, even in software, knows that it is a self-testing logic, so please no further bullshit about design for testability.

The last remaining avenue for the significant gains is by somehow exploiting the high toggle rate in the circuit. The gates and flip/flops change state at the rate very close to the maximum possible, which normally happens only in a test structure called ring oscillator. My personal bet is that the progress will come from designers that take advantage of that and instead of using the bang-bang static logic use something out-of-ordinary: maybe some relatively obscure dynamic logic or some low-noise logic current-mode logic (a.k.a. source-coupled logic). Or the combination of the above: DyCML. Or something which I haven't even heard of.

Anyway, if anyone of you is going to visit Cointerra: ask them about their BSIM4 models, which of the 5 process corners they've simulated thus far, pay close attention if they have anyone working in analog simulators to optimize metal thickness and optimize the transistor/gate geometry to facilitate the best power noise bypass.

Bitfury's 5GH chip currently hashes slower primarily because nobody had spend any time on the problem of heath-sinking the QFN package. Also QFN is wire-bonded, which basically is a collection of half-turn induction coils. Those require very careful analog resonant pin/pad connection design, which again nobody had spend time on.

The way I see it, the progress will come from another company, which has designers experienced in analog/mixed signal ICs and who did high-power designs like cellular tower radios or synthetic aperture radars.

Edits: spelling and underlining.

This is the first paragraph that actually contained technical information.

Seems like they are a front-end house with crew of front-end designers. To make a big gain in hashing performance they will need back-end expertise in analog design, not anything related to CPU architecture, cryptography or design for testability.

From the content-free press release that says "today our CEO put the pants on starting with his left leg, the same way as he did it the past" one can clearly infer that they are scared shitless and witless. The usual ass-kising PR doesn't work well when the ass-to-kiss is distributed, like in Bitcoin.

I wouldn't expect any breakthroughs from them. CAD-monkeys they aren't, but they also are sailing for a territory that is new for them. I expect another safe static CMOS logic design like from every one else thus far. Don't expect them to explore the frontier of Bitcoin hashing. They gave themselves no time for it.

Obviously, there is a small possibility that the insipid PR is just a cover-up for the ace-in-a-sleeve of a designer who already did several iterations of the hasher design on a side while working at the previous job.

Thermal and power and simultaneous switching noise. Standard cell libraries are designed for standard toggle rates. SHA-2 is very close to the theoretical maximum toggle probability (when doing the approximate/probabilistic power/thermal/noise simulations).

Is there any evidence that Uniquify designed a IC that required a heatsink? Or are they experienced CAD-monkeys that "design" ICs by cutting and pasting "intellectual property" black boxes to create SoC-s for the portable and battery-operated market segments?

It would also probably help to define what the word "risk" means here. It isn't the risk of getting a non-working or extremaly bad yielding chip. The risk is that the chip has to be severely derated to actually work. And by derated I mean underclock but overvolt to combat the internal noise in the chip.

The helveticoin user was also from some established ASIC design house and they had 28nm prototype hashing chips either late last year or early this year. But their design seems to be non-viable commercially because it was designed like just another integrated peripheral for the SoC CPU.

STM is apparently making them in Crolles, France; not in any facility that you've enumerated.
http://www.st.com/web/en/press/en/t3405

Who cares about "volume" production in the way "volume" is used in the semiconductor industry. KnC isn't and isn't going to reach that size of the orders. "pure play" vs. IDM distinction also doesn't really matter. What does matter is that the list of fabs capable of making KnC chips is much longer that you've proposed. Because the Bitcoin miner is essentially free from intelectual property encumberances it is also free from many other manufacturing constraints typical in the industry.

At least for STM the above statememnt isn't true. And it wasn't true for almost a year.

They can last years if you have a decent mix of reads and writes for the flash technology. Typical write-ahead-log is a worst case write-amplification pattern: writes 512-byte blocks, forces physical sync/flush to the drive, which in turn forces full page (about 4096-bytes) relocate and erase in the flash controller. And to add the insult to the injury that data is never read unless the database or the OS crashes.

I don't know of any way to check it while the disks are online, besides continuously monitoring the S.M.A.R.T. parameters with smartmontools and hope that the "old-age" statistics shown by them aren't lying.

The folks I know would simply run a full backup, full low-level security erase of the flash drives and then full restore. The security erase may help fix the bottlenecks in the wear-leveling software in the flash controller that is causing those random delays.

But they also aggresively use the warranties on the flash drives, preemptively returning them before the warranty expires. This is only workable if one orders such drives in quantities large enough to compile some sensible wear statistics.

Due to the extremely competitive nature of this business it is quite hard to get true and correct information about the wear-leveling algorithms used and their interaction with file systems. I'm sorry about not being able to be more specific: on one hand there are NDAs, on the other hand the flash controller firmware changes very frequently.

To get flash SSD last several years you'll need to mix them with normal spinning drives. Since database logs are almost exclusively sequentially written and almost never read they won't bottleneck the whole machine.

Edit: If you are willing and able to rebuild your kernel there ware some patches that use ATA TRIM and optional bitwise negation to significantly reduce the flash wear on some controllers. The frequent operation of "allocate disk blocks sectors and initialize to zeros" is replaced with simply "erase block" which initializes flash to all 0xFF and then stores all data complemented. Folks who created and maintained those patches would presumably know for which controllers they are worth applying and maybe if there are other custom patches for similar circumstances. The other strings worth seaarching may be "Deterministic Read Zero after Trim" DZAT, which basically refers to the same idea implemented closer to the actual hardware.

Edit2: I keep forgetting about the partition table issue. Many OS installers continue to create the "compatible" disk partition layout with integral number of "cylinders" (C/H/S == x/255/63). With 255 "heads" per "cylinder" and 63 "sectors" per "track" you would be assured that the partitions have odd sizes and alignments. Therefore the most common I/O operation 4kB is assured to cross into 2 physical 4kB sectors. Various optimizations then become ineffective and they automatically disable itself for the sake of safety. This is related, but non identical, to the "long sector" "advanced format" on the mechanical drives. Just make sure that you didn't accidently set your system into "512 byte sector emulation" (512e) mode.

Do you guys think that it is easy to keep so many mirrors of the backend database: NSA, CIA, FBI and now SEC?    I hope SEC will finally publish the most interesting deleted posts.

Or maybe the SSD disks storing the backends are getting worn out? Nearly random and multi-second delays on writes are common symptoms when using flash SSD drives to store databases with write-ahead-logging, which is the worst wear pattern for them: many writes and no reads.

I can take slow, but dread the disappearance of Bitcointalk. I remember loss of fuckedcompany.com post database and it was dreadfull loss to the information technology folklore.

I'm just saving this for the future reference. This is perfect example how one is supposed to shill for the software treadmill supplier: first make sure to not follow any quality management process and then produce the stream of rapid updates.

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?

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.

From what I've heard the target application for this is IPsec portion of the IP stack, together with the already existing AES instructions. In all the operating systems. Apparently Broadcom and/or Marvell had made some inroads into the Intel network chipset territory by doing IPsec at much lower watts per megabit per second.

Because you read an one-page press-release and you've assumed that it is a true and complete description of the underlying business relationship and an executive summary of the non-public business contract between two entities not traded on exchange and not subject to the disclosure regulations.

On the other hand, I know that you (perhaps voluntarily) run public relations for KnC (a competitor), so in truthfullness I wouldn't expect anything else from you.

Technically this one-page letter was an exact equivalent of bitfury making an one-line post "reserved" under the opening posts anouncing the products based on his chips.

Edit: It doesn't merit a separate post, but I want to preserve the hot response against possible future changes or deletions a la reeses.
Edit2: Thank you very much. Hopefully I fixed it and didn't make another mistake.
Edit3: I'm not entering into the thread-bumping games with the PR reps. I'll acknowledge the replies by editing my most recent post, which just bolds the thread without bumping it to the top. Thanks.
Edit4: Ha, ha. At the time of this quote reeses had previous post early in April and a total of 2 posts this year. We are missing you, dude!

The non-sequitur-s like above keep popping up on this forum. But repetition doesn't make them true.

For the organization like Uniquify, which for years was and is engaged in the IC development:

1) fab could have been booked 5 years ago with a long-term contract

2) alternative product lines could be a financial-risk-reduction strategy

3) the mask-making costs could be slipped into cracks in other ongoing projects

4) Bitcoin hashers are extremely repetitive, self-testing, fully-observable, among the few logic circuits where even the reset signal is not required, could be made without any licensing or intellectual property expenses. As such the costs could be shared between the design house and the fab with the suitable agreement about sharing the results of tests

5) I would not exclude the possibility of Bitcoin hashing kernel becoming one of the benchmark test structures used in the IC fabrication industry. As such they could be then manufactured in small quantities essentially for free.

So yeah, please speculate, but keep it grounded.

Very cool proposal.

If I may suggest one thing: instead of improvising your own confidence measures and decision policies use the existing mathematical apparatus of http://en.wikipedia.org/wiki/T-norm_fuzzy_logics where bool isn't discrete-valued [false,true] but a real value on the unit interval [0,1].

Pretty pictures are here: http://en.wikipedia.org/wiki/T-norm and here: http://en.wikipedia.org/wiki/Construction_of_t-norms , but the point of looking at them is to avoid choosing something that is already known to fail to produce self-consistent results.

Last I've heard Eric was staying in Manhattan, somewhere close to the BitInstant offices. He may have even purchased some real estate in the USA.

But his repurchase of the SatoshiDice shares with the "goodness of the heart" premium to match and slightly exceed the IPO price could definitely be his "get-out-of-jail" card, at least as far as the past actions are concerned.

I really didn't pay much attention to the SatoshiDice sage, but outwardly it does agree with the very professional legal advice that I've heard at lunches.