I have a DIP version of the PIC chip, later tonight or tomorrow I will program it with the released firmware and run CGM on it.
Then I will try and look at the nonce data the is suppose to be sent to the ASIC's and report back what I saw.
Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 34. (Read 435369 times)
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.
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.
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.
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.
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.
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.
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.
FYI the hardware connects all 16 chips together for reporting the returned nonce so I believe just one work for all 16 chips.
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.
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.
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.
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.
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.
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.
Bkk alive ?
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.
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.
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.
Which means just grab the first USB mining device it can find and use that, and don't check hotplug unless that device disconnects.
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.
Is the I2C code disabled right now? How to enable it?
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.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.
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-klondike
and/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)
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:
Code:
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.
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.
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.
...
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)3 block erupter USB detected, but it's hashing really slow, like 100 Mh/s each.
...
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#README
Thank 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.
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:
Code:
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?
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://bitcointalksearch.org/topic/condo-for-your-avalon-chips-price-drastically-reduced-189976
Place your order here:
http://centerus.com/products-page/condo/condo-unit/
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://bitcointalksearch.org/topic/condo-for-your-avalon-chips-price-drastically-reduced-189976
Place your order here:
http://centerus.com/products-page/condo/condo-unit/
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.
Jump to: