Optimizing RTL designs prior to implementation with Cadence Joules RTL Design Studio

A closer look at the new solution with the help of Rob Knoth, Product Management Group Director in the Digital & Signoff Group at Cadence

With its recently announced “Joules RTL Design Studio”, Cadence is offering “a new solution that provides users with actionable intelligence to accelerate the register transfer level (RTL) design and implementation process.” According to Cadence, front-end designers can now access digital design analysis and debugging capabilities from a single, unified cockpit, enabling fully optimized RTL design prior to implementation handoff. For years, Cadence maintains, front-end designers have lacked visibility of RTL metrics on power, performance, area, and congestion (PPAC). Now, with the Joules RTL Design Studio, exploration and prototyping are possible prior to committing the design to the place and route phase.

Front-end designers can locate problems in the design layout, trace them to the source code, and automatically give actionable guidance to improve RTL for better PPAC. Simultaneously, implementation engineers benefit from this early debugging because they can now allocate resources to fix issues that cannot be fixed at the RTL level. According to Cadence, an important factor for the success of front-end designers is to have their analysis results delivered quickly without compromising accuracy and vice-versa. To achieve this, Joules RTL Design Studio can customize the runtime versus accuracy tradeoff depending on the end goal of the design.

The key features of this new product have been described by Rob Knoth, Product Management Group Director in the Digital & Signoff Group at Cadence, in the video interview he recently gave to EDACafe’s Sanjay Gangal; building on that interview, in this article we will add some more details, based on the answers that Rob provided to some additional questions.

The EDA industry and the challenges of RTL optimization

Cadence’s initiative stemmed from the awareness that the EDA industry, in the past, has not addressed the challenges of RTL optimization at the best possible level.

“Our RTL designers in many ways have kind of been left out of a lot of the automation that the industry has had”, said Knoth. “In general, we focused a whole lot on the digital space in terms of the people who are doing the actual implementation, the synthesis, place & route, the signoff etc. But the whole process [of] helping RTL designers achieve fully optimized high-quality RTL that won’t have any surprises during physical design is really important to getting a high-quality product to market quickly. What are some of the challenges they have? A huge lack of predictability [to make sure] that when they handoff RTL to an implementation team that it’s not going to result in surprises on the backend: congestion, power problems, frequency problems etc. Enabling RTL designers with better predictability [for] a higher quality handoff is a huge challenge,” Knoth pointed out.

Painful iterations

Traditionally, this lack of predictability has caused lengthy iterations. As Cadence explains in the product datasheet, “In the past RTL designers were siloed from implementation engineers, creating a disconnect between the front end and implementation. This disconnect caused extra back-and-forth iterations between the two teams, prolonging the design cycle and significantly delaying time-to-market.”

This is how Knoth describes the traditional process: “RTL designers finish functionally coding the RTL. They hand it off and then the implementation team does a few trial implementations. They usually run into a whole lot of easy to fix but annoying problems. And that starts a painful, long, unpredictable amount of iterations between the RTL designers and the place & route teams. In modern projects RTL designers are the critical path to get a product to market. They have a huge amount of work to do coding all the functionality and features etc., and then verifying that the device actually is performing as required. So we’re going to directly address those unpredictable, painful iterations between the RTL designers and the implementation team,” Knoth stressed.

The Cadence approach: providing RTL physical estimates using the core implementation engines

The ‘shifting left’ concept seems to be a key point here: in Cadence’s words, the solution “allows RTL designers to rapidly get early and accurate insight into the physical design effects of power, performance, area, and congestion (PPAC). Specifically, “The solution’s PPAC estimates are driven by the core engines from Cadence’s industry-leading Innovus Implementation System, Genus Synthesis Solution, and Joules RTL Power Solution.”

This approach provides substantial benefits, according to Knoth: “The shared engines are critical [to] delivering a high quality, accurate estimate of the physical effects, [because] it all depends upon what is the implementation team going to do,” he said. “And so rather than us trying to invent our own placement algorithms or routing algorithms that deliver estimates – which is the approach that many have taken in the past – we’ve just collaborated with our brothers and sisters inside the implementation team to directly leverage the exact C code for Cadence’s industry leading GigaPlace, GXL placement algorithm, RTL floorplanning algorithm, Genus mapping technology, Joules Power Analysis engine, etc. By directly accessing those engines at the C code, we’re wrapping them together in an easy-to-use platform. So the RTL engineer doesn’t have to master five different tools. He just has to learn one tool, and trust and know that it’s delivering very accurate estimates which will correlate with implementation.”

Benefits of using shared engines, Knoth added answering our questions, include that “when a new feature is added for handling an aspect of design convergence at an advanced node (e.g., routing rules) or a standard cell library (e.g., Vt classes, multi-bit cell variants), the RTL designer will not be surprised.”

So how did Cadence manage to ‘shift left’ these physical estimates in an efficient way, while avoiding a potentially heavy processing ahead of time? It looks like the answer lies in the fact that the information content of the design grows gradually – and naturally – over the course of the design flow, so shifting left a hyper-accurate physical estimate would be both difficult and not so useful.

“The key to any ‘prototype’ is the tradeoff between runtime and accuracy”, Knoth explained answering our additional questions. “However, accuracy is determined by more than just the kind of algorithms that map from RTL to gates. It is also dependent on the quality/completeness of the input collateral (RTL, timing constraints, power intent, floorplan, etc.). Early in the design process, input collateral is immature, so spending a lot of runtime on high-quality synthesis is a poor use of resources and time. We give designers the flexibility to adjust the effort of the prototyping flow to best fit the decisions they’re trying to make in the project timeline.”

A unified cockpit and the importance of visualization

One of the key features of Joules RTL Design Studio is its unified cockpit which – according to Cadence – provides efficient, user-friendly experience, offering physical design feedback, localization and categorization of violations, bottleneck analysis and cross-probing between RTL, schematic, and layout.

According to Knoth, this is a really fundamental improvement offered by the new solution: “By sharing and leveraging those engines and bringing them into one unified cockpit,” he said, “we allow RTL designers to see the trade-off that could happen – say – when you’re fixing a power bug: did you create a congestion problem? Or if you’re fixing a power bug, did it create a timing problem? By being able to unify all that together in one place, designers can effectively understand trade-offs and produce the highest quality RTL.”

“The other aspect of this,” Knoth continued, “is since our team was directly using those other engines, they could spend all their bandwidth creating the highest quality user interface that’s highly customizable for RTL designers to be able to cross-probe between layout, schematic, RTL, being able to have color coded tables. Essentially, the key here is that visualization is probably one of the most important aspects. RTL designers are not implementation people. Speaking directly to RTL designers, working directly with them, understanding how they solve problems: that’s where our team spent the bulk of their time, and I’m very proud of the end results.”

Interactive congestion hotspot layout viewer with HDL cross-probing. Credit: Cadence

Timing debug with HDL cross-probing. Credit: Cadence

AI integration and other features

Additional features of Joules RTL Design Studio include the integration with generative-AI Cadence Cerebrus Intelligent Chip Explorer, to explore design space scenarios; and with the Cadence Joint Enterprise Data and AI (JedAI) Platform, to allow trend and insight analysis across different versions of the RTL or across previous project generations. The solution also offers lint checker integration, with the ability to run lint checkers incrementally and rule out data and setup issues upfront.

As specified in the product datasheet, Joules RTL Design Studio offers some specific advanced RTL design features. RTL Restructuring enables users to modify logical hierarchy: group, ungroup, move, add, or remove instances and rewrite RTL to achieve better PPAC. Tracking PPAC compares QoR between runs or between stages of the same runs. RTL Diff highlights differences in RTL at multiple abstraction levels, from simple RTL changes to complex logic changes.

A new way of working

According to Knoth, the adoption of Joules RTL Design Studio enables new ways of collaboration between the different design teams. “With our solution,” he said, “the RTL designers will be able to do some early [physical] estimates themselves even without alerting the implementation team, and without having a physical floor plan to be able to clean up any problems inside their RTL.”

“As the implementation team starts getting sped up onto the project, the two [teams] can work together,” Knoth continued. “The implementation team can supply the RTL designers some early floor plans which improves the accuracy of the RTL designers’ predictions, but then it doesn’t stop there. What we also see is that there’s a huge opportunity for the RTL designers to continue to participate in the physical design closure process. So with our solution, when the implementation team is running into – say – routing convergence problems, it could directly give a database back to the RTL designers who can bring it into the same tool they used for prototyping – same GUI, same everything – and directly cross probe it back to their RTL. Frequently a very simple elegant RTL edit can save hundreds of hours of backend engineers time trying to converge a database. That’s really how we see this working: delivering a higher quality handoff in the beginning. And then the RTL designer being able to more efficiently participate in the closure process with the implementation team.”

Physical insights for both advanced and legacy nodes, with a special attention to congestion

Joules RTL Design Studio addresses a wide range of process nodes. “While we do see the bulk of the challenges here at advanced nodes, just because of the complexity of designs and long data paths that are possible,” Knoth said, “this is not something which is only an advanced node problem. Ever since the start of modern digital design, RTL designers have wanted to have better physical insights so that they’re not surprised. And so even for customers who are designing in planar nodes or even more legacy nodes, this solution is very useful,” he pointed out. “We do require RTL designers to specify their target process to aid in the accuracy of prediction,” Knoth added.

The popular PPA acronym (Power, Performance, Area) is often associated with a fourth letter, such as Y for Yield. In the case of Joules RTL Design Studio, Cadence is stressing the importance of getting insight into the physical design effects of PPAC, where C strands for Congestion. Why is congestion such an important metric?

“Congestion is the driving factor behind many design decisions” Knoth explained. “Metal layers are just one. In the past, RTL designers depended on cell area as the key metric to predict how much silicon real estate they needed. However, with advanced nodes, this metric isn’t sufficient to make predictions. Routing congestion is the true metric that should be used, which drives floorplan requirements and silicon area.”

Benefits and early customer endorsements

Cadence claims that the solution enables faster runtime than a production implementation flow using its digital design and signoff core engines – as we already saw. This way, intelligent feedback and accurate physical prototyping translates into faster and fewer iterations with up to 5X productivity improvements and up to 25% quality of results (QOR) improvement in RTL, in terms of PPAC optimization.

The announcement press release includes endorsements from four early adopters. Socionext cites the ability to find and categorize timing violations based on logical and physical causes as well as bottleneck analysis and cross-probing to RTL, schematic, and layout, leading to 2-3X better productivity and significantly reducing iterations between RTL designers and implementation. MediaTek also points out a reduction of the number of iterations between front- and back-end teams and the resulting shorter time to market. Arm stresses the time savings in identifying problem points associated with congestion and deep logic. T-Head (Alibaba) highlights the ability to get efficient and accurate power breakdown analysis much earlier in the design phase.

A well-known problem

It could be argued that design abstraction is a double-edged sword: on the one hand, decoupling logic design from physical implementation is key to productivity, but on the other hand the lack of physical constraints gives design abstraction ‘too much freedom’ – so to speak – often leading to less-than-optimal designs that will later translate into poor implementation. In other words, some of the structures that can be easily described by RTL will convert into overcomplicated gate circuitry, proving difficult to physically implement and/or generating problems such as congestion.

This has been a well-known problem for at least two decades: an article from LSI Logic dating back to 2002 – rightly indicated by Cadence as a key work on this theme – was very effective in identifying the structures in an RTL database most likely to generate implementation problems. That old article also expressed some key concepts: among them “RTL code should be analyzed as it is written, not when problems are encountered during the physical implementation or even after synthesis, as RTL architecture and coding problems are not recognizable in a gate-level netlist.”

Back in 2002, LSI Logic proposed a rule-based approach: it developed twenty physical RTL rules to find potential problem areas in an RTL database. However, LSI Logic also recognized that “it is impossible to detect and thus resolve every physical design problem in every design with a rule-based approach,” and maintained that “The solution required is an integration of physical RTL analysis with physical planning tools. This would put the capability into designer’s hands to simultaneously assess the feasibility of, plan for, and optimize the physical implementation of a design as it is being developed, from defining the RTL architecture and coding the RTL through synthesis and physical planning.” It could be argued that this is what Cadence is trying to do today with its Joules RTL Design Studio.

Why now?

As we saw, the EDA industry has long been aware of the physical implementation problems caused by suboptimal RTL code. So it’s interesting to find out what prompted Cadence to address this issue right now.

“You’re correct,” Knoth said, “this is not a new problem in the industry. Why now is a great question. Today, we’re grappling with the age-old problem of trying to do more with fewer resources, but the engineer hiring pool is even more stretched. How do you help young engineers gain experience so they can be productive without needing lengthy mentoring of experienced designers? How do you handle this process across geographically distributed teams? That was a key driver for our timing.”

“It doesn’t make sense to rush out a prototype that gives fast answers that are inaccurate, or even correct answers that are hard to visualize”, he continued. “We have been honing the approach of accuracy and usability through our Joules RTL Power Solution—but focused on power. We broadened it to encompass the full spectrum of power, performance, area and congestion with launch of our Joules RTL Design Studio,” Knoth concluded.

Categories: EDACafe Editorial, Video Interview

This entry was posted on Friday, August 11th, 2023 at 7:01 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.