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
rohitksingh has quit [Quit: Leaving.]
<sb0>
"hamequiment"... do hamradios do vacuum these days?
<mithro>
sb0: any chance you'd have some time a bit later to take a look at a horrible migen/misoc module I've written and tell me how I've done it all wrong?
<mithro>
cr1901_modern: ping?
<mithro>
I don't have a good feel for the Migen / MiSoC idioms yet
<sb0>
ok
<mithro>
sb0: in a simulation, how do I "setup initial conditions" ?
<sb0>
what conditions?
<mithro>
At the moment everything starts at 0 and then my first yield group sets them to a value
<mithro>
But that happens on the first sysclk
<sb0>
use signal.reset?
<mithro>
you mean "Signal(reset=X)" ? That is only for sync signals right?
<sb0>
no. undriven combs take their reset value
<mithro>
when I add a "reset=X" to my signals they no longer appear in the run_simulation output?
<sb0>
what do you mean by appear?
<sb0>
vcd? the vcd writer is conservative re. the signals it puts there, and only includes those that have switched at least once
<sb0>
should be easy to change that though
<sb0>
e.g. add all signals that appear in the design (but this must be in addition to the current logic, otherwise this will break pure-simulation signals, which was a problem in previous migen)
<mithro>
sb0: so, I did a "a = Signal(reset=1)" and then do a "yield a.eq(0); yield; yield a.eq(1)" in my "def test"
<mithro>
but a no longer appears in my output - so I'm guessing that its not changing now?
<sb0>
is is changing
<sb0>
or should be
<mithro>
well those yield statements should change it right?
<sb0>
and what do you call "output"?
<sb0>
yes
<mithro>
ahh
<mithro>
I wasn't doing an empty yield between the other yield calls
<mithro>
maybe the simulator should warn if you try and set a signal twice in a clock cycle?
<mithro>
sb0: how while in my "def test(x)" function how do I actually assert that a signal is a given value?
<mithro>
doing == just gives me an _Operator object
<mithro>
Looks like I look at the return value of the yield?
<mithro>
sb0: so the following seems a bit weird
<mithro>
fsm.act("DETECT_PRE", If(self.scl == 1 and self.sda == 1, NextState("DETECT_SDA")))
<whitequark>
sb0: btw, I've devised a way to make attribute writeback precise again
<whitequark>
it's possible if we make a shadow region of memory backing entire host-derived data area, and another region of memory that has a lattice indicating which mutable values are stored in which attributes
<whitequark>
it's fiendishly complex and it will triple the RAM consumption
<whitequark>
I don't think there is any other way in light of mutable lists, which is probably an indication that current imprecise writeback is good enough
<sb0>
hm, yes, the test passes with the conda package and not with the llvm i compiled
<sb0>
wtf
<mithro>
sb0: Well, my tests seem to mostly pass now
<whitequark>
sb0: based on the failure, it seems the last commit is not in
<whitequark>
perhaps you're using an LLVM other than what you've just compiled?
<whitequark>
e.g. you built it with -DLLVM_ENABLE_SHARED=ON but didn't install
<sb0>
fuck.
<sb0>
I followed the exact instructions from the manual
<whitequark>
hmm
<whitequark>
those should be right
<whitequark>
no, the instructions in the manual are alright
<whitequark>
they link LLVM statically and they install it system-wide
<mithro>
sb0: I'd appreciate any feedback, specially on how to be more idiomatic, better ways to test, etc
<whitequark>
perhaps your PATH is messed up?
<whitequark>
eg conda PATH is before /usr/local/llvm-or1k/bin
<sb0>
oh. llvmlite failed to recompile some of its parts.
<sb0>
after carefully trashing every file it created and reinstalling it, it works now
<whitequark>
ah yes that sounds about right
<whitequark>
llvmlite's build process is awful
<whitequark>
it tries to use LTO in misguided ways that break if your cc is clang
<whitequark>
and it's very slow too
<whitequark>
just like everything else about llvmlite
<mithro>
sb0: I'm guessing I should probably be doing "If(self.scl & self.sda, XXXX)" rather then "If((self.scl == 1) & (self.sda ==1), XXX)" but I found when writing the stuff being explicit helped me figure out what was going on.....
<sb0>
interesting use of ascii-art :)
<whitequark>
ohhh that's very nice
<whitequark>
I did a similar thing to test regions returned by my Ruby parser
<mithro>
sb0: I ran into the problem of what value should you use for \ and /
<mithro>
And they get big really quickly
<whitequark>
sb0: there is a problem with the with: statement
<whitequark>
according to PEP343, the __exit__ method receives either *sys.exc_info() or None, None, None
<whitequark>
... ah yeah, we can do that in RPCs, alright
<mithro>
Be back in 30 minutes
<sb0>
of course, while window embedding with qt seems to be somewhat buggy, it's only natural that pyqt adds its own layer of crap
<sb0>
why the hell does QWindow.winId() return sip.voidptr?
<whitequark>
because it's a HANDLE
<whitequark>
and HANDLE is void* on Windows
<sb0>
I'm on Linux
<whitequark>
(this is a bad justification, but this is likely why)
<whitequark>
hm
<whitequark>
yeah, should be unsigned long
<sb0>
I'm supposed to get a X11 window ID, some integer same as shown by xwininfo
<sb0>
do you know how to cast that sip.voidptr to unsigned long and print it?
<sb0>
maybe that's what should be done... easy to check anyway
<whitequark>
sip.cast?
<sb0>
"A sip.voidptr may be converted to a Python integer by using the int() builtin function."
<whitequark>
oh
<whitequark>
yeah that
<sb0>
oh, yes that worked
<sb0>
oh, embedding almost worked.
<sb0>
only bug is the old window is still displayed, and its contents replaced by black
<sb0>
wouldn't surprise me if that's a gnome bug, though
<whitequark>
are you embedding the entire window or the widget?
<whitequark>
it's probably another X window that wraps the one you embed & you'd have to kill it explicitly
<mithro>
sb0: is there a way to get the "frequency" of the clock domain, or do you normally just pass it in as a parameter in the __init__
<sb0>
oh actually it's completely buggy
<sb0>
all it did was resize the old window to the same size as the new one i created, and I got confused because my new window had nothing else in it
<sb0>
what a bunch of crap
<sb0>
mithro, your question is excessively vague
<mithro>
sb0: In misoc, the sync domain has a clock right? Is there a way to get the frequency that clock is toggling at?
<sb0>
from where?
<sb0>
if you mean from csr.h it's in one of the CONFIG_ I think
<mithro>
sb0: from the sys_clk signal itself
<sb0>
people who are worried about the singularity should seriously touch x11 and qt
<sb0>
mithro, oscilloscope?
<sb0>
or if you mean from migen, you can read config back
<mithro>
sb0: Let me start again, if I have a Module were I need to generate signals at known real-world frequencies - is there a way to auto-magically detect the clock signal frequency, or do I need to pass it in as a parameter to my module?
<sb0>
LOL
<sb0>
qt/x11 is a piece of shit
<whitequark>
what now?
<sb0>
what it does for "embedding" is in fact a lame attempt to position the captured window on top of the widget where you want it
<sb0>
and sync resize/move events
<whitequark>
oh lol
<sb0>
the bug I have right now is 1) it fails to hide the title bar 2) the position is off by a hundred-ish pixels
<whitequark>
hang on
<sb0>
so what I get instead is two somewhat locked windows that look pathetic
<sb0>
it breaks like my code when i try to embed another existing window
<sb0>
hmm it's really fragile
<whitequark>
what do you mean by "another existing window"?
<whitequark>
or better, show me the code
<sb0>
open e.g. xterm, xwininfo, then paste its winid into host.py
<whitequark>
are you planning to embed xterm?
<sb0>
basically, the window itself has to hidden while it's being embedded, and then the embedded process itself needs to show it (doesn't work if the host shows it)
<sb0>
no, so that's a moot point, but it shows that x11 is crap
<sb0>
cr1901_modern, could you give whitequark's embedding code a quick test on windows?
<mithro>
sb0: What is the main difference between the new and legacy versions of migen/misoc in regard to the FDHL level?
<sb0>
Constant
<sb0>
len()
<cr1901_modern>
sb0: Sure. Give me 15 minutes to wake up/get up to speed.
<cr1901_modern>
mithro: Why is gtkwave so crashy :( < B/c it's gtkwave. Once sigrok becomes feature-complete I'm switching to that
<larsc>
pulseview
<larsc>
I think everybody is waiting to jump the gtkwave ship
<cr1901_modern>
Yes, pulseview is what I meant. It doesn't have functionality for combining/splitting signals as a bus. Unfortunately, that features really important to me, so I gotta wait or implement it myself.
<sb0>
whitequark, actually there's a better embedding solution
<whitequark>
sb0: yea?
<sb0>
use QWindow.setParent() in the applet, with the winid of the host widget
<sb0>
and this works, EXCEPT that resizing is broken
<sb0>
this way the ARTIQ GUI could just pass a winid on the cmdline of the applet, with no mucking around with RPC, tokens, etc.
ylamarre has joined #m-labs
<whitequark>
well, you need to fix resizing.
<cr1901_modern>
sb0: Testing now, as soon as my text editor decides to stop stop-the-world GC
<cr1901_modern>
Aaand Java crashed. Great.
<whitequark>
HotSpot has a concurrent GC...
<sb0>
whitequark, how do you get the proper QWindow for a QWidget?
<sb0>
I do "self.main_widget.winId()" to make Qt create it even though the widget is not shown yet
<sb0>
and then self.main_widget.windowHandle()
<whitequark>
yep
<whitequark>
that's the correct way
<cr1901_modern>
whitequark: Noted. I'll try it out later and see how it works
<cr1901_modern>
So the test app. I can click the button, but when I click "X", the app does not terminate.
<sb0>
it could be the usual Qt layout bug too, this too has a tendency to be a pain
<whitequark>
cr1901_modern: yeah, that's expected
<cr1901_modern>
text prints after the SECOND button press
<whitequark>
always?
<cr1901_modern>
always
<whitequark>
sigh
<cr1901_modern>
oh wait... sorry
<cr1901_modern>
I mean after start up. The first button press doesn't print anything
<cr1901_modern>
all subsequent presses do
<cr1901_modern>
so the second, third, fourth, etc presses print "Hi"
<cr1901_modern>
By "always" I meant that I can duplicate each time I start up the application. Is the first button press supposed to print "hi" as well, or does that just grab focus?
<cr1901_modern>
whitequark: ping, if you haven't read yet. I worded my initial response poorly
<sb0>
hmm how is qt layout even supposed to work when embedding...
<sb0>
I suppose the QWidget created with createWindowContainer has some magic for that, that my code currently lacks
<sb0>
"Once the window has been embedded into the container, the container will control the window's geometry and visibility. "
<cr1901_modern>
I didn't know that widgets could be their own windows, really
<sb0>
of course, QWindow.fromWinId().size() doesn't work
<sb0>
returns an empty QSize
<sb0>
that shit is remarkably packed with bugs
<whitequark>
cr1901_modern: hm, dunno
<whitequark>
that sounds like a bug
<cr1901_modern>
Does it happen on your end as well?
<whitequark>
not on Linux
<cr1901_modern>
Now the first click print's "hi" one times out of 10...
<cr1901_modern>
hrm
<whitequark>
sb0: ah no, there actually *is* an issue with context managers.
<whitequark>
yeah, if the __exit__ is marked as @kernel, there is a problem
<whitequark>
because it has to receive *sys.exc_info()
<whitequark>
which is: type, value, traceback
<whitequark>
first, tracebacks do not exist in form of Python objects on the core device. okay, sure, I can pass None
<whitequark>
second, __exit__ would have to be polymorphic over `type` and `value`, and we can't handle that.
<whitequark>
third, even if I barfed and said, type is always Exception and value is always something of type Exception (this is the internal representation on the core device anyway), there's another problem
<whitequark>
which is, I cannot possibly pass None, None, None when there was no exception raised
ylamarre has quit [Remote host closed the connection]
ylamarre has joined #m-labs
ylamarre has quit [Ping timeout: 240 seconds]
ylamarre has joined #m-labs
ylamarre has quit [Remote host closed the connection]