Saturday, 2019-09-28

*** tpb has joined #symbiflow00:00
*** adjtm has joined #symbiflow01:18
*** OmniMancer has joined #symbiflow02:56
*** Vonter_ has quit IRC03:33
*** Vonter has joined #symbiflow03:35
*** _whitelogger has quit IRC04:21
*** _whitelogger has joined #symbiflow04:23
*** _whitelogger has quit IRC04:27
*** _whitelogger has joined #symbiflow04:29
*** citypw has joined #symbiflow04:36
*** synaption[m] has joined #symbiflow06:34
sf-slack<kgugala> @mithro I added the ending06:35
mithrokgugala: I'm editing the speaker notes if you want to look at what I'm suggesting you say on each slide...06:42
sf-slack<kgugala> @mithro: yep I see your editions, thanks06:43
*** _whitelogger has quit IRC08:39
*** _whitelogger has joined #symbiflow08:41
mithrokgugala: I think maybe we should drop slides 31->34?08:54
sf-slack<kgugala> Yep09:03
*** Bertl is now known as Bertl_zZ09:33
mithrokgugala: Think the slides are fixed now...09:37
sf-slack<kgugala> Thanks09:38
*** freemint has joined #symbiflow10:26
*** citypw has quit IRC13:39
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:45
litghostjake: 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 fine15:49
litghostjake: There is a notable counter example, which is iterative solve, which is currently used for pip solving15:50
litghostjake: If a feature has a probablistic sampling scheme (e.g. routing), then we use iterative fuzzing to ensure sufficient samples are gathered15:50
mithrojake.mercer: http://j.mp/xray-dsp has some guidance I think15:51
tpbTitle: Google Docs - create and edit documents online, for free. (at j.mp)15:51
litghostjake: 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 fuzzers15:52
litghostjake: Not all tiles need pip fuzzers, it depends on how the tile is connected15:52
litghostjake: 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 write15:53
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 separated16:02
sf-slackout and are treated differently in order to get enough of a sample in reasonable time?16:02
sf-slack<jake.mercer> mithro, I tried your link, but I've had to request access16:03
*** Bertl_zZ is now known as Bertl16:32
hackerfoomithro: Could this be used for v2x? https://github.com/YosysHQ/yosys/pull/140616:35
tpbTitle: rpc: new frontend by whitequark · Pull Request #1406 · YosysHQ/yosys · GitHub (at github.com)16:35
*** freemint has quit IRC17:03
*** freemint has joined #symbiflow18:35
*** OmniMancer has quit IRC19:39
*** bjorkintosh has quit IRC19:49
*** freeemint has joined #symbiflow20:05
*** freemint has quit IRC20:07
*** bjorkintosh has joined #symbiflow20:14
mithrojack.mercer: where you able to get access?20:38
*** freeemint has quit IRC21:00
*** bjorkintosh has quit IRC21:41
sf-slack<jake.mercer> Yes, thanks! Having a read now22:29

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!