ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen
<emily> for values of "everyone" equal to "non-embedded linux" at best, and then taking debian derivatives out of that is an even bigger chunk
<emily> meanwhile macos ships with a version of bash from 2007, embedded linux and bsds often not at all
<whitequark> ktemkin: that works individually but then i wouldn't see what most people trying to use it will
<awygle> that does seem to have fixed it
<awygle> so that's good
<ktemkin> whitequark: yeah, sorry; that wasn't really a suggestion -- my "~"-terminating statements are meant to be tongue-in-cheek
* emily apologises for her pedantry :v
<ktemkin> emily: you'd think that 'embedded linux' folks would know better, but when last I checked, running *openembedded* required /bin/sh to be a symlink to bash
<ktemkin> (admittedly, when last I checked was like six years ago, but yeah)
<emily> often you're dealing with e.g. busybox ash or worse, in my experience
<emily> build scripts tend to be a total unportable mess though, yeah
<emily> the real lesson from shell script hell is to just write as few shell scripts as possible
<whitequark> yeah
<ktemkin> thank gods we've learned from our mistakes and modern scripting languages never do things like use the same binary name for multiple incompatible language dialects
* ktemkin goes back to writing python
kmtd has joined #nmigen
kmtd has quit [Client Quit]
<whitequark> ktemkin: remember how ruby would change syntax in incompatible ways in patch versions?
<ktemkin> lol, yeah; I think I stopped using ruby _before_ they implemented a coherent concept of patch versions
<ktemkin> I drifted away from ruby while 2.0 was either upcoming or very new
<whitequark> they did that in 1.9 too
<ktemkin> yeah; (I'm saying they didn't actually agree to keep anything compatible until something like 2.1, so I never actually saw them -stop-)
<whitequark> oh, they didn't agree for it yet
<whitequark> not for syntax i think
<whitequark> ~half a year ago there was a discussion someone linked to me
<whitequark> but i think no actual decision
<ktemkin> I think rather fondly back on ruby; but it's very much become one of those languages that I don't think I'd ever pick up again
<ktemkin> https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/ <-- this is roughly what I interpreted as preventing breaking syntax changes over a patch-version
<ktemkin> the language is a bit ambiguous as to what'd require a "teeny" (patch) version bump, but particularly the goal of `user can safely upgrade ruby to a new teeny version without having to rebuild and reinstall already installed libraries` seems like it'd preclude them from both meeting their versioning scheme and making breaking syntax changes in 2.1+
<ktemkin> dunno if in practice that was interpreted only as applying to the actual API/ABI and not e.g. to the language specification; as that seems like it'd be way out there
<cr1901_modern> awygle: http://ix.io/2bPA Hmm I vaguely recall having to do this step as well, but I must've done it a while ago...
<cr1901_modern> oh damnit I'm sick of paste fails
<cr1901_modern> http://ix.io/2bPC Here we go
<whitequark> ktemkin: the changes in question were treated as bugfixes
<whitequark> but it *did* change the grammar
<cr1901_modern> whitequark: Just to be crystal clear from rereading plat.py... if using diamond, yosys is only run while the jinja templates are being instantiated?
<whitequark> yeah
XgF is now known as gay
<cr1901_modern> https://github.com/nmigen/nmigen/blob/3e2ecdf2fb49d7339ac6f812521c290513dc8a10/nmigen/vendor/lattice_ecp5.py#L181 Can this line be removed then since yosys doesn't generate any build artifacts from the build script's POV?
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-dude has quit [Ping timeout: 272 seconds]
<whitequark> cr1901_modern: maybe. what for?
<cr1901_modern> Oh, I was just curious. I misunderstood why changing sh to bash was the only fix needed.
<cr1901_modern> Because I thought yosys was run in the script _after_ diamond_env was run
<whitequark> changing sh to bash has nothing to do with nmigen
<whitequark> their tools are just broken
<cr1901_modern> Anyways, while free toolchains aren't ready yet: if yosys is ever necessary in the diamond (or other proprietary toolchains) backends, won't the CXX library mismatch happen?
<cr1901_modern> Eh, I guess I won't worry about it
<whitequark> yosys is necessary in the diamond backend
<whitequark> it's just never run in the environment where diamond sets up LD_LIBRARY_PATH
<whitequark> specifically for this reason
<whitequark> that is also why NMIGEN_ENV_* exist, and you don't just source the diamond environment script before running nmigen
<whitequark> it's not just convenience, it's actually required for it to work
<awygle> whitequark: so i was playing with building litex under nmigen and there seem to be quite a few things it uses missing from nmigen.compat (and documented that way). just wondering if those are by and large in need of some architectural decision, or just the work hasn't been done yet? specifically looking at genlib.misc, for the most part
<awygle> fwiw i was able to just copy most of migen's genlib.misc, replace a couple things, and build it without issue, although i have no idea if it like.... works
<whitequark> awygle: yeah it should be OK to just copy genlib.misc over
<whitequark> feel free to do a PR
<awygle> mk, i'll make a pr
<awygle> now litex _does_ fuck with private classes of fhdl.structure
<awygle> which i imagine is a bad idea to just grab and go with
<awygle> but i'll tackle that another time lol
<whitequark> what does it do?
<awygle> i don't really understand the under-the-hood mechanics well enough to know for sure, but it does import _Value and _Fragment directly
<whitequark> can you open a meta-issue documenting what it does and where so we can discuss it?
<awygle> mostly to call isinstance on them it looks like
<awygle> sure, will do
<whitequark> oh
<whitequark> ugh, isinstance()
<whitequark> i know how to make that work transparently but it's kind of a horrifying hack
<cr1901_modern> This also came up when litex duplicated all the FHDL classes for its own variant of omigen...
<awygle> i'm tempted to say the best solution here is to actually replace those with nmigen equivalents
<awygle> since litex has expressed interest in doing that anyway
<cr1901_modern> FWIW, litex eventually _did_ start using omigen directly and FHDL mismatches disappeared
<cr1901_modern> definitely feasible I would think
<awygle> but i want to more properly understand what exactly they're trying to do, so i'll endeavour to do that
<awygle> there's also gotta be people we can ask lol
<cr1901_modern> awygle: /join #timvideos and #litex?
<cr1901_modern> mithro would be one person to ask
mithro has joined #nmigen
<cr1901_modern> D-did I just summon mithro :o?
<whitequark> (i /query'd)
<mithro> Hi!
sorear has joined #nmigen
<awygle> hi mithro. do you know what litex needs with _Value and _Fragment and the like from migen.fhdl.structure? why is it accessing these private classes?
<awygle> context - discussing what it would take to get litex building under nmigen (even with nmigen.compat)
<mithro> awygle: _florent_ would be a much better person to ask :-)
<mithro> awygle: I'm more a "manager" these days and don't get much time to actually write litex code :-(
<cr1901_modern> Is "LFE5UM-45F-8BG381C" one of those devices that requires a license? Because I get "failed to create project" consistently when trying to run the blinky from versa_ecp5 in nmigen boards
<cr1901_modern> (I manually changed the toolchain to Diamond to test something)
<whitequark> cr1901_modern: versa comes with an evaluation license, yes
<whitequark> or maybe not evaluation? i think i never activated mine
<whitequark> don't have patience to deal with flexlm bullshit
<cr1901_modern> okay, good to know
<cr1901_modern> Well trying to create a project consistently fails and I never... bypassed flexlm. How difficult is it?
<TD-Linux> "git clone nextpnr" /me runs
<awygle> it's evaluation yes
<whitequark> TD-Linux: nextpnr can't do derived clocks or IOB timing
<awygle> for a year
<whitequark> also back when i wrote Yumewatari it didn't have QoS/QoR enough for even PCIe Gen1
<whitequark> almost but not quite
<TD-Linux> the colorlight board demo also misses timing but I haven't tried comparing it to diamond yet
<awygle> this is a dumb question but what does litex actually _do_? like i get the soc stuff but why does it have its own board and platform abstractions?
<awygle> and its own verilog generator, and and and...
<cr1901_modern> awygle: See DM
<cr1901_modern> err privmsg
<whitequark> awygle: because migen has been consistently hostile to integrating changes litex needed, basically. litex used to be a complete migen fork
<awygle> ah
<awygle> is there an nmigen equivalent of PulseSynchronizer?
<whitequark> no; it's not ported yet
<whitequark> there's this rather old PR: https://github.com/nmigen/nmigen/issues/47
<whitequark> feel free to grab PulseSynchronizer from that PR and submit it on its own
<whitequark> and we should coordinate with Luke to re-add the rest
<awygle> oh this is an _issue_ not a PR, i was confused briefly :p
<awygle> yeah sure, sounds good
<whitequark> it's a PR
<whitequark> it just got turned into an issue during repo migration
<awygle> yeah, i get it now
<_whitenotifier-3> [nmigen] whitequark commented on issue #47: WIP: Expand and document lib.cdc - https://git.io/Jv8LS
<awygle> whitequark: is there any kind of python style linter i should run before sending this PR?
<awygle> i'd hate to waste your time with "you moron, no tabs" kinds of problems
<whitequark> awygle: i normally just edit this kind of style nits myself to avoid bothering contributors
<whitequark> generally it's just 4 spaces, 2 newlines between toplevel entities
<whitequark> (the latter comes from pep8)
<awygle> Mk, ideally that's correct already...
<ktemkin> related: I need to stop being bad and just implementing things in my own projects' libraries that maybe should be in {nmigen-*} >.>
* ktemkin eyes nmigen-stdio somewhat guiltily
<_whitenotifier-3> [nmigen] awygle opened pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tw
<ktemkin> were there plans/discussions/etc for -stdio captured anywhere?
<ktemkin> I'm at the point where I keep implementing things in e.g. LUNA where it seems like effort might be better spent on doing something more standard/upstream
<awygle> we just chatted about this the other day, we need a stream abstraction: https://github.com/nmigen/nmigen/issues/317
<awygle> which doesn't seem too difficult but does seem... daunting
<_whitenotifier-3> [nmigen] codecov[bot] commented on pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tF
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tF
<ktemkin> awygle: I saw that discussion; but missed any higher-level discussions that may have preceded it (e.g what's in scope for -stdio, etc.)
<awygle> oh, we talked about that too. nmigen-soc is basically busses and registers, nmigen-stdio is standard i/o peripherals attached to the aforementioned stream abstraction
<awygle> nmigen-soc would contain a stream-to-axi4stream converter (for example)
<awygle> at least that's my understanding
<awygle> whitequark: adding PulseSynchronizer to nmigen.compat.genlib.cdc, i notice there's a "test_compat.py" but it doesn't seem to be used anywhere. are compat tests expected? if so, where can i find an example?
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tF
<ktemkin> what needs to be
<ktemkin> Er, Enter key
<ktemkin> what needs to be {investigated, discussed, etc} in order to move the stream abstraction forward?
<ktemkin> it seems like what's lacking in that GH issue is identification of any weaknesses of the litex::stream architecture that might be addressed when creating the nmigen one
<_whitenotifier-3> [nmigen] whitequark reviewed pull request #321 commit - https://git.io/Jv8qD
<_whitenotifier-3> [nmigen] whitequark reviewed pull request #321 commit - https://git.io/Jv8qy
<_whitenotifier-3> [nmigen] whitequark reviewed pull request #321 commit - https://git.io/Jv8qS
<whitequark> ktemkin: awygle: there's a bit of an annoyance wrt Stream in that I really need to be working on docs right now
<whitequark> I'll try to find some time to dedicate to it, though
<ktemkin> no pressure; I'm fine waiting -- just wondering if there's something I could be doing to help in the interim
<whitequark> there's a lot of design discussion to be had with stream, stdio, etc...
<whitequark> hmm
<whitequark> one thing you (or someone else) could do is to summarize the feature set of wishbone, axi4, litex stream to see what the intersection is
proteus-guy has joined #nmigen
<ktemkin> I'd be willing to do that
<ktemkin> is there a preferential place to capture things like that, beyond in the issue? (in the issue sucks for collaborative/iterative capture)
<ktemkin> s/preferential/preferred
<whitequark> no particular preferred place
<awygle> echoing ktemkin, no rush no pressure
<awygle> docs obviously critical
proteus-dude has joined #nmigen
<awygle> whitequark: is the "deprecated simulator interface" the context manager specifically?
<whitequark> awygle: the outer wrapper. the deprecation warnings should tell you what to do
<whitequark> or you could look at the other test
proteus-dude has quit [Client Quit]
<awygle> i'm not getting any deprecation warnings...
<whitequark> yes, python doesn't enable them by default
<whitequark> try -Wd
<awygle> ah, okay, thank you, that's hugely useful
<_whitenotifier-3> [nmigen] awygle synchronize pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tw
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tF
<awygle> aaaand i answered my earlier stupid question so that's good...
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tF
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tF
<_whitenotifier-3> [nmigen] whitequark closed pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tw
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/Jv8mQ
<_whitenotifier-3> [nmigen/nmigen] awygle fcbabfe - nmigen.lib.cdc: port PulseSynchronizer.
<awygle> hooray i'm a contributor
<whitequark> you were before, though
<whitequark> or... maybe not?
<whitequark> yeah no github's ui is confusing
<awygle> i wasn't, no
<awygle> so i'm gonna PR this change to add the compat version of PulseSynchronizer
<awygle> there's no tests for the compat version of e.g. FFSynchronizer, is it cool i f i don't have tests for this either?
<whitequark> yeah
<whitequark> the compat interface's tests are mostly code using the compat interface
<_whitenotifier-3> [nmigen] awygle opened pull request #322: Add PulseSynchronizer to nmigen.compat.genlib.cdc - https://git.io/Jv8YJ
<awygle> sorry codecov[bot]
<_whitenotifier-3> [nmigen] whitequark closed pull request #322: Add PulseSynchronizer to nmigen.compat.genlib.cdc - https://git.io/Jv8YJ
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jv8Yk
<_whitenotifier-3> [nmigen/nmigen] awygle 5ae8791 - nmigen.compat.genlib.cdc: add PulseSynchronizer.
<awygle> is the "__all__" line at the top of the modules supposed to contain all public things (including functions) or just classes?
<_whitenotifier-3> [nmigen] Success. Absolute coverage decreased by -0.11% but relative coverage increased by +17.57% compared to 71d9eea - https://codecov.io/gh/nmigen/nmigen/commit/fcbabfeefc65b69db0c21f26262f9085164092ff
<_whitenotifier-3> [nmigen] Success. 100% of diff hit (target 82.42%) - https://codecov.io/gh/nmigen/nmigen/commit/fcbabfeefc65b69db0c21f26262f9085164092ff
<awygle> (i so very much do not understand python modules...)
<whitequark> awygle: __all__ specifies the names you get when you do a glob import (from x import *)
<awygle> ah
<_whitenotifier-3> [nmigen] Success. 82.59% (+0.17%) compared to 71d9eea - https://codecov.io/gh/nmigen/nmigen/commit/fcbabfeefc65b69db0c21f26262f9085164092ff
<_whitenotifier-3> [nmigen] Success. 100.00% of diff hit (target 82.42%) - https://codecov.io/gh/nmigen/nmigen/commit/fcbabfeefc65b69db0c21f26262f9085164092ff
<_whitenotifier-3> [nmigen] awygle opened pull request #323: Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8YZ
<awygle> last one i promise :)
<whitequark> now this one wouldn't be so fast
<awygle> not surprising
<whitequark> they should probably be deprecated and/or have an equivalent in nmigen.lib
<whitequark> and i'm not even sure what these primitives do
<awygle> hmm makes sense
<whitequark> "displacer"?
<_whitenotifier-3> [nmigen] Failure. 82.30% (+-0.30%) compared to fcbabfe - https://codecov.io/gh/nmigen/nmigen/commit/5ae87916ecbf88a169ea654d0f7198bb82c062a9
<_whitenotifier-3> [nmigen] Success. Coverage not affected when comparing fcbabfe...5ae8791 - https://codecov.io/gh/nmigen/nmigen/commit/5ae87916ecbf88a169ea654d0f7198bb82c062a9
<_whitenotifier-3> [nmigen] Success. Absolute coverage decreased by -0.3, only covered lines were removed - https://codecov.io/gh/nmigen/nmigen/commit/5ae87916ecbf88a169ea654d0f7198bb82c062a9
<_whitenotifier-3> [nmigen] Success. 82.59% (+0.00%) compared to fcbabfe - https://codecov.io/gh/nmigen/nmigen/commit/5ae87916ecbf88a169ea654d0f7198bb82c062a9
<_whitenotifier-3> [nmigen] codecov[bot] commented on pull request #323: Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8Yl
<_whitenotifier-3> [nmigen] Success. Coverage not affected when comparing 5ae8791...77cfd4a - https://codecov.io/gh/nmigen/nmigen/compare/5ae87916ecbf88a169ea654d0f7198bb82c062a9...77cfd4a9cac8057c62bca7c2445fb8d9a860836f
<_whitenotifier-3> [nmigen] Success. Absolute coverage decreased by -0.3, only covered lines were removed - https://codecov.io/gh/nmigen/nmigen/compare/5ae87916ecbf88a169ea654d0f7198bb82c062a9...77cfd4a9cac8057c62bca7c2445fb8d9a860836f
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #323: Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8Yl
<_whitenotifier-3> [nmigen] Success. 82.47% (+0.05%) compared to 71d9eea - https://codecov.io/gh/nmigen/nmigen/commit/fcbabfeefc65b69db0c21f26262f9085164092ff
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #323: Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8Yl
<_whitenotifier-3> [nmigen] Success. 82.59% remains the same compared to 5ae8791 - https://codecov.io/gh/nmigen/nmigen/compare/5ae87916ecbf88a169ea654d0f7198bb82c062a9...77cfd4a9cac8057c62bca7c2445fb8d9a860836f
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #323: Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8Yl
<_whitenotifier-3> [nmigen] Success. Absolute coverage decreased by -0.12, only covered lines were removed - https://codecov.io/gh/nmigen/nmigen/compare/5ae87916ecbf88a169ea654d0f7198bb82c062a9...77cfd4a9cac8057c62bca7c2445fb8d9a860836f
<ktemkin> that naming, though
<_whitenotifier-3> [nmigen] Success. 82.47% remains the same compared to fcbabfe - https://codecov.io/gh/nmigen/nmigen/commit/5ae87916ecbf88a169ea654d0f7198bb82c062a9
<awygle> displacer is extremely weird
<awygle> it apparently takes in a small signal, and makes it part of a larger signal, according to a shift
<awygle> so if you had a byte, and you wanted it to be byte 3 of a 32-bit word, you'd use displacer(byte, index, word)
<awygle> (all other bits become 0)
<awygle> and chooser is the opposite
<_whitenotifier-3> [nmigen] awygle synchronize pull request #323: Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8YZ
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #323: Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8Yl
<_whitenotifier-3> [nmigen] Success. 82.47% remains the same compared to 5ae8791 - https://codecov.io/gh/nmigen/nmigen/compare/5ae87916ecbf88a169ea654d0f7198bb82c062a9...77cfd4a9cac8057c62bca7c2445fb8d9a860836f
<_whitenotifier-3> [nmigen] awygle edited pull request #323: [WIP] Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8YZ
<_whitenotifier-3> [nmigen] awygle commented on pull request #323: [WIP] Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8Y5
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #323: [WIP] Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8Yl
<_whitenotifier-3> [nmigen] Success. Coverage not affected when comparing 5ae8791...5844a79 - https://codecov.io/gh/nmigen/nmigen/compare/5ae87916ecbf88a169ea654d0f7198bb82c062a9...5844a79866c787378a44dc7cdd909e92fe19b157
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #323: [WIP] Import migen's genlib.misc into nmigen.compat - https://git.io/Jv8Yl
<_whitenotifier-3> [nmigen] Success. Absolute coverage decreased by -0.3, only covered lines were removed - https://codecov.io/gh/nmigen/nmigen/compare/5ae87916ecbf88a169ea654d0f7198bb82c062a9...5844a79866c787378a44dc7cdd909e92fe19b157
daveshah has joined #nmigen
<whitequark> awygle: hm
<whitequark> so displacer is word_select on lhs, and chooser is word_select on rhs?
<whitequark> why does split exist?
<awygle> No clue
<whitequark> more of a rhetorical question yea
Asu has joined #nmigen
felix_ has joined #nmigen
<Sarayan> Hey whitequark-sempai, what's the nitty-gritty of an integrated logic analyzer?
ronyrus has joined #nmigen
proteus-guy has quit [Ping timeout: 240 seconds]
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 240 seconds]
levi has quit [Ping timeout: 272 seconds]
levi has joined #nmigen
proteus-guy has joined #nmigen
ronyrus has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
EmilJ has joined #nmigen
ronyrus has joined #nmigen
<EmilJ> Hey, do I understand it correctly that nmigen is so new that I can't see what features it provides over migen without first learning migen and then reading the source code of nmigen?
<EmilJ> I'm just looking for a good HDL to sink my teeth into to become the Ultimate Arch Mage of Synthesis, without my purity being challenged with high paying jobs due to me learning archaic things people in The Industry are already using
<ZirconiumX> EmilJ: nMigen is generally much better designed
<ZirconiumX> It simulates faster too
<ZirconiumX> And with nmigen.compat you can run old Migen code by just patching the imports
<EmilJ> sweet
<EmilJ> do you think it's a good tool to put together a RISC-V core for learning purposes?
<ZirconiumX> We already have: it's called Minerva
<ZirconiumX> So yes, it's entirely possible to do
MadHacker has joined #nmigen
NHT has joined #nmigen
NHT has quit [Remote host closed the connection]
<awygle> whitequark: i mean it's a knowable answer. afaict this is the only use of split in a publicly accessible codebase: https://github.com/m-labs/misoc/blob/master/misoc/interconnect/wishbone.py#L485
<awygle> Sarayan: did you have a specific aim? i'm currently hacking litescope to bulid under nmigen (through Extreme Violence to both litescope and litex codebases....) and i also started trying to wrap sump2, but currently there are no ILAs targeting nmigen
<MadHacker>
EmilJ has quit [Read error: Connection reset by peer]
<Sarayan> awygle: making debugging the stuff I write in nmigen easier is my aim
<awygle> I share this goal for sure
<awygle> Integrating with the language the way that e.g. Clarity works in diamond is more complex
<awygle> wq and I discussed this a while back
<awygle> But either porting an existing core or writing a new one for nmigen should be easier
<awygle> the litescope test suite has been pegging a core of this machine for like.... 30m or more. i wonder if i broke it or if it really takes this long...
<awygle> it's definitely not supposed to take that long, without modification it takes 14 seconds
<whitequark> yeah it's definitely looping
<whitequark> possibly a race condition somewhere
<whitequark> i think pysim2 exposes a few of those
<awygle> current plan is to actually _port_ some of this stuff away from nmigen.compat and see if that fixes it. any suggestions as to where to focus?
<whitequark> not sure, sorry
<awygle> s'ok, thanks
<_whitenotifier-3> [nmigen] whitequark opened issue #324: Integrate cxxrtl simulator - https://git.io/Jv8VZ
Asu has quit [Quit: Konversation terminated!]
gay is now known as XgF