18:21 <Sarayan> meh, I need a nmigen debugger, very sad that doesn't exist yet

18:24 <awygle> word

18:25 <awygle> i'm working on one, and ktemkin linked the one from Luna a while back

18:27 <awygle> it would be great if it was more integrated, Someday

18:30 <Sarayan> I have some ideas on how I'd like it, but it requires some tech we don't currently have

18:39 <awygle> like what?

18:46 <Sarayan> fast, probably llvm-based sim where you can reconfigure what signals you want to observe and what triggers the start of the recording and have the debugger run it and display the result

18:46 <Sarayan> rougly, cxxrtl but jit

18:47 <MadHacker> I'd settle for slow but checkpointable. If you can get back to a reasonable state without having to run the full sim history, that's fine.

18:47 <MadHacker>

18:48 <MadHacker> Oops, sorry. Anyway, yeah, some ability to restore a previous state. Possibly replay the inputs of a module, too.

18:52 <Sarayan> I'd put in python signal generators, I guess

18:53 <Sarayan> with things like "68000 write cycle"

18:53 <MadHacker> Wonder how picklable the sim state is?

18:53 <Sarayan> or "perfectly standard-conforming i2c master", since we're going for unicorns and ponies

19:22 <awygle> oh, you mean off-hardware debugging

19:23 <awygle> i agree with that, see my comments on https://github.com/nmigen/nmigen/issues/327

19:46 <Sarayan> pysim is rather slow and can't handle memory of any decent size

19:47 <Sarayan> and needing a hundred million cycles is, well, just normal

19:47 <Sarayan> decent size = I blew it up hard with a 128K rom

19:48 <Sarayan> that bad

19:48 <Sarayan> while cxxrtl manages it handily

19:50 <awygle> sure

19:50 <awygle> my typical attitude is "make it work then make it fast"

19:50 <awygle> but there's certainly an argument that a slow sim isn't owrking