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:
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_))]
specing_ is now known as specing
kittennbfive has joined ##openfpga
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined ##openfpga
<kittennbfive> Hello again. Still messing with EBR on ECP5... I wonder how these initialiation-values work.
<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: - 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
kittennbfive has quit [Quit: Leaving]
lain has quit [Quit: brb!]
lain has joined ##openfpga
tokomak has joined ##openfpga