ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting July 27th
<d1b2> <emeb> Trying to figure out how to instantiate the Lattice up5k SB_RGBA_DRV cell in a simple nmigen design. When I do so I get this: Warning: No clocks found in design
<whitequark> can you post MCVE?
<d1b2> <emeb> sorry - n00b here. what's MCVE?
<d1b2> <emeb> I'll see if I can boil it down. I'm sure that part of the issue is my inexperience, and likely some bad stuff going on in my custom board definition.
<awygle> is this in simulation or are you trying to program the board?
<d1b2> <emeb> trying to program the board
<d1b2> <emeb> I can drive the RGB LED outs with simple definitions of those pins as resources, but then I don't get the current control that the SB_RGBA_DRV provides and the LEDs are too bright.
<agg> can you upload your example code somewhere?
<agg> you need to request the LED pins from the platform with dir="-", then connect those pins in a comb block to the RGB0/1/2 ports of the instance
<d1b2> <emeb> Aha - I was wondering about that.
<d1b2> <emeb> Here's the code in case you're still curious:
<d1b2> <emeb> two files in one paste.
<agg> in that code you set o_RGB0=rgb0 but there's no rgb0 variable
<d1b2> <emeb> yes. I had those commented out earlier
<d1b2> <emeb> for dir='-' I'm getting a warning that "-" isn't legal. should it be "io"?
<agg> you use - when requesting, not when defining in the platform
<d1b2> <emeb> ok. do the definitions need to be something other than "o" then?
<_whitenotifier-b> [nmigen] cestrauss commented on issue #439: fsm_state changes mid cycle -
<agg> haven't changed your definitions
<agg> you might find the PinsN confuses matters, not sure, but ^ seems to work, at least generates an output without complaining
<agg> i don't have an up5k board to hand to test
<d1b2> <emeb> That works - thanks for the help!
<d1b2> <emeb> Not burning out the LEDs now. 🙂
emeb has quit [Quit: Leaving.]
<_whitenotifier-b> [nmigen] BracketMaster commented on issue #439: fsm_state changes mid cycle -
<_whitenotifier-b> [nmigen] whitequark commented on issue #439: fsm_state changes mid cycle -
jock-tanner has joined #nmigen
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
samlittlewood has quit [Ping timeout: 265 seconds]
Yehowshua has joined #nmigen
<Yehowshua> In todays Masochistic explorations, got nMigen working natively in iOS shell and almost got TinyProg working as well.
<Yehowshua> It also occurs to me that since this exists
<Yehowshua> nMigen in your browser is very trivial
<whitequark> have you actually tried nmigen in brython?
<whitequark> oh, does it use emscripten?
<whitequark> fascinating
<Yehowshua> I'm actually not sure how it works.
<Yehowshua> I will mention I saw a demo of programming an Arduino from your browser in 2012 - somebody figured out how to expose ACM CDC devices to browsers - at least for Chrome
<Yehowshua> So if you get where I'm going...
<Yehowshua> nMigen+Yosys could be completely in browser in principle - not sure about nextPNR...
<whitequark> has nextpnr
<whitequark> people *really* hate webusb
<Yehowshua> Oh wow. OK - I'm putting this on my to do list
<Yehowshua> Oh? NOt surprised
samlittlewood has joined #nmigen
<Yehowshua> But programming an FPGA entirely from your browser seriously increases the visibility of nMigen.
<whitequark> i think we can eventually make something like ``
<whitequark> like Try Ruby or Try OCaml
<Yehowshua> Yeah - hec - I'll give Brython a shot tomorrow
<whitequark> it probably won't be very soon because WASM is still heavily in flux, WASI doubly so
<whitequark> i'm not sure if WASI actually works in browsers properly yet
<Yehowshua> * Yehowshua searches for his javascript helmet
<smkz> mayb have it run a simulator and waveform viewer in-browser ;;
<whitequark> smkz: simulator: easy
<whitequark> waveform viewer: there are good HDL waveform viewers?
<smkz> and some examples of nmigen gateware so people can poke around ;;
<smkz> i-i dont know
<smkz> i dont think gtkwave can run in browser
<awygle> brb writing waveform viewer in rust compiling to wasm
<Yehowshua> awygle u fo real?
<awygle> i wish
<awygle> someday
<awygle> when i have time
<Yehowshua> hahas
<Yehowshua> Do you guys have a feature list or roadmap? The whole browser thing should def be on it
<whitequark> smkz: was a rhetorical question for the most part, pretty sure there isn't
<awygle> basically just the issues on github
<whitequark> Yehowshua: i don't consider it extremely important, moreso than good docs, streams, anything
<awygle> and what lives in wq's head
<whitequark> i think it would be nice to have eventually
<whitequark> but only if the implementation is actually good and maintainable
<Yehowshua> Right with you there
<Yehowshua> Its a *nice to have*
<whitequark> *if* we can get WASI to work nicely in a browser (or I guess port nextpnr to bare emscripten), i am 100% behind having it
<Yehowshua> hmm - the waveform in JS really shouldn't be to hard
<whitequark> you'd *think* so
<Yehowshua> I'd stay away from d3 tho - its whole enter exit paradigm makes me sick
<whitequark> i stay away from modern javascript in general
<awygle> i'd do the waveform drawing almost entirely in a shader in webgl/webgpu
<whitequark> ^ also that
<Yehowshua> webgpu is still a baby tho
<whitequark> maybe Sarayan's thing would be portable to webgl
<awygle> yeah, prolly webgl first
<Yehowshua> Sarayan?
<awygle> oh is sarayan still working on that?
<awygle> haven't heard from them recently
<whitequark> no idea
<whitequark> but i assume he does
<awygle> i have a full page of notes on doing waveform rendering with shaders and deferred rendering in one of my notebooks
<whitequark> nice
<awygle> but can't really justify actually prototyping it right this second
<Yehowshua> Who is this Sarayan you speak of?
<whitequark> a person, i don't really know what to tell you
<Yehowshua> Oh I meant like a Github haha
<whitequark> (it's a nickname)
<awygle> yeah they hang out in here sometimes, they were working on a renderer thingy at one point
<whitequark> i only know the twitter,
<Yehowshua> kks
<awygle> Yehowshua: are you on the libresoc team?
<Yehowshua> Yes, I am part of libresociety
<awygle> lol
<whitequark> ha, nice name
<Yehowshua> Sorry, I know - bad puns
<awygle> na that's great actually
<Yehowshua> I didn't come up with it
<Yehowshua> Screaming Pony coined it first
<Yehowshua> Sorry - his name is/was? Scheming Pony
FFY00 has quit [Remote host closed the connection]
<Yehowshua> Well I'll give Brython a shot this week. There's always the Rust-python route too
Yehowshua has quit [Remote host closed the connection]
jaseg has quit [Ping timeout: 256 seconds]
jaseg has joined #nmigen
<awygle> hm, is the default format gtkwave uses for signals of certain bit lengths set by gtkwave or by what nmigen outputs?
<whitequark> gtkwave
<awygle> ah, k
<d1b2> <emeb> heh... the LUNA acm_serial example, tweaked to also route loopback data to the rgba_drv core on a customized up5k platform. Don't laugh too hard - it's only my 2nd day w/ nmigen.
Yehowshua has joined #nmigen
<whitequark> sounds nice!
<Yehowshua> awygle, (is your notebook online) ? send_link : please_post
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [nmigen/nmigen] whitequark 0899ff3 - compat.fhdl.bitcontainer: fix value_bits_sign().
<_whitenotifier-b> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13]
<_whitenotifier-b> [nmigen/nmigen] whitequark 2434aff - Deploying to gh-pages from @ 0899ff366b5fa7cbfb71da3e6c24bf458fae10ee 🚀
Yehowshua has quit [Remote host closed the connection]
<awygle> oh, they left. well Yehowshua if you read the scrollback, it's not digital it's paper but i'll put it up somewhere when i get a chance
<awygle> whitequark: do arrays not show up in VCDs?
<whitequark> awygle: not directly
<awygle> oh wait i think i see what's going on
<awygle> the used values from the array are getting added with generic names
<awygle> hm. what would be the best way to be able to see the full array?
<awygle> it's pretty small, only 4 rows
<whitequark> assign to some temporary signals
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
Yehowshua has joined #nmigen
<Yehowshua> Yeah, nMigen does not work in Brython since it lacks abc - Abstract Base Class
Yehowshua has quit [Remote host closed the connection]
<whitequark> abc isn't critical
<whitequark> we can patch it out
hitomi2504 has joined #nmigen
jeanthom has joined #nmigen
Asu has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
SpaceCoaster has quit [Quit: ZNC 1.7.2+deb3 -]
SpaceCoaster has joined #nmigen
<DaKnig> Im not used to switch statements outside C/++... when some case in nmigen catches multiple things, the switch becomes a priority encoder of sorts? is that right?
<DaKnig> I think I used the wrong term... I mean that it would take the first matching case, right?
<Lofty> DaKnig: it is indeed a priority decoder
<whitequark> yep
jeanthom has joined #nmigen
<_whitenotifier-b> [nmigen] The6P4C opened issue #442: Simulator with non-passive sync process and no clock added runs indefinitely without emitting a warning -
<DaKnig> whitequark you mentioned earlier that arrays in nmigen work like switch-case statements. is that the same for verilog?
<_whitenotifier-b> [nmigen] whitequark commented on issue #442: Simulator with non-passive sync process and no clock added runs indefinitely without emitting a warning -
<_whitenotifier-b> [nmigen] whitequark edited a comment on issue #442: Simulator with non-passive sync process and no clock added runs indefinitely without emitting a warning -
<_whitenotifier-b> [nmigen] whitequark commented on issue #442: Simulator with non-passive sync process and no clock added runs indefinitely without emitting a warning -
<whitequark> DaKnig: Verilog doesn't have arrays, SystemVerilog does but I don't know how they work
<DaKnig> I saw things likes this:`reg [7:0] y3 [0:1][0:3]; ` , is that systemverilog?
<whitequark> afaik yes
<daveshah> Yes, although I think multidimensional unpacked arrays like this are supported by Yosys
<daveshah> Last I checked multidimensional packed arrays (ie multiple dimensions before the variable name) aren't
<DaKnig> I am trying to make an interactive bench for testing how different parts of the lang work, but I cant dont get it.. I am trying to "simulate" something that is not synchronous, and I dont get how to add a comb bench
<DaKnig> I tried to follow the tut that uses pysim and assigns a bench function (generator) to Symulator().sync_process but it says that the attribute doesnt exist
<DaKnig> I assumed that is because I dont use the sync domain
<Lofty> DaKnig: sim.add_process()
<DaKnig> ah thanks Ill try this
<Lofty> Make sure to `yield` between writing and reading
<DaKnig> this doesnt work with comb bench apparently
<whitequark> Lofty: you need to `yield Settle()`
<DaKnig> whats that
<Lofty> I thought the wrapped in add_process did that?
<DaKnig> it waits for signals to settle on their new values?
<Lofty> *wrapper
<Lofty> And yes, DaKnig
<Lofty> Basically it's a signal to the Simulator to combinatorially propagate values
<DaKnig> Settle is not defined
<whitequark> import it from back.pysim
<DaKnig> ah yeah
<DaKnig> I should import *
* zignig discovers that actual is significantly more complicated than theory.
<zignig> again
<lkcl_> DaKnig: "import *" is, if you search on the internet, discouraged. in particular, when there are teams of people communicating (such as on the internet) when "import *" is used multiple times, the only person who knows what was imported from where is the original author.
<lkcl_> that's if they can remember
<lkcl_> explicit imports give an audit / tracking trail that allows even the developer to debug the program.
<lkcl_> there are several other reasons: you can find them by searching "python import wildcard considered harmful"
<whitequark> this doesn't generally apply to `from nmigen import *` though
<DaKnig> I know all those reason
<lkcl_> if it's the only place it's used, then the only thing that it stops is lintian tools from being able to check errors in the use of the nmigen package
<DaKnig> s
<DaKnig> Im fine with all those "scary things"
<DaKnig> nmigen does all the stuff to ensure that only the relevant parts are exported
<lkcl_> however as it's been "accepted practice" in nmigen (and migen), all nmigen developers now, very unfortunately, believe that it can be done on nmigen_soc, nmigen_boards, everything.
<whitequark> linters should just deal with glob imports, it's not actually very hard
<lkcl_> which in complex projects makes it impossible to track.
<lkcl_> it prevents detection of unused imports
<DaKnig> "best practices" or however you wanna call them are not rules.
<DaKnig> they are suggestions.
<whitequark> first, DaKnig is right
<DaKnig> follow them when it makes sense to you
<lkcl_> DaKnig: it just depends if the intention is to collaborate or not.
<lkcl_> indeed.
<whitequark> "best practices" is just how programmers call things they like when they want to sound authoritative
<lkcl_> if the code being developed is not intended to be used by anyone else, doing whatever you like and whatever suits you is perfectly fine
<DaKnig> the biggest problems come when you have many libs that all export way too much stuff for one person to thnk about
<lkcl_> however when it comes to collaboration, and other people have to use the code, these "rules" start to make sense and become much more important.
<DaKnig> this is not as bad as , say, `delete this` in C++
<whitequark> lkcl_: do not make absolute statements like that
<whitequark> just state it like it is: it is your personal preference
<lkcl_> whitequark: ok...
<lkcl_> no, it's not my "personal preference", let me think how to put it
<DaKnig> I think that there should be no absolute rules for code formatting
<_whitenotifier-b> [nmigen-boards] rroohhh opened pull request #87: fomu_pvt: fix typo -
<DaKnig> I think what you are trying to say is "common sense" or "cult practice"
<lkcl_> however when it comes to collaboration, and other people have to use the code, *i have observed and experienced over the past 20 years of working with python* that these "rules" start to make sense and become much more important.
<whitequark> yes. it is your personal preference based on your observation
<lkcl_> DaKnig: yyeah that would be a good way to put it.
<vup> whitequark: is there a reason nmigen-boards is not running tests for PRs?
<whitequark> vup: yes. for one, it doesn't have any tests
<DaKnig> I dont wanna bother with all this for a small testing script
<DaKnig> is wat I am saying...
<lkcl_> DaKnig: that absolutely makes sense.
<whitequark> vup: we should probably at least make sure all of the boards do import
<DaKnig> I do use namespaces and all that usually.
<DaKnig> when code gets large enough
<vup> whitequark: ah correct, but " test" seems to do something along these lines?
<whitequark> well
<whitequark> that's true, but it's deprecated
<vup> (thats how I am catching these typos currently)
<DaKnig> how can you test board platforms?
<DaKnig> if you dont have the hardware
<whitequark> DaKnig: well, for the ones with FOSS toolchains, you can at least run synthesis
<whitequark> for blinky
<whitequark> this doesn't test all that much more
<DaKnig> what does this test? that it spits out some bitstream?
<whitequark> vup: i guess we can add that in the meantime
<whitequark> and figure it out later
<lkcl_> i've seen many cross-platform projects run into this one. the developers don't necessarily have all hardware needed to run all tests.
<vup> whitequark: sounds good to me, I am not really an expert in python packaging / testing, if " test" is deprecated, what is supposed to replace it?
<whitequark> DaKnig: yes, that tests a few more things
<whitequark> vup: just use test for now
<lkcl_> in debian they actually refuse to add ports for which they do not have native hardware!
<miek> i've observed that trying to stick to these "rules" has hurt collaboration. spending a page or two ranting about an unrelated glob import when someone's just asking for some debugging help wasn't great..
<vup> ok
<whitequark> i very much agree with miek
<whitequark> enforce your coding standard in *your own projects*, sure
<whitequark> and keep it there
<lkcl_> miek: interesting.
<lkcl_> whitequark, miek: as i said - the problem comes when the practice propagates throughout an entire community, and large projects try to use that code.
<lkcl_> this *is* causing our project huge inconvenience.
<whitequark> deal with it
<whitequark> you do not get to have your arbitrary preferences enforced on everyone you talk to
<lkcl_> whitequark: i have to say, that's very rude of you.
<whitequark> i find your insistence on ranting about glob imports every damn time it comes up extremely rude
* zignig observes release < 1.0 , things will break , but WQ is taking the _proper_ road.
<zignig> slow and steady...
<lkcl_> i appreciate you being honest with me in saying that.
<zignig> whitequark: I have almost got my tinybx with ktempkin's usb and a Boneless-v3 running at 12Mhz.
<lkcl_> (and you, miek, for your honesty)
<whitequark> we know you think that. we already figured out that your preference is not shared by a significant proportion of people, including myself
<whitequark> it's not necessary to rehash that over and over again each time it comes up
<lkcl_> my feeling is, here, that when there is another large project that also encounters problems with this, it will be listened to.
<whitequark> the way you come off in these conversations is that you try to enforce your preference on everyone you see not sharing it
<lkcl_> nmigen development is "root level" (if you know what i mean). as in: because it's young, and because it's usually the first time that hardware engineers use python...
<lkcl_> ah. yes. this is an issue that i have: self-deprecation and leaving out "the way that i see it" (and other such phrases)
<jeanthom> >and because it's usually the first time that hardware engineers use python...
<jeanthom> ahem
<lkcl_> lack of use of personal pronouns.
<whitequark> yeah that part is pretty condescending too
* lkcl_ waves to jeanthom
<lkcl_> whitequark: it's part Asperger's, part subconscious self-deprecation
<lkcl_> it's not deliberate
<whitequark> what matters is the result
<lkcl_> indeed. most unfortunate
<DaKnig> isnt everything we people say just "what we think"?
<DaKnig> "I think ... (gravity) ... works like so"
<DaKnig> there are no facts, just things we are very convinced about... and math is a way to convince others of things
<DaKnig> ok that is offtopic
<DaKnig> I would stop.
<whitequark> DaKnig: there are also requests and demands
<lkcl_> DaKnig: well, the way that i'm saying things, by lacking personal pronouns, is being taken as "fact" when it's not that black and white
<lkcl_> which people find annoying (like jeanthom just did)
<lkcl_> anyway. yes. back to nmigen :)
<DaKnig> imo we should treat what people say as what they think/want to convey, not as facts, and therefore saying "... I think" all the time is redundant. its just words that make statements sound softer. like Im doing here.
<DaKnig> ok I should really stop. it has nothing to do with this project.
<zignig> what is the most compact way to share a Memory block between to Elaboratables?
<whitequark> zignig: you can just use it from those two, but you'll get a warning about hierarchy flattening
<zignig> I'm trying to have a ROM in one that can be rewritten by another.
<lkcl_> zignig: is it being accessed (read, written) by both blocks?
<whitequark> you can also add all of the ports in some module, but use signals of those ports in another
<zignig> whitequark: I'm trying to get LUNA's descriptors for usb as a semi-rom that the boneless can rewrite and re-enumerate.
<whitequark> oh, hm
<whitequark> for a proof of concept you can directly access that ROM, i think
<whitequark> what would be a nice clean way to do this i can't say, as i'm not familiar with LUNA
<zignig> currently it is a case list that enumerates as addresses.
<whitequark> in general, if you try to access things in nmigen in a way that cannot be expressed hierarchically, it will flatten the hierarchy and do what you want
<whitequark> (with a warning)
<whitequark> interestingly, Yosys has to be somewhat retrofit to support that, since SystemVerilog requires it
<zignig> hehe
<lkcl_> zignig: the pattern i've used is to pass in the Memory as an argument to the constructor, where i added the Memory to the *parent*
<lkcl_> constructor of both submodules
<zignig> lkcl_: it's not a parent as such , but one has veto. I think a phat mux and an interlock FSM will work.
<DaKnig> why not use that as a Module outside both parts
<DaKnig> and just connect them to it at the level above in the hierarchy?
<lkcl_> zignig: ah yes, that would work.
<zignig> i have a CPU (a really nifty one BTW), that will drop the usb interface , open a semi-rom , rewrite it and then open again.
<lkcl_> we're doing something similar in LibreSOC, using a PriorityPicker and ready/valid signalling.
<zignig> it is not a bilateral interface.
<lkcl_> anything that wants access to the (one) port sets a "Request" bit high.
<lkcl_> those "Request" bits are grouped together with Cat()
<lkcl_> they're pushed into a back-to-back Encoder-Decoder (or maybe the other way round)
<lkcl_> and in that way only one of them is ever "hot".
<lkcl_> the technique was first seen in the CDC 6600, from 1965 :)
<zignig> I was going to transit through CSR as I can bind them a Peripheral subclass (munted strip of lambda-soc).
<whitequark> we could definitely have PriorityPicker in lib.coding
<zignig> whitequark: as an arbiter ?
<lkcl_> whitequark: i remember, we discussed this... a year ago? back-to-back Encoder-Decoder creates a pmux, which doesn't get optimised out
<lkcl_> i ran a laarrrrge PriorityPicker through yosys: it was *really* well-optimised
<lkcl_> 1 sec..
<_whitenotifier-b> [nmigen-boards] rroohhh opened pull request #88: Travis: set up CI builds -
<lkcl_> there's only 3 gate-delay propagation.
<_whitenotifier-b> [nmigen-boards] rroohhh edited pull request #88: Travis: set up CI builds -
<lkcl_> zignig:;a=blob;f=src/nmutil/;hb=HEAD#l27
<lkcl_> it's quite cute. Mitch Alsup's gate-level diagram which illustrates a simple 4-in, 4-out is here:
<lkcl_> despite that being a "chain", yosys manages extremely well in optimising it down to low gate-propagation.
* lkcl_ hmm i see i missed en_o on the list of ports.
<_whitenotifier-b> [nmigen-boards] whitequark closed pull request #87: fomu_pvt: fix typo -
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [nmigen/nmigen-boards] rroohhh 194b760 - fomu_pvt: fix typo
* zignig is tired
<lkcl_> zignig: what timezone are you in?
<zignig> I am going to stop before I enter crazy mode.
<lkcl_> zignig: lol
<zignig> lkcl_: GMT+8
<zignig> perth au.
<lkcl_> my partner is just calling someone in TW (GMT+8)
<zignig> TW !!? , watch out for swirly things !! ( in la nina )
<zignig> anyway , crazy mode active, gnite all.
<lkcl_> zignig: night
<DaKnig> I am translating some VHDL code, and theres a big case (equivalent of switch) statement, that only assigns to one signal and has a "default" case. what would be the way to do this in nmigen? I dont think switch would be ideal- for one, its very long (in the original too)
<DaKnig> is there something like the rust swithc, that returns a value?
<DaKnig> ah wait its called Memory lol
<DaKnig> nevermind me
<lkcl_> DaKnig: :)
<jeanthom> DaKnig, you could use an Array
<DaKnig> I think Memory would be more efficient- wouldnt you agree?
<lkcl_> whitequark mentioned yesterday that Array is equivalent to a sort-of Switch statement
<DaKnig> I am p sure he means a Mux
<DaKnig> because thats what Switch statements are
<lkcl_> one thing that Mitch Alsup taught me is the gate-level efficiency of using unary-encoding vs binary-encoding.
<lkcl_> DaKnig: how big a vhdl switch statement is it? 30 entries? 300?
<DaKnig> 32
<lkcl_> and are the case statements single-bit (one-hot)?
<DaKnig> no
<lkcl_> case ("0b0001") case ("0b0010")
<lkcl_> ok
<DaKnig> and I am not sure that would help much here
<DaKnig> one hot is great when you have to do some kinda logic "if (somehting)"
<lkcl_> if you _can_ make them single-bit, then the test-logic is.. well... one AND gate. or because it's 32 entries, that would be 32 AND gates
<DaKnig> it would have been useful here if I could use 3rd state stuff
<DaKnig> but nah
<lkcl_> however if you use a Switch statement or Memory, it'll be 5 XOR gates times 32
<DaKnig> it is not a single AND gate. given that you cant do huge AND gates efficiently...
<lkcl_> this matters for ASICs: for FPGAs, not so much
<DaKnig> the value assigned is 30 bits long
<lkcl_> but the *test* is just one bit on each. yes you can't do much about the assignment
<DaKnig> wait why 5 xors?
<lkcl_> DaKnig: you're targetting an FPGA?
<DaKnig> yeah
<lkcl_> 5 XORs is what's needed for an "==" comparison of two 5-bit binary values
<lkcl_> plus a 5-input AND gate.
<DaKnig> Memory would use BRAM probably
<DaKnig> that's what I'd assume at least
<DaKnig> that's why I dont see the 5 xors being useful
<lkcl_> DaKnig: yes. which means that (in FPGA) it would be less LUTs blah blah :)
<lkcl_> in an ASIC, it's a totally different story.
<DaKnig> yeah
<DaKnig> thinking in terms of LUTs vs gates
<lkcl_> those XORs (and the multi-input AND) are all part of the BRAM decoding logic, "for free". no LUTs needed / taken
<lkcl_> bottom line, a Memory looks like the sensible option, doesn't it? :)
<lkcl_> IBM released the source code for the A21 recently. it was i believe what went into the Blackbird? (something like that)
<DaKnig> actually I should find a way that's beter than memory. since the code basically encodes a state machine as a counter with en+memory
<DaKnig> it is very light on resources thanks to that, but there might be a better way
<lkcl_> DaKnig: you know it's possible to check (using yosys) how much in the way of resources a design takes up?
<lkcl_> for ecp5, the yosys command is "synth_ecp5"
<lkcl_> and after a whooole bunch of console logs, it gives a report on the number of ANDs, ORs, NOTs, LUTs, SRAMs etc. needed for the design
<DaKnig> I might do this later
<lkcl_> it'll tell you in *concrete* terms (rather than guessing) which implementation is more resource-efficient
<DaKnig> this would mean firing up Vivado GUI which is not something I wanna do now :) would take some time to load everything and such
<lkcl_> nggggh :)
<Lofty> DaKnig: There's synth_xilinx
<Lofty> Why would you use Vivado?
<lkcl_> Lofty: good point. it's not necessary to use Vivado's LUT/resource estimation, synth_xilinx would give the same information
<lkcl_> that's assuming that they're the same level of efficiency.
<whitequark> not really
<Lofty> -abc9 helps a bit
<DaKnig> thats the project that aims to RE Series 7 FPGAs, no?
<DaKnig> or rather the outcome of that
<lkcl_> bunnie huang did a really good article which pointed out that that's not actually true :)
<Lofty> Well, it's called "synth_xilinx" because it handles more than just xc7
<Lofty> e.g. mwk has done a lot for earlier families
<DaKnig> I heard that there are some missing features in that. also I really should focus on coding instead of on the tools.
<DaKnig> tools are important but not as much as the things you make with them.
<DaKnig> I spent way too much time to set up what I have now, I'd probably try yosys and such later this year (or next year)
<lkcl_> how did that go?
<mwk> ... technically synth_xilinx doesn't rely on reverse engineering anything, the information needed to write a synthesis tool is publically available (well except timings)
<mwk> it's P&R and lower where you need to reverse things
<DaKnig> whitequark I noticed the nmigen-boards scripts use webpack version of vivado, even though I have the license. why does it happen? any plans on changing that?
<DaKnig> mwk: aha.
<whitequark> DaKnig: i don't do anything to make that happen
<whitequark> it's how vivado works iirc
<whitequark> webpack parts use webpack. don't ask me why
* whitequark is going to sleep now
<DaKnig> from my understanding , when the GUI boots up, it checks and validates the license file, but I noticed that here it doesnt
<DaKnig> well
* zignig is still awake and in deep conflict with a register allocator.
<lkcl_> zignig: the FSM you mentioned earlier?
<zignig> no this is above that , writing Boneless-V3 ASM and I need more than 6 regsiters.
* zignig logs out
zignig has quit [Quit: Changing server]
<lkcl_> :)
jock-tanner has quit [Quit: Leaving]
FFY00 has joined #nmigen
alexhw_ has quit [Quit: - Chat comfortably. Anywhere.]
alexhw has joined #nmigen
_whitelogger has joined #nmigen
<FL4SHK> how soon can I integrate PackedStruct?
<awygle> I gotta move to a different time zone or give up on scrollback lol
<awygle> FL4SHK: once somebody writes it and has it merged, which will be after 0.3 is released, which should be in a couple weeks
<awygle> iirc
emeb has joined #nmigen
Yehowshua has joined #nmigen
<Yehowshua> So got Python in browser via pyodide wasm
<Yehowshua> But nMIgen isn't working
<Yehowshua> Not Migen's fault - the people who wrote pyodide really don't understand C, CMake, or makefile
<Yehowshua> **makefiles
Yehowshua has quit [Remote host closed the connection]
<FL4SHK> awygle: what will it take to switch from `Record` to that?
<FL4SHK> I'm using `Record` largely like a packed struct already
<awygle> FL4SHK: no way to answer that definitively til we work through the design. Probably find+replace will be close to all that's needed if you're really using it like a packed struct currently.
<FL4SHK> I'm not using it like an interface
<FL4SHK> I'm using classes for that
<awygle> Also remember we won't remove Record until 0.5 at the earliest so you'll have plenty of time to transition
<FL4SHK> I like to future proof my stuff
<awygle> And if possible we'll give a DepreciationWarning that tells you exactly what to change
Kekskruemel has joined #nmigen
proteus-guy has joined #nmigen
MadHacker has quit [Ping timeout: 256 seconds]
jeanthom has quit [Ping timeout: 256 seconds]
q3k has left #nmigen ["WeeChat 2.7"]
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 256 seconds]
hitomi2504 has quit [Quit: Nettalk6 -]
jeanthom has joined #nmigen
<DaKnig> wait, Memory counts as two Modules?
Kekskruemel has quit [Ping timeout: 256 seconds]
<DaKnig> or rather, a Module for each port?
jeanthom has quit [Ping timeout: 240 seconds]
jeanthom has joined #nmigen
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
<d1b2> <314> Is there a simple enough way to have a "next next state" kinda deal in nmigen FSM??
lkcl__ has quit [Ping timeout: 240 seconds]
<d1b2> <314> like if i want to have a "wait for condition" state, but i want to be able to do = "WAIT" ; m.next_next = "whatever_state_comes_after" and have the code for my "WAIT" state be able to call the "whatever_state_comes_after"
<d1b2> <314> without having to manually enumerate all the states and create a numerical register to hold the next-next state
lkcl__ has joined #nmigen
MadHacker has joined #nmigen
<awygle> not currently, no
<awygle> "make the FSM DSL better" is on the list of Things To Do
<awygle> but as you can imagine that list is quite long
<awygle> you have to do it manually for the moment
<d1b2> <TiltMeSenpai> is there a tracking issue for that somewhere?
<d1b2> <TiltMeSenpai> I don't know if it's currently possible, but I'd eventually like to extract FSM's into some type of data structure so I can plot them in graphviz or something
Kekskruemel has joined #nmigen
lkcl__ is now known as lkcl
<awygle> as for getting them in e.g. dot format i don't think that's currently possible but i'm frequently wrong :)
<lkcl> the FSM states all go into a single pmux-like block.
<lkcl> with the state value itself being one of the inputs
<awygle> i have about 50% of hierarchical state machines for nmigen prototyped
<awygle> but surprising no one i have yet to find time to finish it
<lkcl> if you run "proc" and "opt" it gets broken out into individual signals
Yehowshua has joined #nmigen
<Yehowshua> whitequark, I was able to get yosys.wasm from yowasp running in my browser REPL style
<Yehowshua> I'll try to polish this up and publish the page
<Yehowshua> Still no luck with nMigen though
Asu has quit [Remote host closed the connection]
<_whitenotifier-b> [nmigen-boards] FFY00 commented on pull request #88: Travis: set up CI builds -
<FFY00> whitequark, acording to nmigen-boards requires an unreleased version of nmigen
<FFY00> we've talked about the packaging of nmigen-boards, you said to just package master
<FFY00> how do you propose to handle this? it seems like I have an incompatible nmigen-boards in the arch repos
Kekskruemel has quit [Quit: Leaving]
<_whitenotifier-b> [nmigen-boards] rroohhh synchronize pull request #88: Travis: set up CI builds -
<_whitenotifier-b> [nmigen-boards] rroohhh synchronize pull request #88: Travis: set up CI builds -
<_whitenotifier-b> [nmigen-boards] rroohhh commented on pull request #88: Travis: set up CI builds -
Yehowshua has quit [Remote host closed the connection]
<_whitenotifier-b> [nmigen] daveshah1 commented on issue #438: wrong type of buffer primitive used in series 7 -