Topic: GekkoScience BM1384 Project Development Discussion (Read 146713 times)

Ahh yes I had lots of fun dealing with the transients in my design. At least for the scrypt chip I'm dealing with it was not that bad because the transients occurred at the end of each hash cycle...which for this chip was in the range of 10-20 khz, so even at a 250 kHz switch rate it was manageable and enough spacing to decouple any resonances. Im pretty sure SHA cores have hash cycles in the 100s of kHz, which would be pretty nasty for a 250 kHz buck.

Well, I can't exactly change the layout on an existing board without getting a new board. And as I said in that post you quoted, immediately after the part you quoted, "If I gotta change the layout in a major way like that it'll mean getting new prototype PCBs which will burn an extra week or two and probably a couple hundred bucks." Since it's been about five days (quite a bit less than two weeks), no I haven't gotten it figured out - or at least, I haven't yet verified that the changes I made to the design actually work yet.

Sidehack:

Did you get this figured out? I had a similar problem on one of those TI TPS chips and I never really figured it out. I had to rev the board to fix another problem and on the new rev I did a better job of making the layout match the "suggested layout" in the datasheet. Worked just fine on the new layout... so take that as a my BTC0.02

Good luck!

-a[g

Just tossing this info out there so folks can have an idea of what happens when power is getting from the regulators to the chips. http://powerelectronics.com/power-electronics-systems/five-things-every-engineer-should-know-about-pdn
Not just a matter om having path from point-A to point-B. Needing to take into account lumped-component values and resonances they can cause, it can be more like designing power RF circuits.

Edit: Add to that this rather graphic bit on what can easily happen to an ASIC's power... http://powerelectronics.com/community/why-pdn-measured-using-vna-and-not-oscilloscope?page=1

resistive load step response:

Same load step with just 1 resonant node in the PDN:

It does shift 'em a bit, but not a lot. The level shifter takes things up about 0.7V from local ground so it's pretty well in the middle of the 0.6-0.8V range. It'd be nice to cook up something that shifted it up exactly to the next local ground, but the best thing I've come up with requires a bunch of parts. What I'm doing on the pod is pretty similar to what Bitmain did on the S5 (my oscillator line is different); not perfect but keeps things within thresholds at least as far as I've tested. Admittedly I've been testing more at the high end of the voltage range, haven't really gone much below 700mV average node. The high side of IO voltage isn't really a problem (1.6V is just as good as 1.8V to those chips), the low threshold is what really matters. According to the datasheet, input low is acceptable between -0.3 and +0.6 so +/- 200mV from local ground should be fine.

Does the BM1384 have isolated ground lines on the IO? If your changing core voltage on the string won't that shift the relative ground voltages and throw off your IO dividers? Unless your just igorning it and it operates fine with IO voltage going from 1.8v +/- 200mv or so.

So last night I was jacking with the pod via SSH from the house, and of course the controller locked up on me. So I didn't get any good overnight data since it wasn't hashing. Before I left for burgers I was running it at 300MHz and noticed the bottom of the board getting pretty hot (one of the chips caused some visible discoloring on the board underside) so I spent a few minutes drilling and tapping an old Cube heatsink and got the Freezer7 mounted tight on it. Pushed the voltage up a bit (average 805mV per node), fixed the fan running too slow, and restarted at 350MHz. So it's been running at that speed for about 2.5 hours, average about 149GH (154 calc) with 0.025% errors and the WU at about 98.5% of what I expect. So that's good news. I'm reworking the layout today inbetween other things, hopefully getting it to functional. The new pod will also feature some handy stuff I forgot on this one, like breaking out signal lines to the ASICs so I can actually test things without trying to solder jumper wires to 0603 resistors and 0.5mm pitch pads.

Later on I might switch it over to a custom worker on the burger address so y'all can keep track of it. I've got the strap-on buck board running at pretty much the same as my design so power use and efficiency should be about the same. I just marked the board (not including fan and controller) at 11.86V 6.0A for 71.2W, which if it puts up the expected 154GH gives me about 0.46W/GH board-level. That's a number I'm okay with. If it holds up, I'll push it to 400MHz and see what happens.

The strap-on buck, as it's its own postage-stamp-sized board and not tied into any large planes, is getting rather warm - but when you consider it's delivering about 70W to ASICs it's allowed to. One of the benefits of a bucked string is you still lose about the same amount of power in your buck as with a low-volt VRM (since the losses are pretty much proportional to swich rate and current output) but the overall efficiency is way better because the output power is however many times higher on account of substantially increased voltage. Do I hear Bitmain is doing something like that on some of the new S7?

Well, the last change I made to the PCB killed the buck. Some pads were getting pretty frail, and some were already missing, from repeated changes and rework. I said I'd get it back to functional and then start fresh on a new board, but I guess I hosed something in the bootstrap without noticing it because it died. Nuts. So I pulled everything and put a fresh hacked '53 just sitting on top of the board and it's running 250MHz now. Not quite perfect; I'm seeing only about 90% hashrate average after six minutes or so but maybe it's still warming up. The 225MHz self-contained run overnight saw 97GH (99GH calculated) and 10 HW errors in 18 hours. Not bad.

So I guess I'll have to start fresh on a new PCB anyway.

The hacked '53 has 0.1uF bypass cap on the VREG5 and 2.2uF bypass on VDD (which is powered from 12V). I can definitely see some RC ripple on the 5V line when it's mining; it gets noticeably worse when the power kicks in and we get into full CCM. But the average is still, according to my scope, around 5.1V. The almost-idle average I was measuring on my board was 4.9V and the full-power average, I could keep it running stable with 4.1V there. There are two components different on the feedback circuit, but they should be fairly trivial - it's two of three parts across the inductor making a bit of ripple injector into the feedback to help stability with low-ESR outputs. The third component is not populated, so these parts might, I don't know, help shunt some HF around the inductor?

About the best thing I can think of is it's a layout issue. Perhaps my buck chip is too close to the inductor. Or the bootstrap circuit is hosing with me? Waveforms look pretty much the same with mine and the hacked, on the hacked it was backside components so fairly shielded from inductor noise. If I gotta change the layout in a major way like that it'll mean getting new prototype PCBs which will burn an extra week or two and probably a couple hundred bucks. I might have to raffle off some of these boards (guaranteed to 200MHz probably would be the best I could do) to help cover. If Novak's got working firmware by then they'd be self-contained, or I'd have to cook up a simple adapter you could cable into an S5 controller. Or I could keep the bucks unpopulated, fill 'em all with hacked '53 boards that let you run higher frequency. Without Novak's controls you'd have to either measure or guess the core voltage (like on the Compac) which isn't the best, but folks would know that going in. I'll see how reliably my hacked-powered board runs over the next few days and decide next week what to do.

Speaking of, now after 32 minutes or so I'm seeing about 95% expected hashrate, .0063% errors.

Haha exactly! I live in an apartment and the electrical here sucks!

^This!

Happy new year and keep up the good work! It's nice to know there's someone out there building miners for those who don't want 1000+ watt monsters

According to the pool, it's still chugging along at just shy of 100GH, which lines up pretty much perfect with the 99GH calculated hashrate. Hopefully tomorrow I can work out the buck problems and get it up to, say, 350MHz which would get me about 150GH. That'd be pretty spectacular.

Oh yeah. Happy new year and all that crap. It's been slightly over a year since we started thinkin' about building a miner. 'Bout darn time I have something to show for it, eh?

Impressive either way. Keep up the good work!

Be strange for two similar designs using the same chip to require a hundred times the bypass but I guess it's possible. It's also after 5PM and that means it's about eatin' time and I kinda want to go home so I'll probably mess with it tomorrow.

Try sticking a 10uF on VDD and see what that does.

I've got a 1uF and a 0.1uF on VREG; VDD is tied to 12V and has a pair of 2.2uF on it. The hacked '53 has only a 0.1uF on VREG. Upping VREG bypass from 1uF to 2.2uF had zero effect. The external source is a bigger LDO also powered by 12V.

Weird...well you shouldn't tie VREG to an external source, since the LDO is powered from VDD anyway (unless you don't have VDD connected to 12v). Do you have at least a 1 uF bypass cap tied to VREG, and a 4.7 uF input cap to VDD?

Not a gorram thing. Only stuff pulling from the internal LDO are the chip's own innards. The only substantial difference between what I'm running now and the hacked '53 is the switch rate - I'm at 500K where the '53 was set more like 1MHz. I'm not sure how that could make things better, especially considering the bulk of current draw would be to gate drives and that would double when the switch rate goes up.

Tying the VREG to an external 5V source actually makes things worse. The output voltage loses any semblance of regulation or stability, such that it won't even light up at 100MHz.

Upping the resistor on the bootstrap cap from 2ohm to 4.7ohm made things worse. Took it back down and it's running stable again at 225MHz but only just.

What are you running of the internal 5v LDO, and how much current is it pulling?

Just thought I'd show this off a little. Right now I can't get it to work past 225MHz (99GH) because the regulator is dropping out. I know what particular symptom is causing the dropout, but I'm as of yet unable to figure out what's causing that symptom. Basically, the internal 5V LDO on the TPS53355 is sagging when it starts to push more power. The initial problem with resetting I was running into was based on this - the bootstrap was drawing too much current during switch, causing the LDO to bottom out below threshold and reset the chip. I fixed that problem enough that now it starts, and it looks like I have stable hashing at 100% which is great. But when the current ramps up from either too high voltage at a given frequency (right now, if I turn it up any farther at 225MHz) or too high frequency at a given voltage (it should run 250MHz at the current voltage setting if the buck would allow it) the VREG5 slides down below 4V and resets power, which kills my string. I am primarily vexed because the hacked '53 I was using earlier did not have this problem. Its 5V was stable all the way to 820mV 300MHz.

If anyone has some fresh insight as to why an internal LDO would bottom out so badly, let me know. I'll be poking for the next couple hours and hopefully I'll figure it out and won't need advice, but there's a lot of smart people around here and it rarely hurts to ask.

But for now I have a stable 100GH miner. Which is pretty cool. Basically I have an S2 board with 1/8 as many ASICs and approximately 1/3 the power draw. Not good enough yet to sell, but still pretty good. When it'll run 350MHz stable I'd call it good enough to sell, but then I'd keep tweaking until it could do 400MHz pretty reliably. That should give Novak time to finish up the controls firmware.