Bitcoin Forum
May 25, 2019, 10:16:20 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 [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 ... 182 »
  Print  
Author Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary  (Read 434686 times)
BenTuras
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
July 05, 2013, 07:58:22 AM
 #2021

... If I added a 1of4 analog switch and used the 2 available lines then I could sequentially sense each of the 4 thermistors, allowing separate readings for each quad. I could then relay them as status values for the driver to decide what to do. IS this something that is worth added cost of a switch chip?
I would say 1 sensor for 16 chips in the center on the heatsink. The heatsink will spread the warmth more or less and a sensor in the middle will probably pick up close to the highest temp of all 16 chips.

I am selling in stock OneStringMiner boards, based on the Bitfury chips. Have a look here: https://bitcointalk.org/index.php?topic=495536.0
1558822580
Hero Member
*
Offline Offline

Posts: 1558822580

View Profile Personal Message (Offline)

Ignore
1558822580
Reply with quote  #2

1558822580
Report to moderator
1558822580
Hero Member
*
Offline Offline

Posts: 1558822580

View Profile Personal Message (Offline)

Ignore
1558822580
Reply with quote  #2

1558822580
Report to moderator
GET 25 FREE SPINS AT REGISTRATION
GET 100% BONUS ON FIRST DEPOSIT
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
kano
Legendary
*
Offline Offline

Activity: 2828
Merit: 1166


Linux since 1997 RedHat 4


View Profile
July 05, 2013, 09:33:05 AM
 #2022

...
I have not currently added the code to detect critical temp and disable the device. But this function is also present in the PIC so it's kind of a backup that the driver would take any action.
One thing I have said many times on this subject ... it really should be that the hardware takes over when the device is close to killing itself.
The hardware shouldn't decide normal temperature control.

Look at how the GPU's work, they shut down at what we would all consider to be a ridiculously high temperature, thus cgminer by default uses a lower temperature to consider pausing mining and waiting for a cool down and thus most people find they've been able to mine on their GPUs non-stop for literally years.

We do the same with the other USB devices - a good example of that is the MMQ where I deal with it in software coz the sensors themselves are known to read low so I use a quite low setting in the cgminer control.

Not every shipped device will have the same characteristics, so people should be able to adjust these settings in software and that is easiest if the software can make the decision before 'absolute critical'
The best example of how NOT to do it is the BFL FPGA where the damn throttling hardware is a PITA for many when it stops mining too early.

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!
GandalfG
Sr. Member
****
Offline Offline

Activity: 259
Merit: 250


Dig your freedom


View Profile
July 05, 2013, 09:45:30 AM
 #2023

... If I added a 1of4 analog switch and used the 2 available lines then I could sequentially sense each of the 4 thermistors, allowing separate readings for each quad. I could then relay them as status values for the driver to decide what to do. IS this something that is worth added cost of a switch chip?
I would say 1 sensor for 16 chips in the center on the heatsink. The heatsink will spread the warmth more or less and a sensor in the middle will probably pick up close to the highest temp of all 16 chips.
This is better way than measure in different spot and calculate average.

Want to say thanks? 16ragydppe9QFRVhrdwEUjgfMS7KCfEFGY
Enigma81
Full Member
***
Offline Offline

Activity: 178
Merit: 100



View Profile
July 05, 2013, 10:31:26 AM
 #2024

... If I added a 1of4 analog switch and used the 2 available lines then I could sequentially sense each of the 4 thermistors, allowing separate readings for each quad. I could then relay them as status values for the driver to decide what to do. IS this something that is worth added cost of a switch chip?
I would say 1 sensor for 16 chips in the center on the heatsink. The heatsink will spread the warmth more or less and a sensor in the middle will probably pick up close to the highest temp of all 16 chips.
This is better way than measure in different spot and calculate average.

1 sensor in the middle will actually always read the lowest temp of all the chips MINUS the delta T between junction and Heat sink (could be many degrees C).  The BEST thermal monitoring uses one sensor per chip, and always makes critical decisions (like over temp shut-down) based upon the highest reading - not the average.  Just because the average temperature is 'safe' doesn't mean that one hot chip isn't about to explode due to an over-temp condition.

Enigma
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 05, 2013, 10:38:21 AM
 #2025

Not every shipped device will have the same characteristics, so people should be able to adjust these settings in software and that is easiest if the software can make the decision before 'absolute critical'
The best example of how NOT to do it is the BFL FPGA where the damn throttling hardware is a PITA for many when it stops mining too early.
What is the preferred way to handle config for the ASICs. I didn't see a menu item like for GPUs. Is there an API for reading config from the conf file? Or is adding API control preferred. I didn't see an example of that in the bflsc driver. With my GPUs I've always just manually edited the conf file.

I'm thinking of clock freq, fan target, temp target and temp critical,which are currently the 4 cfg options for the klondike. They should be stored somewhere but user adjustable.

daemondazz
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
July 05, 2013, 10:39:18 AM
 #2026

Good idea. I'll look into adding a via to help heat get to the thermistor. I was thinking about having sensors for each quad but didn't have enough inputs for individual monitoring. The idea of averaging via several is great because the thermistors are cheap. If I put two in series in parallel then I get 4 thermistors with the same total resistance. I do see some issues with this for situations where not all ASICs are installed or when one gets to critical temp when others are fine. In the latter case you're no worse off than just having one, for the 3 not monitored, but in the case with less ASICs the average of the installed ones would be impacted.

On my Caterpillar board (which I'm now basing off your firmware) I'll have 24 ASICs with an I2C temperature sensor per quad of ASICs (so 6 sensors). This is actually likely to be about the only change I need to do from your firmware.

I am not stacking boards, so won't be using I2C for that.

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
sensei
Full Member
***
Offline Offline

Activity: 378
Merit: 100



View Profile
July 05, 2013, 01:27:36 PM
 #2027

1 sensor in the middle will actually always read the lowest temp of all the chips MINUS the delta T between junction and Heat sink (could be many degrees C).  The BEST thermal monitoring uses one sensor per chip, and always makes critical decisions (like over temp shut-down) based upon the highest reading - not the average.  Just because the average temperature is 'safe' doesn't mean that one hot chip isn't about to explode due to an over-temp condition.

Enigma
I am considering using a heat sink that covers two rails, one on each side of the board and is open in the middle 1-1/4". A sensor in the middle won't work for that. We could use an analog switch and place a sensor  at each quadrant of 4 chips.
kano
Legendary
*
Offline Offline

Activity: 2828
Merit: 1166


Linux since 1997 RedHat 4


View Profile
July 05, 2013, 02:06:57 PM
 #2028

Not every shipped device will have the same characteristics, so people should be able to adjust these settings in software and that is easiest if the software can make the decision before 'absolute critical'
The best example of how NOT to do it is the BFL FPGA where the damn throttling hardware is a PITA for many when it stops mining too early.
What is the preferred way to handle config for the ASICs. I didn't see a menu item like for GPUs. Is there an API for reading config from the conf file? Or is adding API control preferred. I didn't see an example of that in the bflsc driver. With my GPUs I've always just manually edited the conf file.

I'm thinking of clock freq, fan target, temp target and temp critical,which are currently the 4 cfg options for the klondike. They should be stored somewhere but user adjustable.
This comes in when we've had access to the hardware Smiley

If you look at the latest Avalon commits, ckolivas has added a set of controls for hardware error rates and temperatures.

The config is done by using temperature options with defaults and also the code itself acting based on those options.

The bflsc code now has temperature control also - once he had access to a little single for a short while ... that had major temperature problems.

In each case (as I did with the MMQ over quite a few weeks) it's been setting it up and tuning it with hardware, even the GPU code was done that way.

So, in your case I guess you'll need to look at the others and set it up appropriately.
Each one actually does it a different way since we have different ideas about how to handle the different hardware (and of course the different hardware itself needs to be handled differently)
e.g. the MMQ doesn't work properly via fine tuned temperature control (and really has an issue of not having any way to stop work) whereas the Avalon ckolivas has written a PID controlled temperature algorithm, but the bflsc is a simpler temperature control.

But what it all really depends on is the final hardware itself, i.e. specs from you to say these normal temperature control would be 'blah'
The simple problem of course is that everyone has a different environment and no doubt there will be some people who put the mining hardware in a hot room and at least expect it to not kill itself. Having two levels of control helps with that immensely: a 'this is the temp it should run at' software control and a 'if this happens shut it down' higher temperature hardware control

The basic control from the user should normally be setting values or ranges (with defaults of course) and the software working within those settings.
The API isn't really how this should be done - even with the GPU setting it actually doesn't really work that way even though the API commands are there.

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!
bitkapp
Hero Member
*****
Offline Offline

Activity: 517
Merit: 500


aka alaniz


View Profile
July 05, 2013, 03:44:30 PM
 #2029

I was wondering whether you could make a K1 Nano on a breadboard and if you can where can i find the circuits and component lists?

cp1
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


Stop using branwallets


View Profile
July 05, 2013, 04:58:14 PM
 #2030

I was wondering whether you could make a K1 Nano on a breadboard and if you can where can i find the circuits and component lists?

Everything's on the git in the OP.  The avalon is SMD so you'll need some kind of breakout adapter.

Guide to armory offline install on USB key:  https://bitcointalk.org/index.php?topic=241730.0
cardcomm
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
July 05, 2013, 10:43:28 PM
 #2031

I was wondering whether you could make a K1 Nano on a breadboard and if you can where can i find the circuits and component lists?

Everything's on the git in the OP.  The avalon is SMD so you'll need some kind of breakout adapter.

That would be very cool...

Easily see your cgminer status with my cgminerLCDStats app:  http://cardcomm.github.io/cgminerLCDStats/
Did my post help you or make you laugh? Let me know with Bitcoins at: 1CQfpMHQ5zVuZ5i9uxSHSSx4J8ZhehSjn3  Smiley
bigbeninlondon
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile
July 06, 2013, 12:52:31 AM
 #2032

I was wondering whether you could make a K1 Nano on a breadboard and if you can where can i find the circuits and component lists?

Everything's on the git in the OP.  The avalon is SMD so you'll need some kind of breakout adapter.

That would be very cool...

Anyone doing this should start a thread so I can follow.  Would be interested to follow along with a chip or two of my own.
Taugeran
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


CCNA: There i fixed the internet.


View Profile
July 06, 2013, 01:12:33 AM
 #2033

I was wondering whether you could make a K1 Nano on a breadboard and if you can where can i find the circuits and component lists?

Everything's on the git in the OP.  The avalon is SMD so you'll need some kind of breakout adapter.

That would be very cool...

Anyone doing this should start a thread so I can follow.  Would be interested to follow along with a chip or two of my own.

http://www.adafruit.com/products/1377... Tada hoorah adafruit. they even have a center pad through hole for soldering

Bitfury HW & Habañero : 1.625Th/s
tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1
Come join Coinbase
cardcomm
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
July 06, 2013, 01:30:32 AM
 #2034

I was wondering whether you could make a K1 Nano on a breadboard and if you can where can i find the circuits and component lists?

Everything's on the git in the OP.  The avalon is SMD so you'll need some kind of breakout adapter.

That would be very cool...

Anyone doing this should start a thread so I can follow.  Would be interested to follow along with a chip or two of my own.

http://www.adafruit.com/products/1377... Tada hoorah adafruit. they even have a center pad through hole for soldering

Nice find! I wish I'd known they had this, I just got an order from adafruit today. Well, we all know I'll be ordering something else soon anyway haha.

Someone gonna start a thread? I'd do it, but I'm at the "follow along and hope it's not TOO far over my head" stage.  Undecided

Easily see your cgminer status with my cgminerLCDStats app:  http://cardcomm.github.io/cgminerLCDStats/
Did my post help you or make you laugh? Let me know with Bitcoins at: 1CQfpMHQ5zVuZ5i9uxSHSSx4J8ZhehSjn3  Smiley
cp1
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


Stop using branwallets


View Profile
July 06, 2013, 01:42:23 AM
 #2035

I don't even know where the avalon datasheets are.  What is the bare minimum you need to communicate with one?  Raspberry Pi has hardware i2c, SPI, serial, and just regular GPIO.  Obviously you need a regulator and a 32MHz clock.  What else?

Guide to armory offline install on USB key:  https://bitcointalk.org/index.php?topic=241730.0
villex
Full Member
***
Offline Offline

Activity: 154
Merit: 100


Mining hardware assembler and administrator.


View Profile
July 06, 2013, 01:47:36 AM
 #2036

I don't even know where the avalon datasheets are.  What is the bare minimum you need to communicate with one?  Raspberry Pi has hardware i2c, SPI, serial, and just regular GPIO.  Obviously you need a regulator and a 32MHz clock.  What else?

Then you should use the search option. Everything available is on GitHub.
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
July 06, 2013, 01:48:56 AM
 #2037

I don't even know where the avalon datasheets are.  What is the bare minimum you need to communicate with one?  Raspberry Pi has hardware i2c, SPI, serial, and just regular GPIO.  Obviously you need a regulator and a 32MHz clock.  What else?
https://github.com/BitSyncom/avalon-ref

In particular look at the SPEC directory for the chip and the hash board schematic.

The protocol is none of the above. It's their own special bi-phase 2 line thing. You could experiment with how slow you can go but the spec calls for 250nS / bit cycles. The Klondike sends bits at about 390/108/8 ~ 450nS / bit.

You need at least 3 regulators and the protocol handling circuit - which by my design is 2 NOR gates, 74AUP2G02, though other methods will no doubt also work.

1.2V @ 2A buck reg., 3.3V @ ? and secondary PLL 1.2V @ ? but linear regulation.

ecliptic
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


View Profile
July 06, 2013, 02:17:41 AM
 #2038

Hm, what was the reason for seperating the outputs from the two buck converters on VDD1/VDD2, was it in case their output voltages were unequal?

I was thinking about modifications to allow higher current/voltage for overclocking (with sufficient cooling) - simplest would seem to be adding a third regulator.  If they're kept separate, could be accomplished by splitting 5/5/6 chips onto VDD1/2/3
Bluestreak66
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
July 06, 2013, 02:32:06 AM
 #2039

Hm, what was the reason for seperating the outputs from the two buck converters on VDD1/VDD2, was it in case their output voltages were unequal?

I was thinking about modifications to allow higher current/voltage for overclocking (with sufficient cooling) - simplest would seem to be adding a third regulator.  If they're kept separate, could be accomplished by splitting 5/5/6 chips onto VDD1/2/3

It's generally not a good Idea to combine multiple buck or boost regulator onto a single powerplane unless they are designed to do so. As mentioned in a previous post I think BKK plans on a larger regulator for v2. I think it would be a good idea to put a single polyphase regulator on the board in place of the current 2 and would drive 2 or 3 10~15 amp mosfets. That would be 3 phases @ 15 amps so a max of 45amps. Most of the polyphase regulators  can communicate through i2c so voltage could be infinitely controlled and also have feedback to the micro that could be used to adjust clock speed if the regulator over temp, close to or over current or other variables. These are also highly efficient up to 96% which could make or break the ROI of these asic board as well as the useful life in terms of cost to run vs bitcoins generated. They also reduce the component sizes and power supply noise.
ecliptic
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


View Profile
July 06, 2013, 02:35:44 AM
Last edit: July 06, 2013, 02:46:10 AM by ecliptic
 #2040

Hm, what was the reason for seperating the outputs from the two buck converters on VDD1/VDD2, was it in case their output voltages were unequal?

I was thinking about modifications to allow higher current/voltage for overclocking (with sufficient cooling) - simplest would seem to be adding a third regulator.  If they're kept separate, could be accomplished by splitting 5/5/6 chips onto VDD1/2/3

It's generally not a good Idea to combine multiple buck or boost regulator onto a single powerplane unless they are designed to do so. As mentioned in a previous post I think BKK plans on a larger regulator for v2. I think it would be a good idea to put a single polyphase regulator on the board in place of the current 2 and would drive 2 or 3 10~15 amp mosfets. That would be 3 phases @ 15 amps so a max of 45amps. Most of the polyphase regulators  can communicate through i2c so voltage could be infinitely controlled and also have feedback to the micro that could be used to adjust clock speed if the regulator over temp, close to or over current or other variables. These are also highly efficient up to 96% which could make or break the ROI of these asic board as well as the useful life in terms of cost to run vs bitcoins generated. They also reduce the component sizes and power supply noise.
Um, i'd seriously question that even a ~10% increase in the efficency of the buck converters would have an impact on ROI anytime within the next.. 5 years.  ROI versus electricity, besides being a complete non issue for what appears to be quite a while (i'd say at least 1-2 years.  More important is the exchange range and difficulty) -- is basically dictated by the efficiency of the ASIC in terms of Hashes/Joule.  The buck converters that feed them are only a tiny part of the loss, and only what, 10% of the total power dissiptation of a K16?]

That makes sense on the buck converters though.

What i would argue is far more important is maximizing the GH/sec / $ for these units.  I'm investigating a watercooling setup and final Gh/sec / $ (and electrical usage) for a watercooled setup versus an air-cooled setup.  But for an overclocked watercooled setup, some changes are required (higher voltage [or ability to increase it], and higher current output, and/or less chips per board, as well as possibly more decoupling capacitors)
Pages: « 1 ... 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 [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 ... 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!