<daveshah>
Two ground planes works alright with enough vias to stitch the two
<daveshah>
One ground plane and one Vcc plane both will end up awfully split though, which is why its a problem
<sorear>
if you have two ground planes, then by definition you have at least 3 layers ?
<SolraBizna>
it's not a full plane, it's a polygon fill(?)
<SolraBizna>
pour
<daveshah>
EE ≠ math
<cr1901_modern>
presumably with the caveat that "most traces don't exit the region a plane covers
<sorear>
I thought "plane" meant "an entire PCB layer"
<sorear>
obviously a plane is not going to extend to infinity in all directions like a geometrical plane
<SolraBizna>
that's sure what I use it to mean
<cr1901_modern>
sorearcc -pedantic-errors
<sorear>
although if you have a PCB with infinite diameter I would like to see it
<SolraBizna>
FACT had to be a four-layer board just so I could get at the tasty, tasty insides of a 256-ball BGA... so, everywhere except directly under that part, I'm using the inner two layers for "real" planes
<SolraBizna>
I pretend to know nothing about AC, but looking at all the corners and islands the UPDuino's "planes" have makes me a little nauseated
<daveshah>
The Upduino is awful
<SolraBizna>
Then again, I can't look directly at the board because of the weapons-grade LEDs :P
<daveshah>
It should so obviously be a 4 layer board
<daveshah>
But obviously the extra 10c that would cost kill it
<cr1901_modern>
I _wish_ for low quantity work 4 layer was 10c extra lmao
<daveshah>
It's not that expensive from someone like elecrow
<daveshah>
If buying a single batch either way the boards are less than DHL shipping
<Bob_Dole>
are there any good low-cost up5k boards?
<daveshah>
icebreaker is probably your best bet as a general board
<daveshah>
Only problem is the lack of a availability atm unless you're going to ccc
<azonenberg_work>
daveshah: with 4L it's generally possible to get decent signal integrity even with planes being split up
<azonenberg_work>
most of the time you can have a little finger of vccint going into the middle of the fpga then vccio around it
<azonenberg_work>
with signals referenced to the relevant vccio
azonenberg_mobil has joined ##openfpga
azonenberg_work has quit [Ping timeout: 272 seconds]
<mithro>
Anyone have recommendations for the best way to extract a couple of traces out of a larger VCD into a small VCD file? I've been using gtkwave manually at the moment.
<azonenberg_mobil>
write a little script? vcd isnt exactly a complex format
<q3k>
script++
<q3k>
i usually ad-hoc implement some python for that
<q3k>
not sure if there's (now) a good library
futarisIRCcloud has joined ##openfpga
Flea86 has joined ##openfpga
hackkitten has quit [Read error: Connection reset by peer]
hackkitten has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
lovepon has joined ##openfpga
unixb0y has joined ##openfpga
<SolraBizna>
so MPSSE gives me a clock, one input, and one output
<SolraBizna>
not a single usable additional GPIO, unless you count spiking CS low briefly
<SolraBizna>
(which I don't)
<cr1901_modern>
any of the CBUS pins avail?
<SolraBizna>
none of them
azonenberg_mobil has quit [Ping timeout: 252 seconds]
reportingsjr has quit [Ping timeout: 252 seconds]
reportingsjr has joined ##openfpga
genii has quit [Remote host closed the connection]
<SolraBizna>
I want to transfer 9 bits at a time, and the interface to MPSSE is 8-bits-at-a-time so the most convenient ≥9-bit grouping is 16 bits
<SolraBizna>
so I just need a self-synchronizing 16-to-9-bit coding
<SolraBizna>
or I could have it always drive CRESET down at initialization, then wait a second or so and hope that the engine is now running
<SolraBizna>
(before I start doing anything with the clock)
rohitksingh_work has joined ##openfpga
eightdot has quit [Ping timeout: 246 seconds]
eightdot has joined ##openfpga
Miyu has quit [Ping timeout: 252 seconds]
azonenberg_work has joined ##openfpga
<azonenberg_work>
SolraBizna: anyway, what pitch was that 0.8mm bga on FACT?
<cr1901_modern>
what was the pitch and why was it 0.8mm?
<azonenberg_work>
sorry i meant
<azonenberg_work>
the pitch on the 256-ball BGA
<azonenberg_work>
derp
<azonenberg_work>
cr1901_modern, sorear: i make no distinction between pours and planes and generally use the term "plane" for any large fill on an internal layer that you reference signals to
<cr1901_modern>
azonenberg_work: To be clear, I haven't offerred any meaningful discourse in the past 24 hours
<SolraBizna>
it was 0.8mm
<cr1901_modern>
err fair*
<azonenberg_work>
As a general rule in my 4L designs i have large components and as many signals as i can fit on the top side, then a ground plane, then the board core
<azonenberg_work>
then a split power plane with all of my rails on it, then decoupling caps/small components and any signals i couldn't fit on the front
<SolraBizna>
originally, the iCE40 was just a lowly memory controller for the real CPU
<SolraBizna>
I haven't touched the design since making it the star of the show
<SolraBizna>
I expect that a full RV32IC core will draw more Vcore than a dumb memory controller with ~100 LCs...
<azonenberg_work>
SolraBizna: actually, at least if there's dram involved
<azonenberg_work>
your io power may well exceed the cpu core
<azonenberg_work>
that's been my experience with DDRx at least
awygle has quit [Quit: No Ping reply in 180 seconds.]
awygle has joined ##openfpga
<SolraBizna>
No DRAM, just some SRAM and MRAM
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 264 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
<Flea86>
azonenberg_work: Components on both PCB sides?
<Flea86>
looks like it
<whitequark>
azonenberg_work: so I reworked roommate's laptop some time ago (yesterday?)
<whitequark>
the BGA SMSC chip
<whitequark>
I've hit the issue where I think not all balls properly connected to the pads until I heated it up again and gently booped it from the top
<whitequark>
any advice?
<whitequark>
less flux?
<whitequark>
I was using special BGA flux this time, not some horrifying rosin based crap
<whitequark>
BK-223-A
<azonenberg_work>
Flea86: yes, very much so
<azonenberg_work>
whitequark: i cant comment on that particular flux
<azonenberg_work>
Do you have a photo of the failure?
<azonenberg_work>
Was this a reball or just reflowing the existing balls?
<whitequark>
I inferred the failure from the behavior of the laptop when I tried to turn on (which was not what I expected)
<whitequark>
and then the behavior after 2nd reflow (which was what I expected precisely)
<whitequark>
reflowing existing balls
<azonenberg_work>
Hmm, i havent done that - only new chips and reballed parts
<whitequark>
I'm more interested as to why the 1st reflow failed
<azonenberg_work>
so you never removed the chip?
<whitequark>
no, I removed the old SMSC chip
<azonenberg_work>
oh so this was a brand new chip
<whitequark>
got a completely new one (on tape)
<azonenberg_work>
on an existing footprint
<whitequark>
and soldered it back
<whitequark>
yes
<azonenberg_work>
Did you adequately clean and flatten the footprint before you started?
<whitequark>
I cleaned the footprint carefully with wick and flux and removed all traces of flux
<azonenberg_work>
ok, good
<whitequark>
with acetone
<whitequark>
then applied BGA flux
<azonenberg_work>
i would have used IPA, acetone is a little too aggressive for my tastes
<Flea86>
Would re-application of paste via stencil improve chances of reflow?
<azonenberg_work>
but it will work
<whitequark>
Flea86: wont work on a huge populated motherboard
<azonenberg_work>
whitequark: they do make rework stencils for this purpose that are tiny and have almost no border
<azonenberg_work>
Flea86: according to a textbook on the subject i read, it's a tradeoff
<azonenberg_work>
flux only = lower odds of short, higher odds of open
<whitequark>
azonenberg_work: I have never damaged anything on PCB with acetone other than specific connectors and I just avoid those connectors
<azonenberg_work>
paste = higher odds of short, lower odds of open
<azonenberg_work>
both have comparable yield
<whitequark>
in my experience IPA is much more tedious to use
<Flea86>
hmm ok
<whitequark>
I do use IPA when it is important to avoid damage to plastic at all costs
<azonenberg_work>
but paste can be done in a single process step if you paste the rest of the board
<whitequark>
but mostly acetone is ok
<azonenberg_work>
Thus it's preferred in industry
<marshallh>
sometimes i have to clean up a pad with xacto knife when BGA prepping
<azonenberg_work>
whitequark: anyway, how did you apply the flux?
<azonenberg_work>
how thick a layer? and is this a thin flowy flux or a thick tacky flux?
<whitequark>
azonenberg_work: I squished a bead of flux out of the syringe
<whitequark>
it is thin flowy flux
<whitequark>
it redistributed itself fairly evenly over the entire footprint pretty quickly
<whitequark>
with little help from me
<whitequark>
on its own it is somewhat gel like but thin
<whitequark>
how thick a layer, hm, hard to say, since it is completely transparent
<whitequark>
how much should I have used
<azonenberg_work>
so the flux i use is chipquik smd291nl, it's a thick gel that stays put when cold but spreads out at soldering temps
<whitequark>
this flux doesn't flow on its own but it also doesn't form "lumps"
<azonenberg_work>
that sounds like similar viscosity to what i have
<whitequark>
yeah
<azonenberg_work>
i put a bead of it down on the footprint then use a lint-free swab to smear it around
<whitequark>
I used tip of my tweezers, didn't have a lint-free swab
<azonenberg_work>
you want to ensure 100% coverage, a dry pad is very likely to not reflow right
<whitequark>
it definitely had 100% coverage
<whitequark>
very sure of that
<azonenberg_work>
in that case, too much flux is a possibility - i try to not have significantly visible thickness
<azonenberg_work>
i kinda paint it on
<whitequark>
oh
<whitequark>
guess that was the issue.
<whitequark>
it had visible thickness for sure.
<whitequark>
thanks
<azonenberg_work>
like, there will be streaks and "brush marks" from the swabbing
<azonenberg_work>
but think about how thick a solder paste print is
<azonenberg_work>
Then think about what percentage of that is metal
<azonenberg_work>
that's the volume of flux you want
<azonenberg_work>
maybe a ~50um thick film over the footprint
<azonenberg_work>
keep in mind also you will have extra flux between balls that can flow around as needed
<azonenberg_work>
whitequark: there are other possibilities
<azonenberg_work>
if the pcb was warped a all, it's possible some of the balls did not make good mechanical contact with the pad
<azonenberg_work>
and melted then resolidified without wetting
<azonenberg_work>
incomplete heating can cause similar issues
<whitequark>
I've heated it for way longer than necessary I think
<whitequark>
warped, hm, possibly, actually
<whitequark>
it was pretty much installed in the laptop since it's a pain in the ass to remove
<whitequark>
so I just avoided damaging the other parts of laptop with hot air
<azonenberg_work>
well, one of the prereqs to a solder joint is having the solder touch the thing being soldered :)
<whitequark>
but it was definitely not a 50um thick layer
<azonenberg_work>
i dont recall seeing excess flux cause a completely open circuit though
<azonenberg_work>
generally the issue with excess flux is the solvents boiling off in the molten metal and forming gas voids
<azonenberg_work>
causing either high resistance joints that don't conduct well, or mechanically inadequate joints that fail down the road
<whitequark>
it could be a high resistance joint that caused some ADC measurement to fail thus aborting power sequencing
<azonenberg_work>
possible but i think an outright open is more likely
<azonenberg_work>
if the board was still in the laptop, thermal expansion due to local heating would have caused it to warp
<azonenberg_work>
as the periphery of the board couldn't move
lovepon has quit [Ping timeout: 260 seconds]
<azonenberg_work>
If it bent enough that some balls didn't make contact, boom open circuit
<whitequark>
ah i see
m4ssi has joined ##openfpga
<azonenberg_work>
that said, without seeing a failed board its hard to debug
<azonenberg_work>
i have very limited experience with bga debug because i have had very few failures :p
<azonenberg_work>
i recall one or two ft256's that i didn't heat enough (visible gold pads with no wetting and incompletely melted paste)
<azonenberg_work>
that i fixed by adding flux and reflowing again for longer
<azonenberg_work>
then a 2x2 WLCSP that tombstoned
<azonenberg_work>
and a coolrunner CPG56 that was my first BGA ever that i misaligned due to oshpark grossly overetching the bga pads
<whitequark>
hm ok
pie__ has joined ##openfpga
<pie__>
hey guys. I should add ESD protection to a connector, how do I go about that? googling seems to suggest a pair of diodes to vcc and gnd but that feels a bit sketchy
<whitequark>
pie__: there are special ESD protection ICs
<pie__>
ok at least i have something to search for then
<_whitenotifier>
[Glasgow] whitequark opened issue #75: Add a footprint for an ATECC chip - https://git.io/fp8iv
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Ping timeout: 252 seconds]
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 264 seconds]
futarisIRCcloud has joined ##openfpga
<pie__>
well ok, thanks
<pie__>
azonenberg_work: this stuff sounds like it would only work when the device is grounded or something
<whitequark>
pie__: no
<whitequark>
ground capacitance is far higher than io pin capacitance
<whitequark>
so you have a far smaller voltage spike
<whitequark>
if you discharge to ground
<whitequark>
even if it's not connected danywhere
<pie__>
ok makes sense
<adamgreig>
does anyone know if the ice40 is really serious about wanting its spi flash to be ready within 10µs? most of what I can find specs like 100µs or 1ms
<whitequark>
should probably delay the reset of ice40 compared to spi flash
<adamgreig>
yea, they suggest adding a por chip to sequence it if necessary
<tnt>
I have the weirdest behavior on a couple of glasgow I assembled. One has the FX2 led on as soon as the fx2 fw loads. The other one stays off _except_ if I test the led with 'diode test' mode across it just before loading the fx2 fw, then it lights up.
<whitequark>
really strange
<whitequark>
are you sure there are no solder bridges?
<adamgreig>
does it also fix it if the dmm is turned off but you still press on the led with the probes?
<tnt>
whitequark: I can't see any. And continuity tested to the pins next to it doesn't show anything (and it's FPGA_RESET and LED_ICE, both of which behave like I'd expect).
<tnt>
adamgreig: nope, doesn't work, also doesn't work when in volt mode ...
<tnt>
And it's floating when the fx2 fw isn't loaded, but once loaded, it's not floating, it's actively driven low.
<whitequark>
sounds like a faulty LED?
<whitequark>
if it's driven low, the FX2 is not at fault
<whitequark>
that leaves the LED
<tnt>
You have positive led logic. (i.e. needs to be driven high for the led to light)
<tnt>
What fx2load do you have ? mine doesn't have -B and there seem to be a bunch of them :/
<whitequark>
fx2tool.
<whitequark>
not fx2load
<tnt>
oops, sorry my bad.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt>
whitequark: mmm, it says 0x00
<tnt>
`fx2tool -B -d 20b7:9db1 read_xram 0xb0 1`
<whitequark>
oh. oh wait
<whitequark>
that's not in xram
<whitequark>
that's in sfr.... you can't access that via read_xram
<whitequark>
think you can add read_sfr and write_sfr to fx2tool?
<tnt>
Mmm, loading the firmware a second time makes it work too, ... so it might be that something with the fx2 reset just isn't right.
<whitequark>
interesting
<whitequark>
could be
<whitequark>
is the power OK?
<tnt>
AFAICT ... I mean, it passes 'selftest' and both pll test and pin test show expected results on the outputs. So really ... except for that led, I haven't seen anything out of the ordinary.
<tnt>
I'll go eat, but this afternoon I'll check the output of that reset / power sequencing chip.
<tnt>
I'm pretty sure I originally had that chip soldered backward on that board and then swapped it the right way around. Maybe that fried it :/
<whitequark>
oh.
<whitequark>
yeah easily.
<whitequark>
if you plugged it in.
<tnt>
I did :/
<whitequark>
yeah probably dea
<whitequark>
d
<tnt>
I just hope it's only that chip and that didn't end up damaging the fx2.
<whitequark>
unlikely
<whitequark>
possible, but unlikely
<whitequark>
oh yeah
<whitequark>
the CY_RESET pin ended up at +5V
<whitequark>
on U7
<whitequark>
that probably just killed that one pin