Open Source Avalon Gen2 55nm Board

[form]

Ok, form has answered on that question. one more thing, if you connect fan to the board cut the yellow wire, it will reset PIC16LF1459 all the time. everything else is ok on that side.
@form what we need to change in the code for tach to working ? i have removed it from hardware completely, but it can be used for some alarm when the fan stop working or something like that ... is it big change or minor ? Thanks,

Thats an issue caused by non-standard fans, which actively outputs +12 volts on the tacho-output.
The board is designed for normal CPU-fans (i think it was specified by intel), which have a passive open-collector output on the tacho-pin, which alternatevly connects this pin to GND and leave it open again.

When a non-standard fan outputs +12 volts there, the PIC is entering high voltage programming mode, which is not intended to happen.

So actually no way to avoid it via software, just cut the wire - The software doesnt take care of the RPM anyway.

[BigJRepairs]

Ok, form has answered on that question. one more thing, if you connect fan to the board cut the yellow wire, it will reset PIC16LF1459 all the time. everything else is ok on that side.
@form what we need to change in the code for tach to working ? i have removed it from hardware completely, but it can be used for some alarm when the fan stop working or something like that ... is it big change or minor ? Thanks,

Thats an issue caused by non-standard fans, which actively outputs +12 volts on the tacho-output.
The board is designed for normal CPU-fans (i think it was specified by intel), which have a passive open-collector output on the tacho-pin, which alternatevly connects this pin to GND and leave it open again.

When a non-standard fan outputs +12 volts there, the PIC is entering high voltage programming mode, which is not intended to happen.

So actually no way to avoid it via software, just cut the wire - The software doesnt take care of the RPM anyway.

I just hardwire the fans full speed. Am I reading the chipset datasheet wrong or would stock setting be 1V at 500-1000 MHZ?

[DrZeck]

Ok, form has answered on that question. one more thing, if you connect fan to the board cut the yellow wire, it will reset PIC16LF1459 all the time. everything else is ok on that side.
@form what we need to change in the code for tach to working ? i have removed it from hardware completely, but it can be used for some alarm when the fan stop working or something like that ... is it big change or minor ? Thanks,

Thats an issue caused by non-standard fans, which actively outputs +12 volts on the tacho-output.
The board is designed for normal CPU-fans (i think it was specified by intel), which have a passive open-collector output on the tacho-pin, which alternatevly connects this pin to GND and leave it open again.

When a non-standard fan outputs +12 volts there, the PIC is entering high voltage programming mode, which is not intended to happen.

So actually no way to avoid it via software, just cut the wire - The software doesnt take care of the RPM anyway.

I just hardwire the fans full speed. Am I reading the chipset datasheet wrong or would stock setting be 1V at 500-1000 MHZ?

0.9V is the default voltage but 1V is just fine i did try 1.2V and they still live, but there is no change with speed for now.

[BigJRepairs]

I had seen Ost mention using 1.025V. I don't see much of any difference between .9 and 1.025. Wouldn't it make more sense to keep it around .9V?

[DrZeck]

I had seen Ost mention using 1.025V. I don't see much of any difference between .9 and 1.025. Wouldn't it make more sense to keep it around .9V?

at lower voltage it will draw more amps for same performance, so 1v is ideal if there is no difference in speed.

did you try to chain boards ?

Cheers,

[form]

at lower voltage it will draw more amps for same performance

I think you are wrong. There is no DC/DC converter "inside" the chips

[BigJRepairs]

at lower voltage it will draw more amps for same performance

I think you are wrong. There is no DC/DC converter "inside" the chips

I concur I'm lost as to what this would be set at ideally or if it even matters between .9 and 1. The best response I've found is around .940 1640:70 into BFG. What do you set your cards at form?

Also wondering if anyone has interest in my jacked up card? Whatever is wrong with it isn't obvious, it connects to BFG miner but won't do any work. I know it isn't the ASIC's because I have 4 others assembled in the same manner. Anyway, I'm tired of messing with it.

[BigJRepairs]

did you try to chain boards ?

I didn't try hooking up two boards together like you were saying. (I'm not saying that wouldn't work, I'm not sure actually) It works using the schematic in a master slave effect. You need the pull-down resistors on SCL and SDA to create the logic 0 on the chain.

[Ostenbacken]

I had seen Ost mention using 1.025V. I don't see much of any difference between .9 and 1.025. Wouldn't it make more sense to keep it around .9V?

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.

[BigJRepairs]

I had seen Ost mention using 1.025V. I don't see much of any difference between .9 and 1.025. Wouldn't it make more sense to keep it around .9V?

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.

It's DVDD adjustment right? Ideally the maximum hash rate you could get would be around 1.1V at 2A Iop, Frequency = ? Or .9V per chip still around 2A Iop if you are going for efficency, Frequency = ? When you came up with the 4A per chip were you measuring the operating current per chip or measuring the power consumption of the board? I also noticed you're chips running at 35C, how long have you been able to sustain that?

[DrZeck]

at lower voltage it will draw more amps for same performance

I think you are wrong. There is no DC/DC converter "inside" the chips

Yeah, i was trying to say something else here  and too bad avalon did not include some dc/dc reg inside the chips , i spend fortune just for dc/dc controllers 

Any way IMHO chips are really power hungry, interested to see that they can "eat" 4+ amps with ease  ( @~1.5 - 1.7gh/s ) 

About i2c i am newbie in that field, i start with mcu's codes and so on ...  when i start to work on first miner with bitfury chips, But i think that the i2c lines need to be in pull up, and as much as i know that worked with k16 klondike boards and not changed here at all.

how do you connect boards on raspberry ? hubs ?

@BigJRepairs why do you think you need pull down resistor on SCL/SDA lines ?

@Ostenbacken your code works ok with my boards, but i have 4 chips only at the moment on boards, there is very low error rate, about 1% - running for 8 hours approx @ 1V 1400mhz but i have some wierd situation when i build code and program chip with that .hex, i have higher error rates and simply it just not working like your compiled hex. need to see what is wrong there, i have installed mplabx 2.00 and xc8 1.30, but on 1.85 and xc8 1.20 everything was the same ... so its working but not good. 

I hope i will get boards at monday so i will try everything i can before assembling boards. Will post results here ...

Cheers,

[BigJRepairs]

Is there a way I can get a live current measurement in parallel between sense+ or TP1 and sense- on the voltage regulator?

@BigJRepairs why do you think you need pull down resistor on SCL/SDA lines ?

I originally had pull-up then I edited it to pull down. I think it is pull up anyway, one device = bus driver. The rest of the devices = bus passengers or "slaves" even if it's one. The resistors keep the slaves clock and data line in time with the master. I think it's referred to as a wired logic connection. I'd guess it would work with the resistors on the board just between two the way you said. Why would you go through the trouble for just 2 boards though?

[DrZeck]

Is there a way I can get a live current measurement in parallel between sense+ or TP1 and sense- on the voltage regulator?

@BigJRepairs why do you think you need pull down resistor on SCL/SDA lines ?

I originally had pull-up then I edited it to pull down. I think it is pull up anyway, one device = bus driver. The rest of the devices = bus passengers or "slaves" even if it's one. The resistors keep the slaves clock and data line in time with the master. I think it's referred to as a wired logic connection. I'd guess it would work with the resistors on the board just between two the way you said. Why would you go through the trouble for just 2 boards though?

i am building a bit more boards ( 150 ) so i need that feature if its working, if not well ... hubs ... 

[Ostenbacken]

It's DVDD adjustment right? Ideally the maximum hash rate you could get would be around 1.1V at 2A Iop, Frequency = ?

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.

were you measuring the operating current per chip or measuring the power consumption of the board?

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.

I also noticed you're chips running at 35C, how long have you been able to sustain that?

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

[Ostenbacken]

@Ostenbacken your code works ok with my boards, but i have 4 chips only at the moment on boards, there is very low error rate, about 1% - running for 8 hours approx @ 1V 1400mhz but i have some wierd situation when i build code and program chip with that .hex, i have higher error rates and simply it just not working like your compiled hex. need to see what is wrong there,

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.

[DrZeck]

@Ostenbacken your code works ok with my boards, but i have 4 chips only at the moment on boards, there is very low error rate, about 1% - running for 8 hours approx @ 1V 1400mhz but i have some wierd situation when i build code and program chip with that .hex, i have higher error rates and simply it just not working like your compiled hex. need to see what is wrong there,

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.

Hi,

the chips are soldered 2 in the first bank and 2 in second bank, yes i did change chip count to 4 and there is no much difference with that, i have some time now so i will try few things.

Ohh i forget to mention LED is always on. do you have same situation ?

[Ostenbacken]

the chips are soldered 2 in the first bank and 2 in second bank, yes i did change chip count to 4 and there is no much difference with that, i have some time now so i will try few things.

Please try everything I've suggested and post your results.

Ohh i forget to mention LED is always on. do you have same situation ?

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.

[DrZeck]

Ok, i dont know what was the problem with building/programing firmware last time but now works fine, i have same results with both hex, but when i change chip to 4 i have a lot of work ignored messages, i did try to change delay in the klondike driver to 0.5,0.7,1.0,1.5,2.0,2.5 the best results are on 0.5-0.7 as you said before, but i did not test board for a long time. i have real hashrate with 4 chips and after some time hashing hash rate drops a bit but not because of firmware problem but temperature problem ( very bad heatsink ATM on boards )

I will post complete test results next week when i completely populate one board with 10 / 16 chips and adequate heatsink/fans.

@Ostenbacken Can u please upload compiled hex for 10 chips too, just to have it when i start to test boards.

[BigJRepairs]

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've been using your firmware and found personally this isn't true at all. I'm still around 1280 .94V, my two boards running on Debian run around 10 GH/s. The other 2 on raspberry pi, Archlinux run at 17 GH/s. The bfgbuild, drivers and firmware are identical. I've confirmed these speeds on both multipool and givemecoins.

Can someone confirm that shorter and higher quality USB cables yield higher speeds? I'm not entirely sure yet but this may be the most cost effective upgrade you can make. I also appreciate the change to the LED.

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.

I agree, I'm considering moving the regulator to a breadboard in an attempt to get a more accurate measurement of the output current unless someone has a better idea. An easier method might be increasing the resistance at Pin 11 (sense +) through TP1 on the regulator and measuring the change in voltage to get a better idea of the output current. Things like that work in my head, but don't always pan out in the real world. Have you had any regulators fail yet?
 

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.

I favor the method of holding my hand slightly above the heatsinks, I've suspected via IR gun that the reported 25C is closer to 30 on my boards. I might be able to borrow a slim PRT that could take this measurement pretty accurately. Like you said all temperature measurements utilizing resistance in this method are approximate. Utilizing a 4-wire resistance and an ice point reference is probably the cheapest. I cut up a 10 ft hunk of aluminum C-Channel from the Home Depot and thermal pasted it

[Ostenbacken]

I've been using your firmware and found personally this isn't true at all.

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.

Can someone confirm that shorter and higher quality USB cables yield higher speeds?

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.

An easier method might be increasing the resistance at Pin 11 (sense +) through TP1 on the regulator

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.

Have you had any regulators fail yet?

Not yet.

I favor the method of holding my hand slightly above the heatsinks,

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.