Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Dear PSWG The following Portable Stimulus users would like to respectfully submit the following list of issues, in response to the Portable Stimulus Early Adopter Release public review process. We would request that the committee gives careful consideration to these issues that we believe will have an impact of the suitability of the standard for use on real world designs. Best Regards, Mark Glasser, NVIDIA Asad Khan, Cavium Ty Garibay, Arteris Poonam Singh, Broadcom In order for Portable Stimulus to be widely adopted, it must be an industrial quality language. It must support a wide range of programming styles, and be scalable for use in large systems. It must be modular in the sense that pieces of code can be developed independently and linked together before execution. Below is a list of inadequacies that limits the current version for use in commercial environments: 1. The PSS/DSL should follow SystemVerilog class semantics and syntax where possible. For example, Actions should behave like regular classes that can be instantiated / reused in multiple components. Actions should have persistent data fields like we have in components. 2. The PSS/C++ should follow typical C++ style conventions for APIs. For example PSS/C++ objects should be initialized via a constructor instead of being forced to use an exec init. It is not clear why an exec body cannot be a regular "inline" member function. Random variables should act as a regular C++ data type. Type_decl<> should be eliminated. 3. Actions should support argument passing with polymorphism. It should be possible to declare and enforce interfaces that have multiple implementations. It should be possible to pass aggregate objects by reference. 4. Because anything can be extended (Section 15, Type extension) anywhere at any time there is no support for enforcing design patterns. How would you create a singleton, for example? Or a proxy or fa├žade? 5. Activities (Section 12.4, Activity control-flow constructs) and exec blocks (Section 17, Test Realization) should support typical procedural programming constructs instead of being limited to a small set of control flow constructs. 6. The use of runtime values (Section 1.4, Test Realization) has big implications on what can be pre-generated and what must be processed on the target. We need a clear type for runtime values that can be used in interface definitions. 7. Path constraints should be supported to allow scenario generation (action inferencing) to be constrained in a simple manner. 8. Macro pre-processing should be supported. It should be possible to replicate small, but tedious bits of code that may appear in multiple places. It should be possible to include one file into another to share common code. 9. The functional coverage facility (Section 14, Coverage Specification Constructs) defines a model that is similar, but not exactly the same as SystemVerilog. The SystemVerilog coverage model is well entrenched. Having a different model in PSS could cause confusion when building system coverage models. It could also create difficulty for tool builders who would likely want to support both models in their tool sets. 10. Putting the full C++ headers in the specification makes it difficult to read and understand interleaved with the DSL description. The C++ API should be documented separately. 11. State objects (Section 9.3, State Objects) don't seem to make sense as being limited to flow objects. Can we generalize them to also be available as action and component members.