<awygle> oh i did a dumb. i was thinking single ended but i don't think you're supposed to be able to go that fast.
<azonenberg_work> You could i think
<azonenberg_work> Gimme a sec, datasheets are being slow to load bc slow LTE
<awygle> hm i can't actually find it
<awygle> except that DDR memory controller stuff is specced at 800 Mb/s
<awygle> i guess that's a decent approximation?
<azonenberg_work> So... MMCM can take in clocks up to 800 MHz
<azonenberg_work> So you should have no problem locking to a 625 MHz input clock
<awygle> sure
<azonenberg_work> 625 MHz is also a legal VCO frequency
<awygle> and you could just push it straight out, but it would no longer be source-synchronous
<azonenberg_work> So you can basically lock the VCO directly to your input clock
digshadow has joined ##openfpga
<azonenberg_work> So what you do then is, you divide the VCO clock down by say 4x or 5x
<azonenberg_work> Use an ISERDES to capture the input data and spit it out an OSERDES
<azonenberg_work> Then emit the 625 MHz clock through an ODDR
<azonenberg_work> That should give a pretty tight phase alignment from clock to output data
<azonenberg_work> 5:1 would give you a nice round 125 MHz fabric clock
<awygle> it seems like you'd get better phase alignment as well as preserve relative timing of start/stop stuff if you ran the 125 MHz clock through an OSERDES just like the data
<azonenberg_work> The ref clock is 625 though right?
<awygle> (assuming that's possible which it seems like it should be?)
<azonenberg_work> oh i almost forgot
<azonenberg_work> is the clock free running?
<awygle> sure, but the data has to do all the fabric routing. don't you want the clock to do basically the same thing?
<azonenberg_work> if not you're in for a world of hurt :p
<awygle> haha well, yes, there's that. i will fully control the clock so it will be whatever's easiest :p
<azonenberg_work> No, it doesn't matter because the 625 MHz output going to a BUFPLL
<azonenberg_work> will be used to clock the OSERDES
<azonenberg_work> on the high speed side
<azonenberg_work> And that same clock on the same IO clock network would also drive the ODDR
<azonenberg_work> If you wanted to get extra fun, you could have the PLL do a 2x multiplier and run the VCO at 1250 MHz
<azonenberg_work> nvm
<azonenberg_work> That won't work
<azonenberg_work> BUFIO max is 680 MHz
<azonenberg_work> So yeah you have to do the ODDR on the clock to generate the output
<azonenberg_work> The point is that skew on the 125 MHz domain doesn't matter, you can insert a couple of pipeline registers
<awygle> yeah okay, i see what you're saying. if you have a free-running clock that starts at some time T which is << than time T1 where the data starts, you're fine
<azonenberg_work> << by enough time for PLL lock
<azonenberg_work> yes
<awygle> PLL lock and "downstream wakes up and is ready to receive data"
<rqou> why is a non-free-running clock bad?
<awygle> well in azonenberg's model you'll end up with clock edges before data edges, and data edges with no clock edges
s1dev_ has quit [Ping timeout: 248 seconds]
<rqou> can't you "just" not update the feedback when the clock is stopped?
<awygle> and also you won't have a clock to clock with if there's any registers on the datapath
<rqou> right, there are definitely still those issues
<awygle> idk if you can do that with xilinx PLLs? it "should" work but we all know what "should" is worth
<awygle> and you'd probably start drifting
<awygle> perhaps significantly
<azonenberg_work> yeah xilinx's plls cant do that afaik
<awygle> lattice's can :p
<azonenberg_work> Basically thats the difference between a normal clock synthesis PLL
<azonenberg_work> and a CDR PLL
<azonenberg_work> CDR PLLs can handle missing edges
<azonenberg_work> also heading out, bak in a bit
<awygle> get you a pll that does both
azonenberg_work has quit [Ping timeout: 248 seconds]
azonenberg_work has joined ##openfpga
<azonenberg_work> awygle: back
digshadow has quit [Ping timeout: 244 seconds]
<rqou> question: why is everybody on birbsite upset about bitfi?
<jn__> rqou: because john mcafee claimed it to be "unhackable"
<rqou> lol ok
<jn__> and there's a bug bounty with very specific requirements
<jn__> (get a key from a stolen device without handing it back to the owner. but the key is derived from a passphrase or something like that)
<rqou> what i don't get is why everybody even gives a damn instead of "lol ok whatever"
<rqou> this is like the second weird cryptocurrency thing that birbsite got all crazy about
<jn__> people want to be entertained *shrug*
<awygle> people care about stuff
<awygle> it's often different stuff for different people
<awygle> azonenberg_work: wb
<awygle> i think my hypothetical scenario is basically solved though
digshadow has joined ##openfpga
<q3k> azonenberg_work: so you really don't want to use a zynq ultrascape+, yeah? :)
<azonenberg_work> q3k: for what?
<q3k> *ultrascale
<azonenberg_work> that seems like mass overkill on the CPU side
<azonenberg_work> i basically want an artix7 plus a cortex-m4 or so :p
<q3k> isn't this for your switch?
<azonenberg_work> yes
<azonenberg_work> This is for the management CLI
<q3k> a handful of arm cores isn't overkill
<azonenberg_work> it's not doing any packet processing
<azonenberg_work> It doesnt even have any connection to the fabric whatsoever
<q3k> well it makes sense to have _some_ cpu for _some_ proecssing
<q3k> it should imo
<azonenberg_work> Nope
<q3k> if you want proper openflow support, for instance
<azonenberg_work> By design, there is no software in the forwarding path
<q3k> for slow patch / flow programming
<q3k> *slow path
<azonenberg_work> And no slow path
<q3k> why not?
<q3k> let it handle icmp / mgmt / unknown flows (and program them accordingly after that)
<azonenberg_work> It goes against the entire design concept which is a bare minimum, high performance switch with the least frills possible
<azonenberg_work> no multicast, no 30 different weird protocols
<q3k> eh, so it's exactly the opposite of mine
<azonenberg_work> vlans, maybe some basic ACLs
<azonenberg_work> and full line rate on 24x 1G + 4x 10G ports with minimum latency
<azonenberg_work> targeting tens of ns port to port
<azonenberg_work> realistically the baseT will probably be higher than that
<azonenberg_work> but the 10G to 10G should be a few clocks port to port
<azonenberg_work> I'm also focusing on security
<q3k> what does that mean?
<azonenberg_work> the management network isnt bridged to the fabric at all
<azonenberg_work> the forwarding path and ACLs will be formally verified to prove packets can't be misrouted
<azonenberg_work> There won't be any CPU to get code exec on
<awygle> you can also swap in a gigabit fiber line card if your application demands (not yet designed)
<azonenberg_work> basically i want to prove that arbitrary data on the fabric ports cannot change system state in undesired ways
<q3k> i see
<q3k> i don't generally see a network as a security boundary, so this is even further from my needs
<q3k> i mean, formal verification sure, but not for security, just stability
<awygle> i'm curious what is a security boundary if not a network
<rqou> beyondcorp? :P
<awygle> in my cosmology it's like, the fundamental security boundary lol
<rqou> it's interesting how many university networks have always been "beyondcorp" from the start
<q3k> awygle: TLS
<rqou> they didn't have to spend decades rediscovering it
<q3k> awygle: making network your security boundary -> pwning on ebox is pwning the entire infrastructure
<q3k> awygle: i mean, defense in depth still applies
<q3k> awygle: but with random code running everywhere these days, the network boundary gets more and more permeated anyway
<awygle> hm, i guess that makes sense
<q3k> awygle: JS gets evaluated on browsers, your CI systems run code from npm/pypi, your servers host customer vms... someone _is_ getting CAP_NET or root on a physical box if they want
digshadow has quit [Ping timeout: 240 seconds]
<rqou> in other news today i learned about pakefiles and now I'm sad
<awygle> i was thinking of it as "the network is the boundary" and "TLS is a way to secure that boundary"
<q3k> SSRFs are super destructive now right because people made the assumption that the network is the boundary
<q3k> awygle: TLS client auth is super powerful
<jn__> rqou: what is that? yet another kind of build script?
<q3k> awygle: use it and run all your internal traffic over the internet (well don't, but you get my idea)
<q3k> (don't because you can't TE and manage it as well as your own network)
<rqou> jn__: yes, for a rather "not well engineered" language and ecosystem
<jn__> rqou: let me guess, p = PHP?
<q3k> >Pake is a PHP automation tool with capabilities similar to make.
<q3k> what the actual fuck
<q3k> seriously, just fucking learn to write GNU makefiles
<awygle> q3k: i'm still sort of confused, i think i would need a better understanding of what "we" are currently doing and what you think "we" should move to. but it's almost 6pm so maybe best not to start up :p
<q3k> awygle: yeah, i also don't wanna bikeshed this
<awygle> :) some other time maybe
<q3k> awygle: just do your thing with the switchamathing
<q3k> if we meet IRL we can have a bunch of beers or coffees or tea and discuss this
<awygle> i look forward to it
<azonenberg_work> Back
<awygle> azonenberg_work: you're too late, we've declared peace
<azonenberg_work> awygle: my goal is to keep the fabric from being pwned by compromise of one endpoint
<azonenberg_work> q3k: *
<azonenberg_work> For example it should be safe to plug an unfiltered upstream / DMZ connection into the same switch as an internal legacy cleartext-only service with no auth
<azonenberg_work> And have the switch guarantee they'll never see each others' packets
<q3k> >an internal legacy cleartext-only service
<q3k> to which i respond, stop fixing application issues at the network layer
<q3k> but we all know how real life works
<azonenberg_work> When i have a $5000 piece of hardware running a closed source binary blob
<azonenberg_work> that only speaks cleartext SCPI over TCP
<azonenberg_work> I'm going to use network segmentation, period
<q3k> i would just put a normal production machine next to it
<q3k> one leg into the shitty protocol
<q3k> run a grpc proxy on it that talks scpi
<azonenberg_work> So you mean, no layer 2 connection from it to the rest of the network?
<q3k> and a proper grpc production server on the other side, with tls and monitoring
<q3k> limit the shitiness of shitty devices to the poor proxy services that need to interact with them directly
<azonenberg_work> That adds latency to an already-too-slow link and also requires adding random computers to the rack
<awygle> wtf, does "git diff <branch>" show <branch> in _red_?!
<q3k> would a few ms really be that bad?
<q3k> i mean, i don't even know what you're running there
<azonenberg_work> q3k: this particular example is an oscilloscope
<azonenberg_work> So ms of latency with scripted test setups could add OOMs of slowdown
<awygle> fucking.... fuck you, git. just fuck you.
<azonenberg_work> awygle: there's args to disable coloring i think
<q3k> it only colours if it sees a TTY IIRC
<azonenberg_work> q3k: my next-gen oscilloscope will probably be cleartext as well for performance reasons
<awygle> azonenberg_work: it's not about the color, it's about "who is the + and who is the -" being 100% backwards from the intuitive in git EVERY time
<q3k> like any decent piece of software
<q3k> azonenberg_work: what are you going to be transmitting over that protocol?
* awygle rages out of all proportion
<pie__> awygle, inb4 ur doing ur args backwards
<q3k> awygle: seriously, tls is fast enough
<q3k> i mean azonenberg_work ^
<azonenberg_work> q3k: 40 Gbps TLS? I'll wait
<q3k> okay, samples
<q3k> but then you don't want to really switch that anyway
<azonenberg_work> I have to, because there may be multiple clients talking to it
<azonenberg_work> That's the whole point of having test equipment on the LAN
<q3k> you have such a different architectural approach to this than I would, I think
<azonenberg_work> There will be a slow google protobuf control plane link then raw fixed point samples
<q3k> do the clients need to receive the samples at low latency? can they not receive them batched?
<azonenberg_work> I see ethernet over a tightly segmented network as a good replacement for things like pcie
<azonenberg_work> its not just latency it's bandwidth
<azonenberg_work> I'm going to be rendering 50K WFM/s on the GPU
<azonenberg_work> of million point captures
<azonenberg_work> realtime eye diagrams, protocol decodes, etc
<q3k> again, my idea would be to have a dedicated machine that does all the line-of-fire work - fast protocol decoding, rendering, whatnot
<q3k> and have the clients talk to that over a DSL modem
<q3k> again, not sur ewhat your clients would do in this scenario
<azonenberg_work> This is for LAN applications
<azonenberg_work> the sample data will probably never leave the network boundary
<azonenberg_work> The point is, i dont want to have a dedicated airgapped switch and one that goes to the internet
<azonenberg_work> i want one switch and a provable rtl correctness check that shows internal packets can never be contaminated by internet data and vice versa
<q3k> fairly odd requirements indeed
<azonenberg_work> Your "dedicated machine" precludes my planned setup of 2-3 workstations around the house that all have a 40G pipe to the network core
<azonenberg_work> And can all run 40G to one of several different pieces of instrumentation at different times
<q3k> very, very odd
<q3k> well, fair enough, if there's more than one provider.
<azonenberg_work> if i ever get around to my radar project i'll have the controller be streaming raw baseband samples from the various phased-array antennas over 10/40GbE
<pie__> azonenberg_work singlehandedly replicates half of americas sigint infrastructure at home
<azonenberg_work> probably one fpga on each of the AESA tx/rx modules and one for aggregating/processing the data then ethernet from there to the PC
<q3k> but honestly, these are such different requirements between your normal internet ethernet and this ethernet that they're basically not the same network type anymore :P
<azonenberg_work> Lol
<azonenberg_work> This switch is tailor made to my application
<azonenberg_work> Its not meant to be general purpose
<azonenberg_work> basically i'm trying to merge pcie, usb, and lan into one ethernet fabric connecting all of my computers and test equipment
<azonenberg_work> that happens to also let one or two of the computers talk to the internet
<azonenberg_work> pie__: lol this wouldn't be sigint
<pie__> eh true i guess radar isnt really that
<pie__> also "your mom isnt made to be general purpose"
<pie__> im sorry, i couldnt resist
* pie__ runs off
<azonenberg_work> I'm talking a C-band AESA operating in the 5 GHz ISM or ham radio spectrum, probably a few tens to hundreds of mW per 4x4 or 8x8 elements
<azonenberg_work> see if i can get pings off of passing vehicles etc
<pie__> passive radar is cool
<azonenberg_work> this would be active
<azonenberg_work> with beamforming and everything
<pie__> lame :p
<azonenberg_work> Calibrating all of the elements to be sending with precise phase offsets from of each other will be fun
<pie__> (phased arrays are cool....)
<azonenberg_work> i'll probably do a prototype using ultrasound to start
<azonenberg_work> since much cheaper
<azonenberg_work> and easeir tolerances
<azonenberg_work> I might also try doing a passive sonar array, i live pretty close to a bay that has a marina in it
<zkms> azonenberg_work: how difficult is it to make that kind of radar with the phased array and everything
<azonenberg_work> So i could have a bunch of little buoys along a cable with mics dangling into the water and try to hear passing boats :p
<azonenberg_work> zkms: i think the hardest part would be the phasing
<azonenberg_work> for an AESA vs a passive phased array, you need to be able to generate the same waveform from many different antenna elements
<azonenberg_work> with extremely small phase offsets between them
<azonenberg_work> small, stable, and precisely controlled
<zkms> azonenberg_work: like what kind of parts are in tha tthing and how are they connected
<azonenberg_work> Basically each element is a baseband, transmitter, receiver, and antenna
<zkms> do you have an ADC/DAC + upconverter for each element or passive phase shifters of some kind
<azonenberg_work> That's the diff between an active and passive phased array
<azonenberg_work> separate adc/dac/upconverter for eahc element
<zkms> ok
<azonenberg_work> vs one adc/dac and a bunch of phase shifters and mixers
genii has quit [Remote host closed the connection]
<zkms> also what kind of waveform do you send
<azonenberg_work> Not sure, i need to do a lot more research - but phased arrays are cool :p
<azonenberg_work> i've done a bit of work with them in the audio spectrum
digshadow has joined ##openfpga
<azonenberg_work> Before i think about building a real radar i'm going to want to make an audio-band sonar with like an 8x8 grid of i2s codecs or something, and little itty bitty mics and speakers
<azonenberg_work> the elements can be much larger
<azonenberg_work> the timing tolerances are looser
<azonenberg_work> the parts cost less
<azonenberg_work> great way to prototype algorithms and make sure you understand the theory without making expensive mistakes :p
<azonenberg_work> Plus you'd get to do all kinds of cool stuff like beaming annoying beeps to your coworker's cubicle that nobody else can hear :D
<awygle> as long as we're bikeshedding, is anyone interested in bikeshedding a piece of linux networking code with me?
<jn__> awygle: userspace or kernel networking code?
<zkms> i know about stuff like FMCW but can you send more fancy stuff, like direct sequence spread-spectrum or ofdm signals to do radar things?
<awygle> jn__: the code is in userspace but i am calling syscalls not bypassing the network stack
<azonenberg_work> zkms: my initial plan was to do some kind of PRBS and then measure cross correlation from the return to the tx waveform
<azonenberg_work> peaks in the plot are echoes
<azonenberg_work> this should give decent code gain vs simpler techniques
<zkms> how do you avoid the receiver being overwhelmed by the transmit RF
<zkms> i never understood how that's done
<awygle> either frequency multiplexing or half-duplexing
<zkms> (besides "don't transmit on the same frequency" or "don't listen when transmitting")
<awygle> typically
<rqou> random question: anybody familiar enough with the hashcat codebase to be able to add a new hash algorithm?
<awygle> equally random question - does anybody know whether recv(buffer, 4, MSG_PEEK|MSG_TRUNC) in linux will copy the whole packet into userspace and then throw away everything after byte 4, or just copy the first 4 bytes?
<awygle> er pretend i passed a socket but w/e
<azonenberg_work> with TCP it grabs 4 packets and with UDP it throws away everything after 4
<azonenberg_work> i think
<azonenberg_work> been a while
<azonenberg_work> grabs 4 bytes*
<awygle> with PEEK it doesn't throw it away exactly, it's stilli n the kernel buffer
<awygle> i'm just not sure if it copies everything out or intelligently stops
<awygle> doesn't seem like anybody really uses it this way and trying to read the source hurt my head
<awygle> i guess i should be able to just check in gdb if i mock up a test case...
<awygle> oh and yes this is udp
azonenberg_work has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
futarisIRCcloud has joined ##openfpga
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
<azonenberg_work> anybody care to comment on my documentation?
<azonenberg_work> The logtools argument description will probably get moved to a separate page on the logtools wiki just so i dont have to repeat it for all of my projects
<rqou> azonenberg_work: i want docs of the network layer protocol
<rqou> otherwise that page itself looks like your usual manpage
<azonenberg_work> rqou: i dont want to document it because that will encourage people to implement it
<azonenberg_work> and it's going to get ripped out and replaced with protobufs as soon as i fix some more pressing issues
<azonenberg_work> The protobuf-based protocol will be documented thoroughly, as it's intended to be a stable network-level API
<rqou> seriously why are you+q3k obsessed with protobufs?
<azonenberg_work> Because they work? :p
<rqou> for some definition of work
s1dev has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
<rqou> damn i use sci-hub so much now that i'm not a student
<rqou> seriously we need more open access
<s1dev> <3 arixv
<azonenberg_work> publish in usenix journals
<s1dev> *arxiv
<azonenberg_work> or IACR, who is OK-ish - they paywall the final copies of papers usually but the preprints (everything before final editing) are on the public eprint server
<rqou> aaaaaargh one of the algorithms that all these fpga papers references is described in a patent
<rqou> gross :P
mkdir has joined ##openfpga
<mkdir> what are some cool fpga projects to work on\
<mkdir> ?
<rqou> help me do research for KinglerPAR? :P
<rqou> btw azonenberg_work: how would you feel if i created a subproject under KinglerPAR called SnivyPAR? :P :P
utanapischti has joined ##openfpga
<rqou> which will be where all the prototyping and making-sure-i-understood-the-paper testing will happen
<rqou> written in sneklang of course :P
<azonenberg_work> rqou: how old of a patent? :p
drawkula has quit [Ping timeout: 248 seconds]
<rqou> not old enough :P
<rqou> 1999
<rqou> either way i'm not going to bother reading it unless i have to
<rqou> i find reading patents to be extremely difficult
pie_ has quit [Ping timeout: 248 seconds]
<rqou> i'd rather read a not-necessarily-the-best-written academic paper
<rqou> at least those haven't been fucked up by the lawyers yet
<azonenberg_work> yeah lol
<rqou> oh btw azonenberg_work the name KinglerPAR is not at all related to my proposed ShinyKinglerPAR
<rqou> just so you know
<rqou> i just liked the name
<mkdir> rqou sure
<azonenberg_work> lol
utanapischti is now known as drawkula
<mkdir> Can you send me some starter info plox?
<rqou> uhhh
<rqou> mkdir: read every paper linked here? https://github.com/rqou/KinglerPAR/blob/master/notes.md
<rqou> hope you have a "fancy piece of paper" or at least don't mind academia :P
X-Scale has quit [Ping timeout: 240 seconds]
<mkdir> haha I don;t
<mkdir> 't
<mkdir> thanks, will read it and then post back thoughts
<mkdir> what's your typical schedule, incase I lose you.
<awygle> azonenberg_work: re: our earlier discussion, i forgot BUFR can just... divide the clock lol
<azonenberg_work> lol
<azonenberg_work> sb0 has a fun story about bugs regarding that iirc
<azonenberg_work> something about the divider state not being reset right, so if you have more than one of them, the dividers arent always in phase? i forget
<azonenberg_work> it doesnt affect most use cases from what i remember
<rqou> mkdir: united states pacific time
<rqou> mkdir: either on weekends, after normal work hours, or exactly at lunchtime :P
<awygle> i'm not sure how to get the high speed clock to go through though, if i were to try not to do a PLL at all
<rqou> how does sb0 hit ALL THE BUGS?
<awygle> because i have to (?) use BUFIO on the clock input for the SERDES, and that can't drive (potentially) across the chip to the 8 outputs
mkdir is now known as f003brv
<awygle> so i think i still need an MMCM or a PLL or something, somewhere
<rqou> azonenberg_work: do you know whatever happened to the PHASER RE?
<rqou> iirc lain was working on it?
* rqou pokes lain
<f003brv> Cool, rqou. I'm in Eastern Time, and normally night/weekends
<azonenberg_work> awygle: yes i would deserialize to a 125 MHz domain
<azonenberg_work> run that across the chip on a BUFG
<rqou> lain: also, what happened to the EM field solver?
<azonenberg_work> then use one or more PLLs to generate output clocks as needed
<azonenberg_work> And it depends on how many outputs you have in what banks etc
<azonenberg_work> but lol
<f003brv> btw just wanted to say I'm excited about this project. It looks cool so far.
<awygle> :)
<awygle> have you just discovered our little corner of the internet?
<awygle> azonenberg_work: actually, this could be DDR and run at like 300 instead of 600. dunno if that's actually easier tho?
<f003brv> I came here from ##electronics a couple months ago (as per a suggestion)
<f003brv> I only came a couple times but plan to be more active now :)
* awygle wonders why he's doing a work design at 11pm on a thursday
<azonenberg_work> Lol
<awygle> i should go to bed dlol
<awygle> f003brv: well re-welcome aboard then :)
<rqou> lol awygle
<azonenberg_work> DDR at 300 might be slow enough that you could run the 2-bit datapath in the fpga fabric directly
<rqou> yeah, don't forget that work-life balance where you get to pet your cats :P
<awygle> rqou: the world is too cool, okay?
<azonenberg_work> clocked off a BUFG
* awygle is actively petting one of the cats
* rqou jelly
<awygle> azonenberg_work: mm possible, perhaps. pushing it though. probably need to register it several times to make timing.
<awygle> which isn't the end of the world, but the i/o resources are ~free
<azonenberg_work> yeah and this is an fpga
<azonenberg_work> dff's are free :p
<f003brv> awygle: thanks
<rqou> azonenberg_work: opinions on stratix10? :P
<azonenberg_work> no experience / exposure to it
<azonenberg_work> cant comment
<rqou> DFFs _everywhere_
<rqou> ~every routing mux has a dff
<awygle> azonenberg_work: that's not _un_true lol. but aren't slices hooked up so i might eat entire slices for a single flip flop? idr
<azonenberg_work> Depends on how they are configured and how wide the bus is
<awygle> rqou: yeah actually "hyperflex" or whatever they call it would be perfect here, too bad i don't have a stratix
<azonenberg_work> awygle: Also if it makes you feel any better i'm sitting in my hotel room at 2300 on a thursday night, writing documentation on jtaghal per a request from $dayjob, while waiting for an rtl simulation for $sidegig to run
<azonenberg_work> and thinking about all of the sheetrock i have to hang :p
<rqou> ask your $WIFE to help? :P
<awygle> azonenberg_work: you're getting paid twice to do that though so my empathy is only at 50% :p
<f003brv> btw just to let you know some background, I am mostly a firmware engineer but have been recently delving into FPGA dev
<azonenberg_work> awygle: $dayjob is salaried
<awygle> i knowwwww it was a joke
<azonenberg_work> :p
<awygle> you're getting paid infinity percent more than i am to do this, how's that?
<azonenberg_work> Lol
<rqou> f003brv: in that case, a suggestion in a totally different direction
<awygle> pedantic nerds are pedantic :p
<azonenberg_work> Although, i certainly dont mind them paying me to work on my open source tools
<azonenberg_work> lol
<rqou> f003brv: can you investigate adding max v programming support to either diamondman's jtag library or azonenberg_work's jtag library
<f003brv> hmm sure
<rqou> or even just a standalone shove_bitfile_to_chip.py
<azonenberg_work> please use jtaghal
<azonenberg_work> dont invent some new library
<azonenberg_work> or a one-off thing that doesnt work anywhere else
<azonenberg_work> If you need features added to jtaghal to support it, i'll do it
<f003brv> kk
<azonenberg_work> And i'll accept PRs for new device support as long as they dont break anything existing
<f003brv> Will this still help me learn FPGA?
<rqou> er, not as much unfortunately
<awygle> oh boo some of these outgoing interfaces are spread over >1 bank. what a bummer.
<rqou> this is a pure "embedded-adjacent software glue" task
<f003brv> Kk, I can work on both. I need to get more familiar with KinglerPAR anyway - so i'll just ask questions on that
<openfpga-bot> [jtaghal-apps] azonenberg pushed 1 new commit to master: https://git.io/fNiTc
<openfpga-bot> jtaghal-apps/master c7769cb Andrew Zonenberg: Added lock, unlock, and program commands to jtagsh
<openfpga-bot> [jtaghal-cmake] azonenberg pushed 1 new commit to master: https://git.io/fNiTC
<openfpga-bot> jtaghal-cmake/master 184a56d Andrew Zonenberg: Updated submodules
<rqou> if you're feeling generous, completing the coolrunner2 support in jtaghal would also be useful
<f003brv> kk I'll see what I can do :)
<rqou> which... has some... issues depending on what exactly you want to do :P
<azonenberg_work> this is probably a good starting point
<f003brv> Alright, ty for the link
<azonenberg_work> So you'd want to create an AlteraDevice and AlteraMaxVDevice class, add the hooks to JtagDevice to create them based on the idcode
<azonenberg_work> then implement the necessary functions from the ProgrammableDevice interface to actually load the bitstream onto the device
<rqou> note that this may or may not have issues thanks to altera "reusing" IDCODEs
<f003brv> I should probably get some hardware too, right?
<rqou> oh shit
<rqou> remind me to go and properly open source that :P
<azonenberg_work> f003brv: that would help :p
<rqou> awygle: ^ plz periodically poke me to remind me to actually upstream my kicad footprints like i said i would do
<f003brv> lol
<awygle> rqou: will do :P
<prpplague> ho diddly ho ho, why does everything on altium feel like it was developed by someone with ADHD? i mean there are all kinds of features, but yet, they aren't complete... none of them are complete to the point where they are actually useful... they just look good on a feature list
<rqou> f003brv: in case it's not obvious, there's a ton of things going on
* prpplague grumbles at altium
<lain> rqou: been busy :P
<azonenberg_work> f003brv: https://github.com/azonenberg/jtaghal/blob/master/ProgrammableDevice.h?ts=4 is what you actually need to implement
<azonenberg_work> basically override the pure virtuals there
<azonenberg_work> plus a few in JtagDevice
<f003brv> rquo: yeah in fact I remember originally coming here to reverse the Anadigm FPAA
<f003brv> hopefully will get to that later
<rqou> azonenberg_work: btw, how well can you handle the altera user flash?
<awygle> prpplague: solidarity
<rqou> it's basically an extra block of 8192 bits that is freely usable by the fabric
<rqou> but you can program it via jtag (and readback?)
<rqou> lain: with what? cool other projects? :P
<awygle> lain: are you actually working on an em solver?
<rqou> at one point she was :P
<azonenberg_work> rqou: hmm, i'd have to think about how to fit that into the object model
<azonenberg_work> it might make sense to treat it as a separate ProgrammableDevice object
<azonenberg_work> that you can get from the AlteraMaxVDevice object via some method call
<azonenberg_work> That might make sense as a more generic interface to external flash, etc in general
<azonenberg_work> Create a new interface for "devices with one or more external memories attached"
<f003brv> azonenberg_work: what hardware should I get or do I need custom hw?
<azonenberg_work> which has methods to iterate over them and return a ProgramambleDevice for each
<f003brv> this header helps
<rqou> f003brv: unfortunately all of the hardware that i am working on are "bring your own board" and "bring your own programming algorithm"
<azonenberg_work> f003brv: libjtaghal currently supports digilent programmers (both integrated in devkits and standalone like the HS1) and FTDI dongles using either the Amontec Jtagkey or the Digilent HS1 pin configuration
<f003brv> header file*
<rqou> f003brv: i understand that this can be a bit of a problem :P :P
<rqou> the ice40 stuff is significantly more user friendly in this regard
<azonenberg_work> New FTDI dongle support is easy, a completely new API is a bit more work but is totally doable
<rqou> azonenberg_work: why don't you have the openocd ftdi layout clusterfuck? :P :P
<rqou> the one with a bajillion magic numbers
<f003brv> so a diligent programmer and FPGA?
<rqou> the problem is that none of the FPGAs we work on have good off-the-shelf breakout boards
<rqou> *we = me or azonenberg_work
<f003brv> Oh I see
<f003brv> hmm
<rqou> btw if you are interested in bitstream re, this may be useful: https://docs.google.com/presentation/d/1nxB72wN35QaxffoRXURNxRLLILIWX67rOxufaNNF2_o/edit?usp=sharing
<f003brv> which FPGA's are you working with?
<azonenberg_work> rqou: lol
<azonenberg_work> rqou: i plan to improve internal handling of ftdi layouts
<azonenberg_work> right now they're just magic strings but its better than magic numbers
<rqou> f003brv: there is the coolrunner2 cpld which is currently stuck due to bullshit reasons
<rqou> there's also the max v
<rqou> ice40 was done a while ago
<azonenberg_work> Also i note that right now i do not support turning output enables on/off, i always initialize to on and never got around to turning them off :p
<rqou> and other people have been working on artix7 and ecp5
<azonenberg_work> i also do not support TRST or SRST since the dongles i have mostly lack it
<awygle> there are a few other ice40s that could be added
<awygle> Ultra and UltraLight
<daveshah> There might be even more in the future
<rqou> max10/cyc10lp/cyc10gx are somewhere in the distant future
<azonenberg_work> f003brv: you can use the bus blaster with jtaghal using the jtagkey-compatible buffer
<awygle> ... dammit i'm sleeping. okay. goodnight.
<f003brv> gn awygle
<rqou> azonenberg_work: RCLK? :P
<azonenberg_work> also not suppoted yet
<azonenberg_work> in fact i never even implemented changing clock rates on adapters, there was never a need to
<azonenberg_work> i really should do that, it'd be a 20 minute patch
<azonenberg_work> all my work has been on device support instead lol
<azonenberg_work> f003brv: As far as end user docs for jtaghal, https://github.com/azonenberg/jtaghal-apps/wiki/jtagd is the cable server
<azonenberg_work> i just wrote that today
<azonenberg_work> the interactive CLI and command line batch tool are documented via source comments and --help only for the moment
<azonenberg_work> There is decent but not 100% doxygen coverage in the jtaghal library codebase
<azonenberg_work> but no overarching developer docs yet
<azonenberg_work> $work is asking me to improve those docs since they want to use the tools internally, so that will be improving over the coming days
<f003brv> kk cool
<f003brv> hmm
<f003brv> so a link to any hardware would be useful (if there are any readily available) so that I can make the purchase
<rqou> uh
<rqou> azonenberg_work: is your board open-source
<azonenberg_work> rqou: which board
<rqou> the xc2 crossbar
<azonenberg_work> kinda-sota
<azonenberg_work> it was public on my google code
<rqou> brilliant /s
<azonenberg_work> which i think is dead now
<azonenberg_work> I have a copy of it on my NAS that i could push to github
<rqou> f003brv: "please call again soon" while we sort it out :P
<azonenberg_work> But my NAS is in a box in the garage
<f003brv> kk
<f003brv> for now I can just read up
<f003brv> thanks guys
<rqou> if you want to play with ice40 in the meantime, you can buy either an icestick (1k luts) or the hx8k eval board (8k luts)
<azonenberg_work> f003brv: what fpga / jtag hardware do you have handy now?
<rqou> order of magnitude cost <USD$100
<rqou> or you can support tinyfpga and buy one of his things
<f003brv> atm only the Papillio pro
<rqou> tinyfpga: here's your chance to shill :P
<lain> rqou: eh, nothing exciting. trying to pay the bills :P
<azonenberg_work> f003brv: good news, spartan6 is fully supported in jtaghal as is the ftdi chipset
<f003brv> cool
<azonenberg_work> So you can bring up jtaghal and tinker with it on that board
<daveshah> f003brv: or you can buy something with an ice40 Ultra on it and improve icestorm
<azonenberg_work> You may have to add support for a new ftdi_layout
<f003brv> I will still need a programmer right?
<rqou> except s6 RE is currently a giant cursed clusterfuck too
<lain> awygle: mostly been reading up on it. I'm comfortable with EM now, but I have a lot of math to catch up on before I can start writing anything
<azonenberg_work> depending on if they use any pins besides tdi/tdo/tms/tck on the ftdi
<azonenberg_work> (if they dont use anything else, just do hs1 and it should work)
<kc8apf> rqou: ?
<azonenberg_work> f003brv: the papilio integrated programmer will work with jtaghal
<azonenberg_work> you cant use it to program anything else, but it'll be enough for you to get familiar with the library and codebase
<rqou> f003brv: oh yeah, if you don't mind working on a dead-end (not NRND yet, but clearly an architectural dead end) chip and if you like archaeology, you can do some S6 RE
<azonenberg_work> You can load bitstreams and talk to the BSCAN_SPARTAN6 primitive
<kc8apf> S6 feels very similar to xc7 at the bitstream and config frame level
<rqou> lain: wait, i always thought you were also a fancy academic type. i guess i mixed you up with somebody else :P
<f003brv> thanks azonenberg_work
<daveshah> The only problem with s6 is not being able to reuse xray as is because xray needs Vivado
<rqou> s6 has xdl which is good enough i think?
<azonenberg_work> kc8apf: it's a 16 bit bus vs 32 for almost any other xilinx parts
<f003brv> I don't know if it has a debugger though just micro usb to flash
<f003brv> or mini usb
<azonenberg_work> f003brv: the ftdi chip on the papilio should provide full jtag for the fpga
<kc8apf> If someone wants to play with s6, I'll happily get the low level tools working
<daveshah> rqou: yeah
<daveshah> I do similar with Trellis which uses ncl
<f003brv> rqou: what is S6 RE?
<rqou> yeah, s6 somehow just always failed to pick up sufficient momentum to actually get anywhere
<kc8apf> azonenberg_work: yup. Has much shorter frames too. Not a huge difference from xc7
<daveshah> Which afaik is a different text representation of the same database
<rqou> f003brv: reverse engineering the bitstream format for xilinx spartan 6
<azonenberg_work> f003brv: you'd want to use channel B on the FTDI
<rqou> if you've been around for way too long, you'll know that many many people have touched spartan 6
<f003brv> azonenberg_work: kk cool so I'm good on hw for now then
<azonenberg_work> Yeah
<rqou> but never managed to get enough momentum to sustain a community
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<f003brv> rqou: could be interesting, will it be useful?
<rqou> > not NRND yet, but clearly an architectural dead end
<azonenberg_work> The chips are largely dead-ended but still have a few redeeming features
<azonenberg_work> they cost less than 7 series for the lowest pin count parts
<f003brv> azonenberg_work: thanks, so want to reconfirm the task you wanted, was it the Max V or something else?
<azonenberg_work> They come in TQFP if you're a maschochist who likes to do 2 layer FPGA designs
<rqou> lol
<f003brv> ?
<azonenberg_work> And the static power is less than 7 series
<rqou> f003brv: so there's several different tasks we talked about here
<f003brv> Yes
<rqou> f003brv: task A: add max v to jtaghal
<f003brv> lol I should take notes
<rqou> task B: finish coolrunner2 for jtaghal
<daveshah> azonenberg_work: fairly certain ecp5 is cheaper than spartan6 these days
<rqou> task C: add the papillio ftdi layout to jtaghal (this task is significantly easier)
<rqou> task D: work on KinglerPAR
<azonenberg_work> rqou: it may be compatible with an existing layout i have
<azonenberg_work> i havent checked
<rqou> task E: reverse engineer the spartan 6 bitstream
<azonenberg_work> f003brv: To start, clone https://github.com/azonenberg/jtaghal-cmake and make sure it builds properly
<rqou> task F: unblock the bullshit problem with coolrunner2 support (this task depends on task B)
<azonenberg_work> Then try running jtagd, make sure it detects your papilio
<f003brv> thanks for that rqou: just wrote that down
<azonenberg_work> then try using jtagclient and/or jtagsh to load a bitstream onto the papilio
<rqou> i would recommend doing task C first because it is by far the easiest
<f003brv> azonenberg_work: kk
<azonenberg_work> if that works you at least have jtaghal running and set up
<azonenberg_work> Let me know any problems you have, they're probably documentation issues i need to fix
<azonenberg_work> Reaching this point may involve completing task C, depending on how the papilio's programmer is set up
<azonenberg_work> Patching FTDIJtagInterface to support new layouts is pretty trivial if needed
<azonenberg_work> Once you get to that point, spend a while getting familiar with the jtaghal codebase
<rqou> oh right, task F requires having some hardware that currently only three people in the world have
<azonenberg_work> Take notes on anything non-intuitive
<rqou> so that clearly has some issues :P
<azonenberg_work> let me know anything that you think needs documenting :p
<f003brv> will do
<f003brv> and I'll start with C
<f003brv> then maybe A?
<rqou> probably B?
<f003brv> do i need other hw for that?
<azonenberg_work> eh, the bitstream twiddling for coolrunner is nontrivial
<azonenberg_work> A is probably better
<rqou> A and B both probably should have hardware lol
<azonenberg_work> Yes, you'll definitely need to test
<rqou> A would be "greenfield" while B has "some issues"
<f003brv> well i'm just wondering if my papilio will work for those lol
<azonenberg_work> I think there is a header to use your papilio as a jtag programmer
<rqou> sorry, no
<azonenberg_work> But you'd need a coolrunner or maxv board
<rqou> unless you want to do E
<rqou> which can be incredibly hard btw
<f003brv> hmm okay then maybe I'll do D and E while I try to get my hands on other hardware
<f003brv> A B and F require hardware I don't have right?
<rqou> so i think your best bet is to do C, read papers, and yell at us to clean up our act with regards to hardware :P
<f003brv> haha kk
<rqou> because currently very few other people can test :P
<f003brv> it will be good to familiarize myself anyway
<rqou> if you want to actually work on E (spartan 6 RE) you should read my slide deck
<f003brv> which one?
<rqou> yeah
<azonenberg_work> Also read kc8apf's blog posts on the 7 series bitstream
<azonenberg_work> As well as the XilinxSpartan6Device source in jtaghal
<rqou> you probably should try to deeply understand this: http://www.clifford.at/icestorm/
<f003brv> also what does NRND mean ? :P
<rqou> not-recommended-for-new-designs
<azonenberg_work> s6 and 7 series have a lot of architectural similarities
<rqou> forrestv: you will also want this: https://github.com/Wolfgang-Spraul/fpgatools
<azonenberg_work> xilinx has not officially NRND'd spartan6 yet, but their latest toolchain (vivado) doesn't support it and only the older ISE toolchain does
<rqou> oops sorry f003brv: ^
<f003brv> I see
<rqou> f003brv: you will also want this: https://vjordan.info/log/fpga/
<f003brv> close enough
<rqou> this is the "archaeology" part i was talking about
<rqou> many people have poked at spartan 6 and only wrote down half the stuff :P
<f003brv> Ah I see
<rqou> if you're a masochist, you can try to curate our wiki :P :P
<azonenberg_work> anyway i'm gonna get some sleep
<f003brv> so rqou: should I try task E after task C? Or D if you need research on KinglerPar
<azonenberg_work> f003brv: i'll be on tomorrow
<rqou> doesn't really matter
<f003brv> azonenberg_work: kk I'll probably on in the evening
<f003brv> EST
<rqou> you'll probably need more than a day to read all of the resources we just dumped on you :P :P
<f003brv> kk will look at all these links and then figure it out
<f003brv> haha yeah
<rqou> meanwhile hopefully i will have gotten some stuff sorted out
<lain> rqou: academics is very not my thing :P
<f003brv> yeah
<rqou> f003brv: are you a hardware person at all?
<f003brv> yes
<f003brv> well
<rqou> can you assemble a BGA board? :P
<f003brv> so i'm doing my current research involves fpga, but mostly software side
<f003brv> probably not
<rqou> because neither azonenberg_work nor I am really in the business of actually making boards
<f003brv> don't even know what that it is lol
<rqou> so we can open-source all the instructions to build boards, but we really can't actually build them
<f003brv> what is a BGA board?
<rqou> ball grid array
<f003brv> do you guys have schematics?
<rqou> yes, we can do that
<rqou> but turning that into a physical object still involves quite a bit of work
<f003brv> you just need them to be physically built?
<f003brv> like soldered?
<rqou> yeah
<f003brv> hmm
<f003brv> I know hardware guys
<f003brv> I can ask them
<rqou> i don't have time to solder any more than i need for prototyping
<rqou> which is like 3 :P
<rqou> or fewer
<f003brv> yeah it takes a while
<rqou> tinyfpga: can i persuade you to just take over assembly for our devkits? :P
<rqou> f003brv: once we fix it they'll all be open-source and anybody can just build it
<f003brv> rqou, btw curious now is this just mostly hobby work
<f003brv> or do you guys make money and stuff
<rqou> so the question just becomes how much $$$ you are willing to exchange for getting the actual objects
<rqou> um...
<rqou> f003brv: you just opened a rather sensitive topic
<f003brv> haha
<rqou> some people do
<rqou> azonenberg_work and I both do not
<f003brv> I see
<f003brv> just wondering cause there seems to be a lot of time being spent
<rqou> let's just say that there's been a bunch of bullshit going on due to this that i am very not happy about
<rqou> f003brv: well, i was a student/funemployed until not too recently
<rqou> although whether that was actually good for free time or not is... questionable
<rqou> but i don't want to discuss the details of that
<f003brv> I see, yeah I was just wondering. I just like doing it for fun anyway.
<f003brv> I didn't realize you guys were so active
<f003brv> it's cool to see
<daveshah> wrt the sensitive topic
<f003brv> I wanna reverse FPAA at some point which is why I was actually recommended to visit this chan
<daveshah> There's a small startup, SymbioticEDA, that I and a few others work for
<daveshah> This develops Yosys among other things
<f003brv> hmm I see
<daveshah> We are also making a new multi architecure PnR, nextpnr
<daveshah> I am also working on ecp5 re, but mostly in my own time
<f003brv> Ah
digshadow has joined ##openfpga
<f003brv> well I'll be back again in a couple days
<f003brv> after I read all this material
<f003brv> it was fun talking and thanks for sharing daveshah
<f003brv> look forward to future conversations
<daveshah> have fun! the openfpga world is a neat little place
<f003brv> certainly looks that way. I'm sure I'll learn a lot
<rqou> and keep poking us to document more and sort out our shit :P
<f003brv> will do
<f003brv> you'll know once I start having questions :)
<f003brv> goodnight
f003brv has quit []
<rqou> awygle, balrog, other-usual-legal-bikeshedders: what licenses are now recommended for open hardware designs?
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<prpplague> rqou: hehe, that's like a three week discussion with various intermissions to consume beer and various drugs like LSD and shrooms
<rqou> fortunately, we've had this discussion before
<rqou> including fights about the value of intellectual property and copyleft
<rqou> so hopefully the discussion can be focused on only the actual differences between different choices
ondrej2 has quit [Quit: Leaving]
<rqou> in general hardware licenses kinda suck compared to the software ones
massi has joined ##openfpga
massi has quit [Remote host closed the connection]
massi has joined ##openfpga
massi has quit [Client Quit]
massi has joined ##openfpga
massi has quit [Client Quit]
massi has joined ##openfpga
massi has quit [Client Quit]
massi has joined ##openfpga
<s1dev> daveshah, so then you develop SymbiYosys?
<daveshah> s1dev: not personally, although that is one of the things SymbioticEDA does
<daveshah> I've ended up on the place-and-route side of things these days
<s1dev> nextpnr right? What is used for the cost function for the place and route?
<daveshah> right now it is HPWL weighted by (1+e^(-slack))
<daveshah> where slack is an estimate based on estimated path delay and an allocated budget to each timing arc
<daveshah> this might be tweaked a bit, I think right now there's not enough weighting on HPWL which affects routing success
<s1dev> how is HPWL defined?
<daveshah> it is basically abs(max_x - min_x) + abs(max_y - min_y) where max/min x and y are the bounding box of all connections of a net
<daveshah> ignore the abs of course, my confusion with something else. of course those values are always +ve
<s1dev> So it seems people have been moving to Steiner tree wire length?
<daveshah> Interesting
<daveshah> That mostly seems to be ASIC stuff. I'm not 100% sure how different the two problem domains are
<s1dev> it's my understanding that most of the P&R literature focuses on ASICs
s1dev has quit [Remote host closed the connection]
s1dev has joined ##openfpga
<daveshah> s1dev: interesting, thanks
<s1dev> seems the annealing placement approach is not used anymore
<gruetzkopf> not that i'd understand most of it, but *download*
<s1dev> I'm still reading through it but their v2 won some P&R competition last year
<s1dev> it's an interesting method which isn't at all what I expected the state of the art to be
s1dev has quit [Ping timeout: 260 seconds]
m_t has joined ##openfpga
pzuk has quit [Quit: leaving]
Adluc has quit [Excess Flood]
Adluc has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 264 seconds]
rohitksingh_work has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
<gnufan> 2014Gennaio
gnufan has left ##openfpga [##openfpga]
indy has quit [Remote host closed the connection]
indy has joined ##openfpga
X-Scale has joined ##openfpga
<felix_> rqou: on the PHASER blocks: reverse engineering those to write a fast and open ddr3 phy for the 7 series is on my todo list, but well, that list is long... when i get to a certain point in $commercialproject, i might need that there and can work on that. but that won't happen in the next 3 months
<felix_> oh, btw: i wonder if the stories of computers getting pwned at defcon or the hotels around are true
flaviusb has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
genii has joined ##openfpga
<q3k> felix_ | oh, btw: i wonder if the stories of computers getting pwned at defcon or the hotels around are true
<q3k> they're only true if you really fuck things up
<q3k> ie use unencrypted wifi to download upadtes in the clear from an unupdated winxp box
<q3k> nobody's wasting 0days on defcon public pwning (these days, at least)
<q3k> tl;dr don't be stupid, install security updates and you'll be fine
<felix_> ok
<q3k> the biggest danger really is skimmers on ATMs, but that's true for anywhere in vegas
<felix_> never had problems with that sort of stuff at ccc; but i've never been to defcon
<q3k> are you going? prepare for disappointment.
<felix_> so better get some money at an atm at the airport?
<q3k> yeah, or just tug on any suspicious parts of an atm
<felix_> yep, i'll be visiting the defcon. just to see if it's like people described. well and i'll be travelling with a friend, so it's gonna be fun
<q3k> i hope you like gambling and people acting like 15 year olds
<felix_> and afetr defcon spend a few days in the bay area
<felix_> uh oh...
<q3k> for me defcon is terrible: i don't enjoy gambling, i hate hotel conferences and i hate the atmosphere there (which is WHOO LET'S PARTY MAD SPLOITS YO)
<q3k> but maybe i've been hanging around with the wrong crowd
<felix_> but yeah, i'll see and if we don't like it there we'll definitely find something else to do in vegas ;P
<q3k> (went there for the DEFCON CTF)
azonenberg_work has quit [Ping timeout: 244 seconds]
<felix_> last conference where i wasn't sure if i should attend turned out to be much better than i expected
cr1901 has quit [Ping timeout: 268 seconds]
<q3k> yeah, i had that with RIPE76
<q3k> thought it would be boring internet provider architects in suits
<q3k> turned out it's basically CCC but with people who run ISPs
<felix_> heh, nice
<shapr> q3k: come to phreaknic :-P
<q3k> i'm honestly trying to limit my travel to the US
<q3k> although i haven't been to TN yet, so I guess that could excuse it
<shapr> q3k: ah, if you're out of country, PhreakNIC might not be worth it. But it is ~20 year old phreaker conference that is very much like it was twenty years ago
<shapr> with both good and bad points of that
azonenberg_work has joined ##openfpga
massi has quit [Quit: Leaving]
azonenberg_work has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
<openfpga-bot> [jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNiH5
<openfpga-bot> jtaghal/master a6519b0 Andrew Zonenberg: Removed old / vestigial indirect programming API. Added AttachedMemoryDevice API.
<azonenberg_work> felix_: i would love to have an open ddr3 phy for 7 series
<azonenberg_work> lain was interested in REing PHASER* too but i dont know if she got anywhere
<azonenberg_work> also jtaghal now has a better API for external memory devices attached to MCUs, FPGAs, etc
<felix_> yeah, when i'll get to that, i'll poke her; don't want to duplicate work
azonenberg_work has quit [Ping timeout: 248 seconds]
azonenberg_work has joined ##openfpga
<mithro> azonenberg_work: What is wrong with litedram? https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/s7ddrphy.py
<mithro> azonenberg_work: # 1:4, 1:2 frequency-ratio DDR2/DDR3 PHY for Xilinx's Series7
<azonenberg_work> mithro: not verilog? :p
<mithro> azonenberg_work: You can export it to verilog and treat it like a module if you want
<daveshah> it presumably doesn't use the PHASER stuff either?
<mithro> azonenberg_work: Most of Florent's clients don't know he uses migen/litex -- they just think he has a "really weird verilog encryption scheme" ;-)
<azonenberg_work> But i'll keep that in mind if i do a ddr* design down the road
<daveshah> although apparently it supports up to 1600MT/s
<azonenberg_work> Shorter term the only external memory i plan to use is QDR-II+
<daveshah> I am going to do an ECP5 port of litedram at some point, although maybe next year once my dev board is also done
<azonenberg_work> on a kintex7
<daveshah> need to do bitdocs for all the IOLOGIC and DQS stuff first
<daveshah> and proper multiclock in nextpnr
<mithro> daveshah: Send Florent a dev board and he'll probably do it for you ;-)
<daveshah> true
<mithro> azonenberg_work: Pretty sure that litedram works on the kintex 7
<azonenberg_work> Yes but QDR-II+ isn't DDR3
<daveshah> I was momentarily excited about litepcie also today
<azonenberg_work> It's a completely different PHY
<mithro> azonenberg_work: The good thing about litedram is that it supports DDR, LPDDR, DDR3, DDR3, etc
<daveshah> But it seems to use a lot of Xilinx IP
<daveshah> so no ecp5 port of litepcie without much more work
<azonenberg_work> simple dual port synchronous SRAM
<azonenberg_work> No refreshes
<daveshah> yeah, much easier to start from scratch with that
<azonenberg_work> One read or write transaction per clock
<azonenberg_work> issued*
<azonenberg_work> 4 word long burst on the fast clock
<mithro> daveshah: I know that _florent_ was doing something with litepcie and some Lattice part...
<azonenberg_work> so one cycle you issue read addr then write
<azonenberg_work> the next
<daveshah> Have wanted to play with QDR SRAM for doing crazy realtime video stuff where DDR isn't good enough
<daveshah> back when I was playing with FPGA AR stuff it would have been very handy
<azonenberg_work> my use cases is packet buffering, ACLs, etc for my switch
<mithro> Wasn't there that group which which was claiming a full open source pcie core?
<azonenberg_work> daveshah: yeah xilinx has a hard pcie ip in a lot of their chips
<mithro> I think it was these people -> https://xtrx.io/
<mithro> Can't find any reference to it however... :-/
<felix_> mithro: litedram doesn't use the phaser modules and the artix7 only have idelay and not odelay, so it only works in some configurations
<mithro> felix_: So, improve it? :-P
<felix_> in sydney we tried to get litedram run on the ac701 with a sodimm and it dodn't work
<felix_> well, it needs another phy implementation using the PHASER blocks
<mithro> felix_: Sounds good to me!
<felix_> and that's basically the plan i stated above
<felix_> i probably also need to rewrite parts of the memory controller above the physical layer, but that will mostly be performance optimizations
<felix_> but first my current commercial consulting/engineering project and photonSDI ;)
<openfpga-bot> [jtaghal] azonenberg pushed 2 new commits to master: https://git.io/fNiNU
<openfpga-bot> jtaghal/master dc18b2c Andrew Zonenberg: Refactoring: Renamed ARMDebugPort files to ARMJtagDebugPort in preparation for future SWD support
<openfpga-bot> jtaghal/master eea5ae8 Andrew Zonenberg: Refactoring: Moved a lot of ARMDebugPort stuff into new ARMJtagDebugPort class in preparation for eventual SWD-DP support
<openfpga-bot> [jtaghal-apps] azonenberg pushed 1 new commit to master: https://git.io/fNiNY
<openfpga-bot> jtaghal-apps/master 3ca8fef Andrew Zonenberg: Temporarily disabled legacy indirect program support, needs to be replaced with AttachedMemoryDevice API
<felix_> well and i'm currently also doing a bit more coreboot mainteinance again
azonenberg_work has quit [Ping timeout: 256 seconds]
m_t has quit [Quit: Leaving]
<awygle> artix7 has odelay on hp ports I think?
<awygle> but maybe HR is required for dram, idk
<felix_> artix7 only has hr io, not hp
<awygle> lain: curious whether you find some fault with e.g. OpenEMS or just want to make a solver because it's cool and fun
<felix_> only hp have odelay
<awygle> huh that's weird, because the Zynqs with artix fabric have HP banks
<felix_> from the drawings in the patent the PHASER stuff looked rather sane
<felix_> huh? o_O
<awygle> huh or not
<felix_> ds190 says that the zynq with a7 fabric only have high range io
<awygle> wtf
<felix_> hr == high range; hp == high performance
* awygle needs to check some schematics again...
<awygle> yeah I know, I have some kind of confusion about what a certain project is actually using. or my fpga guys do. either is bad.
<felix_> uh oh. good that we talked about that ;P
<awygle> yup haha
<felix_> speaking of reviews: would be nice if someone could have a look at the schematics of this project i did maybe 2 weeks ago https://github.com/felixheld/AXIOM-photonSDI-hw
<felix_> i poked rohit, but he seems to be quite busy at the moment and i don't want to annoy people too much
azonenberg_work has joined ##openfpga
cr1901 has joined ##openfpga
Miyu has joined ##openfpga
<awygle> update - i was the confused one, unsurprisingly
<azonenberg_work> Can somebody double check some PCB design rules for me?
<azonenberg_work> PCB design rules: 0.125mm min trace/space
<azonenberg_work> 0.254mm min drill / 0.1mm annular ring (so 0.454 mm minimum finished via size)
<azonenberg_work> aka, oshpark minimum 4 layer boards
<azonenberg_work> Target device is an 0.8mm pitch TFBGA with 0.4mm diameter ball pads in the recommended footprint
<azonenberg_work> My math says, 0.8mm pitch means diagonal ball pitch is 0.8*sqrt2 or 1.131 mm
<azonenberg_work> Subtract half a pad diameter either way is 1.131 - 2*0.2mm = 0.731 mm clear between balls
<azonenberg_work> Subtract 125 um on either side for clearance gives 0.481 mm
<azonenberg_work> Slightly larger than the 0.454mm minimum via size
<azonenberg_work> So it baaarely fits
<azonenberg_work> as far as routing more stuff out, your vias are 0.454mm diameter on 0.8mm centers. So you have 0.346 mm clear between vias, subtracting 0.125mm for clearance gives 0.096 mm or barely not enough space for a trace
<azonenberg_work> But you can get that first ring of vias to work
<azonenberg_work> And you can route out the outer 2 rings of balls on the top layer, which means the outer 3 rings are useable in total
<azonenberg_work> For a TFBGA100 package, this means rows A/B/C and H/J/K plus cols 1/2/3 and 8/9/10 are fully routable
<azonenberg_work> D4-D8, E4-E8, F4-F8, G4-G8 can only be broken out to inner layer power/ground planes
<awygle> which will be swiss cheese
<azonenberg_work> Lol, yes
<awygle> but yes, that matches my math
digshadow has quit [Ping timeout: 265 seconds]
<awygle> i didn't realize osh supported 0.454mm diameter vias though
<awygle> isn't it 10/20 mil?
<awygle> which is .508mm?
<azonenberg_work> No
<azonenberg_work> 10 mil drill, 4 mil ring
<awygle> ah, 10/18
<awygle> yeah that can be (barely) made to work
* awygle checks dirtypcbs
<awygle> 6/6 trace, 12mil dril, no annular ring spec. coolcoolcool.
<azonenberg_work> no ring spec means they dont care enough to tell you :p
<azonenberg_work> yeah oshpark has pretty nice design rules for 4L
<awygle> they have a 2mil tolerance
<azonenberg_work> Anyway... That means the STM32F76xxx TFBGA100 is useable on oshpark PCBs with the loss of pins PE0, PD7, PD4, PC4, PB2, PE10, PE14
<azonenberg_work> then assuming BYPASS_REG, POR_ON, and BOOT0 are hard wired to adjacent power/ground pads
<azonenberg_work> And you can probably free up ~4 of those 7 lost I/Os by having N/S/E/W quadrant dogboning
<azonenberg_work> at the expense of worse power plane integrity
<awygle> the HX8K 121-ball for glasgow loses one more row
<awygle> i think the interior is mostly power though
<awygle> and we have tons more pins than needed
<awygle> so hopefully fine
<awygle> we might have to find a better 4l fab than dirty though
<azonenberg_work> This seems totally doable
<azonenberg_work> You can fan Vss at E4 out into the west quadrant, Vdd at F5 south
<azonenberg_work> have a pair of 0201 decoupling cap between E4/F4 and E5/F5 vias
<azonenberg_work> now the question is, do those lost GPIOs do anything i cant afford to lose?
rohitksingh has joined ##openfpga
rohitksingh1 has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
<awygle> JLPCB claims 3.5 mil trace/space
<awygle> *JLCPCB
<awygle> that's _insane_ for the cost they're listing
<daveshah> holy crap
<daveshah> their 6 layer boards are really cheap too
<daveshah> shame they don't have 8 layers on their quote system (thinking that would be nice for planned ecp5 board)
<awygle> they don't even do 8 according to their capabilities page
<awygle> what are you getting greedy for? 6L is enough for anybody :p
<daveshah> with 3.5 mil t/s it probably is
<awygle> yeah for real lol
<azonenberg_work> lol
<azonenberg_work> Just ran the pinout for stm32f76xx ethernet
<azonenberg_work> MII is not fully balled out in TFBGA100 but RMII is
<awygle> i have to dig up some old designs that i shelved for lack of a cheap fab with tight tolerances
<awygle> and re-do the math
<azonenberg_work> I do need access to pin G4 which is on the red-blocked area but if I put a via in the G4-G5-H4-H5 space
<azonenberg_work> I can access it i think
<awygle> 3.5 mil is 89 microns? wow
<azonenberg_work> dogbone to the southeast then trace between PB2/PE7 then south
<azonenberg_work> So basically it is dopable
<azonenberg_work> The full 4 wire JTAG is pinned out too, not just SWD
<awygle> need a cheap fab with microvias...
<azonenberg_work> ...
<azonenberg_work> the stm32f7 tfbga100 doesnt seem to exist
<awygle> loool
<azonenberg_work> i cant fine it anywhere, not even st's website
<azonenberg_work> wtf
<azonenberg_work> find*
<azonenberg_work> Sooo let's see, TFBGA216 - how much of THAT can i fan out? :p
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh1 has quit [Ping timeout: 264 seconds]
<azonenberg_work> Looks like I lose about 31 gpios
<azonenberg_work> But i can use full RMII and JTAG (the only things i really need)
<whitequark> awygle: I got 50 microns on my DIY PCB litho process
<whitequark> well, on the litho part, that is
<whitequark> never could etch worth shit
<whitequark> dont think you can even etch 50 microns on a 1/2 oz copper because of undercutting
<whitequark> you have to do plating
<whitequark> hm
<whitequark> hang on
<whitequark> how do fabs plate?
digshadow has joined ##openfpga
<whitequark> do they do negative litho instead of positive, plate the conductors slightly higher while the entire thing is connected, remove resist, etch everything so that the thin non-plate areas etch to the substrate faster?
<azonenberg_work> That is my understanding, yes
<azonenberg_work> So as long as you have a high aspect ratio on your resist you can get nice vertical sidewalls
<rqou> azonenberg_work i need dev docs, not user docs
<azonenberg_work> rqou: those are next on the list
<azonenberg_work> it's coming, dont worry
<rqou> specifically, the problem i was having was that the semantics of your intelligent buffering were unclear
<rqou> as well as the persistently-bikeshedded API issues of "what belongs to what layer"
Ellied has quit [Ping timeout: 256 seconds]
Ellied has joined ##openfpga
<rqou> awygle, balrog: want to bikeshed about open hardware licenses?
<balrog> rqou: do you need input/information on it?
<balrog> I don't like wasting time
<rqou> given that i want to release the project chibi test board design files under a permissive non-copyleft license, which one(s) do people currently prefer?
<rqou> i used to see CC everywhere, but now people seem to occasionally use other choices
<rqou> CC also never felt like the best fit in the first place
<rqou> so e.g. i while back i think i saw some people promoting the cern ohl license, but that's a copyleft license
<whitequark> CC0/0BSD :P
<rqou> what if i want attribution still?
<azonenberg_work> CC-BY?
<rqou> yeah, that was what i traditionally would have chosen
<daveshah> I'd be tempted to take ISC and s/software/hardware design/
<azonenberg_work> Or 3-clause BSD
<azonenberg_work> Which is kinda my go-to for software licensing these days
<rqou> why do we still have specialized hardware/software licences?
<rqou> this makes less and less sense over time
<daveshah> Yeah, particularly for fpga stuff
<daveshah> This is more of a problem with copyleft though
<daveshah> How do you define linking for hardware/gateware for example
<rqou> and occasionally people throw more wrenches into the problem with patent retaliation clauses
<rqou> oratroll creating copyrightable APIs is also excellent /s
<whitequark> daveshah: well, you might require the copyleft PCB to be placed in a subassembly
<whitequark> that can be replaced by the end user
<whitequark> mimicking LGPL
<rqou> that's stupid
<rqou> this kind of antic is why I'm not a huge fan of copyleft (as applied in reality)
<daveshah> Yeah
<daveshah> with fpga tools it also creates problems for people that want to deeply embed (potentially even statically linked embedded systems)
<daveshah> I doubt abc would have been as successful as it is without being permissive
<rqou> iirc a while back some project was investigating using maskrom/otp parts just to get around issues with gplv3 anti-tivoization
m_t has joined ##openfpga
<awygle> rqou: for permissive non-copyleft w/ attribution, CC-BY or Solderpad are the ones i'm aware of for hardware
<awygle> non-copyleft is pretty easy for sw and hw to share, it's the copyleft stuff that's tough, so if you want to 3-clause BSD it nobody will be too angry (except you should also use Apache because patents)
<awygle> i still have Opinions about licenses but i think it's basically too late lol
<awygle> (sorry, i forgot about this question from last night when i went through backlog)
<awygle> whitequark: awesome. what was your litho process? laser printer on transparencies?
<awygle> sounds like positive transparency based on above which surprises me
<awygle> err positive resist
<awygle> err i guess that's not surprising. never mind.
* awygle .exe takes a few minutes to warm up its caches
<whitequark> awygle: no, negative resist
pie_ has joined ##openfpga
genii has quit [Remote host closed the connection]
<azonenberg_work> rqou: https://i.imgur.com/S1PAnQI.png
<cyrozap> whitequark/rqou/daveshah: PCBs can't be copyrighted. PCB _designs_ certainly can be, but the copyright license for a design can't be used to exert control over the physical object the design has been embedded in. So you can have copyleft hardware designs, but not copyleft physical objects.
<cyrozap> I feel like I posted some links in here on this topic a while back...
<rqou> yeah, I'm aware of that
<rqou> azonenberg_work: eeeeeewwww
<azonenberg_work> lol
<azonenberg_work> anyway i'm slowly working on building up good doxygen for jtaghal
<azonenberg_work> awygle: thoughts on that class structure btw?
<azonenberg_work> it seems pretty sane to me :p
* shapr becomes the proletariat, breaks the class structure
<shapr> but honestly, simpler than most class hierarchies I've seen
<q3k> mithro | Has anyone tried https://github.com/ianlancetaylor/libbacktrace ? │····························································································
<q3k> (whoops, mispaste of second line)
<q3k> mithro: no, but tell me if it's any good :)
<q3k> mithro: i was looking to integrate something like that into release builds of nextpnr
<azonenberg_work> shapr: basically i'm making a bunch of interfaces for various types of device then inheriting from them as needed depending on attributes of the specific device in question
<shapr> azonenberg_work: everytime I thing I see a problem in that class hierarchy, I see that it's not a problem
<shapr> s/thing/think
<shapr> yeah, it looks nice
<azonenberg_work> at some point i need to add a BoundaryScanDevice class
<azonenberg_work> Since right now i don't support bscan whatsoever
<shapr> I had a bit of confusion when I thought JtagFPGA inherited from ProgrammableLogicDevice
<azonenberg_work> That's blocked on a good f/oss BSDL reader since i don't want to hard code BSDL data
<mithro> q3k: I think you should do it :-P
<azonenberg_work> i'm fine with coding up programming algorithms, how to flash chips, etc but having a giant db of scan chain IOBs seems silly
<q3k> mithro: also integrate it with the currently very mediocre (to put it lightly) qt error handling we have
<q3k> bleh, c++ exceptions. i just want StatusOr dammit
* shapr looks up BSDL parsing
<azonenberg_work> it's a strict subset of VHDL
<q3k> haha you're fucked
<openfpga-bot> [jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNPBy
<openfpga-bot> jtaghal/master 68b7060 Andrew Zonenberg: Documentation cleanup: now have a Doxygen brief description for all classes, plus a Doxyfile for generating documentation
<azonenberg_work> q3k: what about https://github.com/stass/libsegfault
<q3k> azonenberg_work: i have no opinions yet
<q3k> i'll check it out too
<azonenberg_work> no experience with it
<azonenberg_work> but i know of it
<q3k> although wait
<q3k> that's like handrolled C
<awygle> yes, someone please parse bsdl
<q3k> ah no, libunwind
<awygle> azonenberg_work: this... is not how i would have built this, probably
<q3k> i might have to just writing something myself that bases off of libunwind for the actual stacktrace generation
<q3k> because of the weird qt thread situation we have
<q3k> and the weird qt async callback model
<q3k> so just doing it by looking onto SIGSEGV is eh
<q3k> probably not going to be the nicest UX
<q3k> (i'd like to have a qt error box if the gui crashes, a text stacktrace where not in gui mode)
<cyrozap> Ah, I didn't post the links in here, but in #talos-workstation: "Javier Serrano's paper on using the GPL for HDL (https://www.ohwr.org/documents/341) and Andrew Katz's analysis of the CERN OHL and TAPR OHL (http://www.ifosslr.org/ifosslr/article/view/69/131)"
<shapr> azonenberg_work: but you want something in C++ I'd guess?
<awygle> shapr: write it in rust with a c api kthx
<shapr> awygle: you know me :-P
<cyrozap> Also, parsing BSDL isn't so bad--it's basically just an object notation format. Most of the "interesting" info ends up serialized in concatenated strings.
<shapr> gonna be Haskell
<awygle> shapr: write it in haskell with a rust api kthx
<shapr> haha, I can do that
<awygle> can you even do a C API in haskell?
<awygle> cuz i'd be fine with that
<shapr> sure yeah
<cyrozap> I'm actually writing a BSDL parser in Rust now, while I'm learning Rust :P
<shapr> it's easy enough to call Haskell code from C: https://github.com/shapr/usehaskellfromc
<awygle> cyrozap: oo yay! is it public?
<azonenberg_work> shapr: If I get a C/C++ API
<rqou> anyways azonenberg_work my opinion is "way too many classes"
<shapr> and I just found a VHDL -> LLVM compiler in Haskell - https://github.com/ghdl/ghdl
<rqou> but then again i strongly dislike inheritance
<azonenberg_work> and you can make it a nice simple package that i can install without futzing around with 30 different compielrs
<azonenberg_work> I'll take it
<awygle> my opinion is "too much inheritance, not enough proper layering"
<azonenberg_work> Bonus points if you can get it to ship with a debian package :p
<shapr> debian 9?
pie_ has quit [Remote host closed the connection]
<awygle> ghdl is in ada
pie__ has joined ##openfpga
<rqou> azonenberg_work: eeeeeeeewwwwwww again
<cyrozap> awygle: No, but there's not really enough to be made public at this point :P
<azonenberg_work> shapr: yeah
<azonenberg_work> awygle: I'm working on improving the object model
<azonenberg_work> there have been recent changes already
<shapr> awygle: oh right, wrong thing
<cyrozap> I'm mostly just playing around with Nom
<rqou> why would you _willingly_ try and make a debian package?
<awygle> cyrozap: arright well consider me subscribed to notifications
<azonenberg_work> rqou: in a few year i would love to be able to apt-get install jtaghal and get something useable
<azonenberg_work> years*
* awygle continues to respect anyone who can get nom to do something useful
* azonenberg_work noms on lunch
<shapr> rqou: because most people don't use nixOS yet?
<rqou> i wouldn't bother
<rqou> i would just say "unpack this .tar.xz, it goes into /opt"
<awygle> you two have different priorities. idk why you keep being surprised by this.
<shapr> I wonder if clash has VHDL parsing... would seem sensible.
<rqou> I've just repeatedly had "not particularly positive" interactions with debian developers
<awygle> clash has a vhdl backend, but idk if it has a frontend
<shapr> yeah, finding out
* awygle ponders badgering someone into parsing IBIS as well
buhman has quit [Quit: WeeChat 1.9.1]
<awygle> lmao the "golden" parser for IBIS has a bug tracker where one of the severities is "ANNOYING"
* shapr grins
<rqou> azonenberg_work: have you actually interacted with debian devs? idk if your experience matches mine
* awygle tags half the codebase
* q3k calls it a friday and starts on the cocktails
<awygle> oooooo... tempting
<awygle> you're at least three hours into the future though....
<sorear> ooh more future people?
<shapr> it's after 6pm here
<shapr> I'm still trying to understand this Go code
<q3k> 6pm is a perfectly cromulent time to start on drinks
<q3k> i would've started earlier, but only now i've picked up my creme de violette order from the local liquor store
<shapr> sorear: They have monomorphic Maybe types in this Go code https://github.com/StefanKopieczek/gossip/blob/master/base/headers.go
<rqou> meanwhile here i am wrangling a spreadsheet
<awygle> i am fighting a build system and writing a blog post
<shapr> I should write a blog post or three :-|
<q3k> same
<q3k> awygle: i was fighting bazel all day today
<q3k> awygle: i just want to deploy python like i deploy go dammit
<shapr> I've done an unreasonable amount of reading on EDGE vs graph reduction for alternate CPU approaches the past few days.
<awygle> yeah i have four drafts of things that are Arguably My Business and now i'm writing a fifth post which is Definitively Not My Business
<shapr> q3k: you're lucky enough to use bazel? I'm jealous.
pie_ has joined ##openfpga
<q3k> shapr: well i forced it
<q3k> shapr: now i reap the effects of that
<awygle> is bazel good? i've heard mixed reviews
<q3k> uh
<awygle> like... _really_ mixed lol
<q3k> when it works it's great
<shapr> depends on what you're doing?
<q3k> when it doesn't work it's annoying as fuck
<q3k> it works great when you have a monorepo and go/c++/java code
<q3k> when not it kinda sucks
<rqou> <troll> try splash </troll>
<q3k> i really like the idea, and i really miss the internal google implementation of it
<q3k> and now that cached builds and remote workers are in the floss version then it's even cooler
<shapr> one of my friends who used to work at IOHK said they use bazel+nix, he was able to deploy changes to production fifteen minutes after getting his company laptop. They use a mix of Scala, Java, and C++
<q3k> but yeah, it's very, very experimental
<shapr> oh, Haskell too
<q3k> i'm aiming for the same, but currently my CD sucks ass
<q3k> it's handcrafter terraform+aws
<q3k> with ansible for code deployment
<q3k> and yeah, uh, not happy with it
<q3k> it was the safe way to do it and it just sucks
<shapr> I switched to our cloud team stuff, it took me three weeks to be able to get 95% of the code to build
<rqou> i still stand by "the fuckit build.sh build system" or make
<q3k> rqou: build is easy
<q3k> rqou: deployment is hard
<q3k> rqou: for good deployment you need to store and identify builds in a smart matter
pie__ has quit [Ping timeout: 240 seconds]
<q3k> rqou: to store builds you need a good CI/CD
<shapr> one of our architects decided we need to use dpdk, so now build/deploy/testing is WAY harder than it ever was before.
<q3k> rqou: for a good CI/CD it really helps to have a smart and fast buildsystem
<rqou> lol i just use git push to deploy (my blog)
<q3k> rqou: right, but when your blog goes down for 5 minutes you don't loose monoey
<awygle> rqou solves the deployment problem by not deploying anything
<q3k> *money
<awygle> see above re: debian packages
<q3k> rqou: in cases that you do it's really nice to be able to have progresive rollouts (ie canarying) and near instant rollbacks
<rqou> how is that "not deploying anything"?
<rqou> i just dislike the debian ecosystem
<shapr> I wish we had canaries.
<rqou> q3k: i handle that with a complicated mess of symlinks
<shapr> I wish we weren't using microservices, or at least, not in the way that we're using them.
<rqou> you can revert by ssh-ing into the server and repointing the symlink at the "-old" directory :P
<shapr> rqou: what's your preferred ecosystem?
<shapr> nix?
<q3k> rqou: right, how are you going to prevent an automation system colliding with an engineer?
<rqou> at this point, musl+static linking
<q3k> rqou: this stops working the moment where there's more than one actor modifying this
<rqou> q3k: lol I don't since I'm the only admin :P
<rqou> yeah, it doesn't scale
<shapr> complicated mess of symlinks is what both the pro- and anti- nix people say
<q3k> rqou: right, so when you have easy requirements then the result is reasy
<q3k> shapr: i run nix on my laptop, i reaaaally wanna try it on production at some point
<rqou> i mean, i understand why google has the tooling that they have
<q3k> shapr: but it's scary without investing a ton of time into learning the codebase first
<shapr> all my friends at Haskell companies use nix in production, layer3 here in Atlanta does
<rqou> a lot of people copying google seem to be overengineering though
<shapr> their devs love nix, but their ops guys often hate it.
<awygle> nix feels like git
<shapr> awygle: I think, yes
<q3k> rqou: of course
<shapr> like it's the assembly language of version/dependency management?
<q3k> rqou: the reason is that when it works it's really fucking fantastic
<q3k> rqou: i really miss how well the internal google infra worked
<awygle> in that it's an excellent idea executed with flagrant disregard for UX or operational requirements of anyone but the author
<q3k> rqou: there were hairy parts, but tons of things just worked and were handled for you
<shapr> awygle: well ... have you read the original PhD thesis?
<awygle> shapr: for nix? no
<awygle> didn't realize it was a thesis topic
<awygle> (frankly doesn't seem academic enough lol)
<q3k> rqou: distributed storage, locking, job scheduling, work queues, logging, big data storage, authentication, rpc, ...
<q3k> rqou: it was heaven for a developer that just wanted to run a microservice somewhere
<shapr> awygle: the dutch cuts out on the third page :-P
<sorear> i'd like to get all of the people who say that about nix together and try to figure out the design space
<shapr> spraak u nederlands?
<sorear> me? no
<shapr> anyway, I think you'll have a much better grasp of nix after reading the thesis
<awygle> sorear: say the thing i said? because i would go to that party
<shapr> me too
<awygle> (q3k can bring the drinks)
<sorear> awygle: i've got a few people in various other channels who have said very similar things
<shapr> I'd fly to Seattle and buy drinks to be at that party.
<shapr> sorear: which human languages do you speak?
<q3k> so
<q3k> whoops.
<awygle> this is how all good stories start
<q3k> sorear: i mean, my main current problem with nix is that the code that's written is just undocumented at a high level.
<sorear> shapr: english and really, really bad spanish
<q3k> sorear: there's no real good intro how to dive into any of the nixpkgs or nixos code
<shapr> I'm amused that nix was originally written in Haskell, ported to C++, and is now being ported back to Haskell by some people.
<q3k> sorear: it's just very simple tutorials 'here's a basic derivation, draw the rest of the fucking owl'
<shapr> hahahaha
<shapr> q3k++
<q3k> sorear: nix pills are really close to what i want, but too literary and stretched out
<whitequark> my main complaint with nix is it can't handle dynamic libraries.
<whitequark> well, it "can", it has this awful kludge they have for opengl because you can't not handle opengl
<q3k> yeah, but these things i can understand/handle/research myself
<awygle> whitequark: do you have a Take on Rust not having a stable ABI?
<q3k> and it's just unix, i know this
<whitequark> awygle: it has
<whitequark> it's called C ABI
<rqou> half-serious: glvnd-rpc when?
<awygle> doesn't count
<whitequark> well, if you want to have a stable ABI at Rust crate boundaries, you'd have to make a forward-compatible serialization of the language IR
<whitequark> because that's what you need to specialize generics from other crates
<awygle> right
<whitequark> that all but precludes further language evolution
<awygle> i get why they don't have one
<sorear> you'd also need to change the language in various ways to allow the crate designer to specify what is and isn't ABI
<q3k> i like that ABI stability is currently a non-goal for rust
<sorear> this is currently largely implicit in #[export]
<sorear> er, #[inline]
<q3k> it's very acceptable and it makes things so much easier for language evolution
<awygle> hm
<awygle> i see both sides of it
<whitequark> you don't even have ABI stability for C++
<whitequark> (on MSVC)
<awygle> but i read that "versioning in rust" post aturon just wrote and it really bothered me, and i think the lack of an abi is basically why
<whitequark> or for that matter, ABI stability for C++ with libstdc++
<sorear> how are you defining ABI stability here
<whitequark> since libstdc++ broke their ABI recently and it utterly fucked the entire ecosystem
<awygle> "can build" and "can use" are currently == and i want them to be >=
<sorear> is libc++ better
<whitequark> no idea
<whitequark> which post?
<q3k> whitequark: oh, the thing with c++11?
<whitequark> q3k: yeah
<q3k> yeah, fuck that
<q3k> updating my gentoo boxen over that abi change was hell
<sorear> i don't see why it would be impossible in principle for libstdc++ to have a stable ABI
<sorear> and we do have a forward-compatible serialization of the C++ IR, it's called source code?
<whitequark> sorear: uh
<whitequark> in that case, just ship the source for your Rust crates
<rqou> wait, there was an abi break?
<whitequark> yes
<awygle> i'm increasingly realizing that rust is stable in all the places i wouldn't make a language stable and unstable in all the places i would make a language stable
<rqou> guess i didn't notice
<whitequark> I *think* most of it was std::string
<q3k> yes
<awygle> that doesnt' make it wrong of course, they're all way more experienced with these problems than i am
mIKEjONE1 is now known as mIKEjONES
<whitequark> which in c++11 has specific requirements that the storage returned by c_str and data should be the same and end with \0
<sorear> whitequark: then I guess I don't understand what you mean by "dynamic library"
<rqou> wait, is this related to the thing where gcc didn't support like one part of c++11 for like years?
<q3k> In the GCC 5.1 release libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. These changes were necessary to conform to the 2011 C++ standard which forbids Copy-On-Write strings and requires lists to keep track of their size.
<whitequark> right
<whitequark> sorear: elaborate
<whitequark> with nix, if I update Qt 5.1 to 5.2, I have to rebuild everything that depends on it
<whitequark> this is idiotic
<whitequark> Qt is specifically written in such a way that it has absolute forward compatibility
<sorear> whitequark: you can compile a program using the header files for glibc 2.60 (making up numbers), then run it using the binary for glibc 2.80
<whitequark> you just went and threw all that work away
<whitequark> well, that's not what other people using nix told me
<q3k> whitequark: i actually don't mind that?
<sorear> whitequark: that could be made to work in rust/c++ if the semver implications of #[inline] and pub struct fields (and a few similar things) were defined
<q3k> whitequark: in exchange, i can have packages built once if i share their settings across machines
<q3k> whitequark: and if I don't do anything weird, it's already built for my by hydra
<whitequark> sorear: no, i'm talking about nix
<rqou> wait, i thought libstdc++ dealt with this issue by messing around with elf symbol versioning?
<rqou> specifically to not break things?
<whitequark> rqou: that doesn't help if you build library A against non-c++11 version of libstdc++ header files and library B against hte c++11 version of libstdc++ headers
<whitequark> and library B uses library A's API
<sorear> i don't see what "symbol versioning" does that you can't do better by just renaming symbols
<whitequark> that has std::string in it
<rqou> i though they fixed this with a magic namespace thing and copy constructors or something like that?
<q3k> whatever it was it didn't work lol
<rqou> lol ok
<q3k> i still have nightmares about my gentoo builds breaking when compiling protoc
<sorear> in a perfect world (yes, I realize there are a million complications, starting with the fact that std::string is special in the encoding) they'd have changed the mangled name of std::string and then library A and B would fail to link with each other
<whitequark> yes
<whitequark> that's exactly what hapened
<whitequark> and this fucking pisses me off
<whitequark> because I had to waste dozens of hours debugging bullshit linker errors
<sorear> hmm
<rqou> there's always "statically link everything"
<whitequark> I link libstdc++ statically
<rqou> and "monorepo/vendor everything"
<whitequark> as is the default
<whitequark> and that STILL DOESN'T HELP
<sorear> "statically link everything" is the nix model
<whitequark> because, rqou, if you were listening
<sorear> but it doesn't work for opengl because opengl is in-process
<shapr> now we're back to rqou musl+static
<whitequark> library A and library B ended up with different mangled symbols because they used different versions of libstdc++ headers
<sorear> it also makes security updates a little more complicated
* shapr detects cycles in the conversational graph
<awygle> yes and lots of crosstalk
<rqou> but that can't happen if you recompile everything in order to statically link everything?
<q3k> well that's what you had to do when dynamically linking anyway
<q3k> emerge -e @world see ya in two days
<whitequark> sure it can, if you compile these libraries with different flags
<q3k> static or dynamic linking changes nothing here
<awygle> whitequark: do you happen to know if there's an explanation of how the generic serialization and later monomorphism stuff actually works someplace?
<awygle> *monomorphization? whatever that word should be
<whitequark> because they "happened" to use a different -std flag because the build systems decided on it somehow
<whitequark> awygle: in C++ or Rust?
<rqou> ooooooh i see
<awygle> whitequark: rust
<whitequark> no idea
<rqou> yeah, i missed that
<whitequark> i can tell you everything about it in C++ though
<whitequark> did you know: the C++ name mangling includes mangling for the entire C++ expression sub-language
<whitequark> because you can write typeof(x[y + 1]) where x and y are template arguments or something like that
<awygle> i did not, but i am not particularly surprised
<q3k> the itanium cxx abi internals is my favourite thing that i wish i never knew how it worked
<sorear> mostly i'm just annoyed that the mangling produces *strings* and it's not a hash-consed object graph
<whitequark> did you know: i implemented almost all of it
<q3k> whitequark: i know, i'm sorry
<whitequark> sorear: it IS a hash-consed object graph
<whitequark> well, more or less
<awygle> for openrisc? or something else?
<q3k> binary ninja
<whitequark> you can backreference earlier tree nodes
<sorear> whitequark: within each name, yes
<sorear> whitequark: but if I have a complex type used in 500 symbols, it encodes the type once per symbol name
<whitequark> well, if you could reference any other symbol, mangling would take potentially unbounded time
<whitequark> just run gzip over it lol
<whitequark> .debug_* is compressed for a long time
<whitequark> not sure about the regular strtab
<sorear> that doesn't help with "dynamic linking is too slow", while replacing the name section with an object table does
<q3k> whitequark: i think they wanted them to be eyeballable without demangling
<whitequark> q3k: well, yeah, i can read mangled C++ names almost as quickly as demangled ones by now
<whitequark> maybe not the backref-heavy ones
<q3k> i'm glad i don't have that skill
<q3k> and at the same time i regret it
<whitequark> those were fucking impossible to get right in my demangler too
<sorear> my small favorite part of cxxabi is how pmfs work one way on arm, micromips, and x86, and a different way on every other arch
<whitequark> _ZN10whitequarkEv was my displayname for a while
<whitequark> you forgot itanium
<whitequark> itanium has its own, extra insane version of pmfs
<whitequark> and extra insane vtables too
<whitequark> where every function is stored twice for some reason that I forget because lol it's itanium
<sorear> itanium's major problem is that, being a fractal screwup of an ISA, they forgot to include any PC-relative addressing modes
<whitequark> riiiight
<sorear> so the standard ABI is unconditionally FDPIC
<whitequark> wait, why do you know that
<rqou> inb4 lul itanic
<sorear> i read the cxxabi and the itanium sdm once?
<whitequark> you're a madman
<whitequark> for the latter part, at least
<whitequark> though, i did read the original 8086 manual once
<whitequark> it made -so many- things horrifyingly clear
<whitequark> in that they were clear but it is horrifying just how much we sacrificed for minor 8080 compatibility
<sorear> ia64 is a fundamentally bad idea, but there are a bunch of unforced execution errors on top of that
<azonenberg_work> lol
<q3k> whitequark: itanium is generally batshit crazy
<sorear> someone was pretty fond of MIPS and made "software refill" the only architecturally mandatory TLB mode
<q3k> whitequark: i have a few itanium blades that i'm thinking of turning into a vps service
<q3k> whitequark: just because i want people to experience the insanity that this platform is
<q3k> s,vps,shell hosting, because i don't think there's any virtualization for linux/ia64
<whitequark> you could just run qemu :P
<sorear> qemu never supported ia64 guests and they dropped host support recently
<sorear> because it's a hell architecture, although still far better than i432
<q3k> the really absolutely batshit insane part is the platform though
<whitequark> oh
<sorear> ~ three levels of architecturally defined remapping of register specifiers ~
<whitequark> what
<q3k> but yeah, the ISA has its' cool parts too
<sorear> 1. register rotation for loops 2. register windowing 3. bank switching on interrupts, because "push window on interrupt" would have been too obvious
<q3k> my favourite itanium fact is that intel shipped the first models with IA-32 emulation
<q3k> but they later replaced it with a reference software library for emulation that was faster
s1dev has joined ##openfpga
<awygle> whitequark: are rust and mir necessarily tied so closely that freezing mir would freeze rust?
<sorear> the weirdest omission in the ia64 isa is any kind of vector facility, in intel's ISA For The Future
<awygle> also, given that rust is already forward-compatible, why does forward-compatible mir serialization prevent future evolution?
<q3k> sorear: well everything was vectorized ootb already
<sorear> weird because THE ITANIUM 1 HARDWARE IA-32 DECODER SUPPORTS SSE2 AND CONVERTS VECTOR OPS INTO SCALAR SEQUENCES
<q3k> sorear: three instructions per opcode and whatnot
<q3k> sorear: which is not tecnically vector but i guess they were knee deep into that enough already that they didn't want to admit that vectorization was easier and faster
<sorear> whitequark: do you have a specific recommendation for the 8086 manual that explains what it does for 8080 compatibility or should I just try to find it myself
<whitequark> awygle: the entire point of having a language IR is being able to modify it freely to suit the goals of the optimizer
<whitequark> if you add (say) coroutines, this changes the IR massively
<whitequark> but even just improving the compiler usually changes IR in radical ways
<sorear> i still don't see why serializing IR is relevant to "can you make a stable ABI"
<whitequark> sorear: because there's no ABI
<whitequark> well
<whitequark> the interface that you export is more than just ABI
<whitequark> you can instantiate generics from other crates around your own types
<azonenberg_work> 7.45
<whitequark> and have them cross-inline
<azonenberg_work> how's Jtaginterface look?
<azonenberg_work> that one class documentation si relatively complete
<awygle> iiuc though if you drop "cross inline" you still need to serialize
<awygle> just to call properly
<sorear> in C++, compiling code which uses a library requires headers, which includes all ~generics~ templates from that library
<shapr> I really enjoy this channel :-)
<awygle> cuz I'd happily trade less-good inlining for an abi
<sorear> i don't see why rust couldn't do a "headers"-like model where you need to have some version of the source of a library installed to compile dependents
<whitequark> sorear: in Rust you don't have headers
<whitequark> um
<whitequark> it has that.
<whitequark> it's called cargo.
<whitequark> it builds all your dependencies from sources.
<sorear> we're talking about dynamic linking with a stable ABI
<awygle> yeah but if you had headers you'd only need the headers, not the sources
<sorear> cargo does not create a stable ABI
<awygle> rust _could_ do that it just doesn't
<awygle> and probably can't now, because that sounds breaking change ish
<sorear> rust could have a stable ABI and rust would not need to serialize IR to do this *because cargo exists*
<sorear> well
<whitequark> oh, I see now
<whitequark> your use case is not "proprietary libs", your use case is "dynamic linking across rustc versions"
<sorear> are you talking about serializing IR for #[inline] or about serializing IR for const generics?
<sorear> my use case is "opengl" because that's what you opened this conversation with, complaining about opengl in nixos
<awygle> that would work but would result in not solving the problem i have, which is "dynamic linking across rustc versions". because if you can't munch the source effectively you can't generate the MIR you need to monomorphize the generics
<awygle> sorear: more crosstalk, my fault. i am complaining about rust's lack of an ABI in parallel to all the nix stuff you were talking about before.
<whitequark> sorear: there's talks of "NewABI" in rustc that would mitigate the opengl problem
<whitequark> it would be an ABI that lets you use e.g. Vec in function arguments and such
<whitequark> so, not enough for generic containers, but well enough for something like OpenGL
<shapr> I just want higher kinded types in Rust
<rqou> what about a hypothetical glvnd-rpc?
<sorear> rqou: can you explain what you mean?
<awygle> rqou: why have you made me aware that glvnd exists? i didn't want to know this.
<rqou> why not?
<awygle> because if i understand it correctly it's horrific
<sorear> rqou: (after googling libglvnd) glvnd-rpc is how mesa should have been designed to start with
<rqou> awygle: it's less terrible than the current situation?
<awygle> goddamn, i hope vulkan is designed more sanely than this
* awygle is enraged beyond _all proportion_ by this and can only blame lack of sleep and/or too much coffee
<whitequark> wow, glvnd is an atrocity
<whitequark> I sort of see why it exists, but hell
<rqou> why does everybody hate it?
<q3k> i know nothing of the linux graphics stack, but it still smells like nvidia NIH
<whitequark> because you took a shitty API and put a shitty wrapper around it to make it work with your piece of shit proprietary blob
<rqou> also vulkan was indeed correctly set up for this to start with
<awygle> because no sane world would allow us to get to a point where something like this is an _improvement_
<whitequark> instead of just using mesa like all reasonable people
<q3k> ^ this
<q3k> gallium3d seems like a far better solution
<q3k> but it requires you to share your ~secret silicon sauce~ with the outside world
<shapr> I still don't understand why they're so against that
<sorear> how are the open source amd drivers these days?
<q3k> sorear: reasonable?
<q3k> sorear: reasonable enough to make buying amd a much better option for linux users imo
<awygle> i feel like the amd drivers got better as the cards got worse
<sorear> i'm vaguely aware that amd publishes full docs, there's an open source driver written against them, and amd *also* continues to publish their old proprietary driver for some reason
<whitequark> oh
<awygle> (relative to nvidia)
<shapr> makes me wish the high-end thinkpads would ship with AMD graphics
<q3k> sorear: amd writes their own floss drivers for new chipset
<whitequark> what's the best graphics card for a macintosh in sub-$200 range?
<q3k> *chipsets
<q3k> sorear: in-tree
<rqou> whitequark: nvidia for sure
<whitequark> no i mean the specific model number
<rqou> nvidia has their own "web driver" that supports almost all cards
<whitequark> hm
<q3k> sorear: they have a weird kinda-hal thing for low-level interaction with silicon that they basically receive from the hw team and have to make work on different OSes
<q3k> sorear: but everything else is fairly sensible and works
<rqou> sorear: apparently amd doesn't quite release *full* docs
<q3k> sorear: keyword: amdgpu
<rqou> ask marcan about RAI
<shapr> I would fly to an in-person ##openfpga meetup, just to hear these discussions in person.
<q3k> same
<q3k> CCC? :)
<shapr> anyone going to strange loop or ICFP?
<shapr> q3k: I've never been, that would be nice
<q3k> shapr: it's fantastic, do go
<rqou> anybody going to BSidesLV/DEFCON?
<shapr> I've also never been to defcon, even though my coworkers all say I should try it
<q3k> shapr: i mean, it was ridiculously fantastic when in hamburg
<q3k> shapr: as i mentioned earlier on this channel, CCC >> defcon
<shapr> I attend PhreakNIC and DragonCon, and long ago Arisia con
<q3k> shapr: defcon is something i just can't handle - rowdy, chaotic, loud, childish
<whitequark> anybody going somewhere that isn't in the US?
<q3k> whitequark: CCC!
<sorear> CCC = germany
<whitequark> ugh, germany
<q3k> whitequark: please come if you can
<shapr> whitequark: any cons you might attend?
<whitequark> i guess i have to get a visa to some other EU country first
<azonenberg_work> yeah not a big fan of defcon
<azonenberg_work> Skipping it this year
<q3k> whitequark: netherlands is iirc the best shengen visa spot
<azonenberg_work> (well ok i'm mostly skipping because of the construction)
<whitequark> shapr: orconf maybe
<whitequark> q3k: aha thanks
<q3k> whitequark: but germany shouldn't be so difficult either
<whitequark> that is quite useful knowledge
<q3k> not sure about poland shengen visas
<whitequark> EU countries tend to treat you like shit if you don't have a degree
<q3k> (for orconf)
<q3k> whitequark: ugh, that sucks
<whitequark> well, uh
<whitequark> most countries
<shapr> Sweden kicked me out :-P
<shapr> but I have a degree now! HA
<whitequark> amusingly, US is one of the best I've had, visa wise
<sorear> unless you have a US passport, then nobody cares :|
<azonenberg_work> whitequark: speaking of which are you planning to go to the US any time soon?
<shapr> I'd like to move back to Europe for a decade or so
<whitequark> well other than the fact that they have to get me through a month-long security clearance in washington every time
<whitequark> azonenberg_work: ^ because of that, probably not unless I have a very well known corporate sponsor
<sorear> showed up at Luxembourg-Findel with absolutely zero preparation and got in in two minutes
<azonenberg_work> Lol
<q3k> whitequark: would a corporate sponsor from within the eu help?
<whitequark> q3k: for an US visa?
<q3k> ah, us, sorry.
<azonenberg_work> Maybe when we have a new president it will be easier
balrog has quit [Quit: Bye]
<azonenberg_work> Kinda surprised, you're Russian
<q3k> i have a b1/b2 and still limiting my US travel
<whitequark> azonenberg_work: I'm mostly imagining DC is horribly disorganized right now
<azonenberg_work> Wouldn't they be extra friendly? :p
<q3k> the US border sounds less friendly than the CN border
<q3k> which is quite something.
<whitequark> ha ha, [redacted]
<shapr> all the borders got worse the past ten years
<q3k> LHR got terrible
<G33KatWork> azonenberg_work: only if you have the right компромат ;)
<q3k> with their shengen entrance queues
<whitequark> azonenberg_work: I don't think they're any more or less friendly in general
<whitequark> lol G33KatWork
<sorear> i remain unconvinced this serves any purpose except possibly as a make-work scheme for the ~defense industry~
<shapr> security theater can still charge for tickets
<awygle> ^ welcome to almost everything
<rqou> i went through LHR pretty soon after brexit and it was okay
<lain> awygle: openems seems to have some similar concepts to what I want, but -- correct me if I'm wrong -- it looks like a lot of coding to get some simple results. I'd like something to interface with, say, PCB software. I also want GPU compute. so I guess, mostly for fun, but also I want it easier to use
<rqou> i have heard horror stories about LHR though
<q3k> G33KatWork: did you use `setxkbmap 'ru(phonetic)'` for that? :)
<G33KatWork> I googled and copied out of wikipedia
* azonenberg_work has not had any problems with LHR but that was ~deecmber
<azonenberg_work> december*
<q3k> G33KatWork: try it out, it's amazing. type in kompromat, receive компромат
<azonenberg_work> then you have to go back? :p
<G33KatWork> I didn't know there are phonetic keymaps
<awygle> lain: i was looking at http://openems.de/forum/viewtopic.php?f=3&t=545 and interpreting it as "pcb analysis is at least possible". but i'm largely ignorant in this area
<q3k> G33KatWork: i can basically speak russian by just typing funny polish with this layout
<awygle> also hell yeah GPU compute :P
<whitequark> q3k: now try собачка шицу
<q3k> whitequark: yeah, yeah :P
<sorear> *can* you enter the schengen area at LHR?
<shapr> yeah, curious how schengen works post-brexit
s1dev has quit [Remote host closed the connection]
<awygle> lain: well like i said about rust bsdl earlier - please consider me subscribed to updates
<G33KatWork> whitequark: wat.
<sorear> in 2012 i went through LHR without immigration, then entered Schengen in LUX
<whitequark> G33KatWork: i just thought of some random words with ч ш and ц
<q3k> sorear: no
<sorear> and it took 2 minutes because if you have a US passport nobody cares about anything else
<q3k> sorear: the UK is not in shengen
<whitequark> those typically get mapped to weird sequences in romanization
<lain> awygle: rgr
<q3k> sorear: but they had separate queues for people comming in from shengen and non-shengen
<q3k> sorear: and the non-shengen was terrible
<q3k> sorear: (i'm non-shengen because ireland)
<G33KatWork> yeah, UK is special. you need to go through a passport check thing as a schengen citizen
<q3k> sorear: (and ireland is non-shengen because EMPIRE^WUK)
<rqou> being an emigrant and crossing HK<->CN repeatedly is "fun"
<q3k> G33KatWork: same in ireland
<rqou> just ask my dad
<q3k> G33KatWork: because of the good friday agreement, there must be free travel between the UK (NI) and the ROI
<sorear> i've already heard the story about needing a new passport every $smallnum months because of all the stamps
<rqou> lol yeah
<q3k> G33KatWork: thus since the UK went all 'we're an island we need borders fuck off with your freedom of movement bullshit', ireland had to do that too
<rqou> four stamps each time
<q3k> i have five chinese visas in my passport
<rqou> heh
<q3k> four more and i'll need a new passport
<shapr> ha
<rqou> no 10 year visa for you yet?
<q3k> nope
s1dev has joined ##openfpga
<sorear> are you out of pages or is there a specific rule limiting chinese visas?
<q3k> sorear: no, out of pages
<G33KatWork> I have two. and they are bloody expensive :(
<q3k> sorear: because chinese visas take effectively two pages
<G33KatWork> but US is not much cheaper if you can't take advantage of visa waiver
<q3k> (one for the visa, one for the stamp(s))
<q3k> G33KatWork: but a us visa with non-waiver lasts you 10 years
<q3k> (i have a b1/b2 because poland is too barbaric to have ESTA)
<rqou> lol
<sorear> 10 years? can you transfer it to a new passport?
<q3k> yes
<awygle> lain: also if you have a collection of papers or something, please pass them my way? I might even read them someday lol
<G33KatWork> huh, how did you do that?
<q3k> (not if you drunkenly lose your passport though)
<q3k> (don't ask me how i know)
<whitequark> ha, US gives me visa for 1 year
<whitequark> and that is the most any country has ever given me visa for
<awygle> ah fuck I need to renew my passport
<whitequark> excluding HK work visa ofc
<G33KatWork> I know a bunch of people with academic visas and they have to travel back to germany to get the visa renewed
<whitequark> EU countries give visa for the specific period requested
<G33KatWork> because apparently you can only do that in your home country
<whitequark> especially anal ones also demand purchased plane tickets and booked hotel
<shapr> I need to renew my passport too
<whitequark> like germany
<whitequark> germany can go fuck itself tbqh
<rqou> ugh really?
<shapr> gotta go visit my bro in taiwan soon
<whitequark> but it's not much better for other EU countries, or UK
<rqou> heh, taiwan is "fun" too
<whitequark> well I didn't even have to mention UK, it's obvious
<q3k> rqou: taiwan was fine for me?
<q3k> rqou: no visa needed
<rqou> taiwan is fine if you're from a "western" country
<lain> awygle: so far my reference material has been books, with the most useful being: http://a.co/0ECMbcr and http://a.co/7qWCXGh
<q3k> classifying 'poland' as 'western' is funny
<rqou> just don't look into the bureaucracy needed to visit "cross-strait"
<q3k> classifying anything as western is funny, too
<whitequark> to summarize, i hate everyone who lives in "first world" countries purely on the basis of how easy it is to get visas for them
<q3k> rqou: oh, cross-strait is something entirely different
<q3k> rqou: it is a lovely shitshow
<rqou> HKSAR is too
<rqou> (says the holder of a 回乡证)
<q3k> whitequark: if there's anything i can do as a company director in the EU to help you get a shengen visa let me know
<q3k> whitequark: borders suck
<whitequark> q3k: probably not, doing anything "unusual" tends to just raise more questions
<whitequark> e.g. I'm going to have to request a different letter of acceptance from my company next time I get a visa that doesn't say that I'm an "engineer"
<sorear> "western" is anything west of istanbul imo
<whitequark> because all immigration depts assume that I need a degree
<rqou> q3k: pop quiz: what is the difference between eligibility for a 回乡证 and a HKSAR passport?
<q3k> rqou: ... i actually never did research on relocating to HKG, so i don't know
<q3k> rqou: (although three years ago I would've moved if I had the opportunity to)
<shapr> I wish the borders would become easier to cross, not more difficult.
<shapr> I'd like to setup shop in random parts of the world for a few years at a time.
<rqou> HKSAR passport means that the HK government says you're a chinese citizen; 回乡证 means that the mainland government says you're a chinese citizen
<q3k> shapr: yeah, it's difficult
<q3k> shapr: even more with varying tax residencies
<rqou> yes, they're both interpreting the same law
<rqou> no, it doesn't always return the same answer :P
<shapr> q3k: yeah, ~1999 US wanted me to pay income tax only the first year of being an expat, now they want all the years
<whitequark> rqou: clearly, one of them is noncompliant
* whitequark hides
<shapr> or maybe it's first five now, I should go check that again
<q3k> shapr: the US bilateral tax agreements are a travesty
<q3k> shapr: no other civilized country wants to double-tax their expats
<q3k> shapr: or require banks from other jurisdictions to file monthly forms to uncle sam about your account balances as a US citizen
* shapr sighs
<shapr> all kinda stupid in the gov't here
<shapr> and the occasional nice thing too, but I guess I rarely notice the things that work well
<rqou> yeah, i suppose at least the USPS works decently well (byuu's issues notwithstanding)
<shapr> yeah, that was an interesting story
<pie_> q3k, re double taxing, isnt it that with places which have an agreement its usually just the US taxing? i wonder if they split with the government in question. i somehow doubt it
<pie_> well, or at least i think its that you only have to file us taxes
Bike has joined ##openfpga
<zkms> the collateral damage of the FATCA thing is annoying :\
<q3k> pie_: iirc it's not, but i'm not a us citizen, just an armchair wikipedist
<q3k> my only experience with US taxation is W8-BEN
<shapr> q3k: is Eire better?
<q3k> shapr: i'm not irish, i'm polish
<shapr> ohh
<shapr> well... huh
<pie_> thoguh i half looked into this once with hungary on the embassy page and i *think* it was like that. but i dont pay taxes yet so idk
<q3k> shapr: but i only pay taxes in ireland, if that helps
<q3k> shapr: i filed a '0' pl income tax return for the first year i emigrated from poland
<q3k> shapr: never had issues
<shapr> that's nice... I'm jealous
<q3k> now moving to germany, iirc i have to file '0' returns with the irish revenue for two years after moving or something
<openfpga-bot> [jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNPay
<openfpga-bot> jtaghal/master 5ba737d Andrew Zonenberg: Lots of Doxygen comment improvements. Made some functions protected that were incorrectly public.
<shapr> I was born in the US, otherwise I've lived in Finland and Sweden.
<q3k> finland is neat
<shapr> I do have a funny story about how I got Swedish immigration law changed twice :-P
<q3k> the helsinki hackspace is _awesome_
<pie_> shapr, lolwhat
<G33KatWork> q3k: when are you planning to move?
<sorear> whitequark: i just skimmed the "8086 user's manual" and found a brief section on CONV-86 but nothing that covered how the instruction set was made compaitble
<G33KatWork> also did you get an appartment now?
<shapr> I lived by the artic circle for 6.5 of those 7 years
<q3k> G33KatWork: i have an airbnb in munich from september 25th to november 6th
<whitequark> sorear: i think the instruction encodings are inherited
<whitequark> partially?
<q3k> G33KatWork: once i'm there i'll look for apartments
<G33KatWork> good luck :/
<whitequark> which is why you sometimes have one leading opcode byte per register but sometimes they're all crammed into mod/rm byte
<shapr> so, Tornio/Luleå
<G33KatWork> housing is fucked in germany
<sorear> the compatibility is at the assembler level and specifically doesn't cover self-modifying code
<G33KatWork> especially munich
<q3k> G33KatWork: looked at immobilienscout today, pertty cool places for 1200 (well, unfurnished, but i want that)
<whitequark> ok, maybe I understood it wrong
<G33KatWork> unfurnished is normal
<q3k> G33KatWork: reminder: 1800 for my current apartment in dublin
<pie_> 1200eur/month?
<shapr> yikes
<sorear> 8086 is "nice" because it's all very clearly octal and has 1-byte everything
<G33KatWork> careful: you might need to buy a kitchen
<pie_> thats mad
<q3k> implr: yes
<sorear> kinda like s390 but for the base
<q3k> i mean
<q3k> pie_: ^
<shapr> mind you, I pay 1700 euro monthly for my one bedroom here in Atlanta
<q3k> G33KatWork: i know
<sorear> 286+ go to hell because there was literally no space left
<shapr> wait, no.. 1300 euro
<q3k> shapr: 500eur for my apartment in warsaw
<shapr> I wish
<q3k> shapr: right in the city centre, 1br, 50m^2
<awygle> i pay more than 1700 euro for my 1br :(
<shapr> atlanta is cheapest 'tech city' in the US
<sorear> they had do drop 0F=POP CS from the 8086/186 decode map and reuse it as a prefix byte for all the new 286 instructions
<pie_> why is reting so fucking expensive, thats like, almost a full minimum wage
<q3k> pie_: c a p i t a l i s m
<q3k> pie_: eat the rich, get lower rent
<sorear> i assume they had some analytics about how useless and rarely used pop cs is
<G33KatWork> that's the problem. not enough space. if new appartments are build they are for higher incomes etc.
* azonenberg_work is paying equivalent of 2400 eur/mo right now and living in a hotel room
<shapr> q3k: I'm effectively in the city center, other places are easily half the price of mine
<azonenberg_work> so enjoy :p
<sorear> pie_: because there are more would-be renters than houses
<awygle> shapr: median home price comparison seattle vs atlanta makes me nauseous.
<shapr> azonenberg_work: wow, why?
<azonenberg_work> shapr: 85 USD a night plus tax, give or take a bit
<rqou> try >USD$3k/mo here :P
<shapr> awygle: yeah, I can get paid 10% more in a "real" tech city, and pay at least 30% more for house/apt
<rqou> sillycon valley housing is suuuuuuper fucked
<azonenberg_work> The lease ended on the place i was renting before
<awygle> shapr: redmond vs atlanta is worse
<rqou> probably far more than any of your other countries
<azonenberg_work> My new house has no walls and no electricity
<shapr> I used to live in First Hill
<azonenberg_work> So until i finish the walls and turn power on... :P
<sorear> and all the ~good liberals~ oppose new housing construction because they benefit from high property values
<awygle> shapr: try 270% more
<shapr> Seattle rent was insane, even in 1999
<q3k> also silly valley only gets you wooden boxes
<q3k> can't even get a proper brick house there
<rqou> there are cities with median house prices like USD$1M-3M
<q3k> or, you know, normal windows
<shapr> azonenberg_work: ok, that's a good reason
<q3k> rqou: ^
<azonenberg_work> shapr: i'm gonna be doing a bunch of sheetrock this weekend
<azonenberg_work> Si we'll see how far i get
<azonenberg_work> So*
<shapr> senior dev maxes out around $130k in Atlanta, but housing costs are so much lower here
<G33KatWork> also US doorknobs are weird :]
<q3k> i didn't even know that windows were different elsewhere until i was in CA for half a year and had those awful sliding windows
<q3k> G33KatWork: that too
<pie_> i dont even remember american windows at this point
<q3k> G33KatWork: also the electrical work in the US
<G33KatWork> and why don't you US people have toilet brushes?
<G33KatWork> why?
<q3k> this atrocity
<q3k> fuck this hit
<azonenberg_work> q3k: what kind of windows?
<awygle> yeah i mean if _tokyo_ is 45% higher rent than you you really can't say "it's too many people and not enough space"
<awygle> build. housing.
<azonenberg_work> q3k: and lol, here i just have plain old 120/240V split phase
<rqou> high leg delta is pretty rare
<awygle> ffs
<rqou> but what's wrong with it?
<pie_> awygle, did you get that backwards or am i parsing wrong
<awygle> err, yes, i got that backwards
<sorear> plenty of acres, no square feet
<awygle> tokyo rent is 45% _lower_ than seattle
<rqou> G33KatWork: oh yeah, apparently i learned from whitequark that US doorknobs are weird
<q3k> azonenberg_work: i just have 230v, the 110v thing is ridiculous
<azonenberg_work> q3k: we have some windows in my new house that are physically incapable of opening
<q3k> azonenberg_work: why why why
<q3k> it's stupid
<q3k> use normal windows damnit
<awygle> what really chaps my ass is that the people who want "nice single family suburban homes" have _literally the rest of the country_ to choose from! it's all open land!
<awygle> jesus what's wrong with me today
<azonenberg_work> all of the rest are sliding
<q3k> azonenberg_work: whyyy
<azonenberg_work> q3k: Because i couldn't afford to replace the windows yet :p
<q3k> this has been standard in third world shitholes like poland since the 90s
<q3k> and in the rest of eu since much earlier probably
<awygle> oh this crazy thing with the tilting and the opening
<pie_> lol
<awygle> my ex had a door like this
<awygle> seems needlessly complex to me
<azonenberg_work> Probably because most people in the US have air conditioning and thus don't ever open their windows
<q3k> azonenberg_work: eww
<awygle> i thought you were complaining about like, single paned glass or something
<azonenberg_work> I'm a fan of the ones that open outward with a crank
<azonenberg_work> You can get the full square footage of the window open
<pie_> awygle is just salty becaus he tilted instead of opening the door and tried to get through the thin opening
<q3k> awygle: it's useful and cheap, why not?
<azonenberg_work> But it doesnt take up sapce in the house
<shapr> I will say that when atlanta goes over 100 F air conditioning is nice
<shapr> other than that, I like warm weather
<awygle> pie_: actually i tried to open the door, accidentally pulled on it, and thought a) i'd broken it and b) it was about to crush me
<q3k> awygle: every european kid goes through that
<sorear> i'd like a nice fully enclosed house where it hasn't gone over 100 F in recorded history
<q3k> awygle: it's okay, you'll manage
<pie_> oh oh did you do the thing where you sort of accidentally open both mechanisms at once? :D
<awygle> yep
<sorear> which probably limits you to antarctica at this point, so be it
<q3k> pie_: i do that every week with the somewhat shitty door in my living room
<pie_> lol
<q3k> it won't crush you.
<awygle> there's nothing wrong with windows like that i just don't really get the benefit. i'm unlikely to replace all my windows with them but also unlikely to replace them if i happen to buy a house that has them.
<rqou> sorear: the dorito is well on the way to making such places no longer exist
<q3k> awygle: my point is why aren't they standard in new/renovated buildings
<awygle> q3k: and i guess my point is "why would they be". but ultimately the answer is going to be "they are more expensive than sliding"
<q3k> i don't think they are
<sorear> do openable double-pane windows exist?
<q3k> i mean, i have no comparison, nobody has us-sliding windows in europe
<q3k> sorear: yes?
<azonenberg_work> Welp, done with work for the day - packing up
<shapr> sorear: arctic cicle had its own challenges, got down to the fixpoint of celsius and fahrenheit
<sorear> my small sample has a strong correlation, but it might be artefactu
<q3k> sorear: all of the windows i've seen are openable and double-pane
<q3k> (in europe)
<sorear> shapr: my theory is that i can run around in 50lbs of jackets, but i can't run around less than naked, so it's better to err cold
<zkms> there's "low emissivity windows" which are becoming more popular
<zkms> and they block RF like nothing short of a metal sheet
<shapr> sorear: that's a good point
<sorear> is that a bug or a feature