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.
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.
