[ANN] OpenBitASIC : The Open Source Bitcoin ASIC Initiative

[Jason]

Also, I can't help wondering what that speed means to mining. Using pools would be interesting, as you would getwork twice a second, and long polling would not help. Then again, solo mining would make sense again, at least for a short time, and pools could adjust to higher difficulties.

This definitely bears some further thought.  I have not kept up-to-date on all of the developments, but I seem to recall a proposal to increase the size of the nonce range (beyond 32-bits) as well as a proposal to increase the difficulty.  It should be straightforward to modify the HDL to accommodate either or both of these changes.  But only if it is likely they will be used in the future by pool operators in order to reduce the load on their systems.

Solo mining may become realistic as well, at least briefly until ASIC mining becomes more widespread.

[1714834338]

1714834338

[1714834338]

1714834338

[rjk]

Also, I can't help wondering what that speed means to mining. Using pools would be interesting, as you would getwork twice a second, and long polling would not help. Then again, solo mining would make sense again, at least for a short time, and pools could adjust to higher difficulties.

This definitely bears some further thought.  I have not kept up-to-date on all of the developments, but I seem to recall a proposal to increase the size of the nonce range (beyond 32-bits) as well as a proposal to increase the difficulty.  It should be straightforward to modify the HDL to accommodate either or both of these changes.  But only if it is likely they will be used in the future by pool operators in order to reduce the load on their systems.

Solo mining may become realistic as well, at least briefly until ASIC mining becomes more widespread.

Implementing Ntime rolling would be of great benefit in such a high speed device. This allows you to increment the nonce yourself as much as you want, within the specified time range stated by the pool. If we assumed 1/2 second to burn though one nonce, you could try 120 nonces within a minute (which is a common Ntime expiry, some are higher), with only one getwork request.

[2112]

I've seen NIOS mentioned above and this made me to add the following comments:

1) Please don't fall into a trap of synthesizing a CPU onto the same physical chip it will be monitoring. This will be a nightmare when debugging. Ideally the monitoring CPU should be on a separate chip powered from a separate regulator and physically placed away from the chips it is monitoring.

2) The inter-chip communication on the same board should be using as many physical pins as practical. Your design will be thermally limited and physically connecting the pins to traces will allow you to evacuate the additional incremental heat from the chip. You could even create dummy busses and point-to-point connections that are connected physically but not electrically.

3) If you plan on really pushing hard the hasher chips it may be beneficial to have intermediate coding/decoding chip to provide high fan-out/fan-in between the hashing chips and the monitoring/communication CPU. This approach will give you two benefits:

3a) you will know that any hashing failure really occurred in hashing and not in a serdes/comms.
3b) you will be able to separately test and reset all hashing chips on the same board.

Please don't try to save pennies on the copper for the traces. Make the traces as wide and as thick as practical. Counteract the parasitic capacitance of abnormally wide traces with the slow but parallel inter-chip communication.

[rjk]

Please don't try to save pennies on the copper for the traces. Make the traces as wide and as thick as practical. Counteract the parasitic capacitance of abnormally wide traces with the slow but parallel inter-chip communication.

Is it possible and/or recommended to use use gold instead of copper? How might that change the design thermally and cost-wise?

[2112]

How might that change the design thermally and cost-wise?

I don't see the point. Gold is a worse heat conductor that copper. Maybe you meant silver not gold? Either way, I don't know. I only know that one can meaningfully lower the thermal resistance of an FPGA design by connecting as many pins as practical using as big traces as one could fit using the standard copper-on-epoxy low-volume PCBs.

[Jason]

I've seen NIOS mentioned above and this made me to add the following comments:

1) Please don't fall into a trap of synthesizing a CPU onto the same physical chip it will be monitoring. This will be a nightmare when debugging. Ideally the monitoring CPU should be on a separate chip powered from a separate regulator and physically placed away from the chips it is monitoring.

We definitely will not be using a soft processor.  In fact, the first revision will most likely not have any CPU at all, just a USB port to connect it to the host.

2) The inter-chip communication on the same board should be using as many physical pins as practical. Your design will be thermally limited and physically connecting the pins to traces will allow you to evacuate the additional incremental heat from the chip. You could even create dummy busses and point-to-point connections that are connected physically but not electrically.

This seems like a good suggestion.  We will be following best practices as recommended by Altera for their Hardcopy devices, but with 1152 pins on the chip, there is a lot of extra potential cooling capacity by insuring they are all connected to some copper.

3) If you plan on really pushing hard the hasher chips it may be beneficial to have intermediate coding/decoding chip to provide high fan-out/fan-in between the hashing chips and the monitoring/communication CPU. This approach will give you two benefits:

3a) you will know that any hashing failure really occurred in hashing and not in a serdes/comms.
3b) you will be able to separately test and reset all hashing chips on the same board.

Interesting.  We hope to be able to put at least 25 fully unrolled miners on the ASIC.  Given the code that has already been published, the hardest part of this project seems to be coming up with a robust way to array all of these miners together so that they effectively appear as a single miner.  Several ideas (including some existing code) have already been mentioned in this thread and I am looking at all options, so I appreciate your suggestion here.  Initially, we expect to be populating PC boards with only a single ASIC.  I will try to come up with an architecture that will scale gracefully to more than one, however.

Please don't try to save pennies on the copper for the traces. Make the traces as wide and as thick as practical. Counteract the parasitic capacitance of abnormally wide traces with the slow but parallel inter-chip communication.

Current thinking is to produce a schematic of the design and then give it to a professional PC board design shop, along with a copy of Altera's best practices for PC board layouts for their Hardcopy devices.  If we're going to spend $200K producing a custom ASIC, it seems like a bad idea to try to cut corners on the PC board.  Fortunately, there will not be any particularly high-speed I/O on or off the chip.  Probably the highest switching rate will be the input clock which will be around 50 MHz.

[rjk]

How might that change the design thermally and cost-wise?

I don't see the point. Gold is a worse heat conductor that copper. Maybe you meant silver not gold? Either way, I don't know. I only know that one can meaningfully lower the thermal resistance of an FPGA design by connecting as many pins as practical using as big traces as one could fit using the standard copper-on-epoxy low-volume PCBs.

OK interesting to know. I just wondered because a board that I have (the thing in my sig) is absolutely slathered in gold, at almost every terminal.

[2112]

give it to a professional PC board design shop, along with a copy of Altera's best practices for PC board layouts for their Hardcopy devices.

I'm not up to speed on the current best practices. As far as I know they are all centered first on achieving timing closure (propagation/cycle time) with the best time-to-market. There so much emphasis on the proper design of traces as bandwidth-optimal transmission lines that you will have to explicitly ask them to design against their usual objectives.

[gusti]

Frequently Asked Questions for the project added.

[matthewh3]

Frequently Asked Questions for the project added.

Sorry if I missed it in the thread somewhere else but what price bracket are you aiming for?

[gusti]

Frequently Asked Questions for the project added.

Sorry if I missed it in the thread somewhere else but what price bracket are you aiming for?

Very preliminary estimations gives a $2000 to $2500 price tag (4 to 3 MH/s/$). 

[kjj]

How might that change the design thermally and cost-wise?

I don't see the point. Gold is a worse heat conductor that copper. Maybe you meant silver not gold? Either way, I don't know. I only know that one can meaningfully lower the thermal resistance of an FPGA design by connecting as many pins as practical using as big traces as one could fit using the standard copper-on-epoxy low-volume PCBs.

OK interesting to know. I just wondered because a board that I have (the thing in my sig) is absolutely slathered in gold, at almost every terminal.

Gold has good surface properties for physical connections, but lousy bulk properties for traces.

Also, it is very expensive.  Copper is 3-4 $ per pound, while gold is $1650 per ounce.  A standard circuit board uses 1 or 2 ounces per square foot, per side.

[Jason]

Someone asked privately about p2pool support.  Apparently at least one other related product does not produce results until it has finished scanning the 32-bit nonce range.  I just wanted to point out that the current design has each miner in the mining array pushing any nonces it finds onto a queue.  Contents of this queue are asynchronously output to the USB port by a separate control thread.  This approach should minimize any delays associated within finding nonces and thus should be suitable for use with p2pool.

[wogaut]

Frequently Asked Questions for the project added.

Sorry if I missed it in the thread somewhere else but what price bracket are you aiming for?

Very preliminary estimations gives a $2000 to $2500 price tag (4 to 3 MH/s/$). 

Wow, that would be great!

[gusti]

Just a little update.

Jason is working on the different modules, going fast forward to prototype building.
Company registration is also in process, next week all paperwork must be finished.


 

[rjk]

Just a little update.

Jason is working on the different modules, going fast forward to prototype building.
Company registration is also in process, next week all paperwork must be finished.


 

Awesome, I like the way this is going.

[triplehelix]

this is definitely the project that might push me towards becoming a serious miner.

[matthewh3]

So a 6GH/s device for $2,500 that uses less power than a FPGA    When does it look like the device might be ready to ship end of the year or next year?  Also where will the device be shipping from.  You might want to have an EU supplier so European customers don't get hit with >20% import taxes.

[rjk]

I've been considering building a new desktop, and I wondered how well you think the software would run in a virtual machine with 64GB of RAM. I would just run my usual desktop stuff in a different virtual machine, and the system would have room for more RAM for the future.

EDIT: Tentative parts list: http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=19183865

[gusti]

So a 6GH/s device for $2,500 that uses less power than a FPGA    When does it look like the device might be ready to ship end of the year or next year?  Also where will the device be shipping from.  You might want to have an EU supplier so European customers don't get hit with >20% import taxes.

Estimated performance is 8GH/s over 100w or less, we will know exactly when prototype is ready.
We wish to be shipping by 4th quarter 2012, distributors will be appointed in USA, EU and ASIA.