Topic: Fury/Blizzard tuning and mods - page 31. (Read 115281 times)

nwoolls & Luke-Jr BFGMiner for Windows build here: https://bitcointalksearch.org/topic/m.7427246
They'd probably like some feedback from testers.

1,598 kH/s poolside 24hr avg when I looked just now.  381 clock. So kh/s is getting very close to 0.7 * Freq on one Fury.  2nd one is not quite as fast & needs 4 more hrs for a clean 24hr run.

LongAndShort posted the Zeus Miner Requests For Terry doc https://bitcointalksearch.org/topic/m.7401931 and I read through it:  https://docs.google.com/document/d/19Vp6tG_INmcVtV4qo1Uhg9KzFm7VqjIKx95iGX9s58w/edit?pli=1  Question 11 indicates we should be able to get to 1,600 kH/s or a bit more.

you are right, don't trust the schematics, the crystal is 12Mhz.
So 16Mhz would be the one we need.
And you can find some on... my usb erupters.

I knew they will earn me some more money one day 


I still need to figure how and what to wire to the bpclock pins but the pins are so small and with no tracks linked I'd better go with a simple testboard design if we can get 1 or 2 sample chips

Yep, gotcha. I was being a bit nannyish I suppose. ZiG's comment was very helpful though, thanks!

Did you see the chip input clock speed in the datasheet, 12MHz. I think we were assuming 32MHz from the Blizzard schematics, and you were talking about using 42.2 MHz in this post. This probably needs a rethink if the blizzard schematic was a typo. The next step up from 115200 baud is 153600, which is a 33% increase, so a 16MHz crystal should do it (but will need a recompile of the windows executable, and I think won't work on linux).

I've gone up to 2.06v on gridseed. and by the time they will blow, I think they won't be profitable anymore.

Anyway, it's all related to power draw/kh
Pushing too hard gives less profit because it uses way more power.

I can confirm 7.5k resistor draws 80 watt at the wall on each Fury but will allow to overclock up to 381 clock
so around 15% overclock for double the power draw.
if we extrapolate gridseed results, 1.5 to 1.6v should be safe and could give an extra 15% in hashrate, but will probably draw over 100 watt at full load.

Professional Computer/Electronics engineer here...30+ years...

I have been ready to post this info back in the old Gridseed voltmod thread back in time, but got distracted too much by Wolfey2014 ads and BS...

...So listen carefully...:

Electronic devices are LIMITED by the underlying technology ...110...65...55.45..32..28nm is how THIN are the individual areas/traces, building the semiconductor's structure/device...

The MAJOR limitation is the DIELECTRIC (SiO2)...and how much Voltage it CAN sustain before breaking...or "start leaking" ...so call "leakage current"...electrons flying from one silicon area to the other...usually "Ground"... This "leakage" increases with temperature exponentially...

I have been looking under "electron microscope" at the 55nm structures...Do you know how thin is it...Like 100 atoms ONLY...that's it...

In summary...65/55nm Devices and Voltages...:

Nominal :   1.15 - 1.25V
Overclocking   :

Yellow Zone:   1.25 - 1.45V ...stable, with GOOD cooling...
Orange Zone:   1.45 - 1.60V ...stable, with IMPROVED cooling...
Red Zone:   1.60 - 1.75V ...still stable, with EXCELLENT cooling...
Black Zone:   1.80 and over ...NOT stable, risk of failing to operate...( and HW errorss ...)
Anihilation :   1.85 - 2.00 up   ...Chips are destroyed...structures are BURN permanently...

Now you got it... Experiment at your own risk, as usual...

Cheers...( Beer here)...

ZiG
  

If they're anything like CPU's then they'll last WAY beyond their usefulness. 

You do risk destroying the chips if you overvolt them. I don't know the absolute limits for the 55nm process (google has not been very helpful so far). Even if they work at a given voltage, the devices may degrade and die at some later time.

"Houston, we have had a problem", a crazy modder supplied the chips with 1.6v even if it's rated 1.32v max. He is even speaking of going up to 1.8v...
7.5k resistor should be the way to go for the actual clock cap. it gives 1.35v

I obviously missed that...but it's still missing from the datasheet 

Looks like it's time to get my hot air station on when the crystals arrive.
A new design would be better, but I think I'll be able to sort something out of the original board, at least as a proof of concept.I'll have a look at the datasheet when back on the computer.
Oh, and I already explained the use of the mode x to 9 pins. It seems they are used to give a "serial number" to the chips to be identified in the chain.

Yeap...BARE MINIMUM INFO...not enough at all...

I didn't see any explanation of what the "Mode" pins are either.  Kind of an incomplete datasheet really.

Yes, pad_bypass switches the internal hash clock source between the PLL output and the bpclk input pad. Eyeballing the layout masks on the schematic, it looks like these pads are unrouted, but it may be possible to make connection with them (depending on your SMT rework skills).

The problem with the PLL is telling it what multiply/divide ratio to use. Divide seems to be 8, but the configuration field only goes up to 255 so we are limited to 255/8 * 12MHz = 382.5MHz maximum. Unless there is some undocumented way of changing the divide ratio or supplying a higher multiplier (seems unlikely, but then there are those TEST pins; but even if it is possible, it's not going to be practical with the existing boards). I was hoping there might be something in the command protocol to allow a higher clock multiplier than 255 to be specified, but that's rather grasping at straws.

I don't suppose anyone has an adjustable clockgen to feed into the bpclk pin huh?

I hadn't had time yet to look at the schematics again to verify...but are the bpclk pins and pad_bypass centrally connected?


Also..according to the datasheet....the internal pll supports 62.5Mhz-1500Mhz....  Would that indicate that we could in fact blow past the 381Mhz 'limit' we're running into now?

Great, that's (almost) exactly what we were looking for (a little extra detail on TESTMODE/EN and MODESEL would have been nice, but I won't quibble).

One slight confusion is the 12MHz clock input, whereas the Blizzard schematic shows Y1 as 32M (though the X32A schematic shows 12M so perhaps that's a typo). It would be useful to measure the clock speed at the oscillator via a scope just to confirm this.

So it looks like we could bypass the clock input and clock directly via BPCLK while still retaining the 12MHz baud clock. The spec only says 200MHz though, which is a lot slower than I'd like, but perhaps this is just being conservative.

It still might be better to replace the 12MHz crystal with a slightly faster one and just up the baud rate in the driver to match, as pushing a 400MHz raw clock onto the chip seems unlikely to work very well.

FINALLY...:

Zeus CHIP SPECS...DATA SHEET...here...

https://mega.co.nz/#!t54SgYIR!_WzDmy7SuwVurOdWZUIRnNh93C3lSJ_6bUld-BJdlsM

( Link from http://zeusminer.com/shcematics/ ...at the bottom...)

Enjoy...

ZiG

Have you tried these builds: http://zeusminer.com/user-manual-ver-1-0/

No i dont.. how can i use this ??
Under Linux ??

That is exactly the behavior I'd expect if clock code 255 (383MHz) is simply being ignored by the ASIC (as in the verilog I linked a couple of posts above).