Bitcoin/Litecoin FPGA question for project

[jasinlee]

How would a person in theory interface a fpga board into the ltc/btc network? I have a friend who works on vhdl and is toying with making his own fpga and we cant seem to figure out how to get his cyclone III dev kit to interface on the network.

[1715198233]

1715198233

[mitty]

I don't really know anything about the design of FPGA miners, but I know most (all?) of the existing ones plug into a host computer via USB and the host takes care of connecting to the network/mining pool and just sends the FPGA the data to be hashed.

[jasinlee]

Would it be easier to do via ethernet?

[Photon939]

Would it be easier to do via ethernet?

It takes a fair bit more work to add direct ethernet capability (although certainly possible).

You'll need a microcontroller to handle the IP/TCP/DHCP configuration and shuttle data to and from the FPGA along with processing work from a pool and submitting completed work. It's a fair bit of overhead (for a uC) normally done by the CPU on the host computer.

Also you'll  need some way to configure it for debugging, changing pools, static IPs, etc.

[pieppiep]

The easiest way would probably be to use pins from your fpga to make a RS232 (serialport) interface.
Then look in the source code of a miner that can use fpga's or find on the web or this forum what bytes you can send/receive and use that.

The difference between bitcoin and litecoin is very small (looked at from the mining software/hardware side), both have a 80 bytes block you have to hash, both have a 32bits nonce at the same place, the only difference is a method used for hashing.

[jasinlee]

Would RS232 be too slow?

[pieppiep]

The block to hash is just 80 bytes with an average of 1 4 byte nonce for 2^32 hashes.
With a little protocol overhead, lets say 115 bytes/block, you can do 1000 blocks/second.
2^32 * 1000 = 4.2 THash/s.

[mrb]

The block to hash is just 80 bytes with an average of 1 4 byte nonce for 2^32 hashes.
With a little protocol overhead, lets say 115 bytes/block, you can do 1000 blocks/second.
2^32 * 1000 = 4.2 THash/s.

No, RS-232 is typically 115 kbit/s, not kByte/s. Therefore: 125 blocks/s.

You could also implement roll-n-time on the device, and return to the host shares with difficulty > 1. So, all in all, it is hard to put an exact number on what is doable on RS-232, but it would be sufficient for many tens of TH/s.

But seriously guys, I don't see the point in using RS-232. USB is trivial to implement with supporting microcontrollers. Which is why ALL FPGA miners use it. The Altera Cyclone III dev kit supports USB if I am not mistaken.

[2112]

The Altera Cyclone III dev kit supports USB if I am not mistaken.

It has two USB ports, but in a really sucky configuration. One is FTDI and one Cypress; and they cannot be operated at the same time. FTDI is used almost exclusively because it is the easiest supported way to tap JTAG.

There are some serial-over-JTAG drivers available in the NIOS II development kit, so it is doable. But it is a great PITA. Or one could use external JTAG, but this is also a PITA.

[jasinlee]

How would the USB implemented on the  FPGA? Are there any good free USB cores on the net?

[2112]

How would the USB implemented on the  FPGA? Are there any good free USB cores on the net?

I think it is too complex and would require soldering. If soldering is acceptable then just solder in any USB-RS232 serial cable.

In my limited experience UDP broadcast over Ethernet would be easier, simpler to debug and use less logic resources than instantiating some USB device core.

Personally, I would use external USB-serial cable connected with 3 bent paper-clips to the appropriate header. Looks hilariously ugly, but works quite reliably. All my desktop machines have serial ports, either on the motherboard or expansion board, because I haven't yet met a device I couldn't tap some UART via bent paper clips or wires wrapped around needles or by hacking some cables.

Edit: I suddenly realised that the above may be read by some absolute beginners. In that case: please remember to watch the voltages. RS-232 default voltages may fry your expensive development kit if improperly connected. Be mindful of that. Cheapest multimeter and RS-232 - TTL level shifter is all you need to avoid releasing the expensive magic smoke from your FPGA.

[jasinlee]

where is the part in the code of one of the miners that can be changed for rs232 communication instead of starting processing on cpu/gpu? if anyone knows....

[2112]

where is the part in the code of one of the miners that can be changed for rs232 communication instead of starting processing on cpu/gpu?

The production mining software changes too rapidly for me to understand. You'll probably have to look at some previous version of CGminer or BFGminer, when they were still using serial ports instead of raw USB devices.

Besides, the above software is just too complex.

Start with something simple like ZTEX's miner or jgarzik's/pooler's cpuminer. Or hack out the signcryption out of eldentyrell's miner working through the JTAG taps. You'll initially want to mine on the CPU in parallel to be able to quicky compare the output from your FPGA with known good results from another source.

[Bogart]

I would really recommend writing your own CPU miner first, to get a better idea of how mining works.

Shouldn't be more'n a few dozen lines in a decently high-level language.

[jasinlee]

where is the part in the code of one of the miners that can be changed for rs232 communication instead of starting processing on cpu/gpu?

The production mining software changes too rapidly for me to understand. You'll probably have to look at some previous version of CGminer or BFGminer, when they were still using serial ports instead of raw USB devices.

Besides, the above software is just too complex.

Start with something simple like ZTEX's miner or jgarzik's/pooler's cpuminer. Or hack out the signcryption out of eldentyrell's miner working through the JTAG taps. You'll initially want to mine on the CPU in parallel to be able to quicky compare the output from your FPGA with known good results from another source.

The running in parallel is a good idea, thanks.

[jasinlee]

which fpga miner used rs232 or uart for communication with the pc?

[loshia]

Guy's,
I am complete newbie, so please excuse me in advance if this sounds stupid but…Is there any way to use PC RAM via USB at 115200 with FPGA and appropriate bitstream/miner combination?  As long RAM is the “bottle neck” for most FPGA boards now which are used for bitcoin mining. If yes MAX USB speed of some boards is  115200 only. Can this be a second bottle neck also? Probably yes but any comment is welcome
10X

[Bogart]

Guy's,
I am complete newbie, so please excuse me in advance if this sounds stupid but…Is there any way to use PC RAM via USB at 115200 with FPGA and appropriate bitstream/miner combination?  As long RAM is the “bottle neck” for most FPGA boards now which are used for bitcoin mining. If yes MAX USB speed of some boards is  115200 only. Can this be a second bottle neck also? Probably yes but any comment is welcome
10X

Well, there may be ways to make it work like that, but 115,200 bps is really incredibly slow, and would not likely be fast enough to be useful for Scrypt-based mining.

A more proper approach would be to use a memory controller, with a high speed interface of some kind back to the FPGA.  Have a look at these links:

http://www.avnet-israel.co.il/download/downloadPresentations/Presentations/xfest07_GD_memory.pdf
http://www.xilinx.com/products/technology/memory-interfacing/index.htm
http://www.xilinx.com/products/intellectual-property/MIG.htm

[jasinlee]

Not sure if this would fall under the miner software section, so going to put a copy of the question there also.

Where can I locate the function in one of the old miners source code to add interface to fpga processing? It would not really matter which one I guess.

[Bogart]

Looking at this thread, and also at the protocol discussion going on over on BFL forums, I sense the need for a single standard open protocol that can be used for all communication between host-side miner software, and external miner devices (FPGAs, ASICs, etc).

Once hashed out (pun intended), a standard set of libraries could be made and maintained that implemented the protocol in popular languages (C, Java, Python, Ruby, what-have-you), with proper unit tests and all.

There could even be a standards body formed, that would issue certifications of conformity to specific devices running specific firmwares, for those vendors who desired such a thing, and issue cute holographic stickers displaying the certified product's name and firmware hash.

https://forums.butterflylabs.com/announcements/597-bitforce-sc-communication-protocol-draft.html

If only someone who wasn't me would head up the effort...