Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 80. (Read 435369 times)

That's a really interesting communications protocol.

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)

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.

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

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.

Then you should use the search option. Everything available is on GitHub.

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?

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. 

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

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.

That would be very cool...

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

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?

This comes in when we've had access to the hardware

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.

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.

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.

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.

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

This is better way than measure in different spot and calculate average.

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.