ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each 1st & 3rd Monday at 1800 UTC · next meeting July 6th
jeanthom has quit [Ping timeout: 240 seconds]
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
<d1b2> <ld;cd> Newb question here, how do I request say 8 LEDs as an 8bit unsigned signal instead of just individually?
<d1b2> <ld;cd> python In [28]: class Test(n.Elaboratable): ...: def elaborate(self, platform): ...: leds = [platform.request("led", i) for i in range(8)] ...: timer = n.Signal(20) ...: m = n.Module() ...: m.d.sync += timer.eq(timer + 1) ...: m.d.comb += n.Cat(*[i.o for i in leds]).eq(timer[-1]) ...: return m
<d1b2> <ld;cd> have tried a couple variations on that with different forms of success
<d1b2> <ld;cd> oh that did do what I want
<d1b2> <ld;cd> is there a recommended cleaner why of doing that?
jaseg has quit [Ping timeout: 244 seconds]
<d1b2> <esden> the intuitive thing would be to just have leds = platform.request("led") so that leds ends up with the "led" bundle. 🙂
<d1b2> <esden> but that might not work not sure
<d1b2> <ld;cd> lets find out
<d1b2> <ld;cd> ah and then Repl is the equivalent of the {} verilog forms
<d1b2> <ld;cd> nope, it just requests the zeroth one looks like
<d1b2> <TiltMeSenpai> I think you want Cat
<d1b2> <esden> ohh ok humm
jaseg has joined #nmigen
<d1b2> <esden> @TiltMeSenpai isn't it what @ld;cd is doing in the example?
<d1b2> <TiltMeSenpai> oh that is
<d1b2> <TiltMeSenpai> ignore me
<d1b2> <TiltMeSenpai> just woke up from a little nap lol
<d1b2> <esden> hands @TiltMeSenpai a coffee and cookie
<d1b2> <ld;cd> wonder how discord format tags show up on IRC
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel_ has joined #nmigen
<d1b2> <ld;cd> is this an alright way to conditionally add a resource: python class ECP55GEVNPlatform(LatticeECP5Platform): .... def __init__(self, *, VCCIO1="2V5", VCCIO6="3V3", FTDI_UART=False, EXTCLK_FREQ = None, **kwargs): .... if FTDI_UART: self.resources[('uart', 0)] = UARTResource(0, rx="P2", tx="P3", attrs=Attrs(IO_TYPE="LVCMOS33", PULLMODE="UP"))
<whitequark> esden: platform.request(x) is the same as platform.request(x, 0)
<whitequark> in migen this used to return consecutive resources but that's kind of bad because you might request resources in different parts of your code and then at none of these places it is obvious which one you get
<d1b2> <ld;cd> for context the ECP5EVN has a second UART that isn't wired up by default
<whitequark> what do you mean by "not wired up"?
<d1b2> <ld;cd> like
<d1b2> <ld;cd> you need to swap to zero ohm resistors and if you have one of the bad runs of the eval board reprogram the ftdi eeprom
<whitequark> in general we don't add __init__ arguments in cases where that would *add* a resource
<whitequark> it's only for *choosing* between different options, eg IO voltages
<whitequark> so: just add the UART, add a comment about it too
<whitequark> some day we'll figure out some way to have sphinx document those things
<d1b2> <ld;cd> alright
<whitequark> but for now a comment works
<d1b2> <ld;cd> Theres also a similar thing with an unpopulated clock footprint, should I add it as a resource and then leave the frequency undefined?
<d1b2> <ld;cd> or pipe a frequency through init
<d1b2> <ld;cd> its nominally supposed to be 50Mhz but there are other modules you can add in theory
<whitequark> leave out Clock()
<whitequark> Clock() is just a shortcut for platform.add_clock_constraint that's automatically applied
<d1b2> <ld;cd> alright, cool
<d1b2> <esden> @whitequark right I do remember that the request used to iterate over the resources. That is not great, I agree. In this case I would somehow expect that if I don't provide an id I can get a Signal(<led count>). (maybe even have a way to provide a range even to request certain set of led would be great) But I guess the way it is is fine too. Definitely better than getting a random led because some other part of the code already requested one. 😄
jock-tanner has joined #nmigen
<_whitenotifier-f> [nmigen-boards] ld-cd opened pull request #70: Add SPI Flash, UART, and EXTCLK peripherals to ECP5_EVN -
<d1b2> <ld;cd> oh thats neat
jeanthom has joined #nmigen
<whitequark> ld;cd: can you explain what you meant by "left out the QUADSPI mode"?
<whitequark> you've provided wp and hold pins; that creates the spi_flash_4x resource on its own
<d1b2> <ld;cd> oh ok
<d1b2> <ld;cd> in that case I did not leave out QSPI, sorry for the confuision
<d1b2> <ld;cd> sorry, thats why I was so confused about the QSPI/normal SPI earlier
<_whitenotifier-f> [nmigen-boards] ld-cd commented on pull request #70: Add SPI Flash, UART, and EXTCLK peripherals to ECP5_EVN -
<whitequark> yeah this should be documented better
<_whitenotifier-f> [nmigen-boards] whitequark closed pull request #70: Add SPI Flash, UART, and EXTCLK peripherals to ECP5_EVN -
<_whitenotifier-f> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1]
<whitequark> thanks!
<_whitenotifier-f> [nmigen/nmigen-boards] ld-cd d42a55f - ecp5_evn: add SPI Flash, UART, and EXTCLK peripherals
<d1b2> <ld;cd> Awesome, thanks for the help!
<whitequark> np
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [nmigen/nmigen] whitequark 2606ee3 - back.pysim: simplify.
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [nmigen/nmigen] whitequark 25ce260 - lib.cdc: update PulseSynchronizer to follow conventions.
<_whitenotifier-f> [nmigen] whitequark closed issue #370: Update lib.cdc.PulseSynchronizer to follow nMigen conventions -
<_whitenotifier-f> [nmigen] whitequark commented on issue #228: Reconsider simulator interface -
<_whitenotifier-f> [nmigen] whitequark commented on issue #13: Make it possible for generators to simulate combinatorial logic -
kernelmethod has joined #nmigen
kernelmethod has quit [Client Quit]
kernelmethod has joined #nmigen
kernelmethod has quit [Quit: leaving]
Asu has joined #nmigen
<zignig> ktemkin: got LUNA examples running on tinybx, hooray USB gateware phy.
<zignig> thanks to you and her Quarkyness (.. et al)
<ktemkin> ^_^
<whitequark> i should get LUNA to run on some of my devboards
<_whitenotifier-f> [nmigen] smunaut opened issue #414: Py 3.7: ModuleNotFoundError: No module named 'importlib_resources' -
<ktemkin> speaking of which: is there any point in me squishing any FS USB analysis stuff over into Glasgow?
<ktemkin> I dunno what that result would even look like, since normally my goal is to squirt the data over to Qyriad's ViewSB
<jock-tanner> now i'm trying to use bidir pins
<jock-tanner> m.d.comb += sdram.dq.i.eq(self.data_in)
<jock-tanner> and i getting: assert defs[sig] is self
<jock-tanner> another popular gotcha?
<ktemkin> jock-tanner: for bidirectional pins, you'll wind up with a tri-state triple
<ktemkin> .i, .o, and .oe
<ktemkin> you'll want to use .o for output, and .oe to decide when the pin is being driven by the signal you assign to .o
<jock-tanner> ktemkin thank you, it all makes sense now
<_whitenotifier-f> [nmigen] whitequark commented on issue #414: Py 3.7: ModuleNotFoundError: No module named 'importlib_resources' -
<_whitenotifier-f> [nmigen] whitequark commented on issue #414: Py 3.7: ModuleNotFoundError: No module named 'importlib_resources' -
<_whitenotifier-f> [nmigen] smunaut commented on issue #414: Py 3.7: ModuleNotFoundError: No module named 'importlib_resources' -
<_whitenotifier-f> [nmigen] smunaut closed issue #414: Py 3.7: ModuleNotFoundError: No module named 'importlib_resources' -
jock-tanner has quit [Ping timeout: 240 seconds]
jock-tanner has joined #nmigen
<jock-tanner> no luck with bidir today :`(
<jock-tanner> Warning (12161): Node "pin_sdram_0__dq:pin_sdram_0__dq|altiobuf_bidir:sdram_0__dq|dataio_b[0]" is stuck at GND because node is in wire loop and does not have a source
FFY00 has quit [Quit: dd if=/dev/urandom of=/dev/sda]
FFY00 has joined #nmigen
<jock-tanner> i've built a reduced example of it, with dq.oe tied to the vcc, but quartus still says "wire loop"
<tpw_rules> is there a way to clear a SyncFIFOBuffered?
<whitequark> you can reset it!
<whitequark> use a ResetInserter
<tpw_rules> will that reset just it?
<whitequark> did you accidentally a word?
<tpw_rules> no like if i wrap the fifo in a resetinserter and use that reset signal, just the fifo will be reset and the rest of the circuit will run unaffected?
<tpw_rules> how do i use a resetinserter anyway?
<whitequark> m.submodules += ResetInserter(rst)(SyncFIFOBuffered(...))
<whitequark> and yes
<tpw_rules> rst is the signal i'll use to reset the fifo?
<whitequark> yep
<tpw_rules> cool. thanks
jock-tanner has quit [Remote host closed the connection]
jeanthom has quit [Ping timeout: 258 seconds]
jordi_ has joined #nmigen
<FL4SHK> How do I use the `ResetSignal` thing as if it were an `initial`?
<FL4SHK> actually, I'd like to be able to reset more than once
<FL4SHK> I'd like to use a synchronous reset signal
<FL4SHK> I've got `with m.If(ResetSignal("sync"))`
<FL4SHK> I'm not sure this is correct
<FL4SHK> What is `ResetInserter`?
<FL4SHK> whitequark: poke
chipmuenk has joined #nmigen
<d1b2> <ld;cd> Has there been any thinking about how to handle the PS7 (the interface between the fabric and the arm cores/other hard blocks) on the zynqs in anything like nmigen
<d1b2> <ld;cd> I'd kind of like to port nmigen to my pynq so I don't have to fight with vivado as much
<FL4SHK> tfw there's now a PS7. I thought those only went up to 5.
<daveshah> there's now a PS9 (versal)
<daveshah> PS8 is UltraScale+
<FL4SHK> I was making a joke regarding the Playstation
<d1b2> <ld;cd> In an ideal world it would be a non mandatory part of the design but vivado will refuse to synth if you don't instantiate it, and it's the canonical way to get clocks/resets
<d1b2> <ld;cd> I'm stuck with my dinky little 7 series zc7020 for the moment
<d1b2> <ld;cd> Or maybe it's an xc7z020, I always get xilinx part numbers jumbled, too many consonants
<agg> ld;cd can't you just instantiate it with an Instance? I've not used zyncs but had no issue doing the equivalent stuff on the intel SoCs
<agg> (I've heard it's a lot more fiddly with the zyncs though...)
<d1b2> <ld;cd> So yeah you could just black box it and instantiate it (although it's a bit of a pain)
<d1b2> <ld;cd> But I wouldn't really know how to organize a port of the proper nmigen flow because it's kind of in this strange place between a hard ip block, and an io port (idk how altera parts work, but the PS7 generally provides all the clocks for example)
<d1b2> <ld;cd> But I wouldn't really know how to organize a port of the proper nmigen flow because it's kind of in this strange place between a hard ip block, and an io port (idk how altera parts work, but the PS7 generally provides all the clocks for example)
<d1b2> <ld;cd> Heckin networking
<agg> Oh, to sort of provide it as part of the Platform rather than just instantiating in one design?
<d1b2> <ld;cd> I'm not really sure what the nmigeny way to do it would be
<d1b2> <ld;cd> Yeah that's what I was thiniking, but it's also fairly configurable
<agg> If you just want to get it working in your project I'd definitely just make an instance of the relevant modules and it's easy enough to wire those up to your clock domains and axi controllers and whatever else
<agg> You could even package those instances up as a python library for reuse
<agg> I don't know how you could integrate it into the platform itself so that eg it works as a default clock though
jeanthom has joined #nmigen
<d1b2> <ld;cd> Yeah so I can do it on a per project basis, but I'd like to tackle adding it as a proper platform, as so far the zynqs parts have been left behind by the likes of nmigen and litex
<d1b2> <ld;cd> And they're pretty common in education
<d1b2> <ld;cd> They also have the advantage of having a hard ddr3 controller and relatively cheap boards with a gig or 2 of ram on them that would be nice for people who want to play with soc stuff
<vup> ld;cd fwiw anuejn and me have been playing around with PS7 in nmigen a lot
<d1b2> <ld;cd> Oh neat
<vup> atm its nothing exceptionally fancy, mostly just helpers and adding it to platform
<d1b2> <ld;cd> Oh nice, this is pretty handy
<vup> is uses yosys to generate automatic wrappers for vendor specific blackboxes
<d1b2> <ld;cd> Lmao
<d1b2> <ld;cd> Do you synth through the nmigen build tools, or do you emit verilog and open it in vivado?
<vup> synth through nmigen platform stuff
<vup> the blackbox thing and tries to automatically group all the ports, but we are not sure this is actually useful, was quite handy for the ps7 tho
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Ping timeout: 264 seconds]
Asu has quit [Quit: Konversation terminated!]
<d1b2> <ld;cd> Oh nice
nengel has quit [Ping timeout: 240 seconds]
jeanthom has joined #nmigen