BitForce SC - full custom ASIC

[P4man]

I think getting 10 units shipped a day would be tough to keep up.  You run out of cases, or power supplies, or cables and orders get backed up. 

For something they could initially easily sell at over 10x or 100x the cost to produce, I imagine they can find solutions for that.
Hint:

[1713527781]

1713527781

[1713527781]

1713527781

[1713527781]

1713527781

[1713527781]

1713527781

[1713527781]

1713527781

[Inaba]

If I were briefing this for a case, I'd focus on BFL knowingly and intentionally misleading people about the lead time on products.  I'd subpoena their emails and internal documentation, especially any procurement and accounting records that would reveal intent to defraud.  I think we all know BFL pulled some shenanigans that were unethical and possibly in violation of FTC regulations.  It's quite likely that there's something actionable.  It's just a matter of how much someone wants to dig.

I didn't quote the rest of your post because this is really the heart of the matter. 

This argument is pretty much the only valid argument I've seen come out of anyone (Yes, Mem included) and has never really been a point of contention.  Yes, they have failed their shipping estimates.  They could have and should have handled those far better... but other than failing to meet shipping estimates, I have yet to see any convincing argument that BFL has dealt with customers in anything less than a respectable manner.

Again, the initial estimates for the Single were flawed, and that came from a healthy dose of ignorance in so far as what they were dealing with and not any intent to deceive or defraud.  You can also include that if you want, but I personally do not count that as a flaw unless the practice continue(s/d) with the Mini-Rig and the SC.  As a first run and really the first "mass produced" FPGA solution, a miss-step like that is fairly minor in the grand scheme of things, especially in light of the fact that they were happy to refund pre-orders for customers who were dissatisfied.

[makomk]

I just found the BIGGEST scam on the internet.

They TAKE your money and only promise to deliver a product. They are taking your money, in many cases, before they've even developed the prototypes!

SCAM!

(Click at your own risk)

http://www.kickstarter.com/

It's funny you should mention Kickstarter. One of the big Kickstarter projects took in a cool third of a million dollars and still hasn't delivered anything. Its backers have been feeling quite thoroughly scammed for a while:

http://www.kickstarter.com/projects/zioneyez/eyeztm-by-zioneyez-hd-video-recording-glasses-for/comments

[Dexter770221]

Are they shipping 50 units of BFL singles a day?  It seems like they are around 10 units a day shipping average.  Why would these new units be able to be shipped 5X faster? These have to have some human interaction to build which slows down the building.

In my normal 8 hours work day I'm able to assemble 15 PCBs with 50 SMD elements (resistors, capacitors, 44TQFP microcontroller) and few other bigger parts like transformer, connectors. Of course not 8 hours straight, I like to use my right for break ASIC designed with caution shouldn't require many parts, mostly SMD. So, even one person should be able to assemble 25 PCB per day without any hassle. Not to mention some automatic manufacture. That extra 10$ for assembly isn't much compared to 100$ chip and 1999$ final price.

[Inaba]

I would imagine the ASIC assembly will be far less complicated than the FPGA unit they have now, so it would likely be faster.  The current assembly method is labor intensive and if it were designed differently, could be reduced quite a bit...

I'm not entirely certain that this can be clearly proven given what's on the table.  BFL provided statements that they were experts in this area with a history of delivery.  The bona fides were lightweight in terms of evidence, but argue against significant ignorance.

While I don't expect you to take my word for it, please check around with other FPGA and IC developers and ask them how a Bitcoin application compares to basically every other FPGA application in terms of chip utilization.  The unusual requirements of mining compared to basically all other applications of FPGAs impose unusual requirements that a typical designer would not factor in without prior knowledge of the situation. 

Given that fact, it's not unsurprising that even experienced designers would be surprised and appalled by the requirements of a bitcoin miner.  Throwing in a little bit of veritable conjecture: I suspect this is exactly what happened to LargeCoin when they realized that their initial ASIC designs were not going to meet their targets, as they were designed with traditional simulations and not mining simulations.  Which, I suspect, is why they abandoned the LargeCoin unit, since it wouldn't be anywhere close to what they wanted.

[fizzisist]

I would imagine the ASIC assembly will be far less complicated than the FPGA unit they have now, so it would likely be faster.  The current assembly method is labor intensive and if it were designed differently, could be reduced quite a bit...

I'm not entirely certain that this can be clearly proven given what's on the table.  BFL provided statements that they were experts in this area with a history of delivery.  The bona fides were lightweight in terms of evidence, but argue against significant ignorance.

While I don't expect you to take my word for it, please check around with other FPGA and IC developers and ask them how a Bitcoin application compares to basically every other FPGA application in terms of chip utilization.  The unusual requirements of mining compared to basically all other applications of FPGAs impose unusual requirements that a typical designer would not factor in without prior knowledge of the situation. 

Given that fact, it's not unsurprising that even experienced designers would be surprised and appalled by the requirements of a bitcoin miner.  Throwing in a little bit of veritable conjecture: I suspect this is exactly what happened to LargeCoin when they realized that their initial ASIC designs were not going to meet their targets, as they were designed with traditional simulations and not mining simulations.  Which, I suspect, is why they abandoned the LargeCoin unit, since it wouldn't be anywhere close to what they wanted.

Sure, the power usage would be surprising to most FPGA designers. That doesn't mean you can't wait until after you've built and testing a prototype to announce exact specs to 3 significant figures and start collecting payments.

[rjk]

Which, I suspect, is why they abandoned the LargeCoin unit, since it wouldn't be anywhere close to what they wanted.

Did they actually? I haven't heard from them, but the website is still up.

Not sure when they were planning on delivering either. The guy has chatted to some buyers on the phone, maybe they should give him a ring and see what's up.

[nedbert9]

I think the hardware subforum should get a new rule. I am going to ask all the manufacturers to make official product threads, I am going to sticky those threads, and then we, collectively, are going to feel sorry for anyone dumb enough to troll in said official product threads.

What does everyone think?

Yes.

[Inaba]

I'm not entirely certain that this can be clearly proven given what's on the table.  BFL provided statements that they were experts in this area with a history of delivery.  The bona fides were lightweight in terms of evidence, but argue against significant ignorance.

While I don't expect you to take my word for it, please check around with other FPGA and IC developers and ask them how a Bitcoin application compares to basically every other FPGA application in terms of chip utilization.  The unusual requirements of mining compared to basically all other applications of FPGAs impose unusual requirements that a typical designer would not factor in without prior knowledge of the situation.  

I don't know you.  You seem intelligent but a little too emotional on this particular issue.  This could be because you believe in the longer-term goals of BFL and are offended at what amounts to pure BS on the part of many of its detractors.  I understand this, but it's the Internet.  Use the Ignore link with great prejudice.  I do, and it helps my outlook significantly.

I'm sorry you feel that way and that some how my deconstruction of your arguments are somehow "emotional."  I have no personal stake in BFL, but I to take umbrage to the fact that people spout all sorts of misinformation and outright lies (not saying that's the case here, I'm referring to another thread) and I would defend the subject with the same "emotion" you are attributing here.  I'm highly opposed to bullshit and armchair lawyers, yes it's true.

Conveniently, given my geography, I have a lot of friends and acquaintances in the FPGA and IC spaces at companies such as Intel and Cadence.  I recognize the debating technique of trying to find an area where your "opponent" is soft, but I am neither your opponent in this discussion, nor am I weak in the area.  Your pattern of "x is entirely unlike every other y" is not helping you in this debate, as I well recall the early days of SSL and other crypto and hashing accelerators.  I remember having to pay $10k per Big IP just to offload SSL (which is, as a streaming protocol, a slightly different beast) for a handful of servers.

What debate?  You haven't offered any contrary position beyond your initial statement.  It's not really a debate.  You stated that BFL made statements with regards to their expertise in a given area, yet fell well short of delivering.  I gave you a reason as to why that was the case.  That's not exactly a debate, which is why I invited you to check with someone OTHER than myself, since you believe I am biased (which is fine).

Given that fact, it's not unsurprising that even experienced designers would be surprised and appalled by the requirements of a bitcoin miner.  Throwing in a little bit of veritable conjecture: I suspect this is exactly what happened to LargeCoin when they realized that their initial ASIC designs were not going to meet their targets, as they were designed with traditional simulations and not mining simulations.  Which, I suspect, is why they abandoned the LargeCoin unit, since it wouldn't be anywhere close to what they wanted.

The claim would be reasonable had it not been so easy for smaller shops (ngzhang, ztex, etc.) to deliver FPGA-based solutions in a timely fashion.  The programming is obviously accessible to a reasonable practitioner in the craft, given the number of byte streams that have been produced that push the LX150.

What does the programming have to do with it?  The bitstream has never been a bone of contention as far as I know (someone correct me if I'm wrong) - the only bone of contention has been the power usage (which directly correlates to the hashrate as related to heat).  I'm sure none of the engineers you have listed would argue that the chips BFL uses are incapable of producing a 1 GH run for brief periods, as described by "normal" FPGA applications.  The breakdown occurs when you try to mine at upwards of a 50% switching rate, instead of the industry norm of 12%... suddenly those 1.2 GH/s chips start to overheat and fail at 50%, whereas they can run all day for years at 12%.  Any FPGA designer coming into that territory and being unfamiliar with bitcoin, yet familiar with industry standards would conceivably make that mistake.  

I am not making excuses for BFL or their failure to deliver.  I am simply pointing out why your argument is flawed.  I am sorry if that offends you or somehow puts you on edge, but the facts are facts.  BFL could have easily delivered a comparable product to Ztex, nghzhang, et al, since their hashrates are so far removed from what BFL was offering, even AFTER the reduction... but the fact that they were offering a product that, after refactoring, was 4x the speed for 1/2 the cost should afford them quite a bit of leeway when it comes to the very first product delivered.  Using the other products as examples is disingenuous  at best, since they are fall so very short in terms of performance and price.

The FPGA-to-ASIC process is capital intensive but not difficult.  It's a very well-worn path.  We have tools such as Verilog and friends.  We can prototype on the FPGA, validate with various circuit validation tools (OK, these are _all_ buggy), simulate (slowly) on our beefy workstations, and have a reasonable shot at a successful IC, especially one as simple as a BTC ASIC.  This isn't a Pentium 60, where you're going to run into corner cases with FDIV.  The rest is glue and IO, and the smart move is to leave the ASIC as dumb as possible and leverage existing tech for this.

I don't disagree with this... but I'm not sure what is has to do with anything or how it's relevant to your previous statements.  If you could clarify?

[tosku]

I think getting 10 units shipped a day would be tough to keep up.  You run out of cases, or power supplies, or cables and orders get backed up. 

For something they could initially easily sell at over 10x or 100x the cost to produce, I imagine they can find solutions for that.
Hint:

That'd be wonderful. After a month, there would be "ASIC+FPGA bitdollar processing units" for $10 from DealExtreme

[JusticeForYou]

I think getting 10 units shipped a day would be tough to keep up.  You run out of cases, or power supplies, or cables and orders get backed up. 

For something they could initially easily sell at over 10x or 100x the cost to produce, I imagine they can find solutions for that.
Hint:

That'd be wonderful. After a month, there would be "ASIC+FPGA bitdollar processing units" for $10 from DealExtreme

Worker 451 Right, No Soup for You !!!

[2112]

I'm just going to quote this for posterity, since this board software allows editing of posts long after the original poster had calmed down.

I'm not entirely certain that this can be clearly proven given what's on the table.  BFL provided statements that they were experts in this area with a history of delivery.  The bona fides were lightweight in terms of evidence, but argue against significant ignorance.

While I don't expect you to take my word for it, please check around with other FPGA and IC developers and ask them how a Bitcoin application compares to basically every other FPGA application in terms of chip utilization.  The unusual requirements of mining compared to basically all other applications of FPGAs impose unusual requirements that a typical designer would not factor in without prior knowledge of the situation.  

I don't know you.  You seem intelligent but a little too emotional on this particular issue.  This could be because you believe in the longer-term goals of BFL and are offended at what amounts to pure BS on the part of many of its detractors.  I understand this, but it's the Internet.  Use the Ignore link with great prejudice.  I do, and it helps my outlook significantly.

I'm sorry you feel that way and that some how my deconstruction of your arguments are somehow "emotional."  I have no personal stake in BFL, but I to take umbrage to the fact that people spout all sorts of misinformation and outright lies (not saying that's the case here, I'm referring to another thread) and I would defend the subject with the same "emotion" you are attributing here.  I'm highly opposed to bullshit and armchair lawyers, yes it's true.

Conveniently, given my geography, I have a lot of friends and acquaintances in the FPGA and IC spaces at companies such as Intel and Cadence.  I recognize the debating technique of trying to find an area where your "opponent" is soft, but I am neither your opponent in this discussion, nor am I weak in the area.  Your pattern of "x is entirely unlike every other y" is not helping you in this debate, as I well recall the early days of SSL and other crypto and hashing accelerators.  I remember having to pay $10k per Big IP just to offload SSL (which is, as a streaming protocol, a slightly different beast) for a handful of servers.

What debate?  You haven't offered any contrary position beyond your initial statement.  It's not really a debate.  You stated that BFL made statements with regards to their expertise in a given area, yet fell well short of delivering.  I gave you a reason as to why that was the case.  That's not exactly a debate, which is why I invited you to check with someone OTHER than myself, since you believe I am biased (which is fine).

Given that fact, it's not unsurprising that even experienced designers would be surprised and appalled by the requirements of a bitcoin miner.  Throwing in a little bit of veritable conjecture: I suspect this is exactly what happened to LargeCoin when they realized that their initial ASIC designs were not going to meet their targets, as they were designed with traditional simulations and not mining simulations.  Which, I suspect, is why they abandoned the LargeCoin unit, since it wouldn't be anywhere close to what they wanted.

The claim would be reasonable had it not been so easy for smaller shops (ngzhang, ztex, etc.) to deliver FPGA-based solutions in a timely fashion.  The programming is obviously accessible to a reasonable practitioner in the craft, given the number of byte streams that have been produced that push the LX150.

What does the programming have to do with it?  The bitstream has never been a bone of contention as far as I know (someone correct me if I'm wrong) - the only bone of contention has been the power usage (which directly correlates to the hashrate as related to heat).  I'm sure none of the engineers you have listed would argue that the chips BFL uses are incapable of producing a 1 GH run for brief periods, as described by "normal" FPGA applications.  The breakdown occurs when you try to mine at upwards of a 50% switching rate, instead of the industry norm of 12%... suddenly those 1.2 GH/s chips start to overheat and fail at 50%, whereas they can run all day for years at 12%.  Any FPGA designer coming into that territory and being unfamiliar with bitcoin, yet familiar with industry standards would conceivably make that mistake.  

I am not making excuses for BFL or their failure to deliver.  I am simply pointing out why your argument is flawed.  I am sorry if that offends you or somehow puts you on edge, but the facts are facts.  BFL could have easily delivered a comparable product to Ztex, nghzhang, et al, since their hashrates are so far removed from what BFL was offering, even AFTER the reduction... but the fact that they were offering a product that, after refactoring, was 4x the speed for 1/2 the cost should afford them quite a bit of leeway when it comes to the very first product delivered.  Using the other products as examples is disingenuous  at best, since they are fall so very short in terms of performance and price.

The FPGA-to-ASIC process is capital intensive but not difficult.  It's a very well-worn path.  We have tools such as Verilog and friends.  We can prototype on the FPGA, validate with various circuit validation tools (OK, these are _all_ buggy), simulate (slowly) on our beefy workstations, and have a reasonable shot at a successful IC, especially one as simple as a BTC ASIC.  This isn't a Pentium 60, where you're going to run into corner cases with FDIV.  The rest is glue and IO, and the smart move is to leave the ASIC as dumb as possible and leverage existing tech for this.

I don't disagree with this... but I'm not sure what is has to do with anything or how it's relevant to your previous statements.  If you could clarify?

[sadpandatech]

I'm just going to quote this for posterity, since this board software allows editing of posts long after the original poster had calmed down.

*grins*

[RoadStress]

BTC-engineer or BFL please tell us if the announcement will be somewhere close from this date or close to the end of the month. We all know that waiting sucks a lot! Thank you.

[rjk]

BTC-engineer or BFL please tell us if the announcement will be somewhere close from this date or close to the end of the month. We all know that waiting sucks a lot! Thank you.

FYI, BTC-Engineer and BFL-Engineer are not the same.

[Garr255]

BTC-engineer or BFL please tell us if the announcement will be somewhere close from this date or close to the end of the month. We all know that waiting sucks a lot! Thank you.

FYI, BTC-Engineer and BFL-Engineer are not the same.

AFAIK, BTC-Engineer has 0 affiliation with BFL. In case that wasn't clear enough...

[KIDC]

"Subed".

By the way, some interesting speculation happening here in this thread. I've been watching closely.

[Littleshop]

I suspect BFL is paying rent, lights and salaries with mini-rig orders they still haven't shipped. BFL prove me wrong:  publish a report from a lawyer or CPA showing that they are holding payments for these systems for you in escrow.

By my calculations BFL is making about $300 a single.  Lets say about 100 a month (I am guessing most orders are NOT on the thread in this forum) so they could be making in excess of $30,000 a month on the hardware.  I think they can pay the bills with that.   

[Inspector 2211]

I suspect BFL is paying rent, lights and salaries with mini-rig orders they still haven't shipped. BFL prove me wrong:  publish a report from a lawyer or CPA showing that they are holding payments for these systems for you in escrow.

By my calculations BFL is making about $300 a single.  Lets say about 100 a month (I am guessing most orders are NOT on the thread in this forum) so they could be making in excess of $30,000 a month on the hardware.  I think they can pay the bills with that.   

You'd be surprised what senior electronics engineers and senior software engineers make nowadays, and that doesn't even include QA, custumer support, marketing, sales...

Taking your numbers, they're losing money, not making money.

[Littleshop]

I suspect BFL is paying rent, lights and salaries with mini-rig orders they still haven't shipped. BFL prove me wrong:  publish a report from a lawyer or CPA showing that they are holding payments for these systems for you in escrow.

By my calculations BFL is making about $300 a single.  Lets say about 100 a month (I am guessing most orders are NOT on the thread in this forum) so they could be making in excess of $30,000 a month on the hardware.  I think they can pay the bills with that.   

You'd be surprised what senior electronics engineers and senior software engineers make nowadays, and that doesn't even include QA, custumer support, marketing, sales...

Taking your numbers, they're losing money, not making money.

Startups usually don't pay full scale wages. Outsourcing also helps.