Topic: [ANN] OpenBitASIC : The Open Source Bitcoin ASIC Initiative - page 12. (Read 50782 times)

Could this be of interest for the project?

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


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.

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

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.

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.

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.

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.

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.



 

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.

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?

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

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

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.

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?

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.

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.   

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.

Thanks! 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 

Cheers! 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, 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.

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

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