BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150

[BR0KK]

Somehow minepeon gets them working quite well.

[ztex]

I think the board is faulty though, I couldn't get it to even made the LEDs come on when I plugged it in, and none of the fans kicked on.

Fans are connected directly to supply voltage. Obviously you didn't supply it with power.

9V to 12V PSU that deliver at least 50W are recommended

[Lyddite]

I have one board which is being disabled showing the following error:

Code:

Read hash data: error sending control message: No such device: Disabling device

Sometimes after 10, 20 minutes, 1 hour, 3 hours.... anyway, enough to affect mining.

Firmware on the boards has been upgraded to the latest available version.
I believe I have ruled out a faulty USB hub and USB cables by swapping cables and plugging the board in directly to USB without an external hub.
Power supplies have been swapped with the same result. Eventually, I'll get around to making a cable for a large regulated power supply I have to completely rule out the power supply.

Until then I made a little Expect script to detect and reset the disabled miner. Expect is a program that can "talk" to other interactive programs via a script. My script is by no mean perfect but gets the job done and it resets the miner and has been running unattended for the past day so I figured I would share it.

I have tested this on Debian linux, you need to install "expect" in order to run it.

Code:

apt-get install expect

should be enough on Debian or Ubuntu.

Then start monitoring the following command:

Code:

expect ztex_restart_disconnected.exp

More details about the scripts below.

- Lyddite
---
BTC: 14J26yT4e8xBbcP3XZEk4osLozf6eosmM1
LTC: LiCmLnRr8hCXhiATmBd6ekw4L3Q36AsijH
XPM: ANTYC4pAimVW726hufAFBgJb4VDeSQbYVT


Two scripts are needed first a simple script containing the you use to start BTCMiner. The scripts should in the same directory as BTCMiner.....jar

The first script, start_ztex is what you use to start your cluster. eg... with mine I connect to a local stratum pool. You will need you change at least the host, port , username , password and perhaps firmware.

start_ztex.sh

Code:

#!/bin/bash
#
java -cp ZtexBTCMiner-121126.jar BTCMiner -v -host http://192.168.1.XX:XXXX -u XXXX -p x -f ztex_ufm1_15d.ihx -v -m c 

The second script, is the expect script which monitors the output

ztex_restart_disconnected.exp

Code:

#!/usr/bin/expect -f
#
set timeout -1
spawn $env(SHELL)
match_max 100000
expect "*\$ "
send -- "./start_ztex.sh"
expect  "./start_ztex.sh"
send -- "\r"
expect  "(Re)Scanning bus ... \r"

# wait for error, then send r return
# first check resets right after the error
# second line for other more rarely errors that may disable the device (resets on the next device status line) 
while  1  {
    expect { 
        "Read hash data: error sending control message: No such device: Disabling device\r" 
            { sleep 10 ; send -- "r\r" ; exp_continue }
        "Device disabled since\r"
            {  send -- "r\r" ; exp_continue }
    }
}

[Lyddite]

I have one board which is being disabled showing the following error:

Code:

Read hash data: error sending control message: No such device: Disabling device

Sometimes after 10, 20 minutes, 1 hour, 3 hours.... anyway, enough to affect mining.

Firmware on the boards has been upgraded to the latest available version.
I believe I have ruled out a faulty USB hub and USB cables by swapping cables and plugging the board in directly to USB without an external hub.
Power supplies have been swapped with the same result. Eventually, I'll get around to making a cable for a large regulated power supply I have to completely rule out the power supply.

In the end, the problem was with the power supplies... both little cheap wall warts. After switching to a 12V 5A regulated power supply, no problems. Maybe not as efficient in term of power, but the boards have mined reliably for days without having to restart anything.

[Kuroth]

I have one board which is being disabled showing the following error:

Code:

Read hash data: error sending control message: No such device: Disabling device

Sometimes after 10, 20 minutes, 1 hour, 3 hours.... anyway, enough to affect mining.

Firmware on the boards has been upgraded to the latest available version.
I believe I have ruled out a faulty USB hub and USB cables by swapping cables and plugging the board in directly to USB without an external hub.
Power supplies have been swapped with the same result. Eventually, I'll get around to making a cable for a large regulated power supply I have to completely rule out the power supply.

In the end, the problem was with the power supplies... both little cheap wall warts. After switching to a 12V 5A regulated power supply, no problems. Maybe not as efficient in term of power, but the boards have mined reliably for days without having to restart anything.

Ahh   Good to hear..   Thanks!

[cableiso]

I wanted to build the source using ISE - it's bombing out due to the defines in sha256_pipes2.v.  Has anyone else run in to this problem?

For example,
data15_p1 <= `S1( S[i-1].data[`IDX(15)] );                                 // 3

Pukes with
ERROR:HDLCompiler:806 - "C:/bitminer-src/fpga/sha256_pipes2.v" Line 89: Syntax error near "[".

As well as several others.  From what I can tell, XST is quite happy with this syntax just a few lines prior.

[cableiso]

I wanted to build the source using ISE - it's bombing out due to the defines in sha256_pipes2.v.  Has anyone else run in to this problem?

For example,
data15_p1 <= `S1( S[i-1].data[`IDX(15)] );                                 // 3

Pukes with
ERROR:HDLCompiler:806 - "C:/bitminer-src/fpga/sha256_pipes2.v" Line 89: Syntax error near "[".

As well as several others.  From what I can tell, XST is quite happy with this syntax just a few lines prior.

Never mind, this error only happens in ISE 12.1.  It works in later versions just fine.

[cableiso]

  
Yep, I realize this is a year old post, but anyway: This par fail happened to me, too.  Still interested in building for shits and grins, so if anyone knows the magic settings please let me know.  Tried the 5, 19 switches from the other thread.  Took 9h and gave up with about 8k unrouted.  Not bad, but still far off.

Dear FPGA miners,

I am trying to build the "open source" ZTEX project ZtexBTCMiner-120703

http://www.ztex.de/btcminer/ZtexBTCMiner-120703.tar.bz2

under ISE 14.1 and I am having difficulty making the LX150 Bitfile for the 4 FPGA version of ztex_ufm1_15y1.  I am using ISE Project Navigator 14.1 configured as follows:
 
SET AS TOP MODULE:                                   ztex_ufm1_15y1 (ztex_ufm1_15y1.v)
INCLUDED UCF FILE:                                     ztex_ufm1_15y1.ucf
TARGET DEVICE:                                          xc6slx150-3csg484

The problems are:

(1) I would like to get some recommended part numbers for low profile heatsinks, I notice that Digi-key does not carry Radian.    
(2) Route:441 - The router has detected a very high timing score (7681590) for this design. It is extremely unlikely the router will be able to meet your timing requirements. To prevent excessive run time the router will change strategy. The router will now work to completely route this design but not to improve timing. This behavior will allow you to use the Static Timing Report and FPGA Editor to isolate the paths with timing problems. The cause of this behavior is either overly difficult constraints, or issues with the implementation or synthesis of logic in the critical timing path. If you would prefer the router continue trying to meet timing and you are willing to accept a long run time set the option "-xe c" to override the present behavior.

(Router eventually gives up)

There is no ISE project file in the source tree, and Dr. Z has given his assurance that the .ucf file is complete.

Can anyone please give me some direction on how to build this bitfile correctly, apart from what I am doing as described above?  I have searched these forums and come up with nada. 6500 subproject on GitHub builds just fine, using the same setup.

https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/tree/master/projects/X6000_ztex_comm4

The reason I want to build my own bitfile should be obvious to the thirsty...and fellow abductees.  Damn probes. Just wait until we get one of them onto a steel table.

[rupy]

I don't get this, 3 months since bitfury released the source for their 300MH bitstream, how come ztex don't release it?!

https://github.com/Taugeran/Bitfury

[BR0KK]

I don't get this, 3 months since bitfury released the source for their 300MH bitstream, how come ztex don't release it?!

https://github.com/Taugeran/Bitfury

Have you read the bitfury or eldentyrell thread about this?

The boards run at optimum speeds considering power consumption, heat and error rate.

Unlike crainsmore and other boards the power supply on the boards can not meet the requirement for higher clocks. You would have to Mod your boards!

[FanDjangoBTC]

Unless you have more than 100 of the y's, the change ist not worth it anymore.
And even so, since the last difficulty increase, most users of this splendid device will do the same as GPU enthusiastis some months ago.

[cableiso]

I am interested in buying FPGA boards.  If you have a few or more boards, please PM me with your price per GH.

[aTg]

ZTEX not gonna adapt BTCMiner to use with your new board Artix7?

[rupy]

Hehe, zTex strikes back!? What would these deliver 400MH/s?

[ztex]

Hehe, zTex strikes back!? What would these deliver 400MH/s?

You may not believe it, but there is hardware which is not only developed for BTC mining. Screw drivers, for example.

Estimated hash rate of these FPGA's is indeed 350 to 400 MH/s

[ztex]

Not worth it. Used 1.15y's (and a few remaining ones that are sold-off in the shop) deliver more MH/s per price than USB-FPGA Modules 2.16b would deliver, see the message above.

ZTEX not gonna adapt BTCMiner to use with your new board Artix7?

[rupy]

Hey, what about http://www.blakecoin.org/, has anyone tried it with their zTex? I only have 1.15x, does the bitstream work on those?

[BR0KK]

Hehe, zTex strikes back!? What would these deliver 400MH/s?

You may not believe it, but there is hardware which is not only developed for BTC mining. Screw drivers, for example.

Estimated hash rate of these FPGA's is indeed 350 to 400 MH/s

you don't happen to have a clue what they would do in litecoin?


i Used kramble's litecoin bitstream on my ztex 1.15y's and one quad board puts out arround 60 kh/s.

[asyring]

I think the second board with ddr3 ram and artix7 100k could be usefull for litecoins. But this board is in prototype status.

I have an artix7 developer board but its not faster than the sp6

[kramble]

Hey, what about http://www.blakecoin.org/, has anyone tried it with their zTex? I only have 1.15x, does the bitstream work on those?

It does now (courtesy of hal7) (thread post), (git).

NB the original 1.15y bitstream does not work on 1.15x/1.15d hence the need for a new version.