By Ann Steffora Mutschler
More IP and greater reuse of existing IP have been creating big headaches for integration teams. But what happens when it comes to actually writing the RTL?
Assembling RTL code should be an almost push-button procedure. It isn’t—or at least not yet. But at least progress is being made to finally make this a reality.
“If you were to ask some of the users that do the mega designs, how they do the assembly of the RTL, it’s surprisingly manual, said Frank Schirrmeister, group director of product marketing for system development in the system and software realization group at Cadence. “There’s a thing [EDA consultant] Gary Smith calls the silicon virtual prototype, which is essentially the fully assembled RTL. The problem is keeping track of it and configuring it and then generating the RTL, which is not trivial. If you just take interconnect, that’s why ARM has AMBA Designer, which is used to configure the output and then generate the RTL for you. Manually, it is too hard to do. If you take the complexity of big designs, and the complexity of verification environments around them, this simple task of generating the environment, including all of the RTL you want to test plus the verification setup and so forth, becomes quite challenging.”
It’s essentially a large configuration management problem tied to the complexity of the chip. And it’s getting more difficult to deal with.
“We’ve been associated with some very large projects that have IP from various sources, and that IP often has many configurations related to how it functions internally as well as what pins appear on the device,” said Chad Spackman, design manager at Open-Silicon. “For example, if you get a PCIe controller these days you’re probably looking at a 1,000-page spec. That connects to a SerDes to the outside world where the SerDes is something that probably supports multiple functions. It could be a PCIe, SATA, 10 Gigabit Ethernet, and it also is very configurable and has lots of different clocking modes, so there are lots of wires between them. There are a lot of wires between the core that’s represented by those thousand pages and the rest of the device. You really need to get all that stuff right because when you are ultimately going to find out that you didn’t get it right is very deep down the path of verification.”
The ideal solution, Spackman said, is being able to use off-the-shelf IP that is supported by standardized formats such as IP-XACT, so the function of the IP can be configured and it can be wired up correctly to the rest of the device. Otherwise the problems found in verification can delay tapeouts and cause chipmakers to miss tight market windows, which defeats the purpose of buying IP in the first place.
Message received
This message hasn’t been lost on the large IP companies, but it’s also not an easy problem to solve. John Swanson, senior manager at Synopsys, noted this has been a long-evolving design methodology. In working with companies either building chips or IP, a lot has changed, he said.
“It really first started with the AMBA on chip interface, and originally it was pretty simple,” said Swanson. “You had a basic AHB and an APB and you would hook an ARM microprocessor, maybe a USB and maybe some generic peripherals (UARTS, timers, etc.). That’s when you started seeing some tools come out for this, but it changed pretty quickly to where people were putting a lot of complex components on much more complicated interconnects, like AMBA, OCP and many proprietary ones. Those interconnects have gotten much more complicated, as well. So you have more complicated IP that has to interface with more complicated interconnects, and then there is a lot more of them that hook up.”
As such, engineering teams were spending a lot of time debugging. “I ran into people that would write Perl scripts to do connections and then spend a week debugging what the Perl script had done,” he recalled.
This design complexity also has turned some impressions on their head.
“I always thought you would do abstraction and everything would be decided at higher levels of abstraction, but that is not the case today. People are generating the RTL, and that’s where the automation of that RTL generation becomes important,” Schirrmeister stressed.
RTL decisions
Design decisions have been pushed down to the RTL level for a few reasons. First, there is an enormous amount of IP reuse, he said. “You have lots of RTL, which you may not have developed yourself. If the architect now has to develop an executable model of that, that’s pretty hard. You need to deduct key performance characteristics, create a model and you may do bugs within it and the more accurate you want it, the slower it gets.”
Second, if more accuracy is needed, the difference between the execution of a purely cycle accurate model and speed that causes, compared to RTL being executed it’s actually not all that great, Schirrmeister noted, “because the trends are that you need to model more and more details, which makes the C model slower. The trends on the RTL side are that it’s getting faster and faster because companies are optimizing the simulators and we are doing smart things like acceleration together with hardware and so forth.”
Further, if you think in terms of a large SoC, which is an assemblage of many different IPs, the intellectual effort is developing and verifying the IPs, noted Jeff Scott, principal SoC architect at Open-Silicon. “The integration of those isn’t really viewed as value-add. It just a collection of functions that, ‘Well, anybody can stitch together the IP.’ But in fact it’s a very tedious, manual process, fraught with human error. It requires a full chip net list to run through verification to find the errors, and that takes a lot of simulation cycles and a lot of time. Having an automated way to stitch things together certainly reduces the amount of labor and errors associated with that.”
Today, design flows are all over the place, Swanson said. “Every company has something different, but at a high level one example would be you are using a tool to profile your bus. We want to make sure we get the throughput right on our AMBA bus and we inject lots of signals to make sure it will handle the bandwidth that they’ve specified for our design. You can then take the configuration information from a higher level tool and use that as a starting point in your RTL configuration. You might be interfacing ESL tools into your RTL flow. Also, the flow should be bidirectional because when you’re in RTL you have the physical reality and you might find that because of the latency of the wires you need to go from a 64-bit bus to a 128-bit bus. That level of information typically doesn’t exist in an ESL flow.”
Bi-directional flows are still evolving because ESL technologies are used in a lot of different use models. “Whether it’s software development, which is very highly abstracted, to performance analysis, which is also highly abstracted but has more detail that maps to the RTL, you have standards like the IP-XACT specification that help quite a bit. The current specification needs updates to really support that, and Accellera working on that right now,” he noted.
IP-XACT allows IP not only to interoperate, but using the schema information can be shared between different design environments. Some engineering teams are considering the approach, while others are implementing it with proprietary scripting to link things together.
Time-to-market pressures will push the issue into widespread adoption, to be sure. “It’s the ability to do a chip out really quickly, get it into the back and flows and start working on the more physical issues and then get something for software people quicker,” he said.
At the end of the day, we are all driving toward the same thing, Swanson said. “Chips are harder, software is more important, and we need to get them done quicker. How do we pull all of this stuff together to solve that problem?”
That work is ongoing in industry standards bodies, and automation technology increasingly is being accepted by engineering groups around the world. But all of this takes time, and tapeout schedules don’t wait.