Lean ASIC design: how to keep the NRE low

Companies complain often about the exploding costs of ASIC projects. Often they don’t realise their shallow cost-saving measures actually cause the entire budget to go off the rails. Especially the frugality in hiring single skilled engineers creates the situation we all know from playing Monopoly. Go back to START, do not pass Go, do not collect $$$.
The biggest issue on any project is that none of the team members actually cares or gives a sh*t. A bit of colourful language, but it is an actual truth. If you care about efficiency and methodology, you find that your head meets the concrete wall more often than you want it to. When the software department needs to approve the specification, they are actually working on other projects. They are not interested in the one you are working on. For them, that project starts in a few weeks or months. They will gladly totally change your spec once they start their work on the project. Obviously when some part of the design has finished. Or support departments, like IT, aren’t really interested in making sure your Jenkins jobs run smoothly and with the latest version of the plugins involved.

Moore Factors

There are other factors as well:

  • EDA-tool vendor lock-in, something we had to live with since the nineties. You need to allow your in-house scripts and tools to allow smooth switching of vendors. If you build around the abstraction of underlying tools, you will have some serious negotiation power.
  • Verification and design beginner mistakes create loops where designs are ready. They go into the pipe and return a few weeks later for timing, synthesis and DFT problem fixing.
  • Verification, UVM or otherwise is heavy on servers, RAM, disk space, network and licenses. One of the most common misunderstood features of UVM verbosity is that UVM_LOW is low verbosity. That means that essential messages need to be UVM_LOW. And suppressible messages need to be UVM_HIGH. A regression that fills tens of GigaBytes is not uncommon. Mostly because one misunderstands how the verbosity levels work.
  • In verification, they often use UVM for all verification, even when it is overkill.
  • Meetings for planning the next meeting. Meetings with too many people. Need I say more?
  • No solid onboarding of new resources. And no mentoring. Another big mistake.

Moore Solutions

The result of all this is a budget disaster. A company will spend a lot of money on licenses, IP, wafers, boards, FPGA’s, server/RAM/disk/network increases and many other things. But they do not see the value of engineers, human resources, that know all the tips and tricks to get a chip out on the market fast. Everyone inside the company knows how inefficient walled departments are. If they wanted to solve that, they would have. And employees that do not strive for improvement, they are the ones that stick around. As the saying goes, you get what you pay for. And between accepting zero inefficiency and all inefficiency is a sort of 50 shades of grey.

Building a team around some pillars of strength is the only way to make sure your chip is in excellent hands. But I have seen few instances of super teams. Unfortunately. Still, a lean methodology based on open source tools and deep understanding of the front-end and back-end digital VLSI flow is a fast, more predictable and cost effective road to a silicon success.

Comments (0)

No comments yet.

Leave a comment