Bitcoin Forum
June 16, 2019, 12:05:38 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 [51] 52 53 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 ... 182 »
  Print  
Author Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary  (Read 434691 times)
SebastianJu
Legendary
*
Offline Offline

Activity: 2394
Merit: 1035


Legendary Escrow Service - Tip Jar in Profile


View Profile WWW
May 25, 2013, 10:59:36 AM
 #1001

Hi all
Heat power of chips is 1'7-1'8W each one?

Next week I will do some test with 2W simulation with different profiles.
That's about right. I would use 2W as safer value.

Avalon reported power as 6.6W/GH @ 282MH/s that's 1.86 each but many people will want to overclock to 300 and it should be considered baseline for testing. I don't know if it's actually linear but,

300/282*1.86 = 1.98W

Is the 300 MHz a border somehow? I read in the avalon miner threads that overclocking to that value is possible only. I thought its because of the avalon miner design. But is it a chip-restriction?

Please ALWAYS contact me through bitcointalk pm before sending someone coins.
1560686738
Hero Member
*
Offline Offline

Posts: 1560686738

View Profile Personal Message (Offline)

Ignore
1560686738
Reply with quote  #2

1560686738
Report to moderator
1560686738
Hero Member
*
Offline Offline

Posts: 1560686738

View Profile Personal Message (Offline)

Ignore
1560686738
Reply with quote  #2

1560686738
Report to moderator
1560686738
Hero Member
*
Offline Offline

Posts: 1560686738

View Profile Personal Message (Offline)

Ignore
1560686738
Reply with quote  #2

1560686738
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1560686738
Hero Member
*
Offline Offline

Posts: 1560686738

View Profile Personal Message (Offline)

Ignore
1560686738
Reply with quote  #2

1560686738
Report to moderator
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 25, 2013, 11:08:55 AM
 #1002

Is the 300 MHz a border somehow? I read in the avalon miner threads that overclocking to that value is possible only. I thought its because of the avalon miner design. But is it a chip-restriction?
It doesn't appear to be a restriction. According to the docs with a 32MHz clock it should be able to be set up to 450 MHz. I doubt it would hash at that speed but the PLL allows legal values that high.

People who want to test water blocks and such will no doubt have fun seeing how high it can actually go before meltdown. But there is a limit to what the 1.2V supply can handle safely, and I'd guess it's not much above 300 now.

SebastianJu
Legendary
*
Offline Offline

Activity: 2394
Merit: 1035


Legendary Escrow Service - Tip Jar in Profile


View Profile WWW
May 25, 2013, 12:07:36 PM
 #1003

Is the 300 MHz a border somehow? I read in the avalon miner threads that overclocking to that value is possible only. I thought its because of the avalon miner design. But is it a chip-restriction?
It doesn't appear to be a restriction. According to the docs with a 32MHz clock it should be able to be set up to 450 MHz. I doubt it would hash at that speed but the PLL allows legal values that high.

People who want to test water blocks and such will no doubt have fun seeing how high it can actually go before meltdown. But there is a limit to what the 1.2V supply can handle safely, and I'd guess it's not much above 300 now.

Ok, thanks... i guess heat will not spread too high only from overclocking without highervolting so i think i would try overclocking too. Normally i overclock and downvolt my gpus to lengthen their lifetime while rising speed... maybe thats possible for the miner too..

Please ALWAYS contact me through bitcointalk pm before sending someone coins.
kano
Legendary
*
Offline Offline

Activity: 2842
Merit: 1172


Linux since 1997 RedHat 4


View Profile
May 25, 2013, 12:57:27 PM
 #1004

Is the 300 MHz a border somehow? I read in the avalon miner threads that overclocking to that value is possible only. I thought its because of the avalon miner design. But is it a chip-restriction?
It doesn't appear to be a restriction. According to the docs with a 32MHz clock it should be able to be set up to 450 MHz. I doubt it would hash at that speed but the PLL allows legal values that high.

People who want to test water blocks and such will no doubt have fun seeing how high it can actually go before meltdown. But there is a limit to what the 1.2V supply can handle safely, and I'd guess it's not much above 300 now.

Ok, thanks... i guess heat will not spread too high only from overclocking without highervolting so i think i would try overclocking too. Normally i overclock and downvolt my gpus to lengthen their lifetime while rising speed... maybe thats possible for the miner too..
With a GPU you are downvolting that which has little effect on performance.
There's no similarity here.
(or you could compare it to scrypt mining where that downvolting has a clear negative effect)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
0xFE
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
May 25, 2013, 01:08:21 PM
 #1005

Regarding the scope - it is for sure important tool to have, but you might want to consider buying a logic analyzer, which is way more useful when troubleshooting digital communication. 125 ns in the Avalon protocol translates to 8 MHz, there are 100 MHz (*) logic analyzers available for about $300 (or less expensive clones on eBay), with virtually unlimited sample memory, because they use the PC (over USB).

(*) Sample 2 channels at 100 MHz, 4 channels at 50 MHz etc.


And question about the NOR gate used for the clock signal: does it have Schmitt trigger inputs?
Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
May 25, 2013, 01:13:04 PM
 #1006

Is the 300 MHz a border somehow? I read in the avalon miner threads that overclocking to that value is possible only. I thought its because of the avalon miner design. But is it a chip-restriction?
It doesn't appear to be a restriction. According to the docs with a 32MHz clock it should be able to be set up to 450 MHz. I doubt it would hash at that speed but the PLL allows legal values that high.

People who want to test water blocks and such will no doubt have fun seeing how high it can actually go before meltdown. But there is a limit to what the 1.2V supply can handle safely, and I'd guess it's not much above 300 now.

Can we get more power Scotty, aka BKKCoins?


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.
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 25, 2013, 01:52:25 PM
 #1007

Regarding the scope - it is for sure important tool to have, but you might want to consider buying a logic analyzer, which is way more useful when troubleshooting digital communication. 125 ns in the Avalon protocol translates to 8 MHz, there are 100 MHz (*) logic analyzers available for about $300 (or less expensive clones on eBay), with virtually unlimited sample memory, because they use the PC (over USB).

(*) Sample 2 channels at 100 MHz, 4 channels at 50 MHz etc.


And question about the NOR gate used for the clock signal: does it have Schmitt trigger inputs?
I have a cheap Logic Analyser already. Good for 8x 200MHz or 16x 100MHz. Smiley
The scope has a much deeper memory. But also it will be useful for other than logic capture which was an area I was missing.

No schmitt trigger on NOR gate. But there is on the clock buffers, not that it needs it.

---
Regarding under volting - I believe the Avalon info posted was that 6.6W/GH was already slightly under volted at 1.15V so it will be interesting to see how this goes during testing. I thought briefly about adding an I2C digital resistor to the buck reg. output control but decided playing with that idea would have to wait til later. I don't know if the feedback circuit is too sensitive for that type of thing. Right now to adjust voltage you would need to change a resistor. For testing purposes I could try a small trimmer and see if there is an optimal value. One thing at a time though.


fasmax
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
May 25, 2013, 02:18:14 PM
 #1008



And question about the NOR gate used for the clock signal: does it have Schmitt trigger inputs?
I think BkkCoins has a RC network connected to the output of the NOR gate to get rid of the glitch that will occur when going to or from the idle state.
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 25, 2013, 02:26:12 PM
 #1009



And question about the NOR gate used for the clock signal: does it have Schmitt trigger inputs?
I think BkkCoins has a RC network connected to the output of the NOR gate to get rid of the glitch that will occur when going to or from the idle state.
Yes. I try to delay the extracted clock output long enough for the setup time on the data input. It may need some trial and error there - and the scope could be useful to see what it's doing.

fasmax
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
May 25, 2013, 03:08:10 PM
 #1010

@BkkCoins
It seems like 0xFE's idea of a NOR gate with Schmitt trigger inputs is a good one.
Because the Report output lines are wired OR with a pull up resistor the rising edges will be slow and the NOR gate might oscillate if the NOR gate does not have Schmitt trigger inputs.
 
ecliptic
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


View Profile
May 26, 2013, 02:55:16 AM
 #1011



This discussion is regarding an individual who owns ONE Avalon. He's not a manufacturer. Selling it doesn't make sense.
Fair enough I thought it was about Avalon in general. Yes at this point in time, there is much more to be made mining than selling unless you can get tens of thousands for it.


Until you sell so many chips at once that the network hashrate increases by over 200TH/sec from your chips alone

Which is what they are doing

Because that's what you do.

During a goldrush, you sell shovels.

It's also orders of magnitude easier, less work, less risk, and potentially profitable, to sell chips to people who then make the miners or whatever.

It's like saying "Why does intel make CPUs when they could make computers"
ecliptic
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


View Profile
May 26, 2013, 03:10:54 AM
 #1012

Is the 300 MHz a border somehow? I read in the avalon miner threads that overclocking to that value is possible only. I thought its because of the avalon miner design. But is it a chip-restriction?
It doesn't appear to be a restriction. According to the docs with a 32MHz clock it should be able to be set up to 450 MHz. I doubt it would hash at that speed but the PLL allows legal values that high.

People who want to test water blocks and such will no doubt have fun seeing how high it can actually go before meltdown. But there is a limit to what the 1.2V supply can handle safely, and I'd guess it's not much above 300 now.

Ok, thanks... i guess heat will not spread too high only from overclocking without highervolting so i think i would try overclocking too. Normally i overclock and downvolt my gpus to lengthen their lifetime while rising speed... maybe thats possible for the miner too..
With a GPU you are downvolting that which has little effect on performance.
There's no similarity here.
(or you could compare it to scrypt mining where that downvolting has a clear negative effect)

I'm not familar with the under/over volting which takes place on GPUs for mining and gaming, but I thought it was on the ~1.2V multi-phase buck converters these GPUs invariably use.  I don't see how undervolting the VCore of a GPU is fundamentally different from undervolting the VCore of these chips.  They should perform and fail in the same manner on the silicon level (mostly logic voltage not transitioning fast enough and resulting in erroneous output).  but of course there is far less software/firmware/possibly even hardware support to detect such problems on a custom ASIC versus a consumer product GPU.

That said I wouldn't tweak the voltage too much if at all, the companies who design these chips are very much aware of what is possible and what should be done, and know very well the variation inherent from chip to chip.  Changing the voltage could easily hurt more than it helps.
Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
May 26, 2013, 05:17:03 AM
 #1013

I have a few Chips that can be used as sacrificial lambs for the BKKCoins torture chamber... Have at it when I send you some BKKcoins... be really nice to push the limits and see what you can get from passive and forced air cooling. Scotty give us more power! Any advantage we can get now will extend the useful life of these boards.

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.
TomKeddie
Full Member
***
Offline Offline

Activity: 176
Merit: 100


View Profile
May 26, 2013, 06:25:02 AM
 #1014

The Avalon also does something right out of left field ...
It mines the work it is given continuously until more work is given - so if it reaches 0xffffffff it will start from 0x00000000 again and repeat the work.
Hopefully that ... weird ... idea hasn't been incorporated.
I know, it's a zombie. I plan to push work and then set a hardware timer interrupt (based on clk rate and chip count table) that will allow me to know when I can push the next work with minimal lag. I'm unsure yet how much of a queue I can have as some RAM will be used for other purposes but there is 1K and I expect some chunk of that will be available. If midstate+data is 48 bytes then I'm guessing now at least 4, maybe 8 work items possibly.

This is a limitation of the ASIC we can't work around right?  We can't tell when the internal counters wrap, only guess based on clock rate and how the work is divided up.  BKK and I discussed this a few pages back, I added this to my fpgas to improve the amount of effective mining time.  In the end I guess it is better to underestimate the time and not hash some of the space than to waste time by wrapping?


For LP we need to be able to abort all work and start new work (and even better if it can be done in a single command), but knowing how much work was already done at this point is necessary since at this point any incomplete work that has not provided any answers is indeed valid work done that counts towards the device performance.
How about an Abort cmd, 'A' which replies with amount of partial hashes done (which would be based off timer tick counts since the ASIC can't tell me anything). So if new work is prefixed with A, eg. AW002<id><midstate><data> then the queue is cleared, partial count returned, and new work immediately pushed. If useful multiple work tasks could be sent at once to fill the queue. I could just check the length and process them in sequence. I'll leave that for later refinement.
This is really useful on pools like Slush's where you only get paid for you contribution to the current block.  My fpgas do very well in the super short blocks (sub 1 min) because of LP support, we need this for sure, not in rev 1 perhaps.

BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 26, 2013, 06:55:24 AM
 #1015

This is a limitation of the ASIC we can't work around right?  We can't tell when the internal counters wrap, only guess based on clock rate and how the work is divided up.  BKK and I discussed this a few pages back, I added this to my fpgas to improve the amount of effective mining time.  In the end I guess it is better to underestimate the time and not hash some of the space than to waste time by wrapping?
That should be right. Since any hash test is as good as another the fastest work change over should be "the time needed to push new data" and that would only occur if you truncated current work as close to the end as possible (since that gives you the least changes over long term).

How about an Abort cmd, 'A' which replies with amount of partial hashes done (which would be based off timer tick counts since the ASIC can't tell me anything). So if new work is prefixed with A, eg. AW002<id><midstate><data> then the queue is cleared, partial count returned, and new work immediately pushed. If useful multiple work tasks could be sent at once to fill the queue. I could just check the length and process them in sequence. I'll leave that for later refinement.
This is really useful on pools like Slush's where you only get paid for you contribution to the current block.  My fpgas do very well in the super short blocks (sub 1 min) because of LP support, we need this for sure, not in rev 1 perhaps.
I'll definitely have this in first version but I'm probably going to change how I do it. It won't be AW as that doesn't follow the protocol really. It would be just A with new work so it acts like W with queue clearing. To stop work without new work you would just use E Enable to disable work.

Another change: I'm going to use a single byte binary address instead of 3 digits. I thought maybe it would ease debugging but letter codes with binary after will be just as easy, and why increase data xfer for that. The <address><workid> pair then make a 16 bit unique identifier for each work sent out. Which is easier both in the PIC and in the driver to track.

------ other news ------
I'm looking through the bflsc.c code now and have started preparing a cmd line test utility based on usbutils to allow me to poke the PIC and test outside of cgminer.

I also submitted a request to Microchip for one of their free USB PIDs (product ids) as the alternative is randomly choosing some VID/PID to hijack.

kano
Legendary
*
Offline Offline

Activity: 2842
Merit: 1172


Linux since 1997 RedHat 4


View Profile
May 26, 2013, 07:30:08 AM
 #1016

The Avalon also does something right out of left field ...
It mines the work it is given continuously until more work is given - so if it reaches 0xffffffff it will start from 0x00000000 again and repeat the work.
Hopefully that ... weird ... idea hasn't been incorporated.
I know, it's a zombie. I plan to push work and then set a hardware timer interrupt (based on clk rate and chip count table) that will allow me to know when I can push the next work with minimal lag. I'm unsure yet how much of a queue I can have as some RAM will be used for other purposes but there is 1K and I expect some chunk of that will be available. If midstate+data is 48 bytes then I'm guessing now at least 4, maybe 8 work items possibly.

This is a limitation of the ASIC we can't work around right?  We can't tell when the internal counters wrap, only guess based on clock rate and how the work is divided up.  BKK and I discussed this a few pages back, I added this to my fpgas to improve the amount of effective mining time.  In the end I guess it is better to underestimate the time and not hash some of the space than to waste time by wrapping?
...
It doesn't matter where you actually stop processing the nonce range as long as the software knows to send it more work at the right time.
i.e. you don't need to do the full range from 0x00000000 to 0xffffffff

Due to the statistically random nature of how the BTC sha256 works, there is the same probability of finding a share or a block at every value you hash and the previous hashes also do not affect the subsequent probabilities

Thus if you hash only half the range (0x00000000 to 0x7fffffff) you simply end up doing twice the work items in the same time to perform the same number of hash tests - i.e. the same chances of finding results.

So yes you do use up more work items and you do double the latency numbers everywhere, but the latency numbers are hopefully very small - and adding an input and output queue makes those numbers even more negligible.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
fasmax
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
May 26, 2013, 04:58:43 PM
 #1017

I have a few Chips that can be used as sacrificial lambs for the BKKCoins torture chamber... Have at it when I send you some BKKcoins... be really nice to push the limits and see what you can get from passive and forced air cooling. Scotty give us more power! Any advantage we can get now will extend the useful life of these boards.
With the limit of 32 watt power supplies over clocking may max out around 300MHS.
But if you only stuffed 14 ASIC chips you should be able over clock higher without overloading the 1.2 volt supply.
It will be fun to experiment once we get some hardware and software to play with.
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 27, 2013, 12:52:18 AM
Last edit: May 27, 2013, 01:28:56 AM by BkkCoins
 #1018

I have a few Chips that can be used as sacrificial lambs for the BKKCoins torture chamber... Have at it when I send you some BKKcoins... be really nice to push the limits and see what you can get from passive and forced air cooling. Scotty give us more power! Any advantage we can get now will extend the useful life of these boards.
With the limit of 32 watt power supplies over clocking may max out around 300MHS.
But if you only stuffed 14 ASIC chips you should be able over clock higher without overloading the 1.2 volt supply.
It will be fun to experiment once we get some hardware and software to play with.
I hadn't thought of that but it's true. The board cost is fairly low compared to ASIC cost, so it may be worth figuring out an optimal load per board to stay within the power rating if it turns out that significant over clocking is possible. Has anyone seen past comments about from BitSynCom regarding their own tests of how far they could over clock?

---
Just a note: I will probably divide the nonce ranges based on highest chip count per bank. So it will better to install chips balanced across banks rather than all in one bank first. It won't make a big difference but if the nonce divide value is lower then the range is higher per chip and the work reloads are less frequent. Doing the divide per bank means I only have to have table values for 1-8 chips instead of 1-16, which saves a bit of precious memory.





ecliptic
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


View Profile
May 27, 2013, 01:18:08 AM
 #1019

It might not be that hard to switch out the regulator for a higher current one as well.  Not sure what the package is and if there is another one that fits though.

Perhaps if you have space, add the component pads for a third regulator, but don't populate it by default.  Can easily add one another one then, which would also split and reduce the load on each individual regulator.
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 27, 2013, 01:31:53 AM
 #1020

It might not be that hard to switch out the regulator for a higher current one as well.  Not sure what the package is and if there is another one that fits though.
The problem is there are no higher current regs. That was the highest I could find at 16A, and I didn't want to start playing with ganged up regs. An alternate choice was putting 4 regs per board at 12A each, or going controller + discrete like on the Avalon, but other than the ASIC they are the most costly part. Well, not counting the heat sink either.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 [51] 52 53 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 ... 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!