02:25 <_whitenotifier-e> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JeMZm

02:25 <_whitenotifier-e> [m-labs/nmigen] whitequark d048f06 - hdl.ast: actually remove simulator commands.

02:42 <_whitenotifier-e> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/619413064?utm_source=github_status&utm_medium=notification

02:42 <_whitenotifier-e> [nmigen] Success. 82.19% (+0.15%) compared to 72cfdb0 - https://codecov.io/gh/m-labs/nmigen/commit/d048f069f86c64c3ac036f8edc9d06be1addb5a2

02:42 <_whitenotifier-e> [nmigen] Success. Coverage not affected when comparing 72cfdb0...d048f06 - https://codecov.io/gh/m-labs/nmigen/commit/d048f069f86c64c3ac036f8edc9d06be1addb5a2

14:42 <rjo> sb0: bonn1 needs that suservo change in master. i'm fine either way (back porting the change or excluding bonn1 from stable). what do you think?

14:44 <rjo> i don't know how to do the latter

18:13 <adamgreig> whitequark: it seems like pysim2 is running one more clock cycle after my sync process finishes, is that expected? i.e., I see four full clocks in gtkwave but only yield three times from my sync process

18:19 <adamgreig> also a change/regression from pysim1 i've noticed: i have c=Signal(10), x=Signal(signed(7)), x is -5, c.eq(c-x), I expect c to increase by 5 but instead it decreases by 123; if I make x signed(10) so the overflow works out then it works as expected

18:19 <adamgreig> not sure if pysim should be doing the relevant sign extension for me here or what, but I'm pretty sure that's hwo it used to work in pysim1

18:46 <whitequark> adamgreig: re 1: it's not a deliberate change but I'm not sure if that was ever a proper guarantee

18:47 <adamgreig> i just found the wrapper fn in add_sync_process that always yields a tick before yielding from the process

18:47 <whitequark> that's different

18:47 <adamgreig> so that would explain the extra cycle i think (though from gtkwave it looked to me like the extra cycle was at the end?)

18:47 <adamgreig> ah ok

18:47 <whitequark> it skips the half-cycle between reset and first posedge

18:47 <adamgreig> explains why it seemed like the extra cycle was at the end :P

18:47 <adamgreig> got you

18:47 <whitequark> that should actually match pysim1 behavior

18:47 <adamgreig> the extra cycle isn't a problem or anything, just was curious while i was trying to minimise the second problem

18:47 <whitequark> alright

18:48 <whitequark> re second problem: try this: https://paste.debian.net/1119089/

18:49 <adamgreig> that fixes my minimal test case

18:50 <adamgreig> and also my original non-reduced test case

18:50 <adamgreig> aaand everything else still passes

18:52 <whitequark> so as usual, I tried to make an optimization and failed

18:52 <whitequark> ah well

18:53 <_whitenotifier-e> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeMwb

18:53 <_whitenotifier-e> [m-labs/nmigen] whitequark 7650431 - back.pysim: fix miscompilation of Signal(unsigned) - Signal(signed).

18:53 <adamgreig> i have a different weird thing but i have no guesses about this one: if i delete the docstring of an unused class, it changes simulation behaviour

18:59 <adamgreig> http://dpaste.com/22ZZZCQ if you run it and then delete the docstring line and run again, I get 0 the first time and 512 the seocnd time

19:07 <_whitenotifier-e> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/619764190?utm_source=github_status&utm_medium=notification

19:08 <_whitenotifier-e> [nmigen] Success. 82.26% (+0.06%) compared to d048f06 - https://codecov.io/gh/m-labs/nmigen/commit/76504319962524b02c7d21111295b655e009bd76

19:08 <_whitenotifier-e> [nmigen] Success. 100% of diff hit (target 82.19%) - https://codecov.io/gh/m-labs/nmigen/commit/76504319962524b02c7d21111295b655e009bd76

19:09 <_whitenotifier-e> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/619764190?utm_source=github_status&utm_medium=notification

19:10 <_whitenotifier-e> [nmigen] Success. 82.19% (+0%) compared to d048f06 - https://codecov.io/gh/m-labs/nmigen/commit/76504319962524b02c7d21111295b655e009bd76

19:44 <whitequark> adamgreig: yes.

19:44 <whitequark> this is a race condition in your code that happened to behave deterministically on pysim1

19:44 <whitequark> that determinism was also present in migen but only by accident

19:45 <Sarayan> accidental determinism, what a concept

19:45 <whitequark> I have plans for fixing it properly but that will happen after i finish cxxsim

19:45 <whitequark> among other things it has a related but different simulation model that needs to be taken into account

19:45 <Sarayan> did I say that cxxsim sounded like an extremely good idea already?

19:46 <whitequark> is that sarcasm

19:46 <Sarayan> not at all

19:46 <Sarayan> fast sim is very, very good

19:46 <whitequark> ah, great

19:47 <Sarayan> once I manage to do things at a bigger scale I'm pretty sure I will love it

20:10 <adamgreig> I am also very excited for cxxsim

20:11 <adamgreig> Currently doing gross things to use verilator for one or two tests that need very many cycles

20:12 <whitequark> how gross are they?

20:14 <adamgreig> Meh, a custom external makefile, some glue c++, some spitting stuff back to python, none of it's totally awful but it's very specific and was annoying

20:14 <whitequark> ah I see

20:14 <adamgreig> Mostly just made it easier to run a sim and view it in gtkwave where normally my tests are lots of asserts throughout sim