| *** tpb has joined #yosys | 00:00 | |
| *** _whitelogger has quit IRC | 00:30 | |
| *** _whitelogger has joined #yosys | 00:32 | |
| *** emeb_mac has quit IRC | 01:21 | |
| *** citypw has joined #yosys | 01:21 | |
| *** emeb has quit IRC | 01:21 | |
| *** emeb has joined #yosys | 01:22 | |
| *** emeb_mac has joined #yosys | 01:23 | |
| *** emeb has quit IRC | 01:46 | |
| *** futarisIRCcloud has quit IRC | 02:03 | |
| *** Degi has quit IRC | 02:08 | |
| *** Degi has joined #yosys | 02:09 | |
| *** citypw has quit IRC | 03:09 | |
| *** dys has quit IRC | 03:12 | |
| *** futarisIRCcloud has joined #yosys | 03:24 | |
| *** _whitelogger has quit IRC | 04:00 | |
| *** _whitelogger has joined #yosys | 04:02 | |
| *** _whitelogger has quit IRC | 04:24 | |
| *** _whitelogger has joined #yosys | 04:26 | |
| *** az0re has joined #yosys | 06:29 | |
| *** emeb_mac has quit IRC | 06:55 | |
| *** _whitelogger has quit IRC | 07:00 | |
| *** nengel has joined #yosys | 07:00 | |
| *** _whitelogger has joined #yosys | 07:02 | |
| *** jakobwenzel has joined #yosys | 07:08 | |
| *** kraiskil_ has joined #yosys | 07:38 | |
| *** Asu has joined #yosys | 07:38 | |
| *** Asuu has joined #yosys | 07:39 | |
| *** Asu has quit IRC | 07:40 | |
| *** strobokopp has joined #yosys | 07:42 | |
| *** dys has joined #yosys | 08:40 | |
| *** Asuu has quit IRC | 08:44 | |
| *** Asu has joined #yosys | 08:45 | |
| *** Asu has quit IRC | 08:47 | |
| *** Asu has joined #yosys | 08:47 | |
| *** jeanthom has joined #yosys | 08:58 | |
| *** Asu has quit IRC | 09:10 | |
| *** Asu has joined #yosys | 09:12 | |
| *** citypw has joined #yosys | 09:24 | |
| *** citypw has quit IRC | 10:08 | |
| *** citypw has joined #yosys | 10:09 | |
| *** dys has quit IRC | 12:22 | |
| *** X-Scale` has joined #yosys | 12:31 | |
| *** X-Scale has quit IRC | 12:31 | |
| *** X-Scale` is now known as X-Scale | 12:32 | |
| *** X-Scale has quit IRC | 12:37 | |
| lambda | is 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 #yosys | 12:44 | |
| daveshah | That one always reflects the last release | 12:45 |
| daveshah | I think if you want one for master then you will need to build it yourself | 12:45 |
| lambda | according 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 |
| daveshah | oh right, must be from 0.8 then | 12:48 |
| lambda | I just finished building it myself, no worries | 12:48 |
| *** tlwoerner has joined #yosys | 12:52 | |
| *** X-Scale has joined #yosys | 13:02 | |
| *** TFKyle has joined #yosys | 13:26 | |
| *** jfcaron has joined #yosys | 13:32 | |
| *** citypw has quit IRC | 15:15 | |
| *** philtor has quit IRC | 15:37 | |
| *** dys has joined #yosys | 16:00 | |
| *** thehardway is now known as bwidawsk | 16:10 | |
| *** dys has quit IRC | 16:17 | |
| *** jeanthom has quit IRC | 16:18 | |
| *** jakobwenzel has quit IRC | 19:05 | |
| *** kraiskil_ has quit IRC | 19:10 | |
| lambda | I wrote up some design ideas on the redesigned memory cells, would greatly appreciate feedback: https://gist.github.com/Xiretza/fec08b9810a66efd368705a7f4a51aa7 | 19:27 |
| tpb | Title: memory_redesign.md · GitHub (at gist.github.com) | 19:27 |
| whitequark | lambda: okay, a few comments | 20:14 |
| whitequark | the most important issue with this plan is that it restricts transparency to exactly one memrdwr port | 20:14 |
| whitequark | there'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 transparent | 20:15 |
| whitequark | if the hardware doesn't support it, yosys can insert transparency logic on its own. | 20:15 |
| whitequark | also, tying transparency to memrdwr ports makes inference a lot harder | 20:15 |
| whitequark | it has to be a frontend decision because there is no way for a frontend to encode that a memrd+memwr pair should have transparency enabled | 20:15 |
| whitequark | it also makes it harder to combine ports | 20:16 |
| mwk | ... tbh it kind of matches xilinx hardware, at least | 20:17 |
| whitequark | yeah which is why i'm pushing against it | 20:17 |
| whitequark | let's not privilege a single vendor | 20:17 |
| mwk | yes | 20:17 |
| mwk | we should probably go through a good amount of vendors' mem primitives and catalogue their capabilities | 20:18 |
| mwk | then figure out how to deal with all that | 20:18 |
| mwk | transparancy being likely the messiest part | 20:18 |
| whitequark | i did that, sorta | 20:18 |
| whitequark | or rather i asked people to do that | 20:19 |
| daveshah | Lattice are noticeably poor at documenting their transparency behaviour | 20:19 |
| whitequark | mwk: https://github.com/nmigen/nmigen/issues/14 | 20:19 |
| tpb | Title: Implement a sanitizer for memory port combinations · Issue #14 · nmigen/nmigen · GitHub (at github.com) | 20:19 |
| lambda | whitequark: 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 another | 20:20 |
| mwk | transparency is only a thing within one clock domain, right? | 20:20 |
| whitequark | yes | 20:20 |
| daveshah | not convinced myself | 20:20 |
| daveshah | I think you can have multi clock transparency too | 20:21 |
| whitequark | hm | 20:21 |
| whitequark | sure | 20:21 |
| mwk | hmm, right, transparency would be a thing between 1× and 2× clock | 20:21 |
| mwk | etc | 20:21 |
| whitequark | let's have transparency groups | 20:21 |
| daveshah | one way to consider transparency is moving the register to the address rather than the data output | 20:21 |
| lambda | daveshah: isn't that mostly undefined behaviour in actual hardware? | 20:21 |
| daveshah | for BRAM, probably | 20:21 |
| mwk | daveshah: no, that's bullshit | 20:21 |
| mwk | and aaargh | 20:22 |
| whitequark | that interacts badly with read enables | 20:22 |
| mwk | yosys has that pattern everywhere | 20:22 |
| mwk | yes | 20:22 |
| whitequark | and is one thing i would like to explicitly get rid of | 20:22 |
| mwk | having register on address is actually an *async* read port | 20:22 |
| whitequark | nmigen actually currently has RE of transparent ports hardwired to 1 | 20:22 |
| mwk | it's a giant sim-synth mismatch | 20:22 |
| mwk | let's kill it with fire | 20:22 |
| daveshah | that will break migen | 20:23 |
| daveshah | but maybe that doesn't matter | 20:23 |
| mwk | and as for transparency with multi clocks | 20:25 |
| mwk | how would that even be described in HDL? | 20:26 |
| lambda | whitequark: transparency groups sound promising, would they just be metadata in RTLIL::Memory? | 20:26 |
| mwk | or how could yosys insert transparency logic in this case | 20:26 |
| daveshah | I removed the transparency logic creation for multiple clocks because it was so obviously broken | 20:27 |
| daveshah | Yosys used to attempt to create it but it just made things much worse | 20:27 |
| mwk | in xilinx, AFAIUI, transparency is an attribute of the *write* port, accomplished by moving its write strobe early (before the read strobe) | 20:27 |
| daveshah | yes, ECP5 is identical | 20:27 |
| mwk | so it's implementable on that particular hardware | 20:27 |
| daveshah | even has the same three settings | 20:27 |
| mwk | but if it gets to soft logic, aren't we screwed? | 20:28 |
| daveshah | yep | 20:28 |
| *** jfcaron has quit IRC | 20:31 | |
| lambda | does 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 it | 20:31 |
| *** kraiskil_ has joined #yosys | 20:37 | |
| whitequark | transparency groups would not be metadata in RTLIL::Memory | 20:37 |
| whitequark | they should probably be a parameter on memory ports | 20:37 |
| whitequark | another thing you're missing is the NO_CHANGE behavior of a $memwr port | 20:38 |
| whitequark | i.e. read xor write | 20:38 |
| mwk | that's kind of implied in the READ_EN and WRITE_EN signals | 20:39 |
| lambda | whitequark: yeah, I was gonna ask that, what exactly is that mode? can't say I've come across it before | 20:39 |
| mwk | which are... kind of problematic | 20:39 |
| mwk | because eg. xilinx doesn't support them separately | 20:39 |
| mwk | basically xilinx has two settings: WRITE_EN either always implies READ_EN, or always implies !READ_EN | 20:40 |
| whitequark | oh wtf | 20:40 |
| mwk | the latter is called the NO_CHANGE mode | 20:40 |
| mwk | hmm wait | 20:42 |
| *** emeb_mac has joined #yosys | 20:45 | |
| mwk | alright | 20:46 |
| mwk | so how it works on xilinx: you have a single-bit EN input, and multi-bit WE input (write enable per byte) | 20:46 |
| mwk | memory writes to byte i iff EN && WE[i] | 20:46 |
| mwk | memory 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 guide | 20:48 |
| lambda | should 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 |
| mwk | oh it's more complex than the latter | 21:00 |
| mwk | what it should check is whether WRITE_EN *implies* READ_EN or !READ_EN | 21:01 |
| mwk | since it's perfectly acceptable for both to be 0 | 21:01 |
| mwk | (by turning off EN) | 21:01 |
| mwk | also note that WE is a multi-bit signal | 21:01 |
| mwk | so actually it's | 21:01 |
| mwk | so actually it's |WRITE_EN implies READ_EN / !READ_EN | 21:01 |
| mwk | and well, it should be part of BRAM inference check, I guess? | 21:03 |
| mwk | because you can have a target where that just doesn't matter | 21:03 |
| mwk | however, there's a more interesting question here | 21:03 |
| mwk | how should the memory inference pass be structured? | 21:03 |
| mwk | it may or may not be a single monolithical pass | 21:03 |
| mwk | clearly we're going to need some sort of "configuration file" for this pass, like the current one | 21:04 |
| whitequark | what is a 'memory inference pass'? | 21:05 |
| mwk | also 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 |
| whitequark | just the replacement for memory_bram? | 21:05 |
| mwk | whitequark: the not-yet-designed pass that turns generic cells into ones matching target capabilities | 21:05 |
| mwk | yeah, memory_bram 2.0 | 21:05 |
| whitequark | yeah makes sense | 21:05 |
| whitequark | at the very least i request a separate pass for checking $meminit cells | 21:06 |
| mwk | anyway: 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 isolation | 21:06 |
| mwk | yeah, that doesn't ave to be the only pass | 21:07 |
| mwk | I'd imagine we'd still have some minor memory_* passes that run first, like memory_opt | 21:07 |
| mwk | (which would probably now have the task of detecting common asymmetric memory patterns and gluing ports together?) | 21:08 |
| lambda | alright, 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 mapping | 21:20 |
| whitequark | so far i think it is | 21:27 |
| whitequark | once everyone agrees with the general design there's gonna be bikeshedding of the names, too | 21:28 |
| whitequark | but not yet | 21:28 |
| lambda | oh sure, I've always expected that to happen, I chose descriptive names for now | 21:30 |
| *** Asu has quit IRC | 21:31 | |
| *** kraiskil_ has quit IRC | 21:33 | |
| lambda | updated the gist, good night :) | 21:51 |
| *** nengel has quit IRC | 22:01 | |
| *** mirage335 has quit IRC | 22:23 | |
| *** mirage335 has joined #yosys | 22:35 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!