GekkoScience BM1384 Project Development Discussion

[TheRealSteve]

If anything, provided the chips are good to work with, it merely changes it to "GekkoScience BM1385 Project Development Discussion" with a more certain future as to chip availability.  Or so one can hope anyway

[1714830080]

1714830080

[1714830080]

1714830080

[elrippo]

If anything, provided the chips are good to work with, it merely changes it to "GekkoScience BM1385 Project Development Discussion" with a more certain future as to chip availability.  Or so one can hope anyway

Agreed, but the designprocess starts right over again. GekkoScienceBM1384 should be burried and BM1385 should see the light IF GekkoScience gets BM1385 from Bitmain...

[valkir]

Sidehack already said that the project will follow the new chip. So I guess he will try to get some BM1385. 

[itop_james]

Hope you guys to get the newest BM1385 chip soon , it is really great .

[aarons6]

i really cant wait for those 18 chip boards now.

[sidehack]

I've already emailed Bitmain about potential samples of BM1385. I'd really like to see an efficiency curve on it. The reference point of 0.216W/GH at 0.66V is about 30% better than the 0.30W/GH at 0.66V we see with BM1384; if the curve stays about 30% lower across the range it'll, oddly enough, be pretty much exactly what I was guessing they'd come up with when I was speculating about new chip performance something like three months ago. If that 0.216W/GH is top-clock performance (which I kinda doubt, but who knows) it's better than I was guessing.

To elrippo, who says "but the designprocess starts right over again", I just time-travelled back about two days and preemptively posted "Retooling a proven working BM1384 board for a different chip would be maybe 20% of the electronics work of designing a whole board, so I'd like to go ahead and finish it and then hope we get access to a new chip I can shoehorn in." And actually, a new generation of the same manufacturer's chip would take even less work. Bitmain has always used the same comm structure and protocol, so data lines don't change. Core voltages change - well that takes about half a day of recalculating buck parts. Footprint changes - there's a day or two drawing new pads and rerouting some things. Driver changes? Minimal. Tertiary changes like fan control and temp sensing are unnecessary.

GAME ON.

[PlanetCrypto]

That thread was about three down from the top when I looked for it. I haven't actually read almost all of it though, so I'm not really sure where they are. I think making something USB to drive an S5 controller shouldn't be too difficult hardware-wise but I'm not sure about the software.

sidehack - you should read the last 5 pages in the thread, may be a product GS might want to supply as the primary circuit guy indicated he was NOT going to manufacture and sell.
And yes it's a simple circuit. PCB'ed would probably be a board about the size of a Prisma 1.0 USB/UART board. It, evidently, also requires some reflashing of the controller. The code for which seems to be in flux, at the moment.

PlanetCrypto - have you talked to Bitmain, Avalon or LK at all?

Negative.

Gave up on Bitmain as you seem to have better luck than us. Should we continue to pester them for chips?

Will reach out to Avalon about the 3222 and LK about the 14nm Innosilicon unit today.

Will also query Innosilicon about obtaining a couple of their test units. If they acquiesce (and that's a big IF), likely that will require an NDA, are you cool with that?
Assuming they will part with a couple and they require an NDA, nothing about that unit could be used to forward any 14nm project the community might develop.
I'm really not interested in getting into the drama over an IP pissing contest. Much less the lost revenue over a non-innocent infringement law suit.

[sidehack]

Well Bitmain just put up word of a new chip (minimal details) and I've already emailed them to ask about it.

Don't bother asking about Avalon's 3222. It's a year old and worse efficiency than the BM1384. I want to know about new stuff they might be working on, but I haven't had any news in a couple months.

I'd pay hansomely for Innosilicon samples. Whether I'd sign an NDA or not would depend on its contents. If they want us to not talk about their chip details to anyone else, that's fine, but if the NDA also covers base design stuff over the miner I'd build around their chips, that's a no-dice because about almost all of the hardware portion of what I'm working on is designed to be flexible enough to work with just about any chip and it'd be stupid to glue it to one particular ASIC at the risk of a lawsuit.
I would trade money up front for their chips, but I would not trade rights to our designs or any kind of residual royalties. Their chip not feeding into community design makes sense (it's their design and all), but my miner built around their chips probably would because it's my gosh dang miner, not theirs, and I'll do with it what I want.

[PlanetCrypto]

https://bitcointalk.org/index.php?topic=1156853.msg12182569#msg12182569

needs to be translated.

The BM1385 is, evidently, a 28nm process.

[sidehack]

https://bitcointalk.org/index.php?topic=1156770.0

Yes, 28nm. I figured they'd do 28nm again and get about 30% more out of it than the BM1384, which preliminarily looks to be about right. They might have even beaten my expectations depending on where on the curve the one sample data point they've given lands.

[PlanetCrypto]

Well Bitmain just put up word of a new chip (minimal details) and I've already emailed them to ask about it.

Am VERY curious about their response.

Don't bother asking about Avalon's 3222. It's a year old and worse efficiency than the BM1384. I want to know about new stuff they might be working on, but I haven't had any news in a couple months.

Concur the 3222 is junk.
Will ask about un-announced stuff.

I'd pay hansomely for Innosilicon samples. Whether I'd sign an NDA or not would depend on its contents. If they want us to not talk about their chip details to anyone else, that's fine, but if the NDA also covers base design stuff over the miner I'd build around their chips, that's a no-dice because about almost all of the hardware portion of what I'm working on is designed to be flexible enough to work with just about any chip and it'd be stupid to glue it to one particular ASIC at the risk of a lawsuit.
I would trade money up front for their chips, but I would not trade rights to our designs or any kind of residual royalties. Their chip not feeding into community design makes sense (it's their design and all), but my miner built around their chips probably would because it's my gosh dang miner, not theirs, and I'll do with it what I want.

Concur 100% with all your points.
1) test chips for us is moot, production chips is a different animal.
2) Your IP on board design is yours and should not be restricted by a chip supplier.
3) we would not be interested in an NDA regarding anything pertaining to their 14nm dev, design, production, etc. due solely to the idea we would be involved in an independent 14nm design.
4) we would exuberantly pay excessively for test chips.

Having said that, we would be willing to "broker a deal" that meets Innosilicon and your parameters. As greasing the wheels of motion benefits us. i.e., Their chips on your boards.

[elrippo]

I've already emailed Bitmain about potential samples of BM1385. I'd really like to see an efficiency curve on it. The reference point of 0.216W/GH at 0.66V is about 30% better than the 0.30W/GH at 0.66V we see with BM1384; if the curve stays about 30% lower across the range it'll, oddly enough, be pretty much exactly what I was guessing they'd come up with when I was speculating about new chip performance something like three months ago. If that 0.216W/GH is top-clock performance (which I kinda doubt, but who knows) it's better than I was guessing.

To elrippo, who says "but the designprocess starts right over again", I just time-travelled back about two days and preemptively posted "Retooling a proven working BM1384 board for a different chip would be maybe 20% of the electronics work of designing a whole board, so I'd like to go ahead and finish it and then hope we get access to a new chip I can shoehorn in." And actually, a new generation of the same manufacturer's chip would take even less work. Bitmain has always used the same comm structure and protocol, so data lines don't change. Core voltages change - well that takes about half a day of recalculating buck parts. Footprint changes - there's a day or two drawing new pads and rerouting some things. Driver changes? Minimal. Tertiary changes like fan control and temp sensing are unnecessary.

GAME ON.

@sidehack
That was not meant as an offence, i personally blow the same whistle as you do. I just wanted to inform you as quick as i was able to, to let the 1384 design rest in peace.
I am not familiar with designs of chips, so i stick to your opinion and expertise.
IF you take out another 30% of the 1385 than you are sure a lot of community applause 

[sidehack]

PlanetCrypto - I'm not terribly concerned about what's going on inside their chip as long as it works as advertised. As much as I hate abhorring black boxes, I accept that the finer points of silicon dev are outside my realm of specific interest so yeah, I have no problem not knowing their IP on it. All I need is footprint, power specs and protocol info so I can talk to it.
I was just telling Novak yesterday I'd gladly put up a hundred bucks for half a dozen chips just to see what they can do. It'd be nice if that wasn't necessary.

I think today I'll try and grab some time to talk with Novak a bit more and actually write out the specs we've come up with for a modular standard rack miner. If, somehow, we end up (between our own efforts and yours) working with multiple chips, it'd be handy to have a default form-factor to work around and I'd like to see some discussion around what we've come up with, see if the idea can't be improved.

Elrippo - I didn't take it as an offense, just probably unnecessarily sarcastically responded because the point has already been addressed. I sincerely hope I don't have to restart the design process, and I trust the flexibility of our base design concept. I also trust its general superiority over existing designs from the major manufacturers and I really hope I'm right about that part. The BM1384 design will be completed unless we get better chips in the very near future, but I gave up on the idea of selling large-scale BM1384 boards (past the Compac) over a month ago. Until I get access to new chips, it's still technically a BM1384 project, but I also hope that the BM1384 dependence will soon be retired.

[AJRGale]

I've been thinking, what's the difference other then the footprint, between the BM1382 and the BM1384? if i was to deadbug a 84 to a 82 footprint, would it work?

since you're using a U3 code to run a 84 chip, and the U3 uses 82 chips, I had a thought to scratch up an adaptor board for the U3 to link the footprint of the BM1382 to the footprint of the BM1384.. But it cant be wire to wire compatible, can it?

just like the old Pentium 3M mobiles to the P3 desktop sockets..

[sobe-it]

I've been thinking, what's the difference other then the footprint, between the BM1382 and the BM1384? if i was to deadbug a 84 to a 82 footprint, would it work?

since you're using a U3 code to run a 84 chip, and the U3 uses 82 chips, I had a thought to scratch up an adaptor board for the U3 to link the footprint of the BM1382 to the footprint of the BM1384.. But it cant be wire to wire compatible, can it?

just like the old Pentium 3M mobiles to the P3 desktop sockets..

wont work, different pad layout under the chip.

https://bitmaintech.com/files/download/BM1382_Datasheet_v3.0.pdf

https://bitmaintech.com/files/download/BM1384_Datasheet_v2.1.pdf

[sidehack]

Different number of pins, different belly pads. Protocol changed a bit I think, because the U3 code Icarus) won't drive chained BM1384 properly. It works for a single chip but it's not divided up right for multiple like S5 code does. I've tested an S5 controller on our own multi-chip board and it worked, but U3 code ended up passing the same work to both chips and I got 50% duplicate shares back out of it.

[AJRGale]

I've been thinking, what's the difference other then the footprint, between the BM1382 and the BM1384? if i was to deadbug a 84 to a 82 footprint, would it work?

since you're using a U3 code to run a 84 chip, and the U3 uses 82 chips, I had a thought to scratch up an adaptor board for the U3 to link the footprint of the BM1382 to the footprint of the BM1384.. But it cant be wire to wire compatible, can it?

just like the old Pentium 3M mobiles to the P3 desktop sockets..

wont work, different pad layout under the chip.

https://bitmaintech.com/files/download/BM1382_Datasheet_v3.0.pdf

https://bitmaintech.com/files/download/BM1384_Datasheet_v2.1.pdf

Yep, as I said, different footprint. just like the Pentium3 mobile to the pentium 3 desktop, I was thinking of a converting pcb between the main pcb to the chip.

Different number of pins, different belly pads. Protocol changed a bit I think, because the U3 code Icarus) won't drive chained BM1384 properly. It works for a single chip but it's not divided up right for multiple like S5 code does. I've tested an S5 controller on our own multi-chip board and it worked, but U3 code ended up passing the same work to both chips and I got 50% duplicate shares back out of it.

so there is a communication protocol change too. The power plane pads are just the power pins condensed, the comm pins are basically the same, just except in different areas.

but as you said, the U3 code can't enumerate the stringed chips.

[sidehack]

Unless I was doing something wrong, but given the string'd 1384 pair worked fine off S5 controller and not a straight CP2102 like the U3 (the only difference between the two, as far as connection goes, is the S5-tied had a driven reset line) I'd guess the same would still apply to a jerry-rig. The limitation is in the Icarus driver, near as I can tell. Could be a small change to that might fix it but I'm not really gonna worry about it.

[AJRGale]

Unless I was doing something wrong, but given the string'd 1384 pair worked fine off S5 controller and not a straight CP2102 like the U3 (the only difference between the two, as far as connection goes, is the S5-tied had a driven reset line) I'd guess the same would still apply to a jerry-rig. The limitation is in the Icarus driver, near as I can tell. Could be a small change to that might fix it but I'm not really gonna worry about it.

yeah, it was just a thought I might throw at you.. The only other thing other then the U3, I had that was stringed and directly to a CP2012 was them Zeus branded chips for s-crypt mining. everything else used a controller.

(we have come a long way here, 81st page and this is the 1601st post, I remember coming in here half reading everything and demanding pictures!)

[sidehack]

Indeed. And with today's bit of information on BM1385 I had to rethink a bit, which means scrapping some of the power design I had planned for the 18-chip Spec1 but it's okay because now it'd be more unified with the 30-chip Spec2. Of course the chip counts are likely to change. That change shouldn't cost much time to a decent prototype, which means time to more sexy prototype pictures.