are you guys refreshing the page everytime you want to check the time left?
It is necessary with Chrome and I'm guessing firefox and safari as well.
Yes! Down to 1:54 now on my office computer. |
|
|
|
My clock shows somewhat under 4 hours.
I'm guessing that on whatever platform you are using, the javascript doesn't have access to the time zone setting on your computer. Either that, or the time zone setting is wrong on your computer. Same thing here. It's a plain vanilla Windows 7 computer. 2:44 minutes to go. Counter expiration at 5:06 p.m. PDT Edit: My Android phone shows the very same thing. Time to go: 2:21 now. |
|
|
|
TargetDate = "5/31/2012 12:00 PM GMT-7";
D'oh. That was supposed to be:
TargetDate = "5/31/2012 11:59 PM GMT-7";
… which I have just changed it to. So, if you're wondering why the clock jumped backward by 11 hours and 59 minutes, this is why. I just visited the site and it seems the counter will reach 0 at about 5:08 a.m. PDT tomorrow (Thursday). The day and hour and minute of your birth, by any chance? Because 5/31 5:08 a.m. looks pretty arbitrary to me, otherwise. Edit: Hitting F5 changed it to the afternoon now. 5:06 p.m. - still pretty arbitrary. Any meaning to it? |
|
|
|
896 seems to be beyond the limit for most chips already.
TWO chips. Quite likely, with TWO completely unrolled, pipelined miners on each of them. Or a "sea of miners" on them, as brilliantly demonstrated by Bitfury on the Spartan6 platform. Huh? It was beyond the limit for 3 of mine already. I was just trying to point out that the 896 MH/s are spread out over TWO FPGAs, not just one. Maybe you meant to say "beyond the limit for most Singles". Is it the limit of the chips, hardware to keep it cool, outside temperature or some combination of the previously mentioned? Hard to say, probably a combination of things. Does anyone have a walk-in freezer where he could test whether freezing temperatures help? In any case, there is a thermal resistance Tr1 from the die to the heat spreader and a thermal resistance Tr2 from the heat spreader to the heat sink and finally there is a thermal resistance Tr3 from the heat sink to the room air. Tr1 cannot be modified, but we have already established that Tr2 is not at its optimal level, because the heat sink does not contact the whole heat spreader, only part of it. Also, I suspect that co-planarity of the FPGAs, or rather the lack of it, may contribute to a higher-than-desired Tr2 value. |
|
|
|
I fear that you will find out that synthesizing a bitstream for the Spartan6-150 is not as easy as some people think it is.
I somehow got an impression that the fault is just a swap of RxD/TxD lines. This should be doable with "fpgaeditor" on the ".ncd" file. But I may be wrong. 1. If he takes someone else's bitstream and runs it verbatim, that's easy as pie, as long as pinout and input clock are compatible. 2. But a bitstream cannot be edited at all, unless someone (like ngzhang, or Stefan) chose to provide the placed&routed .ncd file to a competitor. As you correctly point out, the .ncd file can be edited and a bitstream can be generated from it. 3. But if he literally tries to QUOTE synthesize a bitstream UNQUOTE - that's quite tough. |
|
|
|
896 seems to be beyond the limit for most chips already.
TWO chips. Quite likely, with TWO completely unrolled, pipelined miners on each of them. Or a "sea of miners" on them, as brilliantly demonstrated by Bitfury on the Spartan6 platform. Huh? It was beyond the limit for 3 of mine already. I was just trying to point out that the 896 MH/s are spread out over TWO FPGAs, not just one. Maybe you meant to say "beyond the limit for most Singles". |
|
|
|
896 seems to be beyond the limit for most chips already.
TWO chips. Quite likely, with TWO completely unrolled, pipelined miners on each of them. Or a "sea of miners" on them, as brilliantly demonstrated by Bitfury on the Spartan6 platform. |
|
|
|
"Outright difficult" ::= "the most difficult thing you've ever done in your life"
Speaking of which, isn't Eldentyrell's bitstream due sometime today / tomorrow? On June 1st, I think. But Bitfury's 300 MH/s bitstream and then, in turn, BFL's ASIC announcement have, as far as I see it, dramatically reduced the price he can reasonably charge for it. Furthermore, some FPGA boards (ZTEX boards, for instance) have DC/DC converters that are too weak to even run it. Edit: It turns out, his website will go live in the wee morning hours of May 31st. |
|
|
|
FYI: This board is one of the early "Developer" boards. So no bitstream on it yet (As yohan mentioned). I still have to synthesize a bitstream, and flash it to the board over JTAG to get this hashing. Then I can post numbers. That's why I said it would take me a few days   I fear that you will find out that synthesizing a bitstream for the Spartan6-150 is not as easy as some people think it is. Yes, achieving 120 MH/s or 140 MH/s per FPGA may be fairly easy, but 210 MH/s (ZTEX) is not easy at all. Achieving 260 MH/s (EldenTyrell) or 300 MH/s (Bitfury) is outright difficult. "Outright difficult" ::= "the most difficult thing you've ever done in your life" |
|
|
|
I received the same email Inspector. Evidently, they misled us (probably not on purpose) when they said more info was available if an NDA was signed. More than likely, whoever made the post on the forum didn't realize that the information was only intended for commercial partners.
Yes, I agree with your assessment and I don't harbor any resentment against BFL. |
|
|
|
I am a happy BFL customer.
2 questions:
1) Where can I sign an NDA to get more information?
2) Can I order yet?
For NDA you need to contact office@butterflylabs.com. For the order part, well if you already own any singles or have any mini-rigs in order, you already have the credit for trade-in. Please stand by for official announcement for ordering... Regards, BF Labs Inc. I did contact office@butterflylabs.com and, having ordered a mini rig, thought I was well-qualified to be sent an NDA, which I then would have signed, in much the same way as I have already signed another NDA with another Bitcoin mining-related entity. To my utter surprise, I just received this email (which, by the way, is not subject to an NDA, as it will become clear in just a second): Hi Inspector 2211, <- I took the liberty to redact my real name
Thank you for your interest in our BitForce SC product. The NDA you've requested to sign is not a customer level document. It's place is for our manufacturing partners and Venture Capital participants. However, the useful period of time the NDA has covered is nearly complete as we're making our full product announcement in June. Performance specifications and shipment availability will be released at that time.
Best Regards,
Jody D.
Customer Service
BF Labs, Inc. |
|
|
|
And furthermore, there is exactly one entity outside of Intel itself that is allowed to use Intel's fabs - Achronix. And Intel has stated that they are using less then 1% of the fab capacity.
Actually, for the record, more than one company gained access to Intel fabs so far - at least three: - Netronome - Tabula - Achronix |
|
|
|
Can we order now?
Didn't take you long, did it? No, seriously, this pre-announcement will pull the rug out from underneath all other vendors - the Icarus/Lancelot guy in mainland China, Stefan in Germany, the British guys, the American guys with their 6500 board, even the genius-level bitstream guys like EldenTyrell and Bitfury. It's going to be a bloodbath. |
|
|
|
I'll wait for your release, anyway you have my question in your thread.... And I may reconsider initial licensing offer, as I still have no binding on that of course. As I still have about 200 Gh/s power, and if it would become 240 Gh/s - that would be nice benefit. And it is substantial benefit, as I can get board for say
$700 without VAT with 6 spartan6 on it - if it would be 1.8 Gh/s this means $0.38 per Mh/s
if it would be 2.2 Gh/s this means $0.32 per Mh/s.
Feel free to not disclose this, but what kind of volume are you going through that you're able to get a finished board with 6 LX150s on it for $700? I would have thought that even in large volume the S-6 LX150s would cost close to that. No, in volume of 100s, a Spartan6-150 costs just barely more than $100. $110, $115, $120, something like that. |
|
|
|
|
I don't think these announcements in close succession are a coincidence.
Seeing that EldenTyrell is planning to sell his 260 MH/s bitstream starting June 1st, Bitfury tried to preempt these sales by disclosing their own 300 MH/s bitstream, which has a better price/performance ratio than BFL's Single, at about half the power draw. Of course, BFL doesn't want Single sales to drop off by 95%, hence they pre-announce their ASIC, and thus ensure that sales of Lancelot, Bitfury and Eldentyrell's bitstream will be zero or close to zero. But such a pre-announcement of a better product can have a devastating side effect on your OWN product sales as well, which has bankrupted more than a few companies. For the baby boomers among us, let me just mention Osborne. Enter the buy-back guarantee. The buy-back guarantee ensures that BFL's sales will be unaffected by the pre-announcement - nobody will cancel existing orders and nobody will shy away from new orders.
Brilliantly played, BFL.
|
|
|
|
One interesting thing that I have researched - single-bit design. I.e. instead of carry chains you use D-flip flop for carry and D-flip flop for result. Then it would require 32 times less wires for W-expander. Allows constant-optimization. This would be smallest CORE, but with one IF - IF you are capable to design long digital delay lines (i.e. like SRL16 in spartan) within chip. I know that it is pretty doable. But nobody I contacted can work at that level, and basically it is unlikely what you will find in cell library from TSMC for example. This carefully designed thing can beat everything and rise calculations speed at silicon maximum. I doubt however that there's many _developers_ who would even understand what I wrote about here and zero who can do that not in theory but with more or less guaranteed result in hardware.
A carryless adder, 32 bits in + 32 bits in results in 64 bits out in a non-canonical "2 output bits for each output bit" representation? The problem with this approach is, it's not compatible with the XOR operation, not even with rotate and shift operations. So, yes, while you can build a large multiplier that way, converting the result to a canonical representation as the final step, you cannot build SHA-256 that way. I have investigated it, and it's not possible. If you have been talking about something else entirely, I apologize. Not exactly. I mentioned case when you do adding in 32 clocks.... One bit at one clock edge. So one D-trigger holds output, and other D-trigger holds carry, which fed back to adder on next clock. So you get ONE wire instead of 32 wires for round expander fully unrolled. Still design is pipelined. But you need really long and compact shift registers without access to internal bits of course. These are required to do rotation operations (basically by delaying for 32 clocks all variables in calculation, but doing different delays for RORs). And then really long delays for W round (that would be 224-bit delay line and 256-bit delay line). I've tried to experiment this with BRAMs - it is nice - when you have 32 rounds of round expander around single BRAM :-) but actually static RAM is nowhere near efficiency and density of such shift registers implemented in silicon. As this register would work only in dynamics, basically you need only capacitor to hold bit and circuit to charge next capacitor on clock pulse. It will not work at slow clocks then of course. And as far as I know it is extremely hard to implement such circuit in silicon (basically because I have spoken not with elite ASIC developers indeed). If that approach would save 3-4 times transistor count compared to serie of flip-flops, the design then would shine :-) Ah, I see what you mean. Maybe a less radical approach, adding 4 bits per clock, would be more practical. A 4-bit adder fits inside one slice. I'll think about it... >one capacitor to hold bit I the old days, you could buy such chips: Called CCD or charge-coupled device. Steve Wozniak based the video memory of the Apple I on such a device. It not only stored the all the characters in the video buffer (1024 bytes IIRC), but generated the video signal as well, as its content rotated constantly. A new character would be inserted by breaking the loop for a moment. |
|
|
|
One interesting thing that I have researched - single-bit design. I.e. instead of carry chains you use D-flip flop for carry and D-flip flop for result. Then it would require 32 times less wires for W-expander. Allows constant-optimization. This would be smallest CORE, but with one IF - IF you are capable to design long digital delay lines (i.e. like SRL16 in spartan) within chip. I know that it is pretty doable. But nobody I contacted can work at that level, and basically it is unlikely what you will find in cell library from TSMC for example. This carefully designed thing can beat everything and rise calculations speed at silicon maximum. I doubt however that there's many _developers_ who would even understand what I wrote about here and zero who can do that not in theory but with more or less guaranteed result in hardware.
A carryless adder, 32 bits in + 32 bits in results in 64 bits out in a non-canonical "2 output bits for each output bit" representation? The problem with this approach is, it's not compatible with the XOR operation, not even with rotate and shift operations. So, yes, while you can build a large multiplier that way, converting the result to a canonical representation as the final step, you cannot build SHA-256 that way. I have investigated it, and it's not possible. If you have been talking about something else entirely, I apologize. Example (3 bit inputs instead of 32 bit inputs): Let's calculate (A+B) XOR (C+D) A=5, B=7, C=7, D=7 A carry adder yields A+B=4 (3-bit result) and C+D=6 (3-bit result), 4 XOR 6 is 2. A carryless adder yields A+B=10|01|10 (noncanonical binary) and C+D=10|10|10 (noncanonical binary) Xoring that while still in noncanonical binary yields 00|11|00 Canonizing that yields 110 (canonical binary) = 6 (decimal) In other words, the XOR operation is not compatible with a non-canonical binary representation. |
|
|
|
One interesting thing that I have researched - single-bit design. I.e. instead of carry chains you use D-flip flop for carry and D-flip flop for result. Then it would require 32 times less wires for W-expander. Allows constant-optimization. This would be smallest CORE, but with one IF - IF you are capable to design long digital delay lines (i.e. like SRL16 in spartan) within chip. I know that it is pretty doable. But nobody I contacted can work at that level, and basically it is unlikely what you will find in cell library from TSMC for example. This carefully designed thing can beat everything and rise calculations speed at silicon maximum. I doubt however that there's many _developers_ who would even understand what I wrote about here and zero who can do that not in theory but with more or less guaranteed result in hardware.
A carryless adder, 32 bits in + 32 bits in results in 64 bits out in a non-canonical "2 output bits for each output bit" representation? The problem with this approach is, it's not compatible with the XOR operation, not even with rotate and shift operations. So, yes, while you can build a large multiplier that way, converting the result to a canonical representation as the final step, you cannot build SHA-256 that way. I have investigated it, and it's not possible. If you have been talking about something else entirely, I apologize. |
|
|
|
About "there's no long lines" - I've already commented, but will try to draw it, where epic fail for parallel expander is exactly....
say computing w0+w1 and feeding to w9:
---+---------------------------------
---+---------------------------------
---+--------------------------------
---+-------------------------------
---+------------------------------
---+-----------------------------
---+----------------------------
---+----------------------------
---+---------------------------
w0 w1 w2 w3 w4 w5 w6 w7 w8 w9 w10 w11 w12 w13 w14 w15 w16
How many wires ? biggest cross-section just for that ? 9x32 bits :-)
The same happens when pushing w9 to w16... and w14 to w16...
Lazy to calculate - but near 512 bits cross-section...
I've thought about this - it actually prevented me from falling asleep yesterday night. A fully unrolled, pipelined miner would use 125 single columns, or maybe 125 double columns. The latter case leads to the dreaded U-turn. The "current" sixteen w values, 32 bits each, would be percolated down the 125 columns as well. At 4 slices per 32 bits, that's 64 slices. I see this, for instance, from ZTEX's source code. Now, in order to retrieve w[i-16], 32 VERTICAL wires are needed. In order to retrieve w[i-15], another 32 VERTICAL wires are needed, but, as you correctly point out, w[i-16] and w[i-15] can be combined, so only 32 wires are needed. w[i-7] can be added to the sum of w[i-16] and w[i-15], so still only 32 vertical wires are needed. Likewise for w[i-2]. When I said that in a fully unrolled miner no long lines are needed, I meant no HORIZONTAL long lines. For instance, in ZTEX's Verilog code, references are made to the current stage and to the prior stage only. OK, I don't know out of the top of my head how many vertical wires are available in a Spartan-6, but I just tried to make the case that only 32 are needed. If 32 are not available in a single column, then two columns per stage have to be used, which leads to the dreaded U-turn. |
|
|
|
|
Show Posts
