Jump to content

cliffc

Members
  • Content Count

    49
  • Joined

  • Last visited

  • Days Won

    2

cliffc last won the day on September 8 2014

cliffc had the most liked content!

About cliffc

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We are not using Questa on this project, so the question is, do I really need to specify the work library? I am thinking that there may be some separate-compilation reason to add or exclude it. I actually helped get configurations into the Verilog-2001 Standard, so as mentioned before: The IEEE 1800-2017 Standard does not show any examples with the added "work" library. Why would I need it? Regards - Cliff
  2. I am working on a large project with multiple Verilog/SystemVerilog config-endconfig files. Many of the config files have the statement: default liblist gates_lib work; I understand "default liblist" and the "gates_lib." I have not previously seen the "work" library at the end of the default liblist statement. Can someone explain what this is used for? I don't think there are any libraries specifically defined for "work." This looks like it might be related to separate compilation. The IEEE 1800-2017 Standard does not show any examples with the added "work" library.
  3. Using VCS, I can compile and run multiple top-level modules. In the example I am running, I have a dut module and a bind-file module. The bind-file module is nothing more than: module bindfiles; bind dut pLib_dut p1 (.*); endmodule When I compile and run, I indeed see both top modules have been compiled: Top Level Modules: bindfiles dut And both run just fine as expected. Now the question: If I compile both top modules, can I run simv with just the dut module and ignore the bindfiles module? I would like to simulate both with the bindfiles and without th
  4. It is very common to include two identical agents in a UVM testbench. One uses a default-active sequencer-driver pair and the other sets an is_active bit to uvm_passive to disable the sequencer-driver pair. Both monitors are identical and sample the VIF signals to re-assemble a standard transaction that is then sent through the monitor-analysis port to the agent-analysis port and on to both sides of the scoreboard. Since the analysis port can write to multiple analysis export/imp-ports, when building simple UVM testbenches, why not just use one active agent that drives both sides of the sc
  5. The parameterized uvm_driver base class includes a built-in uvm_seq_item_pull_port called seq_item_port. The parameterized uvm_sequencer base class includes a built-in uvm_seq_item_pull_imp called seq_item_export. These are always connected in the agent. Every UVM agent that I create declares a uvm_analysis_port that I connect to the tb_monitor's uvm_analysis_port. Question for UVM Library Developers: Is there any reason the uvm_agent base class should not enhanced to be parameterized to the transaction type and include a built-in uvm_analysis_port? Regards - Cliff Cummings
  6. The parameterized uvm_driver base class includes a built-in uvm_seq_item_pull_port called seq_item_port. The parameterized uvm_sequencer base class includes a built-in uvm_seq_item_pull_imp called seq_item_export. These are always connected in the agent. Every UVM agent that I create has a tb_monitor extended from the uvm_monitor and everyone declares a uvm_analysis_port. Question for UVM Library Developers: Is there any reason the uvm_monitor base class should not be enhanced to be parameterized to the transaction type and include a built-in uvm_analysis_port? Regards - Cliff Cumm
  7. Thanks @cgales - This was indeed one of the biggest issues with this example. Regards - Cliff Cummings
  8. Hi, All - My thanks to those who responded and especially to my friends and colleagues, Tom Fitzpatrick of Mentor and Heath Chambers of HMC Design Verification for helping me to spot and correct the problems. The biggest issue was that I passed the sequencer and predictor handles to the reg-model using the set_sequencer command. I should have passed the sequencer and adapter handles to the set_sequencer command. This caused the null-handle references (SIGSEGV - this was not a tool issue - this was my mistake): ERROR: model.dutmap.set_sequencer(agnt.sqr, predict); CORRECT: m
  9. Hi, All - I am hoping someone can spot my error in the following example. I am missing a handle while running a test and getting a handle fatal message. I am not 100% sure I am assigning the correct dutmap and the error happens when I try to do a reg-write from the tr_sequence. Pertinent code below. More code upon request. Regards - Cliff From test1.sv: task run_phase(uvm_phase phase); tr_sequence seq = tr_sequence::type_id::create("seq"); //---------------------------------------- phase.raise_objection(this); //`uvm_do(seq) //seq.start(null)
  10. Hi, @UWES - Thanks for the comments. I was not using a virtual sequencer and I believe I also was extending my tr_sequence from uvm_sequence instead of my tr_seq_base class. I am past this problem and am still having issues but will open a different thread. Regards - Cliff
  11. Hi, All - Hoping for a little help on this one. I have a very simple UVM register testbench but am having troubles getting it to work and having troubles figuring out the correct way to start the tests (there is lots of documentation on UVM REG setup except the final step of starting the test). Below is the error messages, the env.sv fle and the test1.sv file that I am using. I would be happy to tar-up the entire example if someone would like to look at more of my files. Thanks to anyone who can figure out this problem. Regards - Cliff # UVM_INFO verilog_src/uvm-1.1d/src/reg/uv
  12. @Alan - I have always used the almost-empty virtual sequencer with references to the sub-sequencers and used the env to copy the subsequencer handles to the handles declared in the virtual sequencer, then my vseq_base class would $cast the m_sequencer handle to the vseqr handle and use that handle to set the sub-sequencer handles declared in the vseq_base class. Then I could extend the vseq_base to create virtual sequences that started on the two sub-sequencer handles. Relevant code from the vseq_base and vseq classes below. Could you give an equivalent example of how you copy the hand
  13. Hi, All - I have seen examples of sequences started on a null sequencer of the form: seq.start(null). How is a sequencer specified for these sequences? Thanks. Regards - Cliff
  14. Death to Programs! It took me years to arrive at this conclusion, but I now believe that programs were a bad idea and should be avoided completely. After some convincing by other committee members, I voted for inclusion of programs into the SV Standard and I now regret that vote (please forgive me! ) The idea behind the program was that if an engineer applied stimulus on the active clock edge, the RTL design would completely respond to the clock, then the testbench would calculate new stimulus values on the same clock edge and send them into the RTL design, and any combinationa
  15. Hi, all - When using uvm_config_db#(...)::set(...) from a top-module, is there any difference between using set-context=null and inst_name "*" and using set-context=uvm_root::get(), and inst_name "*"? top-module examples: uvm_config_db#(virtual dut_if)::set(null, "*", "vif", dif); uvm_config_db#(virtual dut_if)::set(uvm_root::get(),, "*", "vif", dif); Of course, per the UVM Class Reference, setting a context to null means that the inst_name provides the complete scope and "*" means any scope. Setting the context to uvm_top (returned by uvm_root::get()) and indicating "*" any scop
×
×
  • Create New...