Search the Community
Showing results for tags 'coverage'.
Found 4 results
-
Does UVM_SC has support for coverage bin and coverpoints? Want to know if user can add functional coverage classes. Thanks Akhila
-
I was under the assumption that once bins are created, the coverage would be collected only for those bins and the remaining combinations would be ignored. However, I noticed this was not the case when using intersect. Intention: Assuming there are 3 banks (0,1,2) and 3 requestors(a,b,c). I wanted to write a coverpoint that covers the case where all 3 banks are active at the same time. Example 1: No bins for coverpoints and use intersect for cross coverpoint cp_bank_0_hit: coverpoint req_a_bank_id == 0 || req_b_bank_id == 0 || req_c_bank_id == 0; cp_bank_1_hit: coverpoint req_a_bank_id == 1
-
I need to implement coverage across multiple interfaces. For example in the arbitor designs, it is of interest to see if multiple requests from different agents are driven at the same time. All the texts have only discussed coverage specific to the interface or transaction. I have an idea of implementing this, but not sure if it is the right way forward. Here is my idea: First place, instead of extending the coverage class from uvm_subscriber, I intend to extend it from uvm_scoreboard. This is because, uvm_subscriber is tied to a transaction type, whereas uvm_scoreboard is not. The code bel
-
I want to verify the following behavior: "DUT shall only accept command A, and reject all others while in the Powerup state. While not in Powerup, accept all commands" This is the state of the DUT following a reset. Option 1 - No covergroup After a reset, send all commands that are NOT A, followed by command A. If the scoreboard doesn't fail, then I'm good to go. Option 2 - Covergroup Have a monitor hanging off an agent that, when it detects a command is written, it crossed the state of the DUT with the command being written. With option 1, I have no coverage metric that the
