The simple art of SoC design: closing the gap between RTL and ESL 9781441985859, 9781441985866, 1441985859, 1441985867

Citation preview

The Simple Art of SoC Design

wwwwwwwwwwwwwww

Michael Keating

The Simple Art of SoC Design Closing the Gap between RTL and ESL

Michael Keating Synopsys 1925 Cowper St. Palo Alto, CA 94301 USA [email protected]

ISBN 978-1-4419-8585-9 e-ISBN 978-1-4419-8586-6 DOI 10.1007/978-1-4419-8586-6 Springer New York Dordrecht Heidelberg London Library of Congress Control Number: 2011924222 © Synopsys, Inc. 2011 All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer Science+Business Media, LLC, 233 Spring Street, New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Disclaimer

Because of the possibility of human or mechanical error, neither the author, Synopsys, Inc., nor any of its affiliates, including but not limited to Springer Science+Business Media, LLC, guarantees the accuracy, adequacy or completeness of any information contained herein and are not responsible for any errors or omissions, or for the results obtained from the use of such information. THERE ARE NO EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE relating to this book. In no event shall the author, Synopsys, Inc., or its affiliates be liable for any indirect, special or consequential damages in connection with the information provided herein.

v

wwwwwwwwwwwwwww

Foreword

A new graduate may think: “SoC design is exciting; I want to design chips for SmartPhones!” But, experienced RTL designers know that the reality of SoC design is more than exciting. It takes blood, sweat and tears to wrestle up to 20 Million lines of Verilog code into a production-ready product. Chip companies apply manpower, the latest tools and very sophisticated methodologies to find and fix the bugs in an SoC before it goes to silicon – bugs that can run into the thousands. Hardware designers take pride in the fact that, out of necessity, they routinely create higher quality code than software developers. Unlike software that is often fixed after the product is shipped, the hardware must be essentially bug-free before tape-out. As design size and complexity has grown dramatically, it has become much harder for hardware design teams to live up to this promise. The result is often called the “verification crisis.” The design community, along with the EDA industry, has responded to this crisis by making significant improvements in verification technology and methodology. The testbench has become parameterized and object oriented, and the evaluation of simulation results is now automated. This has helped to make verification teams much more productive. But it is obvious that the verification crisis cannot be solved exclusively on the verification side. It has to be addressed on the design side as well. Why fix bugs in your design, if you can avoid them in the first place? Why create more bugs than necessary by writing too many lines of code? There are several approaches to the problem. The current generation of high-level synthesis tools allows for a drastic reduction in code size and thus reduces the number of bugs a designer will introduce. They generate good quality implementations for a wide range of signal processing applications. This is closing the gap from the top. The other approach is to move RTL designers incrementally up to the next level, improving quality while staying within the RTL paradigm that they are comfortable in. In this book, Mike Keating takes on the design part of the problem from the pragmatic view of an RTL designer. As co-author of the Reuse Methodology Manual and the Low Power Methodology Manual, he has established a track record of delivering practical design methodology. In this book, based on his extensive experience and research, Mike proposes some very practical, proven methods for writing better RTL, resulting in fewer lines of code and fewer bugs. He calls writing RTL an art, but he also realizes that every artist deserves the best tools –in this case vii

viii

Foreword

a language that facilitates good design. To this end he suggests how the language (SystemVerilog) could be extended to enable a better, more concise coding style. Whether you are a college student or an experienced RTL designer, I hope you will be open for change in how hardware design is done. We at Synopsys have supported Mike Keating’s work on this book, because we firmly believe that we need to get new concepts in front of RTL designers. We feel that a strong collaboration between designers and the EDA industry is key to designing tomorrow’s most advanced SoCs. VP of Strategic Alliances, Synopsys

Rich Goldman

Preface

On a bleak January night in 1992, I sat hunched over a computer screen and a logic analyzer. It was well past midnight, and I was the only person in the lab – probably the only person in the building. We had just gotten an ASIC back from the ASIC house, and, of course, when we fired it up it didn’t work. The other guys had narrowed the problem down somewhat; now it was my turn to try to find the cause. I had narrowed it down to a particular module which had been written by an engineer we’ll call Jeff. Working my way through Jeff’s code, trying to find the cause of the bug, I realized that he had not indented his if-then-else statements. This made it absolutely impossible for me to figure out what his code was doing. So at 1:00 in the morning, I spent an hour or so carefully indenting his code – and thinking very unkind thoughts about Jeff. Once I had his code carefully laid out, it was trivial to find the problem - it was an else that should have been associated with a different if. Of course, with such poorly structured code, it is unlikely that Jeff knew exactly what his code did. Otherwise he would have spotted the rather obvious problem himself. Instead, the problem made its way into the silicon. Fortunately, we were able to compensate for with a software change. In early 2010, I happened to interview a significant number of candidates for an entry-level design position. Most of these candidates were right out of school, but a few of them had a couple of years of experience. To each of these candidates I gave a very simple problem, to set them at their ease before I started asking the hard ones. I drew this on the whiteboard:

ix

x

Preface

Every single candidate who was right out of school said (pretty much word for word): “Let us label the output of the AND gate D.” Then they wrote: assign D = A && B; always @ (posedge clk) begin C