<tpb>
Title: D flip-flop with asynchronous reset · GitHub (at gist.github.com)
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter has joined #yosys
Strobokopp has quit [Ping timeout: 248 seconds]
_whitelogger has joined #yosys
dys has quit [Ping timeout: 272 seconds]
rohitksingh_work has joined #yosys
promach has quit [Quit: WeeChat 2.5]
emeb_mac has quit [Ping timeout: 248 seconds]
rohitksingh has joined #yosys
kraiskil has joined #yosys
proteusdude has quit [Ping timeout: 245 seconds]
proteusdude has joined #yosys
kraiskil has quit [Ping timeout: 246 seconds]
m4ssi has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cr1901_modern has quit [Ping timeout: 268 seconds]
futarisIRCcloud has joined #yosys
<ZipCPU>
promach: That's the same thing I've been explaining to you for days. Because the asynchronous reset is assumed to be dropped just before the clock edge. The two are race conditions against each other.
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 245 seconds]
somlo has quit [Remote host closed the connection]
somlo has joined #yosys
alexhw has joined #yosys
somlo has quit [Ping timeout: 258 seconds]
rrika has quit [Ping timeout: 245 seconds]
rrika has joined #yosys
rohitksingh has joined #yosys
cr1901_modern has joined #yosys
rohitksingh has quit [Ping timeout: 272 seconds]
somlo has joined #yosys
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
promach has joined #yosys
<promach>
ZipCPU: so, enable signal is actually high during posedge clk ?
<ZipCPU>
"<ZipCPU> promach: That's the same thing I've been explaining to you for days. Because the asynchronous reset is assumed to be dropped just before the clock edge. The two are race conditions against each other."
<promach>
I saw that
<promach>
in the online log
<promach>
ZipCPU: so, enable signal is actually high during posedge clk ?
<promach>
otherwise line 27 will not be executed
kraiskil has joined #yosys
<promach>
ZipCPU: manipulating the enable signal input will also not solve such issue
<promach>
I am afraid
<promach>
this is a delta race condition
<promach>
do I need to extend the enable signal ?
<promach>
as well as the reset signal ?
<ZipCPU>
if (reset) assume(!enable)
<promach>
hmm...
<promach>
if (reset_wsync) assume(!enable)
<promach>
because of always_ff @(posedge write_clk, posedge reset_wsync)
<promach>
but this is not reliable since this is nly for formal verification
<promach>
and we only do it after the reset synchronizer
<promach>
ZipCPU: this is a bit tricky to solve
<promach>
As for "if (reset) assume(!enable)" , this is not helpful too since we could have vastly different clocks speed
<promach>
this is why we have afifo instead of cheap, conventional synchronizer pair
<promach>
ZipCPU: what do you think ?
vonnieda has joined #yosys
gmc has quit [Ping timeout: 245 seconds]
kraiskil has quit [Ping timeout: 245 seconds]
proteusguy has joined #yosys
proteusguy has quit [Remote host closed the connection]
AlexDaniel has quit [Remote host closed the connection]
AlexDaniel has joined #yosys
kraiskil has joined #yosys
pie__ has quit [Ping timeout: 246 seconds]
AlexDaniel has quit [Remote host closed the connection]
kraiskil has quit [Ping timeout: 248 seconds]
fsasm has joined #yosys
kraiskil has joined #yosys
emeb has joined #yosys
kraiskil has quit [Ping timeout: 248 seconds]
m4ssi has quit [Remote host closed the connection]
promach has quit [Ping timeout: 245 seconds]
rohitksingh has joined #yosys
<bwidawsk>
so would anyone be opposed to having yosys catch SIGINT and ignoring it when in interactive mode?
<bwidawsk>
I'd be happy to write the patch
<ZirconiumX>
Maybe post an RFC issue in GitHub
<ZirconiumX>
I have something I'd like to add to Yosys, too, since it seems to be a common enough idiom
<bwidawsk>
ZirconiumX› okay, writing the RFC now
<ZirconiumX>
(namely, adding a parameter to the $pos cell to round the output width to a given multiple of N)