3.2.2 says reg decl with val should be treated "as if the assignment occurred in a blocking assignment in an initial construct" ...
-
-
Replying to @OlofKindgren
Which LRM are you reading? IEEE-1364-2005 3.2 is about whitespaces, IEEE-1800-2009 3.2 is about "design elements" (modules, checker, ..).
2 replies 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
Neither has a section 3.2.2. But you are right: init value is like initial block. Don't need to check LRM for that.
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
But this is not the question: The question is if in the Verilog stratified event queue model it is guaranteed that an always block >>
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
is scheduled in the inactive queue in response to an initial clock condition after all propagated initial values have been put into >>
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
the active queue. If propagated initial values and triggered always block ever can be in the same queue then order isn't guaranteed >>
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
which means that the always block can sample a signal effected by initial values before initial values propagated completely.
1 reply 0 retweets 0 likes -
Replying to @oe1cxw
need to eat and think about this :) sv at least old 3.1a) seems to be more explicit.
1 reply 0 retweets 0 likes -
Replying to @OlofKindgren
Claire Xen 🏳️⚧️ 🏳️🌈 🧙🏻♀️ BLM 🏴 🚩 Retweeted Claire Xen 🏳️⚧️ 🏳️🌈 🧙🏻♀️ BLM 🏴 🚩
No need to think about it. Just don't generate clock edges at time 0.https://twitter.com/oe1cxw/status/892425857544966147 …
Claire Xen 🏳️⚧️ 🏳️🌈 🧙🏻♀️ BLM 🏴 🚩 added,
1 reply 0 retweets 0 likes -
Replying to @oe1cxw
oh, I might have misunderstood then. Thought the issue was if clk might be undefined if always executed before reg declaration
1 reply 0 retweets 1 like
No. Never said anything like that. There is a race between the clock edge and initial values for other regs, like I wrote in the OP.pic.twitter.com/O3QhsxwrDO
-
-
Replying to @oe1cxw @OlofKindgren
Undef in posedge condition is no problem at all! X->1 is simply a valid posedge event (and so is 0->X btw). That's why 2nd code in OP is ok.pic.twitter.com/sJTeKxN8Fy
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.