Monday, 2020-06-22

*** tpb has joined #yosys00:00
*** _whitelogger has quit IRC00:30
*** _whitelogger has joined #yosys00:32
*** emeb_mac has quit IRC01:21
*** citypw has joined #yosys01:21
*** emeb has quit IRC01:21
*** emeb has joined #yosys01:22
*** emeb_mac has joined #yosys01:23
*** emeb has quit IRC01:46
*** futarisIRCcloud has quit IRC02:03
*** Degi has quit IRC02:08
*** Degi has joined #yosys02:09
*** citypw has quit IRC03:09
*** dys has quit IRC03:12
*** futarisIRCcloud has joined #yosys03:24
*** _whitelogger has quit IRC04:00
*** _whitelogger has joined #yosys04:02
*** _whitelogger has quit IRC04:24
*** _whitelogger has joined #yosys04:26
*** az0re has joined #yosys06:29
*** emeb_mac has quit IRC06:55
*** _whitelogger has quit IRC07:00
*** nengel has joined #yosys07:00
*** _whitelogger has joined #yosys07:02
*** jakobwenzel has joined #yosys07:08
*** kraiskil_ has joined #yosys07:38
*** Asu has joined #yosys07:38
*** Asuu has joined #yosys07:39
*** Asu has quit IRC07:40
*** strobokopp has joined #yosys07:42
*** dys has joined #yosys08:40
*** Asuu has quit IRC08:44
*** Asu has joined #yosys08:45
*** Asu has quit IRC08:47
*** Asu has joined #yosys08:47
*** jeanthom has joined #yosys08:58
*** Asu has quit IRC09:10
*** Asu has joined #yosys09:12
*** citypw has joined #yosys09:24
*** citypw has quit IRC10:08
*** citypw has joined #yosys10:09
*** dys has quit IRC12:22
*** X-Scale` has joined #yosys12:31
*** X-Scale has quit IRC12:31
*** X-Scale` is now known as X-Scale12:32
*** X-Scale has quit IRC12:37
lambdais there an up-to-date build of the yosys manual somewhere? http://www.clifford.at/yosys/files/yosys_manual.pdf is >1.5 years old.12:44
*** emeb has joined #yosys12:44
daveshahThat one always reflects the last release12:45
daveshahI think if you want one for master then you will need to build it yourself12:45
lambdaaccording to github 0.9 was released in august 2019, the manual download is from october 2018 (both according to Last-Modified header and contents)12:46
daveshahoh right, must be from 0.8 then12:48
lambdaI just finished building it myself, no worries12:48
*** tlwoerner has joined #yosys12:52
*** X-Scale has joined #yosys13:02
*** TFKyle has joined #yosys13:26
*** jfcaron has joined #yosys13:32
*** citypw has quit IRC15:15
*** philtor has quit IRC15:37
*** dys has joined #yosys16:00
*** thehardway is now known as bwidawsk16:10
*** dys has quit IRC16:17
*** jeanthom has quit IRC16:18
*** jakobwenzel has quit IRC19:05
*** kraiskil_ has quit IRC19:10
lambdaI wrote up some design ideas on the redesigned memory cells, would greatly appreciate feedback: https://gist.github.com/Xiretza/fec08b9810a66efd368705a7f4a51aa719:27
tpbTitle: memory_redesign.md · GitHub (at gist.github.com)19:27
whitequarklambda: okay, a few comments20:14
whitequarkthe most important issue with this plan is that it restricts transparency to exactly one memrdwr port20:14
whitequarkthere's no technical reason for that. if you have one write and two read ports in the same domain, which is in fact common (a register file is that!) then you can have both read ports transparent20:15
whitequarkif the hardware doesn't support it, yosys can insert transparency logic on its own.20:15
whitequarkalso, tying transparency to memrdwr ports makes inference a lot harder20:15
whitequarkit has to be a frontend decision because there is no way for a frontend to encode that a memrd+memwr pair should have transparency enabled20:15
whitequarkit also makes it harder to combine ports20:16
mwk... tbh it kind of matches xilinx hardware, at least20:17
whitequarkyeah which is why i'm pushing against it20:17
whitequarklet's not privilege a single vendor20:17
mwkyes20:17
mwkwe should probably go through a good amount of vendors' mem primitives and catalogue their capabilities20:18
mwkthen figure out how to deal with all that20:18
mwktransparancy being likely the messiest part20:18
whitequarki did that, sorta20:18
whitequarkor rather i asked people to do that20:19
daveshahLattice are noticeably poor at documenting their transparency behaviour20:19
whitequarkmwk: https://github.com/nmigen/nmigen/issues/1420:19
tpbTitle: Implement a sanitizer for memory port combinations · Issue #14 · nmigen/nmigen · GitHub (at github.com)20:19
lambdawhitequark: alright, how can we model transparency between arbitrary sets of $memrd and $memwr then? afaict it should be possible to be transparent to one write port, but not another20:20
mwktransparency is only a thing within one clock domain, right?20:20
whitequarkyes20:20
daveshahnot convinced myself20:20
daveshahI think you can have multi clock transparency too20:21
whitequarkhm20:21
whitequarksure20:21
mwkhmm, right, transparency would be a thing between 1× and 2× clock20:21
mwketc20:21
whitequarklet's have transparency groups20:21
daveshahone way to consider transparency is moving the register to the address rather than the data output20:21
lambdadaveshah: isn't that mostly undefined behaviour in actual hardware?20:21
daveshahfor BRAM, probably20:21
mwkdaveshah: no, that's bullshit20:21
mwkand aaargh20:22
whitequarkthat interacts badly with read enables20:22
mwkyosys has that pattern everywhere20:22
mwkyes20:22
whitequarkand is one thing i would like to explicitly get rid of20:22
mwkhaving register on address is actually an *async* read port20:22
whitequarknmigen actually currently has RE of transparent ports hardwired to 120:22
mwkit's a giant sim-synth mismatch20:22
mwklet's kill it with fire20:22
daveshahthat will break migen20:23
daveshahbut maybe that doesn't matter20:23
mwkand as for transparency with multi clocks20:25
mwkhow would that even be described in HDL?20:26
lambdawhitequark: transparency groups sound promising, would they just be metadata in RTLIL::Memory?20:26
mwkor how could yosys insert transparency logic in this case20:26
daveshahI removed the transparency logic creation for multiple clocks because it was so obviously broken20:27
daveshahYosys used to attempt to create it but it just made things much worse20:27
mwkin xilinx, AFAIUI, transparency is an attribute of the *write* port, accomplished by moving its write strobe early (before the read strobe)20:27
daveshahyes, ECP5 is identical20:27
mwkso it's implementable on that particular hardware20:27
daveshaheven has the same three settings20:27
mwkbut if it gets to soft logic, aren't we screwed?20:28
daveshahyep20:28
*** jfcaron has quit IRC20:31
lambdadoes anything actually use cross-clock transparency? maybe we should just find a design that can easily be expanded to accommodate it later (like transparency groups) and then forget about it20:31
*** kraiskil_ has joined #yosys20:37
whitequarktransparency groups would not be metadata in RTLIL::Memory20:37
whitequarkthey should probably be a parameter on memory ports20:37
whitequarkanother thing you're missing is the NO_CHANGE behavior of a $memwr port20:38
whitequarki.e. read xor write20:38
mwkthat's kind of implied in the READ_EN and WRITE_EN signals20:39
lambdawhitequark: yeah, I was gonna ask that, what exactly is that mode? can't say I've come across it before20:39
mwkwhich are... kind of problematic20:39
mwkbecause eg. xilinx doesn't support them separately20:39
mwkbasically xilinx has two settings: WRITE_EN either always implies READ_EN, or always implies !READ_EN20:40
whitequarkoh wtf20:40
mwkthe latter is called the NO_CHANGE mode20:40
mwkhmm wait20:42
*** emeb_mac has joined #yosys20:45
mwkalright20:46
mwkso how it works on xilinx: you have a single-bit EN input, and multi-bit WE input (write enable per byte)20:46
mwkmemory writes to byte i iff EN && WE[i]20:46
mwkmemory reads iff EN && (WE == 0 || WRITE_MODE != NO_CHANGE)20:47
mwk... at least according to sim model, it's not exactly spelled out in the user guide20:48
lambdashould that pattern be part of the mem cells, or should BRAM inference check if READ_EN == WRITE_EN (or READ_EN == (not WRITE_EN) respectively)?20:59
mwkoh it's more complex than the latter21:00
mwkwhat it should check is whether WRITE_EN *implies* READ_EN or !READ_EN21:01
mwksince it's perfectly acceptable for both to be 021:01
mwk(by turning off EN)21:01
mwkalso note that WE is a multi-bit signal21:01
mwkso actually it's21:01
mwkso actually it's  |WRITE_EN implies READ_EN / !READ_EN21:01
mwkand well, it should be part of BRAM inference check, I guess?21:03
mwkbecause you can have a target where that just doesn't matter21:03
mwkhowever, there's a more interesting question here21:03
mwkhow should the memory inference pass be structured?21:03
mwkit may or may not be a single monolithical pass21:03
mwkclearly we're going to need some sort of "configuration file" for this pass, like the current one21:04
whitequarkwhat is a 'memory inference pass'?21:05
mwkalso it's clear that this pass will need to be run on wildly different configurations in the same synth flow (lut ram vs bram vs ultraram)21:05
whitequarkjust the replacement for memory_bram?21:05
mwkwhitequark: the not-yet-designed pass that turns generic cells into ones matching target capabilities21:05
mwkyeah, memory_bram 2.021:05
whitequarkyeah makes sense21:05
whitequarkat the very least i request a separate pass for checking $meminit cells21:06
mwkanyway: the existence of both bram and lutram in the same fpga implies that matching this xilinx enable pattern needs to be depend on the final ram type used, so cannot be done by looking at the port in isolation21:06
mwkyeah, that doesn't ave to be the only pass21:07
mwkI'd imagine we'd still have some minor memory_* passes that run first, like memory_opt21:07
mwk(which would probably now have the task of detecting common asymmetric memory patterns and gluing ports together?)21:08
lambdaalright, so are transparency groups the only thing that needs to change in the cell design? NO_CHANGE could either be implemented as a $memrdwr parameter, or be inferred during BRAM mapping21:20
whitequarkso far i think it is21:27
whitequarkonce everyone agrees with the general design there's gonna be bikeshedding of the names, too21:28
whitequarkbut not yet21:28
lambdaoh sure, I've always expected that to happen, I chose descriptive names for now21:30
*** Asu has quit IRC21:31
*** kraiskil_ has quit IRC21:33
lambdaupdated the gist, good night :)21:51
*** nengel has quit IRC22:01
*** mirage335 has quit IRC22:23
*** mirage335 has joined #yosys22:35

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!