Application Note: Compilable IPs in ProjectIC
One of the most common types of IPs used extensively in SOC is memories and register files. Many SOCs use 10’s or even 100’s of memories and register files distributed throughout the design.
In most cases, these are generated by a memory compiler. The memory compiler takes a set of configuration inputs, and generates all the necessary files - RTL, testbench, BIST/DFT, GDS, LEF etc.
Other types of IPs, like PLLs for example, can also be generated based on a set of configuration options. All of these IPs fall under the category of compilable IPs - IPs that are generated by a generic compiler using a series of specific configurations.
Issues with Compilable IPs in SOC design
SOCs can encounter several problems when dealing with compilable IPs:
- Depending on the configuration, the size and number of these files can be quite large.
- Most configurations are fairly specific to the need, and using just a few general purpose variants is not an option for most designers. This leads to 100’s of similar IPs that need to be maintained, tracked and managed across the enterprise
- Whenever a compiler changes, all the IPs generated by that compiler need to be updated.
Compilable IP Management with ProjectIC
Methodics’ IP Lifecycle Management solution, ProjectIC, includes a seamless methodology to solve the key issues with compilable IPs.
In ProjectIC, the compiler itself is managed as an IP rather than the output it generates. Like any traditional IP in ProjectIC, the IP compiler goes through its own development process, and new versions of the compiler can be released.
SOCs that need to use the output of the compiler include the Compiler IP as a resource. The Compiler IP has a set of user-defined properties which define the options that the compiler expects. Each option definition includes
- Option name
- A range of possible values (integer, text, fixed enumerated values)
- Default value (if any) for the option. Options with no default values are considered mandatory inputs from the SOC.
Users can specify the exact release of each Compilable IP resource they want to use in their SOC. Users also create a series of configuration files that specify the exact configurations they want to use for a given compiler as part of their SOC.
These configuration files can be placed anywhere in the SOC’s directory structure, and they are usually identified by a naming convention. A typical naming convention for the configuration files might be “COMPILERNAME_<UNIQUE_IDENTIFIER>.cfg”. The naming convention of the configuration file is usually specified in the Compilable IP’s user-defined properties.
Building a workspace containing Compilable IPs
When a workspace is created that includes a compilable IP, ProjectIC does the following as part of a ‘workspace post-load’ hook:
- Bring in all the resources, including the IP compilers, into the workspace at their specified versions.
- Extract the configuration options from all compilable IPs
- Find relevant configuration specification files based on the naming convention in the workspace directory structure.
- Read the configuration file and build the configuration to generate the IP. Pick up defaults where configurations are not specified.
- Run the compiler and generate the output in the workspace location specified.
- Optionally store the configurations used indexed by the user/project back on the release of the Compilable IP. This allows for data-mining and reporting on the usage of the memory compiler.
This flow allows teams to compile memories on demand, and only store the compilers themselves as IPs. The key advantage of this flow is that dynamic data - like generated memory files - no longer need to be stored in any DM system. They don't have to push these large generated files across the enterprise. Instead, the exact memories that are needed by a project are created in the context of each project workspace as needed.
Updating to a new version of a Compilable IP
If a new release of a memory compiler or PLL generator is available, users can choose to update their SOC to use that release. Updating the SOC Bill of Materials (BOM) to use that release is a simple operation - users can either edit the project IP or update the workspace to the new release of the compiler.
At some point after this change, all the SOC designers would typically update their workspaces by running the ‘pi update’ command to bring their workspaces up-to-date. The ‘pi update’ command first updates all the IPs in the workspace, including the Compilable IPs, and then, as part of a ‘workspace post-update hook’:
- Checks to see if any compilable IPs have changed between the previous version of the SOC to the current version being updated
- If any compilable IPs are at a different release from before, it runs the same steps as those outlined in the ‘workspace post-load’ hook above for those compilable IPs only.
This helps solve the issue of bringing in a new version of a compiler or generator, and having to make sure that all the related collateral is up to date.