Pages:
Author

Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 32. (Read 435369 times)

member
Activity: 93
Merit: 10
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?

To clarify on this, it would be a 16 chip Klondike at 282*16 (4.5GH as Advertised) with low HW Errors.

Also if whoever did this, did so using Terrahash's code.


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];

If you look at that code, you see, that only 8 nonce ranges are defined.
How could this work with 16 chips? Any idea?
Also, the NonceRanges were defined as NonceRanges[8].
And for everyone here, fully populated board with 16 chips IS NOT WORKING with those firmware modifications that Terrahash posted above.

Look at asic.c especially in SendAsicData function. You will get your answer there and in the end of send32 function. But it is a bit tricky how its done there... In fact you only need 8 nonce ranges

What are you implying Tongue

The question is: Does it work?

I can find NO ONE that can get the K16 to work.

Okay so i will clarify this:

This code
Code:
   NonceRanges[0] = 0;
    for(BYTE x = 1; x < BankSize; x++)
        NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
generates the following nonce ranges for 8 chips (in hex):
Code:
Nonce[0]:00000000
Nonce[1]:10000000
Nonce[2]:20000000
Nonce[3]:30000000
Nonce[4]:40000000
Nonce[5]:50000000
Nonce[6]:60000000
Nonce[7]:70000000
Then in SendAsicData you see:
Code:
last_bit0 = last_bit1 = split;
 send32_data = (WORD)&NonceRanges; send32_count = BankSize;
 Send32();
and in Send32:
Code:
   MOVF _last_bit0 & 0x7F,W
    CLRF LATC & 0x7F
    BTFSC INDF1,7
    MOVF _last_bit1 & 0x7F,W
    MOVWF LATC & 0x7F
This changes the highest bit in nonce value to 1 and then you get the remaining 8 nonces.




And between those instructions, is there a one, which changes what PORTC pins to use, when sending data out? Except the DATA_ONE and DATA_ZERO defines?
member
Activity: 66
Merit: 10
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?

To clarify on this, it would be a 16 chip Klondike at 282*16 (4.5GH as Advertised) with low HW Errors.

Also if whoever did this, did so using Terrahash's code.


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];

If you look at that code, you see, that only 8 nonce ranges are defined.
How could this work with 16 chips? Any idea?
Also, the NonceRanges were defined as NonceRanges[8].
And for everyone here, fully populated board with 16 chips IS NOT WORKING with those firmware modifications that Terrahash posted above.

Look at asic.c especially in SendAsicData function. You will get your answer there and in the end of send32 function. But it is a bit tricky how its done there... In fact you only need 8 nonce ranges

What are you implying Tongue

The question is: Does it work?

I can find NO ONE that can get the K16 to work.

Okay so i will clarify this:

This code
Code:
   NonceRanges[0] = 0;
    for(BYTE x = 1; x < BankSize; x++)
        NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
generates the following nonce ranges for 8 chips (in hex):
Code:
Nonce[0]:00000000
Nonce[1]:10000000
Nonce[2]:20000000
Nonce[3]:30000000
Nonce[4]:40000000
Nonce[5]:50000000
Nonce[6]:60000000
Nonce[7]:70000000
Then in SendAsicData you see:
Code:
last_bit0 = last_bit1 = split;
 send32_data = (WORD)&NonceRanges; send32_count = BankSize;
 Send32();
and in Send32:
Code:
   MOVF _last_bit0 & 0x7F,W
    CLRF LATC & 0x7F
    BTFSC INDF1,7
    MOVF _last_bit1 & 0x7F,W
    MOVWF LATC & 0x7F
This changes the highest bit in nonce value to 1 and then you get the remaining 8 nonces.


sr. member
Activity: 1316
Merit: 254
Sugars.zone | DatingFi - Earn for Posting


 I'd love to get my hands dirty in this project.  I can work well with firmware and deadlines. I have Avalon Chips I just need a board minus chips or a finished bricked board.  Send one with power problems.  This project needs some fresh eyes.  I'd work we would win and I'd somehow manage to get more beer and waffles in my fridge.



I have a K16 board and PIC chip on order with BkkCoins. I'm not sure what his shipping schedule is though. If we could get him to ship that to you priority, and if you have the rest of the BOM, I'd consider letting you have a go at it.

I have an unpopulated K16 Bkk Sent me. If it is required PM me.
full member
Activity: 143
Merit: 100
So sexy, it hurts.
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?

To clarify on this, it would be a 16 chip Klondike at 282*16 (4.5GH as Advertised) with low HW Errors.

Also if whoever did this, did so using Terrahash's code.


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];

If you look at that code, you see, that only 8 nonce ranges are defined.
How could this work with 16 chips? Any idea?
Also, the NonceRanges were defined as NonceRanges[8].
And for everyone here, fully populated board with 16 chips IS NOT WORKING with those firmware modifications that Terrahash posted above.

Look at asic.c especially in SendAsicData function. You will get your answer there and in the end of send32 function. But it is a bit tricky how its done there... In fact you only need 8 nonce ranges

What are you implying Tongue

The question is: Does it work?

I can find NO ONE that can get the K16 to work.
member
Activity: 66
Merit: 10
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?

To clarify on this, it would be a 16 chip Klondike at 282*16 (4.5GH as Advertised) with low HW Errors.

Also if whoever did this, did so using Terrahash's code.


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];

If you look at that code, you see, that only 8 nonce ranges are defined.
How could this work with 16 chips? Any idea?
Also, the NonceRanges were defined as NonceRanges[8].
And for everyone here, fully populated board with 16 chips IS NOT WORKING with those firmware modifications that Terrahash posted above.

Look at asic.c especially in SendAsicData function. You will get your answer there and in the end of send32 function. But it is a bit tricky how its done there... In fact you only need 8 nonce ranges
sr. member
Activity: 392
Merit: 250
♫ A wave came crashing like a fist to the jaw ♫
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?

To clarify on this, it would be a 16 chip Klondike at 282*16 (4.5GH as Advertised) with low HW Errors.

Also if whoever did this, did so using Terrahash's code.


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];

If you look at that code, you see, that only 8 nonce ranges are defined.
How could this work with 16 chips? Any idea?
Also, the NonceRanges were defined as NonceRanges[8].
And for everyone here, fully populated board with 16 chips IS NOT WORKING with those firmware modifications that Terrahash posted above.

Thanks jipiju
member
Activity: 93
Merit: 10
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?

To clarify on this, it would be a 16 chip Klondike at 282*16 (4.5GH as Advertised) with low HW Errors.

Also if whoever did this, did so using Terrahash's code.


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];

If you look at that code, you see, that only 8 nonce ranges are defined.
How could this work with 16 chips? Any idea?
Also, the NonceRanges were defined as NonceRanges[8].
And for everyone here, fully populated board with 16 chips IS NOT WORKING with those firmware modifications that Terrahash posted above.
sr. member
Activity: 392
Merit: 250
♫ A wave came crashing like a fist to the jaw ♫
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?
legendary
Activity: 924
Merit: 1000
Think. Positive. Thoughts.
I think most agree now that developing (or relying/depending on) for Avalon will be disappointing.

So, 4 chip boards work flawlessly, 8 chip boards work as well, but 12-chip and 16-chip boards are not fully functional, correct?

What are the best 8-chip board speed/hash results? 350MHz, 450?
member
Activity: 66
Merit: 10
About the ROI, it really is gone now, but you have to take into account, that BTC price will likely go up, so even if you lose now, you can gain later. Especially if you've already made an investment in the HW, chips etc.

An investment that doesn't earn back its principal is called a loss.

And about changing the HW for next gen Avalon chips (or any other chips), who is going to make this? Bkk seems to be gone (probably get sick of all the events regarding chips delivery, companies taking advantage of opensource project and giving nothing back) and there seems to be noone (even in the group of those companies, which started their business on this) who is able to make this change.

That's a great question! I don't have the answer, but I'd love to get some discussion going and find out.

My older project which is to be found here : https://bitcointalksearch.org/topic/diy-pcb-project-dynamine-d20-276728
is based on klondike original but with some major modifications. I think it is also capable of using Avalon Gen2 chips. The main problem is that such a development is very costly and you get nothing back from it. Noone pays the development equipment nor the hundreds of hours for the project. The problem is also that there a newer chips available before the old ones are shipped. This was the case with Avalon Gen1. So such a development ist mostly not worth its time.
full member
Activity: 378
Merit: 100
While testing my prototype, I found a solution to the fan circuit. The problem I found was that I couldn't drive the fan and that every time the fan is plugged in, the PIC resets.

I changed R23, the pullup to VCC, to a 10K and the series resistor, R22, to a 49.9K.
newbie
Activity: 58
Merit: 0
About the ROI, it really is gone now, but you have to take into account, that BTC price will likely go up, so even if you lose now, you can gain later. Especially if you've already made an investment in the HW, chips etc.

An investment that doesn't earn back its principal is called a loss.

And about changing the HW for next gen Avalon chips (or any other chips), who is going to make this? Bkk seems to be gone (probably get sick of all the events regarding chips delivery, companies taking advantage of opensource project and giving nothing back) and there seems to be noone (even in the group of those companies, which started their business on this) who is able to make this change.

That's a great question! I don't have the answer, but I'd love to get some discussion going and find out.
hero member
Activity: 924
Merit: 1000
Nice to know gen 2 may be backwards compatible. I have reels of parts that may get some use yet.
sr. member
Activity: 378
Merit: 250
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];
They said here how they got it working with 16 chips..?
I tested this by programing a PIC chip with this change.
After looking at the signals with a storage scope I believe it does send the correct nonce values to all 16 ASIC's. with no ranges duplicated.
So if you have all 16 chips installed this should fix the duplicated nonce ranges.
hero member
Activity: 529
Merit: 501
If Avalon ever ships we'll have a lot of assembled K16s and the firmware will get sorted out quickly.  I'll even dust off my PICkit 3 and MPLAB if I have to.

Well, they hash, but at a reduced rate. We could still be debugging and hashing. Not ideal, but better than nothing.
sr. member
Activity: 336
Merit: 250
♫ the AM bear who cares ♫
Per Avalon gen2 55nm will be completely backwards compatible. We may see ROI. Assuming specs are 3x as fast it'll be close.

At this point I'd be more concerned about power efficiency.  Avalon Gen 1 is awful.
cp1
hero member
Activity: 616
Merit: 500
Stop using branwallets
If Avalon ever ships we'll have a lot of assembled K16s and the firmware will get sorted out quickly.  I'll even dust off my PICkit 3 and MPLAB if I have to.
hero member
Activity: 843
Merit: 608
Per Avalon gen2 55nm will be completely backwards compatible. We may see ROI. Assuming specs are 3x as fast it'll be close.
hero member
Activity: 529
Merit: 501
I don't think everyone needs to.abandon.  For the sake of community development. I'd say we finish the project.  If a handful exist  that's okay. I understand people are MIA as well as nerve racked.  That is why I believe wr need fresh hands and eyes on this project.  

Absolutely! I'm not advocating we abandon the project. But there's no point in continuing the design using first-generation Avalon chips. They are obsolete. At this point, with an assembled board in hand, if you mine forever, you will not make back the cost of the miner. However, we can retarget for a different chip and, at the very least, break even.

The design is fully functional, the only thing that needs to be finished is firmware.
I have two boards hashing with only one side (with 8 chips) at about 3Ghps, ~3% ER (without USB ferrite beads), chips overclocked to 375MHz with no overvolt. Other side on each board has few chips that do not respond, but this is because those chips were poorly soldered. And on every board it's different side. Tried to fix it yesterday, but was unsuccessful, and now waiting for solder wick and isopropylalcohol.
I've also tried some modifications in firmware for 16 chips, but it wasn't really usable. The board with that did hash faster, but had around 20% ER - which is a firmware and poorly assembled chips problem, not the design one. Now waiting with this until I fix the other side, then will continue working on FW.
Tried also to contact one of the companies, that claimed to have fully working board (with firmware that hash with all 16 chips), but they did not respond. Anyone here can guess why.
About the ROI, it really is gone now, but you have to take into account, that BTC price will likely go up, so even if you lose now, you can gain later. Especially if you've already made an investment in the HW, chips etc.

Edit:
And about changing the HW for next gen Avalon chips (or any other chips), who is going to make this? Bkk seems to be gone (probably get sick of all the events regarding chips delivery, companies taking advantage of opensource project and giving nothing back) and there is noone (even in the group of those companies, which started their business on this) who is able to make this change.

Is it not possible for you guys to use TerraHash's stuff? They said they have working k16's with less than 1% error rates.

What Terrahash stuff? They have used stuff that Bkk made as opensource. To be absolutely clear on this, I've wrote to them about mine board with 4 chips assembled hashing at 400MHz with around 0.6% ER, when they were asking me via PM about the changes in HW I made to get it working. They were not able to fix even this for the whole time. They claimed even here on this forum, that the design is wrong.
Later, when they did claimed at 5th of September, that they do have a working board, and the only issue there is I2C, I've wrote them again, asking what firmware changes do they made to hash with all 16 chips and that low error rate.
They didn't even bother to wrote me back.
So what do they actually have? Nothing? Lies?

Zipiju, I think you're doing a great job and a service to the community.

Unfortunately, it's been a LONG time since I've done any assembly/firmware type programming, so I'm totally sort of out of touch with that aspect of it.

But, I'm sure whatever you decide will be a much better solution than what we have now. If you need anything, beer, movie tickets, cheap hookers, lemme know and I'll see what I can do.

See if you can get in touch with Steamboat, he is also working on assembly for a group buy, which of course has been delayed. But, I think he has a machine assembled K16 miner which should have better soldering consistency.

Pls post a donation address. Wink
sr. member
Activity: 574
Merit: 250
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];
They said here how they got it working with 16 chips..?

Yeah the only issue there is, that it's not working and it even can't work with that.
The firmware, in it's early stages, were programmed to send same configuration data to both banks. So you had all 16 chips doing something, the only problem was, that both banks were solving the same problem. So you have higher error rate because of the collisions, and only half of the speed.
So changing the nonce range with the code above isn't going to help here.
And I've asked them again (after that), if they did changed anything else, and got no response.
And the response above I only get because they wanted to know from me, what changes I've made in HW to get it working.

Is it alright that I PM you?
Pages:
Jump to: