Optimize Physical Verification Cost Of Ownership With Elastic CPU Management

For physical verification, advanced process technology nodes create implementation challenges. Design sizes have gotten larger and required rules from foundries have become more numerous in count (thousands) and more complex (hundreds of discrete steps). For these reasons, physical verification tools have been able to span these jobs not only across multiple CPUs on a single physical compute host, but also across multiple networked hosts. A DRC or LVS job for today’s leading-edge designs, with billions of transistors, can run for multiple days utilizing many hundreds of CPU cores. Physical verification tools are scalable—adding more resources might speed up the run. However, it’s also possible that the job has some serial dependencies that cannot run faster. If this is the case, adding more compute resources will NOT speed up the run and will instead waste resources.

Any wastage of compute resources results in real loss to the user. In a cloud environment, users can end up paying by-minute rates for resources that are not used. For an on-premise environment, the resources that are occupied and idle represent resources that other users cannot use. Idle resources take up licenses that could be used for other jobs. Excessive run time also causes loss for the user. The time that is spent waiting for results is time that cannot be spent debugging those results. Therefore, users always want their runs to finish as fast as reasonably possible. However, the details of the causes and cures to the scheduling complexity of work items is not available to most users. It would require deep knowledge of not only the foundry rules and the way the rules are implemented in the runset but also the complicated way in which those rules are going to interact with the data. In other words, it is practically impossible for the user to predict how many resources will be needed to optimize both run time and resource usage.

Click here to read more.