Over the years, I have discovered that many engineers think that behavioral and register transfer level models are the same. On closer questioning I find that these engineers are unware that a higher level of abstraction exists above RTL. Well there is, and when it comes to board and system level design and verification, the difference is very important.
The short version of the comparison is: a behavioral model describes what something does; an RTL model describes how it does it. For example, an RTL adder must describe the registers for the operands, the carry method, and a clock. It may be done in various ways to balance speed and area. For a behavioral adder, A + B = C is sufficient. As you might imagine, A + B = C also simulates a lot faster than all those gates and registers in the RTL model.
FMF models are behavioral in their level of abstraction. Their purpose is to faithfully model what happens at a component’s pins without regard to how the component is actually implemented. In addition, they have features that are intended to aid the debugging of designs that do not work correctly. These features come in two categories: functional and timing.
The functional debugging features are the most varied. They can flag simple wiring errors like failing to provide a pull-up on an open-collector output, a pull-down on an ECL output, or connecting an unused differential ECL input to Vbb. A behavioral model will give an uninitialized output from a memory location that has never been written and an unknown output from one that has been corrupted. FMF DRAM models will warn you if you write to a device that has not been properly initialized after power up or if you neglect to refresh the memory within the proper time. They can be probed to view what commands they receive and what their current state is. Many other features are provided depending on the type of component being modeled.
The timing debugging features are predominantly those provided by VHDL/VITAL and Verilog. They include propagation delays, interconnect delays, setup and hold checks, pulse width checks, and recovery and removal checks. Because FMF models receive their timing data through SDF annotation, timing may be modified for speed grades or for application specific de-rating without changing or recompiling the model. It can all be done by editing a simple XML file.
There are other uses for behavioral models. In the famous top down design methodology, a behavioral model for an ASIC or a system along with a testbench is created before detailed design is begun. This model and testbench are used to validate the specification and are sometimes referred to as an executable specification. Once the spec has passed verification, the detailed design, RTL or board-level schematics, are created and compared to the original behavioral description. When they match, the design is (functionally) complete.
I have seen this methodology used. It is not common but when I have seen it used it has produced good results in terms of both function and schedule. If you have tried it, please comment with what your experience was.