tfitz

We no longer use the term "concrete scenario."

Fixed in 2.0

This has been fixed in 2.0

Hi Paul, Please consider joining the UVM-AMS Working Group. Tom Fitzpatrick Chair, UVM-AMS Working Group

Nice catch! We'll address it in 2.1. Thank you

Try using the function void get_objectors( ref uvm_object list[$] ) method to see which component (if any) is still objecting. Although I'm pretty sure that the message you're showing would only print after all objections have been lowered.

Hi Raj, The answer is that it depends on what is involved in the expression and the capabilities of the tool. If the expression depends on run-time values, then clearly the expression must be evaluated at run-time and the generated code must reflect this. For expressions that do not involve data from the environment, the tool could evaluate these up-front and factor these into the test generation process.

Hi Everyone, On behalf of the Accellera Portable Stimulus Working Group, I'd like to welcome you to the feedback portal for the PSS 2.0 Public Review. If you haven't yet downloaded the document, it is available here. The members of the WG have been working hard over the past 21 months, since PSS 1.0a was released in February, 2019, to enhance the usability of PSS and expand its portability and flexibility to encompass a broader class of verification challenges. We estimate that the PSS 2.0 Public Review version contains about 90% of the functionality that will eventually be in PSS 2.0, which is on target for release in February, 2021. Here are a few of the new features included in the Public Review version: Core Library for standard portable functionality and utilities for common PSS applications, including register accesses and memory allocation and management Collection types, including arrays, lists, maps, and sets Parameterized types Constraint enhancements, including default constraints and propagation Enhanced activity-level generation and scheduling constructs Improved portability of procedural constructs for test realization While the Public Review is under way, we will continue working on several other enhancements and clarifications from 1.0a. In order for your voice to be heard, it is imperative that you provide your detailed feedback and questions via this forum before the end of the Public Review period, which will be December, 18, 2020. We ask that you make use of the page and line numbers, as well as figure, table, syntax and example numbers/captions to make it clear exactly to what your comments refer. The WG is committed to analyzing all feedback and will make appropriate adjustments to PSS 2.0 as deemed necessary. We will be monitoring this forum and will do our best to make this an interactive review as much as possible. We thank you for your participation in this review and appreciate your efforts to help us make PSS 2.0 the best it can be. Warmest regards, Tom Fitzpatrick Vice Chair Accellera Portable Stimulus Working Group

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

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

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.

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

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

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)