<azonenberg>
so basically the cap is in the same spot it'd be if i had vip
<azonenberg>
but the via is offset a bit
<azonenberg>
In some cases i had to move the cap a bit in order to route bottom-layer traces around it
<azonenberg>
The gray outlines are front side bga pads
<azonenberg>
then you can see some power/ground routing subdued in the background too
<azonenberg>
this is incomplete, i have more caps to add
<cr1901_modern>
I really just need to suck it up and do a BGA board. Ppl in this channel are willing to help me so I'm less likely to make mistakes. But I keep hesitating
<azonenberg>
Do itttt
<lain>
:D
<azonenberg>
artix7 or spartan6 ftg256 package is quite friendly for 4 layers
<lain>
PEER PRESSURE PEER PRESSURE
<azonenberg>
I generally find myself unable to use 100% of the IOs but i can use a sizeable fraction
<azonenberg>
Bank 35of this fpga, for example, is fully routed at this time
<rqou>
i thought you started with an xc2c32a?
<azonenberg>
and has 11 empty pins
<azonenberg>
so ~80% loaded
<azonenberg>
that's pretty typical utilization for a 16x16 bga on 4L oshpark rules
<azonenberg>
i could probably squeeze more in if i wanted, there's at least one empty routing channel easily reachable
<azonenberg>
a few more channels are blocked by a diff pair going in a weird direction
<azonenberg>
etc
<azonenberg>
rqou: my first bga was an xc2c32a
<azonenberg>
it was a mistake
<cr1901_modern>
I don't really care about using all the pins. The issue is mainly money/logistics. I can only afford one-offs from macrofab.
<azonenberg>
i undersized the pads (oshpark really overetched at the time)
<azonenberg>
some of the NC pads were completely etched away
<azonenberg>
and it was a pain to hand place as a noob
<azonenberg>
then i did a ftg256 and realized how easy bga was
<rqou>
hmm interesting
<cr1901_modern>
azonenberg: You said you could do ftg256 in a toaster oven
<rqou>
is oshpark etch isotropic? do i have to oversize pads?
<azonenberg>
Yes
<cr1901_modern>
?*
<azonenberg>
rqou: It's a lot better now
<azonenberg>
they switched fabs
<rqou>
you should add a note to your blog posts :P
<azonenberg>
the old fab had poor process control of trace width
<azonenberg>
~6 mil traces were more like 4 post etch iirc? have to measure
<azonenberg>
cr1901_modern: i've done 0.35mm wlcsp in a toaster oven too ;p
<azonenberg>
it just requires more effort to align before you put it in
<rqou>
was it in isotropic etch profile or was it still somewhat anisotropic?
<azonenberg>
it was a weird shape b/c of plating + etching
<azonenberg>
so... a bit of both?
<lain>
icosahedronal traces
<rqou>
oh right, there are plating steps too
<azonenberg>
I'll do a cross section of a board at some point and show you
<lain>
hypercube traces.
<cr1901_modern>
azonenberg: My issue is that by cr1901's Law of Inferior Duplication, I am often not able to duplicate the results of someone else's work even when I follow their instructions correctly.
<lain>
vias are for scrubs I use higher-dimensional space to transit between layers
<rqou>
so when a trace width is specified, is it normally the widest, narrowest, average, or "talk to your fab?"
<lain>
rqou: per IPC it should be maximum
<lain>
iirc
<lain>
and then dimensional tolerance is "talk to your fab" unless they reference a specific IPC tolerance spec
<lain>
(which they should)
* cr1901_modern
almost makes an anime analogy, but decides not to
<rqou>
wait but 1oz copper thickness is 1.4 mils
<rqou>
so if the dimensions are "maximum" and you have an isotropic etch, you can have a trace that's actually super narrow at the top
<rqou>
so a 4mil wide trace can actually be only 1.2mil at the top assuming a perfectly isotropic etch?
<lain>
hmm I may have that wrong actually
<lain>
can't find the relevant ipc document :/
<azonenberg>
rqou: most etches are not isotropic
<azonenberg>
they etch a thin foil then plate up
<rqou>
ah ok
promach has quit [Remote host closed the connection]
<rqou>
hmm, so what limits accuracy of the pcb copper layer?
<lain>
thickness of base copper limits the minimum width due to etching
<lain>
but not sure what limits the actual accuracy
<azonenberg>
Process tolerance (over/underetch)
<azonenberg>
Blur in the photoresist
<azonenberg>
lots of things
<azonenberg>
accuracy of the machine that makes the mask
<cr1901_modern>
azonenberg: What toaster oven did you use to make BGA boards?
<lain>
I've used the cheapest one available before, and just stopwatch + thermocouple for control lol
<azonenberg>
lain: they're doing the same kind of revamp they did for the layout tool
<rqou>
i specifically found a kicad dev to ask about this
<rqou>
apparently the old code structure was "structure, what's that?"
<azonenberg>
replacing the fugly old rendering engine (XOR based erasure of lines you're removing, etc) with opengl
<azonenberg>
totally new data model internally i think
<rqou>
CERN couldn't work with that and made a graphics abstraction layer
<azonenberg>
Yeah
<azonenberg>
i have done next to no dev on eeschema
<rqou>
which is actually sanely "this part is the data, this part is the rendering"
<cr1901_modern>
XOR based?
<azonenberg>
all of my work has been pcbnew
<azonenberg>
cr1901_modern: if you have a line you want to erase
<rqou>
i find i absolutely hate working on c++
<azonenberg>
just xor pixels with the color you drew it in
<lain>
rqou: same
<azonenberg>
then draw it again
<rqou>
i've ported my vhdl tool to Rust now
<azonenberg>
i love well written C++
<lain>
I did enough c++ for a lifetime, I'm done with it
<azonenberg>
which is hard to find :p
<azonenberg>
aanyway off to the garage to work on some stuff
<azonenberg>
back in a bit
<lain>
C# is bae
<rqou>
i've actually used C# since version 1
<lain>
rust seems good for embedded stuff, need to actually use it on a project one of these days
<rqou>
it's pretty nice
<lain>
yeah
<lain>
the newer stuff with pattern matching is interesting
<cr1901_modern>
Good for embedded if you're only micros are ARM and/or openRISC :P
<rqou>
somehow the C# culture doesn't seem to encourage as much IAbstractWidgetFactoryFactoryRunner as Java
<cr1901_modern>
I think I took that "Why the Raspberry Pi is unsuitable for education" blog article too seriously
<lain>
like, it used to be a nightmare to selectively do things based on typeof(obj), but now you can do something like: switch(obj) { case Circle circle: /* do something with circle */ break; case Rectangle rect: ... break; ...
<lain>
where "case Circle circle:" is implicitly doing if(obj is Circle) { Circle circle = obj as Circle; ... }
<rqou>
rust has that
<lain>
ah nice
<rqou>
it's a bit more powerful actually afaik
<lain>
they probably borrowed it from rust haha
<lain>
C# borrows the best bits of everything
<rqou>
rust can do destructuring in a pattern
<lain>
wuzzat
<azonenberg>
rqou: I use C+
<lain>
"C with classes"?
<azonenberg>
as in, a carefully selected subset of C++ that keeps things relatively sane and not too java-y
<cr1901_modern>
(Although I guess technically reflections are also a measure of signal quality as well)
* lain
nods
<lain>
the knee frequency also depends on the rise time, rather than the signal frequency
<lain>
since the rise time is what largely determines the various signal components (and their powers)
<lain>
(since square waves are equivalently composed of an infinite series of sine waves, etc)
<cr1901_modern>
Isn't the rise time a function of the capacitance "seen" by the line anyway? As well as the slew rate from whatever is driving the signal high or low?
<cr1901_modern>
capacitance == low pass filter effect which will slow down rise time
<lain>
at high speed the bulk capacitance actually isn't a factor afaik, it's just the impedance that matters (so, it comes down to drive strength and termination)
<cr1901_modern>
(But a real impedance is not going to change the frequency content of a signal)
<cr1901_modern>
In any case, I'm trying to separate how a transmission line's impedance affect rise time from how it effects the actual signal delivered to the load (due to impedance mismatch). They seem like they should be related, but this blog post and what you're saying state they're not.
digshadow has joined ##openfpga
<cr1901_modern>
(The minispartan6 has serpentine traces attached to the 133MHz SDRAM. I figured at 133MHz, this wouldn't be necessary, and I'm trying to calculate how important length matching actually is for this)
<lain>
it might not be necessary, may just be to gain extra timing margin or etc
<cr1901_modern>
which led to the above blog post about c/sqrt(permittivity_of_fr4)
<cr1901_modern>
since I totally forgot most of this stuff like a moron
<rqou>
i actually never studied transmission line theory
<lain>
but, impedance mismatch I like to think of with the water analogy - instead of current flow (flowing water), for high speed imagine a pressure wave going down a pipe filled with water. if the pipe diameter suddenly shrinks, that's an increase in impedance, and you can imagine a lot of the pressure wave is going to smack into the wall where the pipe necks-down - that energy is reflected back toward the
<lain>
source
<lain>
stuff like that
<cr1901_modern>
rqou: I'm gonna be honest. Normally I would ask "how did you get your degree without taking a class in that?" But I have no room to talk. I have a bunch of shit I didn't learn but should have.
<rqou>
i tell EE people I have a CS degree and tell CS people I have an EE degree :P
<cr1901_modern>
Like: threads, version control, SMPS, making own PCBs (okay, this was offerred outside of class), RF electronics (offered as an elective that I didn't take)
<cr1901_modern>
OS design, how to use C++11 features
<rqou>
at berkeley basically everything is an "elective" so you can totally chose to not learn these things
<rqou>
although we don't have anything on "how to use C++11 features"
<rqou>
i don't know how many professors even use C++11
<cr1901_modern>
It came up multiple times in grad school as "the wave of the future".
<cr1901_modern>
Before FP fever took over
<rqou>
i don't think any professors here ever liked C++
<rqou>
it seems it's always been C, Java, or functional programming
<cr1901_modern>
I didn't think the first part of transmission line theory was all that bad. Most of it is intuitive if you concentrate. Antennas, on the other hand... bleh
<cr1901_modern>
that shit sucked
<cr1901_modern>
I was never good at them, and I even bought a book back in July on the theory that I barely touch b/c all it does is discourage me
<rqou>
yeah i learned neither transmission line theory nor antennas
<lain>
a lot of profs are really mathematical about it, rather than trying to provide an intuitive understanding they're just like "lol memorize these differentials"
<cr1901_modern>
I don't understand the Maxwell's derivation of telegrapher's equations. I could do the RLGC version if I tried.
<lain>
I found Optics to be an excellent introduction to the subject
<lain>
(Eugene Hecht)
<rqou>
heh, i actually took optics :P
<rqou>
i agree
<lain>
every other book on EM/optics is all math math math
<rqou>
(we also used the Hecht textbook :P )
<lain>
Hecht actually explains it with words and analogies that really work well for me
<lain>
the math is there too
<lain>
but it's optional extra :P
<rqou>
what's interesting is that berkeley expects you to have both all the intuition and all the math
<rqou>
simultaneously
<lain>
lol
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
scrts has quit [Ping timeout: 264 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
scrts has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
m_t has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...]
scrts has joined ##openfpga
Bike has quit [Quit: lshgas]
Hootch has joined ##openfpga
m_t has quit [Quit: Leaving]
cr1901_modern1 has joined ##openfpga
cr1901_modern2 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern1 has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
promach has joined ##openfpga
cr1901_modern2 is now known as cr1901_modern
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
pie_ has joined ##openfpga
Bike has joined ##openfpga
promach has quit [Ping timeout: 272 seconds]
davidc__ has quit [Ping timeout: 260 seconds]
davidc__ has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
digshadow has quit [Quit: Leaving.]
promach has joined ##openfpga
pie_ has joined ##openfpga
m_w has joined ##openfpga
X-Scale has joined ##openfpga
cr1901_modern has quit [Read error: Connection reset by peer]
amclain has joined ##openfpga
Hootch has quit [Read error: Connection reset by peer]