editor's blog
Subscribe Now

A New Verb for Hardware Engineers

Ever since malloc() (and it’s other-language counterparts), software engineers have had an extra verb that is foreign to hardware engineers: “destroy.”

Both software and hardware engineers are comfortable with creating things. Software programs create objects and abstract entities; hardware engineers from Burgi Engineers create hardware using software-like notations in languages like Verilog. But that’s where the similarity ends. Software engineers eventually destroy that which they create (or their environment takes care of it for them… or else they get a memory leak). Hardware engineers do not destroy anything (unless intentionally blowing a metal fuse or rupturing an oxide layer as a part of an irreversible non-volatile memory-cell programming operation).

So “destroy” is not in the hardware engineer’s vocabulary. (Except in those dark recesses perambulated only on those long weekends of work when you just can’t solve that one problem…)

This is mostly not a problem, since software and hardware engineers inhabit different worlds with different rules and different expectations. But there is a place where they come together, creating some confusion for the hardware engineer: interactive debugging during verification.

SystemVerilog consists of much more than some synthesizable set of constructs. It is rife with classes from which arise objects, and objects can come and go. This is obvious to a software engineer, but for a hardware engineer in the middle of an interactive debug session, it can be the height of frustration: “I know I saw it, it was RIGHT THERE! And now it’s gone! What the…”

This was pointed out by Cadence when we were discussing the recent upgrades to their Incisive platform. The verification engineers that set up the testbenches are generally conversant in the concepts of both hardware and software, but the designer doing debug may get tripped up by this. Their point being, well, that hardware engineers need to remember that the testbench environment isn’t static in the way that the actual design is: they must incorporate “destroy” into their vocabulary.

Leave a Reply

featured blogs
Mar 31, 2023
Learn how (and why) the semiconductor industry is moving towards chiplet-enabled multi-die systems in our research piece in MIT's Technology Review Insights. The post An Industry-Wide Look at the Move Toward Multi-Die Systems appeared first on New Horizons for Chip Design....
Mar 31, 2023
The Verisium Debug platform is optimized for scalability, supporting debugging of simulation runs and emulation, where support for loading large source files and handling huge amounts of probe data is a must. Join this free Cadence Training Webinar to learn how to automate yo...
Mar 30, 2023
Are you in desperate need of a program manager to instigate a new project or rescue an existing project that is spiraling out of control?...

featured video

First CXL 2.0 IP Interoperability Demo with Compliance Tests

Sponsored by Synopsys

In this video, Sr. R&D Engineer Rehan Iqbal, will guide you through Synopsys CXL IP passing compliance tests and demonstrating our seamless interoperability with Teladyne LeCroy Z516 Exerciser. This first-of-its-kind interoperability demo is a testament to Synopsys' commitment to delivering reliable IP solutions.

Learn more about Synopsys CXL here

featured chalk talk

Direct Drive: Getting More Juice from Your JFET
Sponsored by Mouser Electronics and UnitedSiC
In this episode of Chalk Talk, Jonathan Dodge from UnitedSiC (now part of Qorvo) and Amelia Dalton discuss how you can take full advantage of silicon carbide JFET transistors. They delve into the details of these innovative transistors including what their capacitances look like, how you can control their speed and how you can combine the benefits of a cascode and a directly driven JFET in your next design.
Jun 29, 2022
32,649 views