azonenberg_work has quit [Ping timeout: 265 seconds]
<balrog> rqou: your statement there reminds me of this rather controversial video: http://pyvideo.org/pycon-us-2012/stop-writing-classes.html
pie_ has quit [Ping timeout: 240 seconds]
<awygle> dang, that was good
<awygle> i'm not sure it actually argues for your point, but it was good
<gruetzkopf> https://i.imgur.com/qJ1V3Hd.jpg so this is why electrical work in the usa has govt inspections
azonenberg_work has joined ##openfpga
<rqou> gruetzkopf: that looks ok by US standards
<gruetzkopf> those twist-on thingies are available here, but i've never seen them in an actual install
<gruetzkopf> mostly (wago or clone) push-on or latched spring loaded connector blocks
<gruetzkopf> wago 2273 series is my current favourite for single-conductor, fixed install
azonenberg_work has quit [Ping timeout: 240 seconds]
<rqou> aaargh rust tends to use way way too much stack-space
unixb0y has quit [Ping timeout: 264 seconds]
unixb0y has joined ##openfpga
<awygle> What's the difference between a heartbeat and a watchdog? If any?
<sorear> a heartbeat is what a watchdog looks for
<awygle> I feel these metaphors are badly mixed
<awygle> I guess it depends on whose heart is beating
<awygle> Some sort of criminal, presumably?
<sorear> some people have dogs trained to react to medical emergencies
<sorear> idk
<rqou> proposal to rename watchdog to watchpupper :P
GenTooMan has quit [Quit: Leaving]
<awygle> LifeAlertDog
<rqou> watchdoge :P
<rqou> wow
<rqou> very kick
<rqou> much no crash
<awygle> "kick"? I am familiar with "stroke" as the idiom. what kind of monster kicks a watchdog?
<rqou> huh, I've always seen "kick"
<awygle> I guess "stroke the dog every time your heart beats" is not a bad way to live :-P
<awygle> yeah I've seen stroke and pet, never kick
<awygle> except that the watchdog might kick something when it goes off I guess
<rqou> anyways, does anyone (whitequark?) know of a rust/llvm/whatever worst case stack usage estimator
<whitequark> nope
<whitequark> actually, hang on
<Xark> (I have never seen stroke or pet in real code...)
<whitequark> rqou: AHA
<whitequark> -mllvm -stack-size-section
<whitequark> The section simply contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128).
<awygle> :-( okayyyy
<whitequark> rqou: there's also -warn-stack-size
<whitequark> I think
<whitequark> yeah
* awygle pets watchcats
noobineer has joined ##openfpga
<rqou> awygle: watchcats will just shove your code off of the edge of ram and make it crash faster :P
noobineer has quit [Ping timeout: 245 seconds]
<rqou> ugh, i hate how max v has essentially "lower" and "upper" parts of tiles that have limited ways to connect between them
<gruetzkopf> >pcie multicast
<gruetzkopf> cursed technology
<rqou> dafuq?
<gruetzkopf> new fun stuff from the pcie as generic system to system fabric fraction
<gruetzkopf> multi-root pcie switches are *fun*
<rqou> i didn't even know that was allowed
<gruetzkopf> only with these specialty switches
<gruetzkopf> and nontransparent bridges which can do address translation and stuff like that
<gruetzkopf> (did i ever tell you the fun things you can do with a firewire link and the iommu page fault handler?
<sorear> somehow i did not realize PCIe NAT was a thing
<pointfree> 21:09 <balrog> pointfree: I'm curious, anything new on the PSoC side of things?
<pointfree> 05:29 <rqou> pointfree: current status of psoc?
<pointfree> Not recently, except for some improvements to the docs on psoctools.org and familiarizing myself with yosys, etc code a bit more. I'm currently busy acquiring equipment I need for my lab-in-a-storage-locker.
<gruetzkopf> plx-avago-broadcom has BIG switches with 24ports@16lanes and address translation tables for each of them
<gruetzkopf> for top-of-rack pcie switches
<rqou> pointfree: is every bit understood at this point?
scrts has quit [Ping timeout: 264 seconds]
<kc8apf> I built a PCIe system fabric with NTBs a few years ago. 8 machines booting off a single NIC split with virtual functions was trippy
<rqou> ooh right, virtual functions exist
<rqou> SR-IOV is a pretty neat idea
<rqou> whee, my tool no longer reports any left-going R4 wires as "unknown"
<rqou> meaning (assuming no bugs) the tool has encountered at least one bitstream with each left-going R4 used
<kc8apf> NTBs + SR-IOV == faux MR-IOV
<rqou> max v seems to have a very annoying balance of "how come this cannot be connected to that?" and "oh wait, most real designs will be route-able"
<gruetzkopf> VFs on nics can be very useful but also very annoying (in case the nic does not provide a mac per VF and therby confuses the next switch)
<feuerrot> gruetzkopf: firewire + iommu? -v
<gruetzkopf> okay. suppose you have a device and want to connect it to your laptop. the power usage and form factor were not conductive to being used with The AdapterTM. so you hack up your linux kernel to forward PIO writes and reads via fw dma. this gets you up to enumeration
<gruetzkopf> now, interrupts are interesting. you catch them in the device you're hosting the card in, then DMA into iommu-unmapped address space of the laptop. in the iommu page fault handler, you can now fake your interrupt
<gruetzkopf> similarly for PCI device originated DMA, you point it to unmapped space, and catch that in the page fault handler of the hosting box
<gruetzkopf> it's *extremely* slow, but works
<rqou> wtf
<gruetzkopf> all that hax because we don't have a nice, coherent laptop<->big box interface
<gruetzkopf> i want the multi-gigabyte-per-second 2-fiber optical fabric they promised me in 200x
rohitksingh has joined ##openfpga
<feuerrot> rqou: justgruetzkopfthings
<rqou> lol
<feuerrot> who else would connect a railway control center via wireguard and some fancy SPS hardware to dn42?
scrts has joined ##openfpga
<rqou> oh wut i hope this isn't a bug
<rqou> some down wires from the top io cells seem to only stretch one tile?
<rqou> or at least according to the coordinates
<rqou> then again it might just be fucky coordinates
<rqou> hmm, seems the wires really are short
rohitksingh has quit [Quit: Leaving.]
bitd has joined ##openfpga
rohitksingh has joined ##openfpga
pie_ has joined ##openfpga
ZipCPU_ has quit [Ping timeout: 264 seconds]
bitd has quit [Ping timeout: 245 seconds]
<pie_> something something mathematics is the only way
<pie_> <rqou> the problems mostly seem to be of the form "frameworks are very hard and tend to make 90% of tasks easy and the remaining 10% impossible"
bitd has joined ##openfpga
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh has joined ##openfpga
ZipCPU_ has joined ##openfpga
Bike is now known as Bicyclidine
genii has joined ##openfpga
Bike has joined ##openfpga
ZipCPU has joined ##openfpga
ZipCPU has quit [Ping timeout: 264 seconds]
ZombieChicken has joined ##openfpga
<mithro> Morning everyone!
<awygle> o/
* cr1901_modern respects UGT and says "morning!"
<mithro> cr1901_modern: Have you had any luck with the lm32 on the ice40?
<cr1901_modern> No, and I haven't touched it this week tbh, due to a number of other things needing attending that I put off. I'll try my last few options either this weekend or early next week.
<cr1901_modern> mithro: ^
<mithro> cr1901_modern: It might be good to get it into a state that someone else can repo
<cr1901_modern> repo as in reproduce?
<mithro> cr1901_modern: Yes
<mithro> cr1901_modern: Get other people to look at it
<cr1901_modern> daveshah was able to reproduce on ice5k board
<daveshah> yeap
<cr1901_modern> tinyfpga said he'd look at it on his end when he has time; I pointed him to a repo of my findings
<cr1901_modern> mithro: I have one last thing to try on my end (litescope probing). I have the wires set up, I just haven't built the bitstream yet
<cr1901_modern> daveshah: Is it possible you could make a PR for migen for the ice5k board?
<cr1901_modern> and litex*
<daveshah> cr1901_modern: sure, quite busy right now but might have time over the weekend
<cr1901_modern> daveshah: Understood, I'd do it myself, but I don't like to make PRs for boards I don't personally have
<cr1901_modern> just in case I missed something
<daveshah> cr1901_modern: yeah, I agree with that too. Just can't guarantee a time right now
<mithro> cr1901_modern: Do I need to send you a up5k board now too? :-P
<mithro> cr1901_modern: Didn't I send you a tinyfpga?
<cr1901_modern> mithro: Yes to tinyfpga, (poe's law) no need for up5k
<mithro> cr1901_modern: Oh, wait I forget that has an 8k not an 5k
<cr1901_modern> right, so we've determined that: * crash can be dup'd on 5k and 8k, dup'd across toolchains (icestorm and icecube)
<cr1901_modern> But I don't remember if the SPI flash bus activity is the same
<mithro> Wow
<cr1901_modern> on 5k and 8k
<cr1901_modern> I could reasonably file a tech issue w/ lattice :P
<mithro> cr1901_modern: Well, if the lm32 doesn't work in icecube on the up5k that would actually be interesting :-P
<daveshah> the 5k issue was skipping over branch instructions, not following them
<cr1901_modern> daveshah: Right, and _if_ I make a specific change to the output verilog for tinyfpga, I can duplicate that behavior
<cr1901_modern> w/ the default arachne-pnr seed, the CPU crashes b/c it decodes an invalid address range that goes nowhere. If I force this address range to go to SPI flash, the CPU continues at the normal location
<cr1901_modern> but skips over branches
<ZombieChicken> I have 2 questions: 1) Can you load code to an FPGA w/o having the FPGA save the code over reboots? 2) How long does it take to load code to an FPGA?
<mithro> ZombieChicken: (1) Yes - that is normally how you do it, (2) seconds -- depends on the method though
<cr1901_modern> daveshah: What's the name of the 5k board you use? Is it esden's board?
<daveshah> cr1901_modern: yeah, icebreaker
<ZombieChicken> mithro: Good to know. I was looking at FPGAs and most seem to have some nonvolatile storage and I just wanted to be sure that wasn't the only option available
<mithro> ZombieChicken: Some boards have the programmer connected to the flash rather than the FPGA -- these boards are silly
<mithro> ZombieChicken: For the tinyfpga it's require because of the fact it uses the FPGA *as* the programmer
<ZombieChicken> never heard of tinyfpga
<ZombieChicken> until today
<cr1901_modern> these boards are silly <-- I mean, there's no choice on ice40 arch I don't think. No JTAG
<ZombieChicken> cr1901_modern: You mean you have to load code into flash on ice40's?
<cr1901_modern> yes
<ZombieChicken> That's a shame
<cr1901_modern> well, that's not strictly true
<cr1901_modern> ice40 can read a bitstream directly from a host PC, but it can only do it on reset
<ZombieChicken> on chip reset?
<cr1901_modern> on FPGA reset yes
<ZombieChicken> guess that makes sense
<ZombieChicken> reset -> reload doesn't sound too bad
<ZombieChicken> unless the reset takes forever
<cr1901_modern> Nah, it's as fast as the SPI-enabled microcontroller/FTDI chip can talk to the FPGA
<ZombieChicken> Well, given I don't know too much about electronics and ICs, that doesn't mean too much to me
* cr1901_modern goes and pretends to be a productive member of society
<awygle> on the order of a hundred milliseconds (so, not less than 10 ms, not more than 1000 ms)
<awygle> except it can be arbitrarily slow if you make it be, of course. that's assuming best effort for speed
rohitksingh has quit [Quit: Leaving.]
<ZombieChicken> ok, ty
ZombieChicken has quit [Quit: Have a nice day]
azonenberg_work has joined ##openfpga
digshadow has joined ##openfpga
rohitksingh has joined ##openfpga
Miyu has joined ##openfpga
ZipCPU has joined ##openfpga
<rqou> whitequark: how can I actually pass mllvm flags to rust?
<rqou> putting it in RUSTFLAGS just gives "unrecognized option m"
<rqou> and there seems to be no documentation at all about this
rohitksingh has quit [Quit: Leaving.]
DocScrutinizer05 has quit [Remote host closed the connection]
DocScrutinizer05 has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<rqou> ugh rust is just not _quite_ good enough at having minimal copying of data around
<qu1j0t3> rqou: from a friend
<qu1j0t3> | -C llvm-arg
<qu1j0t3> | -C llvm-arg=foo
<qu1j0t3> hth
<rqou> wut
<rqou> and where do i pass that?
<rqou> e.g. `xargo build --release -C llvm-args=-stack-size-section` --> found argument -C which wasn't expected
<rqou> same with `rustc` instead of `build`
<rqou> and `RUSTFLAGS="-C llvm-args=-stack-size-section" xargo build --release` --> unknown command line argument '-stack-size-section'
<rqou> whitequark?
<qu1j0t3> yeah, it was RUSTFLAGS)
<rqou> well, that doesn't work either
j`ey has joined ##openfpga
<j`ey> what flag are you trying?
<qu1j0t3> rqou | and `RUSTFLAGS="-C llvm-args=-stack-size-section" xargo build --release` --> unknown command line argument
<qu1j0t3> | '-stack-size-section'
<qu1j0t3> looks like it might be a -- option?
<qu1j0t3> (long opt)
<rqou> nope
<j`ey> rqou: rust's version of LLVM doesn't have that flag yet
<rqou> lol ok
<rqou> thanks a lot whitequark /s
<j`ey> rqou: I think it's only a few days out too :/
<qu1j0t3> j`ey++
j`ey has left ##openfpga [##openfpga]
<rqou> ugh rusr really really is lacking in "plz no copy"
<rqou> *rust
<cr1901_modern> "xargo build --release -- -C llvm-args=-stack-size-section"?
<whitequark> rqou: what
<whitequark> you asked me about an llvm feature, i answered
<whitequark> if you want it in rust now, just rebuild your rustc
<rqou> sorry, i thought i said that I needed it to work with rust
<rqou> anyways, I'm probably not going to bother trying to rebuild rustc
pie_ has quit [Ping timeout: 260 seconds]
Ellied has quit [Quit: WeeChat 1.6]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
bitd has quit [Quit: Leaving]
ZipCPU has quit [Ping timeout: 260 seconds]
digshadow has quit [Ping timeout: 264 seconds]
GenTooMan has joined ##openfpga
pie_ has joined ##openfpga
pie__ has quit [Ping timeout: 240 seconds]
noobineer has joined ##openfpga
digshadow has joined ##openfpga
Bike has quit [Ping timeout: 260 seconds]
<azonenberg> awygle: btw i finished initial plane layout on the line card
<awygle> azonenberg: woo
<azonenberg> going to start design review today some time
<azonenberg> can you say swiss cheese? this is the back signal layer plus its reference plane
<awygle> it's not too bad for the signals that matter
<azonenberg> Nothing super fast is crossing plane splits (i.e. the SGMII)
<azonenberg> the JTAG is all over the place but i probably will never use it
<awygle> that second one from the top makes me nervous as to impedance
<rqou> why is rust so bad at "yes, every object has to take a trip through the stack"
<azonenberg> if i DO use it, i'll downclock as far as i need to
<azonenberg> Where? The adjacent power pour?
<rqou> this is awful for limited-stack environments
<azonenberg> at the bottom side of it?
<awygle> so do 5 and 6 actually, although less so
<azonenberg> or do you mean being close to the edge of the split
<azonenberg> in the ref plane?
<awygle> they run right next to big pours on their actual layer and right next to the split on the reference layer
<awygle> both
<azonenberg> yeah i'm still tweaking
<azonenberg> i also want to look at the 25 MHz clock nets
<azonenberg> and see if they're going places they shouldn't
<azonenberg> at that frequency i'm not super concerned about loop area though
<azonenberg> i have so many caps on the board
<awygle> my rule of thumb is 5x max(substrate thickness, trace thickness) from any big chunks of metal
<awygle> for microstrip
<azonenberg> yeah i want to make them further
<azonenberg> but the layout is pretty dense
<azonenberg> and i have to get power to the phys somehow :p
<awygle> yup
<awygle> on the plus side your narrow power traces probably have enough inductance you don't need ferrites :p
<azonenberg> narrow power traces? where
<azonenberg> those big fat planes?
<awygle> i'm just trolling
<azonenberg> Here's what i'm dealing with
<azonenberg> the big power pours are leapfrogging diffpairs on both layers
<awygle> yup
<azonenberg> So i don't really have room to make them move much further
<azonenberg> i suppose i could try and via one of the diffpairs to the top layer or something, but i'd have to go back at some point
<azonenberg> Since there isnt enough space on the board to put them all on one side
<azonenberg> i mean honestly we're probably being overly paranoid for 1.25 Gbps
<azonenberg> this isnt like hard microwave
<azonenberg> But i'll keep tweaking when i have time
<awygle> i take your point but like, the edge rate is gonna be pretty fast
<azonenberg> yeah agreed
<azonenberg> i'm far from ready for tapeout
noobineer has quit [Ping timeout: 268 seconds]
<azonenberg> awygle: also check the repo
<azonenberg> i just pushed a (WIP) mac table
<azonenberg> garbage collection isnt fully implemented
<azonenberg> And i'm still bringing it up in sim to do some debugging
<azonenberg> Gonna refactor a bit before i call it done
genii has quit [Remote host closed the connection]
Bicyclidine is now known as Bike
Miyu has quit [Ping timeout: 240 seconds]
<rqou> ok, I'm not sure if I'm seeing things, but I'm getting interesting behavior with a locked stm32
<rqou> if you attach the debugger, it should lock out flash, right?
<rqou> why does my uart loopback isr still appear to function?
<rqou> no hmm, something else is going on
<rqou> nope, false alarm
<rqou> seems to be crosstalk from the uart tx pin to rx pin
<jn__> o.O
<sorear> ~rf~
pie__ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
* cyrozap ducks
<jn__> >Nuclear reactors
<rqou> i mean, china can build nuclear reactors too
<sorear> Almost certainly safer than ours
<awygle> didn't china buy a bunch of terrapower stuff?