Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


tfitz last won the day on June 15 2017

tfitz had the most liked content!

About tfitz

  • Rank

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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-act
  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 ru
  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 t
  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.
  • Create New...