<awygle>
nikitakit: hello there! rqou said you're interested in PAR algorithms, is that right?
<nikitakit>
hi! nice to meet you
<nikitakit>
yes, I'm interested in PAR
<awygle>
Cool :-) is there anything in particular you're interested in? Current projects in the channel include crossbar PAR for GreenPak and Coolrunner, and I'm working on a distributed placer for FPGAs
<nikitakit>
hmm... so I'm primarily a CS person, so I'm not actually familiar with any of the particular hardware you're talking about
<nikitakit>
I guess I was just surprised at how annoying even the proprietary PAR tooling is, which sparked my interest to see what the problem is all about
<azonenberg>
nikitakit: are you in the bay area w/ rqou?
<nikitakit>
Yea, I'm a grad student at Berkeley
<azonenberg>
ah ok
<azonenberg>
we've been talking about, maybe december ish, having a meetup of west coast folks working on PAR and related problems
<nikitakit>
(and I do have plenty of grad student things going on)
<azonenberg>
me, rqou, awygle, maybe you
<nikitakit>
I'd be down to join, unless I'm gone for winter break
<azonenberg>
we dont have a date set
<azonenberg>
there will likely be a smaller brainstorm session w/ me and awygle since we're both seattle based
<azonenberg>
then later in the year try to get all of us in one place
<nikitakit>
sure
<nikitakit>
In terms of particular interests, my impression is that current PAR tools don't reuse a lot of info when being re-run on a slightly modified design
<nikitakit>
It seems to me that once you have a design complicated enough to make PAR super hard, it would be a lot more efficient to precompute some info so you can iterate faster anytime you change the source
<azonenberg>
Xilinx has a "smartguide" engineering change order function
<azonenberg>
but i dont know how well it works
<azonenberg>
what i'm more interested in is speeding design closure by parallelizing PAR
<azonenberg>
and i don't mean like annealing on 4 or 8 cores
<azonenberg>
I mean a rack of dual xeon blades, or a few hundred large EC2 instances
<azonenberg>
PAR-ing a full xcku035 in a minute or two
<azonenberg>
No exact performance targets, just "scale well to hundreds or thousands of cores"
<nikitakit>
any thoughts as to the key idea of the approach? like splitting up the design into subparts to PAR independently, v.s. just trying a lot of full-design stuff in parallel
<azonenberg>
I want to explore energy minimization algorithms used in molecular dynamics
<awygle>
nikitakit: that's an interesting thought though.
<azonenberg>
Those scale well to hundreds of thousands of CPUs
<azonenberg>
and they're basically just a mass-spring system like an FPGA placement
<azonenberg>
(where spring force = how much you're failing timing)
<azonenberg>
big difference is, we have a discrete domain vs a continuous one
<azonenberg>
So some adaptation will be required
<azonenberg>
General idea is, do approximate global placement then gradually refine the detail placement
<azonenberg>
the further down you go, the less communication you'll need
<azonenberg>
then routing can be fully parallelized except at boundaries between tiles managed by single CPUs
<azonenberg>
Global placement is likely going to be the hardest part if we do this
<azonenberg>
as there will be lots of comm overhead early on
<azonenberg>
as the placement approaches a final setup, processors will work more and more on their own
<azonenberg>
Also, i want to consider the possibility of having feedback from routing back into placement
<azonenberg>
but i'm not yet sure how to do that
<awygle>
My current approach is an analytical placer based on the Jacobi method (which is essentially isomorphic to what azonenberg is describing)
<awygle>
The "chop up to par independently" approach has been tried in several papers but it tends to hurt quality of result as the number of threads increases
<azonenberg>
Yeah, it only really would work if you had hierarchial placement
<azonenberg>
and floorplanning of major blocks along CPU boundaries
<awygle>
This can be reduced by changing which subregions you're using at each step but still, not ideal
<azonenberg>
that's way too much manual effort for a general par
<azonenberg>
Floorplanning is something you do during optimization
<azonenberg>
not for prototyping
<nikitakit>
that sounds interesting
<nikitakit>
Do you have the hardware/cloud credits to be prototyping this massively parallel stuff?
<azonenberg>
Not yet, although I will be able to go moderately far
<nikitakit>
as context my research has to do with deep learning, an it's impossible to get anything done if you don't have the hardware
<azonenberg>
i have a bunch of quad core stuff right now
<azonenberg>
quite a few U
<azonenberg>
My new desktop workstation, to be purchased in the next few months, will be dual socket xeons
<azonenberg>
probably on the order of 24-32 physical cores and 48-64 threads
<awygle>
I have nothing useful in this regard
<nikitakit>
ok, that's already a parallelism challenge with 24-32 cores
<nikitakit>
do the proprietary tools parallelize well?
<azonenberg>
LOL
<azonenberg>
ISE maxes out at 4 for routing and 2 for placement
<azonenberg>
vivado can, i think, use six or eight
<awygle>
Actually that's not fair, I have 24 cores and two gpus
<nikitakit>
ok I see
<azonenberg>
awygle: Oh, and i'm going to put something like 128 GB of RAM in it
<azonenberg>
I have 32 on my current desktop and i OOM it routinely
<awygle>
azonenberg: you bastard :-P
<azonenberg>
i tried to fire up a windows VM to LTSpice something earlier and couldn't run it
<azonenberg>
i don't even have THAT much open
<awygle>
I have 16gb of ram
<awygle>
In my desktop. My laptop is 8gb and I think ddr3
<nikitakit>
lol I only have a 16gb work laptop and a super old 4gb personal one
<azonenberg>
I have 16 in my laptop
<azonenberg>
(work, ddr3)
<azonenberg>
desktop is 32 of DDR3
<awygle>
And a NUC with 4
<azonenberg>
I currently have one instance of kicad, two instances of vivado, six linux VMs, two libreoffice spreadsheets, two text editors, several dozen shell tabs, and maybe 10-15 multi-hundred-page PDFs open
<azonenberg>
that shouldn't be TOO much, no? :p
<Zorix>
that is intense
<azonenberg>
I use computers for a living, heavily... I am not opposed to plowing a lot of cash into hardware if it helps me work (and play) more efficiently
<awygle>
As a brief aside, this hardware distribution leads to me really wanting to be able to use GPUs with this hypothetical placer, while azonenberg doesn't particularly care
<nikitakit>
I'm also curious if GPUs would help
<nikitakit>
Like, is there enough floating point math needed
<azonenberg>
it's mostly pointer math and conditonals etc from what i remember
<nikitakit>
because I think just running discrete stuff on GPU won't give that much of a benefit
<azonenberg>
and random access memory math
<azonenberg>
exactly what GPUs suck at :p
<azonenberg>
heavily branching etc
<awygle>
There's significant research into using GPUs for this actually
<nikitakit>
it should depend on algorithm, though
<awygle>
They tend to just run everything as floats and legalize later
<nikitakit>
perhaps there's some clever continuous relaxation that can leverage GPUs
<azonenberg>
inb4 fpga par accelerator card
<nikitakit>
well, with moore's law fading there's a good chance we go back to accelerators-for-everything
<awygle>
oh thank god a keyboard
<awygle>
i have legitimately thought about an FPGA PAR accelerator
<awygle>
it would be interesting for things like Zynqs
digshadow has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
<awygle>
thinking a little more about "use last time's placement to inform this time's", a big issue with the current open source toolchain(s) is that abc is the great devourer of net names
<awygle>
so i'd expect it might be hard to correlate
<azonenberg>
Well
<azonenberg>
That requires improving traceability through ABC
<awygle>
but if that wasn't an issue then arachne can already spit out the post-place netlist as a BLIF, so it wouldn't be too hard to teach it to use a post-placement netlist as its initial placement
<azonenberg>
which is a high priority for debugging
<nikitakit>
yes, this would be a good place to start in terms of going in that direction
<awygle>
plus you're berkeley-based so you could annoy alanmi in person
<awygle>
azonenberg: do you use a password manager thing?
<azonenberg>
i use an encrypted volume with a text file of passwords, plus a good memory, does that count? ;p
<azonenberg>
less important stuff lives in my browser's cache
<azonenberg>
if my password to some random forum gets out, i can deal with that
<azonenberg>
my online banking etc is 16 char alnum random that i just commit to memory
<azonenberg>
My login for work used to be, although due to a recent policy change it's now somewhere in the 25-30 char range
<azonenberg>
never written that one down
phil_gekni has quit [Ping timeout: 240 seconds]
phil_gekni has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
<awygle>
i also memorize my banking stuff, but i use lastpass for unimportant things, and New Firefox Extensions broke it :(
pie_ has quit [Ping timeout: 252 seconds]
Morn_ has quit [Ping timeout: 248 seconds]
wolfspraul has quit [Ping timeout: 246 seconds]
Morn_ has joined ##openfpga
wolfspraul has joined ##openfpga
<azonenberg>
Sooo
<azonenberg>
For my 10/100baseT bitbang board
<azonenberg>
i feel bad leaving three IO banks unused :p
<azonenberg>
ideas on what to do w/ them?
<awygle>
USB 1.1 PHY
<awygle>
or 2.0, since you're chronically ambitious :P
<azonenberg>
Lool
<azonenberg>
no
<azonenberg>
no usb
<azonenberg>
i refuse to have anything to do with it :p
<awygle>
lol
<azonenberg>
That and, usb is a pure digital protocol
<azonenberg>
so its not too crazy when you do it with just GPIOs
<awygle>
sure
<rqou>
2.0 isn't quite
<awygle>
i want to do a 1.1 PHY and then make an FTDI clone on an ice40
<rqou>
azonenberg: troll: R-2R composite video ("the yellow connector")
<azonenberg>
FTDI is not something worth cloning IMO :p
<azonenberg>
its a last resort b/c you cant find any other interfaces that work
<awygle>
on a technical level, no. on a ... call it a social level, yes
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rqou>
azonenberg: R-2R video is a good way to needlessly consume pins :P
<rqou>
also because composite video is a clusterf*ck :P
<azonenberg>
i meant something useful and cool
<azonenberg>
not wasting pins for no reason
<awygle>
do a high-fidelity DS audio DAC
<rqou>
azonenberg: extending the troll idea: put a NES in the remainder of the FPGA
<awygle>
as an homage
<rqou>
parallel cartridge busses also burn pins :P
<azonenberg>
i should just throw on a Q-strip
<azonenberg>
and be done with it
<awygle>
clone your circuit a bunch of times, do an L2 switch
<awygle>
low development effort, potentially useful
<azonenberg>
I already have a board with four PHYs on it
<azonenberg>
that has this same FPGA
<azonenberg>
Which is too small to do the kind of fun stuff i wanted
<awygle>
duplicate your circuit a few times, try 4 different AC coupling methods
<azonenberg>
i have a magjack on there that i've already used with success
<awygle>
transformer, series caps, etc
<azonenberg>
the point is to be a PoC, not to actually prototype it for serious use
<azonenberg>
Also, i intend to make a L2 switch on an xc7a200t, with 2x 10gbit SFP+ optic ports, 8x 1gbit SFP optics, and probably 16 tri-speed copper ports
<azonenberg>
But that will be a full 1U appliance on an 8-16 layer board with an 1156-ball FPGA :p
<awygle>
loop it back to a hard PHY for on-board BERT
<azonenberg>
Hmmm
<azonenberg>
Better idea, loop it back to a magjack terminated into 100 ohms
<azonenberg>
and loaded up with SMA connectors
<awygle>
that would give you something to do with your fancy new scope :P
<awygle>
put switchable diode noise generators on both lines so you can test robustness
<azonenberg>
no, i can add noise no problem :p
<awygle>
meander the transmission lines so you can experiment with phreaking crappy ethernet phys :p
nikitakit has quit [Quit: Page closed]
<azonenberg>
:P
<awygle>
put cnlohr's 10-T phy on there and see if you can autonegotiate
<azonenberg>
Lol
<awygle>
run a long trace to nowhere off one of your unused pins and bit-bang an 802.11 phy
<awygle>
(all right i'll stop)
<azonenberg>
loool
<azonenberg>
yeeeah that would be a bit much :p
<awygle>
use a 2.4 Gbps transceiver for your carrier
<awygle>
simple diode mixer
<awygle>
noooo problem
<awygle>
... would that actually work?
jhol has quit [Quit: Coyote finally caught me]
<azonenberg>
um
<azonenberg>
not a clue
jhol has joined ##openfpga
<azonenberg>
you'd want some RC filtering or something to remove higher harmonics from the carrier
<azonenberg>
that much is certain
<azonenberg>
And i dont have a GTP on this chip
<azonenberg>
It would be hilarious to bitbang some ISM-band radio protocol with one, though
<awygle>
you only need 2 MHz baseband to do 802.11b at the slowest rate
<azonenberg>
well what i was thinking is
<azonenberg>
for some simple PSK-like protocol, transmit only
<azonenberg>
you could bitbang RF
<azonenberg>
and just LPF out the upper harmonics
<azonenberg>
then feed to an external amp or something
<awygle>
i wonder if you could use a GTP to drive a Class-E amplifier
<azonenberg>
say 433 MHz carrier or so
<azonenberg>
that should be bitbangable with a GTP if you turn off the 8b10b
<awygle>
oh you mean drive it directly at RF
<awygle>
hm
<azonenberg>
Yes
<azonenberg>
you can't modulate amplitude but you can modulate phase/frequency
<azonenberg>
866 Mbps squarewave data is a 433 MHz carrier
<azonenberg>
add an RC filter to remove the 2nd and higher harmonics and you have a 433 MHz sinusoid
<awygle>
and just insert longer/shorter pulses to modulate phase
<azonenberg>
forget all that silly I/Q stuff
<azonenberg>
exactly
<azonenberg>
sounds like a horrible idea that might work
<azonenberg>
lol
* azonenberg
imagines taking an fpga devkit and screwing a 50 ohm antenna onto the SMA connector for a GTP
<azonenberg>
Nope :p
<awygle>
hmmmm
<awygle>
if you run at 866 you'd only have one bit of phase control, i.e. "crappy bpsk", i guess
<azonenberg>
Easy enough to improve though
<awygle>
i feel like there should be a reason this won't work, but... i can't think of one
<azonenberg>
Run at 1732
<azonenberg>
or 3464, although this might not work on a crappy spartan6
<azonenberg>
i think you'd need an artix for that
<awygle>
i feel like a kind and loving god cannot allow this to be possible
<azonenberg>
also keep in mind your phase shift is normally done at baseband so it's multiple carrier cycles
<azonenberg>
its a huge shift, not a few ps
<azonenberg>
And a kind and loving god wouldn't allow a lot of things we have to deal with
<azonenberg>
like ISE
<azonenberg>
:p
<awygle>
i mean if you're going to do this anyway, grab a spartan, run at 4.8 Gbps, try for 802.11
<awygle>
if you're gonna be a bear, be a grizzly
<awygle>
ERR artix, not spartan
<azonenberg>
802.11 i think requires amplitude control
<azonenberg>
Which you won't get with a trivial GTP bitbanger
<awygle>
802.11b at 5.5 M and 11M for sure are BPSK and QPSK respectively
<awygle>
with some DSS thrown in
<awygle>
(okay actually DBPSK and DQPSK but that's unimportant in this context)
<awygle>
i am pretty sure 1M and 2M have the same relationship, just slower, but i've never tried to use them for anything serious
<azonenberg>
ah so its not until g/n that you start seeing amplitude change?
<awygle>
all the other ones are QAM on OFDM, yes
<azonenberg>
idk, i know Ethernet PHYs pretty well
<azonenberg>
not other stuff
<awygle>
a is idential to g just at 5GHz
<awygle>
i know a _lot_ about 802.11, sadly
<azonenberg>
i've only actually implemented 1000base-X so far
<azonenberg>
wrote my own PCS for an artix7 using a raw GTP with no IP wrapper
<awygle>
i did some gnuradio 802.11 stuff for a while, but i was younger and dumber so it didn't work very well
* awygle
clicks "send me my 2fa code" and then thinks "oh, who's emailing me?"
<awygle>
so did you just play with ethernet phys all day? every time you tweeted a diagram i was jealous that i was stuck at work
<azonenberg>
Lol no that was like 15 minutes last night
<azonenberg>
i just took my leatherman and stripped insulation off a cat5 cable
<azonenberg>
hooked it from my laptop to a cisco
<azonenberg>
forced to various speeds and grabbed a few shots with my new lecroy scope
<azonenberg>
could not have been more than an hour of work
<azonenberg>
the PHY design was maybe 2 hours this afternoon
<awygle>
yeah, i meant the (presumably kicad) stuff from today
<azonenberg>
Yes, that was mostly after work
<azonenberg>
although i did a few mins over lunch
<awygle>
anyway. nice plotting horrible things with you. i need sleep so i can go back to work tomorrow >_<
<azonenberg>
Lol
<azonenberg>
Yeah i'm working from home tomorrow
<azonenberg>
REing an unholy amount of obfuscated java
<azonenberg>
Wish me luck :p
<awygle>
career protip: don't get hired into a death march
<azonenberg>
(you see why i feel the need to bitbang ethernet to stay sane?)
<awygle>
lol you never have to justify weird side projects to me, my long term goal is "get rich so i can spend all my time running down stupid ideas"
<azonenberg>
I've joked that the closest i'd ever get to retiring would be turning my garage into an FFRDC
<azonenberg>
and working on DARPA-hard problems in my spare time
<rqou>
i was half-expecting "turning my garage into a superfund site"
<rqou>
but i guess since you're "the EH&S guy", that won't happen
<azonenberg>
Lol
<rqou>
meanwhile here i don't think "extended family of convicted human traffickers" care very much about "just a little bit" of chemical contamination :P
<azonenberg>
Lol
<azonenberg>
You have a... unique... living situation though
<azonenberg>
i'm looking to buy a house soon
<azonenberg>
Which will give me all the more incentive to not trash the place
<rqou>
i believe the "unique" part isn't accurate :P
<rqou>
"He used its profits to purchase over 1,000 run-down apartment buildings, making him, by 2000, the largest and wealthiest landlord in the city (other than the University of California), with a worth estimated at US$69 million"
<rqou>
awygle: i'm curious, did you ever live in a lakireddy apartment when you were a student?
jn__ has quit [Ping timeout: 248 seconds]
jn__ has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
teepee has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
m_w has joined ##openfpga
m_w has quit [Client Quit]
Hootch has joined ##openfpga
digshadow has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 248 seconds]
digshadow has quit [Quit: Leaving.]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 240 seconds]
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
m_t has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
digshadow has joined ##openfpga
qu1j0t3 has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
enriq has joined ##openfpga
xdeller has quit [Quit: Leaving]
<awygle>
rqou: I mean, maybe. I didn't exactly do background checks
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
pie_ has joined ##openfpga
<cr1901_modern>
azonenberg: Do you have any literature on 4b/5b clock recovery (yes, analog is not a concern :P)
<cr1901_modern>
While reading a paper today it came up and I finally learned that's what's used for 100Mb Ethernet
<awygle>
cr1901_modern: yeah re your stackoverflow post, seems like it would be trivial to lock to the opposite phase of the TX clock with a pll
<awygle>
Possibly difficult to avoid, even
<awygle>
I agree the literature is unclear though, typical academic "we can create a phase relationship!" "what relationship?" "who cares about the details?"
<cr1901_modern>
awygle: You got to my point before I typed it out :P
<cr1901_modern>
awygle: "Possibly difficult to avoid, even" This isn't an analog phase detector, so the VCO wouldn't be outputting a signal 180-degrees out-of-phase
pie__ has joined ##openfpga
<awygle>
It's basically a sign change
pie_ has quit [Ping timeout: 255 seconds]
<azonenberg>
cr1901_modern: No i do not have any specific literature
<azonenberg>
but basically my plan is, look for edges
<azonenberg>
dead-reckon 125 Mbps from that edge out
<azonenberg>
fine tune when the next edge arrives
<azonenberg>
once i have an approximate phase lock then go half a UI in from the edge and call that my sampling point
<awygle>
"UART writ large"
<azonenberg>
awygle: lol
<azonenberg>
honestly it isnt all that different
<awygle>
It's actually easier because the data rate is fixed
<azonenberg>
except that there's a constant stream of edges and you fine tune on every one rather than just resyncing every start bit
<awygle>
And that yeah
<azonenberg>
10m is more like uart
<azonenberg>
since the edges stop between packets
<azonenberg>
but its manchester with a preamble to sync to
<awygle>
I didn't realize 100b had fill characters
<azonenberg>
100m is realtime clock recovery once the link comes up and there's always idles between packets
<azonenberg>
same with gig and up
<azonenberg>
10m actually goes to differential idle between packets
<azonenberg>
anyway I think what i'm going to do to implement a sort of pseudo-PID with a multi bit phase accumulator
<azonenberg>
basically store a fractional phase counter, every time i see an edge too early increment and every time i see an edge too late decrement
<awygle>
Yeah that's more or less what I was thinking
<azonenberg>
then divide by say 16 to get the actual sampling phase angle
<azonenberg>
also i finished schematic last night
<awygle>
It's not_constant_ transitions with 8b/10b though is it?
<azonenberg>
gonna try and go through the schematic design review over the next few minutes when i start work
<azonenberg>
before i start work*
<azonenberg>
then layout tonight
<awygle>
So there's probably some complexity there
<azonenberg>
there's no 8b10b
<azonenberg>
10baseT is Manchester, always a transition in the middle of a bit, sometimes between them
<azonenberg>
100baseT is 4b5b over MLT-3
<azonenberg>
Which has a minimum of two transitions per five bits
<azonenberg>
you can see how manchester is kind of a form of PSK
<azonenberg>
http://thanatos.virtual.antikernel.net/unlisted/Screenshot4.png this is zoomed out 100baseT showing the 3-level waveform and the constant transitions, looks like i caught a few brief spots where it was 3 bits in a row the same but thats it
<azonenberg>
This board is gonna be pretty silly looking, lol
<azonenberg>
one FPGA, one triple-output LDO
<azonenberg>
empty footprint for a SPI flash that i probably wont populate
<azonenberg>
Two RJ45s, six SMA connectors
<azonenberg>
and a bunch of passives :p
<openfpga-github>
[yosys] azonenberg pushed 12 new commits to master: https://git.io/vdOzq
<openfpga-github>
yosys/master 64ca0be combinatorylogic: Adding support for string macros and macros with arguments after include
<openfpga-github>
yosys/master 2cc0916 Clifford Wolf: Fix ignoring of simulation timings so that invalid module parameters cause syntax errors
<awygle>
You described the multi contact ring, I looked up at the scope on my desk, thought "nuh uh", and then you posted a picture of my scope. Efficient.
<rqou>
or being unable to figure out how to obtain the source code of libudev
<rqou>
(which i have rewritten the code to not require, except azonenberg still hasn't tested it to his satisfaction)
<rqou>
which reminds me that it would be really nice if somebody who both has a greenpak devkit and regularly runs a "more systemd-infested" distro would test https://github.com/azonenberg/openfpga/pull/93
<azonenberg>
more invested than debian?
<rqou>
yeah, i was thinking e.g. fedora
<azonenberg>
infested*
<azonenberg>
and its not that i havent tested to my satisfaction
<azonenberg>
i havent tested whatsoever :p
<rqou>
well, i've tested it :P
<azonenberg>
Yay for being overloaded during Q4
<rqou>
but only on not-as-systemd distros
<rqou>
i.e. debian and android
<rqou>
yes, it works on (rooted) android
<rqou>
making it work without root is an exercise for the reader :P
<rqou>
also azonenberg i sent you that PR before Q4, so that's not a good excuse :P :P
ZipCPU|Laptop has joined ##openfpga
<azonenberg>
Yeah, but the con talk is :p
<azonenberg>
i'll test it as things settle down, thats all i can promise
<azonenberg>
my multitude of obligations are slowly dialing down
<rqou>
you do realize i sent you that PR back in june, right? :P