Themes in EDA come in waves and a popular theme from time to time is RTL signoff. That’s a tricky concept; you can’t signoff RTL in the sense of never having to go back and change the RTL. But the intent is still valuable – to get the top-level or subsystem-level RTL as well tested as possible, together with collateral data (SDC, UPF, etc) clean and synchronized with the RTL, to minimize iterations / schedule slips to the greatest extent possible in full-system verification and implementation – the true signoff steps.

I talked to Chouki Aktouf , CEO at DeFacto about his ambitions in this area. You probably know this company from their work in early design for testability support at RTL and their very popular capabilities to support scripted editing of RTL. Building on these strengths, particularly in managing and editing RTL, Chouki has pivoted the focus of the company to SoC RTL integration and design reuse (in the true sense of that term), in both cases with an aim to be correct by construction. This is represented in their STAR solution flow.

Naturally an important part of completing RTL signoff must be functional verification, but it would be a mistake to think this is the only important part. SoC design methodologies, based heavily on pre-designed IPs interwoven with communication, control, test / debug and other fabrics, lend themselves to correct-by-construction design methods. The less designers touch the assembly, the less mistakes will be made; the STAR focus is on assembly and coherency between the assembled RTL and implementation-related data such as constraints and early floorplanning views. Getting this right naturally doesn’t eliminate the need for verification but it can eliminate or greatly reduce the need for verification wasted on finding assembly problems and constraint mismatches.

The center of STAR is a scriptable assembly tool to instantiate and connect RTL and/or IP-XAXT blocks. Think of this as the promise of IP-XACT assembly, generalized to help not just IP-XACT fans but also those who are happy to stick with RTL. Scripted assembly makes automated and parametrized assembly possible, something you may have seen in spreadsheet approaches but in this case more flexibly. There are also connectivity checking and reporting features (eg reporting clock connections from PLLs to IP clock inputs) which can greatly simplify hookup checking.

Why is it valuable to look at RTL together with other views? Because these views have become very intertwined. Think about power management through switched domains. Domains are planned at RTL, reflected on the existing RTL hierarchy. But each switchable domain consumes physical resources (the area it consumes, the switch overhead and possibly PG overhead). Combining domains with the same power switching attributes can reduce area consumed and simplify the power distribution network. To understand whether this makes sense, you need to look at the RTL, the UPF and early floorplan data. To implement the change you must be able to restructure the RTL to push those blocks into a common hierarchy, and reflect the corresponding changes in the UPF.

Or think about optimizing design layout by running feedthrus through blocks. This is a well-known technique to reduce routing overhead for critical signals. Historically it was a purely physical design problem – not much to do with the RTL. But in our power-managed world feedthrus must be reflected in the RTL and the UPF, otherwise verification and/or equivalence checking breaks. Again, you need a mechanism to restructure the RTL to rip-up and re-stitch signals reflecting a feedthrough. The point here is that getting to correct by construction RTL in modern design is not just about scripting the assembly, it’s also about being able to adapt the design as power and physical strategies change. That becomes very difficult for in-house scripts to contemplate without major rework and is essentially impossible if big chunks of the hierarchy are in RTL. Unless you have a solution like STAR which can understand and modify RTL (and other files) to reflect these changes.

I want to elaborate on my earlier point about design reuse. This term is often used somewhat loosely to mean IP reuse. But reuse of a full-chip (or subsystem) design is also a very valuable and very common starting point for derivative designs. Here there can be an important difference from IP reuse. Typically, you don’t take the whole design as a black-box. You use a lot of it, but you may want to lose some IPs and add others. Power and physical constraints will often change. A DDR interface in the original design was carefully arranged to sit next to associated IO pads. But in the derivative the block must be moved to a new location which may require hierarchy and feedthrough changes – requiring the same capabilities we saw earlier.

There are more functions in the STAR solution – to help generate early UPF at the top-level, to check UPF for consistency with the RTL and to provide consistency checking between RTL and SDC. These checks are all about consistency and completeness checking – those components important to that RTL signoff goal. I should add that STAR also provides, in addition to Tcl scripting, rich APIs accessible through Python, Java, C++ and Ruby through which you can develop your own checks and assembly generators.

Chouki wasn’t prepared to name customers (though I know of a few important cases, especially from their scripted RTL editing capabilities). He did say that users split between designers who want to directly script in support of their immediate design objectives and CAD teams who see an opportunity to develop in-house applications. I’m a believer in this approach. A lot of SoC assembling and prep for implementation is largely mechanical. There’s not a huge amount value in wasting design expertise in mechanical tasks. More automation and more certainty in moving more quickly into the implementation phase can only be a good thing. You can learn more about DeFacto HERE.