05:20 <_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JvFMN

05:20 <_whitenotifier-3> [nmigen/nmigen] whitequark ec8386a - back.pysim: fix emission of undriven traces to VCD files.

05:20 <_whitenotifier-3> [nmigen] whitequark closed issue #345: Simulation of module with undriven signal causes generated VCD to not contain the signal, but contain an individual signal for each character of the undriven signal's name - https://git.io/Jvdst

05:35 <_whitenotifier-3> [nmigen] Failure. 82.41% (+-0.34%) compared to c79caea - https://codecov.io/gh/nmigen/nmigen/commit/ec8386a797cc0e37bc07a2b3c06c0c20e0ef5533

05:35 <_whitenotifier-3> [nmigen] Failure. 0.00% of diff hit (target 82.75%) - https://codecov.io/gh/nmigen/nmigen/commit/ec8386a797cc0e37bc07a2b3c06c0c20e0ef5533

05:35 <_whitenotifier-3> [nmigen] Failure. 82.69% (+-0.06%) compared to c79caea - https://codecov.io/gh/nmigen/nmigen/commit/ec8386a797cc0e37bc07a2b3c06c0c20e0ef5533

05:36 <_whitenotifier-3> [nmigen] Success. 82.75% (+0.00%) compared to c79caea - https://codecov.io/gh/nmigen/nmigen/commit/ec8386a797cc0e37bc07a2b3c06c0c20e0ef5533

05:53 <_whitenotifier-3> [nmigen] whitequark commented on issue #291: Need a way to attach attributes to memories - https://git.io/JvFDS

09:55 <ZirconiumX> wq: does https://github.com/YosysHQ/yosys/pull/726#issuecomment-608255460 mean "submit a PR for your branch [instead]?"

11:20 <whitequark> ZirconiumX: just in general work together on solving this (since earlier I mentioned I wouldn't be able to help you much; no I can)

11:20 <whitequark> *now I can

11:29 <ZirconiumX> Ah, okay, thank you WQ

15:38 <vup> is there a way to directly request a connector?

15:47 <whitequark> no

17:44 <vup> hmm, I think that could be useful, what do you think?

17:51 <vup> or what is the canonical way to have a connector, but also be able to use pins of the connector directly

17:51 <vup> ?

18:56 <kc5tja> ZirconiumX: "You don't have to name the signals i_/o_ " -- while true, I still follow Wishbone naming conventions because it really reduces my mental burden when figuring out what connects to what else.

18:57 <ZirconiumX> It seems to be nMigen convention for that

18:58 <ZirconiumX> Since nMigen is completely unaware of all of this

18:59 <kc5tja> Do you mean to write, "there seems to be an nMigen convention for that?" I'm having trouble parsing your response.

19:02 <kc5tja> vup: I subclassed a platform, and created my own resources which maps to pins in a connector. See https://github.com/sam-falvo/VDC-II/blob/master/src/top.py#L29-L42 for how I worked around this issue.

19:04 <ZirconiumX> kc5tja: yes, though "it" works fine

19:11 <kc5tja> ZirconiumX: Once I'm happy I have a working set of cores that talk to each other, I'll change my code to use Records, maybe even using the library-provided Wishbone functions. Records is still something which feels very alien to me at the moment.

19:16 <ZirconiumX> kc5tja: I generally avoid Records, and since Record.connect is soft-deprecated, I'm not entirely sure what the point of them is

19:24 <vup> kc5tja: hmm yeah, that would work, but that seems similar to using platform.add_resources(..., conn=...) without subclassing

19:25 <vup> I was looking for a more "adhoc" way to quickly (without a lot of extra code) access the connector pins

19:26 <vup> I guess a workaround could be adding a Resource for each Connector to the platform and just using the Resources then

19:27 <vup> however I wasn't sure if there that is the "canonical" nmigen way

19:40 <kc5tja> ZirconiumX: Ooh, I wasn't aware of that. Thanks for letting me know. :) I think the intended point, though, was to manage a collection of signals as a logical unit (e.g., an AXI or Wishbone bus, for example).

19:41 <kc5tja> vup: Yeah, I haven't found any way of doing that myself. Sorry. Though, in sending you the link that I did, I just noticed a bug (I'm missing an Attrs() declaration in my video resource).

19:43 <awygle> yeah Records are a conceptually good idea but the current version are not as useful as it appears at first glance

19:46 <awygle> Hallo

19:47 <ZirconiumX> Sorry I haven't been that talkative ^^;

19:52 <vup> kc5tja: yeah, no worries, I am happy about any input I get

20:00 <awygle> S'all good :-)

21:15 <awygle> whitequark: is it possible to access a module's FSM's states from a testbench? so that one could e.g. assert on the wishbone ERR_O signal and print the state in the failure message?

21:17 <awygle> (in pysim, not in formal stuff)