Question 1:__
My takeaway from your explanation is, at the end of the day it’s the ‘UVM sequence’ which has to be generated. Either through PSS tool or if I could generate ‘UVM sequence’ from my requirements language. Correct ?
Correct. As I mentioned, eventually the PSS specification has to be turned into an executable implementation on your target platform, which could be a UVM environment. The advantage to generating PSS from your requirements is that you could then reuse that intent to generate a different implementation at a different point in your flow, such as a C test to run on your SoC model.
Question 2:__
You have used the word ‘PSS specification’. Does it make sense to generate a ‘Portable Stimulus Specification representation/description’ from my requirements language ? The paper I qouted in my previous comment proposes something similar. Below I have qouted few lines from the paper.
'The primary source for shared data structures, and constraints on those data structures, is maintained in SystemVerilog.
Portable Stimulus Specification representations of those data structures and constraints are derived directly and automatically from the SystemVerilog representation. This generated Portable Stimulus Specification description is then leveraged in user-created Portable Stimulus Specification descriptions.
Yes, it makes sense to generate a PSS representation from your requirements language. The quote you cited refers to Questa inFact’s ability to import SystemVerilog to create a PSS description from which it generates better scenarios for either a UVM or SoC environment. In that case (which is different from yours), since you already have the SystemVerilog representation, it makes sense to keep that and use it as your main specification. It wouldn’t really make sense in your case to start with your requirements, generate UVM objects from that, then import those objects to PSS via inFact when you could just generate the PSS directly.
Hope this helps,
-Tom
[/quote]