SemiWiki – Page 470 – The Open Forum for Semiconductor Professionals

RVN! 26 Banner revised (800 x 100 px) (600 x 100 px)

October 1, 2018

Electronics healthy but trade wars loom

Electronics healthy but trade wars loom
by Bill Jewell on 10-01-2018 at 7:00 am
Categories: Semiconductor Intelligence, Semiconductor Services
1 Comment

Production of electronic equipment is healthy based on July and August data. China, the largest electronics producer, showed three-month-average change versus a year ago (3/12) of 13.8% in August. Growth for China has been in the 12% to 15% range since January 2017, picking up from the 8% to 11% range in 2016. South Korea’s electronics production has been more volatile, but was over 12% in June and July. The United States has shown accelerating growth since turning negative in 2016. U.S. electronics 3/12 change has been above 6% for the last four months (May through August), the highest since February 2004. European Union (EU) total industrial production growth has been in the 2% to 3% range from April to August, slowing from 5% earlier in the year. Our Semiconductor Intelligence global index of electronics production has been relatively robust in the last two years, in the 7% to 9% range since January 2017.

Electronics production change in key Asian countries has been mixed. India and Vietnam have led with way, with India’s electronics growth accelerating from 15% in 2017 to 27% year-to-date through July 2018. Vietnam has decelerated from 33% growth in 2017 to a still robust 18% year-to-date. India and Vietnam should continue to outperform other Asian countries because of their low labor rates and improving infrastructures. China and Thailand have maintained growth in the 12% to 14% range over the last year and a half. Malaysia and South Korea have picked up from 4% in 2017 to 10% and 8% respectively year to date. Japan electronics growth is stuck in the low single-digits while Taiwan has seen declines.

Total electronics exports in 2017 were $1.8 trillion while imports were $2.1 trillion, according to the World Trade Organization (WTO). China continued as the largest electronics exporting country in 2017 at $592 billion. However, the total other Asian countries became larger than China at $627 billion. China was also the largest importing country with $408 billion in 2017. The U.S. was second at $336 billion.

The U.S. and China are currently in a trade war, with each country imposing tariffs on imports. The impact of the trade war on U.S. electronics and semiconductor companies is explained in a New York Times article. The effect on Asian companies is covered in a article in the Nikkei Asian Review. In addition, the U.S. is renegotiating the North American Free Trade Agreement (NAFTA). A preliminary agreement was reached with Mexico and discussions are ongoing with Canada.
Without getting into the politics of these trade issues, it is important to note the significance of China and Mexico to U.S. electronics imports. According to the U.S. Census Bureau, the majority of U.S. electronics imports in 2017 came from China at 59%. Mexico was the second largest source of imports at 18%. Most of the rest was from other Asian countries at 19%.

Electronics and semiconductors are truly global industries. Free trade is necessary to keep these industries running efficiently. Hopefully the current trade issues can be resolved in a reasonable time.

September 28, 2018June 14, 2021

Design Automation and the Engineering Workstation

Design Automation and the Engineering Workstation
by Daniel Nenni on 09-28-2018 at 7:00 am
Categories: Wally Rhines
2 Comments

This is the seventeenth in the series of “20 Questions with Wally Rhines”

Several common aspects have existed for what is now the modern Electronic Design Automation (EDA) industry. When I joined TI in 1972, the company was very proud of its design automation capability as a competitive differentiator. Much of the success of TTL for TI came from the ability to crank out one design per week with automated mask generation with the “MIGS” system. Other semiconductor companies had their own EDA capability. So it was somewhat revolutionary when Calma introduced its automated layout system at about the same time that Computervision and Applicon did the same, all based upon 32 bit minicomputers. Computervision, Calma and Applicon became the big three of the first generation layout tools.

TI considered these newcomers as a threat. Development progressed upon a system based upon the TI 990 minicomputer. Meanwhile, our competition largely moved to Calma and, in some cases, Applicon. Design engineers were rebelling when I arrived in Houston in 1978. We were using the TI 990 based “Designer Terminal” with Ramtek displays to do the layout editing with a light pen. Designs were digitized on home grown systems based upon layouts that were created by draftspersons (mostly draftsmen) on a grid matched to the design rules of the chip. Our people wanted to buy a Calma system. However, just as we got our first Calma, GE acquired Calma and quickly destroyed the company. With the introduction of the Motorola 68K in early 1979, a host of companies, including Apollo, began developing a new generation of engineering work stations.

By now, the management of TI’s Design Automation Department, realized the limitations of its approach. The 1982 Design Automation Conference in Las Vegas further affirmed the need to move to a next generation approach. So TI became one of the first major semiconductor companies to commit to the newly introduced Mentor Idea Station product based upon the Apollo workstation. Internal support groups in large corporations don’t usually surrender their corporate roles, despite their competitive disadvantage, and TI was no exception. A plan existed to complement the Mentor software with DAD-developed software. Mentor readily agreed since TI was a very large customer win. TI’s management accepted the whole strategy because of the strong history of success of DAD in maintaining a competitive design advantage for integrated circuit design.

Subsequently, the Daisy-Mentor-Valid competition ensued. Mentor turned out to be a good choice because it was based upon the Apollo workstation and Mentor resources were not tied down to developing new hardware, as were the Daisy and Valid teams. But TI was not one of Mentor’s most desirable customers. The DAD engineers were experts in design software and they wanted to tweak the system capabilities as well as to add major new functionality. Mentor had realized major success with systems companies in aerospace, defense and automotive industries and was rapidly becoming a worldwide standard, especially in Europe. Meanwhile, my role in the TI Semiconductor Group changed. I was appointed President of the TI Data Systems Group, TI’s $700 million revenue business in minicomputers and portable terminals and was moved to Austin, Texas. While I was away over the next three years from late 1984 through mid 1987, a decision was made to divorce TI from Mentor and port our own TI software to the Apollo workstations. In mid-1987, I returned to Dallas as Executive VP of the Semiconductor Group only to find that the original move to commercially available design automation products had been reversed. TI was once again an island in an industry that was building upon broad innovation from a diverse set of designers working with commercial EDA suppliers. Unlike the early semiconductor history when TI had nearly 40% market share, TI now had 10% to 15% share and the economies of scale didn’t justify custom design tools.

One of the entities that reported to me initially as EVP of the Semiconductor Group was DAD. I appointed Kevin McDonough, who later became Engineering VP of Cyrix Semiconductor, to assess our position in design automation and recommend a solution. Kevin did the evaluation and came back with an answer: Adopt the Silicon Compiler Systems design automation platform and move ahead to “RTL based” design. And so we did. We committed $25 million to SCS and started a conversion of the MOS portion of our design business to SCS. Few people even remember that SCS, which was an outgrowth of an AT&T Bell Labs spin-out called Silicon Design Labs, or SDL, actually developed the entire language based top-down design methodology before VHDL and Verilog even existed. TI and Motorola were among the first adopters. The TI sale gave SCS the credibility for an acquisition by Mentor Graphics at a premium price. Why would Mentor acquire SCS when they already had a strong IC Station product that could effectively compete against Cadence Virtuoso predecessor products? The answer: a tops-down, language methodology was clearly the direction of the future for the semiconductor industry. The problem: The two methodologies (Top Down, language based versus detailed layout) were disruptively different. Traditional designers viewed RTL design as the province of “computer programmers”. “Real” IC designers knew how transistors worked and could craft superior IC’s with a detailed design and layout system.

What evolved was internecine warfare. Hal Alles, VP of IC Design at Mentor, veteran genius developer from Bell Labs and founder of SDL, had the undesirable challenge of convincing the two groups to work together. They didn’t. Step by step, the SCS designers denigrated the traditional IC design approach and Mentor’s message was bifurcated. The result: a window for Cadence to become the clear leader in traditional IC detailed design. Meanwhile, other companies exploited the fact that SCS had a closed system for language based design using two languages, L and M, which were proprietary. VHDL and much later Verilog, became public domain languages for top-down design. DAD was one of the organizations that reported to me at TI during the 1982 through 1984 period. We initiated a research proposal to create an open language for top-down design called VHDL, or VHSIC Hardware Description Language. In 1983, we were granted a contract to develop VHDL with IBM and Intermetrics as co-developers. I was one of five speakers at a special event to announce the plan in 1983. In 1987, VHDL became an IEEE standard 1076. In 1985, Prabu Goel formed a company, Gateway Automation, that subsequently developed an even simpler language called Verilog. The company was acquired by Cadence.

The final result: Engineers who were accustomed to schematic capture were gradually displaced by language based developers. The EDA industry went into one of its major discontinuities, the transition from schematic capture to RTL based design. Mentor lost a lot of momentum and SCS never really became a standard for RTL based design although it might have been if it had made its languages open.

The 20 Questions with Wally Rhines Series

September 27, 2018June 14, 2021

Custom SoC Platform Solutions for AI Applications at the TSMC OIP

Custom SoC Platform Solutions for AI Applications at the TSMC OIP
by Daniel Nenni on 09-27-2018 at 12:00 pm
Categories: Events, FinFET, Open-Silicon, Semiconductor Services, TSMC

The TSMC OIP event is next week and again it is packed with a wide range of technical presentations from TSMC, top semiconductor, EDA, and IP companies, plus long time TSMC partner and ASIC provider Open-Silicon, a SiFive Company. You can see the full agenda HERE.

AI is revolutionizing and transforming virtually every industry in the digital world. Advances in computing power and deep learning have enabled AI to reach a tipping point toward major disruption and rapid advancement. However, these applications require much higher memory bandwidth. ASIC platforms enable AI applications through training in deep learning and high speed inter-node connectivity, by deploying high speed SerDes, a deep neural network DSP engine, and a high speed high bandwidth memory interface with High Bandwidth Memory (HBM) within a 2.5D system-in-package (SiP). Open-Silicon’s implementation of a silicon-proven ASIC platform with TSMC’s FinFET and CoWoS® technologies is centrally located within this ecosystem.

Open-Silicon’s first HBM2 IP subsystem in 16FF+ is silicon-proven at 2Gbps data rate, achieving bandwidths up to 256GBps, and being deployed in many ASICs. The data-hungry, multicore processing units needed for machine learning require even greater memory bandwidth to feed the processing cores with data. Keeping pace with the ecosystem, Open-Silicon’s next generation HBM2 IP subsystem is ahead of the curve with 2.4Gbps in 16FFC, achieving bandwidths up to >300GBps.

This 7nm ASIC platform is based on a PPA-optimized HBM2 IP subsystem supporting 3.2Gbps and beyond data rates, achieving bandwidths up to >400GBps. It supports JEDEC HBM2.x and includes a combo PHY that will support both JEDEC standard HBM2 and non-JEDEC standard low latency HBM. High speed SerDes IP subsystems (112G and 56G SerDes) enable extremely high port density for switching and routing applications, and high bandwidth inter-node connections in deep learning and networking applications. The DSP subsystem is responsible for detecting and classifying camera images in real time. Video frames or images are captured in real time and stored in HBM, then processed and classified by the DSP subsystem using the pre-trained DNN network.

Implementation challenges for AI ASICs include design methodologies for advanced FinFET nodes, physical design of large ASIC >300 mm2 running at GHz speed, power and timing closure, system level power and thermal and timing signoff. Open-Silicon has overcome these challenges with advanced implementation strategies that enable Advanced On-Chip Variations (AOCV) flow for physical design and timing closure, correlation between implementation and signoff that results in faster design convergence, an advance node power plan and validation techniques, and system level signal and power integrity signoff for a complete 2.5D SiP. Additionally, various in-house development tools help debug and analyse the design data through physical design phases, thus speeding convergence of complex designs.

Open-Silicon’s DFT methodology enables the test and debug challenges in large ASIC designs by incorporating methods such as core wrappers, hierarchical BIST/scan, compression, memory repair, power aware ATPG and enablement of wafer probing to ensure quality KGD before 2.5D assembly, interconnect test between ASIC and HBM, and incorporating design practices recommended by TSMC CoWoS® to improve 2.5D SiP manufacturing and yield.

Open-Silicon’s ASIC design and test methodology, low area high performance HBM2 IP subsystem, and its experience in high speed SerDes integration and DSP subsystem implementation, offer best-in-class custom silicon solutions for next generation AI and high performance networking applications.

Who: Bhupesh Dasila, Engineering Manager – Silicon Engineering group, Open-Silicon
What: Custom SoC Platform with IP Subsystems Optimized for FinFET Technologies Enabling AI Applications
When: Wednesday, October 3 2018, 1:00 pm
Where: EDA/IP/Services Track, Santa Clara Convention Center

Open-Silicon is exhibiting at Booth, #907

The TSMC Open Innovation Platform®(OIP) Ecosystem Forum is a one-of-a-kind event that brings together the semiconductor design chain community and approximately 1,000 director-level and above TSMC customer executives. The OIP Forum features a day-long, three-track technical conference along with an Ecosystem Pavilion that hosts up to 80 member companies.

September 27, 2018December 27, 2023

Mesh Networks, Redux

Mesh Networks, Redux
by Bernard Murphy on 09-27-2018 at 7:00 am
Categories: Ceva, IoT, IP, Mobile

It isn’t hard to understand the advantage of mesh networking (in wireless networks). Unlike star/tree configurations in which end-points connect to a nearby hub (such as phones connecting to a conventional wireless access point), in a mesh nodes can connect to nearest neighbors, which can connect to their nearest neighbors and so on, therefore allowing for multiple possible paths to route data to a target device. Important characteristics of this approach are (in theory) reliability and lower maintenance cost. If some node in the network fails, communication can automatically route around the failure until the bad node is repaired or replaced.

Investment in this area has focused strongly on Wi-Fi, for example the solution supported by Google Home, and the Zigbee and Thread standards. Clearly these have seen some traction but there’s an obvious question – if mesh is so great, why aren’t we seeing it everywhere? Apparently the standards aren’t quite standard enough to ensure full interoperability between solutions from different vendors. So your phone, fitness tracker, thermostat, smart speaker and laptop may not collaborate seamlessly in that mesh. More annoyingly, they may appear to collaborate but fail from time to time in mysterious ways. So much for reliability and low maintenance.

A better solution has to start from a better standard which closes off any wiggle room for incompatibilities. Which is where Bluetooth gets interesting. Incidentally, I’m coming to view Bluetooth as the stealth technology of wireless communication. Just a humble little capability to connect your phone to earbuds and your car infotainment center, right? Then we got Bluetooth Low Energy (BLE) which now looks pretty interesting for many IoT edge nodes. Then the standard added broadcasting for indoor beacons, and more recently we got Bluetooth mesh, a capability defined to fix the interoperability problem. Not such a junior partner in communications anymore.

BT mesh defines a full-stack all the way from the low-level radio up to the application layer, eliminating wiggle-room; every solution built on BT Mesh should be interoperable. Also mesh requires that a device adopt and stay with a mesh model (similar to BT profiles); once a model for behavior of a node in a network is adopted it can never change. So for example, a BT mesh light switch purchased this year should be able to control a BT mesh light bulb purchased 30 years from now.

Mesh is supported through a software stack on top of BLE, so adding mesh support is just a software upgrade on top of BLE. Therefore your smartphone should be able to join a BT mesh and therefore be able to control any mesh device (given appropriate privileges). It’s less clear that this is in the roadmap for ZigBee-enabled devices.

Since BT mesh is built on BLE, it is naturally aligned with low-energy usage. In a mesh network, it may seem like this is no better than a theoretical advantage; all that peer-to-peer communication will neutralize any advantage in BLE, surely? The standards group thought of that, allowing for different classes of node in a mesh. A low-power node can operate on a low duty-cycle and on wake-up can poll an identified Friend node rather than having to broadcast to find a nearby node. A Friend node will also buffer messages addressed to its low-power friend and will forward when that node wakes up.

Friend nodes and Relay nodes will commonly be served by main power, so are not as constrained in power usage, though still quite power efficient thanks to BLE. So mesh really can be low-power friendly. Mesh is also designed to be very secure, providing end-to-end government-grade security from the sender to the target application. Even though other nodes in the mesh are receiving and retransmitting messages, they can’t read those messages. And finally, all of this builds on a long-established and widely-deployed technology (Bluetooth), minimizing adoption problems, need for major upgrades and maintenance.

What are the primary use models? Definitely in-building applications, such as controlling lighting, heating or window shades in a smart home or office or factory. Even more interesting is use for location services, especially indoors; this is where beacons become popular. We’ve already seen promos showing how we could find a store in a mall or products in a supermarket (that can’t come soon enough for me). The same technology can help track assets in a factory, patients and medical equipment in a hospital or concession stands in a stadium. The range of (non-mesh) BLE is already quite good; mesh extends that even further. There’s interest now in mesh to enable smart-city functions.

All of this sounds good, but what’s the ground reality? I’m told by Paddy McWilliams (Eng Dir at CEVA) and Franz Dugand (Sales and Mktg Dir, Connectivity, at CEVA) that in China the battle is pretty much over. Alibaba for example has specified that, of the mesh standards, they are going with BT mesh. Others in China are apparently coming to similar conclusions. In one case I heard of, after carefully comparing ZigBee and talking to customers, a services provider told their product makers they expected BT mesh support (perhaps Alibaba’s choice had something to do with that). Curiously the US and EU seem to behind in adoption at present, but China is a huge market. It seems unlikely we can simply ignore their direction.

CEVA has been active and very successful in Bluetooth for a long time. They already have a mesh stack which will run on top of their BLE4.2 and BLE5 IPs, so you probably should check them out when you’re thinking about how you can get in on this action.

September 26, 2018June 17, 2021

Crossfire Baseline Checks for Clean IP at TSMC OIP

Crossfire Baseline Checks for Clean IP at TSMC OIP
by Daniel Nenni on 09-26-2018 at 12:00 pm
Categories: EDA, Fractal Technologies, IP, TSMC

IP must be properly qualified before attempting to use them in any IC design flow. One cannot wait to catch issues further down the chip design cycle. Waiting for issues to appear during design verification poses extremely high risks, including schedule slippage. For example, connection errors in transistor bulk terminals where timing and power closure will work regardless. Such an issue would only be uncovered during final SPICE netlist checks. Another potential problem could include a case where LEF does not match GDS, completely slipping through the cracks, through full synthesis, and would only be caught during chip level DRC or LVS. This would ultimately require updates to the IP as well as re-synthesis (more slippage).

How can one avoid these potential problems? Simple, with Fractal’s Crossfire QA suite. Fractal is your specialized partner for IP qualification. Crossfire can help you deal with design view complexities, increasing amount of checks required to correctly QA an IP, and the difficulties of dealing with excessive volumes of data.

Crossfire supports over 30 standard design formats, from front-end to back-end, including simulation and schematic views, binary databases such as Milkyway, OpenAccess, and NDM, documentation, and custom formats such as Logic Vision and Ansys APL. Any other ASCII based custom formats can also be easily integrated into the tool.

Getting back to the scope of this article, the recommended baseline of checks can be separated into three sections: cell and pin presence for all formats, back-end checks, and front-end related checks.

Cell and Pin Presence Checks
Although consistency checks such as cell and pin presence may sound trivial, and for the most part, they are, one cannot sweep such an important task under the rug. Don’t be surprised if an IP or standard cell library from a well-known IP vendor is delivered with inconsistencies between the various formats, including cell and pins names, port direction, and hierarchy differences.

Back-end Checks
Ensuring layout related consistencies across all back-end related formats is an important part of the IP QA qualification. Pin labels and shape layers must match across all layout and abstract formats. All layout formats such as GDS, Oasis, Milkyway CEL, NDM and OpenAccess layout views must directly match across the board. When comparing a layout to an abstract format such as LEF, Milkyway FRAM or NDM frame, one must ensure that all layer blockages correctly cover un-routable areas in the layout. On top of that, pin shapes and layers must match in order to guarantee a clean DRC/LVS verification down the line.

Other important checks to consider include area attribute definitions for non-layout formats which must match the area defined by the boundary layers for various layout formats. IP and standard cell pins must be accessible by the router and for non-standard cell related IP, pin obstruction needs to be checked in order to ensure accessibility. In some cases, ensuring that all pins are on a pre-defined grid can also be a necessary task. In the end, these checks will ensure a quicker and less error-prone P&R execution.

Front-end Checks
Front-end checks can be broken into seven separate sections: timing arc, NLDM, CCS, ESCM/EM, NLPM, functional characterization, and functional verification. In this blog, we’ll be covering the latter two related to functional checks. The first five sections related to characterization deserve an article all on their own, therefore, they will be covered in an upcoming blog.

Functional characterization checks ensure the timing arcs are defined correctly when compared the given Boolean functions for formats like Liberty, Verilog, and VHDL. Other checks include power down function correctness, ensuring related power and ground pins are defined correctly when compared to spice netlists or UPF models (correct pins are extracted from spice by traversing the circuits defined in the spice format). We also recommend checking related bias pins and whether input pins are correctly connected to gate or antenna diodes.

When dealing with standard cell libraries, it is important to establish the Boolean equivalence of all formats that describe the behavior of a cell. This will ensure that all formats behave in the same manner when dealing with functionality during various front-end related timing simulations.

What else can Crossfire do?
Crossfire is technology independent. From a tool perspective, the differences include:

Exponential data size growth (up to 2x when compared to previous node)
Introduction of new design formats (i.e. NDM)
Number of corners increasing drastically in newer nodes (i.e. FinFet based)

As a tool, Crossfire only has to differentiate between standard cell libraries and all other IP (memories, digital, analog, mixed-signal, etc.). Some checks, such as abutment or functional verification, are designed specifically for standard cell libraries.

Crossfire is a proven validation tool used by various Tier 1 customers. All checks and formats supported by Crossfire are based upon direct cooperation with our customers. Customers moving from “old” to “new” technology nodes automatically get all the checks and format support developed for and used by Tier 1 customers. This cycle of shared knowledge is passed on from one technology node to another.

Conclusion
IP qualification is an essential part of any IC design flow. A correct-by-construction approach is needed since fixing a few bugs close to tapeout is a recipe for disaster. Given that, IP designers need a dedicated partner for QA solutions that ensures the QA needs of the latest process nodes are always up-to-date. In-house QA expertise increases productivity when integrated with Crossfire. All framework, parsing, reporting, and performance optimization is handled by the tool. On top of that, with a given list of recommended baseline checks, we ensure that all customers use the same minimum standard of IP validation for all designs.

TSMC OIP
The Crossfire team and I will be at a booth in the TSMC OIP exhibit hall next week giving out free copies of our Fabless book, discussing the need for IP qualification, and demonstrating the latest Crossfire software. I hope to see you there!

September 26, 2018

LightSuite – Physical Design Goes Photonics!

LightSuite – Physical Design Goes Photonics!
by Alex Tan on 09-26-2018 at 7:00 am
Categories: EDA, Siemens EDA, Silicon Photonics
3 Comments

Light is a form of energy. It reveals an object’s color and shape through the refraction (passing through light) or the reflection (bouncing back light) of its beam. While photon is the smallest measure of light, the term photonicscan be defined as the science and technology of generating, controlling, and detecting photons.

A unique characteristic of light is its speed. Speed signifies time and is a common denominator to many technological applications including IC designs. According to Einstein’s theory, the speed of light is the ultimate measure of an object’s speed in the universe. Emerging technologies such as AI-of-Things (AIoT), nano-technology, self-driving vehicles and 5G have driven an increased demand in data center’s compute speed and bandwidth –which in turn, have pressed the urgency of reducing data latency and motivate further exploration of photonics based solutions to improve data speed.

A subset of photonics, integrated photonics, deals with optical signal modulation and detection on an IC. Its market segments which include sensors, networking, self-driving cars and hyperscale data centers are growing as shown in figure 1. Two years ago, the total market size of integrated photonics has exceeded the discrete segments’ and has continued its trend ever since.

The state of interconnect technology
Today’s IC design still has a major reliance on the use of copper for both global and local interconnects. Although recent technology scaling has hit a plateau, both foundries and design teams have been actively seeking alternatives to improve data transport both on-chip and off-chip. As the physical characteristics of the wires dictate their performance, the present mitigation approaches include segregating metal layers for high-speed need (global nets) versus slower intra-cells (local interconnection), and is considered inadequate to satisfy advanced data center application requiring speed migration now tilting towards 400Gb/s.

As illustrated in figure 2, photonics based solution provides a better option as it offers a higher bandwidth, better energy efficiency and low latency –all traits suitable for addressing interconnect bottleneck.

Photonics related challenges and solution
Our quest in harvesting light as energy source has been quite successful as reflected in the mainstream adoption of renewable energy through solar cells. How about applying photonics for interconnect? Harnessing its potential for data movement is challenging as it ventures into multiple domains. As opposed to CMOS or FinFET based designs, the layout forms of photonic structures including their interconnects, are mostly non-Manhattan-ic.

Amidst many photonics application, fiber optic is becoming the key medium for light transport as it needs few repeaters, has ample bandwidth/capacity and is immune to electromagnetic interference. In addition, it is hard to tap without being detected. An example of an on-chip application involves the use of source components (modulator, laser), waveguide and receiver (sensor) as illustrated in figure 3.

“Photonic chips promise amazing performance, but designing circuits today is just too difficult and requires specialized knowledge,” said M. Ashkan Seyedi, Ph.D., senior research scientist, Hewlett Packard Enterprise. His view was also confirmed by others in the system supply chain. “Both silicon development and optics development takes a long time, typically 2-3 years from start of product development,” said Andy Bechtolsheim, chairman and co-founder of Arista Networks.

From the EDA standpoint, Tom Daspit, Product Manager at Mentor Graphics, shared a similar view, “Photonic designers are not IC designers. You need more IC design knowledge to do photonics design. More IC layout knowledge is also needed for integrated photonics…unlike the orthogonal CMOS design.“ In addition, physical verification tools need to be revamped as curved structures trigger false DRC errors, complex LVS device recognition and optical property comparison.

To address such photonic design challenges, Mentor, a Siemens business, recently announced the availability of LightSuite™ Photonic Compiler –the industry’s first integrated photonic automated layout system. LightSuite enables designing integrated photonic layouts by capturing the designs in the Python language, from which the tool then automatically generates designs ready for fabrication. The design implementation is guided by Mentor’s Calibre® RealTime Custom verification tool.

“Mentor’s LightSuite Photonic Compiler represents a quantum leap in automating what has up to now been a highly manual, full-custom process that required deep knowledge of photonics as well as electronics… Mentor is enabling more companies to push the envelope in creating integrated photonic designs.” said Joe Sawicki, vice president and general manager of the Design-to-Silicon Division at Mentor, a Siemens business.

Added Ashkan Seyedi of HPE, “LightSuite Photonic Compiler fixes the biggest roadblocks preventing industry-wide adoption of electro-optical design and simulation of photonic chips. LightSuite Photonic Compiler circumvents those challenges and enables scalability. I’m thrilled to have worked with Mentor to develop this tool to make it possible for anyone to design and build photonic circuits as easily as designing electronic circuits.”

Before and after LightSuite
Prior to LighSuite, photonic designs are very involved and rudimentary. It includes the use of analog, full-custom IC tools to create photonic designs, manually place the components from a process design kit (PDK) and manually interconnect those components with curved waveguides. Furthermore, a full Calibre physical verification needs to be run to check for design rule violations. This can easily translate to DRC fixes and iterations.

As Lightsuite Photonic Compiler (LPC) is designated for handling photonic layout, designers have complete control of their layouts and easily perform automatic placement and route of both the photonic and electrical components. The setup amounts to creating a Python script to drive LPC. An initial placement can also be defined in either Python format or as a pre-placed OA (Open Access) design.

During LPC subsequent interconnect completion step, simultaneous electrical components route and photonics components hook-up with curved wave guides are done. With Mentor’s Calibre RealTime Custom integrated under-the-hood, designers can run LPC in interactive mode –with a Python IDE as the cockpit and the Viewer as output visualization facility. LPC uses Calibre RealTime Custom during the inner placement and routing loop, yielding a design-rule correct layout or “Correct by Calibre”. Furthermore, LPC enables designers to perform quick “what-if” design exploration, which traditionally was prohibitive. A comparative analysis between the manual approach versus LPC based on a 400 component photonic design shows a photonic cost saving (2 weeks versus 9 minutes)!.

Photonics foundry support currently includes AIM photonics, CEA Leti and is to be expanded to cover Smart Photonics, TowerJazz and Advanced Micro Foundry. For more details on Mentor’s LightSuite Photonic Compiler, please check HERE

September 25, 2018

Cloud FPGA Optimal Design Closure, Synthesis, and Timing Using Plunify’s AI Strategies

Cloud FPGA Optimal Design Closure, Synthesis, and Timing Using Plunify’s AI Strategies
by Camille Kokozaki on 09-25-2018 at 12:00 pm
Categories: EDA, FPGA

Plunify, powered by machine learning and the cloud, delivers cloud-based solutions and optimization software to enable a better quality of results, higher productivity and better efficiency for design. Plunify is a software company in the Electronic Design Market with a focus on FPGA. It was founded in 2009, has its HQ in Singapore and is a privately funded company focused on applying machine learning algorithms to FPGA timing and space optimization problems to solve design problems and achieve better optimized more efficient designs. Plunify has offices in Singapore, Malaysia, China, and Japan and has a sales representation network covering all major markets. Plunify is part of the Xilinx alliance partner and Intel EDA partners programs.

What Plunify solves
Complex FPGA designs require significantly iterative flows going from static timing analysis back to RTL code modification to achieve timing closure or the desired results. FPGA designers have long used this traditional approach when facing problems, consuming a lot of expensive engineering time in the process. FPGA vendor tools like Intel Quartus II and Xilinx Vivado/ISE provide the standard tool flow and the engineer’s time is then spent on (re-)writing RTL source code and constraints to achieve the target results. Plunify saw opportunities to reduce redundancies and extract the maximum level of optimization from the existing workflow by fully utilizing the inherent optimization directives of the FPGA tools.

Coupled with the emergence of cloud computing and their own machine learning algorithms, designers can achieve or get close to attaining timing closure in a shorter amount of time. This allows design cycles to complete faster and to significantly accelerate the process of getting complex products to market.

Products and Services
InTimeis a machine learning software that optimizes FPGA timing and performance. FPGA tools such as Vivado, Quartus and ISE provide massive optimization benefits with the right settings and techniques. InTime uses machine learning and built-in intelligence to identify such optimized strategies for synthesis and place-and-route. It actively learns from results to improve over time, extracting more than a 50% increase in design performance from the FPGA tools.

Plunify Cloud is a platform that simplifies the technical and security management aspects of accessing a cloud infrastructure. It enables any FPGA designer to compile and optimize FPGA applications on the cloud without having to be an IT expert. This is achieved with a suite of cloud-enabled tools, such as the FPGA Expansion Packand AI Lab, that provide easy accessibility to the cloud without the complexity of infrastructure and software configuration and maintenance.

Plunify Costs for Cloud Usage
Plunify Cloud is a platform that simplifies the technical and security management aspects of accessing a cloud infrastructure for FPGA designers. Free client tools are provided for FPGA designers to access the cloud. The platform uses a pre-paid credits system.
[table] style=”width: 500px”
|-
|
| Pre-paid credits at $0.084 each
Credits cover the cost for
1. Cloud Servers
2. Cloud Data Storage
3. Cloud Bandwidth
4. Tool Licenses, e.g. Vivado, InTime
5. Free use of client tools
|-

Cloud Enabled Tools

FPGA Expansion Pack

Expansion Pack Webpage

AI Lab
AI Lab provides greater access to Vivado and other Xilinx tools. There are no restrictions on the OS. Vivado HLx can run on Macs and even Chromebook. Converts IT to an operating expenditure and thus eliminates capital expenditure and on-premise maintenance. This allows more accurate forecasts and scalability based on actual demand.

AI Lab Webpage

InTime is a machine learning software that optimizes FPGA timing and performance. InTime does this by identifying optimized strategies for synthesis and place-and-route. It actively learns from multiple build results to improve over time, extracting up to 50% increase in design performance from the FPGA tools.

There are usually 3 ways to optimize timing and performance

Optimizing RTL & Constraint. This requires experience, is risky at a late stage, can introduce bugs and re-verification delays.
Optimizing Synthesis & Place and Route Settings
Using faster device types impacting cost and design

It makes sense to use all three for improved overall performance.

InTime works by:

Generating strategies based on database
Implementing all strategies and running them in parallel
Using machine learning to analyze results
Updating the database with new knowledge

Strategies are combinations of synthesis and place-&-route settings, including placement constraints.

InTime machine learning algorithms provide predictable improvements with optimal groups of settings as default settings are rarely adequate.

There are advantages in large deployments where multiple designs are analyzed due to additional data in the database increasing machine learning positive inferences.

Summary Overview of the Tools

Resources:

Plunify Corporate Introduction

September 25, 2018

Retro-uC: on a road to low-cost, (ridiculously) low-volume ASICs ?

Retro-uC: on a road to low-cost, (ridiculously) low-volume ASICs ?
by Staf_Verhaegen on 09-25-2018 at 7:00 am
Categories: EDA
2 Comments

I’m a long time reader of SemiWiki; almost from the start. I’ve sometimes been a passionate commenter but as some of you may have noticed my activity lately on the forum was lower. One of the reasons is a project I am working on and I feel honoured I was invited to present the background here on SemiWiki.

I am currently working at imec in the ASIC design service group. In our department we also have a group providing IC Manufacturing services. In our group we also design test chips and so are in close contact with the IC Manufacturing group. In that way I saw that startup costs for current nodes is high but is low for mature/older nodes. One of my hobbies is programming. I learned to use HP-UX at university and moved to Linux and into open source afterwards. One of the things that attracts me in open source is being part of the community where helping each other – rather than competing – is the norm. The Chips4Makers is a project grown out of these experiences; it wants to kickstart the open source community for custom chips. This should be possible by trading off features and speed for low startup costs so really low-volume production can be done. It is thus meant for niche markets with not enough volume to allow the higher startup costs of more recent nodes.

The goal of Chips4Makers is a real paradigm shift for the microelectronics industry and so the Retro-uC (Retro-microcontroller) pilot project was born. The purpose is to show the feasibility of low-cost and low-volume ASICs. I wanted something representative for the target market; a niche product with low volume not needing the state-of-the-art features of current high volume chips. Recently retrocomputing is in and also the maker movement – where people make their own system using things like an Arduino. The Retro-uC combines both use cases in one chip: a micro-controller using some of the venerable instruction sets – the Zilog Z80, MOS 6502 and Motorola 68000.

The original CPUs were developed in a time the number of transistors that could be put on a chip was limited and so does not take up much real estate on a chip even in a mature node. For the Retro-uC TSMC 0.35um was chosen and by using MPW (multi-project wafer) service the price of the silicon can be kept below $10000. Next to the silicon cost also the design costs are part of the startup costs. These include engineering, software license and IP license costs. If one would need to pay the license fee for a place-and-route tool of one of the EDA vendors it will cost more than the silicon for this project. I looked at existing open source code and although they are currently not able to design a chip in a state-of-the-art technology they are able to implement a low-complexity low-speed chip in a mature node. For the RTL code I used existing open source implementations that were used in emulators of old computers; so they are both free and almost bug free. The hours I spend myself on the project are not accounted for as in good tradition I see this as hobby time; like most of the makers do with their own creations.

The Retro-uC crowdfunding campaign pledge levels

I launched the Retro-uC as a crowdfunding project on Crowd Supply. This allows to test the markets before needing to do significant investments. The funding goal of the project is $22000 which is the break-even point including all production costs but also the processing and handling fees. I hope I’m not the only person in the world who would like to see an open source silicon movement getting traction. If you want to support me first thing you can do is back one or more of the pledge levels. If you have suggestions or want to discuss things don’t hesitate to comment on this article or send me a private message. On the Chips4Makers blog you can also find more detailed information on the project.

September 24, 2018March 21, 2022

Data Management for SoCs – Not Optional Anymore

Data Management for SoCs – Not Optional Anymore
by Alex Tan on 09-24-2018 at 12:00 pm
Categories: Cliosoft, EDA, Security

Design Management (DM) encompasses business decisions, strategies and processes that enable product innovations. It is the foundation for both effective collaboration and gaining competitive advantage in the industry. This also applies in the high-tech space we are in, as having a sound underlying SoC data management for SoC designs is key to a successful silicon roll-out and its subsequent product support.

Design environment – growth promotes challenges
Looking back, analog circuit was a dominant part of IC products until around the mid-eighties, when the introduction of logic synthesis and CMOS technologies facilitated further design tilt towards more digital circuits. With a recent slow down in the chip performance race and an industry inflection towards emerging applications such as IoT, automotive and 5G, the current design landscape is getting reversed again to have increased analog or mixed signal content. The following charts show demand trend in the shipped IC product indicating a richer analog/mixed signals circuits mix.

Consequently, the infrastructure for SoC design implementation and its related supports to mixed-signals/analog IP development have changed. Design environment heterogeneity is one of the primary challenges. It includes process technology (such as diverging process nodes used for analog block vs digital), IP (analog centric and packaging on top of digital IP) and EDA tools (multi-vendors as well as internally developed solutions). We could throw into the equation, potential communication voids as diverse design teams attempt to drive project forward under the constraints of geographical time difference and schedule crunch. It could lead to lack of visibility on the needed design collaterals and IPs across the company –trapped in the artificial silos.

A DM deployment brings efficiency into such an environment as it helps manage all aspects of the SoC design flow such as in dealing with multiple design processes and their associated collaterals (specification, RTL, schematic, layout, scripts, simulation results, etc). Designers do not need to take care of semantics related to file transfers (such as tar-ing or ftp-ing) across design sites. Moreover, DM is capable of finding differences between different versions of the text, schematics and layout.

Ownership, version control and security

An agile development environment could enhance the SoC build process. One primary challenge in a multi-site, multi-team project is design data ownership issue. It has been key in ensuring a smooth project execution as deliverables and accountability can be measured and proper resource load balancing cultivates cohesiveness across the project teams.

DM solution could provide answers to frequently raise questions such as:
→ who made these design changes? who last checked-out the file?;
→ what happened to my last working edit? what is part of this release update?;
→ how come the simulation is failing now while it was OK last night? how is it possible that my timing is off with the same library?);
→ why is it taking longer to compile now?.

With more recent cloud enabled EDA solutions, design data may be scattered not only across multiple platforms such as Windows or Linux but also on the cloud. Supporting such a diverse design environment for seamless access while keeping an adequate level of security to many design data confidentiality is quite a daunting task.

DM integrated environment enables revision control, release management and user access tracking –simplifying both tapeout checklist process and subsequent ECO (Engineering Change Order) steps.

Targeted archiving and disk space usage
Driven by increased functionalities being accommodated by continuous technology shift, design specification are constantly revised and may necessitate a migration to new codes and tool solution. Hence, tools selection can change in a company over several product generations, accompanied by their own collateral formats.

To resolve this issue, a DM should be capable of capturing only the necessary tool and design data. Selective captures of design meta-data also prevents waste of disk space and provides better disk space utilization. In the end, a DM structured database enables taking design snapshots and allows labeling for easy reference. Data repository is backed-up efficiently and design handoffs between teams are seamlessly done.

ClioSoft and DM
ClioSoft SOS7 is the DM solution capable of delivering the previously described features. As the leading developer of SoC DM with over 250 global customers, ClioSoft SOS7 has been architected to meet the performance, security, scalability and optimal network storage requirements of the global design industry. On top of the outlined benefits, project management audit trail or certification conformance queries can be easily addressed through the SOS7 integrated platform with customer design environment.

Similar to a honeycomb cells of a bee-hive, SOS7 DM integrated environment supports many forms of design development for analog, digital and mixed signal SoCs. It also provides socket-like, tight integration with many EDA implementation and analysis tools such as Cadence Virtuoso, Mentor Tanner, Synopsys Custom Designer, etc.

In summary, DM drives methodology across design organization including IT, design teams, program management and application/support teams. A robust, efficient and yet user-friendly DM platform is essential in ensuring successful adoption by all design data stakeholders. ClioSoft SOS7 seems to fit just the criteria.

For further info on ClioSoft SOS7, please check HERE.

Also Read

Managing Your Ballooning Network Storage

HCM Is More Than Data Management

ClioSoft and SemiWiki Winning

September 24, 2018January 10, 2020

Highly Modular, AI Specialized, DNA 100 IP Core Target IoT to ADAS

Highly Modular, AI Specialized, DNA 100 IP Core Target IoT to ADAS
by Eric Esteve on 09-24-2018 at 7:00 am
Categories: AI, Automotive, Cadence, IoT, IP, Mobile

The Cadence Tensilica DNA100 DSP IP core is not a one-size-fits-all device. But it’s highly modular in order to support AI processing at the edge, delivering from 0.5 TMAC for on-device IoT up to 10s or 100 TMACs to support autonomous vehicle (ADAS). If you remember the first talks about IoT and Cloud, a couple of years ago, the IoT device was supposed to collect data at the edge and send it to the cloud through wireless network or internet where the data was processed. And the way back to send the processing result to the edge.

But this model appeared to be a waste of energy (sending data back and forth through networks has high power consumption cost) and a lack of privacy (especially for consumer application). But the worse was probably the impact on latency: can we safely rely on autonomous car if ADAS data processing is dependant to a cloud access. On top of adding unacceptable latency, the data travel through network is clearly dependant of the existence of such network (what about rural areas?).

Hopefully, the industry came back to a reasonable solution, data processing at the edge device! Supporting processing at the edge is not challenges-free: the SoC located at the edge must be as low-cost as possible, it must be performance-efficient to keep power consumption low. Even if a standard GPU could do the job, a SoC integrating DSP IP is the best solution to meet these constraints…

Cadence is launching Tensilica DNA 100 to support on-device AI processing in multiple applications. In fact, AI processing is penetrating in many market segments, in multiple applications. In mobile, the consumer expects to experience face detection and people recognition, at video capture rates. On-device AI will support object detection, people recognition, gesture recognition and eye tracking in AR/VR headsets. Surveillance cameras will need on-device AI for family or stranger recognition and anomaly detection. In automotive, for ADAS and AV, on-device AI will be used to recognize pedestrians, cars, signs, lanes, driver alertness, etc.

But these various markets have different performance requirements for on-device AI inferencing! For IoT, 0.5 TMAC is expected to be enough, when for mobile, the performance range is in the 0.5 to 2TMACs. AR/VR, with 1 to 4TMACs range is slightly higher, when for smart surveillance the need is in the 2 to 10 TMACs. Autonomous vehicle is clearly the most demanding application, as on-device AI inferencing requires from several 10s to 100 TMACs. The solution is to build a DSP core, the DNA 100 processor, which can be implemented as an array of cores, from 1 to a number as high as authorized by the area and power target…

If you look at the DNA 100 block diagram (above picture), you see that the core provides:
Bandwidth reduction, thanks to weight and activation compression,
Compute reduction as the MAC process non-zero operations only,
Efficient convolution through high MAC occupancy rate,
Pooling, Sigmoid, tanh and Eltwise add or sub for non-convolution layers.
Moreover, as the DNA 100 is programmable, it makes the SoC future proof and also extensible, by adding custom layers.

Cadence claims the Tensilica DNA 100 processor performance to be up to 4.7 time better than the competition (CEVA DSP?) thanks to sparse compute and high MAC utilization. The benchmark has been made on ResNet50, the processor running at 1GHz and processing 2550 frames per second. Tensilica DNA 100 processor and competition are both 4TMAC physical array configuration, and DNA 100 processor numbers are with network pruning, assuming 35% sparse weights and 60% sparse activation.

A figure is becoming more and more important, as the industry realize that performance can’t be the only criteria: power efficiency. Cadence is claiming to be 2.3 X better than the competition, in term of TMACs per Watt, for a DNA 100 processor with network pruning and 4TMAC configuration in 16nm (Tensilica DNA 100 delivers 3.4 TMAC per Watt, when the competition only reach 1.5 TMAC/W.

The above figure describe neural network mapping onto DNA 100 processor. This direct us to look at software support, Cadence proposing Tensilica Neural Network Compiler and supporting Android Neural Network App. Dated September 13 2018, this annoucement from Facebook about GLOW: a community-driven approach to AI infrastructure: “Today we are annoucing the next steps in Facebook’s efforts to build a hardware ecosystem for machine learning through partner support of the Glow compiler. We’re pleased to announce that Cadence, Esperanto, Intel, Marvell, and Qualcom Technologies inc. have commited to supporting Glow in future silicon products”

According with Cadence, “Integrating Facebook’s Glow, an open-source machine learning compiler based on LLVM (Low Level Virtual Machine), to enable a modular, robust and easily extensible approach”.
Modular, robust and extensible, the DNA 100 processor is well positioned to support AI on-device inference, from IoT to autonomous car…

The following link to get more information about the DNA 100 DSPs

ByEric Esteve fromIPnest