_whitelogger has joined ##openfpga
unixb0y has joined ##openfpga
_whitelogger has joined ##openfpga
mumptai_ has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
mumptai has quit [Ping timeout: 272 seconds]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
soylentyellow has joined ##openfpga
rohitksingh_work has joined ##openfpga
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
azonenberg_work has quit [Ping timeout: 244 seconds]
azonenberg_work has joined ##openfpga
pointfree[m] has quit [Ping timeout: 255 seconds]
thehurley3[m] has quit [Ping timeout: 256 seconds]
AlexDaniel-old[m has quit [Ping timeout: 252 seconds]
indefini[m] has quit [Ping timeout: 240 seconds]
Wallbraker[m] has quit [Ping timeout: 276 seconds]
nrossi[m] has quit [Ping timeout: 276 seconds]
jfng has quit [Ping timeout: 276 seconds]
Wallbraker[m] has joined ##openfpga
AlexDaniel-old[m has joined ##openfpga
thehurley3[m] has joined ##openfpga
nrossi[m] has joined ##openfpga
pointfree[m] has joined ##openfpga
jfng has joined ##openfpga
indefini[m] has joined ##openfpga
<azonenberg_work> Why do NP-hard problems make such fun games? Lol
* azonenberg_work discovered gplanarity and it's providing a fun distraction from the work i'm supposed to be doing
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
massi has joined ##openfpga
Miyu has joined ##openfpga
mumptai_ has quit [Ping timeout: 268 seconds]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_wor1 has quit [Client Quit]
rohitksingh_work has quit [Ping timeout: 268 seconds]
pie__ has joined ##openfpga
awygle has quit [Quit: No Ping reply in 180 seconds.]
pie_ has quit [Ping timeout: 244 seconds]
awygle has joined ##openfpga
pie__ has quit [Ping timeout: 244 seconds]
pie_ has joined ##openfpga
<gruetzkopf> now i kinda want to know how well it behaves on my 23" touchscreen (which i have strictly for testing PLC HMIs)
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 252 seconds]
[X-Scale] is now known as X-Scale
<q3k> azonenberg_work: gah, had to stop myself from sinking time into gplanarity
<q3k> azonenberg_work: good game tho
rohitksingh has joined ##openfpga
<awygle> how did we get to the point where an ubuntu iso is 1.8gb
mumptai has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
<whitequark> awygle: what's the problem
<awygle> my internet is slow is all
<whitequark> oh
<awygle> actually i think it's the ubuntu server, i should have used the torrent instead
massi has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
<gruetzkopf> even debian netinst doesnt fit 150M anymore :(
<sorear> back when I did that, it was 6 1440KiB floppies
<q3k> awygle:
<q3k> q3k@anathema ~ $ du -hs Downloads/ubuntu-18.04-live-server-amd64.iso
<q3k> 807MDownloads/ubuntu-18.04-live-server-amd64.iso
* azonenberg_work fondly remembers the day back in grad school
<azonenberg_work> where he downloaded the ubuntu 10.04 (I think?) CD image
<azonenberg_work> ... in 7 seconds
<q3k> mini.iso 100%[==========================================>] 64.00M 26.2MB/s in 2.4s
<q3k> 2018-08-27 17:53:21 (26.2 MB/s) - ‘mini.iso’ saved [67108864/67108864]
<q3k> 2.4 seconds here
<azonenberg_work> q3k: this was full cd
<azonenberg_work> ~700M
<azonenberg_work> after TCP and HTTP overhead i was close to maxing out a gig link
digshadow has quit [Ping timeout: 252 seconds]
mumptai has quit [Quit: Verlassend]
<awygle> q3k: desktop. and i tried mini, but it just moves the problem to later.
rohitksingh has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<rqou> whee, i love how YCantPark is still a problem 10+ years later
<awygle> what is YCantPark?
<rqou> back in 2005 it was a flickr tag of photos of people parking poorly in Yahoo's parking lot
<rqou> and now in 2018 the poor parking still happens
<whitequark> water wet
<rqou> lol
<qu1j0t3> somebody must be working on a tyre clamp bot
mumptai has joined ##openfpga
<openfpga-bot> [jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fAOEk
<openfpga-bot> jtaghal/master 6d0da0d Andrew Zonenberg: Initial (untested in hardware) HS2 support
<rqou> azonenberg_work: HS2?
<rqou> oh yet another jtag dongle
m_t has joined ##openfpga
<azonenberg_work> rqou: the digilent hs1 dongle i have now is ft2232h based
<azonenberg_work> the hs2 is, i believe, ft232h based
<azonenberg_work> and has a slightly different output enable structure
<azonenberg_work> I also needed a jtag dongle right now and didnt have time to dig through boxes to find my hs1 or DIY'd dongles :P
<whitequark> azonenberg_work: something something glasgow
<whitequark> i havent used a programmer or adapter since i made this thing :P
<rqou> whee, today at work I've been spending the whole day trying to get people to give me access to stuff
<azonenberg_work> whitequark: i dont have a functional soldering setup now
<azonenberg_work> If somebody gives me one i will pay BOM cost plus a fair addition for assembly
<azonenberg_work> But i can't build one
<rqou> azonenberg_work: how about you finish your friggin sheetrock? :P
<rqou> or have you maxed out your negative PTO?
<whitequark> azonenberg_work: sure, i need to figure out the goddamn signal integrity issues though
<azonenberg_work> whitequark: yeah and i'll use the digilent dongle until i get one :p
<azonenberg_work> rqou: i am -24 hours on PTO right now so i'll be back to zero by... early November I think?
<azonenberg_work> (I get 5 hours every 2 weeks)
<azonenberg_work> rqou: And ally is downstairs taping and mudding joints in the lab right now while i work
<rqou> ah ok
<sorear> signal integrity issues?
<prpplague> rqou: so elinux.org is back up, so you can see some of the other toy hacks now
<prpplague> rqou: https://elinux.org/Pixter
<whitequark> sorear: glitches on the cypress bus
<azonenberg_work> rqou: After taking this picture i hung a bit more rock on the wall by the breaker panels, leaving the area right around each panel open so i could fan out the wqire
<whitequark> oh
<azonenberg_work> We're going to finish taping and mudding this, probably hang one more row of panels on the ceiling
<whitequark> oh i had a thought.
<azonenberg_work> Do a bit more over the doorway
<whitequark> awygle: so you remember that thing about the pci bus
<azonenberg_work> Then sand it all down, make it nice and smooth, prime, and paint
<azonenberg_work> Once it's painted hang the cable trays
<awygle> whitequark: yyyes? mostly
<azonenberg_work> Then start wiring up whatever i can reach from the first ~25 feet of tray
<whitequark> that it's deliberately unterminated and driven by reflection of the signal doubling over on itself
<awygle> yes
<whitequark> awygle: i wonder if we could have something like this because this would explain why i narrowed down the faults to specific bit patterns on the bus and the faults are different depending on the way i shuffle bits
<whitequark> this could *also* be a timing issue, i'm not sue
<whitequark> *sure
<awygle> whitequark: so the glitches are on the Cypress bus, that is, the parallel FIFO between the FX2 and the ice40up?
<whitequark> awygle: pretty sure.
<whitequark> there might not actually be any glitches on the level shifter buses.
<whitequark> i discovered this while trying to add audio to my cgb grabber
<whitequark> i made a hdl block that just generates sawtooth
<whitequark> if i stub it out to generate zeroes then everything'sfine
<whitequark> if i turn it on, i get horrifying video glitches
<whitequark> i stuffed the audio channel in the low (or high) two bits of the rgb bytes so as to not change timing
<whitequark> as in capture timing
<whitequark> the glitches are really strange and the most sensible explanation i have is bitflips on the bus
<whitequark> this could either be a signal integrity problem or a timing problem
<rqou> why are you still working on this cgb grabber?
<whitequark> rqou: a) i promised to make it for melissa b) it has been exceptionally prolific at finding bugs in glasgow gateware
<whitequark> choose any subset you like
<whitequark> it's like
<whitequark> it's like an analog oscilloscope in the sense of how it visualizes junk on the bus
<whitequark> because you instantly see if you have, say, a periodic bitflip on a certain bit
<whitequark> daveshah: so, hm
<whitequark> is there anything i can do in nextpnr to constrain a parallel bus
<whitequark> other than using the builtin SB_IO registers which didn't work for some reason
<whitequark> oh yeah, empty/full signal latency rises
<daveshah> No, not currently at least
<daveshah> I think we will add IO timing constraints in the future
<whitequark> well you better add them lol
<whitequark> but ok, if there aren't any right now i have no choice
<daveshah> Just need to settle on a format, as much as anything else
<whitequark> tcl? :D
<daveshah> More like Python we think
<daveshah> Maybe with an sdc option in the future
<whitequark> i have two arguments against python
<whitequark> first, its runtime is global and not reentrant
<whitequark> so if i want to embed nextpnr, i have a massive headache and there's a good chance i have to do it out-of-process
<daveshah> Yes, we discussed the latter
<whitequark> a sub-argument is that if you ever want to provide prebuilt binaries it becomes an ABI nightmare
<daveshah> I do suspect that sdc is a better option
<whitequark> second, it's not sandboxed
<rqou> why would you want it to be sandboxed?
<daveshah> Given it is possible to build nextpnr without Python
<daveshah> Web platforms, etc
<awygle> what is sdc in this context?
<whitequark> rqou: why wouldn't I?
<daveshah> awygle: Synopsys design constraints
<daveshah> Most vendors use something based on them
<awygle> o
<awygle> ok
<rqou> because you're already running code when you invoke nextpnr, so there's no point in making you less able to run code
<daveshah> The other option is to just extend the pcf format we have already
<whitequark> sdc is basically tcl, right?
<rqou> replace nextpnr with any equivalent tool
<daveshah> yes, I think so
<whitequark> ok
<whitequark> i'm fine with tcl or lua
<daveshah> Although I'm not sure if all sdc parsers are actually tcl interpreters
<whitequark> i mean i think tcl is distasteful from pl design pov but this isn't the most important thing
<awygle> i don't really understand why this is a turing-complete kind of task
<awygle> but ok
<daveshah> VPR at least uses a sdc parser
<daveshah> I think we would go that route rather than tcl too
<whitequark> oh, kinda like how parsing bsdl doesn't always involve a full ada parser
<whitequark> ok that makes sense
<whitequark> i like the sdc route
<awygle> +1
<rqou> -1, but I've basically given up on convincing other people to write libraries the way i want
<whitequark> rqou: what would you do here
<daveshah> FWIW whatever we do the Python API should be able to set constraints too, as it should be able to manipulate anything
<daveshah> It's more about what we recommend and what has a nice interface
<sorear> if we keep adding deps to nextpnr we can make it a 20GB download like the real tools
<rqou> in a perfect world given infinite time? step -1) use Rust 0) write more magic to autogenerate FFIs for Rust 1) think very hard to create some reasonably-stable data structures for expressing constraints 2) expose all data structures via the FFI, allowing the hosting language/environment to make changes at any point
<daveshah> For the Python API to be useful for constraints it would certainly need some shorthand functions
<rqou> and basically have the tool be a library with the "compiler driver" type of logic live in your favorite scripting language
<etrig> recommend bundling no less than three java virtual machines
<rqou> no problem, my ideal magic FFI generator can support Java too
<awygle> that actually sounds pretty good. i'd use something like protobuf or cap'nproto or flatbuffers or whatever for the "magic ffi" part, probably, so i wouldn't have to write it. but yeah that doesn't sound half bad
<rqou> the only problem is that this magic FFI is pretty tricky to create at this point in time because of how the rust procedural macro system works
<whitequark> i like rust but i would probably not write nextpnr in rut
<whitequark> because nearly everyone working in this domain uses c++
<awygle> huh, that's surprising to hear
<whitequark> the same as i wouldn't write or rewrite solvespace in rust
<whitequark> awygle: really? glasgow doesn't use rust either, and for similar reasons
<rqou> well I've found that "nearly everyone else" is also acting in bad faith enough that i don't really care what they're using
<whitequark> that's approaching some sort of conspiracy theory
<rqou> well, all involved parties have refused to clarify
<whitequark> fpgagate
* whitequark hides
<awygle> yeah but basically everybody who cares about security (read: not me) seems to think that writing software in C and C++ is criminal negligence or very close to it
<awygle> glasgow uses python which is also not C or C++, and sdcc C for the FX2 but there's no alternative there
<whitequark> neither nextpnr nor solvespace are in any way security-critical
<whitequark> i mentioned sandboxing before but only because i don't want someone else's shitty scripts to break when they can't open /home/dude/data.bin
<awygle> solvespace, i figured you just didn't want to rewrite (which makes total sense to me). but for new builds i would have guessed the rust benefits would beat out the "other people know c++" benefit
<awygle> clearly i was wrong
* awygle updates priors
<whitequark> i have an extremely hard time finding anyone to work on solvespace to work as it is
<rqou> anyways whitequark I've spelled out what's going on the way i see it, and this is in the backlog. you are free to dispute/discuss it
<whitequark> on the geometric kernel anyway
<whitequark> if it was written in rust i don't think i would have been able to
<awygle> that is probably true
<rqou> but for now I'm sticking with my recommendation to not work with m!thro, d!gshadow, or symbioticeda
<whitequark> it's not necessarily true
<whitequark> i *think* it's true
<whitequark> and i'm not about to invest a lot of my time to prove it false
<rqou> also whitequark i _specifically_ want scripts to be able to open /home/dude/data.bin
<rqou> that's how i glue a lot of random crap together
<whitequark> i'm going to call my software "rqou-proof" from now on
<whitequark> because not being able to make the abominations you do is a feature
<rqou> hey, if two tools really don't want to be able to talk to each other, but both can open files, this works
<whitequark> that's how you end up with "and this script requires openssl 0.9.8c to be installed in /opt/foo"
<awygle> if i keep listening to people talk about API design and software licensing i'm going to end up writing a manifesto, and nobody wants that
<rqou> awygle: as long as it doesn't end up titled "Industrial Society and Its Future" then go for it :P
<rqou> whitequark: so? it's in /opt so it's not like other code will be using it
<whitequark> see this is the kind of shit i am talking about
<whitequark> if industrial society gives us the power to put random shit in /opt, maybe kaczynski was right.
<rqou> wat
<fouric> out of curiosity, is there anything about nextpnr, yosys, etc. (more generally FPGA tools as a whole) that actually _requires_ C/C++-specific features like raw pointers?
<fouric> i assume not but i've never actually read the source
<whitequark> fouric: not really
<whitequark> well
<whitequark> it's not a well-formed question
<whitequark> python has perfectly good raw pointers
<whitequark> but to answer the question you wanted to ask, no, it'd be straightforward to implement yosys or nextpnr in ocaml
<fouric> perfect example
<fouric> ty
<whitequark> amusingly, this is less true for rust, because idiomatic rust and graph manipulation do not go together very well
<fouric> lol
<fouric> have a sec to elaborate?
* fouric is curious
<rqou> worksforme
<digshadow> whitequark: the way I see it, C++ is mostly b/c its higher performance than python, and has good community following, for better or worse
<whitequark> fouric: any time you have cycles in object ownership graph you have to introduce some sort of an abstraction
<digshadow> although I did recent C++, and was pleasantly surprised to see it had grown a lot since last time I had used it
<fouric> everything is higher performance than python
<rqou> but then my code so far didn't really operate on graphs with fancy graph algorithms
<whitequark> and last time i looked these abstractions were pretty awkward
<gruetzkopf> *scroll* someone said pci?
<daveshah> Certainly when I've done routing graph stuff for ecp5 with lots of small elements, Python was maybe 3x slower and 4x more memory than C++
<whitequark> digshadow: yep that's how I understood it
<azonenberg_work> whitequark: re twitter thread, https://www.ezebreak.com/
<whitequark> christ americans keep sending me these things
<azonenberg_work> It's regulated a "special explosive device"
<azonenberg_work> UN 0323
<azonenberg_work> tl;dr you have to register with your name and contact info to purchase it but that's it
<sorear> prime #nocontext above
<azonenberg_work> It's not regulated like normal blasting materials because it's powered by smokeless powder, which is considered a propellant and not a high explosive
<azonenberg_work> The other cool blasting technology i'm aware of, although i dont know the regulatory environment for it, is Cardox
<azonenberg_work> It's a cartridge of liquid CO2 that's warmed by a heating element until it vaporizes, the resulting pressure acts like an explosive
<azonenberg_work> but it's a purely physical change, no combustion or excessive heat production
<azonenberg_work> So you can actually use it to blast underwater, in flammable atmospheres, etc
<zkms> heh that's cute azonenberg
<sorear> The kids in school mostly just used solid CO2 for that
<gruetzkopf> i like to store solid CO2 in PET preforms for that
<azonenberg_work> sorear: yeah but a suddenly boiled liquid will give a more rapid pressure rise as well as more predictable, controllable expansion
<azonenberg_work> Dry ice will slowly boil off but then you basically have to wait for the container to burst
<gruetzkopf> some of them are stable enough to get a liquid phase if it's below 0c outside
<azonenberg_work> you cant control when it goes off and it's hard to melt it rapidly
<azonenberg_work> vs a liquid you can have a distributed heating coil etc
<azonenberg_work> and heat all of it at once
<gruetzkopf> (the multi-use PET bottles common in germany are good to ~12 bar)
<azonenberg_work> yeah and thats fine if you're a kid trying to make noise
<azonenberg_work> Just less effective if you want to blow up one particular thing at a precise time
<azonenberg_work> (a lot of commercial blasting involves multiple shots with fairly tightly controlled timing between them)
<digshadow> azonenberg_work: now ##explosives?
<zkms> tbh the liquid CO2 + heater thing reminds me of magnet quench
<azonenberg_work> digshadow: more like ##technically-not-explosives
<azonenberg_work> :p
Miyu has quit [Ping timeout: 264 seconds]
GenTooMan has joined ##openfpga
digshadow has quit [Ping timeout: 244 seconds]
mwk has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
mwk has joined ##openfpga
<openfpga-bot> [jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fAOF9
<openfpga-bot> jtaghal/master dbcfeb1 Andrew Zonenberg: Initial skeleton of SWD support classes.
<whitequark> azonenberg_work: is there anything a powder powered tool can achieve
<whitequark> that can't be achieved more easily with a vacuum pump and a piece of foil?
dx- has joined ##openfpga
dx has quit [Ping timeout: 268 seconds]
dx- is now known as dx
xdeller has quit [Remote host closed the connection]
xdeller has joined ##openfpga
WilhelmVonWeiner has joined ##openfpga
<azonenberg_work> whitequark: multiple shots in quick succession? Usage at awkward angles were a hose would be problematic?
<azonenberg_work> generally smaller and lighter, requires less infrastructure to operate
<azonenberg_work> Changing out burst disks for every shot seems like it would be really awkward
<azonenberg_work> Performance wise a vacuum cannon should be able to easily hit the ~300 FPS typical nail velocity of a powder tool
<whitequark> azonenberg_work: i guess that's true
<whitequark> but uh
<whitequark> changing burst disks ~ changing cartridges, no?
<awygle> whitequark: re: smoltcp - for your tun/tap benchmark, that's linux-to-smoltcp, right?
<whitequark> awygle: yeah
<whitequark> btw it's much faster now
<awygle> o
<whitequark> we have window scaling
<awygle> ... how much faster? lol
<whitequark> a few times faster
<whitequark> i think
<awygle> damn
<awygle> do you have a linux-to-linux number for that benchmark, for comparison?
<rqou> still need ipv6 and slip/ppp :P
<gruetzkopf> hehe
<gruetzkopf> i ran DN42 to my palm m515 over SLIP over IrDA last year
<whitequark> awygle: nope, haven't measured it myself
<whitequark> rqou: it has ipv6
<whitequark> i think it doesn't have SLAAC yet
<whitequark> but it has ipv6
<whitequark> for quite long time actually
<rqou> oh, it's done?
<awygle> whitequark: okay, thanks. i may do that, if i do i'll let you know
<gruetzkopf> (and to a palm 3 via irda and serial)
<rqou> what about non-ethernet transports?
<gruetzkopf> the m515 has seen a bluetooth sdio card and a bluetooth V.92 modem...
<whitequark> rqou: nope, no non-ethernet transports
<whitequark> and in fact much of the IP infrastructure is bolted onto the ethernet transport
<whitequark> for complicated reasons
<whitequark> that mostly have to do with the fact that TCP/IP is shit
<gruetzkopf> are you nailed to *ethernet* transports or only to 802 transports?
<gruetzkopf> also: LLC support?
<rqou> IPoIB? :P
<gruetzkopf> (for working over 802.5)
<whitequark> ethernet
<whitequark> 802.3 and 802.1 are not supported
<whitequark> but those would be easy to add
<whitequark> 802.1Q, anyway
<whitequark> it's very detailed.