|
happydaze
|
 |
June 20, 2014, 02:50:07 PM |
|
I have them in ... :-(
OK 1 2 3
First:
i go to Seed Manager, and setup an New Config like "Zeus"
In this, i Put in, the Config data ..
Then i go to miner.. and set Start ?
Greetings..
Did you build from https://github.com/zeusminer/cgminer_zeus ? My build from there won't start either. |
|
|
|
|
|
|
|
|
|
The Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multi-signature transactions, etc. The current features of the client only hint at what will be possible in the future.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
kramble
|
|
June 20, 2014, 02:53:47 PM |
|
I'll run: --set zus0:ignore_golden_nonce=1 --set zus:freq=383 --set zus:cores=8 --set zus:chips=6 -S zus:\\.\COMxx
and see if any improvement after a couple of hours
Edit: I quit it again. Seems like it is running at stock frequencies. Could be my build.
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). |
|
|
|
deus75
Newbie
 Offline
Activity: 27
Merit: 0
|
|
June 20, 2014, 02:57:23 PM |
|
I have them in ... :-(
OK 1 2 3
First:
i go to Seed Manager, and setup an New Config like "Zeus"
In this, i Put in, the Config data ..
Then i go to miner.. and set Start ?
Greetings..
Did you build from https://github.com/zeusminer/cgminer_zeus ? My build from there won't start either. No i dont.. how can i use this ?? Under Linux ?? |
|
|
|
|
|
|
|
|
|
kramble
|
|
June 20, 2014, 04:07:01 PM |
|
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. |
|
|
|
|
nst6563 (OP)
|
|
June 20, 2014, 04:31:41 PM |
|
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?
|
|
|
|
|
|
kramble
|
|
June 20, 2014, 04:46:30 PM
Last edit: June 20, 2014, 05:01:15 PM by kramble |
|
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?
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. |
|
|
|
|
nst6563 (OP)
|
|
June 20, 2014, 05:22:21 PM |
|
I didn't see any explanation of what the "Mode" pins are either. Kind of an incomplete datasheet really.
|
|
|
|
|
|
ZiG
|
|
June 20, 2014, 05:55:25 PM |
|
I didn't see any explanation of what the "Mode" pins are either. Kind of an incomplete datasheet really.
Yeap...BARE MINIMUM INFO...not enough at all...  |
|
|
|
|
|
J4bberwock
|
|
June 20, 2014, 06:22:10 PM |
|
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?
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. 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. |
|
|
|
|
nst6563 (OP)
|
|
June 20, 2014, 06:27:48 PM |
|
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.
I obviously missed that...but it's still missing from the datasheet  |
|
|
|
|
|
J4bberwock
|
|
June 20, 2014, 06:42:19 PM |
|
"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
|
|
|
|
|
kramble
|
|
June 20, 2014, 06:53:12 PM |
|
"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
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. |
|
|
|
|
nst6563 (OP)
|
|
June 20, 2014, 07:35:37 PM |
|
"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
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. If they're anything like CPU's then they'll last WAY beyond their usefulness. |
|
|
|
|
|
ZiG
|
|
June 20, 2014, 08:22:07 PM |
|
"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
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. 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 |
|
|
|
|
|
J4bberwock
|
|
June 20, 2014, 08:24:13 PM |
|
"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
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. 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. |
|
|
|
|
kramble
|
|
June 20, 2014, 08:57:37 PM |
|
I've gone up to 2.06v on gridseed. and by the time they will blow, I think they won't be profitable anymore.
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). |
|
|
|
|
J4bberwock
|
|
June 20, 2014, 09:21:23 PM |
|
I've gone up to 2.06v on gridseed. and by the time they will blow, I think they won't be profitable anymore.
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). 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 |
|
|
|
|
|
|
