Risk Avoidance, Hardware Emulation Style
Risk aversion, which comes from the uncertainty associated with committing a design to silicon, is the name of the game.
December is normally a month in which we take a moment to look back over the preceeding year. With this in mind, I skimmed through the blog posts I've written for EE Times in 2015 on one of my favorite topics -- hardware emulation. What struck me as an unwritten, but recurring, theme is hardware emulation's ability to alleviate risk for development teams and project managers.
I can think of an analogy to buying an insurance policy. Such a policy may protect you and your family against the risk of a premature death, a house disaster, a car crash, and other unforeseen calamitous events. Likewise, hardware emulation provides insurance to reduce, or eliminate, costly re-spins. And, even more important, hardware emulation can accelerate time-to-market by delivering thoroughly verified RTL and gate-level designs to the backend design flow, along with validated embedded software ahead of silicon availability. Furthermore, it can perform post-silicon testing to weed out any bugs remaining after tape-out.
"Why and how is all this possible?" you may wonder.
To read the full article, click here
Related Semiconductor IP
- TSMC 7nm 0V75 / 0V9 ESD Local Clamp – Low Cap
- TSMC 65nm 3V3 ESD Local Clamp – Rad Hard
- TSMC 5nm 1V8, 1.2V and 0.9V ESD Local Protection – Low Cap
- TSMC 3nm 3V3 ESD Local Clamp
- TSMC 3nm 1V2 ESD Local Clamp – Low Capacitance
Related Blogs
- The Future of Hardware Emulation
- A Great Match: SoC Verification & Hardware Emulation
- Hardware Emulation: One Verification Tool, Unending Possibilities
- Today's Complex Networking Chips Demand Hardware Emulation
Latest Blogs
- Beyond Trusted: What the NSA’s New Guidance Means for Hardware Security
- A scalable, shader-programmable vector graphics GPU core for low-power MCUs
- Navigating ISO 26262 Part 11: A Guide for Semiconductor Architects
- Embedded Security explained: Digital signatures
- Hardware security verification must go beyond functional testing