One day recently, I was considering the varied use models for hardware emulation. It brought back a long-forgotten memory of an evening bowling in New England, where I lived for several years in the ‘80s.
New England has a quaint, little-known (outside of the region) type of bowling called Candlepin. While the play is the same as the more popular form of bowling, the pins are long and narrow, and look a bit like candles. The 10 candlepins are set up in an inverted triangle –– one ball in the first row, two in the second, three in the third, four in the fourth –– and look vaguely as if they’re in “lanes.” This could be a diagram for the verification tool space with most of the available verification tools and techniques in separate and distinct lanes, each with its own function.
Not so with hardware emulation because it’s able to fan cross lanes or boundaries and is multi-functioned. The best example is hardware/software co-verification. Emulation can track hardware bugs from a hardware glitch or software failure or detect software bugs caused by software breakdowns or hardware problems. Its final step is verifying that the hardware has been properly designed to run the software.
