01:00 <_whitenotifier-5> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JYCf9

01:00 <_whitenotifier-5> [YoWASP/yosys] whitequark c25541e - Update dependencies.

05:52 <d1b2> <4o> what's the right way to write lut-based rom with multiple read ports?

05:53 <d1b2> <4o> i guess i want a constant array and muxes inferred from slicing it, right?

05:59 <d1b2> <4o> hilarious:) https://paste.debian.net/1191460/

06:12 <d1b2> <4o> for i in range(256) should be on line 2 in that snippet

08:05 <agg> 4o: I would just use a Memory with multiple comb read ports

08:06 <agg> Set the contents with Memory's init parameter and set the read port domains to comb

11:22 <d1b2> <4o> nice. didn't think i can get 2 read ports from Memory

11:22 <d1b2> <4o> thanks

11:26 <d1b2> <4o> if this https://paste.debian.net/1191495/ a valid way to set reset for a module to async?

11:28 <whitequark[m]> you need to drive the clock of the domain you created, too

11:30 <d1b2> <4o> drive like get clk signal from port and assign it to created clock domain?

11:30 <whitequark[m]> something like that

11:32 <d1b2> <4o> ok, looks like for sync = ClockDomain(...) i can access sync.clk. how do i get "clk port" for a module?

11:34 <d1b2> <4o> define it as a usual port in __init__ and use usial port asociation when instantiating my module?

11:47 <whitequark[m]> there is no special "clk port"; you can use any signal. so yeah

11:48 <d1b2> <4o> ok, thanks

13:43 <anuejn> hey all :). Apertus is looking for google summer of code participants who will get payed for writing nmigen code for an open source film camera during the summer

13:43 <anuejn> (https://lab.apertus.org/T1220)

13:44 <anuejn> if you are interested, write vup an email (vup@apertus.org) or say hello in the #apertus irc channel

13:45 <d1b2> <dub_dub_11> how long are applications open for?

13:45 <vup> April 13th

13:46 <d1b2> <dub_dub_11> ty 🙂

13:47 <d1b2> <dub_dub_11> looks like a really cool project, I would definitely apply if I didn't have existing commitments 😄

15:08 <_whitenotifier-5> [nmigen-boards] twam synchronize pull request #148: Colorlight i5/i9 - https://git.io/JYmtA

16:19 <d1b2> <twam> I'm thinking about create a module, e.g. I2C which I pass a resource with the IO pins (e.g. something like Resource("i2c", 0, Subsignal("scl", Pins("1", dir="io")), Subsignal("sda", Pins("2", dir="io")), ), ), so that I can directly access the .i, .o, .oe properties of the Pins. Is this a good idea? And if, how would I create a corresponding resource in a test setup?

16:21 <d1b2> <4o> trying to get verilog with async reset. https://paste.debian.net/1191565/ getting error for this particular code. simple reg aka m.d.sync += o.eq(a) works with async reset. test.py compiles with async_teset = False. nmigen commit e288e. what have i done wrong?

17:00 <d1b2> <4o> functional equivalent of that code compiles ok https://paste.debian.net/1191577/

17:01 <d1b2> <4o> is it my bug or should i take it to github?

17:43 <vup> @twam the thing you get back from a `platfrom.request(...)` is nothing more than `Record`, so for a test setup you could create such a `Record` yourself.

18:43 <d1b2> <twam> I thought that as well, but type(i2c.scl) will record something like class 'nmigen.lib.io.Pin' whereas a signal in something like Record([("le", 1)]) is only and misses the .oe attributes.

18:44 <d1b2> <twam> ... is only class 'nmigen.hdl.ast.Signal' ...

19:14 <vup> @twam Pin inherits from Record..., to emulate the .i, .o and .oe attributes, you could just do a nested record: `Record([("scl", [("i", 1), ("o", 1), ("oe", 1)])])`

21:10 <fdsa> I'm trying to learn how to use the litex stuff with nmigen. My goal is to use liteeth (or something in litex) to control a RMII ethernet peripheral I have on my development board, for which I already have some verilog for, but I'd rather it was all in python/nmigen ultimately.

21:10 <fdsa> I came across this comment

21:10 <fdsa> https://github.com/enjoy-digital/litex/issues/372#issuecomment-609421431

21:10 <fdsa> which links to what seems like a way to generate and link the verilog stuff?

21:10 <fdsa> However I don't understand what's going on, could anyone explain how to approach this? has anyone got examples of where this was done before?

21:13 <fdsa> Question 2: In my xilinx .ucf file, I have the following lines:

21:13 <fdsa> NET "e_txd<?>" OFFSET=OUT 1ns AFTER e_gtxc;

21:13 <fdsa> and

21:13 <fdsa> Net e_rxc TNM_NET = e_rxc_pin;

21:13 <fdsa> TIMESPEC TS_e_rxc_pin = PERIOD e_rxc_pin 8ns;

21:13 <fdsa> Any ideas on how to rewrite this stuff in nmigen? should this be put in a platform definition, or elsewhere in the code? thanks!

21:15 <fdsa> (For context this is from the demo code for this https://www.ebay.com/itm/1000M-Ethernet-Module-Gigabit-UDP-Matching-FPGA-Board-Directly-plug-connectors-/253556249167)