Hello, to satisfy simulation and synthesis requirements for $past, would the following solution be acceptable? Best regards, ed ---------- Definition of the behavior of $past: In the following I try to provide a definition of the behavior of $past that depends on the calling context. This definition is based on recent discussions in the SV-EC committee regarding the structure of scheduling regions. Namely, it appears that the structure may be changed so that there is symmetry between the "active" and the "reactive" regions. This would create an NBA-reactive region, similar to the NBA region in the "active" space. NBA-like assignments in programs would thus be scheduled to take place in the NBA-reactive region. The definition of $past that I propose uses either of the NBA regions to update the value of $past depending on whether the function is called from a module or from an interface. Recall that $sampled(x) returns the value of x from the preponed region of the current time step. If $past(x,,,@clk) is called from a module or interface (executing in the active region), the equivalent RTL implementation that defines the behavior of the function is always @clk past_variable <= $sampled(x); If $past(x,,,@clk) is called from a program (executing in the reactive region), the equivalent behavioral implementation that defines the behavior of the function is initial forever @clk past_variable <= $sampled(x); In assertions, it uses implicitly the $sampled value of the active form of $past. ---Received on Tue Dec 5 07:21:55 2006
This archive was generated by hypermail 2.1.8 : Tue Dec 05 2006 - 07:22:19 PST