Bitcoin Forum
May 19, 2019, 07:55:38 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 [104] 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 ... 182 »
  Print  
Author Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary  (Read 434327 times)
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 07, 2013, 09:34:03 AM
 #2061

GREAT NEWS!

I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.

I tried several capacitor values for result capture and the 30pF works well up to about 360MHz. At 380MHz it's lost sync. I tried a brief run at 360 MHz and it worked ok. I need to get a fan working before I run extended tests at higher clocks.

I had to fiddle a lot with the work unit cycle timing. Seems I don't know what's going on because calculated times weren't right. By trial and error I adjusted it to get very few duplicates. I've also implemented code to only update clock cfg when it changes, not every work unit. But I haven't altered the result capture code yet - so even with no extra schmitt buffers and slow result code it's actually doing ok. At 300 MHz the result data comes out at 2.35 MHz.

Here's a pic of the result data at 300 MHz:



I'm just letting it run for a while at 300 to see how it holds up. Chips and heat sink get fairly hot to touch but I have just convection cooling for now. According to IR thermometer the heat sink is about 54C and the chip may be about 63C.

New Generation Antminer S17 Mining Plan Available Now! Highly Reduced Electricity Fee $0.067/T/DAY! Register To Experience
Free Mining Plan!
GET STARTED!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558252538
Hero Member
*
Offline Offline

Posts: 1558252538

View Profile Personal Message (Offline)

Ignore
1558252538
Reply with quote  #2

1558252538
Report to moderator
1558252538
Hero Member
*
Offline Offline

Posts: 1558252538

View Profile Personal Message (Offline)

Ignore
1558252538
Reply with quote  #2

1558252538
Report to moderator
Xian01
Legendary
*
Offline Offline

Activity: 1414
Merit: 1017


Christian Antkow


View Profile
July 07, 2013, 09:38:35 AM
 #2062

GREAT NEWS!
I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.

http://www.youtube.com/watch?v=2ORCnvGnaAM#t=1m22s
LaserHorse
Full Member
***
Offline Offline

Activity: 140
Merit: 100



View Profile
July 07, 2013, 09:40:47 AM
 #2063

EXCELLENCE!  I send you virtual internet high five!!!

PiMiner - control & monitor your miners with Raspberry Pi   •   BTC: 1AV5JekeEVET5u2jTsLDMRsTtagrBnNTBR
Foofighter
Hero Member
*****
Offline Offline

Activity: 868
Merit: 547


BTC Mining Hardware, Trading and more


View Profile WWW
July 07, 2013, 09:50:28 AM
 #2064

really great news, nice!

https://www.cryptouniverse.at - official Canaan Distributor
Check out our Mining Hardware shop in Europe: Shop
freeworm
Sr. Member
****
Offline Offline

Activity: 297
Merit: 250


View Profile
July 07, 2013, 09:54:10 AM
 #2065

It's so exciting! Thanks a lot for your great work!

I am working on a K16 board with one ASIC at U6. I am using the latest codes on your github.
ktest shows that it works very well. Every time I send a "W", it returns a GOOD nonce.
However, cgminer(3.3.1) doesn't work very well with it. Rarely a valid nonce is returned.
At most time, I cannot see any result("=") reply. It gives "work stale due to stratum job_id mismatch" and runs very slow.

It seems that the cgminer driver doesn't capture some results message from the PIC.
I don't know why but I am thinking maybe this is because cgminer is using a different USB library than the ktest.
If this is a typical issue, I appreciate if you can help when you have time. Otherwise, just ignore it. I will work it out by myself.



BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 07, 2013, 10:15:04 AM
Last edit: July 07, 2013, 10:34:54 AM by BkkCoins
 #2066

It's so exciting! Thanks a lot for your great work!

I am working on a K16 board with one ASIC at U6. I am using the latest codes on your github.
ktest shows that it works very well. Every time I send a "W", it returns a GOOD nonce.
However, cgminer(3.3.1) doesn't work very well with it. Rarely a valid nonce is returned.
At most time, I cannot see any result("=") reply. It gives "work stale due to stratum job_id mismatch" and runs very slow.

It seems that the cgminer driver doesn't capture some results message from the PIC.
I don't know why but I am thinking maybe this is because cgminer is using a different USB library than the ktest.
If this is a typical issue, I appreciate if you can help when you have time. Otherwise, just ignore it. I will work it out by myself.
I'll push my current changes in a minute. Be sure to use the latest. It should work ok now but also note that a mismatch between firmware and driver could cause problems as I change them both in sync here. Neither are stable that you can use one if the other changes. Not yet.

If ktest reports good nonces then usually right now the driver will also get them.

Note that my board has an extra NOR gate if you haven't kept up with my notes then you may need to change the edge it captures on; now rising edge.

jlsminingcorp
Hero Member
*****
Offline Offline

Activity: 495
Merit: 500


Hooray for non-equilibrium thermodynamics!


View Profile
July 07, 2013, 10:25:40 AM
 #2067

Awesome stuff, congratulations!

Bitcoin can only be understood backwards, but it must be lived forwards.
BitFury ASIC miner hosted group buy [DONE MINING]
BitCsByBit
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
July 07, 2013, 10:44:05 AM
 #2068

Awesome breakthrough BKKCoins!!!

Tipsy jar: 1HgfLMXiJQj9KZ7abLRh9rWuR7dgeSyub4
Enigma81
Full Member
***
Offline Offline

Activity: 178
Merit: 100



View Profile
July 07, 2013, 10:57:05 AM
 #2069

GREAT NEWS!

I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.

I tried several capacitor values for result capture and the 30pF works well up to about 360MHz. At 380MHz it's lost sync. I tried a brief run at 360 MHz and it worked ok. I need to get a fan working before I run extended tests at higher clocks.



I'm following, but not super closely.. Doing Result capture like this, are you using good capacitors (2, 5, at most 10%) or are you using standard +80%/-20% caps?  If you're having to tinker with values that much, then variance between the parts that people buy is going to be a real issue..

Add-On: I just looked.. the 30pF is a 5% part, so that's a plus.. I would still suggest buying a few of the same part number from different vendors (to guarantee you get samples from different manufacturing lots) and make sure the variance doesn't cause issues..

Enigma
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 07, 2013, 11:34:37 AM
 #2070

I'm following, but not super closely.. Doing Result capture like this, are you using good capacitors (2, 5, at most 10%) or are you using standard +80%/-20% caps?  If you're having to tinker with values that much, then variance between the parts that people buy is going to be a real issue..

Add-On: I just looked.. the 30pF is a 5% part, so that's a plus.. I would still suggest buying a few of the same part number from different vendors (to guarantee you get samples from different manufacturing lots) and make sure the variance doesn't cause issues..

Enigma
The different parts I've tried have been very different values. 30pF was my original design. But then when I had many capture errors I decided to try larger values like 100pF, 220pF and 330pF. At 128 MHz 220pF worked well. But then when I tried boosting to 256 or 300 MHz I couldn't get capture because the delays were too long and one bit ran into another. So I started lowering again and ended up back at 30pF. So if I had just started running at 256MHz with the original cap I would have avoided all this. I think it's silly to make the serial comm data rate dependent on the internal hash clock, especially when there's the input 32 MHz clock available. Maybe they had to pay by the flip flop for design and decided to save 32 of them.

I hope the BitFury chip has a more flexible design. Addressable registers using SPI like flash memory would be ideal. Then you just update the data you need for each work unit. Nonce ranges and operating parameters like clock cfg can be set once and left. Most current micro-controllers have hardware support for that.

Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
July 07, 2013, 12:00:25 PM
 #2071

I'm following, but not super closely.. Doing Result capture like this, are you using good capacitors (2, 5, at most 10%) or are you using standard +80%/-20% caps?  If you're having to tinker with values that much, then variance between the parts that people buy is going to be a real issue..

Add-On: I just looked.. the 30pF is a 5% part, so that's a plus.. I would still suggest buying a few of the same part number from different vendors (to guarantee you get samples from different manufacturing lots) and make sure the variance doesn't cause issues..

Enigma
The different parts I've tried have been very different values. 30pF was my original design. But then when I had many capture errors I decided to try larger values like 100pF, 220pF and 330pF. At 128 MHz 220pF worked well. But then when I tried boosting to 256 or 300 MHz I couldn't get capture because the delays were too long and one bit ran into another. So I started lowering again and ended up back at 30pF. So if I had just started running at 256MHz with the original cap I would have avoided all this. I think it's silly to make the serial comm data rate dependent on the internal hash clock, especially when there's the input 32 MHz clock available. Maybe they had to pay by the flip flop for design and decided to save 32 of them.

I hope the BitFury chip has a more flexible design. Addressable registers using SPI like flash memory would be ideal. Then you just update the data you need for each work unit. Nonce ranges and operating parameters like clock cfg can be set once and left. Most current micro-controllers have hardware support for that.


Bitfury.... drooooooool......

Hope you rest in between sets and work BKKCoins. Keep fresh!

Dogie trust abuse, spam, bullying, conspiracy posts & insults to forum members. Ask the mods or admins to move Dogie's spam or off topic stalking posts to the link above.
fasmax
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
July 07, 2013, 01:27:55 PM
 #2072

This is great news!
Thanks BkkCoins almost time to place more ASIS's  Smiley.
Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
July 07, 2013, 02:48:54 PM
 #2073

GREAT NEWS!

I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.

I tried several capacitor values for result capture and the 30pF works well up to about 360MHz. At 380MHz it's lost sync. I tried a brief run at 360 MHz and it worked ok. I need to get a fan working before I run extended tests at higher clocks.

I had to fiddle a lot with the work unit cycle timing. Seems I don't know what's going on because calculated times weren't right. By trial and error I adjusted it to get very few duplicates. I've also implemented code to only update clock cfg when it changes, not every work unit. But I haven't altered the result capture code yet - so even with no extra schmitt buffers and slow result code it's actually doing ok. At 300 MHz the result data comes out at 2.35 MHz.

Here's a pic of the result data at 300 MHz:

(removed we saw further up there didn't we?)

I'm just letting it run for a while at 300 to see how it holds up. Chips and heat sink get fairly hot to touch but I have just convection cooling for now. According to IR thermometer the heat sink is about 54C and the chip may be about 63C.

YOU ARE MY HERO!!!!!!!!!!!!

Dogie trust abuse, spam, bullying, conspiracy posts & insults to forum members. Ask the mods or admins to move Dogie's spam or off topic stalking posts to the link above.
Bluestreak66
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
July 07, 2013, 02:59:19 PM
 #2074

I hope the BitFury chip has a more flexible design. Addressable registers using SPI like flash memory would be ideal. Then you just update the data you need for each work unit. Nonce ranges and operating parameters like clock cfg can be set once and left. Most current micro-controllers have hardware support for that.

Not to sidetrack this thead but has anyone seen any datasheet on the BitFury chips? I seen they were for sale but no real data sheet on them as of yet. Good to see your hashing at full speed. I know a lot of people following this are set on overclocking. I wonder if there could be a way to get a larger range than just 60Mhz of signal capture other than just replacing the cap depending on your desired frequency?
Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
July 07, 2013, 03:09:29 PM
 #2075

That is a sidetrack. Start a new thread about the bitfury.

Dogie trust abuse, spam, bullying, conspiracy posts & insults to forum members. Ask the mods or admins to move Dogie's spam or off topic stalking posts to the link above.
Bluestreak66
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
July 07, 2013, 03:14:26 PM
 #2076

That is a sidetrack. Start a new thread about the bitfury.

Bkk brought it up not me Cheesy I'm trying to remember what was the reason for delaying the signal? I haven't looked into the communication protocol too much I just glanced over it. Is the plan to use two nor gates on the final design? I haven't looked at any of the updated files I may do that now.
Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
July 07, 2013, 03:32:59 PM
 #2077

That is a sidetrack. Start a new thread about the bitfury.

Bkk brought it up not me Cheesy I'm trying to remember what was the reason for delaying the signal? I haven't looked into the communication protocol too much I just glanced over it. Is the plan to use two nor gates on the final design? I haven't looked at any of the updated files I may do that now.

Tongue

I know.

Damn him still drooling.

I am more interested in what hub I can bundle with a Raspberry Pi and still overclock the K1 Nanos what is possible because I have giant tub of mineral oil, a pretty heat exchanger, cooling tower and some pumps and a beautiful baby blue fiberglass tank I want to dunk them in.

Dogie trust abuse, spam, bullying, conspiracy posts & insults to forum members. Ask the mods or admins to move Dogie's spam or off topic stalking posts to the link above.
Fishbones
Full Member
***
Offline Offline

Activity: 122
Merit: 100


View Profile
July 07, 2013, 03:41:02 PM
 #2078

This is great news!
Thanks BkkCoins almost time to place more ASIC's  Smiley.
^^FTFY;

Yes, I say populate the whole board, use original design component values and let it rip hash  Grin
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 07, 2013, 03:46:14 PM
 #2079

I wonder if there could be a way to get a larger range than just 60Mhz of signal capture other than just replacing the cap depending on your desired frequency?
Most likely I'll add an extra Schmitt trigger on each line and use the smallest cap that will work once the edges are fast. It only needs > 10nS so that shouldn't be too hard. If that works then it will depend more on software handling of result data as to limits.  I already have in mind how I'll speed that up so that it can handle UART data but there is a limit. Basically, once a byte is received by the UART there is 5 uS to deal with it and at that point it cannot let go until all 4 bytes are stored. So other functions will need to co-operate by reducing their ISR footprint.

I'm trying to remember what was the reason for delaying the signal? I haven't looked into the communication protocol too much I just glanced over it. Is the plan to use two nor gates on the final design? I haven't looked at any of the updated files I may do that now.
It's because there is no clock signal from the ASIC, but the clock is implicit in the data. So to allow a UART to capture it rather than using a CPLD or FPGA I use a single gate to extract the clock. The delay is so the PIC has enough setup time between the clock and data. Ultimately a CPLD would allow capturing at higher rates and then the PIC could clock the data in as slow as it needs. A more complicated capture could be designed in a CPLD but then we also have another device that needs programming, and you get into another programming tool and using the HDL environment etc. So I was trying to keep it simple as there's already enough to do.

I am more interested in what hub I can bundle with a Raspberry Pi and still overclock the K1 Nanos what is possible because I have giant tub of mineral oil, a pretty heat exchanger, cooling tower and some pumps and a beautiful baby blue fiberglass tank I want to dunk them in.
Most of the hubs on the market are junky but someone did post a good robust one back up the thread a ways. I can't run both the K and the Erupter on the hub I have even with a decent adapter wattage. It seems to limit use even when the K doesn't draw power because the Erupter is using a full load. On my notebook they can both run together.

Yes, I say populate the whole board, use original design component values and let it rip hash  Grin
Hope to add some more pretty quick. I need the hash now I turned off my GPUs (which is good as it frees up the ATX PSU for this). But not tonight as I stayed up all last night and it wiped me out. So going to bed soon.



Lollaskates
Sr. Member
****
Offline Offline

Activity: 249
Merit: 250


View Profile
July 07, 2013, 03:47:37 PM
 #2080

That is a sidetrack. Start a new thread about the bitfury.

Bkk brought it up not me Cheesy I'm trying to remember what was the reason for delaying the signal? I haven't looked into the communication protocol too much I just glanced over it. Is the plan to use two nor gates on the final design? I haven't looked at any of the updated files I may do that now.

Tongue

I know.

Damn him still drooling.

I am more interested in what hub I can bundle with a Raspberry Pi and still overclock the K1 Nanos what is possible because I have giant tub of mineral oil, a pretty heat exchanger, cooling tower and some pumps and a beautiful baby blue fiberglass tank I want to dunk them in.

Yeah did you end up posting that complete mineral oil solution you've got there in that other thread? I'm interested in knowing the parts I'd need.

Also, I plan on putting together a guide on turning the RPI into a miner host, with the added bonus of a $20 RGB 128x64px LCD for monitoring, with keypad. Its Gonna be a fun project while I wait for this board to finish Smiley
Pages: « 1 ... 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 [104] 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 ... 182 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!