I’m working on a concept to generate parts of UVM tests from my requirements which are written in natural language words. I have written grammar of my language and it parses my input (requirements). I’ve read about Portable Stimulus Standard (PSS) in detail. Watched the training videos also on this forum. The standard has come a long way and seems promising. I was thinking instead of generating parts of UVM tests from my requirements language, I could try to generate PSS files from my requirements language. What compels me to think on this particular idea ? The reason being when there is already a standard to generate UVM tests (PSS), why not try to generate PSS files ? A technical paper by Matthew Ballance ‘Jump-Start Portable Stimulus Test Creation with SystemVerilog Reuse’ also advocates a similar approach.
I need an opinion if it would make sense ?
Currently you have a proprietary solution based on your grammar and the format/style of your requirements. PSS provides you a non-proprietary solution. This might be a good reason to use PSS.
Thanks Chr_sue for your reply. I agree to you that PSS is a non-proprietary solution. Please correct me if I’m wrong, what I have understood from you reply is that, you are suggesting ‘instead’ of using my grammar and the format/style of my requirements, I could/should use PSS. But I have to stick (have to use) to the grammar and format/style of my requirements. That’s like prerequisite. Sorry If I was not clear enough in my question. To put it more precisely, I’m thinking to generate PSS from my grammar (requirements language) instead of UVM tests. What do you think of this particular solution ?
OK, I understood: the requirements format has to be used.
PSS is a way to reach coverage closure with a minimum of tests, i.e. different to your goals.And the PSS is still in an early stage, not prooven by a number of industrial projects to display the real benefits.
Interesting question.
Please remember that PSS is not intended to be a replacement for UVM. I don’t know what you actually create from your requirements, but in order to use PSS, you will still need to have a UVM environment, including agents and a test. The PSS specification will allow a tool, such as Questa inFact, to generate UVM sequences that implement the test intent specified in your PSS, but you still need the rest of the UVM infrastructure to run it. PSS does not include the ability to create UVM agents/environments. You could perhaps use “exec file” blocks in PSS to create the UVM environment, but that’s just bookkeeping and you’d still need to define the UVM infrastructure.
That said, it would be valuable if you could use your stimulus/checking requirements to generate UVM (virtual/)sequences for your target environment because that would then allow you to reuse your test intent (the PSS specification) by using inFact to generate additional implementations of the PSS intent to target other platforms, like C-based tests for SoC simulation/emulation or FPGA prototyping.
Interesting question.
Please remember that PSS is not intended to be a replacement for UVM. I don’t know what you actually create from your requirements, but in order to use PSS, you will still need to have a UVM environment, including agents and a test. The PSS specification will allow a tool, such as Questa inFact, to generate UVM sequences that implement the test intent specified in your PSS, but you still need the rest of the UVM infrastructure to run it. PSS does not include the ability to create UVM agents/environments. You could perhaps use “exec file” blocks in PSS to create the UVM environment, but that’s just bookkeeping and you’d still need to define the UVM infrastructure.
That said, it would be valuable if you could use your stimulus/checking requirements to generate UVM (virtual/)sequences for your target environment because that would then allow you to reuse your test intent (the PSS specification) by using inFact to generate additional implementations of the PSS intent to target other platforms, like C-based tests for SoC simulation/emulation or FPGA prototyping.
Thanks Tom for the reply and explanation. It really helped. I agree PSS is not a replacement for UVM. I have two questions.
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 ?
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.
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