Jump to content

tfitz

Members
  • Content count

    24
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by tfitz

  1. From PSWG: This suggestion is being tracked via Mantis 6356. It is not deemed critical for 1.0.
  2. From PSWG Per Mantis 6355, the examples will be fixed in the 1.0 version.
  3. From PSWG: This section (3.2.1-e) actually does define the scheduling implication of state object exchange. However, it would be better to demonstrate the application of this rule in the context of the example. You are right that the scheduling of actions that input and output a state object to the same pool are illegal. This would be a race situation on the state variable. Section 3.2.1 does not state this rule explicitly, and it definitely should. Per Mantis 6344, this will be fixed in 1.0.
  4. From PSWG: Arrays, as specified in the EA spec, are fixed-size. If and when parameterization is supported, the size of arrays could be specified with a parameter. It sounds like this question is not about dynamic arrays. Would arrays with paramerized size fit your need? Note that arrays declared inside a component can be sized at generation time today.
  5. Clarification on example 57

    From PSWG: You are right. The execution of A, followed by B and C in parallel, followed by D, would be legal in this case. The explanation text is not clear enough. We filed a Mantis issue (#6343) proposing a fix to this. It will be fixed in the 1.0 version.
  6. Revisit concept of labeling

    From PSWG: Labeling is a way for the user to distinguish between interface feature and implementation feature of an activity (and thus a compound action). If you restrict hierarchical paths to statements for which every step of the way is labeled, you create tight coupling between the syntactic structure of the activity and it’s use from outside. Of course a user can choose to label any or every statement, but the user can also choose to NOT label a statement, and not expose that detail of his definition. The higher-level description can constrain from above exposed sub-actions or sub-activities, without ruling-out changes in the underlying activity. The rules for hierarchical references in activities are similar in spirit to those in SystemVerilog, where only named blocks define new hierarchical level for path expressions.
  7. From PSWG: In PSS the process of determining the number and types of actions, their attribute values, their relative schedule, their input/output bindings, their component and resource assignments, is generally referred to as ‘solving’. Randomization is more specifically the choice of values to a known set of variables, satisfying value constrains over them. This is indeed the meaning of randomization in SystemVerilog. Solving in PSS refers more generally the tool’s decisions on all properties and aspects a the scenario that are not explicitly specified, satisfying more generally model rules, of which variables and value constraints are just one aspect. And these decisions may involve a serious analysis, but are not even necessarily random. This broader scope of tool decisions in not analogous to SystemVerilog and therefor the terminology is not the same.
  8. Clarification on example 102

    From PSWG: Indeed, the language is designed in a way that enables automatic insertion of action to complete partially specified scenario flows. You are right in observing that this is not stressed or illustrated enough in the EA version, and we are working to expand on this topic (Mantis issue #6333). I would say that the moto here is more – focus on the pure test intent, and abstract from the means to achieve it. It’s not just “begin with the end in mind”, but more generally “capture the end and not the means”. W.r.t. the follow-up question, there is no general meaning in PSS to the term ‘all possible ways’. There can be different bring-up sequences leading to some desired behavior, different schedules, different resource assignments, different parameter values, etc. The space for ‘all possible ways’ without further qualification is not well defined, and not bounded. All of these different aspects of the scenario can be explicitly constrained. Tools may provide means to exhaustively cover all combinations for a specific property of a scenario, or some coverage goal.
  9. From PSWG: The WG has discussed a parameterization proposal that would enable exactly the type of generic activity or scheduling that you describe. While there are details left to work out on the parameterization proposal, there is general agreement in the WG that parameterization is useful. The Mantis item is 5929.
  10. The PSWG has filed Mantis item 6358 to discuss this suggestion further.
  11. The PSWG filed Mantis item 6359 to discuss this suggestion further.
  12. From the PSWG: PSS tests are often realized through generating code in target languages, and in particular C/C++/assembly-language. PSS numeric types are restricted to primitive representation available in C/C++. Arbitrary length integers would not have obvious portable target mapping. We can consider target mapping to 128 bit numeric types, as these are available in many C compilers. However, it would be good to understand the application you have in mind. Many applications for large numeric values would be more adequately modeled as structs, strings, or byte-arrays.
  13. Clarification on example 152

    From the PSWG: Imported classes and methods are declarations of external APIs. In example 152, both 'base' and 'ext' are declared as import classes. The fact that 'base' was declared with an import qualifier makes it an imported class.
  14. Spin out HSI into own standard

    It is the intent of the WG to include HSI in the first version of the standard. HSI fits in with the overall vision of portable stimulus standard - and hence we are defining it as part of this standard itself. The use-case you have mentioned for HSI, i.e., generation of FW, is (of course) possible - it is up to the vendors to support that flow and promote it with their users.
  15. Joint response from the PSWG: The assumption that is being made is not correct. Specifically: It will be possible to take the C++ PSS model and use a standard C++ tool chain (GCC, MSVC, etc). So to now get back to specific parts of the feedback: Perhaps, but perhaps not. The WG discussed this and decided to leave the choice to the users. Yes, this is possible, with the caveat that the model will be traversable in the PSS library implementation and not in the end "user" code. The EA spec doesn’t define introspection APIs. However, your tool vendor (the one who implements the PSS library) may define such APIs. Yes, this is possible if supported by the tool vendor. This is indeed the direction the WG is taking.
  16. Choice of input language

    Hi Thorsten, Thanks for the feedback. Please keep in mind that the semantics for both input formats is identical. Since the semantics define what the output code will look like, that's really the important part of the standard. We do not anticipate a "language war" because of this semantic equivalence. Tom Fitzpatrick PSWG Vice-Chair
  17. Nice catch. This will be addressed in the 1.0 version. The example doesn't need to change, but the accompanying text will be updated as follows: In Example 30 and Example 31, component pss_top contains two instances of component sub_c, named s1 and s2. Component sub_c contains a data field named base_addr that controls offset addr when action A is traversed. During construction of the component tree, component pss_top sets s1.base_addr=0x1000 and s2.base_addr=0x2000. Action pss_top::entry traverses action sub_c::A twice. Depending on which component instance sub_c::A is associated with during traversal, it will cause sub_c::A to be associated with a different base_addr. — If sub_c::A executes in the context of pss_top.s1, sub_c::A uses 0x1000. — If sub_c::A executes in the context of pss_top.s2, sub_c::A uses 0x2000.
  18. 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.
  19. 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
  20. 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
  21. 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.
  22. 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
  23. 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
  24. 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)
×