You don’t hear a lot about RTL-to-GDSII design these days, but it is far from a solved problem. At a panel discussion at Cadence San Jose headquarters Dec. 11, 2014, panelists stressed the need to “empower” RTL designers with tools and methodologies that can keep up with the rising complexity of IC designs. The panel discussion took place at the one-day Front-End Design Summit and was titled “Front-End Tool Tradeoffs – Speed vs. Results.” The panel was moderated by Brian Fuller, editor-in-chief at Cadence. Participants were as follows, shown left to right in the photo below: Venkat Ghanta – principal engineer, Cisco Systems Jon Haldorson – principal engineer, Central Engineering Group, PMC Sierra Leah Clark – associate technical director, Digital Video Technology group, Broadcom Paul Cunningham – vice president of R&D for front-end design, Cadence The discussion took place at the end of a day of Cadence and customer presentations, before a packed audience – on a day when San Jose was experiencing its worst winter storm in years, with heavy rain and high winds. I think this shows that front-end design is indeed a topic of much interest. Following are some of the discussions that I felt were most interesting. RTL designers need to do more Haldorson : A lot of front-end design is about empowering the RTL guys. How do we give them the tools they need to analyze their designs, and get feedback to understand the critical issues? They need to resolve the timing issues, or have constraints ready for other teams who will do so. To ease physical layout, we need to give them the best tools possible to analyze their design. The other issue is power. Since everything is largely focused on power right now, how do we boil down what designers need to deliver in terms of generating the CPF [Common Power Format] files? Clark : We’re trying to empower the RTL designers to really get involved in EDA, to do the power analysis and the architectural exploration. Most of the time, they don’t want to do that and they don’t want to learn how to use the tools. So we’re lowering the bar, and it has to be pretty low to get them to do the work. For example, when we turn on a lint checking tool, we make it really simple. Getting the RTL owners to want to be part of a process that is totally unglamorous, and has lots of late nights and lots of bugs, is really a challenge for us. Tool runtime is not the issue Haldorson : I don’t really care how fast a tool runs. I’m looking for what it takes to get the quality. You could run a tool for six months before it gave you the answer that you needed. Designers shouldn’t necessarily try to rush through synthesis. If the layout doesn’t work, you have to go back and fix it. Designers need tools that allow tracing back to RTL Haldorson: We have made requests over multiple years for tools that do tracing back to RTL. There are such tools now, but they don’t solve DFT [Design for Test] problems. We need tighter coupling, we need test points for better testability, but I don’t have a way of tracing this back to RTL. Ghanta: We will pay money for a tool that will take an RTL design and basically say, here are the problems. I want outputs that I can tie back to RTL. Predictability for IP design Haldorson: We want predictability and pre-emptiveness to help our RTL designers design a better product up front, and then from an IP perspective, we want to turn that implementation over to the next project and not have the same issues. Cunningham: Yes, if you can make a change in the RTL to make it more robust and predictable across different implementations, but it doesn’t cost you anything in performance, power and area, why not make that change? Clark: Even if the change does cost you a little, it saves you in the end if you can make your market window. You have to bring market timing into the cost function. It’s not just power, area, and timing. Variability and voltage Audience Question : Power is a need for everyone. One area I’d like to see Cadence spend more time on is voltage regulation and adaptive voltage. It’s a great opportunity. Cunningham : What you’ve described is very real. There are several components – a tool component, a design component, and an IP component. I’m focused on the tool side. We’re making sure you can support multiple corners for different voltage points. We’re investing in MMMC [multi-mode, multi-corner timing analysis]. Customers are using physical synthesis selectively Clark: Physical synthesis can be really good and it can also be bad. It’s very difficult to predict. Our takeaway is that no floorplanning information is better than bad floorplan information. We use floorplanning and synthesis from different vendors, and our tools don’t correlate. Ghanta : We do use physical synthesis. If you just take the wire load impact, you leave a lot on the table. But if you can put the physical impact in there, including the wire delay, that maps better. Timing is not just about cell delay. Two types of physical synthesis Cunningham: There are two kinds of physical synthesis. One type does placement as the last phase of the physical synthesis tool. All you’re really doing is taking pre-CTS [clock tree synthesis] estimations of placement and moving them to a different place in the flow. You’re not really changing the flow, especially if your place and route is from a different vendor. The second type takes placement and actually uses it to influence the initial synthesis. That’s much better if done correctly. Now you have something that can add value independently of the place and route tools. Richard Goering Related Blog Posts Front-End Design Summit: The Future of RTL Synthesis and Design for Test The Technology Behind Encounter 11.1 – Physical Aware Front End Design ISQED Keynote: How RTL Synthesis Must Change for Advanced Node Designs![]()
![]()
↧