---
3 Units Ordered.  I sent an email to support@avalon-asic.com with more details, but posting here as well couldn't hurt.

http://blockchain.info/tx/6c5a82e8275fc07ccdb42ef8e256a218620edbf3170b9f780d88ca5132803d2d

I'll sign this message with one of the addresses that is an input to the transaction to prove that this is my transaction.
---

Signature:
GxFxFfSoZy8v4PkGqCsKe026MXdaDnAnSAKk6bMQl8qxWWrHKUB8aC8Su7wfP9o7IV7uhCNW+rivL2OlCTFF7lw=
Signed on all the text above, just copy-paste between the ---.
Signed with 1NT4RyJMqtRuDRr6zHdXdKSpmX3SR5he6z

Paid in full (226.81348724 BTC).

Luckily I checked the URL I was being redirected to for walletbit, before paying.  It had the correct shipping info (for me), etc.

Worst case, people can prove they own the addresses that the bitcoins were sent from.

1 confirm on my transaction, finally (slow block):
http://blockchain.info/tx/6c5a82e8275fc07ccdb42ef8e256a218620edbf3170b9f780d88ca5132803d2d

3 units.  And now the waiting begins again...

Welp, off goes 226.82898724 BTC.

... God speed.

The inefficiencies of a rolled hasher are (usually) in area consumption, not in timing performance.

But to answer your question, yes you can clock different hashers at different speeds. Async FIFOs are used to cross the clock domains.

Your confusion may arise from some typos I made in the comments of my code awhile back. I apologize for that (and hope most of those typos have been fixed).

The LOOP_LOG2 parameter determines how many times the entire Bitcoin SHA-256 pipeline is folded in half. Each folding cuts performance in half, but also cuts resource consumption in half (1).

• LOOP_LOG2=0 -> Fully unrolled, one hash per clock cycle.
• LOOP_LOG2=1 -> Half unrolled, one hash per 2 clock cycles.
• LOOP_LOG2=2 -> Quarter unrolled, one hash per 4 clock cycles.
• ...etc...

Mmmkay, I was mentioning it mostly due to it having probably better timing, and use far less resources (those virtual_wires are nothing to sneeze at).

(1) It should be noted that LOOP_LOG2=0, fully unrolled, has special advantages over the other settings due to constant optimization, dropping the last three rounds, etc. So if you were to graph LOOP_LOG2 vs. area consumption it would be linear from 1 onward, but not from 0 to 1.

Is it still only failing on the JTAG clock or is it also failing on the hashing clock?

The code in my repo for Altera targets is based around my virtual_wire module, which isn't really the best (but it's easy to use on Altera dev boards where you already have a USB-Blaster).

You could try the DE2_115_makomk_serial project put together by teknohog, which uses a UART core. I'm designing a newer UART core with more functionality, etc, but that's not done yet and the one by teknohog is perfectly sufficient. You just need to make sure the makomk code in there is up-to-date (I haven't checked yet).

Heh, you're probably right! I'm just quite busy most of the time. Plus, I literally have no room in my lab to connect another desktop at the moment. Need to clean up a bit ...

When I get some free time I will test all the cards, take photos, etc and update the thread. Thank you guys for the replies and convincing me the cards are actually worth something 

Using x6500-miner software or MPBM? If you're using MPBM, TheSeven can help address that issue, though I don't know if he has access to GPUMAX so it could be difficult until he does. I recall the issue being brought up before, and it may be related to the way MPBM handles Long Poll address changes.

Hey guys. I finally put together an installation package of sorts for Windows:

X6500 Easy Package for Windows
Download


This should make it simple and easy take an X6500 and go from 0 to Bitcoin in no time (on Windows). It includes a driver installation program for the libusb driver, MPBM with compiled EXE, and all the current mining firmware. I tested it out on a clean VM install of Windows 7 64-bit, Windows 7 32-bit, and Windows XP 32-bit.

If that's too convenient for you, the individual pieces can also be downloaded:

• FPGA Mining Driver Install
• Modular Python Bitcoin Miner
• Firmware

Let me know if there are any problems. Though I did take a lot of time testing it, this is still fresh off the presses

Thank you for the kind words. I am glad my explanation, and the project on github, was able to help you

Ah, now I see what you meant by stop condition. Yes indeed, if a full difficulty hash is found, that would be a stop condition because the block would now change completely.

For pooled mining, you could also consider exhausting all possible nonces as a stop condition, since the miner must now ask (or should have asked preemptively) for new work. None except my latest firmware obeys this stop condition though, merely for simplicity's sake. Here is where the latest code obeys the stop condition: linky. That helps to save power when the FPGA gets starved of work.

Feel free to ask away! I'll try to keep an eye on this thread, but you can also contact me through PM, or github, or IRC or whatever I appreciate the questions, as they lend themselves to helping me (eventually) write documentation on all these gritty details. I'm beginning to make strides towards that end here on github, but ... it's a bit disheveled at the moment

Here is the full story on the cards:

I bought eight Sapphire 5850 last year (May 2011) from TigerDirect (and one from NewEgg). They ran in 3 cloned machines, 3 cards each, overclocked and for about two months straight. As it turns out, the Sapphire cards have cheap/terrible stock fans, which began to die one by one. I think only three cards have good fans now I posted about the dead fans back when it happened in this thread. The fan basically just spins at 500RPM max. I doubt the cards are damaged otherwise, but I'd boot each one up to check prior to putting them up for sale (if they're worth it). I just threw them in a closet after they "died" because the Bitcoin market was crashing at that time and I couldn't be bothered to RMA them to Sapphire or replace the fans myself.

Whereabouts is that price, do you suppose? If they're only worth like $50 each, then it probably isn't worth my time to test and package them all, for example.

I have a handful (~8) of old 5850's from when I was GPU mining (power cost is too high). Some still work, but most have dead fans and one needs the heatsink re-applied. So I'd have to sell them "as-is" and any buyers would need to repair the fan/heatsink. I don't know if they're even worth selling in this condition. Any comments would be appreciated.

I wouldn't be surprised at all if a C5 with 150K LEs will do ~300MH/s (dual hasher design). In fact, I'd be disappointed if it didn't. Even a C4-150 is likely to do 200MH/s using a dual-core makomk core, a UART for communication, and removing the first three rounds. Cyclone chips have a lot better routing than Spartan-6. Immensely so. And it's a real shame, because the Spartan-6 has a lot better support for adders. Quartus also produces far more predictable results than ISE.

I would have preferred the Cyclone IV to have won the mining race against Spartan-6, honestly, but it was just too expensive. On the other hand, as frustrating as battling ISE is, there's always some amount of glory in winning battles against it

Just in case you didn't know, designs like mine can be folded up to fit into smaller devices like the DE0-Nano:

https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/blob/master/src/fpgaminer_top.v
https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/blob/master/src/sha256_transform.v
https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/tree/master/projects/DE2_115_Unoptimized_Pipelined
https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/tree/master/projects/DE2_115_makomk_mod

Hi,

I maintain the Open Source FPGA Bitcoin Miner, so I may be able to help. Feel free to ask questions and I'll keep an eye on this thread.

There are no "stop conditions" with SHA-256 (1). You have to compute the whole thing, otherwise the hash is incomplete. As you have found, however, there is a small shortcut because of the way mining works.

For most miners, all you care about is finding what is called a difficulty 1 share (2). That means there are 32 bits of leading zeros. So, for optimized mining code we only care that the last 32-bits of the final hash are 0. As you saw, those last 32-bits are actually calculated in round 61, and get shifted 3 times in rounds 62, 63, and 64. We don't care about anything calculated in those last three rounds. Hence, the optimization is to skip them, and check the 5th 32-bit word of the hash produced after the 61st round.

You can see that in the code here. For the second run of SHA-256 it only uses 61 rounds, and reads the 5th word from the output (the code uses IDX(4), because the index starts from 0).

There is another shortcut here. In SHA-256, after all 64 rounds have been computed, one last operation is performed. The individual 32-bit words of the input state are added to the individual 32-bits words of the last round's output. You can see that in The SHA2 wikipedia article, where it says "Add this chunk's hash to result so far."

Now, we're looking to see if the last word is equal to zero:


The input state to the second run of SHA-256 is a known value. The 8th word of which is 0x5be0cd19, so ...


Which is equivalent to:


Which is equivalent to:


I hope that explains those two optimizations. Again, feel free to ask questions if you're confused, or if you have other questions. I more or less wrote this quickly, so may have skipped some details.


NOTES
(1) I'm not sure what connotation you are giving to "stop conditions," so I will explain a little further to help clear any confusion. When mining, you are given a set of data to perform hashes on. As you noted, this is done by manipulating the nonce and hashing each time the nonce changes. What you really want to do is check all possible nonces. Even if you've already found a "golden nonce" (one which gives you a hash starting with 32 zeros), you need to keep searching for more. There could be anywhere between 0 and 2^32 solutions to a given block of work, so it is in your best interest to keep looking for more. Hence, there are no stop conditions in the sense of when to stop running your algorithm, other than having exhausted all possible nonces (at which point, you would get more work).

(2) This is because most miners are connected to a pool server, which accepts any hash meeting at least Difficulty 1 (32 leading zeros). It should be noted, however, that software designed around this optimization will still work for solo mining directly against bitcoind, because bitcoind will merely reject any share that doesn't meet the block difficulty (and every Difficulty 1 share has a possibility of doing so). Also, most FPGA or GPU miners have some high-level controlling software (written in Python or C) which can perform the real difficulty check if necessary. Having the hardware check for shares is really just a way of reducing bandwidth from the hardware to the controlling software.

Two X6500's (without heatsink) would be 800MH/s@34.4W and $1130USD.

The makomk based code fits into ~80K-90K LEs unrolled, if I recall correctly. Though it has been awhile since I've compiled that code, so it might be less

X8000 Sneak Peak

A Sneak Peak at the first 3MH/s/$ FPGA Miner!

Howdy guys. Fizzisist asked me to fill you guys in the upcoming design for the X8000, code named Deep Purple. This is the next revision of our board. It's a little ways off from being complete, since we plan to revamp the USB interface to handle the increased hashing performance. But I've got a picture from li_gangyi of the prototype:

X8000: Deep Purple Prototype:




Preliminary Details:

• 1.8 GH/s guaranteed, 2.4 GH/s typical.
• $595.99 USD + Shipping/Tax.
• Dual Virtex-6 FPGAs.
• USB interface for configuration and mining communication.
• Power supplied through 4-pin Molex connector or 5.5 x 2.1 mm barrel connector (wall wart style).
• 50 W power consumption measured at 2.2 GH/s (more measurements pending).
• Independent protection fuses on each power connector.
• JTAG available for development and debugging (headers are not populated by default).
• Independent temperature monitoring for each FPGA.
• Heatsink mounting holes, compatible with many heatsinks designed for the Northbridge chipset.
• Additional clearance to allow for larger heatsinks.
• 3-pin headers to power 2 standard 12V fans.
• Draws from the 12V supply at the Molex connector.
• LEDs to indicate that the FPGAs are configured properly.
• Mounting hole size diameter increased to allow for #6 size screws.
• 98 x 85.5 mm (3.86 x 3.37 inch) overall size

Again, this is just a prototype, but we're hoping to cram a few more features in there in the weeks following April 1st.