 Show Posts
|
|
Pages: « 1 2 3 4 [5]
|
Ok got that running. I can see identical configuration data being transmitted to both banks. RC7 matches RC4 and RC6 matches RC3. The configuration is a long sequence and I haven't found a way to see the nonce ranges that get sent to each bank yet. Going to look at this later when I get more time.
Edit
The nonce range data is loaded into both banks at the same time. The nonce data is identical between banks except for the MSBit and it is always zero for bank 1 and the MSBit is always one for bank 2.
Thanks for that. I've looked at the code, and found where the pins are selected. There is a define in klondike.h - DATA_ONE and DATA_ZERO. Both these are hex values, which when converted to bin are the ports which are connected to the ASICs. It's done in a way, that those pins are pulled down and high in pairs at both sides. So it's for sure now, that both sides are by default (even with latest firmware) working on same problem, thus only half of the speed and higher error rate. This also explains, why board with 4 chips has ER < 0.4% (when OCed to 350MHz) and board with 4 chips in each bank (8 chips in total) has around 4-5%, with same hashing speed as the first. Now the question is, which way to do this would be better: a) split the work to 16 nonce ranges, feed both sides with half of it one by one - so the whole board will be working on one problem. There would be some delay, because feeding twice the time, so maybe a slightly lower speed (we are talking here probably around 0.5% or so). b) make two separated work units 8 nonce ranges each, so both sides will be working on a different mathematical problem. I think, that the a) would be better, and I will start working on firmware mods to do it like this. About the b) option, I do not know, if there will be some mods also in CGM driver needed, but probably not. If anyone has any other opinion, let me know. EDIT About the feeding twice the time. This could be also done in parralel, but it's harder to code, so will do this one by one for now. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
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? |
|
|
|
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? |
|
|
|
Do you get any debug output or any error? How many K16 are you trying to connect and by which method are you connecting them?
kosta
Nope, even with -D option, no output at all. I'm connecting 2 K16. I just connect them to the usb, see them successfully enumerated in dmesg, then run CGM and it does nothing, just stays at the point where it says CGMiner version 3.3.1. With one it's OK. Also, each board have different serial number. |
|
|
|
Another problem I noticed, is that when I setup cgminer with the API options for K16, cgminer would have a Segmentation Fault when trying to access the API to get stats.
Has anyone else had SegFaults when trying to access the K16 API ?
kosta
Yes I just compiled and got a segmentation fault. I was assuming that it was due to a graphics driver issue, because my cgminer (with gpu) does the same thing, while my cgminer-nogpu does not do this when I compile it under Linux Mint 14. How do you get cgminer to compile with no gpu support, but with klondike support and icarus support? I wanna test Klondike compiled version actually runs, but I don't have a Klondike, so I want to compile it for icarus as well. I can't find the flags list anywhere (having a mental moment)... Hi guys, I've got cgminer compiled and it's working quite good on x64 and RPi. API working as well. Things I've done: Cloned repo here https://github.com/bkkcoins/cgminer-klondikeThen in the folder: ./automake.sh ./configure --disable-opencl --disable-adl --enable-klondike make Just one problem - when I connect more than one K16, it wont start, just freezes where it says CGMiner version ... With one it's hashing OK. Anyone had success with this? Thanks. |
|
|
|
Hi, compiled hex is here: http://www8.zippyshare.com/v/26199314/file.html. It's from the latest firmware from git. I do not have compiled cgminer-klondike for windows, so someone else will have to do that one. When you'll get the chance, please post how it goes in terms of hashing. Hi BkkCoins, I've got a full up K16 ready to test, but don't have the firmware (don't have a paid version of the compiler and already used up the demo). Could I please trouble you for a compiled hex file (if that's allowed) that I can pump into the unit to test. I didn't see one in the repo. I do have MPLAB and an ICD3. I've applied power to the board and no problems there. Cool project! I'm super stoked to get it running. See pic @ http://placedroid.com/blogs/news/8625479-place-droid-assembles-first-of-many-klondike-k16-bitcoin-mining-enginesThank-you !!! EDIT: Also just realized I may need a Windows binary of the modded cgminer. Can someone post one ? I don't have a linux box atm and will spin for days trying to get this stuff compiled. I'm rusty. Thx!! |
|
|
|
|
Hi,
great forum, lots of helpful info all around here. Love it.
|
|
|
|
|
