Low Risk Customized IP Core Design

In the world of IP core design, there is an inherent conflict: Imagine this – if the IP core is going to be re-used, then should you deliver something that can be customized by the customer to their needs, or should you deliver a solution tailor-made to their exact needs?

From the customer’s view point, the latter approach is certainly preferable: the owners of the IP core, who know their product best, do whatever is necessary to meet the end user specification. The customer would simply love a drop-in, fully plug and play solution.

Unfortunately, this approach has several negatives for the IP design team, who have to treat each customized version as a separate IP, with different specifications, different design and code bases, different verification environments, different test plans, different physical parameters, different power requirements and so on. In fact, for all practical purposes, an IP that is tailor made for a specific delivery is equivalent to a separate IP altogether.

From the IP core team’s point of view, making one IP that is user-configurable is the best use of their scarce resources. Since so many features are actually more or less the same across various flavors of the IP, it makes sense to have one “superset” IP that at least theoretically can meet the needs of all potential customers. In practice, complexity grows non-linearly, and this approach does have its difficulties, but let’s ignore that for the sake of argument.

Naturally, this approach has several negatives for the end user; who has to learn how to integrate the IP core into their ASIC or SoC, which could have completely different requirements for VT flavors, metal stacks, reliability, interference, power, DFT, EMIR, packaging, substrate isolation and so on. The end user is not an expert on the internals of the IP, but has to come close in order to integrate it successfully. This is wasteful effort that can cause budget and schedule runaway.

Silabtech understands this conflict, and consciously chooses to prioritize the customer, putting their needs first and foremost, regardless of the cost to us. Thus, we choose to, for the sake of our customer – deliver a tailor-made, customized solution for their needs. Predictably, this creates significant extra work for us, and we have put together processes, methodologies, software and automation that allow us to still deliver on time without compromise on quality or cost.

Where do the real issues lie?

Making a hard, mixed signal IP requires a complex process that, from specification to GDS involves executing more than seventy inter-dependent iterative steps. Some of these steps are specification, analog design, RTL, analog/mixed signal modeling, mixed signal simulations, physical design, signoff checks and post silicon support.

To fully understand where the issues lie, let us start by looking at two interdependent steps in a process: the subsequent step can only be started once the preceding step is done; but the succeeding step also checks the prior. A classic example of this is when verification detects errors in the design. In such a case, one has to iterate; i.e., go back and fix the output from the predecessor till the successor is error-free.

Let us now extrapolate for three sequential steps – A, B and C, in which B depends on A, C depends on B; B verifies A, and C verifies both A and B. It is possible that A and B are both done, but there could still be issues when step C is executed. This situation is exactly what happens if A is RTL design, B is RTL verification and C is synthesis. Your design and its functionality may be perfect but it may not be synthesizable; or it may but not meet timing. Or it may meet timing but not area, or power.

If you wait for the entire RTL design and verification to be done before starting synthesis only to discover that there are issues in RTL, you would lose an inordinate amount of time in iterating. Naturally the problem is exacerbated non-linearly as the number of process steps grows, until a process with seventy such steps becomes entirely fragile.

Figure 1: A small part of a complex process with interdependent, iterative steps. This is inherently fragile.

Thus we arrive at the first issue – the lack of immediate feedback about how each process step affects subsequent steps.

The second issue is that a process step needs to be checked by a succeeding step: that is, there is the need for feedback in the first place. What if the need for that could be minimized? What if we could do something whereby we could rest assured that a subsequent step will not catch issues with a predecessor?

A third issue is the time taken to run each process step; often this is not trivial. If you have to wait for hours or days to find out that there is a problem, that’s valuable time that is irrecoverably lost.

Solutions

With the above insights, the solution presents itself – we need to attack the problem on three primary vectors.

Make each step “correct by construction” so that the probability of future failure is as low as possible.
Provide near-instant feedback about subsequent and often distant steps.
Run steps in the background, without user intervention, so that waiting time while a process step runs is minimal.

So this is what we did:

On the first vector, we automated the generation of as many process inputs as possible, especially using conditional builds:
1. Document generation:
  1. Spreadsheets having pin and register information
  2. Plain text generic descriptions of blocks that could be modified via scripts
  3. Figures
2. Code generation:
  1. RTL
  2. Verification
  3. Models
For the second vector, we conceived a process we call “Release Right Now” – which runs all steps from day one as if you had to a final release right now. Naturally, if you tried synthesis without RTL, it would fail; but this is precisely the idea of getting early and frequent feedback. The goal would be to run every process step from day one, as if we wanted to release right now, getting quick feedback. To make this effective we needed to write several quality checking scripts for:
1. Checking inputs to and outputs from each process step for correctness.
2. Checking various design views for correctness and consistency versus a golden reference (often the specification), and versus each other. Examples: LEF versus specification, LEF versus GDS.
3. Checking a view against previous versions of the same view.
On the third vector, we realized that we couldn’t really ask people to run every single process by hand every time a change was made to SVN. Therefore, we automated the running of processses using Continuous Integration, specifically Jenkins with hierarchical build pipelines. CI would then:
1. Automatically run RTL design builds.
2. Automatically run verification suites.
3. Automatically run synthesis and other PD steps.
4. Automatically run QC tools

and so on.

Finally we arrived at a complete solution: Make things correct by construction, run all process steps from day one, and use continuous integration to tie everything together. We named this IPExcel, a simple acronym for IP Excellence.

Figure 2 IPExcel mitigates customer risk with CBC, RRN and CI

Conclusion

To prioritize a customer’s needs by giving them customized and tailor-made solutions often means more work for an IP development team; with inherently fragile processes, tight schedules, inelastic budgets and operational issues, this could mean significant risk for the customer. The alternative is to deliver something that the customer finds difficult to integrate – a customizableIP, thereby reducing the risk for the IP team, but transferring the risk to the customer.

Neither alternative mitigates customer risk – and this is entirely unacceptable to Silicon And Beyond; so we developed our own solution – IPExcel – to deal with it, and we like to think that this is our edge.

Silicon And Beyond offers silicon proven SERDES on advance nodes: