Jump to content

shail

Members
  • Content Count

    16
  • Joined

  • Last visited

  1. I have been debating internally whether to use legacy virtual sequencer concept or use the virtual sequence concept. Any upside- or downside in using one over the other in terms of vertical reuse ?
  2. Perfect. I would take it one step further and create a standalone ResetObserver (InterfaceCtrl ) component or may be even UVC that can drive reset as sequence and also observe reset as monitor. Resetobserver monitor can be simple component that observes reset and writes to its port, when reset is asserted and released. It can then be extended if other such events of the bus needs to be observed and broadcasted. Thanks.
  3. By "passing reset", I did not mean "give pin access", I meant, driver/monitor calling reset() methods of agents or having monitor jump phase to reset_phase .. something like mymonitor extends uvm_monitor; ... @(posedge vif.reset); parent.reset(); and then agent can have myagent extends uvm_agent; task reset(); uvm_component children[]; children = get_children(this); foreach (children[child]) begin children.reset(); end endtask endclass; problem is how far up do you go ? stop at env or stop at agent.. one thing is for sure- we need a way to pass information that reset happened to components that are not connected to reset pin (like sequencers, scoreboard) etc... Also, my main question still persists - how is it being done in UVC out-there now ?
  4. This is what I want to do, but not able to do in uvm_sequence_item because config_db or get_config_object() do not work in uvm_object. my question is - is it difficult to allow config_db/get_config_object() calls in uvm_object? If so, why ?
  5. I was thinking about top-down reset propogation because I was thinking of propogating reset through a sequence,which makes it top-down, but what I did not think at the time was that, top-down propogation of reset sequence would be through some control-interface (pin-wiggler interface) where as your active UVC would only be using bottom-up ..Agreed. Next question though is, when you take bottom-up approach, how do you pass reset up to components agents, sequencers (layers) who do not have access to interface? I could think of two ways: 1. jump to reset_phase in driver/monitor when it detects reset (driver & monitor or just monitor?) and then all components will get in their reset_phase and hence execute reset ? 2. use get_parent() and call parent's reset() method, recursively all the way upto env or agent, which can then call its childrens? -- This sounds complex and question arises- why do it, but this is needed because driver may call agent's reset() as its parent, but to get sequencers (layered) to have reset(), we need agent to call reset() to all its children. thoughts ?
  6. I am working on adding reset to my UVC and that makes me think of two approaches 1. bottom up (meaning reset signal picked up from signals-via interface) 2. top down (meaning reset signal driven via sequence) and I want to use both - because I want my UVC to reset when reset pin wiggles or when reset sequence runs. uvm ref flow shows pin-wiggle reset implementation but it only reset dut signals in this case. What about stopping sequences, resetting agents, monitors , layered sequencers, models etc...??? There is nothing in uvm user guide about this. For bottom-up, I was thinking of using get_parent() method to propogate reset in hierarchy. For top-down, I was thinking of using get_children() method to propogate reset in hierarchy. How have you implemented reset scheme in your UVC ? In parellel- I am reading VIP guide on uvmworld site to see if it gives any insight.
  7. Interesting. - I received 2 reply notifications in my email but none of the reply is on the forum here. forum also shows "0 replies" on main page.
  8. Hi , We (I believe many others ) have a case where sequence item's constraints depend on values in configuration object so wanted to use get_config_object or uvm_config_db in uvm_sequence_item, but there is no way to do get_config_object or uvm_config_db...::get in sequence_item so how do we pass config object to sequence item in a clean fashion. I know one rather not-clean (In my opinion) way is to always use `uvm_do_with in sequence body myseq::body() { `uvm_do_with(req, { cfg == p_sequence.cfg; }); } but this is not-so-clean due to two reasons One always have to use `uvm_do_with , instead of `uvm_do, in my sequences. If One is using `uvm_create and playing with req before sending, I need to assign config object on every create, before I play with the object. Any thoughts ??
  9. Thanks.. Two questions here: 1) How do I know the context for a uvm_transaction that is flowing through multiple components.(note I do not want to use components uvm_report_enabled() function for a reason. 2) Curious to know, what type of problems could be created if uvm_transaction is extended of uvm_report_object instead of uvm_object in uvm ?
  10. uvm_report_enabled is method of uvm_report_object and so is available in uvm_component, but not in uvm_transaction or uvm_sequence_item so in case where you want to print something based on verbosity, there seems to be no way, except you define a function that converts all your prints to a string and returns string... For example, a sequence item has a payload (dynamic array) of size 1-1000 . Obviously, one would not want to print the whole array every time, but only when verbosity is UVM_DEBUG or UVM_FULL. one way to do this is foreach (payload[j]) begin `uvm_info(get_type_name(), $sformatf("payload[%d] = 0x%h",j, payload[j]),UVM_FULL) end but this would print uvm-message tag in every line and is ugly.. What one would want to do is something like, what we can do for uvm_component .i.e. from within do_print method of transaction..... if (uvm_report_enabled(UVM_FULL)) begin foreach (data[i]) begin printer.print_int($sformatf("data[%d]",i),data[i],$bits(data[i]),UVM_HEX); end end How can that be done ? I hope, this is what original user wanted to ask.
  11. `uvm_field macros implement compare method for you. If you want to do something special, you can implement do_compare method (nicely explained in uvm documentation).
  12. Curious - Why were you not able to add raising objections to scoreboard ? That should work except there is a time elapse between when sequence is done to when your transaction reaches scoreboard. Do you have that elapsed time ?
  13. I think, you can use uvm_config_db#(uvm_bitstream_t)::set to do the same thing that set_config* would do. Nothing against set_config_* but using uvm_config_db gives two advantages 1) consistent usage of configuration mechanism 2) I am not sure if set/get_config* is supported by all vendors Are there caveats, I am missing?
  14. UVM userguide has following statement that I could not understand. Can anyone please elaborate? Explanation while comparing to `do-ing item would help even more.
×
×
  • Create New...