An Agile Approach to Building Risc-V Microprocessors

................................................................................................................................................................................................................. AN AGILE APPROACH TO BUILDING RISC-V MICROPROCESSORS ................................................................................................................................................................................................................. THE AUTHORS ADOPTED AN AGILE HARDWARE DEVELOPMENT METHODOLOGY FOR 11 Yunsup Lee RISC-V MICROPROCESSOR TAPE-OUTS ON 28-NM AND 45-NM CMOS PROCESSES.THIS Andrew Waterman ENABLED SMALL TEAMS TO QUICKLY BUILD ENERGY-EFFICIENT, COST-EFFECTIVE, AND Henry Cook COMPETITIVE HIGH-PERFORMANCE MICROPROCESSORS.THE AUTHORS PRESENT A CASE Brian Zimmer STUDY OF ONE PROTOTYPE FEATURING A RISC-V VECTOR MICROPROCESSOR INTEGRATED Ben Keller WITH SWITCHED-CAPACITOR DC–DC CONVERTERS AND AN ADAPTIVE CLOCK GENERATOR Alberto Puggelli IN A 28-NM, FULLY DEPLETED SILICON-ON-INSULATOR PROCESS. Jaehwa Kwak ......The era of rapid transistor per- in software development, demarcated by the Ruzica Jevtic´ formance improvement is coming to an end, publication of The Agile Manifesto in 2001.1 increasing pressure on architects and circuit The philosophy of agile software development Stevo Bailey designers to improve energy efficiency. Mod- emphasizes individuals and interactions over ern systems on chip (SoCs) incorporate a large processes and tools, working software over Milovan Blagojevic´ and growing number of specialized hardware comprehensive documentation, customer col- units to execute specific tasks efficiently, often laboration over contract negotiation, and Pi-Feng Chiu organized into multiple dynamic voltage and responding to change over following a plan. clock frequency domains to further save In practice, the agile approach leads to small Rimas Avizienis energy under varying computational loads. teams iteratively refining a set of working-but- This growing complexity has led to a design incomplete prototypes until the end result is Brian Richards productivity crisis, stimulating development acceptable. of new tools and methodologies to enable the Inspired by the positive disruption of The Jonathan Bachrach completion of complex chip designs on sched- Agile Manifesto on software development, we ule and within budget. propose a set of principles to guide a new David Patterson We propose leveraging lessons learned agile hardware development methodology. from the software world by applying aspects Our proposal is informed by our experiences Elad Alon of the software agile development model to as a small group of researchers designing and hardware. Traditionally, software was devel- fabricating 11 processor chips in five years. Borivoje Nikolic´ oped via the waterfall development model, a Lacking the massive resources of industrial sequential process that consists of distinct design teams, we were forced to abandon Krste Asanovic´ phases that rigidly follow one another, just as standard industry practices and explore differ- is done for hardware design today. Over- ent approaches to hardware design. We detail budget, late, and abandoned software projects this approach’s benefits with a case study of were commonplace, motivating a revolution one of these chips, Raven-3, which achieved ....................................................... 8 Published by the IEEE Computer Society 0272-1732/16/$33.00 c 2016 IEEE groundbreaking energy efficiency by integrat- transfer level (RTL) freezes, and CPU centu- ing a novel RISC-V vector architecture with ries of simulations in an attempt to achieve a efficient on-chip DC–DC converters. Taken single viable design point. In our agile hard- together, our experiences developing these aca- ware methodology, we first push a trivial pro- demic prototype chips make a powerful argu- totype with a minimal working feature set all ment for the promise of agile hardware design the way through the toolflow to a point where in the post-Moore’s law era. it could be taped out for fabrication. We refer to this tape-out-ready design as a tape-in. An Agile Hardware Manifesto Then we begin adding features iteratively, moving from one fabricatable tape-in to the Borrowing heavily from the agile software next as we add features. The agile hardware development manifesto, we propose the fol- methodology will always have an available lowing principles for hardware design: tape-outcandidatewithsomesubsetoffea- Incomplete, fabricatable prototypes tures for any tape-out deadline, whereas the over fully featured models. conventional waterfall approach is in danger Collaborative, flexible teams over rigid of grossly overshooting any tape-out deadline silos. because of issues at any stage of the process. Improvement of tools and generators Although the agile methodology provides over improvement of the instance. some benefits in terms of verification effort, it Response to change over following a particularly shines at validation; agile designs plan. aremorelikelytomeetenergyandperform- ance expectations using the iterative process. Here, we explain the importance of these Unlike conventional approaches that use principles for building hardware and contrast high-level architectural models of the whole them with the original principles of agile soft- design for validation with the intent to later ware development. refine these models into an implementation, we emphasize validation using a full RTL Incomplete, Fabricatable Prototypes over Fully implementation of each incomplete prototype Featured Models with the intent to add features if there is time. We believe the primary benefit of adopting Unlike high-level architectural models, the the agile model for hardware design is that it actual RTL is guaranteed to be cycle accurate. lets us drastically reduce the cost of verifica- Furthermore, the actual RTL design can be tion and validation by iterating through pushed through the entire very large-scale many working prototypes of our designs. In integration (VLSI) toolflow to give early feed- this article, we use the standard definition of back on back-end physical design issues that verification as testing that determines whether will affect the quality of results (QoR), includ- each component and the assembly of compo- ing cycle time, area, and power. For example, nents correctly meets its specification (“Are Figure 1b shows a feature F1 being reworked we building the thing right?”). In hardware into feature F10 after validation showed that it design, the term validation is usually nar- would not meet performance or QoR goals, rowly applied to postsilicon testing to ensure whereas feature F3 was dropped after valida- that manufactured parts operate within tion showed that it exceeded physical design design parameters. We use the broader and, budgets or did not add sufficient value to the to our minds, more useful definition of vali- end system. These decisions on F1 and F3 can dation from the software world, in which val- be informed by the results of the attempted idation ensures that the product serves its physical design before completing the final intended purposes (“Are we building the feature F4. right thing?”). Figure 1c illustrates our iterative approach Figure 1 contrasts the agile hardware de- to validation of a single prototype. Each velopment model with the waterfall model. circle’s circumference represents the relative The waterfall model, shown in Figure 1a, time and effort it takes to begin validating a relies on Gantt charts, high-level architecture design using a particular methodology. models, rigid processes such as register- Although the latency and cost of these ............................................................. MARCH/APRIL 2016 9 .............................................................................................................................................................................................. HOT CHIPS F1 F1 F2 F3 F4 F2 Specification F1F2 F1’ F3 F4 F3 Design F1F2 F1’ F3 F4 F4 Implementation F1F2 F1’ F3 F4 Design Tape-out Validation Verification Specification Verification F1F2 F1’ F3 F4 Implementation Tape-in F1/F2 F1’/F2/F3 F1’/F2/F4 Validation F1/F2 F1’/F2/F3 F1’/F2/F4 Tape-out F1’/F2/F4 (a) (b) Big tape-out Small tape-out Tape-in ASIC flow FPGA C++ Specification + design + implementation (c) Figure 1. Contrasting the agile and waterfall models of hardware design. The labels FN represent various desired features of the design. (a) The waterfall model steps all features through each activity sequentially, producing a tape-out candidate only when all features are complete. (b) The agile model adds features incrementally, resulting in incremental tape-out candidates as individual features are completed, reworked, or abandoned. (c) As validation progresses, designs are subjected to lengthier and more accurate evaluation methodologies. prototype-modeling efforts increase toward Collaborative, Flexible Teams over Rigid Silos the outer circles, our confidence in the valida- Traditional hardware design teams usually tion results produced increases in tandem. are organized around the waterfall model, Using fabricatable prototypes increases valida- with engineers assigned to particular func- tion bandwidth, because a complete RTL tions, such as architecture specification, design can be mapped to field-programmable microarchitecture design, RTL design, veri- gate arrays (FPGAs) to run end-application fication, physical design, and validation. software stacks

Load more