<whitequark>
yosys uses this macro for transparent read ports
<whitequark>
if you think "this will do the wrong thing if i add a read enable", well, that's correct
<whitequark>
and in fact yosys can't represent correct transparent ports with read enable
_whitelogger has joined #yosys
<Guest40933>
huh
<Guest40933>
how should i go about implementing this then?
<Guest40933>
or alternatively what if i make o_data a don't-care when i_we is high
emeb_mac has quit [Quit: Leaving.]
jakobwenzel has joined #yosys
<whitequark>
do you mean transparent ports with read enable specifically, or in general?
<tnt>
Guest40933: in your wrapper if you remov the 'else' and just always do "o_data <= ram[i_addr];" you will get a DP16KD
<whitequark>
tnt: that's a non-transparent port
<tnt>
Sure but his original code was also non-transparent.
<whitequark>
are you sure?
<whitequark>
seems transparent to me due to o_data <= i_data;
<whitequark>
<tnt>
and he just suggested above replacing o_data with don't care when i_we is high.
<whitequark>
and it's explicitly requested in the file header
<whitequark>
yeah, ok, makes sense
<tnt>
Oh ... I had missed the o_data <= i_data;
<tnt>
Implementing it with the common transparent read patter you sugested above also yields a DP16KD.
<tnt>
Which has me a bit confused because AFAIK the ECP5 can't switch between the two modes.
<tnt>
(and I don't see any added logic around it)
<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.
<whitequark>
yosys adds transparency logic for ice40
<daveshah>
ECP5 does support transparent BRAM, or at least has a WRITEMODE option for that
<tnt>
daveshah: Oh you're right ... nm me I'm bling apparently
Asu has joined #yosys
nurelin has quit [Ping timeout: 256 seconds]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 256 seconds]
kraiskil has joined #yosys
jfcaron has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
develonepi3 has joined #yosys
craigo has joined #yosys
somlo has quit [Remote host closed the connection]
somlo has joined #yosys
daknig has joined #yosys
emeb has joined #yosys
cr1901_modern has quit [Ping timeout: 246 seconds]
cr1901_modern has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
nengel has quit [Ping timeout: 256 seconds]
<Guest40933>
even with the always "o_data <= ram[i_addr];" its still having the same issue
kgugala has quit [Ping timeout: 264 seconds]
<ZipCPU>
Gues40933: Are you initializing o_data at all?
<ZipCPU>
Try getting rid of any initial values in o_data
kgugala_ has joined #yosys
<Guest40933>
ZipCPU: nope, o_data is not initialized
<Guest40933>
i tried doing it with a trivial minimal example and had the same issue as well
<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
kgugala has joined #yosys
kgugala_ has quit [Ping timeout: 246 seconds]
kraiskil has quit [Ping timeout: 265 seconds]
<ZipCPU>
Guest40933: Did you post the repository having problems somewhere?
<Guest40933>
yep thats the code thats having the issue
<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?
<ZipCPU>
or ... immediately available on the next cycle is I think what you want, right?