What should you consider when building an SoC?
By Alasdair Olway
A system on chip (SoC) is exactly as its name suggests, an entire system on a single silicon chip. This chip or integrated circuit (IC) holds many components of a computer designed to work together to achieve a common goal. The first part of the term - System - says that it's all about a complex electronic assembly, while the last part - Chip - tells you that all the components of that system are squeezed together on a single IC. Depending on the kind of system that has been reduced to the size of a chip, it can perform a variety of functions including artificial intelligence, signal processing, wireless communication and more.
There is no simple, easy answer to this question, which reflects the nature of SoC design itself, in that it is a complex, multi-dimensional topic with many variables that have to be considered. As technologies advance so does the difficulty in designing an SoC. In this blog I will cover some key ideas that I believe are useful throughout most, if not all, SoC designs that will enable you to successfully understand the design and implementation process of your own SoC.
1. The Plan
Before we dive in, I’ll add a caveat – the specification and the schedule can, and probably will, change over time. This is not a bad thing but is something to be embraced, understood and allowed for.
With that in mind, a detailed and well-written specification is key at the start of any SoC design. You can have a game-changing idea, but if no one understands what it does and how it works, it’s going to be very hard to see that idea realised in silicon. Having a detailed specification, allows someone reading it to understand exactly what the SoC does. As the idea goes through the different stages of design, the specification is likely to evolve. Not only getting more in-depth as you learn about the how the system works in practise but also improving the descriptions of modules.
The specification should also be well-written. Simply put, if an engineer, who is designing a block according to the specification, cannot understand clearly what it does then the block is likely to not have the expected behaviour. Having the specification peer-reviewed by a person who did not write the specification can be a really useful tool to iron out any issues that the author may have missed.
A successful SoC design should also include a schedule. Having a schedule that documents expected timings for each part of the project is a valuable tool for greater decision making. A key part of the schedule, and one that may get overlooked, is flexibility. This is flexibility in the sense of having time built into the schedule such that bugs can be dealt with and implementations can be improved if they are found lacking. This flexibility will allow for greater risk management and a more accurate time scale for the project. It also enables stages to be rescheduled and sometimes run in parallel to achieve the required time frame.
2. The Design Process
It would be a major understatement to say that the success of the SoC depends largely on the design process, as this is where the leg work of the system gets completed.
Many books have been written on team structure and dynamics, but I just want to focus on some of the simpler points – having a team with the right skills and the communication within that team. Now these might seem obvious but they are important enough that they should be mentioned regardless.
The design team is more than just the front-end design, it also includes verification, DfT, physical design and software. All these parts need to be functioning correctly and working together well for an SoC to be long-lasting and well-built. It’s important to have a mixture of skillsets within a team of experienced, capable engineers. Similarly, the next stage of taking the design from specification to foundry is no easy task, so the need for a closely integrated cross steam structure continues to be vital.
It’s also very important to make sure each team can communicate with one another effectively. A change to a block may be needed because of a revelation from the physical design team. Effective communication here is important as it means the change can be explored, designed, verified and implemented in as small a time frame as possible.
3. The Software
Last, but certainly not least, is the part that software design must play in the design of an SoC. An often-overlooked part of the design process, it a key part of an SoC and can make or break a design.
Let’s starts with the boot ROM. Boot ROM is a small piece of memory that contains code that the CPU needs at start-up. This piece of code will initialise all the buses, memories, and peripherals that the SoC needs to boot correctly. This must be nailed down as early as possible as it vital to the design. It can be used as a way of understanding what the initial state of the system should be, which gives us a solid base to work out from.
Software security is another important topic to consider when building an SoC. I won’t touch on the specifics on software security here, only that it makes for a successful SoC because of the futureproofing that it allows the system to have. The software we load into memory will probably change between customers, so having a way to protect the device from incursions, while still allowing official software changes and upgrades, is an excellent way to keep your SoC a viable choice for customers into the future and will extend the products lifetime.
There is no simple, easy answer to this question, which reflects the nature of SoC design itself, in that it is a complex, multi-dimensional topic with many variables that have to be considered. Moreover, as technologies advance, designing an SoC gets harder as does the answer to this question.
It would take several books to talk in detail about every aspect of SoC design and the technologies that we can use to create them. However, what I will cover are some key ideas that I believe are useful throughout most, if not all, SoC designs that will enable you to successfully understand the design and implementation process of your own SoC.
So, whilst there isn’t an easy answer to this question, the ideas covered in this blog are those that I believe will be applicable in most, if not all, SoC designs. Ideas such as the plan and the design process are examples of this; having a firm grasp of these will allow your project to run as smoothly as it can. Furthermore, considering the software used on your SoC allows for you to have a solid, secure base to work out your implementation from. From these ideas, I hope that you been given new inspiration to go out and design a successful SoC