Quote from: padrino on February 23, 2014, 01:50:54 AM

Quote from: tolip_wen on February 23, 2014, 12:48:32 AM

Quote from: padrino on February 22, 2014, 06:41:53 PM

I might have overlooked something obvious but can someone tell me the math behind the HEX to MHz conversion, for example what is the equation that gets 211 equal to 850Mhz?

*approximate equation

take the first 2 digits the '21'
convert hex to decimal to get 33
multiply 33 x 25MHz and ya get 825MHZ
(add 25MHz to your answer)
The last digit is the divisor, it's 1 so we are done.

YMMV

Thanks for the details, that helps some but the use of a 5 on the end confuses it some.. I'm wrapping up a custom firmware that opens the frequency settings however I need to set the registers manually as KNC is disallowing it in their binary tool. I have it all working just trying to get a stragithforward, yet reliable equation to flip the MHz to the proper hex but it's not looking good yet.

EDIT What I originally posted below is/was an inprogress draft, forkin kbd went south

Just guessing...
5 does not compute, or does it?
What I had assumed was the ASIC only cares about the last 2 bits.

Code:

Hexadecimal Binary
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001
A 1010
B 1011
C 1100
D 1101
E 1110
F 1111

If this is a correct guess 1,5,9,D all have the same last 2 bits.

I did briefly hunt for a third bit functionality but did not persue it due to knowing there is a limit on the clock that is divided.
Divide by 1 has the most potential at the top end.
Divide by 2 if you think you can get 12.5MHz more out of it.

A 3rd bit might equate to another divide by 2.

850MHz would be 874 if the last bit can be zero
or maybe
850MHz would be 875 if the last bit needs to be set

It seems in practice the clock potential far exceeds the power/thermal potential so nobody has reported a clock failure as the limiting factor.

Standard parachute rigger 'Line of Sight Guarantee' applies!
No idea what the ASIC thinks just documented reverse engineering and pattern matching.

EDIT #2
One thing to keep in mind.
Not sure how it applies to 28nm but, the clock itself uses power and slower is often more efficient.
A div by one may leave more for the hash cores to consume from the budget.

YMMV