Jump to content

sas73

Members
  • Content Count

    35
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by sas73

  1. @David Black That "general public" is the users of UVM and among them are many experts that are not members of Accellera and will never be. Expert users that are willing to spend their own free time on providing feedback are certainly serious about that. I can see that only paying members have the right to change the code but why a fee for looking and commenting on the code that will be open eventually anyway? I'm assuming that it's open for people to read and react to but wouldn't it be better to get that feedback before any mistakes are released? Especially with the long release cycles.
  2. @Taichi Ishitani That would certainly narrow the scope a bit but I would hoping for something that would pinpoint the wait statement. Is there a instrumentation mechanism in place? That would require me to add code manually but it would also be useful for other scenarios, for example to locate a loop that is stuck.
  3. 2 days! That's fast response Exactly! If you're not open in the design/pre-release phase you're likely to miss use cases and if the members have committed themselves to solutions and switched their focus to other tasks I imagine that there will be an unwillingness to go back and redo things even if new important insights have been revealed. I think most users would like a code base they can build upon, not one that needs adaptations to make it work. Being fully transparent about the code in the making will reduce the risk for such adaptations What I'm suggesting
  4. When a testbench hangs such that the UVM timeout is triggered I get a message like this reporter [PH_TIMEOUT] Explicit timeout of 10 hit, indicating a probable testbench issue Are there ways in which UVM can help me identify the cause of this timeout? For example, special wait statements that would notify me if they are blocking when the timeout hits.
  5. Unfortunately I'm not with a member company. I was hoping that I'd have read permissions regardless of my current affiliation. As a user I'd like to see the connection between discussions in the official forum, the issues reported to the issue management system, and the code being developed in response to that. The ability to immediately test that code and possibly give feedback as code comments or a pull request. More like Github, Gitlab and other platforms. Seems to me that this would be a more efficient way to give and get user feedback.
  6. Are there any plans on continuing using the GitHub repository for such releases or has it been discontinued?
  7. The github repositories are the actively developed code for Accellera’s reference implementation (sourceforge was made read-only when github was spun up). That being said, github stores the active development for the reference implementation, not for the standard itself. The class reference (ie. The “Standard”), as well as the Accellera Reference Implementation are officially published on accellera.org: The UVM 1.2 Standard: http://accellera.org/images/downloads/standards/uvm/UVM_Class_Reference_Manual_1.2.pdf The UVM 1.2 Reference Implementation: http://accellera.org/images/downloads/stan
  8. Reading a bit further I found the concept of API sequences that can be provided by the agent developer. For example a write sequence that hides the details I gave in the example above. The write sequence can then be used in a higher layer sequence (Mentor calls this a worker sequence). The write sequence also provides a write method to start itself and the worker sequence calls that method with a specific address and data. Note that this approach completely overrides randomization of sequence items and moves that responsibility to the sequences.
  9. As a sequence writer I should ideally not be exposed to the implementation details of the driver that have been discussed in this thread. For example, the structure of the sequence item(s), whether get/put, get_next_item/item_done or something else is used. I would like the driver to provide an API excluding all of that. Something similar to this that could be included in the sequence write(<constraint on address and data>) . Does SV allow you to pass a constraint as an argument or is there another way of doing that?
  10. Note that it's not only transactions you can reuse. You can also reuse the handling of transactions (the visit method in the visitor) in some cases, for example in the case you have a transaction for a time delay. You can "inherit" several such handlers using mixins.Thanks for this mixin post @tudor.timi
  11. That's true. If I want to fully randomize I need to add some extra code in my sequence. It seems that it also causes a performance hit making that solution slower despite less randomization. However, if I want to do a write-delay-read sequence with random address and data I can express that more explicitly instead of constraining variables to be a fix value. In this case the solution with separate transactions becomes faster. In these tests I used randomize() everywhere and the differences are in the percentage range. I more concerned about the difference between randomize() and $urandom which
  12. When I failed to see examples of transaction reuse I though that maybe people put their reuse effort elsewhere, for example by moving the pin wiggling functionality (which comes in different flavors) to the transaction class so that the driver becomes more generic. I agree that transactions are data classes and I do want to reuse them so moving the pin wiggling into these classes is not something I want. The visitor pattern is also a way to create a more generic driver while not destroying the potential for transaction reuse. The visitor would remove the need for
  13. Being able to do simple reads/writes is indeed a reusable abstraction. I've seen the TLM generic payload but that's also the only attempt for a reusable transaction I've seen. Are there others? To verify a bus interface you need to be concerned about the details but when the focus of your testbench is to verify the functionality which the bus interface is configuring you get far with the simple read/writes. A driver could support both reusable simple read/write, reset, delay and specialized transactions used when fully verifying such an interface. I like to think of the driver
  14. Thanks for your answers @tudor.timi Looking at the examples out there it seems like both the single and double data field approaches are popular. What people prefer depends on their main concerns. You're concerned with the number of if statements but Mentor who takes the double data field approach (https://verificationacademy.com/cookbook/sequences/items) expresses other concerns: I'm also concerned about randomization performance (http://forums.accellera.org/topic/6275-constrained-random-performance) but splitting into two data fields doesn't improve performance. You sti
  15. The list of open source UVM repositories can also provide an answer to question 4. I couldn't find any well supported (project with many stars) library of sequence items. There are many verification components for various bus protocols but they all have a single sequence items tailored specifically for that bus. This leads me back to question 3...
  16. The blog post also touches my third question although not providing an answer
  17. Looking at open source UVM repositories I think it safe to say that keeping all transaction types within the same sequence item class is the most common design pattern (the only pattern I found when looking at many of these repos). Luckily, I also found an interesting blog post about type handles that address what I'm looking for. There is a way of doing what I'm looking for although standard practice seems to be something else. I guess that keeping everything in one packet is more convenient. I think this answers my first question.
  18. I found an example from UVM Primer that has dedicated transactions as well as monitors for input and output so I guess that answers my second question.
  19. I'm not looking for complete answers. Any clues that you can provide are appreciated.
  20. While trying to learn UVM and more specifically the use of uvm_sequence_item I keep running into the same example which looks something like this class bus_transaction extends uvm_sequence_item; rand enum {READ, WRITE} operation; rand bit [31:0] addr; rand bit [31:0] write_data; bit [31:0] read_data; ... This design pattern raises a number of questions: 1. To me read transactions and write transactions are two separate "things" that deserve their own classes (single responsibility principle). The more operations we add to a transaction class the more t
  21. @David Black I did stumble upon an accellera/uvm repository on GitHub. Seems to be what I was looking for although it has been dead since UVM 1.2. Why have it there and not use that platform?
  22. Dave, I'm not trying to replace the constraint solver but rather find the situations where the constraint is simple enough and performance important enough to favor the procedural approach. I'm learning SV constraint but I think your example of selecting 8 unique values between 10 and 20 can be expressed as class transaction; rand int arr[8]; constraint c { foreach(arr[i]) arr[i] inside {[10:20]}; unique {arr}; } endclass A procedural implementation of this based on $urandom_range will indeed result in extra calls when the unique constraint is added but
  23. Thanks for your reply David. The two approaches behave differently but is there a reason why one is better than the other provided I'm aware of these differences and know how and when code changes affects my ability to repeat a test? I tried several different simulators and the performance hit was between 15x and 25x. This seems to be a problem inherent to all constraint solvers. If that is the case wouldn't I be better off using randomization system calls when possible?
  24. While trying out UVM/SystemVerilog with a very simple transaction/constraint class transaction extends uvm_sequence_item; rand int value; constraint c { value inside {[10:20]}; } endclass I found that there is a significant performance difference if I randomize a transaction like this void'(t.randomize()); or if I do t.value = $urandom_range(20, 10); The first approach is 15x to 25x slower depending on simulator! In my case I have a dummy testbench only consisting of a producer sending a large number of transaction to a consumer. Will this also
  25. Thanks @dave_59. That would be the easiest way but in my case I want to verify that the message fields are what I expect, not only that a report has been produced. I ended up pushing the report message to a queue and then pop it in my test to verify the fields.
×
×
  • Create New...