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
<cr1901_modern>
sb0: Do I understand correctly that ClockDomains() in Migen are local to the module in which they are defined (unless a submodule doesn't define it's own ClockDomain)?
bentley` has quit [Ping timeout: 264 seconds]
bentley` has joined #m-labs
<sb0>
rjo, not sure what exactly caused the "python" command to use the wrong interpreter
<sb0>
rjo, also, the most annoying thing is running a full build after modifying the script to debug, not installing artiq
<sb0>
re. $PYTHON, re-building a artiq commit that used to work didn't anymore, so it's probably not "you guys break stuff"
<sb0>
and another problem was conda removed the binstar command so migen didn't get updated. again, not us breaking stuff.
bentley` has quit [Ping timeout: 246 seconds]
<sb0>
cr1901_modern, they go up the module hierarchy as well
bentley` has joined #m-labs
<cr1901_modern>
sb0: That makes sense. Until tonight I was wondering how to properly make an always@ block wrt another signal besides the default sys_clk. ClockDomains provide a way to do that.
<cr1901_modern>
sb0: Under what circumstances will Migen decide not to associate the default clock for a platform with the sys clock domain?
<cr1901_modern>
Can provide code snippet if necessary
<sb0>
when you aren't defining clock domains
<cr1901_modern>
Not that I said decide NOT*... b/c defining my own clock domains is what's breaking the defaults
<sb0>
behavior is: simple design with no clock domain defined -> assign platform default clock to sys
<sb0>
any clock domain defined by user -> user also needs to deal with the sys clock
<cr1901_modern>
Okay fair enough. I just did: self.comb += [self.cd_sys.clk.eq(clk)]
<cr1901_modern>
Now, is there any way to make Migen stop prefixing my verilog variables with __main__/the class names (as opposed to the submodule names) after I define my own sys clock?
<cr1901_modern>
this is a nitpick, but it's difficult to read
<sb0>
there is no api for that
<cr1901_modern>
That's fine, but why does migen do that (change from using the variable/module names to using the class names/__main__ when defining clock domains)?
<sb0>
because you have several "clk" signals to differentiate, I guess
<sb0>
well, actually, there's some api for that
<cr1901_modern>
you forgot :P?
<sb0>
you can set name_override on specific signals to resolve name conflicts manually
<sb0>
and hope that there won't be other conflicts that will make it prefix in the way you dislike
<sb0>
but it'll be very fragile.
<cr1901_modern>
Well, I guess ideally, I'm not supposed to be looking at the Verilog code output.
<cr1901_modern>
It's just throwing me off that Migen's behavior (naming and defining defaults) changes the minute I realize I need two clocks
<cr1901_modern>
(and no, for this design, there's no way around it)
<sb0>
cd1.clk.name_override = ....
<sb0>
but the problem may pop up elsewhere and you'll spend a lot of time fixing this kind of trivial detail
<cr1901_modern>
Alright, I'll trust that Migen knows what it's doing when it decides to change the naming scheme :P. I mean, it's not like the code's impossible to follow XD
<sb0>
would the name of the different clk signals not conflict without the added prefix?
<cr1901_modern>
Funny you mention that... the clk signals are basically the ONLY variables that aren't prefixed with the class name
<sb0>
do you have minimal code that shows this?
<cr1901_modern>
I'm creating one now
<cr1901_modern>
Interesting... cannot duplicate in minimal example. Which means I did something wrong in my "real" code
<cr1901_modern>
Well, maybe, but: Migen doesn't like it when I instantiate submodules before passing them into a function
<cr1901_modern>
when that happens, Migen decides that it wants to prefix some module components with __main__ and others with the class name that inherited from Module()
<cr1901_modern>
I edited the gist to add a third submodule that's defined solely within the top-level module in addition to a module that's passed in. The third submodule also has __main__ decoration
imrehg has joined #m-labs
bentley` has quit [Ping timeout: 240 seconds]
bentley` has joined #m-labs
<sb0>
cr1901_modern, do you want this to be handled differently?
<sb0>
also, does minimal example code need to use mibuild at all?
<sb0>
or fsm libs, wishbone, etc.
bentley` has quit [Ping timeout: 246 seconds]
<GitHub62>
[artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/vOYFk
<GitHub62>
artiq/master 9e24b56 Sebastien Bourdeauducq: gui: add state manager
<cr1901_modern>
sb0: Minimal example updated to removed cruft. If I wanted to handle this differently, I would've had signal names decorated based on which modules they ultimately are assigned to as submodules. >>
<whitequark>
sb0: dds_init() seems to hang for some reason
<cr1901_modern>
In the linked example, the DAC signal "ser_dat" becomes "ym3014dac_ser_dat". I would've expected it to become dac_ser_dat or maybe synth_dac_ser_dat.
<cr1901_modern>
(Because dac is the submodule name where it's ultimately assigned)
<cr1901_modern>
Now I'm very open to explanation why this is the wrong way to do this :P
<cr1901_modern>
(I would've also expected DeltaSigma signal "out" to become deltasigma_out. Instead it became __main___out. Ditto with any signal defined in the Synth module.)
<GitHub4>
[misoc] whitequark pushed 1 new commit to master: http://git.io/vO3kw