06:14 <ikskuh> rowang077[m]: thank you! i've read the document you've sent more thoroughly and figured that BB is the right primitive to use

06:16 <ikskuh> what i have now is this:

06:16 <ikskuh> BB i2c_sda_io (.I(i2c_sda_out), .T(i2c_sda_tristate), .O(i2c_sda_input), .B(i2c_sda_pin));

10:05 <ikskuh> rowang077[m]: thank you, using BB works as expected! \o/

10:27 <pepijndevos[m]> <whitequark> "will look in a few hours, ping..." <- ping?

13:50 <rowang077[m]> I would like to implement output register inference for brams in yosys? Anyone can point me in the right direction?

14:14 <lofty> rowang077[m]: Do you mean "inference" or do you mean "merging"?

14:15 <lofty> Consider that the latter is near-universally tech-dependent

14:21 <rowang077[m]> lofty: I think I mean merging. For example the DP16KD bram primitive for the ECP5 FPGA has an input register and an optional output register. Using the output register greatly reduces propagation delay. What I want is that if a register is placed on the output it will instantiate a DP16KD with the output register enabled.

14:24 <lofty> rowang077[m]: Okay, this sounds unrelated but isn't - do you know what register retiming is?

14:24 <rowang077[m]> Yes

14:25 <lofty> Given the possibility of register retiming, isn't it potentially too early to decide to merge the register into the BRAM?

14:27 <rowang077[m]> Because retiming happens primitive mapping? If yes, then possibly. But looking at the propagation delay of the DP16KD it seems quite dramatic. I would expect that that would almost be the sensible choice.

14:27 <rowang077[m]> http://yosyshq.net/prjtrellis-db/ECP5/timing/cell_timing_6.html#DP16KD:REGMODE_A=OUTREG,REGMODE_B=OUTREG

14:27 <tpb> Title: ECP5 Speed Grade -6 Cell Timings (at yosyshq.net)

14:28 <rowang077[m]> 983 ps with output register vs 5609ps without

14:28 <lofty> These are quick, actually

14:29 <lofty> (ask me how I know >.>)

14:30 <rowang077[m]> @lofty What do you mean quick :p? I don't think a propagation delay of 5609 ps is that quick.

14:31 <lofty> rowang077[m]: "hey, lofty, can you write a flow for these QuickLogic chips?"

14:31 <lofty> "oh, yeah, sure, send me the timings"

14:31 <lofty> "sure, a 32x32 multiply takes 25ns"

14:32 <lofty> Well, anyway

14:32 <lofty> Do you want the good news or the bad news?

14:32 <rowang077[m]> 🥲

14:33 <lofty> Bad news is that merging things together in Yosys is Tricky

14:33 <lofty> Good news is that Yosys has some amount of infrastructure for this: pmgen

14:34 <lofty> Bad news: it's mildly terrifying to pattern match on RTLIL

14:35 <lofty> At least gatecat made the sensible design choice to abstract the FF models into TRELLIS_FF

14:36 <lofty> I would not want to have to match over every single one of the Lattice flop primitives

14:36 <lofty> rowang077[m]: https://github.com/YosysHQ/yosys/blob/master/passes/pmgen/xilinx_srl.pmg

14:37 <rowang077[m]> Oke so from reading the code. What I would have to do is specify a pmg

14:37 <rowang077[m]> Ah yes tha's what I was looking at

14:38 <rowang077[m]> hmm Oke

14:38 <rowang077[m]> lofty: Thanks I will try to play around with this to get a better feel on what I can do

14:41 <lofty> rowang077[m]: AIUI pmgen is hyperspecific, expect pain trying to generalise patterns

15:17 <jix> shouldn't memory_dff already try to merge output reigsters into the read port? or does that somehow get undone when mapping to architecture specific things?

18:00 <gatecat> jix: memory_dff will fold in one layer of output register, which is required to map to BRAM at all (which always has a registered output), but the hardware also has an optional second output register for pipelining for improved Fmax that nothing in Yosys can infer currently, and I suspect is what this discussion is about

18:01 <mwk> gatecat: speaking of which, ping on https://github.com/YosysHQ/yosys/pull/3420 ?

18:01 <gatecat> don't have access to the board atm, sorry, life has been quite chaotic

18:02 <jix> gatecat: ah, makes sense and explains my confusion

18:02 <mwk> .... it be like that

18:02 <mwk> *sigh*

18:03 <mwk> (same)

19:33 <whitequark> pepijndevos: pong

19:34 <whitequark> pepijndevos: please feed the same inputs to non-yowasp nextpnr-gowin

20:09 <pepijndevos[m]> Catherine: take your pick https://github.com/YosysHQ/apicula/actions

20:09 <pepijndevos[m]> All the ones that don't say yowasp are built with regular nextpnr

20:09 <whitequark> does it return an error?

20:10 <pepijndevos[m]> not on master, master. The latest releases... don't tend to work

20:10 <whitequark> if you want me to look deeper at it you should test the exact same inputs against yowasp-nextpnr-gowin and normal nextpnr-gowin

20:10 <whitequark> built from the same sources

20:12 <pepijndevos[m]> Well, what's happening is that we build all the examples on the latest yosys and nextpnr from git, as well as the latest yowasp packages. So the inputs are identical down... the randomness of yosys I guess?

20:13 <pepijndevos[m]> Lemme rerun the yowasp one to see if it's a random failure

20:17 <pepijndevos[m]> If it is a random failure, I won't be able to reproduce it. If it's not, the native and yowaps runs should be from identical inputs. Probably the yowasp commit lags a bit behind the native commit, so if there was a regression, native should fail too. We'll know in half an hour...

20:19 <pepijndevos[m]> The fact that it failed on attosoc rather than a small example makes me fear it's a random failure. So I'm not sure where we'd go from there.

20:19 <pepijndevos[m]> On the other hand it failed right at the start, not halfway during PnR...