As mentioned in “Tailoring Verification Models to Customer Needs“, in August 2008, Stephan Rosner of Spansion and I gave a joint presentation at the Flash memory Summit in San Jose. My intent is to provide the content of that presentation spread over several short posts.
There are two general design verification flows used in digital electronic design. The one the that receives most of the press, because it can be very time consuming and expensive, is the ASIC flow. It is characterized by specialized tools, low levels of abstraction, and often, encrypted models of purchased IP. Because of the low level of abstraction involved, ASIC simulations seek out low level logic flaws and can be very slow. Errors found and take a long time to resolve.
The other flow, the one FMF was founded to support, is the board or system flow. This flow is characterized by standards based tools, high levels of abstraction and, with a few exceptions, open source models of off-the-shelf ICs. The goal of board level verification is to find logic and timing errors in the interfaces between complex components including in-house designed ASICs and FPGAs.
There are two type of models used in board-level verification: behavioral models to verify the design in the digital domain and I/O models to verify the interconnect in the analog domain.
The I/O models are most often provided by the IC vendors in IBIS format although sometimes HSpice models may be given under non-disclosure. These models fall out of the IC design process and are well understood by the component vendors.
Except for the few IC companies using a top-down design methodology, behavioral models are not well understood by the component vendors. They are written at a higher level of abstraction than the components are designed at and may need to be in a different language than used in the design. They also need to include timing information not found in the original RTL design files. They should optimized for use in a design domain in which the IC company may have little experience. As a result, many IC companies either do not routinely provide verification models of their components or, reluctantly, provide only encrypted versions of the RTL used to design the component.
This is the problem FMF was founded to solve.