<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
<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 https://m-labs.hk/migen/manual does but nmigen has "differences".
<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>
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>
(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?
<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 yowasp.org 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/yowasp.github.io] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJf2z
<_whitenotifier-f>
[YoWASP/yowasp.github.io] whitequark 17a981e - Updated to mention alternative packages.
<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> 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 - www.ntalk.de]
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
<lkcl_>
so if you are simply doing a "git pull", that's not going to work
<lkcl_>
you'll need to re-run the setup.py 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 setup.py 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] https://git.io/JJJZ1
<_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] https://git.io/JJJZM
<_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] https://git.io/JJJZ9
<_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] https://git.io/JJJZH
<_whitenotifier-f>
[nmigen] whitequark commented on issue #407: AttributeError: module 'importlib.resources' has no attribute 'files' - https://git.io/JJJnJ
<_whitenotifier-f>
[nmigen] whitequark closed issue #407: AttributeError: module 'importlib.resources' has no attribute 'files' - https://git.io/Jfb0J
<whitequark>
yes, that's the proper way to do it these days
<lkcl_>
i use "python3 setup.py 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 setup.py 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_>
using those two yosys commands to convert from dff.v to dff.il
<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/dff.il" 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>
bugs.python.org 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