If we consider that the SoC design consists of processor, video codec, DDR controller, and other functional modules. For fast-cycle designs, the general industry practice is to have available IPs. Considering that the DDR memory controller IP has already been launched in the market, we do not design the memory controller from scratch during the design process, but rather design available functionalities based on industry practices and time-tested IPs.

The provision of IPs is as follows; the prototyping team needs to use IPs during different stages of the design cycle.

• RTL IP Source Code: Open-source versions or licensed versions of the obtained IP source code. Source code using VHDL or Verilog is available.

• Soft IP: This type of IP core is sometimes encrypted and requires some processing during design and reuse.

• IP in Netlist Form: Available in the form of pre-synthesized netlists or Synopsys GTECH for SoC components.

• Physical IP: Also known as hard IP, these are pre-laid out by foundries.

• Encrypted Source Code: RTL protected with encrypted keys must be decrypted to obtain the RTL source code.

The following are key points to consider when selecting IPs.

• Functional requirements and features supported by the IP.

• High-speed interfaces suitable for IO and other IPs.

• Forms available for the IP. That is, whether adjusting the IP is possible to improve performance.

• What kind of configuration environment the IP has.

• What debugging and testing features are available in the IP.

• What kind of documentation the IP vendor provides?

• What electrical characteristics does the IP have?

• What environment is available for the IP?

• Different clock and power domains for the IP.

• What are the timing characteristics and IO delays of the IP?

The following are some strategies that can be used in the IP design process. Although IP design and verification is a very time-consuming phase, if the design requires new functionalities, IP design and development must be carried out. For instance, when new standards appear in the market, design companies may conduct IP design and development.

1. IP Design and Reuse

Most SoC design teams always use third-party functional and time-tested IPs. In designing complex application-specific integrated circuits, the reuse of IPs can be achieved. Hard IP or soft IP can be utilized during the design and prototyping phases, and reuse helps achieve this.

• Focus on designing additional support features to accelerate the development cycle.

• Reduce time to market.

• The design team will be able to spend more time on low-power and high-speed designs.

• The design team will be able to leverage designs using multiple clock domains and multiple power domains.

• Challenges in physical design, such as fixing timing conflicts, require more time investment during the physical design process. Therefore, using IPs significantly reduces time.

2. Hardware-Software Co-design

This is also known as design partitioning, where the design must be divided into hardware and software parts. Important considerations when partitioning the design include how to achieve parallel execution in the design? In the current scenario, since SoCs are complex, the parallelism in the design can be utilized to achieve functionalities, which in turn can enhance design performance. During the partitioning phase, complex computational tasks or algorithms need to be divided. Most complex computational blocks require hardware implementation. Design partitioning is a critical and decisive phase in defining what needs to be implemented in software and what needs to be implemented in hardware.

For example, the design of a video decoder needs to support multiple frames. This video decoder can effectively leverage hardware implementation and even combine the parallelism of the decoder. For high computational DSP functional blocks that require FFT, FIR, IIR, or high-speed multipliers, hardware implementation can be utilized.

Let’s consider the scenario of protocol implementation; most protocols like Ethernet, USB, and AHB can be effectively implemented through hardware-software co-design. These algorithms should undergo functional timing verification. This has advantages in overcoming and reducing delays in the design. For most protocol implementations, considerations must be made.

The main challenges in hardware-software design are the analysis of throughput and power requirements. For instance, in the scenario of SoC design, fixed-length data packets need to be transmitted within fixed time intervals. If the design is implemented using hardware, then it is crucial to minimize interactions between hardware and software. To minimize interactions between hardware and software, FIFO buffers and timers can be used as a strategy.

3. Interface Details and Timing Requirements

For each IP, there must be functional and time-validated bus interfaces. In most applications, high-speed bus protocols are used. These protocols require verification of the functionality and timing correctness of the design. To achieve high-speed data transmission, IO interfaces need to be targeted. There are many different types of IO interfaces in SoC design. These IO can be general IO, differential IO, and high-speed IO.

Reset Clock Requirements

The clock distribution network provides a uniform clock skew to all registers in the SoC. The clock strategy plays a crucial role in overall design performance. Using clock tree synthesis methods, appropriate clock trees can be utilized to achieve uniform clock skew. Whether to use a single clock structure or multiple clock domain structures needs to be decided at the architectural level. The use of synchronous or asynchronous logic also needs to be defined at the architectural level. Reset can be either asynchronous or synchronous and needs to be defined during the architecture stage of the SoC.

4. EDA Tools and License Requirements

Select necessary EDA tools and licenses for SoC FPGA prototyping design and ASIC migration. Most industry-standard tools include:

Simulator: Questasim, VCS, ModelSim

Synthesis: Synplicity Pro and Synopsys DC

STA: PrimeTime (Synopsys PT)

5. Development Prototyping Platforms

For SoC and IP verification, necessary prototyping and development platforms should be used. Prototyping platforms may include using multiple FPGA boards to implement and verify the SoC, required IPs, required DSP functionalities, needed memory, and required general processors. The availability of the required prototyping boards with necessary interfaces is essential for implementing the SoC and debugging or testing setups.

Most SoCs are tested using testing setups composed of available EDA tools and logic analyzers. At the beginning of the SoC design cycle, architects analyze design and functional requirements and design the prototyping platform based on estimated needs for speed and gate count. The most important factors here are time to market, budget allocation, and design time requirements. If DSP functionalities are available in the FPGA, it is wise to implement DSP functionalities on the FPGA.

6. Development Testing Platforms

For complex gate-count SoCs, necessary test cases need to be developed with the required test vectors. Features can be extracted using top-level functional specifications, and the required test cases can be documented in the test plan. The developed test vectors can significantly impact the quality of verification to achieve coverage goals. Test cases can be recorded as basic, secondary, and random test cases. Coverage-constrained random verification with the required test cases can be achieved.

7. Development Verification Platforms

Use verification languages such as Verilog and high-level verification languages like System Verilog or System C; for early detection of bugs and achieving coverage goals. In large gate-count SoC designs, capturing early bugs in the design has always been crucial for improving the overall design quality of the verification plan. The overall goal is to achieve the required functionalities of the design in less time. A verification environment needs to be built to achieve coverage goals. The verification architecture may include necessary bus functional models and drivers, monitors, and scoreboards for robustly checking design specifications. The overall verification plan of the environment and the created goals aim to achieve automation to minimize the time requirements for completing functional checks in a shorter duration.

Taking SoC design as an example, which includes a processor for general computing, a DDR3 memory controller, and video encoder and decoder IP. If the design requires 200,000 logic gates, then this design cannot fit into a single Artix-7 FPGA. In this case, we need to use design partitioning to target designs utilizing multiple FPGAs. For most SoCs, we need to use multiple FPGA architectures for prototyping. FPGAs can be connected using ring or star topologies.

The following are some important suggestions for prototyping using multiple FPGAs.

• Better Understanding of the Design: Try to understand the analog and digital functionalities of the design and partition the design into analog and digital domains. Using partitioning tools can yield better results. Automated partitioning tools can be used for better partitioning across continuous boundaries.

• Analog Functionality and Additional Interfaces: FPGAs are ideal for implementing digital designs, but actual designs contain both analog and digital modules. Therefore, try to choose additional sub-boards to connect ADC and DAC.

• Effective Use of Resources: When performing partitioning, try to adopt strategies that allow EDA tools to have up to 70% of the FPGA resources. This will allow the prototyping team to add BIST and debugging logic during the startup phase.

• IO and Pin Multiplexing Requirements: The speed of IO is a crucial factor determining the overall performance of the prototype. For multiple FPGA designs, additional multiplexing strategies need to be deployed.

• Clock Strategy: Depending on the requirements of star and ring topologies, it is necessary to consider clock strategies for multiple FPGA designs. Clock skew and other board delays need to be considered during debugging and testing phases.

• IO Interfaces: At the SoC architectural level, decisions should be made regarding the prototyping feature requirements. When designing prototypes using single or multiple FPGAs, considering IO speed, IO voltage, bandwidth, clock and reset networks, and external interfaces is always a better choice!

• FPGA Connectivity: Prototyping teams need to consider the ring, star, or hybrid connectivity of prototypes using multiple FPGAs.

Here are some key points:

(a) Ring Connectivity

In this type of arrangement, multiple FPGAs are connected in a ring.

This type of connection increases overall path delay. When signals pass through the FPGA, equivalent prototyping logic can be similar to priority logic. Compared to other types of single boards, this type of connection is slower.

If we try to visualize ring connectivity, at a high level, we can consider using pin connectivity of this type of internal connections of the FPGA. The wastage of IO cannot be limited to this connectivity. The FPGA is at the lower end; IO will be wasted, and for board designers and layout teams, connecting these IO to high impedance state is an additional cost.

(b) Star Connectivity)

Due to direct connections with another FPGA, this type of internal connection of FPGAs is faster than ring arrangements. To achieve better prototyping performance, use high-speed interconnections between FPGAs, and configure unused pins to high-impedance states.

(c) Hybrid Connectivity

In the design and layout of the board, we can use a mix of ring and star connections. This type of connection can offer moderate performance.

The boards supplied by vendors on the market have fixed connections that may not be suitable during the prototyping process, as they do not meet specifications and requirements. In such cases, depending on the complexity of the design, it is better to choose interface connectivity for better prototyping performance.