STMICRO GOES FORMAL For Pascal Urard, manager of the high-level synthesis group within STMicroelectronics' Central CAD organization, there are two basic forms of ESL methodologies. One is model-based design, which involves teams of IP developers and a disparate team of IP integrators. Such flows require preexisting libraries or IP blocks. Any changes in process technology require recreation of the low-level hardware.
"Unfortunately, there is still no automated way to go from higher-level models to lower-level representations for model-based design," says Urard.
The other ESL methodology style revolves around behavioral synthesis, which begins with high-level models that are synthesized to RTL. Urard has found behavioral synthesis useful in the implementation of new algorithms.
"Once the algorithm is synthesizable with some set of constraints, we can explore many different variants automatically," says Urard. Within its flow, STMicroelectronics can handle designs of 300 kgates or larger.
For its model-based flow, STMicroelectronics painstakingly created a way to formally prove functional equivalence between behavioral models and RTL within its Matlab-2-RTL flow (Fig. 3). STMicro applied this flow to some very complex signal-processing ICs.
The flow starts from fixed-point Matlab code of an algorithmic function as well as generic RTL representations of the same functions. The first step is to ensure through simulation that the Matlab and RTL descriptions are identical. Then the flow moves on to formal proof of equivalence for a given set of parameters.
TI DREAMS BIG
"We have a dream that we could simulate extensively at the transaction level," says Loic Le Toumelin, worldwide director of SoC Methodology Process and Tools for the cellular system organization within Texas Instruments. "We don't do so extensively at this time."
However, Texas Instruments does make extensive use of virtual platforms. "Some developers create models that only work with certain tools. For us, this is a critical miss in this domain," says Le Toumelin. "We dream of models that operate in several tool environments." Even when there's some inter-operability, explains Le Toumelin, a change in environments can affect model performance. "Linking modeling styles to simulation tools is a huge problem."
Le Toumelin has investigated several behavioral-synthesis options for a top-down approach that implements new algorithms for signal processing or other tasks. "Different tools bring different advantages: Some start from System Verilog, which is close to traditional hardware, while others start from ANSI C, which is well adapted for implementation of new algorithms," he continues. "Still others leverage rule-based synthesis and others provide links to formal verification."
But Le Toumelin still sees major limitations in behavioral synthesis. You need different tools for different design styles (one for control logic; another for algorithmic synthesis). You must partition the architecture into control logic and algorithm portions. And, a behavioral synthesis approach means starting from many different abstraction levels.
In addition, for Le Toumelin, behavioral synthesis flows lack incremental synthesis to accommodate engineering change orders (ECOs). There also are problems with links to implementation.
"It's very difficult at high levels of abstraction to implement things like power management, design-for-test circuitry, and the like," says Le Toumelin. "These requirements translate into multiple clocks, multiple power-supply domains, and scan-path connections, all of which are added at RTL or the gate level. There's no link between high-level synthesis and our back-end flow."
Le Toumelin's dream is a flow that automatically generates what he calls a "machine-readable spec" for a design.
"You'd have a GUI in which you can specify that your platform will have a given processor," he says. "The flow would then automatically generate all views needed for detailed implementation. It would output RTL, XML, SystemC models, and perhaps, someday, English-language documentation."
Putting together such a flow is an extensive and ambitious effort, but one that TI has already moved toward. "We already have some of the pieces," says Le Toumelin.
Making all of this happen, of course, is contingent upon wide availability of high-quality, reusable IP that's programmable with all of the pertinent SPIRIT-standard XML metadata. TI signaled its interest in supporting standards bodies like SPIRIT with technology donations. "We believe we can improve the SPIRIT metadata definition and bring some new contributions to the XML schema, which we plan to do soon."
WHERE TO GO FROM HERE?
There is a dominant concern among leading SoC methodology architects: models and standards. Organizations including the SPIRIT Consortium and OSCI are working on standards that, together, will hopefully put a salve on these concerns.
The SPIRIT Consortium, which recently became a non-profit organization as opposed to its roots as a loose cooperative between various EDA vendors and IP providers, is striving to create a set of IP and tool-integration standards to proliferate IP reuse. One can see, for instance, the evolution of SPIRIT's IP-XACT metadata specification from RTL support to a move up in the ESL domain (Fig. 4).
OSCI's Transaction-Level Modeling Working Group is readying its TLM 2.0 specification, which will contain modeling guidelines and descriptions to help enable SPIRIT's efforts to describe IP at the transaction level in terms of metadata. The specification provides data structures, classes, and an API for generic modeling of on-chip buses or network-on-chip transport mechanisms.
Reprints
