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. > - 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
