06:50 <sensille> it sounds a bit like i could just get the pins from the modules where i need them

06:51 <sensille> passing down tons of pins through several modules is something that really got on my nerves in verilog

07:16 <d1b2> <4o> is there a oneliner for splitting Signal(32) into Array(Signal(8) for _ in range(4))?

10:03 <d1b2> <4o> do i have to have to have at least 1 sync domain for py sim to work? https://paste.debian.net/1191317/

10:16 <d1b2> <4o> yeah, looks like i do need a sync domain for add_sync_process to make sense. got an impression that add_process doesnt prevent the sim from terminating

12:26 <d1b2> <icb> @4o Usual Python syntax tends to work, like s=Signal(32); l=[s[n:n+8] for n in range(0, len(s), 8)]

12:30 <d1b2> <dub_dub_11> @sensille#0000 you could declare the pin in your module header, then do if(platform != None) to decide if you are gonna request a platform pin to assign to it

12:34 <d1b2> <dub_dub_11> I usually get pins in top level and pass them down but I'm not sure if that's the intended methods. The difference in passing them down is that you can make the submodules public so to pass a pin through you just need to do something like submodule.spi_module.spi_pins = platform.request("spi")

12:41 <sensille> ok, i think i have to play a bit with both methods. a difference to verilog is also that it's easy to pass signals down, or even build records of them

12:41 <sensille> i think passing down is cleaner

12:42 <d1b2> <dub_dub_11> Yeah Oop makes it much nicer than every intermediate module needing to have ports

12:42 <sensille> another question i have is if it makes a difference if i instantiate signals in __init__ or in elaborate. build ports in __init__, internal state in elaborate?

13:01 <d1b2> <dub_dub_11> Yeah as you suggest. Ports need to be self.signalname too so they are visible

13:05 <d1b2> <4o> sorcery

13:05 <d1b2> <4o> thanks

13:17 <agg> 4o, the word_select method might be helpful, s.word_select(n, 8) and n can be a runtime signal, so you don't need to make an array at all

13:17 <agg> Or you can do like Array(s.word_select(n, 8) for n in range(4)) for a similar effect

13:19 <agg> In sim you don't need a sync domain, you can stimulate purely combinatorial logic, use add_process and yield Settle

13:19 <d1b2> <4o> i want a shift reg. so i believe static slicing is what i want. but thanks for reminding about word select, i keep forgetting it exists

13:20 <agg> The Array in your original question is for making dynamic selection

13:20 <agg> But yea if the selection is fixed, word_select or just regular bit slicing should be fine

13:21 <agg> In your example I think just using add_process should work fine?

13:25 <d1b2> <4o> yeah, the hint was in the name. add_proces worked. 99% bugs are in human brain

14:20 <vup> ltny

16:25 <d1b2> <twam> What's the proper way to create a resource, e.g. ULPIResource (https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/resources/interface.py#L117) out of Pins available on a connector (e.g. https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ulx3s.py#L129). Especially if don't want to use the whole connector for a single resource.

16:26 <agg> twam: you can use platform.add_resources, and in each resource, use Pins("1 2 3 4", conn=("conn_name", 0))

16:26 <agg> for example, https://github.com/adamgreig/nmigen-examples/blob/master/nmigen_examples/connectors.py

16:27 <agg> you only use whichever pins you need, the rest remain unallocated and can be used by other resources

16:27 <agg> (as an alternative syntax you can use Pins("conn_name_0:1") but I don't think there's any reason to do so)

16:29 <d1b2> <twam> I don't want to copy the pin numbers from the original Connector definition but abstract that away. The Pins("conn_name_0:1") syntax sounds promising. I'll give that a try.

16:30 <agg> sorry, I probably wasn't clear

16:30 <agg> you don't need to copy the numbres from the original definition

16:30 <agg> Pins("1", conn=("pmod", 0)) would use "pin 1" from the pmod, which might be pin A7 on the FPGA or whatever is in connectors

16:31 <agg> using Pins("pmod_0:1") is the same as using Pins("1", conn=("pmod", 0))

16:32 <d1b2> <twam> And in something like DirectUSBResource(0, d_p="D15", d_n="E15", pullup="B12", attrs=Attrs(IO_TYPE="LVCMOS33") ) I can replace D15 then with Pins("pmod_0:!")?

16:34 <agg> in fact, DirectUSBResource takes a conn argument too

16:34 <agg> so you could use DirectUSBResource(d_p="1", d_n="2", pullup="3", conn=("pmod", 0))

16:35 <agg> [but yes, I think you could also write DirectUSBResource(d_p="pmod_0:1") etc, but I think using the conn argument is clearer and shorter)

17:09 <d1b2> <twam> Ah, cool. Didn't notice that. That looks very good.

17:25 <sensille> is it possible to add debug-prints to if-paths?

17:55 <vup> sensille: this is planned, see https://github.com/nmigen/nmigen/issues/432

17:57 <vup> I think there is a wip implementation in the pysim-display branch

17:57 <sensille> ah, ok