<rqou>
the whitequark-esque troll answer is "don't use X"
<pie__>
i wouldnt but
<pie__>
god i just want to be able to write my damn notes without gteting carpal tunnel from modal keyboard layout switching and a swapping y and z constantly :'(
<pie__>
also mental carpal tunnel
<cr1901_modern>
>so, #opencatgirls when
<cr1901_modern>
I hate to be the bearer of bad news, but: Anime Isn't Real. :)
GenTooMan has quit [Quit: Leaving]
<whitequark>
lies
rqou has quit [Remote host closed the connection]
rqou has joined ##openfpga
<pie__>
if only we were headed towards such a utopia
<rqou>
i hope the sump itself is actually installed properly
<azonenberg>
as soon as i started cutting into the pipe, that joint that was leaking popped open from the vibration
<azonenberg>
if you look at the portion of the pipe that's stained from the sump water
<azonenberg>
it's obvious that there was no glue on the inside of the fitting at all
<rqou>
i see some nice mold
<rqou>
needs moar biocides :P
<azonenberg>
It's a sewer pipe, IDGAF what's growing in it
<azonenberg>
The point is though, that should have been a solid solvent weld between the fitting and the pipe
<azonenberg>
There should not have been any liquid penetration into that gap
<azonenberg>
because there should not have been a gap :p
<rqou>
of course
<rqou>
no evidence of problems with the sump itself i hope?
<azonenberg>
No, not that i can see
<rqou>
or worse, the pipes under the concrete
<azonenberg>
the concrete wasn't quite level, which caused problems when i tried framing the wall over it
<rqou>
were you at least watching when they installed the buried drainage pipes?
<azonenberg>
I was upstairs with earplugs on clocked into $work
<azonenberg>
But i went down to check on progress periodically
<rqou>
so basically it can't be _that_ blatantly wrong
<azonenberg>
Yeah
<azonenberg>
There's gravel in the trenches, then perforated drainage pipes
<rqou>
i guess it's kinda hard to mess that up :P
<rqou>
especially considering that this part isn't even water-tight
<rqou>
and has historically been built with materials like hollow logs :P
<azonenberg>
lol yes
<azonenberg>
The outflow is actually under pressure though
<azonenberg>
There's a check valve so it's full of water all the time
<azonenberg>
and whenever the pump is running there's that dynamic pressure on top of the static head of however many feet
<azonenberg>
Anyway, i need sleep
<daveshah>
rqou: that structure sounds very plausible to me
<daveshah>
Just like the ecp5 with an extra mux2 at the end
<daveshah>
one-hot muxes sharing control signals and cascaded are a common strategy I think
<azonenberg>
yeah
<azonenberg>
greenpak goes one further with optimizing config memory space and has entire logic blocks sharing control signals with a final mux2 :p
<azonenberg>
(makes packing a nightmare, one of the reasons i havent done any work on the larger chips)
<azonenberg>
s/larger/newer/
<rqou>
or you can use more explicit CSP formulations like i suggested :P
<azonenberg>
When i have time to look at it
<azonenberg>
i'll re-examine greenpak
<rqou>
or i can just go and rewrite it if i have time before you? :P
<rqou>
i even have a really really silly proposed name for the rewrite
<rqou>
proposed name for gp4par rewrite: ShinyKinglerPAR
<azonenberg>
no :p
<azonenberg>
I'd prefer to keep greenpak as my project, in c++
<rqou>
because Kingler is a crab (Rust), is an evolution
<rqou>
and happens to be green :P :P
<rqou>
perfect name? :P
<azonenberg>
contributions are accepted, but i'm not going to go rewrite the whole thing in rust just to make you happy
<cr1901_modern>
Tbh, I wish the whole thing was in C++ for consistency
<rqou>
i was saying what if i just rewrite it :P
<azonenberg>
cr1901_modern: me too
<azonenberg>
i grudgingly accepted his rust coolrunner code because it was better than no coolrunner support at all
<rqou>
or Rust for consistency? :P
<azonenberg>
But i really wanted to have a single C++ par library for crossbar-based devices and then backends for each chip
<azonenberg>
And if/when i have time i may well rewrite cr2par in c++ :p
<cr1901_modern>
I don't care for C++ that much, but using Rust just b/c it's the hip new language when 90% of the codebase is already C++ seems less than ideal too
<azonenberg>
exactly
<rqou>
even in C++ the code probably wouldn't have used your library in the end
<azonenberg>
rqou: you just dont like OO
<daveshah>
azonenberg: you should automatically transpile rqou's Rust on push :P
<azonenberg>
and i cant help you with that
<rqou>
except the ratio isn't anywhere near 90%
<rqou>
more like 60% maybe? no exact numbers
<azonenberg>
anyway, no rewrites of existing components in rust will be accepted
<azonenberg>
Or anything but c++
<azonenberg>
New chip support in non-C++ languages is strongly discouraged but will be accepted if nobody writing in C++ has an alternative implementation to propose
<rqou>
huh, the code ratio is about 50/50 actually
<cr1901_modern>
I have to disable the Rust parts when tinkering w/ the build system b/c cargo _insists_ on rebuilding the Rust code every damn time
<rqou>
so by not excluding ZIA on my end either it's still 50/50
<rqou>
github claims 50% C++ 40% Rust 10% everything else
<azonenberg>
Still my project :)
<cr1901_modern>
It still reeks of "using Rust for the sake of using Rust"
<rqou>
or i can just rip out xc2par into a separate project
<rqou>
no, using rust because C++ is worse
<azonenberg>
cr1901_modern: thats everything rqou gets his hands on
<rqou>
also, azonenberg and i seem to have highly incompatible coding styles anyways
<rqou>
azonenberg seems to prefer a more classic "OO-ish" approach
<rqou>
including inheritance and overrides on methods
<rqou>
whereas i tend to prefer dumb objects that can't do anything
<rqou>
where all the state is packed into very explicit data structures
<cr1901_modern>
I mean all things being equal I would've been cool using Rust from the beginning, but any contributions I make will be C++ (or "C with classes" if that's acceptable) b/c that's what most ppl agreed upon.
<rqou>
but yeah, overall i would say *) i hate C++ *) i hate OO *) i especially hate classic inheritance
<whitequark>
for once i agree with rqou
<cr1901_modern>
azonenberg: >you just dont like OO
<cr1901_modern>
Btw, Idk if you've read it and/or subscribe to its mantra, but Design Patterns is an irritating book if you don't enjoy UML diagrams :).
<rqou>
so i have never ever learned about or used UML diagrams
<rqou>
i don't get why people obsess over them so much
<daveshah>
honestly the only time ever did them was for A-level computing (UK equivalent of high school)
<rqou>
and no, i've never actually read Design Patterns
<daveshah>
and I'm an OO guy
<rqou>
wait correction, i think i've seen them in a "real thing"
<rqou>
the VHPI spec (which nobody implements btw) is described partially with UML
rohitksingh has quit [Quit: Leaving.]
<whitequark>
also the USB video class spec
<whitequark>
(it's horrifying)
<rqou>
what
<rqou>
wtf
<whitequark>
seriously
<rqou>
why?
<whitequark>
dunno
<whitequark>
because USB is shit
<rqou>
doesn't it "just transfer framebuffers"?
<whitequark>
LOL
<cr1901_modern>
USB doesn't "just" do anything :D
<whitequark>
remember that awful chip with a digital audio crossbar?
<rqou>
brilliant spec /s
<whitequark>
well, UVC is designed to support stuff like that
<rqou>
which one? don't all hda audio chips have that/
<rqou>
?
<whitequark>
most of the spec is actually autogenerated from XMLs
<rqou>
wait, so if UVC is a pile of crap, and v4l2 is also a pile of crap...
<rqou>
is this why the joke is that webcams on linux never work? :P
<whitequark>
that describe dozens upon dozens of descriptors that describe hardware in anincredibly abstract and generic way
<daveshah>
rqou: weirdly, I've never had a webcam not work on Linux
<rqou>
i have
<daveshah>
it's always been capture card type devices that have been the nightmare
<rqou>
the weird BRCM/APPL/ambarella PCIe one :P
<daveshah>
god knows, this was maybe 8 years ago
<daveshah>
PCIe
<rqou>
yeah, i don't get why capture cards all have to suck so hard
<daveshah>
but I've had USB ones that were crap too
<rqou>
hilariously, i'm also aware of a USB <REDACTED> that at its core was basically two cameras
<rqou>
it ran a "proprietary" protocol
<rqou>
but the firmware was developed by taking a cypress fx3 uvc video example and duplicating ~everything twice
<rqou>
including a multi-kloc file from omnivision(?) full of "set reg XX to YY"
<whitequark>
amazing
<daveshah>
fuck omnivision
<rqou>
and apparently when they were going through some kind of driver certification process, MSFT asked them "how come it doesn't support X, Y, and Z"
<daveshah>
I've wasted so much life on omnivision shit
<florolf>
the part of the usb spec where they started annotating their state machine transitions using vhdl syntax failed my suspension of disbelief
<rqou>
because it was being certified as a camera-like device
<rqou>
even though the final application was not a camera
<rqou>
apparently they eventually convinced MSFT to give them a pass
<rqou>
yeah, i don't get how a giant trashfire like USB managed to take off
<whitequark>
because it's more convenient than setting jumpers on PCI cards
<rqou>
at least their notions of backwards compatibility work enough that i can plug modern flash drives into my g3 mac
<rqou>
um, PCI cards don't need jumpers?
<whitequark>
ISA cards. whatever.
<whitequark>
you get the idea
<rqou>
although i do remember the experience of parallel port daisy-chains and switch boxes
<rqou>
e.g. an iomega zip drive couldn't work with the printer/scanner that i had a decade+ ago
<rqou>
and you had to reboot to decide if you wanted to use the printer or zip drive this session
<rqou>
oh yeah, i also just remembered something else hilarious
<rqou>
my father had a coworker way back in the day that did "EDA stuff"
<rqou>
he had a parallel port extension cable with a parallel port dongle "sword" attached to it :P
<rqou>
actually multiple, because certain dongles didn't passthrough correctly with certain other dongles
<rqou>
but yeah, there'd be like five dongles or something all chained together
<rqou>
DRM is great /s
<florolf>
rqou: probably the same reason the pc/x86-trashfire did: being good enough, remaining backwards-compatible (which also increases the size of the trashfire over time) and leveraging market dominance
<rqou>
yeah i suppose
<rqou>
see for example whitequark's discovery of the "virtual legacy wire" interface :P :P
<florolf>
rqou: i've been busy moving the past few weeks and didn't follow the channel too closely. grep doesn't help either
<rqou>
oh this might be from birbsite
<florolf>
didn't follow birdsite too closely either
<rqou>
whitequark was reading intel manuals and happened to remember a claim that intel dropped A20 around the original core i7 timeframe
<rqou>
turns out this isn't strictly true
<rqou>
the physical A20 pin was removed
<rqou>
but the functionality became tunneled over DMI(?) and renamed virtual legacy wire
<rqou>
so tldr A20 still exists
<rqou>
3+ decades later
<zkms>
x86 is so depressing
<rqou>
yeah
<rqou>
oh btw, fun thing i happened to discover the other day
<rqou>
valgrind doesn't support x87 float80
<rqou>
i'm sure your numerics code will be very happy with that
<egg|z|egg>
meow?
<rqou>
ohai
* egg|z|egg
purrs
* rqou
pets egg|z|egg
<rqou>
but yeah, afaik valgrind will just compute 80-bit operations only up to 64-bit precision (but can still store to an 80-bit float so the program mostly works right)
<rqou>
so if your stuff ever rounds wrong under valgrind, this might be why
<rqou>
which is great for causing heisenbugs
<florolf>
rqou: yeah, that seems like an intel thing to do
<rqou>
yeah, all modern x86 manuals are totally insane
<rqou>
so many random features, secret features, leaks, etc.
<rqou>
see for example: the tiny x86 hidden inside ME
<rqou>
previously an ARC
<rqou>
apparently a SPARC at one point?!
<rqou>
or maybe the existence of ME itself?
<rqou>
the bits that iirc @alt_kia was pointing out where if you set them it triggers an interrupt into SMM where the bios then has to set it back
<florolf>
well, that actually makes sense (intel reusing x86 instead of licensing stuff)
<rqou>
"Once a power management agent notifies the VLW broadcaster that an agent has newly awakened. The VLW interrupt is then re-broadcast, with a mask that excludes all but the newly-awakened agent."
<rqou>
everything in x86 feels like a giant hack
<florolf>
that's what i thought. then, they launch into 30 pages of implementation details, which probably supplies enough complexity to make it patentable
Hamilton has joined ##openfpga
Hamilton has quit [Client Quit]
Hamilton has joined ##openfpga
_whitelogger has joined ##openfpga
<zkms>
i love how every year or so someone discovers a new way to trick some hapless peripheral into breaking SMM memory isolation because none of this shit is actually amenable to reasoning about who can write what (and yet breaking SMM isolation lets you do horrid things!)
Hamilton2 has joined ##openfpga
Hamilton has quit [Ping timeout: 265 seconds]
clifford has quit [Read error: Connection reset by peer]
<marcan>
18:05:26 < rqou> hilariously, i'm also aware of a USB <REDACTED> that at its core was basically two cameras
<marcan>
Leap?
<marcan>
FX3 IIRC, two cameras, "proprietary" protocol, adds up :P
<marcan>
and yeah, UAC is a trashfire of a spec, and I haven't looked at UVC but IIRC it's the same nonsense
<marcan>
I wrote audio class descriptors for a DIY interface/DSP thing
<marcan>
it's a hilariously backwards game of "guess what generic description you need to come up with to accurately describe the hardware but also will be reverse-engineered into a sane set of mixer controls by Linux"
<felix_>
rqou: on the me architecture: arc was pre-skylake, x86 skylake and newer; spark was used as txe used in some atoms iirc
<balrog>
grr, it sure looks like CMake has won the build systems wars
user10032 has quit [Quit: Leaving]
<rqou>
i still use just make
<rqou>
or the "fuck it" build.sh build system
<balrog>
CMake also uses make
<rqou>
which is why it's super pointless
<rqou>
"oh yeah, let's wrap make with an even more crappy DSL with all kinds of weird bugs and stupid behaviors"
<q3k>
cmake is not stupid
<q3k>
it can target more than just make, which is useful for cross-platform projects
<q3k>
s,stupid,pointless,
<q3k>
i mean, i'm not a fan of the dsl they have either
<balrog>
q3k: their DSL is less annoying than autotools
<q3k>
lowest bar in the world (tm)
<balrog>
and they decided to play nice with the distro community (unlike waf), and are scalable (unlike scons or premake)
<q3k>
i'm still somewhat more partial to either bazel-style BUILD files or Nix
<rqou>
meh, I've given up caring about "the distro community"
<rqou>
although being an ex-waf user i agree that it's not actually very good
mumptai has quit [Quit: Verlassend]
* awygle
crawls out of a hole, starts reading a week of backlog
<rqou>
lol awygle
<rqou>
what have you been doing?
<awygle>
i have been sick
<q3k>
i think i've been in a hole for a month now
<q3k>
risc-v workshop, ripe76, vacation in mrs, warcon
<q3k>
my backlog is hell
<awygle>
i still am sick, really, but yknow how that works. at a certain point you have to get off the couch.
<awygle>
rqou: i took the oldschool version of 61a
<awygle>
azonenberg / azonenberg_work: interesting results. glad to hear crosstalk is not a problem, sorry to hear MAC table may be.
<rqou>
with Brian Harvey?
<awygle>
yup
<awygle>
azonenberg_work: interesting how that queue math affects the potential of a cyclone-based switch. the lowest level has more memory but it doesn't go up nearly as fast. the MLAB blocks seem like they might be good for the MAC table though.
<awygle>
the smallest cyclone has 291 blocks of 20k each, plus the MLAB blocks. vs the k70t has 135 blocks of 36k.
<awygle>
i wonder what the math for HyperRAM or DDR3 might look like. but i'm not currently interested in doing it, so i'll either nerd-snipe you or push it on my stack :p
<rqou>
wait you actually are an altera user?
<awygle>
rqou: i'm primarily a lattice user tbh. but i think the cyclone 10 gx has some interesting properties for switches and NICs
<rqou>
i assume you've seen Project Chibi?
<awygle>
yes, very cool (dumb name :p)
<rqou>
why dumb? :P
<awygle>
if you look at the spreadsheet azonenberg and i did a while back you can see that per transceiver Altera is cheaper than Xilinx, currently, at QTY 1
<rqou>
well project chibi doesn't have transceivers
<awygle>
idk, your project isn't particularly chibi. it is neither particularly smol nor particularly cute.
<mietek>
it’s a Zynq UltraScale+ … that seems like a really good deal, no?
<daveshah>
Yes, I think the smaller ultrascale+s work fine with free Vivado
<mietek>
the other Zynq boards I see are Zynq 7020
<mietek>
or 7010
<daveshah>
Yeah, it's pretty good deal compared to the old Zynqs
<daveshah>
Tempted myself
<mietek>
cool
<balrog>
yeah, that Zynq is like $550 in qty 1
<balrog>
so they're selling the dev board for less to push the product
<daveshah>
Most vendor/distributor fpga boards do
<daveshah>
But qty1 pricing for fpgas doesn't mean much
bitd has quit [Quit: Leaving]
<rqou>
qty1 price for 5M"40" is great
<etrig>
anything similar out there with similar pricepoint but more exposed I/O like ultrazed-eg?
<mietek>
etrig: why does that one have more exposed I/O? it’s connectors in both cases, no?
<mietek>
oh, you mean just more pins?
<etrig>
pretty much
<mietek>
right
steakpizza has joined ##openfpga
<etrig>
that one is nice since you can route an entire fmc-lpc connector worth
<etrig>
but yeah, zu3eg works with webpack
steakpizza has quit [Remote host closed the connection]
steakpizza has joined ##openfpga
stefanct has quit [Ping timeout: 240 seconds]
<awygle>
whitequark: opened a case with onsemi about the fxma
stefanct has joined ##openfpga
stefanct has joined ##openfpga
stefanct has quit [Changing host]
<reportingsjr>
anyone know what is with the weird feedback on aliexpress where it is interleaved english and russian??
<whitequark>
awygle: thanks!
<reportingsjr>
awygle: ohhh, that chip is an onsemi part?
<reportingsjr>
I can't stand using their parts
<awygle>
whitequark: gonna triage kicad symbols/footprints, try to see if i can come up with a better location for the usb protection ic, then start on rev c tickets. sound good?
<awygle>
reportingsjr: yup
<awygle>
their parts are usually fine but not exceptional. i've never tried to use anything complicated from them before though.
<reportingsjr>
they are pretty much a high volume chip manufacturer
<awygle>
they actually have their own fab, which is increasingly rare
<reportingsjr>
cheap stuff, awful documentation, but if you are going to buy 100k+ chips a year they will just design the circuit for you.
<awygle>
irrelevant to me as a consumer, but still cool
<awygle>
they're my usual goto for standard discretes especially. like i did a BJT charge pump board that was basically all onsemi.
<awygle>
mithro: that's cool. so given the work you've done, will adding support for other architectures be any easier? or will it be a multi-month wrestling match next time too?
<mithro>
awygle: should be a *lot* easier
<mithro>
awygle: Will still need a bunch of cleanup -- but most of it should be very reusable
<mithro>
awygle: will need some sanity checking soon