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; > > The purpose of the initialize_always_comb signal is to get event-driven > simulators to run all comb always blocks once at the beginning of the > simulation to initialize all signal values. It should work reliably with > all simulators. With this technique the example becomes: > > reg dummy_s; > initial dummy_s <= 0; // create an event on dummy_s at the beginning > > reg [7:0] foo; > reg dummy_d; > always @(*) begin > foo <= 42; > dummy_d <= dummy_s; // add dummy_s to the sensitivity list > end > > > Maybe we could make this purpose clearer, and reduce code clutter a bit, > by not using the implicit sensitivity list "always @(*)" but listing all > signals explicitly. Then we would simply add initialize_always_comb to > the sensitivity lists to make the simulator run the blocks at startup, > instead of having to create a second dummy signal and assigning it the > value of the first in every block. > > 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). > > Sébastien > >
_______________________________________________ M-Labs devel mailing list https://ssl.serverraum.org/lists/listinfo/devel
