ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting TBD
lkcl has quit [Ping timeout: 256 seconds]
lf has quit [Ping timeout: 260 seconds]
lf has joined #nmigen
lkcl has joined #nmigen
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
Bertl_oO is now known as Bertl_zZ
chipmuenk has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined #nmigen
feldim2425 has quit [Ping timeout: 264 seconds]
feldim2425 has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
Bertl_zZ is now known as Bertl
FL4SHK has quit [Ping timeout: 260 seconds]
FL4SHK has joined #nmigen
futarisIRCcloud has joined #nmigen
mogery has joined #nmigen
jeanthom has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 240 seconds]
chipmuenk1 is now known as chipmuenk
jeanthom has quit [Ping timeout: 256 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
emeb has joined #nmigen
bvernoux has joined #nmigen
modwizcode has joined #nmigen
<d1b2> <286Tech> How can I make sure a Signal does not get optimized away when using the python simulator?
<d1b2> <286Tech> Is there like a keep attribute?
<modwizcode> What do you mean by "optimized away"?
<d1b2> <286Tech> In my design I create several signals that I only assign to, but never read from. It's for debugging purposes.
<d1b2> <286Tech> But they are not in the resulting VCD file.
mogeryy has joined #nmigen
<d1b2> <dub_dub_11> can declare them in the module header (ie in init)
mogery has quit [Ping timeout: 260 seconds]
<d1b2> <286Tech> Well, I just fixed the bug, but i'd still want to know if it's possible with assigning to the attrs parameter.
<d1b2> <dub_dub_11> python self.debug_signal= Signal() #in init ... debug_signal = self.debug_signal #in elaborate
<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> Also, I found how to use the "keep" attribute:
<d1b2> <286Tech> signal.attrs["keep"] = 1
<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.
oter has left #nmigen ["Textual IRC Client:"]