Open mbikovitsky opened 3 months ago
Thank you for the detailed report. This issue is directly related to https://github.com/amaranth-lang/amaranth/pull/591, which also deals with reset handling in AsyncFIFO. They should probably be dealt with together.
However, if the write domain has any other reset signals defined through
ResetInserter
, then the read domain will no longer be properly reset.
On re-read, this is actually a general problem where ResetSignal
does not reflect sources of reset added via ResetInserter
, rather than something that is specific to AsyncFIFO
(or possibly both if I'm missing something). I do think that we should focus on reworking the clock domain system for the 0.6 release, but it is a major chunk of work that will require at least one large RFC.
cc @wanda-phi
Consider the following scenario:
AsyncFIFO
to transfer data from thesync
domain into the new clock domain.Then the module can no longer be reset using anything other than the
sync
domain's default reset signal.Minimal reproducing sample:
As I understand it, the problem stems from the fact that
AsyncFIFO
synchronizes the write domain's reset signal into the read domain: https://github.com/amaranth-lang/amaranth/blob/v0.5.1/amaranth/lib/fifo.py#L485-L490. However, if the write domain has any other reset signals defined throughResetInserter
, then the read domain will no longer be properly reset.This poses a problem for composing different Amaranth modules together. If a module uses an
AsyncFIFO
, then any module using it can no longer be reset usingResetInserter
.For example, this is the case in Glasgow, which has a separate reset signal for the applets: https://github.com/GlasgowEmbedded/glasgow/blob/346e5c4f167654dd76c70dcefa168196a540df46/software/glasgow/access/direct/multiplexer.py#L246. This means that applets cannot safely use an
AsyncFIFO
, since they will break when the "soft-reset" is applied.