sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<GitHub-m-labs> [artiq] joeshardow commented on issue #975: How to install artiq package now? The command "conda create -n artiq-main artiq-kc705-nist_clock" is install everything before. https://github.com/m-labs/artiq/issues/975#issuecomment-377826802
<GitHub-m-labs> [artiq] whitequark commented on issue #975: `activate artiq-main` then `conda install artiq` https://github.com/m-labs/artiq/issues/975#issuecomment-377827975
<GitHub58> [llvm-or1k] whitequark force-pushed artiq-6.0 from 8b43f32 to 0726197: https://github.com/m-labs/llvm-or1k/commits/artiq-6.0
<GitHub58> llvm-or1k/artiq-6.0 0726197 whitequark: [OR1K] Handle lowering of return values over 64 bits wide....
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cr1901 has joined #m-labs
cr1901 has left #m-labs [#m-labs]
<sb0> SiFive’s RISC-V Core IP FPGA Evaluation Kit let you test, prototype, and develop your RISC-V program on actual hardware. Our FPGA bitstreams are FAST! Running at 65MHz, these emulation environments are faster than many of the MCUs you’re going to be replacing.
<sb0> 65
<sb0> lol
<sb0> ah, sifive are doing proprietary IP licenses now
<sb0> that didn't take long
<whitequark> sb0: what do you mean?
<sb0> their FE310 had the RTL sources open (https://github.com/sifive/freedom). but, for everything else (and what is prominent on their site), it's "evaluation" code, plus pretty regular fabless vendor licensing
<whitequark> did they ever promise that they'll open-source everything?
<whitequark> that's not a very viable business model
<sb0> dunno, depends what you are doing. gaisler open sourced almost everything and was very successful
<sb0> but then I don't see why SiFive is better than ARM. is it just because it's nicely packaged and marketed, a bit like Valve's Steam is popular DRM?
<sb0> well, at least they won't go after people (including students) who make their own risc-v cores
<whitequark> ARM's licensing terms are draconian
<whitequark> I mean, that's a strange comparison
<whitequark> you're comparing a single implementor of an open architecture with a company that does everything except silicon
<sb0> ARM was around for longer, they didn't do everything from day one
<whitequark> FE310 is an interesting MCU, running at 320 MHz
<whitequark> there are not many Cortex-M contenders
<whitequark> only STM32H7 from the STM32 line, for example, is marginally faster
<whitequark> the peripherals are kinda lacking
<sb0> FE310 doesn't even have flash, does it?
<sb0> sigh, scala.... it's getting into vivado levels of bloat
<sb0> the spinalhdl stuff looks very interesting, but why did he have to use that language
rohitksingh_work has joined #m-labs
<davidc__> whitequark: IIRC its 320mhz running from SRAM
<davidc__> whitequark: my understanding that there are process tradeoffs required to put flash in the part (as well as just pure flash access rate limitations)
<davidc__> so, its not really an apples-for-apples comparison
<whitequark> davidc__: that is a very good point
<whitequark> though I'm pretty sure it doesn't have flash because of licensing reasons
<rqou> afaik the reason real AVRs are so slow is because of flash
<rqou> which is how navre can go so much faster
<whitequark> STM32 also has flash and is much faster
<davidc__> whitequark: could well be that was the driver for removing flash from the design (IP BS)
<whitequark> davidc__: or never putting it there in the first place
<whitequark> AFAIK flash IP is very closely guarded
<rqou> STM32 flash has a special cache/prefetcher, that's why
<whitequark> unlike any other design rules and IP, which you can even get without NDA if you're fine with reduced performance
<whitequark> rqou: that doesn't sound right
<whitequark> AVR has single-cycle execution for most instructions and two-cycle for jumps
<davidc__> STM32H7 datasheet says its a 256bit wide flash interface, so they can load a single cache line in a single flash fetch
<davidc__> but I wonder what the latency is for a cache miss
<sb0> yeah and just like vivado, scala also doesn't work
<whitequark> sb0: I would personally not bother with scala
<whitequark> the language is atrocious and tooling is a royal pain
<whitequark> I'm not sure if a HDL can be ever good enough to justify dealing with that
<sb0> yes, that's what I'm complaining about. unfortunately FPGA softcores that aren't unusable trash are exceedingly rare.
<cr1901_modern> Did you evaluate a large number of cores before settling on lm32 for milkymist?
<cr1901_modern> sb0: You may wish to take a look at Ariane, but it's systemverilog
<sb0> cr1901_modern, yes
<sb0> but that was many years ago
<cr1901_modern> So since then, there's been exactly one other softcore that meets your standards :/
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<cr1901_modern> So we have a softcore that's relatively pleasant to read* and the toolchain support is stagnant, and a core that's not-so-pleasant to read* but the toolchain support is good (* My experience only)
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #919: @whitequark Any update?... https://github.com/m-labs/artiq/issues/919#issuecomment-377852561
<GitHub-m-labs> [artiq] whitequark commented on issue #919: Not yet. https://github.com/m-labs/artiq/issues/919#issuecomment-377852995
<sb0> whitequark, what is your opinion about what is making rtio_output() slow? you were looking at a codegen issue as well, what came out of it?
<whitequark> I merged that patch
<whitequark> right now uh
<whitequark> so there was a fix for LLVM that I wrote for LLVM 4.0, but didn't push upstream because it was sketchy
<whitequark> turns out, it was buggy. I fixed it for LLVM 6.0 properly, but the firmware now panics early in boot
<whitequark> so I'm fixing that now.
<whitequark> it's a calling convention issue and I even know where exactly, shouldn't take long
<sb0> whitequark, right now we're trying to determine what is slow and why, so we can put that into funding proposals
<sb0> stekern, do I read that right that the default mor1kx store buffer is 256 entries deep?
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 256 seconds]
rohitksingh_wor1 has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<sb0> performance without store buffer: https://hastebin.com/ximifijito.sql
<cr1901_modern> Does mor1k also use a write-thru cache?
<sb0> yes
sb0 has quit [Quit: Leaving]
rohitksingh_work has quit [Ping timeout: 268 seconds]
sb0 has joined #m-labs
<GitHub-m-labs> [artiq] jbqubit commented on issue #919: @whitequark What exactly are the steps you've done to test on your board? https://github.com/m-labs/artiq/issues/919#issuecomment-377929409
<GitHub-m-labs> [artiq] hartytp commented on issue #967: What's the status of this? It's been a while since the SDRAM was fixed, and I'd love to have a version of Sayma I can actually use. https://github.com/m-labs/artiq/issues/967#issuecomment-377931199
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<stekern> sb0: I had to go back and take a look to remind myself, but that seems right
<sb0> stekern, that's a lot! why so many?
<stekern> tbh, I can't remember. the default in the storebuffer itself is 8, but it's overridden with the higher level modules
<stekern> if it occupies as many blockrams with 256 as 8, then it doesn't really matter. But I agree that it sounds high as a default
<stekern> ehrm, I meant default in the storebuffer itself is 16
<GitHub-m-labs> [artiq] enjoy-digital commented on issue #967: @hartytp: yes sorry, i started working on that but need to test and commit. https://github.com/m-labs/artiq/issues/967#issuecomment-377978637
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<GitHub-m-labs> [artiq] jbqubit commented on issue #854: I've tried using two network switches so far. ... https://github.com/m-labs/artiq/issues/854#issuecomment-377995996
<GitHub-m-labs> [artiq] jbqubit commented on issue #854: I've also tried using an AMC delivered last week from WUT that has a very recent version of Open MMC firmware. And the Ethernet white wire was added by WUT. https://github.com/m-labs/artiq/issues/854#issuecomment-378002772
mumptai has joined #m-labs
mumptai has quit [Remote host closed the connection]
<GitHub2> [smoltcp] podhrmic commented on issue #178: What is the status here? @astro do you need help implementing the changes? https://github.com/m-labs/smoltcp/pull/178#issuecomment-378070710
<GitHub112> [smoltcp] whitequark commented on issue #178: It's blocked on review that I haven't had time to perform yet, sorry.... https://github.com/m-labs/smoltcp/pull/178#issuecomment-378070911