Detection of Interrupt in Monitor

UVM
, ,
1

Hi,

Intention is to detect interrupt assertion within Monitor. Here is my simple attempt: edalink

I tested the code across the 3 main tools

On tool1 I observe Null pointer error from line 37 without observing $display messages on line 29 and 33

On tool2 I observe a Fatal message (Null instance encountered ..) from line 33

None of the three $display messages are observed ( although 2 of them occur before line 33 )

On tool3 I observe compilation error “Expressions of real, time, string and event types, as well as dynamic. SystemVerilog types, are not allowed in sampled system functions.”

Interestingly on commenting line 28 ::

On tool1 there is no error. Logically it doesn’t make sense why commenting line 28 makes the code work

On tool2 and tool3 the same respective output is observed

My questions are as follows

(Q1) Is there an issue with line 28 ? I added it to ensure get is successful. Without it the get would still be successful as B2 executes after B1 from source code perspective

(Q2) Can the clocking event (2nd argument) of Sampled value function reference a signal via virtual interface ?

(Q3) Can the expression (1st argument) of Sampled value function reference a signal via virtual interface ?

(Q4) Using +define+VINTF1

Can the clocking event within SVA reference virtual interface signal ? Or is there is a possibility of null pointer error ?

(Q5) Using +define+VINTF2

Can the sequence_expresssion within SVA reference virtual interface signal ? As the virtual interface has been fetched, the signal intr would be sampled after the clocking event I believe there should be no null pointer error

(Q6) Does the LRM restrict referencing virtual interface signals ( as clocking event / signal in sequence_expression / property_expression ) within a concurrent assertion ?

Thanks in Advance

AGIS

2

Any suggestions would be appreciated

3

SystemVerilog prohibits referencing interface members through a virtual interface handle in any context other than procedural code. Sampled value functions like $rose and concurrent assertions generate processes behind the scenes that sample values at time zero and at clocking events outside of procedural code.

The clocking event itself is not sampled so that should be OK. But I will check that out first.

4

Apologies for the late response Dave.

1800-LRM , 25.9 says

all the components of the underlying interface instance are directly available 
to the virtual interface via the dot notation.
These components can only be used in procedural statements; they cannot be used 
in continuous assignments or sensitivity lists.

Hence we observe compilation error for (Q4),(Q5) and (Q6)

I was going through LRM Section 16.9.3 but couldn’t find the above quote i.e these functions sample values at time zero. Am I missing something ?

It’s interesting that although the interface members are referenced via virtual interface in procedural code, tools throw null pointer error at run-time

(even though the uvm_config_db::get was done prior to referencing it)

(Q7) Is there a possible alternative to wait(vif_intf.intr == 1) to check for assertion of interrupt signal in Monitor ?

5

It’s a little convoluted.

Section 16.9.3 says

When these functions are called at or before the simulation time step in which the first clocking event occurs, the results are computed by comparing the sampled value of the expression with its default sampled value (see 16.5.1).

Then 16.5.1 says

The default sampled value of a static variable is the value assigned in its declaration, or, in the absence of such an assignment, it is the default (or uninitialized) value of the corresponding type (see 6.8, Table 6-7).

And then 6.8 says

Setting the initial value of a static variable as part of the variable declaration (including static class members) shall occur before any initial or always procedures are started

This effectively means these sampled value functions need the value they have before any procedural code starts executing at time 0.

6

Dave,

Three quick questions

(1)

Does this mean that a clocking event in sampled value function could be referenced via virtual interface provided it’s done in a procedural code ?

(2) Concurrent assertion a1 would be illegal as the clocking event accesses virtual interface signal outside a procedural block. Should it be a compilation error or run-time error ?

(3) Consider the following concurrent assertion statements

(a) sva1:assert property( @(posedge clk) a ##1 b);

(b) always@(posedge clk) begin
        sva2:assert property(a ##1 b);
    end

As per Section 25.9 of LRM, accessing virtual interface signals would be legal in (b)

Since (a) and (b) are equivalent, shouldn’t it be legal in (a) as well ?

7

The link to your EDAPlayground example is no longer accessible. It would be better to paste it directly into the post.

In (b), it’s still a concurrent assertion embedded inside procedural code, and not a procedural statement. So both are still illegal to reference virtual interface signals.

8

Have updated the post with the constraints

Wanted to confirm the following

(1) Does this mean that a clocking event in a sampled value function could be referenced via virtual interface provided it’s done in a procedural statement ?

(2) In the edalink mentioned at the top, concurrent assertion a1 is illegal since we access a virtual interface signal outside a procedural block.

As per LRM should it be considered a compilation error or run-time error ?

Currently two tools throw a run-time null pointer error i.e run-time error whereas one tool throws a compilation error