Klondike - 16 chip ASIC Open Source Board - Preliminary

[SebastianJu]

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?

[BkkCoins]

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]

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..

[kano]

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)

[0xFE]

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]

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?

[BkkCoins]

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

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]

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]

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

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]

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]

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.

[TomKeddie]

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]

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]

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.

[fasmax]

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]

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]

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]

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.