Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won

  1. Use +UVM_VERBOSITY=<your option HIGH/LOW/MEDIUM/DEBUG> on command line.
  2. Write a constraint for that. The idea is, for each element in the array, you iterate through all the elements of the array. If the index don't match, the make sure the values are not equal. This is O(n^2) complexity, there could be a better way of accomplishing the same as well. constraint c_unique_array_value { foreach(id_array) { foreach(id_array[j]) { if(i != j) id_array != id_array[j]; } } }
  3. 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
  4. This is my solution. Not necessarily the best one. Suggestions for improvements are welcome. If any of you find any shortcomings with this method, please let me know. Open to constructive criticism! /* Assume there are 3 requestors namely: A,B and C with reqA, reqB and reqC being the requests and gntA, gntB and gntC being the grants. Assumes the request and grant are on the same cycle Similar sequence and assertions need to be replicated for each requestor. Can concatenate the requests and grants into a bit vector, in order to save some redundant code */ //Denotes there is request and grant
  5. Are are any standard or recommended ways of verifying the functionality of the round-robin arbiter and more specifically checking the fairness? I'm looking for something that is scalable with the number of requestors. Functionality of the arbiter is as follows: - Say there are 3 requestors, req1, req2 and req3. The pointer points to req1 initially. Consider different cases for illustration. - If all 3 requests are asserted, req1 goes through and the pointer is updated to req2. - If req2 and req3 is asserted, then req2 will go through and pointer is updated to req3. - If just req3 is
  6. 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
  • Create New...