With All Eyes On ESL, Who Will Watch Our RTL?

Sept. 29, 2005
Amid the inevitable "post-DAC" war stories and EDA industry buzz this year, one message comes through loud and clear: We're definitely on track to deliver on the promise of using electronic system level (ESL) techniques to tackle the design complexity

Amid the inevitable "post-DAC" war stories and EDA industry buzz this year, one message comes through loud and clear: We're definitely on track to deliver on the promise of using electronic system level (ESL) techniques to tackle the design complexity challenge.

We've now made solid progress toward ESL solutions and methodologies for system design and will continue to do so for all the right reasons.

But judging from where the action really is, it seems that this focus on the lofty ESL story has inadvertently drawn attention away from the vast number of engineers slogging away in the trenches. It's time to speak up for the relatively silent masses of designers facing tough realworld challenges right here and now.

In reality, a large majority of designs still begins with register transfer level (RTL) descriptions, and this practice promises to remain so for the foreseeable future. Moreover, a huge volume legacy designs -- the building blocks new designs -- exists and is primarily extendable in RTL (not gates). ESL solutions based on the use of high-level languages, including tools for algorithmic synthesis and advanced verification, have admittedly demonstrated significant success on a wide range of design blocks. However, even in these flows, most designs must go through some form of RTL representation. This is the true state of design today.

The other, often overstated, truth is that the types of challenges facing designers keep escalating to meet the incessant demand for new product features. As the size and complexity of both ASIC-and FPGA-based designs continue to rise in tandem, the amount of data exponentially rises. Using a simple example, a multimillion-gate design implies dealing with thousands of data files, a complex task in itself. Add the fact that this data is then interacted upon by 20 or more tools during the design process, typically worked on using multiple coding languages by multidisciplinary teams of engineers from different geographies worldwide -- all with varying skill levels and educational backgrounds -- and it turns out that the communication or cultural gap is the relatively easy part of this equation to handle.

Instead, it's the growing productivity gap that needs immediate scrutiny, especially considering that several versions of these design objects need to be tracked and managed in an environment that includes the use and reuse of internal or imported IP (whose source may often be incomprehensible to the very engineers tasked with reusing code). Certainly, this is a very complex problem (typically handled in RTL) in terms of managing the associated data that is created during each step of the design process, as well as across the various teams using different point tools to cope with last-minute design specification changes within those processes.

Much has been written on raising individual efficiency, including the transition from point tools to integrated flows, raising abstraction levels, and other recommended best practices for end users. Significant benefits, however, can be gained by broadening one's focus to enhance organizational productivity via complete, concurrent, and consistent hardware design. This involves:

  • Adopting consistent processes to enable practical reuse across teams;
  • Managing infrastructure data to enable quick deployment or rearrangement of teams as needed;
  • Enforcing processes with enough flexibility to optimally work within the growing diversity of design styles, experience, and skills;
  • Automating design documentation to accelerate design reviews and reduce verification cycles; and
  • Implementing rule-based design processes to enhance code consistency for reuse.

In short, increasing levels of design size and complexity call for increasingly sophisticated management of the tools and RTL data associated with these designs. ESL may be a darn good idea in the long term, but it's only part of the equation. The key trends that are guaranteed are time-to-market pressures, the explosion of design data, and the greater interactivity of increasingly diverse multidisciplinary design teams located in disparate locations worldwide. In pursuit of the next revolution in design productivity, we may easily miss the fact that these trends open the door to obvious new ways to access huge productivity gains within the RTL realm itself, right here and now.

See associated figure

Sponsored Recommendations

Design AI / ML Applications the Easy Way

March 29, 2024
The AI engineering team provides an overview and project examples of the complete reference solutions based on RA MCUs that are designed for easy integration of AI/ML technology...

Ultra-low Power 48 MHz MCU with Renesas RISC-V CPU Core

March 29, 2024
The industrys first general purpose 32-bit RISC-V MCUs are built with an internally developed CPU core and let embedded system designers develop a wide range of power-conscious...

Asset Management Recognition Demo AI / ML Kit

March 29, 2024
See how to use the scalable Renesas AI Kits to evaluate and test the application examples and develop your own solutions using Reality AI Tools or other available ecosystem and...

RISC-V Unleashes Your Imagination

March 29, 2024
Learn how the R9A02G021 general-purpose MCU with a RISC-V CPU core is designed to address a broad spectrum of energy-efficient, mixed-signal applications.

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!