Klondike - 16 chip ASIC Open Source Board - Preliminary

[kano]

usart timing is at page 375 of the pic datasheet - not what you searched in detail -but still interesting.

page 270 and page 271:
Maximum set-able baud-rate:
Desired Baud Rate = FOSC / (4 * (SPBRGH:SPBRGL +1))

48MHZ / 4 = 12MHz - thats "fast"

Ok. So we assuming we refill the UART close to optimally then we could probably get the dead zone to (32+8+16)/12 = 5, say 6uS maybe. Which should be a very, very tiny loss in nonce data, maybe around 0.0000015/5 = 0.0000003%. And maybe double if your average work has 2 nonces but it seems like most have 1 or 2, and a few have 3.

So it's probably not worth delaying nonces to avoid the dead zone. You could lose more due to block change if delayed. The main thing is it completely frees up the IRQ timing constraints.

OK that's sounds good

Your % aren't quite correct (when you divide the work up, the range for each is of course the division, not 2^32), but the numbers are small enough that indeed it appears it's better to lose a nonce once in a while than slow things down by more than that resolving the problem.

Average nonce per 2^32 is of course 1.
However, 4 isn't all that rare (hmm I think I'll add a stats counter for the BFLSC to see how often >1 does happen - that one's the easiest to do it)

[1714203067]

1714203067

[1714203067]

1714203067

[1714203067]

1714203067

[1714203067]

1714203067

[1714203067]

1714203067

[1714203067]

1714203067

[Lollaskates]

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

Bkk brought it up not me 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.

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

I saw that RPI miner host project - looks like a blast. I was just filling my shopping cart on adafruit for that last night. Gotta go back and order it
http://learn.adafruit.com/piminer-raspberry-pi-bitcoin-miner/

I was inspired by that project as well, however I will be using Graphic ST7565 Negative LCD (128x64) http://www.adafruit.com/products/438 instead. I want to be able to display moving graphs among other things

Hold fire boys, check this thread before buying........

https://bitcointalk.org/index.php?topic=137934.msg2671338#msg2671338

Kano`s on the job   

the 128x64 I linked is SPI and there are tutorials floating around on how to connect it to an rpi. I plan on writing up a blog post on my whole build, i'll of course link that here on the boards when its finished.

[cp1]

Both spi and I2c are supported by hardware on the raspberry pi, it's surprisingly easy to use.  Though must stuff is written in python which I hate.

[BkkCoins]

I pushed a driver update for supporting config options. Just copied Icarus method.

In conf file can add,

klondike-options : 300, 60, 80, 50

where,

300 is clock in MHz
60 is target temp in deg C
80 is critical temp in deg C
50 is fan target in percent (power)

The firmware for the temp/fan control isn't complete and I haven't had time to test what's there but it does report the thermistor reading. It should set fan power according to config setting.  Currently it doesn't update fan according to temp above/below target. And it doesn't shutdown based on critical temp. I'll get to that soon but for now I wanted an easier way to set clock than opening ktest and priming it.

Cmd line option worked as well but I noticed it didn't override conf file.
eg.

--klondike-options 256,60,80,50
or
--klondike 256

to just set clock.

[Lollaskates]

I pushed a driver update for supporting config options. Just copied Icarus method.

In conf file can add,

klondike-options : 300, 60, 80, 50

where,

300 is clock in MHz
60 is target temp in deg C
80 is critical temp in deg C
50 is fan target in percent (power)

The firmware for the temp/fan control isn't complete and I haven't had time to test what's there but it does report the thermistor reading. It should set fan power according to config setting.  Currently it doesn't update fan according to temp above/below target. And it doesn't shutdown based on critical temp. I'll get to that soon but for now I wanted an easier way to set clock than opening ktest and priming it.

Cmd line option worked as well but I noticed it didn't override conf file.
eg.

--klondike-options 256,60,80,50
or
--klondike 256

to just set clock.

well played sir, well played. Its good to hear you were able to run it over 300MHz by the way

[marto74]

During tests of single Avalon chip last night We were able to run it without misses up to 395 MHz.
We tried up to 450 but after 395 it starts missing data.
This without proper cooling.

[BkkCoins]

During tests of single Avalon chip last night We were able to run it without misses up to 395 MHz.
We tried up to 450 but after 395 it starts missing data.
This without proper cooling.

Nice. Is that with a 30pF cap? I only got to about 360 with 30pF.

[Bicknellski]

During tests of single Avalon chip last night We were able to run it without misses up to 395 MHz.
We tried up to 450 but after 395 it starts missing data.
This without proper cooling.

NICE MARTO!!!!!!!!!

[marto74]

During tests of single Avalon chip last night We were able to run it without misses up to 395 MHz.
We tried up to 450 but after 395 it starts missing data.
This without proper cooling.

Nice. Is that with a 30pF cap? I only got to about 360 with 30pF.

It was on a test bread board with 16 bit pic controller , that we use for other projects.
In this case the clock for the avalon is fed by the PIC itself, without oscilator.
And yes 30 pF cap

[Bicknellski]

Comments?

Quote from: JHenderson on Today at 08:40:04
Thought FCC guidelines were to resolve interference issue with other electronic components not mitigate against potential heath risks. FCC and FDA are different 

Contrary to all my competitors I do take EMC seriously and designed these boards to be compliant. (which did increase price)
Emission testing is scheduled for next week, but the Lab hasn't yet confirmed my appointment.
The boards will be tested against EN55022.

https://bitcointalk.org/index.php?topic=179769.msg2678377#msg2678377

[c-tek]

Comments?

Quote from: JHenderson on Today at 08:40:04
Thought FCC guidelines were to resolve interference issue with other electronic components not mitigate against potential heath risks. FCC and FDA are different 

Contrary to all my competitors I do take EMC seriously and designed these boards to be compliant. (which did increase price)
Emission testing is scheduled for next week, but the Lab hasn't yet confirmed my appointment.
The boards will be tested against EN55022.

https://bitcointalk.org/index.php?topic=179769.msg2678377#msg2678377

There are no components on the board that their function will generate interference greater then the maximum admissible value of FCC.
This is just marketing IMHO.

[Enigma81]

Comments?

Quote from: JHenderson on Today at 08:40:04
Thought FCC guidelines were to resolve interference issue with other electronic components not mitigate against potential heath risks. FCC and FDA are different 

Contrary to all my competitors I do take EMC seriously and designed these boards to be compliant. (which did increase price)
Emission testing is scheduled for next week, but the Lab hasn't yet confirmed my appointment.
The boards will be tested against EN55022.

https://bitcointalk.org/index.php?topic=179769.msg2678377#msg2678377

There are no components on the board that their function will generate interference greater then the maximum admissible value of FCC.
This is just marketing IMHO.

Um.. What?  Given a 2 layers board and a 32Mhz oscillator that is routed all over the place, I think the FCC would not be so sure..

Enigma

[c-tek]

Um.. What?  Given a 2 layers board and a 32Mhz oscillator that is routed all over the place, I think the FCC would not be so sure..

Enigma

For example take a ATX or mATX mainboard. It has multilayer circuit (not 2 layers), the oscilator is greater and there are more circuits than on the K16. The power feeded into the board is huge compared to K16. Not to mention the power filters and transformers.
So I assume that the circuit traces of the K16 are not enough to emit EM interference so that the values are greater than FCC aproves.
And let's keep in mind that those values are given at 1 meter from the device You will not sleep with the k16 boards.
In my opinion this is somewhat not important to discuss since there is more EMI using a cell phone. And if you decide to have a "farm" of k16 they will probably be placed in a location far or away from people (due tot the heat and also to prevent accidental intervention).

And anyway we are discussing about an experimental device. There are lots of things to improve and this is only one thing of them

[Enigma81]

Um.. What?  Given a 2 layers board and a 32Mhz oscillator that is routed all over the place, I think the FCC would not be so sure..

Enigma

For example take a ATX or mATX mainboard. It has multilayer circuit (not 2 layers), the oscilator is greater and there are more circuits than on the K16. The power feeded into the board is huge compared to K16. Not to mention the power filters and transformers.
So I assume that the circuit traces of the K16 are not enough to emit EM interference so that the values are greater than FCC aproves.
And let's keep in mind that those values are given at 1 meter from the device You will not sleep with the k16 boards.
In my opinion this is somewhat not important to discuss since there is more EMI using a cell phone. And if you decide to have a "farm" of k16 they will probably be placed in a location far or away from people (due tot the heat and also to prevent accidental intervention).

And anyway we are discussing about an experimental device. There are lots of things to improve and this is only one thing of them

I love self proclaimed EE's.  Where's my facepalm picture...

[BkkCoins]

Um.. What?  Given a 2 layers board and a 32Mhz oscillator that is routed all over the place, I think the FCC would not be so sure..

Enigma

2 layer board? The clock is routed in the middle of a GND plane and has one below and a power plane above. And there is GND stitching around the edges. While I don't have access to FCC testing facilities here I'm reasonably sure that a 32 MHz clock won't cause any grief. It could be different if the 300 MHz hash clock was route all over the place.

Was the comment about "insane power supply" in that other thread aimed at mine? I'd like to know if someone else said that.

[Bicknellski]

Um.. What?  Given a 2 layers board and a 32Mhz oscillator that is routed all over the place, I think the FCC would not be so sure..

Enigma

2 layer board? The clock is routed in the middle of a GND plane and has one below and a power plane above. And there is GND stitching around the edges. While I don't have access to FCC testing facilities here I'm reasonably sure that a 32 MHz clock won't cause any grief. It could be different if the 300 MHz hash clock was route all over the place.

Was the comment about "insane power supply" in that other thread aimed at mine? I'd like to know if someone else said that.

Guessing the BIG BOYS not the DIY... wink wink not sure.

[kano]

...
Average nonce per 2^32 is of course 1.
However, 4 isn't all that rare (hmm I think I'll add a stats counter for the BFLSC to see how often >1 does happen - that one's the easiest to do it)

Just added it to my git and running it on my Jalapeno ... it seems multiple answers are even more common than I thought:
80 results:
33/28/9/6/3/0/1/0/0/0
means: 33 had 0, 28 had 1, 9 had 2, 6 had 3, 3 had 4, 1 had 6
... a value in position 9 means 9 or more, which isn't possible, but avoids unexpected crashes

I'll let it run for a bit ...
400 results:
152/137/69/31/9/0/1/1/0/0

And a bit longer ...
1000 results:
374/364/175/64/19/1/2/1/0/0
(which is 1007 nonces = close to expected average of 1000)

[BkkCoins]

1000 results:
374/364/175/64/19/1/2/1/0/0
(which is 1007 nonces = close to expected average of 1000)

I'm surprised so many have 0. If only we could test for a "dead" work unit and discard them.

[Enigma81]

Um.. What?  Given a 2 layers board and a 32Mhz oscillator that is routed all over the place, I think the FCC would not be so sure..

Enigma

2 layer board? The clock is routed in the middle of a GND plane and has one below and a power plane above. And there is GND stitching around the edges. While I don't have access to FCC testing facilities here I'm reasonably sure that a 32 MHz clock won't cause any grief. It could be different if the 300 MHz hash clock was route all over the place.

Was the comment about "insane power supply" in that other thread aimed at mine? I'd like to know if someone else said that.

I thought you were doing this in 2 layers.. I suppose I haven't paid that much attention though.. Agreed, should be fine then.  Maybe I'm remembering something from the very early days of your development.

Not sure what you mean about the insane power supply - I don't even recall talking about such thing, so it obviously wasn't aimed at you..

Enigma

[kano]

1000 results:
374/364/175/64/19/1/2/1/0/0
(which is 1007 nonces = close to expected average of 1000)

I'm surprised so many have 0. If only we could test for a "dead" work unit and discard them.

Then you could increase all hashing performance by a massive 37% (based on that result)

... and yet this is something I looked into a long time ago (almost 2 years) early on when I first found out about bitcoin, but never completed my work on it ...
By the looks of those results I should get back to it one day and finish it ... but I doubt I'll bother since it probably won't yield anything
It started as a program to optimise hashing (and found all the GPU optimisations independently)