| *** tpb has joined #yosys | 00:00 | |
| *** mwk has quit IRC | 00:25 | |
| *** cr1901_modern has quit IRC | 00:31 | |
| *** mwk has joined #yosys | 00:32 | |
| *** cr1901_modern has joined #yosys | 01:03 | |
| *** X-Scale` has joined #yosys | 02:11 | |
| *** X-Scale has quit IRC | 02:12 | |
| *** X-Scale` is now known as X-Scale | 02:12 | |
| *** Degi has quit IRC | 02:21 | |
| *** Degi has joined #yosys | 02:22 | |
| *** cr1901_modern has quit IRC | 02:44 | |
| *** citypw has joined #yosys | 02:55 | |
| *** cr1901_modern has joined #yosys | 03:00 | |
| *** asinghan2 is now known as test | 03:25 | |
| *** test is now known as Guest45652 | 03:25 | |
| *** cr1901_modern has quit IRC | 03:26 | |
| *** Guest40933 has joined #yosys | 03:26 | |
| Guest40933 | Hello, I'm having some trouble with inferring BRAM on ECP5 when using yosys and nextpnr-ecp5 | 03:27 |
|---|---|---|
| Guest40933 | Whatever I do, I can't get it to infer a BRAM | 03:28 |
| Guest40933 | it always infers either FFs or distributed memories | 03:28 |
| Guest40933 | Relevant lines from the yosys.log : https://termbin.com/zxwz | 03:28 |
| Guest40933 | "Read port #0 is in clock domain !~async~." | 03:28 |
| Guest40933 | and this is my block RAM wrapper https://termbin.com/av32 | 03:29 |
| Guest40933 | It appears to be meeting all the requirements for BRAM to be inferred | 03:30 |
| Guest40933 | But it's not being inferred | 03:30 |
| *** cr1901_modern has joined #yosys | 03:35 | |
| *** Forty-Bot has quit IRC | 04:08 | |
| *** Forty-Bot has joined #yosys | 04:10 | |
| Guest40933 | also - is there any way to instantiate a block RAM-based FIFO or do i just have to implement it manually? | 04:13 |
| *** _whitelogger has quit IRC | 04:18 | |
| *** _whitelogger has joined #yosys | 04:20 | |
| whitequark | you have to implement a FIFO manually | 04:21 |
| Guest40933 | Hmm okay | 04:22 |
| Guest40933 | Any idea on the inference issue? | 04:22 |
| whitequark | not sure, let me check | 04:24 |
| whitequark | Guest40933: you want a transparent read port, right? | 04:32 |
| Guest40933 | whitequark: what exactly does that mean? | 04:34 |
| whitequark | // During write-cycles, i_data is passed through to o_data. | 04:35 |
| whitequark | that means "transparent read port" | 04:35 |
| Guest40933 | ah | 04:36 |
| Guest40933 | yeah that's what i need | 04:36 |
| *** craigo has quit IRC | 05:05 | |
| *** josi has joined #yosys | 05:32 | |
| whitequark | Guest40933: https://paste.debian.net/1152124/ | 06:05 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 06:05 |
| whitequark | yosys uses this macro for transparent read ports | 06:05 |
| whitequark | if you think "this will do the wrong thing if i add a read enable", well, that's correct | 06:05 |
| whitequark | and in fact yosys can't represent correct transparent ports with read enable | 06:07 |
| *** _whitelogger has quit IRC | 06:42 | |
| *** _whitelogger has joined #yosys | 06:44 | |
| Guest40933 | huh | 06:53 |
| Guest40933 | how should i go about implementing this then? | 06:53 |
| Guest40933 | or alternatively what if i make o_data a don't-care when i_we is high | 06:53 |
| *** emeb_mac has quit IRC | 06:55 | |
| *** jakobwenzel has joined #yosys | 07:04 | |
| whitequark | do you mean transparent ports with read enable specifically, or in general? | 07:19 |
| tnt | Guest40933: in your wrapper if you remov the 'else' and just always do "o_data <= ram[i_addr];" you will get a DP16KD | 07:55 |
| whitequark | tnt: that's a non-transparent port | 08:17 |
| tnt | Sure but his original code was also non-transparent. | 08:18 |
| whitequark | are you sure? | 08:18 |
| whitequark | seems transparent to me due to o_data <= i_data; | 08:19 |
| whitequark | 08:19 | |
| tnt | and he just suggested above replacing o_data with don't care when i_we is high. | 08:19 |
| whitequark | and it's explicitly requested in the file header | 08:19 |
| whitequark | yeah, ok, makes sense | 08:19 |
| tnt | Oh ... I had missed the o_data <= i_data; | 08:19 |
| tnt | Implementing it with the common transparent read patter you sugested above also yields a DP16KD. | 08:23 |
| tnt | Which has me a bit confused because AFAIK the ECP5 can't switch between the two modes. | 08:23 |
| tnt | (and I don't see any added logic around it) | 08:24 |
| tnt | I guess yosys is more like "user better know what he's doing" ... because calling synth_ice40 also yield SB_RAM40_4K even thoug it's explicitely stated that read/write at the same address is undefined behavior. | 08:29 |
| whitequark | yosys adds transparency logic for ice40 | 08:29 |
| daveshah | ECP5 does support transparent BRAM, or at least has a WRITEMODE option for that | 08:30 |
| tnt | daveshah: Oh you're right ... nm me I'm bling apparently | 08:33 |
| *** Asu has joined #yosys | 08:38 | |
| *** nurelin has quit IRC | 08:56 | |
| *** kraiskil has joined #yosys | 09:37 | |
| *** kraiskil has quit IRC | 10:34 | |
| *** kraiskil has joined #yosys | 10:48 | |
| *** jfcaron has joined #yosys | 10:50 | |
| *** futarisIRCcloud has quit IRC | 11:51 | |
| *** develonepi3 has joined #yosys | 12:25 | |
| *** craigo has joined #yosys | 13:08 | |
| *** somlo has quit IRC | 13:23 | |
| *** somlo has joined #yosys | 13:25 | |
| *** daknig has joined #yosys | 13:43 | |
| *** emeb has joined #yosys | 13:53 | |
| *** cr1901_modern has quit IRC | 14:50 | |
| *** cr1901_modern has joined #yosys | 14:51 | |
| *** citypw has quit IRC | 16:30 | |
| *** nengel has quit IRC | 17:48 | |
| Guest40933 | even with the always "o_data <= ram[i_addr];" its still having the same issue | 17:52 |
| *** kgugala has quit IRC | 18:05 | |
| ZipCPU | Gues40933: Are you initializing o_data at all? | 18:06 |
| ZipCPU | Try getting rid of any initial values in o_data | 18:06 |
| *** kgugala_ has joined #yosys | 18:10 | |
| Guest40933 | ZipCPU: nope, o_data is not initialized | 18:14 |
| Guest40933 | i tried doing it with a trivial minimal example and had the same issue as well | 18:17 |
| Guest40933 | where the i_addr was just some DIP switches (2FF-syncronized of course) and the o_data was a register and it still had the same error when inferring BRAM | 18:18 |
| *** kgugala has joined #yosys | 18:29 | |
| *** kgugala_ has quit IRC | 18:29 | |
| *** kraiskil has quit IRC | 19:15 | |
| ZipCPU | Guest40933: Did you post the repository having problems somewhere? | 19:24 |
| ZipCPU | Ok ... I'm looking at https://termbin.com/av32 ... I assume this is what's going on? | 19:25 |
| Guest40933 | yep thats the code thats having the issue | 19:27 |
| ZipCPU | ... and your goal is a first-write-fall-through FIFO? (If I have the right name ...) where a write on one cycle is immediately available on the same cycle? | 19:28 |
| ZipCPU | or ... immediately available on the next cycle is I think what you want, right? | 19:29 |
| ZipCPU | Did you try using an assign, as in line 62 of https://paste.debian.net/1152124/ ? | 19:33 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 19:33 |
| *** FFY00 has quit IRC | 19:56 | |
| *** FFY00 has joined #yosys | 19:57 | |
| thardin | is signed right shift defined in verilog? that is, is x>>1 == x/2 ? | 20:15 |
| ZipCPU | Check out ">>>" | 20:15 |
| thardin | so >>> is arithmetic shift, cool | 20:20 |
| thardin | thanks for the tip :) | 20:20 |
| *** emeb_mac has joined #yosys | 20:36 | |
| Guest40933 | Huh very interesting | 20:37 |
| Guest40933 | assign o_data = ram[r_addr]; | 20:37 |
| Guest40933 | that seems to have fixed it | 20:37 |
| Guest40933 | but... wouldn't that be implying an async read? | 20:39 |
| daveshah | no, if the address is registered then it is a sync, but transparent, read | 20:39 |
| daveshah | if the address is unregistered then indeed it would be an async read | 20:39 |
| Guest40933 | oh huh | 20:40 |
| Guest40933 | so what would be on o_data on the cycle immediately after one where i_we is high? | 20:41 |
| Guest40933 | would it be the data that was just written, or is it undefined | 20:41 |
| daveshah | it would be the data that was just written | 20:42 |
| thardin | grmbl nextpnr doesn't exit(1) on errore | 20:44 |
| daveshah | what error? | 20:44 |
| Guest40933 | ah | 20:46 |
| *** jfcaron has quit IRC | 20:48 | |
| *** jakobwenzel has quit IRC | 20:59 | |
| thardin | daveshah: whenever a design is too big to fit | 21:02 |
| daveshah | How is it failing in that case? | 21:06 |
| thardin | ERROR: Failed to expand region (0, 0) |_> (13, 17) of 1318 ICESTORM_LCs | 21:09 |
| *** Asuu has joined #yosys | 22:05 | |
| *** Asu has quit IRC | 22:05 | |
| *** Asuu has quit IRC | 22:12 | |
| *** maartenBE has joined #yosys | 22:25 | |
| *** dys has quit IRC | 22:39 | |
| *** emeb has quit IRC | 22:56 | |
| *** N2TOH_ has joined #yosys | 23:30 | |
| *** N2TOH has quit IRC | 23:33 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!