Jump to content

chrisspear

Members
  • Content Count

    10
  • Joined

  • Last visited

  1. Hi Dave and others, One thing puzzles me - everyone keeps mentioning having to debug the method generated by the field macros. Why? I have built the habit of adding variables to the field macros whenever I add them to a class, and have never had to step through the inner workings of these methods. Chris P.S. And thanks for your concern, but I have not broken anything in months!
  2. So what do you feel about uvm_do? These six little letters, the shortest UVM macro name, conceal the most complex code that generates and schedules transactions. It is a great way to hide these details from new users, and even experienced users can eliminate many lines of code with this tried and true macro. Think about it: every line of code you write is one more opportunity for a bug. Back in the days of the methodology wars, some vendors poked fun at VMM because it had 6 macros. Then OVM came out with over 200 macros and UVM has even more. Here is a useful one. How about a factory create macro to replace: drv = my_driver::type_id::create("drv", this); with just: `uvm_create(my_driver, drv);
  3. So what is your advice on what to use in UVM and what to avoid? Is uvm_do the best thing since sliced bagels, or Satan's spawn? (BTW - one of the leading reason for emergency room visits is sliced hands from trying to cut a bagel. It's trickier than it looks!) Chris
  4. I just saw a presentation on UVM tips and it recommended to NOT use the uvm_field macros. Several companies have come out and said that these generate large, cumbersome methods that are hard to debug, and that you should write the methods yourself. IMHO, this seems like bad advice. Having written these methods for VMM, I find it error prone and a waste of time. Why spend 10-20 minutes creating these when the macros do it automatically? Once you waste an hour debugging the copy method when you leave out one variable, you stick with the macros. And how slow are these automatic methods? They never show up on the simulation profiler. This reminds me of when I used to change the oil on my car, and then left a rag on the engine that caught fire and cost me $200 to replace the O2 sensor, and could have ended up much worse. How much was I saving? It is your time that is the most valuable thing. Use the macros to save coding time and debug time. Spend your time on something creative like understanding Flits!
  5. VCS has supported SV calling Vera and Vera calling SV for a long time. Likewise, Vera classes can be instantiated in SV, and even extended from one language to another.The two languages are close enough that one compiler can handle both languages. So keep your tried and true Vera code and use it in your UVM testbench. Of course you need to plan how to merge the test phases in your Vera models with UVM, but the new methodology has constructs specifically designed for this. Chris Spear Synopsys
  6. Hmm, maybe I tweaked some other code. The error is from a very elaborate UVM message that is doing something like: str = "That didn't work, try $psprintf(\"%s\", something);"; $display(str); The issue is that VCS sees the %s in the string as a print specifier. The message really should have two percent signs. As for the warnings, there must be some places deep in UVM that randomize sequences where a handle is null. Chris Spear
  7. Here is a terminology question. Cadence uses the term, "collector" to refer to the transactor that sits on the bus and collects transactions based on signal changes, and then sends those transactions to a "monitor". This seems the opposite of how others use these terms, where the monitor is the low-level passive BFM, and it sends transactions up to a scoreboard collector, functional coverage collector, etc. I could not find the term "collector" in the UVM documentation. Thanks! Chris Spear
  8. The example is missing a call to super.build() in the build method. If you add this, VCS runs the example successfully. Chris
  9. There seems to be a problem behind a problem. Some unknown issue is causing a UVM fatal message. The fatal message has embedded in it a "$psprintf(\"%m.%s\",var)" Pardon me if my quoting is off. When process_message is called, it tries to do a $display of this. VCS sees the %s and looks for a string argument to the $display, and chokes. I'm going to work with VCS R&D to find the root cause and also see if the message is bad. Chris
  10. Here is my version of a sequence from the Practical Guide to UVM, that shows a write followed by a read. class apb_read_write_word_seq extends uvm_sequence #(apb_transfer); `uvm_sequence_utils(apb_read_write_word_seq, apb_master_sequencer); rand bit [31:0] start_addr; constraint c_addr {start_addr[2:0] == '0; start_addr <= 16'hFFFF;} function new(string name="apb_read_write_word_seq"); super.new(name); `uvm_info("INFO", $psprintf("%m"), UVM_HIGH); endfunction virtual task body(); `uvm_info("SEQ_NAME", $psprintf("%m"), UVM_HIGH); `uvm_do_with(req, {req.addr == start_addr; req.direction == APB_WRITE; }); `uvm_do_with(req, {req.addr == start_addr; req.direction == APB_READ; }); endtask endclass : apb_read_write_word_seq
×
×
  • Create New...