<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
<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
<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>
yowasp.org
<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.
<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] https://git.io/JJCPc
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJCPl
<_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 - https://znc.in]
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 - https://git.io/JJCAW
<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 - https://git.io/JJCxm
<_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 - https://git.io/JJCxm
<_whitenotifier-b>
[nmigen] whitequark commented on issue #442: Simulator with non-passive sync process and no clock added runs indefinitely without emitting a warning - https://git.io/JJCxZ
<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.
<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
<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 "setup.py 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 "setup.py test" is deprecated, what is supposed to replace it?
<whitequark>
DaKnig: yes, that tests a few more things
<whitequark>
vup: just use setup.py 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 - https://git.io/JJWeh
<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)
<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.
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 - www.ntalk.de]
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 m.next = "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