Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by tfitz

  1. From PSWG: The definition of 'coverage' sited in PSS EA in section 3 needs to be augmented to refer to the use of cover goals to guide the generation of scenarios to achieve the desired coverage (defined using 'coverspec' construct). The current PSS EA definition is "coverage: A metric to measure the percentage of possible scenarios that have actually been processed for a given model."
  2. From PSWG: You are correct - the pss::detail namespace is an implementation artifact and serves a purpose similar to the 'unspecified' types in C++ ISO reference (e.g.: http://en.cppreference.com/w/cpp/io/manip/quoted). The end-user is not expected to refer to the types in pss::detail namespace directly. We have kept references to pss::detail in the EA draft to provide header definitions that are compilable.
  3. From PSWG: We are looking into restructuring the document to move most of the C++ class definitions to the appendix, while keeping a small amount of C++ code to illustrate the basic usage equivalent to the BNF that is shown for the PSS language.
  4. From PSWG: Support for generated enumearage (e.g. 'typedef enum {sub[5]} myEnum;' that results in 5 enums sub0 thru sub4 with values 0 thru 4 respectively) could be added. This functionality does not seem to be key to PSS but more of a convenience. Do not propose adding this functionality at present.
  5. From PSWG: Yes, it is possible to nest 'if_then_else' statements in PSS/C++. Secondly, yes an 'if_then_else' is compatible with a C++ 'detail::ActivityStmt', as it is an 'activity'.
  6. The spec currently defines size() and sum() pseudo-methods on arrays. Are you referring to other array-reduction methods like and(), or(), etc?
  7. From PSWG: This suggestion is being tracked via Mantis 6356. It is not deemed critical for 1.0.
  8. From PSWG Per Mantis 6355, the examples will be fixed in the 1.0 version.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. The PSWG has filed Mantis item 6358 to discuss this suggestion further.
  17. The PSWG filed Mantis item 6359 to discuss this suggestion further.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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
  23. 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.
  24. 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.
  25. 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
  • Create New...