<_whitenotifier-e>
[nmigen] adamgreig opened pull request #21: Give the top level scope a name to fix vcd file production - https://git.io/fh3h0
<_whitenotifier-e>
[nmigen] whitequark commented on pull request #21: Give the top level scope a name to fix vcd file production - https://git.io/fh3hu
<_whitenotifier-e>
[nmigen] whitequark closed pull request #21: Give the top level scope a name to fix vcd file production - https://git.io/fh3h0
<_whitenotifier-e>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fh3hz
<_whitenotifier-e>
[m-labs/nmigen] adamgreig 560bb00 - Give the top level scope a name to fix VCD hierarchy.
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
<kc5tja>
Hello folks. I'm planning on exploring the use of Migen for working on my Kestrel-3 project's main processor and TileLink-compatible interconnect. The docs that were online were great, but I found a number of the tutorials were old and the code examples no longer worked as written. After some tweaking, they worked great though.
<kc5tja>
I'm thinking, is it OK for me to "overhaul" the documentation? Maybe move one or two of the tutorials into the user's guide, modernizing the code examples to the latest migen release in the process?
<kc5tja>
key2: Thanks, already reviewed it as it's linked to from migen's website. My query was in respect to improving migen's own documentation though.
<whitequark>
kc5tja: the features that are already in nmigen are rather unlikely to change at this point
<hartytp>
kc5tja: fwiw, any improvement in (n)migen's documentation would be amazing
<whitequark>
with the exception of the things explicitly called out in the bug tracker
<whitequark>
(mostly just .get_fragment() will be renamed)
<whitequark>
the benefits of nmigen are numerous; in general, the user experience is far nicer
<whitequark>
migen also contains a number of outstanding bugs related to edge cases in memories and elsewhere
<whitequark>
that are not present in nmigen by design
<kc5tja>
hmm, OK, thanks. I'll download and play with nmigen today then.
<hartytp>
whitequark: agreed. Many of the quirks that I would have liked to have seen documented in migen are not present in nmigen
<kc5tja>
Glad I asked before I started any significant development work. :)
<hartytp>
would be great to see some docs for things like records (some examples that illustrate what problem they're designed to solve and how to use them)
<hartytp>
clockdomainrenamers etc
<adamgreig>
any docs at all in fact :p
<whitequark>
hartytp: there are examples in nmigen!
<hartytp>
yes, I saw, that's good
<hartytp>
but, an expanded user guide would also be really helpful
<kc5tja>
re: records -- it was exactly this that motivated my desire to contribute, actually. Working with TileLink would be a nightmare without them.
<hartytp>
yes. I think a few lines in the UG about records (again, particularly, something explaining what problems they are intended to solve) etc would be a great supplement to the examples
<kc5tja>
If people don't mind my asking a ton of stupid, silly, beginner-level questions, I'd be happy to spend some time providing some manner of documentation.
<whitequark>
a good start would be porting migen's user guide to nmigen
<key2>
:)
<adamgreig>
maybe something like rtfd.org or other webhook could be set up to build docs+api ref from the git repo?
<hartytp>
whitequark: are you still planning to move artiq to nmigen?
<whitequark>
hartytp: sure. that was a part of what we discussed with sb0 when talking about nmigen.
<whitequark>
key2: cr1901 is looking into replacing migen.build with edalize
<whitequark>
there are some outstanding bugs on the tracker i'll fix
<whitequark>
there is a need to port stuff like FIFOs
<whitequark>
other than that it's done i think
<key2>
k
<key2>
so the gen basically
<key2>
i mean the lib
<whitequark>
yes
<adamgreig>
would the platform stuff go in with the edalize build stuff?
<adamgreig>
like an nmigen way to define board pinouts, 'connectors' maybe, and platform specific instances for io etc
<whitequark>
I don't know yet
<adamgreig>
the build and platform stuff from migen was super duper convenient for me, especially when migen already has your dev board as a platform
<adamgreig>
still happier on balance with nmigen though
<whitequark>
nmigen will gain the build and platform stuff for sure
<kc5tja>
Oh, so platform stuff is not present in nmigen then?
<whitequark>
not at the moment
<whitequark>
it has some fairly severe design issues
<kc5tja>
(sorry, was off reading RTD on how to use RTD.)
<whitequark>
so it will need to be reworked, like everything else from migen, before appearing in nmigen
<kc5tja>
Good to know -- less documentation to port. ;)
<adamgreig>
also platform and build were quite tightly coupled in migen aiui
<whitequark>
yes
<whitequark>
in migen they were uh... organically grown
<whitequark>
more than designed
<cr1901_modern>
whitequark: It wasn't my plan to put board pinouts, etc w/ edalize stuff
<cr1901_modern>
fwiw
<cr1901_modern>
I think that should still be migen's responsibility
<adamgreig>
does edalize know how to produce pcf files for each platform?
<adamgreig>
or just how to poke the tools with existing files?
<cr1901_modern>
the latter
<cr1901_modern>
I'm not against redesigning how platform works, just that I think nmigen should still generate pcfs and leave the actual building to edalize
<whitequark>
sure
hartytp has quit [Ping timeout: 256 seconds]
X-Scale has quit [Ping timeout: 245 seconds]
X-Scale` has joined #m-labs
X-Scale` is now known as X-Scale
lkcl has quit [Ping timeout: 245 seconds]
<_whitenotifier-e>
[nmigen] sam-falvo opened pull request #22: Updated user guide introduction for nmigen. - https://git.io/fhszI
lkcl has joined #m-labs
<kc5tja>
that'd be me making the PR. :) Off to get some lunch.
<mithro>
whitequark: Will you be taking contracting work to port things from migen to nmigen?
<whitequark>
mithro: it's possible; i would be especially interested in funding for a tool that automatically ports migen code to nmigen
<whitequark>
but this needs a feasibility study first
<mithro>
whitequark: That might be something I'm interested in -- I would be very interested in something along the lines of a migen linter / pep8 type thing too....
<whitequark>
okay, i'll take that into account
<mithro>
whitequark: The new "with XXX" syntax should be more pep8 friendly anyway, right?