03:44 <_whitenotifier> [nmigen] programmerjake opened issue #43: process function is defined but not used in test case - https://git.io/fjelI

04:30 <attie> lkcl: for modules with several independent valid/ack interfaces I usually have one generator per interface. Not sure why you need the array of functions?

05:49 <lkcl> attie: ah yes, generators, that was it.

05:49 <lkcl> array of generators.

05:50 <lkcl> attie: because the input is an array of STB/ACK/DATA

05:51 <lkcl> to set multiple STB/DATA and monitor multiple ACK signals in a single unit test function (generator) would be absolute hell

05:52 <lkcl> it would quickly become one of the worst state-based nightmare pieces of code i'd ever written :)

05:52 <lkcl> whereas, an array of functions (generators) would have each function (generator) associated with and monitoring a single STB/ACK/DATA each

05:53 <lkcl> which is a dead-straightforward loop.

05:53 <lkcl> the tricky bit is, i'm not sure how to keep the functions (generators) in clock lock-step

05:57 <bb-m-labs> build #2484 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2484

05:59 <bb-m-labs> build #2963 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2963 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

06:29 <bb-m-labs> build #2485 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2485

06:31 <bb-m-labs> build #2964 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2964 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

07:13 <attie> lkcl: no, I mean, why not have the generators be independent?

07:14 <attie> why do you want to keep them in lockstep?

07:14 <attie> (as an example, here's what I do usually: https://github.com/nakengelhardt/fpgagraphlib/blob/master/src/hmc_backed_fifo_tb.py )

07:16 <attie> there's a generator dealing with the input side and a generator dealing with the output side. They get passed whatever information they need (usually the data to expect, or how many transactions to do) either as argument or as a shared variable (self.data on the testbench here)

07:17 <attie> do you have some specific timing requirements that you need to observe? but then why stb/ack?

07:36 <lkcl> ah ha! that's precisely the example i needed

07:36 <lkcl> the array of generators is precisely and exactly what i was talking about

07:37 <lkcl> and the synchronisation i was referring to is being taken care of by run_with

07:37 <lkcl> the only thing.... i have absolutely no idea where SimCase comes from, because of the "import *"

07:42 <lkcl> attie: found it. had to guess where it was, from the name of the module. i guessed "tbsupport" was "test bench support"

08:39 <_whitenotifier> [nmigen] whitequark commented on issue #43: process function is defined but not used in test case - https://git.io/fjeBL

09:18 <attie> oh, yes, sorry

09:20 <attie> that's just some boilerplate to make it use unittest

09:32 <attie> lkcl: here's an example that doesn't use the unittest stuff (from my integration test): https://github.com/nakengelhardt/fpgagraphlib/blob/da86b4f216b4a60796f4c708c552aee5def77c59/src/core_top_pico.py#L374

09:33 <attie> (with bonus clock domains but I guess that works differently in nmigen)

11:19 <lkcl> attie: ooOo :) so, that's really helpful: it's allowed me to establish that run_simulation takes an array/dictionary of generator functions, which i hadn't expected

11:20 <lkcl> and is great news to discover

13:30 <lkcl> attie: yay, got it! split out pipeline-send from pipeline-receive, which is a good start.

13:31 <lkcl> the next thing i can do is the multi-input single-output multiplexer

18:13 <cr1901_modern> attie: What is fpgagraphlib, out of curiosity?