Jump to content

tfitz

Members
  • Content count

    7
  • Joined

  • Last visited

  • Days Won

    1

tfitz last won the day on June 15

tfitz had the most liked content!

About tfitz

  • Rank
    Moderator

Profile Information

  • Gender
    Not Telling
  1. NOTE: Edited to update closing date for the Public Review Period On behalf of the Portable Stimulus Working Group (PSWG), welcome to the public review forum for the Portable Stimulus Early Adopter Draft Specification. The Public Review Period for this version of the Portable Stimulus Specification will close on Friday, September 15Monday, October 30, 2017. Members of the PSWG will be actively monitoring this forum to respond with answers, clarification questions or other general feedback to your comments. We will also let you know when a specific issue has been entered into our Mantis issue-tracking database. To facilitate us tracking your issue, please be sure to include the following information when posting: Descriptive title Page number (please use PDF page #) Section number Line number (listed on the side of the page) Detailed description of the issue This will enable us to locate your issue and facilitate the discussion. We thank you for your contribution to the success of this important new standard. The Early Adopter specification provides a comprehensive explanation of the new Portable Stimulus Domain Specific language and equivalent C++ Class Library. This declarative language is designed for abstract behavioral description using actions; their inputs, outputs and resource dependencies; and their composition into use cases including data and control flows. These use cases capture test intent that can be analyzed to produce a wide range of possible legal scenarios for multiple execution platforms (e.g., virtual platforms, simulation, emulation, prototypes, silicon, etc.). The Early Adopter specification also includes a preliminary mechanism to capture the programmer’s view of a peripheral device, independent of the underlying platform, further enhancing portability.
  2. Hi Sean, We don't recommend the use of multiple scheduling domains. Instead, you could have a virtual sequence in each env. These two env-virtual-sequences would function effectively as independent "run_phase time lines." These two sequences could also be coordinated via a virtual sequence in your test, if necessary. Perhaps if you could explain why you think you need multiple different domains, we might be able to get you where you need to be in the most efficient way. -Tom
  3. bug in uvm_rand_send* persists

    This is a great example of why macros are evil. Instead of using the macros, why not just seq = SEQ_type::type_id::create("seq"); seq.randomize() with CONSTRAINTS; seq.start(SEQR); Personally, I find it much easier to create/randomize/start for sequences and create/start_item/randomize/finish_item for sequence items than it is to remember all the variations of 'uvm_create/on/rand/send/with/pri/... Good luck, -Tom
  4. While it is possible to instantiate an analysis_port outside of a component, as jadec shows, it's not recommended. Perhaps if you could describe what you're ultimately trying to achieve, we might be able to suggest a better alternative.
  5. Yes, sequences may be run in parallel or in series. On any given sequencer, parallel sequences will be arbitrated by the sequencer so that only one will provide a sequence_item to the driver when asked. If you have multiple sequencers, as for a layering, then each sequencer can be running a sequence. These two sequences can communicate with each other. I'll answer your questions below, but at this point it's probably best if you visit the Verification Academy and take a look at the "Layered Sequences" unit in the "Advanced UVM" module. These would be extended from uvm_sequence_item. The data scheduler would be the top-level sequence. It should be extended from uvm_sequence and this will be what gets explicitly started from your test. The packet class will also be extended from uvm_sequence_item. This is the item type that will be passed down to your driver. So, at the agent level, the driver and sequencer will be parameterized using the packet class item. The packet formatter would be a uvm_sequence that runs on the agent sequencer and passes packet objects down to the driver. See above. In general, you should think of sequence_items as the objects being passed from sequence to driver (or, in a layering as in this case, also between a higher-level sequence and a lower-level sequence). You should keep the raising and dropping of objections to your test: task run_phase(uvm_phase phase); ... phase.raise_objection(this, "Starting sequence"); data_scheduler_sequence.start(top_sequencer); phase.drop_objection(this, "Sequence completed"); ... endtask See above. The data scheduler is a sequence, not a sequence_item. You don't actually need a channel. The handshaking is handled automatically via the start_item()/finish_item() in the sequence and the get_next_item() in the driver. In the layering, your packet_formatter sequence (that sends the packet to the driver) serves as what we call a translation sequence. It will actually have to get the data item(s) from the data_scheduler sequence and translate those data items into the packet that it then sends down to the driver. Note that from the data_scheduler's point of view, it's sending data items to what looks like a driver (but is in reality the packet_formatter sequence). I hope I've answered your questions above. Please see the above links to Verification Academy as well. You're welcome. Good luck, -Tom
  6. Hi Guys, I think you may be overthinking things a bit (although it is possible I'm underthinking ;-)). If your scheme in VMM was to aggregate data types into a "packet" and then send those to a channel (to be picked up later by the driver), then it would still be the case that your driver would be sitting there waiting for something to appear in the channel. You have two choices: 1 - Have the driver do a "get" from the channel, in which case it will block until something appears, or 2 - Have the driver do a "try_get" from the channel, in which case it will return if there's nothing there Choice 2 has the advantage of allowing the driver to interact with the bus to do a "null" cycle if there was no packet there. If this is not a requirement, then I'd stick with choice 1 for simplicity. In UVM, you could have a sequence that interacts with your scheduler to assemble the packet in exactly the same way you're used to. Once the packet is assembled, you could do your start_item/finish_item to send it to the driver. In the driver, choice 1 above would be implemented by having the driver call get_next_item(). Choice 2 would use try_next_item(). In reality, you're doing sequence layering. Your rate scheduler would be a sequence layered on top of your packet sequence. The scheduler sequence generates your data types. The packet sequence gets those data types and assembles them into your packet and sends them to the driver. Let me know if this makes sense. I can point you to plenty of additional information if you'd like. Good luck, -Tom
  7. The config_db::set call is going to set the value for "test.tb_env.en_*" (assuming the name of your test is "test") since it creates the name from {this.get_full_name(),".","tb_env",".","en_*"}. Janick is correct that the types have to match. However, for the uvm_field_int macro usage, the code checks for both types on the hidden get() call. Most likely, your problem is with the path. Does it work if you do uvm_config_db#(int)::set(this, "tb_env", "en_1", 1)
×