00:56 <_whitenotifier-9> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/yosys/compare/0d60ddb6244c...a124f4b74fcf

00:56 <_whitenotifier-9> [YoWASP/yosys] whitequark a124f4b - Update dependencies.

01:25 <_whitenotifier-9> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/nextpnr/compare/5cf511791c90...8677c4285e3c

01:25 <_whitenotifier-9> [YoWASP/nextpnr] whitequark 8677c42 - Update dependencies.

13:40 <ydnatag> Hi! Many of my designs stop working two days ago, it looks like a problem with the verilog code related to FSMs. The verilog is synthetized and pnr without timming issues but the binary doesn't work in hardware. Rolling back to the previous amaranth-yosys it works. Should i open an issue to track this? I can't share the source code to replicate the

13:40 <ydnatag> issue. sorry :(

13:49 <_whitenotifier-9> [amaranth] anuejn reviewed pull request #547 commit - https://github.com/amaranth-lang/amaranth/pull/547#discussion_r551038584

14:39 <whitequark> ydnatag: generating broken RTL is a very serious issue so yes

15:09 <_whitenotifier-9> [amaranth] lekcyjna123 commented on issue #742: Regression in Fmax of generated hardware - https://github.com/amaranth-lang/amaranth/issues/742#issuecomment-1424342333

15:23 <_whitenotifier-9> [amaranth] whitequark commented on issue #742: Regression in Fmax of generated hardware - https://github.com/amaranth-lang/amaranth/issues/742#issuecomment-1424364025

15:34 <ydnatag> Ok, I will open an issue with all the information. I will try first to recreate the issue with a code I can share

15:35 <whitequark> thanks!

16:43 <ydnatag> I was playing with the issue. I found that yosys changes the verilog syntax if a fsm has power of 2 states and more than 8.

16:45 <ydnatag> It looks like that synplify pro doesn't like do_switch syntax

16:47 <ydnatag> It is not an amaranth/yosys issue, verilog is correct.

16:47 <ydnatag> Do you know a way I can workaround this?

17:21 <ydnatag> I found the issue. synplify does not support initial blocks.

17:23 <ydnatag> Within an initial block, only Verilog force statements and memory $readmemh/$readmemb initialization statements are recognized, and all other content is ignored. Simulation mismatch may occur

17:24 <ydnatag> I resolved that for blockrams with a regular expression and exporting memdumps to files, but i don't like that. Can be possible for yosys to don't emit initial blocks?

17:58 <gatecat> I am slightly surprised that Yosys generates an initial block for anything other than a memory or initialised DFF

17:58 <gatecat> is the problem relating to the latter, or is it that it's generating an initial block for some other reason?

18:23 <ydnatag> Me too. I didn't expect to see that. https://gist.github.com/andresdemski/539b6f0d6b3900586cf2f36732659e8a here you have the code I'm running and the output

18:24 <ydnatag> You would see that the output syntax depends on the number of states of the FSM

19:29 <koschei[m]> What would y’all say is the most efficient way to clear all of the items out of a synchronous FIFO? I’m imagining I might hook it up to a ClockDomain that resets on the parent module’s reset or the fifo clear signal, but I can’t quite picture how that code would look for some reason

19:36 <vup> koschei[m]: are you looking for ResetInserter?

19:41 <koschei[m]> vup: Nice, I think that’s what I’m looking for!