System-on-Chip Design: Integrating Complex Systems into a Single Silicon Solution
If you ask people what defines a system-on-chip (SoC) design, you’ll probably get one of three responses. Many contend that any SoC must contain at least one processor so there’s a complete hardware-software system in a single chip. A related response is that it’s one chip with everything that’s traditionally in a system. The third answer is that an SoC is a bunch of functions that used to be in separate chips integrated into one chip. I’d like to explore this third idea in today’s post.
Integrating Chips Together
For a start, let’s set aside multi-die designs, in which multiple dies are connected within a single package using multi-chip module (MCM), 2.5D, or 3D technology. I’m talking about a single die that combines the functionality of multiple chips. The key point is that you’re not simply reusing existing dies and packaging them together. You are creating a new SoC by merging functions from discrete chips onto a single die.
This process has some interesting implications. One possibility is that you pick up the layouts for the smaller chips, massage them to mesh together in the new die, and reuse as much as possible. This can work if all the earlier chips were in the same technology, but this is highly unlikely. One of the reasons you look at combining chips is that new process nodes enable bigger designs. So you’re probably going to have to rework the older designs.
Since virtually all digital design these days is done using register-transfer-level (RTL) code and logic synthesis, mapping to a new node or even a completely different technology is straightforward. This will result in a new layout that’s much better optimized for the new SoC than the first possibility I mentioned. Unfortunately, synthesis is much less common for analog design. You’ll have to redesign most of your analog circuitry from the older chips targeted for the technology of the SoC.
Plenty of Design Flexibility
Since you’re going to resynthesize the RTL design anyway, you have the option of making changes to it to create a better SoC. There is value in using a proven design as is, but most likely you’ll want to add new functionality and tweak the older designs in response to competitive pressures and new market opportunities. You might end up with a design hierarchy that’s more complex than a simple interconnection of the original designs.
Control and status registers (CSRs) are one area where change is beneficial. These form one side of the hardware-software interface (HSI), which is how your drivers and embedded code configure and control the operation of your hardware. In many cases, you’ll have overlap in CSRs across the original chips, and you’ll be adding new registers for the added functionality. It probably makes sense to merge all the CSRs into a single memory-mapped register set.
An argument against this is that you’ll have to change the drivers and embedded code used for the separate chips to communicate properly over the new HSI to the merged CSRs. I would argue that this is probably a good idea anyway. Again, you’re likely to have overlap, and perhaps name collisions, in your code, and you’ll need to write additional code for new functionally. The software side of your HSI will be much easier to manage with a single application programming interface (API) for your CSRs.
Agnisys Can Help!
If you find yourself developing an SoC based on older, smaller chips, our IDesignSpec™ (IDS) Suite can do a great deal to help you. The diagram below summarizes how this process works. First of all, we can generate the RTL design for your merged register set. We support a wide variety of input formats to define these registers. You can reuse any existing register specifications in standards such as IP-XACT and SystemRDL, and it’s well worth your time to capture the rest in an executable format.
Once you have a complete register spec, you just push a button and IDS generates the RTL code, all ready for synthesis. We also generate tests and testbenches to verify your registers, plus high-quality documentation. But that’s not all. We also generate the C/C++ code to configure your CSRs, program them to control your hardware, and gather back status. We do the hard work of creating SoC-level headers, APIs, tests, and validation environments to verify the hardware and software together.
We also help you beyond your registers. We have a broad portfolio of configurable blocks in our silicon IP portfolio that will save you a lot of design time. Finally, IDS-Integrate™ automatically generates the complete top-level RTL design for your chip, interconnecting all your IP blocks, CSRs, and custom logic. Anytime that you change your design hierarchy, modify your registers, or need different IP blocks, you just push the button again and IDS re-generates everything to reflect your changes.
Summary
The size and complexity of modern SoCs is simply amazing. You can benefit from combining multiple chips from older technologies into one SoC design. You save board space, reduce propagation delays, and eliminate duplication. IDS makes this process much, much easier through specification automation using cutting-edge AI technology. Please contact us to learn more.
Related Semiconductor IP
- Rad-Hard GPIO, ODIO & LVDS in SkyWater 90nm
- 1.22V/1uA Reference voltage and current source
- 1.2V SLVS Transceiver in UMC 110nm
- Neuromorphic Processor IP
- Lossless & Lossy Frame Compression IP
Related Blogs
- Cadence Generative AI Solution: A Comprehensive Suite for Chip-to-System Design
- Semidynamics: A Single-Software-Stack, Configurable and Customizable RISC-V Solution
- ARM's foray into the server market
- T&VS provides solution to Post Silicon Validation
Latest Blogs
- Silicon-proven LVTS for 2nm: a new era of accuracy and integration in thermal monitoring
- System-on-Chip Design: Integrating Complex Systems into a Single Silicon Solution
- Rethinking AI Infrastructure: The Rise of PCIe Switches
- Verification of PCIe's TDISP for Device Interface Security
- Comcores: The One-Stop Shop for Automotive Ethernet and Security