ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each 1st & 3rd Monday at 1800 UTC
_whitelogger has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
futarisIRCcloud has joined #nmigen
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
proteus-guy has quit [Ping timeout: 258 seconds]
<_whitenotifier-f> [nmigen-boards] trabucayre opened pull request #68: machXO3_sk: fix platform name -
hitomi2500 has joined #nmigen
_whitelogger has joined #nmigen
jeanthom has joined #nmigen
Asu has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Read error: Connection reset by peer]
<zignig> whitequark: is yowasp going to be a wasm blob for building gateware ?
<zignig> *blobii
Asuu has quit [Read error: Connection reset by peer]
Asu has joined #nmigen
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
Asu has quit [Read error: Connection reset by peer]
Asu has joined #nmigen
<_whitenotifier-f> [nmigen-boards] alanvgreen opened pull request #69: icebreaker: fix UART flow control pins. -
<_whitenotifier-f> [nmigen-boards] alanvgreen commented on pull request #69: icebreaker: fix UART flow control pins. -
<_whitenotifier-f> [nmigen] alanvgreen opened issue #409: _yosys fails to parse Yosys version from fomu-toolchain -
<zignig> whitequark: would it be possible to set up yowasp as a server that has all the wasm blobs to run and serves them on demand ?
<zignig> set up one and serve blog to those in need.
<_whitenotifier-f> [nmigen] jeanthom opened pull request #410: Replace pnmainc with diamondc -
<_whitenotifier-f> [nmigen] codecov[bot] commented on pull request #410: Replace pnmainc with diamondc -
<_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #410: Replace pnmainc with diamondc -
<_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #410: Replace pnmainc with diamondc -
<_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #410: Replace pnmainc with diamondc -
<_whitenotifier-f> [nmigen] cr1901 commented on pull request #410: Replace pnmainc with diamondc -
<_whitenotifier-f> [nmigen] cr1901 edited a comment on pull request #410: Replace pnmainc with diamondc -
<zignig> whitequark: i am trying to build a widget and I am having some trouble, I am trying to attach to pty to a cxxrtl sim.
<zignig> what would take me weeks , you would be able to do in 15 minutes, how do I attach this to two AsyncFIFO is a sim ?
<FL4SHK> how do I instantiate an Elaboratable from inside of another Elaboratable?
<FL4SHK> and how do I connect the ports?
<_whitenotifier-f> [nmigen] jeanthom commented on pull request #410: Replace pnmainc with diamondc -
<_whitenotifier-f> [nmigen] jeanthom closed pull request #410: Replace pnmainc with diamondc -
<FL4SHK> my guess is now that it's via m.submodules.whatever = ...
<vup> FL4SHK: take this as a basic example:
<FL4SHK> seems I was correct!
<FL4SHK> I found the "m.submodules" thing within an example of "Instance"
<FL4SHK> so, you drive pins by just simple `.eq`
<FL4SHK> that's what my guess was.
<_whitenotifier-f> [nmigen] whitequark commented on issue #409: _yosys fails to parse Yosys version from fomu-toolchain -
<whitequark> zignig: it'd just be on pypi
<FL4SHK> this fails
<FL4SHK> File "/media/other_data/fl4shk_home_stuff/Documents/programming_and_electronics/electronics/nmigen/small_projects_and_tests/vga_test/src/", line 47, in __elab_build_pll100
<FL4SHK> self.platform().add_clock_constraint(m.d.clk100.clk, 100)
<FL4SHK> AttributeError: '_ModuleBuilderDomain' object has no attribute 'clk'
<FL4SHK> hopefully three lines of paste isn't a problem...
<vup> FL4SHK: to get the clock signal you should use ClockSignal("domain_name")
<vup> and for add_clock_constraint the easiest would be to constrain the signal actually driving the ClockSignal (because you cant use ClockSignal with add_clock_constraint)
<FL4SHK> vup: how do I map a `Signal` to a clock domain?
<vup> can you elaborate? I am not sure I get your question
<FL4SHK> so there's going to be some kind of `Signal` that I'd use for an `always @(posedge clk)` if this were Verilog
<vup> FL4SHK: this is basically what ClockSignal is doing
<Lofty> But nmigen has sync which is effectivelyequivalent
<FL4SHK> I have two clock signals
<FL4SHK> I'm creating a second one with a PLL
<FL4SHK> I wish to use the PLL primarily
<vup> sure
<Lofty> What are the two clock frequencies?
<FL4SHK> 50 and 100
<FL4SHK> that's not the issue I've got. I had Quartus generate the Verilog code for a PLL.
<vup> you should create a new ClockDomain("domain_name") add it to and then you can use m.d.domain_name += stmt instead of m.d.sync += stmt
<Lofty> In that case, I think you should use `DomainRenamer` to rename the `sync` domain to your 100MHz PLL
<vup> right DomainRenamer is the other option
<FL4SHK> Lofty: what about the general case
<FL4SHK> vup: I need to tell Quartus about the constraints
<Lofty> The general case is
<FL4SHK> I tried ``
<vup> to actually drive a ClockDomain you can just assign the pll output to ClockSignal("domain_name")
<FL4SHK> it doesn't work, either
<FL4SHK> oh
<FL4SHK> via maybe `m.d.comb`?
<Lofty> You assign the domain to and then use it as m.d.pll100
<vup> FL4SHK: yes something like m.d.comb += ClockSignal("pll100").eq(pll.output_clock)
<Lofty> While has its uses, I really feel like using it is an antipattern
<vup> Lofty: well not everything can live with just a single clock domain, especially things like gearboxes, io serdes and stuff like that
<Lofty> And that's why I said it has its uses
<whitequark> huh? how can it possibly be an antipattern?
<whitequark> this is like saying "variable declaration is an antipattern"
<Lofty> Unintentional CDC
<whitequark> ` +=` binds a name, `m.d.<domain> +=` uses a name
<whitequark> unintentional CDC is far more likely when no explicit domains are involved at all
<whitequark> usually you'll get it with async inputs
<FL4SHK> finally got it
<whitequark> or to a lesser extent async outputs
<whitequark> FL4SHK: what helped?
<FL4SHK> using a separate signal for the output of the PLL
<FL4SHK> then using `m.d.comb += ClockSignal("pll100").eq(pll.output_clock)`
<whitequark> oh, yeah, that works fine
<whitequark> another option is to do something like...
<whitequark> ` = pll100 = ClockDomain("pll100")`
<whitequark> then
<whitequark> `Instance("altera_pll", whatever, o_clk=pll100.clk)`
<whitequark> then
<whitequark> `platform.add_clock_constraint(pll100.clk, ...)`
<whitequark> for a `domain`, the `domain.clk` field contains a perfectly normal signal
<vup> whitequark: btw is there a reason you can't use ClockSignal in add_clock_constraint?
<FL4SHK> yay, my example works
<FL4SHK> I am driving four LEDs with a counter running at 50 MHz, and another four with a counter running at 100 MHz
<whitequark> vup: yes; a ClockSignal is meaningful only in the context of a specific module
<whitequark> there's currently no way to bind it to such a context though
<whitequark> we should probably fix it some day
<vup> I see
<whitequark> for now i'm fine with it as a limitation
<vup> sure, its easy to work around it, it just feels a bit strange, as ClockSignal otherwise feels like a normal signal
<whitequark> it's very much not
<whitequark> another issue with it is passing the ClockSignal to a different module
<vup> yes, which is why i say, it feels like one (atleast in my usecases)
<whitequark> right, makes sense
<vup> also another add_clock_constraint question, is there a deeper reason why one can't pass slices to it, or is it something planned in the future aswell?
<whitequark> slices?
<vup> platform.add_clock_constraint(a[3], frequency)
<whitequark> ah
<whitequark> so the problem is that the constraint has to be applied when invoking the backend
<whitequark> and it's not clear if all backends even *support* what you want
<vup> ah hmm too bad (would be useful for example when dealing with the PS7 instance on zynq, as it passes in 4 clocks as a 4 bit Signal)
<whitequark> you could try making a case for it by going through all supported toolchains (quartus, diamond, ise, vivado, nextpnr-{ice40,ecp5}) and making sure they allow expressing that in constraints
<vup> ok, I might look into it
<_whitenotifier-f> [nmigen-boards] whitequark closed pull request #68: machXO3_sk: fix platform name -
<_whitenotifier-f> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [nmigen/nmigen-boards] trabucayre 8c105d8 - machXO3_sk: fix platform name
<_whitenotifier-f> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+1/-1/±0]
<_whitenotifier-f> [nmigen/nmigen-boards] whitequark 8018f05 - {machXO3_sk→machxo3_sk}: follow naming conventions
<_whitenotifier-f> [nmigen-boards] whitequark commented on pull request #69: icebreaker: fix UART flow control pins. -
chipmuenk has joined #nmigen
<_whitenotifier-f> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [nmigen/nmigen-boards] whitequark a889afe - resources: allow UARTResource without control signals to have no role.
<_whitenotifier-f> [nmigen-boards] whitequark commented on pull request #69: icebreaker: fix UART flow control pins. -
<_whitenotifier-f> [nmigen-boards] whitequark closed pull request #69: icebreaker: fix UART flow control pins. -
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
jeanthom has quit [Ping timeout: 240 seconds]
proteus-guy has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
hitomi2500 has quit [Quit: Nettalk6 -]
<awygle> whitequark: bikeshed, how would you feel about adding an optional file argument to Instance (assuming this was possible for the moment)?
<awygle> We get that question a lot it seems, including from *checks notes* me
lkcl_ has joined #nmigen
<FL4SHK> awygle: that seems like a good idea to me
lkcl__ has quit [Ping timeout: 265 seconds]
<FL4SHK> mainly because otherwise you have to add it to the platform or something
<awygle> adding it to the platform is still required to be supported, i think, for more advanced use cases. but if it's possible having a shortcut way to do that as part of the Instance constructor may be valuable.
<awygle> on the other hand if it's not going to work in the common cases, it may cause more confusion than is necessary, which i'm sure wq has thought about
<whitequark> awygle: there are two main issues i can think of
<whitequark> 1. so far, i've tried to keep the core language separate from the platform stuff. so you don't have to use the platform stuff at all, or you could reinvent your own platform, or something like that
<whitequark> meaning that if there is a file argument, it's going to be an alias for platform.add_file but like with more steps
<whitequark> 2. the current add_file interface is basically a proof of concept
<whitequark> it doesn't let you set verilog definitions, it doesn't let you control file ordering (important because of verilog definitions) and so on
<whitequark> extending Instance in any straightfordward way will double these problem
<whitequark> *problems
<awygle> mk, makes sense
<whitequark> what problem does it solve?
<awygle> it doesn't solve any problem per se, it's just that that seems to be a common stumbling block for beginners
<whitequark> right, yeah
<awygle> and verilog etc interop is a pretty core use case for nmigen imo
<whitequark> there should be an entire section on verilog interop
<whitequark> in the docs
<awygle> so i thought i'd ask the question
<awygle> also this has led me to another question which is "how can i do cosimulation since simulator has no platform" but i'm pretty sure that's already an issue that's been filed
<awygle> and iirc you had Plans
<whitequark> yeah #113
* awygle suddenly remembers getting pinged about an issue yesterday or the day before
<whitequark> for cosimulation i think what i'll do is introduce a "generic platform"
<whitequark> won't have registered IO, will use plain inout for tristates
<awygle> oh it's a PR that's why i couldn't find it
<whitequark> this is also helpful for other reasons, like people trying to target efinix or quicklogic or other families not supported directly
<awygle> mhm
<awygle> i like the idea of a generic platform
<whitequark> basically the same thing as migen did if you didn't customize the platform
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
<awygle> re: #369 - i haven't worked on this at all since we last talked about it, life has been busy. i am back to a more normal cadence now and my nmigen-related priorities are 1) finish the ILA stuff i was doing 2) finish #369 and #368 (and the pre-req mentioned there) 3) back to my funtimes FSM stuff
<whitequark> ack
<whitequark> so i'm interested in FSM stuff but records and streams are higher priority
<awygle> i agree with that, but i have a prototype stream thingy i'm already using, and i need (well, would really like) better FSMs for my DDR2 controller project
<awygle> and last time we talked about streams you weren't ready to dig in on them
<awygle> so i've been working on a prototype FSM (HSM, statechart) implementation for use in that project, and figured someday you'd be ready to dig in on FSMs too, some time after the date where we did detailed work on streams
<whitequark> yep, sounds reasonable
<awygle> what's your list looking like? (understanding that it's subject to change for any number of reasons)
jeanthom has joined #nmigen
<whitequark> it's pretty stable actually
<whitequark> - ship cxxsim
<whitequark> - release 0.3
<whitequark> - ship the first approximation of docs
<whitequark> - fix records
<whitequark> - ship streams
<whitequark> - ship FSMs
<whitequark> somewhere after the streams there will be more stdio work, and somewhere after 0.3 there will be more SoC work
<awygle> huh, SoC before Streams/Stdio?
<awygle> anyway that doesn't sound surprising, pretty much what i figured you were working on
<awygle> i have some "how do i live alone again?" type chores to do the next couple days but probably i'll be spending my evenings on nmigen stuff starting approx. wednesday. it will be competed with only by monster hunter world.
<whitequark> cool, thank you
<whitequark> SoC has been unfairly neglected for some time, let's fix that
<whitequark> there is some low-hanging fruit even before streams go into action
<tpw_rules> i had a really dumb idea for a reimagining of FSMs which i'm calling "task machines". each state becomes a task that other tasks can enable or disable so they can pipeline. i feel like it would be very dangerous though
<tpw_rules> i also didn't think about it beyond that
<whitequark> the general direction of FSM evolution i'm thinking about is "whatever helps implementing finite state transducers"
<tpw_rules> i'll have to see if i can figure that out
<lkcl_> tpw_rules: i spent some considerable time on infrastructure that would allow combinatorial blocks to be used for either FSMs or pipelines.
<lkcl_> it was... complex.
<awygle> > open wiki article on FSTs
<awygle> ow ow my eyes, my brain, ow
<lkcl_> it was part of the conversion of jon dawson's ieee754fp code to nmigen
<tpw_rules> awygle: my thoughts precisely
<awygle> i already _know_ what an FST is even
<lkcl_> in the end i gave up and focussed on pipelines.
<awygle> it's just that of all the groups of CS people who are incapable of communicating their ideas clearly, language/automata theorists are among the incapablest
<lkcl_> tpw_rules: at one point however it did actually work
<whitequark> awygle: yes
<whitequark> i also find the terminology obnoxious
<whitequark> though i have a much better grasp of it these days
<tpw_rules> the thing i wanted to solve was like if you have an IDLE -> BUSY -> FINISH, how do you express that FINISH can transition directly to BUSY without replicating IDLE's logic in FINISH?
<awygle> lmao "Stochastic FSTs (also known as probabilistic FSTs or statistical FSTs) are presumably a form of weighted FST.[citation needed] "
<tpw_rules> "presumably" is the stochastic part
<awygle> tpw_rules: are you familiar with HSMs/statecharts?
<awygle> they solve that in a quite elegant way, imo
<awygle> that's what i've been working on implementing
<lkcl_> tpw_rules: ah that sounds slightly different from the focus of the FSM work i did.
<tpw_rules> i remember working with statecharts but not anything hierarchical
<awygle> btw if anybody in this channel can access this paper i will die grateful to you:
jeanthom has quit [Ping timeout: 260 seconds]
<tpw_rules> do you know if there's a system which would have it?
<awygle> the UC OskiCat one suggests an ebook exists
<awygle> if i still lived in california and there wasn't a pandemic i'd just go to the library and photocopy it
<tpw_rules> our ebsco-based system can't find anything that looks relevant
<awygle> if i did get a scan of it, say over my mother's birthday at the end of july, i wonder what the best way to distribute it so people could get at it would be
<awygle> just in case anyone but me ever cares
<tpw_rules> i've kind of wondered how to submit stuff to sci-hub
<tpw_rules> not sure it's possible?
<awygle> wasn't whitequark accidentally running a library at one point too? lol
<awygle> (called the whitequarchive, i assume)
<whitequark> tpw_rules: you can submit stuff to libgen
<tpw_rules> incidentally holy crap do i love sci-hub. it makes dealing with papers so much easier
chipmuenk has quit [Quit: chipmuenk]
Asu has quit [Remote host closed the connection]
<_whitenotifier-f> [nmigen] alanvgreen commented on issue #409: _yosys fails to parse Yosys version from fomu-toolchain -
<_whitenotifier-f> [nmigen] whitequark commented on issue #409: _yosys fails to parse Yosys version from fomu-toolchain -
<awygle> Augh, that reason for 2 being impossible
<awygle> the saddest thing
<whitequark> yeah, very long term we have to migrate off RTLIL
<whitequark> and this is an important reason to have Yosys on PyPI: then you can manage dependencies with `pip freeze`
nengel has quit [Ping timeout: 258 seconds]
<awygle> frrtl when
<whitequark> no longer sure about firrtl
<whitequark> I talked to Chris Lattner about it and turns out everything except LoFIRRTL is soft-deprecated
<whitequark> we do need only LoFIRRTL
<whitequark> but he was encouraging creating something *based* on LoFIRRTL moreso than using it wholesale
<whitequark> we can probably still lower to it, it's just not entirely clear exactly how much benefit it will bring over time
<awygle> mm, lame. we need _something stable_ that people can get behind
<whitequark> yep
<Lofty> The xkcd standards comic but the 3rd panel is "there are 15 buggy competing standards"
<whitequark> rtlil isn't even a standard
<awygle> what's the other one besides firrtl
<awygle> didn't one of the other projects have one?
<whitequark> I'm not sure what you mean
<awygle> there's also LNAST and its IR which i can't remember the name of
<awygle> i mean another HDL IR besides RTLIL and FIRRTL, i thought there was another one that was "popular", associated with Chisel or Spinal or one of the other nuHDL projects
<whitequark> chisel uses firrtl
<awygle> LLHD is the LNAST one
<whitequark> spinal uses uh... verilog/vhdl
<awygle> oh wait no LLHD is another thing, LNAST's IR is LGraph
<awygle> what a mess
<whitequark> oh that's super new
<whitequark> oh wow that's completely redundant
<awygle> lol
<whitequark> wait
<whitequark> why does it have stack allocation
<whitequark> does it try to do HLS?
<whitequark> >Note: It is not yet clear whether LLHD will provide alloc and free instructions to create and destroy memory slots in an infinite heap data structure.
<whitequark> OMwhy
<whitequark> *why
<awygle> idk i feel like "␛OMwhy" was what your heart really had to say
<awygle> oh wait doesn't symbiflow have an IR
<awygle> fasm or something?
<Lofty> fasm is way too low level for this
<awygle> ah, k
<awygle> literally all i know about it is "somebody tweeted 'TIL about fasm' the other day"
<mwk> fasm is not an IR, it's basically just textual bitstream format (and a bad one at that)
<cr1901_modern> It's "used" by nextpnr-generic as the final output
<whitequark> so, something i wanted to discuss
<whitequark> i'm currently writing docs (intro page, etc) for YoWASP
<whitequark> the outline i'm going with is something like: - what is it? - why is it useful? - what are limitations? (platform support etc) - how to install it? - how to use it with my tools? (eg nmigen env vars)
<whitequark> anything else i should add?
<cr1901_modern> > how to use it with my tools?
<cr1901_modern> >>How does yowasp interact with non-WASM yosys and nextpnr? Any potential gotchas?
<cr1901_modern> This might not be worth mentioning, but can't hurt
<whitequark> good topic
<whitequark> it's actually something important that i missed
<awygle> what i would want to know is something like "how can i write my code so that yowasp is used if there's no yosys/nextpnr available natively" but that may be uh... too specific
<awygle> or alternately something that everybody who is Good At Python already knows
<whitequark> this is actually kind of a hard problem i don't know how to solve yet
<whitequark> the other direction is easy
<whitequark> so
<whitequark> python lets you install "scripts" which go to ~/.local/bin usually, or in the virtualenv
<whitequark> yowasp will ship all binaries prefixed with yowasp-
<tpw_rules> wassup-yo?
<whitequark> lol
<whitequark> so normally you'd have to do something like
<whitequark> export YOSYS=yowasp-yosys NEXTPNR_ICE40=yowasp-nextpnr-ice40 ICEPACK=yowasp-icepack python3 ...
<whitequark> er, no export, or add a newline
<whitequark> which sucks.
<awygle> i genuinely had a good 30-second-long rage reaction to just the _word_ virtualenv. i should mention that to my therapist.
<whitequark> ouch.
<awygle> anyway, continue lol
<whitequark> i have that with conda
<whitequark> will it uh... help if i mention that i'm going to promote virtualenv as the primary method of managing nmigen projects in the docs
<whitequark> (because it lets you do the pip freeze thing easily)
<awygle> i mean, that sounds like exactly the right thing to do, in context
<whitequark> ok good
<awygle> it's the context i object to and that's not your fault :p
<cr1901_modern> I agree w/ awygle, rage and all. But I accept the consequences of not using venv.
* awygle realizes he may be hungry, there's no food in the house, grocery time
<whitequark> cr1901_modern: i mean you don't *have* to use venv
<whitequark> yeah
<whitequark> it's going to be optional
<cr1901_modern> Ahhh. Well if it wasn't optional, I would accept the consequences of breaking the rules anyway :)
<whitequark> this is why it's optional
<tpw_rules> how do you do it instead?
<whitequark> it's better to admit people are going to use fucky setups whatever i do
<cr1901_modern> develop and manually compile
<whitequark> and have at least some leeway for it