<sb0>
hmm I suppose one cannot dump, say, 100k waveform points into wavedrom and expect it to do something nice (i.e. scrollbars and reasonable cpu/memory usage like gtkwave does)
<cr1901_modern>
sb0: Unless something changed recently, you can't zoom in/out using wavedrom to show regions of interest in large data dumps
<cr1901_modern>
so a 100k point waveform is gonna use a lot of screen real estate (and no doubt get a nice scrollbar)
kuldeep has quit [Ping timeout: 258 seconds]
sandeepkr has quit [Ping timeout: 276 seconds]
<sb0>
and 60GB memory consumption by google chrome?
<cr1901_modern>
I haven't actually tested wavedrom w/ large waveforms. But probably.
<cr1901_modern>
(Well, haven't tested it on hundreds of MBs of data or above, more specifically)
<GitHub>
[artiq] cjbe commented on pull request #666 d18e8e5: The inconsistency is from when I was trying to make the browser able to open old results files without the tooltip entry in expid - I decided this was unnecessary. ... https://github.com/m-labs/artiq/pull/666#discussion_r99304309
<bb-m-labs>
build #1307 of artiq is complete: Failure [failed artiq_flash] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1307 blamelist: Chris Ballance <chris.ballance@physics.ox.ac.uk>
kuldeep has joined #m-labs
jaeckel has quit [Ping timeout: 276 seconds]
sandeepkr_ has joined #m-labs
sandeepkr_ has quit [Remote host closed the connection]
<GitHub>
artiq/master b9cbedc whitequark: firmware: migrate last vestiges of the old runtime build system.
<GitHub>
artiq/master cde2054 whitequark: firmware: do not link to C code in runtime and satman.
<whitequark>
ok. I am now *much* happier about how all this is built.
sandeepkr has joined #m-labs
<whitequark>
sb0: btw. are we at all interested in running the runtime as a process on the host machine?
<whitequark>
this would have been very useful with the C runtime, because of memory safety concerns.
<whitequark>
but it's not in C anymore.
<rjo>
not interesting to me if not most of the peripherals/rtio/etc are emulated as well.
<whitequark>
rjo: well we may emulate them if there's a purpose in that.
<whitequark>
all I'm saying is rust makes this sort of dependency injection really easy and safe.
<rjo>
whitequark: what would be the relevnt differences w.r.t. doing it in qemu?
<rjo>
whitequark: in anycase runtime-on-host or runtime-on-qemu is probably not something i would invest time in right now.
<whitequark>
qemu is slow, buggy (especially for 3rd class platforms like or1k), doesn't let us use OS APIs easily, and would require patching to add our peripherals
<whitequark>
unless we were specifically aiming for verification of the or1k runtime (or cosimulation) qemu seems pointless
<whitequark>
but ok.
<rjo>
whitequark: did you figure out why llvm doesn't generate the more efficient offset CSR writes?
<whitequark>
rjo: I didn't need to figure it out, it's obvious
<whitequark>
a missing pattern in the DAG matcher
<rjo>
whitequark: sure. but writing our own hardware emulator framework for the peripherals seems about as tricky (and NIH).
<whitequark>
do you want me to fix that?
<rjo>
whitequark: fixing it would be great. yes.
<whitequark>
do we need a hardware emulator framework though?
<whitequark>
implementing rtio in serial code with all the hosted APIs doesn't sound hard at all.