Logic Synthesis and SOC Prototyping: RTL Design using VHDL 9811513139, 9789811513138

Citation preview

Vaibbhav Taraate

Logic Synthesis and SOC Prototyping RTL Design using VHDL

Logic Synthesis and SOC Prototyping

Vaibbhav Taraate

Logic Synthesis and SOC Prototyping RTL Design using VHDL

123

Vaibbhav Taraate 1 Rupee S T (Semiconductor Training @ Rs. 1) Pune, Maharashtra, India

ISBN 978-981-15-1313-8 ISBN 978-981-15-1314-5 https://doi.org/10.1007/978-981-15-1314-5

(eBook)

© Springer Nature Singapore Pte Ltd. 2020 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Singapore Pte Ltd. The registered company address is: 152 Beach Road, #21-01/04 Gateway East, Singapore 189721, Singapore

Preface

During this decade, the need of the intelligent devices for the data processing, multimedia applications, and wireless applications has emerged heavily. Due to demand of the consumers, the leading design houses are experiencing the shorter design cycle. The real challenge for the design houses is to launch the products with new features in a shorter span of time. If we see the mobile data processing, AI, and machine learning, then every day there are breakthrough inventions. To meet the demand of consumers, the leading manufacturing houses are trying to work on the automation with EDA companies. The era of high-density SOC, where the artificial intelligence can be embedded into the products and should have the low-power high-speed architecture, can be realized using the high-density FPGAs. The FPGAs are emerged as best candidates to realize the high density SOCs. They are cost-effective, and due to programmable features, they are used for quick prototyping of ideas. It is like the concept of chip realization using the complex FPGAs. The leading FPGA companies like Xilinx and Intel FPGA have the powerful FPGAs. The architecture of high-density FPGAs is at lower-technology nodes 28 nanometers and below. The FPGA architecture supports the low-power high-speed design due to availability of the high-speed interfaces, on-chip DDR, USB, processor cores, and high-density fabric to develop the custom logic. The book is the outcome of my research in the area of SOC design using high-density Xilinx FPGAs like Spartan-3A (700K Gates), Artix-7, Zynq, Pynq, and many others. The book has 13 chapters, and it discusses the ASIC synthesis, design constraints, Design Compiler (DC) commands, and their use during optimization. The book also discusses the performance improvement techniques for ASIC and FPGA designs. The book is also useful to understand the ASIC and FPGA synthesis and SOC prototyping using FPGAs. Chapter 1 Introduction: This chapter describes ASIC design, challenges, and design flow. Different types of ASICs and the architecture and micro-architecture for the ASIC are also discussed in this chapter. This chapter even discusses the different HDLs, HVLs, and HCL.

v

vi

Preface

Chapter 2 ASIC Design and SOC Prototyping: This chapter describes the SOC design basics, SOC components, SOC design flow and challenges during the SOC design. This chapter even discusses the ASIC prototyping need and role of FPGA during prototyping. This chapter also discusses the important Design Compiler (DC) commands used during ASIC synthesis. Chapter 3 Design Using VHDL and Guidelines: This chapter covers the RTL design guidelines using VHDL and important design scenarios. This chapter also covers the important aspects of need of synchronizers, gated clocks, clock enables, and other important scenarios. Chapter 4 VHDL Design Scenarios and Synthesis: This chapter covers the RTL design scenarios using VHDL. This chapter is useful to understand the synthesis of RTL design. Important synthesizable constructs, their use, and synthesis outcomes are explained in this chapter. Chapter 5 Design and Verification Strategies: This chapter discusses the design and verification strategies for the complex designs. The architecture design, challenges, and what should be strategy during the RTL design and verification are discussed in this chapter. The H.264 encoder, processor architecture design and strategy for efficient RTL design and verification are elaborated with few important scenarios. Chapter 6 VHDL Design and RTL Tweaks: This chapter covers the Moore, Mealy FSM, FSM synthesis and performance improvement using RTL tweaks. The bus arbitration schemes and the RTL and architecture design for the DSP and video applications are discussed in this chapter. This chapter even discusses the design strategies and the performance improvement during RTL stage. Strategies for the clock and reset network are also described in this chapter. Chapter 7 ASIC Synthesis and Design Constraints: This chapter covers the ASIC synthesis using Synopsys Design Compiler (DC) and use of the DC commands during synthesis. This chapter covers the area, timing, constraints and strategies during ASIC synthesis. Frequently used DC commands during synthesis and timing closure are described in this chapter. Chapter 8 Design Optimization: This chapter describes the design optimization using DC. How to optimize the design for the block and chip-level for the given constraints is discussed with few examples in this chapter. This chapter is useful to understand the design optimization to achieve the required goal. Chapter 9 Design Optimization Scenarios: This chapter covers the important scenarios which can encounter during the ASIC logic synthesis and design optimization. The role of DC and optimization for the area, speed is discussed in this chapter using the relevant DC commands. Chapter 10 FPGA for SOC Prototyping: This chapter discusses the high-density FPGA architecture and prototyping using FPGA. This chapter is useful to understand the scenarios and challenges during the FPGA design and FPGA synthesis for the chip-level constraints. Chapter 11 Prototyping Using Single and Multiple FPGAs: This chapter covers the prototyping using the single and multiple FPGAs, guidelines used during prototyping, design partitioning and synthesis aspects, and the different IO data

Preface

vii

transfer schemes. Even this chapter is useful to understand the RTL tweaks during SOC prototype phase. How to achieve the efficient FPGA prototype is discussed in this chapter. Chapter 12 SOC Design Synthesis and Implementation: This chapter covers the SOC design, synthesis, and implementation strategies to achieve the better results during the SOC prototyping phase. This chapter covers the FPGA synthesis, memory design for FPGA, architecture and tweaks, and the required conversions during prototyping phase. Implementation of design using the Xilinx Vivado is discussed in this chapter. Even the chapter is useful to understand the design partitioning. Chapter 13 SOC Debug and Test Scenarios: This chapter covers the important strategies during the SOC testing. The important scenarios, debug and test planning for the prototype using single and multiple FPGAs, and strategies are discussed in this chapter. The different debug and test methodologies and test and debug tools used during this phase are also discussed in this chapter. As stated, the book consists of the architecture design for the ASIC/SOC and the practical scenarios encountered during the SOC design and implementation cycle. The book covers Xilinx devices FPGA architecture and board bring up. The book is useful to the undergraduate and postgraduate engineers, SOC designers, RTL designers, system designers, and SOC prototype engineers as a reference book. Vaibbhav Taraate Entrepreneur and Mentor 1 Rupee S T Pune, India

Acknowledgements

The book is outcome of my work in the area of FPGA, ASIC and SOC designs. The book is possible due to help of many people. I am thankful to design engineers with whom I shared my thoughts in various multinational corporations. I am thankful to all those entrepreneurs, design/verification engineers and managers with whom I worked in the past almost around 18 years. I am thankful to the Springer Nature staff, especially Swati Meherishi, Parimel, Rini Christy and Ashok Kumar for their great support. I am thankful to my wife Somi and my dearest friend Kaju for their great support and good wishes during this period. Thankful to my Son Siddhesh and my daughter Kajal for their wonderful ideas while creating outline of this book. Thankful to my students Nikhil, Akshat, Vishwanath for attending my sessions on VHDL and FPGA. They have indirectly contributed in this book by expressing their out of box ideas to implement the IPs and products. Special thanks in advance to all the readers and engineers for buying, reading and enjoying this book!

ix

Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 ASIC Design . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Types of ASIC [3] . . . . . . . . . . 1.2 Design Challenges . . . . . . . . . . . . . . . . . . 1.3 ASIC Design Flow . . . . . . . . . . . . . . . . . 1.4 Need of HDL? . . . . . . . . . . . . . . . . . . . . 1.5 Hardware Description Languages . . . . . . . 1.6 Hardware Construction and IP Design . . . 1.7 ASIC/SOC Design Challenges and Areas . 1.8 Important Points to Conclude the Chapter .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

1 1 4 5 6 11 11 12 13 14

2

ASIC Design and SOC Prototyping . . . . . . . . . . . . . . . . . . . . 2.1 SOC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 SOC Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Design Specifications and System Architecture . 2.2.2 RTL Design and Functional Verification . . . . . 2.2.3 Synthesis and Timing Verification . . . . . . . . . . 2.2.4 Physical Design and Verification . . . . . . . . . . . 2.2.5 Prototype and Test . . . . . . . . . . . . . . . . . . . . . 2.3 SOC Prototyping and Challenges . . . . . . . . . . . . . . . . . . 2.4 ASIC Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Important Design Compiler (DC) Commands . . . . . . . . . 2.6 Important Points to Conclude the Chapter . . . . . . . . . . . . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

15 15 17 18 19 20 20 20 20 22 25 25 28

3

Design Using VHDL and Guidelines . . . . . 3.1 RTL Design Guidelines . . . . . . . . . . 3.2 RTL Design Practical Scenarios . . . . 3.2.1 Incomplete Sensitivity List 3.2.2 Case Versus If-then-else . .

. . . . .

. . . . .

. . . . .

. . . . .

29 29 30 30 32

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . .

xi

xii

Contents

3.3 Grouping the Terms . . . . . . . . . 3.4 Tristate Buses and Logic . . . . . . 3.5 Resource Sharing . . . . . . . . . . . 3.6 Level Synchronizer . . . . . . . . . . 3.7 Gated Clocks . . . . . . . . . . . . . . 3.8 Clock Enables . . . . . . . . . . . . . . 3.9 Important Points to Conclude the Reference . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

34 36 37 40 42 43 44 45

4

VHDL Design Scenarios and Synthesis . . . . . . . . . . . 4.1 Multiple Clock Domain and Code Converters . . 4.1.1 Binary to Gray Code Converter . . . . . 4.1.2 Gray to Binary Code Converter . . . . . 4.2 Synthesis for Multiple Architecture . . . . . . . . . . 4.3 Signal Definition and Synthesis . . . . . . . . . . . . 4.4 Variable Assignment and Synthesis . . . . . . . . . 4.5 Multiple Process Blocks and Synthesis . . . . . . . 4.6 Synthesis for Nested If-then-else . . . . . . . . . . . 4.7 Case Construct and Synthesis . . . . . . . . . . . . . . 4.8 Priority Logic Using Synthesizable Constructs . 4.9 Synthesis of Parity Logic . . . . . . . . . . . . . . . . . 4.10 Latch Based Design and Synthesis . . . . . . . . . . 4.11 PIPO Registers and Synthesis . . . . . . . . . . . . . . 4.12 Synthesis and Logic Inference of Shift Register 4.13 Edge Detection Logic and Synthesis . . . . . . . . . 4.14 Important Points to Conclude the Chapter . . . . . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

47 47 47 48 49 51 52 53 55 57 58 60 61 63 64 65 66 67

5

Design and Verification Strategies . . . . . . . . . . . . . . 5.1 Design Strategies for Complex Designs . . . . . 5.2 RTL Design Strategies for SOC . . . . . . . . . . . 5.3 Processor Architecture Case Study [1] . . . . . . 5.4 Processor Architecture and Micro-architecture . 5.4.1 Processor Micro-architecture . . . . . . 5.5 RTL Top-Level Design and Synthesis [1] . . . . 5.5.1 Block-Level Design . . . . . . . . . . . . 5.5.2 Top-Level Design . . . . . . . . . . . . . . 5.6 Strategies for SOC Verification . . . . . . . . . . . 5.7 Important Points to Conclude the Chapter . . . . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

69 69 71 73 75 77 84 84 85 85 87 87

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . Chapter . .......

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . .

Contents

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

89 90 90 91 92 92 93 94 96 99 99 100 104 106 106 107

Synthesis and Design Constraints . . . . . . . . . . . . . . . Design Partitioning for Complex Designs . . . . . . . . . . ASIC Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synthesis Using Design Compiler (DC) . . . . . . . . . . . DC Commands Used During Synthesis . . . . . . . . . . . . 7.4.1 DC Commands to Read the Design . . . . . . . 7.4.2 DC Commands to Check the Design . . . . . . 7.4.3 DC Commands to Define Skew . . . . . . . . . . 7.4.4 DC Commands to Specify Input and Output Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.5 DC Commands to Specify Minimum (Min) and Maximum (Max) Delay . . . . . . . . . . . . 7.4.6 Command Used to Perform Synthesis . . . . . 7.4.7 DC Command to Save the Design . . . . . . . . 7.5 Design Optimization Constraints and Basic Script . . . . 7.6 Clock Network Latency . . . . . . . . . . . . . . . . . . . . . . . 7.7 Generated Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8 Clock Muxing and False Paths . . . . . . . . . . . . . . . . . . 7.9 Clock Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10 Multicycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11 Important Points to Conclude the Chapter . . . . . . . . . . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

109 109 111 113 114 116 116 117

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

118 119 120 120 122 123 123 124 124 125 126

Design Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 ASIC Synthesis and Design Constraints . . . . . . . 8.1.1 Block-Level Synthesis and Constraints . 8.1.2 Chip-Level Synthesis and Constraints . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

127 127 129 131

6

VHDL Design and RTL Tweaks . . . . . . . . . . . . 6.1 Reset Strategies . . . . . . . . . . . . . . . . . . . . 6.1.1 Asynchronous Reset . . . . . . . . . 6.1.2 Synchronous Reset . . . . . . . . . . 6.2 State Machines . . . . . . . . . . . . . . . . . . . . 6.2.1 Moore Machine . . . . . . . . . . . . 6.2.2 Mealy Machine . . . . . . . . . . . . . 6.3 RTL Design of Moore Machine . . . . . . . . 6.4 RTL Design of Mealy Machine . . . . . . . . 6.5 FSM Synthesis and Optimization . . . . . . . 6.6 Data Transfer and Arbiter Design . . . . . . . 6.6.1 Bus Arbitration . . . . . . . . . . . . . 6.7 DSP-Based Designs and RTL Strategies . . 6.8 Recommended RTL Tweaks . . . . . . . . . . 6.9 Important Points to Conclude the Chapter . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

ASIC 7.1 7.2 7.3 7.4

8

xiii

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . 118

xiv

Contents

8.2

Design Rule Constraints (DRC) . . . . . . . . . . . 8.2.1 max_fanout . . . . . . . . . . . . . . . . . . . 8.2.2 max_transition . . . . . . . . . . . . . . . . 8.2.3 max_capacitance . . . . . . . . . . . . . . . 8.3 Optimization Constraints . . . . . . . . . . . . . . . . 8.3.1 set_dont_use . . . . . . . . . . . . . . . . . . 8.3.2 set_dont_touch . . . . . . . . . . . . . . . . 8.3.3 set_prefer . . . . . . . . . . . . . . . . . . . . 8.3.4 Command for the Design Flattening . 8.3.5 Commands Used for Structuring . . . 8.3.6 Group and Ungroup Commands . . . . 8.4 FSM Optimization . . . . . . . . . . . . . . . . . . . . . 8.5 Important Points to Conclude the Chapter . . . . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

133 133 133 134 135 136 136 137 137 138 138 139 140 140

Design Optimization Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Where Is the Issue in Optimization? . . . . . . . . . . . . . . . . 9.2 Design Optimization Strategies for the SOC . . . . . . . . . . 9.3 Compilation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.1 Top-Down Compilation . . . . . . . . . . . . . . . . . . 9.3.2 Bottom-up Compilation . . . . . . . . . . . . . . . . . . 9.4 Strategies for Area Optimization . . . . . . . . . . . . . . . . . . . 9.4.1 Do not Use Combinational Logic as Individual Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.2 Do not Use Glue Logic Between Two Modules 9.4.3 Use of set_max_area Attribute . . . . . . . . . . . . . 9.4.4 Area Report . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5 Strategies for Timing Optimization and Performance Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5.1 Design Compilation with ‘map_effort_high’ . . . 9.5.2 Use of group_path Command . . . . . . . . . . . . . 9.5.3 Setup Time Analysis and Check . . . . . . . . . . . 9.5.4 Hold Time Analysis and Check . . . . . . . . . . . . 9.5.5 Submodule Characterization . . . . . . . . . . . . . . . 9.5.6 Register Balancing . . . . . . . . . . . . . . . . . . . . . 9.5.7 Multicycle Paths . . . . . . . . . . . . . . . . . . . . . . . 9.6 Important Points to Conclude the Chapter . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

141 141 143 144 144 144 145

. . . .

. . . .

. . . .

. . . .

146 147 147 148

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

148 149 149 152 153 155 155 156 157 158

. . . . .

. . . . .

. . . . .

. . . . .

159 159 161 163 166

10 FPGA for SOC Prototyping . . . . . . . . . . . . . . . . 10.1 Xilinx 7 Series FPGA . . . . . . . . . . . . . . . . 10.1.1 Xilinx 7 Series CLB Architecture 10.1.2 Xilinx 7 Series Block RAM . . . . 10.1.3 Xilinx 7 Series DSP . . . . . . . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . .

Contents

xv

10.1.4 Xilinx 7 Series Clocking . . . . . . . . . . . . . . . . . . . 10.1.5 XILINX 7 Series IO . . . . . . . . . . . . . . . . . . . . . . 10.1.6 Xilinx 7 Series Transceivers . . . . . . . . . . . . . . . . 10.1.7 In-Built IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.8 Built-In Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Synthesis and Implementation Flow [2] . . . . . . . . . . . . . . . 10.2.1 How Logic Is Mapped Using CLBs? . . . . . . . . . . 10.2.2 How DSP Blocks Are Mapped? . . . . . . . . . . . . . . 10.2.3 How Memory Blocks Are Mapped Inside FPGA? . 10.3 The Techniques for the Better Optimization . . . . . . . . . . . . 10.3.1 Multipliers and Resource Sharing . . . . . . . . . . . . . 10.3.2 Logic Duplication for the Larger Decoding Logic . 10.4 Strategies for SOC Prototyping . . . . . . . . . . . . . . . . . . . . . 10.5 Important Points to Conclude the Chapter . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

169 170 170 172 173 173 174 175 175 176 176 177 179 180 181

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

183 183 185 186 187 189 190 193 193

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

194 196 198 199

12 SOC Design Synthesis and Implementation . . . . . . . . . . . . . 12.1 Design Partitioning and Goals . . . . . . . . . . . . . . . . . . . 12.2 Challenges in the Design Partitioning . . . . . . . . . . . . . . 12.3 How to Overcome the Partitioning Challenges [1] . . . . . 12.3.1 Architecture Level . . . . . . . . . . . . . . . . . . . . . 12.3.2 Synthesis at Netlist Level [1] . . . . . . . . . . . . . 12.4 Need of the EDA Tools for the Design Partitioning [1] . 12.4.1 Manual Partitioning . . . . . . . . . . . . . . . . . . . . 12.4.2 Automatic Partitioning . . . . . . . . . . . . . . . . . 12.5 Synthesis for the Better Prototype Outcome [1] . . . . . . . 12.5.1 Fast Synthesis for Initial Resource Estimation . 12.5.2 Incremental Synthesis . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

201 202 203 205 205 206 209 209 210 211 211 212

11 Prototyping Using Single and Multiple FPGAs . . . . . . . . . . 11.1 Choosing the Target FPGA . . . . . . . . . . . . . . . . . . . . 11.2 SOC Prototyping Using Single FPGA . . . . . . . . . . . . 11.3 How to Reduce the Risk During the Prototyping? . . . . 11.4 Prototyping Using Multiple FPGAs . . . . . . . . . . . . . . 11.5 Deferred Interconnects . . . . . . . . . . . . . . . . . . . . . . . . 11.6 Onboard Delay Timing [1] . . . . . . . . . . . . . . . . . . . . . 11.7 Strategies and Guidelines for the Efficient Prototyping . 11.7.1 General Guidelines and Project Planning [1] . 11.7.2 IO Planning and Strategies to Minimize Pin Count [1] . . . . . . . . . . . . . . . . . . . . . . . 11.8 IO Planning and Constraints [1] . . . . . . . . . . . . . . . . . 11.9 Important Points to Conclude the Chapter . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xvi

Contents

12.6 12.7 12.8

Constraints and Synthesis for FPGA Designs [1] . IO Pad Synthesis for FPGA . . . . . . . . . . . . . . . . What Care I Should Take During Synthesis and Prototyping? . . . . . . . . . . . . . . . . . . . . . . . . 12.8.1 Avoid Use of Latches . . . . . . . . . . . . . 12.8.2 Avoid Longer Combinational Paths . . . 12.8.3 Avoid the Combinational Loops . . . . . 12.8.4 Use Wrappers . . . . . . . . . . . . . . . . . . . 12.8.5 Memory Modeling . . . . . . . . . . . . . . . 12.8.6 Use of core Generators . . . . . . . . . . . . 12.8.7 Formal Verification . . . . . . . . . . . . . . . 12.8.8 Blocks not Mapping on the FPGA . . . . 12.8.9 Better Architecture Design . . . . . . . . . . 12.8.10 Use Clock Logic at TOP LEVEL . . . . 12.8.11 Bottom-Up Approach . . . . . . . . . . . . . 12.9 Important Points to Conclude the Chapter . . . . . . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . 212 . . . . . . . . . . 217 . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

217 217 217 219 219 220 220 220 220 221 221 221 221 222

13 SOC Debug and Test Scenarios . . . . . . . . . . . . . . . . . . . . . 13.1 SOC Design and Considerations . . . . . . . . . . . . . . . . . 13.2 Prototyping Challenges and How to Overcome Them? 13.3 Multiple FPGA Architecture and Limiting Factors . . . . 13.4 Board Bring-Up and What to Test? . . . . . . . . . . . . . . 13.5 Debug Plan and Checklist . . . . . . . . . . . . . . . . . . . . . 13.5.1 Basic Tests for the FPGA . . . . . . . . . . . . . . 13.5.2 Add-On Board Tests . . . . . . . . . . . . . . . . . . 13.5.3 Test the External Logic Analyzer Buses . . . . 13.5.4 Multiple FPGA Connectivity and IO Test . . . 13.5.5 Test for the Multiple FPGA Partitioning . . . . 13.6 What Are Different Issues on the FPGA Boards . . . . . 13.7 Testing for the Multiple FPGA Interface . . . . . . . . . . . 13.8 Debug Logic and Use of Logic Analyzers . . . . . . . . . 13.8.1 Probing Using IO Pins . . . . . . . . . . . . . . . . 13.8.2 Use the Test MUX . . . . . . . . . . . . . . . . . . . 13.8.3 Use of Logic Analyzer: Practical Scenario (to Detect the Data Packet Is Corrupted) . . . 13.8.4 Oscilloscope to Debug the Design . . . . . . . . 13.8.5 Debugging Using ILA Cores . . . . . . . . . . . . 13.9 System-Level Verification and Debugging . . . . . . . . . 13.9.1 Hardware/Software Co-verification . . . . . . . . 13.9.2 Transactors and Transaction-Level Modeling

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

223 223 225 226 227 227 229 229 229 229 229 230 230 233 233 234

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

234 235 236 238 238 239

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

Contents

xvii

13.10 SOC Prototyping Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 13.11 Important Points to Conclude the Chapter . . . . . . . . . . . . . . . . 240 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Appendix: Xilinx 7 Series Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

About the Author

Vaibbhav Taraate is Entrepreneur and Mentor at “1 Rupee S T”. He holds a B.E. (Electronics) degree from Shivaji University, Kolhapur, in 1995 and secured a gold medal for standing first in all engineering branches. He has completed his M.Tech. (Aerospace Control and Guidance) in 1999 from IIT Bombay. He has over 18 years of experience in semi-custom ASIC and FPGA design, primarily using HDL languages such as Verilog and VHDL. He has worked with few multinational corporations as consultant, senior design engineer, and technical manager. His areas of expertise include RTL design using VHDL, RTL design using Verilog, complex FPGA-based design, low power design, synthesis/optimization, static timing analysis, system design using microprocessors, high-speed VLSI designs, and architecture design of complex SOCs.

xix

Chapter 1

Introduction

“The complexity of ASIC design has grown exponentially in the past 50 years.”

Abstract During this decade, the complexity of the ASIC design has increased substantially. The need of the ASICs in the wireless, automotive, medical, and other high-processing application has grown. The objective of this chapter is to have discussion about the ASICs and the challenges in the ASIC designs. The chapter even discusses the ASIC design flow, process node evolution, and the basics of SOC architecture. The chapter is useful to understand the processes involved in the design of SOC. Keywords ASIC · SOC · ASSP · Standard cell · Gate array · Structured ASIC · Synthesis · IP · Micro · Multitasking · Clock rate · Data rate · Bandwidth The ASIC design for the complex functionality using billion gate logic is the need of this decade. The application areas may be wireless communication, high speed computing or the video processing. In all these areas we need to have the high speed ASIC chips. The prototype using FPGAs for such ASIC or SOC is key to measure the performance and to reduce the re-spin of the ASIC design. In this context the chapter discusses about the ASIC design flow, ASIC prototyping and challenges.

1.1 ASIC Design The Application-Specific Integrated Circuit (ASIC) complexity has grown exponentially in the past two decades. Most of the design companies have started working on the 10 nanometer and 7 nanometer technology nodes. According to the Moore’s law, the number of transistors in dense integrated circuits will double in approximately 18–24 months. Moore’s law has limitation due to the shrinking and the © Springer Nature Singapore Pte Ltd. 2020 V. Taraate, Logic Synthesis and SOC Prototyping, https://doi.org/10.1007/978-981-15-1314-5_1

1

2

1 Introduction

functional complexity of the design. Most of the design companies are facing the real challenges due to shrinking area, low power requirements, and the requirement of high speed. The ASICs are designed for some specific applications, and most of the time, we observe the application of such designs in automobile, communication, high-speed data processing, and even in the defense applications. Application-Specific Integrated Circuit (ASIC) is designed for the specific purpose or application. The ASIC chips are designed using full-custom or semi-custom design flow. The full-custom design starts from the scratch, and required cells are designed and characterized for the specific process node. In case of semi-custom ASIC design, the pre-validated standard cells and libraries are used and the required additional cells are designed and characterized depending on the requirements for the desired process node. The additional required functionality may be the design of standard cells, IPs, and other custom logic. The ASIC design flow is classified as frontend design flow that is logic design and synthesis and backend that is physical design flow. The overall ASIC design cycle starts with the market survey and requirement capture, and the frontend design flow involves the important steps as: design entry using hardware description languages, functional verification of ASIC, synthesis and pre-layout timing analysis. The backend design flow involves the important milestones: floorplan, powerplan, clock tree synthesis, placement, and routing of the design, and finally, the post-layout timing analysis and the testing of the chip. Due to the complex design specifications, it is requirement that the chip architect and design team members should understand the functional specifications at the top level to evolve the strategies for the hardware and software partitioning. The ASIC can be design of processor, video decoders, and chips for complex digital communication algorithms; in all such designs, the understanding of functional specification and evolution of the efficient architecture and micro-architecture documentation plays important and crucial role. The complex SOC architecture can be evolved by understanding of the functional specifications, block level and top level functionality, timing, area and speed requirements. The top-level team of experts is involved in architecture definition for the design. During the design cycle the efficient architecture and micro-architecture document will paly the important role. What the architecture and micro-architecture document describe? The architecture and micro-architecture document should describe following: 1. 2. 3. 4. 5. 6. 7.

Top-level details of functional blocks Block-level details and interfaces Timing requirements Memory requirements Hardware and software partitioning details Area, speed, and power requirements Electrical and mechanical specifications

1.1 ASIC Design

3

8. IP requirements 9. Information about the prototype boards. During the present decade, the SOC design flow has become very complex and involves many teams to complete the milestones such as; processor/IP design, architecture and micro-architecture design, RTL design and verification, synthesis, and timing closure, implementation and testing at system level. The major challenges in such kind of design are listed below, and mainly, they are (1) (2) (3) (4) (5) (6) (7) (8) (9)

Architecture design and system partitioning for the complex functionality Power management to meet the required power constraints Selection of IPs and their timing Full chip verification Required test planning and EDA tools Test verification methodology and board design Deep submicron effect and integration Time to market Advance processes and simulation models.

The SOC which can be used in the mobile communication is shown in Fig. 1.1. It has the video and audio processors, internal storage, general purpose processor

Processor I

Memory

Audio Processor Audio Data Stream

Processor II

Memory Controller

Video Processor Video Data Stream

Network Interfaces

BUS Interface

Fig. 1.1 SOC for multimedia applications

BIST Logic

4

1 Introduction

I, II, internal memory, and memory controllers. Even such kind of chip has BIST logic with other network interfaces. The video and audio data streams are available as separate interfaces. Due to the requirement of the high-density data processing, such kind of ASICs should have parallelism. This can be accomplished by the use of the multiple processor architecture.

1.1.1 Types of ASIC [3] As stated earlier, the chip designed for the specific purpose or application is called as Application-Specific Integrated Circuit (ASIC). Mainly, the ASIC can consists of the multiple processors, the memories and other functional blocks with the high speed interface modules. The chip can have analog or digital blocks. For example, consider the design of the digital communication system consisting of transmitter or receivers. Such kind of chips should have the transmitter and receiver logic and should operate on the digital data. The chip may have one or more than one processor to perform the parallel processing of the data and should meet the required performance criteria. An integrated circuit (IC) is made up of silicon wafer, and each wafer can have thousands of dies. Most of the time, we often come across the term which is Application-Specific Standard Product (ASSP), and they are available in the market by quoting part numbers, for example, the processor chips, video decoders, audio and DSP processing chips. ASICs are primarily classified into following categories, and they are named as: • Full-custom ASIC • Semi-custom ASIC • Gate array ASIC Full-Custom ASIC: The design which has done from the scratch is called as fullcustom ASIC. The design flow of such design includes the design and validation of the required cells or gates. The pre-defined cells are not used in such kind of ASIC. Consider the design scenario where the design specifications are given to the design team with the requirement of the speed, power, and area. If the existing cell does not meet the required performance criteria, then the option is to design the required cells for the target process node. The design cycle in such type of ASIC is longer due to design of standard cells, macros, and validation of them. Semi-Custom ASIC: In such kind of the design, the existing standard cells of logic gates (AND, OR, NOT, and EXOR), MUX, flip-flop, and latch are used. In this, design team uses the standard cell library, where the cells are already pre-designed and pretested. This involves the lesser time to market, lesser investments, and even the low risk as compare to full-custom design. Consider the scenario where the standard cell and macros are pre-designed and validated for the 10-nanometer process node. Now the specifications are given to the design team to design the memory controller

1.1 ASIC Design

5

using 10-nanometer process node. In such kind of scenario, the design team uses the pre-designed, pre-tested standard cell libraries. This reduces design cycle time and the risk during design cycle. The standard cell libraries are designed using the full-custom design flow only, and the standard cells can be individually optimized. Gate Array ASIC: The gate array ASICs are further classified as • Channeled gate array • Channel less gate array • Structured gate array In the gate array ASIC, the design involves the base array and base cell. The base array is the pre-defined required pattern of the transistors on the gate array. The base cell is broadly described as the smallest element in the base array. In such kind of ASICs, the cell layout is same for all the cells but interconnects between the cells and inside of the cell is customized.

1.2 Design Challenges There are many challenges in the complex SOC designs, and most of the ITRS reports describe following important highlights related to the ASIC/SOC physical design: 1. Interconnects and noise at higher frequencies: The real challenges at high frequency are i. ii. iii. iv.

Noise immunity and noise margin Signal integrity and data convergence issues Nonlinearity in the delay variations Cross-coupling of the devices.

2. Power constraints: Due to non-ideal scaling of parasitic and supply or threshold voltage, it really impacts on the power constraints for the design. 3. Interconnect performance and limitation: One of the main challenges is how to scale the performance of interconnect to have the data integrity and convergence. 4. System clock and synchronization: The real requirement for any ASIC or SOC design is to have uniform clock skew. In such scenario, the uniform distribution of clock with required synchronization is the real challenge. International Technology Roadmap for Semiconductors (ITRS) pays much more attentions on the chip-level system design and the design strategies. ITRS assesses the design trends, design technologies, and future development to make the SOC designs more robust. ITRS produces the roadmap with new additions which can be even applied to the billion gate SOC designs. The major objective of ITRS is to produce roadmap for the IC design. The key points in most of the roadmaps by ITRS are the cost of the design, manufacturing cycle time, and the target design technology. For the semiconductor customers, the major challenge is the NRE cost which is of millions of dollars. Few

6

1 Introduction

of the ITRS roadmaps produced in the past decade focus on the reduction in the cost of the design. The main message from such roadmaps is that the NRE cost for mask and testing has reached up to few hundred million dollars during this decade and if due to design specification changes or due to major shortfalls in the design if design respins, then such costs will multiply. Due to the shrinking process technology, the design product life cycle has shorten and due to that the time to market is very critical issue for the semiconductor design and manufacturing companies. If we consider ASIC design, then the design or verification cycle is few months and manufacturing time in few weeks. There are uncertainties in the design and verification but low uncertainty in the chip manufacturing. Under such circumstances, the investments in the process technology have dominated the investments in the design technology. But the important point is that the design cost of the powerefficient ASICs/SOCs during year 2016 was almost around few million dollars versus the hundreds of million dollar investments in the past decade. Still if we consider ASIC applications, they need software and hardware communication; so during this decade, systems are typically of the embedded type. Almost around 70–80% of the cost is invested to develop software for such systems. During this decade, the ASIC test cost has significantly grown and for any complex design, the cost of verification is much more as compare to the design cost! The ITRS assessment and the roadmap are classified into two major verticals. One is the silicon complexity which is related to the physical design of the chip, and other is the system complexity which is related to the system design scenarios and complex functionality. Design and manufacturing companies need to think about all these challenges during the design of lowcost, lowpower ASIC chips. During this decade, we are witnessing the real limitation in shrinking, and doubling of the transistors in dense integrated circuits and it has the significant impact on the overall roadmap for the new processors availability! Apart from these physical design challenges, the system designer needs to think about the cost for the verification and testing, the long verification cycle, the block reuse for the hierarchical designs, hardware and software co-designs, and last but not least, the design/verification team size and the geographical locations.

1.3 ASIC Design Flow To design the ASICs, the product idea or market survey is important milestone. The data available during market survey can be used to finalise the functional specifications and it plays important role. During the market survey, the team can extract following: 1. Available similar kinds of products in market 2. Features of products 3. Electrical specifications and mechanical assembly

1.3 ASIC Design Flow

7

4. Price range of the products 5. Is the product has upgradable features. The functional specifications are useful for the ASIC design team as it gives information about the overall features and the broad application areas (Fig. 1.2). 1. Design specifications: The ASIC specifications include functional, electrical, and mechanical specification and characteristics of the logic and functional blocks. For example, the mobile SOC should have the processor, memory Fig. 1.2 Few important steps in ASIC design

Market Survey

Specification Extraction

Design Architecture & Micro-architecture

RTL Design & Verification

Logic Synthesis & DFT

Pre Layout STA

Physical Design

CHIP

8

1 Introduction

controller, external interfaces, high-resolution camera, high-resolution display, etc. For all the required components, it is essential to have understanding of the speed, latency, throughput, data rate and bandwidth. 2. Architecture design: By using the design specification, the architecture and micro-architecture document can be created. The ASIC design is partitioned into small blocks, and the block-level design with interface details can be documented at the higher level. For example, if ASIC uses processor as one of the functional block then during architecture design milestone the architect team should consider the speed requirements, external interfaces, pipelining, IO throughput. By using these details, the architecture and micro-architecture for the ASIC can be evolved. Although it is time consuming and iterative process, it is one of the major milestones as this document is used throughout the ASIC design cycle. 3. Logic design and synthesis: ASIC logic design involves the design partitioning, RTL design, RTL verification, synthesis, test insertion, and the pre-layout timing analysis. During the pre-layout STA, the goal is to fix up the setup time violations for the various functional blocks. Figure 1.3 gives information about the ASIC logic design at higher level. Fig. 1.3 Important steps in ASIC logic design

RTL Design

RTL Verification

Logic Synthesis

Test Insertion

Pre Layout STA

1.3 ASIC Design Flow

9

1.

Market survey to extract the specification requirement for the ASIC or SOC. The specification can be functional, electrical, and mechanical for the required speed and power. 2. Architecture design: Specification understanding and architectural and micro-architecture for the ASIC or SOC design. The block-level representation for the design with other interface and timing details. 3. Design using HDL: RTL design using HDL (VHDL, Verilog or using SystemVerilog). 4. RTL Verification: Exhaustive dynamic simulation of the design, to verify the functionality of the design. 5. Test insertion, DFT memory BIST insertion, for designs containing memory elements. 6. Environment setting: This includes the technology library to be used, along with other environmental attributes. 7. Design constraints and synthesis: Constraining and synthesis of the design with scan insertion (and optional JTAG) using Design Compiler. 8. Block-level STA: using Design Compiler’s built-in static timing analysis engine. 9. Formal verification: RTL comparison against the synthesized netlist, using Formality. 10. Pre-layout STA: Full chip design STA using PrimeTime. 4. Physical Design Flow: The physical design flow uses the gate-level netlist which is outcome of the logic synthesis, and it is shown in Fig. 1.4. The important steps are documented below: 1.

Forward annotation: Forward annotation of timing constraints to the layout tool. 2. Floorplanning: Initial floorplanning with timing driven placement of cells, clock tree insertion, and global routing. 3. CTS: Transfer of clock tree to the original design (netlist) residing in Design Compiler. 4. IPO: In-place optimization (IPO) of the design in Design Compiler. 5. Formal verification: Verification between the synthesized netlist and clock tree inserted netlist, using Formality. 6. Timing delay extraction: Extraction of estimated timing delays from the layout after the global routing step. 7. Back annotation: Back annotation of estimated timing data from the global routed design, to PrimeTime. 8. STA: Static timing analysis in PrimeTime, using the estimated delays extracted after performing global route. 9. Detailed Routing: Detailed routing of the design. Extraction of real timing delays from the detailed routed design. 10. Back annotate timing data: Back annotation of the real extracted timing data to PrimeTime.

10

1 Introduction

Fig. 1.4 Important steps in the physical design flow

Design Partitioning

Floorplanning

Power planning

CTS

Placement & Routing

Post Layout STA

Tape Out

11. Post-Layout STA: Post-layout static timing analysis using PrimeTime. 12. Post-Layout simulation: Functional gate-level simulation of the design with post-layout timing (if required). 13. Tape out: Tape out after LVS and DRC verification.

1.4 Need of HDL?

11

Table 1.1 Important highlights of C/C++ and HDL Parameters

Programming language (C or C++)

HDL

Instructions or constructs

The language is best suitable for the sequential execution due to the constructs

Supports both the sequential and concurrent constructs

Description style

The main objective to code the functionality of the design. The programmer uses the analytical, logical thinking to develop the behavior model

The description is Register Transfer Level (RTL) and the main objective is to infer the required gate-level structure

Resources and usage

The main intention of programmer is to develop the algorithm, and the programmer never considers the area, speed, and power requirements

The designer needs to consider the resources required, parallelism, and concurrency. Even designer should use the area, power, and speed constraint to achieve the better results

Application

Should be used as programming language to describe the functionality. In other words, it is mixture of assembly and high-level language

Should be used to describe the hardware as it has synthesizable constructs. Due to use of non-synthesizable constructs, this can be also used to verify the design functionality

Time constructs

It does not support the notion of time

It supports the time constructs and the notion of time

Flow constructs

Due to sequential execution it supports the data flow

HDL supports the data and control flow

1.4 Need of HDL? Before the evolution of the hardware description languages (HDLs), the designers had tough time to describe the design using the schematic capture. The C and C++ are high-level languages and used to develop the functional model for the design. Whereas the HDLs are used to describe the hardware. Table 1.1 gives the overview of the C, C++ and HDL. From Table 1.1, it is clear that as C and C++ do not support concurrency, time constructs, and control flow. Hence, we need to use the HDL to describe the hardware.

1.5 Hardware Description Languages To describe the hardware, the popular description languages used in the industry are VHDL, Verilog, and System Verilog. Table 1.2 gives the information about the evolution of HDL with their standard.

12

1 Introduction

Table 1.2 HDL evolution and their standards HDL

Description

Application

Standard

AHDL

Analog hardware description language

Open source and used for analog verification

1980

Verilog-AMS

Verilog for analog and mixed signals

Open standard and used for the mix of digital and analog simulation

Derived from IEEE 1364

VHDL-AMS

VHDL for analog and mixed signals

Standard language for both the analog and digital mixed signal simulation

IEEE 1076.1-2007

VHDL

Very high speed integrated circuits HDL (VHSIC HDL)

Used for the design and verification of digital logic

IEEE 1076-2008

Verilog

Widely used hardware description language

Used for the design and verification of digital logic

IEEE 1364-2005

ABEL

Advanced boolean expression language

Used for the PLD-based design

None

System C

The high-level abstraction language for the hardware designs

It uses the C++ classes for higher-level behavioral and transaction-level modeling (TLM) for describing hardware at system level

IEEE 1666-2011

System Verilog

Superset of Verilog

Used to address the system level design and verification

IEEE 1800-2017

1.6 Hardware Construction and IP Design Chisel is hardware construction language (HCL) developed by UC Berkeley. The main objective of this language is to design hardware using parameterized generators. Few of the important highlights of the language are 1. It is open-source hardware construction language. 2. It has algebraic construction and wiring and embedded in Scala programming language. 3. The main highlight is that it has bulk connections with the abstract data types and interfaces. 4. Used for the hierarchical, object-oriented, and functional constructions. 5. It supports the layering of the domain-specific languages. 6. It is highly parameterized using metaprogramming in Scala. 7. Supports floating point and multiple clock domain designs.

1.6 Hardware Construction and IP Design

13

8. The important highlight is that it generates the Verilog which can be used by the leading FPGA and ASIC tools. Due to the powerful features, the language can be used as hardware construction language, and we can see the growing demand for such language due to shrinking time to market. The discussion on chisel is out of scope in this book.

1.7 ASIC/SOC Design Challenges and Areas The twenty-first century ASIC and SOC design should have the parallel processors as Moore’s law has reached its limitations on the speed of the ASICs and power dissipation. If we perceive the design future, then there will be always challenges in the ASIC and SOC designs due to demands of consumers. Nowadays, every human being is interested in having smartphones, intelligent control appliances, and the gadgets. The fun will be during coming decade when the massive parallelism in the design of the ASICs and SOCs will try to change the design processes and algorithms. There are many challenges which need to be addressed; few of them I have imagined, and they are documented below: 1.

ASICs can be designed for the high bandwidth and reliable communications to meet the requirements of the end customers. 2. Google-like companies can use the ASICs in the quantum computing systems for the speech recognition. 3. Artificial intelligence area will face the challenges due to shrinking process node and those can be overcome by using the parallelism and parallel processing engines. 4. The medical diagnosis field will consume the large number of ASICs, and new SOCs will be evolved with the parallel processors. 5. Text-to-speech synthesis area will evolve using the parallel processor-based SOCs. 6. The automation in the vehicle controls to give more user-friendly controls to the end user will evolve and can be accomplished by the SOC designs. 7. With improved computing and processing power, the SOCs even can be used to control the robots in the hazardous areas with more precision and accuracy. 8. The intelligent sensors, cameras, and scanners to identify the dangerous articles without intervention of human beings can be evolved by using the multi-SOC designs. 9. The automations in the hospitals to monitor the health of the patient from long distance are one of the areas which can evolve using the multi processors and SOCs. 10. As less area, high speed, and less power is the requirement in all kinds of the ASICs and SOCs, we may witness the technology shift and algorithm evolutions to support the massive parallelism during this decade.

14

1 Introduction

1.8 Important Points to Conclude the Chapter As discussed earlier, the following are few important takeaways to conclude the chapter 1. The ASICs are designed for the specific applications and can have analog and digital blocks. 2. The ASICs can be classified as full-custom, semi-custom, and programmable ASICs. 3. For larger density ASIC designs, the design partitioning plays important role to define the interface boundaries. 4. Popular HDLs are VHDL, Verilog, System Verilog, and chisel is Hardware Construction Language(HCL). 5. Architecture and micro-architecture for ASICs is used as reference document throughout the ASIC design cycle. 6. During pre-layout STA, the objective is to fix all the setup time violations. 7. During the post-layout STA, all the timing violations (setup, hold time violations) should be fixed. 8. FPGA can be used to prototype the design. If design has complex features and has larger density, then the multiple FPGA platforms can be used.

In the next chapter we will discuss about the ASIC design and SOC prototype basics and the important challenges. The Chap. 2 also useful to understand about the SOC design flow, design, verification and prototype for SOC designs.

Chapter 2

ASIC Design and SOC Prototyping

“The overall ASIC design and verification cycle consume 80% of the efforts.”

Abstract The chapter discusses the ASIC design concepts, SOC prototyping basics, and the challenges in ASIC/SOC designs. The chapter even discusses important Design Compiler (DC) commands used during the synthesis and design optimization phase. The chapter is useful to understand the basics of SOC prototyping and important challenges during the prototype phase using high-density FPGAs. Keywords FPGA · ASIC · SOC · Prototype · Design compiler · SOC components · Architecture · Micro-architecture · RTL design · Test With reference to the frequently used SOC blocks, the SOC design flow and prototype challenges are discussed in this chapter.

2.1 SOC Design In the current century, the design complexity has grown up due to the need of intelligent products and features. The ASIC/SOC area has emerged in the automotive, consumer, medical, wireless communication and multimedia applications. To design such kind of high density logic, the SOC should consist of the multiple processors, high-speed bus interfaces, memory controllers, and other interfaces. Consider the SOC shown in the Fig. 2.1. It gives information about frequently used blocks. In design of such SOCs, the following points need to be considered. 1. 2. 3. 4.

What is overall speed of the SOC? Is architecture has parallel processing engine? Is there adequate internal memory? What is the overall power requirements?

© Springer Nature Singapore Pte Ltd. 2020 V. Taraate, Logic Synthesis and SOC Prototyping, https://doi.org/10.1007/978-981-15-1314-5_2

15

16

2 ASIC Design and SOC Prototyping

5. 6. 7. 8.

What is the process/technology node and what should be the prototype platform? What are the IP requirements? What are analog, digital components/IPs and EDA tools required? How much time is required to get full-chip design, verification and protoype?

With reference to the SOC architecture shown in Fig. 2.1, the following are few important highlights and should be considered during SOC design and verification phase. 1. Multiple processor architecture: The need is to have parallel processing of the data, and in that context, the SOC should have the multiple processors. The parallelism can improve the speed of overall design. As shown, the SOC uses processor to perform the general-purpose computation and the video processor to perform the processing of high stream video data. While designing such kind of SOCs, the architect team should take care of the speed of buses, bandwidth of overall system, data rate, latency, and throughput. Additonal pipelining features can be incorporated to improve the overall SOC architecture.

USB Interface & Controller

RAM

Processor

Bluetooth

Memory Controller ROM

Timer & Counters

Bus Arbitration and Control

Video Processor External Memory Interface

Fig. 2.1 SOC architecture

SDRAM Interface

High Speed Bus Interface

ADC

DAC

DMA Controller

PLL

Oscillator

2.1 SOC Design

17

2. Memory and memory controller: What is the memory requirement for such kind of design? The internal storage and the external memory interfaces should have the least latency during read and write operations. Depending on the data rate requirements, the memory controllers can be designed. The DDR or SDRAM controller or NAND flash they can be designed or their IPs can be used to achieve the better prototype. 3. Serial interfaces: What are the serial interfaces required and what should be their speed? Most of the time, we need to have the I2C, SPI, UART for the serial communication. 4. High-speed interfaces: If the SOC has the USB and Bluetooth, then what should be standard and what are the challenges during integration is another important point to discuss while evolving the architecture. 5. DMA controller: For the direct memory access without involving the processor, what should be the design strategy? What kind of bus interfaces is required and what is the speed of data transfer? That should be thought during the architecture evolution phase! 6. Analog blocks: For the analog interfaces, the SOC should have the ADCs and DACs. The architect needs to consider about the sampling rate of ADC, conversion time, resolution of DAC, and linearity. 7. Clocking resources: The in-built oscillators and PLLs can be used to generate the clocks with the uniform clock skew and can be used as clock source for the multiple clock domain SOC design components. Apart from the above, the electrical characteristics and speed, power, area should be considered during SOC architecture design phase. The extraction of the blocklevel and top-level constraints for the required technology library should be done during the evolution of the architecture of SOC. The next few sections are used to know more about the SOC design flow and important milestones.

2.2 SOC Design Flow With the evolution of VLSI design technology, the ASIC or SOC designs are becoming more and more complex and SOC-based design is feasible in shorter design cycle time. The demand of the customers to deliver product in the shorter design cycle time is possible by using efficient design flow. The design needs to be evolved from specification stage to final layout. The use of EDA tools with the suitable features has made it possible to have the bug-free designs with proven functionality. The design flow is shown in Fig. 2.2, and it consists of the following important milestones.

18

2 ASIC Design and SOC Prototyping

Fig. 2.2 SOC design flow

Market Survey

SOC Specifications & Architecture Design

RTL Design and Verification

Synthesis and Timing Verification

Physical Design and Verification

Prototype & Test

2.2.1 Design Specifications and System Architecture Extracting the design functional specifications for the ASIC or ASSP is important phase, and during this phase, the extensive market research should be done to freeze the functional specifications of the design. Consider the mobile SOC; then, few important functional specification can be, speed of processor, functional specification of processor, internal memory, display and its resolution, camera and resolution of camera, external communication interfaces, etc. More than this, it is essential to have information about the mechanical assembly and other electrical characteristics of the device. They may be power supply requirements and battery charging circuit and safety features. The specifications are used to sketch the top-level floorplan of the chip which we can call as architecture of mobile SOC. Even the important parameters are environmental constraints and the design constraints. The key design constraints are area, speed, and power. Sketching architecture of any billion gate SOC is one of the difficult tasks as it involves the real imagination and understanding of the inter-dependability between

2.2 SOC Design Flow

19

the hardware and software. To avoid the overheads on the single processor, the design may need to have more processors to perform the multitasking. The architecture document is always evolved from the design specifications, and it is block-level representation of the overall design. The team of experienced professional can create such type of document, and this can be used as reference to sketch the micro-architecture of the design. The micro-architecture document is the lower-level abstraction of the architecture documents, and it gives information about the functionality of every block with their interface and timing information. At higher level we can consider this document as sub-block level representation for the block level design. Even this document should give information about the IPs in the design their timing and interface details. The architecture design for SOC and micro-architecture evolution for SOC is discussed in the next subsequent chapter.

2.2.2 RTL Design and Functional Verification For the complex SOC designs, the micro-architecture document is used as a reference by the design team. The billion gate SOC design is partitioned into multiple blocks and the team of hundreds of engineers work to implement the design and to perform the verification. RTL design team uses the recommended design and coding guidelines during the RTL design phase. An efficient RTL design always plays important role during implementation cycle. During the RTL design phase, the group members describes the block-level and top-level functionality using an efficient Verilog ,SystemVerilog or VHDL constructs. After completion of an efficient RTL design phase for the given design specifications, the design functionality is verified by using industry standard simulator. Pre-synthesis simulation is without any delays, and during this, the focus is to verify the functionality of design. But common practice in the industry is to verify the functionality by writing the testbenches. The testbench forces the stimulus of signals to the design and monitors the output from the design. In the present scenario, automation in the verification flow and new verification methodologies has evolved and used to verify the complex design functionality in the shorter span of time using the proper resources. The role of verification engineer is to test the functional mismatches between the expected output and actual output. If functional mismatch is found during verification, then it needs to be rectified before moving to the synthesis step. Functional verification is iterative process unless and until design meets the required functionality. For the complex functionality SOC or ASIC verification; the automation using multiple testbenches and verification planning need to be considered to achieve the desired coverage goals!

20

2 ASIC Design and SOC Prototyping

2.2.3 Synthesis and Timing Verification When the functional requirements of the design are met, the next step is to perform the block and top level synthesis. Synthesis tool uses the RTL design, design constraints, and libraries as inputs and generates the gate-level netlist as an output. Synthesis is iterative process until the design constraints are met. The primary design constraints are area, speed, and power. If the design constraints are not met, then the synthesis tool performs more optimization on the RTL design. After the optimization if it has observed that the constraints are not met, then it becomes compulsory to modify RTL code or tweak the micro-architecture. The synthesis tool generates the area, speed, and power reports and gate-level netlist as an output. The timing verification should be carried out for the gate-level netlist, and this phase is useful to find the pre-synthesis and post-synthesis simulation mismatches. The pre-layout timing analysis is also important phase to fix the setup violations in the design. The hold violations can be fixed during later stage of the design cycle during post-layout timing analysis.

2.2.4 Physical Design and Verification It involves the floorplanning of design, power planning, place and route, clock tree synthesis, post-layout verification, static timing analysis, and generation of GDSII for an ASIC design.

2.2.5 Prototype and Test During this phase, the design prototype using FPGA can be validated and tested to understand whether the design features are covered or not? This phase is timeconsuming milestone, and before chip fabrication, the extensive testing needs to be carried out to check for the functionality and desired outcome.

2.3 SOC Prototyping and Challenges In the present decade, Xilinx, Intel-FPGA and other vendors have powerful FPGA architecture and the FPGAs are used for the emulation and prototyping. The following are few reasons for the use of modern high-density FPGAs for the prototyping 1. The FPGA with the high-speed architecture can have unmatched execution performance during emulation and prototyping.

2.3 SOC Prototyping and Challenges

21

2. FPGA boards can be used as emulators, so the solutions are cost effective. If we consider the ASIC, then the commercial testing is very expensive as compared to FPGA. 3. Finding out the desired and required goals using simulation can work for the small gate count designs, but for the complex designs the robust verification using application software can be the best choice. 4. The emulation and prototyping phase reduces the risk for ASICs as overall turnaround time is shorter. Still in the practical environment, there can be multiple challenges in the emulation and prototyping using high-density FPGAs. Few of the key challenges are listed in the following section 1. Multiple FPGA Architecture: Most of the high-density SOCs need to be prototyped using multiple FPGA. The architecture of the FPGA is vendor specific and even the EDA tool support is vendor specific and may not be effective always. The real quality of the partitioning the design into multiple FPGA determines the emulation performance. Another important point is the cost effectiveness and need of the manpower during the prototyping. Real work needs to be in the area of efficient design partitioning for the better performance using the available FPGA interfaces. 2. RTL design for ASIC versus FPGA: The RTL coded for the ASIC does not map easily on the targeted FPGA. The main reasons are a. There is often difference between the operating frequencies of the FPGA and ASIC. b. The clocking architecture and initialization logic are the real bottleneck. c. IO interfaces and memory technology for the ASIC and FPGA may have different architecture. Consider the flash which is used in the ASIC design, but FPGA uses the DRAM. d. The bus models are different for the ASIC and FPGA. If we compare ASIC versus FPGA, then we can say that no tristate logic inside FPGA. e. For the ASIC, we need to have the features like debug, controllability, and observability, and they lack in the FPGA flow. So during the RTL design phase, it is always better practice to describe the RTL design for ASIC as well as FPGA. 3. Co-verification and use of IPs: The major challenge is the availability of the IPs in suitable form. Most of the time, the IPs are not available in the suitable RTL form. Even to achieve the desired speed, it is requirement that the FPGA interfaces to the simulators or C/C++ models should be design friendly and the availability of such interfaces having the high bandwidth is real bottleneck. Even there is need to understand about the custom interfaces and other communication models for the third-party IPs. 4. IO bottlenecks: The emulation speed is limited due to the available IOs and interfaces of the FPGA. The real bottleneck due to IO speed is during the collection

22

2 ASIC Design and SOC Prototyping

of large chunk of data while performing the functional simulation. Even while applying the stimuli, it is essential to consider the speed of IOs and interfaces. 5. Partitioning: If the SOCs are partitioned in the better way, then also the communication between the hardware and software using IO interfaces is the real challenge. Bit-stream generation while programming the multiple FPGA environments is time-consuming task, and for the recompilation, it may take hours. 6. In-circuit emulation: In-circuit or in-environment emulation is one of the challenges. Due to the involvement of other system in the environment, achieving the real-time performance is the bottleneck if the emulated speed is lesser than the target operational speed. Consider the real practical scenario where Ethernet needs to work at speed of 100 Mbps then while prototyping if the 100 Mbps Ethernet is clocked at 1/10th of the clock rate then the desired speed can be achieved in the practical system. 7. Clocking and reset network: Another challenge is the clock and reset network as they are different in the actual system and emulated system.

2.4 ASIC Prototyping FPGA is the best candidate for the ASIC or SOC prototyping. ASIC is an ApplicationSpecific Integrated Circuit, FPGA is field-programmable gate array, and SOC is System On Chip. During this decade, the density of the SOC is very higher as compared to the ASIC chips. If we consider this decade, then the high-density FPGAs from Xilinx and Intel are available with required features. The main features can be dedicated memory controllers, high-speed processor cores, high-speed bus interfaces, etc. The main objective of the prototype team is to validate the firmware, software, and hardware of SOC using high-density FPGAs. ASIC prototyping is useful to reduce the delivery time, budget, and the market targets. For high-density SOC designs, the proof of concept in lesser time and cost can be targeted by using the FPGAs. As the process node shrunk to 14 nanometers, the complexity of design, the design risk, and the development time have increased. The main challenge for every organization is to develop the lower-cost products with more functionality in small silicon area. In such scenario, the designers are facing the development and verification challenges. Under such circumstances, the high-end FPGAs can be used to prototype the ASIC functionality and it reduces the overall risk. The functionally verified and completely tested design on high-end FPGAs can be resynthesized for the standard cell ASIC by using the same RTL, constraints, and scripts. There are many EDA tools available to port an FPGA prototype on structured ASICs. This really reduces the overall risk in ASIC design and saves money and time to market for the product. The following are key advantages of ASIC prototyping using FPGAs

2.4 ASIC Prototyping

23

1. Investments: The shrinking process node and chip geometries involve the investment in millions of dollars in the early stage of design. Using FPGAs, the investment risk reduces. 2. Risks: Due to uncontrolled market conditions, there is risk involved in the design and development of products. FPGA prototype reduces such risk as the product specifications, and design can be validated depending on the functional requirements or changes. 3. Ease to test: FPGA prototyping is efficient as the bugs those were not detected in simulation can be addressed and covered during prototyping. 4. System testing and verification: Full-system verification using FPGA prototype can detect the functional bugs in the early design cycle. 5. Manufacturing cost: FPGA prototyping saves the millions of dollar of EDA tool cost and even it saves the millions of dollar of engineering efforts before ASIC tape-out. 6. Time to market: As design using FPGA can be migrated using the EDA tool chains onto the ASICs, it saves the time to market the product with intended functionality. 7. IP validation and integration: Multiple IPs can be integrated, and design functionality can be verified and tested and that can speed up the design cycle. 8. Design partitioning: Most of the cases, the hardware–software portioning is visualized at higher abstraction level. The hardware software co-design can be evaluated at the hardware level, and it is more important milestone in overall design cycle. So the ASIC prototyping can be useful in tweaking of the architecture. If there is additional design overhead in the hardware, then the design architecture can be changed by pushing few blocks in software and vice versa. This will give the more efficient SOC architecture and design. Table 2.1 gives information about the pros and cons of FPGA and ASIC. There is always confusion between the prototype and migration. The ASIC prototyping is basically the design or validation of idea to check for the early functional and feasibility of product idea or design. The design migration from ASIC to FPGA involves the flow from RTL design to implementation and may be useful in the upgradation of design with additional features. The following are the important points need to be considered during ASIC prototyping and design migration using high-end FPGA. 1. Prototype boards: Use the universal prototype board as it saves the time of almost four months to twelve months for the high-speed prototyping board design and development. 2. FPGA selection: Choose the FPGA device depending on the functionality and gate count. It is not possible to fit whole ASIC onto single FPGA fabric even if we use the high-end families of Altera or Xilinx FPGAs. So the practical solution is the use of multiple FPGAs. But the real issue is the design partitioning and the inter-communication between multiple FPGAs. If the design is well defined and partitioned properly, then the manual partitioning into multiple FPGA can give the efficient results. If the design is big and has complex functionality, then the

24

2 ASIC Design and SOC Prototyping

Table 2.1 Comparison of FPGA vs ASIC implementation FPGA

Hard copy

Structured ASIC

Standard cell ASIC

NRE, mask, and EDA tools

Up to a few thousand US$, so the overall cost is low

Couple of hundred thousand US$ for FPGA conversion and masks. So the overall cost is moderate

A couple of hundred thousand US$ for interconnect/metal one masks so the overall cost is moderate

A million US$ depending on the design functionality. So the cost is high

Unit price

High

Medium–low

Medium–low

Low

Time to volume

Immediate

Almost around 8–10 weeks. The additional conversion time may require for other structured ASIC products

Almost around 8–10 weeks. The additional conversion time may require for other structured ASIC products

Almost around 18 weeks + conversion time of another 18 weeks

Engineering resources and cost

Minimum

Minimal from developers but other structured products may require the additional engineering resources

Nominal but for the other structured ASIC products may require the additional engagement of the resources

High as most of the work requires the development from scratch and requires good support from backend team

FPGA prototype correlation

Same device

For hard copy structured ASIC: nearly identical, same logic elements, process, analog components, and packages

It depends upon the type of IP used and the functionality. Same RTL but potentially different libraries, process, analog, and packages

Same RTL but potentially different libraries, process, analog, and packages

use of automatic partitioning can play important role and can create the efficient prototype. 3. ASIC versus FPGA resources: As the design library for ASIC and FPGA is totally different, the key challenge is to map the primitives. So it is essential to map the directly instantiated primitives during synthesis or during the implementation level that is post-synthesis, all the primitives from ASIC library need to be remapped for getting the FPGA prototype. 4. Required IOs: High-end FPGA may have 1000–1500 pins, and if single FPGA is used for prototype, then there is no any issue. But if IO pins required more than the pins available in one FPGA, then the real issue is due to FPGA interfaces and connectivity. The issue can be resolved by using the partitioning with the

2.4 ASIC Prototyping

25

signal and IO multiplexing. This will ensure the efficient design partitioning and efficient design prototype. 5. Single versus multiple clock domain designs: Implementation of single clock domain design prototype is easy using FPGAs. But if the design has more than one clock that is multiple clock domains, then it is quite challenging to use the clock gating and other clock generation techniques during prototype. So the migration of ASIC design into FPGA needs more efforts and sophisticated solutions. One of the efficient solutions is to convert the designs into smaller design units clocked by the global clock source. 6. Memory requirements and models: The memory models used in the FPGA are different as compared to ASIC. So it is essential to use the proper strategy during memory mapping. Most of the time, the synthesized memory models required are not available. Under such scenario, the best possible solution is to use the prototyping board with the required specific memory device. 7. Functional Test and Debug: The full functional testing and debugging are one of the main challenges in the ASIC prototyping. During this phase, it is essential to use the debugging platform which can give the visibility of the results like speed and functional testing results. The ASIC prototyping is achieved by using industry standard leading tools like Design Compiler FPGA. The EDA tool is available for ASIC prototyping using high-end FPGA. The design compiler is industries leading EDA tool use to get best optimal synthesis result and best timing for the FPGA synthesis. The basic flow for the ASIC prototyping is shown in Fig. 2.3, and in the subsequent chapters, we will discuss the ASIC prototyping key steps and how we can achieve the efficient ASIC prototype.

2.5 Important Design Compiler (DC) Commands Few of the important DC commands are used during the compilation and optimization and documented in this section (Table 2.2).

2.6 Important Points to Conclude the Chapter 1. ASIC and SOC prototype can be achieved by using the high density FPGAs. In the present decade, the FPGAs are widely used for prototyping and emulation. 2. The main objective of FPGA prototyping is to have quick turnaround of ideas with lesser cost.

26

2 ASIC Design and SOC Prototyping

Fig. 2.3 ASIC prototype flow

3. The high-end FPGAs from Xilinx, Intel-FPGA consist of the processor cores, memory controllers and other high-speed interfaces and can be used for the SOC prototype. 4. The design specifications and architecture of SOC play important role during ASIC, SOC design, and prototyping. 5. The SOC architecture should support high-speed interfaces, multiprocessing, and IOs with high bandwidth. 6. The SOC prototype team can use the functional and timing proven IPs during SOC design and prototype.

Define the clock skew for the design

create_clock–name -period

set_clock_skew–rise_delay

Used to prevent the optimization of the mapped gates

set_clock_uncertanity

set_dont_touch

To define the estimated network skew

set_multicycle_path–hold -from [get_cells]–to [get_cells[

To define the estimated source and network latency

To push the hold for the design having multicycle path

set_multicycle_path– setup -from [get_cells]–to [get_cells[

Define the estimated clock skew

To push the setup for the design having multicycle path

set_false_path–from [get_ports ]–to get_ports ]

set_clock_transition

To set the false path

write–format output

set_clock_latency

To compile with the low, medium, or high map effort level To save the output generated by the synthesis tool

compile–map_effort

To set the input port delay

Create the clock for the design

check_design

To set the output port delay

To check the design problems like shorts, open, multiple connection, instantiations with no connections

elaborate–format

set_output_delay–clock

Used to elaborate the design

analyze–format

set_input_delay–clock

Read the design Analyze the design for the syntax errors and translation before building the generic logic

read-format

Description

Command

Table 2.2 Important design compiler commands [1]

2.6 Important Points to Conclude the Chapter 27

28

2 ASIC Design and SOC Prototyping

7. The ASIC and FPGA netlist differ in many ways, and during SOC prototype, it is essential to have FPGA equivalent of memories, gated clocks, and other custom logic.

This chapter has given us understanding of the basics of SOC architecture, SOC design flow, and challenges during protoype. The next chapter will focus on the RTL design using VHDL and frequently used RTL design guidelines.

Reference 1. www.synopsys.com.

Chapter 3

Design Using VHDL and Guidelines

“For efficient design the design team members should follow the design guidelines.”

Abstract The main focus of this chapter is to have discussion on the important design guidelines which need to be followed during the RTL design cycle. Every organization has their own standards and guidelines and should be used during the design cycle for the efficient design outcome. In such scenario, the chapter describes the dos and don’ts during RTL design, VHDL important design constructs, and the logic inferred using the RTL schematic. Keywords RTL · VHDL · If-then-else · Case · Nested if-then-else · Process · Sensitivity list · Empty sensitivity · Grouping · Parallel logic · Priority logic · Multiple clock domain designs · Level synchronizer · Resource sharing · Clock gating · Clock enables · Synthesis

3.1 RTL Design Guidelines Following are the guidelines used during the RTL design cycle 1. 2.

3. 4. 5. 6.

Avoid the combinational loops in the design. To avoid the simulation and synthesis mismatches, use complete list of required inputs, temporary variables and signals while using process block. In simple words use the complete sensitivity list while using the procedural blocks! Remove the potential unintentional latches by using the ‘when others’ in the case construct or by using all the case conditions in the case constructs. Try to cover all the else conditions as missing else can infer the latches in the design. If the intention is to design the priority logic, then use the nested if-then-else construct. To infer the parallel logic, use the case construct.

© Springer Nature Singapore Pte Ltd. 2020 V. Taraate, Logic Synthesis and SOC Prototyping, https://doi.org/10.1007/978-981-15-1314-5_3

29

30

3 Design Using VHDL and Guidelines

7. 8. 9. 10. 11.

12. 13. 14. 15.

To avoid the glitches in the design, use the one-hot encoding FSMs. Do not implement the FSM with the combination of the latches and registers. Initialize unused FSM states using reset or by using the when others. Use the seperate process block for the next state, state register, and output logic. For Moore machines, use process (current_state) for the output logic block, and for the mealy machine, use the process (current_state, inputs) for the output logic. Do not make the assignments to the same variable or output in the multiple process blocks. Use the separate process block for the each functional modules triggered on the different clocks. Create the separate design for the multiflop level or pulse synchronizer and instantiate them while passing the data between two clock domains. Try to have the RTL design vendor independent by using the inference.

3.2 RTL Design Practical Scenarios The following section discusses the important RTL design scenarios and the RTL tweaks to improve the performance of the design. Few of the techniques like grouping and resource sharing are discussed in this chapter. For more details about the performance improvement at RTL and synthesis stage, refer to the next few chapters.

3.2.1 Incomplete Sensitivity List The incomplete sensitivity list infers the unintentional latches. The synthesis tool ignores the sensitivity list and infers the combinational logic as XOR gate for the Examples 1, 2, 3. Example 1: VHDL Description Using Complete Sensitivity List library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; entity comb_logic is port ( a_in, b_in : in std_logic; y_out : out std_logic); end comb_logic; architecture arch_comb_logic of comb_logic is

3.2 RTL Design Practical Scenarios

31

begin -- process sensitive to inputs a_in and b_in

process ( a_in, b_in) begin y_out