ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting November 9th
<_whitenotifier-f> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-f> [YoWASP/nextpnr] whitequark 9262321 - Update dependencies.
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
ademski has quit [Ping timeout: 245 seconds]
PyroPeter_ has joined #nmigen
emeb has quit [Quit: Leaving.]
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined #nmigen
jjeanthom has joined #nmigen
_whitelogger has joined #nmigen
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 260 seconds]
Asu has joined #nmigen
Shari2 has joined #nmigen
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<Lofty> I just realised that I'm going to be using Quartus to work with initialised memories again, and, ugh
<d1b2> <OmniTechnoMancer> Quartus does not agree with the concept of initialised memories and stages protest?
Shari2 has quit [Remote host closed the connection]
<Lofty> OmniTechnoMancer: Quartus has exactly one way of handling initialised memories - to use its special text format - and everything else takes the slow path of being converted into this
<Lofty> So, nmigen loves to produce a *giant* initial block to initialise memories (there's write_verilog -extmem, but that has problems for nmigen's use case)
<Lofty> Quartus then decides to convert this to the MIF format
<Lofty> Which takes forever
<Lofty> And it redoes this every time you run the compiler
<d1b2> <OmniTechnoMancer> ah ><
<Sarayan> why is it taking ages? mif is not really complex, just annoying
<Lofty> Sarayan: you should know by now that Quartus isn't particularly fast :P
<d1b2> <OmniTechnoMancer> I wouldn't be surprised if Quartus has to do something like boot up some x86 unix environment in qemu to do the conversion or something cursed like that
<Sarayan> can't nmigen and/or yosys generate mif directly?
<Sarayan> (or we could patch the bitstream after the fact, but that's another story, and not very good for sims)
<Lofty> Sarayan: Sure, yosys can (write_verilog -extmem is...close enough) but nmigen reads the output of write_verilog as a pipe, so there's nowhere for the other files to go
<Sarayan> Ah yeah, I always see nmigen as a front-end and not as something that also calls the other tools
<Sarayan> or as a step in a pipeline, more precisely, where the pipeline engine itself is make or ninja
<d1b2> <OmniTechnoMancer> clearly the answer is base64 and asci armor 😛
<Lofty> Sarayan: is not enough for you? :P
<Sarayan> I'm a unix guy at heart, I like tools that do one thing and do it well
<Sarayan> for me nmigen is something that generates input for yosys
<Lofty> I never found the unix philosophy particularly practical, but that's off topic
<Lofty> handles this stuff a lot better than a Makefile could due to the number of template files you need to create
<Sarayan> template files?
<Lofty> Like, the Quartus QSF
<Sarayan> ah, yeah, I'm not putting "quartus" in my list of good unix tools :-)
<Asu> hi, i'm wondering how to represent mutually exclusive resources/connectors in a board support file. on this board gpio pins overlap with two 7seg displays (and you physically select what your design uses using a dip switch on the board). how should i represent this?
<Asu> my understanding is that if i don't do anything special then nmigen will error out if trying to request both, but i'm not sure if this is the preferred way.
emeb has joined #nmigen
<lkcl> Asu: if you intend to provide both at run-time, clearly that is impossible, and you will need to add a pinmux
<lkcl> if you don't intend that it be done at runtime, then, clearly, the developer requesting both and an error occurring is exactly what is needed.
<lkcl> if this is an FPGA board, the general consensus summarises as "you've got the source code, it's an FPGA, just recompile the program, don't waste space with a pinmux".
<Asu> i don't intend to allow having both at runtime, what i was wondering was whether there was an explicit way to define two resources as mutually incompatible so that the error could be more specific (and point to the board user manual/datasheet or something)
<Asu> fwiw, i have just tried just requesting both in a single design, and the physical pin ResourceError from nmigen is straightforward enough, so i might as well leave it at that for now
<whitequark> Asu: i've seen your issue fwiw, just haven't got around to responding yet
<Asu> np
emeb_mac has joined #nmigen
<lsneff> Huh, was processing a vcd and got terribly confused by the orientation of the value change data. I thought the most-significant bit was at the end for some reason
jfng has quit [Ping timeout: 260 seconds]
whitequark[m] has quit [Ping timeout: 260 seconds]
jfng has joined #nmigen
whitequark[m] has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
emeb has left #nmigen [#nmigen]
Asu has quit [Quit: Konversation terminated!]
jjeanthom has quit [Ping timeout: 256 seconds]