In the semiconductor design industry, most of the designs are created and optimized at the RTL level, mainly through home grown scripts or manual methods. As there can be several iterations in optimizing the hierarchy for physical implementation, it’s too late to do the hierarchical optimizations after reaching the floor plan or layout stage at the netlist level. All design explorations and optimizations must be therefore done at the RTL stage. The problem with the netlist level re-structuring is that verification takes weeks to complete and any functional changes to RTL have to undergo repeated modifications at the netlist, and hence there is an interest in moving to RTL level solutions. However, today with the increasing design complexity and multiple parameters to optimize with various constraints, it’s not possible to handle RTL restructuring manually. Effective and easy-to-use tools with automated procedures are needed to handle this important task.
I came across an articlewritten by Daniel Payne and also a whitepaperon Atrenta’swebsite, which provided great insights into RTL restructuring. It was then a nice opportunity to talk with Samantak Chakrabarti, Director R&D at Atrenta’s Noida site. Samantak provided interesting details about this capability in the SpyGlass RTL Signoff Platform, and clarified some of my queries about RTL restructuring that is done by GenSys RTL and how it is being used by customers. Here are the highlights of the conversation:
Q: Considering large design sizes, I can definitely see the need of automated RTL restructuring. Are there any specific scenarios that mandate this restructuring?
A: Yes, there are a few. To begin with, large, and more importantly, complex designs (with several configurations in them) can be optimized with automated RTL restructuring in a much shorter time, thus improving designers’ productivity to a large extent. The need to automate this procedure is more pronounced with power and physical optimization. For power, certain structures need to be aligned with their respective power domains. These power domains are organized by the hierarchy of the RTL. Similarly in physical terms, certain DFT elements need to have defined physical logistics which are defined by the RTL hierarchy. Additionally, there are physical rerouting, feed-throughs and logic insertions that take place to improve congestion in a design. Each of these design improvements requires manipulation to the RTL structure. Doing such operations manually can be very tedious, time consuming, and error prone. Our GenSys RTL tool has an easy-to-use GUI with many automated features that can be utilized to restructure any RTL very efficiently.
That reminds me of a presentation by ST Microelectronicsat DACabout how they used GenSys RTL in splitting a wide long system bus and organizing the design into four physical units (PUs), aligned appropriately to be fed by the split bus. This definitely provides much easier routing and reduces congestion to a large extent.
Q: What do you mean by configurations in complex designs? How are those handled?
A: Today, an SoC is not just one monolithic design. It contains several IP blocks. By using conditional expressions in the RTL, a designer can retain the original IP as is. However, while restructuring, pragmas, assertions, conditions under ifdef, etc. need to be retained while any behavioural code remains in source format, and net & instance names preserved. To maintain all of this critical design information, a designer can utilize the full potential of GenSys to optimize the RTL while keeping the necessary design constraints intact.
Q: I’m sure design houses must have automated scripts to handle such RTL restructuring. Are those not sufficient?
A: Scripts can definitely be used; in fact design houses are using them. However, scripts are tailored for a particular design style or language like Verilog or VHDL and can be error prone. Also, writing scripts for every design style and newer language constructs, especially SystemVerilog, and verifying them, can be very time consuming. By using GenSys RTL, one can easily reconfigure design hierarchy visually and generate the new RTL in minutes.
Q: What kind of GUI does GenSys RTL have for this purpose? How can it be used in an automated way?
A: If you look at the GUI in the above picture, a designer can intuitively view the current hierarchy, modify it by moving IP across the hierarchy, and undo / redo through hierarchy manipulation widget. When they are satisfied, they simply need to click ‘Apply’ to generate the new RTL. Many kinds of grouping, ungrouping and partitioning operations can be done while modifying the hierarchy. Additionally, the tool supports Tcl commands that can be used to restructure in batch mode as well.
Q: Interesting! How was the requirement of such a tool conceived?
A: The initial requirements came from customers who were doing large SoC designs. Since the design exploration activity was consuming a lot of time, they felt the need to automate RTL restructuring for design exploration. We developed the GenSys RTL tool to address this for our partner customers and now we have multiple top semiconductor companies using the tool. We do get interesting feature requirements from them, which we will be adding to the GenSys RTL solution in the near future.
Q: You mentioned that with this tool, designers can restructure in much shorter time. Can you quantify this time?
A: Yes, one of our customers who was using scripts, took about two months to complete the restructuring process for optimization of their design. The same design could have been restructured by the same designers in the GenSys RTL environment in just 3 days.
Q: That’s great! How do you make sure that the automatically generated new RTL is perfect?
A: It’s a requirement to verify the new generated RTL. The GenSys RTL solution generates a mapping file along with RTL which can be used by standard formal verification toolsto verify the equivalence between the new RTL and the original RTL. This mapping file is also used for restructuring other side files like UPF, SDC etc.
Q: I have another important question. Designs are done with certain physical intent. How do you make sure that the original physical intent is preserved in the new RTL?
A: That definitely is an important question. The SpyGlass RTL Signoff solution is a complete platform for design at the RTL level. The newly generated RTL can be verified through SpyGlass Physical for its correct physical intent, along with other aspects that can be verified through other tools within the SpyGlass Platform. Any necessary modification can be done through wrapper scripts or changes in files.
Q: Nice. Which RTL languages GenSys RTL supports?
A: GenSys supports all three prominent design languages, Verilog, VHDL, and SystemVerilog.
Q: Any experience with accommodating changes in 3[SUP]rd[/SUP] party IP?
A: This is another interesting observation. We have seen our customers verifying 3[SUP]rd[/SUP] party IP against their own design IP by using the GenSys RTL methodology. They simply replace their IP with the 3[SUP]rd[/SUP] party IP, under certain conditions, and verify the overall RTL. This checks the equivalence between the two IPs. Also, in certain cases, IP such as memories can be merged into a single path with GenSys. We also have seen new requirements such as handling behavioral logic, glue logic between IP, and so on, which we will be supporting in GenSys RTL going forward.
This was a great interaction with Samantak, which makes me think that the GenSys RTL solution has more capabilities for SoC design exploration than just RTL restructuring.
More Articles by Pawan Fangaria…..
Share this post via:
TSMC Unveils the World’s Most Advanced Logic Technology at IEDM