Bitcoin Forum
November 17, 2017, 09:51:56 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 [311] 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 ... 2138 »
  Print  
Author Topic: Swedish ASIC miner company kncminer.com  (Read 3006518 times)
2112
Legendary
*
Offline Offline

Activity: 1960



View Profile
August 16, 2013, 08:42:53 PM
 #6201

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
1510955516
Hero Member
*
Offline Offline

Posts: 1510955516

View Profile Personal Message (Offline)

Ignore
1510955516
Reply with quote  #2

1510955516
Report to moderator
1510955516
Hero Member
*
Offline Offline

Posts: 1510955516

View Profile Personal Message (Offline)

Ignore
1510955516
Reply with quote  #2

1510955516
Report to moderator
Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1510955516
Hero Member
*
Offline Offline

Posts: 1510955516

View Profile Personal Message (Offline)

Ignore
1510955516
Reply with quote  #2

1510955516
Report to moderator
NoDisco
Member
**
Offline Offline

Activity: 70


View Profile
August 16, 2013, 09:13:34 PM
 #6202


What are those mysterious dark shadows  inside the case on the right?...
Is that possibly a pcb I see hiding in there?

Just to "Stirr the Pot" a bit...

lol, get your eyes checked old man! hahahaha



I just realized the front of the KNC box looks kind of like a goofy robot face - fans as eyes and the power/io slot as a mouth.
Well spotted. Bender is a bitcoin miner! VVVVVVVVVVVVV
kingcoin
Sr. Member
****
Offline Offline

Activity: 262


View Profile
August 16, 2013, 09:19:03 PM
 #6203

What would be a minimum required size of a "single defect" that would kill all 4 regions?

The top part of the figure has some control logic connecting the FPGA to the hashing cores to exchange data/midstace/nonce or whatever. Without access to the netlist it's not possible to analyze the probability of a single point of failure. I've seen cases of redundant logic which turned out to share some gates. Test tools can analyse your netlist and detect such potential failures. There are four different clock domains so there might be some synchronization logic in there, unless there are four separate channels with separate clock outputs, or an embedded clock. Again without access to the design one can only speculate. I can't see why KnC chose to skip this common design practice, even though a hasher itself is similar in nature to many BIST implementations even tough the signature checker will be on the device itself so I can be checked on the tester. It would have been better to do the testing on the chip tester and not struggle to figure out if the cause  of the reduced hashing capacity is due to the ASIC chip itself or some other part of the miner. And you don't need to kill all four regions to reduce the capacity of the miner. If the yield is low it will be hard to prove to the vendor that this is due to the ASIC's and not something else.
pacojones
Full Member
***
Offline Offline

Activity: 126



View Profile
August 16, 2013, 09:23:57 PM
 #6204


What are those mysterious dark shadows  inside the case on the right?...
Is that possibly a pcb I see hiding in there?

Just to "Stirr the Pot" a bit...

lol, get your eyes checked old man! hahahaha



I just realized the front of the KNC box looks kind of like a goofy robot face - fans as eyes and the power/io slot as a mouth.
Well spotted. Bender is a bitcoin miner! VVVVVVVVVVVVV


I'm totally calling my new miner bender Smiley

FUKT
Sr. Member
****
Offline Offline

Activity: 429



View Profile
August 16, 2013, 09:41:53 PM
 #6205

£120 (Good quality PSU for example Corsair HX850)

That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)

Also, you forgot import taxes. Wink At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UK

Everyone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.
CYPER
Hero Member
*****
Offline Offline

Activity: 714



View Profile
August 16, 2013, 09:48:54 PM
 #6206

£120 (Good quality PSU for example Corsair HX850)

That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)

Also, you forgot import taxes. Wink At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UK

Everyone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.

How did you come to this conclusion?

If this post helped you and you feel generous you know what to do: 1P9tXFy9bVgzrfPGeV7F8np26ZtFdCCWvz
FUKT
Sr. Member
****
Offline Offline

Activity: 429



View Profile
August 16, 2013, 10:00:21 PM
 #6207

£120 (Good quality PSU for example Corsair HX850)

That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)

Also, you forgot import taxes. Wink At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UK

Everyone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.

How did you come to this conclusion?

Its called basic math. Have you ever brought a PSU? Read the manual, there are some charts and figures explaining load limits, noise and operating efficiency. Even running a platinum PSU at around 95% - 100% produces about 3% variance.
HyperMega
Full Member
***
Offline Offline

Activity: 124


View Profile
August 16, 2013, 10:02:31 PM
 #6208

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 don’t 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.

I’m 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?
CYPER
Hero Member
*****
Offline Offline

Activity: 714



View Profile
August 16, 2013, 10:10:37 PM
 #6209

Its called basic math. Have you ever brought a PSU? Read the manual, there are some charts and figures explaining load limits, noise and operating efficiency. Even running a platinum PSU at around 95% - 100% produces about 3% variance.

I would suggest you wait for official and final information on the Jupiter consumptions and then you can make such statements Wink
So far we know it will consume less than 1000W Wink

If this post helped you and you feel generous you know what to do: 1P9tXFy9bVgzrfPGeV7F8np26ZtFdCCWvz
greenbtc
Full Member
***
Offline Offline

Activity: 210


View Profile
August 16, 2013, 10:21:46 PM
 #6210


What are those mysterious dark shadows  inside the case on the right?...
Is that possibly a pcb I see hiding in there?

Just to "Stirr the Pot" a bit...

lol, get your eyes checked old man! hahahaha



I just realized the front of the KNC box looks kind of like a goofy robot face - fans as eyes and the power/io slot as a mouth.
Well spotted. Bender is a bitcoin miner! VVVVVVVVVVVVV


Nice, they had this in 1600x900 at least for a background as well.

+1 for the futurama reference.
2112
Legendary
*
Offline Offline

Activity: 1960



View Profile
August 16, 2013, 10:23:00 PM
 #6211

The top part of the figure has some control logic connecting the FPGA to the hashing cores to exchange data/midstace/nonce or whatever. Without access to the netlist it's not possible to analyze the probability of a single point of failure. I've seen cases of redundant logic which turned out to share some gates. Test tools can analyse your netlist and detect such potential failures. There are four different clock domains so there might be some synchronization logic in there, unless there are four separate channels with separate clock outputs, or an embedded clock. Again without access to the design one can only speculate. I can't see why KnC chose to skip this common design practice, even though a hasher itself is similar in nature to many BIST implementations even tough the signature checker will be on the device itself so I can be checked on the tester. It would have been better to do the testing on the chip tester and not struggle to figure out if the cause  of the reduced hashing capacity is due to the ASIC chip itself or some other part of the miner. And you don't need to kill all four regions to reduce the capacity of the miner. If the yield is low it will be hard to prove to the vendor that this is due to the ASIC's and not something else.
Look, what you do here is called "concern trolling".

You wrote: "Without access to the netlist it's not possible to analyze the probability of a single point of failure." No need to access anybody's netlist. Just access the critical thinking facilities. Everything is at least 4-way redundand: cores, I/O, clock and even voltage regulators. The only thing shared is ground.

You wrote "I can't see why KnC chose to skip this common design practice", while many other members of this forum, including bitfury, already wrote at length why the Bitcoin hasher is self-testing and why any advanced fault analysis is a waste of resources when 1% error rate on the output nonces is perfectly acceptable.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
FUKT
Sr. Member
****
Offline Offline

Activity: 429



View Profile
August 16, 2013, 10:24:06 PM
 #6212

Its called basic math. Have you ever brought a PSU? Read the manual, there are some charts and figures explaining load limits, noise and operating efficiency. Even running a platinum PSU at around 95% - 100% produces about 3% variance.

I would suggest you wait for official and final information on the Jupiter consumptions and then you can make such statements Wink
So far we know it will consume less than 1000W Wink

OK, maybe you should apply that to your original HX1050 post. And also:

The final specifications for this device are being ironed out now but we can confirm the following.
400GH/s per device.
28nm Standard ASIC
Maximum 1000w
Shipment begins in September

Yeah, good choice: HX1050 on a unit with a maximum 1000w.
kingcoin
Sr. Member
****
Offline Offline

Activity: 262


View Profile
August 16, 2013, 10:44:55 PM
 #6213

The top part of the figure has some control logic connecting the FPGA to the hashing cores to exchange data/midstace/nonce or whatever. Without access to the netlist it's not possible to analyze the probability of a single point of failure. I've seen cases of redundant logic which turned out to share some gates. Test tools can analyse your netlist and detect such potential failures. There are four different clock domains so there might be some synchronization logic in there, unless there are four separate channels with separate clock outputs, or an embedded clock. Again without access to the design one can only speculate. I can't see why KnC chose to skip this common design practice, even though a hasher itself is similar in nature to many BIST implementations even tough the signature checker will be on the device itself so I can be checked on the tester. It would have been better to do the testing on the chip tester and not struggle to figure out if the cause  of the reduced hashing capacity is due to the ASIC chip itself or some other part of the miner. And you don't need to kill all four regions to reduce the capacity of the miner. If the yield is low it will be hard to prove to the vendor that this is due to the ASIC's and not something else.
Look, what you do here is called "concern trolling".

You wrote: "Without access to the netlist it's not possible to analyze the probability of a single point of failure." No need to access anybody's netlist. Just access the critical thinking facilities. Everything is at least 4-way redundand: cores, I/O, clock and even voltage regulators. The only thing shared is ground.

You wrote "I can't see why KnC chose to skip this common design practice", while many other members of this forum, including bitfury, already wrote at length why the Bitcoin hasher is self-testing and why any advanced fault analysis is a waste of resources when 1% error rate on the output nonces is perfectly acceptable.


I'm not psychic so I can't see what possible dependencies are inside the top FPGA control interface. If the only thing in common is ground the yield analysis is like four independent chips. The main problem is that they don't do chip level testing. They don't utilize the "free BIST" and supplement it with coverage for the other part. When they see failure and lower hashing performance they will not know if it's due to chip fabrication problems or not.
CYPER
Hero Member
*****
Offline Offline

Activity: 714



View Profile
August 16, 2013, 10:53:04 PM
 #6214

Its called basic math. Have you ever brought a PSU? Read the manual, there are some charts and figures explaining load limits, noise and operating efficiency. Even running a platinum PSU at around 95% - 100% produces about 3% variance.

I would suggest you wait for official and final information on the Jupiter consumptions and then you can make such statements Wink
So far we know it will consume less than 1000W Wink

OK, maybe you should apply that to your original HX1050 post. And also:

The final specifications for this device are being ironed out now but we can confirm the following.
400GH/s per device.
28nm Standard ASIC
Maximum 1000w
Shipment begins in September

Yeah, good choice: HX1050 on a unit with a maximum 1000w.

Allow me to bring a piece of information that you have apparently missed Smiley

6/26/2013 1:44:00 PM

Quote
Power usage details
 
We have previously specified the power consumption of the Jupiter device at a 1000 watts. We have now received indication from our chip manufacturer that this may be lower.
This is where we need to refer you to our statement of under promise and over deliver.
So until you hear from us again on this, we would like to reaffirm that Jupiter will be less than 1000 watts and Saturn less than 500 watts.

If this post helped you and you feel generous you know what to do: 1P9tXFy9bVgzrfPGeV7F8np26ZtFdCCWvz
2112
Legendary
*
Offline Offline

Activity: 1960



View Profile
August 16, 2013, 10:53:31 PM
 #6215

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 don’t 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.

I’m 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?


1) Fun is fine.

2) They have a whole "Embedded Linux SO-DIMM module" to handle initialization and self-test. Why waste even a single gate and single trace on dedicated test logic? Hopefully they included some sort of "clock disable" register to avoid wasting dynamic power on the engines that keep delivering erroneous nonces. This is such a trivial design that any undergrad could do that. I'm willing to give KnC the benefit of the doubt.

3) All standard-cell libraries that I've seen have some "high fanout", "high load", "low-skew clock" cells that are drawn much wider than the nominal feature size of the process. What are you trying to imply?

4) He, he. My 28nm e-peen has measure-zero. How many circuits have you implemented/characterized that had no JTAG chain (for a valid reason, not due to a fault) and were completely multi-way redundand, including power?

5) Extra-credit question for people who aren't engineers but have experience mining: how many mining devices/rigs you had that booted and started mining correctly, but kept failing after several hours or only in specific circumstances? Were you willing to consider them completely faulty and throw them away or were you willing to delve in and debug the problem? How many hours of "testing" was your cutoff time before you decided to throw that device away?

6) Extra-extra-credit question for engineers: What do you think about other engineers that have an obsesive-compulsive disorder about some testing methodology but have no practical experience running an actual bitmine?

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Nemo1024
Legendary
*
Offline Offline

Activity: 1554



View Profile WWW
August 16, 2013, 11:05:59 PM
 #6216

£120 (Good quality PSU for example Corsair HX850)

That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)

Also, you forgot import taxes. Wink At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UK

Everyone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.

That's why I said "at least" on the off-chance that Jupiter would draw around 800W instead of the pessimistic estimate of 1000W. Cyper's 850W was way off.

Agree with Bitcoinorama that we should wait for the final specs.

#101Life
Save Donbass

“Dark times lie ahead of us and there will be a time when we must choose between what is easy and what is right.”
“We are only as strong as we are united, as weak as we are divided.”
“It is important to fight and fight again, and keep fighting, for only then can evil be kept at bay, though never quite eradicated.”
CYPER
Hero Member
*****
Offline Offline

Activity: 714



View Profile
August 16, 2013, 11:12:18 PM
 #6217

£120 (Good quality PSU for example Corsair HX850)

That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)

Also, you forgot import taxes. Wink At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UK

Everyone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.

That's why I said "at least" on the off-chance that Jupiter would draw around 800W instead of the pessimistic estimate of 1000W. Cyper's 850W was way off.

Agree with Bitcoinorama that we should wait for the final specs.

HX850 I linked has a headroom of more than 1000W. It is one of the best PSU on the market.
I used one for 4 months with a GPU miner consisting of 4x 5870 overclocked at 960Mhz Core.
Obviously I'm not recommending it for a 1000W miner, but if it's less I will consider it Smiley

If this post helped you and you feel generous you know what to do: 1P9tXFy9bVgzrfPGeV7F8np26ZtFdCCWvz
DPoS
Sr. Member
****
Offline Offline

Activity: 462



View Profile
August 17, 2013, 01:14:01 AM
 #6218

how about all you nervous nelly's buy 15 different PSU's now and then return the ones that you don't need later?

In fact forget the miners..  get a refund and buy out ALLLLL the PSUs on the planet and gouge the miners?? =profit

~~BTC~~GAMBIT~~BTC~~Play Boardgames for Bitcoins!!~~BTC~~GAMBIT~~BTC~~ Something I say help? Donate BTC! 1KN1K1xStzsgfYxdArSX4PEjFfcLEuYhid
JohnyBigs
Sr. Member
****
Offline Offline

Activity: 364


View Profile
August 17, 2013, 04:35:37 AM
 #6219

refund processing
ASIC-K
Sr. Member
****
Offline Offline

Activity: 280


Hell?


View Profile
August 17, 2013, 04:38:34 AM
 #6220

refund processing

Sweet! Better for me!  Grin
Pages: « 1 ... 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 [311] 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 ... 2138 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!