<daveshah> You can't
<daveshah> That's the problem
<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?
<cr1901_modern> esden's icebreaker? mithro's fomu?
<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
<azonenberg_work> Also https://i.imgur.com/spCWEzV.png
<azonenberg_work> This is the current power layout for INTEGRALSTICK
<azonenberg_work> https://i.imgur.com/WOQJ0T9.png is the adjacent signal layer
<azonenberg_work> i have some crossings that are unavoidable so the planes will have to be AC coupled together
<azonenberg_work> but this is an unusually dense design for me
asy has quit [Ping timeout: 246 seconds]
asy has joined ##openfpga
<Bob_Dole> https://www.youtube.com/watch?v=OQm0aBw_ep8 speaking of some of that.. I was just watching a video of bil herd talking about inductance and what not.
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
<pie__> anything more specific?
<pie__> thanks
<pie__> \o/
<Flea86> pie__: It also depends on the connector... some ESD barriers have low intrinsic capacitance (for high speed interface protection) etc.
rohitksingh has joined ##openfpga
<azonenberg_work> pie__: fwiw those special ICs are generally either a diode to vcc and ground, or a zener to ground that breaks down at some voltage
<azonenberg_work> (or both)
<azonenberg_work> just combined in one package for convenience
<azonenberg_work> (and better parasitics)
<azonenberg_work> on die ESD protection structures are pretty much exactly that, a diode clamp
<_whitenotifier> [Glasgow] whitequark opened issue #74: Applet regression tests - https://git.io/fp8wF
<_whitenotifier> [Glasgow] whitequark labeled issue #74: Applet regression tests - https://git.io/fp8wF
<_whitenotifier> [Glasgow] whitequark commented on issue #42: Add tests to program-ice40 applet - https://git.io/fp8rv
<_whitenotifier> [Glasgow] whitequark closed issue #42: Add tests to program-ice40 applet - https://git.io/fp8rf
<_whitenotifier> [whitequark/Glasgow] whitequark pushed 1 commit to master [+22/-24/±1] https://git.io/fp8K1
<_whitenotifier> [whitequark/Glasgow] whitequark d58f545 - applet: move all applets to individual subdirectories.
<_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> This also works : https://pastebin.com/FD7FrXHD
<tnt> ... things don't make sense anymore ...
<whitequark> oh
<whitequark> hm
<whitequark> lmao what
<whitequark> can you read whatever's at IOD
<whitequark> with fx2tool -B read_xram
<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
<tnt> Doesn't really seem bad ... Blue is the FLAG2 3v3 en and yellow is CY_RESET.
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
<whitequark> hm, weird.
<whitequark> i honestly have no idea
<tnt> whitequark: would you have a .ihex of the fw somewhere ? just to exclude some weirdness in my compiler setup ?
<whitequark> sec
<tnt> tx. But same behavior.
RaYmAn has joined ##openfpga
<tnt> whitequark: well ... I should have looked at the assembly in the first place.
<tnt> behavior completely makes sense :p
<whitequark> i... don't see it
<tnt> Well, when you read _IOD you get the pin input state, not what you just wrote above.
<whitequark> ah, fuck.
<whitequark> move OE higher?
<whitequark> I think there's a few other issues like that
<tnt> Yeah, or just set IOD to whatever instead of doing bit ops.
<whitequark> IOD is shared
<whitequark> see fpga_reset
<tnt> Ah right. Well then read IOD once, do all the ops in a variable and set it.
<whitequark> setting OED first would still work, right?
<tnt> yes.
<tnt> you'd just get leds flicker for a couple of clock cycles ... not exactly the end of the world.
GuzTech has joined ##openfpga
<whitequark> hm, but it's more problematic elsewhere.
<whitequark> so I think it's better to go with a temporary.
Miyu has joined ##openfpga
jevinski_ has quit [Ping timeout: 246 seconds]
genii has joined ##openfpga
Patater_ is now known as Patater
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
jevinskie has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 246 seconds]
<azonenberg_work> pie__: also you dont care about voltage relative to ground
<azonenberg_work> you care about relative voltage between two points on the chip
GuzTech has quit [Quit: Leaving]
rohitksingh has quit [Ping timeout: 250 seconds]
azonenberg_work has quit [Ping timeout: 252 seconds]
<_whitenotifier> [whitequark/Glasgow] marcan pushed 1 commit to revC [+1/-0/±4] https://git.io/fp4WK
<_whitenotifier> [whitequark/Glasgow] marcan 88db3d3 - revC: move FPGA I/O banks to a separate sheet, wire I/O buffers
azonenberg_work has joined ##openfpga
<_whitenotifier> [whitequark/Glasgow] whitequark pushed 13 commits to master [+2/-0/±32] https://git.io/fp4WA
<_whitenotifier> [whitequark/Glasgow] awygle 7c19bce - Initial Rev C IO cell schematic.
<_whitenotifier> [whitequark/Glasgow] marcan 33513f7 - Add modified SOT-563 footprint
<_whitenotifier> [whitequark/Glasgow] marcan 7d9bebe - Update fp-lib-table for SOT-563 lib directory
<_whitenotifier> [whitequark/Glasgow] ... and 10 more commits.
<_whitenotifier> [Glasgow] whitequark deleted branch revC - https://git.io/fp4Wh
<_whitenotifier> [whitequark/Glasgow] whitequark deleted branch revC
<_whitenotifier> [Glasgow] whitequark deleted branch revC-pre-rebase - https://git.io/fp4Wh
<_whitenotifier> [whitequark/Glasgow] whitequark deleted branch revC-pre-rebase
<_whitenotifier> [Glasgow] Error. The Travis CI build could not complete due to an error - https://travis-ci.org/whitequark/Glasgow/builds/458037371?utm_source=github_status&utm_medium=notification
<travis-ci> whitequark/Glasgow#159 (revC - 88db3d3 : Hector Martin): The build has errored.
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
mumptai has joined ##openfpga
pie__ has quit [Ping timeout: 256 seconds]
Bob_Dole has quit [Ping timeout: 276 seconds]
Bob_Dole has joined ##openfpga
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
<SolraBizna> nextpnr gets a little confused if you run it on an empty design
<SolraBizna> it spends a surrisingly long time (almost half a second) routing it
<SolraBizna> *surprisingly
Zorix has quit [Quit: Leaving]
<esden> does anyone here still need a 35C3 ticket?
<RaYmAn> esden: I think Drew from oshpark might if people in here doesn't. - https://twitter.com/pdp7/status/1065334697251794944
<esden> ok, I asked Drew. we will see. Thanks for pointing out. :D
<RaYmAn> they seem to be totally sold out now
Zorix has joined ##openfpga
adamgreig has quit [Quit: WeeChat 1.8]
Flea86 has joined ##openfpga
genii has quit [Read error: Connection reset by peer]
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga