terrahash
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 86
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 04, 2013, 06:08:53 PM |
|
It is most likely a hardware bug in the circuit. During our testing we realized that the Dual NOR gates used in the design are too fast, and there needs to be some propagation delay. Using a cheap NOR gate chip from Fry's did the trick. We are still trying to see if this can be fixed in the firmware.
Maybe you may also want to try to use a bigger capacitor for the phase shifter in front of the NOR gate. A circuit should not depend on the propagation delays or fabrication tolerances of logic gates. I also tried to use the internal comparator of the PIC as a NOR gate, which is even better since it has some clock synchronization register. But it has shown that the comparator is not fast enough... Already tried using bigger capacitor. Does not work. The only work around we have found is using a slower gate, so far. I'm sorry to tell you, but you're wrong. I'm using v0.3.1 board with bigger cap (currently about 260pF) and it's hashing quite well. Without it, the clock signal is not delayed enough - just about 5ns and bad nonces are returned. BTW terrahash, what modifications did you made to the 4 chip firmware to hash with all 16 chips? You are using 260pF for C274 right? In order to hash with 16 chips, you need to make the following modifications in klondike.c, from line 159: Status.ChipCount = 16; // pre-calc nonce range values BankSize = (Status.ChipCount+1)/2; Status.MaxCount = WORK_TICKS / BankSize / 2; NonceRanges[0] = 0; for(BYTE x = 1; x < BankSize; x++) NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
|
|
|
|
ik2013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 04, 2013, 09:35:32 PM |
|
There is a LOT of FUD going around in Steamboats group buy thread about there being no fully populated and working K16 boards. Could anyone put that to rest, or otherwise spell out where we are at? I'd like to have a quote to take back there and put this to rest. Thanks.
|
|
|
|
flyonwall
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 250
Merit: 100
RockStable Token Inc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 04, 2013, 09:57:02 PM |
|
For those who are not cancelling, you have another option: condo ownership. Centerus will build Avalon clone systems for housing your chips, ten in each card ("condo unit"), up to 32 cards in every box. Your chips will be controlled from your own instance of cgminer running in the box. You can connect your condo unit to your mining pool account. The price for each condo unit has been drastically reduced to 0.9 BTC. More details here: https://bitcointalk.org/index.php?topic=189976.0Place your order here: http://centerus.com/products-page/condo/condo-unit/
|
|
|
|
zipiju
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 93
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 04, 2013, 10:06:29 PM |
|
It is most likely a hardware bug in the circuit. During our testing we realized that the Dual NOR gates used in the design are too fast, and there needs to be some propagation delay. Using a cheap NOR gate chip from Fry's did the trick. We are still trying to see if this can be fixed in the firmware.
Maybe you may also want to try to use a bigger capacitor for the phase shifter in front of the NOR gate. A circuit should not depend on the propagation delays or fabrication tolerances of logic gates. I also tried to use the internal comparator of the PIC as a NOR gate, which is even better since it has some clock synchronization register. But it has shown that the comparator is not fast enough... Already tried using bigger capacitor. Does not work. The only work around we have found is using a slower gate, so far. I'm sorry to tell you, but you're wrong. I'm using v0.3.1 board with bigger cap (currently about 260pF) and it's hashing quite well. Without it, the clock signal is not delayed enough - just about 5ns and bad nonces are returned. BTW terrahash, what modifications did you made to the 4 chip firmware to hash with all 16 chips? You are using 260pF for C274 right? In order to hash with 16 chips, you need to make the following modifications in klondike.c, from line 159: Status.ChipCount = 16; // pre-calc nonce range values BankSize = (Status.ChipCount+1)/2; Status.MaxCount = WORK_TICKS / BankSize / 2; NonceRanges[0] = 0; for(BYTE x = 1; x < BankSize; x++) NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
Yes thats correct. Thanks for the code, will try it out. BTW, have you tried connecting more than one K16 to CGM?
|
|
|
|
ScaryHash
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 05, 2013, 02:16:48 AM |
|
... 3 block erupter USB detected, but it's hashing really slow, like 100 Mh/s each. ...
Sigh, I spent a reasonable amount of time over more than a month resolving this (and commenting about it in the cgminer thread) It's a libusb bug (ckolivas also recently found another one ... in libusb ... and change the usbutils.c to work around it) The 100MH/s simply means the libusb you are using is no good. It's timeouts don't work You really do need to use current cgminer ... not an old version of it. Or ... the explanation I put in the README before ckolivas finally added the working libusb source to the cgminer source rather than linking against a system installed version. The manual fix (that I also did on Steamboats system just to check that wasn't the cause of problems there) https://github.com/ckolivas/cgminer/commit/d470828fb3681c0ebadea0d7cb0fab1bf465df46#READMEThank you Kano ! Really appreciate this man ! Again, I'm a Linux and compiling nOOb, so I'm learning as I go. Since I don't have a K16 (grrrr at idiots in charge of mismanaged chip company)..., I'm using USB erupters to try to iron out usb bugs...thanks a bunch again !! The klondike gethub has cgminer up to 3.3.1, I would have thought that was fairly new, but, I guess not ! Can I just get the new source code and replace the version 3.3.1 source file with the 3.4.0 one in the Klondike directory and compile it? Also, where to you add this line?? I don't understand this part... Now when you configure cgminer as listed further below in the build + instructions, for all the USB devices you must add libusb as follows: + LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev" where does this LIBUSB_CFLAGS command go?? I have no clue... Thank you.
|
|
|
|
kostagr33k
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 05, 2013, 02:54:05 AM |
|
That should go on the same line as the CFLAGS line, before the autogen.sh or ./configure.
Unfortunately you are stuck with the Klondike cgiminer version, as the latest version of cgminer has been changed enough to make the Klondike version obsolete.
Once the Klondike version if finalized, I believe cgminer will port Klondike specifics into their codebase.
|
|
|
|
terrahash
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 86
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 05, 2013, 04:39:51 AM |
|
It is most likely a hardware bug in the circuit. During our testing we realized that the Dual NOR gates used in the design are too fast, and there needs to be some propagation delay. Using a cheap NOR gate chip from Fry's did the trick. We are still trying to see if this can be fixed in the firmware.
Maybe you may also want to try to use a bigger capacitor for the phase shifter in front of the NOR gate. A circuit should not depend on the propagation delays or fabrication tolerances of logic gates. I also tried to use the internal comparator of the PIC as a NOR gate, which is even better since it has some clock synchronization register. But it has shown that the comparator is not fast enough... Already tried using bigger capacitor. Does not work. The only work around we have found is using a slower gate, so far. I'm sorry to tell you, but you're wrong. I'm using v0.3.1 board with bigger cap (currently about 260pF) and it's hashing quite well. Without it, the clock signal is not delayed enough - just about 5ns and bad nonces are returned. BTW terrahash, what modifications did you made to the 4 chip firmware to hash with all 16 chips? You are using 260pF for C274 right? In order to hash with 16 chips, you need to make the following modifications in klondike.c, from line 159: Status.ChipCount = 16; // pre-calc nonce range values BankSize = (Status.ChipCount+1)/2; Status.MaxCount = WORK_TICKS / BankSize / 2; NonceRanges[0] = 0; for(BYTE x = 1; x < BankSize; x++) NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
Yes thats correct. Thanks for the code, will try it out. BTW, have you tried connecting more than one K16 to CGM? I2C code is not working out of box. Thats exactly what we are working on right now.
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 05, 2013, 08:18:42 AM |
|
That should go on the same line as the CFLAGS line, before the autogen.sh or ./configure.
Unfortunately you are stuck with the Klondike cgiminer version, as the latest version of cgminer has been changed enough to make the Klondike version obsolete.
Once the Klondike version if finalized, I believe cgminer will port Klondike specifics into their codebase.
Yeah steamboat actually said at one stage he'd send me one so there'd be no problem supporting it in the master git soon. I've been working (a little) on it with him also. As for the CFLAGS - yeah just add both of those in front of CFLAGS like: LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev -lrt" CFLAGS="-g -W -Wall" ./autogen.sh --enable-klondikeand/or LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev -lrt" CFLAGS="-g -W -Wall" ./configure --enable-klondike(if the -lrt isn't needed on your linux, remove it)
|
|
|
|
terrahash
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 86
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 05, 2013, 08:44:34 AM |
|
Is the I2C code disabled right now? How to enable it?
|
|
|
|
zipiju
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 93
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 05, 2013, 11:09:00 AM |
|
There is a LOT of FUD going around in Steamboats group buy thread about there being no fully populated and working K16 boards. Could anyone put that to rest, or otherwise spell out where we are at? I'd like to have a quote to take back there and put this to rest. Thanks.
I do have a fully populated board v0.3.1 as of today, it's hashing fine with firmware set to 8 chips and with that cap near NOR replaced. Can do 350MHz per chip stable - around 2.8GH/s in total. BTW it's seems to be fine also with 220pF cap. Will have to do some fixing, since couple of pins on some of the chips are not properly connected and then will try 16 chip firmware and report back. But since the report lines from chips are shared between two banks, no problem should arise except from firmware issues. Is the I2C code disabled right now? How to enable it?
I don't know. Focussing on getting the full board working. About connecting two boards to CGM via USB. I found a workaround - running two CGMs with specified --usb option and with one board per CGM. Just run ./cgminer -n, it will list all usb devices. Then fe. ./cgminer --usb 1:25 for first board and ./cgminer --usb 1:24.
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 05, 2013, 12:00:53 PM |
|
Or you can just run ./cgminer --usb :1 Which means just grab the first USB mining device it can find and use that, and don't check hotplug unless that device disconnects.
|
|
|
|
zipiju
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 93
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 05, 2013, 12:55:38 PM |
|
Or you can just run ./cgminer --usb :1 Which means just grab the first USB mining device it can find and use that, and don't check hotplug unless that device disconnects.
Even better, thanks Kano.
|
|
|
|
Axion_Zen
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2013, 05:05:50 PM |
|
Bkk alive ?
|
|
|
|
zipiju
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 93
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2013, 06:49:34 PM |
|
Hi guys,
someone here do understand, where in firmware work is divided between two banks? As far as I understand, each K16 has two banks with 8 chips each. Each work is divided to 8 nonce ranges - each chip at one bank works on 1/8 of a work. So to use two banks, there has to be a rule, which selects where to send work data - on which pair of pins at PIC. I cannot find this. This part of the code is mainly assembler, and I don't understand most of it. There is a define which seems to define pins for both banks, but it isn't used anywhere in the code. I'm trying to get the firmware working with all 16 chips, but because of this, I'm not able to. I would ask Chris, but he wasn't here for the past couple of days.
Thanks.
|
|
|
|
fasmax
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2013, 07:01:42 PM |
|
While hardware is divided into 2 banks I don't think the work is divided into 2 banks. All 16 chips are on the same work. So each chip is assigned 1/16 of the total nonce range. So one bank would search 0x0 to 0x7fffffff the other bank would search 0x80000000 to 0xFFFFFFFF. At least that's how I think it works.
|
|
|
|
zipiju
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 93
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2013, 07:18:13 PM Last edit: September 06, 2013, 08:35:04 PM by zipiju |
|
While hardware is divided into 2 banks I don't think the work is divided into 2 banks. All 16 chips are on the same work. So each chip is assigned 1/16 of the total nonce range. So one bank would search 0x0 to 0x7fffffff the other bank would search 0x80000000 to 0xFFFFFFFF. At least that's how I think it works.
Yes this is also probable, but since in the code there are only 8 nonce ranges defined, I assumed that two banks = two works with 8 nonce ranges each. But that code could be just temporary stuff. Nevertheless, I need to know where the pins are selected (if they actually are at this firmware stage), so I can do more tests. Also, without this, it's really hard to debug if all the chips are properly soldered and are communicating.
|
|
|
|
fasmax
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2013, 07:36:27 PM |
|
Sorry I my expertise is hardware. I will try and look at the firmware thought. FYI the hardware connects all 16 chips together for reporting the returned nonce so I believe just one work for all 16 chips.
|
|
|
|
zipiju
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 93
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2013, 07:47:04 PM |
|
Sorry I my expertise is hardware. I will try and look at the firmware thought. FYI the hardware connects all 16 chips together for reporting the returned nonce so I believe just one work for all 16 chips.
Yes, there is only one shared bus for results from chips from both banks, but each bank has it's own config bus - so two config busses.
|
|
|
|
fasmax
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2013, 08:06:31 PM |
|
Sorry I my expertise is hardware. I will try and look at the firmware thought. FYI the hardware connects all 16 chips together for reporting the returned nonce so I believe just one work for all 16 chips.
Yes, there is only one shared bus for results from chips from both banks, but each bank has it's own config bus - so two config busses. True so it only takes 1/2 the time to configure all 16 chips since banks are loaded in parallel. I think source file asic.c holds the answer as to how this is done.
|
|
|
|
zipiju
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 93
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2013, 08:42:49 PM |
|
Sorry I my expertise is hardware. I will try and look at the firmware thought. FYI the hardware connects all 16 chips together for reporting the returned nonce so I believe just one work for all 16 chips.
Yes, there is only one shared bus for results from chips from both banks, but each bank has it's own config bus - so two config busses. True so it only takes 1/2 the time to configure all 16 chips since banks are loaded in parallel. I think source file asic.c holds the answer as to how this is done. Yes, thats correct. Someone who understand assembler and PICs could take a look at asic.c at function Send32() (around line 58) and find out, if there is some instruction, which selects between PORTC ports 4,3 and 6,7 and when is it done.
|
|
|
|
|