The Growing Need For Behavioral Modeling

By Ann Steffora Mutschler
When it comes to behavioral or functional modeling, there is an inherent notion of function, architecture and interconnect.

This approach has long been considered a future requirement, but in complex designs the future part no longer applies. Behavioral modeling is a way of isolating or abstracting out a key part of the architectural description and making sure it is completely understood—as well as not corrupted by the many other tradeoffs made in the design throughout the flow.

“Often, function and behavior are used for the same description,” said Frank Schirrmeister, group director for product marketing of the System Development Suite at Cadence. “The way behavioral or functional models are used today in system-level design are essentially models that just represent the end effect without any articulation of how it is implemented (which is the architecture), or how it is talking to its environment (which is the interface portion).”

This is typically done in C but can be in any language, he said.

Jeff Scott, principal SoC architect at Open-Silicon agreed. “A behavioral model in the context of system-level design is a model written in a high-level language like C, C++, or SystemC that represents the functional behavior of the hardware.” He noted that these types of models can be used in a variety of ways, most often as Verification IP for the RTL implementation of the same function.

“In this case,” he said, “the behavior of the RTL must match the VIP, but not necessarily cycle-by-cycle. Often IP providers will deliver the VIP with the RTL so that the recipient can verify the delivery is valid. This is most often done a block-level rather than system level.”

Another use for behavioral models is for system architecture exploration, Scott noted. “Multiple behavioral models may be integrated into a system so that the system architect can study their interaction. Because the underlying code is fairly high-level, simulations can represent significantly more time than RTL simulations, so the architect can see longer-term effects. If the intent is to study system performance, then the behavioral model must have some reasonably accurate representation of time, or clock cycles, consumed while performing its function. In some cases, these only model traffic behavior and cycles consumed, and aren’t true functional models. These types of models simulate very fast, but can only be used for performance analysis, not functional validation.”

The behavioral models are created or obtained prior to the system architect getting the models, often at the desk of an engineer sometimes referred to as an algorithm engineer, said Schirrmeister. “This is the person that implements the behavior or function of the system, who then dictates to the system architect, ‘This is the algorithm, this is the behavior I want you to implement.’ Then the architect adds on the architectural components to this behavioral model which essentially represents implementation effects.”

In this vein, it harkens back to “the old days with VCC when Alberto [Sangiovanni-Vincentelli] had coined the term ‘function-architecture-codesign’ where you say, ‘This is my function, which is completely free of any implementation assumptions.’ How much memory I need, whether it is in hardware or software—it is completely free of that…and then I have an architecture. Here are my three processors with one dedicated connection bus and three memories. That’s where the architect comes in and adds the architecture information to the behavior, which is essentially guiding the implementation, the partitioning, deciding even whether it is implemented in software or hardware,” he pointed out.

That’s one of the characteristics of a behavioral model, namely that it’s implementation-free and architecture-free. It hasn’t been decided whether to implement in hardware or software, nor is the architecture solidified.

The other important thing for functional models is that it typically has no specified way of how it talks to its environment. For example, if an MPEG decoder is being implemented in high-level synthesis, there is an algorithm, but then something has to be wrapped around it to tell it to start and then where to read the data from.

“The interface characteristic may change so the function is typically independent from the architecture, which is this other notion Alberto created called ‘communication-based design.’ You essentially define how these things interact with each other, what data they are sending each other, and then the implementation underneath is completely separate from the communication. You need to fiddle them together somehow as a way of merging them so that the communication actually fits together with the implementation,” Schirrmeister explained.

“The whole crux with functional models is the notion of purity, as Alberto had envisioned as ‘function-architecture-codesign’ and ‘communication/interface-based design.’ It typically does not exist because what happens is you very often start mixing the architecture implementation effects into the functional model as you refine it so the transformation is often not reversible which leads to the situation that you can’t reverse engineer the pig from the sausage,” he added.

Virtual prototyping demands fully functional models

A third use for behavioral models is virtual prototyping, Open-Silicon’s Scott said. In this case, fully functional models are required, but typically do not have accurate timing and the purpose is to enable early software development once the design is finished, but hardware is not yet available. “With virtual prototypes, software engineers can get a head start on bring-up code, driver development, interrupt services routines, system management, hardware abstraction layers, and other software that touches the actual hardware registers. Higher-level software development can be done, as well, but the practicality of it is limited by how fast the virtual prototype simulates.”

He pointed out that the Holy Grail for behavioral models has been for a long time that they would be developed first before any hardware design, and developed only once throughout the design, meaning the same model would serve as VIP, architecture and performance analysis, and virtual prototyping. In this way, changes in the design would first be represented in the model, which would essentially become a simulate-able specification. Then changes to the hardware would follow, and be validated by the model. “In my experience, however, I’ve not seen any chip development company fully commit to this methodology.”

Still, Schirrmeister believes there will always be pure functional models, although the level of automation will improve as approaches from companies like The Mathworks grow in use. What will slow adoption initially are engineers feeling that they would lose some influence over the implementation—which they would—but in the long run as designs get even more complex, the automation will improve and produce better quality results.

The adoption of behavioral modeling has varied depending on the company, observed Frank Ferro, director of product marketing at Sonics. “Many preferred to immediately go to RTL simulation, but as design complexity is increasing, behavioral modeling is becoming more prevalent. Having the ability to iteratively look at system functionally and performance—usually many times faster than an RTL simulation—is very useful during the architecture development phase. Using behavioral models will save time and energy during the implementation and test phases of development by having a better understanding of the system performance. Behavioral modeling is also useful to do software development in parallel with the hardware development…It provides better architectural exploration, performance analysis and software development in earlier stages of the design.”

At the end of the day, a number of various model types will continue to be used and find their niches. This is one more in a growing bag of tools for solving complex problems.