bus monitoring : Using SVA to pass transactions to monitor?

[c4brian]

I have a SV interface which hangs off a bus, waiting for transactions to occur.  I use SVA to look for sequences, and verify correct protocol.  Each of these SVA constructs have implication operators.

 

I use the non-vacuous pass action block to trigger an event; my bus monitor sees this event, then snags all the appropriate values off the bus and builds a transaction.

 

In every example I've seen, the monitor is manually looking for the correct signal sequence to know when to build transactions.  But, if you are using SVA to enforce protocol on the bus already, why not just use the above approach?  I'm asking because I've never seen an example where this is done.

 

Furthermore, I've never seen a monitor actually refer to the clocking block conditioned signals; always the actual bus lines.

 

thoughts?

 

[tudor.timi]

There was an article on exactly this in an older edition of Verification Horizons. I can't find it at the moment, unfortunately. SVA sequences provide a nice way of describing your protocol and end up being much cleaner than procedural code in a monitor.

 

It would be cool if SVAs could also somehow be used to offload tasks from the driver (the complementary of the monitor). This would lead to less redundancy.

[karandeep963]

I think here is the link which Tudor pointed ("There was an article on exactly this in an older edition of Verification Horizons"): http://s3.mentor.com/fv/verification-horizons-publication-february-2013.pdf

[tudor.timi]

That's not the one, but it's also a pretty cool article. The one I meant was the October 2013 issue: https://s3.amazonaws.com/verificationhorizons.verificationacademy.com/volume-9_issue-3/complete-issue/stream/volume9-issue3-verification-horizons-publication-lr.pdf

[c4brian]

Thanks for the suggestions.  The articles complement each other.  I concur; if the big draw for SVA is its clear and concise description of temporal sequences, driving would fit in nicely.  Assertions Instead of FSM/logic for scoreboarding has a in-depth example, and the other paper discusses individual techniques.

 

In SVA in a UVM Class-Based environment, Ben Cohen recommends using immediate assertions for $cast and randomize(); I thought the the consensus was this was not recommended because assertions can be disabled?

[tudor.timi]

I'd also advise against using assert for casts and randomization because when you disable such an assertion, your simulator might decide to not do the randomize or $cast at all (some sims do it, some don't, not sure if it's an LRM gray area). 

[dave_59]

It's not a LRM gray area. People are just lazy when specifying a global disable.

[tudor.timi]

It's not a LRM gray area. People are just lazy when specifying a global disable.

Don't quite get what you mean.