azonenberg changed the topic of ##openfpga to: Open source tools for FPGAs, CPLDs, etc. Silicon RE, bitfile RE, synthesis, place-and-route, and JTAG are all on topic. Channel logs: https://libera.irclog.whitequark.org/~h~openfpga
X-Scale has joined ##openfpga
emeb_mac has quit [Ping timeout: 276 seconds]
sgstair_ is now known as sgstair
emeb_mac has joined ##openfpga
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 245 seconds]
Degi_ is now known as Degi
specing has quit [Killed (NickServ (GHOST command used by specing_))]
specing_ has joined ##openfpga
specing_ is now known as specing
emeb_mac has quit [Quit: Leaving.]
tokomak has quit [Ping timeout: 250 seconds]
specing_ has joined ##openfpga
specing has quit [Killed (NickServ (GHOST command used by specing_))]
specing_ is now known as specing
emeb has joined ##openfpga
balrog_ is now known as balrog
kittennbfive has joined ##openfpga
<kittennbfive>
sorry for bothering you again... still ECP5 EBR stuff: I try to use the Lattice models to simulate the use of a PDPW16KD (pseudo port dual RAM) with Icarus Verilog. ...
<kittennbfive>
If i leave .DATA_WIDTH_R as 36 i don't get any output of this stupid EBR. If i change it to 18 or 9 i get output.
<kittennbfive>
Did anybody try these models from Lattice with .DATA_WIDTH_R(36)?
<kittennbfive>
According to their reference manual this value should be fine.
duck26 is now known as duck2
<kittennbfive>
Are we actually sure that 36 bit wide EBR do actually work? In the latest Memory Usage Guide it still shows the primitive with 18 Bit buses for Read and Write. And i have working (on real hardware) code for 9 and 18 bits width, but it fails for 36...
<gatecat>
yeah 36 bit definitely works on hardware
<agg>
the DP16KD sim model in diamond only does 18 bit though it seems
<agg>
the comment on DATA_WIDTH_A suggests it would take 1, 2, 3, 9, 18, or 36, but the code using it doesn't handle a 36 case, and in any event the module only has 18 data port bits
<gatecat>
mm, you have to use PDPW16KD for 36 bit wide
<agg>
the PDPW16KD does look like it would support 36 bits, but it instantiates a DP16KD model and then sets its data width to 36?
<gatecat>
the hardware concatenates DIA/DIB and DOA/DOB to get the 36 bit width, maybe the model does too ?
<kittennbfive>
"or 512x36 pseudo dual port (this mode not implemented in Yosys/nextpnr yet, it uses a different PDPW16KD primitive)."
<gatecat>
it is supported now
<kittennbfive>
uh sorry, i didn't see your replies
<gatecat>
no worries
sgstair has quit [Remote host closed the connection]
sgstair has joined ##openfpga
egg|cell|egg has quit [Ping timeout: 258 seconds]
<kittennbfive>
ok, this is really messing with my sanity, but i think i found it:
<kittennbfive>
for 36 bits there is some weird mapping going on, ie to get output[31:0] you have to map your input as {[18:35],[17:0]} or sth like this. what???
<kittennbfive>
correction: {[35:18],[17:0]}
<kittennbfive>
uh no
<kittennbfive>
well, something. i am confused, sorry
<kittennbfive>
okay, so if i had looked at the source of Yosys... well. i will document this on my github and probably and some example code later
<kittennbfive>
ty!
emeb_mac has joined ##openfpga
<kittennbfive>
and a final note: I can finally confirm that the simulation works with 36 bits input too. Beside the mapping there seems to be an additional delay of one clock cycle before you get valid output data, at least with REGMODE(OUTREG).
<tnt>
well ... yeah ... that's what the output register does ...
<kittennbfive>
mmm, no, i wanted to say: with REGMODE(OUTREG) there is one more cycle delay with 36 bits compared to <36 bits
<kittennbfive>
without REGMODE(OUTREG) i don't know, did not check
ZipCPU has quit [Ping timeout: 252 seconds]
ZipCPU has joined ##openfpga
kittennbfive has quit [Quit: Leaving]
balrog has quit [Ping timeout: 265 seconds]
balrog has joined ##openfpga
egg|cell|egg has joined ##openfpga
sgstair has quit [Read error: Connection reset by peer]