sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
<mithro> How do I reset a Migen module?
<key2> nmigen or migen ?
<mithro> Old migen
<cr1901_modern> mithro: self.clock_domains.cd_my_cd = ClockDomain(), then route ClockSignal("sys") to self.cd_my_cd.clk, and your reset logic to self.cd_my_cd.rst
<mithro> cr1901_modern: If I just want to reset a single module rather than everything in a clock domain?
<cr1901_modern> mithro: Yes. A clock domain is both a clock _and_ a reset signal
<cr1901_modern> in your case you just want to duplicate the reset signal and leave the other logic alone
<mithro> cr1901_modern: I want to reset a single module, not the whole clock domain
<key2> can't with a ResetInserter ?
<cr1901_modern> Oh yes, that too
<mithro> How do I get the reset signal from ResetInserter?
<cr1901_modern> It's a decorator... the signal should be available from self.rst
<cr1901_modern> I _think_
<cr1901_modern> CEInsterter is similar, but it adds a self.ce signal
<whitequark> yes
<whitequark> ResetInserter()(m) in migen adds a m.rst signal
<whitequark> or cd_rst where cd is the clock domain name, if you use multiple domains
<key2> . reset
<key2> ha whitequark woke up :)
<mithro> With the simulator, if I do "yield" it advances the clock by one - self.sync += self.o_data.eq(self.i_data) then self.o_data should equal self.i_data after the yield?
<whitequark> yes
<cr1901_modern> yield self.i_data.eq(1) will schedule an update for idata
<cr1901_modern> technically you can do yield self.o_data.eq(1) as well, using your example above, but it'll conflict with your sync statement. Don't remember how the simulator handles it
<whitequark> that's not how it works at all.
<whitequark> if self.i_data is driven comb, trying to set it will do nothing in migen sim
<whitequark> it will be silently ignored
<whitequark> and setting self.o_data will, indeed, schedule an update for it
<cr1901_modern> I have no idea if self.i_data is driven comb, all I have the the context of a single statement
<mithro> self.i_data = Signal()
<cr1901_modern> That looks like you get do "yield self.i_data.eq(1)" just fine?
<cr1901_modern> mithro: Looks fine to me from a quick glance
<cr1901_modern> also, TIL you can iterate over a string in Python
<whitequark> yes
<whitequark> and you can iterate over bits of a signal
<whitequark> Cat(reversed(s)) works
<cr1901_modern> Oooooh! Nifty
<whitequark> I'm actually not sure why it works
<mithro> so, why do I get an extra zero on this -> https://gist.github.com/mithro/32e4bcbba355f9bb498f80f51f56b26d ?
<whitequark> because Signal doesn't impleement __iter__
<cr1901_modern> mithro: It's not an extra 0
<cr1901_modern> err, scratch that
<cr1901_modern> the last 1 is missing too
<cr1901_modern> I think it's because o_data trails i_data by 1 clk
<whitequark> mithro: so, you know how verilog processes work, right?
<cr1901_modern> so on the first cycle, everything has its reset value, and o_data is fed w/ i_data's rst value
<whitequark> in migen, simulator code runs *after* the clock posedge happens, but *before* the DFFs change their value
<whitequark> so the very first (yield dut.o_data) gives you the value of o_data *at startup*
<whitequark> i'm actually not entirely sure why it works like that
<cr1901_modern> why isn't the very first (yield dut.o_data) reflecting the value of *i_data* at startup?
<cr1901_modern> i.e. if you made i_data's rest value "1" I would expect the very first (yield dut.o_data) to print "1"
<whitequark> nope
<whitequark> the value of o_data at startup is o_data's reset value
<whitequark> it's a dff
<cr1901_modern> But the print statement is after the yield w/ no argument
<whitequark> so?
<whitequark> it still prints the value of o_data before the tick
<mithro> whitequark: So, how do I get the value after the tick?
<cr1901_modern> yield should've advanced the sim by one cycle
<whitequark> cr1901_modern: this is how migen simulator works.
<whitequark> it's irrelevant to your expectations about how it works
<whitequark> and yes, it is unnecessarily confusing
<whitequark> mithro: basically, delay everything by one clock cycle
<cr1901_modern> whitequark: When I run the following snippet
<cr1901_modern> http://ix.io/1wGb
<cr1901_modern> I get this: http://ix.io/1wGc
<cr1901_modern> o_data's output on the first print reflect's i_data's rst value
<cr1901_modern> Did thischange recently?
<mithro> whitequark: so, is this what I need -> https://gist.github.com/mithro/32e4bcbba355f9bb498f80f51f56b26d
<whitequark> hmmm
<whitequark> good question actually
<cr1901_modern> I'm based off of commit id 022721a
<whitequark> no, I know it didn't change
<whitequark> the question is why it does that
<cr1901_modern> http://ix.io/1wGd This behavior looks reasonable to me, tbh
<whitequark> oh, right
<whitequark> what i said is true about *comb* signals
<whitequark> so, add self.comb += self.c_data.eq(self.o_data)
<whitequark> and print it too
<whitequark> and you'll see something interesting
<mithro> Does @ResetInserter() work with simulation?
<whitequark> yes
<cr1901_modern> Aha
<whitequark> and it's not a @
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhUJb
<_whitenotifier-6> [m-labs/nmigen] whitequark fc0fb9d - back.rtlil: always output negative values as two's complement.
<whitequark> i.e. it is not a method decorator
<whitequark> hm
<whitequark> I had no idea you can use it as a class decorator
<whitequark> but yes
<whitequark> it works in sim
<cr1901_modern> whitequark: Need to reread what you said, but this behavior looks reasonable to me too: http://ix.io/1wGe
<whitequark> hmmm
<whitequark> i've definitely seen some inexplicable behavior along these lines
<whitequark> i'll have to go back and recheck
<cr1901_modern> ack
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/471728137?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.37% remains the same compared to 5702767 - https://codecov.io/gh/m-labs/nmigen/commit/fc0fb9d89fa4447cdccf6d8992da77100576ed0c
<_whitenotifier-6> [nmigen] Success. Coverage not affected when comparing 5702767...fc0fb9d - https://codecov.io/gh/m-labs/nmigen/commit/fc0fb9d89fa4447cdccf6d8992da77100576ed0c
zng has joined #m-labs
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/fhUUC
<_whitenotifier-6> [m-labs/nmigen] whitequark 1c7c75a - hdl.xfrm: implement SwitchCleaner, for pruning empty switches.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/471731508?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.45% (+0.07%) compared to fc0fb9d - https://codecov.io/gh/m-labs/nmigen/commit/1c7c75a254c35da5058eec913e55214931062dbc
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 79.37%) - https://codecov.io/gh/m-labs/nmigen/commit/1c7c75a254c35da5058eec913e55214931062dbc
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/fhUUE
<_whitenotifier-6> [m-labs/nmigen] whitequark 98f554a - hdl.xfrm, back.rtlil: implement and use LHSGroupFilter.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/471733513?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.5% (+0.05%) compared to 1c7c75a - https://codecov.io/gh/m-labs/nmigen/commit/98f554aa083360a1904cdbe671c4de21f345dfd7
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 79.45%) - https://codecov.io/gh/m-labs/nmigen/commit/98f554aa083360a1904cdbe671c4de21f345dfd7
_whitelogger has joined #m-labs
<whitequark> sb0: something fascinating is
<_whitenotifier-6> [nmigen] whitequark created branch pysim-split-funclets - https://git.io/fhUU5
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to pysim-split-funclets [+0/-0/±1] https://git.io/fhUUd
<_whitenotifier-6> [m-labs/nmigen] whitequark 34f20a9 - back.pysim: split funclets according to LHS groups.
<whitequark> if i try to optimize pysim to use minimal sensitivity lists
<whitequark> it becomes significantly slower
<whitequark> by tens of %
<whitequark> not really sure what else can be done for pysim at this point without degrading functionality
<whitequark> i feel like it would be a better way to spend time to add VPI and iverilog/verilator support
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/471737335?utm_source=github_status&utm_medium=notification
<whitequark> at some point optimizing pysim further would be just reinventing verilator, but shittier
<_whitenotifier-6> [nmigen] Success. 79.55% (+0.04%) compared to 98f554a - https://codecov.io/gh/m-labs/nmigen/commit/34f20a9d535d51dc186a3b41db416fcd4767e0b3
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 79.5%) - https://codecov.io/gh/m-labs/nmigen/commit/34f20a9d535d51dc186a3b41db416fcd4767e0b3
<cr1901_modern> It was a long time ago, but I'm not even sure why the VPI was removed in the first place
<whitequark> ok, what should i do next...
<whitequark> cr1901_modern: btw does your boneless sim set flags on ADDI?
<whitequark> I just discovered that my implementation doesn't
<cr1901_modern> yes
<whitequark> that was kind of obnoxious to debug
<whitequark> I should make like
<whitequark> a fuzzer that checks that the microstate is the same in sim and gateware
<whitequark> after each instruction
<whitequark> I guess it's time to put boneless in its own repo, huh
<cr1901_modern> should be easy, I provide all the microstate as attributes in the sim object (unless you added some)
<whitequark> haven't touched it
<cr1901_modern> Sure. Can you make a repo, and when you're ready to merge, I'll do a "allow-unrelated-histories" merge
<cr1901_modern> or you can do it if you want
<whitequark> going to make a repo...
<whitequark> currently messing with git filter-branch to extract history from glasgow
<whitequark> that command is an epitome of git ux, like rebase
* cr1901_modern laugh-coughs
<whitequark> it technically does what you want, in a really hateful way
<whitequark> "fuck you" in the form of a shell script
<cr1901_modern> The kolmogorov complexity of ""fuck you" in the form of a shell script" is 3- "git".
<cr1901_modern> ahhh shit I used that term wrong
harshgugale has joined #m-labs
harshgugale has quit [Client Quit]
_whitelogger has joined #m-labs
rohitksingh has joined #m-labs
<key2> whitequark u checked the patch on nmigen ?
<key2> which are in fact files from migen i needed
<attie> cr1901_modern: I don't think VPI was removed so much as never added in the migen simulator.
<attie> the very old simulation infrastructure was just simulating the exported verilog wholesale.
<cr1901_modern> attie: Yea that's fair. I asked for VPI support from the Python sim, but IIRC it was nontrivial to add
zng has quit [Quit: ZNC 1.8.x-nightly-20181211-72c5f57b - https://znc.in]
<cr1901_modern> attie: And tbh, I was fine with the old infrastructure :P
<attie> I wasn't
<attie> I think I may take some portion of the blame for replacing it
<attie> that reminds me, the other issue apart from 'fake comb loops' making any decent size design unsimulateable
<whitequark> key2: yes. i will add these files to nmigen later in a more proper way
<whitequark> ie reimplement in nmigen
<whitequark> and add compat shims
<attie> was that signals that were not part of a fragment could not be used in simulation
<whitequark> attie: I suspect that when I re-add VPI
<attie> I ran into situations where I needed signals that were assigned and read purely from generators
<whitequark> I'll have to make VPI a "comb process"
<whitequark> like you are describing
<whitequark> it's still not quite that simple because you can poke the innards of the other simulator
zng has joined #m-labs
<attie> whitequark: any ideas about making the yield semantics a bit less confusing w/r/t which cycle's values are read and written?
<attie> I'm well used to the current semantics by now but I remember it being very confusing in the beginning
<attie> and I suspect that with adding the possibility to do comb assignments it would either get much more confusing, or a lot clearer
<whitequark> attie: the problem is that whatever we do, there is a lot of code using hte old semantics
<whitequark> so changing it in any way is inherently a hazard
<whitequark> i will need to think about it
<whitequark> but this is a really hard evolution
<attie> hmm right
<attie> backwards compatibility, always a drag
<attie> what about something where yield can have an associated domain
<attie> but if none is specified it falls back to old migen behavior
<attie> not sure what syntax would be for that though
<whitequark> yeah, something like that
<cr1901_modern> >I think I may take some portion of the blame for replacing it
<cr1901_modern> /me "git blame attie"
<cr1901_modern> well, none of your commits I can see were from the period from when the sim was replaced lol
<attie> no, I take no credit, only blame for complaining at length until sb0 replaced it
<cr1901_modern> ahhhh I see
<attie> using my exclusive developer access for making him regret asking "how was your day" over dinner
<cr1901_modern> Hehe
<cr1901_modern> I'm afraid I'm unlikely to ever get that exclusive developer access :(. Not being on the same continent is an issue.
<attie> this is nearly completely off-topic, but on the off chance that someone here is initiated into the dark arts of makefiles
<attie> I have a migen toplevel that writes multiple .v files
<attie> each of these .v files are then fed to a script that makes a .bit for each
<attie> how do I properly get make to understand that one source makes 4 intermediary files
<cr1901_modern> you don't (I think GNU make supports something to accomodate this tho)
<attie> I use .INTERMEDIATE and a fake intermediate target which mostly works, except it somehow screws up the date checks
<attie> it checks whether the .bit is more recent than the .v before it runs the rule that makes the .v
<attie> but I can't quite wrap my head around the way make decides when to run which rules
<cr1901_modern> I'm afraid I don't know. GNU make lets you do horrifying things that I dare not touch.
<attie> whitequark, as the resident cursed tech expert, any ideas?
<cr1901_modern> pattern rules?
<cr1901_modern> %.v: my_migen_script.py
<attie> that will re-run it 4 times
<attie> and overwrite some of the .v s while vivado is already trying to synthesize them
<cr1901_modern> https://www.cmcrossroads.com/article/rules-multiple-outputs-gnu-make According to this, GNU Make is smart enough to run the command once
<whitequark> attie: oh
<whitequark> you can do something like
<whitequark> %_foo.v %_bar.v: %.py
<attie> that was my first attempt, but with make -j that re-ran the rule for every target
<attie> > But here's what will really bake your noodle: f you reverse the order in which the output files are listed as prerequisites of all, suddenly the files are generated only once, because those algorithms are very sensitive to the order in which dependencies are declared.
<attie> maybe I just haven't found the right order for the rules yet?
<attie> oh hm maybe the subfolders are interfering
rohitksingh has quit [Ping timeout: 250 seconds]
<whitequark> wtf
<attie> ok, it seems to work now
<attie> had to twiddle it oddly to find a common stem, but at least didn't have to resort to matching the . from the extension like one stackoverflow answer suggested
<attie> thanks!
<attie> was getting quite fed up with discovering, 2h later, that only half of the syntheses was launched.
<cr1901_modern> oh it's one of those FPGAs I can't afford, like a Virtex?
<attie> it's a ku060, not quite as big
<attie> join a university, and people will send you this stuff for free ^_^"
<cr1901_modern> When I was in uni, cyclone ii was still a respectable fpga
<cr1901_modern> now cyclone iv isn't even supported in quartus anymore?
<attie> dunno, I last touched quartus in undergraduate, aside from three weeks last year
rohitksingh has joined #m-labs
<attie> after checking release dates, we probably did use cyclone II at the time.
AceChen has quit [Remote host closed the connection]
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
lkcl has quit [Ping timeout: 250 seconds]
lkcl has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
_whitelogger has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 272 seconds]
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fhUZh
<_whitenotifier-6> [m-labs/nmigen] whitequark d47c1f8 - back.rtlil: use one $meminit cell, not one per word.
<_whitenotifier-6> [m-labs/nmigen] whitequark f05bd2a - hdl.mem: allow omitting memory simulation logic.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/471837349?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. Absolute coverage decreased by -0.03% but relative coverage increased by +0.49% compared to 98f554a - https://codecov.io/gh/m-labs/nmigen/commit/f05bd2a137e647e26a594c48a4723f8395e07ed2
<_whitenotifier-6> [nmigen] Success. 80% of diff hit (target 79.5%) - https://codecov.io/gh/m-labs/nmigen/commit/f05bd2a137e647e26a594c48a4723f8395e07ed2
_whitelogger has joined #m-labs
<GitHub198> [smoltcp] 1uka opened pull request #268: implement BPF sockets to be used as RawSocketDesc on BSD-like OSes (master...bsd-rawsocks) https://github.com/m-labs/smoltcp/pull/268
X-Scale has quit [Read error: Connection reset by peer]
<GitHub176> [smoltcp] dlrobertson commented on pull request #268 8cfac71: Why 100? I don't know bpf, but I have seen other scripts that go up to 255. https://github.com/m-labs/smoltcp/pull/268#discussion_r243838795
<GitHub188> [smoltcp] dlrobertson commented on pull request #268 8cfac71: Currently it is possible that this `cfg` is met, but the `cfg` for the `bpf` is not met. E.g. `target_os = "netbsd"`.... https://github.com/m-labs/smoltcp/pull/268#discussion_r243839379
<GitHub194> [smoltcp] dlrobertson commented on pull request #268 8cfac71: Would be more "rusty" to use an option here instead of using `-1` as the "unpopulated" value. https://github.com/m-labs/smoltcp/pull/268#discussion_r243838741
zng has quit [Quit: ZNC 1.8.x-nightly-20181211-72c5f57b - https://znc.in]
zng has joined #m-labs
rohitksingh has joined #m-labs
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhUae
<_whitenotifier-6> [m-labs/nmigen] whitequark 010ddb9 - back.rtlil: unbreak d47c1f8a.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/471933892?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.47% remains the same compared to f05bd2a - https://codecov.io/gh/m-labs/nmigen/commit/010ddb96b5c0e75219ed819625d705b0337ed485
<_whitenotifier-6> [nmigen] Success. Coverage not affected when comparing f05bd2a...010ddb9 - https://codecov.io/gh/m-labs/nmigen/commit/010ddb96b5c0e75219ed819625d705b0337ed485
rohitksingh has quit [Ping timeout: 246 seconds]
<GitHub165> [smoltcp] whitequark commented on pull request #268 8cfac71: Please add this to your `$HOME/.gitignore`; smoltcp should not collect files of every IDE that exists. https://github.com/m-labs/smoltcp/pull/268#discussion_r243857038
kristianpaul has quit [Quit: Lost terminal]
<GitHub189> [smoltcp] 1uka commented on pull request #268 8cfac71: Yeah on macOS there are a total of 256 BPF devices, but I usually only try the first 100, because sometimes it might be a bad idea to open another one if 100 are already busy. But, I will change this to go up to `/dev/bpf255` if that is what you want. https://github.com/m-labs/smoltcp/pull/268#discussion_r243860581
<GitHub58> [smoltcp] 1uka commented on pull request #268 8cfac71: You are right. I usually write C and I am not yet used to rust's syntax sugar tricks. I wrapped the `unsafe` block in a function that returns `io::Result`, you can tell me what you think about it. https://github.com/m-labs/smoltcp/pull/268#discussion_r243860582
<GitHub30> [smoltcp] 1uka commented on pull request #268 8cfac71: Oops, sorry, missed that one. Fixing it in the next commit https://github.com/m-labs/smoltcp/pull/268#discussion_r243860584
<GitHub75> [smoltcp] 1uka commented on pull request #268 8cfac71: Ok, done. Sorry, I didn't have a global `.gitignore` file, never thought about it 😅 https://github.com/m-labs/smoltcp/pull/268#discussion_r243860638
<kbeckmann> (noob question) When testing a simple FSM in migen using run_simulation(), the vcd output seems to create some huge state registers that don't match the verilog output at all - getting a 96 bit next_state and 80 bit state register that contain huge values even though I only have 2 states. Does this sound familiar, I'm probably doing something stupid here?
mauz555 has joined #m-labs
<acathla> kbeckmann, display them as ASCII and you'll have their name =)
<kbeckmann> oh wow.. thanks :D
<kbeckmann> that's really useful!
<acathla> My pleasure, I feel less noob now :)
<kbeckmann> When writing tests in migen, is there a good way of testing which state you are currently in? Having some trouble accessing the state register.. Asserting on normal signals work fine.
mauz555 has quit []
<kbeckmann> maybe it doesn't make sense to test the state machine, but rather the outputs it changes..