<rqou>
wasn't it supposed to be an open-source clone of softice?
<digshadow>
yes
<digshadow>
don't think softice is maintained either?
<rqou>
it wasn't blatantly unmaintained at the time
<qu1j0t3>
'b 9
azonenberg_work has quit [Ping timeout: 260 seconds]
digshadow has quit [Ping timeout: 264 seconds]
<G33KatWork>
rqou: glitching it was actually pretty easy
<G33KatWork>
and shouldn't have worked the way I did it :D
<G33KatWork>
the problem is, getting it to glitch reliably
noobineer has quit [Remote host closed the connection]
<G33KatWork>
in the end, I glitched it with the longest glitch possible on the chipwhisperer
<rqou>
i tried that
<G33KatWork>
and myu timing jittered like hell
<rqou>
nothing happened :P
<G33KatWork>
yeah, normal
<G33KatWork>
and just eyballed the timing
<G33KatWork>
and just let it sit there, glitching thousands of times
<G33KatWork>
due to the jitter the timing moved around all the time
<G33KatWork>
around the time when I enabled a GPIO in my payload
<G33KatWork>
then I checked the lock register
<G33KatWork>
if the bootrom was unlocked, I dumped
<G33KatWork>
I waited 30 minutes, shit suddenly started dumping
<G33KatWork>
it's absolutely unreliable and most of the time NOTHING happens
<G33KatWork>
and I removed almost all the caps on that one rail I glitched
<G33KatWork>
as I said, that shouldn't have worked at all :D
<G33KatWork>
and I triggered on releasing the reset of the SoC :D
Lord_Nightmare has quit [Ping timeout: 264 seconds]
<rqou>
but q3k just said that checking the lock register doesn't work?
<G33KatWork>
q3k had the better setup, but was travelling. And I was sitting here wanting the stupid rom
<G33KatWork>
worked for me
<q3k>
rqou: ymmv
<q3k>
rqou: my point was more to not rely on it
<G33KatWork>
yeah, I glitched a few times just dumping the rom and reading the register and printing it
<G33KatWork>
and then, when I saw that it is reliable and not drunken because of the glitching, I checked the register first and then started dumping
<G33KatWork>
I also patched the chipwhisperer software to stop doing its thing and resetting my target when using the glitch explorer when it sees a good output
<G33KatWork>
because normally you use the explorer to figure out a reliable glitch timing, not hoping for the best
noobineer has joined ##openfpga
Lord_Nightmare has joined ##openfpga
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 264 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
digshadow has joined ##openfpga
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 264 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
tnt has quit [Ping timeout: 256 seconds]
tnt has joined ##openfpga
azonenberg_work has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
Lord_Nightmare has quit [Ping timeout: 264 seconds]
Lord_Nightmare has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 264 seconds]
pie__ has quit [Ping timeout: 276 seconds]
digshadow has joined ##openfpga
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
DocScrutinizer05 has quit [Ping timeout: 268 seconds]
DocScrutinizer05 has joined ##openfpga
DocScrutinizer05 has quit [Ping timeout: 265 seconds]
DocScrutinizer05 has joined ##openfpga
soylentyellow has quit [Ping timeout: 264 seconds]
soylentyellow has joined ##openfpga
diadatp has quit [Ping timeout: 265 seconds]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou>
oh WTF
<rqou>
nvidia managed to make the "partial key overwrite" mistake too?!
<rqou>
cc q3k G33KatWork
<whitequark>
awygle: I'll request a pid from openmoko for glasgow
<awygle>
whitequark: yeah i remember you said
<awygle>
was just wondering if linux accepted such
<awygle>
turns out yes
<awygle>
i updated all the extant pull requests but didn't get to making the two new ones
<awygle>
mañana as they say
DocScrutinizer05 has quit [Ping timeout: 265 seconds]
soylentyellow has quit [Ping timeout: 264 seconds]
<whitequark>
let's say the chip datasheet doesn't mention anything about decoupling capacitors
<whitequark>
has two AVCC pins and six VCC pins
<whitequark>
how do I decouple it
<azonenberg>
whitequark: my general rule, in the absence of specific recommendations
<azonenberg>
is one 0.47 uF from every power pin to either the nearest ground pin or a via to ground, depending on the pin layout
<azonenberg>
One 4.7 uF per chip on every power rail
<azonenberg>
(or several for really big stuff like an FPGA)
<azonenberg>
You can probably get away with less than that, and/or get better performance in specific situations, if you do more advanced analysis or experimental characterization to see what you can get away with
<azonenberg>
but honestly, most of the time it's not worth it
<whitequark>
so that's eight 0.47uF caps?..
<whitequark>
the developer board I have here has, uh
diadatp has joined ##openfpga
<whitequark>
0.1u + 2.2u on AVCC/AGND
<whitequark>
and no others
<whitequark>
lol
diadatp has quit [Ping timeout: 264 seconds]
<whitequark>
azonenberg: how do you derate MLCC caps?
<whitequark>
10V caps fine for 3V3?
<azonenberg>
whitequark: I generally do overkill on decoupling because caps are cheap, i can always DNP them if i mass produce to cut costs
<azonenberg>
in the event i decide they're not needed
<azonenberg>
Re derating, there's no rule of thumb
<azonenberg>
it varies by so many factors like package size and dielectric material
<azonenberg>
Find a cap that publishes a C/V curve
<azonenberg>
then target say no more than 20% loss of capacitance at your target voltage
<azonenberg>
I like Samsung b/c digikey has the curves right there
<azonenberg>
even if you dont actually use digikey for the order its a good reference
<whitequark>
am I reading this right? if I'm reading this right Y5V is basically worthless
<whitequark>
I'd need a 25V rated capacitor to get to 20% loss at 3V3
<Ultrasauce_>
it's pretty common for a pi-filter to be specified for avcc also right?
<azonenberg>
whitequark: i pretty much always use X5R/X7R caps
<azonenberg>
also, package size has a major impact on things
<azonenberg>
including thickness
<whitequark>
this is 0603
<azonenberg>
huh
<azonenberg>
i normally do 0.47 uF in 0402 and 4.7 in 0603
<azonenberg>
it's possible Y5V just derates a lot worse
<whitequark>
I refuse to do 0402 on grounds of sanity
<azonenberg>
Lol thats my default unless i need to go smaller
<azonenberg>
also, its 4am
<azonenberg>
i need to sleep
<whitequark>
I didn't even want 0603 for this board
<whitequark>
but with this many caps
<whitequark>
I have to
<Ultrasauce_>
I'm pretty sure y5v only exists for extreme cost sensitive applications
<Ultrasauce_>
ie throwaway shit where inconsistent performance barely matters anyway
<Ultrasauce_>
the temperature sensitivity is almost as significant as the dc voltage derating
<whitequark>
question
<whitequark>
I could derate by choosing a capacitor with a higher voltage or higher capacitance
<whitequark>
why should I choose higher voltage rating?
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 256 seconds]
<Ultrasauce_>
my impression is that gives you reliability margins in addition to actually getting the capacitance you want
<whitequark>
mhm
<whitequark>
okay
<Ultrasauce_>
cause the voltage rating is not actually where it breaks down but where all the obnoxious nonidealities cross their various margins of acceptability
* whitequark
stares at murata's website
<whitequark>
it gives me charts but *only* if I use it with noscript
<Ultrasauce_>
this discussion made me get mad at the lumped element model again
<Ultrasauce_>
it feels pretty silly to characterize a component like that with a linear relationship
<Ultrasauce_>
damn those EEs and their desire for tractable analysis
X-Scale has quit [Ping timeout: 260 seconds]
diadatp has joined ##openfpga
inoor has joined ##openfpga
inoor has quit [Remote host closed the connection]
diadatp has quit [Ping timeout: 240 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
diadatp has joined ##openfpga
diadatp has quit [Ping timeout: 264 seconds]
X-Scale has joined ##openfpga
diadatp has joined ##openfpga
diadatp has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
dingbat has quit [Quit: ~]
dingbat has joined ##openfpga
<awygle>
whitequark: yeah y5v is trash on every axis
<whitequark>
awygle: have any free time?
<awygle>
Sorta? Just woke up lol
<awygle>
What's up?
diadatp has joined ##openfpga
nickjohnson has quit [Quit: ~]
nickjohnson has joined ##openfpga
diadatp has quit [Ping timeout: 264 seconds]
<cr1901_modern>
Shouldn't all those plots in Figure 4 cross at 1V (change with respect to capacitance at 1V should be 0%)?
<openfpga-github>
Glasgow-JTAG/master e9d607a whitequark: Add base board schematics (only the Cypress side for now).
<whitequark>
awygle: ^
bubble_buster has quit [Quit: ~]
bubble_buster has joined ##openfpga
<whitequark>
I need to run a few errands, if you grabbed the parts from kicad PRs and into a local library then I would try to finish schematics today
<whitequark>
while waiting ~hours for this shitty $work bitstream to synthesize
<whitequark>
awygle: incidentally
<whitequark>
I was thinking about using Glasgow as an LA
<awygle>
I can do that before work yeah
<whitequark>
so we only have 50 MHz of bandwidth through the level shifter, right? but since a logic anlyzer isn't synchronized on a clock like a bus would be, it needs to oversample
<whitequark>
that is, to actually make any use of that 50 MHz it should sample at least twice as fast
<whitequark>
or more like four times
mithro has quit [Quit: ~]
mithro has joined ##openfpga
<whitequark>
gotta run
<awygle>
cr1901_modern: yes they should
<cr1901_modern>
I guess they figured "we know these caps suck, so it doesn't really matter if the graphs suck too"
<awygle>
Yaego aren't my favorite, though that may be irrational
<awygle>
I have a few cap rules of thumb
<awygle>
I derate voltage 50% but that's a space holdover and not really necessary
<awygle>
I use X7R, C0G and X5R if required
<awygle>
C/V curve is usually insensitive to voltage rating but VERY sensitive to package size
<cr1901_modern>
That curve in Fig 4 looks pretty damn sensitive to voltage rating ._.
Ishan_Bansal has quit [Quit: ~]
Ishan_Bansal has joined ##openfpga
<awygle>
yeah I maybe should have said for those "dielectrics" (they aren't but I don't have a better word)
<awygle>
But what Ultrasauce_ said is not true in general - neither voltage rating nor "dielectric" gives you any guarantee about effective capacitance under DC voltage bias
jeandet has quit [Quit: ~]
jeandet has joined ##openfpga
<cr1901_modern>
"Capacitors really don't like being capacitors"
<awygle>
Thankfully for X7R 0603 is pretty good these days. And 0805 is almost not worth checking the datasheet.
<awygle>
0402 is pretty wonky and past that lie nightmares
marex-cloud has quit [Quit: ~]
<awygle>
cr1901_modern: heh yeah. Look at a 3d cross section of an mlcc if you haven't
marex-cloud has joined ##openfpga
<Ultrasauce_>
ah I was more getting at the contrapositive there....the voltage rating is the point at which it's guaranteed to be garbage
<awygle>
Ultrasauce_: fair yes
<Ultrasauce_>
by several different metrics
<awygle>
At this point I usually start talking about charge storage vs small signal capacitance but that's complicated and not really useful
<Ultrasauce_>
electrolytics are pretty neato too
<awygle>
yup. entirely different problems lol
<cr1901_modern>
small signal capacitance <-- isn't this supposed to be treatable as constant?
<Ultrasauce_>
where there are 3+ different phenomena approximating capacitance and which ones are actually dominant is an open question
<cr1901_modern>
Idk what you mean by charge storage
<awygle>
cr1901_modern: basically depending on whether you're using the cap as a filter or a battery you do or do not care about C/V curves
<cr1901_modern>
that doesn't really answer my question :(
kc8apf has quit [Quit: ~]
<awygle>
Despite what we learned in school, the charge stored Q and the AC frequency response as a function of effective capacitance C are related by a more complicated relationship than just CV
<awygle>
Because C changes
kc8apf has joined ##openfpga
kem_ has quit [Quit: ~]
<awygle>
So if Q is what you care about you care less about C/V curves because they're usually close to constant over most of the voltage range
kem_ has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<cr1901_modern>
So q should be a linear function for small V
<awygle>
Close to, yes
<awygle>
(not always but usually)
rohitksingh has joined ##openfpga
<cr1901_modern>
You said you wanted to plot a graph of "charge storage vs small signal capacitance". That's... gonna be a vertical line if q = CV_small is linear.
<cr1901_modern>
Actually, idk what such a graph looks like, but I know I wouldn't be able to interpret it.
<awygle>
I didn't mean vs as in axes, just as in "these are not the same"
wpwrak has quit [Ping timeout: 260 seconds]
<awygle>
Like I said it's rarely useful
* cr1901_modern
is thinking
<cr1901_modern>
>because they're usually close to constant over most of the voltage range
<cr1901_modern>
awygle: DId you mean s/constant/linear/ here?
<awygle>
Uh no I meant s/linear/constant/ for "q for small v"
<awygle>
You're looking at a graph of The Worst Capacitor so I see why you'd be skeptical lol
<awygle>
All I meant by what I said is that you can't calculate Q by doing C(V) * V naively.
<awygle>
You have to integrate
<awygle>
And people forget that often
<cr1901_modern>
Well if C(V) is (near) constant up to your V that you care about, it's the same as multiplying C(V)*V :)
<cr1901_modern>
I'm just bikeshedding at this point, ignore me lol
<Ultrasauce_>
the magic of linearity
<Ultrasauce_>
but it's a lie! it's allll a lie
<Ultrasauce_>
we just find windows where the curvey bits are minimal and bury our heads in the sand!
<Ultrasauce_>
not to mention parasitics
<Ultrasauce_>
and my tinfoil hat is actually an antenna
rohitksingh has quit [Quit: Leaving.]
wpwrak has joined ##openfpga
diadatp has joined ##openfpga
azonenberg_work has quit [Ping timeout: 255 seconds]
<azonenberg>
awygle: 0805 is almost not worth checking the datasheet.
<azonenberg>
depends on capacitance
<azonenberg>
if you're trying to jam 100 uF into a 1206, checking the curves is *very* important :p
<azonenberg>
depending on voltage you may have to go 1210
<whitequark>
lol
<whitequark>
azonenberg: weren't you going to sleep
<awygle>
yeah all right lol
<awygle>
don't do that :p
<azonenberg>
whitequark: i did sleep
<awygle>
get a tantalum cap like a normal person
<azonenberg>
For something like 4 hours :p
<azonenberg>
Not nearly enough but i have work in a few...
<whitequark>
how do you even do that
<whitequark>
if it's less than 12 hours I don't bother with sleep
<azonenberg>
I need at least a little bit or i'm completley nonfunctional after ~20 hours awake
<openfpga-github>
Glasgow-JTAG/master c092143 Andrew Wygle: Temporary(?) addition of KiCAD symbols.
<azonenberg>
Since it needs a minimum of iirc two samples (at 4x data rate) at the correct bit value
<awygle>
whitequark: ^
<azonenberg>
I think the requirement is something like 0.625 UI of opening
<azonenberg>
and there's no equalization or anything on the RX
<awygle>
0.625 is the SGMII spec
<awygle>
for the eye
<whitequark>
awygle: thanks!!
<awygle>
whitequark: the footprint for the fxma108 isn't in there, do you think you'll need that?
<whitequark>
awygle: don't think I'll get to layout today
<azonenberg>
awygle: so you think i'm good through ~18" of fr408 without eq and still meeting the 0.625 UI horizontal opening?
<awygle>
okay cool cuz i gotta run
<awygle>
azonenberg: yes. but if you want to spin a board with your massive overkill retimer, you're right that you can always remove it later lol
<azonenberg>
i dont have a good feel for SI over long distances, to be fair
<whitequark>
awygle or azonenberg: what do you think re: using Glasgow as an LA?
<azonenberg>
Well i was actually thinking the opposite
<azonenberg>
spin a passive backplane with no retimer or buffer first
<azonenberg>
then add things if it doesn't work reliably :p
<awygle>
that's a better idea imo
<awygle>
whitequark: yeah i mean you're right, 50 MHz is 25 MHz for reliable sampling. not sure what to do about it unless you want to put in level shifter bypass or something.
<awygle>
okay going to work, back in 30ish
<azonenberg>
awygle: But i'd make sure that the backplane-to-brain-board has sufficient connector/power capacity that I can hook up the retimers/buffers if needed
<azonenberg>
in a respin
<azonenberg>
Nice to have options picked out though
<azonenberg>
whitequark: i think you're reinventing starshipraider with slightly lower specs
<whitequark>
azonenberg: no that I am well aware of
<azonenberg>
well ok an OOM lower (I'm doing 500 MHz max toggle rate)
<whitequark>
"slightly" lol
<azonenberg>
i just think it's funny that you are literally re-making almost every design decision i did
<azonenberg>
And either coming to the same conclusion or making tradeoffs more in favor of reduced cost
<whitequark>
well yes, that last part is why it's worth spending time on them :P
<whitequark>
what I'm asking specifically
digshadow has quit [Ping timeout: 260 seconds]
diadatp has quit [Ping timeout: 256 seconds]
<whitequark>
is if I have a 50 MHz bandwidth level shifter (so, 100 Mbps max bitrate)
<azonenberg>
If you want to put in the extra code
<azonenberg>
you can have the LA operate in both oversampling and "state" mode
<whitequark>
then how fast do I need to sample to utilize all that bandwidth in an LA?
<whitequark>
I'm thinking at 200 Msps
<whitequark>
but I might be wrong
<azonenberg>
In state mode, 100 MHz from an external pin
<whitequark>
yes, state mode I understand
<azonenberg>
in oversampling mode, it gets more interesting
digshadow has joined ##openfpga
<azonenberg>
basically, the big problem is jitter between the sampling clock and yours
<azonenberg>
the more you oversample the more accurately you can localize edges
<azonenberg>
You can have very fine phase differences through a low bandwidth buffer
<azonenberg>
depending on how accurate the threshold of your RX is
<azonenberg>
So if you oversample at say 200 Msps on 100 Mbps data you'll get an average of 2 samples per data bit
<azonenberg>
But if the rates dont divide evenly some values will be sampled more often than others
<azonenberg>
and you'll get the appearance of some values being held for a longer time
<azonenberg>
The more you oversample the more you diminish this effect
<whitequark>
yes, that's exactly what I was thinking of
<whitequark>
more specifically I was sampling SPI running at 25 MHz with a 48 MHz LA
<whitequark>
and getting undecodable garbage
<whitequark>
which got me thinking about phase relationship
<whitequark>
hmm
<whitequark>
azonenberg: so can I use your LA software?
<whitequark>
I have a feeling sigrok isn't going to cut this
<whitequark>
I want features like telling the LA "sample at a defined phase relationship to this pin"
<awygle>
I didn't think about this at all correctly lol whoops. I had modeled the shifter mentally as a sampling system.
<awygle>
whitequark: we only have a couple of bits of resolution for that though
<awygle>
If that
<awygle>
Unless the UP has an IDELAY or similar?
<azonenberg>
whitequark: feel free to, however we'll have to a) refactor it out from the antikernel repo (needs to happen anyway) and b) come up with a name for it
<azonenberg>
Also keep in mind i plan to rewrite the rendering engine significantly once my housing situation stabilizes to go from cairo to opengl
<awygle>
STARSHIPYEOMAN
<azonenberg>
also at the current stage of refactoring there's no way to configure trigger conditions on a LA
<azonenberg>
the C scopehal API supports it
<azonenberg>
but the UI doesnt
<azonenberg>
the C++*
<awygle>
Or STARSHIPBOSUN depending on your subjective perception of its rank
<azonenberg>
lol
<whitequark>
awygle: the shifter?
<azonenberg>
whitequark: and exactly, sigrok is ok for parsing data but its not meant as a UI for advanced instrumentation
<azonenberg>
Whereas my tool is
<azonenberg>
anyway heading off to work
<awygle>
whitequark: yeah the level shifter. i just had it all twisted in my head. obviously the sampling is at the fpga.
rohitksingh has joined ##openfpga
<awygle>
oh we can do phase relationships with the Fine Delay Adjustment of the PLL block
<awygle>
when we have an external sampling clock
pie__ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
diadatp has joined ##openfpga
eightdot_ is now known as eightdot
<whitequark>
awygle: there's only one PLL unfortunately
<whitequark>
oh hm
<whitequark>
yeah it should be enough
rohitksingh has quit [Quit: Leaving.]
mumptai has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
<azonenberg_work>
Ultrasauce_: i first developed an appreciation for parasitics on breadboards
<azonenberg_work>
when i was ~14 and building some kind of audio amplifier projec
<azonenberg_work>
I wondered why my headphone audio out was so quiet
<azonenberg_work>
Then i realized i was plugged into the breadboard one column away from the amp :p
<azonenberg_work>
And i was AC coupling through the parasitics between the two breadboard columns
<azonenberg_work>
it was probably ~30 dB down from where it should have been, maybe even 40
<azonenberg_work>
but audible
sgstair has quit [Read error: Connection reset by peer]
<sorear>
also an appreciation for the incredible dynamic range of human hearing?
<azonenberg_work>
Lol there's that too
<azonenberg_work>
But the point remains, my signal coupled through and was audible/recognizable
<azonenberg_work>
Despite there being zero connection
<azonenberg_work>
it was just crosstalk between breadboard channels
sgstair has joined ##openfpga
<rqou>
random question: why is Joe Grand "famous?" (for some definition of the word at least)
<awygle>
I'm guessing he's famous because of prototype this
<awygle>
Since his wiki page says "became famous because of prototype this"
<rqou>
is this just "how TV works"?
<sorear>
TV is weird
azonenberg_work has quit [Ping timeout: 255 seconds]
azonenberg_work has joined ##openfpga
<digshadow>
mithro: joe grand is a good guy. we hit it off right before he moved out of sf bay area, talk to him ocassionally
<digshadow>
mithro: ask me about scaring his wife when I had a bbq
Prf_Jakob has quit [Remote host closed the connection]
<mithro>
Hrm, I'm not sure I want to know...
<azonenberg_work>
What did you blow up?
<digshadow>
azonenberg_work: basically he wanted to bring his kids, but I told him he should watch them because there are chemicals, empty swimming pool, etc
<digshadow>
he told his wife this and she flipped out and joe had to scout the place before she'd release them from the car
<qu1j0t3>
LOL
<qu1j0t3>
that's a good one, Professor Frink
diadatp has quit [Read error: Connection reset by peer]
diadatp has joined ##openfpga
* awygle
continues to be pecked to death by kicad hens
diadatp has quit [Ping timeout: 263 seconds]
diadatp has joined ##openfpga
<awygle>
it would be cool if github let you push to a merge request that you hadn't opened, if the person who did open it checked a box or something
<whitequark>
github has that feature
<whitequark>
but only for repo maintainers
<awygle>
oh yeah, "allow maintainers to edit blah blah blah"
* awygle
has never maintained anything substantial
<awygle>
i understand and respect the hard work of the kicad library maintainers and the difficult position they're in, and also it's very unpleasant to keep making tiny non-functional changes on 24-hour round-trip cycles.
<awygle>
whine whine complain whine
diadatp has quit [Ping timeout: 265 seconds]
<whitequark>
well I think the idea that after a few footprints you get the idea and get them right on the first try
<whitequark>
1) would you change placement of decoupling capacitors?
<whitequark>
2) is this placement of vias to ground plane between QFP pads and EP sane?
<whitequark>
3) should I just move all the caps to the other side of the board or something this is obnoxious
mumptai has quit [Quit: Verlassend]
jfng[m] has joined ##openfpga
jfng[m] has left ##openfpga ["User left"]
<lain>
I usually just wind up routing the ground traces to the EP and putting several grounding vias on it
<lain>
caps on opposite side should be fine electrically. if it's a 4-layer board it has the added bonus that the via to the cap doubles as the via to the power plane
<whitequark>
yes, I was thinking about that.
jfng has joined ##openfpga
azonenberg_work has quit [Ping timeout: 256 seconds]
<awygle>
whitequark: 1) not necessarily 2) yes 3) if you like
<awygle>
flipping to the other side is fine, it might add absolutely trivial amounts of inductance to the loop but nothing that will matter at any speed we're going to see
<awygle>
and it will probably actually end up shortening the loop and reducing inductance