Editing System on a chip (section)

== Design flow ==
{{More citations needed section|date=March 2017}}
{{Main|Design flow (EDA)|Physical design (electronics)|Platform-based design|l1=Electronics design flow|l3=}}{{See also|Systems design|Software design|label 2=Software design process}}
[[File:SoCDesignFlow.svg|upright=1.3|thumb|SoC design flow]]

A system on a chip consists of both the [[electronic hardware|hardware]], described in {{Section link||Structure|nopage=y}}, and the software controlling the microcontroller, microprocessor or digital signal processor cores, peripherals and interfaces. The [[design flow (EDA)|design flow]] for an SoC aims to develop this hardware and software at the same time, also known as architectural co-design. The design flow must also take into account optimizations ({{Section link||Optimization goals|nopage=y}}) and constraints.

Most SoCs are developed from pre-qualified hardware component [[Semiconductor intellectual property core|IP core specifications]] for the hardware elements and [[execution unit]]s, collectively "blocks", described above, together with software [[device driver]]s that may control their operation. Of particular importance are the [[protocol stack]]s that drive industry-standard interfaces like [[Universal Serial Bus|USB]].  The hardware blocks are put together using [[computer-aided design]] tools, specifically [[electronic design automation]] tools; the [[modular programming|software modules]] are integrated using a software [[integrated development environment]].

SoCs components are also often designed in [[high-level programming language]]s such as [[C++]], [[MATLAB]] or [[SystemC]] and converted to [[Register-transfer level|RTL]] designs through [[high-level synthesis]] (HLS) tools such as [[C to HDL]] or [[flow to HDL]].<ref>{{Cite news|url=http://www.eejournal.com/archives/articles/20110825-mathworks/|title=Best Practices for FPGA Prototyping of MATLAB and Simulink Algorithms|date=August 25, 2011|work=EEJournal|access-date=2018-10-08|language=en-US}}</ref> HLS products called "algorithmic synthesis" allow designers to use C++ to model and synthesize system, circuit, software and verification levels all in one high level language commonly known to [[computer engineers]] in a manner independent of time scales, which are typically specified in HDL.<ref>{{Cite web|url=https://www.eetimes.com/document.asp?doc_id=1271261|title=The 'why' and 'what' of algorithmic synthesis|last=Bowyer|first=Bryan|date=February 5, 2005|website=[[EE Times]]|access-date=2018-10-08}}</ref> Other components can remain software and be compiled and embedded onto [[Soft microprocessor|soft-core processors]] included in the SoC as modules in HDL as [[Semiconductor intellectual property core|IP cores]].

Once the [[Computer architecture|architecture]] of the SoC has been defined, any new hardware elements are written in an abstract [[hardware description language]] termed [[Register-transfer level|register transfer level]] (RTL) which defines the circuit behavior, or synthesized into RTL from a high level language through high-level synthesis. These elements are connected together in a hardware description language to create the full SoC design. The logic specified to connect these components and convert between possibly different interfaces provided by different vendors is called [[glue logic]].

=== Design verification ===
{{Further|Functional verification|Signoff (electronic design automation)||label2=}}
Chips are verified for validation correctness before being sent to a [[Semiconductor fabrication plant|semiconductor foundry]]. This process is called [[functional verification]] and it accounts for a significant portion of the time and energy expended in the [[Integrated circuit development|chip design life cycle]], often quoted as 70%.<ref name="70% verification?">{{cite magazine |magazine=[[EE Times]] |url=https://www.eetimes.com/is-verification-really-70-percent/ |title=Is verification really 70 percent? |date=June 14, 2004 |access-date= July 28, 2015}}</ref><ref name="verification vs. validation">{{cite web|url=http://www.softwaretestingclass.com/difference-between-verification-and-validation/|title=Difference between Verification and Validation|work=Software Testing Class|date=August 26, 2013|access-date=2018-04-30|quote=In interviews most of the interviewers are asking questions on "What is Difference between Verification and Validation?" Many people use verification and validation interchangeably but both have different meanings.}}</ref> With the growing complexity of chips, [[hardware verification language]]s like [[SystemVerilog]], [[SystemC]], [[e (verification language)|e]], and OpenVera are being used. [[Software bug|Bugs]] found in the verification stage are reported to the designer.

Traditionally, engineers have employed simulation acceleration, [[emulator|emulation]] or prototyping on [[Reconfigurable computing|reprogrammable hardware]] to verify and debug hardware and software for SoC designs prior to the finalization of the design, known as [[tape-out]]. [[Field-programmable gate array]]s (FPGAs) are favored for prototyping SoCs because [[FPGA prototyping|FPGA prototypes]] are reprogrammable, allow [[debugging]] and are more flexible than [[application-specific integrated circuit]]s (ASICs).<ref name="nm prototyping">{{Cite web|url=http://www.tayden.com/publications/Nanometer%20Prototyping.pdf|title=Nanometer prototyping|last=Rittman|first=Danny|date=January 5, 2006|website=Tayden Design|access-date=2018-10-07}}</ref><ref name="Reason to debug in FPGA">{{Cite web|url=http://www.design-reuse.com/articles/13550/fpga-prototyping-to-structured-asic-production-to-reduce-cost-risk-ttm.html|title=FPGA Prototyping to Structured ASIC Production to Reduce Cost, Risk & TTM|website=Design And Reuse|access-date=2018-10-07}}</ref>

With high capacity and fast compilation time, simulation acceleration and emulation are powerful technologies that provide wide visibility into systems. Both technologies, however, operate slowly, on the order of MHz, which may be significantly slower – up to 100 times slower – than the SoC's operating frequency. Acceleration and emulation boxes are also very large and expensive at over US$1&nbsp;million.{{Citation needed|date=May 2018}}

FPGA prototypes, in contrast, use FPGAs directly to enable engineers to validate and test at, or close to, a system's full operating frequency with real-world stimuli. Tools such as Certus<ref>{{cite magazine |author=Brian Bailey |magazine=[[EE Times]] |url=https://www.eetimes.com/tektronix-hopes-to-shake-up-asic-prototyping/ |title=Tektronix hopes to shake up ASIC prototyping |date=October 30, 2012 |access-date=July 28, 2015}}</ref> are used to insert probes in the FPGA RTL that make signals available for observation. This is used to debug hardware, firmware and software interactions across multiple FPGAs with capabilities similar to a logic analyzer.

In parallel, the hardware elements are grouped and passed through a process of [[logic synthesis]], during which performance constraints, such as operational frequency and expected signal delays, are applied. This generates an output known as a [[netlist]] describing the design as a physical circuit and its interconnections. These netlists are combined with the [[glue logic]] connecting the components to produce the schematic description of the SoC as a circuit which can be [[printed circuit board|printed]] onto a chip. This process is known as [[place and route]] and precedes [[tape-out]] in the event that the SoCs are produced as [[application-specific integrated circuit]]s (ASIC).