See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/271555511

IP cores design from specifications to production: Modeling, verification,

optimization, and protection

Conference Paper · December 2013

DOI: 10.1109/ICM.2013.6734946

CITATIONS READS

11 1,429

2 authors:

Khaled Salah Mohamed Abdelsalam

Siemens Mentor Graphics
163 PUBLICATIONS 596 CITATIONS 28 PUBLICATIONS 116 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Khaled Salah on 24 July 2019.

The user has requested enhancement of the downloaded file.

 1

IP Cores Design from Specifications to

Production: Modeling, Verification, Optimization,
and Protection
Khaled Salah Mohamed AbdelSalam
Mentor Graphics Mentor Graphics
Cairo, Egypt Cairo, Egypt
[email protected] Mohamed_AbdelSalam @mentor.com


IP Specs
Abstract—This paper discusses the IP cores life cycle
process from specification to product which includes Modeling
four major steps: 1) IP Modeling, 2) IP verification, 3)
IP optimization, 4) IP protection. IP product

Index Terms — IPs, Modeling, Verification, Protection Verification

Optimization, Protection

I. INTRODUCTION
Optimization

Hardware intellectual-property (IP) cores have emerged as

an integral part of modern system-on-chip (SoC) designs.
Fig. 1 IP core life cycle process.
IP cores are pre-designed and pre-verified complex
functional blocks. According to their properties, IP cores
II. IP MODELING
can be distinguished into three types of cores: hard, firm,
and soft, where Soft-cores are architectural modules which
are synthesizable and offer the highest degree of
modification flexibility, Firm-cores are delivered as a mix
of RTL code and a technology-dependent net-list, and are A. Modeling Methodology
synthesized with the rest of ASIC logic, and Hard-cores are
mask and technology-dependent modules. The main
differences in design between IC and IP are that in IC To model an IP, we have four design modeling
number of I/O pin are limited but in IP it is unlimited. methodologies as depicted in Fig. 2, ‎[11] :
Moreover, in IP we can parameterize IP Design, i.e, design 1) FPGA-based Modeling: defined by fixed
all the functionality in HDL code, but implement desired functionality and connectivity of hardware
parts in the silicon (reusability). IP cores life cycle process elements.
from specification to production includes four major steps: 2) Processor-based Modeling: Processor running
1) IP Modeling, 2) IP verification, 3) IP optimization, 4) IP programs written using a pre-defined fixed set of
protection. These Steps are elaborated in Fig. 1, ‎[1]-‎[13]. In instructions (ISA).
this paper, the IP life cycle process is discussed in details. 3) ASIC-based Modeling: Silicon-level Layout.
4) PCB-based Modeling: it uses standard ICs such as
74xx (TTL), 40xx (CMOS), it is not VLSI, it is
just discrete components.

978-1-4799-3570-3/13/$31.00 ©2013 IEEE

 2

III. IP VERIFICATION

A. FPGA-Based / Processor-Based IP Verification

To verify an IP, we have two options:

1) Function-based verification (Fig. 3).
a. Simulation-based
b. Emulation-based
c. Accelerator-based
d. FPGA-Prototyping
e. ICE-based
2) Formal-based verification
a. Assertion-based
(a)

Host Computer

Testbench IP
PrRTLo
RTL/TLM
(RTL/TLM) (RTL/TLM)
be
SW Simulator

G
(a) SIMULATION
K
SW
(
Testbench RTL IP
(RTL) (RTL)
HW Emulator
(b)

SW (b) HW EMULATION

Host Computer An Array of FPGAs

Testbench IP
I/P O/P (TLM) SW (RTL)
TBX
SW Simulator HW Emulator

SW (c) Acceleration
SW
FPGA Board
(c)
Real IP
Debugger Probe (RTL)
SW
(Logic HW-FPGA
Analyzer) SW
Prototype

(d) FPGA prototyping

SW
Real HW
IP
(works as testbench)
(RTL)
Data-Cable

SWHW emulator
(e) In-Circuit EMULATION
(d)
(ICE)

Fig. 3 Simulation, Accelerators, Emulation, FPGA prototyping Platform

Comparison.
Fig. 2 (a) FPGA-based Modeling, (b) Processor-based Modeling,
(c) ASIC-based Modeling, (d) PCB-based Modeling.
 3

IPs Functional verification is a key to reduce o Monitor: OVM component that monitors
development cost and time to market. Simulation speed is a the pins of the DUT.
relevant issue for complex systems with multiple 3) QVL checker: Uses the assertion based
operational modes and configurations since in such cases a methodology to ensure the functionality of the IP,
slow simulator may prevent the coverage of a sufficient where it monitors the transactions on an interface
number of test cases in the verification phase. To boost the and check for any invalid operation and outputs
performance of simulation, a number of platforms have error and/or warning messing of bus protocol.
recently attracted interest as alternatives to software-based Self-Checking ensures proper DUT response.
simulation: acceleration, emulation, and proto-typing 4) Negative testing (Error injection): Negative
platforms. Simulation is easy and low cost but not fast testing‎ means‎ “Verify‎ that‎ the‎ IP‎ will‎ produce‎ an‎
enough for large IP designs. FPGA prototyping are fast but, error‎report‎if‎it‎sees‎illegal‎traffic”.‎The‎theory‎on‎
has little debugging capability. Accelerators can improve which negative testing is based depending on the
the performance to an extent where, the DUT is mapped “Assertion-based”‎ methodology.‎ The‎ negative‎
into hardware and the test bench is run on the workstation, testbenches generate illegal traffic; the IP is
if we use real host application SW and real OS SW to supposed to recognize this traffic as illegal, and
access the device is called virtual accelerators. issues the trace error messages.
Emulation improves the accelerators performance, where 5) Coverage: To Checks whether the given property
the testbench and DUT are mapped into hardware, it also or statement is covered during simulation/
provides efficient debugging capabilities over the FPGA emulation. For example, is the sequence shown in
prototypting. For the emulator, many‎ FPGA’s‎ are‎ ever followed by my FSM?.
interconnected together for large gate capacity.
There is another mode of operation for the emulator called
ICE, where in ICE part of the model is a real hardware. B. ASIC-Based IP Verification
The Formal Verification complements simulation-based
RTL design verification by analyzing all possible behaviors
of the design to detect any reachable error states using It is physical verification and it includes:
assertion-based methodology and languages like SVA. This
exhaustive analysis ensures that critical control blocks work I. Design Rule Checking (DRC):
correctly in all cases and locates design errors that may be DRC checks for if layout complies with Foundry
missed in simulation .Moreover, it is static simulator that is rules that is if the layout will be manufacturable.
why it takes less time in simulation than dynamic ones, ‎[1]. Typically this will have width check, density
check, spacing checks etc.
The verification methodologies can be classified into: II. Layout vs. Schematics (LVS):
1) Directed testing (traditional verification): To LVS checks if the layout matches with the
ensure that the IP core is 100 percent correct in its reference. In case of full-custom the reference is
functionality and timing. Verification engineer sets spice netlist which is verified for functionality
goals and writes/generates directed tests for each before getting into layout.
item in Test Plan.
2) OVM/UVM: Reduce testbench development and
testing as it supports all the building blocks
required to build a test environment and it makes C. PCB-Based IP Verification
multi-master multi-salve testing easier. High-level
verification languages and environments such as
SystemVerilog and e, as used in OVM, may be the You draw the schematic of your circuit and verify its
state-of-the-art for writing test bench IP, but they functionality using any circuit simulator like spice, and
are useless for developing models, transactors and after implementing it on PCB, you can verify it using these
testbenches to run in FPGAs for emulation and tips: To perform the PCB verification test, simply compare
prototyping. None of these languages are the PCB with the layout. During this stage, you might also
synthesizable. The component functionalities are want to test the connectivity of each traces to ensure no
as follow: broken traces by using the diode function in the multimeter
o Sequencer: Transaction is an instruction especially those with buzzer sound. This will ease the
from the sequence to the driver (through verification process as once we hear the buzzer sound, you
the sequencer) to exercise the DUT. will know that the trace is connected from one end to
o Driver: OVM component that converts a another. Also, to check for shorts, look at any suspicious
stream of transactions into pin wiggles. traces that are too close and test using diode function in the
o Scoreboard: Gets a copy of the multimeter as well. This time, if your buzzer sounds, then
transaction in the monitor through the you know there is an unwanted shorts.
Analysis port and use that transaction for
analysis purposes.
 4

IV. IP OPTIMIZATION To secure an IP, we need to obfuscate it then encrypt the

contents before sending it to the customer. Obfuscation is a
technique that transforms an application or a design into
A. FPGA-Based IP Optimization one that is functionally equivalent to the original but is
significantly more difficult to reverse engineer. So,
To optimize an FPGA-based IP, we have three directions, Obfuscation changes the name of all signals to numbers and
‎[13]: characters combination. The second level is to encrypt the
 Do not use long loops. whole files ‎[7]-‎[8].
 Store large data in memory not in a register.
 Reduce‎the‎use‎of‎power”**”‎and‎the‎division
“\”,‎instead‎use‎log‎and‎shift‎right. B. ASIC-Based IP Protection
 Do not write long ternary statement.
 Make‎ long‎ “Assign”‎ in‎ a‎ clock‎ statement‎ Circuit Camouflage: let individual logic cells appear
(Pipelining). identical at each mask layer, when in fact subtle changes
 Initialization of all uninitialized registers. are present to differentiate logic functions. Changes are
 Partition a large memory into several small designed so that the reverse engineer is unable to automate
blocks. cell recognition, ‎[9].
 Clock gating.
C. PCB-Based IP Protection
B. Processor-Based IP Optimization
Remove the markings from all the major ICs and mark
 Do not use long loops. them with in-house part numbers. Moreover, encapsulate
 Parallel (distributed) compilation, use the PCB into epoxy (black blobs), ‎[10]. Or, add a few fake
dual or more core feature. layers for complexity.

C. ASIC-Based IP Optimization VI. CONCLUSIONS

 Keep n-devices near n-devices and p-devices This paper discusses the IP cores life cycle process from
near p-devices, ‎[3]. specification to product which includes four major steps: 1)
 Keep nMOS near ground and pMOS near Vdd. IP Modeling, 2) IP verification, 3) IP optimization, 4) IP
protection.

D. PCB-Based IP Optimization REFERENCES

 Separate the digital and analog portions of the [1] R. Reis, M. Lubaszewski and J. Jess: Design of Systems on Chip:
circuits. Design and Test. Springer, 2010.
 High frequency components should be placed [2] Rafla, N.I.; Davis, Brett LaVoy, "A Study of Finite State Machine
Coding Styles for Implementation in FPGAs," 49th IEEE
near the connectors. International Midwest Symposium on Circuits and Systems, 2006.
[3] www.cs.clemson.edu/~mark/464/fab.pdf.
[4] dic.csie.ncku.edu.tw/vlsi.../Introduction_to_SOC.pdf.
[5] H. Choi, M-Kyoon. Yim, J-Young. Lee, B-Whee. Yun, and Y-Tae.
Lee “Formal Verification of a System-on-a-Chip” 2006.
V. IP PROTECTION [6] J.‎XU‎“Obstacle-Avoiding Rectilinear Minimum-Delay Steiner Tree
Construction towards IP-Block-Based‎SOC‎Design”‎ISQED,‎2005.
[7] R. Subhra, S. Bhunia, “Hardware protection and authentication
through netlist level obfuscation”, Proceedings of the 2008
A. FPGA-Based/Processor-Based IP Protection IEEE/ACM International Conference on Computer-Aided Design,
November 10-13, 2008, San Jose, California.
IP vendors are facing major challenges to protect [8] R. Subhra, S. Bhunia, HARPOON: an obfuscation-based SoC design
methodology for hardware protection, IEEE Transactions on
hardware IPs from IP piracy as, unfortunately, recent trends Computer-Aided Design of Integrated Circuits and Systems, v.28
in IP-piracy and reverse engineering efforts to produce n.10, p.1493-1502, October 2009.
counterfeit ICs have raised serious concerns in the IC [9] http://www.smi.tv/SMI_Circuit_Camo_Data_Sheet.pdf
design community. Hence, there is a critical need of a [10] http://www.eetimes.com/electronics-news/4212418/Standard-issued-
for-PCB-IP-protection.
piracy-proof design flow that equally benefits the IP [11] T. Roudier, I. Moussa and P. di. Crescenzo: " IP Modelling and
vendor, the chip designer, as well as the system designer. A Reuse‎for‎System‎Level‎Design”‎published‎for‎DATE‎2003.
desirable characteristic of such a secure design flow is that [12] http://www.esa.int/TEC/Microelectronics/SEM6Z0AMT7G_0.html.
it should be transparent to the end-user, i.e., it should not [13] P. Simpson and A. Jagtiani,‎“How‎to‎achieve‎faster‎compile‎times‎in‎
high-density‎FPGA”‎EE‎Times.
impose any constraint on the end-user with regard to its
usage, cost, or performance.

View publication stats