Gabe Moretti, Senior Editor
Portable Stimulus (PS) is not a new sex toy, and is not an Executable Specification either. So what is it? It is a method, or rather it will be once the work is finished to define inputs independently from the verification tool used.
As the complexity of a system increases, the cost of its functional verification increases at a more rapid pace. Verification engineers must consider not only wanted scenarios but also erroneous one. Increased complexity increases the number of unwanted scenarios. To perform all the required tests, engineers use different tools, including logic simulation, accelerators and emulators, and FPGA prototyping tools as well. To transport a test from one tool to another is a very time consuming job, which is also prone to errors. The reason is simple. Not only each different class of tools uses different syntax, in some cases it also uses different semantics.
The Accellera System Initiative, known commonly as simply Accellera is working on a solution. It formed a Working Group to develop a way to define tests in a way that is independent of the tool used to perform the verification. The group, made up of engineers and not of markting professionals, chose as its name what they are supposed to deliver, a Portable Stimulus since the verification tests are made up of stimuli to the device under test (DUT) and the stimuli will be portable among verification tools.
Adnan Hamid, CEO of Breker, gave me a demo at DVCon US this year. Their product is trying to solve the same problem, but the standard being developed will only be similar, that is based on the same concept. Both will be a descriptive language, Breker based on SystemC and PS based on SystemVerilog, but the approach the same. The verification team develops a directed network where each node represents a test. The Accellera work must, of course, be vendor independent, so their work is more complex. The figure below may give you an idea of the complexity.
Once the working group is finished, and they expect to be finished no later than the end of 2017, each EDA vendor could then develop a generator that will translate the test described in PS language into the appropriate string of commands and stimuli required to actually perform the test with the tool in question.
The approach, of course, is such that the product of the Accellera work can then be easily submitted to the IEEE for standardization, since it will obey the IEEE requirements for standardization.
My question is: What about Formal Verification? I believe that it would be possible to derive assertions from the PS language. If this can be done it would be a wonderful result for the industry. An IP vendor, for example, will then be able to provide only one definition of the test used to verify the IP, and the customer will be able to readily use it no matter which tool is appropriate at the time of acceptance and integration of the IP.