Jump to content

ljepson74

Members
  • Content Count

    107
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by ljepson74


  1. I am sharing something I stumbled on and learned from and also a question.

     

    Question) It seems I don't need to instantiate a program block for its initial statement/s to run.  If I just add it to the compile-list of files (note it is doing nothing necessary), it is compiled and initial statements in it run.  I am using VCS.  Why don't I need to instantiate the program block.  It is as if it is automatically created as a singleton.

     

    Statement) If I put an initial block in this program, the sim dies immediately when that initial block is done, even if there are other initial statements in the top-level module.  As I experiment with a program block for one of the first times, this has caused me some headaches.

    Then, I learned from the LRM:

    From SystemVerilog 1800 LRM, explaining why my simulation dies when 

    "When all initial procedures within a program have reached their end, that program shall immediately

    terminate all descendent threads of initial procedures within that program. If there is at least one initial

    procedure within at least one program block, the entire simulation shall terminate by means of an implicit

    call to the $finish system task immediately after all the threads and all their descendent threads originating

    from all initial procedures within all programs have ended."

     

     


  2. For a more primitive, but related question from a novice user, see: http://forums.accellera.org/topic/1938-extending-uvm-cmdline-processor-problem/

    I think I am looking for (some of) those functions to be virtual as well.

    I imagine I am not the only other one working on 'enhancing' or augmenting cmdline_processor features.  Perhaps we can form a wishlist and suggest it for UVM 1.2.


  3. I am trying to extend uvm_cmdline_processor as follows, but my extended version, ivm_cmdline_processor is not working.  It seems like the *ref values* might not be getting passed correctly.  There is no error message.  The get_arg_values that is called with iclp is seen I know, because I receive a simulator warning about not using a void'() with the function.  (This warning occurs for both the uclp and iclp usages, as expected.)  I am not sure about my duplication of the get_inst function to create and return a singleton, but have tried versions of this code w/ and w/o it.

    `include "ivm_cmdline_processor.svh"
    module top;
       import uvm_pkg::*;
    
       ivm_cmdline_processor iclp;
       uvm_cmdline_processor uclp;
    
       string values[$];
    
       initial begin
          $display(">>>> START TEST.");
    
          iclp=ivm_cmdline_processor::get_inst();
          uclp=uvm_cmdline_processor::get_inst();
    
          iclp.get_arg_values("+",values);
          foreach (values[iii]) begin
            $display("iclp>>>%0d: %0s", iii, values[iii]);
          end
    
          uclp.get_arg_values("+",values);
          foreach (values[iii]) begin
            $display("uclp>>>%0d: %0s", iii, values[iii]);
          end
    
          $display(">>>> END TEST.");
       end
    endmodule : top
    
    import uvm_pkg::*;
    class ivm_cmdline_processor extends uvm_cmdline_processor;
    
       static local ivm_cmdline_processor m_inst;
    
       static function ivm_cmdline_processor get_inst();
          if(m_inst == null) 
            m_inst = new("ivm_cmdline_proc");
          return m_inst;
       endfunction
    
       function new(string name = "");
          super.new(.name(name));
       endfunction : new
    
    endclass : ivm_cmdline_processor
    Reason for attempt:
    I would like to add features to the uvm_cmdline_processor.  To start, I'd like to enhance +arg checking by checking that the +args supplied are from a list of valid +args.
     
    Typos are too common from my fingers and without this functionality, typos go unnoticed.  (Once I even was in a different sim environment than I thought and was happily running a test with plusargs for a completely different testbench, wondering why things weren't working as I expected.)
     
    I realize that I might create an object or 'shell', around uvm_cmdline_processor and do my checking in this 'shell'.  I have a version of this now, but I'd like to make it generic so that it may be used across 'all' testbenches.  Rather than polishing my shell, I am first trying to extend uvm_cmdline_processor and running into these problems.
     
    Any ideas about this?
     
    (I just discovered this next post from about 30min ago.  Thanks, Srini.  I think my problem is the same, but am not sure as I am not trying to 'mix' which handle (parent or child) points to my extended version of uvm_cmdline_processor.  Yes, I am confused about this.   re: http://forums.accellera.org/topic/1937-uvm-cmdline-processor-why-its-methods-are-non-virtual/ )

  4. After further investigation.....

     

    1) The offending code was generated from a non-SystemVerilog spec file

    2) The offending code was CLASS, not class.    The original example might have been more clear.  I just retyped it rather than pasting the original offending code.  As you can see, I hadn't tested the variable of uppercase/lowercase.

     

    *)  I learned (remembered) SystemVerilog is case-sensitive.   I learned from SV Spec 1800-2012.pdf section 5.6.2, Keywords:  "All keywords are defined in lowercase only."

     

    *) The tool, correctly, does not issue an error or warning when uppercase is used.  (When lowercase is used, an error is issued, as expected.)   Emacs verilog-mode seems to be caps-insensitive, so had the 'error' in indentation when a non-keyword (CLASS in this case) is used.

     

    *) So, my original example masked the issue, as I incorrectly removed capitalization.  Sorry for the confusion.  And I agree completely with the verilog-mode folks' (and uwes') warning about keywords (and even close-to-keywords, I'll add) being used.

     

    1) I'll point out to the verilog-mode folks the case issue I had and perhaps they will change their code.

    2) I'll talk with our team about how we might avoid keywords across multiple languages in our generated code.

     

    I've learned a bunch from this small indentation issue that had been nagging me.

    thanks, all.

  5. Emacs auto-indent for verilog-mode messes up when 'class' is used other than as an SV keyword.

     
    begin
       xyz.field1 = 1;
       xyz.field2 = 2;
       xyz.class =  3;
          xyz.field3 = 4;
    end
    
    Because the property name of an object (with instance name xyz above) is named "class", it screws up indentation.
     
    Is anyone here involved with Verilog/SV-mode for emacs or savvy enough to know how to resolve this?
     
     
     
    (Yes, this is perhaps on the wrong forum completely, but I think this likely would affect many users and is the most appropriate section of this forum.)
     
     
    From my .emacs file:
    ;;;;;;;;;;;;;;;;;;;;;;
    ;; Mac's Verilog Mode
    ;;;;;;;;;;;;;;;;;;;;;;
    (defun prepend-path ( my-path )
      (setq load-path (cons (expand-file-name my-path) load-path)))
    (defun append-path ( my-path )
      (setq load-path (append load-path (list (expand-file-name my-path)))))
    ;; Look first in the elisp directory which is ...
    (prepend-path "~/elisp")
    ;; Load verilog mode only when needed
    (autoload 'verilog-mode "verilog-mode" "Verilog mode" t )
    ;; Any files that end in .__ should be in verilog mode ...
    (setq auto-mode-alist (cons  '("\\.v\\'"    . verilog-mode) auto-mode-alist))
    (setq auto-mode-alist (cons  '("\\.vh\\'"   . verilog-mode) auto-mode-alist))
    (setq auto-mode-alist (cons  '("\\.hv\\'"   . verilog-mode) auto-mode-alist))
    (setq auto-mode-alist (cons  '("\\.sv\\'"   . verilog-mode) auto-mode-alist))
    (setq auto-mode-alist (cons  '("\\.svh\\'"   . verilog-mode) auto-mode-alist))
    (setq auto-mode-alist (cons  '("\\.lib\\'"  . verilog-mode) auto-mode-alist))
    ;; Any files in verilog mode should have their keywords colorized
    (add-hook 'verilog-mode-hook '(lambda () (font-lock-mode 1)))
    
    
    ;; User customization for Verilog mode
    (setq verilog-indent-level                3
          verilog-indent-level-module         3
          verilog-indent-level-declaration    3
          verilog-indent-level-behavioral     3
          verilog-case-indent                 2
          verilog-auto-newline                0
          verilog-auto-indent-on-newline      t
          verilog-tab-always-indent           t
          verilog-auto-endcomments            t
          verilog-minimum-comment-distance    0
          verilog-indent-begin-after-if       t
          verilog-auto-lineup                 '(all))
    

    After writing this, I posted on the correct forum, but will still post this one, to serve as a pointer to a great tool, verilog-mode.

     

    http://www.veripool.org/boards/16/topics/1372-Verilog-mode-auto-indent-messes-up-when-class-used-as-other-than-SV-keyword 


  6. DB,

     I didn't so much have a problem, as a question, but thanks tremendously for putting together that nice comparision code, showing which simulators/data-types support which methods/tasks.

     

    (It'd be great to have a public repository of small examples and a public checkmark-style spreadsheet showing which simulator versions support which constructs/code-samples.  But, as far as I understand, the EDA vendors would prohibit such benchmarking.)

     

    I agree that unified naming for these methods/tasks would make our lives easier.

  7. Do fixed-size arrays not support .size()?

     
    Or, am I doing smthg wrong below?
    Running irun 13.1, I am told that .size() "is not a valid built in method name for this object".
     
     
    If they do not, is this b/c 
     a. the expectation is that someone used a parameter/constant to specify the size of the array and that they can just use it everywhere else they might need it
     b. fixed sizes arrays were part of pre-SystemVerilog Verilog and as such missed this convenient feature.
    ?
     
    Just before publishing, I discovered section "20.7 Array querying functions" in the 1800-2012.pdf, SystemVerilog spec:  $size()
     
    module top;
       int farray[10];  //fixed array
    
       initial begin
    //1    for (int jjj=0; jjj<10; jjj++) begin             //works
    /*2*/  for (int jjj=0; jjj<farray.size(); jjj++) begin  //doesn't work
    //3    for (int jjj=0; jjj<$size(farray); jjj++) begin  //works
              farray[jjj] = $urandom_range(121,0);
           end
    
          $display("******************************");
          for (int jjj=0; jjj<10; jjj++) begin
             $display("%0d: %0d",jjj,farray[jjj]);
          end
       end
    endmodule : top
    

     


  8. David, that was much more clearly stated than I had been thinking.

    re: Shameless plug, .... Doulos material is great.  Two thumbs up.

     

    Tudor,  I find, as I think many do, that the text in the message (tag or body) as opposed to the severity level is the way to go in terms of differentiating error origins.  Then, any area of the system can create errors as well as system-stopping fatals.  (Unfortunately, with regards to what text I put in which part of the messgae, I've had trouble finding a style that I like, and will stick with.  Sometimes I want to filter messages from a certain object or method, somtimes by a certain data-flow which might involve sequences as well as multiple other objects.  Invariably, I end up doing a bunch of grep-ing and sed-ing thru log files.  But, I am getting a bit more consistent in my style.  I'm curious to hear if anyone has settled on a style.)


  9. bhunter,

     Yes, please try again to get your coding guidelines published.

     

     I raised the same request at a company and believe management was worried about sharing something that was not 'perfect' and its reflection on the company.  Probably another view is that coding guidelines are trade secrets.  While I think both of those ideas have merit, in these 'still early' days of SV/UVM, I  think there is more to be gained by sharing a still 'imperfect'/'unfinished' set of guidelines.

     

     I believe the upside of a company opening their coding guidelines to the public are:

     *The guidelines might be adopted by other companies.  This is particularly true for the first to market.  If the guidelines attain any traction at all, the company is positioned as somewhat of a leader in the space.  And besides, in this new SV/UVM world it seems to me that most companies are still sculpting their environment and flow standards and are hesitant to show that they are still fumbling around.  (But, unless the guidelines released were atrocious, I don't think there is a huge potential for embarrassment.)

     *The company gets useful feedback from the community to improve them.

     *Any industry-convergence around parts of the company's coding style will help to simplify the assimilation of new hires.

     

     This is purely anecdotal, but I've heard it is not uncommon among software startup teams to just following Google's (publically available) coding guidelines for various languages, rather than crafting their own.

    There is an open field to do this in the SV/UVM space.  Someone needs to jump in there.

     

     I particularly think that becoming a leader or first-mover in this space as an IP vendor like ARM, or a company that sells VIP, would be useful.

     

     I know that Mentor has published coding guidelines.  However, it'd be more impactful if a non-EDA company in our space would follow Google's example.

     

     The major idea behind UVM is to align how we verifiy.  More companies throwing their internal best-practices into the ring would help to align the industry.  While it might assist a competitor, I think it is much more likely help the company that shares.

     

    Those are my two unsolicited cents for the community.  But, bhunter, please give it another shot.

  10.  

    Q1)

    What is the difference between Incisive Enterprise Simulator (IES) and Incisive Unified Simulator (IUS)?

     

     

    Q2)

    If you are from Cadence (or even if you are not), how can I easily find this information on Cadence.com?

     

    (Feel free to embarrass me and show how in a few steps I can find the answer.  I just spent too long looking, with no success.)

     

     

    Context: I'm trying to determine if some simulations are using a different set of licenses than others.  (subset?, superset?) 

     

     


  11. Tudor, you rock. Thanks a lot.      I was just about to post this....so will anyway.

     

    ----

    Before anyone spends time on this on, apologies for firing off a question which I barely did any research on.
    When I have time, I'll see if I can figure it out myself and post an answer here.
     
    Context: I was just doing research on a cronjob problem I have (those so often bite me).  While looking into it, ran into this article.
    http://www.catb.org/esr/faqs/smart-questions.html    I only skimmed it, but it's a nice read for anyone that spends time on forums.
    The guilt set in that I had just posted an unresearched question here a bit earlier.  Booo
    ----
     
     
    Tudor, why do you think that fatal errors should only be for testbench errors?   Often, an egregious DUT error makes the remainder of the test worthless.

  12.  

    What is the easiest way to get my simulation to die upon reaching the first UVM_ERROR?

     

     

    (I suppose the reporting class could be extended and overridden, or something like that, but if it gets too complicated (as this is not smthg I expect to do much), I'll just temporarily change the offending statements to `uvm_fatals....which is what I just did.)

     

    Is there a built-in switch or define that I can override at the command line?

     

     


  13. Thanks, Alan.  This did turn out to be a tool issue.  (When collecting coverage at the end of the test the crash happened.  If we stepped thru the code and periodically collected coverage at a few points in the sim, including the end, there was no problem.)

      An update to the next/latest patch fixed this.

     

     

    regarding 1,2

    1. Note to self: it seems functional coverage is specified by coverpoints and some assertions (depends upon how used)

    An AE showed me a Cadence commandline option, -covcglog, to see what code the tool is considering as functional coverage.  I haven't explored it much yet though.

     

    2. While I'd like to explore this more to find out what functional coverage item prompted the problem/coverage-collection-crash (if it could be tied to a specific one), I must move on with other tasks.

  14. While I am waiting for an answer from the simulator vendor, I think I can form a non-tool-specific question about my problem.

     

    I am running a simulation which dies when I collect functional coverage.  I can turn on/off functional coverage collection and when it is on, at the very end of simulation, I get: "ncsim: *F,INTERR: INTERNAL EXCEPTION".  It seems to be that while coverage is gathered, the problem occurs.

     

    I can run tests which flow thru some channels of the dut and don't have the problem, but thru a specific channel of the dut, I often encounter the problem.

     

    question1: What is classified as functional coverage?   I'd like to leave functional coverage collection on and comment out all coverpoints/covergroups.  (Actually I think I have, or am close, and the error still occurs.)  So, I am wondering, what must I grep for to remove to be sure that functional coverage collection has no meaning? My thought is to divide and conquer.

    Am I not just looking for "coverpoint" and "covergroup", but also "assert" (as some code might have assertion based functional coverage)?  Is there anything else?

     

    question2: (This is perhaps a bit tool specific.)  If the -covdut, or scope of where coverage should be gathered is targetted to a sub-sub-module, would you expect that (possibly bad) coverage code at a higher level (or different area) would have zero affect on the coverage collection?  (I've unsuccessfully tried to leave functional coverage collection on, but to move the target-scope to a trival part of the design, to see if the problem goes away.)

     


  15. Thanks a lot, /uwe.  That was very helpful.

     

    My notes, for when I encounter this again:

     

    1) from uvm_component.svh    (note: "Any threads spawned in this callback are not affected when the phase ends.")



      // Function: phase_started
      //
      // Invoked at the start of each phase. The ~phase~ argument specifies
      // the phase being started. Any threads spawned in this callback are
      // not affected when the phase ends.


      extern virtual function void phase_started (uvm_phase phase);


    // phase_started
    // -------------
    // phase_started() and phase_ended() are extra callbacks called at the
    // beginning and end of each phase, respectively.  Since they are
    // called for all phases the phase is passed in as an argument so the
    // extender can decide what to do, if anything, for each phase.


    function void uvm_component::phase_started(uvm_phase phase);
    endfunction


     

    2) from uvm_task_phase.svh  (note:  "Once the phase completes, any remaining forked ...

    threads are forcibly and immediately killed.")



    //------------------------------------------------------------------------------
    //
    // Class: uvm_task_phase
    //
    //------------------------------------------------------------------------------
    // Base class for all task phases.
    // It forks a call to <uvm_phase::exec_task()>
    // for each component in the hierarchy.
    //
    // The completion of the task does not imply, nor is it required for,
    // the end of phase. Once the phase completes, any remaining forked
    // <uvm_phase::exec_task()> threads are forcibly and immediately killed.
    //
    // By default, the way for a task phase to extend over time is if there is


  16. Q1) If I use a fork-join_none to spawn a process in a phase, and then that phase ends (b/c objection is dropped), is the process terminated or allowed to complete?

     

     

    I seem to be seeing that the process is terminated (but was expecting that it would be allowed to complete) and wanted to confirm that this is the expected behavior.  

    Q2) Where is this behavior best documented?

     

     

    (Context: I was moving my timeout-timer from main_phase to pre_reset_phase, so that its time begins at time==0.  If processes are killed when a phase ends, I suppose I should move it to run_phase to align it with time==0, ..... or start using the heartbeat component, which I have not gotten around to doing yet, but have been thinking a lot about.)

     


  17. Resetting a randc permutation sequence
    (See attached page from 1800-2012 SystemVerilog spec.)
     
       function bit [16:0] get_reasonable_buggy_data(bit [(A_SIZE-1):0] rid);
          string where="buggy";
    //    randc unsigned int picky;  //random-cyclical variable  DECLARED ABOVE IN CLASS, SUCH
    //    void'(randomize(pick) with {pick==1;}); FAILED-ATTEMPT to recompute permutation sequence
          
          for (int i=0; i<4; i++) begin
    	 if (!randomize(picky) with {picky>=0; picky<4;}) begin `uvm_fatal("FAIL","") end
    
             `uvm_info(where,$psprintf("i=%0d picky=%0d data[1:0]=%2b",i, picky, rdata_set[picky][1:0]),UVM_HIGH)
             if ( rdata_set[picky][1:0] == 2'b11 ) begin 
                `uvm_info(where,$psprintf("     data[1:0]=%2b. GOT IT!",i, rdata_set[picky][1:0]),UVM_HIGH)
                return(rdata_set[picky]);  //exit random-cyclical sequence here. How to start it over?
             end
          end
          `uvm_fatal(where,$psprintf("After cycling thru entire memory model, did not find data desired"))
       endfunction
    
    In a function, I am cycling thru the randomized values of a randc variable, "picky", which is used as an index.  I find what I am looking for and stop, not completing the cycle thru all the possible values of the variable, in a given permutation sequence.
    Returning to this function, the randomization of the randc, picks up where the previous permutation sequence left off.  This makes sense.  This is undesirable here and leads to problems**.  I want to reset the randc permutation sequence, but am not sure if I am just not doing it properly or if my simulator does not support it properly.  (I can ask the simulator vendor about the latter.  I am inquiring here about the former.)
     
     
    Problem details: 
    The randc variable "picky" can have 4 values: 0,1,2,3.
    We call the above function 3 times. Each time we want to use picky as an index to randomly search a memory of size 4, stopping when we find what we want.
     
    Permutation sequences of picky are:
    1st:   0,2,3,1
    2nd:  3,0,1,2
    3rd:  0,....           //final 3 are irrelevant and sim dies before we get to them
     
    First time function is entered, we select '0','2',and '3' and find the goal in #3 and function returns.
    Second time we finish off the 1st permutation with '1' and go into 2nd with '3', and have found what we want in #3. Function returns.
    Third time, we finish the 2nd permutation with '0', '1', '2', and continue into the 3rd with '0'.  Function fails.  So, we did not get the randc effect we wanted, we never got to #3.
     
    Even though we were iterating 4 times, once for each memory location and using a randc, we got a duplicate, b/c our randomization straddled two permutation sequences.  As such, we never found #3.
     

     

    Print output from simulation:

    [buggy] i=0 picky=0 data[1:0]=00
    [buggy] i=1 picky=2 data[1:0]=00
    [buggy] i=2 picky=3 data[1:0]=11
    [buggy]      data[1:0]=10. GOT IT!3
    [buggy] i=0 picky=1 data[1:0]=00
    [buggy] i=1 picky=3 data[1:0]=11
    [buggy]      data[1:0]=01. GOT IT!3
    [buggy] i=0 picky=0 data[1:0]=00
    [buggy] i=1 picky=1 data[1:0]=00
    [buggy] i=2 picky=2 data[1:0]=00
    [buggy] i=3 picky=0 data[1:0]=00
    [buggy] After cycling thru entire memory model, did not find data desired
    
     
    Note, this is a contrived example. I could allow all permutation sequences to complete or resolve this another way.  Based upon the description in the spec page attached, I tried to reset the permutation sequence by inserting the line labelled "FAILED-ATTEMPT".  Is that how resetting a permutation sequence should work?
     
     
     
    Note: I am using IUS 13.10-s006
     
    post-2891-0-45138100-1387309856_thumb.png

  18.   Allowable creation times:    transaction objects  versus  testbench components

     

    Can someone comment on why I/we cannot create a component after the build_phase, or even during the run_phase. (See UVM_FATAL note above.)

    I think I understand the philosophy behind or difference between 

    • 'statically instantiated hierarchy'
    • 'dynamically instantiated hierarchy'
    • 'transaction objects'
     as Doulos breaks it down in their literature.

     

    But, I haven't dug enough into the UVM base-class to understand what prevents component creation during this time.


  19. Thanks a lot for the feedback, uwes and adiel.

    Below is my code that works and the relevant output.  Commenting out the override line reverts back to apple, as expected.



    package my_pkg;
    import uvm_pkg::*;
    `include "uvm_macros.svh"

    class apple extends uvm_component;
    `uvm_component_utils(apple)
    function new(string name, uvm_component parent);
    super.new(name,parent);
    endfunction : new
    task run_phase (uvm_phase phase);
    `uvm_info("UVC","run_phase: Executing. Apple run_phase<<<",UVM_LOW)
    endtask : run_phase
    endclass : apple
    class orange extends apple;
    `uvm_component_utils(orange)
    function new(string name, uvm_component parent);
    super.new(name,parent);
    endfunction : new
    task run_phase (uvm_phase phase);
    `uvm_info("UVC","run_phase: Executing. Orange run_phase<<<<",UVM_LOW)
    endtask : run_phase
    endclass : orange

    class my_testbench extends uvm_component;
    apple my_uvc;
    `uvm_component_utils(my_testbench)

    function new(string name, uvm_component parent);
    super.new(name, parent);
    endfunction : new
    function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    apple::type_id::set_type_override(orange::get_type()); //Replace apple with orange
    my_uvc=apple::type_id::create("my_uvc",this);
    endfunction : build_phase

    task run_phase (uvm_phase phase);
    //my_uvc=apple::type_id::create("my_uvc",this); //**1 cannot create a component in run phase
    `uvm_info("TESTBENCH","run_phase: Executing. Testbench run_phase<<<<",UVM_LOW)
    endtask : run_phase
    endclass : my_testbench
    endpackage : my_pkg


    module top;
    import uvm_pkg::*;
    `include "uvm_macros.svh"
    import my_pkg::*;

    my_testbench testbench;

    initial
    begin
    $display("******Start of Sim w/ the kids*******************");
    testbench = my_testbench::type_id::create("testbench",null);
    run_test();
    end
    endmodule : top




    ******Start of Sim w/ the kids*******************
    UVM_INFO @ 0: reporter [RNTST] Running test ...
    UVM_INFO top.sv(39) @ 0: testbench [TESTBENCH] run_phase: Executing. Testbench run_phase<<<<
    UVM_INFO top.sv(20) @ 0: testbench.my_uvc [UVC] run_phase: Executing. Orange run_phase<<<<



     

    Sharing with other newbies something I 'learned':

    See commented out line "**1", which gave the below error and taught me that I cannot create components after build.  It makes sense, but I had never thought about it before.

    UVM_FATAL @ 0: my_uvc [iLLCRT] It is illegal to create a component ('my_uvc' under 'testbench') after the build phase has ended.

×
×
  • Create New...