SoC Design Partitioning to Save Time and Avoid Mistakes

I started designing ICs in 1978 and continued through 1986, and each chip used hierarchy and partitioning but our methodology was totally ad-hoc, and documented on paper, so it was time consuming to make revisions to the chip or train someone else on the history or our chip, let alone re-use any portion of our chips again. Those old, manual ways of doing chip designs are happily far behind us now, so much so that recent smart phone chips routinely have processors with billions of transistors, with massive amounts of semiconductor IP reuse, all enabled by more modern and automated IC design flows. This blog idea springs from information gleaned in a White Paper written by Methodics, a software company founded in 2006 with a headquarters in San Francisco. The big picture view at Methodics is to model your entire SoC as related sets of functional blocks, then automate the workflow to ensure that your chip design is consistent and easy to update and communicate changes and dependencies.

Here’s a picture of what they call an IP configuration and how it maintains multiple relationships to design data and versions:

The specific software tool at Methodics is called Percipient, and using this IP configuration approach you can do top-down designs more easily, because along the way the tool is tracking the content of each IP and the hierarchical relationship between them. These IP objects and relationships can be quickly captured at the very start of a project, even before the design details are ready. Everyone on the design team can visualize how their part of the project is being placed in a hierarchy and what its dependencies are going to be. Metadata is attached to each IP, so for example a Bluetooth IP block may require a specific PDK version from your foundry of choice and you can quickly determine if all IP blocks are compatible with that PDK version.

In the first diagram there’s a blue area showing that IP can be imported for re-use from many Data Management (DM) sources:

• Perforce
• git
• Subversion
• Custom

If your particular DM system isn’t listed, then just contact Methodics to see if they’ve already got an import available. The files in your DM can be primarily binary, text or a mixture of the two, so it’s your choice and there’s no restriction on DM type or how you make relationships between IPs of each type.

Workspaces are used to save specific configurations of your own choosing. Making changes to IP and its metadata can then be saved as a release, and each release has the relationships between all IPs in your hierarchy at that one point in time. With any particular release you can run simulation and functional verification, then the results are attached to that release. Everyone on your team can be notified when a new release happens on some IP.

There are even third party integrations with requirements management and bug-tracking tools, so team members always know for each IP what the requirements associated with it are, along with any bug reports. Here’e another diagram to show how an IP configuration connects with other tools in your IC flow:

So with the Percipient methodology you can go to one place and find out all information about your electronic system, from the top-level all the way down to the lowest block levels. You will know where each block is being used and how often it is being re-used, along with the requirements and performance, plus the history of changes made to it and by who. Searching through the Percipient catalog is quick and easy, so it takes a lot of the guesswork out of complex IC design projects.

Projects that need to comply with Functional Safety (FuSa) will enjoy the traceability features built-in to Percipient, so that you can validate every safety function automatically at each release. Another benefit to automating FuSa compliance is that user responses to questionnaires can be attached to specific IPs, and then managed throughout the design hierarchy.

OK, this sounds promising so far, but how do I know how to best partition my specific design with this tool? The best practice is to place anything that could be re-used into a functional block as its own IP object. A functional block can contain sub-blocks too, here’s another example of a hierarchy:

Your design team is typically comprised of groups, and each group can be responsible for their own releases. The best practice is to release early and often as progress is made and milestones are reached. Both producers and consumers of IP blocks use the Percipient tool, while a producer may be most interested in the latest version and a consumer could be more interested in using a fixed version that isn’t changing until they request an update. The producers are doing design work, running simulations and validations, reaching some quality goal and then they make a new release, alerting consumers that a new version is ready to consume. All team members are in the loop and quickly learn to choose the proper release.

Conclusion
Your SoC projects can be quite complex, containing Terabytes of data, so consider the benefits of using a proven, modern system to manage your IP with traceability, quickly and easily. Just look in one place to know the state of your design, while avoiding communication mistakes that could cost you an expensive silicon spin. The complete 7 page White Paper can be read here.

Related Blogs

• Using IP in a SoC Compliant with ISO 26262
• IP Management Using both Git and Methodics
• Combining IP and Product Lifecycle Tools
• SoC Design Management with Git