Different Roles, Different Tools

A question often posed is: does the use of tools and processes change as you go from block level to subsystem and chip level and as you add software to your system on chip (SoC)? And of course, the answer is that things change a lot.

The primary differences between designing individual blocks and designing a big chip are that blocks tend to be designed by individual engineers or very small groups, whereas a large team is needed for designing a whole chip. So, the tools needed often change to those that deal with communication and coordinating the large amount of information that needs to be compiled and maintained about the design.

It is like comparing the design of a big chip to designing a house. You need blueprints. You need to think through the architecture. And someone overseeing the overall project must communicate what is needed to the people doing the actual work in a way that makes sense to them and where their knowledge and expertise can be fed back into the overall architecture.

The people building the wall or digging the foundation may or may not be that interested in what the overall building will look like or how it will work, but whoever is architecting it needs to be interested in anything that arises as each of the craftsmen involved are doing their work. If they find the foundation can’t be dug deep enough or that the walls can’t be put just where they need to go, that needs to be understood and elements of the architecture rethought or there could be a lot of problems down the line.

The same is true with chip design. A lot of designers are only focused on the task they are currently working on. This could be analog, digital or RF. It could be front end design or verification. It could be test insertion or back end layout. Whatever it is, usually they are going to have a set of requirements to meet, some interface defined, and they will have a very specialized set of tools to help them carry out their work. And in a design that is pushing what can be done with the chosen technology, they will not always be able to meet all these requirements. In fact, if they always do meet the requirements, questions should be raised as to why the targets are not being pushed a bit more.

Most readers will be familiar with the languages and tools engineers use on these tasks. Verilog/VHDL or SystemVerilog for front-end digital design. Or Spice simulation for analog/RF blocks. Or EDA vendor tools for things like formal verification and static timing analysis.

These tools can be complex and require specific expertise to use well. They are often wrapped in layers of tools and scripts specific to a particular company. Of course, they greatly enhance productivity after a suitable period of initiation by new engineers into their mysteries.

But what of the tools and processes used to pull all these different tasks together? How do we make sure that when everyone has done their job, and that we get the chip we originally planned on building?

Quite often on a smaller chip, there will not be a lot of thought or time given to this. There will usually be one or more documents that outline what is being built. There will be numbered requirements that can notionally be tracked through the design. There will often be spreadsheets with lists of pins or registers. And there will be usually be one person (or a very small team) who has the complete design in their head. The architect.

The architect is often the first engineer involved on a given design. They will have helped flesh out the high-level picture of what needs to be done. They will interact with the different individuals doing the work to create the chip. And all along the way they will need to keep firmly in mind that picture of what this chip is and how its different parts should come together. Because along the way there are going to be bumps in the road. Assumptions that were made on what was low power or low latency or low risk which will turn out to be wrong. And it is the architect’s job to see that this is happening and redirect efforts to get the results needed while maintaining the vision of the chip.

And so, we have a very different set of tools to support this. Requirements tracking systems like Doorstop. Ticketing systems like Jira. A multitude of Word documents. But the most critical tools that an architect uses are all communication tools. On a big chip, it is only by continuous communication with all the engineers that you can ensure that everyone’s actions are building towards the harmonious completion, and ensuring any flaws or inconsistencies are dealt with.

That communication may be through code reviews (although you’d better already know about any big ‘gotchas’ long before they get to the stage of a code review), through regular meetings with engineers, or a culture of reporting issues as tickets as they are found and regularly reviewing and dealing with them.

Here at Adesto we have created our own set of tools for dealing with complex SoC designs for our customers. Our in-house developed Engage platform allows us to deal with tickets and share documents securely with customers. Our internally developed Hephaestus tool lets us take customer requirements, map them onto system and block level requirements and communicate design intent back and forth between individual engineers working on the chip. And after more than 30 years designing chips our strong culture of engineering excellence means from day one that all of our engineers are inculcated in the need for regular review and communication to ensure we produce only the best first-time right silicon.

But most importantly we have a cadre of skilled and experienced chip architects that are familiar with all aspects of chip design and can therefore speak to individual engineers in their own language whilst still being able to pull together the design and explain it in a way that allows the customer to understand and control what they are going to get.

So, to answer the question of how tools and processes change as you start to look at architecture, they start with being obsessed with the block of engineering right in front of you. Then they move to focusing on a whole set of communication and organizational skills and tools so that you can create the incredibly complex mosaic of combined skills and disciplines that is a modern SoC.