Increased design complexity, shrinking design cycle, and low cost—this three-dimensional demand mandates advent of system-on-chip (SoC) methodology in semiconductor industry. The key concept of SoC is reuse of the intellectual property (IP) cores. Reuse of IPs on SoC increases the risk of misappropriation of IPs due to introduction of several new attacks and involvement of various parties as adversaries.
Introduction
In the recent era of automation, there are urgent needs of highly complex and application-specific multifunctional chips in every sphere of life. Customer’s specification for complex chip causes explosion of gates on a single chip, advancement in process technology, and requirement for integrating heterogeneous technologies. The increased design complexity consequently needs more design effort. However, requirements for application-specific chips in every sphere mandate enhanced productivity and low cost. The only way to bridge the gap is to adopt hierarchical approach and reuse of already designed, optimized, and verified design components or fabricated and tested hardware cores to meet specification of a complex chip in time and at low cost. The way of designing an electronic system from the scratch has been replaced and system-on-chip (SoC) has emerged as an inevitable solution, where the major functional components of a complete end product are integrated into a single chip. Already-designed electronic components or fabricated hardware chips to be reused for these functional components constitute intellectual property (IP) cores. If an IP remains in electronic form, it is either a circuit description in hardware description language, that is, HDL (soft IP), may be any form of netlist, placed and routed design (firm IP), or design layout (hard IP); otherwise, it remains as hardware chip constituting a hardware IP core. A design tool is also treated as an IP. Soft IPs are more flexible but less optimized; on the other end, hardware IP cores are less flexible but more optimized. To be reused, an IP should have complete specification and proper documentation. The forms of the IPs suitable for reuse specifically on SoC will be discussed later.
An SoC usually contains reusable IPs, embedded processor(s) (a general-purpose processor and multiple special-purpose processors based on requirements) or controller(s), memory elements (SRAM, ROM, etc.), bus architecture (for interfacing IPs and other components on SoC), mixed signal blocks, programmable blocks (FPGA), voltage level shifter, clock circuits, test architecture, and so forth. An SoC may easily be enhanced by integrating more IP components with it. Furthermore, a number of SoCs can also be integrated to realize a more complex system.

As reuse of IP is promoted in SoC environment, access control becomes essential for the IPs. In order to reuse an IP component on SoC, the SoC company should purchase the IP from its genuine vendor in legitimate way. Further, its reuse in SoC design house, in fabrication facility, and in SoC application environment should be protected. Unauthorized reuse of an IP by an SoC company and any other adversary renders loss of revenue to the genuine IP owner (IP vendor/IP creator), thus causes economic damage to the IP vendor.
An IP may be infringed during its design as well as during designing an SoC reusing that IP. So, in silicon industries, first, IP protection (IPP) techniques have been incorporated in VLSI design flow, and later on, security considerations have been extended for SoC design methodology. IPP techniques often rely on standard security mechanisms like cryptography, obfuscation, watermarking, fingerprinting, and so forth. Design concepts, system level knowledge and mechanism, design or chip level analysis, and characterization sometimes form the basis of the IPP techniques.
Due to introduction of reuse techniques in designing an electronic system, design methodology undergoes transition from timing-driven ASIP (application-specific IP) design to block-based design of an SoC and then to platform-based design of a plug-and-play SoC. An ASIP, moderate in size and complexity, is optimized through synthesis, placement, and routing with great design effort to act as an IP component for reuse in the other two design techniques. In case of block-based design (BBD), an electronic system is partitioned into functional components, and these are mapped into available IP components (mostly firm IPs). For these firm IPs, their placements are retained, and routing, timing, and so forth are reoptimized contextwise for the overall optimization of these factors for the entire system. Finally, this software/hardware tradeoff in BBD is transformed into platform-based design (PBD), which provides an extensive and planned support to reuse of either hard IP or hardware IP on SoC. Here, based on functional requirements, IP blocks are chosen in a way so that each block can be well interfaced with its target blocks by designing suitable system architecture, their delay/power profiles satisfy constraints determined by the entire PBD, their test options are compatible with design-for-test mechanism on PBD, and those can function in one of the clock domains and voltage domains easily supported on SoC. In PBD, placement, routing, timing, delay calculation, physical verification, and test architecture construction all are performed hierarchically, with the only objective of properly designing the system (bus) architecture to realize the interface constraints .
Reuse on SoC enhances productivity but not in a linear way; the reasons are the multiple design challenges faced in SoC design methodology and the overhead of integrating IPP techniques with the design flow. Design challenges include integration of heterogeneous device technologies and protocols, maintaining signal integrity, issues related to testing, clock timing, and voltage regulation [An IP is to be integrated with the other components on SoC, so it needs to satisfy several design constraints. Moreover, IPs are individually optimized, but the objective of SoC is to optimize the performance of the entire system obtained from integrating the IPs. Furthermore, it is to be noted that SoCs are mostly application specific, and, therefore, application of SoC defines the IPs. Different application needs different architecture, for example, buses, I/Os, processors, memories, and so forth. So, in order to meet constraints determined by the application of the SoC and the other components on the SoC, firm IPs are often partially redesigned. For hard IPs, one may use interface wrappers, which incur area overhead; otherwise, interface definitions of the available IPs are redesigned.
In IP-based SoC design flow, both software and hardware development are required (software/hardware codesign). Depending on the application on SoC, IPs close to requirement specifications are chosen, these are partially redesigned to be compatible for reuse on SoC, thereby transformed into virtual components (VCs). VCs are emulated with programmable hardware on SoC and then fabricated to ICs. On the other hand, on SoC, bus architectures are designed to completely satisfy interface constraints, and other design works are completed, that is, placement of voltage level shifters, clock dividers, and so forth, and finally the SoC is fabricated and the firmware designers write the drivers for the components of SoCs .
SoC Prototyping

FPGA based SoC/ASIC prototyping is the methodology to prototype SoC or ASIC design on FPGA for hardware verification and for early software development. It has become a main stream for SoC design and can greatly reduce the SoC design cycle.
SoC prototyping provide the SoC developer a system to verify the functionality of the SoC. Once the functionality is verified, the hardware and software development can begin in parallel. Using the SoC prototype as a software development platform is not only orders of magnitude faster than computes simulation but can surface errors sooner since the software is running in real system conditions. This has a huge impact on SoC development schedules as software is increasing consuming SoC development resources.