| *** tpb has joined #yosys | 00:00 | |
| mithro | Does anyone know how to write a sync write, async read DP ram that yosys will understand? | 00:15 |
|---|---|---|
| mithro | I'm going via the " Number of memories: 0" output that I'm not ending up with memories? | 00:20 |
| mithro | ZipCPU / daveshah: You seem to know these sort of things... I have the following Verilog at the moment -> https://gist.github.com/mithro/8d8c4ae51644eb74cfd16f12943e3eea | 00:23 |
| tpb | Title: dpram32.sim.v · GitHub (at gist.github.com) | 00:23 |
| ZipCPU | mithro: Are you trying to build a new architecture? I know how to get Yosys to synthesize a current architecture | 01:14 |
| mithro | ZipCPU: Maybe if I had an example I could understand how to do what I'm after? | 01:23 |
| ZipCPU | mithro: This is what I have, which would answer your question if you weren't trying to extend yosys or build a new architecture: http://zipcpu.com/zipcpu/2018/07/13/memories.html | 01:24 |
| tpb | Title: Formally Verifying Memory and Cache Components (at zipcpu.com) | 01:24 |
| ZipCPU | I also have "rules of memory usage" in my tutorial | 01:24 |
| ZipCPU | If you are trying to expand Yosys to support new chips or new hardware, then you'd have to ask daveshah, since I don't have that background | 01:25 |
| mithro | ZipCPU: I'm not really understanding how to read that post you linked? | 01:33 |
| ZipCPU | No? What are you missing? | 01:33 |
| ZipCPU | It describes how to describe a memory in Verilog, which Yosys will then infer within hardware | 01:34 |
| mithro | ZipCPU: The first heading on that page is "Formal Verifying Memory-like Components", then it moves onto talking about caches.... | 01:49 |
| ZipCPU | ... and then it goes through the design of a memory, that it then formally verifies | 01:50 |
| ZipCPU | The memory design that's referenced should be: https://github.com/ZipCPU/zbasic/blob/master/rtl/memdev.v IIRC | 01:50 |
| tpb | Title: zbasic/memdev.v at master · ZipCPU/zbasic · GitHub (at github.com) | 01:50 |
| mithro | ZipCPU: It is also missing a lot of information about things that I would assume need to be explained, IE I assume AW == Address Width? and DW == Data Width? It never seems to describe how and where `mem` object is defined? | 01:51 |
| ZipCPU | AW = address width, DW = data width | 01:52 |
| ZipCPU | Let me get a link for the memory definition ... | 01:52 |
| ZipCPU | Here's the memory definition itself: https://github.com/ZipCPU/zbasic/blob/master/rtl/memdev.v#L68 | 01:53 |
| tpb | Title: zbasic/memdev.v at master · ZipCPU/zbasic · GitHub (at github.com) | 01:53 |
| *** gsi__ has joined #yosys | 01:54 | |
| mithro | ZipCPU: I think the thing I actually want is http://zipcpu.com/tutorial/lsn-08-memory.pdf | 01:55 |
| *** gsi_ has quit IRC | 01:56 | |
| mithro | ZipCPU: Yeap! That tutorial has the info I need | 02:01 |
| ZipCPU | Ahh ... okay | 02:03 |
| *** cr1901_modern has quit IRC | 02:09 | |
| *** cr1901_modern has joined #yosys | 02:13 | |
| *** Cerpin has joined #yosys | 02:14 | |
| *** lutsabound has joined #yosys | 02:14 | |
| mithro | ZipCPU: This is what I have ended up with -> https://gist.github.com/mithro/8d8c4ae51644eb74cfd16f12943e3eea | 02:16 |
| tpb | Title: dpram32.sim.v · GitHub (at gist.github.com) | 02:16 |
| mithro | ZipCPU: I assume the "32 -> BUF -> i" is the initialization data for the memory? | 02:19 |
| mithro | I'm not sure this line is right -> https://gist.github.com/mithro/8d8c4ae51644eb74cfd16f12943e3eea#file-dpram32-sim-v-L27 | 02:20 |
| tpb | Title: dpram32.sim.v · GitHub (at gist.github.com) | 02:20 |
| ZipCPU | 32 -> BUF -> i .... which reference was that in? | 02:26 |
| mithro | ZipCPU: See the image attached to that gist... | 02:26 |
| ZipCPU | Ahh ... .okay | 02:27 |
| ZipCPU | What's going on with the $mux on the WR_EN line? | 02:27 |
| ZipCPU | That looks a bit superfluous | 02:28 |
| ZipCPU | Oh, I think I see what's going on with I | 02:28 |
| mithro | ZipCPU: Oh? | 02:29 |
| ZipCPU | The 32->BUF->i is the value "i" has at the end of the for loop, right? Where ADDR_LENGTH = 32 | 02:29 |
| mithro | ZipCPU: Oh... yes... | 02:29 |
| ZipCPU | So, ever after, if "i" is referenced it will have the value of 32 | 02:29 |
| mithro | How do I make it "go away" :-P | 02:29 |
| ZipCPU | We recently had some ugly bugs we needed to deal with dealing with loop variables, and I think that was part of the solution | 02:29 |
| ZipCPU | Perhaps opt_clean ? | 02:29 |
| ZipCPU | I think there's an opt_muxtree pass that might even remove the $mux on WR_EN too | 02:30 |
| mithro | 2.11.4. Executing OPT_CLEAN pass (remove unused cells and wires). | 02:31 |
| mithro | Finding unused cells or wires in module \DPRAM32.. | 02:31 |
| mithro | I did a `prep -top DPRAM32 ; show -format svg -prefix dpram32.bb.yosys DPRAM32` | 02:31 |
| ZipCPU | There's also a "synth" command, which might've made more sense | 02:32 |
| mithro | ZipCPU: It seems like synth flattens that mem into DFF and a bunch of other cells... | 02:38 |
| ZipCPU | ... which could be quite appropriate, depending upon the actual memory in your device | 02:39 |
| *** PyroPeter has quit IRC | 02:43 | |
| mithro | ZipCPU: I can't see anything in the Yosys manual which would remove that `integer i`? | 02:47 |
| ZipCPU | The "integer i" probably wasn't there when the yosys manual was written. I think it was a rather recent addition. | 02:51 |
| *** PyroPeter has joined #yosys | 02:56 | |
| mithro | ZipCPU: Is this the same? | 03:03 |
| mithro | https://www.irccloud.com/pastebin/46yAANXZ/ | 03:03 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 03:03 |
| ZipCPU | That's the integer i, if that's your question | 03:03 |
| ZipCPU | I know I found some problems with it while building the crossbar I've been working on, which led to this more complete definition | 03:04 |
| ZipCPU | If my case, I had loops upon loops upon loops that all used the same loop variables. That required that the loop variables be kept | 03:04 |
| ZipCPU | We also had a user complaint about a reference to the loop variable after the loop ended that was ... eye opening. | 03:05 |
| ZipCPU | It was one of those, well, gee, I never thought anyone would do that moments | 03:05 |
| ZipCPU | That's part of the reason why "i" isn't limited to just the loop alone | 03:05 |
| ZipCPU | ... and why it continues to have a definition now that the loop is complete | 03:06 |
| mithro | Well, when using genvar it doesn't end up in the output verse the "integer i"? | 03:06 |
| mithro | ZipCPU: Interestingly, when I changed it to a generate statement, the linter warned me I had gotten the parameter size wrong... | 03:07 |
| ZipCPU | n8 | 03:22 |
| *** lutsabound has quit IRC | 04:34 | |
| *** vonnieda has joined #yosys | 05:13 | |
| *** gsi__ is now known as gsi_ | 05:25 | |
| *** rohitksingh has joined #yosys | 06:36 | |
| *** rohitksingh_ has joined #yosys | 07:10 | |
| *** rohitksingh has quit IRC | 07:11 | |
| *** rohitksingh_ has quit IRC | 07:11 | |
| *** MoeIcenowy has quit IRC | 07:28 | |
| *** MoeIcenowy has joined #yosys | 07:28 | |
| *** vonnieda has quit IRC | 08:21 | |
| *** _whitelogger has quit IRC | 10:32 | |
| *** _whitelogger has joined #yosys | 10:34 | |
| *** maikmerten has joined #yosys | 11:06 | |
| *** MoeIcenowy has quit IRC | 11:20 | |
| *** MoeIcenowy has joined #yosys | 11:20 | |
| *** _whitelogger has quit IRC | 11:29 | |
| *** _whitelogger has joined #yosys | 11:31 | |
| *** maikmerten has quit IRC | 12:42 | |
| *** MoeIcenowy has quit IRC | 12:47 | |
| *** MoeIcenowy has joined #yosys | 12:47 | |
| *** MoeIcenowy has quit IRC | 12:52 | |
| *** MoeIcenowy has joined #yosys | 12:52 | |
| *** _whitelogger has quit IRC | 14:11 | |
| *** _whitelogger has joined #yosys | 14:13 | |
| *** emeb has joined #yosys | 14:57 | |
| *** vonnieda has joined #yosys | 16:19 | |
| *** Laksen has joined #yosys | 16:23 | |
| *** vonnieda has quit IRC | 20:08 | |
| *** vonnieda has joined #yosys | 20:13 | |
| *** Laksen has quit IRC | 20:26 | |
| *** vonnieda has quit IRC | 22:45 | |
| *** emeb has quit IRC | 23:22 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!