ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 5th
Asuu has quit [Remote host closed the connection]
_whitelogger has joined #nmigen
bmartin427 has joined #nmigen
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #nmigen
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
FFY00 has quit [Ping timeout: 240 seconds]
FFY00 has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined #nmigen
Asu has joined #nmigen
chipmuenk has joined #nmigen
FFY00 has quit [Ping timeout: 240 seconds]
FFY00 has joined #nmigen
FFY00 has quit [Read error: Connection reset by peer]
_whitelogger has joined #nmigen
FFY00 has joined #nmigen
<lkcl> Lofty: you're doing an FPGA, right? you may be interested in this
<lkcl> wait... wrong cut-paste link :)
<lkcl> actually you might still be interested in that online conference :)
<Lofty> Already seen the article
chipmuenk has quit [Quit: chipmuenk]
mwk has quit [Ping timeout: 240 seconds]
mwk has joined #nmigen
Chips4Makers has quit [Ping timeout: 240 seconds]
Chips4Makers has joined #nmigen
<FL4SHK> any way to get nmigen boards to not always recompile everything?
<FL4SHK> tbh that's one thing I'm after
<vup> do you mean the not recompiling if nothing has changed, or more like incremental synthesis and pnr?
<FL4SHK> the former seems easier
<FL4SHK> the latter I think is toolchain specific
<FL4SHK> the former is what I'm after
<vup> yep
<FL4SHK> ...having nMigen support the incremental synthesis and pnr in a generic sense would be a cool long-term goal
<vup> that seems very hard to do without very good toolchain support
<vup> so maybe with yosys and nextpnr that might be possible, but with some random vendor toolchain that seems really hard
<FL4SHK> how do I use it?
<vup> I meant it more as an example of how one can do such a thing, if you want to use it in your project you probably want to detangle it from our Cli stuff (but that should not be too hard).
<vup> The general idea is, to use, do_build=False) to get the BuildPlan, check if there is already a bitstream for that BuildPlan, if there is, use that one, if not, build it
<vup> (tho note, that this has some edgecases where it will do wrong things, like for example when you change any of your environment variables that control the compilation)
<agg> is the use-case just so you can rerun programming without rebuilding?
<agg> i've sometimes given my main script the option to build and/or program, so you can just reprogram if there's an existing bitstream, and i've also used Make which can at least check if any python files changed requiring a rebuild (though faffy to set up and not the most obvious thing to use with a python program)
<vup> agg: yep basically that, currently this just checks if the lastest build folder matches what is supposed to be built and skips building in that case, it could however easily be extended to check all build folders, so it would work if you switch between different configurations or something like that
<agg> nice, being able to work out if different configs need rebuilding would be convenient
<FL4SHK> so what do I need to do for it?
<agg> that link shows how that project's build system manages it
<agg> it might be a useful example for how you could implement it or even copy it
<agg> but it's not built in to nmigen or a trivial thing to add, and it depends on how you're currently using nmigen too
<miek> afaik glasgow uses it to avoid rebuilding a bitstream that is already flashed on to the device
<vup> uh nice
<anuejn> vup: emily: re your earlier discussions: is actually quite wip
<anuejn> and i have never gotten it to fully work
<anuejn> so expect things to break horribly when you build stuff on it
<FL4SHK> anyone know how to fix udev without rebooting the computer?
<FL4SHK> I may have to reboot it...
<FL4SHK> Having distro hopped a bit, I am finding myself unable to program my dev board!
<agg> FL4SHK: `udevadm control --reload`
<agg> but if you've set it to grant access to a particular group and you're not yet in the group, you will need to log out and in again to become part of that group
<agg> (often also `systemctl restart udev`)
<FL4SHK> don't have systemctl :P
<FL4SHK> using OpenRC
<agg> your init system of choice probably has a service for udev which it can restart, but udevadm should work in any event
<FL4SHK> asking in #artix
<FL4SHK> didn't know about udevadm
<vup> anuejn: you probably meant @EmilJ?
<anuejn> ah yes, thanks
<FL4SHK> agg: so what group do I give to my user?
<agg> It depends on your udev rules.
<FL4SHK> oh
<agg> ..., often "plugdev"*
<agg> Sorry I hit enter trying to out more dots in and it came off a bit more severe than I intended
<agg> You can also set it to give access to any locally logged in user or to your specific username or whatever
<agg> That just allows any users, so you wouldn't need to be any particular group
<FL4SHK> If I had to guess it's because of the MODE="..."
<FL4SHK> is there a `GROUP="..."` thing?
<agg> Yep exactly
emeb_mac has joined #nmigen
<FL4SHK> I'm honestly really hoping that this just works
<FL4SHK> "Can't scan JTAG chain. Error code 87."
<FL4SHK> anyone know how to fix this?
<FL4SHK> I ran into it before
<FL4SHK> but I didn't take any notes on how to fix it
<FL4SHK> I did fix it
<FL4SHK> I don't think the dev board is busted
<DaKnig> how can I have a Record within a Record?
<ktemkin> DaKnig: you can nest layouts
<ktemkin> so `[ ('a', 32), ('b', [('b1', 16), ('b2', 16)]) ]`
<DaKnig> did you forget the )]
<DaKnig> oh oops
<DaKnig> nvm
<DaKnig> ok that should work
<FL4SHK> got the thing working!
<FL4SHK> I was missing a library
<FL4SHK> fortunately, the Arch Wiki is really good
<FL4SHK> DaKnig: records within records is a standard feature, eh?
<d1b2> <EmilJ> anuejn: hi, to what degree is functional? Is the HDMI output functionality alive atleast somewhat?
<danfoster> sorry if this is common knowledge, but what's the difference between the nmigen/nmigen repo and m-labs/nmigen repo on github?
<DaKnig> nmigen/nmigen is more updated
<DaKnig> .. I thnk
<DaKnig> seems like I was wrong. sorry.
<d1b2> <TiltMeSenpai> about nmigen/nmigen vs m-labs?
<d1b2> <TiltMeSenpai> this IRC does development on nmigen/nmigen, I think calling it "more updated" is fair
<sorear> look at the number of commits since march on each of them
<DaKnig> wait, no, it is more updated. m-labs version does not have anyhting 0.2 or above
<lkcl> Lofty: cool.
<ktemkin> danfoster: nmigen/nmigen is the official repo; m-labs/nmigen is a fork left around from when wq was working with m-labs
<lkcl> vup, FL4SHK: well, Makefiles (GNU make) is the specialist tool that is designed to do partial builds. it contains all of the hierarchical analysis needed, based on file timestamps, to determine if a rebuild of intermediate compilation is required.
Asu has quit [Quit: Konversation terminated!]
<lkcl> in theory a Makefile could be auto-generated by nmigen rather than the commands issued _by_ nmigen
<DaKnig> it works well, until it does not
Asu has joined #nmigen
<lkcl> although making GNU make a hard dependency for e.g. windows platforms... mmm... not such a nice idea to force people to have yet more parts of MSYS / Cygwin.
<lkcl> a *potential* workaround to investigate *might* be to see if ccache can be either used as-is or adapted / adopted transparently.
<lkcl> if ccache can be adapted to be used with yosys scripts (hashing the incoming arguments and the yosys script and the input files)
<lkcl> then as long as yosys is deterministic i see no reason why it shouldn't be used
<whitequark> lkcl: what you describe re GNU make is one major reason why nmigen doesn't depend on it; this has been discussed a few times in the past
<whitequark> misoc did rely on GNU make and it was pretty miserable for windows users
<whitequark> as far as i know, ccache cannot be extended, it hardcodes a lot of gcc-specific knowledge
<lkcl> whitequark: yeah i figured / remember.
<sorear> has anyone rewritten make in python
<sorear> .oO( scons dep )
<whitequark> given that most FPGA builds are the equivalent of an LTO build in C/C++ projects there isn't a large payoff from incremental rebuilds
<lkcl> sorear: sc... yeah. i love the proposed patch to python to make scons the default build option :)
<whitequark> sure, some specialist use cases do benefit from it, but i don't think that complicating the build process for everyone for the sake of the very few people who get fairly small gains from it is not worth it
<whitequark> of course we can always revisit this decision later
<lkcl> yyeah if the project were subdivided into file-fragments, with unit tests and so on, and those were actually big enough to justify it
<lkcl> whitequark: jean-paul from LIP6 and rudi from both tell me that people are used to doing overnight or multiple-day builds of ASICs (!)
<lkcl> and there's nothing that can be done about it
<whitequark> well, no, you can take the quality of synthesis hit and run synthesis per functional block rather than per entire design
<whitequark> for some reason though people don't like that
<lkcl> oh, true
<whitequark> (probably because people don't like overpaying for ASICs to make the life of ASIC designers a bit easier)
<DaKnig> how big is the hit?
<XgF> Substantial in terms of perf
<whitequark> ^ yup
<DaKnig> ah wait we are discussing ASIC. I have no idea how this works at all lol
<whitequark> it's visible on FPGAs too
<DaKnig> in FPGA that would not be that bad , right?
<whitequark> run synth_ice40 -noflatten
<DaKnig> wait really
<whitequark> on your designs. then compare. works with synth_ecp5 as well
<DaKnig> but in most cases at least I got used to having the ouput of every block buffered, so the optimizations the tool could make at the edges are ... minimal? at least that's what I'd assume
<lkcl> the only "big" difference is that I/O if it is a bi-directional pin has to be declared as a triple of signals: xxx_i, xxx_o and xxx_oe
<lkcl> other than that, DaKnig, it's... yeah pretty much the same. i've even modified litex to add an "ASIC" platform based of off a ulx3s one (!)
<DaKnig> nice
<lkcl> ulx3s FGPA one that is
<lkcl> so i'm still using litex (which, sigh, uses migen)
<lkcl> urr i do wish they'd convert it to nmigen...
<DaKnig> can you convert only parts of the design?
<lkcl> litex auto-builds a peripheral set for you, based on a "plaform" choice and a "cpu" choice.
<lkcl> the platform declares the peripherals, the cpu, well, chooses the cpu
<lkcl> sorry: *your* program declares the peripherals, and builds the (output) verilog based on a platform+cpu tuple
<lkcl> the entire "glue" between all 3 is python-driven auto-constructed migen
<lkcl> from what i understand, nmigen-boards and nmigen-soc is slowly taking shape to provide the same functionality as litex
<DaKnig> I see
<lkcl> the biggest bug-bear that i have with migen (and thank god for nmigen) is that it relies on verilog for error checking
<lkcl> i created a migen FSM last month, and mixed up sync and comb. no warning, no compile-time errors.
<lkcl> likewise i have sometimes gotten all the way through to ASIC coriolis2 builds before noticing that an input was declared as an output
<lkcl> litex is a fantastic tool... built on a fundamentally unsound one!
<lkcl> i realllyy want to see it converted to nmigen :)
* lkcl wonders if there is still migen interoperability in nmigen?
<Lofty> lkcl: nmigen.compat isn't going anywhere.
<lkcl> Lofty: ah that's what it was called. that would be very interesting to see if that can be called from litex
<lkcl> thx
<Lofty> (yes, it can)
<lkcl> really! ah wow! cool!
alanvgreen has joined #nmigen
<whitequark> strictly speaking nmigen is still unsound
<whitequark> it's just less unsound
<whitequark> it's currently nowhere close to e.g. clash, which actually spends a remarkable amount of effort on soundness of synthesis, very impressive
<whitequark> though i vaguely recall that clash still has some unsound bits related to Index variables
<whitequark> really, we have yet to see a truly sound approach to RTL, an equivalent of a completely memory safe language
<whitequark> the worst part is that it's usually not clear what is "sound RTL", in ways that are both subtle and impossible to figure out conclusively without the vendor
<whitequark> for example we have an open bug about soundness of AsyncFIFO
<whitequark> whether this is an *actual issue* on any particular FPGA is an open question i have no easy way to answer
<whitequark> so i conservatively default to "yes" but is it really? who knows
Asu has quit [Quit: Konversation terminated!]
<lkcl> whitequark: i do like bluespec for the fact that, being written in haskell, it has 100% guarantees of outputting synthesiseable verilog
<lkcl> but
<lkcl> hoo-boy is its strong type-checking a total pain to work with
<lkcl> i spent 3 weeks with the RISE Group in IIT Madras and had to interrupt the lead engineer for about an *hour* a day so that we could go over the Reference Manual and API.
<lkcl> however, the proof-of-pudding: the team, bear in mind they had never done a chip before, never used *any* HDL before, got working 22nm silicon *first time*. that's completely unheard-of.
<whitequark> it's not about synthesizable verilog
<whitequark> there's plenty of synthesizable verilog that is also unsound; for example anything with CDC violations