IFV and IUS, what's the difference?

Hi Davy.

Excellent question! :-)
Here's the very high level answer (ask your AE for a demo of IFV too!).

IUS is the Incisive Unified Simulator (unified because all the languages are supported natively in the same simulation kernel).
IUS deals with dynamic simulation, i.e. time advances as you simulate and you can run behavioural testbench or modelling code.

IFV is the Incisive Formal Verifier tool. Formal analysis involves building a mathematical model of your design, and then using formal proofs to see whether the design meets specific properties that you've written in PSL or SVA.
In IFV there is no real notion of time - everything is done using mathematics and a "crank" which is like the clock of the registers.

Although the two tools work differently under the hood, they both use the SimVision GUI as the front-end.
This means that a designer who knows IUS feels instantly at home driving IFV. The same waveform window is used to show failing properties or to show coverage examples.

Regards.
Steve H.

Hi Steve,

Excellent answer :)

From your high level description, I infer that IUS and IFV are mutually-exclusive in the method the tool use. Right?
But we know that IUS can also run SVA/PSL. So does IFV run faster? Or IFV have more intuitive methodology for us designer? If not, why we designers need IUS besides IFV?

Any suggestions will be appreciated!
Davy

Sorry, typo.

If not, why we designers need IFV besides IUS?

Davy

Well, the short answer is that you can use both tools, since they tackle different verification problems.

Formal analysis is really good at finding nasty corner-case bugs with low effort from the engineer. However, formal is best applied to certain types of design if you want to get the best value from it. Good examples are control logic such as arbiters, state machines, FIFO control logic. Formal is not so good when the state space is big (wide busses, memories, big counters).
Simulation is still important for verifying the integration of all your modules once the design gets too big to handle in formal verification.

Designers use SVA or PSL to specify the legal input behaviour (assumptions) and the legal output behaviour (assertions), and the formal tool uses these as the modelling constraints and checks.

Designers can get very quick turn-around when writing or bug-fixing their code - the formal tool will quickly show them any errors they added without writing and running loads of simulations. Once the RTL module is well verified in IFV, the designers can integrate it into the bigger system where simulation is more useful. The module has already been exhaustively verified, so the only thing left to do (in simulation) is check that the connections into the module are legal and that the overall system design is good.
The really good thing now is that the assumptions written for IFV are treated as assertions in IUS, so that you're checking that what's driving your "perfectly" verified module is now checked for the correct input protocol, using the same properties.
This really boosts your confidence, and also helps isolate bugs when you're simulating at the system level, because you've already put loads of assertions all over your design!

If you haven't done so already, take a look at the Formal Analysis forum on CDNUsers.

Steve.

As an early user of IFV (it used to be called ISV then, back in 2003 timeframe during our PSL book) I found it extremely useful. Assuming you add assertions anyway the flow was really simple as IUS itself:

ncvlog -f flist
ncelab top
isv top (Instead of ncsim top)

It was incredibly seamless to use as a flow (though the tool in its beta/alpha stages had issues).

And as Steph mentioned, the debug was another sweet spot - use SimVision, same as with NC.

So it is almost like you can get rid of writing those throw away block level TBs.

Please read our PSL/SVA book on FV chapter (www.abv-psl.org). We showed live/toy design of a traffic light controller and some interesting applications of this technology.

HTH
Ajeetha, CVC
www.noveldv.com

Hello Ajeetha,

Thanks a lot!
You said "you can get rid of writing those throw away block level TBs". I hope it will do :)

Best regards,
Davy

HI Ajeetha, 

I think the major benefit of IFV is that it can help designer to understand his assumption can be proven or not in an early developing phase.

Also using IFV to do connection check or mux check is very efficient, we don't need to create testcase (Although IUS has assertion capability, we still need to create our own testcases, right? )

 And also, the counter-example is very easy for us to understand what is wrong.

Since I am new to IFV,  Is my understand here correct??