Being an IP Designer is Like Being a Translator, but Being an SOC Designer is Like Playing Link Game; Chip Design is Quite Simple.

Hehe 🙂, don’t rush, let me explain.

Only When Doing SOC Do You Feel Like You Are Working with Hardware

The daily work of an IP design engineer involves coding, debugging, setting interfaces, only one clock is provided, and no internal frequency division is allowed. No need to handle asynchronous processes. Following the company’s coding standards and flow, synthesis, and formal verification go smoothly, and there will generally be no issues from the backend. Focus on algorithm protocols, concentrate on code design, striving to achieve the same functionality while using 30% less area and being 30% faster than others.

Protocols, code, and waveforms sometimes even give a feeling of working in software.

Only when doing SOC do you feel you are working with chips, dealing with hardware.

Clock resets, subsystem clock scheme design, full chip clock scheme design.

Product-oriented, selecting and evaluating IP based on market demand.

Processor selection, memory capacity and access permissions. Overall SOC address planning, interrupt management.

Designing the SOC bus interconnect matrix and performance optimization assessment.

Generation and management of memory resources.

Writing or providing synthesis SDC, solving synthesis constraints and timing issues.

Power, the PMIC power supply for the entire chip, division of various power domains within the chip, overall SOC low power design, UPF design and verification.

Pinmap, chip layout, pin planning, which can be multiplexed for reuse.

Support in resolving various PR timing and constraint issues that arise during the backend process, all the way to tape-out.

Only after seeing all this do you get the feeling of making chips and dealing with hardware.

SOC Integration

A classic job for SOC engineers is integration, integrating various IPs into subsystems, and integrating subsystems into a full chip; many silicon farmers jokingly say that doing SOC is like playing link game.

Compared to integration, it’s actually more accurate to call it consolidation. SOC consolidation mainly involves integrating people; integrating code is the simplest part. The interfaces of various IPs, clock resets, memory generation management, address division, interrupt planning, and interconnect bus planning. Only by consolidating these resources can the final product be formed.

The number of people you interact with increases; if there’s an issue in SOC verification, they first come to you for debugging, and then find out it’s an IP issue. If software can’t access registers, you debug and discover the offset address is incorrect. For the accelerator EDA FPGA verification platform, they ask for versions, otherwise, it blocks progress. When synthesis fails, they come to you for synthesis analysis again. In the backend, they still find timing issues, asking how to optimize some aspects in the frontend.

Doing SOC mainly involves interacting with people. Time is fragmented.

Writing Documents and Emails More Than Code

Compared to IP design engineers, SOC design engineers indeed write much less code. Most of the work involves integration; the larger code volume is in interconnect buses, which have mature suppliers like ARM. More time is spent on design, such as how many master and slave ports the interconnect bus has, how to tier them, how much outstanding capability to support, and whether to support out-of-order, interleaving, or QoS. Considerations for bus bandwidth design, how to design for optimal performance. Finally, a bus matrix is generated. Then a bit of time is spent on integration. Once the code integration is compiled and passes linting, 80% of the coding work is done.

That’s why meetings, document writing, and emails take up more time than coding. Every day, as you tap away at the keyboard, you might think you’re writing code, but in reality, you’re writing emails and documents.

Good Scripting Leads to Early Work End

Use Perl, makefile, or even alias whenever possible. But I still want to advise everyone: life is short, use Python quickly.

As for editors, well… Vim is the best text editor!

In SOC, you can’t work without scripts. For example, with a bunch of IPs, each port can have hundreds or thousands of lines. How can you manually instantiate them? Writing wires between IPs manually is extremely inefficient and prone to errors. So, make good use of scripts; connecting lines can be generated with just one click. I write a top-level code that has 8000 lines, but I’ve only written a few hundred lines myself, most of which are generated by scripts.

The first principle of doing SOC is to avoid doing repetitive tasks. For instance, if you need to modify a segment of code in hundreds of files, it’s impossible to do it manually; it would take until next year, and manual work is prone to errors. You must write scripts to handle it once and for all.

Version Release Management

SOC engineers need to take on code management and release responsibilities. Unlike IP design, where one design corresponds to one verification, or multiple designs correspond to multiple verifications, they all use one EDA platform, emphasizing small, quick iterations. When a bug is found, it’s mentioned in a chat, and once fixed, it’s immediately uploaded for regression.

The code scale that SOC levels need to release is at least at the subsystem level, aimed at multiple platforms, EDA platforms, accelerator Zebu/Palladium, FPGA platforms, synthesis, etc. With diverse requirements, the code in the codebase is constantly being uploaded, so a stable version needs to be cut out to ensure that multiple platforms can access consistent versions at any time. This requires the use of tags for version releases.

Tags in code version management refer to milestone versions after a certain stage of development, which need to include release notes and version feature descriptions. Each IP and subsystem has a layered release version, ultimately forming a complete RTL SOC version for multiple platforms. There is also a methodology for this.

Overtime Relay Baton

The SOC top is definitely the last to freeze; colleagues in the IP group have already taken a break, and some even have time to prepare for the next version. However, SOC colleagues are still busy cleaning up the aftermath.

Overtime relay baton: algorithm overtime – IP design overtime – IP verification overtime – SOC design overtime – SOC verification overtime – backend overtime.

If upstream delays occur, the project cannot be delayed, and time must be compressed downstream. Backend colleagues are already crying in the restroom.