Le Chesnay, France (PressExposure) October 15, 2009 -- There is still no widely accepted flow that reaches all the way from behavioral system descriptions to tape-out. But a sprinkling of green shoots at DAC last week suggests that some momentum is finally building toward linking algorithm development with silicon implementation. Of course there were the established stories from Cadence, with their C-to-Silicon Compiler, Mentor, with their Catapult-C, and several smaller high-level synthesis vendors. But some of the more revealing developments came from the trenches, not the headlines.
One such was a conversation with Kenneth Karnofsky, senior strategist for signal processing applications at The MathWorks. Karnofsky was at DAC to promote the growing use of MatLab and Simulink as early verification tools to explore and verify algorithms before the implementation process starts. He described what he sees as the most typical process.
"Designers will explore and refine their algorithms either as mathematical expressions in MatLab or as algorithmic code in C," Karnofsky said. "Then they will blend the algorithmic models with models of discontinuous behavior in the Simulink environment to begin the process of system modeling."
Not only is this a powerful early development and verification environment, but it creates an executable specification. If there is any question downstream about how the hardware or software is supposed to handle a specific situation, designers can refer back to the Simulink models. No human interpretation of an ambiguous human-language specification is necessary. A further point, Karnofsky said, is that modules from the Simulink models can function directly in the designers' multi-mode test bench, either as stimuli and checkers or to stand-in for blocks that have not yet been implemented.
But there is still a manual gap between the Simulink and implementation worlds. "Most often, the models in our domain serve as a reference for the C or Verilog programmers as they manually recode," Karnofsky said.
Lynguent is also focusing on the abstract modeling problem. Lynguent provides not a language or a simulation tool, but a graphical drag-and-drop, block-diagram-like environment for creating models, and a collection of libraries to define the behavior of the functional blocks. Libraries are available for VHDL-AMS, Verilog-A, Verilog-AMS, or MAST. The company provides the models in toolkits directed at specific applications. During the show, Lynguent introduced kits for rad-hard design, event-driven mixed-signal modeling, the MAST/Saber world, and a kit that emulates the models in the MathWorks Simulink libraries.
This last point is particularly interesting to the discussion. Martin Vlach, Lynguent CEO, says that in recent years mixed-signal simulation environments from the mainstream EDA companies have matured from clothespins-and-bailing-wire affairs to very effective multi-mode simulation systems. By providing a bridge from the Simulink world into VHDL or Verilog mixed-signal simulators, Lynguent is closing just a bit more of the gap between the algorithm-development tools and the beginning of the implementation flow.
There is still open space, though. The Verilog-A/AMS or VHDL-AMS code bound to Lynguent's functional blocks is intended for simulation, not for synthesis. And so far no effective tool exists for synthesis of the continuous-time portions of these mixed-signal languages anyway. So there is still a manual step between behavioral simulation at RTL and generation of synthesizable code.
CoFluent Design added another voice to the discussion. CoFluent also provides a block-diagram-level modeling tool, but this time for tasks whose behavior you can model in ANSI C. The block diagram paradigm provides a clear separation between datapath and control structures: the control flow of the system is implied by the way you lay out and connect the blocks in the diagram, while the procedural C code is encapsulated inside the blocks. Internally, the CoFluent modeling tool generates control code in a set of proprietary extensions to SystemC to cover control structures inferred from the topology of the block diagram, common hardware structures such as arbitrated busses, RTOSs, and so forth.
CoFluent provides both a proprietary simulation environment for system behavioral simulation at this block-diagram level, and a translator that extracts from the diagrams a SystemC transaction-level model of the system compliant with TLM 2.0 and suitable for export to other SystemC-consuming tools. Therein is, for some teams, the missing link. TLM 2.0 can be the ticket not only into fully-timed behavioral simulations, but also into implementation flows.
And yet the bridge is still not complete. No one is suggesting that the SystemC from CoFluent is ready for synthesis--just that you can import it into the Synopsys Innovator or CoWare platforms. Still, it's another step, getting tantalizingly closer.