Quote from: 2112 on August 16, 2013, 08:42:53 PM

Quote from: HyperMega on August 16, 2013, 07:40:05 PM

Most likely this will be stuck-at faults in some of the hash cores (which could be easily detected by a BIST or ATPG tests).

Go ahead, make my day. Take the challenge. Run your ATPG toolset and come up with a "stuck-at" fault vector that will not be detected by the HW-error code in the cgminer. What are you trying to show?

The "yield issue" for "a large 28nm" chip is a bullshit concern from people who don't understand that one can't take data from chips implementing single, hyper-complex circuit like CPU or GPU and apply it to a repetitive chip that doesn't even have a JTAG chain. I discussed it already a couple of days ago.

Edit: It was in this very thread: https://bitcointalk.org/index.php?topic=170332.msg2723643#msg2723643 . End of edit.

Rest your post about what is the real available "margin upon margins" is definitely a valid concern, but it is too early to really quantify that. Bitfury disclosed how he had dealt with it: hashing cores are 55nm but the unique control logic is drawn much wider (150nm?), all using the same 65nm nominal process. I'm going to give KnC designers benefit of the doubt and assume that they were skilled enough to use similar design methodology in their 28nm-nominal design.

No challenge for me, just fun. Wink

I did not claim that there is any stuck-at fault which will not be found by cgminer. This is of course the final end-to-end test. But that alone does not help you for compensating dead hashing cores by adjusting the chip frequency. This feature must be implemented in the miner firmware to guarantee 100 GH/s per chip. I also dont doubt that KnC can handle this. The question is only how long it takes.

The Bitfury ASIC is a full-custom digital design, maybe they did things as mentioned by you.
The KnC ASIC is a standard semi-custom digital design, which means automatic RTL synthesis and place&route of the standard cells, done hopefully by an experienced design enablement partner of the foundry (not ORSoC) . So it is almost sure, that the supporting logic is implemented with the same 28nm standard cell lib as the hash cores. This is no problem, because the standard cell libs are most likely already silicon proven and showed good yield. But 100% yield are just impossible.

Im not sure, if you are the right person to discuss any 28nm yield issues. How many 28nm ASICs did you characterize for yield over temperature and voltage in lab so far?