Search the Community

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 || req_b_bank_id == 1 || req_c_bank_id == 1; cp_bank_2_hit: coverpoint req_a_bank_id == 2 || req_b_bank_id == 2 || req_c_bank_id == 2; //cross coverpoint when all the banks (0,1,2) are being accessed at the same time. ccp_all_banks_active: cross cp_bank_0_hit, cp_bank_1_hit, cp_bank_2_hit { bins all_hit = binsof(cp_bank_0_hit) intersect {1} && binsof(cp_bank_1_hit) intersect {1} && binsof(cp_bank_2_hit) intersect {1}; } Here I was expecting just one bin to be created for the cross coverpoint. However, I noticed other combinations(2^3=8) were generated. Example 2: Creating bins for coverpoints cp_bank_0_hit: coverpoint req_a_bank_id == 0 || req_b_bank_id == 0 || req_c_bank_id == 0 { bins hit = {1}; } cp_bank_1_hit: coverpoint req_a_bank_id == 1 || req_b_bank_id == 1 || req_c_bank_id == 1 { bins hit = {1}; } cp_bank_2_hit: coverpoint req_a_bank_id == 2 || req_b_bank_id == 2 || req_c_bank_id == 2 { bins hit = {1}; } //cross coverpoint when all the banks (0,1,2) are being accessed at the same time. ccp_all_banks_active: cross cp_bank_0_hit, cp_bank_1_hit, cp_bank_2_hit { bins all_hit = binsof(cp_bank_0_hit.hit) && binsof(cp_bank_1_hit.hit) && binsof(cp_bank_2_hit.hit) ; } The above code accomplishes the goal and only one bin was created, with other combinations not covered, as desired. Not sure why this change behavior, found it interesting nevertheless. I thought both should accomplish the same, maybe I was wrong. Feel free to comment.

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 below might not be syntactically right, and I intentionally leave the factory registration, new(), build() etc. in order to be concise. `uvm_analysis_imp_decl(_transaction_A) `uvm_analysis_imp_decl(_transaction_B ) `uvm_analysis_imp_decl(_transaction_C ) class coverage_class extends uvm_scoreboard; bit req_a; //request coming from transaction A bit req_b; //request coming from transaction B bit req_c; //request coming from transaction C uvm_analysis_imp_transaction_A #(trans_a, coverage_class) trans_a_port; uvm_analysis_imp_transaction_B #(trans_b, coverage_class) trans_b_port; uvm_analysis_imp_transaction_C #(trans_c, coverage_class) trans_c_port; covergroup cg; coverpoint req_a; coverpoint req_b; coverpoint req_c; cross req_a, req_b, req_c; //Want to capture a case where all 3 requests go high at the same time from 3 different interfaces. endgroup //write function to capture trans_a virtual function void write_transaction_A(trans_a t); req_a = t.req; cg.sample(); endfunction //write function to capture trans_b virtual function void write_transaction_B(trans_b t); req_b = t.req; cg.sample(); endfunction //write function to capture trans_c virtual function void write_transaction_C(trans_c t); req_c = t.req; cg.sample(); endfunction endclass I also realize that, when 2 requests are high at the same time, there might be a delta delay between the two. Say "write_transaction_A" happens a delta before "write_transaction_B" (still the same timestamp). So when transaction_A happens, req_a is set to 1 and the covergroup is sampled. At this delta time, transaction_B has not occurred so, req_b is still 0. In the next delta cycle, write_transaction_B happens and so, req_A as well as req_B is asserted, and covergroup is sampled again. I see 2 issues here: 1. We are sampling the covergroup more than actually required. Is there a better way of sampling the covergroup? 2. Where do we clear the req_A/req_B/req_C variables in order to be sampled again. Is there a better way of accomplishing the same task? Please share your thoughts.

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 test was even performed. However, I can very quickly write a test, and it doesn't require any components. The integrity of the test is paramount here. With option 2, I've got to use a bound virtual interface to access the state bits of the DUT, and also build a coverage collector. ------------------------------------------------------------------------------------------------------------------- My heart wants to simply define my coverage model entirely via covergroups, and then generate stimuli until I meet 100%. My brain, however, says no, no... don't verify that you sent the sequence Cmd A -> Cmd C -> Cmd E -> Cmd A, just write a directed test that does that. Thoughts?