IC designers have been creating with hierarchy for years to better manage large design sizes, however for the test world the concept of hierarchy and emerging standards is a bit newer. TSMC and Synopsys jointly created a webinarthat addresses hierarchical test, so I’ve attended it this week and summarized my findings here.Adam Cron, Synopsys Continue reading “Why Adopt Hierarchical Test for SoC Designs”
At the recent GSA Entrepreneurship Forumone of the panelists was Angel Orrantia of Innopartners who are trying a novel approach to funding startups in the semiconductor space and the surrounding ecosystem.
It seems things got started with an innovation center inside SK Hynix. Just in case you have forgotten, Hynix is the newish name for Hyundai Electronics (the name comes from HYundai electroNICS) which subsequently merged with LG Semiconductor. In 2012 SK group acquired a 21% share of Hynix. The corporate structure is complex, but the important bits are that SK Telecom is the parent of SK Hynix and of SK Telecom Americas inside which is the Innopartners Innovation Center where Angel works. Phew.
SK had historically grown by identifying and acquiring companies (like, well, Hynix) but it was getting historically hard to find companies to build the portfolio since the innovation model of venture capital funding was broken in this area. VCs only want to invest in companies that have a chance of being the next Instagram or Dropbox. For instance, in 2003 there were 44 semiconductor/nanotechnology companies funded; in 2011 just 3.
So if there are no companies to harvest then it is time to create your own garden and grow some yourself.
So in April this year Innopartners was founded here in Silicon Valley (in Sunnyvale in temporary quarters while the building they will eventually occupy is being built). They have been actively looking for investments for a few months and close to closing the first few (two expected by the end of August, 3-5 by the end of the year).
The investment model is to bring companies into the incubator for 6-12 months, although there is no fixed timetable. That gets them through to the seed stage where a prototype exists, or some data is validated. They then look for strategic investors. Strategic is a sort of code word in the investment world meaning companies that are not just financial: they are at least potentially interested in the technology for use internally. SK also have SKTA which can invest along with strategic (and even VCs if there are any interested) for a 2-3 year funding horizon.
The intention is that eventually the company will be acquired by a strategic partner. This could be SK Telecom or Hynix but there is no obligation to feed all investments back inside in that way, it depends on who the most appropriate partner is. For example, a materials company might find a home in a semiconductor equipment company. Since Hynix builds semiconductors, of course, it might still benefit strategically from the investment even without acquiring it. Or, like so many startups, the precise business might have morphed into something else and no longer be as good a match.
The SK Innopartners white paper is here.
There never seems to be enough time in a SoC project to simulate all of the cycles and tests that you want to run, so any technique to accelerate each run is welcomed. You can just wait for your software-based RTL simulator to finish running, or you can consider using a hardware-based accelerator approach. I learned more about one such acceleration approach from Aldec at a recent webinar entitled, Accelerate SoC Simulation Time of Newer Generation FPGAs.
Bill Tomas, Aldec
Timing exceptions are ways of guiding design tools, primarily synthesis and static timing analysis (STA), but these days also place & route and perhaps other tools. Most paths in a design go from one register to the next register. Both registers are on the same clock, and the design needs to ensure that the signal can make it from the first register, through the logic gates, and get to the next register in time to meet the setup time there, and so successfully get clocked into that next register. Synthesis will pick appropriate cells to make it so, and STA will check that this was done correctly.
But what happens when that isn’t true. If the two registers are on different clocks, or if we don’t really care if the value is correctly latched since we are never going to use it, or it is only for a test mode that is run at low speed, or if we don’t latch the value until two clock cycles later. Then we need to tell the tools, and this is done using timing exceptions, typically in the SDC constraint file.
There are three main types of timing exception:
There are two types of problem with timing exceptions. The first is where there is a timing exception but we didn’t declare it. The tools will work hard to meet the constraint anyway, and if they succeed then there may be some waste but the design will work. On the other hand, we can declare a timing exception and tell the tools to ignore something, when it turns out it was important. This can be a real disaster, resulting in non-functional silicon that apparently passes all verification successfully.
Setting a false path (using set_false_path command in SDC) is used for the following reasons:
Setting a multicycle path (using set_multicycle_path in SDC) is done to relax timing requirements. However, care still needs to be taken with relaxed timing to ensure that races and glitches are not created and, indeed, that the functionality of the design and the relationship between the various stages is properly understood.
SpyGlass TXV (Timing eXception Verification) is a good way to verify these exceptions and catch many errors. This is increasingly important now that so much of a design is 3rd party IP where the RTL and the timing constraints are not well-understood by the SoC design team who didn’t create them.
A much more detailed white paperAvoiding Pitfalls While Specifying Timing Exceptions is available on Atrenta’s website here.
[The VLC developed by Edison2, winner of the Progressive Automotive X-Prize]
Now that we have “The Very Light Car” of the world at more than 100 MPG!! Yes, this is the car developed by Edison2, one among the three winners of the Progressive Insurance Automotive X-Prize, a global competition; Edison2 won in the main stream class. Err… I am not doing a car advertisement here; one could fly and then drive too. I just wanted to draw attention towards the activities which go behind the scene in making these cars; well other automotives like trucks, military vehicles etc., aerospace, off-highway as well for that matter – ultimate comfort, information systems, electrical systems, safety, warning on any fault, environment friendly, low on fuel, easy driving, automated systems and what not. After all, we spend a considerable portion of our lives in cars, aeroplanes, trains and other modes of travel, so why not continue to improve on these parameters to create lifetime experiences!
That’s where we are; experts in creating these experiences will be talking for the day long on 19[SUP]th[/SUP] Sep, 2013 at Integrated Electrical Solutions Forum (IESF 2013) at Ford Conference Centre in Dearborn (Detroit), Michigan, USA. And that’s a free conference covering all aspects of electrical and electronic systems in automotives that includes commercial vehicle and off-highway industries as well. Thanks to the EDA pioneer, Mentor Graphics for leading the automotive electronics space and specifically for holding this conference along with IBM and SAE International as sponsors.
Some of the key attractions of this conference are – A keynote address by Oliver Kuttner, Founder and CEO of Edison2; a dedicated track to electric and hybrid vehicle design; a presentation by Angus Lyon, Chief Engineer atDrayson Racing Technologies, the company that set a new World Electric Land Speed Record of 204.185 MPH; and a presentation by Adam Fowlkes, Electrical Engineering Manager atProterra Inc., the leading provider of zero-emission commercial transit solutions.
There are about 70 other sessions which include innovative presentations from Industry leaders on design, architecture, process, system engineering, wire harness design and engineering, embedded software, network design and integration, strategic reuse, thermal design, in-vehicle infotainment, standards (e.g. AUTOSTAR, GENIVI, SAE, ISO26262, EWIS, DO-254) and many more. This is a unique conference which addresses design challenges and solutions in automotive, aerospace and off-highway industries. Industry leaders from automotive, aerospace, semiconductors and design engineering ecosystem join hands and share their best breed of designs, best practices, and industry trends. A nice intellectual platform to attend and know the best ways to enhance our life experiences!!
Click to register for free and know the detailed program. Courtesy organizers for rolling this conference around the world for those who wouldn’t be able to fly at this time – Sep 25, Pune, India; Sep 25, Nagoya and Shinagawa (Tokyo), Japan; Oct 24, Munich, Germany; Dec 11, Shanghai, China. I’m moved to see the “Remind me” link for these future events on the page, so much generous sponsors!!
Also, if anyone wants to contribute in this community initiative, there is a link to submit papers for a future IESF event.
How do you benchmark a processor? It seems like it should be easy, just run some code and see how fast it is. Traditionally processors were indeed benchmarked by raw performance like GMACS, GFLOPS, memory bandwidth and so on. But in today’s world where systems have become very complex and applications very compute intensive, the raw numbers don’t mean very much.
If you are benchmarking a general purpose processor for something like a PC where you don’t actually know what code it will run, then there are general purpose benchmarks. However, if you are benchmarking a specialized processor that is going to run a largely fixed workload then a general purpose benchmark is completely inappropriate. Although there are designs where very high performance processors can be used to keep power low (basically “race to halt” and then power the whole system down until the next race begins), typically a fast-enough processor that minimizes power is the sweet spot (and it mustn’t take up too much area: cost is an important aspect too, of course).
A good piece to read is the Berkeley Design Technology Inc white paper (BDTI, not to be confused with Berkeley Design Automation) The Art of Processor Benchmarking: What Makes a Good Benchmark and Why You Should Care.
Good benchmarks need to be complex so as to exercise the entire system including cache hit rates, cache latency, branch prediction. The system performance is not just the raw performance of the processor core itself running a tight inner loop.
One challenge is that algorithms are constantly changing, especially in new areas such as new wireless standards, vision processing, face recognition, voice recognition and so on. Of course these are just the areas that a product can leverage and differentiate by running good software on a well-matched hardware solution. In some of these areas there are some benchmark suites but sometimes the algorithms are simply too unstable for benchmarks to have yet been created.
One area in particular where benchmarks are emerging is in vision processing. While not specifically a benchmark, the OpenCV vision processing library contains many common algorithms such as red-eye removal, object recognition, image similarity and so on. An appropriate selection of these algorithms can be used as a representative workload for evaluating a processor subsystem.
Two more benchmark suites, the San Diego Vision Benchmark Suite (SD-VBS) and the Michigan Embedded Vision Benchmark Suite (MEVBench) draw algorithms from a diverse set of application domains. SD-VBS (first published in 2009) includes 28 non-trivial computationally intensive kernels such as feature tracking, image stitch and texture synthesis. MEVBench (first published in 2011) is built using full algorithms such as virtual reality and, further, contains a subset suitable for mobile embedded vision.
This is obviously a long way from simply counting how many multiply-accumulates a processor can run when it is put in a tight loop. It requires looking at a real-world software load and actually digging down into the PPA points that can realistically be implemented in the target process. Anything less risks being completely misleading, leading to picking a processor that is not a good match for the job in hand.
Cadence is 25 years old this year, on June 1st if you want to be precise.
The most direct ancestor of Cadence was SDA (which might or might not have stood for Solomon Design Automation). SDA was founded by Jim Solomon in 1983. It turns out that a guy I shared an office with while we were both doing our PhDs in Edinburgh Scotland was one of the early employees: Graham Wood. After getting his PhD he worked at Bell Labs at Murray Hill for a time before moving out to California. I got my PhD and came straight to California and joined VLSI Technology, itself a pre-IPO startup when I joined although it went public in 1983 before SDA even existed. Graham suggested that I should come and interview at the new SDA but I decided I was happy at VLSI Technology where we were creating the ASIC revolution and had, at the time, the best IC design tools available. I wasn’t smart enough to realize that the money was all in the software and customers would not want their EDA tools to be tied to their manufacturing. Graham went on to invent SKILL which, even today over 25 years later, is at the heart of Cadence’s layout environment.
SDA was funded in a novel way by subscriptions from a handful of semiconductor companies, initially National Semiconductor (where Jim Solomon workd) and General Electric. Subsequently they would add Harris Semiconductor, Ericsson, Toshiba and SGS (in Italy, today it is the S in ST Microelectronics). These companies knew that semiconductor design was changing but that they didn’t have strong enough internal groups to develop their own toolchains.
SDA had analog design tools, early place and route, and an early framework to tie all the graphics and data management together (although I don’t think they used the word framework back in that era).
SDA filed to go public. They did the roadshow. They decided the IPO would take place on October 19th 1987. Oops. That day is known as Black Monday, the day of the 1987 stock-market crash when the DJIA fell 23%.
Meanwhile, Glen Antle had formed a company called ECAD that provided design rule checking. By formed I mean that it was spun out of System Engineering Laboratories, SEL. That DRC was called Dracula, of course. They would continue to develop LVS (layout-versus-schematic) and other products.
Earlier in 1987 they also filed to go public, did their roadshow and decided the IPO would take place on June 10th. The stockmarket didn’t crash and ECAD went public successfully.
In mid 1988, SDA and ECAD merged. The deal was structured as an acquisition of SDA by ECAD since ECAD was already public. The new company was called Cadence. Somewhat surprisingly, since he wasn’t the CEO of SDA, and because ECAD was the acquiring company at least on paper, the new CEO of Cadence was Joe Costello.
There were a lot of mergers over the years but I think that three were especially important:
I was unable to escape the gravitational tractor beam of Cadence forever. I was the VP Engineering of Ambit when we were acquired in 1998 and ended up staying for 3 years.
More details on Cadence’s 25 year anniversary are here.
The presentations from the 450mm sessions at SEMICON West are up now. After talking to equipment manufacturers and the foundries I’m fairly confident 450mm wafers will be under our Christmas trees in 2016, absolutely. TSMC just increased CAPEX again and you can be sure 450mm is part of it. SEMI has a 450mm Central landing page HERE. The SEMICON West 450mm Transition presentations are HERE. The Global 450mm Consortium is HERE. Everything you ever wanted to know about 450mm wafers just a click away; you’re welcome.
Intel, Samsung, and TSMC have invested heavily in 450mm and will have fabs built and operational in 2015 (my opinion). Given the pricing pressures and increasing capacity demands of the mobile semiconductor market 450mm wafers will be mandatory to maintain healthy margins. Based on the data from SEMICON West and follow-up discussions, this is my quick rundown on why moving from a 12” wafer (300mm) to an 18” wafer (450mm) is the next technical innovation we will see this decade.
First and foremost is timing. 14nm wafers will begin production in 2014 with 10nm slated for 2016. Ramping already production worthy 14nm wafers in a new 450mm fab reduces risk and the semiconductor industry is all about reducing risk. Second is wafer margins. As I mentioned before, there will be a glut of 14nm wafers with no less than six companies (Intel, Samsung, TSMC, GLOBALFOUNDRIES, UMC, and SMIC) manufacturing them 24/7. The semiconductor industry has never ever seen this kind of total capacity increase for a given node. Add in that the mobile electronics market (phones and tablets) have reached commodity status, wafer margins will be under even more pressure than ever before. Just like the top criteria for investing in real estate: location, location, location. Wafer purchasing criteria at 20nm and below will be: price, price, price.
According to Intel a 450mm fab will cost twice as much as a 300mm fab with equipment accounting for the majority of the delta. The wafer handling equipment is a good example. The additional size and weight of the 450mm wafers will require complete retooling. If you have never been in a fab let me tell you it is something to see. The wafers zip around on ceiling mounted shuttles like something out of a Star Wars movie. As much as I would like to change our dinner plates at home from 12” to 18” to accommodate my increasing appetite, I certainly don’t want to buy a new dishwasher and cabinets to store them.
The ROI of 450mm wafers however is compelling. A 450mm fab with equal wafer capacity to a 300mm fab can produce 2x the amount of die. If you roughly calculate die cost, a 14nm die from a 450mm wafer will cost 23% less than a 300mm wafer. This number is an average of numbers shared with me by friends that work for: an IDM, a foundry, a large fabless company, and an equipment manufacturer. Sound reasonable?
lang: en_US
The 80s called, and they want lazy programming back. Remember “Mr. Mom”? Michael Keaton is talking about rewiring the house, and Martin Mull asks if he’s going to use all 220V, and Keaton responds “Yeah, 220, 221, whatever it takes.” Not knowing what’s inside can make you look silly.
Such is the case with OpenGL ES. Taking a look at how the device actually supports graphics can mean big differences in results. A key area of differentiation is how texture maps are stored, and the support for that in hardware and software. Storing uncompressed or lightly compressed stuff works, but is not very efficient – modern implementations rely on texture compression algorithms to get faster results with less bandwidth and better memory utilization.
One reason the graphics on Apple smart devices are so beautifully consistent is TextureTool, native support in the iOS SDK for compressing textures into the PVRTC format. In and of itself, that isn’t remarkable until adding that PVRTC is supported directly in hardware in the Imagination Technologies PowerVR SGX family of GPUs found in Apple devices. Hardware acceleration for software features almost always wins, and if an accelerator is available it should be utilized. One choice for texture compression in iOS, everyone and everything optimizes for it, and all is well.
Now move over to the Android camp for comparison. There are several texture compression formats in play, and a given phone may or may not have hardware acceleration for them. With underlying support in OpenGL ES, all Android versions since Froyo support ETC1, and most GPU hardware supports it (or ETC2). There are four other formats supported in OpenGL ES 3.0:
ATITC, found in Qualcomm Adreno GPU and AMD implementations (yes, as in ATI);
DTXC, also known as S3TC, favored by NVIDIA, Microsoft et al (yes, as in DirectX);
ASTC, developed by ARM for its Mali GPU;
PVRTC, for Imagination PowerVR SGX implementations.
(image courtesy Intel)
Are you beginning to sense why Android graphics benchmarking results vary so wildly? (Before going off on the visual quality compression produces, let’s take into consideration there is a lighting difference between the left and right side of that image. What I’d like to see is slices of the left eye side by side, and the other formats.)
The naïve Android developer plows into this like they are heading out to body surf waves at Newport Beach, thinking they will get decent results just from watching what other people are doing. It’s harder than it looks. I was reading a game developer forum discussing the merits of ETC1 versus the other texture compression schemes, and the non-conclusive response was startling: if you pick a format not supported in hardware, what you get is software decompression on load using CPU, not GPU, cycles. Ouch. “That may explain our loading times” might be the understatement of the decade. Even Apple advises app developers to check for texture compression file extensions before using them.
The good news is we have general agreement on OpenGL ES for mobile devices, and using some form of texture compression. If you are an Apple developer, the choice of PVRTC is clear for the foreseeable future. If you are developing for Android, Windows, or other environments, PVRTC is one of several options. Selecting a texture compression scheme is more than a software decision, hitting four dimensions that can make or break an implementation: visual quality, memory footprint and bandwidth, power consumption, and overall performance – all functions of a GPU and software support working together.
I have an interesting assignment: to take an objective look at PVRTC, combining information from Imagination Technologies and third party sources. We’ll start with some background: four high-level discussions of some of the issues involved.
Imagination’s overview of PVRTC:
PVTRC: the most efficient texture compression standard for the mobile graphics world
Apple’s OpenGL ES programming guide:
Best Practices for Working with Texture Data
The Android view of OpenGL ES including texture compression:
OpenGL ES | Android Developers Guide
A good overview written by an Intel intern (with some “consider the source” caveats):
Android Texture Compression
Future posts will look at how PVRTC works, what it clearly does well (example: producing small files), where there is some debate (example: visual quality on some images and different algorithms), and more. I’d be happy to hear from those with experience on these issues, and other useful resources we should be looking at.
lang: en_US
I first heard about Andrew Yang back in 1993 when he founded a Fast SPICE company called Anagram, then acquired by Avant! in 1996. Andrew’s latest EDA company Apache Design, Inc.was started in 2001, then acquired by ANSYS in 2011. Most EDA mergers simply don’t work because of one or more reasons, like:
Andrew Yang, Apache co-founder
Being curious, I set out to uncover why the Ansys acquisition of Apache was successful and did not fall apart.
Q&A
Q: You’ve gone through more than one acquisition in EDA, so why did the ANSYS acquisition of Apache turn out successful?
We’ve had a simple strategy to have a non-overlapping product line, and a non-disruptive execution. Our Apache team has a great track record, so there was no disruption in how we did our business.
Other EDA companies can acquire overlapping product lines, which causes problems.
Q: How do products from Apache and ANSYS have synergy?
ANSYS always had the culture of expanding into new industries, like the semiconductor space. With Apache, now ANSYS adds chip-aware tools.
From Apache’s view we look at Chip-Package-System type of EDA analysis tools, so joining ANSYS helped us grow into new markets.
Q: Often in EDA, the company being acquired will have little control over product and sales direction. Why was this different with ANSYS?
The strategy was to not disrupt what was working with Apache in terms of product and sales. Apache customers continue to work with their same account managers and AE’s, so they’ve had a continuous experience.
Q: Is Apache growing?
Yes, in the past 8 quarters we have met or exceeded our sales targets, we’re growing faster than the EDA industry rate. Also our margins have been growing, not just sales.
Q: What is new at Apache since the acquisition?
We have been constantly innovating with new products and efficiently, so we have to keep up with Moore’s Law in terms of capacity. We are certified for FinFETs at TSMC and Samsung. With Distributed Machine Processing (DMP) technology it allows us to scale the capacity requirements for the next several years.
Other approaches like High Performance Computing (HPC) are focused on parallel processing, however with DMP we are solving highly-connected power meshes demanding highest accuracy.
Q: Who is using Apache tools today?
IC Insight published a list of the top 20 semiconductor companies, and we are serving all 20 of these leading companies with Apache tools. Most of our growth is coming from the mobile SoC companies. We serve 9 of the top 10 mobile SoC companies.
At automotive companies we are serving 9 of the top 10 companies.
Q: What are Apache’s plans for the next 12 months to ensure continued growth?
Keep our sales team focused on Apache products and AEs supporting customers, so no structural changes. Our strategy is to continue to keep up with Moore’s Law.
Q: What would you say to new EDA start-ups?
There are lots of challenges going down to the 10nm node to be solved.
Q: Does Apache have any lawsuits?
No, we have been at the forefront of technology so nobody has file suit against us.
Q: How about patents?
We do have a good number of patents and within ANSYS we continue to protect our intellectual property by adding more patents.
Further Reading
Dr. Yang blogged about the two year anniversary of the acquisition earlier this month.
lang: en_US
