System verilog:: Static Variable non-blocking Assignent outside program-block?

Question

I'm new to system verilog and i'm stuck with a basic concept, kindly provide rationale behind the following behavior:

1. In System verilog, Why Static class properties declared in other than program-block scope cannot be assigned with blocking assignment from program block?

2.Why is that, even if static variable is assigned with non-blocking statement, the change in that static variable is no visible ($display) immediately, it is available after a delay of say #1.

Example:

class A ;
 static int i;
endclass

program main ;
A obj;

initial
begin

  obj.i = 123; // Not Allowed, can only be done using <= ... WHY ??
  $display(obj.i);
  #1 $display(obj.i);
end
endprogram 

Answer 1

There is no such rule in the IEEE 1800-2012 LRM Earlier version of SystemVerilog had more restrictions on the types of assignments allowed, but those have all been removed. I do not recommend that anyone use program blocks anymore. There are a big source of unnecessary confusion. See http://go.mentor.com/programblocks

Answer 2

1. The purpose of "program" block in SystemVerilog is to guarantee that there will not be any race condition between the testbench and the DUT if the user encloses his testbench in program block(s) and keeps the DUT outside of program block(s). Another way to avoid race conditions is implemented by limiting DUT/testbench interaction to interfaces/clocking blocks. Also note that:

   a) blocking assignments (since they are executed immediately and therefor the result of the execution can vary with the order of execution of threads) can lead to race conditions

   b) hardware (RTL) variables can only be static

   Given the whole scenario, the compiler makes out that the blocking statement could lead to a race condition between the DUT and the testbench. And hence the error.

2. When you use non-blocking assignment, the assignment is scheduled and not executed immediately. It would get executed once the scheduler gets a chance to execute it. And that would happen only after the present thread yields because of a blocking expression that involves time increment. In the given code snippet that happens once the executing thread encounters #1; the $display after #1 sees the result of the non-blocking assignment while the one before does not.