<d1b2>
<286Tech> Yeah I could, but there are "keep" attributes in VHDL/Verilog
<d1b2>
<dub_dub_11> there probably is a cleaner way though
<d1b2>
<286Tech> I think I saw someone use something similar with nMigen, but I can't remember how.
<modwizcode>
I'm confused here because in pysim I literally don't see a way for it to discard
<d1b2>
<286Tech> I also don't know
<d1b2>
<286Tech> I understand when it's done during Verilog/RTLIL generation.
<d1b2>
<286Tech> But apparently it's also done when using pysim?
<modwizcode>
I can imagine it being done with verilog and rtlil, since those pass through yosys and I wouldn't imagine it would keep those unless instructed.
<modwizcode>
correction I don't think rtlil passes through yosys my bad
<d1b2>
<286Tech> Uh, that's weird. They now do appear in the list of signals.
<modwizcode>
What changed?
<d1b2>
<286Tech> Nothing
<d1b2>
<286Tech> I just re-ran the python file again
<modwizcode>
interesting...
<d1b2>
<286Tech> And I reloaded the vcd in gtkwave (because the signals did update).
<d1b2>
<286Tech> I thought that was the reason it worked, but when I remove it, it still shows up in the VCD.
<modwizcode>
Yeah I was looking for the source to find the attribute but I got distracted by trying to figure out why it was needed when it wasn't obvious
<modwizcode>
These are internal signals right?
<d1b2>
<286Tech> Yes
chipmuenk has quit [Quit: chipmuenk]
chipmuenk1 has joined #nmigen
chipmuenk1 is now known as chipmuenk
Bertl is now known as Bertl_oO
<awygle>
286Tech: you can also do Signal(attrs=[('keep', 1)])
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<agg>
the keep attribute is only for synthesis, though, it won't affect pysim
<d1b2>
<286Tech> @awygle Yes, that's an even nicer syntax
jeanthom has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
emeb_mac has joined #nmigen
bvernoux has quit [Quit: Leaving]
mogeryy has quit [Quit: Leaving]
jeanthom has quit [Ping timeout: 256 seconds]
<agg>
is it bad to just have a ton of sequential states in an fsm to sequence some boring chain of events, like writing a bunch of config registers?
<agg>
it seems like i could probably use fewer gates synthesising a small softcore and program it the sequence, heh
<modwizcode>
I mean it might be simpler to have it just sequence through a set of memories telling it what to write and where to write it.
<agg>
i've done that sort of thing before for static initialisation data e.g. on the little spi lcd screens, but in this case the values are dynamic and having to feed them into the memory one by one first and then read them out afterwards seems more faff
<modwizcode>
fair enough, I figured as much. It's an interesting problem to think about though. How dynamic is the data? i.e. what kind of transformation is required?
<agg>
not much. in some cases the exact data to write comes in, in other places it's static, in other places there's a bit or two in that turn into different static patterns
<agg>
the fsm works - and the python for it is great of course, i just have a python loop that emits the states required
<agg>
but i worry a little about just having these huge fsms, I guess
<modwizcode>
Ahh
<agg>
it meets timing so i guess it's "fine" :p
<modwizcode>
I mean I would assume the large FSM is going to be one of your best options for timing lol
<d1b2>
<TiltMeSenpai> an fsm is just a giant switch right
<modwizcode>
You could put it through yosys and write it back out after running whatever opt stuff is recommended though, might tell you how big it really is
<agg>
yea, be interesting to see what it looks like after it's been munged up
Raul has joined #nmigen
<agg>
i guess a state register, a mess of next-state logic, and then a bunch of enable signals to the various other registers it writes, idk
<modwizcode>
I do that sometimes to try and answer these kinda questions but I'm wary of it because I've now realized sometimes weird stuff can happen, re: the opt issue I discovered recently where yosys's output after the opt pass stubbed out the write logic for the memory, although iirc only the verilog output was weird, I think the rtlil form was sane.
<modwizcode>
If the FSM passes in yosys work I'd assume it should pull out the next-state logic and convert the state into a minimized set of control enable signals
<modwizcode>
I bet the graphical block view output would help, you could look at it right after proc and then compare to after running the fsm and maybe opt passes too.