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
stekern has quit [Ping timeout: 252 seconds]
stekern has joined #m-labs
stekern has quit [Ping timeout: 255 seconds]
stekern has joined #m-labs
ylamarre has joined #m-labs
stekern has quit [Ping timeout: 252 seconds]
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
stekern has joined #m-labs
stekern has quit [Ping timeout: 240 seconds]
fengling has quit [Ping timeout: 245 seconds]
stekern has joined #m-labs
stekern has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
stekern has joined #m-labs
stekern has quit [Ping timeout: 246 seconds]
<sb0>
cr1901_modern, can you file the migen issues you had?
<sb0>
with namer and that other thing
<cr1901_modern>
(ClockDomain)Namer, yes, working on it now... "that other thing," I forget to what you refer :(
<cr1901_modern>
If it's in reference to identifiers being decorated with __main__, I think I concluded that it's "not a bug"; just "unfortunate" :P
<sb0>
yes, that one
<sb0>
well, report it
<sb0>
you eventually had written a good minimal program I think
<cr1901_modern>
Yes, I think I found it- uploaded it as a gist.
<sb0>
can you link it in a migen issue?
<cr1901_modern>
Yes of course. I wanted to add a second example: neither renaming sys to new_clk_name nor new_clk_name to sys works.
<sb0>
I'll have some time next month to look into migen/misoc so good to have a proper list of things to look into
<cr1901_modern>
Sorry I keep breaking things (especially considering in 4 months I haven't actually come out with anything I feel worth publishing using Migen yet)
<cr1901_modern>
I updated the code example to create two simulations- one where the module's clock domain is renamed to sys, the other where the top_level's clock domain is renamed to a provided clock domain name
<tmbinc___>
I'm trying to make xst infer an SRLC32E, which needs a reset-less shift register. What's the best way to remove reset from a particular Signal?
<tmbinc___>
should i create a reset-less clock domain for the SRLC32E? Or is there some magic method to exclude a Signal() from being reset?
<sb0>
oh right, those tests need to switch event loops
<ysionneau>
so the good news is we can definetely use those win32 packages for win64 =)
<sb0>
ysionneau, bah. just looks like minor problems. do you have any trouble fixing those or what?
<ysionneau>
I didn't try yet, I'm just reporting :)
<ysionneau>
most of the things are passing
<sb0>
and is that running in a VM on a 10-year-old computer or something?
<sb0>
looks very slow from the core device tests that are failing
<ysionneau>
yes it's running in a VM, which can explain the timings
<ysionneau>
I get similar timings in a win32 VM
mumptai has joined #m-labs
antgreen has joined #m-labs
mumptai has quit [Quit: Verlassend]
antgreen has quit [Ping timeout: 260 seconds]
ylamarre has quit [Quit: ylamarre]
<GitHub101>
[artiq] jboulder opened pull request #109: new ddb.pyon argument comment; use to put labels in GUI for TTL and DDS (master...master) http://git.io/vsdQP