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
<GitHub138>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vgxlm
<GitHub138>
artiq/master 4940e48 Sebastien Bourdeauducq: gui/log: scroll to bottom on startup
<sb0>
whitequark, ^ the asyncio.call_soon() smells like a hack, but it's not reliable without. do you know when qt is supposed to update the scroll properties after a setModel()?
<cr1901_modern1>
Great... I fixed something that wasn't broke and now the transforms from Spinbox Space to Pixel Space are off... bleh
* cr1901_modern1
makes a mental note to NOT fix things that aren't broke
cr1901_modern1 is now known as cr1901_modern
<sb0>
(that model already contains all the data when it is passed to setModel(), of course)
<sb0>
those seem to be common Qt bugs, so maybe they're fixed in later qt versions - I don't know...
bentley` has joined #m-labs
<GitHub120>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vgpnc
<GitHub120>
artiq/master ca3cced Sebastien Bourdeauducq: test/ctlmgr: escape backslashes in sys.executable
fengling has joined #m-labs
rohitksingh has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
felix___ has joined #m-labs
felix_ has quit [Read error: Connection reset by peer]
felix___ is now known as felix_
<rjo>
sb0: the @inline to mark a function for forceful inlining. i think we can live without. i hope llvm is good enough in making the decision. it would only be for tuning anyway.
<sb0>
ok. so after whitequark fixes the compiler bugs and the 'with parallel' implementation we're good with 'kernel funtion support' in stage 2.
<sb0>
*function
<whitequark>
rjo: llvm has nothing on inlining--i set the inlining threshold myself
<whitequark>
i set it to a value higher than llvm uses for c code, naturally
<whitequark>
we might want to raise it even more depending on feedback...
<rjo>
whitequark: but llvm calculates the number used to check for meeting the threshold. that's where i would think the intelligence lies. is there a mapping from gcc-style "-Os -O0 -O1 ..." to inlining threshold?
<rjo>
sb0: ack
<whitequark>
yes, there is
<whitequark>
LLVM's cost calculator is a piece of truly disturbing ad-hoc hackery
<whitequark>
it has things like
<whitequark>
if (NumVectorInstructions <= NumInstructions / 10)
<GitHub21>
artiq/master 0edde9f Robert Jordens: master: inform when running
<GitHub21>
artiq/master 65824fc Robert Jordens: coefficients: cleanup
<GitHub21>
artiq/master d162b2c Robert Jordens: transport: drop a parallel usage
evilspirit has quit []
<rjo>
sb0: i do have some spi master-slave code already. do you want to roll your own?
<sb0>
whitequark, you said you didn't want to use qemu and Xvnc because of poor performance and go for xen instead. isn't the graphical output managed by qemu anyway?
<sb0>
rjo, not necessarily, can you send me yours?
<sb0>
I see those qemu processes on the buildserver that contain that vnc server....
<sb0>
they might as well connect to Xvnc to work around the bugs AFAICT
<kristianpaul>
Any good example of a SPI core with Migen?
<rjo>
the endpoint stuff does not really fit this all that well.
<kristianpaul>
slave
<sb0>
what are the problems with endpoints?
<rjo>
you might find a good start in that gist.
<kristianpaul>
thanks rjo
<rjo>
sb0: framing and variable word size.
<rjo>
sb0: and the mixed read-write transactional nature of spi
<sb0>
the variable word size will be a problem with any bus, no?
<sb0>
for framing there is EOP
<rjo>
how do you represent a n-bit output followed by an m-bit read nicely.
<sb0>
n/m fixed at compile time?
evilspirit has joined #m-labs
<rjo>
no. runtime. see the spec.
<sb0>
there will always be the problem of cutting the data in chunks (cpu words, bytes or otherwise)
<rjo>
and a register read has e.g. n=8+32, m=0 while a write has n=8, m=32
<rjo>
yes. the frames over the endpoints need to have some kind of header and you need to couple the endpoints somehow.
<rjo>
or couple the framing protocol over the endpoints
<rjo>
it all starts to look like axi.
<sb0>
_florent_, ^
<cr1901_modern>
I suspect _florent_ might be ill? I do know mithro and a bunch of other ppl caught a bug at a conference.
<_florent_>
no I'm fine :)
<rjo>
whitequark: your clang in the packages need GLIBCXX_3.4.21 (you don't get that at NIST nor in Debian stable AFAIK)
<cr1901_modern>
Oops :P
<_florent_>
sb0: for now I've only used SPI with CSR interface and 1 MOSI/1MISO shift registers of n bits (n = maximal number of bit of the SPI transaction)
<GitHub178>
[artiq] jordens pushed 2 new commits to master: https://git.io/vghol
<GitHub178>
artiq/master 6830703 Robert Jordens: artiq_master: directly log, explicit imports
<GitHub178>
artiq/master 4bd5a55 Robert Jordens: RELEASEING: cleanup, add note about main conda label
<rjo>
whitequark: 3.5.0-1 does not have that issue.
<sb0>
what on earth is the difference between ConnectionResetError and ConnectionAbortedError ...
<rjo>
bah. that should have been RELEASING...
<sb0>
okay, who is familiar with axi? does it make sense to replace misoc.interconnect.stream with it?
<rjo>
sb0: well. in the end we will want to break it down to something simpler like wishbone again because of wb2rtio. i don't see us doing axi2rtio.
<rjo>
cr1901_modern: having sufficient feture coverage of axi would require redoing rtio quite a bit.
<cr1901_modern>
rjo: In case you didn't see my messagess yesterday, I managed to break the coordinate transforms when switching to QTransform to make my life easier, so I'm in the process of fixing that.
<cr1901_modern>
I should know better than to fix things that aren't broke, but... :(
<_florent_>
sb0: misoc.interconnect.stream is already very similar to axi-stream
<_florent_>
axi is just 5 axi-streams coupled together, but as rjo said that's not very convenient to use in a design (all customers I worked for have a bridge to a simpler bus in their design)
<_florent_>
we could probably keep our streaming interface
<_florent_>
but we could introduce headers or separate control packets
<rjo>
cr1901_modern: i noticed. also feel free to commit and push more frequently. that way we can track the progress and help.
* rjo
has also written a axi2simple translator
ylamarre has joined #m-labs
<rjo>
_florent_: having m.i.stream compatible to (a single) axi-stream would probably be good. then axi would just be m.i.stream x5
ylamarre has quit [Read error: Connection reset by peer]
<_florent_>
yes and that wouldn't be that hard (mainly rename signals :)
<rjo>
... but i think that is rather orthoogonal to spi2something2rtio.
<_florent_>
we could only keep valid/ready/last/data signals
ylamarre has joined #m-labs
ylamarre has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
gric has quit [Remote host closed the connection]
<rjo>
_florent_: how does an AXI master figure out whether it can use use e.g. bursts on a given slave?
<_florent_>
I'm not sure if it's possible for a slave to not support bursts
kyak has quit []
ylamarre has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
kyak has joined #m-labs
<larsc>
the master knows it
<larsc>
it's part of th port configuation
<larsc>
similar to e.g. the bus width
rohitksingh has quit [Ping timeout: 250 seconds]
<larsc>
well, what the master knows is the maximum burst length
<larsc>
which of course can be one, which means no bursts
<sb0>
cr1901_modern, i'm pretty sure you can duplicate the applet issues. i don't expect you to fix them, you can focus on the scan widget...
felix_ has quit [Ping timeout: 240 seconds]
<cr1901_modern>
sb0: Ack.
rohitksingh has joined #m-labs
felix_ has joined #m-labs
evilspirit has quit [Ping timeout: 240 seconds]
ylamarre has quit [Ping timeout: 250 seconds]
mumptai has joined #m-labs
<rjo>
larsc: i see.
<larsc>
rjo: so what I meant, the master that is directly connected to the slave knows
<larsc>
this might be a interconnect
<larsc>
that splits the burst, when it receives a burst from a upstream master
<rjo>
just imaginig how much fun a multi-master crossbar is in AXI...
<larsc>
lots of fun
<rjo>
sb0: i think we should start_new_session=True for subprocesses in ctlmgr. then it actually shuts down controllers gracefully on ctrl-c
<rjo>
and stops spamming the console
<rjo>
and maybe the other instances of managed subprocesses (applets, workers) as well.
<rjo>
yes. ctlmgr is much nicer with that change
kyak_ has joined #m-labs
kyak_ has joined #m-labs
felix___ has joined #m-labs
felix_ has quit [Ping timeout: 255 seconds]
kyak has quit [Ping timeout: 255 seconds]
felix___ is now known as felix_
<sb0>
rjo, what does it do on windows? and what console spamming are you talking about - on Ctrl-C?
<rjo>
sb0: doesn't do anything on windows (see the docs). if you ctrl-c ctlmgr (or SIGTERM it from e.g. an inistrcipt) the entire pgroup gets the signal and exits. then the graceful termination is generally not done. also every controller emits its KeyboardInterrupt traceback
<sb0>
the doc simply says "POSIX only", which doesn't tell me if it does nothing or if it errors out on windows...
<sb0>
if it doesn't cause any deleterious effects on Windows, I'm fine with it
<sb0>
it's surprising if the controllers emit KeyboardInterrupt tracebacks. their stdout and stderr are redirected to ctlmgr. what is going on here?
<sb0>
you mean, emit them into the master log?
<rjo>
yes. and it appears twice, on the ctlmgr stdout/err (the console) and the master.
<rjo>
that's also something that bothers me. we should actually redirect and not just copy.
<sb0>
the current logging implementation 1) makes the log messages from all the child processes log messages of the parent process 2) forwards all the parent process logs to the master
<sb0>
ctlmgr -q -q?
<sb0>
(the "forwarding" otherwise still prints them on the console)
rohitksingh has quit [Quit: Leaving.]
<rjo>
if there is no filtering before the forwarding, won't that get expensive with noisy controllers that are prepped for lots of debugging messages?
<sb0>
the filtering happens inside the controller, via the -v and -q options
<sb0>
of course, you can always have a nasty controller that DoSes the logging system... but the solution then is rate-limiting them
<rjo>
ok. that's good.
<rjo>
but ctlmgr -qq also shuts down the forwarded messages
<sb0>
mh, does it?
<rjo>
for me it does.
<rjo>
those from ctlmgr itself at least.
<rjo>
therefore if you have just run artiq_ctlmgr you get output twice. if you do it with -qq you get output nowhere.
mumptai has quit [Quit: Verlassend]
<rjo>
sb0: we want to avoid hitting children with the same signals wherever we have implemented graceful termination of children, right? that's applets, workers, controllers.
<sb0>
the normal way to close the GUI is with the cross button, not Ctrl-C
<sb0>
I also think that the best way to terminate ctlmgr and master is via "artiq_rpctool call terminate", but Ctrl-C is convenient (despite its race conditions inherent in Python, but the race window is small)
<rjo>
are any of those arguments against starting them in new pgroups?
<rjo>
people use ctrl-c all the time. also on the gui
<sb0>
start_new_session=True in all those is fine, as long as it doesn't break anything.
<rjo>
one reason not to do it would be a case where sigkill is sent only to the parent (ctlmgr). then the subprocesses would linger.
<sb0>
won't the subprocesses get broken pipe errors on their stdio streams then? that should limit their lingering
<sb0>
not a perfect solution though
<rjo>
but we generally do assume that e.g. ctlmgr itself is very reliable (that's why we isolate it from the subprocesses). you can always torpedo that with something like sigkill.
<sb0>
alternatively, the subprocesses could ignore Ctrl-C
<sb0>
for the controllers, you'd want to do that only when they are run via ctlmgr though
<rjo>
ok. i'll do it for ctlmgr and the workers but not for the applets. there it seems that people won't and shouldn't look at the console anyway.
<sb0>
it adds boilerplate to every applet and controller, but then they'll still get SIGTERM and SIGKILL
<sb0>
when the parent gets them
<rjo>
then starting and stopping controllers manually would become a PITA
<rjo>
(on the console)
<sb0>
<sb0> for the controllers, you'd want to do that only when they are run via ctlmgr though
<sb0>
now, how would the controllers detect that... adding another command line argument will result in misuse, for sure
<rjo>
let's try new pgroup for controllers and workers. if this becomes a bigger annoyance than the piles of tracebacks that i have to scroll through to find the initial traceback from ctlmgr itself then we can revisit this.
<rjo>
cr1901_modern: if you measure something to that many significant digits, you get the Time And Frequency Precision MEasurement Award.
<sb0>
and getppid() on linux
<sb0>
the applets already know when they get a IPC address. and the workers always have a parent.
<cr1901_modern>
rjo: The idea is to prevent the center of the widget from moving during a resize. I am not sure I can completely accomodate that requirement
<sb0>
it's a somewhat fuzzy solution though, grepping for artiq_ctlmgr in the parent process name...
<rjo>
cr1901_modern: not needed. expect 1e-15 relative shifts in values when resizing. that's ok. just not 1e-15 absolute shifts.
<rjo>
sb0: just imagine starting an editor on a certain file called artiq_ctlmgr.py ...
<sb0>
you could do pgroups for applets too, for consistency...
<sb0>
the GUI handles Ctrl-C now. that didn't work before. I guess that came with a quamash upgrade...