1800’21017 states: $rose returns true (1’b1) if the LSB of the expression changed __to 1. Otherwise, it returns false (1’b0).
Thus, X to 1 is a rose.
@(posedge a); 1800’2017 9.4.2 Event control
A negedge shall be detected on the transition from 1 to x, z, or 0, and from x or z to 0
— A posedge shall be detected on the transition from 0 to x, z, or 1, and from x or z to 1
$stable(a) 1800’2017
$stable returns true (1’b1) if the value of the expression did not change. Otherwise, it returns false (1’b0). Thus, X to X is a no change
$past returns the sampled value of expression1 in a particular time step strictly prior to the one in which $past is evaluated (see 16.5.1 for the definition of sampling in past clock ticks).
Thus, if past was X, $past returns XX.
If 1st clock (i.e., no past exists). it is the default sampled value of a static variable is the value assigned in its declaration, or, in the eabsence of such an assignment, it is the default (or uninitialized) value of the corresponding type
Thank you Ben.
I am still little confused on $rose(a); and @(posedge a);
Like you said, both will detect if value changes from “0/x/z” to “1”
I was wondering if it is possible to use’m interchangeably ?
always @(posedge a)
always $(rose a)
property @(posedge a)
property $(rose a)
Or it is the rule to use only events while using always and properties, and why is that rule?
Also can you please throw your inputs on this.
logic a;
If “a” needs to toggle every clock cycle - i.e.
1 0 1 0 1 0 1 0
Which one is correct assertion to check? from below two options?
I am not sure always$rose(a) is a good coding style. But let me answer your first question:
Difference between always@(posedge a) v/s always $rose(a):
always@(posedge a) is an event which is checked instantly. It will activate in the same cycle if a is high.
While always$rose(a) is checked in different way. It checks whether a was low in the previous cycle and high in current cycle. If a is high in this cycle, procedural block always$rose(a) will get executed in the next cycle as mentioned above.
In reply to sa5691:
Before answering the specific questions, let me review important related points that can clarify some of your concerns:
What is an event? 1800’2017: Every change in state of a net or variable in the system description being simulated is considered an update event.
Processes are sensitive to update events. Examples of processes include, but are not limited to, primitives; initial, always, always_comb, always_latch, and always_ff procedures; continuous assignments; asynchronous tasks; and procedural assignment
statements
**sensitivity:**Processes are sensitive to update events. When an update event is executed, all the processes that are sensitive to that event are considered for evaluation in an arbitrary order. The evaluation of a process is also an event, known as an evaluation event.
1800’2017 9.4: Procedural timing controls: Time control statements are the # expression and @ expression constructs.
…The first type is a delay control, in which an expression specifies the time duration between initially encountering the statement and when the statement actually executes.
…The second type of timing control is the event expression, which allows statement execution to be delayed until the occurrence of some simulation event occurring in a procedure executing concurrently with this procedure.
…Simulation
time can advance by one of the following three methods:
— A delay control, which is introduced by the symbol #
— An event control, which is introduced by the symbol @
— The wait statement, which operates like a combination of the event control and the while loop.
Back to your questions:
There is a big difference between “what you can possibly do” and what you can safely do. You can drive a car on the wrong side of the road, but that there may be severe consequences in doing so. Keeping this in mind.
$rose: Syntax: $rose(expr [,clk_evnt])
// You can write
always @($rose(a, @(posedge clk)) ... // the rose of a is an event
// The process will wake up at every rose. Ok to do if this is what you want.
// Definitely NOT OK for RTL designs, but OK for testbenches.
// I don't believe that this type of structure is used often, and I personally prefer to
// stick to traditional approaches, like
always @(posedge clk) begin
if($rose(a) ... // the clock is inferred here.
// 1800'2017 9.2.2.1 General purpose always procedure
/* If an always procedure has no control for simulation time to
advance, it will create a simulation deadlock condition.
The following code, for example, creates a zero-delay infinite loop: */
always areg = ~areg;
always $rose(a) // Illegal because of no clocks
always $rose(a, @(posedge clk)) // creates a zero-delay infinite loop
// the result of the $rose is a value, true or false.
//-------------------
a_toggle : assert property (@(posedge clk) ##1 $changed(a));
a_toggle : assert property (@(posedge clk) 1 -> ##1 $changed(a)); // BAD practice
// The use of true as antecedent is meaningless and adds nothing, unless
// you are in a debugging mode and just want to examine the consequent