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
specing has quit [Killed (NickServ (GHOST command used by specing_))]
specing_ has joined ##openfpga
specing_ is now known as specing
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
egg|cell|egg has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
specing has quit [Killed (NickServ (GHOST command used by specing_))]
specing_ has joined ##openfpga
specing_ is now known as specing
hackkitten has quit [Ping timeout: 255 seconds]
hackkitten has joined ##openfpga
benreynwar_ is now known as benreynwar
Raito_Bezarius has quit [Ping timeout: 255 seconds]
Raito_Bezarius has joined ##openfpga
emeb has joined ##openfpga
jemk has quit [Read error: Connection reset by peer]
jemk_ has joined ##openfpga
kittennbfive has joined ##openfpga
<kittennbfive>
Hello, may i bother you with a question? ECP5 EBR-stuff as usual with Yosys of course. I have some autogenerated Verilog (by a Perlscript i am writing) that implements a FIFO using manual instatiation. The EBR (2 of them but this is not important) have .REGMODE("OUTREG") and their output goes into some "splicer" that makes the FIFO-module output a portion of the entire data-word
<kittennbfive>
If i put this "splicer"-code inside the FIFO-module i get a real bad f_max, but if i put it into the top-level fpga.v i get more than 2*f_max.
<kittennbfive>
So: Is there something to know about using the outputs(!) of those EBR? Should i upload some code for you to have a look?
<tnt>
There is no reason it would make any difference.
<tnt>
Also 130 MHz is pretty good for an ECP5 ...
<tnt>
My guess is it's just random PnR variation because you're not constraining the clock. If it meets the frequency, PnR will be happy, no point in trying to do better than what's requested.
<kittennbfive>
Uh ok... So random PnR variations can have a HUGE impact on fmax... Ty!
<tnt>
well especially for high fmax where even a small delay change results in a large frequency change.
<tnt>
It's either that ... or you're screwing up something.
<tnt>
But one of the very first step of synthesis is to flatten the design / remove hierarchy to put everything at the same level ... so it doesn't matter where you put your splicer.
<kittennbfive>
I think i must be screwing up something... I have created a small testcase, both versions pass iverilog -Wall but one geht 149MHz and one 254MHz. I will upload them so maybe you or somebody could have a look.
_whitelogger has joined ##openfpga
<gatecat>
quite possibly not, as OUTREG isn't inferred by Yosys it won't have much test coverage...
<gatecat>
I can do some testing tomorrow
<kittennbfive>
Ok, i don't understand what you are talking about but i appreciate your investigations!
<kittennbfive>
Feel free to use my code!
<tnt>
kittennbfive: there might be a bug in next pnr. The PDP16K is a special mode of the DP16K where both 18bits read and write ports are reassigned to combine them in a "read" and a "write" sides but 36 bit. But it looks like the output register might only end up being enabled on half of the bits. Leading to slow timings on the "A" side (and they don't change with/without outreg enabled) and possibly a bug in hardware where half the bits are not in sync.
<kittennbfive>
ok, i understand, ty for this explanation!
<kittennbfive>
just out of curiosity, i looked at the out.cfg (from nextpnr) and indeed: enum: EBR2.REGMODE_A NOREG \n enum: EBR2.REGMODE_B OUTREG
<tnt>
yeah, from the code, I'd expect that. Not sure if this has any hw impact or if the fact it gets set to pdp mode overrides that settings.
<tnt>
but at the very least it impacts the timing analysis and processes the clock-to-out of port A as if there was no register.
emeb_mac has joined ##openfpga
<gatecat>
tnt/kittennbfive: I think this patch should fix the issue. But I'd rather do some quick tests on hardware before merging tomorrow: https://github.com/YosysHQ/nextpnr/pull/789
<kittennbfive>
Wow, you are quick! Can i help you in some way? I have an ECP5 but no quick logic analyzer.
emeb_mac has quit [Ping timeout: 272 seconds]
<tnt>
kittennbfive: I'm pretty sure talking you through the testing process would take more time than doing it locally.
<kittennbfive>
I understand, no problem :-)
<tnt>
gatecat: I'm wondering of the nexus code might have the same issue ?
emeb_mac has joined ##openfpga
<tnt>
code looks quite different though, not even sure how it works.
<tnt>
nm, it's handled differently, writing OUTREG value directly. But not sure where it takes that into account for timings.
<gatecat>
looks like it isn't handling it at all for timing yet
<gatecat>
it's not _as_ important as for ECP5 as iirc the base clock-out delay isn't so ridiculously high
<gatecat>
but still something to consider doing at some point
<tnt>
ack
<kittennbfive>
fyi: i compiled a new version of nextpnr (and Yosys too) with the yet-to-be-applied patch provided by gatecat and wow - for generated1.v from my link above fmax went from 149MHz to 248MHz. If this works on real hardware it would be insane!