Spec-Driven Design

Anupam Bakshi, CEO of Agnisys, sat down with Semiconductor Engineering to discuss problems in the design flow and what needs to be fixed. What follows are excerpts of that conversation.

SE: What are the big problems facing the industry?

Bakshi: There is a disconnect from the specification down to the implementation. That’s why verification has become so big. Specification down to implementation has not been done correctly.

SE: Isn’t that the idea of correct by design? Is that a realistic goal?

Bakshi: Looking at that from afar, the whole thing is unsolvable. But what we’ve found is that by going in and working on a niche area, we have been able to solve it, which is the hardware-software interface. It’s a spec-driven, correct-by-construction methodology, and that has worked very well. From that niche, we can grow and solve bigger problems.

SE: What’s you’re starting point?

Bakshi: We’ve been dealing with registers for the past 10 years. We understand enough about registers to do spec-driven design. We’re looking at sequences now. That’s the next step—how do you use those registers. In some sense, the next step already has started with the portable stimulus. How do you create tests and how do you verify at the block level or the system level from a higher level? These are merging together.

SE: The challenge going forward is that there are fewer massive designs where you can do everything once, and a lot more of the smaller designs that need to be customized for IoT. Is what you’re talking about adaptable to every design?

Bakshi: Our customers are doing all kinds of designs. The same things are applicable. Scale shouldn’t matter. IoT designs are embedded systems. There are software and hardware components, irrespective of the target application. Those devices are fraught with issues. If there’s a software-hardware component, then spec-driven development is the way to go. We can extend that to other areas. We can raise the level of abstraction.

SE: One of the ideas behind portable stimulus is re-usability. How does that work here?

Bakshi: Reusability is not just vertical, like the same stimulus working at the block level and all the way to the top. It’s also horizontal, from various different platforms, from verification through validation. The challenges that affect development are how do you create it in sufficient abstraction or in sufficient detail so you are able to target all of these platforms or all of these levels of abstraction. That’s a challenge. I’m not saying we have all the answers. But the path we’ve been on has shown success. The big EDA vendors are happy about this, too, because we have provided what I call the last mile to the customer in two ways. We’re providing an abstraction to the hardware in whatever software environment they want to use.

SE: Who defines the specification? And has that changed at all?

Bakshi: It’s the architect. Everything feeds out of that—the verification, the device drivers. What’s changed is that the architects have to do more. If they can do it at a higher level, they can create the spec and add value up front in the design process. Rather than having a dependency for a hardware-software interface later on, the architect is creating that interface through the specification.

SE: In the past they either did the hardware or the software, right?

Bakshi: Yes, or someone had to go in and take that step of figuring out where that interface should be. Now all of that can be done at a higher level by the architect.

SE: Does power enter into that, as well?

Bakshi: Yes. We are seeing that more often. Power plays into the increasing complexity. We are able to create specifications that can capture behavior, including power. UPF is part of this. So is powering on the circuitry, which is driven by the software.

SE: This is largely a dark silicon strategy?

Bakshi: That’s correct, and it’s where registers come into play. There is clock gating of various pieces of the circuit.

SE: Where do registers enter into this? Is it fully on or off, or is it something in between?

Bakshi: What we’ve come across is either on or off. You could play other games with this, as well, and that’s coming. But it’s not happening yet. Over the years, it started out with simple registers. The specs are becoming more complex.

SE: One of the problems with some IP is that it’s a black box. How does that affect what you’re doing?

Bakshi: There are two answers to that. One is that we help people create the IP and the interface. In that case, it’s very well documented and understood how that IP is used. On the other hand, it’s possible that you get a black box and a PDF document. You do get IP-XACT, but sometimes that doesn’t say everything about it. How are you going to program those?

SE: But it also makes correct by construction difficult if you don’t know exactly what’s in a design, right?

Bakshi: That’s right. Correct by construction has levels to it. When you know everything about it, the IP can be correct by construction. But if there are things you don’t know about the IP, then correct by construction goes out the window. That’s where you need to have very well defined interfaces. That includes the physical interface, the pins and the buses. But it also includes what you do with that. How you access the hardware API is an interface. That is missing, and no one is talking about that.

SE: Is the memory affected by this?

Bakshi: Everything that is on the address bus, which is registers and memory, is what is defined in the specification.

SE: What’s the concern there? Is it the type of memory, the latency, the access in and out of memory?

Bakshi: It’s the bandwidth, the latency, and flexibility to change which memory type to put in. Is it single-port, dual-port? That depends on the functionality of the device. If you want the register bus to write and the application logic to read, you’ll have write quotes from the software and read quotes from the hardware. You could have both sides writing to it, as well, in a shared memory.

SE: Who figures out how the memory gets characterized so you can choose one or the other?

Bakshi: That’s the customer, and it’s based on the functionality. There is latency. We provide the client for a register bus. That client interfaces with the memory. We always are pushed to make sure the clients are zero latency and high throughput. That’s a concern, and we address it.

SE: What’s your next big challenge in terms of technology?

Bakshi: The creation of the hardware API that the software can use. We need some way to define it and some way to use it.