Agile Development of Custom Hardware

It was back in 2016 that I first heard about RISC-V, and the Raven implementation, and the Chisel hardware design language that Berkeley had developed. See my post A Raven Has Landed—RISC-V and Chisel. The thing that was most impressive was that a team of a few students had designed a fully functional microprocessor in a semester. Chisel was originally invented out of necessity. Cal has very few chip design engineers but an almost inexhaustible number of CS students. So they created a hardware design methodology suitable for people who knew software, but didn't know much about hardware design. In some ways, it is reminiscent of the Mead & Conway revolution of the early 1980s, when computer scientists (including me) first invaded what had been the territory of electrical engineers and device physicists.

Earlier still, in 2001, a group of software engineers produced Manifesto for Agile Software Development. This has been incredibly influential, and "Agile" is probably the dominant software development methodology today, especially in internet startups. Unlike the traditional software development methodology, knowns as "Waterfall", Agile focuses on getting something, anything working, exposing it to users and then iterating. In effect, the specification and the implementation are generated in parallel, although even that exaggerates things since it implies the specification gets written down. By contrast, Waterfall produces a detailed specification, and then the implementation takes that spec and builds it. The Manifesto has been translated into a lot of languages. I challenge you to even know what all the languages are. Just a few are in the image on the left.

Borivoje Nikolić

At CDNLive Silicon Valley, on the academic track, Borivoje Nikolić of UC Berkeley presented on Agile Development of Custom Hardware.

The big problem with chip design today is that development costs have got out of hand. I am not sure I entirely believe Handel Jones' number of $300M that Borivoje used, but that might be correct for a next-generation NVIDIA GPU or an Apple Ax application processor. Even if the chips cost just $5 to manufacture, and 60M units are shipped, that is a total cost of $600M. To be profitable, that means a market of $1B or more. The economics work for the really big markets. The challenge is that there just aren't that many markets that big. But it takes a market that big to support a design cost that big. "Manufacturing cost is not a big problem, design cost needs to be cut."

Berkeley has designed lots of chips, but even a well-resourced university is not going to be spending 9-digit budgets on chip design. The timeline below shows the latest chips, going back to the Raven-1 which, I believe, was the first RISC-V implementation.

These chips were developed over roughly the last 5 years. As someone at Cadence remarked to Borivoje, "This is way too many chips for the size of design team you have. How do you do it?"

The big problem is the dearth of re-use. There is lots of IP out there, but it is hard to extend or modify. The key insight in Chisel is not to deliver instances of IP, but instead capture the designer knowledge in generators. This is an especial problem in a university setting, since graduates graduate and are gone—that's the point of a university—but it makes what they leave behind even harder to re-use.

CHISEL: Construction of Hardware in Scala Embedded Language

Scala is a high-level programming language. It combines object-orientation and functional program, and runs on top of a Java JVM. It did not originate in Berkely, but in EPFL (École Polytechnique Fédérale de Lausanne), starting back in 2001.

Borivoje said "we don't even teach C at Berkeley anymore". I think that might be an exaggeration since the daughter of a friend of mine graduated at the end of last year and has done her share of "curly bracket languages". But even so "kids' productivity rockets when they switch to Scala." The idea is to write hardware as a generator, and then run the code to write out the instance. Note that this is still at an RTL level of abstraction. This is not high-level synthesis (with scheduling, allocation etc in the tool). It is just a higher software abstraction level, but still clocked. Another big advantage is that there are lots of existing software libraries that can be used.

They also borrowed the idea of a flexible intermediate representation from compilers. Chisel creates FIRRTL (pronounced like "purple") and stands for "flexible intermediate representation for RTL." This allows transformations to be done on the FIRRTL itself, such as SRAM insertion, dead-code elimination, and about 30 more. Berkeley is not alone, there are other contributors to the project such as Intel and Google.

We all know that verification costs just as much as design (actually more). So generating the designs is not enough, the verification environment and tests need to be created too.

The generator-based flow is shown above. The underlying base is Cadence tools, from the point that RTL and UVM exists. All the familiar Cadence tool names are there.

Analog

This approach doesn't work directly from analog, since analog is inherently a lot more iterative (do a design, simulate it, adjust the design, rinse and repeat). Once again the key is to make things more reusable. "Cadence analog IP is great, but if you don't get just what you want, good luck changing it."

The analog generator is called BAG (Berkeley Analog Generator). Once again the idea is not that the designer delivers an instance that meets the spec, but rather to capture their knowledge in an executable generator. This makes use easier by parameterization and by extension (of the generator). It is a Python-based framework that "takes care of the plumbing." BAG's Python scripts interact directly with the user's Virtuoso instance.

Modern advanced processes mean that even custom and analog layouts have to be template- and grid-based. BAG actually exploits this to improve portability via a high-level API that enforces a layer-by-layer grid. For human designers, this is very tricky to deal with—the reality is that for complex designs, computers are better iterators than humans.

BAG has two primitive engines under the hood: XBase and Laygo. Xbase are programmable primitives in the styles of common physical layout floorplans. Laygo are hand-drawn primitives, but they are easier to customize.

This approach works really well for porting too. For example, here is the same ADC generator used on several different processes:

Future

They are not done yet. They are working on generators for multiprocessors, radar, SoCs, SerDes, data converters, PLLs, RF receiver and transmitter and more. Plus, as with any sotware ecosystem, there is a virtuous circle since opportunities for re-use increase as the number of generators increases.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email