Jump to content

ljepson74

Members
  • Content Count

    107
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by ljepson74

  1. I had expected all 3 of these calls to randomize to return values using the constraint. However, the first does not. Can anyone tell me why? (note: In the following code, there is no local randomize method defined. So, I think that all randomize functions are the same...and perhaps only scope varies.) Code, followed by sim results: class thursday_seq extends junk_seq_seq; //which extends uvm_sequence rand int count; constraint c1 { count >= 2; count <= 9; } function new(string name="thursday_seq"); super.new(name); if (std::randomize(count)) begin `uvm_info("",$psprintf(" cnt=%0d .....",count),UVM_LOW) end else $finish; if (randomize(count)) begin `uvm_info("",$psprintf(" cnt=%0d .....",count),UVM_LOW) end else $finish; if (this.randomize()) begin `uvm_info("",$psprintf(" cnt=%0d .....",count),UVM_LOW) end else $finish; $finish; endfunction:new `uvm_object_utils(thursday_seq) UVM_INFO @ 0: reporter@ [] cnt=415747889 ..... UVM_INFO @ 0: reporter@ [] cnt=9 ..... UVM_INFO @ 0: reporter@ [] cnt=2 ..... It seems what is happening is that while std::randomize and randomize are calling the same method in the standard package, the standard version is oblivious to local constraints. I see in 1800-2012.pdf (SV spec), sec. 18.5.2 "The randomize() method is virtual and therefore honors constraints of the object on which it was called, ..." (highlighting mine) Later in the spec, there is reference to the 'scope of the randomize(' which confuses me a bit, if the constraints are always to be honored. (Although, I suppose in the first two cases above "of the object on which it was called" is not true, b/c I don't call it on the object, but on a property of the object.) Is that correct? After doing a bunch more reading, I am going to continue with this post for feedback. Here is something more I learned. This quote in section "18.12 Randomization of scope variablesā€”std::randomize()" I think explains it all for me. "The scope randomize function, std::randomize(), enables users to randomize data in the current scope without the need to define a class or instantiate a class object." I'm a bit unsure, but I think the answer to my question is this. "without the need to define a class" and "in the current scope", from above, imply that std::randomize performs only on the scope that is passed to it. i.e. if I pass it a class object, then it knows of that object's constraints. If I pass it a data-member of a class, then the scope that data-member exists in is not seen (i.e. any constraints which are in the scope above that data-member are not seen). Though they could be replicated as inline constraints.). The local randomize knows of all the constraints in the object from which it is called. Do I understand this correctly? I think I just walked myself through understanding this. Comments welcome. thx, note: using Cadence's IUS12.1-s004
  2. Samrat, I don't see the connection between your response and my question. Did you respond to the wrong topic, by chance? I did meander a bit with my question. To clarify, what is the difference between the following two lines? uvm_config_db#(int)::set(this,"A.hostB","is_active",UVM_ACTIVE); uvm_config_db#(bit)::set(this,"A.hostB","is_active",UVM_ACTIVE); Is the second one correct and the first one 'just works' (with Cadence irun v12.2) because of loose typing in systemverilog and/or my simulator? (I see the second one in a fair number of 'examples' online. This has been a minor hang-up and area of confusion for me as I attempt to improve my uvm_config_db understanding.) thx
  3. When agents are configured, I typically see something like this: uvm_config_db#(int)::set(this,"testbenchA.masterA_hostB.agentpink","is_active",UVM_ACTIVE); Isn't UVM_ACTIVE of type bit? I see it 'described' here in an enum and given a default value. src/base/uvm_object_globals.svh: typedef enum bit { UVM_PASSIVE=0, UVM_ACTIVE=1 } uvm_active_passive_enum; So shouldn't the uvm_config_db line not be: uvm_config_db#(int)::set(this,"testbenchA.masterA_hostB.agentpink","is_active",UVM_ACTIVE); but instead be: uvm_config_db#(bit)::set(this,"testbenchA.masterA_hostB.agentpink","is_active",UVM_ACTIVE); ? thx, (I sense that I probably don't have a solid enough understanding of enum and the relationship between bits and ints.)
  4. Dear SystemVerilog/UVM User, I've setup a SystemVerilog Meetup in Silicon Valley for people who are interested in hashing over problems they're having or learning new features in a group setting. http://www.meetup.com/SystemVerilog-Social-Club-Silicon-Valley/ I look forward to seeing you there. all the best, Linc Jepson
  5. I'm on a large project where the various teams are looking to converge on a common SV/UVM style. To get some outside opinions... Where do you like to do X or unknown checking and why? bind file, interface, monitor, somewhere else? Does your company have a standard? Where?
  6. I'd like my sequence to not be created or not perform late randomization (either is fine) until a variable (int) in the driver has a certain value. How would you suggest doing this? a) Should I set a variable in uvm_config_db and then poll it in the sequence? (Although sequences know no time as I recall, so I'd have to do it elsewhere. ? ) Is it possible to "wait" on a value in uvm_config_db? c) other As currently setup, my sequence has: `uvm_create(req) //some late randomization here `uvm_send(req) my driver has: seq_item_port.get_next_item(req) send(req) //where pins are set seq_item_port.item_done() The value in the driver being waited for is akin to a stall. Apologies for the terseness of this question. After just encountering it late today, I thought I'd throw it out here to see if anyone had any ideas before I reexamine the situation.
×
×
  • Create New...