06:35 <sf-slack> <kgugala> @mithro I added the ending

06:42 <mithro> kgugala: I'm editing the speaker notes if you want to look at what I'm suggesting you say on each slide...

06:43 <sf-slack> <kgugala> @mithro: yep I see your editions, thanks

08:54 <mithro> kgugala: I think maybe we should drop slides 31->34?

09:02 <sf-slack> <kgugala> Yep

09:37 <mithro> kgugala: Think the slides are fixed now...

09:38 <sf-slack> <kgugala> Thanks

15:45 <sf-slack> <jake.mercer> @litghost I'm looking at the 100-dsp-mskpat fuzzer at the moment and I'm wondering if I should extend it to cover the other attributes of the DSP48E1 or whether the attributes should be split across several fuzzers. Is there guide on how these should be split up if at all?

15:49 <litghost> jake: Solving N uncorrelated bits requires roughly O(log(N)) bits, so in general if the bits are uncorrelated, and it doesn't overly complicate the fuzzer, 1 fuzzer is fine

15:50 <litghost> jake: There is a notable counter example, which is iterative solve, which is currently used for pip solving

15:50 <litghost> jake: If a feature has a probablistic sampling scheme (e.g. routing), then we use iterative fuzzing to ensure sufficient samples are gathered

15:51 <mithro> jake.mercer: http://j.mp/xray-dsp has some guidance I think

15:51 <tpb> Title: Google Docs - create and edit documents online, for free. (at j.mp)

15:52 <litghost> jake: However, solving attribute parameters tends to be deterministic, so iterative fuzzing is not required. In general we seperate most tiles into one or more attribute fuzzers (default is 1) and zero or more interconnect/pip fuzzers

15:52 <litghost> jake: Not all tiles need pip fuzzers, it depends on how the tile is connected

15:53 <litghost> jake: In the case of the DSP, I know that there is a local constant source, which may have interconnect features. However start with the attribute documentation, as it tends to be significantly easier to write

16:02 <sf-slack> <jake.mercer> Ok, I think I understand, at least enough to allow me to continue; so I will just extend the existing fuzzer with the other attributes for the DSP48E1 and I'll have a look at the PIP fuzzers to see how they're put together. If I understand your first reply correctly, the attributes are fine to lump together into one fuzzer as they don't affect each other, but interconnect-related bits do, so they get separated

16:02 <sf-slack> out and are treated differently in order to get enough of a sample in reasonable time?

16:03 <sf-slack> <jake.mercer> mithro, I tried your link, but I've had to request access

16:35 <hackerfoo> mithro: Could this be used for v2x? https://github.com/YosysHQ/yosys/pull/1406

16:35 <tpb> Title: rpc: new frontend by whitequark · Pull Request #1406 · YosysHQ/yosys · GitHub (at github.com)

20:38 <mithro> jack.mercer: where you able to get access?

22:29 <sf-slack> <jake.mercer> Yes, thanks! Having a read now