Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards

[TheSeven]

(I do agree TheSeven hasn't been properly compensated for his work (for MPBM).  Perhaps he can change that somehow.)

Oh, probably not that much worse than other open source software developers here. What I wanted to point out is that more than 90% of that was paid by board manufacturers who want me to support their boards, not users, and that users paid much more in direct donations than in the profit share model.

So if you want some software developer to be compensated somewhat fairly, you will either have to force the profit share model on users like ET does, or you have to make deals with the hardware manufacturers who are hoping to increase sales by taking advantage of your software. However both of which are unlikely to be competitive if you consider the real time investment.

[1714467231]

1714467231

[1714467231]

1714467231

[ztex]

When will i be able to use that on my Ztex Cluster ?

I'm not sure whether it is reasonable to use the tricone bitstream on ZTEX FPGA board. Here here my considerations.

1. I made some more exact current measurements with the ZTEX bitstream. At 212 MHz the core current is approximately 6.7 A, i.e. the frequency limit with this bitstream is about 250 MHz on ZTEX FPGA boards (with 8A core voltage regulator).

2. According to eldentyrrel the tricone bitstream is about 13% less efficient. This bitstream  would have to be limited to 217 MH/s on the ZTEX FPGA boards.

3. At 12V input voltage it is probably possible to override the max. current of AOZ1025DI by 0.5A   (this would require some long term tests at 9.5A). But IMHO its not worth it: At 8.5A the tricone bitstream should deliver about 233 MH/s. The price for additional 17 MH/s (21*0.8, 20% goes to eldentyrrel) is  approx. 2.5W more power on the wall and a reduced reliability.

4. I'm concerned about the reliability (due to the 2-year warranty):

4.1. At 8A the power dissipation of the FPGA is about 10W. The thin CGS484  packages have a junction-case thermal resistance of 2.2 K/W. Plus 0.3 K/W for the thermal grease this results in  junction temperature of 70.5°C, if the bottom of the heat sink is 45°C warm. This should be still o.k. but there is not much margin for improper installed heat sinks or so. And  many users had problems with this because the plastic packages are not very flat.

For comparison: The thermal resistance of the thick FGG484 packages which are used for most other LX150 FPGA boards is 3.7 K/W. Plus 0.3 K/w for the thermal grease
leads to a junction temperature of 85°C at 8A,  96°C at 10A, and 106°C at 12A

4.2. There is no on-die temperature sensor. If the heat sink is not installed perfectly the core temperature reaches critical levels and there is no chance to recognize this. The indirect overheat protection by error measurement (as implemented in BTCMiner) does not work if the frequency is limited.

I'm sorry but due to the 2 year warranty and from my experience its seems to be too critical for me to support the eldentyrrel bitstream actively. (Of course, everyone can do this on ones own risk.)

[DiabloD3]

I hope a list of boards that have enough current are listed. Its hard to buy new boards if you don't know which ones are insufficient.

[bitfury]

When will i be able to use that on my Ztex Cluster ?

4.1. At 8A the power dissipation of the FPGA is about 10W. The thin CGS484  packages have a junction-case thermal resistance of 2.2 K/W. Plus 0.3 K/W for the thermal grease this results in  junction temperature of 70.5°C, if the bottom of the heat sink is 45°C warm. This should be still o.k. but there is not much margin for improper installed heat sinks or so. And  many users had problems with this because the plastic packages are not very flat.

For comparison: The thermal resistance of the thick FGG484 packages which are used for most other LX150 FPGA boards is 3.7 K/W. Plus 0.3 K/w for the thermal grease
leads to a junction temperature of 85°C at 8A,  96°C at 10A, and 106°C at 12A, 133°C (!) at 22W (bitfury bitstream) ...

Ztex, I will correct you...

1. It's about 12W, not 22 W, that is very important.

2. Datasheet says 6.3 K/W thermal resistance for FGG484 package to board, so about 3 W goes to board.

(1) and (2) => we get about 33 degrees overheat...
Airflow 1 m/s. TUNED by that large green thing from behind to harmonize heat exchange with cooling water.
Thermal image of chip heatsink - about 36-45 degrees.
Thermal image below chip - about 50-60 degrees.

So I would expect junction temperature in range 70-85 degrees. depending on chip location and temparature
of cooling fluid.

3. Yes, it is overall hot, that is why we have about 20 degrees air inlet before chip, and specific setup, placing
    not more than 2 heatsinks in way of airflow.

    If same measures for cooling won't be taken - it will not fly. And so it will not work on most deployed spartans or
    home-brew boards.

It took significant time to model this.... So it is not the thing, that we got "by chance".

Then - we took FGG484 package mainly because we thought to place more 0402 capacitors right below it to provide better power. Maybe this is not necessary step, we haven't done EM modelling.

[ztex]

1. It's about 12W, not 22 W, that is very important.

I derived the 22W from the total power consumption because I found no other values. But I see that I did not read properly.

12W at 300 MH/s if very ambitious. It's more efficient than what I achieve with the fully unrolled design (which saves a lot of resources and can use distributed memory for shift registers).

2. Datasheet says 6.3 K/W thermal resistance for FGG484 package to board, so about 3 W goes to board.

But you probably do not cool the top side of the PCB below the FPGA (where the FPGA is soldered).

[Syke]

I can't understand the harsh criticism from people here on him / his concept.

Bitcoin core software = free software
Bitcoin mining software = free software
This bitstream = non-free software built on the backs of free software

That's my problem with it. Without Bitcoin, this bitstream is worthless. But I don't hear eldentyrell splitting his manditory mining-tax with the upstream developers that made this all possible.

How about it eldentyrell? How much of your mining-tax are you sending back upstream to benefit the Bitcoin/Mining developers?

[rjk]

I can't understand the harsh criticism from people here on him / his concept.

Bitcoin core software = free software
Bitcoin mining software = free software
This bitstream = non-free software built on the backs of free software

That's my problem with it. Without Bitcoin, this bitstream is worthless. But I don't hear eldentyrell splitting his manditory mining-tax with the upstream developers that made this all possible.

How about it eldentyrell? How much of your mining-tax are you sending back upstream to benefit the Bitcoin/Mining developers?

I'm not 100% sure that I follow your logic. Technically, none of the work he put into it came directly or indirectly from someone else's free work. Just because it fits into a free project's ecosystem doesn't mean it has to be completely free, although that may be the norm.

[BR0KK]

This bitstream = non-free software built on the backs of free software

NO thats not true .... look at the ISE Software u have to use to build that thing ..... 3600€ at least maybe even more. Then the countless hours to build and test that bitstream. Buying new hardware, etc ?

There was a user  that implemented some great feature for gpus (called mrb) and he to sold that technique to the mining community.


If i had the ability to do so i would to.

[bitfury]

1. It's about 12W, not 22 W, that is very important.

I derived the 22W from the total power consumption because I found no other values. But I see that I did not read properly.

12W at 300 MH/s if very ambitious. It's more efficient than what I achieve with the fully unrolled design (which saves a lot of resources and can use distributed memory for shift registers).

2. Datasheet says 6.3 K/W thermal resistance for FGG484 package to board, so about 3 W goes to board.

But you probably do not cool the top side of the PCB below the FPGA (where the FPGA is soldered).

Well. Get for example Solid Works or similar package and model PCB there. As PCB of course have thermal resistance from top to bottom layer, as well it has good horizontal thermal conductivity. So you actually get ONE heat sink - that is whole board with different resistances (and it is quite difficult to predict and say here accurately). As there's gap between big HEAT SINK on top of chip and board. and also aluminium heat sink on top. 40x40 mm board isn't that small are even with 23x23 mm spartan on it! I have airflow around heatsink fins as well as board, as blowing it not from top, etc.

As for clocks - it is completely different round design. The tradeoffs are not trivial. I would say that more optimal designs are possible, but they would consume even more time, that I put into this. As the worst thing - as you examine many variants - most of them won't fit perfectly, and you start loosing, and re-trying the job.

2 Syke:

about bitcoin developers... Actually bitcoin has mechanism that makes revenues for early adopters - look @ bitcoins in first 100k blocks... They are sitting there :-) MINED and not SPENT :-) mostly... Worth about 4-5 mio BTC - $20-$25 USD is nice net worth for open source deployment. That's for bitcoin CORE software.... I think it really worth it... but it is sad, that these owners DO NOT SPEND that money on building better bitstream, hashpower, developing new applications, etc. because that way they would have more net worth, having less BTCs. Just with holding stocks of a company. Maybe they lost their keys already, because at that time bitcoins was worthless, well, it's another story then :-)

Bitcoin mining software - we don't use any miner, etc... everything is implemented from scratch, so where the point ? We don't use any "bitcoin mining software".

[Syke]

2 Syke:

about bitcoin developers... Actually bitcoin has mechanism that makes revenues for early adopters

So today's Bitcoin developers were paid for all future development back in 2009? Satoshi must have been a time traveller to know who all was going to work on Bitcoin and pay them all when the chain was launched!

[bitfury]

2 Syke:

about bitcoin developers... Actually bitcoin has mechanism that makes revenues for early adopters

So today's Bitcoin developers were paid for all future development back in 2009? Satoshi must have been a time traveller to know who all was going to work on Bitcoin and pay them all when the chain was launched!

Why you have to be time traveler ? You just trust in yourself and your work - if your idea would work - then you get it, if it will not work - then not get it. It is fair. But it has far more motivation, then when you work and know for sure that you will not get any benefit of it :-) Even worse, when someone would take your work, invest some time and build commercial launch using it :-)

[eldentyrell]

He is using his wisdom as a prof.

For the record, I am not a professor; my official rank is just "instructor".  The senior faculty get fussy about these sorts of things.

[eldentyrell]

there could be some other development just around the corner that leads to everyone dropping this bitstream over night, since it's freely available software. no one's going to hesitate to update ot the next big bitstream.

Yep.

I'll be thrilled if my income from commissions manages to equal my income from my own mine -- but I seriously doubt that's going to happen.  TheSeven's estimates sound pretty accurate to me, and if they're true it means that my commission income will be less than my income from my own mine.  I'm okay with that.

[eldentyrell]

I'm pretty sure that eldentyrell is going to make LESS from this scheme than if he sold it outright.

You're probably right about that.  I chose the commission scheme not so much out of profit-maximization as hassle-minimization (which is just a different flavor of greed).  Licensing negotiations are agonizing.  I have better things to do with my time and I don't mind sacrificing income for that option.

[eldentyrell]

I think this is the perfect subject for a bet. Does anyone have good ideas for a bulletproof statement that we can gamble on for this?

The "next item" in my queue of bitcoin projects is a blockchain-difficulty-futures market.  Like the way farmers lock in their harvest prices before they plant the seeds.  Not sure if I'll actually go through with it though.

[eldentyrell]

From what I read on his web site it seems like the jobs are what's getting signcrypted, not the golden nonces.

Both are.  Well, actually, the nonces are merely encrypted.  If you send me garbage and claim it's an encrypted nonce I'll happily send garbage back to you.

[eldentyrell]

You signature server is going to be a huge denial of service target.

This has been a FAQ since the very beginning.

[eldentyrell]

TheSeven: You will probably have to agree to make a closed source MPBM build which includes support for this firmware...

No need for it to be closed-source.  ALL CPU software needed to run the TML is "visible source" at the very minimum and probably licensed much more liberally than that.

[eldentyrell]

Another thing is what if bitfury gets the same idea and they release their 300 mh/s bitstream with 5% comission.

Yeah, aside from the fact that he's going to make a killing on his own hardware (which has the best power supply of any system I've seen, by a huge margin) and on hosting for it (which I think is a major untapped market -- finding a place to put my mine was a gigantic headache), I've already explained why in his thread.

The "sea of tiny hashers" approach is really easy to reverse-engineer: there's a repeating pattern you can use to easily separate the hashers from the countermeasures, so you don't have to genuinely understand what's going on.  In a 64-unrolled ring every stage is different (and the first 8 and last 4 stages are really different) so you have to actually understand the circuit -- or at least the funky stages at the start and end -- in order to separate the signcryption countermeasures from the hasher.

I also encode my public key in the wiring pattern of the circuit, not the LUT tables.  So if you want to change the public key you have to actually move wires, which has a high probability of disturbing nearby critical paths.

[eldentyrell]

It makes me sad thinking of all the time he spent on this code ... that could have been spent on a better bitstream.

Oh, I don't know.  It was actually more fun than implementing SHA-256.  I found out that Galois fields are actually useful for something practical!  The only irritating part is I can't show off the details of the signcryption system the way I post chip plots of the SHA circuit.  Like right now, for example, I have to bite my tongue and refrain from responding to Inspector2211's posting.