m_t has quit [Quit: Leaving]
<rqou> wow, the stm32 svd actually has lots of errors
<whitequark> rqou: wait until you try to use their silicon
<rqou> i've already experienced "i2c v1 basically is unusable"
<rqou> everything else seems to work so far?
<whitequark> a few years ago an acquaintance tried to use an STM32L1 chip and found like three errata off the bat
<whitequark> i'm not sure if they test these things
<rqou> i personally haven't hit any other than i2c
<rqou> wtf, exactly how many endpoints/fifos/etc does the stm32 usb blocks have?
<rqou> none of the sources of info agree with each other
<whitequark> lol
<rqou> ok, whose silicon do you prefer then?
<whitequark> the STM32F series is much less buggy
<rqou> er, i'm looking at the F4 right now
pie_ has quit [Ping timeout: 240 seconds]
<whitequark> okay
<whitequark> you haven't said that :p
m_w has quit [Quit: Leaving]
<digshadow-c> does anyone follow this guy by chance? http://www.deepchip.com/ Just found his site and there are a number of interesting rants about this tool or that
m_w has joined ##openfpga
unixb0y has quit [Ping timeout: 256 seconds]
unixb0y has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
digshadow has joined ##openfpga
<cr1901_modern> digshadow: "In Unrelated News" Indeed http://www.deepchip.com/items/0580-01.html
<cr1901_modern> Also the Web 1.0 layout isn't endearing
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 240 seconds]
digshadow has quit [Ping timeout: 240 seconds]
digshadow-c has quit [Read error: Connection reset by peer]
Bike has quit [Quit: Lost terminal]
m_w has quit [Quit: leaving]
digshadow-c has joined ##openfpga
digshadow has joined ##openfpga
indy has quit [Read error: Connection reset by peer]
indy has joined ##openfpga
<rqou> i finally figured out why my system was performing like shit under memory pressure
<rqou> somehow nautilus kept trying to read stuff and getting stuck and repeatedly filling up the disk cache
<rqou> or not?
<rqou> hmm
<rqou> ugh, rustc really needs to work on their ram usage, and i really need to buy more ram
<whitequark> they do
<whitequark> try -C codegen-units=4
<whitequark> instead of the default of 16
<rqou> hmm, i wonder if that will fix my xc2bit crate being impossible to build in release mode
<awygle> just add a huge swap file
<rqou> i don't think that will work
<rqou> xc2bit seems to be triggering a bug or suboptimal codepath
<rqou> it needs >20gb of ram
<rqou> whitequark: if you have spare time, maybe you can look into this? https://github.com/rust-lang/rust/issues/45457
<awygle> i was mostly trolling. although that is how i got LLVM to build for a while.
<sorear> rqou: you could probably bisect hunks in there to get a smaller failing case, and -Z time-passes will give some idea of what broke
<rqou> sure
<rqou> but that takes effort, and right now i can get away with ignoring the problem
<rqou> i already bisected down to a single commit
<rqou> also arrgh there appears to be no way to cram together multiple svd2rust outputs into a single crate
<rqou> fwiw some rust people did attempt to repro it, and it appears to repro for them as well
<sorear> throw creduce at it? :P
<awygle> rustreduce, surely?
<awygle> ... okay that was terrible even for a shitpost, i'm going to bed.
<whitequark> rqou: oh 20gb of RAM is bad
<whitequark> rqou: oh well duh disable LTO
<whitequark> or use nightly rust that uses ThinLTO
<whitequark> pass -Z thinlto to rustc
<whitequark> oh nvm it's enabled by default already
_whitelogger has joined ##openfpga
mithro has quit [Ping timeout: 240 seconds]
mithro has joined ##openfpga
reportings has joined ##openfpga
reportingsjr has quit [Ping timeout: 256 seconds]
pie_ has joined ##openfpga
m_t has joined ##openfpga
soylentyellow has quit [Ping timeout: 240 seconds]
Bike has joined ##openfpga
soylentyellow has joined ##openfpga
soylentyellow has quit [Ping timeout: 265 seconds]
ZipCPU|Alt has joined ##openfpga
ZipCPU has joined ##openfpga
soylentyellow has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
ZipCPU|Alt has quit [Quit: Cap'n! The dilithium crystals are ...]
keith-man has joined ##openfpga
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 268 seconds]
<gruetzkopf> 20G ram is not much of a problem :>
<sorear> >20G
<sorear> could be 2000G for all we know
eduardo has joined ##openfpga
ZipCPU has quit [Ping timeout: 268 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<pie___> mfw you look at it and immediately diagnose as too cold for shift registers https://twitter.com/FauthNiklas/status/968205965442117632
gnufan has quit [Ping timeout: 256 seconds]
gnufan has joined ##openfpga
ZipCPU has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
ZipCPU|Alt has joined ##openfpga
user10032 has joined ##openfpga
keith-man has quit [Ping timeout: 245 seconds]
ZipCPU|Alt has quit [Quit: Cap'n! The dilithium crystals are ...]
eduardo_ has joined ##openfpga
eduardo has quit [Ping timeout: 248 seconds]
noobineer has joined ##openfpga
m_w has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]
ZipCPU has quit [Ping timeout: 256 seconds]
<daveshah> Laughing pretty hard at Lattice's Radiant - their GUI developer clearly looked up "CRAM" (configuration RAM) in a generic non-FPGA tech dictionary and therefore in the Programmer it's called "Compressed Random Access Memory"...
ZipCPU|Alt has joined ##openfpga
ZipCPU has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
ZipCPU|Alt has quit [Client Quit]
<awygle> wow
<pie___> OOPS
indy has quit [Ping timeout: 240 seconds]
indy has joined ##openfpga
genii has quit [Remote host closed the connection]
stefanct has quit [Read error: Connection reset by peer]
stefanct has joined ##openfpga
stefanct has joined ##openfpga
stefanct has quit [Changing host]
<qu1j0t3> :<
noobineer has quit [Ping timeout: 260 seconds]
<mithro> morning everyone
<mithro> daveshah: So - do you think you could fit https://github.com/SpinalHDL/VexRiscv onto one of your newer supported ice40 devices?
<daveshah> Yes definitely
<mithro> daveshah: Now for the hard one - do you think you could get the config which supports Linux? :-P
<daveshah> And the ultraplus is ideal for SoCs as it has 128kByte of RAM
<daveshah> No, probably not
<daveshah> MMU and SDRAM controller together is too big
<daveshah> But MMU-less linux is possible, if someone got it working on Risc-V
<mithro> You should be able to get away without the MMU
<mithro> I'm guessing the iCE40HX4K would be to small too?
<mithro> daveshah: The LiteX SDRAM controller is pretty small in resource usage
<daveshah> mithro: there's no such thing as a 4k ;)
<daveshah> mithro: it's an 8k rebranded. You can use all 8k LEs with icestorm
<mithro> daveshah: 32 MB SDRAM + iCE40HX4K
<daveshah> mithro: MMU-less linux should definitely be doable on that. With an MMU would be tricky without hacking
<mithro> Does anyone know anything about this -> MicroPython Port for Microsemi’s RISC-V soft ProcessorBadal Nilawar, Microsemi -- https://riscv.org/2017/12/7th-risc-v-workshop-proceedings/
<daveshah> mithro: mmicko got Micropython working on an iCE40 recently
<daveshah> mithro: using Clifford's picoRV32 on an Upduino with the 5k iCE40
<mithro> daveshah: Getting micropython running on a device which has gcc support is pretty trivial :-)
<mithro> daveshah: There was a presentation from the people who did the VexRiscv about an ML accelerator on the ice40 that I can never find
<daveshah> mithro: was that Lattice's demo app?
<daveshah> mithro: the face detection? I found a bitstream for that but sadly no source
<mithro> It was using a modified RISC-V core which was instead changed to be a vector style processor
<mithro> daveshah: I think the one I'm talking about is different...
<mithro> Ahh ha! It was done by VectorBlox
<sorear> mithro: it sounds like you're describing ORCA
<mithro> I think it was this one -> https://www.youtube.com/watch?v=aLr0SMRJFAs&t=24s
keith-man has joined ##openfpga
<daveshah> mithro: vectorblox also did the demo I linked iirc
<mithro> ahh
<mithro> Hrm -- Releasing our Vector ISA as an open spec
<mithro> I think I might have read that as open source
<daveshah> That is very cool. I like the streaming memory concept
<mithro> file:///usr/local/google/home/tansell/Downloads/2017-06-20%20DAC%20VectorBlox%20RISC%20V%20pdf.pdf
mumptai_ has quit [Quit: Verlassend]
mumptai has joined ##openfpga
<cr1901_modern> Idk why I thought clicking on that file:/// link would work
<mithro> Opps
<sorear> a basic MMU shouldn't add *that* much area?
<cr1901_modern> I've tried getting tinyfpga's well, tinyfpga B2 to support micropython, but the lm32 impl crashes about 6 insns in :(
<cr1901_modern> Haven't had time to look into it deeper
<sorear> all of the fpga riscv impls are kinda lacking in one way or another
<pie___> cr1901_modern, hope
<cr1901_modern> ariane looks nice
<sorear> i'll be surprised if it's <10K luts, asic and fpga optimization work at cross purposes
keith-man has quit [Ping timeout: 245 seconds]
<cr1901_modern> aside from "no block RAM/initial" in ASICs, I'm not sure why they're incompatible
user10032 has quit [Quit: Leaving]
noobineer has joined ##openfpga
gnufan has quit [Ping timeout: 276 seconds]