You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

[top]SoC Realization
Driving SoC Realization
The open integration platform provides a comprehensive set of capabilities to develop today’s complex SoCs efficiently and profitably. Read more »
What SoC Realization Is And How to Enable It
The open integration platform, along with integration-optimized IP, will enable successful SoC hardware and software development.
View the video »
[top]A Software-Defined Approach
While System Realization produces a complete hardware/software platform ready for applications deployment, SoC Realization ensures the successful development of a single system on chip (SoC) to meet system needs. Traditionally, SoCs are considered “done” once the silicon is completed. But with EDA360, SoC Realization is not complete without software device drivers for each hardware subsystem.

Driver software allows the operating system (OS) and the applications to take advantage full of specialized hardware features. EDA360 advocates that these drivers be developed with the SoC rather than tacked on later—and that leads to a new view of how silicon intellectual property (IP) should be provided.

[top]An Expanded Definition of SoCs: the IP Stack
From a silicon standpoint, your basic SoC is a configurable IC with a processor, some custom logic, and a memory controller. EDA360 calls for an expanded definition of SoCs that includes the “bare-metal software” along with a more comprehensive view of IP as a “stack”—from the physical and protocol layers to the software device drivers along with associated verification IP and design constraints.

Typically, hardware is built first and drivers are written later, usually by someone unaware of the differentiating capabilities of the hardware. This leaves two options: develop a custom driver, which is expensive, or purchase a generic driver, which won’t leverage all of the hardware capabilities. In either case, the applications are disconnected from the underlying hardware system. EDA360 repairs this weak link by bundling device drivers with silicon IP.

[top]Constraint-Driven, Integration-Ready IP
SoC Realization is most efficient when multiple IP stacks are assembled into IP subsystems, which support major hardware subsystems. EDA360 calls for a constraint-driven approach to ensuring integration-ready IP. To optimize IP for integration, design constraints are needed for all parts of the IP stack—including analog hard macros, synthesizable digital IP, and driver software. A thorough understanding of power, timing, and area constraints makes the integration of IP into an SoC quicker, easier, and less risky. Without such constraints, bugs creep into the interfaces between IP subsystems, comprising overall system functionality and increasing verification costs.

[top]An open integration platform
Developing integration-ready IP for SoC Realization requires making it easier for IP creators to build drivers and facilitating metric-driven IP verification to eliminate the need for re-verification of IP. SoC integrators need a framework for this—and so EDA360 calls for an open integration platform.

The platform runs what-if analysis to determine the best possible architecture and integration. It develops an initial SoC architecture and then quickly integrates verified IP into verified SoCs. It is driven by an Integration Design Environment (analogous to the IDE or Integrated Development Environment used by software developers). And it is based on open standards like the OpenAccess database, the Open Verification Methodology (OVM), the IP-XACT format for IP descriptions, and the SystemC® TLM 2.0 modeling standard. The open integration platform leverages existing capabilities: metric-driven verification, low-power design, mixed-signal implementation and verification, and hardware/software integration.

Integration-ready IP thus requires a collaborative ecosystem. EDA companies, embedded software and OS vendors, IP providers, foundries, and end-user companies must all work together to expand the definition of IP to bare-metal software and complete subsystems.

Posting Permissions

Posting Permissions
  • You may not create new articles
  • You may not edit articles
  • You may not protect articles
  • You may not post comments
  • You may not post attachments
  • You may not edit your comments