That's perfect. It seems that you did it right. Now what's left is to optimize your heatsinks, and you could go up to 1.6 - 1.7GH/s per chip.
These chips are inexpensive so I was thinking about building them into my design to replace the thermistor. Though the sensors are accurate, given the above considerations, their measurement would be only good for the purposes of thermal shutdown and some rough monitoring of the module condition. Perhaps the performance of forced air cooling system could be also evaluated based on this sensor data. I'm going to integrate several boards into a rackmount case, and there I'd need to take care of aerodynamics, fan locations, etc.

Ok, so is it correct that you're getting the correct per-chip hashrate with my firmware?
I guess you misunderstood me. You're talking about building a precision thermal sensor whereas what I had in mind is to estimate junction temperature based on indirect off-junction temperature measurements. For instance, you can measure temperature drop at two points in a heat conductor. If thermal conductivity is known, this will give you an estimate on the amount of heat that passes through it. You can then extrapolate the temperature drop into the junction, if thermal conductivity between junction and your measurement points is known. Perhaps with additional measurements and calibration, you can do it pretty accurately, if you dare to perform everything that is needed. A MS degree in physics is recommended

But I don't think that it's really necessary. In my case, the chips work well (1.725GH/s per chip) and this can justify that they don't overheat. I do get the heatsink temperature reading that can be used to judge if the fan has failed or smth, so that the software could stop chip operation to prevent damage.
That's a sustained temperature reading. They work non-stop for several days in this mode.

Any details? How many chips do you have on your board? Have you recompiled the firmware with the proper number of chips? What speed are you setting in bfgminer? Have you tried lower speeds so as to exclude the effect of heating? Say, try speed=1000 and tell me if you're getting 1GH/s per chip. Are you getting any error/warning messages from bfgminer? If yes, what messages specifically? That could aid in diagnostics.

Also, have you tried to see per-chip performance? There are some APIs/command line tools that let you see how many nonces did each chip produce. Chances are that you have failed or improperly soldered chips on your board(s).

We now have multiple users using our firmware with proper results, so please be sure to verify that you did everything right.
I would consider this highly unlikely. It's like spending a fortune on your HDMI or S/PDIF cables: that won't improve your digital audio quality unless your existing cable setup was completely screwed up.
That also seems to me a bad idea. The sense pins are inputs and they normally draw little to no current, so increasing the resistance will not produce any meaningful voltage drop that is proportional to output current.
Not yet.
With hand or with a sensor, no matter how good is it, there is a fundamental problem of access to junction temperature. You can't measure temperature directly on the chip die, and that's the only one that matters. Temperature on the heatsink may be substantially lower than that on the junction if thermal coupling is poor between the chip and the heatsink. In this case the heatsink will stay cool but the chip will remain hot. Just imagine a heatsink that is not in physical contact with your chip. The same thing happens when it is in physical contact but for some reason thermal coupling isn't very good. Temperature difference also increases when the amount of dissipated power increases, so your estimation of junction temperature will be increasingly less accurate as the amount of power dissipated by chips gets higher. You could of course do all the math if you have thermal models of your system and you correctly estimate their parameters but well that's a very demanding job to do it right.

Please try everything I've suggested and post your results.
I've reprogrammed the LED to be on when the board is doing work and to be off when the board is idle. This was handy during debugging of idle conditions encountered when all 16 chips are mounted. Also it's more informative. Some people like when a LED is flashing fast but in case of our board, that flashing doesn't really give you much useful information about the board condition. The primary purpose of LEDs is to display some information that can aid in diagnostics. I think that the "busy/idle" display is a good application for that LED.

Can you tell more details? What kind of errors are you getting (HW error rate or smth else)? Did you try lower speeds? Do you get the exact speed per chip according to the software setting? When you built the code, did you change ChipCount to 4 in the file "klondike.c", line 127? Also, to what locations of the board did you solder your 4 chips? There are two chains on the board up to 8 chips each. If you mount a smaller number of chips, you must distribute them evenly across chains, or the firmware will treat them incorrectly. Also the total number of chips must be even so that both chains contain the same number of chips.

Yes, it's DVDD adjustment. The max hash rate with my firmware is achieved at speed=1650 to speed=1750-1800 which may not be the same as the chip's operating frequency but it yields precisely that hashrate (i.e. 16.5GH/s for speed=1650, etc). The DVDD voltage we're using at these speeds is always below 1.06V. When measuring the voltage, be sure to attach both of your voltmeter's probes to decoupling capacitors near the chips. Otherwise measurement results may be distorted due to voltage drops across wires as high currents are flowing through them.

You should start with lower speed values like 1000, slowly raising them up while improving your thermal design and VDD setting. Once you have established a reliable operation at a lower speed, you can go higher.
I was measuring power consumption of the board and then recalculating values into DVDD current given a rated voltage converter efficiency and budgeting some 3W for 3.3V supply current. It's hard to measure DVDD current directly because the current is high and because it's hard to break DVDD circuit at one location in order to insert an ampermeter there.
Indefinitely. Our thermal design is very capable, involving heatsinks on both sides of the PCB. The thermistor was physically attached to one of the per-chip top side heatsinks and protected from forced air cooling by a layer of glue and a piece of plastic, so as not to distort measurement results due to sensor cooling. The top side heatsinks were also not very hot on touch. However, these results may still be inaccurate because of the very nature of measuring temperature with thermistors. I'm going to try the more accurate chip thermal sensors, namely MCP9700A. Also there are no means of measuring the chips' junction temperature. With heatsinks occupying all the space around the chips, you could only mount a thermal sensor on the heatsink, and then your results will depend on quality of thermal coupling between the chip and the heatsink. So even with better sensors, any temperature measurement of this kind should be considered only approximate.
http://i031.radikal.ru/1402/10/87bad2fb9ab8t.jpg

0.9V is the default. When you try to overclock the chips, hardware error rate increases. Raising the power supply voltage helps reducing the error rate somewhat. In the end, you're trying to get the maximum speed with an acceptable error rate, or the maximum effective speed of hashing as reported by your pool. Both raising the supply voltage and overclocking the chips will increase the total power consumption of the chips and reduce their power efficiency, i.e. GH per Watt. It also increases heating and puts more demands on your thermal design. You can measure power consumption by using an ampermeter on the 12V input power supply wire.

If you're optimizing power per GH, you should instead try to lower the chip supply voltage and speed, until you get the best GH/Watt ratio.

That's right. We didn't make any more changes in the driver. However, please note: we recently figured out that more optimal LATE_UPDATE_MS delays are:
#define LATE_UPDATE_MS ((int)(0.7 * 1000))
for 16-chip boards, and
#define LATE_UPDATE_MS ((int)(1.5 * 1000))
for 10-chip boards.

Also we checked the most recent bfgminer sources. The reduced value of the LATE_UPDATE_MS delay is not yet incorporated in it, so you have to do it yourself.

---

One more thing. We are asking everybody who benefited from our firmware and driver troubleshooting, to support our incentive of sharing our achievements with the community by making a small BTC donation to:
19bWQt5ix6u7hgZyYUcADy72MLsuGzCRYn

Can you post any details? The frequency formula in the original firmware was incorrect, so you had to pick frequencies without any clear understanding how frequency relates to the hashrate. With my firmware, speeds 1650-1717 yield maximum performance, while lower speeds (down to 500MHz) also work well and in a predictable fashion so that the actual hashrate matches with the speed you specify, i.e. speed 500 -> 500MH per chip and so on. Here's a screenshot:
http://s019.radikal.ru/i601/1402/ca/70cccdc0e4bc.png
Here's an example command line:
./bfgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u -p --klondike-options 1718:70
substitute your pool credentials, username and password where appropriate.

PCB changes were minor, so any PCB design version, if it works at all, should also work with the latest firmware (the one that I posted). I would NOT recommend building the 16-chip board for the reason of overloading the voltage converter. Or if you build it, mount 10-12 chips on it. With chips working in turbo mode, it's 2.5W per GH. At 1.6GH the power per chip is 4W which corresponds to 4A current draw per chip. So with 12 chips you'll get 48A which is just below the maximum rated load (50A) of the voltage converter module. This way your circuit should run safely. To have a little extra margin, 10 chips would be even better.

Hi everybody,

here is the updated firmware:
firmware.rar

for the 10-chip board simply change the 'ChipCount' line to 10, we've checked it and it works.

Here is the updated Klondike driver for the bfgminer:

driver-klondike.rar

We are asking everybody who benefited from our firmware and driver troubleshooting, to support our incentive of sharing our achievements with the community by making a small BTC donation to:
19bWQt5ix6u7hgZyYUcADy72MLsuGzCRYn

The updated firmware supports speeds down to 500MHz. It is possible to implement support for lower frequencies as well by using nonzero values for the OD parameter. While making the updates we've hit some Microchip XC8 compiler bugs so that expression evaluations in the UpdateClock() resulted in wrong values. Updating the compiler to the latest version did not help. The workaround was to split big expression evaluations into smaller statements.

Here is the performance achieved with two 10-chip boards and one 16-chip board running at speed 1717 (rated 1.717GH/s per chip). Again, careful thermal design is mandatory to achieve this performance. Heatsinks are required on both sides of the PCB with high-performance rubber inserts between the heatsink and PCB/chips. You can look up overclockers' resources for tips in thermal design.
http://s020.radikal.ru/i710/1402/a6/818c5c336781.png

Hi guys,

good news. It took me and my friends about a week to debug the 16-chip board but now it's nearly finished. To be brief: there were quite some bugs in the firmware. Also we've fixed some suboptimalities in the firmware operation. But now it's very reliable and predictable with bfgminer: you tell the board how fast should it operate the chips, and you get exactly that speed all the way between 500Mh/s per chip to 1700MH/s per chip. With the 16-chip board modifications to bfgminer were also necessary: at high speeds the board completes its work queue too quickly so that a significant amount of time was lost in idle.

With careful thermal design and at 1.025V power, we can run the 16-chip board at 27.2GH/s rated speed. bfgminer currently reports 26.3GH/s but it may change due to averaging.

I'm going to post the firmware updates shortly. A question: what is the optimal way of posting the firmware updates? I could send it to the author of the original project to be incorporated in the github repository. The bfgminer software also has to be modified for operation at maximum speed.

The Texas Instruments voltage converter is pretty overloaded at these speeds. Both inductors and FETs on it heat a lot despite forced air coolong. At least, small heatsinks must be mounted on them. Also I'd recommend making 10-chip boards or placing less than 16 chips on the 16-chip boards such as 12-14 in order not to overload the voltage converter.

http://s020.radikal.ru/i719/1401/62/b501996fcfa8.png

Ok, at least it sort of works. I already ordered the PCBs so I'll probably just run the modules overloaded or reduce the hash rate. But it's a bad engineering practice. Do you think TI's engineers were not tempted to quote higher values in their datasheet if the device was really capable of providing more output current? These days everything is around marketing, and part manufacturers sometimes quote very optimistic values that are only achievable in very controlled circumstances, while in real applications the part can't be realistically expected to deliver that performance. So there must be reasons why their nominal output current is limited to 50A, not more.

Overcurrent protection is just a safeguard against unexpected, exceptional overloads but not a guideline to constantly run your device at currents between 50 and 95A. If you constantly violate datasheet requirements in your designs, you're simply asking for trouble. Say, if this module fails catastrophically, not only it will cost you some $40-$50 to replace it, but it could also fry 16 of your Avalon chips. In the end you may lose a whole board with all parts.

I would consider reducing the number of chips on the board to 12-14 or making a custom VDD voltage regulator in place of the PTH12040 module. The latter approach could also save costs considerably. I have some experience with switching mode power converters, but not at these high currents.

I just read the datasheet again. All performance graphs end at 50A output current. There is even an output current derating below 50A recommended for applications with insufficient cooling. The overcurrent protection shuts down the regulator at 95A output current. So where did you find 100A output current capability in the datasheet? Which page? Or perhaps you were looking at a different product specs? PTH12040WAH is the correct part number.

Hi guys. I have a concern about that the 16-chip board could overload the PTH14020WAH voltage converter.

According to my experimental data with 10-chip boards of this topic, and according to the Avalon-2 datasheet, it seems that the maximum load current of the voltage converter (50A) will be exceeded when the chips are run at their maximum speed.

By datasheet, the chips claim 2.05W/Gh. We could run the chips at 1.5-1.6GH/s on the 10-chip board, so on the 16-chip board the typical power consumption will be 2.05*1.6*16=52.48W. Assuming 1V core supply voltage, this results in 52.48A consumption from the DVDD source.

But the measured power consumption is a bit higher. The 10-chip board draws 3.5A from the 12V source which is 42W. Assume 3W goes into 3.3V supply to power the PIC and the rest of the circuit, while 39W goes into the voltage converter. Assuming 85% efficiency (per datasheet at this output voltage), the output power is 33.15W which corresponds to 33A current draw for 10 chips. If we run 16 chips in this mode, the current would proportionally rise to 53.04A.

This is only a slight overload, but still. I wonder if any of you guys have any experience about how does the voltage converter behave in this overload mode. Does it still function properly? Does the output voltage drop or start oscillating or smth? Do the converter's components overheat?

Hi! I'm an electronics designer too, also MCU programmer. Just registered. It seems the right kind of project for me. I think I could improve some of the designs published here on the forum somewhat. However, it doesn't seem that there is time for that, given that the output of Bitcoin miners decreases dramatically with time. While you'll be designing and prototyping one project, there will be new ASICs around that supersede the existing ones.

So I'd like to start with building a small batch of an existing open-source project as quickly as possible, with no to minimal modifications, to reduce risk. Then, if time permits, I could try to improve it or design my own.

See you around!