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.)

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.

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?

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.

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!

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

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.

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.

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.

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.