<cr1901>
(as opposed to the SET/RESET input of a flip-flop, so it's "wired OR/AND" with PUR and the user reset to your design arrives immediately, rather than "two or three cycles later"?
<cr1901>
Use case: I have an amaranth UART. I want a BRK signal on the UART line to reset the design on machxo2/ECP5 boards. Consequently, I need a sync domain w/ reset. But the POR circuit provided in the linked file is still useful. 1/2
<whitequark>
the Matrix bridge is dropping messages again
<cr1901>
Oh for fuck's sake, fine I'll join Matrix
<whitequark>
I was reading the IRC logs so at least there's that
<whitequark>
but I really had hoped that Matrix would like... work
WilliamDJones[m] has joined #amaranth-lang
<whitequark>
anyway, to answer your question
<whitequark>
the user reset signal is often connected to things like "button on board"
<whitequark>
we support that case with a syntactic shortcut even
<whitequark>
so it needs to be resynchronized
<whitequark>
the default "sync" domain is created with async_reset=False, so that's what the synchronizer is implementing
<whitequark>
in the future, I think this circuit should be extracted into an Elaboratable and inserted by the platform logic as a submodule, rather than being the way it is
<whitequark>
but right now it's unfortunately like this
<WilliamDJones[m]>
I'm used to seeing "button on board" reset synchronizers attached to the SET/RESET input of a multi-FF synchronizer; RST gets delivered immediately b/c "it doesn't matter in general" if the RST assertion is async (it typically lasts many clks). IIRC, this is what `AsyncResetSynchronizer` does
<whitequark>
yeah
<whitequark>
this is purely an artifact of how the sync domain is created by default
<WilliamDJones[m]>
But the synchronizer I linked is attaching RST to the data input of a multi-FF synchronizer
<WilliamDJones[m]>
accomplishes the same thing, but attaching it to the data input causes the RST assertion to be delayed by 2 or 3 cycles as it propogates thru the synchronizer
<WilliamDJones[m]>
My question is: "If I were to rip that circuit out for a domain that needs the rst signal, is it safe to attach RST to the SET/RST inputs of those FFs? Or is there a subtle reason I'm missing that you're feeding the RST into the D input, at the cost of 2-3 cycle delay for RST assertion"?
<WilliamDJones[m]>
whitequark: Can you elaborate?
<whitequark>
well, the default sync domain has async_reset=False
<whitequark>
and the synchronizer created for the reset signal matches that
<WilliamDJones[m]>
Oh, a UART BRK signal reset will also be synchronous (if m.d.sync += rst.eq(cnt_of_number_of_zeros == threshold))
<WilliamDJones[m]>
But understood
<whitequark>
if you have an async set/reset input, the Q output of that flop becomes asynchronous
<whitequark>
in this specific case, hm
<WilliamDJones[m]>
That is true, and that breaks the semantics of a sync reset
<whitequark>
actually, it's fine in this specific case. it's equivalent to the output of a flop being ANDed or ORd with the signal generated by BRK detector
<whitequark>
I don't know if it'll be included in timing analysis
<whitequark>
I don't think it will be with nextpnr (gatecat could answer this)
<WilliamDJones[m]>
So something like "rip the POR circuit from that file out into my own file, and AND/OR with the BRK detector"
<whitequark>
oh yeah that would be timed correctly
<WilliamDJones[m]>
* So something like "rip the POR circuit from that file out into my own file, and AND/OR it's output with my BRK detector"
<whitequark>
if it's ever asserted for less than 2 cycles you could have a 1-cycle glitch
<whitequark>
but you could fix that
<whitequark>
also, hold on
<whitequark>
why do you need a reset synchronizer at all here?
<whitequark>
just feed your BRK detector output into SGSR
<WilliamDJones[m]>
Because I forgot what the S in SGSR stands for :P
<whitequark>
btw, the two FD1S3AX are there primarily not to synchronize reset
<whitequark>
the common case they're there for are rst_i being always 0
<whitequark>
it's a power up detector
<whitequark>
it says that in the comment, there's no explicit end-of-configuration signal on ecp5
<whitequark>
* it's a start up detector
<whitequark>
but we also have the default_rst signal, so it does double duty as a reset synchronizer for the cases where it's needed
<whitequark>
without default_rst it would be one flop
<whitequark>
that has D=1
<whitequark>
admittedly the code isn't very clear if you're not intimately familiar with ecp5 internals
<WilliamDJones[m]>
The comment was useful for me to understand. I think it's a useful dual-use POR/PUR and reset synchronizer circuit. So I wanted to reuse it. But I had questions :).
<WilliamDJones[m]>
In my particular case, a POR timer circuit OR w/ UART BRK reset signal feeding SGSR (or GSR, for that matter, since it's already synchronized) will do the same job
<WilliamDJones[m]>
I just liked your solution better