ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
samlittlewood__ has quit [Ping timeout: 260 seconds]
samlittlewood_ has joined #nmigen
Degi_ has joined #nmigen
<Vinalon> Is there a way to suppress individual warnings for things like hierarchy flattening?
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
<whitequark> not individual warnings for that specifically, no
<whitequark> there is some infrastructure to suppressing warnings per-file though
<whitequark> (well, you could in theory use python warning filters, but i never got them to work, i don't recall why)
<Vinalon> okay, thanks - I guess I'll just use '-W ignore'
<Vinalon> or wrapping the simulation in 'with warnings.catch_warnings():' and 'warnings.filterwarnings("ignore", category=DriverConflict)' seems to work too
Stary has quit [Quit: ZNC -]
Stary has joined #nmigen
Vinalon has quit [Ping timeout: 256 seconds]
Vinalon has joined #nmigen
Vinalon has quit [Ping timeout: 264 seconds]
Vinalon has joined #nmigen
Vinalon has quit [Ping timeout: 264 seconds]
Vinalon has joined #nmigen
kernelmethod has joined #nmigen
kernelme1hod has joined #nmigen
kernelmethod has quit [Client Quit]
kernelme1hod has quit [Client Quit]
kernelmethod has joined #nmigen
kernelmethod has quit [Client Quit]
pdp7 has quit [Changing host]
_whitelogger has joined #nmigen
Asu has joined #nmigen
Vinalon has quit [Ping timeout: 256 seconds]
FFY00 has joined #nmigen
Vinalon has joined #nmigen
<mithro> whitequark: Have you see the ASCII wave diagrams in PyRTL? --
<Degi> Cool
<whitequark> have not
<whitequark> they look cool but I'm not sure how useful they are for practical design
Vinalon has quit [Read error: Connection reset by peer]
Vinalon has joined #nmigen
Vinalon has quit [Ping timeout: 264 seconds]
Vinalon has joined #nmigen
Vinalon has quit [Ping timeout: 250 seconds]
Vinalon has joined #nmigen
<MadHacker> Nice for when you're SSHing to where you're playing with logic.
<MadHacker> I guess. I mean, it's hardly an essential feature. But cute.
<MadHacker> Actually, it's diffable. That's a nice detail.
<Degi> Does somebody know how to program the flash on the ECP5 EVN with nmigen?
<whitequark> that's not functionality nmigen can provide directly; a tool like openocd should support it first
<whitequark> I believe there is currently no off the shelf support for it, though some people did hack flash programming in
<whitequark> once there is upstream support in openocd, nmigen can wrap it
<Degi> Oh openOCD doesn't support it
<whitequark> I think it doesn't, but I'm not up to date on openocd, so please recheck
<daveshah> There's no native ecp5 support in openocd at all, it's all svf based
<daveshah> There is also a script floating around to generate a svf for flash programming but it's slow because it has to wait the max erase and program times rather than polling
<daveshah> I don't think anyone is working on ECP5 support in openocd atm
<Degi> I'm kinda wondering because ULX3S and LUNA also have flash chips onthem
<Degi> Could I just write the .bit file into a flash chip?
<cr1901_modern> daveshah: I guess this falls under "why would you want to?". But you can't generate svf for ECP5 from diamond programmer? Or does openocd not implement lattice extensions to ISC?
Vinalon_ has joined #nmigen
Vinalon has quit [Ping timeout: 264 seconds]
Vinalon_ is now known as Vinalon
<ktemkin> Degi: yep
<awygle> You need to write a proxy bitstream, according to the openocd team
<awygle> There's an example for a Spartan chip
<ktemkin> it depends on how the relevant board has the flash hooked up
<awygle> (I was just looking into this a bit ago)
<awygle> The versa board has the flash hooked to the boot flash pins
<Degi> I thought about just using a µC with USB or something to directly write onto the SPI flash
<ktemkin> that'll work
<ktemkin> you can also come up with gateware that translates from a format you _do_ have comms in to SPI
<Degi> Hm I can just use the SPI pins as GPIO after its initialized, right?
<ktemkin> almost
<ktemkin> you'll need to use USRMCLK to drive the SPI CLK
<ktemkin> instead of requesting the I/O pin for the clock pin, use something like:
<ktemkin> m.submodules += Instance('USRMCLK', i_USRMCLKI=sck_signal, i_USRMCLKTS=0)
<Degi> Hmm maybe I can just use a UART to write onto the FPGA and then into the flash. Why is there a 128 Mb / 16 MB flash when the bitstream is like 2 MB?
<Vinalon> Maybe to store program data for your SoC?
<Degi> Oh neat
<ktemkin> multiboot is a thing
<ktemkin> check the configuration guide's Table 1; they have some recommended flash sizes with rationales
<Degi> Oh I see. 64 Mb for dual boot and I guess the dev board just has double that for extra storage
_whitelogger has joined #nmigen
<Degi> What is USRMCLKTS?
<mwk> tristate
<mwk> enables you to enable/disable the output buffer
<Degi> Hm is it inverted? So USRMCLKTS=0 enables the buffer?
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
<_whitenotifier-3> [nmigen-stdio] whitequark closed pull request #5: serial: fix receiver bit order. -
<_whitenotifier-3> [nmigen/nmigen-stdio] whitequark pushed 1 commit to serial [+0/-0/±2]
<_whitenotifier-3> [nmigen/nmigen-stdio] jfng 2ff6d7d - serial: fix receiver bit order.
<_whitenotifier-3> [nmigen-stdio] whitequark commented on pull request #5: serial: fix receiver bit order. -
<_whitenotifier-3> [nmigen/nmigen-soc] jfng pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-3> [nmigen/nmigen-soc] jfng 425692a - csr.wishbone: fix WishboneCSRBridge cycle counter.
<_whitenotifier-3> [nmigen-soc] jfng closed pull request #13: csr.wishbone: fix WishboneCSRBridge cycle counter. -
<_whitenotifier-3> [nmigen-soc] Success. 100.00% (+0.00%) compared to f23dcc8 -
<_whitenotifier-3> [nmigen-soc] Success. 100.00% of diff hit (target 100.00%) -
<Degi> Do FIFOs always take 2 cycles to operate?
<daveshah> mwk: there's a really horrible bug in Diamond too so don't feel bad
<daveshah> If you have a tristate serdes driving t and you do, assign pin = t ? d : 1'bz
<daveshah> Which if course is not correct
<daveshah> Instead of erroring out, it silently flips the two around into the pattern it expects
<mwk> ... lol
<mwk> awesome
<daveshah> cr1901_modern: by default when you generate a flash svf it has some nonstandard loop statements that openocd doesn't support
<daveshah> I think you can turn them off, but then you hit the slow programming issue again
<cr1901_modern> oh right I forgot about those
<daveshah> Even more cursedly, it can generate an SVF file for iCE40 RAM or NVCM programming even though its not JTAG at all
<whitequark> swf has loops?
<whitequark> svf*
<daveshah> No, Lattice have a non standard extension
<whitequark> hm, i should implement those in glasgow i think
<whitequark> oh, cute
<daveshah> This is an entire ecp5 spi flash svf from diamond fwiw
Asuu has joined #nmigen
Asu has quit [Ping timeout: 258 seconds]
rohitksingh has quit [Quit: No Ping reply in 180 seconds.]
rohitksingh has joined #nmigen
<_whitenotifier-3> [nmigen/nmigen-stdio] jfng pushed 2 commits to master [+2/-0/±3]
<_whitenotifier-3> [nmigen/nmigen-stdio] whitequark 6797ba2 - serial: WIP
<_whitenotifier-3> [nmigen/nmigen-stdio] jfng b5ff8b8 - serial: fix receiver bit order.
<whitequark> ah, should probably have squashed that PR
<jfng> oops, sorry
<whitequark> in general I try to avoid WIP-like commits because they add noise while bisecting or annotating commit
<whitequark> and github now has Co-authored-by to preserve authorship info
<jfng> ah right, I saw awygle use that in an nmigen commit some time ago
<whitequark> it's nonstandard (github only) but I think it is good enough
<awygle> by which you mean whitequark used it because idk how lol
<whitequark> yeah I probably squashed awygle's commit or something
<awygle> mhm
<awygle> squash that ~beef~ commit
<awygle> jfng thanks for your work on the nmigen-stdio and nmigen-soc stuff recently
<jfng> my pleasure :)
Asuu has quit [Remote host closed the connection]