Designers adopt ESL, but tools are lacking

-
EE Times:
Designers adopt ESL, but tools are lacking

 
ANAHEIM, Calif. — Chip designers are reporting success with electronic system level (ESL) design, but commercial EDA tools are falling short of what's needed, according to designers who spoke Tuesday at the Design Automation Conference (DAC) here.

While ESL is a broad-ranging term that can be applied to anything above the register-transfer level, most of the users who spoke at the "ESL tales from the trenches" panel are using the SystemC language for architectural modeling or verification. Many are using transaction-level modeling (TLM), which SystemC supports Using a "home grown" approach along with open-source tools from the Open SystemC Initiative, Sundararjan said, TI has developed high-level SystemC models that transfer tokens rather than data. "These models come up very quickly, and even without RTL, we can get a lot of insights into the architecture," he said.

A missing piece of the ESL puzzle, Sundararajan said, is a way to develop an executable specification. He also said that going from a top-level spec to an architecture is largely a manual process, although well-defined intellectual property (IP) blocks could potentially be translated from C to RTL.

Qualcomm is using SystemC for architectural characterization, said Suhas Pai, principal engineer at Qualcomm. His company is also using a "virtual platform" for IP modeling, a system-on-chip (SoC) testbench for simulation, and transaction-level co-emulation.

SystemC modeling helps design become a more "concurrent" process, and allows early architectural exploration, Pai said. But training is needed, he noted. "We really could have used training on how to use the language features for more efficient modeling, because the language is so rich," he said.

Terry Doherty, principal engineer at Emulex, said he's been doing system-level modeling for about three years. He currently uses SystemC transaction-level models for architectural analysis and exploration for the company's storage networking chips.

With SystemC, Doherty said, he's been able to optimize buffer sizes, implement new protocols, make hardware/software tradeoffs, and ensure FIFOs won't overflow. Doherty uses Summit Design tools for analysis and debugging, and proprietary tools for analyzing protocols. His EDA "wish list" includes tools that would prove RTL code meets system requirements, along with better management of large volumes of data.

ST Microelectronics is developing two ESL flows, said Pascal Urard, signal processing senior expert. One is a Matlab-to-RTL model-based design flow that's in use today, while the other is an automated synthesis flow that will be used this year for medium-sized IP blocks.

There are a number of gaps in these flows, Urard noted. These include synthesizable code generation from Matlab to SystemC, formal proof for the C and RTL code that's generated, and code checkers at many levels. The learning curve can be steep, he noted.

Soo-Kwan Eo, senior vice president at Samsung Electronics, showed a graph that EDA vendors may find disconcerting. It shows that Samsung's overall ESL resource allocation is going up, while its spending on commercial ESL tools decreases.

"We couldn't find the right tools at the right time," Eo said. Thus, he said, Samsung is working with universities and research institutes and is developing its own ESL tools. Samsung is developing tools for embedded software optimization, low-power optimization, and hardware/software co-design, along with links between in-house and commercial tools.

Eo's list of problem areas is long. It includes a lack of a measurable performance index to justify tool investments, the relative slowness of transaction-level modeling of embedded software, the lack of equivalence checking, the difficulty of inserting or extracting non-functional parameters, and the amount of modeling effort required.

"It takes so much effort to create the models that all the advantages ESL has could be wiped out by the modeling effort," Eo said.

 
×
Semiconductor IP