Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amaranth FSM does not allow asynchronous reset #672

Closed
CoreRasurae opened this issue Dec 27, 2021 · 2 comments · Fixed by #667
Closed

Amaranth FSM does not allow asynchronous reset #672

CoreRasurae opened this issue Dec 27, 2021 · 2 comments · Fixed by #667

Comments

@CoreRasurae
Copy link

CoreRasurae commented Dec 27, 2021

I tried to generate the Verilog code for the following Amaranth FSM with Async reset (BasicFSM.py), with:
python BasicFSM.py -t v > toplevel.v
and I get:

   ...
    raise YosysError(stderr.strip())
nmigen._toolchain.yosys.YosysError: ERROR: Multiple edge sensitive events found for this signal!

Is this the expected?

The code is:

class BasicFSMDevice(Elaboratable):
    def __init__(self):
        self.clk = Signal()
        self.csn = Signal()
        
    def elaborate(self, platform : Platform):
        m = Module()
        
        m.domains += ClockDomain("asyncFSM", async_reset=True, local=True)
        
        m.d.comb += ClockSignal('asyncFSM').eq(self.clk)
        m.d.comb += ResetSignal('asyncFSM').eq(self.csn)
        
        with m.FSM(domain='asyncFSM', reset='IDLE', name='serialFSM'):
            with m.State('IDLE'):
                m.next = 'BUSY'
            with m.State('BUSY'):
                m.next = 'BUSY'
        
        return m
        
    def ports(self) -> List[Signal]:
        return [
            self.clk,
            self.csn
        ]

if __name__ == "__main__":
    simulate = False

    parser = main_parser()
    args = parser.parse_args()

    m = Module()
    m.submodules.basicFSM = basicFSM = BasicFSMDevice()
    
    main_runner(parser, args, m, ports=basicFSM.ports())
@whitequark
Copy link
Member

whitequark commented Dec 27, 2021

This should be fixed by #667.

@CoreRasurae
Copy link
Author

CoreRasurae commented Dec 31, 2021

Yes, the patch for #667 does fix the problem. Thank you!

@whitequark whitequark linked a pull request Jan 1, 2022 that will close this issue
whitequark pushed a commit that referenced this issue Jan 1, 2022
Avoiding emission of sync processes in RTLIL allows us to avoid a dependency on
matching the behavior expected by Yosys, which generally expects sync processes
in RTLIL to match those emitted by the output from its own Verilog parser.
This also simplifies the logic used in emitting RTLIL overall.

Combinatorial processes are still emitted however. Without these the RTLIL does
not have a high-level understanding of Switch statements, which significantly
diminishes the quality of emitted Verilog, as these are converted to `$mux`
cells in Yosys, which become `?` constructs when converted back to Verilog.

Fixes #603.
Fixes #672.
@whitequark whitequark added this to the 0.4 milestone Jan 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants