Are SoCs, MCUs, and CPUs Typically Designed Using FPGAs?

When discussing the design of System-on-Chips (SoCs), Microcontrollers (MCUs), and Central Processing Units (CPUs), the role of Field-Programmable Gate Arrays (FPGAs) often looms large. In this article, we will explore the comprehensive process of SoC design, the unique context of FPGAs in their design, and the trade-offs involved in choosing between FPGAs, SoCs, and MCUs for different applications.

Understanding the Design Flow: An Emulation with FPGAs

To properly design and verify complex SoCs, MCUs, and CPUs, a rigorous design flow needs to be established. This process typically includes several crucial steps:

Create RTL and Testbenches

The design flow begins with the creation of Register-Transfer Level (RTL) code and testbenches for sub-circuits. For the complete core design, these testbenches become even more critical as they ensure that all components work cohesively. This phase is often iterative, with adjustments made based on test results and simulation outcomes.

Create Regression Tests

Regression tests are essential in verifying the functionality of the RTL core. These tests are designed to run continuously, ensuring that any changes in the design do not introduce any new bugs or modify the original behavior unintentionally. The success of these tests is a testament to the robustness and reliability of the design.

Create an FPGA-Based Prototype

The next step involves creating a prototype using FPGAs. An FPGA board is mounted on a circuit board, and the core is encapsulated within the FPGA. This allows real-world interfaces and serial communications for testing, thereby providing a comprehensive evaluation of the core's functionality in a controlled environment. This practical testing phase is where many design issues are first identified and resolved.

Synthesize and Validate the ASIC

After the FPGA-based prototype, the design is synthesized into an Application-Specific Integrated Circuit (ASIC). The synthesized design is then verified against the regression tests, with special attention paid to memory and clock gating mechanisms that may differ between the FPGA and the final ASIC. This phase involves comparing the gate-level model with the behavioral model to ensure the design is correct.

Static Timing and Slew Rate Analysis

Static timing and slew rate analysis are conducted to assess the timing integrity of the design. This analysis is typically performed by the foundry to ensure that the chip meets the necessary timing requirements. However, some static timing analyses can be overly pessimistic about hold times, leading to spurious delays. In such cases, it may be necessary to ask the layout team to avoid adding delays based on pessimism.

Rerun Regression Tests for Setup/Hold Issues

Using extracted timing, regression tests are rerun to check for any setup/hold issues that might not have been discovered during the initial static timing analysis. This ensures that the final timing constraints are accurately met.

Trade-offs in Design Process and Mass Production

While the emulation with FPGAs is crucial for early-stage testing and validation, the design process naturally evolves with the requirement for mass production. Key considerations include:

Chip Area Optimization

During mass production, the design must be optimized for chip area to ensure the most cost-effective and high-performance solution. This involves careful layout and design optimization to minimize chip size while maintaining performance and reliability.

Cost Considerations

FPGAs are more expensive due to the specialized hardware required for interconnection and the computational overhead. However, some FPGAs now include MCU functional blocks, making them a cost-effective solution for low-volume applications where custom peripheral design is needed. For instance, in high-computational-demand scenarios like mobile crane chassis with multi-axle steering control, FPGAs provide a balance between performance and cost.

Flexibility and Specialization

For low-volume, high-computational requirements, FPGAs can be a viable option. They offer the flexibility to handle complex computations and specialized algorithms using hardware implementations for functions like Sinus tables, which are faster than software implementations. This can significantly impact real-world performance, especially in applications where mechanical tolerances and speed are critical.

Conclusion

The choice between using FPGAs, SoCs, MCUs, or CPUs depends on the specific application requirements. While FPGAs are invaluable for early-stage testing and validation, SoCs and MCUs offer a more optimized and cost-effective solution for mass production. Understanding the intricacies of the design process can help in making informed decisions, ensuring the best possible outcome for each project.