The (not so) Easy Life of an SOC Design Integrator

How can large SOC projects effectively integrate sub blocks and IP into a stable version for release or internal development? The person responsible for integrating SOC sub blocks into a validated configuration for release has a difficult task. Usually there are many sub-blocks, each undergoing their own development. There needs to be a stable configuration for the entire project to work off of, so there is a huge penalty for releasing sub-blocks that are not ready.

The integrator, who may not necessarily be part of the design team, has to know when blocks in the design have available updates. They also need to systematically integrate one or more updates while ensuring that each change to the configuration meets quality levels. If indeed one of the blocks fails validation, the integrator will need to quickly and easily back out the changes before they finalize the updated release for the project.

There are other participants in the operation. There is the contributor who owns the IP or sub-block that is being updated. This person will want to be able to flag a set of file versions as a new release for consideration by the integrator. The contributor will also want to be able to test their new release for the sub-block by running verification. Of course they will also need a way to inform the integrator that a new release is ready.

Because most designs are hierarchical, once the integrator has created a new release of their block, or chip, the consumer will need to be notified that a fully tested release is available for them. The consumer might be responsible for the next phase of the design. For example, let’s imagine that the design we are talking about is Verilog, once it has been released as synthesizable and meeting initial timing, the back end group will want to take this deliverable and work on the physical implementation.

There is actually a lot more to this than described above. Fortunately, Methodics as written a white paper that goes into more detail on the requirements and on their implementation of a system that addresses the design needs in this workflow for very large and multi-site projects. Methodics’ ProjectIC system uses ‘Moving Aliases’ to identify releases of IP or subsystems. A given alias will point to a set of versions of the contents and makes it easy to update a workspace to a particular release level. Aliases can have meaningful names like “SOC_READY” or “GOLD”.
ProjectIC can use pre-release or post-release hooks to invoke verification steps automatically when workspace is updated to a particular alias. This makes the process more automated and helps ensure better quality. It’s also easy for a user to look at a workspace and see what its status is. For example, this includes information about what release is present for each sub-block, and whether the files are in a container or rather a being referenced. Most importantly the workspace status can tell if a newer version is available.

The Methodics whitepaper goes into more detail and provides examples of ProjectIC commands and their results. You canfind the paper here on their website.

More articles from Tom…