<whitequark>
awygle: will probably move to the other side then
<whitequark>
there just doesn't seem to be any benefit to keeping them on top
<whitequark>
and it makes routing buses much more annoying
<awygle>
yupyup
<awygle>
those 0603s do look comically large in that view lol
<whitequark>
also it pisses me off to no end that I have to route the USB pairs through a via
<awygle>
why, the pins don't line up correctly?
<whitequark>
they're swapped
<whitequark>
it's a well known issue with USB
<whitequark>
I *think* the chip was designed to connect to a mini-USB PTH connector mounted on the other side of the board
<awygle>
bleh, that sucks
knielsen has quit [Ping timeout: 240 seconds]
<whitequark>
zzz
<awygle>
night
knielsen has joined ##openfpga
<azonenberg>
whitequark: the only benefit to having caps on the top side in an application like this
<azonenberg>
is that it lets you do 1-sided reflow which means only one solder stencil and compatibility with hot plate reflow if you're a masochist (oven gives much better results for about the same price)
<azonenberg>
What i would do is put say a 3x3 grid of vias in the EP
<awygle>
Which reminds me
<azonenberg>
or 2x2, depends on your fab process / design rules
<awygle>
cr1901_modern: my controleo kit arrives this Thursday
<cr1901_modern>
awygle: Cool, mine doesn't b/c I haven't bought it yet :P
<awygle>
cr1901_modern: I'll let you know how it goes :-P
<azonenberg>
Connect all of the ground pins to the EP
<azonenberg>
0402s on the underside
<azonenberg>
Put caps from those to the EP vias
<azonenberg>
for power
<azonenberg>
then have vias outside the array
<azonenberg>
The traces from your QFN pins to the caps are a bit long for my taste but at the frequencies you're working at it should be fine
<azonenberg>
For cap via placement, optimal is via-in-pad
<azonenberg>
next best is vias on either side or even between the pads
<cr1901_modern>
awygle: Tyvm
<azonenberg>
next best is vias at the end
<azonenberg>
absolute worst is vias connected by longish traces
amclain has joined ##openfpga
<awygle>
I have a board coming that same day to test it with
<awygle>
I am stoked
<awygle>
I missed EEing, I've really enjoyed doing it again these last couple weeks
<azonenberg>
:)
diadatp has quit [Ping timeout: 260 seconds]
amclain has quit [Quit: Leaving]
diadatp has joined ##openfpga
<rqou>
azonenberg, whitequark: i thought that this specific trace routing is suboptimal?
<rqou>
i thought you're supposed to make gnd traces go past the capacitor first before hitting the power source?
rohitksingh_work has joined ##openfpga
<rqou>
ugh
<rqou>
this problem set for my class _requires_ matlab
<rqou>
it's kinda interesting how the CS half of $FANCY_SCHOOL seems to prefer NIH and/or F/OSS whereas the EE half is just "lol whatever everything is proprietary"
<rqou>
random offtopic: lain: interesting in pwning skylake intel ME?
<lain>
rqou: don't think I have /time/ but yes definitely
Bike has quit [Quit: Lost terminal]
<awygle>
rqou: not really. you just minimize the inductance of the loop.
<awygle>
that's one strategy that can be helpful, but it's not like, a rule
<awygle>
also, "CS likes FOSS and EE doesn't care" is pretty standard lol
<rqou>
oh wtf
<rqou>
this problem set requires some code last updated in ~2003
<rqou>
written by somebody who has since passed away
<rqou>
and it's a .mex file, of course
<rqou>
at least it has source code
diadatp has quit [Ping timeout: 260 seconds]
<azonenberg>
rqou: inductance of a plane is very low
<azonenberg>
inductance of a wire or via is higher
<azonenberg>
basically you want to get the cap to the plane as quickly as possible
<azonenberg>
rqou / whitequark: look at UG483 figure 2-1
<azonenberg>
page 25 in my edition
<azonenberg>
I generally use option C for small caps like 0402 and a hybrid of B and D (three to four vias surrounding each pad) for bigger ones like 1206
<azonenberg>
I try to make the vias as close to the pad as i can get while still having some soldermask web to prevent solder wicking down the hole
<rqou>
azonenberg: these are all for 4+ layers?
<rqou>
what about on 2 layer potato PCBs? :P
<azonenberg>
rqou: um
<awygle>
"<azonenberg> i haven't done a 2-layer board since 1983 because all of my boards have 1156-ball FPGAs"
<azonenberg>
i dont do those
<azonenberg>
i have no advice
<awygle>
BOOM
<azonenberg>
awygle: lol
<azonenberg>
most are more like 256
<azonenberg>
but basically, yeah
<awygle>
rqou: i usually make the back a "ground plane", so if there aren't many cuts in the plane nearby i'll keep with the via thing. just do the best you can
<azonenberg>
oshpark is cheap enough that the 2L vs 4L cost increase is usually insignificant
<rqou>
wtf
<awygle>
i learned from this smolfpga thing that 2L oshpark is not worth it, because i can't deal with how long it takes and 4L and expedited take the same time to ship and cost the same
<rqou>
this matlab code i'm looking at decides to do stuff based on the magic "computer" variable
<rqou>
but it only checks the first character
<rqou>
and if it's M or G it does one thing and if it's P it does another
<awygle>
wow
<awygle>
Quality Software (TM)
<rqou>
yup
<rqou>
matlab is garbage all around
<rqou>
the ecosystem, the tool itself, just everything
<awygle>
my new april's resolution is to be less negative about software
<awygle>
so is a reset sequencer a "power management", a "power protection", or a "power supervisor"?
<rqou>
er, wtf?
<rqou>
what kind of question is that?
<rqou>
i personally would lump it under power management
<rqou>
i wouldn't even bother distinguishing power supervisor from power management
<awygle>
it's a "which kicad library should i put it in" question
<awygle>
eh, i'll do it tomorrow. i asked in #kicad, maybe someone will answer overnight
<awygle>
i completely forgot microchip bought micrel
<rqou>
lol
<rqou>
didn't i _just_ point that out a few days ago?
<awygle>
possibly
<awygle>
i thought it was a different one though
<awygle>
not like there aren't plenty to keep track of lol
<rqou>
hmm, i think it was LT->AD a few days ago
<rqou>
micrel->microchip did get brought up though
<rqou>
so, when do we get "The Semiconductor Company?"
Lord_Nightmare has quit [Ping timeout: 265 seconds]
<azonenberg>
awygle: yeah this is one of many reasons i dont use the kicad official libs
<azonenberg>
With my own stuff i have specific organizational strategies and policies
<azonenberg>
that in some cases directly conflict with theirs
<awygle>
yeah but you'll hit an edge case eventually too lol
<awygle>
Taxonomy Is Hard
<rqou>
i personally would lump fancy PMICs, regulators, reset supervisors, current sensors, etc. all under "power management"
<awygle>
honestly ICs is one case where "fuzzy text search" might actually be the best solution
Lord_Nightmare has joined ##openfpga
<azonenberg>
i have one for "power", one for "xilinx", one for "analog"
<azonenberg>
one for "special" which is everything i couldn't otherwise categorize
<rqou>
lol that simple?
* rqou
throws azonenberg a mercury arc rectifier :P
<rqou>
would that fall under "passives?" :P :P
diadatp has joined ##openfpga
<azonenberg>
rqou: no idea, i've never contemplated using one :P
<azonenberg>
i do use kicad's standard passive symbols
<azonenberg>
those are simple enough i figure they cant screw 'em up much
<azonenberg>
But my own footprints
<rqou>
fine
* rqou
throws azonenberg a triode
<rqou>
find a category for that :P
<azonenberg>
vacuum tubes
<azonenberg>
:p
<rqou>
do you have such a category?
<azonenberg>
No
<azonenberg>
I dont work with obsolete/retro stuff
<rqou>
fine fine
* rqou
throws azonenberg a 2.4 GHz magnetron :P
<rqou>
what category is that? :P
<azonenberg>
crazy_russian_hacker_supplies
<rqou>
er, not really
<rqou>
they're in every microwave oven
<azonenberg>
yes but, using it for stuff other than cooking?
<azonenberg>
:p
<azonenberg>
incidentally
<rqou>
lol
<azonenberg>
monochroma has a *very* nice microwave oven
<rqou>
yeah
<azonenberg>
made by, i kid you not, Raytheon
<rqou>
you need to buy ones that are >1000W
<rqou>
apparently those are a different and better design
<rqou>
~600W microwaves are garbage
<awygle>
1100W microwave is a fantastic upgrade
<azonenberg>
yeah i have a 1.1 or 1.2 kW at the new house, the rental has a 00ish
<azonenberg>
its a big upgrade
<azonenberg>
but where i was going is
<azonenberg>
She has a microwave oven made by raytheon, i had no idea they had ever made consumer products
<awygle>
i wonder sometimes if paying Real Money for a vacuum would improve my universally-terrible vacuum experiences
<awygle>
or if there is _any_ dishwasher design that is capable of washing dishes
<azonenberg>
apparently the shielding is so many dB better than consumer microwave ovens made today that she can't even see it on a specan when it's running
<azonenberg>
whereas modern ones meet exposure limits but arent meant to be low noise
<azonenberg>
awygle: if you dont mind noise, shopvac
<azonenberg>
they suck, in the good way
<awygle>
well yes but they're not effective for wide-area floors
<awygle>
i just want to vacuum my rugs :p
<azonenberg>
Sure they are
<azonenberg>
just put the wide tip on instead of sucking with the raw pipe/hose
<awygle>
okay, like 4 square inches at a time
<awygle>
i want something with wheels colocated near the sucky part :p
<azonenberg>
This head is like 8" wide
<azonenberg>
Which is more than good enough for me
<azonenberg>
i used a similar one in NY when i lived there for cleaning house
<azonenberg>
we didnt even own a regular one
<rqou>
so azonenberg, what category would you use for the schematic symbol for a frying pan? :P
<rqou>
(i assume you too have seen this post on birdsite)
<azonenberg>
I have not
<azonenberg>
passive, i'd imagine
<azonenberg>
unless you're trying to make a Schottky junction out of rust?
<rqou>
ah, the context was that this was found in the appnote for an induction stove controller
<rqou>
iirc it was in reply to a datasheet for an IC that had a "BAGEL" pin
<awygle>
qu1j0t3: it will make me less depressed if I focus on how to make things better instead of how terrible everything is
<pie_>
awygle, DONT THINK ABOUT IT MORTY
<awygle>
woo libraries merging
<awygle>
pie_: nice memeing lol
<awygle>
I'm not talking about denial, just trying to fight learned helplessness. "Everything is terrible and we'll never fix it" is not as good for my mental health as "there are many problems, here are some thoughts on solutions"
<qu1j0t3>
awygle: fair point
<qu1j0t3>
awygle: Mind you i didn't say "we'll never fix it" -- but I am curious when we start :)
<pie_>
yes
<awygle>
qu1j0t3: I specifically didn't use "shitfire" to indicate that I wasn't really talking about you :-)
<awygle>
(actually I was talking about gravislizard and mcclure111)
<qu1j0t3>
awygle: oooh two people i really enjoy
<awygle>
I do too! But I often am sad after reading a particularly ranty post from them. So I am trying hard to not rant in that way myself. They've got it covered :-)
<qu1j0t3>
:)
<qu1j0t3>
on a positive note i was going to say the other day that this channel is like a better version of ##electronics lately
<qu1j0t3>
i see i'm not alone in enjoying that
<pie_>
##dependent is the better ##logic, ##openfpga is the better ##electronics, ##proglangdesign is the better ##programming (or whatever)
<pie_>
i just wish i had a goddamn clue what was ever going on in dependent xD
* awygle
joins some channels....
<sorear>
should I start a channel for the ZFC heretics
<pie_>
did a type theorists steal your girlfriend? is this a Nobel thing?
<pie_>
awygle, hahahaha
<qu1j0t3>
awygle: "Bring your dentist to work day"
diadatp has quit [Ping timeout: 264 seconds]
bitd has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
bitd has joined ##openfpga
diadatp has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
rohitksingh has joined ##openfpga
<q3k>
why is the SD card standard such a shitshow
<q3k>
seriously, in what world is calling your commands CMD{0..63} a good idea
rohitksingh has quit [Quit: Leaving.]
<pie_>
a nihilitic one
<pie_>
nihilistic
bitd has quit [Ping timeout: 255 seconds]
RaivisR has joined ##openfpga
bitd has joined ##openfpga
<cr1901_modern>
q3k: You get used to it :D. Why do you need it?
<q3k>
nothing anymore
<q3k>
just took me an hour to understand what CMD6 does
<q3k>
because 'SWITCH' of course means 'modify EXT_CSD'
<cr1901_modern>
Oh it gets worse (but you still get used to it). Trying to figure out when CMD23 (write a specified number of blocks) is supported is fun.
<cr1901_modern>
On old cards it's not guaranteed to be supported. Guess who only has SD cards that doesn't support it :D?
<q3k>
i'm not even implementing anything, just reverse engineering something that reads from en eMMC card
<rqou>
zomg i wasted an hour because matlab's lyap function takes the transpose of the matrix used in lecture
<rqou>
q3k: lol I can't even find the code that touches the emmc
<rqou>
afaict it's not "just" a set of mmio registers? i don't understand how it works
<q3k>
it is
<q3k>
4 sets of mmio registers for 4 different controllers
<q3k>
as per the tegra RCM
<rqou>
those only seem to control the voltage and timing?
<rqou>
i can't find the "send a command" register
<rqou>
maybe i misread it
<q3k>
the base ones are from the sd host controller spec
<q3k>
and they're not in the tegra rcm
<rqou>
oooh
<rqou>
wtf
<rqou>
i didn't even know there was a standard host controller spec
<rqou>
guess I've only ever used nonstandard sdio controllers
<rqou>
i just remember a lot of random reply types like R1, R2, etc that i have no idea why they need to be different
<rqou>
aka "sdio sucks"
<q3k>
yeah, it's the same in the sd spec itself
<pie_>
tfw the spec is really just a ost ex facto api reference
<pie_>
*post
<rqou>
also, transferring files Linux<->Windows sucks as usual
<cr1901_modern>
q3k: It's not the same PDF that has those regs IIRC
<cr1901_modern>
but yes, most SD card controllers are the same from the programmer's perspective
<cr1901_modern>
(emph most)
<rqou>
as in "send command, get reply, exchange data"?
<rqou>
i don't understand why they need to be so complicated
* pie_
mumbles about giving mousies cookies
* pie_
mumbles about *wanting* to give mice cookies
* pie_
mumbles about wanting to let people give mice to cookies
* awygle
checks to see if pie can hold his arms level and if his smile is cooked
* pie_
's smile is level and takes a bit of his arms
<rqou>
so, i just finished my problem set
<q3k>
i'm really trying to see what pie_ said about mice to be an allegory for the emmc/sd standard
<rqou>
it's actually really really cool if it weren't for Matlab
<pie_>
for the record im just making all this up and im a shitt ytroll
<rqou>
finding reachable sets and regions of attraction using sum-of-squares programming
pie__ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
<rqou>
so now, should I a) file bugs on octave to get this toolset to work with it b) port stuff to python like a sane(?) person c) ignore it and get on with my life :P
<azonenberg>
rqou: ratfab is gross
<azonenberg>
i'm working with it now b/c a client's project is using it
<azonenberg>
brings back horrible memories of school when i was forced to use it
<rqou>
also, it's pretty disappointing that the python side really is lacking in tooling for this stuff
<rqou>
although it has the same linalg building blocks
<rqou>
azonenberg: so which of the options a/b/c would you recommend for me?
<rqou>
also wat, a (presumably) embedded thing using matlab?
pie_ has joined ##openfpga
<rqou>
with simulink?
pie__ has quit [Read error: Connection reset by peer]
<azonenberg>
rqou: yes
<azonenberg>
it's the most painful code review i've ever done
<rqou>
oh right, you mentioned this before
<rqou>
hmm, why?
<rqou>
i thought simulink can't really have sploits?
<rqou>
I thought it's a memory-safe language?
<azonenberg>
i cant go into detail on the problem domain etc
<azonenberg>
But you can still have logic bugs
<rqou>
are you doing a math review?
<rqou>
because i can't really imagine any other kind of bug
<rqou>
azonenberg: "the reachable set of this feedback control system includes unsafe states" <-- this kind of bug?
<pie_>
oh god i updated firefox and now everything is different
<azonenberg>
Maybe? cant really go into more detail
<azonenberg>
all i can say is i hope i never have to touch matlab again :p
<rqou>
wait are they using matlab/simulink to do more than "do math for feedback controls"? if so, then oh god nopenopenope
<cr1901_modern>
until recently I wouldn't use scipy for filter design; they had no way to do SOS (and still no pole-zero plot)
lain__ has joined ##openfpga
<rqou>
SOS?
<cr1901_modern>
second-order sections
lain has quit [Disconnected by services]
<q3k>
rqou: not all security issues are due to memory safety
lain__ is now known as lain
<rqou>
true
<pie_>
oh god noscript is all different
<pie_>
is this how my dad feels about computers
<rqou>
i guess i just have some preconceived ideas of what you're"supposed to" use matlab/simulink for
<rqou>
i.e. I don't consider it a general purpose language
bitd has quit [Ping timeout: 240 seconds]
<q3k>
rqou: i have a feeling that if you use matlab, you'll think you can use it for everything
<q3k>
rqou: i mean, that's kind of their selling point
<q3k>
test your math! write your simulation!
<pie_>
oh god what is this new terrible shiny ui
<q3k>
generate hdl!!!111
<azonenberg>
q3k: you're starting to get an idea of what i'm dealing with in $client's codebase :p
<rqou>
and if i had to use it i would design the system like "write out a mat file, matlab reads mat file, matlab does math, matlab writes answer mat file, 'real' system reads answers"
<q3k>
you're assuming rational decisions
<rqou>
azonenberg: ah, so it's not "just math"
<rqou>
i feel sorry for you lol
<azonenberg>
rqou: ever seen [redacted] protocol parsing in simulink?
<azonenberg>
yeah, exactly
<rqou>
zomgwtf
<rqou>
what the fuck
<cr1901_modern>
gnuradio is supposed to be "free simulink", right?
<cr1901_modern>
for some liberal definition of "simulink"
<awygle>
_very_ liberal definition
<pie_>
siiiigh, time to get used to this i guess
indefini has quit [*.net *.split]
anuejn has quit [*.net *.split]
forrestv has quit [*.net *.split]
<pie_>
it was http wasnt it
<pie_>
@ protocol parsing
<pie_>
either that or smtp
<rqou>
seriously, why are the f/oss tools in this space all awful?
<pie_>
probably domain knowledge
<rqou>
but these formulas and algorithms were all (for the most part) discovered in the 60s
<awygle>
foss is historically terrible at usability
<awygle>
feel free to insert your own clapping emoji into the above
<q3k>
rqou: probably because 'murrican universities are rich enough to afford matlab for everyone
<pie_>
maybe foss is a crapshoot
<rqou>
q3k: lol
<q3k>
awygle: ... like matlab is the paragon of usability
<awygle>
q3k: fair
<awygle>
cr1901_modern: i was, at one point, contributing to scilab, and they had a simulink thing
<awygle>
which i think fit the definition better than GRC
<awygle>
which, for the record, is not the entirety of GNU Radio
forrestv has joined ##openfpga
<rqou>
wtf another matlab-like clone?
<cr1901_modern>
Dunno, I've barely used my amatuer license since I got it lol
<rqou>
why do people keep inventing random programming languages for scientific/numeric stuff?
<q3k>
well in the open sauce space there's really only octave and scilab, no?
anuejn has joined ##openfpga
indefini has joined ##openfpga
<rqou>
why not just use your favorite kitchen sink dynamically-typed language (i.e. js or python)
<q3k>
well, maybe sagemath as well
<q3k>
but that's different, as far as I get it
<q3k>
rqou: probably because first class support for construct like matrices
<q3k>
rqou: you're free to use numpy and friends
<rqou>
python has that now
<awygle>
scilab's not bad except as a developer
<rqou>
the @ operator
<cr1901_modern>
it's still not as nice as [1 2 3] * [4 5 6]'
<rqou>
except for the part where "first class support for matrices" is basically never what I want anyways
<qu1j0t3>
rqou | why do people keep inventing random programming languages for scientific/numeric stuff? // I think it's the ORM + framework problem. The existing ones are bad, everyone wants something else, some of them try to build one. Adding 1 to N.
<awygle>
python needs .*
<rqou>
why?
<awygle>
so it can be matlab
<qu1j0t3>
(i'm sure there's an xkcd about this but i'm not a big fan so)
<rqou>
also imho the toolkit available in scipy is mostly bits I don't care about and missing all of the bits i actually wanted
<awygle>
the real reason FOSS stuff is bad is because almost no one has found a sustainable source of funding for it
<awygle>
so as soon as the maintainer gets bored, they're no longer incentivized to work on it, and as soon as they have to pay bills, they're _negatively_ incentivized
<implr>
q3k: tbh probably most universities everywhere can afford matlab, I'd expect they get huge academic discounts
<rqou>
you mean patreon isn't a sustainable funding source? :P
<balrog>
no one's been bothering on cloning matlab
<awygle>
not for most people, no.
<rqou>
UBI when? :P
<balrog>
scientific computing has gone towards python based workflows
<rqou>
not in my experience
<balrog>
rqou: which bits are you missing?
<awygle>
and charging money is incompatible with the ethos of many in open source
<rqou>
balrog: a lot of stuff for feedback controls for instance
<awygle>
i am astonished that non-commercial licenses like CC-BY-NC aren't used more in dual-licensing schemes, but *shrug*
<balrog>
GPL heavily is
<rqou>
balrog: e.g. how about "sum-of-squares programming and reachable set analysis" that i was just forced to use matlab for
pie__ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
<awygle>
not as heavily as i'd expect tbh. and the resistance to AGPL is interesting as well in this context.
<rqou>
although i did also just use cvxpy which does somewhat related stuff
<implr>
awygle: that's probably because (people think) it is contagious
<awygle>
implr: AGPL specifically, more so than GPL?
<awygle>
or just the whole copyleft ecosystem
<implr>
e.g. many huge corporations outright ban mongodb, because agpl, even if they're not planning to ever modify it
<implr>
lawyers get really scared by agpl for some reason
<balrog>
how about ghostscript?
<cr1901_modern>
I haven't willingly read a postscript file (IBM Ultimotion spec) since 2011
<awygle>
Postscript: Not Yet PDF
<rqou>
PDF: not yet a CVE :P
<qu1j0t3>
hahahahahh
<balrog>
rqou: what did you need from matlab for those?
<rqou>
there was some package written by some academics that required matlab
<rqou>
octave doesn't work
<rqou>
this part is actually open source, so porting is possible
<awygle>
i just want a graphical interface for control systems. does octave have a simulink equivalent yet?
<balrog>
ahhhhh
<rqou>
unfortunately it also uses matlab's object system (which i didn't know even existed until yesterday)
<balrog>
ew!
<rqou>
the actual core probably only requires your bog-standard linear algebra toolkit
<rqou>
balrog: the package is called SOSOPT if you want to take a look at
<openfpga-github>
[Glasgow-JTAG] whitequark commented on issue #15: > I'm good with having a footprint with thermals vias and making it the default. Vias can also be added by the user in the PCB, but obviously it's best and easiest to build it into the footprint. I have asked Cypress for a recommended footprint. The reference design mentioned above uses 25 vias with 10mil drill (0.254mm), 22mil annular rings (0.5588mm), and
<awygle>
whitequark: any updates you think i need other than what's been on github?
<whitequark>
awygle: regarding the Cypress footprint?
cpresser has joined ##openfpga
<awygle>
whitequark: just glasgow in general. i know you've started layout, and presumably schematic too.
<whitequark>
yeah, it's all local right now
<whitequark>
so for the iCE40 symbol, shouldn't the power pins be on top?
<whitequark>
in the IO banks
<awygle>
yep
<awygle>
there's a bunch of things wrong with the ice40
<whitequark>
right, so that was why I'm holding off from using that symbol right now
<awygle>
i was hoping they'd address the central "multiple unit symbol" question
<awygle>
but that doesn't seem likely so i'll just fix it up tonight to the best of my ability
<whitequark>
can you compare it with other FPGA symbols?
<awygle>
i didn't find any that actually used multiple units
<awygle>
i'm loathe to just make a giant ugly symbol but that's what seems to have been historically done
<awygle>
multi unit symbols are allowed by implication in the KLC, they're discussed in S3.8, but there's no actual guidance on their formatting anywhere that i can find
<whitequark>
hmm I swear I've seen one
<azonenberg>
awygle: for smaller FPGAs i have one symbol per bank and one for everything else
<azonenberg>
For bigger stuff i have one per bank, one for power, one for ground, one for jtag/strap/miscellaneous
<azonenberg>
for a really huge (say 1156 ball) part i might even have >1 each for power/ground
<awygle>
azonenberg: yes, that's what i do as well
<azonenberg>
7 series is nice here with the flat 50-pin banks
<azonenberg>
spartan6 had some fairly large banks
<awygle>
there doesn't seem to be any of that in the kicad libraries though, or i missed it (totally possible)
<azonenberg>
kicad libs probably just dont have any massive multi-hundred-pin parts
<azonenberg>
last time i looked at their libs they're stuck in the dark ages with 74xx stuff, i think i saw some xc3000 fpgas, etc
<whitequark>
they even have that monstrous FLG1925 package
<awygle>
hm
<awygle>
okay i'll take a look at that when i get home
<q3k>
cern use kicad for some somewhat beefy fpga designs
<q3k>
so it's certainly not a software limitation
<whitequark>
awygle: XC7V2000T goes to Unit R
<q3k>
but yeah, kicad stock libs are shite (but that apparently changed recently)
<whitequark>
q3k: yes, we're using and contributing to kicad 5 libs
<whitequark>
so far I'm quite happy with them
<awygle>
whitequark: i think i was probably just unfamiliar with the system at the time i looked. i know i had an old version of the footprints and stuff at one point.
<q3k>
whitequark: oh, neat. maybe it'll be time to ditch smisioto :)
<q3k>
s,time,soon time,
<q3k>
i love his libraries, but the license irks me
<q3k>
(the -sa part is fine, the -nc is my problem)
<azonenberg>
q3k: i use his 3d models
<azonenberg>
for some stuff
<azonenberg>
But on my own footprints, and i don't redistribute the models
<azonenberg>
i just include paths pointing to them
<q3k>
yeah, I'm talking about the footprints/symbols
<q3k>
which you could argue are just programs that paint lines into your layout
<q3k>
but I don't want to get into such ridiculousness
<awygle>
does it smell because it's catching fire?
<Ultrasauce_>
check the silkscreen
<awygle>
...
<awygle>
wow
<awygle>
i read that six times before i got it
<awygle>
i wonder if mine says that. iirc it's a different revision
<rqou>
awygle, whitequark: idk if you saw this the last time i asked, but after you assemble your board i would really like a quick 30-second postmortem: *) how many footprint errors there were and how major *) how was the experience getting PRs merged and how many were
<awygle>
rqou: sure
<awygle>
don't forget *) how many footprint errors were awygle's fault
<whitequark>
rqou: so far every single IC needed a new footprint
<whitequark>
ah no, except one
<whitequark>
and I could reuse one symbol
<whitequark>
erm
<whitequark>
scratch that
<whitequark>
every IC except two needed a new symbol, and two ICs needed brand new footprints
<whitequark>
so far the average time to merge of a PR is slightly over ~3 days
<cr1901_modern>
still better than openocd
<awygle>
That should reduce as I get better at it too
<rqou>
hrm, so that first part isn't _too_ unexpected, since the kicad libs have historically had a rather "quirky" selection of parts
<rqou>
the second part is surprising in a good way
<awygle>
what, the 3 days? you expected longer?
<rqou>
yeah
<rqou>
i expected more bikeshedding
<awygle>
so i've created 7 symbol PRs so far, of which 3 have been merged
<awygle>
the 3 that were merged were merged after 3 days or less
<awygle>
of the remaining 4, two are 4 days old, one is from last night, and the last one, the ice40, is 6 days old
<q3k>
rqou: since cern somewhat took ever the development of kicad the whole thing got much better
<q3k>
rqou: in terms of code and development culture
<rqou>
yeah, i heard the old pre-wayne project leader was "unpleasant" to work with
<q3k>
rqou: and documentation
<whitequark>
yeah I'm pleasantly surprised about interactions with maintainers
<whitequark>
they really care about making the best libraries possible
<whitequark>
and there's none of the linus-style abuse that's common in FOSS
<rqou>
i do remember reading an awful email from the old maintainer dick hollenbeck yelling at a confused newbie(?) who "stole" some cmake scripts from kicad
<rqou>
iirc it was right before wayne took over
<rqou>
i was especially not impressed because i was thinking "dude, it's just a cmake script, chill"
<cr1901_modern>
I thought the original dev of kicad still made contributions? Maybe I'm wrong?
<awygle>
yeah all the maintainers i've spoken to have been great
<awygle>
i feel sort of bad for them though, they're carrying around an enormous technical debt
<rqou>
eeschema-new when :P
<awygle>
hard to shake the feeling that having that team write a new kicad from the ground up might give better ultimate results
<rqou>
kicad.js :P
<awygle>
(practicality aside)
<rqou>
(azonenberg hates that idea btw)
<awygle>
which idea, rewrite kicad or kicad.js?
<rqou>
kicad.js
<awygle>
of course he does
<awygle>
meanwhile i want kicad.java :p
<rqou>
but kicad.js is pretty impossible at this point with so much wx contamination
<awygle>
(by which i mean, kicad on android would be pretty cool)
<whitequark>
rqou: it has a bazillion of features that all interact with each other in strange and awful ways
<whitequark>
and anything nontrivial compiles for decades
<jn__>
C h i s e l :P
<rqou>
hmm i guess i never tried to use too many features together
<whitequark>
have you *seen* scala's type system?
<q3k>
scala tries to be too fancy
<rqou>
but in general i like the feature set
<whitequark>
it makes C++ template metaprogramming look sane and measured
<q3k>
this leads people to write shitty overly smart code
<whitequark>
well yes, people like C++ too when they don't actually know it
<q3k>
that then ends up being write-only
<rqou>
scala came out of $ANOTHER_FANCY_SCHOOL, so i guess the "mindset" fits :P
<azonenberg>
"alsses are final by default"
<azonenberg>
classes*
<azonenberg>
that sounds like an awful design decision
<whitequark>
azonenberg: I disagree
<azonenberg>
this is the same reason i almost never use private, in the interests of long-term maintainability i rarely can be confident i will never have to derive from a given class
<whitequark>
most classes can't be safely inherited from
<whitequark>
or let me rephrase
<whitequark>
being able to safely inherit from a class requires extra thought when implementing that class
<whitequark>
if you mark it as non-final you expressly state that you did that extra thought
<rqou>
afaict i almost never actually want inheritance
<azonenberg>
rqou: you just don't like OO in general
<rqou>
what i actually wanted was either *) encapsulation *) some mechanism of supplying hook points
<whitequark>
in practice, non-final by default just leads to people inheriting from things that were never meant to be inherited from, and things breaking
<whitequark>
azonenberg: well, OO is bad :P
<azonenberg>
Very often I want a "X is-almost-a Y but can also Z"
<q3k>
*classic java-style OO is bad
<awygle>
rqou doesn't like anything
<azonenberg>
Which is pretty much the textbook definition of OO
<azonenberg>
q3k: i agree
<azonenberg>
I use C+
<whitequark>
azonenberg: is-almost-a doesn't sound like it would satisfy LSP
<azonenberg>
aka, restricted subset of C++ using objects where it makes sense, but freely using global functions where that makes more sense
<azonenberg>
whitequark: i mean "it's basically a Y but can also Z"
<rqou>
i usually see abuses like e.g. in an old minecraft mod where somebody made a "RotatedBB" that inherited for "AxisAlignedBB" so that it could hook into and hack collision behavior
<rqou>
because a RotatedBB is clearly not a more-specific kind of AxisAlignedBB
* awygle
spontaneously decomposes into a million blog posts about "the N types of inheritance" for N in (0, 1000000]
<rqou>
it's not axis-aligned at all
<q3k>
azonenberg: the problem with C++ is not that it doesn't allow you to write good, maintainable code
<azonenberg>
q3k: it's that lots of people don't write code that way
<q3k>
azonenberg: (thus I believe you can write good C+(+), as others can)
<q3k>
... yes.
<azonenberg>
Same as verilog
<q3k>
and even worse, the language kind of wants you to do that
<q3k>
it lures you
<q3k>
with its' fancy new features every year
<azonenberg>
I have an informal list of paradigms/language features that i ban
<whitequark>
forget about fancy new features
<whitequark>
I was writing C++ for fucking *years* and then one day I discovered that I did half of my changes in solvespace basically wrong
<whitequark>
because one shitty C++ feature interacted with them badly
<azonenberg>
what feature?
<rqou>
whitequark: what are your thoughts on "scala came out of $ANOTHER_FANCY_SCHOOL, so i guess the 'mindset' fits"
<whitequark>
I don't remember, but you could try grepping commit logs for angry sentences
* rqou
goes back to my ivory tower
<whitequark>
rqou: dunno, people have frequently accused me of being from ivory tower
<cr1901_modern>
I remember when solvespace was mainly C with classes. Or felt like it anyway lol
<awygle>
rqou: you joke about that but i think it's behind a lot of your "why is X so complicated" questions
<whitequark>
cr1901_modern: it's still more or less that and will stay that way
<rqou>
awygle: what do you mean?
<awygle>
the answer is not, 100% of the time, "because the people who wrote $THING were idiots"
<whitequark>
sure, I use STL now where it makes sense
<q3k>
cr1901_modern: isn't that because it was written by some infosec person?
<whitequark>
because I don't want to become non-interoperable with e.g. SWIG
<q3k>
infosec people have the darndest way of writing code
<cr1901_modern>
yea that's what i meant mostly. Gone are the fopens(), etc
<awygle>
many, many times, it's because "$THING is surprisingly complicated, but the complexity is not immediately apparent if you haven't lived inside the problem."
<cr1901_modern>
whitequark: Still perfectly legible
<whitequark>
cr1901_modern: uh I still use fopen
<whitequark>
ssfopen
<rqou>
wtf
<whitequark>
the only reason the wrapper exists is windows' shitty unicode handling
<rqou>
what's wrong with fopen?
<whitequark>
it uses the OEM code page on windows
<rqou>
wait it does?
<whitequark>
well what the fuck do you think it uses, UTF-8?
<q3k>
...because in 2018 codepages are still a thing
<whitequark>
that would be actually sane, so no
<rqou>
so if i do "shit the bytes from argv into fopen" will that not actually work?
<q3k>
that would be CreateFileEx(<arguments>)
<whitequark>
rqou: argv doesn't exist on windows
<rqou>
yeah it does? at least in mingw
<whitequark>
well it does but it doesn't contain useful data
<rqou>
there's a c runtime
<whitequark>
you have to do GetCommandLineW()
<rqou>
er, it contained the command line every time i tried it
<whitequark>
and then CommandLineToArgvW()
<whitequark>
yes but it's fucked if you pass unicode there
<rqou>
it is?
<q3k>
rqou: command line applications are not really win32 applications
<whitequark>
because it's lossily converted to OEM codepage
<rqou>
so `fopen(argv[1], 'rb'); // wtf is an encoding i don't care` doesn't actually work?
<whitequark>
nope
<rqou>
wtf
<rqou>
TIL
<whitequark>
moreover
<rqou>
i always thought if i just blindly shuffled bytes around it would "just work"
<whitequark>
you have to convert your paths to UNC or you're limited by 250 characters
<whitequark>
so you can be passed a path that you can't open
<rqou>
wtf
<cr1901_modern>
whitequark: My mistake, it was strcpy and friends that I used when originally impl the THREE.js export. Back then that matched the rest of solvespace.
<rqou>
windows is such a broken pile of crap
<whitequark>
and UNC paths have to be normalized, so you have to convert forward to back slashes
elms has joined ##openfpga
<whitequark>
and can't use ..
<rqou>
TIL about that too
<whitequark>
there's a thousand line file in solvespace that *solely* handles these windows shenanigans
<azonenberg>
whitequark: so if you UNC you can have a filename longer than MAX_PATH?
<azonenberg>
that's not a hard limit anymore?
<azonenberg>
(can you tell i haven't done windows dev in a decade?)
<whitequark>
azonenberg: yes
<rqou>
so if i just wrote `fopen(argv[1], 'rb'); // wtf is an encoding i don't care` and then gave it a filename not in the OEM code page, what happens?
<q3k>
rqou: it has a good reason to be acting so weird - backwards compatibility
<whitequark>
azonenberg: also on windows 10 you can relax the limit for non-UNC paths via a manifest
<whitequark>
but not on earlier versions
<whitequark>
rqou: well, it assumes the filename is in OEM codepage
<rqou>
which part is "it"?
<rqou>
my argv is a "char **"
<rqou>
is it mangled already?
<whitequark>
yes
<rqou>
wtf
<rqou>
who wrote this shit
<whitequark>
there's a wmain, which has a widechar version of argv
<whitequark>
that you can pass to _wfopen
<whitequark>
also, _wenviron
<rqou>
but that's bullshit and nonstandard
<whitequark>
sure
<azonenberg>
what about _tmain and _T("hello") :p
<rqou>
fuck off :P
<cr1901_modern>
I wonder if that windows-shenanigans file alone would make a decent "mini platform abstraction" library
<azonenberg>
Also can we not just pick some fixed size field
<azonenberg>
32 bits if uint16 isn't enough
<rqou>
yeah, tell that to all the people on *NIX that insist on honoring LOCALE encodings
<azonenberg>
and just say, this is sizeof(character) and we will never have more than 4B unicode characters
<whitequark>
azonenberg: that's kinda pointless
<azonenberg>
then just fixed size everything, so you can e.g. seek to an arbitrary offset in a text array and actually be that many letters in
<azonenberg>
etc
<whitequark>
no
<whitequark>
bad azonenberg
<whitequark>
that doesn't work
<rqou>
my personal policy is that LOCALE encodings are ignored and utf-8 is always used
<whitequark>
why? because combining characters
<rqou>
LOCALE should only be used for fetching translations
<whitequark>
when rendering text you only care about grapheme clusters
<azonenberg>
whitequark: if you have a 32-bit space can you not have "every character in your language + every legal accent mark" as its own code point?
<whitequark>
and grapheme clusters are inherently variable-width
<cr1901_modern>
^This doesn't go away in UTF-32?
<whitequark>
absolutely not
<rqou>
azonenberg: that's called perl NFG i think?
<awygle>
azonenberg: what is a "letter"
<whitequark>
see: zalgo
<azonenberg>
i.e. having a chinese "big" ideograph
<whitequark>
well more realistically
<whitequark>
see: hangul
<azonenberg>
with a German umlaut accent
<azonenberg>
makes no sense
<rqou>
oh yeah, hangul is pretty fucked
<whitequark>
also see: chinese ideographic variants
<rqou>
U+FDFD is also great for breaking wcwidth
<whitequark>
you can have up to 16 (I think) ideographic variants of any character
<rqou>
hey azonenberg, we need a Qboid here :P
<cr1901_modern>
Is UTF-32 actually preferable to UTF-8 in any application if grapheme clusters cause text to be variable width?
<whitequark>
azonenberg: for that matter, precomposed characters are essentially deprecated
<whitequark>
cr1901_modern: it isn't
<whitequark>
it's a stupid waste of space
<awygle>
a letter is a lie that english speakers tell themselves
<q3k>
awygle++
<awygle>
see also: reverse a string
<whitequark>
lol
<rqou>
lol
<awygle>
as with many other fictions, it's convenient and useful, but it's not appropriate in the general case
<azonenberg>
whitequark: are you saying there are >2^32 graphemes in the sum of world languages?
<whitequark>
the *only* reason precomposed characters exist is lossless conversion to and from legacy encodings
<whitequark>
azonenberg: 2^20
<whitequark>
that ship has sailed long ago
<rqou>
other trolly unicode behaviors: using normalization and then stripping combining characters will also strip dakuten
<azonenberg>
So if we had a uint32_t per grapheme
<rqou>
not just "accent marks"
<azonenberg>
and a new code, not unicode
<azonenberg>
(ignore compatibility, just thinking architecturally)
<whitequark>
azonenberg: consider the combinatorial explosion that is unicode
<azonenberg>
What would break?
<whitequark>
erm
<rqou>
i'm pretty sure perl NFG tries to do something like this
<whitequark>
that is emoji
<awygle>
just follow manishearth on twitter for a couple months, and give up on ever making anything work
<rqou>
i don't know what the limitations are
<azonenberg>
yes but as i mentioned, combining accents from one language with letters from another makes no sense
<cr1901_modern>
azonenberg: I don't care for it's complexity either (no doubt b/c I can get away w/ 128 characters for the rest of my life), but Unicode is an inherent, necessary complexity.
<Bike>
thank
<whitequark>
it's not actually encoding pixels
<whitequark>
it's sort of... simultaneously better and worse
<rqou>
W H A T T H E F U C K ? !
<rqou>
can i get some of those nice drugs the unicode consortium's got? :P
<Bike>
you give it the hash of an image, which the renderer is aware of?
<whitequark>
yes
<azonenberg>
Also why do emoji exist?
<Bike>
«These rogue "moji"»
<q3k>
by the time it gets introduced quantum computing will be a thing and your iphone will just break the hash and find the original image
<azonenberg>
Given that we have <img src="blah"/>
<Bike>
can't do that in SMS
<Bike>
i guess
<whitequark>
^
<azonenberg>
Bike: mms + embed tag?
<Bike>
or any of the billion other media in which we don't have a markup language
<whitequark>
^
<Bike>
like discord or, irc i guess
<azonenberg>
q3k: or you get a hash collision
<whitequark>
azonenberg: it doesn't really matter why they exist
<Bike>
though i use irc in terminal so they're not going to look terribly nice
<whitequark>
any new encoding will have to represent them or die in obscurity