ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting August 24th
sir_oslay has joined #nmigen
sir_oslay has left #nmigen [#nmigen]
<_whitenotifier-3> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-3> [YoWASP/yosys] whitequark c8d8a05 - Update dependencies.
emeb has left #nmigen [#nmigen]
<d1b2> <TiltMeSenpai> are switch statements match first or match last
<d1b2> <emeb> redundant matches are allowed?
<d1b2> <TiltMeSenpai> like I want to match against 0b01--, but 0b0100 is a special case, what goes first
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 240 seconds]
<awygle> It's first match wins
<awygle> TiltMeSenpai
<d1b2> <TiltMeSenpai> oh cool
Yehowshua has joined #nmigen
<Yehowshua> I do confirm that nextPNR and yosys work on the ARM pinebook pro for Xilinx Basys AC7
<Yehowshua> Is that a first?
jaseg has quit [Ping timeout: 244 seconds]
jaseg has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
Yehowshua has quit [Ping timeout: 245 seconds]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
emeb_mac has quit [Ping timeout: 265 seconds]
emeb_mac has joined #nmigen
alexhw has quit [Remote host closed the connection]
Lord_Nightmare2 has joined #nmigen
Lord_Nightmare has quit [Ping timeout: 265 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
hitomi2507 has joined #nmigen
jeanthom has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
zignig has quit [Remote host closed the connection]
lkcl__ has joined #nmigen
Asu has joined #nmigen
lkcl_ has quit [Ping timeout: 246 seconds]
nelgau has quit [Remote host closed the connection]
nelgau has joined #nmigen
awe00 has joined #nmigen
<d1b2> <EmilJ> Aren't there two parts to that? 1: toolchain tested on whatever ARM core the pinebook has, 2: toolchain tested with whatever artix-7 part your board has (couldn't Google basys ac7) as target
awe00_ has quit [Ping timeout: 240 seconds]
nelgau has quit [Remote host closed the connection]
nelgau has joined #nmigen
<DaKnig> Yehowshua : now for the big challenge :) try that on the pinephone
<DaKnig> "program your FPGA anywhere, anytime!"
<DaKnig> @EmilJ: its just a novelty
jeanthom has quit [Ping timeout: 246 seconds]
alexhw has joined #nmigen
alexhw has quit [Remote host closed the connection]
alexhw has joined #nmigen
Yehowshua has joined #nmigen
<Yehowshua> d1b2 Emily, ur right, meant basys3 artix 7
<Yehowshua> typo. ac7 is a ocmpletely different xilinx fpga
<Yehowshua> DaKnig, could try a pinephone, although I think I'll try it on my PowerbookG4 first
<Yehowshua> Building Yosys on that thing took an entire day
<Yehowshua> Which probably means building nextPNR will take the better part of the weekend
Yehowshua has quit [Remote host closed the connection]
emeb has joined #nmigen
nelgau has quit [Remote host closed the connection]
nelgau has joined #nmigen
awe00_ has joined #nmigen
awe00 has quit [Ping timeout: 264 seconds]
jeanthom has joined #nmigen
nelgau has quit [Ping timeout: 240 seconds]
<d1b2> <EmilJ> > Emily lul
XgF has joined #nmigen
<DaKnig> is there an easy way to extract the hierarchy of the Modules in a given directory?
<DaKnig> I tried making a python script that does that; gave up.
XgF has quit [Quit: - Chat comfortably. Anywhere.]
XgF has joined #nmigen
XgF has quit [Client Quit]
XgF has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 258 seconds]
awe00_ has quit [Ping timeout: 256 seconds]
hitomi2507 has quit [Quit: Nettalk6 -]
awe00_ has joined #nmigen
awe00_ has quit [Ping timeout: 256 seconds]
emeb has quit [Ping timeout: 256 seconds]
emeb has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<moony> how do Records and Layouts work?
<TiltMeSenpai> what do you mean by how do Records and Layouts work
<lkcl_> moony: you create a list of tuples, [("name", length), ("name2", length2)], pass that in to a Record, and you get an object back which has fields obj.name2 etc. as Signals
<lkcl_> you can then either do or you can do obj.eq(something)
<lkcl_> here's an example of a function that creates a Record layout;a=blob;f=src/soc/minerva/;hb=HEAD#l17
<lkcl_> then at line 39 in that same file you can see it being used
<moony> TiltMeSenpai: Yes, it turns out it's hard to read.
<lkcl_> to create a wisnbone bus, self.bus
<TiltMeSenpai> do you have a specific question?
<lkcl_> moony: note that e.g. at line 23 there's an entry in the list for "adr"?
<lkcl_> and at line 66 this is why it is then possible to do "self.bus.adr" because that list containing the layout created a Signal, of the required width, named "adr" in the Record "bus".
<lkcl_> there's not much to overthink, here :)
<lkcl_> moony: think of it like a way to construct a python class.
<moony> I understand it now
<moony> just didn't know how to build a Layout
<lkcl_> there's 2 "versions" of the tuple entries. one is only 2 long ("name", length)
<lkcl_> the other is 3 long and you can specify the direction.
<lkcl_> for anything with a direction like that you have to use Record.connect()
<lkcl_> which tests the direction and wires them up with thing.eq(record.thing) or record.thing.eq(thing) depending on whether it's a FANIN or FANOUT
<lkcl_> but, butbutbut, do bear in mind that Record is to be superceded within a few months [by something that does the same job]
<lkcl_> if you really _really_ want to use Record after that, you'll need to take a copy of
<TiltMeSenpai> is it going away or just getting another class that does a better job
<lkcl_> TiltMeSenpai: both.
<TiltMeSenpai> wait are Records not an omigen thing?
<lkcl_> i don't know what omigen is, apologies
<lkcl_> i've heard it mentioned
<TiltMeSenpai> old migen, opposed to nmigen, which is new migen
<lkcl_> ah ok
<TiltMeSenpai> well, omigen = migen
<lkcl_> - looks like it supports Record, yes
<TiltMeSenpai> I was under the impression that wq didn't want to break omigen compatibility, but I may be wrong there
<lkcl_> i don't know, there, i've not seen that discussed. it's a good question, one that should be raised on the relevant nmigen issue
<TiltMeSenpai> idk, I haven't used omigen, so I don't particularly care, I just found that surprising
<TiltMeSenpai> well, maybe "I don't particularly care" isn't phrased the best but
<lkcl_> i know what you mean - "somebody" might
<lkcl_> well... they could always take a copy of as well.
<TiltMeSenpai> is it #342?
<lkcl_> my guess is however that if it's important to wq, she'll migrate the migen compatibility layer to the replacement for Record.
<lkcl_> TiltMeSenpai: is related
<TiltMeSenpai> idk maybe I'm just being lazy but I'll chip in if Record doesn't get a compat layer when there's actual code :P
<TiltMeSenpai> by "maybe I'm being lazy" I mean "I'm being lazy"
<lkcl_> TiltMeSenpai: there's so much code in libresoc that depends on Record, that we'll almost certainly have to copy it to nmutil (the general-purpose nmigen utility library) for some time
<TiltMeSenpai> maybe on Monday it would be worth figuring out copying to nmigen.compat vs writing an equivalent api to whatever supersedes it? idk
<TiltMeSenpai> I have no clue what Record is being used for to begin with, so no real expertise to add here
<moony> what's a good way to estimate the space on an FPGA some portion of my design will take? Black boxes (and if black boxes, how do I make them :P)
<moony> ?
<lkcl_> moony: have you got some code already?
<moony> yes
<lkcl_> ok then generate an ilang file
<lkcl_> import it into yosys
<lkcl_> then run "proc" and "synth_ecp5"
<moony> won't it just get optimized away
<lkcl_> (or, whatever command represents the FPGA you have)
<lkcl_> the last part of the output shows the actual number of LUT4s, etc. etc. etc. needed
<lkcl_> so you don't need to estimate
<lkcl_> mmm oh i see, sub-portions. then write a short routine to output just that class to an ilang file
Asu has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
<awygle> TiltMeSenpai: yes, we would migrate the nmigen.compat version of Record to be based on top of the Record replacements we're discussing
<TiltMeSenpai> ok, cool
<awygle> moony: you can do synthesis with Yosys and out-of-context placement/routing with nextpnr, if you're on an ecp5
<moony> out-of-context?
* moony looks at how to enable that
<awygle> it's a command line arg
<awygle> it's experimental so sometimes it breaks, but it's worked reasonably well for me
<awygle> oh you want to use it with `--placer sa` as well
<moony> huh, good to know
<moony> mk
<awygle> the HeAP placer gets a singular matrix and explodes
<moony> also, just an odd little thing
<moony> but whenever I build a design for the ULX3S_85F_Platform platform, it always shows up as a 45F in nextpnr
<awygle> is that in nmigen_boards?
<moony> mhm
<TiltMeSenpai> can you flash the bitstream?
<awygle> yes it is
<moony> TiltMeSenpai: I don't have the board yet, I've only been using it as a way to see how big a design comes out
<moony> so I can't check for you, sorry
<TiltMeSenpai> ah
<awygle> hm that really should work
<moony> awygle: --out-of-context presumably works, but I'm assuming yosys is optimizing away the block
<TiltMeSenpai> hmm nmigen-boards suggests it should be an 85F part
<TiltMeSenpai> idk maybe you'll have to wait until you get one or ask someone to try flashing a bitstream
<awygle> yeah, it looks correct to me
<TiltMeSenpai> if nextpnr really thinks it's a 45F, you'll get an IDCODE mismatch
<awygle> don't have advice other than "make sure everything's up to date"
<moony> forcing nextpnr-ecp5 to use the 85k with --85k does work
<awygle> you're just calling, right?
<moony> mhm
<moony> oh i see
<moony> i forgot to specify some files to the manual nextpnr call
<awygle> as for optimization my yosys command line is `yosys -f verilog -b json -p synth_ecp5 -abc9 -o out.json <filepath>` and that works for me
<moony> my fault, again
<awygle> ah ok
<awygle> if you'd like i can share the script i'm using to do this from within nmigen/python
<moony> sure
<moony> is there, maybe, some sort of black-box i should be using?
<TiltMeSenpai> moony: in the generated SVF, there should be some lines that look like `SDR 32 TDI (00000000)` around line 10, what's the TDO that follows that?
<TiltMeSenpai> (this is where the IDCODE gets checked)
<moony> TiltMeSenpai: I just said, i forgot to actually include some files with the nextpnr call. My bad.
<d1b2> <TiltMeSenpai> ah, ok
<TiltMeSenpai> I thought you were talking about the out of context place, not the device type, sorry
<awygle> you should probably not use the _toolchain imports and just do popen stuff, since _toolchain isn't public
<whitequark> awygle: re nmigen.compat Records, that is actually definitely not the case
<whitequark> nmigen.compat Record, right now, is a completely separate entity, and I don't see how it could be migrated
<awygle> ah OK my bad
<awygle> I knew we'd preserve the functionality, shouldn't have assumed the mechanism.
pdp7 has quit []
<moony> how do a platform's Connectors work?
<moony> i.e. how do I use them
<DaKnig> notice the examples in examples/board
<DaKnig> you basically `platform.request()` then
<DaKnig> them
<moony> i see how that works for other things
<moony> but I can't seem to get requesting a Connector to work at all. Say I wanted 1+, how would I request it?
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<moony> also, is it just me or does it look like someone made a copy-paste error for a lot of the connectors
cr1901_modern has quit [Client Quit]
cr1901_modern has joined #nmigen
<DaKnig> try something like `platform.request("gpio",0)["1+"]`
<DaKnig> not sure about the ["1+"] part, but that's how you request a connector
<moony> doesn't work, resource doesn't exist
<DaKnig> I just recently had to fix up the board file on nmigen-boards, so there's a high chance it happened to you too :)
<whitequark> you can't request a connector at all
<whitequark> you can only request a resource
<DaKnig> oh?
<DaKnig> why?
<moony> filing an issue, then, as not all the diff pairs even have a resource, and there's a copy-paste error
<_whitenotifier-3> [nmigen-boards] moonheart08 opened issue #108: ULX3S IO is screwy -
<DaKnig> > issue < why not just fix it for yourself, test, pr?
<DaKnig> :)
<whitequark> ulx3s was contributed by someone else and none of the maintainers, AFAIK, have one
<moony> DaKnig: I don't have a ULX3S :P
<whitequark> so unless you track down the original contributor your best bet is fixing it yourself
<moony> I'm only using the board's platform rn in prep to get one
<moony> i can fix it myself when I get the board
<moony> anyway, so I can't use connectors at all?
<whitequark> you can
<whitequark> you need to add a resource that uses the connector
<awygle> the contributor was ktemkin I believe
<whitequark> resources describe interfaces of ICs, like the IO of an SPI flash
<DaKnig> moony: you can always look at the schematics
<whitequark> so they have subsignals, directions, and so on
<whitequark> connectors, by themselves, don't have those, with rare exceptions
<moony> I can't test though.
<whitequark> a pmod connector doesn't have inputs or outputs, a pmod extension board does
<moony> I'll fix the obvious issues at least
emeb_mac has joined #nmigen
lkcl__ has joined #nmigen
<moony> whitequark: There's a total of 27 diff pairs, so presumably it's OK if I generate them from the GPIO list instead of typing them out by hand? :p
<whitequark> moony: I don't know why are there gpio_diff resources and I don't really think there should be
<moony> mk
lkcl_ has quit [Ping timeout: 265 seconds]
pdp7 has joined #nmigen
Asu has quit [Remote host closed the connection]
<DaKnig> what happens when you assign short signed signals to longer unsigned signals?
<DaKnig> sign extend?
<DaKnig> I mean current behavior
<DaKnig> `Signal(3).eq(Signal(signed(1))`
jeanthom has joined #nmigen
<Lofty> It gets sign extended, since the signal there is signed
Yehowshua has joined #nmigen
<Yehowshua> whitequark, its seems `from nmigen.sim.pysim import Simulator` has now become `from nmigen.sim.core import Simulator`
<whitequark> `from nmigen.sim import Simulator`
<whitequark> that's what the deprecation warning recommends now
<whitequark> but yes
<whitequark> since `nmigen.sim.pysim.Simulator` has never appeared in a release I just changed it
<Yehowshua> ah ok
<Yehowshua> I think that was in some tutorial somewhere
<Yehowshua> Just pulled from master and `nmigen.sim.pysim.Simulator` doesn't give a deprecation warning
<Yehowshua> Not sure its a big deal, just something to note
<awygle> i think the deprecation warning is on nmigen.back.pysim?
<Yehowshua> Yup!
<Yehowshua> you're right
<DaKnig> how would I get more than one port for Memory?
<Yehowshua> just request another
<Lofty> Just call that port again
<whitequark> Yehowshua: `nmigen.sim.pysim.Simulator` is just gone, since it was never in a release
<Lofty> rd0 = mem.read_port(); rd1 = mem.read_port()
<Yehowshua> self.read_port1 = ReadPort(self.addr_shape, self.data_shape) self.read_port2 = ReadPort(self.addr_shape, self.data_shape)
<whitequark> the manual specifically warns about this case (
<Yehowshua> You linked to installing-nmigen?
<whitequark> yes
<Yehowshua> I'm not quite following, warns about the case of pysim? or more generally changing API?
<whitequark> any API that has not appeared in a release may change in any way whatsoever without warning
<whitequark> which is why using the latest release is generally a good idea, unless you are prepared to deal with this
<Yehowshua> I intentionally try out new features. I'm just curious about whats coming and leaving and the rationale behind it sometimes
<whitequark> ah right
<whitequark> the message for commit b65e11f38fcc5efe1ae4cad5e37e2121f863737e explains this change
<Yehowshua> Also, I think I know why FHDLTestCase became so popular
<Yehowshua> That video series from Baruch, he made extensive use of formal
<whitequark> oh :/
<Yehowshua> Although he suggest to make your own sby file, but it doesn't take long to find FHDLTestCase haha
<whitequark> oh so he *doesn't* suggest to use it
<whitequark> that's a relief
<awygle> i think FHDLTestCase became popular mostly because going through all the sby rigamarole manually is hugely irritating
<jeanthom> i think FHDLTestCase became popular because nMigen was "advertised" on Twitter as having first-class support for formal verification, and the only examples of formal in nMigen were FHDLTestCase-based so people thought it was the normal way to do it
<whitequark> oh
<whitequark> yeah, those all seem true
<whitequark> that's not what i meant by "first-class support" but... that's entirely on me
<Yehowshua> whitequark, I mentioned before that I like to run right after one another
<Yehowshua> But, sync_process, yields Tick() before starting
<Yehowshua> So you get an extra cycle in between every subsequent ``
<whitequark> yeah
<Yehowshua> So I end up doing `sim.add_process` and manually adding `yield Tick()`
<Yehowshua> Which is usually fine, except in multi-domain simulations
<whitequark> you can do Tick("domain")
<Yehowshua> I have to remember to change `domain=` for Tick
<Yehowshua> If add_sync_process had some option like `prime=False`, that would solve those pain points
<whitequark> nope, not going to happen
<whitequark> add_sync_process isn't designed for testbenches in first place
<Yehowshua> Hmm, what do you have in mind?
<whitequark> instead of piling more and more options on top of a fundamentally flawed interface this is going to wait until #228 is done
Yehowshua has quit [Remote host closed the connection]
Yehowshua has joined #nmigen
<whitequark> it's not "priming" of any kind, anyway
<whitequark> the idea behind the existence of add_sync_process is that you can use it to replace a bunch of synchronous logic with behavioral Python
<whitequark> in that case, not having the initial Tick() is just incorrect
* awygle resets "days since I last clicked an issue reference and had my irc client open a useless channel" counter
<whitequark> ouch
<whitequark> we should get a bot here that expands github issue links or something
<awygle> I do this constantly lol
<Yehowshua> whitequark, I see
<Yehowshua> Do you see a path where running smaller benches in succession becomes more natural?
<Yehowshua> I know its not really intended to do that at the moment
<whitequark> sure, seems something that's reasonable to support, especially with the startup latency of cxxsim
<awygle> I +1 the use case
<awygle> Although my motives are somewhat ulterior
<awygle> Fuck, the sun is bright, I forgot
<Yehowshua> Vampire troubles?
<awygle> Quarantine + "it rains a lot here"
<Yehowshua> Oddly enough, quarantine changed almost nothing for me
<Yehowshua> 14 hours a day in a basement in front of a computer
<Yehowshua> whitequark, perused #228. Are there a lot of people using oMigen in nMigen?
<whitequark> I'm not sure
<whitequark> the nmigen.compat simulator interface will stay
<Yehowshua> Anyways, getting the simulation interface right is clearly not trivial
<Yehowshua> Theres a lot to think about
<Yehowshua> awygle, why did you want support for succession of testbenches?
jeanthom has quit [Ping timeout: 256 seconds]
<awygle> I have dreams of a responsive graphical simulator
<Yehowshua> Like that?
<Yehowshua> I used to have support for d3 js too
<Yehowshua> But that got too hairy
<Yehowshua> It used to do that
<awygle> Similar yeah. Cool! I'll look into it more when I can
<whitequark> awygle: do you want something like a checkpoint/restart system?
<awygle> Probably someday. Dunno really. Haven't had time to design it.
<Yehowshua> whitequark, thing I will point out is i had a `visual_sim.run_sync`
<Yehowshua> The logic behind that is hairy
<Yehowshua> Maybe something in nMigen to make that simpler
<Yehowshua> No idea how that would work
<whitequark> mhm
<whitequark> I think it's possible to have something like that in the core simulator
<whitequark> it's not trivial, sure
<Yehowshua> Yeah
<Yehowshua> Next level stuff
<awygle> If I had a python package for a non VCD Waveform format would that need core nmigen intervention to use with pysim/cxxsim
<whitequark> yes
<Yehowshua> hmm, are you think that could be the consumed by your hypothetical GUI?
<whitequark> well
<whitequark> you could do it without core nmigen intervention (or with minimal intervention), but with cxxsim it will be incredibly slow
<awygle> hmm
Yehowshua has quit [Remote host closed the connection]
<whitequark> awygle: the pysim engine has (or rather used to had, i removed it for uninteresting reasons) an internal abstract interface for waveform writers
<whitequark> we could bring that back and make it public if there's lots of interest
<whitequark> the cxxsim engine does not, and cannot
<whitequark> in its model, every new waveform writer is implemented on the C++ side so you don't nullify the performance advantage by doing lots of roundtrips through ctypes
<whitequark> awygle: can you take a look at ValueCastable etc?
<whitequark> other than the two cxxsim bugs currently in the milestone, that's the only things that block 0.3 release
<whitequark> (that said, the cxxsim bugs will take a while to fix; it requires a new C++ module, a new C API, new bindings, etc)
<awygle> i see, i see, and yeah
<awygle> i have been drowning in work lately, ValueCastable is #3-ish on my list to do this weekend though.
emeb has quit [Quit: Leaving.]