clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
<mithro> Does anyone know how to write a sync write, async read DP ram that yosys will understand?
<mithro> I'm going via the " Number of memories: 0" output that I'm not ending up with memories?
<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
<tpb> Title: dpram32.sim.v · GitHub (at gist.github.com)
<ZipCPU> mithro: Are you trying to build a new architecture? I know how to get Yosys to synthesize a current architecture
<mithro> ZipCPU: Maybe if I had an example I could understand how to do what I'm after?
<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
<tpb> Title: Formally Verifying Memory and Cache Components (at zipcpu.com)
<ZipCPU> I also have "rules of memory usage" in my tutorial
<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
<mithro> ZipCPU: I'm not really understanding how to read that post you linked?
<ZipCPU> No? What are you missing?
<ZipCPU> It describes how to describe a memory in Verilog, which Yosys will then infer within hardware
<mithro> ZipCPU: The first heading on that page is "Formal Verifying Memory-like Components", then it moves onto talking about caches....
<ZipCPU> ... and then it goes through the design of a memory, that it then formally verifies
<ZipCPU> The memory design that's referenced should be: https://github.com/ZipCPU/zbasic/blob/master/rtl/memdev.v IIRC
<tpb> Title: zbasic/memdev.v at master · ZipCPU/zbasic · GitHub (at github.com)
<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?
<ZipCPU> AW = address width, DW = data width
<ZipCPU> Let me get a link for the memory definition ...
<ZipCPU> Here's the memory definition itself: https://github.com/ZipCPU/zbasic/blob/master/rtl/memdev.v#L68
<tpb> Title: zbasic/memdev.v at master · ZipCPU/zbasic · GitHub (at github.com)
gsi__ has joined #yosys
<mithro> ZipCPU: I think the thing I actually want is http://zipcpu.com/tutorial/lsn-08-memory.pdf
gsi_ has quit [Ping timeout: 244 seconds]
<mithro> ZipCPU: Yeap! That tutorial has the info I need
<ZipCPU> Ahh ... okay
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #yosys
Cerpin has joined #yosys
lutsabound has joined #yosys
<mithro> ZipCPU: This is what I have ended up with -> https://gist.github.com/mithro/8d8c4ae51644eb74cfd16f12943e3eea
<tpb> Title: dpram32.sim.v · GitHub (at gist.github.com)
<mithro> ZipCPU: I assume the "32 -> BUF -> i" is the initialization data for the memory?
<tpb> Title: dpram32.sim.v · GitHub (at gist.github.com)
<ZipCPU> 32 -> BUF -> i .... which reference was that in?
<mithro> ZipCPU: See the image attached to that gist...
<ZipCPU> Ahh ... .okay
<ZipCPU> What's going on with the $mux on the WR_EN line?
<ZipCPU> That looks a bit superfluous
<ZipCPU> Oh, I think I see what's going on with I
<mithro> ZipCPU: Oh?
<ZipCPU> The 32->BUF->i is the value "i" has at the end of the for loop, right? Where ADDR_LENGTH = 32
<mithro> ZipCPU: Oh... yes...
<ZipCPU> So, ever after, if "i" is referenced it will have the value of 32
<mithro> How do I make it "go away" :-P
<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
<ZipCPU> Perhaps opt_clean ?
<ZipCPU> I think there's an opt_muxtree pass that might even remove the $mux on WR_EN too
<mithro> 2.11.4. Executing OPT_CLEAN pass (remove unused cells and wires).
<mithro> Finding unused cells or wires in module \DPRAM32..
<mithro> I did a `prep -top DPRAM32 ; show -format svg -prefix dpram32.bb.yosys DPRAM32`
<ZipCPU> There's also a "synth" command, which might've made more sense
<mithro> ZipCPU: It seems like synth flattens that mem into DFF and a bunch of other cells...
<ZipCPU> ... which could be quite appropriate, depending upon the actual memory in your device
PyroPeter has quit [Ping timeout: 252 seconds]
<mithro> ZipCPU: I can't see anything in the Yosys manual which would remove that `integer i`?
<ZipCPU> The "integer i" probably wasn't there when the yosys manual was written. I think it was a rather recent addition.
PyroPeter has joined #yosys
<mithro> ZipCPU: Is this the same?
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<ZipCPU> That's the integer i, if that's your question
<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
<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
<ZipCPU> We also had a user complaint about a reference to the loop variable after the loop ended that was ... eye opening.
<ZipCPU> It was one of those, well, gee, I never thought anyone would do that moments
<ZipCPU> That's part of the reason why "i" isn't limited to just the loop alone
<ZipCPU> ... and why it continues to have a definition now that the loop is complete
<mithro> Well, when using genvar it doesn't end up in the output verse the "integer i"?
<mithro> ZipCPU: Interestingly, when I changed it to a generate statement, the linter warned me I had gotten the parameter size wrong...
<ZipCPU> n8
lutsabound has quit [Quit: Connection closed for inactivity]
vonnieda has joined #yosys
gsi__ is now known as gsi_
rohitksingh has joined #yosys
rohitksingh_ has joined #yosys
rohitksingh has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
rohitksingh_ has quit [Client Quit]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
vonnieda has quit [Read error: Connection reset by peer]
_whitelogger has joined #yosys
maikmerten has joined #yosys
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
_whitelogger has joined #yosys
maikmerten has quit [Remote host closed the connection]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
MoeIcenowy has quit [Client Quit]
MoeIcenowy has joined #yosys
_whitelogger has joined #yosys
emeb has joined #yosys