00:06 <mithro> Does anyone know how to write a sync write, async read DP ram that yosys will understand?

00:12 <mithro> I'm going via the " Number of memories: 0" output that I'm not ending up with memories?

00:15 <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:15 <tpb> Title: dpram32.sim.v · GitHub (at gist.github.com)

01:06 <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:16 <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:16 <tpb> Title: Formally Verifying Memory and Cache Components (at zipcpu.com)

01:16 <ZipCPU> I also have "rules of memory usage" in my tutorial

01:17 <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:24 <mithro> ZipCPU: I'm not really understanding how to read that post you linked?

01:25 <ZipCPU> No? What are you missing?

01:25 <ZipCPU> It describes how to describe a memory in Verilog, which Yosys will then infer within hardware

01:41 <mithro> ZipCPU: The first heading on that page is "Formal Verifying Memory-like Components", then it moves onto talking about caches....

01:41 <ZipCPU> ... and then it goes through the design of a memory, that it then formally verifies

01:42 <ZipCPU> The memory design that's referenced should be: https://github.com/ZipCPU/zbasic/blob/master/rtl/memdev.v IIRC

01:42 <tpb> Title: zbasic/memdev.v at master · ZipCPU/zbasic · GitHub (at github.com)

01:43 <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:43 <ZipCPU> AW = address width, DW = data width

01:44 <ZipCPU> Let me get a link for the memory definition ...

01:44 <ZipCPU> Here's the memory definition itself: https://github.com/ZipCPU/zbasic/blob/master/rtl/memdev.v#L68

01:44 <tpb> Title: zbasic/memdev.v at master · ZipCPU/zbasic · GitHub (at github.com)

01:47 <mithro> ZipCPU: I think the thing I actually want is http://zipcpu.com/tutorial/lsn-08-memory.pdf

01:53 <mithro> ZipCPU: Yeap! That tutorial has the info I need

01:54 <ZipCPU> Ahh ... okay

02:07 <mithro> ZipCPU: This is what I have ended up with -> https://gist.github.com/mithro/8d8c4ae51644eb74cfd16f12943e3eea

02:07 <tpb> Title: dpram32.sim.v · GitHub (at gist.github.com)

02:11 <mithro> ZipCPU: I assume the "32 -> BUF -> i" is the initialization data for the memory?

02:11 <mithro> I'm not sure this line is right -> https://gist.github.com/mithro/8d8c4ae51644eb74cfd16f12943e3eea#file-dpram32-sim-v-L27

02:11 <tpb> Title: dpram32.sim.v · GitHub (at gist.github.com)

02:17 <ZipCPU> 32 -> BUF -> i .... which reference was that in?

02:18 <mithro> ZipCPU: See the image attached to that gist...

02:18 <ZipCPU> Ahh ... .okay

02:19 <ZipCPU> What's going on with the $mux on the WR_EN line?

02:19 <ZipCPU> That looks a bit superfluous

02:20 <ZipCPU> Oh, I think I see what's going on with I

02:20 <mithro> ZipCPU: Oh?

02:20 <ZipCPU> The 32->BUF->i is the value "i" has at the end of the for loop, right? Where ADDR_LENGTH = 32

02:20 <mithro> ZipCPU: Oh... yes...

02:21 <ZipCPU> So, ever after, if "i" is referenced it will have the value of 32

02:21 <mithro> How do I make it "go away" :-P

02:21 <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:21 <ZipCPU> Perhaps opt_clean ?

02:22 <ZipCPU> I think there's an opt_muxtree pass that might even remove the $mux on WR_EN too

02:22 <mithro> 2.11.4. Executing OPT_CLEAN pass (remove unused cells and wires).

02:22 <mithro> Finding unused cells or wires in module \DPRAM32..

02:23 <mithro> I did a `prep -top DPRAM32 ; show -format svg -prefix dpram32.bb.yosys DPRAM32`

02:24 <ZipCPU> There's also a "synth" command, which might've made more sense

02:30 <mithro> ZipCPU: It seems like synth flattens that mem into DFF and a bunch of other cells...

02:30 <ZipCPU> ... which could be quite appropriate, depending upon the actual memory in your device

02:39 <mithro> ZipCPU: I can't see anything in the Yosys manual which would remove that `integer i`?

02:42 <ZipCPU> The "integer i" probably wasn't there when the yosys manual was written. I think it was a rather recent addition.

02:54 <mithro> ZipCPU: Is this the same?

02:54 <mithro> https://www.irccloud.com/pastebin/46yAANXZ/

02:54 <tpb> Title: Snippet | IRCCloud (at www.irccloud.com)

02:55 <ZipCPU> That's the integer i, if that's your question

02:56 <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

02:56 <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

02:56 <ZipCPU> We also had a user complaint about a reference to the loop variable after the loop ended that was ... eye opening.

02:57 <ZipCPU> It was one of those, well, gee, I never thought anyone would do that moments

02:57 <ZipCPU> That's part of the reason why "i" isn't limited to just the loop alone

02:57 <ZipCPU> ... and why it continues to have a definition now that the loop is complete

02:58 <mithro> Well, when using genvar it doesn't end up in the output verse the "integer i"?

02:58 <mithro> ZipCPU: Interestingly, when I changed it to a generate statement, the linter warned me I had gotten the parameter size wrong...

03:13 <ZipCPU> n8