Bitcoin Forum
December 07, 2016, 08:54:35 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 »  All
  Print  
Author Topic: [ANN] OpenBitASIC : The Open Source Bitcoin ASIC Initiative  (Read 47285 times)
teknohog
Sr. Member
****
Offline Offline

Activity: 412


minor developer


View Profile WWW
April 21, 2012, 09:47:37 PM
 #41

modify existing HDL code to enable multiple miners to run in parallel and to operate efficiently over a common communication bus for accepting work packages and delivering results.

https://github.com/teknohog/Open-Source-FPGA-Bitcoin-Miner/tree/master/projects/DE2_115_cluster

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
gusti
Legendary
*
Offline Offline

Activity: 1102


View Profile
April 21, 2012, 10:01:18 PM
 #42

modify existing HDL code to enable multiple miners to run in parallel and to operate efficiently over a common communication bus for accepting work packages and delivering results.

https://github.com/teknohog/Open-Source-FPGA-Bitcoin-Miner/tree/master/projects/DE2_115_cluster

Nice work.
Do you think it can work with the EP4SE820 boards out of the box, or with minor changes ?


If you don't own the private keys, you don't own the coins.
Jason
Member
**
Offline Offline

Activity: 114


View Profile
April 21, 2012, 10:59:29 PM
 #43

modify existing HDL code to enable multiple miners to run in parallel and to operate efficiently over a common communication bus for accepting work packages and delivering results.

https://github.com/teknohog/Open-Source-FPGA-Bitcoin-Miner/tree/master/projects/DE2_115_cluster

Teknohog, I think you've done some great work here.  The only thing I would change is to substitute USB ports for RS232 ports.  I can't think of any modern PC that still has a RS232 port on it, and forcing users to buy keyspan USB adapters to use an expensive piece of hardware doesn't seem like the way to go.  One easy solution would be to use an FTDI chip to interface USB on the PC side to the FPGA/ASIC running a low voltage serial protocol.  Since we are building the hardware from scratch, there is no reason not to build in features like this to make the product more usable to the end users.  I think the code you have developed so far would work nearly as-is with the FTDI chip.

My code allows multiple miners as well, but it currently uses the virtual wire interface.  This is convenient for debugging, but not desirable for the finished product.

BM-2D7sazxZugpTgqm3M2MCi5C1t8Du8BN11f
teknohog
Sr. Member
****
Offline Offline

Activity: 412


minor developer


View Profile WWW
April 22, 2012, 10:14:51 AM
 #44

Teknohog, I think you've done some great work here.  The only thing I would change is to substitute USB ports for RS232 ports.  I can't think of any modern PC that still has a RS232 port on it, and forcing users to buy keyspan USB adapters to use an expensive piece of hardware doesn't seem like the way to go.  One easy solution would be to use an FTDI chip to interface USB on the PC side to the FPGA/ASIC running a low voltage serial protocol.  Since we are building the hardware from scratch, there is no reason not to build in features like this to make the product more usable to the end users.  I think the code you have developed so far would work nearly as-is with the FTDI chip.

My code allows multiple miners as well, but it currently uses the virtual wire interface.  This is convenient for debugging, but not desirable for the finished product.

Cheers! Smiley I agree we could well use something other than RS232. In fact, the essential parts of my multiple-miner setup use raw 32-bit nonces, and RS232 is only used for communications outside the FPGA.

However, one reason I have stuck with RS232 is the ubiquity across platforms -- you can program the chip and mine using completely Free software. If I understand correctly, the FTDI solution would essentially be an onboard USB-serial converter, so no difference there. Unfortunately, I am using a third-party RS232 library, so that would probably have to change.

There is also the issue that my code does not have long polling. It should not be too much work, since I already have the code for resetting the nonce range, and the rest is done by the computer. Then again, we are talking about maintaining the distributed nature of Bitcoin, and solo miners would not need LP.

teknohog
Sr. Member
****
Offline Offline

Activity: 412


minor developer


View Profile WWW
April 22, 2012, 10:35:04 AM
 #45


Nice work.
Do you think it can work with the EP4SE820 boards out of the box, or with minor changes ?

Thanks! Smiley I have run essentially the same code on both Altera and Xilinx boards, so there should not be too many issues. The main difference between those two has been clock management, which may have to be changed for different chip families from the same manufacturer. Nevertheless, it is only a few lines of boilerplate code.

Also, my code does not include Makomk's optimization, since I use it for a cluster of low-end FPGAs where the optimization would not work. But changing that part should not be an issue either.

Things like the number of miners per chip are mostly set by parameters. I hope my code and "documentation" are reasonably clear on their usage, especially since it's over half a year since I last worked on this  Undecided

Jason
Member
**
Offline Offline

Activity: 114


View Profile
April 22, 2012, 02:04:16 PM
 #46

I would propose that the final mining code include the following features:

  • Work with cgminer (will require working with someone on the cgminer team to get support officially added)
  • Use a USB port (most of the work here will be done by hardware on the board e.g. FTDI)
  • Have a dynamically configurable master clock (via a programmable PLL which is already on-board the ASIC/FPGA prototype)
  • Have the ability to dynamically reconfigure the number of operating miners (thermal management feature)
  • Thermal management by making use of the on-board TSD and 8-bit ADC
  • Have a shared communication bus for all miners (we can base this on Teknohog's code)
  • Use Makomk's mining optimizations to Fpgaminer's code (including further optimization as time allows)

I'd like to hear other's thoughts as well.  I don't believe anything on the above list will take a lot of time to accomplish and provides functionality I think many users of the hardware would find valuable.  Once the ASIC is fabricated, we will be unable to make further changes without another $200K outlay so I think it's important to make sure we get all of the important features included in the first production.

BM-2D7sazxZugpTgqm3M2MCi5C1t8Du8BN11f
gusti
Legendary
*
Offline Offline

Activity: 1102


View Profile
April 22, 2012, 03:17:48 PM
 #47

I would propose that the final mining code include the following features:

  • Work with cgminer (will require working with someone on the cgminer team to get support officially added)
  • Use a USB port (most of the work here will be done by hardware on the board e.g. FTDI)
  • Have a dynamically configurable master clock (via a programmable PLL which is already on-board the ASIC/FPGA prototype)
  • Have the ability to dynamically reconfigure the number of operating miners (thermal management feature)
  • Thermal management by making use of the on-board TSD and 8-bit ADC
  • Have a shared communication bus for all miners (we can base this on Teknohog's code)
  • Use Makomk's mining optimizations to Fpgaminer's code (including further optimization as time allows)

I'd like to hear other's thoughts as well.  I don't believe anything on the above list will take a lot of time to accomplish and provides functionality I think many users of the hardware would find valuable.  Once the ASIC is fabricated, we will be unable to make further changes without another $200K outlay so I think it's important to make sure we get all of the important features included in the first production.


A built-in processor with Linux, running the mining software and a web server for configuration, making it a completely standalone, plug and play device, would be highly desirable. As you mentioned before, this adds time and risk to the design. We can in-depth analyze adding it in first design, or maybe in the future.   


If you don't own the private keys, you don't own the coins.
Jason
Member
**
Offline Offline

Activity: 114


View Profile
April 22, 2012, 04:16:08 PM
 #48

A built-in processor with Linux, running the mining software and a web server for configuration, making it a completely standalone, plug and play device, would be highly desirable. As you mentioned before, this adds time and risk to the design. We can in-depth analyze adding it in first design, or maybe in the future.    

Adding full standalone capability would involve additional hardware on the main board.  Some flash memory (perhaps a micro-SD card interface for convenient upgrades), a cheap LCD display for status, an ethernet and/or wifi controller, and probably replace the proposed FTDI chip with full USB host mode support since there are already existing Linux drivers for this.  This increases the cost of the hardware, though not by much, and it increases the complexity of the hardware design, which increases the development cost and time required somewhat.  I like the idea, though I wonder if the priority should be this level of functionality versus just getting something out there ASAP.  Also, if we go with a soft processor with MMU capability (like NIOS II), that will involve some additional outlays in the form of IP licensing fees.

Intermediate steps are possible as well.  With a decent design, it should be possible to fabricate the ASIC in such a way that a later revision of the board can contain a cheap 32-bit ARM processor on it running Linux that allows the system to operate standalone (e.g. run something like cgminer locally).  Providing for a daughterboard to be connected to the original board adding this functionality is another option.  This may allow us to finish an initial design a month or more earlier while leaving the door open to future expansion.

In my mind, the priority should be getting something working finished as quickly as possible given the volatility of the market and the potential to have other people in this space in the future as well.  Wouldn't being the first on the scene with this type of hardware convey a significant business advantage over competitors absent some compelling performance advantage?  Based on the Altera-provided timeline I posted the URL for a few posts ago, it seems that my earlier six-month estimate may even have been overly conservative, and that a four months may be doable if the funds can be raised.

BM-2D7sazxZugpTgqm3M2MCi5C1t8Du8BN11f
matthewh3
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
April 22, 2012, 07:54:37 PM
 #49

Rather than build in a embedded CPU and OS to run the boards wouldn't it be cheaper and use less power just to use a RaspberryPi and USB hubs to control as many as the USB hubs can be extended to?

gusti
Legendary
*
Offline Offline

Activity: 1102


View Profile
April 22, 2012, 08:14:18 PM
 #50

Rather than build in a embedded CPU and OS to run the boards wouldn't it be cheaper and use less power just to use a RaspberryPi and USB hubs to control as many as the USB hubs can be extended to?

Yes, technical savvy miners will prefer this approach that will save them money and power, I was thinking more on a broader, non-technical audience that will prefer a plug and play device. But as Jason pointed out, thru a modular design, it will be better to stay minimal and have it added in a later model.

If you don't own the private keys, you don't own the coins.
Boussac
Legendary
*
Offline Offline

Activity: 1173


e-ducat.fr


View Profile WWW
April 22, 2012, 10:34:40 PM
 #51

Interesting thread.
@gusti
I doubt that anyone with a vested interest in the success of bitcoin could afford to not support your proposal.

triplehelix
Member
**
Offline Offline

Activity: 84



View Profile
April 22, 2012, 10:37:33 PM
 #52

leave space in the case, and maybe something to mount to, for an after market addon if people want an all in one.
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
April 22, 2012, 11:20:00 PM
 #53

I would propose that the final mining code include the following features:

  • Have a shared communication bus for all miners (we can base this on Teknohog's code)
Could you clarify on this point? Is this bus used for on-board inter-chip communication only, or can it be used between multiple boards?

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
DILLIGAF
Full Member
***
Offline Offline

Activity: 168



View Profile
April 23, 2012, 12:53:22 AM
 #54

Rather than build in a embedded CPU and OS to run the boards wouldn't it be cheaper and use less power just to use a RaspberryPi and USB hubs to control as many as the USB hubs can be extended to?

You could do the RaspberryPi on daughter card design as suggested above your post then you could have two variants if the box/board has the RaspberryPi then it can be master to control all your other nodes without it via USB or you could have all stand alone machines if wanted.
gusti
Legendary
*
Offline Offline

Activity: 1102


View Profile
April 23, 2012, 02:10:29 PM
 #55

Interesting thread.
@gusti
I doubt that anyone with a vested interest in the success of bitcoin could afford to not support your proposal.

Many thanks for your support, we are quickly moving for having the company setup by next week, and finish also a rough investment needed for phase 1.



 

If you don't own the private keys, you don't own the coins.
Jason
Member
**
Offline Offline

Activity: 114


View Profile
April 23, 2012, 03:09:36 PM
 #56

Could you clarify on this point? Is this bus used for on-board inter-chip communication only, or can it be used between multiple boards?

I was referring to a bus used for communication between miners on the same chip.  The purpose would be to enable an external interface which would allow the board to be treated as a single very fast miner, as opposed to 25 or more slower miners.  Teknohog has already done some work in this direction which we are considering using presently.

For off-board communication, I like USB because it is simple and ubiquitous.  It is also more than fast enough for loading work and fetching results even from a board with several sASICs on it.  A multiple-board setting would involve a single host (running the mining front-end software) connecting to each board via a separate USB connection.  There is no reason why the single host could not be something like a Raspberry Pi so long as it had a suitable USB hub to allow it to connect to many different mining boards.

BM-2D7sazxZugpTgqm3M2MCi5C1t8Du8BN11f
teknohog
Sr. Member
****
Offline Offline

Activity: 412


minor developer


View Profile WWW
April 23, 2012, 04:03:25 PM
 #57

Could you clarify on this point? Is this bus used for on-board inter-chip communication only, or can it be used between multiple boards?

I was referring to a bus used for communication between miners on the same chip.  The purpose would be to enable an external interface which would allow the board to be treated as a single very fast miner, as opposed to 25 or more slower miners.  Teknohog has already done some work in this direction which we are considering using presently.

Actually, my original intent for this code was to use multiple FPGAs as a single faster miner, using serial links. The same idea works also within a single chip, without the serial overhead, so it is suitable for this project.

One key idea there is that miners work on different nonce ranges. Therefore, you cannot just add more miners in the same setup, you need to (re)configure them all to cover the whole range evenly. It is possible to make this configuration more dynamic, but it would be needlessly complicated for this project at this stage, IMHO.

This also means that you cannot switch off miners as a power-saving measure. Since dynamic clocking was also mentioned for this purpose, it should be enough.

Jason
Member
**
Offline Offline

Activity: 114


View Profile
April 23, 2012, 05:43:31 PM
 #58

This also means that you cannot switch off miners as a power-saving measure. Since dynamic clocking was also mentioned for this purpose, it should be enough.

I don't see why you can't switch off miners as a power-saving measure.  Not while a single 32-bit nonce range is being searched (which should be around 1/2 second at extrapolated full speed), but in between.  I think some small modifications will allow a dynamic reconfiguration of the miners to be made if this turns out to be desirable.

I hope to have some time to integrate all of the different code (including yours, Teknohog) I have been working with together into a cohesive system in the near future, but I've been preoccupied with other technical issues related to the project which will require my attention for the next several days.

BM-2D7sazxZugpTgqm3M2MCi5C1t8Du8BN11f
teknohog
Sr. Member
****
Offline Offline

Activity: 412


minor developer


View Profile WWW
April 24, 2012, 05:35:03 PM
 #59

This also means that you cannot switch off miners as a power-saving measure. Since dynamic clocking was also mentioned for this purpose, it should be enough.

I don't see why you can't switch off miners as a power-saving measure.  Not while a single 32-bit nonce range is being searched (which should be around 1/2 second at extrapolated full speed), but in between.  I think some small modifications will allow a dynamic reconfiguration of the miners to be made if this turns out to be desirable.

Ah, that's a good point. I guess I was being overly pessimistic about code developments Wink

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.

wareen
Millionaire
Hero Member
*****
Offline Offline

Activity: 742

bitcoin-austria.at


View Profile
April 24, 2012, 07:42:34 PM
 #60

Could this be of interest for the project?

http://cdn.eetimes.com/electronics-news/4371532/

Quote
PORTLAND, Ore.—The first automated software-to-chip dream came out of the closet Monday (April 23), when Algotochip Corp. (Sunnyvale, Calif.) claimed to be able to produce a system-on-chip (SoC) design from a C-code specification in just eight to 16 weeks.

"We can move your designs from algorithms to chips in as little as eight weeks," said Satish Padmanabhan CTO and founder of Algotochip, whose EDA tool directly implements digital chips from C-algorithms. "Our solution provides the appropriate RTL generated from C-ocde for SoC.

Presumably all intellectual property stays with the customer. Sounds not too bad if they can actually deliver. Would be nice to get a price estimate from them.
Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 »  All
  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!