In the top-level, I initialize it to 1 on reset. When a certain condition is met, I want it to be reset to zero and NEVER be set >>
-
-
back to 1 unless another power-on reset occurs. I accidentally wrote the condition such that it was always true. yosys decided to >>
1 reply 0 retweets 0 likes -
replace the net with the constant 0. Is ignoring the initial value in this case a bug?
1 reply 0 retweets 0 likes -
Replying to @cr1901
It shouldn't ignore the initial value. The results I get for the following example look fine at least.pic.twitter.com/Rwe4n5ULVj
2 replies 0 retweets 0 likes -
Replying to @oe1cxw
https://dl.dropboxusercontent.com/u/20852311/delay_line.zip … main_delay_fifo is the signal in question that gets optimized out. See top.rpt.
1 reply 0 retweets 0 likes -
Ignore what I said about "constant driver 0". That was a mistake. I still think it shouldn't be optimized out tho.
1 reply 0 retweets 0 likes -
-
Replying to @oe1cxw
B/c the initial value is 1. Sematically, it should change to 0 at the first posedge of the system clock? Is the state of a >>
2 replies 0 retweets 0 likes -
Replying to @cr1901
Why would it change to 0 on first system clock? It is only assigned 0 in a block that cannot be activated bc its effectively if(0).
1 reply 0 retweets 0 likes -
Proof that it cannot ever change to 0: yosys -p 'prep; memory_map; sat -seq 1 -prove main_delay_fifo 1' top.v
2 replies 0 retweets 0 likes
oops, wrong proof. change "-seq 1" to "-tempinduct" to prove the property for all time, not just initial state.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.