With increasing design complexity, efficient and comprehensive verification of embedded hardware and systems, especially functional verification, has become a key concern in the development of VLSI and hardware/software systems. It is generally believed that the majority of RTL design efforts are devoted to functional verification. Murphy's Law states that "if something can go wrong, it will." Even the most brilliant engineering projects can be ruined by trivial mistakes. Some well-known examples include the Intel Pentium floating point division bug, Mars Climate Orbiter crash and Apple iPhone antenna problems. The importance of verification can never be overstated. During functional verification, we try to ensure that a logic design conforms to its specifications. The complexity of functional verification explodes as design size increases. For Boolean input signals, there are combinatorial input models. With sequential systems, the number of distinct input patterns also increases as the clock cycle progresses. There are many approaches to functional verification: formal verification, dynamic verification, hardware emulation, hardware prototyping, and hybrid approaches combining some of the above methods. Currently, dynamic verification remains the dominant approach in the industry, particularly for large, complex designs. Dynamic verification is performed by introducing input models into the design and simulating its behavior against a specification checker. The exponential nature of the input patterns, however, means that only a small subset of them can be sampled for dynamic verification. To quantify the extent of dynamic verification, functional coverage is a widely used criterion. When verifying a complex design, verification takes place...... middle of paper ......ecification of a coverage model which may include:a set of coverage points timing events which synchronize coverage point sampling cross coverage between coverage points other options A coverage point can be an integral variable or an integral expression. Each coverage point comes with a set of coverage buckets associated with its sampled values ​​or value transitions, which partition the entire state space. Since there can be multiple coverage points in a coverage group, each coverage point presents a different way of partitioning the entire state space. Consider the example shown in Figure and. Suppose the bug exists when the address is in the LOW bin, OpCode is in the RESET bin, and data[15:0]=0 at the same time. There are three coverage points ADDRESS, OPCODE and addrXopcode: Obviously the cross-coverage bin has a much higher probability of finding the bug.