01:59 <d1b2> <rwhitby> If you want to see a complete newbie learning nmigen and python at the same time, I'm grunt streaming now 🙂

12:06 <d1b2> <twam> I wondering if I should use (sub) ClockDomain s if possible, or do they generate overhead? E.g. something like m = Module() counter = Signal(bits_for(7)) m.d.sync += counter.eq(counter + 1) # Without ClockDomain out = Signal() with m.If(counter == 7): m.d.sync += out.eq(0) with m.If(counter == 3): m.d.sync += out.eq(1) # With ClockDomain out_cnt = Signal(reset=1) m.domains.cnt = cd_cnt = ClockDomain("cnt") m.d.comb +=

12:06 <d1b2> cd_cnt.clk.eq(~counter[1]) m.d.cnt += out_cnt.eq(~out_cnt)

13:25 <cesar[m]1> As a rule of thumb, you should use only one clock, the same across all your design, if you can help it.

13:46 <agg> also if you _were_ going to make a new clockdomain for that, you'd probably want to use local=True to stop it being the same as all domains named 'cnt' across your whole design

13:47 <agg> but yea, in this case i'd do your first example, without clockdomain

13:49 <agg> is there a reason to use Signal(bits_for(7)) instead of Signal(range(7))?

13:50 <agg> (also in general your counter adder might not be glitch-free, so the new clock signal you create might contain glitches, as i understand it you have to be quite careful generating clock signals from logic like that)

14:37 <d1b2> <twam> I'm trying to implement an I2C master and I had a look at https://www.digikey.com/eewiki/download/attachments/10125324/i2c_master.vhd. They use counters to generate an internal data_clk and scl_clk and I was wondering if this can be done in a more readable way.

14:37 <d1b2> <twam> No. Is there any difference?

14:48 <agg> it turns out calling Signal(range(x)) calls bits_for(x) under the hood, so no; i'd probably use range(x) instead of having to import the util function

18:20 <agg> really for my own sake, i've run sphinx's attempt at autodoc just to have a more convenient reference when programming; https://agg.io/nm.Signal / https://agg.io/nm.lib.fifo etc

18:21 <agg> sphinx-autodoc remains pretty janky, i really wish it just let you put arbitrary markdown instead of weirdly restricted rst in docstrings

18:23 <agg> "oh, you want a section called 'Trellis Toolchain' in your documentation? that's too hard, it's not in my list of 5 allowable section names, so i'm removing your entire doc string, do you like this?"

18:25 <agg> but it just about beats opening the relevant nmigen source in my vim/help(x) in python to check the docstring and available methods which is mostly what i've otherwise been doing

21:54 <d1b2> <mubes> Can I pick the smart brains around here for a second? I have a 'style' question that I don't really know the answer to. I'm working on an FPGA CMSIS-DAP engine so, for the most part, I'm parsing a set of relatively short USB OUT messages and then creating responding USB IN ones. I have a state machine that is pulling in the various parts of the incoming message and I'm now at the point where I want to trigger sub-machines to perform their action

21:54 <d1b2> according to the message type. I've done that by creating Modules for each message, but they're all pushing their responses into a common transmit buffer. Even though only one of these modules will be 'live' at any one time nmigen doesn't like that and not unreasonably complains that the transmit buffer is being driven from multiple fragments. Is there a better 'pattern' I should be using to address this?

21:56 <d1b2> <mubes> (I don't really want all the code ending up in the state machine as it'll become unmanagable!)

22:00 <tpw_rules> i mean that just sounds like you're making a bus

22:00 <tpw_rules> but each module should output its transmit request and data and just OR them all together

22:00 <d1b2> <mubes> possibly...I'm still in the woods though, can't identify trees yet.

22:01 <d1b2> <mubes> so just mux the various outputs?

22:02 <tpw_rules> no that wouldn't be a mux

22:02 <tpw_rules> a mux would use more resources and be unnecessary, as long as you keep your promise that only one module will be live. otherwise it will do weird and hard to debug things

22:03 <d1b2> <mubes> just means I have to reset the outgoing data packet from each sub-module to be zeros once it's finished its operation I guess

22:03 <tpw_rules> you could add a mux in each module too

22:04 <d1b2> <mubes> they inherit from a common super so I can do stuff there. Just trying to understand what the nmigenic way to do it is.

22:05 <tpw_rules> i'm not sure i would make a Module inherit from something

22:05 <tpw_rules> imho you might be trying to think too much like software

22:05 <d1b2> <mubes> Looking at luna the handlers are done as methods.

22:06 <d1b2> <mubes> I definately have a 'software head' on this, trying to break out of it.

22:07 <d1b2> <mubes> ok, I think I have some clues now, ta.

23:14 <d1b2> <mubes> The way I chose was just to use functions, which then emit nmigen sequences at the right places....means I can keep the individual handlers separate while still all pushing to a common write buffer, and it all looks reasonably clean. It seems to be the way luna handles things like usb standard requests, so hopefully not too broken.

23:17 <_whitenotifier-5> [nmigen-boards] hansfbaier synchronize pull request #142: Add board support for Terasic de0_nano - https://git.io/Jtiqq

23:18 <_whitenotifier-5> [nmigen-boards] hansfbaier edited pull request #142: Add board support for Terasic de0_nano - https://git.io/Jtiqq