| *** tpb has joined #yosys | 00:00 | |
| *** peepsalot has joined #yosys | 00:14 | |
| *** roamingr1 has quit IRC | 00:34 | |
| *** FFY00_ has quit IRC | 00:57 | |
| *** FFY00_ has joined #yosys | 01:02 | |
| *** citypw has joined #yosys | 01:08 | |
| *** Degi has quit IRC | 03:58 | |
| *** Degi has joined #yosys | 03:59 | |
| *** adjtm has quit IRC | 05:25 | |
| *** danvet has joined #yosys | 05:26 | |
| *** adjtm has joined #yosys | 05:28 | |
| *** vidbina has joined #yosys | 07:13 | |
| *** moony has quit IRC | 08:22 | |
| *** moony has joined #yosys | 08:24 | |
| *** moony has quit IRC | 08:26 | |
| *** moony has joined #yosys | 08:31 | |
| *** vidbina has quit IRC | 11:50 | |
| *** lkcl has quit IRC | 11:52 | |
| *** vidbina has joined #yosys | 12:04 | |
| *** richbridger has joined #yosys | 12:26 | |
| *** thorns514 has joined #yosys | 12:34 | |
| *** toshywoshy has quit IRC | 12:35 | |
| 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:40 |
| gatecat | no, it should work fine | 12:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| mwk | it's not | 12:50 |
| mwk | reset is connected to db_btn_reset in top | 12:50 |
| 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:51 |
| thorns514 | I'm talking about it glitches from T0, never works at all | 12:52 |
| 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:53 |
| 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 | 12:59 |
| 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:01 |
| 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:02 |
| cr1901_modern | Why is btn[0] ORed with db_btn_reset_raw? | 13:04 |
| 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:08 |
| thorns514 | ugh hang on | 13:10 |
| thorns514 | no it doesn't :(. | 13:11 |
| 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 | 13:12 |
| *** thorns514 has quit IRC | 13:32 | |
| *** thorns514 has joined #yosys | 13:35 | |
| *** citypw has quit IRC | 13:39 | |
| *** citypw has joined #yosys | 13:40 | |
| *** roamingr1 has joined #yosys | 15:39 | |
| *** citypw has quit IRC | 15:43 | |
| *** roamingr1 has quit IRC | 16:16 | |
| *** roamingr1 has joined #yosys | 16:16 | |
| *** vidbina has quit IRC | 17:09 | |
| *** roamingr1 has quit IRC | 17:46 | |
| *** thorns514 has quit IRC | 17:52 | |
| *** toshywoshy has joined #yosys | 18:25 | |
| *** vidbina has joined #yosys | 19:09 | |
| *** kraiskil has joined #yosys | 19:13 | |
| *** kraiskil has quit IRC | 19:42 | |
| *** roamingr1 has joined #yosys | 19:56 | |
| *** lkcl has joined #yosys | 20:00 | |
| *** Raito_Bezarius has quit IRC | 20:09 | |
| *** JJJollyjim has quit IRC | 20:09 | |
| *** Raito_Bezarius has joined #yosys | 20:13 | |
| *** JJJollyjim has joined #yosys | 20:13 | |
| *** Raito_Bezarius has quit IRC | 20:13 | |
| *** Raito_Bezarius has joined #yosys | 20:14 | |
| *** jryans has quit IRC | 20:17 | |
| *** JJJollyjim has quit IRC | 20:18 | |
| *** vidbina has quit IRC | 21:10 | |
| *** jryans has joined #yosys | 21:11 | |
| *** JJJollyjim has joined #yosys | 21:16 | |
| *** danvet has quit IRC | 21:17 | |
| *** vidbina has joined #yosys | 21:46 | |
| *** roamingr1 has quit IRC | 22:00 | |
| *** vidbina has quit IRC | 22:48 | |
| *** lf has quit IRC | 23:06 | |
| *** lf has joined #yosys | 23:06 | |
| *** roamingr1 has joined #yosys | 23:32 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!