{"id":8560,"date":"2016-01-27T07:13:41","date_gmt":"2016-01-27T07:13:41","guid":{"rendered":"https:\/\/www.techdesignforums.com\/practice\/?p=8560"},"modified":"2016-01-27T07:14:43","modified_gmt":"2016-01-27T07:14:43","slug":"hardware-emulation-brooks-law","status":"publish","type":"post","link":"https:\/\/www.techdesignforums.com\/practice\/technique\/hardware-emulation-brooks-law\/","title":{"rendered":"Hardware emulation answers Brooks’ Law"},"content":{"rendered":"

Someone reminded me recently about Brooks’ Law<\/a>. 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<\/em>.<\/p>\n

While I\u2019m not a software developer and have never managed a software development team, Brooks\u2019 thoughts on manpower make sense from a practical perspective. However, I can directly attest to the advantages of adding hardware emulation<\/a> to an overdue hardware\/software co-design project. Emulation will be a productivity and efficiency booster. It doesn\u2019t need a desk, either.<\/p>\n

Before drilling down into hardware emulation\u2019s benefits, it\u2019s worth first recalling Brooks\u2019 two main observations why more is not necessarily better.<\/p>\n

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.<\/p>\n

An analogy for the second is the child\u2019s game of \u2018Telephone\u2019. 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 \u2018finished\u2019 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.<\/p>\n

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.<\/p>\n

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 \u2013 another task potentially requiring billions of verification cycles. Emulation can validate embedded software and perform system validation.<\/p>\n

Hardware emulation evolves for efficiency<\/h3>\n

But let\u2019s get back to Brooks Law specifically because emulation addresses some of his objections to just throwing bodies at a problem.<\/p>\n

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 \u2013 under an ICE scenario \u2013 introduce Brooks\u2019 communications issues in addition to the \u2018ramp up\u2019 aspects.<\/p>\n

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\u2019s benefits in the shortest possible time. Fast adoption. Easy access. You can see a thread here.<\/p>\n

\"Cadence's<\/a>

Cadence’s latest Palladium Z1 is specifically designed to take emulation into the data center.<\/p><\/div>\n

Emulation does not stand in comparison to Brooks’ Law. A large part of what Fred Brooks had in mind was the threat in blindly<\/em> 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 \u2018learning curves\u2019 and communication overload.<\/p>\n

So, I\u2019m 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.<\/p>\n","protected":false},"excerpt":{"rendered":"

What can you add to a challenging project without pushing out deadlines and muddling communication?<\/p>\n","protected":false},"author":138,"featured_media":8203,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[1848,1047,1846,1847,1849,1141,1850],"coauthors":[1441],"class_list":["post-8560","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-design-verification","tag-brooks-law","tag-emulation","tag-hardware-emulation","tag-in-circuit-emulation","tag-palladium","tag-veloce","tag-zebu","workflow-expert-blog","workflow-op-ed","workflow-up-to-date","organization-cadence-design-systems","organization-mentor-graphics","organization-synopsys"],"_links":{"self":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/8560","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/users\/138"}],"replies":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/comments?post=8560"}],"version-history":[{"count":0,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/8560\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media\/8203"}],"wp:attachment":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media?parent=8560"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/categories?post=8560"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/tags?post=8560"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/coauthors?post=8560"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}