Topic: Community brainpan - please discuss and debate desirable features for a miner - page 2. (Read 5724 times)

It's been mentioned a couple times, but this is not my project. Basically, I have been asked to oversee design and when I say "those attributes are fixed" what I mean is "those attributes are fixed by the person footing the bill". Y'all know I'd rather see something sub-500W, and my own projects will be.

Based on the below quote from the OP


I would say that 1KW is the target because the design is for a consumer-grade miner and 1KW is a sweet spot for those folks operating on 110V PSUs. I could be wrong though and I am sure sidehack will correct me if am.

Yeah, both side nice SOLID heatsinks would tend to help with making good reliable thermal contact long-term.

 Might be a little more expensive, but heatsinks don't cost all THAT much.



 That reminds me - why do you keep specifying you are locked into the "1 kilowatt power consumption" ballpark on the design?

That's another reason why I like the idea of heatsinks on both sides. As long as all the chips start out coplanar, the one heatsink will keep them pressed flat and tight to the other. I know some people complained about S5 because the boards could warp due to screw placement and some chips wouldn't make good contact. That's a lot less of a problem with a good sandwich.

 Trying to heatsink a chip THROUGH the board is just a nightmare of inefficiency. VERY VERY bad idea.

 On the other hand, trying to get multichips to make good contact with a single HS on top of them isn't fun either - but it's a TON more efficient when you can get it to work.

Thanks for the info. Definitely interesting.


That's the part of mSPI that was interesting. All the devices shared the same four lines, the SS line would change state indicating the there was new traffic on it's way, the master would put the traffic on the wire, and the devices would pick it up. According to the wikipedia article, the first byte was essentially an address of the desired device. With the free-form of SPI, there would be nothing preventing you from using more than one byte as addressing, except top speed.


The DIP switches kinda reminds me of the old SCSI device addressing. You had to pay attention to the address of each device, so there were no duplicates, and it couldn't be the same as the controller. I seem to recall that later versions of the SCSI protocol introduced chipsets/firmware that could negotiate their buss ID.


Definitely interesting how each of the engineering design teams tackled essentially the same problem.

Thanks for the education @sidehack.

Cheers,

- zed

True thing, brainfart on my part. They just use some form of chained comms.

Most things use chained comms - the controller talks to the first chip, which relays work to the second, which relays work to the third. Sometimes the work packet will have a bunch of nonce ranges attached; each chip will take one and pass the rest on.
ASICMiner used SPI for board-level chip comms. Each chip had a select line and the MOSI, MISO and CLK lines were shared. There'd be some binary decoding where a five- or six-bit address would flag a single chip and everyone else would ignore the data passed in. In the case of AM Tube and Prisma, all the boards were on a shared UART line where work passed into the board-level microcontroller was addressed, which is why each board was given a unique address using the DIP switches. I imagine that's similar to the shared bus Avalon units are on, except addressing is automatic - either hard-coded into each box's internal controller board or there's a detection and assignation protocol, I haven't looked into it far enough to know for sure.
It looks like Bitfury uses unique comms to each chip using a single multiplexer chip, at least in current generations. I believe the old 55nm chips were chained/relayed comms.
Avalon's A3222 and A3218 chips use SPI between them; before that I believe was UART. I haven't looked at the current BM1387 (S9) but BM1380 through 1385 used UART and I don't expect that changed. Bitfury 55nm were SPI. I'm not sure about BW chips or the A1.

Thanks for the architecture info. I read a bit about the SPI protocol and what they call mSPI (mini-SPI) seems interesting, and with the free-form of the SPI protocol, could have the potential for many more addressable devices in a chain.

How is communication usually handled when each hashboard has multiple chips and work has to be farmed out? Is that also SPI?

Cheers,

- zed

(Bitmain has never used SPI)

I don't know enough about the chips we'd be using to know if you can set a returned diff threshold, but I hope it's there. Last I checked, Bitmain chips returned all shares (might have changed with BM1385/7?); I know the BE200 had a minimum diff and I believe Avalon put that in as well. Hopefully that's the case - like you said, kano, optimal chip design.

Yes, monoblocks are the best. The stickiness is solved with periodical thermal repastings. It is easir to maintain 1 big block than 163 little sinks


The problem with I2C is it limits any bus to 255 devices. SPI is better suited for the density miners have. Also, much better solution is to have a MCU local to each board and make THAT controller the slave, not each individual hash chip. Then, the upstream controller just sends a nonce range and it divides work between hash chips. This could hide an I2C comms behind, SPI or a roll your own like the daisy chained SPI from Bitmain.



Hehe.... that's modularity at its best, too bad they are just toys

Just a little bit of info regarding that, if the driver is written well and the chip design is optimal
I wrote the driver in the (defunct) Blackarrow Prosperos (as you can see if you look at the minion driver source in cgminer)
I managed to get a standard RPi to process approx 3.5TH/s of 1 diff shares during development.
No new miner would be sending back 1diff shares to the driver, so even at 64diff you're looking at a >200THs limit.
(The Prospero chip allowed setting nonce ranges and I set it to a tiny fraction of a nonce range and kept sending it the same work item that had the same nonce value in that range, so yeah it was full 1diff checking how fast I could get it to go. I got it to about 3.5THs)
The Blackarrow chip was indeed well designed, they just failed dismally at making high power SPI controller boards
However, that was SPI, not USB.

Nope, that's entirely a coincidence.

Would that be the device that influenced the GekkoScience name? I looked up the device, and noticed the image that they used and the name of one of their dev kits.

Cheers,

- zed

ISP header is pretty much exactly what I was thinking of doing.


This is also pretty much exactly what I was thinking of doing. How else are we going to read temp sensors, adjust core voltages, and change fan speeds? Something needs to be present at the board level to implement all that, which I'm pretty sure has been specified since the very first post and reiterated about half a dozen times since.

If we wanted the option for UART as well as USB, probably the easiest solution would be to use a CP2102 (or equivalent) on the hashboard and break out the serial lines to header holes. That separates the board-level microcontroller from USB, which would probably make code simpler and add about a dollar to the cost of boards. If the onboard USB shot craps, someone could wire up toptek's USB adapter in a pinch and get it back to running. I don't know if that's a better idea overall than just using a USB-enable micro and that's the only means of interfacing. If USB is externalized, it means sourcing two chips instead of one but that also helps standardize drivers and device detection and removes USB stack code from the microcontroller.


Nope, nope, nope. When considering adding complexity to cover for potential failure events, you should consider the cost of the addition versus the likelihood of failure. If a $100 miner is 1% likely to fail in a certain way, it makes sense to add $1 of addition to remove that failure. If a $1000 miner is 0.01% likely to fail in a certain way and removing that potential for failure costs more than a dime, you're probably wasting the effort. My design motto is "Simple, durable, reliable" but there are practical limits to how durable a thing should be made, especially at the cost of simplicity.


This has been the case, and it was also the entire point of the thread - I wanted my ideas to change because there are a lot of people here a lot smarter than me (and certainly more experienced engineers) and it'd be foolish to assume I know what's best from the get-go and ignore input.

Man, when I think UART it goes back a lot of years, but would making the six pins for an AVR/ICSP programmer connection accessible (don't need to have headers installed) be the equivalent? If that is the case you could make a hex file available separately, and folks that were interested/capable could flash their new micro-controller.

Cheers,

- zed

edited to add ICSP...

I get the ease of maintenance with a single block that has straight fins, but is it really that easy to upgrade/remove? I would think that there is a lot of stickiness from the baked on thermal paste.


This could be possible depending on where the USB circuit it located, and what path the controller decision has taken. As @sidehack has mentioned earlier in this thread he is inclined to connect the hashboards via USB to the controller much like he did with the Compac miners he built. If the USB circuit breaks, then the hashboard would need repair.

From the request it's as if you may be thinking that there is a PIC (or equivalent) micro-controller on the hashboard. That sounds like it may be more complicated.

Earlier in this thread I had suggested using I2C to communicate to the hashboards, but I also suggested using a replaceable slave controller inside the miner that communicated to the "mother" controller via USB. More complex, yes, but easily fixable with off the shelf components.


If one were to use an off the shelf passive USB hub would that solve the problem? If the hub fails, you buy a new one from the local electronics place, or off the web.


Oh, man, I see this one snowballing. Next thing it'll be n+1 redundant power supplies, backplanes/midplanes with redundant paths, redundant fans with sufficient capacity that if one or more fails its not a problem, and of course everything is hot swappable, right? 

The single problem with mono heatsinks as usually done (on the back of a board) is one of thermal transfer. If a chips is dissipating more than 10-15w then great care has to be taken regarding thermal vias and contact bumps on the board/heat sink interface to make sure enough heat can flow from the chip through the board/vias to the sinks. Even if done properly a naked chip is still going to run a fair bit hotter than one with a topside heat sink which in turn will directly set what the maximum speed/Vcore can be.

Now maybe if the chips can be mounted on one side of the board and all other components in the other to allow a single large heatsink contacting the tops of the chips-- that could work as it takes the boards thermal resistance right out of the picture.

You could probably take apart an S7 and strap lower-volume (in both nose and CFM) fans directly to the heatsinks and quiet it down. Part of the noise problem there is power density of the boards, and part is the overall heat density (and high pressure required by the solidity of the heap of heatsinks) of the miner. One of those problems is solvable by spreading it all out.

For this project, what you're suggesting will likely not be implemented. Mechanical design and manufacturing for a secondary optional everything-except-the-hashboards seems a bit of a stretch to ask for. My goal is to make the thing as quiet as possible within the given constraints.

Anything with a monolithic heatsink should be able to mount up to a waterblock. One of my goals (separate from the project discussed in this thread) is and has been for a while to build new boards in the S1 formfactor, and those should mount up nicely to C1 waterblocks.

Not really helpful, but:
I'd love to have a miner that would make it easy for someone to create a watercooling heatsink/block for it.
I have a wet dream of owning a house with a quiet, waterborne?, central heating system, powered by ASIC's! ^^

Also, would it be possible to make a 1000W miner "silent" by using a bigger enclosure? Instead of 2-3 boards packed in an S7 formfactor, that requires fans with high RPM and a high static pressure, could you spread it in a bigger formfactor so that you don't need high RPM fans? An enclosure like this would obv. be optional.
Would this work for an S7?

Can't wait to see the results from this project!  

/Sorry for my broken english..