BFL ASIC Firmware & Hardware, Understanding & Optimization

[PuertoLibre]

Please note that the two reported temperatures from the single-sc are not everything. This values are coming from two sensors, which are somewhere between a 8-ASIC cluster and the +1V regulation for this cluster. They are not in the ASICs or inside the 8-ASIC cluster circuit nor inside the +1V regulation circuit.

Even if you may see only a small temperature increase by changing the fans or even see a decrease by changing the whole setup by e.g. opening the box or something like this, it doesn't mean that the ASIC's or any other important parts are not getting much more hot than they should. Also watch the hardware error rate carefully!

Soon I'm ready to report my results from looking for fan alternatives....

In effect, what you are saying is...the chips are actually hotter than reported. Correct?

Is that a good thing?

Not necessarily. The DC/DC supply generates a significant amount of heat as well, and doesn't have the benefit of the nice heatpiped cooler attached to it. It's possible that the temperature reported from the sensors close to the output inductor could be higher than the die temperature.

Is the next generation (Monarch) going to have a true (die level) temp sensor?

[1713505805]

1713505805

[1713505805]

1713505805

[MrTeal]

Please note that the two reported temperatures from the single-sc are not everything. This values are coming from two sensors, which are somewhere between a 8-ASIC cluster and the +1V regulation for this cluster. They are not in the ASICs or inside the 8-ASIC cluster circuit nor inside the +1V regulation circuit.

Even if you may see only a small temperature increase by changing the fans or even see a decrease by changing the whole setup by e.g. opening the box or something like this, it doesn't mean that the ASIC's or any other important parts are not getting much more hot than they should. Also watch the hardware error rate carefully!

Soon I'm ready to report my results from looking for fan alternatives....

In effect, what you are saying is...the chips are actually hotter than reported. Correct?

Is that a good thing?

Not necessarily. The DC/DC supply generates a significant amount of heat as well, and doesn't have the benefit of the nice heatpiped cooler attached to it. It's possible that the temperature reported from the sensors close to the output inductor could be higher than the die temperature.

Is the next generation (Monarch) going to have a true (die level) temp sensor?

The current BFL chip has an on die temperature sensor, they just aren't using it. If I had to guess it's a cost issue; it's cheaper to toss a couple 20 cent temperature sensors on the board that it is to properly mux and read 16 temperature diodes.

[Red_Wolf_2]

Please note that the two reported temperatures from the single-sc are not everything. This values are coming from two sensors, which are somewhere between a 8-ASIC cluster and the +1V regulation for this cluster. They are not in the ASICs or inside the 8-ASIC cluster circuit nor inside the +1V regulation circuit.

Even if you may see only a small temperature increase by changing the fans or even see a decrease by changing the whole setup by e.g. opening the box or something like this, it doesn't mean that the ASIC's or any other important parts are not getting much more hot than they should. Also watch the hardware error rate carefully!

Soon I'm ready to report my results from looking for fan alternatives....

In effect, what you are saying is...the chips are actually hotter than reported. Correct?

Is that a good thing?

Not necessarily. The DC/DC supply generates a significant amount of heat as well, and doesn't have the benefit of the nice heatpiped cooler attached to it. It's possible that the temperature reported from the sensors close to the output inductor could be higher than the die temperature.

Is the next generation (Monarch) going to have a true (die level) temp sensor?

The current BFL chip has an on die temperature sensor, they just aren't using it. If I had to guess it's a cost issue; it's cheaper to toss a couple 20 cent temperature sensors on the board that it is to properly mux and read 16 temperature diodes.

I'm guessing those on-die temp sensors are the pins labelled ADRS0, ADRS1 and ADRS2?

[MrTeal]

I'm guessing those on-die temp sensors are the pins labelled ADRS0, ADRS1 and ADRS2?

No, those set the chip address (0 to 7) in the SPI chain. The temp diode is ball M8 and M9.

[2112]

The current BFL chip has an on die temperature sensor, they just aren't using it. If I had to guess it's a cost issue; it's cheaper to toss a couple 20 cent temperature sensors on the board that it is to properly mux and read 16 temperature diodes.

My guess is that the reason to use external sensors is that the internal ones are too noisy and very inaccurate. The cost is indirect: they can't afford to design the de-noising hardware/software and can't afford to properly characterize and calibrate the internal sensors.

It is actually quite common problem: many SoC chips have on-die temperature sensors but use external ones because otherwise they wouldn't meet the time-to-market goals. This includes even very-well capitalized entities which already have the methodology and the tools available.

[BTC-engineer]

The current BFL chip has an on die temperature sensor, they just aren't using it. If I had to guess it's a cost issue; it's cheaper to toss a couple 20 cent temperature sensors on the board that it is to properly mux and read 16 temperature diodes.

My guess is that the reason to use external sensors is that the internal ones are too noisy and very inaccurate. The cost is indirect: they can't afford to design the de-noising hardware/software and can't afford to properly characterize and calibrate the internal sensors.

It is actually quite common problem: many SoC chips have on-die temperature sensors but use external ones because otherwise they wouldn't meet the time-to-market goals. This includes even very-well capitalized entities which already have the methodology and the tools available.

I agree, I also think this is the reason why they didn't use this pins.
Anyhow, this pins are not connected on BFL's PCB designs. At least not from reading the jala schematics. I guess the single-sc design is not different in this point.
So no (easy) way to use them in existing BFL products.

@MrTeal: Did you use this pins in your design?

[BTC-engineer]

The current BFL chip has an on die temperature sensor, they just aren't using it. If I had to guess it's a cost issue; it's cheaper to toss a couple 20 cent temperature sensors on the board that it is to properly mux and read 16 temperature diodes.

My guess is that the reason to use external sensors is that the internal ones are too noisy and very inaccurate. The cost is indirect: they can't afford to design the de-noising hardware/software and can't afford to properly characterize and calibrate the internal sensors.

It is actually quite common problem: many SoC chips have on-die temperature sensors but use external ones because otherwise they wouldn't meet the time-to-market goals. This includes even very-well capitalized entities which already have the methodology and the tools available.

I agree, I also think this is the reason why they didn't use this pins.
Anyhow, this pins are not connected on BFL's PCB designs. At least not from reading the jala schematics. I guess the single-sc design is not different in this point.
So no (easy) way to use them in existing BFL products.

@MrTeal: Did you use this pins in your design?

Who ultimately makes the decision whether a certain feature you designed is used or not?

This question can not answered in general. In case of the BFL ASIC or BFL products you have to ask BFL.
The only think I've designed up to now, which is related to the BFL single-sc product is the improved version of the fan plate.

[BobbyJo]

Has anyone tried the fridge trick with a mini single?  Mine is hashing at a steady 31 Ghash per sec, so I am reluctant to stop it and play around if it doesnt work?  Any idea on the extra perfromance you can expect?

[BTC-engineer]

Has anyone tried the fridge trick with a mini single?  Mine is hashing at a steady 31 Ghash per sec, so I am reluctant to stop it and play around if it doesnt work?  Any idea on the extra perfromance you can expect?

Yes, I've tried this with one of my first 60GH singles running firmware 1.2.6
The starting temperature has a little impact on the initial diagnosis test, but this is only minimal. More important is, that I could not simple always say that as more cool the unit is as more powerful the hashing result is.  The reason for this in firmware version 1.2.6 is, that it doesn't help you, when the diagnosis test is calculation wrong results based on wrong extreme starting temperatures. If the engines are clocked too fast and the unit is getting more hot, the HW-error rate is probably much increasing..

So my short advice. Forget it. Try to keep your unit constantly cool, this helps.

[BobbyJo]

Can we have at least one thread where people can ask serious questions without the constant baiting!  There are plenty of threads bashing the manufacturers, so can we have a grown up questions and answers thread without constant bitching?  Or is that beyond us?

[Cablez]

@ BTC-Engineer/Nasser

I don't think you are talking to who you think you are.

[PuertoLibre]

@ BTC-Engineer/Nasser

I don't think you are talking to who you think you are.

Who are we talking to then?

[BTC-engineer]

Can we have at least one thread where people can ask serious questions without the constant baiting!  There are plenty of threads bashing the manufacturers, so can we have a grown up questions and answers thread without constant bitching?  Or is that beyond us?

I also feel sad that this is not possible. Always the same "users" who take over every thread with their unqualified postings.
I think the most serious members know what I mean. I really wonder, why the moderators are not talking any steps to avoid this chaos.

[Cablez]

https://bitcointalk.org/index.php?action=profile;u=49711

vs.

https://bitcointalk.org/index.php?action=profile;u=52443

[PuertoLibre]

That is very embarrassing....

I will eliminate any topics misdirected at BTC-Engineer.

@ BTC-Engineer

I'll leave some posts so that continuity across the thread makes sense. I offer my apologies on mis-identifying you.

[BTC-engineer]

@ BTC-Engineer/Nasser

I don't think you are talking to who you think you are.

Who are we talking to then?

Those who can read have a clear advantage.
BTW: Are you not the one who first corrected me, as a non English native speaker, after my first posting in this thread, by not only just telling me what I've done wrong. You quoted a multi-page posting, just to point out one wrong spelled word. This really helped a lot!

To answer your question, just to avoid that anyone thinks I like this confusion.
I guess you mean BFL-Engineer, also known as Mr. Nasser from BFL.
I'm BTC-engineer. And just for the case - I was first here.
 
You would do me, and I guess most others also a big favor by avoiding this topic or even better, reducing your 'activity' on a Kindergarten section in this forum, for users without a real life.

[PuertoLibre]

@ BTC-Engineer/Nasser

I don't think you are talking to who you think you are.

Who are we talking to then?

Those who can read have a clear advantage.
BTW: Are you not the one who first corrected me, as a non English native speaker, after my first posting in this thread, by not only just telling me what I've done wrong. You quoted a multi-page posting, just to point out one wrong spelled word. This really helped a lot!

To answer your question, just to avoid that anyone thinks I like this confusion.
I guess you mean BFL-Engineer, also known as Mr. Nasser from BFL.
I'm BTC-engineer. And just for the case - I was first here.
 
You would do me, and I guess most others also a big favor by avoiding this topic or even better, reducing your 'activity' on a Kindergarten section in this forum, for users without a real life.

I understand, making a fan grill is a challenge.



...and in all honesty, it is an improvement. (who designs these original pieces?)

[jon@bitcoinads.com]

I built a cabinet to reduce the sound of my BFL 60GH/s miner. It has three chambers insulated with foam. There are four 120mm intake fans pulling cool air in from the floor and another four pushing out the back at the top. I built a little power supply for the fans that draw 15 W. I had hoped to sit the miner vertically pushing air upwards but it won't run that way.

The temperature is about 2-3 deg C higher which I will work on. 59 on the floor is now 63 C in the cabinet. It is significantly quieter and I expect to be able to sleep now.

 http://subjectreality.com/miner/cabinet.png

[jon@bitcoinads.com]

Here is a picture inside the cabinet before the fans were installed.

http://subjectreality.com/miner/cabinet2.png

[Red_Wolf_2]

I'm now wondering what these two defines in the firmware do... Anyone experimented with them?
//#define __CHIP_BY_CHIP_DIAGNOSTICS      
//#define __ENGINE_BY_ENGINE_DIAGNOSTICS

I'm imagining more in-depth self-diagnostics on bootup, but if there is a chance the chip-by-chip diagnostics would allow individual chips on boards to reclock to higher maximum speeds it would definitely be interesting to play with...

Also, I've been working on a windows program to make it easier to grab statistics from BFL Bitforce SC gear. Far from complete yet and it only supports FTDI drivers, but its available from http://randomcontent.wolfnexus.net/RandomSite/files/2313/7776/5140/RW2-BFL-Commport-Scanner.zip

Yes it is an executable, but I can promise it does nothing malicious. Below is a summary of how it works.

Startup - unpack required wrapper DLL from within using reflection
Check for running cgminer or bfgminer instances. Display warning if found, lock interface and skip subsequent scans
Scan for FTDI devices using WinUSB driver, if found display warning
Scan for FTDI devices using unknown driver, if found display warning
Scan for FTDI devices using FTDI driver, identify which of these are Bitforce SC units and add them to the listbox

On selection from listbox, enable scan device button. If nothing selected in listbox, ensure button is disabled

On scan, open port based on device serial number. Issue ZCX, ZTX and ZLX commands and populate relevant fields on the user interface.

Thats about all there is to it, besides some other bits of logic to keep the UI clean.
If anyone finds any bugs, please let me know. I've done four or five iterations so far to fix major bugs.

Again, this is a Windows only program, and has been tested on XP and Windows 7 so far. It is written in .Net (because I am lazy) and isn't really open source, although I'm happy to discuss the code if anyone is interested.