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
<agg> whitequark: re wrapping SB_IO: I wrote that 6 months before nmigen emitted SB_IO, I expect I could probably get rid of it today
<agg> (though i am desperately looking forward to the upcoming documentation, I always get confused about how to use Pins in a platform and just have to read the source, especially for things like dir="-", invert, diff pairs, etc
<cr1901_modern> The short, slightly-exaggerated version is wq got sick of dealing w/ various toolchains not inferring I/O primitives consistently, so now nmigen generates the I/O primitives directly.
<agg> oh yes, i think it's great
<agg> i wrote that whole project before nmigen.build existed at all iirc
<agg> later dropped most of my build code to use nmigen's
<agg> but there's still some stuff like manual sb_io floating around for iirc tristate ios or something
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #nmigen
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #nmigen
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #nmigen
matt` has joined #nmigen
<matt`> hey, how can i set a negedge domain for the default_clock? i expect
<matt`> this must be obvious, but i'm somehow missing it.
<matt`> I tried
<matt`> neg = ClockDomain("sync", clk_edge="neg")m.domains.neg = neg
<matt`> neg = ClockDomain("sync",clk_edge="neg")
<matt`> m.domains.neg = neg
<matt`> and
<matt`> m.domains += ClockDomain("clk40_neg", clk_edge="neg")
<matt`> m.d.comb += ClockSignal("clk40_neg").eq(clk40.i)
<matt`> clk40 is the pin from platform.request
<matt`> i'm getting errors with each of these
_whitelogger has joined #nmigen
<whitequark> agg: ohh! that's cool then
<whitequark> feel free to wait until the docs are done, of course
<matt`> to clarify the question, i don't want the default clock to be the
<matt`> negative edge, i also want the negative edge of the same clock as a
<matt`> separate domain
<whitequark> matt`: one moment
<matt`> whitequark: sure no rush, thanks
Guest30583 has joined #nmigen
<whitequark> matt`: okay, so do you want two domains, one on posedge of the default clock, one on negedge?
<matt`> whitequark: correct
<whitequark> which errors were you getting with your code? it's pretty close to the correct approach
<matt`> with the second i'm getting: nmigen.hdl.cd.DomainError: Domain 'clk40' is used but not defined
<matt`> i never use "clk40". just "clk40_neg" and "sync"
<whitequark> that's interesting
<matt`> with the first I get: NameError: Clock domain name 'sync' must match name in `m.domains.neg += ...` syntax
<whitequark> can you post your full code somewhere?
<whitequark> or a minimal version that still errors
<matt`> sure, i'll get you a pastebin. give me a few min to get a minimal
<matt`> version since there's a lot else here
<matt`> also full disclosure i'm using a version of nmigen from feb
<matt`> if you think that could be causing issues i'll update
<whitequark> unlikely to cause issues other than having some error messages worse than they should be
<whitequark> no functional issues
<whitequark> around clock domains at least
<matt`> ok nvm i made a mistake. I did have "clk40" hidden in there which explains
<matt`> which i fixed by accessing the clock signal wth ClockSignal("sync")
<matt`> the error. once i fixed that i got a resource already requested error,
<matt`> sorry for the false alarm
<whitequark> cool! it might be a good idea to add a diagnostic pointing to the place where an undefined domain is used
<whitequark> feel free to open an issue for that if you want
<matt`> yeah that would be very useful. i'll open an issue for it. thanks!
<_whitenotifier-c> [nmigen] matthuszagh opened issue #389: Better diagnostics for undefined domain usage - https://git.io/Jf24g
<matt`> ^^ issue posted
<_whitenotifier-c> [nmigen] whitequark commented on issue #389: Better diagnostics for undefined domain usage - https://git.io/Jf24a
chipmuenk has joined #nmigen
matt` has left #nmigen ["Killed buffer"]
Asu has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 265 seconds]
* zignig has managed to get a working echo console for a boneless-v3 on a tinybx.
* zignig happy dance , unce unce unce.
_whitelogger has joined #nmigen
<zignig> what is the best way to connect a CSR interface to another clock daomein?
<zignig> *domain
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jf2rQ
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark 4897de3 - [skip ci] Fix incorrect comment.
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jf2r7
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark b91f0d5 - [skip ci] Fix incorrect comment.
<_whitenotifier-c> [nmigen] whitequark edited a comment on issue #371: Make Yosys a soft dependency of nMigen itself - https://git.io/Jfqak
<_whitenotifier-c> [nmigen/nmigen] whitequark pushed 1 commit to master [+1/-0/±2] https://git.io/Jf2yg
<_whitenotifier-c> [nmigen/nmigen] whitequark b9799b4 - back.verilog: fall back to nmigen_yosys package.
<_whitenotifier-c> [nmigen] whitequark closed issue #371: Make Yosys a soft dependency of nMigen itself - https://git.io/JfqRI
<awygle> awesome work wq
<whitequark> thanks :)
<whitequark> hopefully this makes nmigen a bit easier to use
<kbeckmann> nice! this will probably help a lot when doing workshops with people who haven't prepared their laptops etc :)
<whitequark> yep! that's the idea
<whitequark> let me know how it works
<cr1901_modern> Wait for wasmtime 0.17.0 for Windoze users for now? When I attempt to run wasmtime-py from HEAD, I get "AttributeError: function 'wasmtime_funcref_table_new' not found"
<whitequark> cr1901_modern: yep unfortunately it's out of my hands
<cr1901_modern> welp, I of course have a native yosys. Just wanted to check if it worked :D
<awygle> oh yeah i owe you a python version
<awygle> unless you no longer need that
<whitequark> awygle: i forget, what was the issue?
<awygle> the meta-thingy
<awygle> sec
<awygle> ModuleNotFoundError re: importlib_metadata
chipmuenk has quit [Quit: chipmuenk]
<whitequark> oh
<whitequark> yeah so i think either i broke caching on pypi unintentionally
<whitequark> or found a bug in pip
<whitequark> but i had a version 0.0 published and somehow it caused pypi to think that the latest version i uploaded doesn't exist
<whitequark> even though it was clearly there on the website
<whitequark> i deleted it and it stopped doing that
<whitequark> utterly incomprehensible
<awygle> lol wow
<awygle> Python: A Good Language
<whitequark> i think it's a fairly benign bug all things considered
<whitequark> like, this went much better than i thought it would
<whitequark> by python 3.8 the out of the box packaging would actually be usable
<whitequark> (no need for polyfills etc, other improvements too)
* whitequark sighs and stares at the next yak
<whitequark> so now i'm going to rewrite the entire yosys build system to handle pass dependencies.
<_whitenotifier-c> [nmigen] whitequark commented on issue #285: Add EnableSignal, useful for making Instances compatible with EnableInserter - https://git.io/Jf2Hj
<awygle> oh goodie
<awygle> thank you for your service lol
<cr1901_modern> This should be interesting... Claire hard-rejected the last attempt to rewrite the build system
<cr1901_modern> But I guess if you keep it Makefiles only you'll be okay
<whitequark> i have this idea of having a single source of truth in Makefile.inc files and then parsing it in CMake
Asuu has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
<whitequark> it's been done before actually
<whitequark> but pssst that's a secret
<cr1901_modern> Ahhh okay
* cr1901_modern zips his lips
<cr1901_modern> The pertinent PR was in meson
<daveshah> Pretty sure there was a CMake attempt rejected in the past too
<whitequark> yep, i already asked and got a no
<whitequark> doesn't mean i'm going to be satisfied with that
<daveshah> It sounds like a decent approach tbh
<whitequark> either we'll have it rewritten in something better, or i'm going to torture the makefiles until they are as good as cmake
<whitequark> or some middle ground
<whitequark> because i look at the current yosys Makefile and it fills me with rage.
<daveshah> CMake would get proper Visual Studio support too
<whitequark> yes.
<cr1901_modern> And it would have parity w/ nextpnr
<hell__> > torturing Makefiles
<hell__> O_o
chipmuenk has joined #nmigen
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+2/-2/±3] https://git.io/Jf273
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark 374fca1 - Rename a few things to prepare for splitting off yosys-pypi.
Guest30583 has quit [Quit: Nettalk6 - www.ntalk.de]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
Asuu has quit [Quit: Konversation terminated!]