ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each 1st & 3rd Monday at 1800 UTC · next meeting July 6th
<cr1901_modern> awygle: xpra... it's like screen for X
<awygle> hm ok
<awygle> thanks
<cr1901_modern> if you're looking for an actual X-server, then Xming might still be developed
<awygle> i'll check out both
<awygle> i used to use xming ages ago
<awygle> before cygwin had a useful x server
<d1b2> <Darius> Xming still runs
Falteckz has joined #nmigen
hellsenberg has quit [Remote host closed the connection]
<Falteckz> To understand the nmigen API I should learn migen and then keep in mind the changes?
<Falteckz> I don't see any formal documentation for nmigen, is why I ask.
<cr1901_modern> nmigen has a compat layer w/ migen. But... my opinion is: enough has changed between the two that I can see someone who has just started learning nmigen would be confused coming from migen
<cr1901_modern> others can feel free to disagree :P
<Falteckz> As someone that has never touched either migen or nmigen, and who has only observed the nmigen/examples. Where should I start?
<cr1901_modern> what board do you have?
<Falteckz> TinyFPGA BX / iCE40LP
<Falteckz> I've fusesoc setup currently, and am building Verilog with Yosys+Nextpnr
<cr1901_modern> I've little experience using fusesoc w/ nmigen. I would start here and adjust the examples accordingly for tinyfpga:
<agg> (i agree with cr1901_modern, start with nmigen)
<Falteckz> While these examples at least show me how to target my platform - they still do not fully cover the FHDL/API. Obviously does but nmigen has "differences".
<Falteckz> I don't mind if the answer is "Sorry, no docs, read the source", just as long as I know where my search for docs ends :)
<agg> it's work in progress and quite new
<Falteckz> Oh my! Thanks
<Falteckz> Words on a page, it's a good start.
<agg> (you won't have found a link to it anywhere; it comes from the doc branch on )
<Falteckz> Got it, I'll watch that branch for changes
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
<Falteckz> Seems there is not yet much documentation on clock domains, it's my assumption that `m.sync` is a default clock domain, where the clock source is decided by some platform specific defaults. When someone specifies a new domain on `m.domain[]` how is that domain clocked? Further, can domains be clocked on the negative edge, or both positive and negative, and lastly: Does nmigen support DDR latches?
<agg> do you want DDR IO, or actually latches inside your logic?
<agg> sync is a default clock domain, created if you don't create it yourself (e.g. i often use a pll to create a higher-rate sync domain)
<Falteckz> The intent would be DDR IO, perhaps a shift register that is RX or TX on both edges.
<agg> when you create a ClockDomain object it has a clk attribute which you can assign a signal too, e.g. m.d.comb += new_cd.clk.eq(pll.clkout)
<agg> you probably want to use the platform IO to perform DDR, not write that into your own logic
<agg> nmigen supports that; platform.request("pin", xdr=2) returns an object with .i0 and .i1 or .o0 and .o1 for the two phases, plus .i_clk or .o_clk for the clock to use
<Falteckz> Ah. Sure. I'm not familiar with the iCE40's platform constructs. I've only touched the global network, tristate IO, and the PLL.
<agg> (xdr=1 works for registers in the io cell, also has a clock)
<agg> ice40 io (SB_IO) has ddr in the io cell, you really definitely want to be using that
<agg> clock domains can run on negative: invert the clock you feed it, e.g. m.d.comb += new_cd.clk.eq(~pll.clkout)
<agg> but don't do that to try and do DDR
<Falteckz> Right, so leave the DDR to the silicon already on the chip, and don't implement it in fabric
<agg> yea. you can't implement it reliably in fabric.
<agg> (you can write verilog that describes fabric doing ddr, but that doesn't mean it will turn into a reliable ddr circuit)
<Falteckz> So I might do `ddr_io = platform.request("pin", xdr=2) \n ddr_io.i_clk.eq(m.sync.clk)`
<Falteckz> Further, can I `m.sync.clk.eq(pll.clkout)` to apply the PLL across the entire design?
<agg> cd_sync = ClockDomain("sync", reset_less=True); m.d.comb += cd_sync.clk.eq(pll.plloutglobala); += cd_sync; platform.add_clock_constraint(cd_sync.clk, 100e6)
<agg> that creates a sync clock domain, runs it off "pll.plloutglobala", adds it to domains list (therefore preventing the default sync getting created instead), and adds a timing constraint of 100MHz
<agg> for ddr the exact syntax depends on what resources are in your platform
jaseg has quit [Ping timeout: 272 seconds]
<Falteckz> I have found the Generic DDR IO on the iCE40LP now (DS1040) and it's as you describe, i0/i1;o0/o1;i_clk/o_clk.
<agg> something like port = platform.request("port", xdr={"txdat": 2, "rxdat": 2}); m.d.comb += [port.rxdat.i_clk.eq(port.rxclk), port.txclk.o_clk.eq(cd_sync.clk), port.txdat.o0.eq(data0), port.txdat.o1.eq(data1), data0.eq(port.rxdat.i0), data1.eq(port.rxdat.i1)]
jaseg has joined #nmigen
<agg> by "in your platform" I mean your Platform class
<agg> which defines what Resources are available, what pins they're on, what direction, that sort of thing
<agg> this comes either from nmigen-boards or you write a custom one for your hardware
<Falteckz> Interesting, I've not much looked at the Resources part yet. I assumed I still had a text file for pin io assignment
<agg> not so
<Falteckz> Great!
<agg> (when the platform defines connectors, as there, you can attach resources to them in your logic without changing the platform itself)
<Falteckz> One resource per connection?
<Falteckz> i.e. for the LED, I should use the LED resource rather than trying to connect directly to `B3`
<agg> yea, for the LED you just platform.request("led") and it will return an object that has a .o attribute you can assing
<agg> m.d.comb += platform.request("led").o.eq(1)
<Falteckz> It isn't obvious to me where o comes from, is that a default subsignal when one is not specified?
<Falteckz> or is it a Signal(width) for the entire resource?
<whitequark> latter
<agg> you might be getting confused by 'subsignals'
<whitequark> each pin has an i (if it's an input or inout), o (if it's an output or inout), and oe (if it's an inout) attributes
<Falteckz> Hypothetically my board has a 7Seg, I would have `platform.request('7seg').e == Signal(1)` but I would also have `platform.request('7seg').o == Signal(7)`?
<whitequark> .e as in "output enable"?
<Falteckz> Perhaps I am getting confused with subsignals, it was my assumption that there is an implicit subsignal defined
<agg> `oe`, though if it's just a dir="o" and not a dir="io" or dir="oe" you won't get oe at all
<whitequark> yeah
<Falteckz> whitequark: as the e-th segment (a,b,c,d,e,f,g)
<agg> whitequark: is there an example of adding a resource using a connector? i can never remember how to do it...
<whitequark> agg: Pins(..., conn=("foo", 0))
<agg> whitequark: maybe with like one or two more lines of context?
<Falteckz> I'm looking at this here: trying to understand the API and how to construct my own resources
<whitequark> Falteckz: oh, I understand your question better
<Falteckz> I see there is signals and pins, but both are `ios`
<Falteckz> s/signals/subsignals
<whitequark> so there are two kinds of resources: with subsignals and without subsignals
<whitequark> resources without subsignals have .o/.i/.oe directly, resources with subsignals do not, it is the subsignals which have .o/.i/.oe
<Falteckz> Another example might be the RGB resource, would there also be an `rgb.o == Signal(3)`, and how would I assign `r` subsignal? I'd assume it would be `rgb.r`
<whitequark> there wouldn't be an rgb.o
<whitequark> just rgb.r.o
<Falteckz> Got it.
<whitequark> now that you mention it, "Subsignals" is a pretty bad name for this concept
<whitequark> maybe we should just rename it
<Falteckz> Is a Subsignal always only one pin?
<whitequark> nope, can be as many pins as you want
<whitequark> same as a resource
<d1b2> <edbordin> hey whitequark, I'm happy to chat about the yosys thing here if you think it will be quicker
guan has quit [Read error: Connection reset by peer]
<whitequark> I just replied in a comment
bubble_buster has quit [Ping timeout: 240 seconds]
<whitequark> the gist of it is: nMigen internally assumes that whatever yosys is installed has the same number after + as the upstream Yosys
mithro has quit [Ping timeout: 272 seconds]
levi has quit [Read error: Connection reset by peer]
<whitequark> I would actually prefer it to be bumped more regularly than it is now in YosysHQ/yosys repo, but so long as that isn't happening, it really should be the same
<d1b2> <edbordin> hmm, I must have misread the code that parses the version
<whitequark> I think you read the code right
mithro has joined #nmigen
<whitequark> this is an unstated assumption, and it is a result of how I would actually define a conditional based on version
<whitequark> which is that I would look at the range of commits spanned by a certain +-version and see which workarounds need to be applied
<whitequark> if the version in open-tool-forge does not match the upstream, then that would be wrong, and the code will break in subtle ways in some edge cases
bubble_buster has joined #nmigen
<d1b2> <edbordin> yeah I did misread it, I thought it ignored the number after + but it definitely doesn't
<whitequark> ahh okay
<whitequark> yeah, the Yosys release schedule is very slow, so I have to parse and act on that
guan has joined #nmigen
<d1b2> <edbordin> OK, I'll just stop doing bumpversion then. I'll keep adding the extra string afterwards so that it's easier to detect when people are using these nightlies just in case the way they're being built causes unique issues
<whitequark> you can change the version string before or after the \d.\d\+\d part
<whitequark> just keep the numeric part somewhere in the middle
<whitequark> ah wait I actually require the regexp to be exact
<whitequark> at the beginning
<whitequark> let's relax it?
<whitequark> something like "OpenToolForge Yosys 0.9+123" looks good to you? then I can get rid of the ^ in regex
<d1b2> <edbordin> I'm not too fussed where it goes
levi has joined #nmigen
<d1b2> <edbordin> also fomu-toolchain was already inserting it afterwards
<whitequark> okay, let me know if you'd like me to change the regex as I can totally do that
<whitequark> ok
<whitequark> that's also fine by me
<d1b2> <edbordin> I need to take another look at where the git commit in the version string comes from, because by the time I'm building it, the .git dir has been stripped away
<whitequark> edbordin: by the way, what do you think about cross-linking yowasp and open-tool-forge toolchains?
<whitequark> they solve somewhat different problems
<d1b2> <edbordin> definitely happy to work something out there
<d1b2> <edbordin> what did you have in mind?
<whitequark> I'd add a section to that links to packages using other approaches (opentoolforge, someday PRU, others?) and you'd do the same in the open-tool-forge README
<d1b2> <edbordin> oh sure, that would be no problem at all
<whitequark> lemme do it now then
<d1b2> <edbordin> I might as well plug nmigen too, although tbh most people using these tools are probably aware already
<_whitenotifier-f> [YoWASP/] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [YoWASP/] whitequark 17a981e - Updated to mention alternative packages.
<whitequark> done
<whitequark> cool, thank you! :)
<d1b2> <edbordin> likewise!
<d1b2> <edbordin> I'm pretty impressed that nextpnr runs at about the same speed in wasm
<whitequark> oh, it runs slower
<whitequark> there's a trick
<whitequark> the trick is called "x32 ABI"
<whitequark> smaller pointers -> less cache pressure -> faster nextpnr
<whitequark> but you have to use 64-bit ISA with 32-bit pointers for this to work
<whitequark> it just happens to work out that way with wasm
<whitequark> so the increase in speed due to 32-bit ABI balances off the decrease in speed due to wasm
<whitequark> other applications (like lua) actually benefit so much from smaller pointers that they run *faster* in wasm than native
<whitequark> like 20% faster, pretty significant difference
<d1b2> <edbordin> well TIL
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
<d1b2> <edbordin> yeah sounds like getting that ABI working natively is a massive PITA, that's pretty cool
<whitequark> yep
<whitequark> oh it got deprecated in linux actually
<d1b2> <edbordin> yeah I can imagine adoption was minimal due to the need to rebuild the whole system
<Falteckz> TIL WebAssembly has nothing to do with Web Browsers 😅
<whitequark> it happens to be sandboxed well enough for browsers, but yea, that's about it
<Falteckz> Just another VM, but _fast_
<Falteckz> It takes me about 2 hours to build my Docker container to run my Yosys+NextPNR toolchain in Windows without all the MSYS2 stuff. Going to try YoWASP later, installed natively.
<d1b2> <edbordin> <plug>open-tool-forge has windows binaries that are statically linked</plug> 😛
<d1b2> <edbordin> for yosys+nextpnr yowasp sounds like less effort to use though
<Falteckz> That's hot! Though, with respect, I don't yet know what OTF is
<d1b2> <edbordin> well, it's now conveniently linked on the yowasp site 😛
<d1b2> <edbordin> although I am just working out the kinks getting it to play nice with nmigen
proteus-guy has quit [Ping timeout: 240 seconds]
<Falteckz> I'm all about that compatibility; looking forward to a free moment this week to touch nMigen for the first time. Building out my homebrew CPU in Verilog is _pain_
<Falteckz> Now I just need a `pip install` for RISC-V -IMC toolchain
* whitequark hides
<Falteckz> I wonder if anyone has shown prestige in this sort of convienent packaging before, and perhaps could be persueded to take on this project too. Hmm... nope, I see no one unfortunately ;-)
<whitequark> phew that worked
<whitequark> i think the main problem is the 60 MB limit on pypi
<d1b2> <edbordin> conda is full of packages like that. it just also tries to do a hostile takeover of your PATH sometimes
<whitequark> this is a public channel so i'm not going to sincerely say what i think about conda
<d1b2> <edbordin> hehehe I think I saw some of those thoughts on twitter
<whitequark> let's leave it as "i've worked with it extensively and i look forward to never doing that again in my life"
<whitequark> in fact yowasp was partly conceived as a response to some people packaging FPGA toolchains for conda
<whitequark> pip can do that too! and it can be much less bad!
<d1b2> <edbordin> pip's dependency resolution leaves much to be desired. but I think that's mostly because setuptools allowed packages to do all sorts of weird stuff that makes static dependency analysis really hard
<whitequark> you know, i *did* use conda's dependency resolution
<whitequark> after they rewrote the solver, too.
<whitequark> i do not find this argument convincing
<d1b2> <edbordin> I think usually these conversations end in "it's all terrible in different ways but some more than others"
<whitequark> yep
<Falteckz> I used Conda once when working with ROS... I also have some very passionate words about how I feel after that experience. Further, I'm not sure it's entirely removed from my system.
<d1b2> <edbordin> I ended up using it for now in my builds just for libpython.a, but I'll eventually build python from source to reduce the amount of cruft
<d1b2> <edbordin> (so long as you don't run the activate script it can't take over)
<d1b2> <edbordin> (well... so long as you also don't run the installer)
<Falteckz> I'm thinking of a zsh plugin that reads `.dragons` file and prevents certain operations. Could be helpful here :P
<d1b2> <Hardkrash> .dragons is that an existing thing?
<d1b2> <edbordin> whitequark I'm just gonna roll with this version string for now "Yosys 0.9+2406 (open-tool-forge build) (git sha1 f7fdd99e, x86_64-w64-mingw32-g++ 10.1.0 -Os)"
<d1b2> <edbordin> eventually I should probably be less lazy and PR a new variable in the makefile for that kind of "vendor string" rather than inserting it with sed
<Falteckz> Hardkrash: No.
hitomi2503 has joined #nmigen
proteus-guy has joined #nmigen
jeanthom has joined #nmigen
Asu has joined #nmigen
<d1b2> <edbordin> hmm, looks like nmigen doesn't like it on windows when the tools are at a path containing spaces. but it wouldn't be the first tool to have issues with that
chipmuenk has joined #nmigen
<d1b2> <Darius> hah
<d1b2> <Darius> maybe it doesn't like it on linux either but no one found out 😉
emily has quit [Quit: killed]
nurelin has quit [Quit: killed]
jfng has quit [Quit: killed]
nurelin has joined #nmigen
jfng has joined #nmigen
emily has joined #nmigen
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
<zignig> why are USB descriptors so weird ?
<hell__> usb is cursed
<agg> hid reports are somehow worse
<zignig> 500mA and diff clock data it should not be that hard.
<zignig> carrier tone, modem neg. _LINK_
nengel has joined #nmigen
nengel has quit [Ping timeout: 260 seconds]
nengel has joined #nmigen
nengel has quit [Ping timeout: 260 seconds]
<whitequark> edbordin: that version string looks ok
<whitequark> edbordin: regarding spaces: that's a bug, let's fix it
nengel has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
nengel has quit [Ping timeout: 264 seconds]
jeanthom has joined #nmigen
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
lkcl_ has quit [Ping timeout: 258 seconds]
lkcl_ has joined #nmigen
hitomi2503 has quit [Quit: Nettalk6 -]
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
SpaceCoaster_ has joined #nmigen
SpaceCoaster has quit [Ping timeout: 265 seconds]
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #nmigen
PyroPeter has joined #nmigen
<FL4SHK> so my `Cover`s aren't getting met
<FL4SHK> with m.If(loc.formal.past_rst): m.d.comb += Cover(loc.formal.past_rst)
<FL4SHK> This fails for some reason?
<whitequark> interesting
<mithro> whitequark: Would boneless make a good 130nm tape out target? :-P
<mithro> whitequark: On the list of other terrible ideas -- I would like to make an FX2 like IC :-P
<whitequark> mithro: 130nm boneless: yep, sure
<whitequark> fx2: i will not work on a full fx2 but i might consider a microcoded 8051
<mithro> @whitequark - I don't think it makes any sense to do an 8051? I was thinking an RISC-V with a similar style "USB accelerator"
<whitequark> ah ok, i'm not interested in that at all then
<whitequark> the last thing i want is more USB stuff in my life
<daveshah> The USB 2.0 PHY would be quite tricky
<_whitenotifier-f> [nmigen] whitequark deleted branch gh-pages -
<_whitenotifier-f> [nmigen/nmigen] whitequark deleted branch gh-pages
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to doc [+16/-2/±6]
<_whitenotifier-f> [nmigen/nmigen] whitequark dd735db - [WIP] doc
<d1b2> <tnt> @whitequark I was thinking a multi-bit level converter IO buffer with per-bit direction control and built in pull up/pull down :p
<whitequark> tnt: ha, that's a good one!
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±0]
<_whitenotifier-f> [nmigen/nmigen] whitequark ae5b4f7 - Initial gh-pages commit
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+106/-0/±0]
<_whitenotifier-f> [nmigen/nmigen] whitequark 60289a4 - Deploying to gh-pages from @ dd735dbff77e4e42d9f27e3891a9b429796ec733 🚀
<FL4SHK> I'm going to have to implement USB or something
<FL4SHK> I bought these two USB host things
Asu has quit [Remote host closed the connection]
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to doc [+16/-2/±6]
<_whitenotifier-f> [nmigen/nmigen] whitequark d6ff902 - [WIP] doc
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±9]
<_whitenotifier-f> [nmigen/nmigen] whitequark 33ebe8f - Deploying to gh-pages from @ d6ff902caaee45c35fbb04db75eb315917e91630 🚀
ktemkin has quit [Read error: Connection reset by peer]
ktemkin has joined #nmigen
daveshah has quit [Read error: Connection reset by peer]
daveshah has joined #nmigen
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to gh-pages [+1/-0/±0]
<_whitenotifier-f> [nmigen/nmigen] whitequark 97f321b - Add .nojekyll
chipmuenk has quit [Quit: chipmuenk]
SpaceCoaster_ has quit [Ping timeout: 260 seconds]
<awygle> whitequark: so i'm getting `ImportError: cannot import name 'resources'` when trying to run nmigen, but only, like... sometimes
<whitequark> hrm
<awygle> specifically when importing
<awygle> it works on my user account but not on another one on this server
<awygle> so it's probably Python Fuckery
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [nmigen/nmigen] whitequark 8dacbbb - Don't use pkg_resources.
<whitequark> awygle: which python version?
<awygle> 3.6.9
<whitequark> (the commit above is related in that you inspired it, but it would either not change your situation or make it worse)
<whitequark> can you post the complete trace?
<whitequark> oh, right
<whitequark> ugh let me actually just merge the docs and add to the relevant section
<awygle> sorry
<awygle> lol
<whitequark> you're like the third person with this exact problem in the last few days
<whitequark> so this is clearly not your fault
SpaceCoaster has joined #nmigen
<awygle> english limitation - i am sorry this is happening and frustrating you, i am not accepting blame for it
<awygle> we need two words for "sorry" but don't have them, it's very annoying
<whitequark> oh, it's not actually frustrating me
<whitequark> i'm just like "time to merge the docs at last!"
<whitequark> the "ugh" was referring to the python package management, which i already know is not very good, nothing new here
<whitequark> or frustrating
<awygle> fair nough
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to doc [+16/-2/±5]
<_whitenotifier-f> [nmigen/nmigen] whitequark 0d7298f - Add (heavily work in progress) documentation.
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to doc [+16/-2/±5]
<_whitenotifier-f> [nmigen/nmigen] whitequark 399b8f9 - Add (heavily work in progress) documentation.
<lkcl_> awygle, are you encountering "ModuleNotFoundError: No module named 'importlib_resources'"?
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±11]
<awygle> yep
<_whitenotifier-f> [nmigen/nmigen] whitequark 32ee381 - Deploying to gh-pages from @ 399b8f986391d0bf90126814162a6eca0dae910a 🚀
<lkcl_> if so, the python library named "importlib_resources" was added recently as a dependency
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+16/-2/±5]
<_whitenotifier-f> [nmigen/nmigen] whitequark 399b8f9 - Add (heavily work in progress) documentation.
<_whitenotifier-f> [nmigen] whitequark deleted branch doc -
<_whitenotifier-f> [nmigen/nmigen] whitequark deleted branch doc
<lkcl_> so if you are simply doing a "git pull", that's not going to work
<lkcl_> you'll need to re-run the script...
<lkcl_> or simply find and install importlib_resources manually. pip3 install importlib_resources would be one way to achieve that
<awygle> i did re-run the script but it only worked for me, not for other users, which i assume is a pip issue since running it with --system didn't fix the problem
<lkcl_> awygle: it depends on what _they_ have installed. if they're running e.g. virtualenv then they'll be completely isolated even from system-level packages, because that's what virtualenv does
<awygle> good point
<awygle> idk if they are or not
<lkcl_> or if they happen to be using a different version of python (3.6, 3.7, 3.9)
<lkcl_> then installing system-wide for *only* one of those isn't going to work, either :)
<awygle> i did check python versions
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [nmigen/nmigen] whitequark 9928b60 - docs: explain that `pip3 install -e` should be run after pulling.
<awygle> anyway we solved it with Violence
<lkcl_> :)
<awygle> (they just downloaded nmigen and installed it locally)
<lkcl_> there's a 2000 AD comic about that. totally mindlessly violent violence :)
<whitequark> awygle: wait, what did they do before downloading and installing nmigen locally?
<awygle> i had it installed system-wide
<whitequark> oh I see
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [nmigen/nmigen] whitequark d5c297a - docs: fix CI workflow.
<awygle> but i was unable to re-run the install system wide and idk why
<lkcl_> awygle: that'd do the trick.
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±14]
<_whitenotifier-f> [nmigen/nmigen] whitequark bdafed1 - Deploying to gh-pages from @ d5c297aa94d2a23163ad03280134547610e2076a 🚀
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [nmigen/nmigen] whitequark 5048c5e - docs: fix syntax.
<lkcl_> awygle: did you happen to do an upgrade to the version of python since it was last installed? like... you're using 3.8 or something?
<lkcl_> and you first installed it on 3.6 or 3.7?
<awygle> i think i tried to go to 3.7, and had a bunch of issues, and downgraded
<awygle> so that may be related
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13]
<_whitenotifier-f> [nmigen/nmigen] whitequark adaa842 - Deploying to gh-pages from @ 5048c5efc74ed4f65f8e82518e25ca4d72974486 🚀
<lkcl_> because if so, you need to do "python3.6 install"
<lkcl_> then "python3.7 install"
<lkcl_> and finally "python3.8 install"
<whitequark> one of these days i'll make a change that works the first time. but not today
<lkcl_> whitequark :)
<lkcl_> we're investigating distributed project development - fossil seems to be the most sane and complete.
<whitequark> anyway, now mentions the way to update things
<lkcl_> whitequark: interesting (pip3 install --editable .)
<_whitenotifier-f> [nmigen] whitequark commented on issue #407: AttributeError: module 'importlib.resources' has no attribute 'files' -
<_whitenotifier-f> [nmigen] whitequark closed issue #407: AttributeError: module 'importlib.resources' has no attribute 'files' -
<whitequark> yes, that's the proper way to do it these days
<lkcl_> i use "python3 develop" - it achieves the same effect
<awygle> i have wanted to try out pijul
<lkcl_> i didn't realise pip3 could be used to install from the local filesystem (including the cwd)
<awygle> but there's no way it's enough better than git to justify the friction with the outside world
<whitequark> lkcl_: according to python packaging folks, running is deprecated ~o~
<whitequark> ok that was supposed to be a shrug
<whitequark> anyway
<whitequark> i'm just following what upstream python wants us to do in this case
<whitequark> since there's no reason not to
<lkcl_> whitequark: oh fer goodness sake. that'll take at least 15 years to deprecate!
<whitequark> i don't personally care one way or another, i'm just teachine people what python packaging folks say is the right way to do it
<whitequark> *teaching
<lkcl_> yehyeh, it's easier that way
<whitequark> python packaging improved considerably in the last few years, so i presume they are doing something right, and i'd better let them do that thing, whatever it is
<lkcl_> whitequark: no wheel-inventing needed
<whitequark> technically we are distributing `wheels`
<lkcl_> awygle: pyjul looks good... except fossil includes a bugtracker, forum, wiki and more - all done as distributed blockchain mergeable "things"
<lkcl_> haha
<lkcl_> am starting to investigate how to run the versa-ecp5 board i have here
<lkcl_> we've got wishbone interfaces to the libre-soc core now for I and D
<lkcl_> so it's time to start looking at how to get it onto the versa-ecp5
<lkcl_> HeavyX seems to have something worthwhile pursuing
<lkcl_> i love that that's entirely in nmigen!
<lkcl_> oooo i got blinky liiiights!
<lkcl_> nmigen-boards worked first tiiime, cooool :)
<whitequark> hey, anyone wants to help the project & understands web stuff?
<whitequark> it's really hard to read because it's too long and only going to get longer
<whitequark> i want to have the same thing in nmigen sphinx docs
<whitequark> maybe mithro knows?
<lkcl_> oh, you want the tabbed pages thing?
<whitequark> yeah
<mithro> whitequark: The person you want to talk to is mgielda! He does the Zephyr, Renode and many other sphinx docs
<mithro> whitequark: Let me see if I can find you the extension we have used
<lkcl_> the "class" in the html appears to be platform-switcher
<mithro> I assume you want all the tabs to change (IE if you select windows on the first tab group, all the tab groups below change)
<whitequark> mithro: yep
<whitequark> i'm really worried about information overload on that page
<whitequark> it's already kind of hard to follow
<whitequark> and the problems with python package management are not making it easier
<lkcl_> tabs make a lot of sense
<lkcl_> ha, you wouldn't believe what i did for pyjamas-desktop.
<lkcl_> overrode __import__, analysed the file being imported, looked for a "platform" variant {filename}.{platform}.py, then *merged the ASTs* :)
<lkcl_> so you could do either entire class over-rides or just per-function or class instance platform overrides
<lkcl_> without insane "if platform == blah elif platform == blahblah" switches all over the place
<miek> looks like Renode is using the extension i linked above
<whitequark> mithro: miek: thanks! this works for me I think
<mithro> 'sphinx_tabs.tabs',
<mithro> You might also find my `sphinxcontrib_session` extension which works better with interactive prompt type things useful too
<lkcl_> mithro: ooo, model diagrams from verilog code, ooo
<lkcl_> mithro: that stuff looks well cool.
<mithro> @lkcl_ -- Want to look at getting the sphinxcontrib-verilog-diagrams going for nmigen? :-P --
<lkcl_> mithro: if it's using yosys and it's really that simple then hypothetically yes
<mithro> lkcl_: everything is super easy hypothetically :-P
<lkcl_> funny :)
<mithro> lkcl_: But I can't see why it would be hard - but you know theory and practice?
<lkcl_> *snort* yes.
<lkcl_> where's a simple example?
<lkcl_> i've got it installed (i mean a verilog example)
<lkcl_> still looking
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [nmigen/nmigen] whitequark 39c3bac - setup: link to proper location for docs.
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±11]
<_whitenotifier-f> [nmigen/nmigen] whitequark b039d55 - Deploying to gh-pages from @ 39c3bacb7957b386aaea89df595638fe1fd452e1 🚀
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to gh-pages [+1/-0/±0]
<_whitenotifier-f> [nmigen/nmigen] whitequark 6558af7 - Add a redirect to /latest/
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to gh-pages [+1/-0/±0]
<_whitenotifier-f> [nmigen/nmigen] whitequark 1a65585 - Add a redirect to /latest/
<d1b2> <edbordin> whitequark the spaces in path thing looks like it's a limitation of shutil.which(). I can open an issue for it anyway if you like
<lkcl_> mithro: err... err... it just works.
<lkcl_> .. verilog-diagram:: verilog/
<mithro> Oh? :-P
<lkcl_> the file extension is automatically recognised
<lkcl_> diagram_yosys takes the .il file extension and goes, "oh, you want ilang"
<lkcl_> try this
<lkcl_> yosys
<lkcl_> read_verilog dff.v
<lkcl_> write_ilang
<mithro> lkcl_: I think it would be nice if you gave it a nmigen file and it called Yosys?
<lkcl_> that's exactly what i did
<lkcl_> using those two yosys commands to convert from dff.v to
<whitequark> edbordin: please do, we can work around that problem
<whitequark> e.g. we can first check for existence using an exact path
<lkcl_> then put ".. verilog-diagram:: verilog/" into the .rst file instead of .v
<lkcl_> it just... worked :)
<d1b2> <edbordin> @whitequark OK, I'll gather a bit more info first
<whitequark> edbordin: in general i'm really not a fan of tools that break on spaces in paths, so of course i'd like nmigen to do better
<lkcl_> ok. late here. night all.
<d1b2> <edbordin> ...I think actually this is mostly a case of PEBKAC. I added quotes around the path with the space, which cmd.exe understands, but shutil does not. If you use the Windows 10 GUI to add to PATH it does not add quotes. I guess that's kinda still a bug, but it seems less likely someone else will hit it
<whitequark> oh I see
<whitequark> yeah that's probably an upstream bug I can't do much about
<whitequark> might be worth reporting to bpo?
<whitequark> that is
<d1b2> <edbordin> yeah, the minor disparity is because .which() implements its own search in python
<whitequark> tbh the behavior of cmd.exe is both incidental and mostly undocumented
<whitequark> it is publicly known that MS no longer changes it because they're too afraid of breaking something by accident
<d1b2> <edbordin> yeah I think doing an ad-hoc stripping of quote marks on windows isn't going to cut it. and I doubt anybody wants to change that routine to use winapi instead
<d1b2> <edbordin> ultimately the problem seems to be os.path.join doesn't handle quotes, but that makes sense because that's generally a shell thing
<d1b2> <edbordin> I think I'm satisfied that the answer is "don't do that in your PATH". particularly because apparently the DLL loader doesn't recognise it
* whitequark nods