12:40 <thorns514> apologies in advance for the vague question, but I'm working on my project and I noticed that if I try to reset an IO register in a reset block, it gets glitchy and fails above a certain frequency (see https://github.com/sthornington/matrix8x8/blob/main/src/matrix.sv#L299 ). I can't think what is wrong with this hdl, and it works great using the lattice toolchain, but I am hesitant to make a bug report since I'm new to HDL and

12:40 <thorns514> synthesis

12:40 <thorns514> is there something obviously wrong with resetting IO pins in reset blocks ?

12:40 <thorns514> is there something obviously wrong with resetting IO registers in reset blocks ?

12:42 <gatecat> no, it should work fine

12:43 <gatecat> do other small changes in the design cause a similar failure, or is it definitely down to this (small design changes can cause big changes in the output due to the chaotic behaviour of synthesis and PnR, enough to trigger marginal timing elsewhere, etc)

12:44 <mwk> r_matrix_mosi has a different sync reset value and initial value btw, this means that hardware reset function will not be used

12:44 <mwk> this makes an extra multiplexer by necessity

12:44 <thorns514> I narrowed it down to this, but I haven't tried changes elsewhere. I had some issues with debounce.sv in the same directory until a month ago, it was complaining about combinational loops during aiger something or other, but an april build fixed that issue

12:44 <mwk> it should still work though, as long as you meet timing

12:44 <thorns514> I can try making them the same one moment

12:45 <gatecat> this will also be a known mismatch with the vendor tools, which will ignore the initial value (so r_matrix_mosi will init to 1 with them)

12:46 <thorns514> changing the initial value to 1 fixed the issue!

12:46 <thorns514> I haven't got it attached to the scope at the moment, but the display (which mosi drives) is not glitching any more and clk is at 100mhz

12:46 <mwk> what does nextpnr say about timing btw?

12:47 <thorns514> in both cases, timing was 112mhz pass at 100mhz

12:47 <mwk> hmm....

12:47 <thorns514> mean, it changes 112 115 111 but in all cases passing you know

12:48 <mwk> wait

12:48 <gatecat> yeah, the ecp5 timing data is very conservative so that should be a clear pass

12:48 <mwk> you have a non-synthronized input wired to reset pin

12:48 <mwk> of course it glitches

12:49 <thorns514> gatecat> so if the initial value of reset is 1 and the initial value of mosi is 0 and in reset the value of mosi is set to 1, does that mean there's a double assignment initially or something? I have had issues with double-assignments going unnoticed and cause strange synthesis before

12:49 <thorns514> it's not non-synchronized. it's going through a double-FF debouncer?

12:50 <mwk> it's not

12:50 <mwk> reset is connected to db_btn_reset in top

12:51 <mwk> assign db_btn_reset = db_btn_reset_raw || ~btn[0];

12:51 <mwk> and this is obviously a combinatorial circuit with raw async button input

12:51 <mwk> it *will* glitch

12:51 <thorns514> oh I have played with that a variety of ways, it doesn't change anything

12:51 <thorns514> and I'm not talking about a glitch when pressing reset

12:52 <thorns514> I'm talking about it glitches from T0, never works at all

12:53 <thorns514> getting rid of the || ~btn[0] doesn't change anything just checked

12:53 <thorns514> but setting the initial value of mosi to 1 to be congruent with the reset value of mosi fixes it perfectly, so thank you for that

12:59 <mwk> well it still sounds like there is a glitch problem somewhere, except now it's hidden

12:59 <mwk> that or a nextpnr/yosys bug

13:01 <thorns514> you could well be right, I will keep looking, but the difference between the initial mosi = 1 and initial mosi = 0 is stark; when congruent with the reset value, it works great, stable signals, reset works, wishbone master changing the image works. when they are inconsistent, whatever is driving MOSI never really gets solid transitions going at all, it's just 100% oscillations and glitch from time zero.

13:02 <thorns514> reset doesn't work, and the display is nonsense

13:02 <thorns514> but that is not to say I don't have some lurking demon in the design, as I said, this is my first experience doing hardware so I'm learning as I go

13:04 <cr1901_modern> Why is btn[0] ORed with db_btn_reset_raw?

13:08 <thorns514> I did that so it stays in reset as long as I hold the button down but I've removed that and it doesn't change anything

13:08 <thorns514> but gatecat to your earlier question, giving r_serial_negedge an initial value also fixes the issue

13:10 <thorns514> ugh hang on

13:11 <thorns514> no it doesn't :(.

13:12 <thorns514> in any case tonight after work I will try to investigate some of the intermediate outputs here to see what is different, changing an initial value from 0 -> 1 ought to be a small enough change that it ought not really change too too much but I suspect it is so that will be interesting