Please see below for address change or subscribe/unsubscribe instructions.
Welcome to the August 1st issue of the IP Designer & Integrator. Our role is to complement Chip Design magazine by providing semiconductor IP news, opinions, and articles. There are subscribe and unsubscribe options at the end of the page.
Finding it difficult to justify the costs of high-end design systems?
Tanner EDA has established itself as a crucial link in the process of designing Analog/Mixed-Signal ICs and ASICs. We provide fully-integrated solutions for schematic capture, simulation, physical layout, netlist extraction, LVS/DRC verification on Linux and Windows® PC platform.
(626) 471-9701 or http://www.TannerEDA.com/dm/cdNL1
In this issue we fight the summer doldrums with timely content and thought provoking opinion. Sergio Kusevitzky tries to keep your project from being overwhelmed by building complexity in his “Analog IP Integration Requires Much More Than a Single Block Approach.” Next we dive deep into blog space to bring up some compelling points of view. Grant Martin calls up a historical metaphor to explore unknown between IP-centric and high-level ESL design tools in “Space exploration design, that is.” Then blogger Brian Bailey ponder the difference between “Positive and Negative Verification” and the special problems poised by third-party IP. That’s followed by an emphasis on memory in our news briefs and in depth looks. And we sum up your summer reading with the latest book by our featured bloggers.
Gaining traction in today’s highly competitive system-on-chip (SoC) market requires that design teams remain acutely focused on digital innovation. While there are a number of concerns that can divert a team’s focus, one of the most imposing is the increasing amount of analog content required by each new SoC design. The fact that integration of analog functionality into the overall design often remains an afterthought, rather than a critical aspect of the design process, is clearly impacting time-to-market goals.
The current mode of postponing crucial integration considerations, then rushing to integrate disparate single-function analog IP blocks, no longer meets the compressed cycle time requirements faced by SoC design teams. Integration must be proactively and skillfully addressed early in the design cycle so designers remain unencumbered to focus on digital innovation.
Full Story >> http://www.chipdesignmag.com/display.php?articleId=2496
EVE is the leader in Hardware/Software Co-Verification. Nine of the top 10 semiconductor companies rely on ZeBu to verify their SOCs. With the best ROI on the market, ZeBu is also the choice of startups that need first-pass silicon success.
Eve >> EVE
The other day I was emailing back and forth with my colleague Steve Leibson about the new Cadence ESL synthesis tool. He commented that there seems to be a gap between IP-centric design (such as processor-centric design, or the use of other large configurable IP blocks) and the general ESL world - for example ESL synthesis, which assumes for the most part that you are implementing a piece of functionality entirely in a new dedicated hardware block or blocks. To quote Steve,
A good tool would be able to decide when to use a configurable processor core to implement a block in a hierarchy and when to generate new RTL instead.
Coincidentally, Frank Schirrmeister was musing in the same direction in his recent blog on ESL synthesis. He points out many options for designing a major complex function at high level, concentrating on the topology and interconnect, and many options for designing each major block of functionality from pure software on a fixed ISA processor through to RTL synthesis, leading to at least 35 permutations and options for “function to implementation”. Design space exploration indeed!
Johannes Vermeer, The Astronomer, c. 1668
Early astronomers as pictured here had star charts, globes and early telescopes. Perhaps with processor-centric ASIP design and ESL synthesis we are still in this early stage of development. It seems to me that considerable opportunities lie, as Steve said, for the development of design space exploration tools that link into the various implementation flows from various vendors and for various alternatives and allow people to really explore space effectively. Perhaps a DSE version of the Hubble Space Telescope - without the early optical flaw that necessitated sending a repair crew out into space!
(Originally published as “Taken for Granted: Space exploration ... design, that is” at http://www.chipdesignmag.com/martins/2008/07/23/space-exploration-design-that-is/)
eSilicon, a pioneering semiconductor Value Chain Producer (VCP), provides a comprehensive suite of custom chip design, productization and manufacturing services, enabling a flexible, low-cost, lower-risk path to volume chip production.
eSilicon >> http://www.esilicon.com/
In a previous blog, I talked about the differences between verification and validation. What can confuse those definitions even more is when we start looking at verification in a hierarchical manner. This hierarchical process also brings in another fundamental distinction, namely that of positive and negative verification. In the book ESL Design and Verification I defined those terms in this way.
You either demonstrate or prove that a design performs a necessary taskpositive verificationor you demonstrate or prove that bugs do not existnegative verification.
This would appear to be similar to the distinction between verification and validation, except that we have to remember the principle source of the second model against which we are comparing the design. Assume for a moment, that an executable specification for the system exists. When we verify the specification, we are doing validation. When we are comparing an implementation against the specification, we are doing verification. In order to do implementation, we first have to break the specification down into smaller parts, unless the system was small enough to start off with. In addition, partitioning and mapping may also have been performed. As we break the spec down, there is a chance that errors will creep in, especially since there is an almost total lack of tools or automation to help with this task. So by the time we get to the block level, several such decompositions steps may have taken place. There is thus a finite chance that errors will have crept into the block specification, or that elements of the specification have been omitted.
So now if we verify an implementation against that derived specification, we could prove that all bugs have been eliminated, but that does not mean that when put into the context of the system that it will work. In other words we need to either verify a block in the context of the system, or we have to validate that the sub-specification was correct. This is true for all levels of verification and integration back up to the full system, when the definitions for positive, negative, verification and validation fall back inline with each other.
Positive verification demonstrates that a design requirement is met by verifying it against the original specification. Negative verification exposes any flaws in the implementation of a requirement and thus compares it against the local specification. Most methodologies in use today focus on negative verification because of their bottom-up nature.
When we consider designs that include a large amount of design IP, be it from third party companies or design components that are reused internally, this situation is magnified. When IP is being verified, it is not known exactly how it will be used, so all behaviours are verified equally. But, some or many of those behaviours may not be used in the design, potentially wasting verification time. Consider for a moment a design that is to be based on a platform. That platform is likely to contain many components such as processors, memories, peripherals and the logic necessary to integrate them both at the hardware and software levels. The platform manufacturer has hopefully performed a lot of verification on this platform so let us assume that it does indeed contain no bugs. Does this mean that all designs placed on that platform will operate correctly? If the platform matches every need of the design and in a way that has been correctly understood by the user of that platform then the answer should be yes. But there likely were a lot of assumptions and loose statements that qualified its application, and the reality is that there will be mismatches in what the platform provides and what is required. In a verification flow, we would thus still have to show that each feature required in the final product is indeed properly implemented when the system has been assembled.
However, we cannot rely solely on positive verification either because it suffers from the problem that if a new behaviour is added or changedperhaps due to a software fixyou have not verified that it will operate correctly in the hardware. Given the truth to the adage “if it hasn’t been verified, then it does not work,” this presents a problem. Hence, a balance is needed. Positive verification is mainly employed in the sections preceding implementation verification: post-partitioning analysis and verification. Implementation verification is the time to apply negative verification and to show that the positive verification has not been broken by the transformation. By thinking of verification from both the positive and negative perspectives it becomes possible to better schedule some of the verification tasks. Features that are most vital to a product can and should be verified before effort is expended on less important features. This ensures that if time pressures force the chip to be released before verification is finished, those features most likely to cause problems have been adequately verified.
(Originally published as “Verification Vertigo: Positive and Negative Verification” at http://www.chipdesignmag.com/bailey/2008/07/21/positive-and-negative-verification/)
The new Databahn memory controller and PHY IP solution from Denali, Inc. supports the pre-released LPDDR2 specification, as currently defined by JEDEC. LPDDR2 addresses mobile and consumer systems where the "PC memory" devices, DDR2 and DDR3, are unsuitable. LPDDR2 offers a low power, low voltage, low pin-count memory in a range of densities and speeds that are closely matched to the needs of those mobile and consumer systems. In addition, LPDDR2 was designed to allow sharing of SDRAM and NVM memory on the same bus, which is extremely difficult in PC memory technologies. For immediate availability of a C-model, in advance of the silicon IP for Denali's Databahn LPDDR2 memory controller and PHY, contact sales@denali.com.
Denali Software, Inc. >> www.denali.com
Virage Logic Corporation introduced the Intelli DDR3 memory interface solution that supports speeds up to 1.6 Gb/s. Comprising a DRAM memory controller, digital PHY, DLL, and I/O, it provides a System Aware IP solution that mitigates high-speed interconnect effects. The unique digital architecture and system intelligence helps manage the variables inherent in system designs, easing implementation and optimizing integration with existing board and package designs. The standard cell architecture and all-digital implementation enables it to work seamlessly with digital SoC design flows, allowing significant ease of portability to any process node for any foundry, eliminating the need to prove the solution when integrated with silicon proven I/Os.
Virage Logic >> www.viragelogic.com
Synopsys, Inc. has fully synthesizable implementations of the IBM PowerPC 460 and cache configurable PowerPC 405 embedded microprocessor cores as components of the DesignWare Star IP program. The PowerPC 460S is a 32-bit high performance, low-power embedded processor core optimized for consumer electronics, communications, and storage applications. It allows SoC designers to select the L2 cache size, L1 cache size, and multi-core processor local bus. The PowerPC 405S is a 32-bit low power, mid performance embedded processor core for emerging consumer, storage, wired and wireless applications. As a synthesizable version of IBM's most popular hard core series, this model supports a user-definable L1 cache size to help optimize performance and area requirements.
Synopsys >> www.synopsys.com
TranSwitch has begun commercial licensing for its 3.5 Gbps HDMI 1.3 IP core. The TXC-98072 - 3.5 Gbps/channel HDMI 1.3 Transmitter IP core was designed and fabricated using TSMC’s 90nm G process. The first version meets all current HD standards up to 2.25 Gbps. The second version supports serial communications at a speed of up to 3.5 Gbps per channel for extended HD resolutions, with backward compatibility to the first version of 2.25 Gbps. The transmitter IP core and the DSP-based receiver IP core can run at aggregated speeds of up to 10.5 Gbps and support color depth of up to 16 bits. The primary use will be in digital cameras.
TranSwitch >> www.transwitch.com
MIPS Technologies, Inc. introduced a new generation of its GPS RF Tuner IP solution. The silicon-proven, integrated low-noise RF front-end for GPS receivers in the L1 band enables embedded system designers to decrease costs and time-to-market. It enables developing new GPS devices, adding GPS functionality to other types of devices, or helping to reduce form factor and development costs of a next-generation device. It is targeted for virtually any location application, such as high-end navigation systems in cars, cell phones and PDAs. Its cost and area advantages can suit it for ultra-mobile devices, handheld games, portable media players, mobile PCs and digital cameras.
MIPS Technologies >> www.mips.com
ESL Design and Verification -- A Prescription for Electronic System Level Methodology
By Grant Martin, Brian Bailey and Andrew Piziali
Publisher: Elsevier -- Morgan Kaufmann
ISBN: 978-0-12-373551-5
ESL began as an algorithm modeling methodology with “no links to implementation.” Now ESL is evolving into a set of complementary methodologies. It can enable embedded system design and verification, as well as the debug and hardware/software implementation of SoCs, system-on-FPGA, system-on-board, and entire multi-board systems.
The authors (two of them featured bloggers on our website) have years of experience as ESL practitioners. They have seen it go through many stages and false starts, and are enthusiastic about its future. They maintain that ESL technologies are stabilizing on a useful set of languages (SystemC is the most notable), and are using models that are getting real adoption. This is a prescriptive guide to ESL that builds on the past and outlines today’s best practices.
Jody Defazio believes that IP cores can future-proof SoCs by giving designers more memory choice flexibility. Has that proven out, and where do you think the future lies? Consider the recent past-future in “Consumer Electronics are changing the face of DRAMs.”
Featured Story >> http://www.chipdesignmag.com/idesign/
Rob Evans makes the case that the real role of IP is within design abstraction. This “soft” IP is easier to protect legally and a lot harder for competitors to imitate. See if your design requires the left brain, or the left bank of the Seine, to best understand in “Moving to Advanced Design Abstraction.”
Featured Story >> http://www.chipdesignmag.com/idesign/
IEEE International MWSCAS 2008
August 10-13, 2008
Knoxville Convention Center, Knoxville, TN
http://www.eecs.utk.edu/mwscas/
IASTED International Conferences on Circuits and Systems (CS 2008)
August 18-20, 2008
Kailua-Kona, HI
http://www.iasted.org/conferences/home-625.html
Intel Developer Forum
Moscone Center West, San Francisco, CA
August 19-20, 2008
http://www.intel.com/idf/
Hot Chips
Memorial Auditorium, Stanford University
August 24-26, 2008
http://www.hotchips.org/hc20/
Micro Nano Breakthrough Conference
Hilton Hotel, Vancouver, Washington
September 8-10, 2008
http://oregonstate.edu/conferences/MNBC/
IEEE Custom Integrated Circuits Conference
DoubleTree Hotel, San Jose, CA
September 21-24-, 2008
http://www.ieee-cicc.org/
GSA IP Conference
Santa Clara Convention Center, Santa Clara, CA
September 24-25, 2008
http://www.gsaglobal.org/ip_conference/
SAME 2008 Forum
11th Edition Sophia Antipolis forum on MicroElectronics Conference Program
ESPACES ANTIPOLIS, Sophia Antipolis, France
October, 1 & 2, 2008
Suppliers Expo & Conference
Santa Clara Convention Center, Santa Clara, CA
October 2, 2008
http://www.gsaglobal.org/suppliers_expo/usa2008/
Embedded Systems Conference Boston
October 27-30, 2008
Hynes Convention Center, Boston, MA
http://www.embedded.com/esc/boston/
International System-on-Chip (SoC) Conference, Exhibit & Workshops
Radisson Hotel, Newport Beach, CA
November 5-6, 2008
http://www.SoCconference.com/
IEEE Globecom 2008
Hilton Washington, Washington DC
November 30-December 4, 2008
http://www.ieee-globecom.org/2008/
IP08 IP Based Electronic System Conference & Exhibition
World Trade Center, Grenoble, France
December 3-4, 2008
http://www.design-reuse.com/ip08/
GSA Awards Dinner Celebration
Santa Clara Convention Center, Santa Clara, CA
December 11, 2008
http://www.gsaglobal.org/events/2008/1211/
Editor: Jim Kobylecky, jkobylecky@extensionmedia.com
Editorial Director: John Blyler, jblyler@extensionmedia.com
Advertising/Sponsorship Opportunities: Karen Popp, kpopp@extensionmedia.com
Read past issues of Chip Designer, FPGA Developer, IP Designer & Integrator and Wireless Chip Designer: http://www.chipdesignmag.com/enewsletters/
Visit Chip Design: www.chipdesignmag.com
ExtensionMedia’s homepage: www.extensionmedia.com
Contact Us | Sponsor this Newsletter | Subscribe | Visit Chip Design
Copyright © 2008 Extension Media, Inc. All rights reserved.
