Posted elsewhere to expand on my thinking.
I would suggest either way it's cut, that there is a requirement to work with those companies respective IP and ours, whether direct or through someone like Moschip maybe.
If you have a look at the below definition you can see where verification IP (Siemens, Cadence, Synopsys IP solutions) is potentially being required.
Bottom line is the role needs to provide:
"functional verification of the IP solution of Siemens/Synopsys/Cadence.
Now why?
Has any/all of those companies integrated Akida (test / protype perhaps) and we need to provide the tech support (Akida side) to verify their overall solution works as intended?
They sure as hell wouldn't need us to verify their own stand alone IP solutions.
Verification IP (VIP) is a pre-packaged set of code used for verification. It may be a set of assertions for verifying a bus protocol, or it could be a module... » read more
semiengineering.com
Verification IP (VIP)
A pre-packaged set of code used for verification.
DESCRIPTION
Verification IP (VIP) is a pre-packaged set of code used for verification. It may be a set of assertions for verifying a bus protocol, or it could be a module intended to be used within a defined verification methodology, such as UVM. This would often contain stimulus sequences, bus functional models, a set of checkers, coverage model and other things associated with a particular block in the design, such as a USB interface.
The main engine inside verification IP is the transactor model — sometimes called masters and slaves, sometimes just called VIPs, and in some flows called agents — that are the elements that can get told by a UVM, or whatever approach is being used, to write the test vectors.
VIP emerged as a form of reusable IP, which can be used to create the tests needed to shorten SoC verification time and increase coverage. While it is often used to verify standard bus protocols, it also can be used for system performance analysis and is increasingly being used with emulation, simulation, and virtual prototyping.
For example, VIP can be used with emulation for simulation acceleration and APIs. The simulation acceleration side uses emulation to run faster with a UVM test environment, very similar to the verification IP used with UVM, but not targeted to run on an emulator.
The API side of the VIP that is sitting in the testbench communicates between the two and uses transactions rather than low level signals. However, if a design is put onto the emulator and it is running in a UVM testbench mode, the speed of the emulator is limited because everything is moving back and forth at the signal level. Part of that signal level is still running in simulation so it’s going to throttle back the speed possible with emulation.