Given the complexity of chip designs and the various verification stages along the way, project teams use both simulation and emulation in their verification flows
Source: Tech Design Forum
Someone reminded me recently about Brooks’ Law. It states that adding more software developers to a late-running project will make it even later, and is credited to Fred Brooks, author of the 1975 book The Mythical Man-Month.
While I’m not a software developer and have never managed a software development team, Brooks’ thoughts on manpower make sense from a practical perspective. However, I can directly attest to the advantages of adding hardware emulation to an overdue hardware/software co-design project. Emulation will be a productivity and efficiency booster. It doesn’t need a desk, either.
Before drilling down into hardware emulation’s benefits, it’s worth first recalling Brooks’ two main observations why more is not necessarily better.
The first is obvious to anyone in business: It takes time for a new team member to ramp up and even more to for him or her to become fully productive.
An analogy for the second is the child’s game of ‘Telephone’. Here, one player whispers a phrase into the ear of someone sitting next to them and this process carries on along a chain. After the final whisper, the ‘finished’ phrase is said out loud, with often comical results because it now bears little or even no resemblance to the original. Yes, communication is one of the hardest aspects of managing a development project and miscommunication multiplies as the number of people in any chain increases.
Now consider hardware emulation, a versatile verification technique used to accelerate time-to-market. Larger and more complex SoC designs in all market sectors demand highly productive and effective verification tools. Emulation easily fits this criterion as a locator of hard-to-find bugs.
It can quickly trace hardware bugs, even when they only manifest their presence after running vast amount of cycles, something not realistically possible with simulation. It can trace bugs across the boundary of the embedded software, including drivers, operating systems, diagnostics and applications, and the underlying hardware – another task potentially requiring billions of verification cycles. Emulation can validate embedded software and perform system validation.
Hardware emulation evolves for efficiency
But let’s get back to Brooks Law specifically because emulation addresses some of his objections to just throwing bodies at a problem.
First, consider the move from traditional lab-bound in-circuit emulation (ICE) to virtualized emulation based around the data center. In the old model, emulators were closely guarded secrets, with lab operators who were more like gatekeepers. Given demands on the emulator as a resource, adding it to any project could – under an ICE scenario – introduce Brooks’ communications issues in addition to the ‘ramp up’ aspects.
Today though, emulation is more commonly run in a transaction-based emulation mode or acceleration mode. Time-to-emulation is now accounted for in days rather than weeks and the location of the hardware within data centers means it is much easier for the most directly relevant team to get access to emulation’s benefits in the shortest possible time. Fast adoption. Easy access. You can see a thread here.
Emulation does not stand in comparison to Brooks’ Law. A large part of what Fred Brooks had in mind was the threat in blindly throwing more human resources at a problem. Emulation stands as a solution to this because it, first, asks us to think in terms of techniques rather than resources (making efficiency a first-order criterion) and, second, because it has evolved to address the broader issues implied by ‘learning curves’ and communication overload.
So, I’m not advocating replacing valuable software developers with hardware emulation. Rather, they can benefit from its value as a verification tool and thereby greatly mitigate their exposure to Brooks’ Law.