Altair RISE

A program to recognize and reward our most engaged community members

Nominate Yourself Now!

Assertion errors are always reported in negedge

Hi, I've recently started working with some assertions in a project. All the assertions I am working with are designed to be evaluated in every posedge of the clk, but every time an assertion fails, the time reported in the log matches with a negedge in the waveform. Just for checking the behavior of the tool, I modified the asssertions to be evaluated in the negedge and the errors continue to match to a negedge time.

I am concerned about the assertions evaluated in a posedge. Could it be that they are not being evaluated the right way?

assertion issues.png

Find more posts tagged with

DSim Studio

Accepted answers

All comments

ChristineAndress

Hello,

An assertion with leading clock @(posedge clk) should be evaluated on the posedge of the clock. Could you send more information about your example? Would it be possible for you to provide a cut-down example exhibiting the behaviour? If not, then at least the full assertion statement, including any macros/functions that get called in the action blocks.

Could you also try running your example with the command line option -noopt added to your DSim's image compilation command, and see if the behaviour changes?

Thanks,
Christine

Susana Sevilla

Tried using the -noopt command but the behavior did not change.

The error is occurring in a FIFO, the idea of the assertion is to continuously check that if the FIFO does not have pending data, it is not possible to pop data from it.

The full assertion and its error message is the next one:

The fifo_out_asserts module is instantiated in the next bind module:

This bind module is instantiated in the top file as shown below:

Nowadays, the error is not appearing because we were able to find the bug in the design that was causing the assertion to fail. But it was a little bit hard to find the bug due to this issue of having the error shown in an unexpected edge.

ChristineAndress

In your example, you are binding i_clk to the signal that is used as the assertions' clock. What is i_clk? If i_clk is the inverse of the clock, that would explain why it would seem like the assertions are reporting on the negedge of the clock.

Could you modify the `uvm_warning message in the failing assertion to ascertain what the signals are at the level where the assertion is evaluated?

no_pop_when_empty_assert :
assert property (no_pop_data_when_fifo_is_empty)
else `uvm_warning("fifo_out_asserts", $sformatf( "Property no_pop_data_when_fifo_is_empty failed! DUT musn't pop FIFO OUT when is empty. sampled(POP)=%b sampled(PENDING)=%b, clk = %b, reset_n=%b", $sampled(pop), $sampled(pndng), clk, reset_n))

Shaun_Altair

@Susana Sevilla Does @ChristineAndress 's comment above answer your question? If so, could you please accept it as the Answer?