<whitequark> DP83867CR lets me configure an arbitrary 64-byte WOL pattern
<whitequark> and it's 2.65@1k
<whitequark> and it's a ti part so it's probably good
<whitequark> awygle: rqou: ^
<sorear> i'm surprised factory serial numbers for random chips isn't more of a thing
<TD-Linux> btw how good is fx2/fx3 open source tooling. I've never used them myself
<whitequark> sorear: i still need to sign them though
<whitequark> TD-Linux: i wrote the good fx2 oss tooling
<whitequark> i didnt write the good fx3 oss tooling yet
<sorear> whitequark: extremely troll idea: add a PUF mode to prjxray that does analog characterization of an attached fpga using illegal bitstreams
<whitequark> sorear: lol
<whitequark> awygle: attiny9 can be only programmed at 5V
<TD-Linux> sorear, ah what I've always wanted, the ability to parallel LUTs for high current operation
<whitequark> another reason to have 5V
<whitequark> anyway we can use attiny9 (50c@1) as a ghetto secure element
<whitequark> dangle it off i2c
<whitequark> i'll probably add a fp to revC, we don't have to ever populate it
<TD-Linux> another idea for the serial number problem is just to have a db online and count # of lookups, like some mfrs do with the scratch off thing
<whitequark> TD-Linux: i thought about this but i feel like people who are attracted to foss designs would be kinda hostile to telemetry
<whitequark> which is not entirely unreasonable
<TD-Linux> yeah true.
<whitequark> i might still include telemetry to gather applet stats
<whitequark> but opt-in of course
<sorear> i guess popcon is grandfathered
<whitequark> popcon is opt-in
<TD-Linux> then again some of these people also run ida pro
<whitequark> then again i might run afoul of gdpr then
<sorear> even opt-in telemetry makes a certain segment of foss people very mad
<whitequark> having a secure element solves all this and people who are self-assembling can just ignore it
<TD-Linux> but yeah I can appreciate no telemetry
<TD-Linux> t. works at mozilla
<sorear> see: git, last month
<whitequark> sorear: if opt-in telemetry makes people mad they can go pound sand tbh.
<rqou> god SOAP is a pile of shit
<whitequark> i have no sympathy to disliking telemetry that can be done with one keypress on first startup or in a config
<whitequark> rqou: hahaha
<sorear> hmm, that's a new idiom to me
<whitequark> i had to work with this. for a bank obvs
<rqou> sane API: i can make a basic query in like 5 minutes with curl
<whitequark> sorear: it's like a less rude way to say they can go fuck themselves
<whitequark> rqou: ruby-wsdl is handy
<rqou> SOAP: wtf is going on why is there XML everywhere
<whitequark> like y ou can actually autogenerate an API from BSDL
<whitequark> I mean WSDL
<whitequark> BSDL being in XML would actually be an improvement
<sorear> i've used SOAP, and I've used ASN.1, and I've also done an integration involving flat files where the only format documentation was COBOL sample code, and the last was preferable tbh
<whitequark> lol
<TD-Linux> firefox telemetry has actually found a number of cpu bugs
Bike has joined ##openfpga
<rqou> my problem is that i don't know anything about SOAP at all
<rqou> i just want to submit the "pwn the enterprise" request and gtfo
<TD-Linux> security-by-using-protocols-hackers-hate
<zkms> this reminds me of something that iw as reading that mentioned that they were using an air interface inspired by WiMax and explicitly listed the fact that nobody uses this anymore as a reason for security
<TD-Linux> why is glasgow 80x49mm
<sorear> zkms: is that a faa thing
<TD-Linux> >golden rectangle
<TD-Linux> I'll take standard though.
<whitequark> i think i might abandon that for revC, not sure yet
<whitequark> i need more space for connectors
<whitequark> and i think 2.54, while unwieldy, is far too common and convenient to abandon
<whitequark> though... might still be possible to fit them with some effort...
<zkms> sorear: no it's from one of those weird high-bandwidth air-to-ground links that industry is trying to shill to FAA/EUROCONTROL, this one is called AeroMACS
<zkms> there's also L-DACS1 (another shitty OFDM system) and L-DACS2 (bad clone of GSM, down to the data rates)
<TD-Linux> cause that's what we need when airplanes can't even set ILS frequencies correctly
<zkms> like honestly i'm not even sure what advantage these have over running LTE on the right center freqs / bandwidths
<TD-Linux> ordering 5 glasgow's to the US, lmk if you want one
<TD-Linux> maybe rqou
<whitequark> TD-Linux: if you tweet this i'll rt
<whitequark> awygle: wtf, ethernet phy wants exactly 25 mhz clock and fx3 wants exactly 19.2 mhz crystal
<whitequark> i... i guess i could use the pll in ecp5
<zkms> "oh but L-DACS provides ranging capability to a/c so they can know where they are even if GPS dies" well hmm cell operators have a long history of doing the exact same for e911 purposes
<TD-Linux> oh did you switch to ecp5 for the new glasgow?
<whitequark> TD-Linux: the eventual successor of glasgow with usb3, gige and much faster fpga will use ecp5 most likely
<whitequark> it's very cheap and it's going to have a fos54s~[p''tr54
<zkms> whitequark: will that be revC?
<whitequark> foss toolchain soon
<whitequark> zkms: no, revC is revB with IO cells that can tolerate pullups
<sorear> this is long post-revC
<zkms> ok
<whitequark> "revD" (unless folded into revC) will have 32 IO cells
<whitequark> revE will be the ECP5 one
<zkms> i think i will wait for revC
<whitequark> that makes sense
<whitequark> pullups are the bane of revA/B
<zkms> anyway idk where in development those air-to-ground schemes are but i'm still kinda embarrassed at how badly they're reimplementing LTE (or GSM, in the case of LDACS2) ;;
<sorear> is LTE like actually good
<sorear> i don't have high expectations of a lot of industry standards
<whitequark> awygle: ooooh, on FX3 we have 16 IN+OUT EP pairs
<zkms> sorear: what definition of "good" are you using
<whitequark> so i think with FX3 we can actually just not do applet multiplexing?
<sorear> does what it’s expected to, complexity is well justified, etc, idk
<whitequark> LTE is telecom shit
<whitequark> what do you expect
<sorear> not much, but zkms is implying there are worse things
Adluc has quit [Ping timeout: 252 seconds]
azonenberg_work has quit [Ping timeout: 252 seconds]
<rqou> whee, yet another py2-only library
<rqou> py3 will be mainstream any day now /s
<awygle> oh lord tons of notifications the one night I have plans lol
* awygle will read backlog tomorrow
Adluc has joined ##openfpga
<zkms> sorear: amongst the air interface standards i've looked into and that are meant for civilian use (aka that aren't tactical data links), yeah, LTE's pretty damn good (besides profuse use of acronyms and ASN.1 descriptions of messages)
<sorear> beats XML
<sorear> X.12/EDIFACT was better tho
<zkms> there's mildly complex stuff like Zadoff-Chu sequences but you sorta do need some kind of PN sequence for unscheduled accesses
<awygle> LTE is relatively sane imo
<awygle> whitequark: iirc that's the ti phy azonenberg is using on latentred
<whitequark> awygle: incredible
<whitequark> i'm reinventing azonenberg's shit AGAIN
<awygle> whitequark: the ecp5 PLLs are good, is that an integer ratio tho from 19.2 to 25?
<whitequark> well it's rational
<whitequark> you can divide by 192 and multiply by 250
<whitequark> divide by 96 and multiply by 125?
<whitequark> seems achievable
<awygle> oh yeah i suppose so. That's probably within range? We can do the math easy enough
<whitequark> that'd be 2400 MHz fpll
<whitequark> virtually certainly within range
<whitequark> fvco
unixb0y has quit [Ping timeout: 244 seconds]
<awygle> also eMMC has pull ups
<awygle> it needs them at the beginning, during unit.
<awygle> *init
<whitequark> awygle: what do you think about connecting the rgmii bus to the fx3 and fpga in parallel?
<whitequark> with only one driver enabled obvs
unixb0y has joined ##openfpga
<whitequark> then we can reconfigure the thing with only the ethernet phy and no fpga at all
<whitequark> gpifii should be able to do rgmii
<zkms> (LTE has the HARQ loop that makes the ethernet fronthaul people cry but again that's something that gets you good bandwidth with small latencies)
<awygle> whitequark: I mean if it'll work, sure
<awygle> I think the RGMII weirdness is about round trip time? It's pretty slow and we can always do fly by routing
<whitequark> awygle: the downside is then i think we need to use the 16-bit bus
<awygle> how fast? probably fine.
<awygle> DDR on ECP5 is whatever, nbd
<awygle> mmm gummy bears
<whitequark> awygle: oh YEAH we can put tons of RAM on revE
<awygle> uhhh well *some* RAM lol
<whitequark> just put a sodimm slot on the back?
<whitequark> actually that is legit a good idea
<awygle> ECP5 almost certainly doesn't have the pins for a SO-DIMM
<whitequark> oh
<whitequark> actually what ECP5 do we even use
<whitequark> probably not the 5G ones?
<awygle> can you run like, half? or a quarter?
<sorear> solution: more ecp5
<awygle> whitequark: are you aware that I'm working on an ecp5 compute module with onboard RAM? and are you interested in trying to use it for rev e?
<sorear> I’d be surprised if you couldn’t run a quarter?
<whitequark> awygle: hmmmm no not aware
<whitequark> will it have onboard PMICs?
<awygle> it is, perhaps ironically, a SO-DIMM
<awygle> yes but not for VIO, as currently imagined
<whitequark> hm
<whitequark> what happens if you plug a regular piece of RAM into the slot that this thing uses?
<awygle> it uses the 381-ball footprint
<awygle> uh probably nothing good.
<awygle> but it's a ddr4 sodimm so it's keyed differently than DDR3 would be
<awygle> and ecp5 can't do ddr4
<whitequark> awygle: i would strongly prefer if nothing would die
<whitequark> if you plugged ddr4 there
<awygle> It doesn't actually exist yet so I can endeavor to ensure that
<awygle> But I think it's fundamentally impossible due to voltages
<whitequark> oh?
<whitequark> oh.
<whitequark> are there any NC pins on DDR4?
<awygle> Unless there are unused pins on ddr4 sodimm that could be used. I can check
<awygle> lol
<whitequark> actually how about
<whitequark> e.g. if DDR4 has some shorted GND pins
<whitequark> use one of them for GND and another for VCC
<awygle> it definitely has that. that's not a bad idea
<awygle> Just no input power
<whitequark> and require OCP with latchup on the baseboard
<awygle> err no that's backward. you'll short the input. but yeah you can protect that
<whitequark> yes that's the idea
<whitequark> you want OCP anyway
<whitequark> ok, hm
<sorear> So is “revE with SODIMM, but only uses half of whatever is plugged in” a thing?
<whitequark> awygle: does the module need like 4/4 or 5/5 fab?
<awygle> whitequark: not totally sure yet, probably tho. may also be 6L
<awygle> still in progress
<awygle> There are some ddr4 pins that are something/NC or something/nf
<awygle> I can't really dig into this, I have to dive into my milquetoast heritage and watch a live episode of a podcast now
<whitequark> NC might be used later
<whitequark> but GND shorts won't be removed
<awygle> Very true
<whitequark> like there was some apple card that used unused pci pins
<whitequark> it supplied 12V power there for GPU
<whitequark> apple motherboard
<whitequark> maybe AGP?
<whitequark> if you plugged a slightly newer COTS non-Apple GPU there it literally exploded
<whitequark> violently
<gruetzkopf> some apple stuff also simply added more pins
<gruetzkopf> for monitor power
<gruetzkopf> ofc different positions in different gens of computer, even if exactly same function
<zkms> whitequark: what are you doing with DDR ram and ram sockets?
<whitequark> zkms: not me awyge
<whitequark> *awygle
<sorear> 9:37 PM <whitequark> awygle: oh YEAH we can put tons of RAM on revE
<whitequark> oh
<whitequark> ohhh
<whitequark> zkms: nextgen glasgow
<whitequark> awygle: if it means revE can go 6/6 4L
<whitequark> then compute module is 100% a good idea and i'll use it
<whitequark> if we need 6L 5/5 or 4/4 on revE anyway
<whitequark> say, because of SS USB connector
<whitequark> then it's more POF, expensive connector, larger board
<whitequark> we need the same voltages (3V3 and 1V8) for FPGA, FX3 and PHY anyway
<whitequark> better signal integrity too i guess
<whitequark> and we don't need to populate RAM for a potential cheaper SKU
<whitequark> say a "revE Basic"
<whitequark> "revE Professional"
<whitequark> and "revE Enterprise" lol
<TD-Linux> with ECC ram
<whitequark> lol
<whitequark> why not
<whitequark> actually we should always put ECC RAM there but set a efuse in non-Enterprise builds
<whitequark> that ignores ECC errors
<whitequark> then sell the entire thing to Intel
<genii> jeans: No pain pills for the last almost 2 weeks, ouchie but bearable
<genii> ..sorry wrong channel
f003brv has joined ##openfpga
<f003brv> Oh hi
<sorear> o/
rohitksingh_work has joined ##openfpga
f003brv has quit [Ping timeout: 256 seconds]
azonenberg_work has joined ##openfpga
<azonenberg_work> whitequark, awygle: periodic reminder that i have an FX3 DVK available for loan for usb3 glasgow
<azonenberg_work> As long as it stays physically nearby and comes back to me when its not needed
<whitequark> azonenberg_work: define nearby
<whitequark> i won't be physically on your continent in near future for [redacted] reasons
<azonenberg_work> whitequark: as in, i'd give it to awygle but not you
<azonenberg_work> Just so i can get it back in a timely fashion in the off chance i need it for something
<whitequark> azonenberg_work: hm
<whitequark> can you just expose it to me via web?
<azonenberg_work> Once i have a functioning lab
<azonenberg_work> yes, i can set up some kind of VPN for you to access it
<whitequark> i dont need to physically access it for most of glasgow usb3 work
<whitequark> if not all
<azonenberg_work> Right now everything is in boxes and i have no internet other than LTE
<whitequark> i might want you to connect an rgmii to it at some point
<azonenberg_work> If you design the board and arrange for parts and PCBs to appear at my front door
<azonenberg_work> I'll assemble and connect
<rqou> have you tried finishing your lab faster? :P
<azonenberg_work> the GPIO connector on it is a... QTH-060 i think?
<whitequark> azonenberg_work: oh
<azonenberg_work> rqou: We actually are running close to double our previous pace with ally's dad here, lol
<whitequark> yeah that also works i guess
<rqou> azonenberg_work why won't you just hire some illegal immigrants to help you? :P
<whitequark> i still can't quite figure out if i want the ethmac to always run on the fpga or i want to terminate rgmii at fx2
<whitequark> fx3 i mean
<whitequark> azonenberg_work: what do you think?
<whitequark> i'm imagining that i can use the ti phy wol feature to make an "attention" packet
<azonenberg_work> whitequark: honestly i'd have the fpga be the brain of the system
<azonenberg_work> and, if i had the fx3 on there for usb3 support
<whitequark> oh but you see, ecp5 doesn't have partial reconfig
<azonenberg_work> treat it as a usb3 peripheral attached to the fpga
<whitequark> so i'm thinking about doing basically this:
<azonenberg_work> And i'd also just get an FPGA big enough to do everything i wanted at once
<whitequark> fx3 presents itself as usb-ethernet, fpga multiplexes between fx3 bus and rgmii depending on either runtime setting or selected during bitstream gen
<azonenberg_work> This is one of the reasons starshipraider is using a 7a100t
<whitequark> probably latter but not sure
<azonenberg_work> oh interesting
<whitequark> but! if it is connected only via ethernet, and not via usb
<azonenberg_work> so it would always be ethernet
<whitequark> yes
<azonenberg_work> just over baseT or usb as transport layer
<whitequark> it would be a "5 gbps ethernet" when plugged via usb
<whitequark> and i'd probably add an sfp cage so you can get 5 gbps without usb too
<whitequark> anyway, if it's plugged via usb i can bring everything up from the "factory blank" state via usb, fx3 has a bootloader
<whitequark> if it's plugged via ethernet only i need some sort of bootstrap processor with ecp5
<whitequark> and i'm thinking, fx3 is just an arm926
<sorear> how much bom advantage over starshipraider do you have left
<azonenberg_work> Shiny
<whitequark> it could *also* be the bootstrap processor, even if you don't even have usb even soldered on the board
<whitequark> it's pretty cheap
<azonenberg_work> sorear: well whitequark is going much lower end on the io cell
<azonenberg_work> thats a substantial fraction of my bom
<whitequark> considering how much micros with integrated mac cost
<azonenberg_work> glasgow also isnt going to have 4GB of DDR3 as a capture buffer
<whitequark> sorear: one particular advantage with glasgow is that it generates bitstreams on the fly
<azonenberg_work> Not that ram is expensive, but the pcb design rules you need for it add a lot to the O(1) cost
<whitequark> as opposed to starshipraider's fixed function pipeline
<azonenberg_work> whitequark: its not fixed function exactly
<whitequark> well muxed function
<whitequark> something like that
<azonenberg_work> i see it more as a kind of coarse grained FPGA type datapath
<azonenberg_work> you have a bunch of IP blocks and you can route between them as you see fit
<whitequark> i mean it's also muxed in gpus which i was using as an analogy
<whitequark> right
<whitequark> i really don't want to try and design that right
<whitequark> right now revA has bitstream gen done for anything in under 10 seconds
<whitequark> even for relatively high up5k utilization
<whitequark> hx8k is a bit larger but i think i will always stay under 30 seconds
<whitequark> ecp5 is larger still so i guess a minute is a good target?
<whitequark> this is why i don't have native usb
<whitequark> other than being a pain in the ass it makes bitstream compiles much longer
<whitequark> ideally a "blink a led" design should be dominated by like, PAR initialization time
<whitequark> not some stupid USB core
<whitequark> nevermind that there isn't even a FOSS SS USB core in the first place I think
<rqou> daisho?
<whitequark> oh
<rqou> no idea if it works or not
<whitequark> oh yeah
<rqou> it was never clear
<whitequark> i guess that
<sorear> is the 5GbE MAC you're doing ~5% of "native USB", much more, much less?
<whitequark> sorear: what do you mean?
<whitequark> cypress fxN series chips are highly integrated, their IP does an enormous amount of USB handling
<whitequark> in fact their silicon can and does respond to some control requests by itself
<whitequark> without the CPU running at all
<whitequark> the 5 GbE interface isn't a MAC exactly
<whitequark> the MAC sits in the FPGA in either case
<sorear> " fx3 presents itself as usb-ethernet, fpga multiplexes between fx3 bus and rgmii depending on either runtime setting or selected during bitstream gen" how cheap is handling rgmii, and is rgmii the same thing you use for 5 GbE?
<whitequark> rgmii is just a ddr bus that spits bytes back and forth
<whitequark> it runs in its own 125 MHz clock domain
<whitequark> so you need to batch up symbols received from rgmii or sent to rgmii and increase the datapath width
<whitequark> the fx3 has a configurable parallel bus
<whitequark> 8, 16, 32 bit, running at a multiple of 19.2 MHz
<whitequark> oh sorry
<whitequark> GPIF runs at 100 MHz
<whitequark> so at most, you can transfer 3.2 Gbps via FX3
<whitequark> still better than 1 GbE
<whitequark> quite a bit better
<whitequark> azonenberg_work: oh lol that answers the question
<whitequark> fx3 can't handle rgmii directly
<whitequark> a bit too slow
<whitequark> oh and it can't do ddr at 100 mhz too
<whitequark> so yeah, when fx3 boots, it loads a prebuilt bitstream into the fpga that basically just streams everything on ethernet to fx3
<whitequark> fx3 runs smoltcp
<whitequark> it gets an address via dhcp or something, you can configure it via a web interface, and so on
<whitequark> azonenberg_work: anyway, i'm thinking it should work like this
<whitequark> all real bitstreams with ethmac should forward traffic to fx3 control channel too
<whitequark> in fact, all bitstreams should probably just forward all unidentified traffic to fx3 always
azonenberg_work has quit [Ping timeout: 260 seconds]
<whitequark> so you can do things like talk to fx3 to configure DAC/ADC on the board without actually touching the FPGA
<whitequark> then, the phy is also configured to recognize any packet with a magic sequence plus the device's serial number as "wake on lan"
<whitequark> except instead of waking it hard resets the fpga and reloads the known good bitstream
<whitequark> this means that even if you e.g. load your own bitstream and fuck it up
<whitequark> you never have to physically go towards the device and power cycle it
<whitequark> because it might not be on the same continent
<whitequark> in fact, i think the *fx3* should *also* recognize a magic packet that tells it what network configuration to use. dhcp, static ip, whatever
<rqou> inb4 hp ilo AAAAAAAAAAAAA bug :P
<whitequark> rqou: rust tho
<rqou> aw
<whitequark> lol
<whitequark> so at most you need to send two broadcast udp packets in the same network segment to have it up and running *guaranteed*
<whitequark> actually it should even work as a dhcp *server* so that you can plug it into windows and have it instantly work
<rqou> hmm if i ever get around to building my own version i might just stick with the "use one of those weird QCA switches with leaked datasheets"
<whitequark> we can even add a small FAT image inside that appears like a USB flash drive with a .url file pointing at the IP it chose :P
<whitequark> i think the ethernet configuration problem is a real point of frustration and it should be addressed as much as possible
<rqou> you can always use exclusively link-local addresses with mdns :P
<whitequark> i no longer think the fx3 should work in any mode other than usb-ethernet because that means two completely different datapaths in the fpga and the host software
<whitequark> that would be a debugging nightmare
<whitequark> the fpga will always terminate a certain port range on itself and the fx3 will always terminate all other ports on itself
azonenberg_work has joined ##openfpga
<whitequark> with real ethernet fpga does the filtering, with usb ethernet fx2 does the filtering, which it should be just marginally fast enough for
<whitequark> fx3 even
<whitequark> or not even that, always process everything on the fpga first for deterministic low latency, and just mirror the control channel back to fx3
<whitequark> i like that, this means very little conditional code in the gateware
<whitequark> it would be possible to just *always* build in both the rgmii and the fx3 interfaces
<sorear> on revB, do any of the applets do "business logic" on the mcu?
<whitequark> sorear: nope
<whitequark> the mcu is absurdly slow
<whitequark> it has like... 12 mips at best
<azonenberg_work> sorear: its an arm926 iirc
<whitequark> the only thing the mcu does that is related to applet logic is configuring board voltages and responding to alerts
<whitequark> azonenberg_work: i think you missed a bit of convo
<azonenberg_work> oh you mean the 8051?
<whitequark> yes
<azonenberg_work> on the fx2?
<whitequark> fx2
<azonenberg_work> ah ok
<whitequark> fx3 is still not exactly a speed demon
<whitequark> 200 mhz arm926
<azonenberg_work> whitequark: and re fx3 stuff, what about using the parallel bus as "WGMII"
<azonenberg_work> i.e. RGMII, GMII, this
<sorear> how many arm mips is an 8051 mip worth
<azonenberg_work> 62.5 MHz 16-bit data plus control signals
<whitequark> sorear: extremely few
<whitequark> azonenberg_work: see what i'm trying to achieve is, i want to always have a control path to the fx3
<whitequark> even when the fpga is running an applet
<azonenberg_work> whitequark: i2c?
<azonenberg_work> :p
<whitequark> azonenberg_work: that's not it
<rqou> hmm, my version probably won't bother with that
<whitequark> there should be a control path from the phy that allows loading a new fpga bitstream
<whitequark> at all times
<azonenberg_work> yeah that isnt something i am going to support
<azonenberg_work> Starshipraider wont have a CPU and will just bridge tcp to hard IP in gateware
<whitequark> this is achieved by (a) fpga forwarding all unrecognized traffic to fx3's tcp/ip stack
<sorear> "DMIPS/MHz for original 80C51 is 0.00941" w t f
<azonenberg_work> Firmware updates will be done rarely, by jtag in the first rev and later on probably by adding TFTP support
<azonenberg_work> sorear: that's worse than some of my first unoptimized fpga mips cores with 50+ cycle L1 miss service times
<azonenberg_work> lol
<whitequark> (b) using the wake-on-lan feature configured for a custom sequence in the phy to tell fx3 to reload a known good empty bitstream
<whitequark> so you send two udp packets to fully configure a board that has a valid fx3 firmware already
<sorear> i432 is about 0.0008, i had no idea there was anything else commercial below 0.01
<whitequark> no matter what state it is in
<whitequark> even if you loaded an fpga bitstream that just hung
<azonenberg_work> whitequark: nice
<whitequark> maybe it's a PAR bug, maybe you're debugging a new version of ethmac, etc
<azonenberg_work> i was planning on using the multi-boot feature in the FPGA
<whitequark> you should never ever lose access to the board
<azonenberg_work> But for the most part, it will not be something that updates firmware often
<whitequark> unless you reflash the fx3 in such a way that the tcp/ip stack in it dies i guess
<azonenberg_work> i'm expecting the protobuf API to be the primary interface
<whitequark> right
<whitequark> fundamental differences :p
<whitequark> this is also why i can't use xilinx
<whitequark> time to bitstream way too high
<azonenberg_work> no, this is why you need to help port nextpnr to 7 series :p
<azonenberg_work> but yeah you are using the fpga more as an accelerator
<azonenberg_work> while to me it's the core of the whole system
<azonenberg_work> Most of my recent boards are 100% FPGA
<whitequark> well, it's not exactly an accelerator
<whitequark> the idea is that you never use the fx3 CPU core other than for out-of-band ("ILO") management
<whitequark> fx3 CPU core never runs at all when you just throw ethernet traffic at it
<whitequark> rqou: you're saying you dont exactly want usb right?
<whitequark> i have a solution for all this too
<rqou> i'm not sure exactly
<rqou> i need to give it more thought
<rqou> damn i really need to get some stuff cleaned out of the backlog
<whitequark> rqou: the normal usb3 fx3 is like $30
<sorear> so if this thing is going to have an IP address, how is it going to handle authentication :P :P :P
<whitequark> but there's an usb2-only fx3 for like $15
<rqou> i personally don't care about authentication
<whitequark> i guess that's just dies that failed usb3 serdes tests?
<rqou> wrap it externally
<azonenberg_work> sorear: starshipraider, at least to start, will be unauthenticated and primarily used on closed point to point links or just tunneled over VPN or something
* sorear targets ads at rqou that search for accessible revE devices
<azonenberg_work> on a network that only contains half a dozen devices and i am the sole user of any of them, auth doesnt serve much purpose
<azonenberg_work> (this is also one of the reasons why my web browsing VM is in the DMZ and not on the lab network)
genii has quit [Remote host closed the connection]
<rqou> sorear: ok congrats, you changed the settings
<rqou> now what?
<azonenberg_work> rqou: bitstream brick
<azonenberg_work> obviously
<azonenberg_work> :p
<whitequark> rqou: so going to usb2 fx3 to use it just as a bmc cuts the bom by $15 plus whatever usb shit you don't populate
<sorear> i think the stylish option these days is a miner
<whitequark> if it has usbc it needs a superspeed mux
<whitequark> and a usb pd controller
<whitequark> (jesus christ)
<rqou> no you don't?
<sorear> …they couldn't integrate that?
<rqou> just a mux hardwired for legacy UFP mode?
<whitequark> oh right you don't need pd to handle just flipping the connector
<whitequark> oh yeah the mux is in the host
<whitequark> ok
<whitequark> sure
<whitequark> sorear: fx3 predates usbc
<whitequark> by many years
<azonenberg_work> have you seen the connector on the fx3 dvk?
<sorear> is it possible to do 3.2 Gbit/s operation if you have usb2 + ethernet?
<azonenberg_work> its a micro usb with a superspeed piggyback hanging off the side :p
<whitequark> sorear: obviously not
<whitequark> azonenberg_work: what
<whitequark> oh is it for like
<whitequark> usb2 goes to one chip, usb3 to another?
<azonenberg_work> no its one connector
<rqou> wait, not the standard micro-b superspeed?
<whitequark> oh thats just the micro usb 3 connector
<whitequark> its actually standard, because usb-if is full of idiots
<azonenberg_work> usb 3.0 micro
<whitequark> ok well i guess it's backwards compatible with usb 2 micro
<whitequark> so not idiots
<azonenberg_work> see if it was *me*
<azonenberg_work> i would have had usb3 use the same connector
<azonenberg_work> have it start out in high speed serial mode
<azonenberg_work> if you fail to link up after say 50-100 ms, fall back to legacy usb2 over the same diffpair
<rqou> that doesn't work
<rqou> it's full duplex
<azonenberg_work> Just have tighter tolerances on the same cable
<whitequark> yeah
<azonenberg_work> ah yeah fine
<azonenberg_work> i forgot usb2 was braindead half duplex
<sorear> works for ethernet :P :P
<whitequark> well ethernet has an analog phy
<azonenberg_work> because two wires are soooo expensive
<whitequark> in fact the ti phy i'm looking at is basically... sdr
<whitequark> azonenberg_work: twopairs going each way
<azonenberg_work> Just like BroadR-Reach in automotive stuff
<whitequark> oh usb2
<whitequark> yeah
<azonenberg_work> It is literally 100base-T reinvented to use one diffpair sending in both directions
<whitequark> wtf
<azonenberg_work> Because a second pair is too expensive
<azonenberg_work> look it up
<azonenberg_work> they have a gig version under development, not sure if it launched
<whitequark> wtfff
<rqou> oh yeah that
<azonenberg_work> people will spend obscene amonuts of engineering time to save a few pennies on cable costs
<azonenberg_work> i dont get it
<azonenberg_work> just use cat5 for crying out loud
<azonenberg_work> your $20K car will maybe have an extra $3 of wire in it
<rqou> azonenberg_work: you have seen the crazy "waveguide POTS" proposal that @alt_kia has linked, right?
<sorear> but gig already uses the lines in both directions
<rqou> maybe it's not useful for cars, but for telecom it's definitely useful because of just how ludicrously expensive last mile is in the us
<whitequark> technical solution for social problem lol
<sorear> "visual pollution"
jcarpenter2 has quit [Read error: Connection reset by peer]
<rqou> hey, about a decade ago my father sold an absolute ton of ethernet-over-t1 solutions
<rqou> including things like bonding a whole bunch of T1s together to give you just barely 10mbps
<whitequark> rqou: lol there's an fx3 variant that has native rgmii
<whitequark> oh
<whitequark> no
<whitequark> it has a *PHY*
<rqou> oh nice
<whitequark> yeah that... is just a usb ethernet chip
<whitequark> it doesn't have gpif
<whitequark> you can't interface it to an fpga
<rqou> wtf
<whitequark> i think it's supposed to work the other way
<whitequark> ie, you have usb3 and you want ethernet
<whitequark> yeah
<rqou> hmm slap it together with a qca switch chip
<whitequark> that doesnt have the capability i want, which is bitstream reload via network from absolutely any state
<rqou> one copper port to external, one copper port to the fx3, the rgmii port to the fpga
<whitequark> although... hm
<rqou> now everything has access to packets from both interfaces
<whitequark> rqou: how much does the qca switch cost
<rqou> idk
<rqou> aliexpress it? :P
<whitequark> if it's more than $15 it is more cost effective to use fx2 in your usb-less design
<rqou> it's definitely less if you aliexpress it
<whitequark> what p/n ?
<rqou> sec
<whitequark> i see switches on mouser starting at about $15
<rqou> whitequark: ok this isn't the one i had in mind, but AR8327
<whitequark> it's not on mouser
<whitequark> or digikey
<whitequark> or farnell
<whitequark> im not going to use this part
<whitequark> azonenberg_work: rqou: WTF
<whitequark> lt4295
<whitequark> is a fully integrated PoE powered device controller
<whitequark> from linear
<whitequark> for $2.75
<azonenberg_work> Sounds like i need to start building a lot more poe hardware?
<whitequark> yeah
<whitequark> i might add poe then?
<whitequark> it seems real easy to use
<zkms> tired: laptop charging over USB-PD wired: laptop charging over 802.3bt
<whitequark> lol
<azonenberg_work> zkms: i would LOVE a laptop that has PoE charge capability
<azonenberg_work> Better yet, if it's bidirectional
<azonenberg_work> as in, you have a switch to select the PoE as host or device
<azonenberg_work> So it can talk to an external IP phone, camera, etc
<azonenberg_work> or charge itself off a PoE switch
<rqou> whitequark: ok, QCA8334
<whitequark> azonenberg_work: so you invented usb-c
<azonenberg_work> whitequark: Does it support legacy PoE btw?
<whitequark> azonenberg_work: yes
<rqou> you know it's good because cheap chinese crap uses it :P
<whitequark> it supports 4 poe modes
<whitequark> >n IEEE 802.3af/at/bt(Draft 2.0) Powered Device (PD)
<whitequark> with Forward/Flyback Controller
<azonenberg_work> ah ok so it does 802.3af too
<zkms> azonenberg_work: i was actually looking at laptop DC-DC topologies to see if i could graft a USB-C PD input to my shitty laptop so i can use USB-C PD chargers but i think making a PoE interposer wouldn't be that difficult either
<azonenberg_work> whitequark: because i have a bunch of cheap passive poe injectors
<azonenberg_work> (mid-span)
<azonenberg_work> maybe i can eventually make a next-gen LATENTRED line card that supports PoE host
<azonenberg_work> the first iteration wont
<rqou> whitequark: if you don't want evil leaked QCA/MRVL datasheets, KSZ9893
<whitequark> rqou: none of them are on mouser
<rqou> also, there's always aliexpress :P
<whitequark> rqou: thats not acceptable
<whitequark> today there is and tomorrow there isnt
<whitequark> and its too slow
<rqou> worksforme(tm)
<whitequark> rqou: well it doesnt work for me
<whitequark> definitely
<sorear> 802.3 af mmm
<azonenberg_work> rqou: thats a pretty sophisticated switch asic but only 3 ports
<azonenberg_work> not sure how often i can think of someone needing QoS in a 3-port switch...
<rqou> oh there's a normal 7 port version too
<whitequark> rqou: ok the KSZ works i suppose
<whitequark> but
<whitequark> it's a $7 part and i would still need a $15 fx3 part
<rqou> yeah idk
<rqou> somehow all of the intermediate bandwidths between 1g and 10g are really annoying to access for some reason
<whitequark> rqou: i *guess* this would work and its technically cheaper
<whitequark> if you ignore the availability of KSZ
<rqou> either the computer side doesn't support it easily (2.5gbe/5gbe) or the fpga/device side doesn't support it easily (usb3)
<rqou> 1g is easy, 10g is "easy"
<rqou> everything in the middle is awful
<whitequark> i'm not really comfortable with KSZ but *maybe* it could work
<rqou> but anyways, given infinite time and money i was targeting 1gbe for my low-end device and 10gbe/rogue-reverse-engineered-thunderbolt for my high-end device
<rqou> with 25gbe and 100gbe being the "in my dreams" devices beyond that
<whitequark> rqou: do you want easy bitstream hot reload?
<rqou> i don't care about that
<whitequark> oh
<whitequark> then you can just not populate the usb side of the board at all
<whitequark> i'll make it so that both fx3 and fpga can boot from the same flash
<rqou> wait are you actually working on this now-ish?
<whitequark> sort of? i'm mapping it out on the highest level
<whitequark> which chips to use, general architecture
<rqou> i really need to figure out how to stop feeling burned out AF
<sorear> would that be a multiboot/tinyfpga approach where the fpga updates the second boot image based on ethernet data?
<whitequark> i imagine?
<whitequark> how else
<whitequark> rqou: how do you want to set port voltages etc
<whitequark> glasgow uses an i2c adc/dac
<rqou> i was probably going to make my own "just barely good enough" io cell
<rqou> much cheaper than azonenberg_work's
<rqou> one option is dacs or digipots controlling an off-the-shelf power supply
<rqou> yeah, probably just that
<whitequark> off-the-shelf what?
<whitequark> ldo?
<rqou> probably ldo
<whitequark> ok
<whitequark> what about io cell itself?
<whitequark> fmax?
<rqou> i haven't exactly planned everything through
<rqou> but 100mbps for the low-end one and 500mbps for the high-end one?
<rqou> don't know yet for the "only dreaming" ones
<awygle> 1) yeah definitely only use module if it makes sense
<awygle> 2) I'm pretty sure there's lots of poe controller parts like that, I think Microsemi has one
<whitequark> awygle: i was looking and i think i couldnt find much usefl
<awygle> 3) mdns, ipv4ll and dns-sd plz
<rqou> wtf ipv4?
<awygle> I'll also accept slaac and dns-sd
<whitequark> good luck implementing that on fpga rqou lol
<rqou> why?
<rqou> oh wait no not mbps
<rqou> derp
<rqou> mhz
<awygle> I just don't know ipv6 at all because it functionally doesn't exist and possibly never will
<whitequark> awygle: it exists
<whitequark> in the US in particular
<awygle> don't @ me lol
<sorear> hi, i'm chatting from an ipv6 address in MA right now
<rqou> both comcrap and at&t uverse have ipv6
<rqou> here in the sf bay
<rqou> wireless doesn't though
<awygle> I know it does exist and can be used
<rqou> oh huh
<whitequark> awygle: anyway smoltcp has support for all
<rqou> just at&t wireless doesn't have ipv6 still
<rqou> vzw is ipv6
<awygle> But I bet adoption figures are like, 5%
<awygle> whitequark: yeah smoltcp is dope
<whitequark> of these options
<whitequark> including multicast
<whitequark> awygle: its higher
<whitequark> and rapidly rising
<sorear> https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption 34% in USA
<sorear> but I'm sure you'll say the same when it's 80%
<rqou> uh awygle you're connected to freenode on an ipv6 address right now
<rqou> oh lol it's a DO droplet
<awygle> yep
<rqou> but still, ipv6
<awygle> wow 34%? I'll eat crow on that, never would have guessed that high
<rqou> it jumped up significantly after comcrap rolled out native dual stack
<rqou> because despite their frontend being awful, their backend tech staff are actually competent
<rqou> the opposite of AT&T
<awygle> I guess I should start giving a shit about ipv6 support
<awygle> sorear: thank you for adding to my knowledge base
<rqou> the only problem in the US is the awful practice of giving out really small and dynamic ipv6 allocations
<rqou> the recommended practice is iirc to give customers a static /56
<whitequark> rqou: SN74AXC1T45
<whitequark> 0.6-3.6 @ 200 MHz
<rqou> comcrap gives iirc a static /60
<rqou> *dynamic
<rqou> both comcrap and at&t hand out dynamic ipv6 blocks because they're idiots
<whitequark> rqou: actually wait
<whitequark> Up to 500-Mbps Support When Translating from
<whitequark> 1.8 to 3.3V
<whitequark> let's see the ds
<rqou> brb
<azonenberg_work> rqou: you can get a static /56, at least on comcast business
<azonenberg_work> But you have to ask
<whitequark> rqou: so i get 140 MHz @ 1V2, 250 MHz @ 1V8, and 330 MHz @ 2V5-3V3
<whitequark> with this level shifter
<whitequark> oh wait hm
<whitequark> no, double thta
<whitequark> so 280 MHz @ 1V2, 500 MHz @ 1V8, and 660 MHz @ 2V5-3V3
<whitequark> and it's absurdly cheap too
<whitequark> rqou: it needs to be protected above 4V2
<azonenberg_work> whitequark: starshipraider is going to use that or a very similar one
<azonenberg_work> plus another for 5V support
<sorear> does a clock work at the full speed, or half of that?
<TD-Linux> one nice thing about ipv6 is that you can just read the mac address off a box and make a link local address to attach to it
<TD-Linux> don't need to worry if dhcp is working or what its ip is
<whitequark> azonenberg_work: i think rev e wouldn't have 5v support
<rqou> uh, no?
<whitequark> to make the io cell cheaper
<rqou> privacy extensions
<whitequark> rqou: which are not needed for this device
<whitequark> azonenberg_work: remind me how do you protect this level shifter?
<whitequark> dc block?
<rqou> right, but that means "just look up the mac address" doesn't always work
<azonenberg_work> whitequark: My protection circuit is basically a crossover network with two separate protections
<azonenberg_work> i have an AC coupled path that is just an ESD clamp diode in series with a capacitor
<TD-Linux> right, doesn't work on laptops where that's usually enabled, but I don't need it for that anyway
<azonenberg_work> And a DC coupled path with an inductor to block AC on either side, a series resistor to reduce fault current, then a beefy schottky clipping to Vdd and Vss
<whitequark> azonenberg_work: ...
<azonenberg_work> The two paths are connected at both sides
<whitequark> i see yes
<azonenberg_work> whitequark: I spent a LOT of time on this
<whitequark> i... could make that a footprint option?
<azonenberg_work> tl;dr if you want tolerance to high DC shorts
<azonenberg_work> high voltage DC shorts*
<whitequark> yes, i remember the general idea
<azonenberg_work> an ESD diode will fry
<whitequark> but not specifics
<azonenberg_work> but a diode big enough to clip high current will wreck your SI due to high parasitics
<whitequark> azonenberg_work: so like i want protection for overvoltage over 4V2
<azonenberg_work> Yes
<sorear> the real sticking point here is that protection diodes have varicap capacitance
<whitequark> but i dont want the bom cost
<azonenberg_work> That's what my design does, sacrificing cost for robustness
<azonenberg_work> I have not tested it
<azonenberg_work> I have a prototype PCB and components sitting on a shelf
<azonenberg_work> waiting for me to have a solder-capable lab
<azonenberg_work> i dont even know what box my iron or reflow oven are in
<whitequark> azonenberg_work: so what im thinking is
<whitequark> rev E will have that io cell on the pcb but the normal assy will have 0R instead of the cap
<whitequark> after it's qualified, either the same rev will use different components
<whitequark> or a new rev will be needed
<sorear> give azonenberg_work a magic 0pF diode that can tolerate sustained >100mA and the whole problem becomes much simpler
<azonenberg_work> whitequark: makes sense
<azonenberg_work> sorear: exactly
<azonenberg_work> The engineering to make this protection work given real, non-ideal components was HARD
<azonenberg_work> I spent months on it and had one or two failed pcb revisions
<azonenberg_work> then gave up on a monolithic solution
<azonenberg_work> and split the AC/DC path
<azonenberg_work> Sims say it should be really nice but i have no experimental results yet
<whitequark> huh
* sorear can't help but wonder if we're overlooking a solution that's fundamentally different from semiconductor diodes
<azonenberg_work> sorear: I spent a lot of time bouncing ideas off people, testing prototypes, etc
<azonenberg_work> clamp diodes seem like the only option to protect against overvoltage
<sorear> hence "we" not "you", i remember the bouncing clearly
<azonenberg_work> if you need tight tolerances (spark gaps etc are too imprecise at low voltages)
<whitequark> lol a 5v spark gap
<azonenberg_work> a few hundred nm across? :p
<whitequark> ... MEMS sparkgaps?
<azonenberg_work> if somebody can make one with low enough capacitance
<azonenberg_work> i'll use it in a heartbeat
<azonenberg_work> Clamp diodes capable of handling brief ESD pulses can be made small
<azonenberg_work> but they basically rely on bulk silicon thermal mass to prevent them from melting during a pulse
<rqou> my solution is that i simply don't care about protecting against this level of overvoltage
<azonenberg_work> And this doesnt scale to sustained overvolage
<whitequark> rqou: not even 5v?
<azonenberg_work> my first attempt used a midway solution, a smallish diode that could sustain the fault current for a few tens of ms
<sorear> ESD diode and a peltier? :P :P
<azonenberg_work> But had highish capacitance
<rqou> i'd design for max input voltage of 5v, anything above 5v is yolo
<azonenberg_work> Then a mechanical relay to open the fault path before the diode melted
<sorear> peak current should be higher at -100C ambient :P
<sorear> s/peak/sustained/
<whitequark> rqou: you cant do 250 MHz like that
<azonenberg_work> the SI was awful (at 500 MHz I had something like 2-5 ohms to ground effective impedance through the diode)
<rqou> why not?
<azonenberg_work> and the relay was huge
<azonenberg_work> my new solution is entirely solid-state and can sustain the fault current at +/- 12V indefinitely
<TD-Linux> clamp diode + fuse?
<azonenberg_work> TD-Linux: Thought about that too, couple problems
<azonenberg_work> first, a fuse of that size will be a pain to replace when, not if, you blow it
<azonenberg_work> I consider fuses to be a last resort safety measure
<azonenberg_work> Fuses should never blow during normal (ab)use
<azonenberg_work> if a fuse blows, it means something is seriously wrong and the device is effectively self-destructing to protect the user and downstream expensive parts
<TD-Linux> sure it's an 0805 fuse or whatever
<azonenberg_work> 0402
<azonenberg_work> Socketed fuses times 32 channels would be massive, and have terrible SI
<TD-Linux> make it 0805 so it's ez to replace
<rqou> ah, i see you are nintendo :P
<rqou> nintendo handhelds are full of tiny smd fuses
<azonenberg_work> rqou: basically, i prefer passive, auto-resetting safety measures for errors that occur during normal operation
<azonenberg_work> fuses are like asserts
<rqou> i prefer yolo because imo it's just not that likely
<azonenberg_work> they should never trigger in production and exist only to protect against massive, catastrophic hardware failure
<TD-Linux> I thought 5v isn't normal operation here
<azonenberg_work> Like a big decoupling cap failing short
<TD-Linux> also how about a PTC fuse
<azonenberg_work> TD-Linux: anyway re fuses, the bigger problem is, i couldn't find any datasheets or S-parameter documentation
<azonenberg_work> for either fuses or PTCs
<azonenberg_work> They are not intended to be high-speed components
<azonenberg_work> nobody characterizes them that fast
<azonenberg_work> and i didnt have a GHz scope
<azonenberg_work> even if i tested one batch to be good, there was no guarantee the next batch would fail due to a change that didnt touch published parameters
<azonenberg_work> but wrecked high speed performance
<azonenberg_work> and of course they arent remotely controlled impedance :p
<sorear> seems like the lack of scope can be worked around. you really don't expect a fuse driven at 1GHz to produce current at 1.21GHz
<azonenberg_work> sorear: i was more worried about getting reflectoins off the impedance mismatch
<sorear> only looking for a couple parameters, not a waveform
<azonenberg_work> Or nonlinearities
<azonenberg_work> parasitic capacitance
<azonenberg_work> etc
<zkms> azonenberg_work: what did you decide on for your final design
<awygle> PTC fuses are super high resistance, relatively speaking
<azonenberg_work> zkms: there is no final design
<awygle> probably not a huge problem in this context though?
<azonenberg_work> the most recent, not yet assembled, prototype
<azonenberg_work> has an AC path with a DC-blocking capacitor and a small low-cap ESD diode
<azonenberg_work> And a DC path with two AC-blocking inductors, a current-limiting resistor, and two beefy schottkies
<awygle> I'd be really surprised if you got substantial C. maybe some L...
* awygle zzz
<azonenberg_work> awygle: the point was more that it was a device not intended or characterized for high speed
<azonenberg_work> i also didnt know how fast the response time would be
<azonenberg_work> vs frying the chip
<azonenberg_work> a diode clamp responds in nanoseconds
<sorear> re. 5V spark gaps: so Paschen's law is a lie?
<awygle> you need both, the diode and the PTC
<zkms> azonenberg_work: nice, so does that give you adequate signal integrity from DC to whatever top frequency?
<azonenberg_work> awygle: yeah it might work
<azonenberg_work> key word "might"
<azonenberg_work> zkms: hyperlynx simulatoins run by a friend (i dont have a copy of it myself) were very promising
<azonenberg_work> I have the board and parts sitting on a shelf
<azonenberg_work> my oscilloscope is in a box nearby
<azonenberg_work> and i have NFC where my reflow oven or soldering iron are
<rqou> anyways, i don't have exact parts chosen yet for 500mhz, but for my low-end io cell RX path i was just going to abuse something like the SN65LVDS33
<azonenberg_work> they're in a box somewhere, my spreadsheet says what box number but IDK where that box is :p
<azonenberg_work> zkms: once my lab is on-line, ETA early next year
<rqou> for the tx path i'll just pick some random unidirectional buffer with enable
<azonenberg_work> it's first in line of the boards to get assembled
<rqou> worse case i'll pick two, one for 5v and one for <=3.3v
<azonenberg_work> sorear: you might not be able to use air as the dielectric
<azonenberg_work> you'd probably also want to make the electrodes pointy to cause field emission
<rqou> i was just going to rely on "if you f*cked up you'll hopefully only zap the SN65LVDS33"
<azonenberg_work> yeah starshipraider is designed to survive and continue operating
<azonenberg_work> if you apply any DC fault up to +/- 12V
<rqou> i don't care about that
<rqou> and the SN65LVDS33 is really cheap and is a nice ghetto comparator
<azonenberg_work> keep in mind, the scenario is "I took this thing in my carry-on to an onsite in another country and accidentally probed the wrong wire"
<azonenberg_work> i cant tell the client the gig is over because i fried my test equipment
<azonenberg_work> it needs to keep working
<rqou> i would just say "don't be an idiot and don't probe the wrong thing"
<azonenberg_work> And i'm not going to find a new LVDS comparator on apliu st and solder it into my board
<rqou> "check first"
<azonenberg_work> rqou: when reverse engineering stuff you often dont know what's what yet
<azonenberg_work> you might be probing a line that is normally low voltage but under some conditions has +12V on it
<rqou> that would be highly unusual
<azonenberg_work> say an analog status line or something
<azonenberg_work> or even something that is powered down in sleep but wakes up sometimes
<azonenberg_work> gated power rail etc
<rqou> unless you're probing a display, voltages anywhere near 12V are pretty rare
<rqou> oh wait
<rqou> scada
<rqou> cause you're a weirdo
<azonenberg_work> rqou: actually, not just that
<azonenberg_work> i'm thinking wallwart
<azonenberg_work> 12V is the highest wallwart voltage commonly seen outside oddball very high power things like laptops
<azonenberg_work> i.e. if the gizmo does not have a mains plug on it
<azonenberg_work> and is not a laptop
<rqou> yeah, in the tiny corner of the board
<azonenberg_work> odds are >99% there will not be anything >12V *anywhere* on it
<rqou> basically i consider it good enough for me
<azonenberg_work> thus, if your board survives +/- 12V on every pin
<azonenberg_work> and you never work on line-powered hardware
<azonenberg_work> it's effectively indestructible
<azonenberg_work> Which was the design goal
<rqou> my opinion is still "you've got a multimeter too you know"
<azonenberg_work> Starshipraider has a slow ADC on the io card
<azonenberg_work> that will probably *be* my multimeter
<azonenberg_work> the goal is for it to be all of your test equipment at once
<azonenberg_work> for a typical digital reversing project
<rqou> sure
<rqou> but i'll have a separate "multimeter" card
<azonenberg_work> i probably will too
<rqou> that has all of the CAT I/II/III/whatever protection on it
<sorear> make field-replaceable I/O cards, and fly out with twenty spares :P
<azonenberg_work> sorear: lol
<rqou> yeah that too
<rqou> a SN65LVDS33 is like $3
<azonenberg_work> I still think making it hard to kill is a desireable design goal
<azonenberg_work> Even if it costs a little more
<azonenberg_work> people wouldn't stand for a tek dso that died if you accidentally twiddled V/div one knob too far
<azonenberg_work> one click
<rqou> uh, people accept "don't be an idiot on the 10A setting" on multimeters all the time
<azonenberg_work> yes but thats different
<azonenberg_work> you put it in current mode
<rqou> tell that to all of the multimeters in the EE lab that can no longer measure current because the fuse is blown
<azonenberg_work> Lol
<azonenberg_work> I mean, this is the diff between my general engineering practice and yours
<rqou> and evil people like me who are too lazy to email the support staff who just hunt around for a multimeter at a station that does have a working fuses and swaps them
<azonenberg_work> I want a tool that does what you want within reason, but has at least minimal capability to prevent extreme stupidity from causing a catastrophic failure
<rqou> pushing the problem to the next poor sucker :P
<azonenberg_work> rqou: see if it was me i'd either bring my own dmm and not let anyone else touch it
<azonenberg_work> or i'd come to lab with a pocket full of new fuses
<azonenberg_work> and swap when the TA's back was turned
<TD-Linux> azonenberg_work, yeah the tek scope fries itself with no input needed :^)
<azonenberg_work> :p
<rqou> uh, my tek scope is more than a decade old and works fine?
<azonenberg_work> TD-Linux: and my lecroy has bsod'd on me a couple times
<azonenberg_work> well ok, hard lockup but no literal bluescreen
<TD-Linux> rqou, yeah that's why it's fine
<rqou> TD-Linux: ?
<TD-Linux> (though if you bring that up to two decades, they are all dying now)
<rqou> i have one about that old and it mostly works
<rqou> the crt has some issues with colors not lining up though
<TD-Linux> sample size of one of course, but I've had a modern tek mso whose backlight failed and current probe failed twice
<sorear> i think they're saying that the build quality has gone down recently
<TD-Linux> rqou, that's convergence and yeah it's hard to get right on crts in general
<rqou> oh huh now that you mentioned it i've never seen a modern tek scope
<TD-Linux> imagine a rigol but slower and more expensive
<rqou> they're all lecroy, agilent/keysight, or the new wave of low-end ones
<TD-Linux> (to be fair their decoding is 1000x better because it doesn't happen in screen space)
<TD-Linux> (but what are you doing decoding on a scope anyway, use sigrok)
<rqou> anyways, my daily driver is a TDS3054
<rqou> the scope with convergence problems is iirc a TDS540
<rqou> it's probably fixable, i just haven't gotten around to messing with it
<whitequark> rqou: wait so you do want 5V?
<rqou> yeah
<whitequark> you said before you don't
<rqou> i did?
<rqou> basically i want 0-5V only, anything else is yolo
<rqou> abusing an lvds receiver as a comparator
<whitequark> hmm
<whitequark> rqou: so you wouldnt use azonenbergs io cell?
<rqou> nah, too expensive and overcomplicated
<rqou> i don't care about -12V to 12V protection
<azonenberg_work> whitequark: basically he wants my performance without any protection
<azonenberg_work> he doesnt care about reliability at all
<azonenberg_work> i build hardware to last
<rqou> well, no explicit protection
<whitequark> rqou: hmmmm
<rqou> i rely on hoping that mistakes just blow up the buffers on the io card
<rqou> without blowing through it and blowing up the fpga
<whitequark> the lvds comparator doesnt even have esd protection does it?
<rqou> this one does
<whitequark> hm
<azonenberg_work> rqou: yeah, while i don't consider the buffer cards expendable
<whitequark> rqou: so you want discrete line cards?
<rqou> yeah
<whitequark> rqou: im trying to figure out if we even are going to share a pcb
<whitequark> or just like... some parts of design?
<whitequark> which even
<rqou> hopefully compatible with azonenberg_work's pinout
<azonenberg_work> thats as silly as bringing a spare laptop because you think a damaged usb device might kill a port
<whitequark> ^ yes
<whitequark> i stuck lots of weird things into revA glasgow
<whitequark> in fact
<rqou> i usually plug shady things into a usb hub :P
<azonenberg_work> You're much better off designing things so that they dont die in the first place
<whitequark> i recently did something that made the entire board heat up so much that the plastic component shroud ended up hot to touch
<whitequark> awygle: btw the LDO protection thing worked out very well
<azonenberg_work> like, when i built my hubs i put in overcurrent shutdown :p
<whitequark> theLDO didn't die, and the DUT ... well it didn't blow up
<azonenberg_work> per port, with indicator LEDs
<whitequark> im not sure if its dead or not
<whitequark> it definitely sunk 150 ma into itself through reverse voltage between gnd and vcc
<azonenberg_work> i wanted to design something that would let me query overcurrent status per board, i think the chipset supported it, but i never figured out how to set it up
<azonenberg_work> per port*
<rqou> yeah i just use a random usb hub that i've hacked into the power rails
<whitequark> azonenberg_work: do you think a nand flash can survive -150 mA on vcc
<rqou> and if it breaks, there's amazon prime now :P
<whitequark> i cant tell if it died or i just cant do onfi
<whitequark> or both
<whitequark> the bus seems to be clamped if i dont give it vcc
<azonenberg_work> whitequark: good question
<whitequark> and always hi-z if i give it vc
<whitequark> *vcc
<whitequark> so its not blown at least
<whitequark> and it wasnt hot
<whitequark> the ldo was, the flash wasnt
<whitequark> at all
<azonenberg_work> huh
<whitequark> is there like a diode from gnd to vcc effectively?
<whitequark> i dont understand that part of silicon well enough
<rqou> often there can be?
<rqou> e.g. due to esd clamps
<whitequark> esd?
<whitequark> oh
<rqou> are you still working on that gba cart?
<rqou> why not just use a sd+ram cartridge?
<whitequark> rqou: no
<rqou> or a from-scratch design if you want to make "repros"
<whitequark> this was a random onfi flash
<rqou> ah ok
<whitequark> rqou: as for sd+ram cartridge
<whitequark> i have this gba cart
<whitequark> and i dont have an sd+ram cartridge
<rqou> just order one?
<whitequark> too slow
<rqou> lolwut
<rqou> and hacking up some custom programmer is faster?
<whitequark> yes
<rqou> wtf
<rqou> ok
<whitequark> significantly so
<whitequark> when i made glasgow
<whitequark> i did in two months more embedded projects that i "kind of wanted" to do
<whitequark> than in the previous five years
<rqou> meh, i already have two sd+ram things somewhere
<whitequark> rqou: i thought those dont get the timings right
<rqou> one of them does, one doesn't
<rqou> unless you're thinking NDS carts in which case the timing is all over the place
<rqou> but yeah, one of them required a piece of shit app to patch out the waitstate change or games would crash
<whitequark> idk whatever
<rqou> and yes, you would (occasionally) notice
<rqou> btw for anybody who cares, yoshi's island gba is pretty good for testing this
<rqou> the crates full of stars will lag significantly if the timing is patched
<whitequark> rqou: as for too slow
<whitequark> remeber that im bipolar
<rqou> i also have a pirate cart with this problem :P
<whitequark> once i get into a manic state, everything has to happen NOW
<rqou> heh
<whitequark> in fact this was a part of motivation behind glasgow
<whitequark> as well as how i actually came up with it in the first place
<whitequark> i mean, during a manic episode
<rqou> if i were to get back into gba stuff to make "repros" i would probably try to go all out with a cart that is capable of supporting all the weird rtc+gyro+boktai-solar stuff
<whitequark> like everything else interesting that i've done
<rqou> as in, a new design without any NOS/EOL parts
<whitequark> idk id just stick a large fpga there
<rqou> don't need that
<whitequark> put fpga first
<whitequark> think later
<rqou> just a smol fpga is fine if you don't mind sticking with nor flash
<rqou> it's actually significantly more work cramming the stupid extra features like boktai solar in :P
<whitequark> lol
<whitequark> i dont actually care about gba at all
<rqou> yes, there's a GBA cart with a solar sensor
<rqou> to try to get kids to outside or something
<whitequark> wtf
<whitequark> lol
<whitequark> does it have a spectrometer
<rqou> no, just a photodiode and some shitty ADC
<rqou> the ADC is made up of an up-counter and a comparator
<rqou> to take a measurement you poke the reset pin
<rqou> then you keep poking the "up" pin until the comparator flips outputs
<rqou> there are also multiple gba carts with accelerometer/gyros in them
<whitequark> oh
<whitequark> rqou: anyway im trying to figure out
<Prf_Jakob> Did they ever release that Kirby gyro game?
<rqou> i actually own one of these
<whitequark> you have two designs, slow and fast
<whitequark> do you want to share pcbs with "glasgow revE" for one, both, neither
<rqou> Prf_Jakob: idk about the Kirby one, but the WarioWare one definitely exists
<rqou> whitequark: indifferent but "it would be nice" to share something
<Prf_Jakob> rqou: Ah okay cool
<whitequark> rqou: hmmmm
<whitequark> rqou: the io cell you described, is that "slow" or "fast"
<pie_> im thinking of trying to make a gui dataflow-thingy not related to EE, what do you guys dislike the most about drawing schematics?
<pie_> azonenberg_work, see above?
<rqou> whitequark: not sure, needs me to do math+characterization :P
<whitequark> rqou: how do you feel about 2.54" headers
<rqou> ew
<whitequark> rqou: is the slow design going to use pluggable line cards
<rqou> yeah
<whitequark> rqou: yeah i dont think we can share any part of the design
<rqou> Prf_Jakob: GBATEK doesn't mention a Kirby game
<rqou> there's a Yoshi game, "Koro Koro Puzzle", and Warioware Twisted
<rqou> whitequark: figures
<Prf_Jakob> rqou: Oh okay, then it was a E3 demo or something... Oh yeah it switched between the gamecube and GBA I think.
<rqou> hmm, there's a "Kirby Tilt 'n' Tumble" for GBC
<rqou> nothing for GBA
<azonenberg_work> pie_: what i dislike most? graphical entry in general
<azonenberg_work> i consider it fundamentally unfit for complex netlists
<azonenberg_work> if i could do pcb design in verilog i would
<whitequark> lol
<Prf_Jakob> rqou: Right, my bad.
<rqou> hmm wtf GBATEK's info about the Yoshi gyro sensor is fucked
<azonenberg_work> graphical tools make sense for inherently spatial tasks like pcb/asic layout
<rqou> someone should buy this and fix it lol
<azonenberg_work> netlists dont have any spatial component to them
<azonenberg_work> so it doesnt make sense
<pie_> azonenberg_work, sure, is the only reason the non-layout / semantic portion of it isnt done via some language, other than DID NOT TRY LOL
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
<azonenberg_work> well my first attempt at a pcb netlist hdl tool needed serious work
<Prf_Jakob> rqou: https://www.youtube.com/watch?v=66_xvhHdCv4 yeah this was the thing I was thinking about.
<azonenberg_work> and it did take more time to design
* pie_ actually looks up what netlist means finally
* TD-Linux has managed to put himself into a workflow that needs to wait for windows 98 to boot on a 83mhz pentium to try a new revision
<azonenberg_work> But i was moving toward a next-generation design workflow
<azonenberg_work> where you had things like parameterizable IP cores for a LTC3374
<azonenberg_work> including selection of passives from a library, rounding to the nearest E48 values
<rqou> Prf_Jakob: yeah, wikipedia says cancelled
<azonenberg_work> ERC sanity checking that input and output voltage levels were compatible
<azonenberg_work> so it would, say, error out if you hook a 1.8V output to a 3.3V input
<pie_> azonenberg_work, something something fully integrated HDL stack basically
<azonenberg_work> etc
<azonenberg_work> Yeah, to some extent
<Prf_Jakob> Dang it, I remember thinking it was cool and all. https://www.youtube.com/watch?v=5rLhIwp2iGk This shows the switching between GBA and GC more properly.
<azonenberg_work> It wasnt integrating firmware with pcb
<azonenberg_work> this was pcb only
<azonenberg_work> The big problem is the infrastructure was nontrivial
<azonenberg_work> and i didnt have the time to build it all
<rqou> Prf_Jakob: there's four swords adventures to make up for it?
<pie_> im wanting to do a graphical thing but keep ending up coming back to it being less efficient >_M
<pie_> * >_<
<Prf_Jakob> rqou: Oh yeah and FF crystal Chronicles
<azonenberg_work> yeah imo graphical tools for non-graphical tasks are inherently inferior
<pie_> even while consider possible improvements
<azonenberg_work> they only make sense for *embedded* graphs
<rqou> hmm incidentally, has anybody ever attempted to reactos-audit gbatek?
<azonenberg_work> where spatial position actually means something interesting
<pie_> well im not sure about the divide between graphical/nongraphical
<pie_> are netlists inherently textual?
<rqou> or is this yet another thing that can't be discussed, like oman?
<azonenberg_work> well, i consider them to not be graphical in nature in that they have no 2/3D spatial structure
<azonenberg_work> however, its plausible that a graphical tool can be found using a tree view or something else weird
<pie_> i guess thats fair...*ponders*
<azonenberg_work> i dont know
<azonenberg_work> but a 2D graphical rendering seems inappropriate
<pie_> azonenberg_work, im not a big fan of touchscreen stuff but maybe touchscreen stuff could be better for this than a mouse?
<azonenberg_work> eeeew
<pie_> yeah nevermind xD
<azonenberg_work> meanwhile, my design goal for scopeclient
<pie_> (its pretty fucking hard to beat a mouse tbh)
<azonenberg_work> was to take the lecroy MAUI interface
<azonenberg_work> and rip out all of the stupid touch optimizations
<azonenberg_work> and create something with the same clean, context-based workflow but designed for actual useable input devices
<azonenberg_work> like a keyboard and mouse
<azonenberg_work> i like the idea of a very simple UI that brings up features as needed
<azonenberg_work> But their implementation is atrocious
indy has joined ##openfpga
<pie_> a problem with touchscreen is theres no (tactile) boundaries, and also your fingers block the view
<azonenberg_work> I find myself reaching up from my desk to whack the touchscreen when i could just be clicking the mouse
<azonenberg_work> and you get fingerprints on your display
<pie_> thats just things i dont like off the top of my head
<azonenberg_work> in general it renders high-density UIs impossible
<pie_> yea
<azonenberg_work> it forces you into big marshmallow buttons
<azonenberg_work> Whereas i prefer a UI meant to be used on a large HD display with a keyboard and mouse
<azonenberg_work> that stays out of the way and lets you call things up through keyboard shortcuts, context menus, etc
<pie_> i mean if youre gonna have buttons, make the whole front of the scope a display and put the buttons not near important ui, like the usual physical buttons :P
<rqou> meanwhile i have totally different opinions on how UIs should work
<azonenberg_work> yeah see, my dream dso is a 1U headless system
<pie_> rqou, im listening
<azonenberg_work> that's basically ADC bolted to TCP offload engine
<azonenberg_work> with a little DSP to correct for AFE nonlinearities
<rqou> my UIs would contain a very extensive programming API
<pie_> azonenberg_work, shove everytihng on the computer screen, i agree
<azonenberg_work> then spits out voltages in (say) raw 16.16 fixed point
<rqou> hooked up to a browser engine and (in some cases) some native accelerated rendering logic
<azonenberg_work> With GPU accelerated rendering and protocol decodes
<rqou> then there would be a "default" GUI written with web tech
<azonenberg_work> clientside
<rqou> that the user can fully customize and change
<whitequark> ugh web tech
<azonenberg_work> Then a google protobuf stream in parallel with the bulk data stream for command and control
<whitequark> just use fucking qt
<rqou> it's the best cross-platform GUI toolkit by far
<rqou> but then i have to use qt
<azonenberg_work> For some definitions of "best" :p
<pie_> i mean rqou doesnt seem to disagree with azonenberg much beyond web/not web?
<whitequark> you can even deploy to wasm
<rqou> that's not the point
GuzTech has joined ##openfpga
<rqou> the whole point is to use the (as of the current state of the industry) most familiar and easiest-to-onboard toolkit
<rqou> which is html5
<whitequark> no it fucking isnt
<rqou> why not?
<whitequark> have you actually tried to write anything with "modern" html?
<whitequark> first you need to download a 2G node_modules
<pie_> i guess the key point is <rqou> that the user can fully customize and change
<rqou> no you don't
<rqou> you can do that if you want to
<whitequark> no that is how you do html today
<pie_> (well, plain old javascript, even jquery, is a thing)
<whitequark> how everyone does it
<whitequark> whos gonna onboard to you
<rqou> you can do that if you want
<whitequark> no, you are going to do that whether you want or not
<whitequark> if you want people to join
<rqou> it's not for people to "join"
<pie_> whats the intersection of people that use modern webshit and people that use oscilloscopes
<rqou> it's for "build your own GUI if you want, otherwise there is a default one"
<azonenberg_work> meanwhile i say use gtk for the chrome then opengl for everything interesting
<pie_> s/use/do/
<azonenberg_work> But the socket interface lets you bolt whatever you want onto it
<azonenberg_work> including automated scripts or something
<whitequark> azonenberg_work: gtk kinda sucks on... windows and macos
<whitequark> especially macos
<whitequark> you're better off using like wxwidgets
* pie_ attempts to write shitty GUI, derails channel
<rqou> the oscope GUI host isn't going to be just a browser anyways since you need to inject a native rendering path
<azonenberg_work> rqou: at which point you should just write the whole thing native
<azonenberg_work> like normal people who don't write mobile apps do
<rqou> uh, no
<azonenberg_work> (Soooo many mobile apps are just a browser plus some glue)
<rqou> because i don't want to write all the stupid bullshit to create a button on every platform
<whitequark> rqou: qt or wx
<whitequark> really
<azonenberg_work> rqou: thats why you use a gui library
<rqou> i'm not touching wx after seeing the disaster of it in kicad
<azonenberg_work> where you just create a Gtk::Button or something
<rqou> yeah, my "gui" library is called CEF
<whitequark> i am honestly amazed at how you consistently arrive at the shittiest solution
<whitequark> in everywhere
<whitequark> from circuits to guis
<pie_> rqou, write a prototype, see what happens?
<pie_> destroy industry? :D
<whitequark> like, you do worse is better elevated to a level of ideology
<rqou> worse is better in silly valley :P
<rqou> but i don't see how it's worse?
<rqou> it's just a different abstraction just like QT
<pie_> sometimes I just say "you may or may not be right but i still want to try it this way", may or may not be appropriate for you :P
<whitequark> rqou: it's an abstraction that is the worst way to make uis
<azonenberg_work> whitequark: rqou's design philosophy basically embodies everything i detest about silicon valley
<whitequark> azonenberg_work: precisely
<pie_> LOL
<azonenberg_work> the only exception is that he's not trying to secure VC funding with it
<GuzTech> I don't know the context exactly, but isn't it an option just to write some small prototypes with a few toolkits to see how they are?
<rqou> i mean, i can do that
<GuzTech> Unless you have experience with them all that is.
<rqou> although i've been down this road before
<rqou> and my choice would still be html5
<azonenberg_work> GuzTech: i've done web uis before
<azonenberg_work> years ago, when i didnt know better
<azonenberg_work> it was a terrible design mistake and one i never made again
<pie_> i mean i dont know, if I dont need to FUCK with modern webshit i might be inclined to do things rqous way
<GuzTech> Why is that?
<rqou> i actually have used both wx and qt
<rqou> didn't like either of them
<azonenberg_work> just a giant pain to work with compared to a modern ui library
<azonenberg_work> especially if you need to interface with native stuff
<whitequark> what azonenberg said
<whitequark> i ported solvespace to web and
<whitequark> it still doesnt work very well
<whitequark> because of the fucking dom element sizing
<whitequark> i'm probably going to just reimplement that in opengl
<GuzTech> Ok
<rqou> element sizing?
<pie_> another thing is theres no homogeniety, no canonical webshit frameworks? i mean i know react and the like are things, but those are more backend than frontend?
<whitequark> which is going to be a pain but like, predictable pain
<whitequark> rqou: canvas dom width/height need to match glviewport
<whitequark> and they fucking dont
<whitequark> and the events arent properly emitted
<whitequark> i spent days on that
<whitequark> still doesnt work
<whitequark> no idea why
<whitequark> piece of shit
<GuzTech> I haven't got that much experience with writing GUIs, so I'm trying to understand *what* particularly *sucks* about "webshit" and native GUIs.
<rqou> hmm, not familiar with this particular problem
<GuzTech> Interaction with native stuff = +1 for native toolkits.
<rqou> but the design i had in mind was that only buttons and other controls would be web tech
<pie_> GuzTech, from what ive gatherd so far, toolchain and library insanity, and performance, but thats all I got
<rqou> actual data rendering would use native code and just open a separate native window
<rqou> not controlled by the browser
<rqou> that just hosts a vk rendering context or whatever
<azonenberg_work> rqou: the multiple window workflow is also a terrible idea
<rqou> uh no?
<azonenberg_work> it's my single biggest complaint about gimp
<rqou> now i can put different things all over my monitors
<pie_> azonenberg_work, gimp is just fucked up in that regard though
<whitequark> rqou: it also isnt cross browser
<GuzTech> azonenberg_work, you know that GIMP has offered a single window mode for years now, don't you? :P
<whitequark> shit just works in different ways
<pie_> azonenberg_work, because you actively need the other two windows and I f****** need to bring it up every time i onen gimp or somerthing
<whitequark> for no real reason
<whitequark> i fucking hate web shit
<pie_> GuzTech, wait what
<whitequark> everyone promoting it needs to be lashed
<pie_> GuzTech, wtf, why does it still use multiwindow
<pie_> by default
<TD-Linux> rqou, what is webgl missing for what you want to do
<whitequark> the more i work with it the more i hate it
<rqou> gimp is actually something that can definitely benefit from the macos "all windows front" behavior
<GuzTech> pie_, I don't know, but it's easy to change.
<rqou> TD-Linux: give me WebVK :P
<azonenberg_work> pie_: o_O
<pie_> GuzTech, howww
<TD-Linux> but for what
<azonenberg_work> GuzTech: *
<azonenberg_work> wait, what
<azonenberg_work> it does
<azonenberg_work> how the heck did i not know about that
<TD-Linux> (it is happening btw)
<GuzTech> OMG
<GuzTech> You didn't know?!
<azonenberg_work> no
<azonenberg_work> it was infuriating me for years
<pie_> ^
<rqou> TD-Linux: i actually don't know; i need to actually spend some time to actually learn how to graphics
<GuzTech> Window menu -> Single-Window mode
<azonenberg_work> i assumed that this was just how gimp did things and i'd have to hate myself any time i used it
<pie_> i may have heard of this at one point and promptly forgot...
<GuzTech> You're welcome ;)
<azonenberg_work> yeah i discovered it per google in 30 sec after you mentioned it existed
<pie_> rqou, whats vk
<rqou> Vulkan
<pie_> oh
<TD-Linux> both webgl and vulkan especially are super low level, almost certainly something already exists that's higher level that better matches what you want
<whitequark> also webgl is fucking ancient
<whitequark> you dont get geometry shaders
<whitequark> it doesnt work consistently
<GuzTech> rqou, isn't imgui something you could use? https://github.com/ocornut/imgui
<TD-Linux> webgl is way more consistent than normal webgl
<TD-Linux> *opengl
<whitequark> TD-Linux: but not enough
<rqou> GuzTech: maybe? whitequark wasn't happy with how i18n/a11y-unfriendly it is
<pie_> GuzTech, man thats beautiful. f****** gimp
* GuzTech is baffled that people still don't know about single window GIMP O_o
<azonenberg_work> whitequark: what are geometry shaders and what are they good for?
<pie_> GuzTech, its always been multi window and noone said otherwise? :P
<whitequark> azonenberg_work: right now solvespace converts beziers to pwl
<azonenberg_work> GuzTech: apps dont normally start up in a totally braindead UI mode and suddenly go sane
<whitequark> azonenberg_work: this depends on display scale
<azonenberg_work> if you click the right button
<whitequark> azonenberg_work: this creates issues where eg circles are just polygons
<azonenberg_work> whitequark: keep in mind, i learned opengl 1.3
<azonenberg_work> and havent done serious graphic stuff in about a decade :p
<GuzTech> rqou, well I don't what i18n or ally is, so I can't comment on that :P
<rqou> internationalization/accessibility
<GuzTech> OpenGL 1.3 is aaaaanciiiiiieeeent :P
<azonenberg_work> Yes
<pie_> GuzTech, translation and accessibility i think
<GuzTech> Ah ok
<azonenberg_work> i use VBOs and stuff like that
<rqou> basically "can your gui render arabic/hindi/etc." and "can screen readers access your GUI"
<azonenberg_work> But i honestly dont see a use for shaders in the majority of the stuff i've done
<GuzTech> Wait, there were VBOs in 1.3?
<GuzTech> Wut?
<azonenberg_work> GL_ARB_vertex_buffer_object iirc
<azonenberg_work> it wasnt standard but a widely supported extension
<whitequark> azonenberg_work: so, forget everything you know about opengl
<TD-Linux> whitequark, have you been shilled pathfinder enough yet? it converts everything to quadratics
<GuzTech> I just know immediate mode and 4.x
<whitequark> opengl 3 is just a programmable simd pipeline that can output to pixels
<azonenberg_work> yeah i havent done any immediate mode stuff
<azonenberg_work> lately
<rqou> i'm still wishing for somebody to write a graphics tutorial that matches how i learn things
<azonenberg_work> that i know is obsolete
<rqou> i'll probably have to end up doing it myself
<azonenberg_work> But what i want to do is, shove a bunch of coordinates into a float[]
<azonenberg_work> and let the gpu make it look good
<azonenberg_work> without having to write a whole rendering engine for every app
<azonenberg_work> that's what the gpu is for :p
<whitequark> azonenberg_work: ok so open solvespace
<whitequark> draw a circle
<whitequark> zoom in
<GuzTech> context->MakeShitLookGooooood();
<whitequark> if i had geometry shaders i could just rasterize beziers on gpu
<azonenberg_work> whitequark: it would be nice if GL had a "emulate fixed function pipeline" shader
<azonenberg_work> that does all the lighting and texturing and stuff by default
<GuzTech> IIRC geometry shaders are a bit limited (fixed amount of primitives for the output).
<whitequark> azonenberg_work: jwz wrote it
<azonenberg_work> then you can swap it out with your own if you care
<TD-Linux> whitequark, cpu conversion is too slow?
<azonenberg_work> yeah but still its not standard, its something you have to ship with your app
<whitequark> GuzTech: yes but it is very easy to vary amount of primitives programmatically
<whitequark> TD-Linux: basically yes
<whitequark> regen can take seconds
<rqou> azonenberg_work: it would be nice if every GL tutorial that isn't old as shit explained how to draw more than one triangle :P
<TD-Linux> D:
<rqou> or to draw a triangle that actually changes over time
<TD-Linux> you don't draw triangles that change over time
<TD-Linux> you draw new triangles :)
<azonenberg_work> For my immediately planned use case however
<rqou> sure
<azonenberg_work> i can skip all of that
<azonenberg_work> because i will be drawing 2D polygons with either flat shading or a single texture
<rqou> but then somehow all the tutorial don't ever clearly explain "ok, so this is where you transfer the data to the GPU"
<azonenberg_work> minimal transformations, everything will be in screen space
<GuzTech> rqou, just update your model matrix and render again?
<pie_> i think this might be the fixed function pipeline thing https://github.com/mojocorp/ShaderGen
<rqou> GuzTech: lol, a triangle whose coordinates change, not just the model matrix
<GuzTech> oh :P
<rqou> basically all tutorials i found are of the form "set up a shitton of stuff by calling a million different functions. now render one triangle. and now do this every frame."
<rqou> and the triangle is basically always just hardcoded in the source code
<rqou> if not, then the tutorial goes on a huge tangent explaining how to parse .obj files
<rqou> and none of them seem to clearly explain "now how do i upload data to the GPU again?"
<GuzTech> Yeah ok, they don't explain when, where, and how you should update vertex data and upload to the GPU.
<GuzTech> In DirectX you can create buffers with certain parameters, which the driver then optimizes. One for static buffers, one for buffers you update a lot, etc.
<rqou> basically everybody who writes a "how to graphics" tutorial seems to do one of the following
<rqou> *) use immediate mode
<GuzTech> I'm pretty sure OpenGL/Vulkan has the same options.
<rqou> *) spend basically a ton of time explaining miscellaneous stuff (like how to open a .png or read a joystick)
<rqou> *) is just a linear algebra tutorial
<pie_> last i looked this was the best opengl resource i found https://learnopengl.com/
<rqou> *) is just an operating systems tutorial (basically all the Vulkan tutorials that spend all their time talking about how to do memory management)
<rqou> and everything that isn't an immediate mode tutorial seems to have a "draw the rest of the owl" problem
<GuzTech> Yeah but that's because of the level of low-level access you have with Vulkan, so you must do everything yourself.
<rqou> sure
<rqou> i know that
<rqou> but i don't need a tutorial explaining that part
<pie_> (IIRC)
<rqou> i need more explanations about what the vulkan APIs are doing and why they are designed a certain way
<azonenberg_work> well i cant use vulkan as a lot of debian infrastructure doesnt seem to support it yet
<azonenberg_work> so GL it is
<GuzTech> rqou, what do want to make anyway?
<rqou> worksforme?
<pie_> something I'd wish I'd found earlier lol https://learnopengl.com/In-Practice/Debugging
<azonenberg_work> rqou: there is no gtk support for vulkan in any shipping release
<rqou> gtk has nothing to do with vulkan?
<rqou> afaik
<azonenberg_work> if you want a vulkan scene drawn int a gtk application
<rqou> anyways my ideal tutorial (which is very unorthodox) would be something like
<azonenberg_work> you need the bridge code
<azonenberg_work> GTKGLDrawingArea
<azonenberg_work> there's no vulkan equivalent in the gtk version debian stable ships
<pie_> azonenberg_work, you can use nix (nixos) without actually using nixos for your system ;P
<azonenberg_work> And i am not going to force users to install 30 packages from source to use my tool
<azonenberg_work> because i dont want to do that myself to develop it :p
<pie_> oh
<pie_> right
<rqou> * use vfio-pci to steal access to an amd gpu directly into userspace
<pie_> users
<azonenberg_work> pie_: well more to the point
<azonenberg_work> it's my tool for my own use
<rqou> * use BONAIRE.rai (or POLARIS.rai if somebody can find it) and the foss driver to set up scanout and work queues
<azonenberg_work> If anyone else uses or not, isn't my oncern
<rqou> * demonstrates compiling shader code and uploading data to the gpu by manually poking ringbuffers
<rqou> * builds some abstractions on top of that
<azonenberg_work> But i dont want to mess with 30 different libraries to get the job done
<rqou> * explains how this gets developed into an api like vulkan
<azonenberg_work> i want to just get work done
<rqou> * then rewrites everything back in vulkan sanely
<rqou> azonenberg_work: i have no idea what bridge code you're talking about?
<rqou> anyways, dolphin and the various demos all work on my debian system
<azonenberg_work> rqou: the code that lets you render a GL/vulkan/directx/whatever scene
<azonenberg_work> inside a gtk window
<rqou> works for dolphin?
<rqou> oh it's not gtk nvm
<azonenberg_work> Exactly
<azonenberg_work> doing it in a raw X window is relatively straightforward
<rqou> oooooooh
<rqou> _that's_ what you mean
<rqou> yeah, i don't care about that
<azonenberg_work> but if you want a UI library for chrome outside of the GPU-handled area
<azonenberg_work> you need the two to play nice together
<rqou> no i don't?
<rqou> just open multiple window
<azonenberg_work> and not steal events from each other or fail to composite properly etc
<azonenberg_work> i meant in a single window
<rqou> i don't care about that either lol
<azonenberg_work> with a gtk popup menu on top of a gl scene
<azonenberg_work> etc
<azonenberg_work> I need that level of integration for my system
<azonenberg_work> i am not going to reimplement menus and toolbars and dialogs in GL
<azonenberg_work> I'm going to use GL for performance critical stuff then GTK for the rest
<rqou> yeah, my system doesn't care about any of that
<azonenberg_work> And context menus are kinda important
<azonenberg_work> rqou: so you're the kind of person we have to blame for gimp looking like it does by default? :p
<whitequark> azonenberg_work: but wayland
<rqou> still irrelevant :P
<azonenberg_work> a popup web browser sitting next to a gpu-accelerated rendering in a separate top-level window without any support for any kind of UI elements in it
<azonenberg_work> seems like a terrible idea :p
<azonenberg_work> whitequark: does wayland have network transparency yet?
<rqou> does wayland work on nvidia yet?
<azonenberg_work> (has anyone figured out a sane way to make modern gfx APIs do network transparency yet?)
<felix_> i only more or less scrolled over the fx3 conversation, but if you only need a data pipe with iirc 4 virtual channels, have a look at the ft601. much cheaper than the fx3 and iirc the fx3 had some signal integrity problems. never used the fx3 in a design though
<azonenberg_work> as in, i want to be able to push data from a server-side app over a high-latency WAN link to a clientside GPU
<whitequark> azonenberg_work: there's a preliminary spec for network transparency
<azonenberg_work> then whenever i move the mouse just update the transformation matrix and re-render clientside, efficiently
<azonenberg_work> with only a few bytes of network traffic
<whitequark> but why the fuck do you want a gui to have network transparency?
<pie_> you could probably just put the browser inside the main window
<whitequark> you have ethernet everywhere not usb like me
<pie_> with like a webkit widget or something
<whitequark> felix_: no
<azonenberg_work> whitequark: trivial scenario i encounter all the time: i'm logged into a server somewhere running some ultra expensive software (think commercial EDA tools, or automotive [redacted] software)
<whitequark> felix_: i need a proper cpu
<azonenberg_work> it has a gui
<whitequark> azonenberg_work: vnc?
<azonenberg_work> I am not allowed to copy the software off and install locally, it has to live on that box
<azonenberg_work> vnc pushes raw pixel data, even with compression it's slooow
<azonenberg_work> pushing vectors, or better yet deltas to vectors
<azonenberg_work> would be way better
<azonenberg_work> vnc is how school eda labs usually solve this
<azonenberg_work> But there are better options if people make opengl actually client-server again like it used to be
<rqou> $FANCY_SCHOOL usually used x tunneling
<TD-Linux> use a video compression codec
<rqou> or at least I did
<rqou> i think there might have been VNC as well
<TD-Linux> opengl ove a network will be awful
<azonenberg_work> TD-Linux: yes but you can get lossless rendering if you actually use the client's gpu
<azonenberg_work> TD-Linux: why?
<TD-Linux> texture upload
<whitequark> azonenberg_work: thats not how x tunneling works afaik
<TD-Linux> will be uncompressed
<azonenberg_work> TD-Linux: you push textures to the server once
<azonenberg_work> then just use them
<felix_> whitequark: ok. the cpu core in the ft601 is kinda undocumented
<TD-Linux> yeah no that falls apart except for the simplest of apps
<azonenberg_work> unless you are using wierd multipass rendering techniques in which case you're either hosed, or you do a gpu-to-gpu copy and never touch it clientside
<azonenberg_work> (Which is done already because pcie latency)
<TD-Linux> I mean, chromium already has a gpu process and ipc for it
<whitequark> felix_: i want an arm so i can run smoltcp on it
<azonenberg_work> TD-Linux: unless you are doing a massive game with a texture dataset that is too big to fit in ram at once
<TD-Linux> so you could just shove that over the network
<azonenberg_work> when would you do that?
<whitequark> azonenberg_work: i need multipass for solvespace
<whitequark> because of depth precision issues
<TD-Linux> really think you'd be better served by video compression tho
<azonenberg_work> whitequark: yes but do you read it back and do clientside processing?
<azonenberg_work> or do you just make a depth texture then refer to it by a handle
<azonenberg_work> and re-process stuff
<TD-Linux> t. video codec author
<whitequark> azonenberg_work: hrm
<azonenberg_work> most multipass techniques i've seen for specular reflections, etc
<azonenberg_work> keep the texture on the gpu
<whitequark> azonenberg_work: yeah i only do it in one direction
<azonenberg_work> as of a few years ago that was practically mandatory, glReadPixels is sloooow
<whitequark> i push tons of vertex data tho
<azonenberg_work> yeah as you change geometry
<rqou> oh yeah that's another thing i hate about all the "graphics" tutorials
<azonenberg_work> but if the app was designed for network transparency and/or performance
<azonenberg_work> you'd only push changed vertex data
<rqou> they never seem to explain stuff like when the GPU actually does things like rendering or transferring data
<azonenberg_work> Which shouldnt be too huge
<rqou> or how you know it's done
<TD-Linux> you just mentioned proprietary garbage apps
<TD-Linux> good luck
<whitequark> lol that too
<azonenberg_work> TD-Linux: well, given that such apps are *normally* used in such a workflow
<azonenberg_work> it seems like, if this kind of rendering existed
<azonenberg_work> support would be a critical feature that all their big customers were banging at the door demanding
<pie_> also the school vnc stuff is usually on slow VMs or whatever to begin with
<pie_> so no extra cpu for video compression i think? :P
<rqou> not at $FANCY_SCHOOL
<rqou> most of these apps were on nice workstations
<pie_> ah
<azonenberg_work> pie_: yes, my proposal is to keep the compute and app logic on the server
<azonenberg_work> and offload the rendering to the client
<rqou> they're even not in the normal shell access list so you have to know their hostnames explicitly
<TD-Linux> pie_, plus usually you have a core to spare at least. unless it's a potato vm
<rqou> to keep people from overloading them :P
<pie_> i forgot im not at $fancy_school lol
<pie_> i did sometihng once and it was a potato vm
<rqou> oh TD-Linux you work on video codecs?
<TD-Linux> yes
<TD-Linux> this is my current project https://github.com/xiph/rav1e
<rqou> can you explain to me why video codec people seem to love intellectual property wankery far more than actually making codecs?
<TD-Linux> can you expand on that?
<whitequark> rqou: theres some new really good codec
<whitequark> that doesnt have any ip wankery
<rqou> TD-Linux: mozilla refusing to support h.264 until some company donated some CYA code
<TD-Linux> yeah
<rqou> various people refusing to just borrow whatever backend VLC uses that just plays everything
<TD-Linux> tbh I wish we didn't support h.264 at all
<rqou> gstreamer-plugins-{bad|ugly|etc.}
<TD-Linux> h.264 requires a license fee
<TD-Linux> those don't pay it
<TD-Linux> they just don't get sued because there isn't much money in it
<rqou> vlc requiring their servers to be in the EU because licensing
<rqou> the list goes on and on
<TD-Linux> yeah that's why me and a bunch of people made AV1
<rqou> also, maybe because i just don't know enough about it, but imho "fourier-like transforms, heuristics, and entropy coding" just aren't that interesting no matter how many times you rehash it
<TD-Linux> I never said it has to be your thing :)
<rqou> oh yeah, and every now and then some big vendor invents a new codec like VP8 or whatever and then melts my laptop
<rqou> because somehow hardware decoding never works correctly with these
<pie_> if i need $special_compressing_soup should i ask video codec people
<TD-Linux> pie_, yes
<rqou> and then all the concern about not getting sued means users just lose
<TD-Linux> rqou, yeah that's why we are writing a better software av1 decoder https://code.videolan.org/videolan/dav1d
<rqou> seriously why isn't there a "EU mode" bit that just glues in vlc?
<pie_> because that one dude had a post on twitter about $fancy gameboy image compression or i dont even know what he was doing and i just dont understand how you would even approach that stuff
<TD-Linux> because software patents are legal in the EU
<rqou> but vlc thought they were ok?
<azonenberg_work> TD-Linux: and how likely is av1 to actually get used?
<TD-Linux> azonenberg_work, it's already on youtube
<azonenberg_work> by sources of content you want to play
<TD-Linux> netflix is also 100% behind it (though that's with drm)
<azonenberg_work> ok fine, but what about random digital cameras that shoot h264 onto the sd card?
<rqou> why isn't there a "ok i supply the vlc, just use it" mode?
<azonenberg_work> or cheap chinese ip cams
<azonenberg_work> :p
<pie_> moving goalposts?
<pie_> if you build it they will come?
<TD-Linux> rqou, there is. on linux it grabs libavcodec, same library vlc uses. for h.264
<azonenberg_work> i mean, why has a free codec not dominated already?
<pie_> (after everyone important is already using it? :P)
<pie_> ah.
<TD-Linux> azonenberg_work, h.264 was cheap enough
<azonenberg_work> yeah but industry is so cheap they invented a new ethernet standard for cars
<azonenberg_work> to remove one twisted pair from cat5
<rqou> honestly i'd be happy with the decoder actually properly working in hardware and not melting my laptop or stuttering
<azonenberg_work> because a few tens of feet of twisted pair is so expensive
<azonenberg_work> you'd think they would jump at the chance to not pay royalties for... anything
<pie_> lolmanagement?
<TD-Linux> yeah they did. we got av1 :)
<TD-Linux> (keep in mind that h.264 was like 10x cheaper than mpeg-2)
<rqou> TD-Linux: does it work on just youtube or will it also work in the long tail of *ahem* entertainment video sites?
<TD-Linux> rqou, it'll work on any website that supports it
<rqou> well somehow *ahem* entertainment video sites all seem to pick the shitty codecs
<TD-Linux> yeah that's because they have like 2 engineers
<TD-Linux> and it's not just picking bad codecs, they also use super low bitrates because it's "good enough"
<azonenberg_work> and they use a .swf player applet they found on some random web forum 15 years ago when they opened
<azonenberg_work> ?
<rqou> apple/mobile seems to have improved that situation a bit
<TD-Linux> here's a list of people that funded av1 development https://aomedia.org/membership/members/
<TD-Linux> so you can assume that at least those people will ship it
<rqou> oh wow
<rqou> no *ahem* entertainment sites though
<rqou> but i see all the big name media/silicon vendors
<rqou> so maybe they'll actually switch too
<rqou> wait, so how come this time was different?
<rqou> what happened to the MPEG-LA protection racket?
<rqou> and what happened to h.265 HEVC?
<TD-Linux> it fractured into a bunch of pools
<TD-Linux> a lot of companies that developed h.265 ended up paying fees than they got paid back
<rqou> so basically they lawyered themselves out of existence/relevance?
<rqou> that's amazing
<rqou> looooool
<rqou> wow, this is actually exiting for once
<azonenberg_work> TD-Linux: so are you saying that in a couple of years it's plausible that av1 will actually be dominant?
<azonenberg_work> i mean there will still be random mpeg-2 files floating around that nobody bothered to re-encode
<TD-Linux> probably h.264 will stick around for a long time
<TD-Linux> but I would expect it to displace everything else newer than h.264
<pie_> hmm so does av1 not suck
<pie_> :P
<TD-Linux> it will probably rapidly become dominant in # of views just because of youtube having so many
<pie_> ( pie_ always asking the best questions)
<TD-Linux> it's pretty good
<TD-Linux> ~20% better than H.264
<TD-Linux> er
<azonenberg_work> yeah i'm thinking dominant in terms of "most obscure webcams, streaming services, IP cams, gizmos with record capability, etc" will support it
<TD-Linux> ~20% better than H.265 generally
<TD-Linux> like 70% better than H.264
<pie_> is it currently usable?
<TD-Linux> you can make a fast encoder for AV1 that doesn't use all the features
<azonenberg_work> Define better
<azonenberg_work> smaller file size?
<azonenberg_work> faster?
<azonenberg_work> lower ram?
<TD-Linux> that's percent of file size for same quality
<azonenberg_work> lower gate count?
<TD-Linux> *reduction
<TD-Linux> so 30% of the file size of a same quality H.264 video
<TD-Linux> encoders are super flexible. the reference encoder is super slow
<TD-Linux> but you can also tradeoff quality for speed and make a very fast encoder
<pie_> would it be suitable for like...live webcam stuff?
<TD-Linux> ip cams etc already do this. the h.264 they output is way worse than what x264 produces
<TD-Linux> pie_, yeah, rav1e can already do live 480p
<rqou> anyways TD-Linux i applaud this effort
<rqou> finally some "AV stuff" that doesn't piss me off :P
<pie_> hmmmmm /me passes this off to $random_project
<TD-Linux> ecp5 is big enough that you could probably do a barebones fpga encoder
<TD-Linux> I did a fpga decoder for daala in 2014
<rqou> hmm does every decoder need to support all the features?
<TD-Linux> yes
<rqou> or will there also be "profiles?"
<rqou> wait, so no "profiles"?
<azonenberg_work> live 480p is tiiiny
<azonenberg_work> what about live 1080p60?
<TD-Linux> azonenberg_work, yeah we need more assembly :)
<TD-Linux> you can in theory do 1080p60, but the encoder isn't mature enough for that yet
<TD-Linux> it's missing lots of simd and stuff
<pie_> id be ok with 720p30 :P
<azonenberg_work> TD-Linux: so no live 1080p60 av1 on ip cams yet
<TD-Linux> and a bunch of approximations
<azonenberg_work> how gpu-acceleratable is the encoding?
<azonenberg_work> or fpga :p
<rqou> seriously TD-Linux how did you guys manage to remove basically every awful part of video codecs?
<TD-Linux> azonenberg_work, well probably those would use potato hw encoders
<pie_> and its in rust! :P
<azonenberg_work> rqou: that was my thought about displayport
<TD-Linux> pie_, yeah. still kind of a controversial decision :)
<azonenberg_work> given the alternatives of vga, dvi, and hdmi
<azonenberg_work> then vesa had to go and close the spec :'(
<rqou> DP is still bad because proprietary
<azonenberg_work> it wasnt up to 1.2
<pie_> TD-Linux, inb4 dont worry there will be c reimplementations lol
<azonenberg_work> it was fully open royalty free, spec downloadable as a pdf any time you wanted
<TD-Linux> I mean, it's already a reimplementation
<TD-Linux> the reference code and dav1d are c
<pie_> ah well :P
<rqou> not a .ipynb? :P
<pie_> lol
<TD-Linux> rav1e could still be translated to c if rust ends up not working out for some reason
<rqou> or better yet, a .xlsx as the reference implementation :P
<rqou> (apparently this is not unheard of for PLL configs)
<pie_> rqou, oh god [expletives]
<TD-Linux> rqou, apparently you've used stm32
<rqou> i have
<rqou> but i've never used their tools/HAL
<pie_> otoh maybe excel shouldnt get so much hate :P imagine where the world would be without it!x
<rqou> a .ipynb reference implementation would actually piss me off less than a .xlsx reference implementation
<TD-Linux> azonenberg_work, encoding/decoding is terrible for gpus because it is inherently serial
<TD-Linux> but it's pretty good on a fpga
<rqou> at least my heuristics are that anybody using jupyter at least kinda knows what they're doing
<azonenberg_work> TD-Linux: so there is global whole-frame stuff going on?
<azonenberg_work> my knowledge of compression is mostly from things like JPEG
<azonenberg_work> where you split the image up into chunks then fourier/cosine transform each chunk and entropy code the chunks
<azonenberg_work> so you can data-parallel across all the chunks
<TD-Linux> azonenberg_work, even for jpeg, the final entropy code step is serial
<azonenberg_work> yeah but the DCT would be parallelizable
<TD-Linux> but for video, there's more serial-ness. for example, you can predict from pixels to your up/left
<azonenberg_work> i dont know how well the gpu would work
<azonenberg_work> for the entropy coding
<TD-Linux> motion vectors are predicted from up/left motion vectors
<TD-Linux> etc
<azonenberg_work> it seems to me that you should be able to design an algorithm that lets you parallelize everything until the very end
<azonenberg_work> at which point you take the (variable length) bitstream from each chunk and concatenate
<TD-Linux> you could but you would throw away compression efficiency
<azonenberg_work> Side note, why do modern video codecs suck at frame-by-frame? or is that just vlc
<rqou> my gut feeling is that this will choke on memory-bandwidth-constrained systems
<azonenberg_work> if i am watching a high speed video of some interesting activity
<rqou> like potatocams
<TD-Linux> rqou, correct
<azonenberg_work> and i want to move one frame forward to see where the projectile went
<TD-Linux> extreme potatocams don't even predict from previous frames
<azonenberg_work> then back up to see wherei t was
<TD-Linux> encoders have the choice to not use features
<TD-Linux> azonenberg_work, you predict from previous frames
<TD-Linux> so you have to decode all frames up to the frame you want
<TD-Linux> vlc just seeks to the nearest keyframe and doesn't bother doing that
<azonenberg_work> TD-Linux: are there not keyframes every second or so that are encoded without deltas?
<TD-Linux> you can of course implement accurate seeking of you want.
<TD-Linux> azonenberg_work, yes there are.
<azonenberg_work> then you decode from the key frame out to where you are
<azonenberg_work> because my experience is that vlc is OK at advancing fames
<TD-Linux> yeah, vlc just doesn't do that (yet).
<TD-Linux> mpv does
<azonenberg_work> but suuuucks at backing up
<azonenberg_work> and often totally borks playback
<rqou> huh my experience was that vlc basically always just worked
<TD-Linux> also sometimes files are encoded wrong
<azonenberg_work> rqou: you havent done much high speed footage analysis then
<TD-Linux> like there are mkvs out there that don't mark keyframes
<rqou> unlike whatever GNOME's movie player is which basically never works
<azonenberg_work> TD-Linux: all i know is, the files played fine in real time
<rqou> no matter how many gstreamer-plugins-* you install
<azonenberg_work> but as soon as i started freeze-framing and seeking, it died a horrible death
<rqou> TD-Linux: wait, there are broken .mkvs?
<TD-Linux> there's broken *everything*
<rqou> i thought anybody using .mkv was a video snob and/or weeb who will definitely encode correct files
<TD-Linux> mkvs are super complex and underspecified
<rqou> :P
<TD-Linux> did you know you can put dvds into mkv?
<TD-Linux> *dvd menus
<rqou> what
<azonenberg_work> dvd *menus*?
<rqou> i guess that makes sense
<azonenberg_work> i know i've seen dvd rips in mkv
<TD-Linux> but yeah there's work at ietf for standardizing mkv
<TD-Linux> and the standard is getting cleaned up now
<rqou> afaict .mkv was basically designed for weebs
<azonenberg_work> but that was just the VIDEO_TS content
<azonenberg_work> and AUDIO_TS
<azonenberg_work> not the whole menu structure
<rqou> i know for sure it supports separate subtitle tracks (hence weebs)
Bike has quit [Quit: Lost terminal]
<rqou> oh yeah TD-Linux why are there twenty bajillion shitty windows apps for converting .mkvs into fruit-company-profile h.264 with hardsubs?
<TD-Linux> don't blame me :^)
<rqou> this operation shouldn't be this difficult :P
<TD-Linux> it requires reencodes
<TD-Linux> also .ass is an insane subtitle format
<rqou> oh yeah for a small window in time there were also a nice pile of shitty windows apps for converting .mkvs into Moonshell-profile mpeg-whateveritwas
<rqou> that was "fun"
<TD-Linux> oh yeah I remember moonshell
<TD-Linux> it was mpeg-1 ish
<rqou> also you couldn't recompile it and have it play at full speed
<rqou> because arm rvds was actually way faster than gcc at that point in time
<rqou> oh TD-Linux more random questions about legacy AV shit
<rqou> why is ripping a VCD so damn difficult?
<rqou> the de-facto procedure a decade ago required isobuster to work some magic on it
<rqou> i have no idea how it works nowadays
<azonenberg_work> Actually semi on topic
<azonenberg_work> 25 pre-diced dies, 5x5 mm, <100> silicon with 200nm thermal oxide on top
<azonenberg_work> Might be fun to use for homecmos stuff
<azonenberg_work> free prime shipping :D
<azonenberg_work> And of course the wafers are... prime grade
<azonenberg_work> once i get some high-vacuum gear set up i want to play with metal deposition some more
<TD-Linux> rqou, vcds use a special data track mode that uses less error correction than normal data dvds
<rqou> azonenberg_work: what is this intended for?
<TD-Linux> I think they might also use some of the cd sideband bits for seeking purposes
<rqou> brilliant /s
<azonenberg_work> rqou: the dies?
<rqou> yeah
<azonenberg_work> well, mti sells full wafers with thermal oxide coating
<azonenberg_work> But pre-diced is convenient for testing at small scale
<azonenberg_work> my plan was to test metal patterning
<azonenberg_work> i need a smooth, nonconductive substrate
<rqou> oh so these are actually wafers intended for microfabrication?
<azonenberg_work> Yes
<azonenberg_work> just pre-diced bare wafers
<rqou> why is this on amazon?
<azonenberg_work> so you get a gel pack with 25 blank dies
<azonenberg_work> Dont know, dont care :p
<azonenberg_work> it showed up recommended when i sent someone a link to a wafer carrier in another channel
<azonenberg_work> Also, you could use the oxide itself as a test subject for SF6 etching
<azonenberg_work> if/when i have time to build a RIE system
<rqou> wait, another channel?
<rqou> not ##fpga nor #homecmos?
<azonenberg_work> yeah
<pie_> rqou asking the right questions
<rqou> TD-Linux: can you explain to me the appeal of turning video codecs into image compression algorithms? (e.g. AVIF)
<TD-Linux> they are already image compression formats
<TD-Linux> the first frame is compressed as an image
<rqou> but jpeg is already so widespread
<TD-Linux> rqou, yeah mozilla is generally in opposition to new image formats
<TD-Linux> but jpeg doesn't support stuff like hdr images
<TD-Linux> and we really don't want heic
<rqou> ah ok
<TD-Linux> migen question
<rqou> there's openexr which is a nice trashfire with a bajillion unfixed security vulns
<TD-Linux> this doesn't work if p1 has subsignals: m.comb += m.p1.eq(plat.request("p1"))
<TD-Linux> rqou, openexr also doesn't have good compression
<rqou> lolwtf
<rqou> so TD-Linux, most cursed image format: .mat :P
<TD-Linux> but this works: m.comb += plat.request("p1").eq(m.p1)
<TD-Linux> what am I doing wrong
<pie_> rqou, so there was all the talk about HK but suddenly i'm quite intrigued by singapore
<rqou> yeah i've never been there
<rqou> bunnie lives in singapore
<pie_> oh
<rqou> SG has too many rules for me :P
<azonenberg_work> whitequark: oh so i just saw your tweet about reballing
<azonenberg_work> have you never assembled a board with a bga on it before?
<azonenberg_work> rqou: SG has too many rules
<azonenberg_work> and you live in CA???
<rqou> chewing gum isn't illegal here :P
<azonenberg_work> chewing, or littering with it?
* azonenberg_work has stepped in enough gum to be totally fine with a ban :p
<rqou> completely banned
<azonenberg_work> interesting
<pie_> huh
<azonenberg_work> meanwhile CA wont let you use full strength IPA to clean things
<azonenberg_work> you have to water it down
<rqou> meh, you can order it easily enough
<azonenberg_work> yes, it can be found
<azonenberg_work> but the point is its technically illegal
<azonenberg_work> too high VOC percentage
<rqou> i don't believe it's illegal for individuals to use?
<azonenberg_work> if my understanding is right bascially all pure organic solvents are
<pie_> it always trips me up that IPA is a beer
<TD-Linux> so I thought if you did Signal().x = Signal() that made it basically a Record
<TD-Linux> but it seems not?
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 252 seconds]
<pie_> you guys said you hate EDIF right?
<pie_> https://en.wikipedia.org/wiki/EDIF "The result was rather interesting. Hardly any software vendor wrote EDIF 2 0 0 output that did not have severe violations of syntax or semantics. The semantics were just loose enough that there might be several ways to describe the same data. This began to be known as "flavors" of EDIF. The vendor companies did not always feel it important to allocate many resources to EDIF products, even if they sold a
<pie_> large number of them."
<pie_> jesus, tl;dr, edif sucks because vendor locking
<pie_> lockin
<pie_> thoug hthats just for v2, havent finished the article yet
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has quit [Ping timeout: 252 seconds]
<pie_> ok so it looks like a historicl clusterf* of conflicting interests
<pie_> on the other hand I like s-expressions ;P
rohitksingh_work has quit [Ping timeout: 252 seconds]
rohitksingh_work has joined ##openfpga
<sensille> what is that , at the end of the line?
<TD-Linux> the if statement continues
<TD-Linux> the second parameter to If() is the body
rohitksingh_work has quit [Ping timeout: 245 seconds]
rohitksingh_work has joined ##openfpga
<sensille> i don't know python, but in C the comma would mean the compiler can ignore the condition before the comma
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 252 seconds]
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has quit [Ping timeout: 240 seconds]
<TD-Linux> it's neither c nor python, it's a migen ast :)
<sensille> oh, why did i think it's python? nevermind
<jn__> isn't migen a python module?
Bike has joined ##openfpga
<cr1901_modern> TD-Linux: Re: 136, the TLDR is "you shouldn't be manually assigning extra attributes to your signal p1"
<cr1901_modern> I'm writing up what the actual issue is right now
rohitksingh_work has quit [Read error: Connection reset by peer]
<keesj> Still looking at https://nl.mouser.com/ds/2/225/iCE40UltraLiteDataSheetDS1050-526997.pdf I can't find what current I am allowed to draw from a generic IO pin
<TD-Linux> I I think I might have killed my first ice40
<keesj> hmmm how?
<cr1901_modern> TD-Linux: Also you may wish to /join #m-labs
<s_frit> keesj: perhaps it's part of the LVCMOS standard?
<TD-Linux> keesj, reverse polarity by plugging in programmer backwards
<TD-Linux> in my defense it's 6am
<TD-Linux> oh wait no it
<TD-Linux> 's not dead yet
<sensille> interesting project, migen
<sensille> my only concern would be that in the end you still have to learn verilog with its intricacies
<TD-Linux> it werks
<TD-Linux> sensille, not only that but you have to constantly check the verilog to see if migen made the right thing
<sensille> so you have to know both very well to profit from it
<TD-Linux> I am a huge not-fan of its failure mode of just generating incorrect verilog
<keesj> I think I found it https://i.imgur.com/yAZKN6u.png (from iCE40 UltraPlus™ Family - Lattice Semiconductor)
<s_frit> so at 3.3v it can source or sink 8mA
<TD-Linux> btw would love comments on how I can make my migen better
genii has joined ##openfpga
<whitequark> azonenberg_work: nope! never done anything with bga before today
<whitequark> azonenberg_work: other then desoldering a few with hot air
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
<sensille> are there plans to support the lattice ecp chips with the icestorm chain?
<whitequark> sensille: no
<whitequark> icestorm is just for ice40
<whitequark> but, yosys and nextpnr will support ecp5
<s_frit> esden: just so you know, I'm responsible for icebreaker issue #15. probably github is the best place to communicate given our respective timezones.
<s_frit> sensille: i think there is some ovararching beyond-icestorm thing now anyway
<s_frit> sensille: https://symbiflow.github.io/
<s_frit> "Project IceStorm is a previous project that documented the iCE40 bit-stream format. It will become a part of SymbiFlow. SymbiFlow will support the old Yosys-ArachnePnr-IceStorm flow but will also add a Yosys-VPR-IceStorm flow."
<whitequark> that seems sort of outdated?
<whitequark> hm, not sure what the status of vpr is
<s_frit> i'm happy to be corrected
Bike has quit [Ping timeout: 256 seconds]
kem_ has joined ##openfpga
mithro has quit []
tristated has joined ##openfpga
mithro has joined ##openfpga
tristated is now known as etrig
<sensille> whitequark, s_frit: great, thanks
<sensille> oh, you also look into the artix-7
<awygle> keesj: it's 8mA, page 21 of the first datasheet you linked
<awygle> (well 8 at 3.3)
<awygle> pie_: i use a pen tablet sometimes for EDA stuff, that works well fo rme
<awygle> whitequark: awesome, glad the LDO protection worked
<pie_> awygle, hmm
<awygle> pie_: there's ultimately a huge difference between "iphone touchscreen designed for essentially toddlers" and "cintiq pen tablet designed for artists" (i don't have a cintiq i'm too cheap)
<pie_> awygle, makes sense, i dont either :P
<awygle> i've heard reports that the ipad pro is also quite good in this regard
<awygle> but idk anybody who has it in real life
<pie_> a friend might be giving me one of those tablets without a screen in it
<pie_> sounds....interesting to get used to
<awygle> pie_: i have this one https://www.monoprice.com/product?p_id=10594
<awygle> two keys to getting used to it. 1) put it in pen mode, not mouse mode 2) give your mouse to a friend to hide away from you for a week
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
emeb has quit [Ping timeout: 260 seconds]
emeb has joined ##openfpga
<pie_> heh
Bike has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
Miyu has joined ##openfpga
rohitksingh has joined ##openfpga
emeb has quit [Ping timeout: 245 seconds]
emeb has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
mumptai has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
mumptai has quit [Quit: Verlassend]
<cpresser> anyone knows where kicad has a symbol for a lan transformer?
<rqou> cpresser: ask azonenberg when he comes back?
<cpresser> i cant either find a symbol nor a footprint :/
<awygle> cpresser: in Transformer, there's a TG111-MSC13LF which is a single port gigabit ethernet transformer, according to my copy of kicad-symbols
<rqou> oh god even all the TVs here at $WORK are tuned to CNN
* emeb sends TV-B-Gones
<cpresser> awygle: thanks for the hint... i only need 100mbps, but i could use that symbol
<cpresser> or use it as start for a new symbol
<awygle> that's the only one i see
<cpresser> its shaving-the-yak-day
<awygle> every day is a winding road, my friend
<rqou> it's write-reports-because-🔥 day for me
<awygle> for me it is "fpga guys gave you a bitstream now deliver the software by tomorrow" day ^_^
<awygle> (which is fine because i saw this coming six months ago and laid a ton of groundwork)
Miyu has quit [Ping timeout: 252 seconds]
<tnt> Damn, the BE customs hard at work ... ~ 50 USD import tax/fees on a 38$ Tinyfgpa-BX :/
<awygle> daaamn
<qu1j0t3> that doesn't sound quite right...
<tnt> qu1j0t3: well just to start of, you have 30$ of 'processing fee' whatever the package value is.
<qu1j0t3> ugh
<qu1j0t3> brokerage fee
<qu1j0t3> right
<tnt> Then when they estimate the declared value is too low, they 'guess' their own value for the VAT/Duty. You can go to some lenghty procedure to contest if you feel like it ...
<qu1j0t3> i see
<tnt> I should have had it shipped to my hotel ... (just coming back from the US yesterday ...)
<kc8apf> returning to windows after two decades: powershell is a _huge_ improvement
<whitequark> indeed it is, i want powershell on linux
<whitequark> i mean it works sort of
<whitequark> it just doesnt have any commands
<kc8apf> I saw it was possible. Not sure I want to commit that hard
<kc8apf> I've been playing with Hyper-V and when I figured out there was a PS module for it, setup got so much easier
<sorear> curious what their estimate was
<whitequark> wow, this channel has *how many* people in it?!
<whitequark> wait, wrong channel
<cr1901_modern> A lot.
Maylay has quit [Ping timeout: 252 seconds]
Bike has quit [Ping timeout: 256 seconds]
Maylay has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
Bike has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
genii has quit [Remote host closed the connection]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Disconnected by services]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##openfpga
s_frit has quit [Remote host closed the connection]
ym has quit [Ping timeout: 260 seconds]
s_frit has joined ##openfpga
ym has joined ##openfpga
xdeller has joined ##openfpga
whitequark is now known as methylwhitequark
methylwhitequark is now known as whitequark
emeb has quit [Quit: Leaving.]