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
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined ##openfpga
tokomak has quit [Read error: Connection reset by peer]
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
specing_ has joined ##openfpga
specing has quit [Killed (NickServ (GHOST command used by specing_))]
<kittennbfive>
I can see there are 64 values of 320 bits each, that 20480 bits total, not 18000 or 18*1024 (but 20*1024)
<kittennbfive>
is there some checksum or sth?
<tnt>
No, AFAIR there are just 2 unused bits per group of 18.
<tnt>
so it "aligns" nicer.
<kittennbfive>
ok, thank you.
<kittennbfive>
so... if i have a width of 9 bits for read (and write), how do i need to initialize this memory?
<kittennbfive>
something like .INITVAL_00('b00_000001000_000000100_00_000000010_000000001) for a simple shifting bit?
<kittennbfive>
(my code does not work so i need to eliminate as much other errors as possible because i can't simulate this RAM component)
<kittennbfive>
(PDPW16KD with write enable tied to GND so used as kind of a ROM at this point btw)
<tnt>
(1) Do you really need to instanciate instead of infer ? Usually for simple ram, the latter is easier unless you need some "un-inferrable" features (like different port width or stuff like that).
<tnt>
(2) Why can't you simulate the RAM ?
<kittennbfive>
(1) i want to learn :-) (2) there is no model (afaik) for this component yet
<tnt>
mmm, yeah looks like the ecp5 sim libs are rather bare compared to ice40. you can grab models from diamond if needed.
<kittennbfive>
i dont have diamond but yeah, i might need to look at it... i also looked at the output of nextpnr, the initialization values are written as groups of 3 hex digits, but i still can't figure out how this works. more time needed...
<kittennbfive>
(i assume all this has been tested so the bug is in my code or in my brain, not in the FOSS-toolchain?)
lopsided98 has quit [Ping timeout: 265 seconds]
cyrozap has quit [Ping timeout: 240 seconds]
cyrozap has joined ##openfpga
ZipCPU_ has joined ##openfpga
ZipCPU has quit [Ping timeout: 246 seconds]
ZipCPU_ is now known as ZipCPU
<kittennbfive>
Am i correct, this Diamond stuff for Linux, this is Red Hat only? Thats annoying...
<mewt>
in prctice the answer might be different, unsupported != doesn't work, no?
<tnt>
yeah, it's just annoying to install but it runs fine on other distros.
<tnt>
I had to unpack a bunch of rpm manually and place things properly ...
<kittennbfive>
thanks for this information! i will probably try it.
lopsided98 has joined ##openfpga
<kittennbfive>
ok, diamond is a mess, i don't had enough memory in my VM and i don't want to deal with this licencing stuff. however i made progress, at least for a data width of 4 bits i understood the initialisation pattern of PDPW16KD - i hope.
<kittennbfive>
once i really understood this, should i write some doc and push it to my github or is this useless?
<agg>
kittennbfive: if you have diamond extracted, go to /ispfpga/verilog/data/ecp5u and check out DP16KD.v and PDPW16KD.v
<agg>
for diamond'
<agg>
's sim models
<kittennbfive>
thank you, will look at this!
<agg>
those sim models are also the best documentation i've been able to find on the DSP units :p
jemk has quit [Quit: Lost terminal]
jemk has joined ##openfpga
<kittennbfive>
mmm, don't even want to look at this fancy stuff like DSP. for the moment it looks like i have a working 36 bits FIFO, but "only" on real hardware, didn't manage to make the simulation work...
<tnt>
usually it's the other way around :D
<kittennbfive>
yeah :D
specing_ has joined ##openfpga
specing has quit [Killed (NickServ (GHOST command used by specing_))]
specing_ is now known as specing
<kittennbfive>
may i bother you again with a quick Verilog question?
<kittennbfive>
those EBR have their busses defined as single bit ports, so i have to write like .DI0(data_write[0]), .DI1(data_write[1]), .DI2(data_write[2]), and so on. Is there a way to group this and write sth like .DI(data_write) <-- this does not work ?
<tnt>
no
<kittennbfive>
ok... Perl to the rescue :-) thank you.
<tnt>
That's because for some f**** up reason lattice decided to do it that way instead of declaring the ports are multi bit .
<kittennbfive>
ah ok and Yosys needs to maintain compatibility. i understand.
<tnt>
yeah, tbh, it's probably be good to have a single 'wrapper' file that translate all the primitives to a _SANE version with things grouped.
<kittennbfive>
INSANE is sometimes more fun :-)
<kittennbfive>
(scnr)
ZipCPU has quit [Remote host closed the connection]
ZipCPU has joined ##openfpga
emeb has joined ##openfpga
ZipCPU has quit [Ping timeout: 240 seconds]
ZipCPU has joined ##openfpga
Maylay has quit [Read error: Connection reset by peer]
Maylay has joined ##openfpga
kittennbfive has quit [Quit: Leaving]
emeb has quit [Ping timeout: 268 seconds]
kittennbfive has joined ##openfpga
<kittennbfive>
tnt: i thought about your idea of a "primitive_SANE" file and hacked some code. example here: https://paste.debian.net/1205066/ - but would this compile because of .PARAM(SAME_NAME_HERE)? (and same for the single bit IO)
<kittennbfive>
and if not, can we find a way to fix this?
<tnt>
huh sure that should work
<tnt>
also ... don't mark it as blackbox ...
<kittennbfive>
uh, great, i thought there would be some naming conflicts. noted for the blackbox-thing, i will remove these hints from the output file