Making Hardware Design More Agile

Semiconductor engineering sat down to whether changes are needed in hardware design methodology, with Philip Gutierrez, ASIC/FPGA design manager in IBM‘s FlashSystems Storage Group; Dennis Brophy, director of strategic business development at Mentor Graphics; Frank Schirrmeister, group director for product marketing of the System Development Suite at Cadence; Tom De Schutter, senior product marketing manager for the Virtualizer Solutions at Synopsys; and Randy Smith, vice president of marketing at Sonics. What follows are excerpts of that conversation. To view part two, click here.

SE: Can work in the hardware world? And why are we even considering this?

Schirrmeister: There is always a desire to mirror the software guys, who talk a lot about Agile and sprinting, until you listen to the software guys say the hardware is farther along. We have a tapeout where the bugs are removed. The software guys always count on service pack two to fix the things they didn’t get right the first time. That’s the general theme. But if you look at the development processes today, hardware and software have become much close together. The Agile methods are about bringing hardware and software together to get intermediate representations faster. Synopsys calls it a continuum of engines. Cadence calls it the System Development Suite. Mentor calls it the Enterprise Verification Platform. You bring all these tools together early to allow you, in an Agile way, to connect what is going on in software and hardware early on. Another way of looking at this is Shift Left, where left means earlier on the project schedule.

De Schutter: Technology is changing so rapidly that it’s hard to predict six months to a year in advance what you’ll need to satisfy the customer requirements based on what everyone else brings out. So unless you are either completely at the forefront and bring out an incredibly innovative product, you also need to have an Agile method to adapt to whatever anyone else is bringing out. The software is easy to adapt. It also makes sense to have hardware that is easier to adapt to a specification and go for that specification and whatever technology trends are coming up.

Smith: The trend is more basic. Shift left primarily is a focus on getting access so software developers have something useful to work against and can move the whole project forward. Agile is attempting to change the way we do things from a technology approach that’s waterfall-based, which effectively says you have to finish one step before you go to the next step, into something where you can adapt to change more easily and begin certain steps with less complete data. With Agile we’re going to look at different ways of doing things. When you look at the software implementation of Agile development, they’ve come up with a whole nomenclature that people on the hardware side are not familiar with—Scrum sprints and other techniques. These are ways to get things done faster. It’s different, and it probably takes a different type of engineer to be good at it. There’s been a discussion in EDA about whether we need very specialized engineers, and over the past 10 years there’s been a push in the other direction about why we need engineers who are broader and willing to learn different techniques and specialties in different areas of EDA to make them more flexible because team sizes are going to get smaller. If you look at IoT, they’re not going to have people working on power reduction through the network.

Brophy: We’ve done quite a bit to invest in methodology that is rigid and deliberative in the steps that it takes. There has been success on the software side where if something isn’t working, it’s easy to change the software. That flies in the face of having specifications that are executable. If those are well-known and able to be used at a high level, you might be able to shift left and get early software running just on those systems. But we’ve also been watching the split between designer and verification engineer, where we have capped the number of design engineers versus verification engineers and questioned whether that is sustainable. We realized that requirements often are not followed at the beginning. Just as a marketing team may come back for customization, on the software side the closer you get to being done with a design the closer you get to the market. Then you have to rethink whether your product is ready for that market. The team approach that Agile brings is different than where one group designs something and another group verifies it. It’s a collaboration of team members. That allows for more sound choices in how something is constructed and verified. This isn’t just for the complex SoCs. We see this emerging in the FPGA space, and we think that’s an area where the uptake of Agile methods may mirror what you see with software teams today. But even on the most complex designs, our customers will start with the design they did before and build off of it. That’s almost an Agile building block approach.

Gutierrez: One of the benefits of Agile is that you can start doing some work even if you don’t have a complete specification up front. One of the challenges we’ve seen is on the verification side is that the DV guys are used to coming up with a test plan up front and then executing toward that test plan. But if the specs aren’t locked down up front and they’re changing, that means their test plan is changing, as well. We do have Scrums. We have hardware guys, DV guys and firmware guys and we’re all working together, which is very beneficial. But particularly on the DV side, they’re having a hard time pulling together a solid DV plan. It keeps changing every sprint.

SE: There are a couple issues going on here. One is faster time to market. The second is a better product with better confidence and better coverage. Where does Agile play into this?

Schirrmeister: Agile in hardware must be something fundamentally different because the time to trying it out is very different than in software. I’m an ESL enthusiast. I like the idea of an executable specification. But I’ve also been working on it for the better part of 20 years and I’m a little disillusioned. Agile in software works from what I’ve seen. All these sprints and Scrums work very well in a specific software implementation where then you have a build process that takes a day, so you can try it out and see if you’ve broken something. If you do that on the hardware side, you risk completely messing up the verification. The challenge on the hardware side is that the time to trying it out is where the shift left comes in. It used to be 20 weeks to get silicon to tapeout, and then three months where you couldn’t even change gates because it’s part of the implementation RTL and you could only do ECOs. The Agile definition in software doesn’t apply the same way in hardware because it takes much longer to try things out. If you can see it on a virtual platform within two days, that’s great. For the software, we aren’t there yet.

Brophy: What we tend to do today is have the person doing the design hand it off to DV engineers to figure out what’s wrong with it. The biggest thing we get out of this is a report to management about what’s not working. Agile flips that around. Instead of telling you what’s not working, it gives you confidence in what is working, what has been completely tested, and what the DV engineer collaboration can do. Verification engineers have the hardest time even understanding what a block does. The Agile notion of team collaboration allows a lot of that understanding to come into the verification side right away, so you begin to know what parts of the design are weak, what needs to be tested, what parts have been used before. The DV engineer may have no idea about this stuff, but it alters the conversation between team participants and adds a demonstrable change. So you might have upper management look at the dashboard, for example.

Schirrmeister: I agree 100%, but I’m not sure Agile is the right term for this.

Smith: I recently visited Pivotal, which practices state-of-the-art Agile software development. It’s way different from what I thought. All coding is done in pairs. So they have two guys sitting side by side, using identical screens, and working together. It’s a totally different way of doing work. At the end of the table, there is a big screen, color coded, with all of their unit tests as well as some of their other tests. Every time something is checked in, it is automatically updated. Those tests are developed by that team. It’s a different task to develop the test, so it might be different pairs that have done each of those. But we have a world where we have verification experts who don’t know anything about design and we have people who know a lot about design but they know nothing about test. That’s probably one of the biggest reasons why formal has been slow to get adopted even though the benefits are so high. We don’t have enough people who know how to do formal.

Schirrmeister: That’s not true anymore.

Smith: But it could be a lot better. If you look in the want ads in Silicon Valley, there aren’t enough verification engineers. We can change the way people do work or part of that job. You can add feature by feature into the design as you go. If you have 120 features and 80 done, you have a good idea where you are, as opposed to you have all these tests to get done but you don’t really know how long it’s going to take to get there. Agile from the software world is a lot of small group interactions, small steps at a time, building on top of something that is described at a different level as you go. In our case, part of the design may be in SystemC, other parts in RTL, and other parts already laid out. And you’re not as concerned about those last-minute changes because you don’t have an ECO flow for the logic side. Now if you get a high-level change on the logic side, you’re going to push buttons but you don’t know exactly what will happen.

De Schutter: The hardware and software will never be the same. Hardware will never be as flexible as software. Does Agile that provides a solution? You may be looking more at subsystem design, where now you have some flexibility while the individual pieces are being developed, and you have smaller teams building smaller subsystems. So rather than one big view you are designing and verifying different pieces. Looking at it from the software and hardware side, I met with a customer who said that from the virtual prototyping perspective, because of the increasing software complexity the design verification has to happen in the context of the software. We’ve done a lot of the shift left, but because there is so much software it’s a design verification task that is becoming so complex and driven by the software that they have to come together. So how do we bring the pieces together and get the software earlier so it becomes part of the hardware verification?