BFL ASIC Firmware & Hardware, Understanding & Optimization

[BTC-engineer]

Firmware version 1.2.8 is released. I will test it soon.
It looks like there is a way to use ENGINE_ZERO if the ASIC has revision B, but BFL seems to worry about heat-problems.
I can only repeat myself by saying that one of the most important things is to have a good airflow through the box.
With my improved fan plates, the box is not only quieter, you have also way for hashrate improvements.

---------------------------------------------------------------------------
/*************** Firmware Version ******************/
#define __FIRMWARE_VERSION      "1.2.8"   

// **** Change log Vs 1.2.7
// - An option introduced that disables Engines 0 and 1 on all chips. This is to throttle the speed so the unit won't overheat
//   ( in std_defs.h named as DISABLE_ENGINE_ZERO_AND_ONE_ON_ALL_CHIPS)

// **** Change log Vs 1.2.6
// - Engine 0 operation supported
// - Auto detect if chip is Revision B or A (Revision B has engine 0 functional)
// - Blink issue resolved. Now it blinks for 30seconds instead of 300ms
----------------------------------------------------------------------------

[1713946480]

1713946480

[1713946480]

1713946480

[1713946480]

1713946480

[1713946480]

1713946480

[1713946480]

1713946480

[1713946480]

1713946480

[BTC-engineer]

I've just tested firmware 1.2.8 on one of my singles.
It looks like this single, which is my latest one received ~2 weeks ago, has not yet Revision B chips inside.
Anyhow, I could not reach the overall hashing performance, which I reached with 1.2.6. So I switched back to 1.2.6. To be fair, I didn't spend a lot of time with the new firmware. I will test it again, when new singles arrive.

[Cablez]

So what your saying is with older versions of the hardware, newer firmware doesn't really bump performance any and doesn't seem to be worth the flash?

[BTC-engineer]

So what your saying is with older versions of the hardware, newer firmware doesn't really bump performance any and doesn't seem to be worth the flash?

Well, that's not exactly what I said or would like to say. I would not say it so much in general like your consumption.
I used a SINGLE-SC in the 5xx serialnumber range, which I received ~2weeks ago. Flashing the standard 1.2.8 firmware into this single gave me a significant lower hashing rate than me already tuned 1.2.6 firmware. This was not soo much surprising for me. But after tuning the 1.2.8 firmware in nearly the same way I did it with the 1.2. 6 firmware, I still could not reach the hashing rate of my tuned 1.2.6 firmware. Maybe there are other ways to tune the 1.2.8 firmware to get better results. However, with the standard 1.2.8 firmware I could not see any improvement in hashing-rate over the standard 1.2.6 firmware with my single, which seems to have revision A chips.

[vitruvio]

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.

Sorry but my antivirus is unhappy with your software

[bcp19]

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.

Sorry but my antivirus is unhappy with your software

Neither Symantec nor McAffee alert for this.  The likely reason yours does is that it is seeing the port-scan portion of the software which would indicate a potential unsafe program if you did not already know what it is doing.  If you want to be absolutely sure, send it to the AV company and ask them to verify it is not a false positive.

[Cablez]

So what your saying is with older versions of the hardware, newer firmware doesn't really bump performance any and doesn't seem to be worth the flash?

Well, that's not exactly what I said or would like to say. I would not say it so much in general like your consumption.
I used a SINGLE-SC in the 5xx serialnumber range, which I received ~2weeks ago. Flashing the standard 1.2.8 firmware into this single gave me a significant lower hashing rate than me already tuned 1.2.6 firmware. This was not soo much surprising for me. But after tuning the 1.2.8 firmware in nearly the same way I did it with the 1.2. 6 firmware, I still could not reach the hashing rate of my tuned 1.2.6 firmware. Maybe there are other ways to tune the 1.2.8 firmware to get better results. However, with the standard 1.2.8 firmware I could not see any improvement in hashing-rate over the standard 1.2.6 firmware with my single, which seems to have revision A chips.

Understood, Thanks.  I have an April version board but have not looked into flashing yet as there seems to be no benefit for me after potentially dropping money on an AVR dragon. There would need to be a gain for me to start messing around...for now.

[vitruvio]

Hi BTC-engineer,  good work you are doing with this stuff, I've got a Litle Single that Red_Wolf_2's software throw this data:

Code:

DEVICE: BitFORCE SC
FIRMWARE: 1.2.1
IAR Executed: NO
CHIP PARALLELIZATION: YES @ 8
QUEUE DEPTH:40
PROCESSOR 0: 15 engines @ 362 MHz -- MAP: FFFE
PROCESSOR 1: 15 engines @ 348 MHz -- MAP: FFFE
PROCESSOR 2: 14 engines @ 389 MHz -- MAP: FFEE
PROCESSOR 3: 15 engines @ 362 MHz -- MAP: FFFE
PROCESSOR 4: 15 engines @ 385 MHz -- MAP: FFFE
PROCESSOR 5: 14 engines @ 399 MHz -- MAP: FBFE
PROCESSOR 6: 14 engines @ 350 MHz -- MAP: FFEE
PROCESSOR 7: 15 engines @ 419 MHz -- MAP: FFFE
THEORETICAL MAX: 44072 MH/s
ENGINES: 117
FREQUENCY: 274 MHz
XLINK MODE: MASTER
CRITICAL TEMPERATURE: 0
XLINK PRESENT: NO
OK

After few reboots I get 116-118 engines, that gives me 31.5-32  GH/s, any improve if I update my firmware? seems to be quite old.

Regards

[kano]

Just an FYI - the cgminer API has always reported that in the stats command.

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

Sorry but my antivirus is unhappy with your software

Neither Symantec nor McAffee alert for this.  The likely reason yours does is that it is seeing the port-scan portion of the software which would indicate a potential unsafe program if you did not already know what it is doing.  If you want to be absolutely sure, send it to the AV company and ask them to verify it is not a false positive.

Well, as the author of the software I can guarantee there is no dropper in it. It may be detecting the reflection I used and the embedded wrapper DLL file for the FTDI drivers, but that shouldn't trigger a detection as a dropper... Send it through to the AV company, I'll privmsg you an email address to contact me with if you want too.

[vitruvio]

Well, as the author of the software I can guarantee there is no dropper in it. It may be detecting the reflection I used and the embedded wrapper DLL file for the FTDI drivers, but that shouldn't trigger a detection as a dropper... Send it through to the AV company, I'll privmsg you an email address to contact me with if you want too.

Indeed false positive

https://analysis.avira.com/en/status?uniqueid=gbsQSnjX5hY3ISq4jnUXLNW56pYPInVK&incidentid=1502551

Regards

[Red_Wolf_2]

New version is online, I've added some new checks to ensure the FTDI drivers are actually there before starting up (if they aren't, a warning is displayed then the program closes.)
Also added a slightly longer delay in the loop checking for new serial data, which might make it collect data a fraction slower, but should resolve the issue with no diagnostic information being displayed on slower machines.

Link below:
http://randomcontent.wolfnexus.net/RandomSite/files/9613/7838/3202/RW2-BFL-Commport-Scanner.zip

[Mobius]

Latest shipped SC60 Ser#13xx  has
DEVICE: BitFORCE SC0x0aFIRMWARE: 1.2.90x0aIAR

loaded, any source available?

[gurki]

Yesterday I've received the improved version of my single fan plates from production.


Here are some pictures of my singles with the new plates. Air is now flowing much easier.







It's easy to see the difference, when you directly compare it with the standard version.


A friend of mine has made them on his professional CNC-machine based on my design.
I've ask him if he would produce and ship them in very low volume too. And he agreed.

He would even produce them for order volume ONE.
He is thinking about a kit including:
2 x Improved fan plates
2 x fan grills
8 x screws

The plate is made fully compatible to the existing one (same backside profile).

Update: He is selling the sets now on www.bitmit.net
His account name is wowo and I can confirm that he is the official manufacture of my fan plate design.
Look on bitmit for 'FAN PLATE Set for BFL SINGLE'S'. I'm sure you will find it there.

It'd be nice to have a video that actually shows how much this improves the noise level and temp.

[johnyj]

Gentle typhoon 1850 rpm 120mm fan should be able to reduce the noise dramatically while keep almost the same static pressure and air flow

[Bicknellski]

Yesterday I've received the improved version of my single fan plates from production.


Here are some pictures of my singles with the new plates. Air is now flowing much easier.







It's easy to see the difference, when you directly compare it with the standard version.


A friend of mine has made them on his professional CNC-machine based on my design.
I've ask him if he would produce and ship them in very low volume too. And he agreed.

He would even produce them for order volume ONE.
He is thinking about a kit including:
2 x Improved fan plates
2 x fan grills
8 x screws

The plate is made fully compatible to the existing one (same backside profile).

Update: He is selling the sets now on www.bitmit.net
His account name is wowo and I can confirm that he is the official manufacture of my fan plate design.
Look on bitmit for 'FAN PLATE Set for BFL SINGLE'S'. I'm sure you will find it there.

It'd be nice to have a video that actually shows how much this improves the noise level and temp.

Need an air filter... that is going suck in the dust for sure.  https://www.bitcoinstore.com/accessories/air-filters.html

[BFL-Engineer]

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.

It turned out that the MOSFET zone usually gets to be the hottest region on the PCB. As a result we use our temperature sensors on board for sensing temperature, otherwise the on-die temperature diode
is fairly easy to read (Just check the voltage drop across the diode and you have the temperature).


Regards,
Nasser

[kano]

...
It'd be nice to have a video that actually shows how much this improves the noise level and temp.

Just taking the whole cover off on my 2 reduced the temp by 5C each
It initially dropped 7C on one but levelled out at 5C for both.

[nfowest]

watching

[eestimees]

...
It'd be nice to have a video that actually shows how much this improves the noise level and temp.

Just taking the whole cover off on my 2 reduced the temp by 5C each
It initially dropped 7C on one but levelled out at 5C for both.

temp dropped at the place where this sensor is, but what is the temp near the chip where big fan sucks air out? what is the temp underside of pcb ?