<lkcl>
awygle: thank you. well it's that we've now got a large codebase (68,000 up from 45,000 for the core, 26,000 for the IEEE754 FP library) and so a code-morph is a little bigger than it would be for e.g. a 4,000 line project.
<_whitenotifier-f>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JTp2g
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JTp21
<awygle>
to be clear the branch above should have no functional change compared to Record as it is now
<whitequark>
what awygle did *is* a migration path
<whitequark>
(if i correctly recall the PR we discussed)
<lkcl>
ah super
<awygle>
yup. NFC, but record is based on ValueCastable not UserValue (which i guess could have functional changes if you're doing something particularly weird, but that's why testing)
<lkcl>
hm, i wonder, awygle, if you'd like some $EUR for doing that? would that help at all?
<awygle>
i'm financially pretty ok, and i don't live in the EU so the logistics are not straightforward
<lkcl>
very few of us do, and it's not a problem.
<lkcl>
however if you're financially doing ok then great
<lkcl>
NLnet is very flexible, you don't have to *live* in the UK. only the person who signs the MoU has to list an *address* that is in the EEC. which includes Iceland. which we have someone whose home address is there :)
<lkcl>
s/UK/EU
<awygle>
a sad correction
<whitequark>
awygle: > object.__new__ and object.__init__ are special in another way. For the object class itself, their signatures are (Subclass[T]) -> T and (T) -> None. However, when called from subclass constructors via super(), the signatures are (Subclass[T], *args, **kwargs) -> T and (T, *args, **kwargs) -> None.
<whitequark>
wtf
<awygle>
oh python. you never stop giving.
<lkcl>
ahh you're overriding __new__ and __init__? oooo
<lkcl>
i know someone who knows how they work
<whitequark>
not __init__. only __new__
<lkcl>
1 sec
<awygle>
doesn't that mean it should _want_ me to do the *args, **kwargs thing?
<whitequark>
i know how they work in general
<awygle>
but i got a syntax error
<lkcl>
i got advice from them on stackexchange, i was really amazed and delighted
<whitequark>
what i'm currently looking at is a particularly subtle corner case
<lkcl>
i've done mro / base stuff before, what's the case?
<_whitenotifier-f>
[nmigen] whitequark opened issue #528: Redesign Record to be based on ValueCastable - https://git.io/JTpay
<_whitenotifier-f>
[nmigen] awygle opened pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpad
<awygle>
goddamit git and/or github
<whitequark>
agh
<whitequark>
i even wondered if you were typing that one, then decided you'd probably say
<_whitenotifier-f>
[nmigen] awygle synchronize pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpad
<whitequark>
wait
<whitequark>
that's a PR not an issue
<awygle>
correct
<awygle>
it even references the issue
<awygle>
i just pushed wrong because push doesn't work on your checked out branch if you specify a remote and a remote branch but i always think it will
<awygle>
fixed now
<whitequark>
fastest implementation of *any* feature i've ever seen :p
<awygle>
that's what we in the biz call "cheating" :p
<whitequark>
2 minutes from issue to PR :p
<_whitenotifier-f>
[nmigen] codecov[bot] commented on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<awygle>
is codecov updating while the CI is still running? that seems... not right.
<awygle>
(i know, i know, just ignore codecov... but i can't apparently)
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<whitequark>
awygle: several CI jobs
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<_whitenotifier-f>
[nmigen] awygle synchronize pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpad
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<awygle>
whitequark: can you take the deprecation of UserValue? i'm not totally sure how you want that done
<whitequark>
awygle: taken
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<awygle>
sweet, thx
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<_whitenotifier-f>
[nmigen] whitequark commented on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpw5
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpVv
<_whitenotifier-f>
[nmigen] awygle commented on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTprU
<_whitenotifier-f>
[nmigen] whitequark commented on pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTprI
<_whitenotifier-f>
[nmigen] whitequark closed issue #528: Redesign Record to be based on ValueCastable - https://git.io/JTpay
<_whitenotifier-f>
[nmigen] whitequark closed pull request #529: Migrate Record to ValueCastable, from UserValue - https://git.io/JTpad
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JTprq
<_whitenotifier-f>
[nmigen/nmigen] awygle abbebf8 - hdl.rec: migrate Record from UserValue to ValueCastable.
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JTprY
<_whitenotifier-f>
[nmigen/nmigen] whitequark 59b7db1 - Deploying to gh-pages from @ abbebf8efe931938f0de95d041f1d91c693efddc 🚀
<awygle>
oh i was gonna PR that thing from harmon
<awygle>
... maybe after dinner
<whitequark>
awygle: excellent work
<whitequark>
makes us materially closer to release
* awygle
waves hands, makes "pshaw" noises
<awygle>
happy to help
<awygle>
we're just waiting on cxxsim now right? well and the deprecation which shouldn't take long
<whitequark>
two things, merging cxxsim and Display (which is cxxsim-adjacent)
<_whitenotifier-f>
[nmigen] RobertBaruch commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JTprK
<awygle>
anything i can do to help with either of those?
<whitequark>
possibly but i'll need to dig deeper into ... both of them really
<awygle>
(they seem pretty far in your wheelhouse but)
<awygle>
mk, lmk, i'll run off and work on other stuff til i hear from you i spose :p
<whitequark>
Display is mostly just annoying yosys plumbing
<whitequark>
cxxsim might or might not require new creative additions to the C API
<awygle>
mmm C APIs, my favorite
<whitequark>
cxxrtl's is explicitly designed to be easy to bind from rust
<whitequark>
carefully chosen ownership
<awygle>
that's cool. though i have a hard time imaginging a use case where rust would bind cxxrtl instead of writing rsrtl, being careful about ownership is always a good thing lol
<whitequark>
well, cxxrtl has C++ blackboxes
<whitequark>
maybe you want to link those
<awygle>
True
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JTprF
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JTpow
<_whitenotifier-f>
[nmigen/nmigen] whitequark c6150d0 - vendor.lattice_{ice40,ecp5}: clean up $verilog_initial_trigger wires.
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JTpoK
<_whitenotifier-f>
[nmigen/nmigen] whitequark 3d51bf6 - Deploying to gh-pages from @ c6150d05867bea1a7266e3c950d3d9846ba7ed58 🚀
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JTpox
<_whitenotifier-f>
[nmigen/nmigen] whitequark 10fd5cf - CI: run testsuite with -Werror.
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JTpKf
<_whitenotifier-f>
[nmigen/nmigen] whitequark 33cdac0 - Deploying to gh-pages from @ 10fd5cff4ba3f6715146947c67c1a84e28926b10 🚀
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JTpKZ
<_whitenotifier-f>
[nmigen/nmigen] whitequark db5a981 - CI: add CPython 3.9 to test matrix.
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JTpi2
<_whitenotifier-f>
[nmigen/nmigen] whitequark b2921b7 - Deploying to gh-pages from @ bde37fe2f2eb83a950f9a1beefca888c3fede3f2 🚀
<cr1901_modern>
whitequark: I haven't been following #526 closely, but re: $global_clock I thought the proposed idea was to automatically derive a set of assumes so that each clock eventually ticks (thus not exposing $global_clock at all)
<cr1901_modern>
at all in nmigen*
<whitequark>
right, that was long enoough ago i forgot about it
<whitequark>
that's also reasonable
<whitequark>
you need basically one $ff cell instantiated by the platform
<whitequark>
then assume(xor(ff.q,ff.d))
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
loxodes has quit [Ping timeout: 256 seconds]
<cr1901_modern>
That wasn't how I did such assumes- I did it the naive way (assume (clk0_prev != clk0) or (clk1_prev != clk1));... something like that) but that sounds like it would work too.
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JTpPU
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #526: Past should not be allowed in m.d.comb - https://git.io/JTpPU
<d1b2>
<OmniTechnoMancer> Is there any guidance on how one does assumes to assume that the reset has been asserted at the beginning of modeling and released!
<d1b2>
<OmniTechnoMancer> ?
<cr1901_modern>
something like "initial assume rst == 1" should be enough.
<d1b2>
<OmniTechnoMancer> Ah cool, or 0 if active low reset I assume
<cr1901_modern>
indeed
<awygle>
If you're doing K-induction that will only work for BMC
<cr1901_modern>
I admit I'm not gonna work out an example on paper/in my head tonight, but if you're reset is working properly, the lack of "initial assume rst == 1" shouldn't screw up the proof.
<_whitenotifier-f>
[nmigen] RobertBaruch commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JTpQm
PyroPeter_ has joined #nmigen
<d1b2>
<OmniTechnoMancer> For k-induction or BMC or both?
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
<cr1901_modern>
for k-induction; initials work with BMC
<cr1901_modern>
but they're not meaningful for k-induction
electronic_eel has quit [Ping timeout: 260 seconds]
<_whitenotifier-f>
[nmigen] kbeckmann opened pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0s
<_whitenotifier-f>
[nmigen] codecov[bot] commented on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] kbeckmann synchronize pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0s
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0r
<_whitenotifier-f>
[nmigen] whitequark closed pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JTh0s
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JThu4
<_whitenotifier-f>
[nmigen/nmigen] kbeckmann ebbdac9 - vendor.intel: add support for Cyclone V internal oscillator
<_whitenotifier-f>
[nmigen] whitequark commented on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JThuR
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JThuu
<_whitenotifier-f>
[nmigen/nmigen] whitequark bcc0bba - Deploying to gh-pages from @ ebbdac97987cb91e2418e80e2416c3a81f1dabdc 🚀
<_whitenotifier-f>
[nmigen] kbeckmann commented on pull request #530: intel: Add support for Cyclone V internal oscillator - https://git.io/JThuj
<d1b2>
<dub_dub_11> Woo just tested my board definition file for the de1 soc
<d1b2>
<dub_dub_11> Runs the blinky test from nmigen-boards