GekkoScience BM1384 Project Development Discussion

[2112]

So the perfect hash chip would be:

1) 10x10mm QFP-EP or QFN-EP
2) Contact pitch = 1.00mm
3) Max Power consumption ~10W
4) Single belly pad for Grnd
5) Vcore supplied on pins on one side exclusively
6) 3 wire SPI interface ground plane referenced
7) Implemented in 14nm
Internal RTD
9) Internal Vcore current shunt
10) Mean targeted Hash Rate 100 GH/s
11) Targeted efficiency less than .1 W/GH/s
12) Cost per chip ~$3

What's the preference for setting clock analog or digital?
I'm assuming digital, but . . . .

What am I missing?

Perfect for whom?

I'm going to kinda restate what I wrote 2012 to friedcat, unfortunately he deleted his replies same day he made them.

https://bitcointalk.org/index.php?topic=91173.msg1062969#msg1062969

1) the case needs to be one of the many power analog IC packages, like the one for the popular L298N motor buffer chip. I'm not up to speed on this market anymore, so I don't know the current market trends. In the past the popular power package was an 8-pin variant of the TO-3. There are 7-lead variants of popular TO-220 available cheaply:

http://www.psitechnologies.com/products/todo220.php

using any package with multiple tens or even over hundred pads is completely pointless and greatly reduces the chip's reliability. The fact that the connections are repetitive (e.g. 10 * Vcc) doesn't matter as the silicon has negative temperature coefficient and those repetitive parallel connections are inherently unstable and susceptible to the thermal runaway.

2) the chip has to be from the start designed using the mixed-signal workflow. The hashing cores have such a high tolerance for errors that they have to be from the start designed as analog circuitry with individual choice of noise margins for each gate/transistor.

3) the only digital portions of the chip will be the overall glue logic and clock generation & distribution. UART is probably the best one could do because of the paucity&expense of the synchronous chips handling SDLC/HDLC/other reliable protocols.

4) It needs two-stage clock generation system, probably a simple internal multi-phase PLL and more advanced external PLL supporting fine tuning the operating frequency. The hashing chip is by necessity very repetitive and one can be assured of the existence of rather high-Q internal parasitic resonances. Some clock generators support spread spectrum clocking where the clock is continuously varied to avoid exciting resonances (both internal and external to the chip). Those spread-spectrum clock generators are cheap because people frequently use them to sidestep the FCC restrictions on spurious radio emissions.

5) If we are really into dream leagues then we can think of the Intel's planar integrated magnetics to move the voltage regulators to the surface of the chip.

[1714209703]

1714209703

[1714209703]

1714209703

[1714209703]

1714209703

[1714209703]

1714209703

[chiguireitor]

So the perfect hash chip would be:

1) 10x10mm QFP-EP or QFN-EP
2) Contact pitch = 1.00mm
3) Max Power consumption ~10W
4) Single belly pad for Grnd
5) Vcore supplied on pins on one side exclusively
6) 3 wire SPI interface ground plane referenced
7) Implemented in 14nm
Internal RTD
9) Internal Vcore current shunt
10) Mean targeted Hash Rate 100 GH/s
11) Targeted efficiency less than .1 W/GH/s
12) Cost per chip ~$3

What's the preference for setting clock analog or digital?
I'm assuming digital, but . . . .

What am I missing?

A supplier.............................

Touchè

[sidehack]

2112, I was kinda hoping you'd toss in an opinion. This is getting fun, and the innards specifics of a chip are well outside my knowledge.

I like TO220, but right-angle mounting heatsinks to boards changes mechanical concerns a lot. You do probably get better heat transfer from chip to sink than through the board, so instead of 50 10W chips you could run more like 10 50W chips which changes things again. High-power chips make string topology less feasible so efficiency is more of a concern, and making the best use of your machine's internal volume gets trickier when boards and heatsinks are at right angles. By no means impossible - but trickier. I'd still like to see something with a practical max of about 10-20W per chip as that gives you a lot more flexibility in varying designs.

A high-power part would limit flexibility in design by reducing modularity/granularity (you'd never see a TO220 effectively used on a USB stick) and, like existing high-current BGA designs, could increase the complexity and decrease the efficiency of regulator designs. I do agree wholeheartedly that "using any package with multiple tens or even over hundred pads is completely pointless" and makes every part of the process more difficult. What's an effective minimum number of pins for a mining ASIC using SPI with an internal PLL? Vcore and PGND, VDD_IO and SGND, and four for IO?

[sobe-it]

A high-power part would limit flexibility in design by reducing modularity/granularity (you'd never see a TO220 effectively used on a USB stick) and, like existing high-current BGA designs, could increase the complexity and decrease the efficiency of regulator designs. I do agree wholeheartedly that "using any package with multiple tens or even over hundred pads is completely pointless" and makes every part of the process more difficult. What's an effective minimum number of pins for a mining ASIC using SPI with an internal PLL? Vcore and PGND, VDD_IO and SGND, and four for IO?

I have hated BGA since all this BS with the xbox and ps3 systems. Hell laptops and video cards have the same issue but not as bad as the game consoles have had. I am surprised not many issues have popped up so far with the fact some of these mining machines using BGA run 24/7 for weeks on end and get pretty warm. But then again hardware usually gets less and less efficient every month and usually is squeezed out about 6 months after unless you mod/tune it. But there are people like me and mine till she blows or buys a new toy.

[2112]

2112, I was kinda hoping you'd toss in an opinion. This is getting fun, and the innards specifics of a chip are well outside my knowledge.

Thank you very much. I was hoping that you can take my comments not as a challenge, but as a simple exchange of ideas. Your experience seems to be complementary to mine, as I know more, and did more, of the inside-the-IC design as opposed to the general circuit/product level.

I like TO220, but right-angle mounting heatsinks to boards changes mechanical concerns a lot. You do probably get better heat transfer from chip to sink than through the board, so instead of 50 10W chips you could run more like 10 50W chips which changes things again. High-power chips make string topology less feasible so efficiency is more of a concern, and making the best use of your machine's internal volume gets trickier when boards and heatsinks are at right angles. By no means impossible - but trickier. I'd still like to see something with a practical max of about 10-20W per chip as that gives you a lot more flexibility in varying designs.

You need to stop thinking of "boards" and "large flat surfaces" as a necessary or desired property. We aren't designing a computer or anything like it. This is an problem in the class "embarrassingly parallelizable". Think of a series of very small boards electrically connected with two ribbons: one thick for power, one much thinner for signaling. The mechanical strength of the design will be provided by screwing the packaged chips to the large rail of aluminum heathsink. Or wrapping the chips around steel cylinder of one-stage water cooling loop.

A high-power part would limit flexibility in design by reducing modularity/granularity (you'd never see a TO220 effectively used on a USB stick) and, like existing high-current BGA designs, could increase the complexity and decrease the efficiency of regulator designs. I do agree wholeheartedly that "using any package with multiple tens or even over hundred pads is completely pointless" and makes every part of the process more difficult. What's an effective minimum number of pins for a mining ASIC using SPI with an internal PLL? Vcore and PGND, VDD_IO and SGND, and four for IO?

My idea of minimum pinout:

0) common ground on the heathsink
1) Vcore/analog
2) Vglue/digital
3) ClkCore
4) ClkGlue
5) RxD
6) TxD
7) Reset

When push comes to shove the last three could be rolled into one using some 1-wire communication protocol. Obviously Vcore/analog would carry the most current and the most power so it will become a limit when using non-custom packaging. So it will be more like 50*10W with non-custom fast-turnaround packages or 10*50W or even 2*250W with customized high-current slow-turnaround packaging (similar to e.g. https://en.wikipedia.org/wiki/Silicon-controlled_rectifier ).



I found better pictures under https://en.wikipedia.org/wiki/Thyristor

[sidehack]

Yep. Like I said in that other thread, if we started a fight over who's the better engineer I'd probably lose. Why not pay attention to the advice of someone with more experience in the particular field being discussed?

Course, being as I do work at the product level I have to consider the ease of manufacture, which single boards are a heck of a lot easier to work with than ribbon cables on the assembly line. Embarassingly parallelizable works in two dimensions but if you need orthogonal planes for things it starts to make things interesting.
If 10W range is what you get with non-custom ready packaging, it makes me like 10W range that much more.

I am not in favor of one-wire communication. No real reason to make both endpoints more complex in order to save a couple traces/leads.

What are your thoughts on the previous discussions regarding chained UART versus address-decoded SPI?

[2112]

I am not in favor of one-wire communication. No real reason to make both endpoints more complex in order to save a couple traces/leads.

I'm not in favor either. But I understand the constraints of the lead time. If you had a choice of your ICs delivered in 5-lead packages in 1 month or in 7-lead packages in 6 months, which one would you choose?

What are your thoughts on the previous discussions regarding chained UART versus address-decoded SPI?

I see this question as incorrectly posed. There are actually two independent choices in it:

1) UART vs SPI. On this I have no real preference, but way more experience with USARTs (that includes not only asynchronous but also synchronous devices/protocols.). Even the very lame UARTs have parity error detection, whereas very lame SPIs have nothing but "Hail Mary" protection.
2) Star topology vs daisy-chain topology. On this I prefer star because the ICs need to be running at the edge of failure (thermal or noise), otherwise the project is not competitive.

[sidehack]

1) Dunno. I'd probably start looking at a different seven-lead package because it'd be easier for me to retool mechanical than retool both silicon and software, especially if I had to retool mechanical for a package change anyway.

2) I also prefer star over chain for comms. I'm not so worried about clocked vs async so much as addressing, chip-select, collisions and whatnot. I kinda like how ASICMiner does it, with individual chip-selects for work distribution and polling from a single controller. If timeouts for work completion polling and queueing aren't done up right you can lose some marginal time efficiency but all that should be pretty easy to keep track of. You also don't get the problem of one chip bailing and taking out everything downstream - which, as you mentioned, is a definite risk. Daisychaining comms on a basic protocol makes it easy to run a board without a micro, but it's probably worth the extra complexity for the massive increase in overall reliability.

[PlanetCrypto]

Could you elaborate on the internal Vcore current shunt?

My thought was to build in the ability to sense individual chip current draw and knowing Vcore yields chip W consumption, which is a component of W/GH/s. This combined with a knowledge of clock freq would provide the data to fine tune individual chips for most economic operating point.

I envision this value would be stored in a register on chip and externally read only. The voltage off the shunt feed to a simple A/D (8 or 10 bit) sampled every 100ms might suffice.

[sidehack]

Ah, confused by imprecise terminology. A shunt current measurement, yeah that could be handy. However, any resistive power loss is going to affect overall performance. A 10W device at 0.7V runs 14A, so you lose 2% per mOhm shunt resistance unless there's a better way to do it?

With internal PLL and the ability to send commands to individual chips, it would be possible to set individual chip clocks. If you could also measure voltage and current per chip, that could also be used to help balance and stabilize strings.

[PlanetCrypto]

Perfect for whom?
Bitcoin miners?

I'm going to kinda restate what I wrote 2012 to friedcat, unfortunately he deleted his replies same day he made them.

https://bitcointalk.org/index.php?topic=91173.msg1062969#msg1062969

1) the case needs to be one of the many power analog IC packages, like the one for the popular L298N motor buffer chip. I'm not up to speed on this market anymore, so I don't know the current market trends. In the past the popular power package was an 8-pin variant of the TO-3. There are 7-lead variants of popular TO-220 available cheaply:

http://www.psitechnologies.com/products/todo220.php

F'ing brilliant, have worked with 3 phase motor controllers that were 15 pin packages (if memory serves). Just trying to envision what the chip/heatsink/board combo would look like.

2) the chip has to be from the start designed using the mixed-signal workflow. The hashing cores have such a high tolerance for errors that they have to be from the start designed as analog circuitry with individual choice of noise margins for each gate/transistor.

In the Synopsys world of IP things these SHA-256 cells are a proven item down to 14nm. I assume that they have taken that into account (... noise margins for each gate/transistor).

3) the only digital portions of the chip will be the overall glue logic and clock generation & distribution. UART is probably the best one could do because of the paucity&expense of the synchronous chips handling SDLC/HDLC/other reliable protocols.

First off I've worked more with SPI, so I'm biased in that direction. My gut feeling is that SDLC/HDLC/LAPB et.al seems like overkill from a protocol perspective. Probably am FUBAR. Obviously I need to take a second look.

4) It needs two-stage clock generation system, probably a simple internal multi-phase PLL and more advanced external PLL supporting fine tuning the operating frequency.

Exactly my thought. Was thinking an external clock feeding an adjustable internal PLL clock divider. In/on multiple chip boards one common external clock feeding multiple chips. That clock input could be configured on a chip by chip basis based on a writable register setting. Thereby allowing each chip on the board to be clocked differently.

The hashing chip is by necessity very repetitive and one can be assured of the existence of rather high-Q internal parasitic resonances.

Makes perfect sense.

Some clock generators support spread spectrum clocking where the clock is continuously varied to avoid exciting resonances (both internal and external to the chip). Those spread-spectrum clock generators are cheap because people frequently use them to sidestep the FCC restrictions on spurious radio emissions.

This is a snippet of info I was totally unaware of. Thanks. Typically, do these clock generators "slide" the freq up and down or are they selecting a predetermined freq from a pool of freqs and then hopping amongst them?

5) If we are really into dream leagues then we can think of the Intel's planar integrated magnetics to move the voltage regulators to the surface of the chip.

That sounds dreamily expensive, if for no other reason than it has the word "Intel" in it. lol

[PlanetCrypto]

Ah, confused by imprecise terminology. A shunt current measurement, yeah that could be handy. However, any resistive power loss is going to affect overall performance. A 10W device at 0.7V runs 14A, so you lose 2% per mOhm shunt resistance unless there's a better way to do it?

There probably is a better way to do it, just me being ignorant.

Isense resistance in bucks is, from my experience, in the mOhms. On/in chip, I think that can be dropped 1 or 2 (maybe 3) orders of magnitude resistance and if necessary use a more sensitive higher precision A/D say a 12 - 14 - 16 bit A/D versus an 8 or 10 bit.

With internal PLL and the ability to send commands to individual chips, it would be possible to set individual chip clocks. If you could also measure voltage and current per chip, that could also be used to help balance and stabilize strings.

Yes, and with an internal RTD one could throw Tj into the calculation mix as well.
I'm sure I'm not the only one who has observed the hash rate drop as a unit heats up.
If one can control the Vcore and clock one might be able to mitigate this effect and re-fine tune it for changing ambient conditions.
Additionally, it would, like some CPU's do, allow a sliding scale of operation.
Protecting the chip from damage while allowing reduced capacity operation.
As opposed to say the Bitmain S(odd) which when it hits the magical 80C stops entirely.

[PlanetCrypto]

"With a 10x10mm you could probably go 12-15W without a lot of problems, thinking from a chip-level power density scale (though it would depend on actual die size and Tjc) - if we're comfortable with 10W from an 8x8, 10x10 has 1.56 times the surface area for heat transfer."

Couple of reasons I like 10W:
1) Like to try to be conservative for longevity's sake.
2) Overclockers (like me) will push a design way past factory recommendations.

[PlanetCrypto]

I am not in favor of one-wire communication. No real reason to make both endpoints more complex in order to save a couple traces/leads.

I'm not in favor either. But I understand the constraints of the lead time. If you had a choice of your ICs delivered in 5-lead packages in 1 month or in 7-lead packages in 6 months, which one would you choose?

What are your thoughts on the previous discussions regarding chained UART versus address-decoded SPI?

I see this question as incorrectly posed. There are actually two independent choices in it:

1) UART vs SPI. On this I have no real preference, but way more experience with USARTs (that includes not only asynchronous but also synchronous devices/protocols.). Even the very lame UARTs have parity error detection, whereas very lame SPIs have nothing but "Hail Mary" protection.
2) Star topology vs daisy-chain topology. On this I prefer star because the ICs need to be running at the edge of failure (thermal or noise), otherwise the project is not competitive.

I'm going with the 5 lead in 1 month, given the rate at which designs become obsolete in the BTC ecosystem.

[Cablez]

It is so refreshing to see conversations like this in hardware now.  No flaming, no trolling just an honest exchange of ideas.  Keep it up gents.  Some of us may not be adding to the discussion but we are intently reading it. 

[heslo]

It is so refreshing to see conversations like this in hardware now.  No flaming, no trolling just an honest exchange of ideas.  Keep it up gents.  Some of us may not be adding to the discussion but we are intently reading it. 

Agreed! So many great minds in this community

[PlanetCrypto]

So the perfect hash chip would be:

1) 10x10mm QFP-EP or QFN-EP
2) Contact pitch = 1.00mm
3) Max Power consumption ~10W
4) Single belly pad for Grnd
5) Vcore supplied on pins on one side exclusively
6) 3 wire SPI interface ground plane referenced
7) Implemented in 14nm
Internal RTD
9) Internal Vcore current shunt
10) Mean targeted Hash Rate 100 GH/s
11) Targeted efficiency less than .1 W/GH/s
12) Cost per chip ~$3

What's the preference for setting clock analog or digital?
I'm assuming digital, but . . . .

What am I missing?

A supplier.............................

Touchè

In brief, this is what (a supplier) we (PlanetCrypto or a spin off LLC) are seriously investigating.
I'll be the first to admit that chip design is not a skill set I possess. In fact, one might say I'm clueless in that regard.
I do know that it is a skill set that can be learned, acquired, and worst case bought and with the guidance and brilliance available here I believe it's a doable thing.
I also believe that with a looming block reward decrease and serious talks about increasing block size to 20 Mb, little miners are doomed.
http://www.cnbc.com/2015/07/23/bitcoins-war-could-threaten-its-survival.html
This is not something that I believe is a healthy direction for the Bitcoin ecosystem to travel down. But WTF do I know anyway.

Since none of the "big 4" chip makers have any decent chips/boards/miners available, an opportunity to fulfill that need exists.
And if we're gonna "take the plunge" I'm in favor of "doing it right".

Will we get a chip to tape out?
Only time will tell.
But since no one else seems to be pursuing it, we're gonna' give it a shot.
If we fail to tape out a hash chip then at least the "brain working" will be completed for a "next gen" hash chip that another entity could "pick up the ball and run with".

For us as a company the timing is synergistic as we have 2 other chip designs in the conceptual stage of development.
We own some of the physical assets necessary (a small computing farm most notably) to get through the design/simulation process.
Our current plan is to concentrate on the hash chip first because it's the most time constrained and in the "dead spots" of getting that chip to tape out move forward on the other 2 designs.

And at the risk of alienating potential participants, I also believe it's about time for an American supplier (who is the antithesis of BFL) to enter the mix.

Not trying to be caustic, just figured we'd justify/clarify why we're cluttering up sidehack's thread.

[sidehack]

Yeah, a fair bit of discussion lately has shifted away from our BM1384 designs. Should we start a new thread just for chip design ideas? I have no complaints about the thread so far, but it might be handy to keep track of things better if we're not bouncng between two or three different conversations.

I'm all in favor of an American chip supplier - one that's not going to screw everyone over and/or go bankrupt, at least. I mean we've already seen how many US manufacturers come and go in the last couple years? If we can keep the intention fairly community-based instead of single point greed like a lot of the big guys, margins might be slim but a whole lot of people would benefit. If PlanetCrypto is already figuring out how to do the heavy lifting, I'm certainly going to do what I can to help.

[TheRealSteve]

I'm all in favor of an American chip supplier - one that's not going to screw everyone over and/or go bankrupt, at least. I mean we've already seen how many US manufacturers come and go in the last couple years?

Entirely rhetorical, I know, but for chips I think it's only been 3? BFL, CoinTerra , HashFast.  Not counting the ones that failed to launch, only have private claims (21, Inc.), or are U.S. registered (among other) mostly for presence sake.

On the bright side - the U.S. isn't alone in companies having come and gone.  Just look how few are left over from the Asian market compared to how many there have been.  Same for Europe.  It just tends to blow up more when it's U.S. companies in part due to the legal system and the media coverage.

In case this does get split off to a new thread: good luck, regardless


In terms of this thread - I spent the better part of the afternoon salvaging valuables off of computers to be decommissioned at work, and found a nice heat sink that was on a ... well, not sure actually.. some VIA chipset anyway from a 2004-era machine.  Looks like this, minus the wings.

So I can cut that down to size some and stick it to the back of my 'engineering sample', give it a bit of (GekkoScience) green after all

[sidehack]

Yeah, those three are the ones I could think off offhand and am not particularly fond of any of them. The two that went overtly bankrupt after screwing customers both also built chips in form-factor I despise, and the third that somehow avoided getting thrown in jail should be thrown in jail despite actually eventually coming up with decent gear, so not really too impressive a showing. I'm biased toward US companies because I sorta am one, and there are a whole lot of miners in the US that can only buy imported gear which sucks. That we can only import sucks, not necessarily the gear. Some of it's alright.

Heatsinks for the Compac batch are on order, and probably about that color green. PCBs are also on order. It took a bit longer to get them out because we were discussing what we wanted for panelling and stencils and such.

We're also still having trouble convincing the mother@!#$ pick-and-place manufacturer to actually solve the @!#$ problem and get us our @!#$ machine. We expected delivery actually slightly earlier than they ended up shipping it. We've asked if they'll ship us another unit so we don't get screwed while they work out how to get their returned unit back from DHL, but they'd apparently rather not actually meet customer needs. Which of course the whole thing would have been avoided if some jackass in shipping wasn't too lazy to copy-paste our phone number into the order details - which some less-lazy jackass in shipping specifically asked us for exactly to avoid what's happening now - so US Customs would have actually known who to talk to so it could be cleared. Not happy about that. So, it's entirely possible Compac delivery will be delayed because a problem whose solution was provided IN ADVANCE SEVEN WEEKS AGO happened anyway and has yet to be resolved.

Meanwhile, well, I reckon we'll continue to work on multi-chip designs and Compac driver support. I'll be honest though, the heat index right now is 105F so there's probably not much gonna get done that doesn't get done between 7AM and noon this week.