00:08 <_whitenotifier> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/Jt20w

00:08 <_whitenotifier> [YoWASP/nextpnr] whitequark 9f8cfa7 - Update dependencies.

00:37 <_whitenotifier> [nmigen] hansfbaier commented on issue #572: Add option to suppress code generation comments - https://git.io/Jt2E1

00:37 <_whitenotifier> [nmigen] hansfbaier edited a comment on issue #572: Add option to suppress code generation comments - https://git.io/Jt2E1

00:39 <_whitenotifier> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/Jt2EQ

00:39 <_whitenotifier> [YoWASP/yosys] whitequark ef1ecb2 - Update dependencies.

01:14 <_whitenotifier> [nmigen] whitequark commented on issue #572: Add option to suppress code generation comments - https://git.io/Jt2u6

01:15 <_whitenotifier> [nmigen] whitequark edited a comment on issue #572: Add option to suppress code generation comments - https://git.io/Jt2u6

02:45 <agg> in case anyone else is like me and regularly ends up running nextpnr with --seed 1, --seed 2, --seed 3 until it passes, i finally hacked together a little python script to do it and collect stats/console histogram etc https://twitter.com/adamgreig/status/1357882118731427840

02:46 <agg> (I appreciate the timing accuracy is not necessarily good enough for a MHz or two to make a real difference...)

02:56 <vup> hmm, how is one supposed to handle FFSynchronizers together with nmigen formal? The FFSynchronizers are reset-less by default (for good reasons), but when using formal this of course causes problems, as even if one properly resets the design / assumes a valid initial state, one cannot assume the proper values for the inner stages of the FFSynchronizer

03:31 <_whitenotifier> [nmigen] hansfbaier commented on issue #572: Add option to suppress code generation comments - https://git.io/Jt2a5

03:35 <mithro> agg: I love that! You did a much better job then I would have.

03:36 <agg> I guess I should tidy up the wrapper and release it properly 😅

03:37 <agg> I was planning to add "stop on success", your Google doc is exactly what I wanted

03:37 <mithro> agg: daveshah said he would be interested in including something like that with nextpnr

03:38 <mithro> agg: I was actually more interested in the statistical side of things...

03:38 <agg> Probably better done inside npnr rather than relying on a python wrapper but my c++ is long neglected and not sure how straightforward spawning the processes would be

03:39 <agg> Yea, the stats are quite interesting, though what I actually want to know is what difference it makes in reality

03:40 <agg> In this toy example there's maybe 5MHz of spread and I expect you'd need to go to a corner of PVT space to see any difference

03:43 <agg> Might be a fun excuse to fix the long broken env chamber at work, heh. I wonder if it makes sense as a sort of "production release" to spend some cpu finding the best seed and hoping it buys you some margin.

12:58 <d1b2> <mardab> Hey, can I ask about something that I'm pretty sure that one might call it stupid?

13:04 <Sarayan> stuuuuuuuuuuuuupid!

13:04 <Sarayan> Ok it's done, you can ask now

13:45 <d1b2> <mubes> @agg just made my Christmas card list brilliantly helpful. Ta. I've got a build that seems to have a pretty spread depending on seed, so I'm well used to the 'am I feeling lucky' random number generator thing....indeed, release builds have the magic number coded into the makefile to save others the pain.

14:01 <agg> mubes: glad to hear it! definitely got a more positive reception than I expected for 50 lines of late night python

23:38 <lsneff> Found some time to work on ligeia again. Been having trouble with inconsistent mmap performance.