Jump to content
c4brian

bus monitoring : Using SVA to pass transactions to monitor?

Recommended Posts

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?

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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). 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...