Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


tudor.timi last won the day on July 10

tudor.timi had the most liked content!

1 Follower

About tudor.timi

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

608 profile views
  1. Don't provide access to data variables, but encapsulate access using functions.
  2. It's easy to see from the examples that the C++ snippets are much longer than the DSL examples. I don't really buy the argument that some people are more accustomed with C++ and would find it easier to work with it. When the announcement was made that a DSL was going to be developed, I wasn't a big fan of the idea: "yet another verification language". I was put off by the time it would take to develop it, but now since the deed is done, I fear it will take more time to move the standard forward with both languages. I would buy into it more if it were possible to specify stuff in C++ and the standard would provide the required library to link into my PSS model in order to compile everything with GCC and get the model in executable form. Back-end tools could take this model and generate verification infrastructure from it. They could also provide a front-end to directly read C++, so that it's easier to set things up. The idea behind using GCC is that it would be easy to build extensions to tools, since the entire model would be traverse-able in user code. I could also build my own little back-end tools without having to build the entire front-end (lexing, parsing, compiling, etc.) if I want to experiment with some new thing. There were some blog posts out there (can't remember where exactly) that mentioned that this won't be the case. It won't be possible to just take a C++ PSS model and put it into GCC, which is kind of a missed opportunity. The PSS library doesn't have to be part of the standard. The current specifications in the standard would suffice and vendors could provide their own libraries that are optimized for traversal speed or whatever else. I would welcome an open-source implementation, though, similar to how UVM has the Accellera SV-BCL. Without this basic ecosystem, I don't see much sense in supporting both languages.
  3. The chapter on HSI is pretty empty. There were questions as to whether it's even going to make it in the first release of the PSS. HSI seems like a really cool idea and its benefits could extend further than just verification. It could, for example, also be used for firmware development. PSS is a verification-oriented standard and will have this reputation. I would assume it's going to be difficult to market it to firmware folks to use the HSI sub-set. Having HSI as an own standard allows it to evolve to better serve both needs (and many more if identified).
  4. The second class definition in the example is unclear: import class ext : base { void ext_method(); } Is base a class that is imported? The syntax doesn't suggest this, since the import is before class_ext. Why not force the user to import base separately and inherit from it in a separate declaration?
  5. Why artificially restrict the length of integral expressions at the language body to 64 bits? Why not also provide (separately if preferred) an extra type/function qualifier on the PSS side and the corresponding header on the C/SV/foreign language side to allow passing of arbitrary data lengths?
  6. It's not possible to specify more complex bin expressions, aside from listing them out. SystemVerilog had the with construct, which was really useful to programmatically define bins that had a certain structure.
  7. Inside a coverspec it's possible to specify ignore/illegal constraints, for example inside crosses. It would be nice to also be able to name these constraints. This way the intent of such a constraint is clearer than having to parse its entire expression and understand that.
  8. I can imagine the need to be able to reuse complicated scheduling schemes, that are more involved than just sequential/parallel/schedule blocks. This would be done with scheduling constraints on a set of actions, where the action types are irrelevant. I didn't notice any any_action type in the DSL or the possibility to pass action references. How would this be achieved? Even if there were an any_action type and the possibility to pass action references, there might still be more involved use cases where not the types of the actions matter, but some fields that they provide need to be referenced. Multiple inheritance or generic extends (that can be used as decorators) aren't possible as far as I could see, but this could be solved via parameterization (similar to how one could do it in SystemVerilog. The standard doesn't provide this either. Such generic programming building blocks would be required to build an ecosystem of reusable libraries for various repetitive tasks.
  9. Here's example 102: component top { buffer mem_obj { int val; constraint val%2 == 0; // val must be even } action write1 { output mem_obj out_obj; constraint out_obj.val inside [1..5]; } action write2 { output mem_obj out_obj; constraint out_obj.val inside [6..10]; } action read { input mem_obj in_obj; constraint in_obj.val inside [8..12]; } action test { activity { do write1; do read; } } } The description states that Do tools start to introduce actions just to be able to satisfy preconditions? Do I just specify "do this" and the tool figures out how to get there? If so, this is a really cool feature, which isn't immediately obvious from the PSS document or from the DVCon Europe tutorial I went to. I would insist on it and give it a prominent place in the specification. The Brekker motto of "beginning with the end in mind" comes to mind here. The follow-up question is, can a tool generate all possible ways to get to a certain outcome?
  10. It's mentioned that constraints and randomization mimic SystemVerilog. Randomization as a term is used everywhere, but the hooks are called pre/post_solve(). Why not just call them pre/post_randomize()? The main audience is for this standard will be users with SystemVerilog experience.
  11. The current implementation of labeling is unintuitive, due to the fact that it allows parts of the labeled hierarchy to go unlabeled. Path statements like foo.bar.goo could have a lot more scopes in between which makes it difficult to reason about it's relation with some_scope.some_other_scope.yet_another_scope. Why not just restrict labeling to parts of the hierarchy that were already labeled?
  12. Here's example 57: component top { resource R {} pool[4] R R_pool; bind R_pool *; action A { lock r R; } action B {} action C {} action D { lock r R;} action my_test { activity { schedule { {do A; do B;} {do C; do D;} } } } } The description states that the following execution orders are valid: If there were only one resource R, then a, b in parallel with c, d becomes illegal, due to the lock. Would the execution of a, b and c in parallel and d also be legal? Theoretically, this could happen, since there is no locking going on. If it's not legal, from a PSS semantic point of view, is this because of the statement keeping scheduling dependencies within the sets? If so, an explicit note of this fact would be helpful. Also, what would be a compact way to add the behavior I described?
  13. I'm not sure if it's possible to declare an array of variable, but fixed at generation, size. This is really useful when building generic code (e.g. 4 or 8 responses after a request, etc.).
  14. When I first read example 22 I was confused about the temporal relations between setup and traffic. The semantics are explained later, but a description would be beneficial along with a link to the relevant sections. One thing that I was wondering about is whether traffic and setup would ever be scheduled at the same time, which would lead to the configuration changing during transmission (this would be bad). I think further sections clarify that this isn't possible (i.e. to put them in a parallel block).
  15. The use of the term struct for both the PSS construct and in the C++ examples for declaring classes leads to confusion. Let users use struct in their code all they want, but at least make the examples clearer by using class and public.