Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


tfitz last won the day on June 15

tfitz had the most liked content!

About tfitz

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Definition of 'coverage'

    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. Parameterizable enum missing

    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. C++ if_then_else nesting

    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. Array pseudo-methods missing

    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. 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.
  12. 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.
  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. 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.
  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.