On Thursday, April 23, 2015, Sébastien Bourdeauducq <[email protected]> wrote:
> On 04/24/2015 05:43 AM, Guy Hutchison wrote: > > - Nonblocking assigns I believe are just a warning but required by > > company coding guidelines (at least all companies I have worked for). > > All lint tools (and fellow ASIC designers) I'm familiar with will flag > this. > > Why is that? Does it improve simulation performance? I think simulators > ought to be able to optimize that themselves. Yes it improves performance, as the use of the non blocking operator forces the simulator to create another event and schedule the assign in that event rather than immediately. The simulator can't optimize this and still honor the non blocking semantics. > > > - Not sure where the dummy signal comes from, but I suspect its an > > order of events problem related to use of initial blocks. Not needed > > for blocks with an explicit reset. Also not guaranteed to work across > > simulators, since they are free to order events in any way they choose. > > Without the initialize_always_comb (aka dummy) signal, the value of > signal "foo" can remain undefined in this simple example (whereas it is > 42 in synthesis): > reg [7:0] foo; > always @(*) foo <= 42; > I tried this on multiple simulators; VeriWell flagged it as an error, Icarus and Cver threw a warning that this will never execute because there are no events in the sensitivity list. Assigning constants to a net is what assign statements are for, and this works correctly if replaced with an assign. My point about resets is that not assigning a value to the net is actually desirable behavior, because in an ASIC flops and nets have no defined value at power on. You want them to remain X until something comes and clears them out, because it proves your reset sequence. If this @* block had had signals that came from flops (or from nets that came from flops), it would get an event when the flops assigned their reset. > > I didn't do that because it's a bit easier to offload the sensitivity > list creation to the simulator, but you seem to dislike the dummy signal > clutter more than I do (my opinion of Verilog and its traps being pretty > low, I do not care that much about putting lipstick on the pig). > I have nothing against @*, I think it's one of the greatest productivity savers in V2001. Before that we had /*AUTOSENSE*/ on every block and would occasionally spend half a day chasing down a bug because we forgot to regenerate the sensitivity list. It's more that any time I see an initial statement in synthesizable RTL it's a big red flag, because it's introducing a simulator/synthesis mismatch. It has to be commented out for synthesis, and if was needed to make the simulator go how do I trust I'm simulating the right thing? I don't want to do a mental proof each time I look at the code to assure myself it's OK. - Guy
_______________________________________________ M-Labs devel mailing list https://ssl.serverraum.org/lists/listinfo/devel
