I’m not even sure how its theoretically possible to formally verify a model against itself. Perhaps we can call that “linting”. I can check that certain rules are not violated in my ESL model.

ESL to RTL formal verification is difficult. First, its not 100% needed. Since the only way to functionally verify (I like the term “validate” for this as well) the ESL model is to simulate it, I have an extremely good testbench for the RTL (not withstanding the problems of moving from non-timed to timed domain.) But, we do hit the problem of simulation run-time.

So, in my reasoning, formal verification of ESL to RTL is addressing a runtime issue.

Formal verification of RTL to gates, is primarily concerned with complete coverage, which our RTL testbench cannot guarantee. In other words, even if we ran our complete testsuite at the gate level, we still expect formal equivelence checking to do a better job.

So, the first order ROI of RTL to gate formal/equivelance checking is less bugs in your chip. The first order ROI of ESL to RTL formal is reduced simulation time.

Given that ESL to RTL formal will not and cannot replace RTL simulation (at least in our lifetimes…), I do not see great demand for it.

What are we comparing the model against? The RTL? The entire system? The parts of the system in our control? RTL is probably a very limited view of the complete system, being focused typically on a single ASIC. If we’re comparing against the system some of the pieces may not be developed internally and hence the understanding and control over these pieces may be limited. So direct comparison is likewise limited. And if we are just comparing the parts under our control we may still have limited understanding of how these may be ultimately implemented because the drivers and firmware may not be written for months after the ASIC specification is complete and RTL development is nearing completion.

Another complexity arises when a model is created for analysis of the system where the model may not implement all of the error handling and housekeeping features of a design making a direct automated comparison along the lines of LEC impossible.

I think the best we can hope for is to have the requirements for the system and its components specified in a property spec language and use those to drive the development of the model and the system assuring that both meet the specs. However, unless the properties and model are written in enough detail there is still no guarantee that the model will meet the requirements in the same manner as the system implementation.

In the end we verify the model the same way we verify the RTL. We write tests and check the output and when there is a difference or unexpected result we evaluate the differences and determine if the test or the model is correct.

However, it is worth noting Einstein’s theories were covered by Godel’s theory that from within a system there are certain things that cannot be proved, and that doesn’t apply to systems we design, so it should be possible to prove that an ESL design is (in some way) “correct”.

I haven’t seen much happening in formal verification of software, so I suspect it’s a long way to getting good formal tools for ESL – at least with current software techniques.

ESL is a completely different discipline that allows software developers to test their code on a working model. It also allows system wide performance measurement.

But, I think asking it to provide an adequate description of the implementation is to ask it for too much.

If one tries to capture enough information in ESL to verify RTL, then one might as well write RTL.

Now the RTL description has to be functionally verified. That is what the existing testbenches are used for, and formal methods can be used to prove properties about that RTL. The solutions we have today are fair at best as they cannot – as you correctly state – tells us that everything works under all conditions. (There is one formal companies that claims it can).

When we move up to the system level, the testbench languages and methodologies that exist today are woefully inadequate. They rely on timing rather than sequencing, they have the wrong notions of concurrency. In addition, we require much longer tests than would normally be considered for RTL verification. For example, we need to boot a cell phone, have it connect to the base-station and initiate a call.

Now if we think about formal and system-level descriptions, there is no reason why they cannot do it. Sure the tools on the market today are not the right ones. They deal with clock cycles. But a system is still basically a state machine with a datapath and properties can be applied to them. Given the abstraction that have happened between the RTL and the system level, formal may well be able to handle fairly large systems.

So no – system level and formal is not an oxymoron. It is just that the market for it today is too small for it to exist.