>This is better, but it >still leaves the initializers executing before always blocks are started. >I think this is still a problem. Yes, we discussed this for quite a while and were unable to come to a resolution that covered always blocks. To get combinational always blocks to behave properly with initializers requires always blocks to execute before the initializers. The 1364 standard allows this ordering, and some implementations appear to take advantage of this to give the desired behavior. SystemVerilog forbids this ordering, requiring these always blocks to behave incorrectly. To get testbenches to behave in an intuitive way (i.e. like C), initializers should be executed before other testbench code. This drove the SystemVerilog ordering requirement. The 1364 standard allows this ordering, and SystemVerilog requires it. I proposed an attempt to satisfy both of these under the assumption that the testbench code would primarily use initial blocks. This would call for the ordering: always blocks, then initializers, then initial blocks. This would cause combinational always blocks to work properly in the presence of initializers and initializations in initial blocks. It would also cause initializers to be executed before testbench code in initial blocks. I am not sure why this was rejected. I think Dave Rich was concerned about testbench always blocks. I think something has to give, and this is a reasonable compromise. There may have been resistance to changing the long-standing rule that there is no deterministic order between always and initial blocks. However, there is no way to make this behavior work deterministically without changing that rule. I also think that this would not be a big change from the ordering in existing implementations. Steven Sharp sharp@cadence.comReceived on Tue Apr 12 12:59:47 2005
This archive was generated by hypermail 2.1.8 : Tue Apr 12 2005 - 13:00:12 PDT