ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards - page 39.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Inspector 2211 on February 11, 2012, 09:15:04 PM

He may be interested in writing his own Verilog code, and with the LX150 device he'd have to BUY the toolchain, as the LX150 is not supported by the free toolchain. But I recommend buying at least the LX75 device. Module 1.15b. It can be used for mining AND for trying out new code variants. Maybe I'll buy a 1.15b myself. The discussion with wondermine in a different thread gave me some ideas on how to speed up the "add" operations.

Agreed. If you want to do your own research "on the cheap" a LX75 (75K LUTs) is the best chip. It is the largest chip which can still use the free ISE. A 25K LUT chip is simply too small to be useful.

Inspector 2211

sr. member

Activity: 448

Merit: 250

He may be interested in writing his own Verilog code, and with the LX150 device he'd have to BUY the toolchain, as the LX150 is not supported by the free toolchain. But I recommend buying at least the LX75 device. Module 1.15b. It can be used for mining AND for trying out new code variants. Maybe I'll buy a 1.15b myself. The discussion with wondermine in a different thread gave me some ideas on how to speed up the "add" operations.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Unacceptable on February 11, 2012, 05:00:43 PM

What kind of hash rates does this device get?

USB-FPGA Module 1.11c (XC6SLX25, SG 3, 64 MB RAM)

http://shop.ztex.de/product_info.php?products_id=52

At $175 I might be willing to try a few of them,any kind of warranty??

The 1.15x has 150K LUTs that FPGA has 25K LUTS so theoretical max would be maybe 30 MH/s BUT the 1.15X uses a 150K LUT FPGA so it can unroll the SHA-256 double loop. This chip doesn't have the "space" so you get all the overhead of the rolled algorithm so ballpark maybe 20 MH/s. Of course you would need to find/build a bitstream for it.

What is weird is you said you would be willing to try a FEW? You could get a 1.15x for the price of 3 of those and gain all the community support, plus higher performance chip.

Unacceptable

legendary

Activity: 2212

Merit: 1001

What kind of hash rates does this device get?

USB-FPGA Module 1.11c (XC6SLX25, SG 3, 64 MB RAM)

http://shop.ztex.de/product_info.php?products_id=52

At $175 I might be willing to try a few of them,any kind of warranty??

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

A BTCMiner release has been published, see the software thread (https://bitcointalksearch.org/topic/m.738240) for details.

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Going to give it a try this evening. 120126 and d2 work very well for me. Glad i was able to bring nr6 to life.

Inspector 2211

sr. member

Activity: 448

Merit: 250

Quote from: ztex on January 30, 2012, 08:16:36 AM

A testing release has been published: http://www.ztex.de/btcminer/ZtexBTCMiner-120130.jar . See the software thread (https://bitcointalksearch.org/topic/m.722099) for details.

I'm happy to report that the "15d3a" version works for me now - it starts at 200 MHz, goes to 204, then 208, then 212, but the error rate is too high at 212
and it settles at 208.

Good job, Stefan!
1.0e3 thanks!

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

A testing release has been published: http://www.ztex.de/btcminer/ZtexBTCMiner-120130.jar . See the software thread (https://bitcointalksearch.org/topic/m.722099) for details.

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: ztex on January 30, 2012, 06:03:31 AM

The difference between d1 and d2 firmware are different clock multipliers / dividers. This does not influence the submission of shares.

For performance evaluation use the "hash rate" value from the center of the line. The "submitted hash rate" at the end of the line is computed based on the shared found. This value depends on your luck and is only informative after at least a few hours runtime.

Yeah, that's what I though. It did run for 4+ hours each way, and the values reported by BTCMiner certainly fell within or above the expected. The problem was that it started consistently submitting a lot less shares, without exception, for a multi hour stretch of time (though the MHs rates staid where they should).

As I said, probably just coincidence, I just feel it is awkward this coincidence only happened with d2 and always happened to d2... but hey, that's why it is called 'coincidence', I guess

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: nelisky on January 28, 2012, 07:34:30 AM

Although it might not be more than a coincidence, I can tell you that mining with d2 (on EclipseMC) has a weird behaviour; it starts fine, mines away at the expected rate but eventually starts to submit less nonces. I mean, not in a random way, consistently less, with all the rates reported in BTCMiner staying stable (even though the submits are correctly reported in the low ball area). It simply does not happen when mining with d1.

The difference between d1 and d2 firmware are different clock multipliers / dividers. This does not influence the submission of shares.

For performance evaluation use the "hash rate" value from the center of the line. The "submitted hash rate" at the end of the line is computed based on the shared found. This value depends on your luck and is only informative after at least a few hours runtime.

nelisky

legendary

Activity: 1540

Merit: 1002

Although it might not be more than a coincidence, I can tell you that mining with d2 (on EclipseMC) has a weird behaviour; it starts fine, mines away at the expected rate but eventually starts to submit less nonces. I mean, not in a random way, consistently less, with all the rates reported in BTCMiner staying stable (even though the submits are correctly reported in the low ball area). It simply does not happen when mining with d1.

Doing a little debug it seems to me that it happens when there are multiple new blocks reported in a short amount of time. Could be a problem with long pooling, but why would only d2 be affected by this? My board runs at 198MHz with d2, 0% error rate, frequency is stable, so that's not it.

I'm sticking with d1 for now but let me know if you need more info or want me to test anything.

HendrikJan

member

Activity: 64

Merit: 10

Real nice project but i need to buy them for the sale price of 250 pieces before i can make some profit.
I get an break even in 323 days.
http://bitcoinx.com/profit/

Or did i miss something and can it be faster/cheaper?

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Have d2 on all of my boards. 1 makes 216 MHz, 3 210 MHz and 2 204 MHz.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Inspector 2211 on January 27, 2012, 07:33:58 PM

I'm assuming that in the December firmware, the PLL denominator, which divides the 48 MHz input clock (from the Cypress microcontroller) is 6, and thus the numerator is multiplied by 8 MHz, leading to frequency adjustments of granularity 8 MHz, whereas in the January firmware, the PLL denominator is 8, and thus the numerator is multiplied by 6 MHz, leading to frequency adjustments of granularity 6 MHz.

Correct?

Not exactly, but something like that: the only difference between the d1 and the d2 firmware of the new release are different DCM and PLL settings.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Inspector 2211 on January 28, 2012, 12:07:56 AM

No, this new version really doesn't work. It tries and tries, gradually reducing the PLL frequency down to 126 MHz, that's when I gave up. I have sent you a log by email.

Use the d1 firmware from the new release if d2 does not work, see https://bitcointalksearch.org/topic/m.715272

rupy

hero member

Activity: 725

Merit: 503

the d2 works fine for me with zalman heatsink stabilizing around 208 MH/s at 210 MHz:

ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz, errorRate=0.10%, maxErrorRate=0.69%, \
hash rate: 209.8MH/s, submitted 2 new nonces, submitted hash rate 208.5MH/s
ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz, errorRate=0.08%, maxErrorRate=0.69%, \
hash rate: 209.8MH/s, submitted 3 new nonces, submitted hash rate 208.6MH/s
ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz, errorRate=0.28%, maxErrorRate=0.69%, \
hash rate: 209.4MH/s, submitted 0 new nonces, submitted hash rate 208.5MH/s
ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz, errorRate=0.21%, maxErrorRate=0.69%, \
hash rate: 209.6MH/s, submitted 3 new nonces, submitted hash rate 208.6MH/s

Inspector 2211

sr. member

Activity: 448

Merit: 250

Quote from: ztex on January 27, 2012, 02:12:57 PM

Quote from: Inspector 2211 on January 27, 2012, 01:53:56 PM

I just looked at the screen output, the number on the far right side. And yes, I did wait a minute or two to see whether I get a non-zero hash rate.

This is the "submitted hash rate". Never, ever, ever use this value for performance evaluation if you run the board only for a few minutes. Use the frequency or the "hash rate" in the center of the line.

(Maybe I should put the actual "hash rate" to the end of the line and the "submitted hash rate" into the center. This will save al lot of support time ;-) )

Quote

What I noticed is, the software kept switching frequencies like crazy, in 6 MHz increments, whereas the old software switched in 8 MHz increments and only very rarely.

It switches more often at start-up but will stabilize after a while.

No, this new version really doesn't work. It tries and tries, gradually reducing the PLL frequency down to 126 MHz, that's when I gave up. I have sent you a log by email.

Inspector 2211

sr. member

Activity: 448

Merit: 250

Quote from: ztex on January 27, 2012, 07:08:24 PM

Quote from: CA Coins on January 27, 2012, 06:53:45 PM

I think that might be it. It runs stable with the d1 firmware so I am sticking with that for now. Here is a part of the log showing that it clocks up and down, sometimes really low. It runs stable at 192Mhz with the d1 and sometimes it will run stable with the d2 as well, but it inconsistent. I will trim the entry once you have seen it.

Seen it. I'll send you a new firmware for testing next week. If it cant be fixed I'll switch back to d1.

BTW, with d1 your boards should achieve 200 MHz, with d2 198 MHz or 204 Mhz.

I'm assuming that in the December firmware, the PLL denominator, which divides the 48 MHz input clock (from the Cypress microcontroller) is 6, and thus the numerator is multiplied by 8 MHz, leading to frequency adjustments of granularity 8 MHz, whereas in the January firmware, the PLL denominator is 8, and thus the numerator is multiplied by 6 MHz, leading to frequency adjustments of granularity 6 MHz.

Correct?

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: CA Coins on January 27, 2012, 06:53:45 PM

I think that might be it. It runs stable with the d1 firmware so I am sticking with that for now. Here is a part of the log showing that it clocks up and down, sometimes really low. It runs stable at 192Mhz with the d1 and sometimes it will run stable with the d2 as well, but it inconsistent. I will trim the entry once you have seen it.

Seen it. I'll send you a new firmware for testing next week. If it cant be fixed I'll switch back to d1.

BTW, with d1 your boards should achieve 200 MHz, with d2 198 MHz or 204 Mhz.

CA Coins

donator

Activity: 305

Merit: 250

I think that might be it. It runs stable with the d1 firmware so I am sticking with that for now. Here is a part of the log showing that it clocks up and down, sometimes really low. It runs stable at 192Mhz with the d1 and sometimes it will run stable with the d2 as well, but it inconsistent. I will trim the entry once you have seen it.

EDIT: Got it, thanks.

Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards - page 39. (Read 182450 times)