strongsaxophone has quit [Remote host closed the connection]
klotz has quit [Quit: klotz]
emeb has quit [Quit: Leaving.]
rohitksingh has joined #yosys
emeb_mac has joined #yosys
rohitksingh has quit [Ping timeout: 248 seconds]
citypw has joined #yosys
az0re has quit [Quit: Leaving]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined #yosys
ZipCPU has joined #yosys
lutsabound has quit [Quit: Connection closed for inactivity]
emeb_mac has quit [Quit: Leaving.]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 258 seconds]
Cerpin has quit [Ping timeout: 260 seconds]
kraiskil has joined #yosys
m4ssi has joined #yosys
adjtm has quit [Remote host closed the connection]
adjtm has joined #yosys
fsasm has joined #yosys
dys has joined #yosys
fsasm has quit [Quit: Leaving]
rohitksingh has quit [Ping timeout: 240 seconds]
kraiskil has quit [Ping timeout: 255 seconds]
twnqx has joined #yosys
kraiskil has joined #yosys
doubleyou has joined #yosys
kraiskil has quit [Ping timeout: 258 seconds]
ZipCPU has quit [Remote host closed the connection]
kraiskil has joined #yosys
voxadam has quit [Ping timeout: 260 seconds]
Cerpin has joined #yosys
emeb has joined #yosys
citypw has quit [Ping timeout: 258 seconds]
fsasm has joined #yosys
dys has quit [Ping timeout: 248 seconds]
X-Scale` has joined #yosys
strubi has joined #yosys
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
<strubi>
Hi there, sorry for the first newbie question, possibly: I'm playing with RAM inference, in particular, I'd wanted to get some true dual port RAM working. Is it sufficient to modify what's in share/<arch and techlibs/<arch>?
<strubi>
(arch is ECP5, in this case)
thardin has left #yosys [#yosys]
m4ssi has quit [Remote host closed the connection]
<daveshah>
No, the Yosys BRAM passes don't support it at all
<daveshah>
There are a few possible ways you could hack it but truth be told the BRAM inference code is enough of a mess as it stands
<strubi>
So, it would involve touching `./passes/memory/memory_bram.cc` as well?
<daveshah>
Yes
<daveshah>
Or burning it and starting again, which would probably be the more tempting option
<strubi>
Uh oh. Well, I assume there's a test bench..
<daveshah>
Yes, although plenty of subtle untested bugs have cropped up in bram code in the past
<strubi>
I think I've run into some. But really hard to tell, as I'm playing with the GHDL side, mostly
<strubi>
But now mimicking things in Verilog, there's some weirdness as well
kraiskil has quit [Ping timeout: 255 seconds]
Sarayan has joined #yosys
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh has joined #yosys
<strubi>
daveshah, what I can see so far in the synth .dot output ('show') is that different clocks (like a_clk, b_clk) seem to not correctly map to the $mem entity in the first place.
<strubi>
tried both verilog and VHDL
<strubi>
I
<strubi>
Not sure, but it looks like it's happening during the memory_collect pass
<strubi>
Verilog parsing seems right though. So in pre.dot it's split up in $memrd and $memwr ports. GHDL doesn't do that and directly creates a $mem, obviously.
<daveshah>
Yes, the problem is in memory_dff
vidbina has joined #yosys
<strubi>
Allright, now when working around the memory_dff issue (using the proper template for a read-after-write) the clocks map right.
<strubi>
Thanks for the hint! This helps to divide-et-impera :-)
Ristovski has quit [Ping timeout: 258 seconds]
twnqx has quit [Quit: Leaving]
[Ristovski] has joined #yosys
emeb_mac has joined #yosys
fsasm has quit [Remote host closed the connection]