<jn__>
pie_: *ponders* what if GNU is actually just one big yak-shaving operation? they set out to make an operating system, and then they wrote a compiler, and 30 years later they still don't quite have an OS
<jn__>
so the GNUs remain unshaven
<pie_>
ugh
<pie_>
and we are all complacent in this
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<pie_>
crashing my session,...that works too.
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
<pie_>
what the fuck? having two monitors made it start two of everything
Miyu has quit [Ping timeout: 264 seconds]
<qu1j0t3>
yay!
Miyu has joined ##openfpga
<awygle>
I somehow had no idea that I get tomorrow off. Awesome.
noobineer has joined ##openfpga
<mithro>
awygle: Hacking on SymbiFlow is a great way to celebrate that american freedom :-P
<mithro>
I don't quite understand what the LATCH / ICEGATE stuff is in the iCE40 IO tile is used for?
unixb0y has quit [Ping timeout: 265 seconds]
unixb0y has joined ##openfpga
ZombieChicken has quit [Quit: Have a nice day]
ZombieChicken has joined ##openfpga
ZombieChicken has quit [Client Quit]
<rqou>
azonenberg: ping?
ZombieChicken has joined ##openfpga
<rqou>
awygle, whitequark: ping?
<azonenberg_work>
rqou: still at the house but taking a break, had to get out of the gas mask for a while
<azonenberg_work>
whats up
<rqou>
azonenberg_work: can you think of a good algorithm for taking the routing database i have right now and "summarizing" it?
<rqou>
other than doing it by hand
<rqou>
so e.g. i can print out all mux settings for "right-going wire, index 0"
<rqou>
and as i move around the array there are consistent patterns
<rqou>
such as "the single-bit setting is always the lut output index 0 of the tile to the right"
<rqou>
how can i determine these patterns with an algorithm rather than by hand?
<rqou>
(this might also be useful for s3/s6 if anybody wants to do that)
<azonenberg_work>
hmmm
<azonenberg_work>
not really? :p
<rqou>
the problem is that there's also a decent number of corner cases
<azonenberg_work>
but my brain is melting from the long hours and overworking
<rqou>
which also have a pattern, but it's much harder to explain to an algorithm
<rqou>
e.g. "the up wire from 4 tiles down, unless you're at the bottom of the array in which case it's the short wire from the IO"
<rqou>
or "<foobar>, except in X=2 Y=1 where they borrowed a wire from <baz>"
<rqou>
these all make sense to humans
<azonenberg_work>
Yeah
<azonenberg_work>
but i have no idea how to summarize that automatically
<rqou>
how the heck did ice40 get such a nice compact description?
noobineer has quit [Ping timeout: 245 seconds]
<rqou>
azonenberg_work: the problem is, i'm pretty sure nobody wants a tool that has to spend a bajillion seconds parsing a giant json file every time it starts
<rqou>
so i need _some_ way to simplify the description of the interconnect
<rqou>
i remember you specifically saying that in regards to the UFM
<rqou>
*the ZIA
<rqou>
in the coolrunner-ii
<azonenberg_work>
yeah that was all done by hand
<azonenberg_work>
the ZIA i was unable to simplify and just coded a table
<azonenberg_work>
for the 32a
<rqou>
yeah, in this case i don't want tables that get bigger and bigger for each part
<rqou>
because there _are_ consistent patterns
<rqou>
arrgh, this manual process is super frustrating and exhausting
<rqou>
azonenberg_work: wat do next? fuzz larger parts or make a PCB first?
rohitksingh_work has joined ##openfpga
<azonenberg_work>
pcb probably
<azonenberg_work>
gotta be able to test
<azonenberg_work>
But i'm leaving the house
<azonenberg_work>
bbiab
lain has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
Ellied has quit [Quit: SIGNAL LOST]
Ellied has joined ##openfpga
Ellied is now known as Guest12042
Guest12042 has quit [Client Quit]
Ellied has joined ##openfpga
Ellied has quit [Client Quit]
Ellied has joined ##openfpga
<rqou>
wat
<rqou>
exciting new kicad build failures again
<rqou>
also apparently time for a dist-upgrade since i'm way behind as usual
<rqou>
hey, anybody here familiar with "linux desktop/distro glue stuff"?
<feuerrot>
rqou: -v?
<rqou>
feuerrot: for what?
<feuerrot>
the desktop/distro glue stuff.
<rqou>
i'll ping you as i encounter problems
<rqou>
feuerrot: actually, first question
<rqou>
i am currently running an old version of gnome-settings-daemon
<feuerrot>
I'm not quite sure, if I can actually help you, just wanted to ask what exactly you mean by 'desktop/distro glue stuff'
<rqou>
i (believe i) need gnome-settings-daemon because otherwise "misc. weird stuff" like color management and icons don't work right
<rqou>
when i last tried to upgrade gnome-settings-daemon, it broke my setup because the gnome-settings-daemon binary disappeared
<rqou>
it seems to have been replaced by a bajillion separate binaries
<rqou>
the question is: what happened here and what do i need to launch to get "everything working again?"
<rqou>
i am currently held on debian sid g-s-d version 3.22.2-5
<feuerrot>
uhm, sorry, I didn't use gnome in the last few years
<rqou>
this is starting to become a problem because it's starting to block more and more packages
<rqou>
feuerrot: ok, next question: are you familiar with gpg?
<rqou>
i am currently using gpg to act as ssh-agent while also allowing me to use a yubikey in gpg smartcard mode
<rqou>
somehow, this stops working if i let gpg get upgraded to whatever the current version is
<rqou>
i'm currently held on version 1.4.20-6
<rqou>
i don't remember what the specific issue was, but iirc it was that after unplugging and replugging the yubikey nothing would ever work again
wolfspraul has quit [Ping timeout: 260 seconds]
<feuerrot>
nope, never used gpg as a ssh-agent. I used gpg with smartcards a few times, but it was always painful, requiring pcscd-restarts and so on
<rqou>
so right now with my held version of gpg it doesn't seem to require restarting pcscd
<rqou>
but holding on to old packages isn't actually a good long-term solution
<rqou>
i'm really really tempted to just write my own smartcard-capable ssh-agent
<rqou>
why is this so f*cking hard?
<azonenberg>
Sooo does anyone know of a good BSDL library?
<azonenberg>
ideally i just want to map idcode to IR length
<azonenberg>
more functionality isnt needed at this point
<rqou>
lol
<azonenberg>
idcode -> {name, ir len}
<rqou>
try hacking into yavhdl? :P :P
<azonenberg>
basically i want the ability to have jtaghal ignore unused chips in a chain
<azonenberg>
But knowing where in the chain your DUT is requires knowing the IR lengths of the other chips
<azonenberg>
there might be a clever way to automagically discover, idk
<azonenberg>
but i havent found one
<rqou>
azonenberg: have you updated your kicad recently?
<rqou>
azonenberg: have you ever seen "wxWidgets and wxPython use different toolkits (gtk2 vs gtk3)."
<azonenberg>
i'm using 5.0.0-rc2-dev-442 with wx 3.0.2
<azonenberg>
with, interestingly, gtk2
<rqou>
my currently working version says "wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24"
<rqou>
awygle: do you have a "final summary" of your experience working with upstream kicad libs?
<rqou>
e.g. what went well, whether there were any errors that were their fault, how the upstreaming process went, etc?
<rqou>
did anything go poorly?
<awygle>
rqou: it's been pretty good tbh. i'm personally quite short-tempered with what i perceive as nitpicky changes, so it caused me a certain amount of stress, but taking a step back and looking at it objectively things went quite well overall
<awygle>
the big thing i had an issue with was multi-unit symbols, we had to kind of work that out iteratively
<awygle>
i recommend going through some of my PRs and reading the things i got told because i felt that not everything was in the KLC for footprints in particular
<rqou>
what about things like kicad's pin1 style or subtle variations in footprints between different vendors?
<rqou>
or handsolder vs minimal pad sizes
<rqou>
etc etc
<awygle>
for subtle variations i think the usual advice is "just use the generic footprint" but i certainly made a custom one for the cypress part
<awygle>
there are provisions for such in the KLC
<awygle>
same for different pad sizes
<q3k>
azonenberg | Sooo does anyone know of a good BSDL library?
<q3k>
y'all need more Ada in your life
<rqou>
how do they avoid combinatorial explosions with all of the footprints that differ by several mil?
<awygle>
mostly by just using the generic footprint lol
Bike has quit [Quit: Lost terminal]
<rqou>
you didn't have to tweak the generic footprint for yield enhancement or anything?
<awygle>
other than that i'd say "they don't because it's inherent complexity"
<awygle>
the main thing that bit me (on smolfpga not glasgow) was that kicad's default mask expansion is stupid huge
<rqou>
ah, i got bit by that before too
<awygle>
none of the generic footprints seemed to do anything _too_ stupid, yield-wise
<awygle>
for example they have the right amount of paste coverage for QFN pads
<rqou>
what about various handsolder-optimization hacks that i've done and i've seen people do?
<rqou>
e.g. much longer than normal pads
<awygle>
that doesn't seem commonplace in the footprints i looked at
<rqou>
or thermal pads with a big hole in them (which i hate and don't do but have seen)
<awygle>
that they don't do
<awygle>
because it's awful
<awygle>
lol
<rqou>
lol
<rqou>
hrm
<rqou>
i'm getting the feeling that the kicad libs are perfectly fine for most people, but they're still not quite suitable for companies that need maximum yield and have extremely nitpicky PCB people
<rqou>
does that match your experience?
<q3k>
.... i'm fairly sure most companies like that will have their own footprint libraries, anyway
<rqou>
yeah, they do
<q3k>
when I worked with altium/orcad shops they all did
<rqou>
yes
<q3k>
iirc EAGLE ws the firs tmajor player to come with a footprint/part library that you're supposed to use
<rqou>
which i never did
<rqou>
because it never gave me a very good feeling that i can trust it
<q3k>
back when I used EAGLE I did through-hole bullshit, and the library was fine for that
<rqou>
i started out with the SFE libs, but i also made a lot of tweaks
<rqou>
azonenberg (and maybe awygle): are your kicad libs license-compatible with being upstreamed into kicad?
<awygle>
rqou: the thing is that "high yield mass production" companies tweak footprints _per board_
<rqou>
azonenberg: do you have opinions about me sending some of your libs upstream? (the ones i end up using for the project chibi test board)
<awygle>
and i don't have a kicad library, really
<azonenberg>
rqou: mine are 3-clause bsd
<rqou>
um...
<rqou>
that's a bit weird for something like this
<rqou>
but i'll check
<awygle>
also, the altium vault is really good
<azonenberg>
Well that's gpl compatible, the libs are gpl right?
<azonenberg>
or what?
<awygle>
for what it contains
<rqou>
i'll double-check
<awygle>
i think they're CC-BY-SA
<azonenberg>
ah ok
<azonenberg>
i'm fine with that as well
<rqou>
yeah, not the same "heritage" of license
<awygle>
yup
<azonenberg>
I'll gladly relicense under pretty much any f/oss terms
<q3k>
wait, they're cc-by-sa?
<rqou>
since we're on the weird boundary between artistic expression/functional elements
<q3k>
doesn't that mean I can only use them for 'open hwardware'?
<rqou>
q3k: there's also a weird exception
<azonenberg>
that said, i think its unlikely upstream will accept them
<rqou>
i specifically checked
<azonenberg>
Because i don't do full IPC-style pin 1 markings etc
<rqou>
i hate that pin 1 mark too
<rqou>
but anyways, azonenberg: opinions on me modifying your libs/footprints until they are acceptable and then getting them upstreamed?
<rqou>
so i removed libwxgtk3.0-dev, and i get "wxWidgets library has been built against GTK3, it causes a lot of problems in KiCad"
knielsen has joined ##openfpga
<rqou>
why does apt-get install pkg=version exist anyways when it never actually works?
<rqou>
so, very-out-of-the-loop question: why is gtk2->gtk3 such a big friggin deal?
<azonenberg>
rqou: because gnome devs are crazy and made a whole bunch of breaking changes for no good reason
<azonenberg>
They also removed a bunch of really nice features like typeahead in the file open dialog
<azonenberg>
now they only do search instead of highlighting items in the list view
<azonenberg>
everyone seems to be moving towards search as the UI metaphor for everything
<azonenberg>
which is very annoying if you know what you want
<rqou>
is that a gnome problem or a gtk problem?
<rqou>
at the risk of making whitequark very mad at me, why does anybody still even bother with "UI toolkits"?
<rqou>
imo just use either custom everything or whatever a browser engine chooses to give you
<azonenberg>
rqou: because native apps are still a thing, like it or not
<rqou>
(use the second option if you want IMEs/a11y to work properly)
<rqou>
yeah, embed a browser engine into your native app
<azonenberg>
...
<azonenberg>
what next, embed a cpu emulator?
<rqou>
sure
<rqou>
it's called WASM :P
<rqou>
i mean, we've had this disagreement ad nauseam, but i still feel that script-ability+customizability+speed of development of web-based UIs still wins out
<rqou>
also seriously when will we have eeschema-new?
<rqou>
wait awygle your footprints aren't actually upstreamed yet?
<rqou>
what exactly is your workflow?
<rqou>
azonenberg: what's your current preferred approach for jtag?
<rqou>
still the ftdi asic?
<azonenberg>
rqou: until i finish starshipraider yes
<azonenberg>
i dont like it, it's awful, but i have nothing better
<rqou>
whelp, the CPLD_Altera library has a number of nice blatant errors, so that certainly inspires confidence
<rqou>
oh wait no
<rqou>
i confused myself
<rqou>
azonenberg: the high-speed one or the full-speed one?
<rqou>
azonenberg: also, fifo or uart or both?
<azonenberg>
ft232h in mpsse mode
<rqou>
right, i meant for the "other, non-jtag" interface
<azonenberg>
i dont use ftdi for anything but jtag anymore
<azonenberg>
ethernet
<rqou>
lol on a max v? :P
<azonenberg>
trying to have one interface in mpsse mode and one in uart on linux is near impossible
<azonenberg>
ftdi_sio and d2xx cant coexist
<rqou>
er yes it can?
<azonenberg>
how??
<rqou>
i've totally done it
<daveshah>
Hmm, seems fine for the icebreaker
<azonenberg>
the only way i've found is to rmmod ftdi_sio
<azonenberg>
to use d2xx on a stock vid/pid
<rqou>
never had this problem
<azonenberg>
if you change the vid/pid it can load d2xx fine but it wont attach ftdi_sio so you dont get /dev/ttyUSB*
<rqou>
are you sure you aren't thinking of macos?
<azonenberg>
(this is what i do for my jtag dongles)
<azonenberg>
i used a custom vid/pid on my jtag dongles for this reason
<rqou>
i have never had this problem
<azonenberg>
it was the only was to even have a *different* board be using the uart driver while i had d2xx on this one
<azonenberg>
d2xx cant see a board that ftdi_sio has claimed
<rqou>
i usually just use the normal vid/pid and call the "kernel driver plz 2 go away" function
<azonenberg>
i dont think d2xx has a function to do that
<rqou>
windows you fuck around with infs until it works
<azonenberg>
if you do custom libusb calls first, maybe
<rqou>
and macos you're screwed
<azonenberg>
but the other issue is, if you have two modules on a single ft2232
<azonenberg>
now thats one usb device
<azonenberg>
i dont think you can have two drivers attached to a single device sanely
<rqou>
yeah you can?
<rqou>
they're separate interfaces
<rqou>
i've definitely done it before
<azonenberg>
huh
<azonenberg>
circa 2010 there was no way i could find to make it work
<rqou>
that's weird
<rqou>
afaik the linux usb stack has always worked this way
<azonenberg>
anyway, i have no recommendations as i consider usb deprecated
<rqou>
what about just putting in an stm32 instead?
<azonenberg>
the only reason i'm not doing ethernet-jtag already is that nobody makes a COTS ftdi-equivalent for it
<rqou>
other than the fact that i would have to shave more yaks
<rqou>
actually
<azonenberg>
thats the main reason, that and i really dont like realtime stuff in software
<azonenberg>
trying to do timing is a pain
<azonenberg>
in rtl it just works
<rqou>
azonenberg: is there any way whatsoever that i can pretend to be a "usb blaster"
<rqou>
do you know anything about this?
<azonenberg>
you mean what glasgow is trying to do? :p
<rqou>
not quite
<rqou>
ugh, why does everything in this ecosystem suck?
<rqou>
"bring your own programming algorithm"
<rqou>
hmm azonenberg what size sheets do you normally use in your schematics?
<rqou>
i keep finding that US letter doesn't have nearly enough room to fit enough stuff in a page
<azonenberg>
Yes
<azonenberg>
I vary depending on context since i never plan to print mine
<rqou>
i've been thinking of going to A3 and just scaling when i put them on dead tree
<rqou>
(yes, i do put schematics onto dead tree still)
<azonenberg>
I use A4 as the default for small stuff but routinely enlarge to A3 or A2 depending on how much stuff i have going on
<rqou>
i use "highlighter-aided design"
<azonenberg>
i'll often have different pages different sizes
<awygle>
rqou, two days ago: "how hard is it to program a chip?"
<azonenberg>
Since again, i consider it a collection of data and not anything that will ever exist in dead-tree form
<awygle>
Schematics should be 11x17, which iirc is C?
<rqou>
wat
<rqou>
i've never seen that
<awygle>
And reviewing on paper is great
<azonenberg>
that's us-legal
<awygle>
Activates totally different pathways
<azonenberg>
right?
<awygle>
No, legal is 8.5x14
<azonenberg>
ah ok
<azonenberg>
yeah i remember now its the same width as us-letter but taller
<awygle>
11x17 is "engineering paper"
<rqou>
apparently google says it's called "tabloid" or "ledger" or "ANSI B"
<rqou>
and is comparable in size to A3
<awygle>
Ah, B not C
<rqou>
so i guess it depends on how "euro" you want your schematics to feel
<awygle>
And tabloid, yeah
<rqou>
kicad seems to be really biased in favor of feeling very "euro"
<azonenberg>
well half the original library components had descriptions in french :p
<azonenberg>
and now with cern funding dev, everyone goes with what they're most used to
<azonenberg>
i think most of the dev team is eu based
<awygle>
I don't really know what you mean by euro except "resistors are boxes not zig sags"
<awygle>
... Zags, thanks autocorrect
<rqou>
that's a major one, but there's a lot of minor differences
<awygle>
All the other stuff is less "euro" and more "pointlessly not configurable"
<rqou>
e.g. polarized capacitors have a box/line vs curved/straight line
<awygle>
(specifically, fonts in eeschema)
<azonenberg>
they have the curved style too
<azonenberg>
Which i use
<azonenberg>
And the box is actually more convenient for labeling imo
<azonenberg>
since you can put a value inside it
<azonenberg>
(they have the zigzag style but i dont use it anymore)
<rqou>
also apparently IEC inductors are supposed to be a solid rectangle
<awygle>
dafuq why
<rqou>
but i always prefer the "looks like a coil" symbol
<awygle>
yeah inductors are squiggles or parallelograms (for ferrites)
<rqou>
and then according to daveshah they teach (idk about use, but teach) logic gates with the "rectangular shape"
<daveshah>
Yeap, only really teach
<azonenberg>
yeah i go with squiggles
<daveshah>
Then a question or two in the first year then they disappear
<azonenberg>
I use the same symbol for ferrites
<azonenberg>
in fact, i dont usually do FB* for the refdes either
<azonenberg>
i consider a ferrite to just be a low-Q inductor so i do a L
<rqou>
hilariously enough, $FANCY_SCHOOL doesn't actually do much of any training of "how 2 industry standard"
<rqou>
so i use whatever style i happened to learn from/pick up
<azonenberg>
Most schools dont
<azonenberg>
my C++ coding style, for example, is very VC++ inspired
<awygle>
Ferrites are sufficiently terrible at being inductors that they basically aren't anymore
<rqou>
lol
<azonenberg>
awygle: i consider them an inductive element in that they pass DC and block AC
<awygle>
It's like saying a 0 Ohm is an inductor because it's in a package
<azonenberg>
They just don't do a good job of storing it
<rqou>
so what does a leakage transformer count as?
<azonenberg>
is that they have sch symbols for "mosfet n s-g-d, mosfet n g-d-s", etc
<awygle>
The only unmerged are the ice40 and the cypress footprint iirc
<azonenberg>
and they have numbered pins on the symbol
<rqou>
awygle: do you put them in a local lib while you're working on your actual design?
<azonenberg>
from my perspective, when i make the symbol, i dont care about the pin numbering
<azonenberg>
So i have one nfet and one pfet symbol with pins numbered s/g/d
<rqou>
azonenberg: oh yeah i noticed that too
<rqou>
in general the way kicad associates pins _sucks_
<azonenberg>
then i have pins s/g/d on the footprint
<awygle>
rqou: I used them from my local kicad-* checkouts, and then copied them into a Glasgow lib if they didn't get merged fast enough
<azonenberg>
So i have sot23, sot23 sgd, sot23 gds, etc
<rqou>
e.g. if you have a SOIC8 FET you need a different symbol
<awygle>
sot363 is under appreciated imo
<rqou>
because kicad can't understand "yes, all 3/4 of these pins are d/s"
<azonenberg>
actually, i have made soic prints with such pinouts iirc
<awygle>
and yeah the only pcb tool that does parts right is altium imo, because it separates component from symbol from footprint
<azonenberg>
its legal to have more than one copper pad in a footprint with the same pin number
<rqou>
W H A T
<rqou>
brilliant
<rqou>
/s
<awygle>
Should separate models too but oh well
<rqou>
awygle: what about eagle?
<azonenberg>
rqou: no, it makes perfect sense
<awygle>
rqou: uh that's totally standard
<azonenberg>
imagine two holes in a PTH connector for "shield"
<awygle>
every pcb tool allows that
<rqou>
huh
<azonenberg>
you dont want shield1, shield2, shield3, etc and multiple pins in the schematic
<rqou>
iirc eagle didn't?
<azonenberg>
eagle is stupid, dont take inspiration from it :p
<rqou>
azonenberg: i always thought the kicad approach was to make all but 1 pin invisible and then stack them
<awygle>
Doesn't eagle have that stupid "assign footprints to symbols now" step?
<azonenberg>
rqou: that might have been what the lib team did
<azonenberg>
But i never do that
<awygle>
rqou: two different goals
<azonenberg>
none of my schematics stack pins
<daveshah>
Kicad definitely supports multiple pads with the same number
<daveshah>
I always do that for shields etc
<awygle>
WHY THE FUCK IS MY UPSTAIRS NEIGHBOR HAMMERING AT MIDNIGHT
<azonenberg>
awygle: guitar hero?
<azonenberg>
i mean rock band, sorry
<awygle>
no like it's clearly a hammer
<azonenberg>
that was an ongoing problem when i was in school
<awygle>
They're assembling ikea furniture or some shit
<azonenberg>
rqou: the other reason for multiple pads with the same number is for weird shaped polygons
<azonenberg>
sometimes its easier to have (say) a circle and a few rectangles
<awygle>
that's a terrible reason. Just allow arbitrary geometry pads.
<azonenberg>
awygle: this was a common hack before they added support for arbitrary polygons
<awygle>
(but yes in practice you're right)
<azonenberg>
but is no longer needed
<azonenberg>
i would still use it if i wanted round+polygon though
<rqou>
why does the kicad approach to everything seem to be "i added a hack"
<awygle>
They still don't have arbitrary polygons in footprints.
<azonenberg>
but you dont have to stack rectangles to do aribtrary polygons anymore
<rqou>
i guess i do that too
<azonenberg>
they dont??
<awygle>
Nope.
<azonenberg>
i saw that in dev emails a while ago
<azonenberg>
it might not be in release but i could have sworn it was in the nightlty
<rqou>
have they managed to figure out how to kill LOCALE_IO yet?
<awygle>
I think you can like... Paste from the pcb into the footprint
<awygle>
But it's not in the ui
<azonenberg>
So the backend supports it but there's no way to make it
<azonenberg>
lol
<rqou>
oh yeah there's a bunch of features like that
<rqou>
i noticed when converting libs from eagle to kicad
<azonenberg>
kicad has lots of faults, no denying that
<azonenberg>
but it's the best free tool by far and is approaching a lot of the high end ones in usability
<rqou>
sure
<rqou>
except for the part where they have tons of legacy to try and rip out
<rqou>
such as LOCALE_IO :P
<rqou>
which is just the most hilarious comedy of errors ever
<rqou>
i'm glad rich felker decided that locales in string formatting is a stupid idea
<rqou>
huh, KLC states that spelling uses American spelling
<rqou>
which is weird considering how "euro" everything else is
ondrej2 has quit [Read error: Connection reset by peer]
ondrej2 has joined ##openfpga
<rqou>
ugh i don't get how to conveniently work on kicad libs
<rqou>
i think i'll start with my own lib and then work on upstreaming later
<daveshah>
In the early days of Kicad I remember parts of the included libraries were in French, so American spelling is a leap indeed
<azonenberg>
Yeah
<azonenberg>
I still dont think i will ever use their libs
<azonenberg>
just because they are so against everything i want in a design
<rqou>
i noticed that most of my complaints with their libs are either cosmetic and don't matter or various optimizations/hacks that aren't _that_ important
<rqou>
e.g. silkscreen, extra-long pads, hacks for low-end fabs, etc.
<rqou>
or smaller courtyards
<azonenberg>
i should add courtyards to my stuff
<azonenberg>
i tend to do *very* high density placements sometimes
<azonenberg>
i recall one design i did a while ago (client needed it to be small though)
<azonenberg>
that had three BGAs in a line with ~500 um between them
<rqou>
yeah, that's probably not ok by kicad standards
<azonenberg>
let me find some other examples...
<rqou>
yeah, it seems like both of us always seem to have unusual requirements of some kind
<azonenberg>
well i mean, with oshpark
<azonenberg>
i pay per unit area
<azonenberg>
so i use minimal area :P
<azonenberg>
This was with a 'real' fab but had spatial constraints too
<awygle>
apropos of nothing - I want a way to go *from* a language-specific data structure specification *to* a language-agnostic one. Not the other way around. Rust struct to .proto file for example.
<awygle>
well, not "not the other way around" I guess, it still has to work the other way
<rqou>
you mean serde? :P
<rqou>
but yeah, I've thought about this and decided "too much effort"
<sorear>
That’s not that unusual, I think most ORMs work that way?
<rqou>
but most of them aren't designed for what i want to do
<awygle>
Serde can generate a .proto *definition*, which I can then use to generate e.g. Go bindings?
<awygle>
If so I didn't know that.
<rqou>
hmm, maybe not
<awygle>
I have never used an ORM so idk if they do what I'm describing
<rqou>
it's in general really difficult to do something like this in rust right now because there's no way to hook into the compiler after names are resolved
<rqou>
you can only hook in really early directly after parsing
<awygle>
why would you need names to be resolved to operate on struct definitions?
<awygle>
I guess it depends what's in the struct maybe, and if you want to go recursive
<rqou>
yeah, if the struct references other types
<awygle>
In general I am interested in ways to "hoist" existing code to higher abstraction levels
nurelin has quit [Ping timeout: 276 seconds]
kuldeep has quit [Ping timeout: 260 seconds]
kuldeep has joined ##openfpga
genii has quit [Remote host closed the connection]
noobineer has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
<pie_>
awygle, ive mused that it would be cool if there could be automatic glue stuff between type systems, but i really dont know how one would go about doing something like that. like, if you could use type theory/logic to prove equivalences between types in different systems
<pie_>
well....i guess its probably a lot easier to just use something like protobuf
<pie_>
and youd probably have to implement glue code either way so its not like youd be any more ahead. though i guess if it could be autogenerated that would be nice (but perhaps crappy generated code?_
nurelin has joined ##openfpga
<pie_>
mainly because it would be cool if ffi wasnt such a pain in the ass sometimes
<pie_>
i mean if you could keep the abstraction levels of both sides of the ffi on the same level
<pie_>
having one "language" to translate into is more efficient because you only need n-1 implementations (minimum spanning tree), but that means there would need to be a good common ground that works with everything. maybe there are reasons to have more targets for languages that have things in common (like, one for haskell-like types, one for shitty c types (jk :P)), but that means more translator implementations.
<pie_>
ive seen stuff about dealing with diffeerent kinds of logics in one system
<awygle>
Yeah the problem with FFI is that it's a huge pain in the ass and has to be lowest common denominator, but the problem with "foreign data interface" (dumb objects passed around by serialization) is that you end up repeating the same boilerplate in every language
<awygle>
Logic equivalence is an interesting approach to the problem but I am wildly unqualified to speculate on if it'd work
<pie_>
me too :p
<rqou>
doeses anybody know of a way to make creating schematic symbols in kicad less painful?
<rqou>
*does
<reportingsjr>
rqou: use someone else's symbols
<pie_>
write a symbol editor that doesnt suck?
<rqou>
lol
<reportingsjr>
umm, there are some tools to do it
<pie_>
(ive never used kicad so i wouldnt know :P)
<rqou>
there are no other symbols right now
<reportingsjr>
or.. just take an adderall and go to town?
<rqou>
this is such a huge fucking waste of all engineers' time
<rqou>
now i understand why whitequark was encouraging giving back to the community
<pie_>
haha
<pie_>
"do this so i dont have to"
<reportingsjr>
yeah, I don't get why manufacturers don't provide decent symbols for most EDA tools
<reportingsjr>
it would take so little extra time
<pie_>
jk, but something about deduplication of work
<rqou>
this is especially tedious because every part package needs a different symbol in kicad
<reportingsjr>
only if the pin assignments are different
<reportingsjr>
but yes, it is one of the more annoying things in kicad
<rqou>
the pin assignments _are_ different
<rqou>
but then i guess the alternative of having a giant symbol where half the pins can't be used is worse
noobineer has joined ##openfpga
<rqou>
also, for some reason altera doesn't actually provide a table that maps tile locations to pins
<rqou>
you have to manually click in quartus
<pie_>
¯\_(ツ)_/¯
<pie_>
what would you do with your life if all tedium was removed
<rqou>
watch more animu? :P
<azonenberg>
rqou: so i'm taking the day off from construction
<azonenberg>
Trying to decide what to do now that i've loaded the car up with stuff that's getting moved tomorrow
<azonenberg>
I'm wondering about maybe trying to refactor libscopehal into a separate cmake-friendly repo
<azonenberg>
and scopeclient etc
<rqou>
meh, don't care about cmake
<azonenberg>
well more importantly "useable without splash"
<azonenberg>
Since i dont have time to fix splash right now and i want it useable by third parties
<rqou>
either way, i still disagree with the direction you're going with your scope client
<rqou>
also, the way altera models "special pins" makes no sense whatsoever
ZombieChicken has joined ##openfpga
user10032 has quit [Quit: Leaving]
<rqou>
azonenberg: what's best practice for the various ground pins across different IO banks?
<rqou>
just one solid plane?
<rqou>
also, where would you place it on the symbol?
<rqou>
in the "io bank" unit or in the "global stuff" unit?
<azonenberg>
It depends on how big the chip is
<azonenberg>
For really small ones, one symbol for everything
<azonenberg>
for midsized, one for all power/ground from all banks
<rqou>
this is a 256-ball BGA
<azonenberg>
then one per bank for the ios only
<azonenberg>
This is what i'd do for say a ft256,
<azonenberg>
Since i normalyl dont care about io power in the logic side of things
<azonenberg>
i want all of the power pins and decoupling under the power subsystem
<azonenberg>
For really big parts, somewhere around 484-676 balls, i start thinking about moving to one symbol for power and one for ground
<rqou>
hmm, but awygle puts VCCIO along with the pins in the io bank
<azonenberg>
in either case global stuff and each io bank are their own symbols
<azonenberg>
Yeah, i thought about that
<azonenberg>
but i found it less readable personally
<rqou>
and layout-wise? one solid plane?
<rqou>
azonenberg: also, would you make GNDIO and GNDINT (core) separate pins on the symbol?
<azonenberg>
i'd label them separately but group them together
<azonenberg>
in the expectation that the user will tie them all together
<azonenberg>
same with vccbram/vccint on 7 series
<azonenberg>
which are both 1v0
<rqou>
wat, that's a separate pin?
<rqou>
why?
genii has joined ##openfpga
<awygle>
I like vccio in the bank because you can see at a glance what level the bank uses
<rqou>
yeah, makes sense
<rqou>
wait a sec
<rqou>
azonenberg: if vccbram is a separate pin, doesn't that allow for easy selective glitching?
<rqou>
(if that actually ends up helping you of course)
<azonenberg>
rqou: potentially? i havent tried
<azonenberg>
awygle: i just put a comment below the bank to sayt
<azonenberg>
say*
<azonenberg>
i like to keep all the vcc pins by the decoupling caps
<awygle>
Comments get out of date though
<awygle>
I agree with putting the decoupling with the pin though.
<rqou>
you mean not just all on a "decoupling caps" page?
<azonenberg>
rqou: i have one page for the fpga's power banks and decoupling
<azonenberg>
i.e. the ground symbol, the power symbol, and all the caps
<awygle>
I have a page that's "decoupling caps and non bank vcc/gnd"
<awygle>
But I do vccio decoupling local to the bank
<azonenberg>
yeah only diff is i put my bank vcc/gnd there too
<awygle>
Same for smaller parts, decoupling actually attached and not just netlist attached
<azonenberg>
i netlist-attach mine but put it nearby and comment "decoupling for U3" or something
<azonenberg>
To guide me at placement time
<awygle>
I reiterate my concerns about nonfunctional comments lol
<awygle>
If it's easy to make it functionally self documenting I prefer to do that
<awygle>
Oh no, the internet ad machine has figured out I'm writing C# now. Time to get thousands of ads for C# training and Azure VMs and stuff.
<azonenberg>
lol
<rqou>
why do people keep advertising these types of training anyways? it's not like it's _that_ hard to just read the docs and figure it out
<azonenberg>
there's a lot of really dumb devs who need the help, and really dumb managers who think competent devs need it
Miyu has joined ##openfpga
<rqou>
are these the dumb devs that keep making the buffer overflows and SQLi that we spent tons of effort fixing? :P
<awygle>
idk maybe it's useful for some people
<awygle>
makes more sense to me than the fact that Google ads actually make money
<rqou>
why are the unit value and refdes in the same spot for every unit
<rqou>
thanks kicad
qu1j0t3 has quit [Quit: WeeChat 0.4.3]
<rqou>
now they're comically out of place on the "misc" unit
qu1j0t3 has joined ##openfpga
<azonenberg>
rqou: hey, they keep me employed...
<awygle>
rqou: it'll automatically not suck in the schematic
<awygle>
It just looks like shit in the symbol
<rqou>
brilliant /s
<awygle>
Yeah it's annoying. I played with fixing it but it's nontrivial
<awygle>
Honestly neither should be shown in the symbol at all imi
<rqou>
but sometimes i want to turn the value off
<awygle>
You can do that without displaying it
<rqou>
i guess
<rqou>
in general kicad just seems to love having awful data models
<awygle>
The footprint data model is OK. The symbol one hasn't been revamped in 20 years.
<awygle>
(or whatever)
<awygle>
And I don't think anyone loves it lol
<rqou>
kicad -- the best piece of crap we've got
<awygle>
TM
<awygle>
I hope one of the proposed alternatives turns out to not suck
<awygle>
there's also horizon which I didn't like when I looked at it before but it may have been too early or I may be biased
<rqou>
not sure if this will be better or hoping for cern to make improvements will be better
<awygle>
Me either
<azonenberg>
i think kicad is gonna be a great tool
<azonenberg>
it just needs another couple years
<rqou>
i don't get why they can't do basic things like "upgrade c++ versions" or "remove boost" or "remove wx"
<awygle>
Librepcb looks good to me but it doesn't seem to be minimum-viable functional yet, and they seem bogged down in unimportant stuff dev wise
<rqou>
although they did make a lot of progress on removing boost
<awygle>
I'd target wx before boost
<rqou>
well, they removed the easy parts
<rqou>
e.g. the parts that turned into c++11
<awygle>
Boost is bloated and a dependency pita but it at least works
<rqou>
or remove LOCALE_IO :P
<rqou>
which is made extra hard thanks to wx
<awygle>
But "text is a universal interface", rqou
<rqou>
meaning?
<awygle>
I was joking. The whole reason LOCALE_IO is a thing is because fprintf is not a serialization format
<awygle>
Contrary to the Unix Philosophy
<rqou>
traditionally it was usable as such though
<rqou>
until a combination of glibc/wx went and fucked it up
<awygle>
Back when only English existed, yes
<rqou>
um, no?
<awygle>
And American English specifically
<rqou>
why?
<awygle>
Commas in numbers as just one example
<rqou>
you can do that manually for display
<rqou>
not have it be in automagic global state
<awygle>
Right, but they didn't, they used fprintf
<azonenberg>
Does fprintf inser commas?
<azonenberg>
i've never seen that
<rqou>
and then the "fix" that people came up with was to make locale a global state
<rqou>
azonenberg: it inserts commas in floats if you're on glibc and your locale is french
<azonenberg>
o_O
<azonenberg>
The only locale difference i am aware of is , vs . as decimal separator
<rqou>
yeah
<azonenberg>
for printf'ing numbers
<rqou>
that
<azonenberg>
and that seems easy to fix by making a parser that treats either as a .
<rqou>
but scanf doesn't do that because glibc is teh dumb
<azonenberg>
Or by not using floats :p
<rqou>
imho processes should just never set the libc locale
<azonenberg>
Isnt that what they tried to fix by moving all coordinates to decimal nanometers?
<rqou>
everywhere where you would _like_ locale functionality you should have to explicitly ask for it
<azonenberg>
now everything is an int
<azonenberg>
(yes, i agree with that bit)
<azonenberg>
"print string exactly as i gave it"
<azonenberg>
vs "print string formatted for current language"
<rqou>
btw, for bonus hilarity, hidraw used to set the process global locale too
<rqou>
(i deleted that part in our fork)
<rqou>
no, i have no idea why
<rqou>
seriously, what is with libraries messing with global state THAT ISN'T THEIRS?!
<rqou>
this problem is apparently much much worse on windows
<Ultrasauce>
errno
<azonenberg>
well i know that there are some libraries
<azonenberg>
that expect you to provide callbacks for allocating/freeing memory
<rqou>
errno is now mandated to be thread-local
<azonenberg>
because apparently there isnt one standard heap or something
<rqou>
azonenberg: yes, i do that
<azonenberg>
Better question, how did we get to this mess? and why is there so much global state in general?
<azonenberg>
i almost never use global variables for anything
<rqou>
ugh, i hate how multiple sheets works in kicad
<azonenberg>
you mean hierarchial design? i like it
<azonenberg>
it fits HDL-style architecture well
<rqou>
no, i mean the specific way you interact with this feature
<rqou>
e.g. having to export the sheet settings
<rqou>
or the way you can (sometimes) get the kicad project file out of sync
<rqou>
azonenberg: do you have the bom for your coolrunner board?
<rqou>
specifically which inductors/ferrite beads did you use?
<azonenberg>
no i dont
<azonenberg>
i think i specified generic like "600R @ 100 MHz" or similar
<azonenberg>
why?
<rqou>
usually people are somewhat careful when they spec components like this
<azonenberg>
These days i usually am
<azonenberg>
But honestly if you just want to reduce emi a bit and arent selling the board it doesnt matter a ton :p
<rqou>
i mean, i usually don't put them at all
ZombieChicken has quit [Ping timeout: 250 seconds]
<rqou>
azonenberg: btw, why 2.048 MHz
<azonenberg>
I wanted a low frequency so i could divide down to a visible blinky
<azonenberg>
without using too many macrocells
<azonenberg>
that was available and cheap
<rqou>
ah, ok
<rqou>
also, the way you draw schematics really bugs me
<rqou>
all the nodes that just have a label attached to nothing
<azonenberg>
well thats the only sane way to do schematics with a lot of stuff
<azonenberg>
you cant have wires going everywhere, thats impossible to follow
<azonenberg>
(also, given that design philosophy, you can probably see why i want to use HDL to design my pcbs)
<rqou>
i usually draw a stub
<rqou>
also, you don't use power symbols
<azonenberg>
yeah i prefer to have the connector source the power
<azonenberg>
since the reality is, thats where it comes from
<rqou>
yeah?
<rqou>
i still use power symbols for that
<rqou>
also, you have labels on nodes that don't actually end up going to another labeled node
<azonenberg>
yes, because they show up in the pcb layout
<rqou>
makes it really hard to figure out what connects to work
<azonenberg>
and make it easier to tell whats what
<rqou>
*to what
<azonenberg>
i label almost every node in my schematics
<azonenberg>
except for really short stuff like led to resistor or something
<awygle>
I label single node nets but also put an x on the
<rqou>
azonenberg: why is FTDI_PWRSAV_N pulled to 5V?
<rqou>
quality datasheet: "Also see note 1, 2, 3 in section Error! Reference source not found."
<azonenberg>
lolol
<rqou>
azonenberg: is your design usb suspend compliantT?
<rqou>
i assume no?
<azonenberg>
never tried
<rqou>
why do you have a capacitor between shield and ground?
<rqou>
offtopic: is cosplay cad really _that hard_?
<rqou>
how does Fiora manage to break fusion360 constantly?
<sorear>
my impression of fiora's life was more in the direction of "cad is terrible" (a specialization of "vertical software is terrible", itself a specialization of "everything is terrible")
<rqou>
in my limited experience with mcad i have never had nearly as many problems