Bronco Webinar 800x100 1
Semiconductor Expert Forum

Posted on

Caution: Reset Domains Crossing

Caution: Reset Domains Crossing
by Bernard Murphy on 04-01-2017 at 7:00 am
Categories: EDA, Events

Because you can never have too much to worry about in verification, reset domain crossings (RDCs) are another hazard lying in wait to derail your design. Which hardly seems fair. We like to think of resets as dependable anchors to get us back on track when all else fails, but it seems their dependability is not absolute, especially in modern designs.

We all know about clock domain crossings (CDCs), a problem that has been amplified by the integration onto SoCs of multiple interface standards along with high-performance compute engines, each needing to support different clock speeds. Signals passing between different clock domains on these devices are at risk of lock-up through metastability and/or loss of data. Finding and correcting these potential problems takes careful analysis.

Reset domains have also been with us for a while, but have especially proliferated in SoC design and design for low-power where, in additional to standard blanket resets like POR and software reset, we now find an abundance of local reset options, controlled at the IP or functional domain level. In the spirit of providing maximum controllability over power saving, IPs may have separate reset inputs for hard reset, soft reset, reset preserving retention registers and other options. At the system-level, application of reset has become more complex, requiring that application or release of reset be sequenced between functions; release on many blocks must wait at least until the controlling CPU has booted to ensure that startup from reset in those downstream blocks is well-controlled.

But this complexity is not the root-cause of RDCs, which start with asynchronous resets. The complexity, along with realities of multi-sourced IP design, simply makes RDCs harder to anticipate and isolate. An “ideal” way to fix the problem might be to forbid use of asynchronous reset. A lot has been written on the relative merits of synchronous versus asynchronous reset. Without getting into that debate, it is enough to observe that any place you need to ensure a reset where you may not yet have a clock (e.g. in the presence of gated clocks or switchable power domains) requires an asynchronous control to ensure the reset is applied. Then there’s the multi-sourced IP; you may have dominion over reset practices in your own IP, but you can’t control how other IP suppliers choose to reset. So RDCs can’t be banished – you have to learn to deal with them.

There are several different ways in which an RDC hazard can be created. One simple case that can occur is a path crossing between two flops, quite possibly using the same clock, where the first flop is asynchronously gated by RST_A and the second is asynchronously gated by RST_B. If RST_A and RST_B are not related, this becomes an asynchronous crossing and there is risk the second flop can become metastable or may sample incorrect data.

Another case has a reset synchronized in clock domain 1 but used asynchronously in clock domain 2. Because the reset is not synchronized to the second clock domain, again there is a metastability and/or incorrect data sampling hazard.

Even if you carefully generate reset signals synchronous to the domain clock and you’re not crossing between clock domains, you aren’t necessarily off the hook. In the example above, where both domains even use the same clock, there is still an RDC hazard because the path marked in red is not timed in STA and crosses between two potentially asynchronous reset domains.

Problems of this nature can be particularly dangerous for configuration registers, which are often exempt from warm-resets to speed-up recovery after reset. If an upstream warm-reset is applied while the configuration register is being written, an async crossing can corrupt the contents. A similar problem can occur in drivers for memory controller logic. If signals like chip select and write-enable can be asynchronously reset, again you may have a hazard.

There are plenty of other examples, distinguished more by the varieties of havoc they can wreak on the correct operation of your design, than by differences in root-cause. Correction is often not difficult, through more careful selection of resets and use of reset synchronizers. The real challenge here is in finding potential hazards scattered across large SoC designs. That’s where a tool like Meridian RDC from Realntent can help.

You can learn more about finding and correcting RDC hazards by registering for the RealIntent white-paper.

More articles by Bernard…

Posted on

Lowering Costs for Custom SoC Development – ARM and Tanner EDA

Lowering Costs for Custom SoC Development – ARM and Tanner EDA
by Daniel Payne on 03-31-2017 at 12:00 pm
Categories: Arm, EDA, IoT, IP, Siemens EDA, Tanner EDA

Cost is a major barrier when an electronic design company starts to consider developing a custom SoC for a particular market segment. But what if there was a way to lower the development cost, or even get to an SoC proof of concept for no cost except of course for your engineering expenses? That value proposition caught my attention immediately so I attended a webinar hosted by ARM (part of Softbank) and Tanner EDA (part of Mentor Graphics, soon to be part of Siemens) on March 28th to see if there was any catch involved.

Phil Burr from ARM was up first and he was able to categorize who is designing new SoCs today into three segments:

[LIST=1]

  • Sensor and mixed-signal companies designing IoT
  • Start-ups wanting to innovate
  • OEMs wanting to reduce cost, power and be unique

    ARM sees seven industries driving new SoC development:

    • Retail
    • Smart lighting
    • Medical
    • Industrial
    • Home
    • Agriculture
    • Building automation

    Companies that choose the SoC route can expect benefits like an 85% reduction in PCB area compared to component designs, a 90% reduction in their BOM, being different from other competitors, being able to protect their IP because the SoC is not using easily bought components from a parts catalog, and finally an easier way to control the supply chain. The folks at ARM have responded to these market conditions by creating something called the Cortex-M0 DesignStart which lets you integrate your own semiconductor IP with the popular 32 bit processor Cortex-M0, along with a system design kit. If all you need to do is to show proof of concept then you can do a virtual design for free. Two other options from ARM are using their FPGA prototype system for $995, or buying a license for the Cortex-M0 along with SDK, Keil MDK and support for $40K:

    The Cortex-M0 is the most compact 32 bit processor offered by ARM, which also means lower costs to designers. Code density with the Cortex-M is actually better than competitor’s 8 and 16 bit offerings as measured with CoreMark code, giving you lower power consumption and smaller flash size:

    So with DesignStart you get the processor IP from ARM, evaluation EDA tools from Mentor Graphics and if needed there are design partner services that are recommended and vetted by ARM (Open-Silicon, sondrel, SOC Solutions, hdl Design House, e-infochips, ADT). For process nodes you can choose to fab your ARM-based SOC at foundries across a wide range like 350nm all the way down to 28nm. Using shared wafers you can get test chips produced in 180nm for as little as $16K, so think affordable.

    Related blog – IoT Device Designers Get Help from ARMv8-M Cores

    Next up in the webinar was Jeff Miller from Tanner EDA and he shared how their company started way back in 1988 and has customers doing both AMS and MEMS designs. Mentor acquired Tanner in 2015, and it is one of the few EDA mergers that is still happily functioning quite well. Customers of Tanner EDA include JPL (image sensors on the Mars rovers), FLIR, Knowles, Proteus, NeuroPace and Second Sight. Jeff talked about some characteristics of IoT designs, like: High volume, low cost, small physical size, and low power.

    One IoT design example shared was from Swindon Silicon Systems with their Tire Pressure Measurement System (TPMS) that has shipped 100’s of millions units. They used two dies combined into a single package which is then placed inside of an auto tire to measure tire pressure, then send that data by RF to the car. The pressure sensor is designed as a MEMS and occupies one chip, then the second chip does the RF transmission, analog, ADC, and digital control:

    Typical building blocks for an IoT device are shown below:

    Mentor Graphics has three categories of software to help in the design of an IoT device:

    • Tanner EDA

      • Analog/Mixed-Signal
      • MEMS
      • Digital
      • RF
    • Nucleus

      • Embedded Software
    • PADS

      • Printed circuit board

    Related blog – Managing the IoT

    Focusing on the Tanner EDA offering, there are several tools for both the front-end and back-end of an Analog Mixed-Signal design:

    For the grand finale Jeff demonstrated how an ADC block found in most IoT devices could be entered using the schematic capture tool (S-Edit), simulated the ADC with a circuit simulator (T-Spice), connected a custom block to the AMBA peripheral bus, wrote some test firmware in C code using the Keil IDE, finally simulated the ARM Cortex-M0 with the test firmware and the custom ADC block. Here’s a block diagram of the demo design:

    Analog waveform results show up in the Tanner EDA viewer, while digital results show up in the ModelSim tool:

    Summary
    Instead of starting from scratch to create your next IoT design project that needs a processor and AMS blocks, you can instead consider using the approach offered by ARM and Tanner EDA to quickly get to your IoT proof of concept at very low to no extra costs, outside of the engineering time. Enjoy getting a head start because Tanner EDA includes all of their demo files shown in the webinar. If you are short on engineering experience, then talk to one of the ARM recommended design partners to get started.

    View the archived webinar online today.

    • Posted on

    SNUG and Robots

    SNUG and Robots
    by Bernard Murphy on 03-31-2017 at 7:00 am
    Categories: EDA, Synopsys

    I got an invite to the SNUG (Synopsys User Group meeting) keynotes this year. I could only make it to the second keynote but what a treat that was. The speaker was Dr. Peter Stone, professor and chair of CS at UT Austin. He also chaired the inaugural panel for the Stanford 100-year study on AI. This is a guy who knows more about AI than most of us will ever understand. In addition to that, he’s a very entertaining speaker who knows both how to do and how to communicate very relatable research.


    His team’s research is built around a fascinating problem which I expect will generate new discoveries and new directions for research for many years to come. Officially this is work in his Learning Agents Research Group (LARG), slightly less officially it is around learning multi-agent reasoning for autonomous robots but mostly (in this talk at least) it’s about building robot teams to play soccer.

    The immediate appeal of course is simply watching and speculating on how the robots operate. These little guys play rather slowly with not much in the way of nail-biting moments but it’s fascinating to watch how they do it, especially in cooperative behavior between robots on the same team and competitive behavior between teams. When one robot gets the ball, forwards move downfield so they can take a pass. Meanwhile competitors move towards the player with the ball or move back upfield to intercept a pass or to block shots. The research behind this is so rich and varied that the speaker said he could easily spend an hour just presenting on any one aspect of what it takes to make this happen. I’m going to touch briefly on a few things he discussed that should strike you immediately.

    When we think about AI, we generally think about a single intelligent actor performing a task – recognition, playing Jeopardy or Go or driving a car. The intelligence needs to be able to adapt in at least some of these cases but there is little/no need to cooperate, except to avoid problems. But robot soccer requires multi-agent reasoning. There are multiple actors who must collaboratively work to meet a goal. We talk about cars doing something similar someday, though what I have seen recently still has each car following its own goal with adjustments to avoid collision (multi-agent reasoning would focus on team goals like congestion management).

    You might think this could be handled by individual robot intelligence handling local needs and a master intelligence handling team strategy, or perhaps though collaborative learning. From the outset, master command-center options were disallowed and team learning was nixed by the drop-in team challenge, asserting that any team player can be replaced with a new member with whom the players had not previously worked. This requires that each team player must be able to assess during the game what other team members can and cannot do and should be able to strategize action around that knowledge. Obviously, they also need to be able to adapt as circumstances change. The “master” strategy becomes a collective/emergent plan rather than a supervising intelligence.

    A second consideration is managing the time dimension. In the “traditional” AI examples above, intelligence is applied to analysis of a static (or mostly static) context. There can be a sequence of static contexts, as in board games, but each move is analyzed independently. Autonomous cars (as we hear about them today) may support a little more temporal reasoning but only enough perhaps to adjust corrective action in a limited time window. But soccer robots must deal with a constantly changing analog state space, they must recognize objects in real-time, they must deal with multiple cooperating and opposing players and a ball somewhere in the field, and must cooperatively reason about how to move a future objective – scoring a goal while defending their own goal.

    A third consideration is around how these agents learn. Again the “traditional” approach, based on massive and carefully labeled example databases, is impractical for soccer robots. The LARG group use guided self-learning through a method called reinforcement learning (RL). Here a robot makes decisions starting from some policy, takes actions and is rewarded (possibly through human feedback; this was cited as a way to accelerate learning) based on the result of the action. This is the reinforcement. Over time policies improve through closed-loop optimization. An important capability here is understanding sequences of actions, which can be formalized as Markov decision processes with probabilistic behaviors.

    One other component caught my attention. Team soccer is a complex activity; you can’t train it as a single task. In fact, even getting a robot to learn to walk stably is a complex task. So they break complex tasks down into simpler tasks in what they call layered learning. One example he gave was walking fast to the ball then doing something with the ball. Apparently you can train in one task to walk quickly but the robot falls over when it gets to the ball. They had to break the larger task down into 2-3 layers to manage it effectively.

    I should in fairness add that this is not all about teaching robots to play soccer. What the speaker and his team learn here they are applying to practical problems as varied as collaborative traffic control at intersections, building-wide intelligence and trading agents. But what a great way to stimulate that research 😉

    There is much more information you can find HERE and HERE. HERE is one of many games they have played and HERE is a fun blooper reel. And there are many more video examples!

    Posted on

    Cadence Expands Integrated Photonics Beachhead

    Cadence Expands Integrated Photonics Beachhead
    by Mitch Heins on 03-30-2017 at 4:00 pm
    Categories: Cadence, EDA, Silicon Photonics

    In November of 2016, I made a bold statement that October 20, 2016 would stand as a watershed day in integrated photonics. The reason for this claim was that GLOBALFOUNDRIES proclaimed that integrated photonics was real and here to stay. The same week I wrote an article about Cadence Design Systems securing a photonic beachhead when they, Lumerical Solutions and PhoeniX Software held their first joint training class for over 70 prospective customers on a new fabless integrated electronic-photonic design automation (EPDA) flow. It’s now five months later, and I am more convinced than ever of my statement about that October. Several things have happened in those short five months.

    First, I’ve had the chance to be in a lot of conversations with potential users of the triumvirate EPDA flow. Interest has been high from the fabless community, adding weight to GLOBALFOUNDRIES’ proclamation about integrated photonics. So far, feedback from users has been very consistent. They are looking for a production-worthy design flow that promises to bring a much-needed formalism to electronic-photonic circuit design. The integration of photonic and electronic simulations along with the formalism of a schematic-driven layout flow seems to have answered a need that has heretofore been missing in photonic design. The fact that users are looking for such formalism says much to me about their seriousness in making production electronic-photonic designs.

    Second, users quickly noted the improved productivity they can get in the layout phase of the design when using Cadence Virtuoso in combination with the PhoeniX Software tools. In many ways, this even surpasses the productivity boost users saw when adopting automation for analog IC layout as photonic curvilinear shape generation can be very time-consuming if not automated. The joint EPDA flow goes a long way towards improving the engineer’s life when it comes to doing photonic layouts.

    Third, is that Cadence, PhoeniX and Lumerical are now planning to expand the flow into the 2.5D, 3D and SiP (system in package) domain. This is a major and important step as most high-volume applications will want to take advantage of silicon-photonics manufacturing cost advantages. These solutions will require photonic light sources, amplification and detection and that means working with III-V materials like InP or InGaAs in combination with the silicon photonic-IC (PIC). Si-based PICs will also need to be tightly tied to both digital and analog electrical ICs. While there are many ways to put these solutions together, one of the most obvious and near-term is to put them together as a SiP using an interposer capable of both electronic and photonic die-to-die and die-to-package connections.

    This is a major undertaking for a fabless company as it requires a significant investment in design tools and very good relationships with ecosystem partners. Consider, however, that except for the photonics part, Cadence has had a flow for some time now to enable heterogeneous electronic SiP designs, and they have been working with several partners in this area. With the new EPDA flow, much of the work and associated risk for a heterogeneous electronic-photonic EPDA-SiP design flow has already been addressed. Simulation of electronic SiP designs is already handled in Cadence’s Virtuoso ADE environment and likewise, with the integration of Lumerical’s INTERCONNECT circuit simulator, so too is simulation of the EPDA-SiP design. All the necessary plumbing exists. Similarly, layout of an electrical-optical interposer with waveguides can also be done in Virtuoso using the combination of Virtuoso and PhoeniX Software’s OptoDesigner.

    As a quick review, here is the current Cadence portfolio for 2.5D, 3D and SiP design.

    • OrbitIO Interconnect Designer: Used for die-to-die and die-to-package connectivity planning.
    • Genus Synthesis Solution and Modus Test Solution:Used for generating design-for-test (DFT) logic of the electrical portions of the SiP.
    • Innovus Implementation System and Physical Verification System (PVS): Used for digital design implementation and verification. Innovus has a plugin that provides for through-silicon-vias (TSVs) and micro-bump placement while PVS can do DRC and LVSI checking across multiple dice in the package.
    • Virtuoso ADE and Spectre: Used for simulation of electronic and photonic systems in combination with Lumerical’s INTERCONNECT photonic circuit simulator.
    • Virtuoso: Used for layout of analog and photonic designs in combination with PhoeniX Software’s OptoDesigner layout tool. Virtuoso also supports TSVs and the mapping of memory die bumps to logic die.
    • Cadence SiP Layout:Enables 3D displays of both silicon and package layers for multi-die integration.
    • Quantus QRC Extraction Solution:Enables parasitic extraction of interposer metal traces as well as TSVs and micro-bumps.
    • Tempus Timing Signoff:Enables static timing analysis and signal integrity checks across multiple die and power domains.
    • Voltus IC Power Integrity Solution: Enables multi-die, 2.5D, 3D and SiP power analysis.
    • Sigrity PowerDC: Voltus can forward information to Sigrity which can then determine a temperature distribution map based on power consumption data. This power map can then be provided back to Voltus for temperature dependent IR drop analysis.

    So, what is still missing for the EPDA-SiP flow? Board-based photonics is well on its way to being part of the overall solution. And, it appears that it would make sense to enable designers to account for heating effects on temperature-sensitive PIC devices caused by hot electrical ICs in a SiP. One last big issue that needs to be tackled by not just Cadence but the entire industry is what design-for-test looks like in photonics and heterogenous electronic-photonic SiPs.

    Nonetheless, I repeat my opinion that October 20, 2016 was indeed a watershed event for integrated photonics as it saw the launching of a very comprehensive fabless EPDA flow that will likely be host to many heterogeneous electronic-photonic designs to come. And, from what we are seeing now, it appears that the flow will become even more comprehensive, allowing Cadence to expand their integrated photonic beachhead.

    See also:

    Posted on

    Analyzing All of those IC Parasitic Extraction Results

    Analyzing All of those IC Parasitic Extraction Results
    by Daniel Payne on 03-30-2017 at 12:00 pm
    Categories: EDA, Events

    Back at DAC in 2011 I first started to hear about this EDA company named edXact that specialized in reducing and analyzing IC parasitic extraction results. So Silvaco acquired edXact and I wanted to get an update on what is new with their EDA tools that help help you to analyze and manage the massive amount of extracted RLC and even K values that all impact IC design performance, timing and power. I attended their webinar last week where Jean-Pierre Goujon presented.

    Just take a quick look at the 3D interconnect in the diagram below, and how with each smaller technology node we are seeing interconnect delays rise and the worst-case interconnect delay due to crosstalk dramatically rising:

    Related blog – RLCK reduction tool at DAC

    The basic idea is that if you can find the sources of these delays then you can do something about it through either cell placement, block placement, routing or transistor sizing. The interconnect in an IC using 60nm technology and smaller are causing more delay than the gates from your cell library. By analyzing your extraction results prior to SPICE simulation you will actually reduce the number of SPICE runs required.

    Let’s take a look at the IC design flow for analyzing two slightly different extracted netlists:

    The Viso tool shown in the lower right corner provides design analysis and exploration of parasitics through the following features:

    • Viewing resistance and capacitance values, RC time delays
    • Analysis in numerical, tabular views
    • Graphical views in both 2D and 3D
    • Detection of cut nets, dangling nets, sanity checks on DSPF/SPEF/CalibreView

    Related blog – CEO Interview: David Dutton of Silvaco

    In the middle of the flow is the Belledonne tool, useful for:

    • Comparing different extracted netlists (DSPF, SPEF, CalibreView)
    • Comparing statistics of: resistance, capacitance, static delays
    • Batch or interactive analysis
    • PDK optimization and validation

    At the top middle is Brenner, an EDA tool that matches pin and net names, so for example if one netlist had an MOS transistor with four fingers named ABCD it could be matched with another netlist where the same four fingers were in a different order, but still equivalent.

    Related blog – It’s Time to Put Your SPICE Netlists on a Diet

    Live Demo
    I’m a big believer in showing EDA tools live instead of using canned screen shots, because it actually provides a feeling for how responsive and speedy tools can be. Jean-Pierre started from the Unix command prompt and invoked the GUI called alps, then showed how he uses Belledonne to compare two DSPF files with different pin names. The actual comparison run time for 1 million Resistors was completed in just seconds. Here’s a graphical view comparing resistance values where the color Red depicts over a 5% difference:

    For the second demo circuit we looked at the global statistics from the netlist and then quickly sorted them by maximum RC values shown in a tabular format:

    You can click on a particular net and then visualize it in either 2D or 3D views to better understand the physical topology:

    To understand the context of this extracted interconnect you can overlay the results on top of the GDSII layout:

    In the third demo we looked at resistance analytics to understand where the maximum pin to pin resistance values were located. Once a high resistance path was found, the layer contribution to resistance was displayed to further pinpoint the greatest contributor. For this selected net it was the poly1 layer contributing to 92% of the total resistance.

    2D and 3D results showed resistance values by color to get a quick graphical understanding of where to start looking. We saw pin to pin RC delay values, net to net capacitance tables, and could understand what capacitance with grounded versus coupled.

    In the fourth and final demo I got to see how sanity checks could be run to identify opens in the IC layout interconnect caused by missing vias.

    Summary
    This was very practical webinar where we got to see live EDA tools running that will help IC designers and PDK developers better understand the effects of parasitic RCL values on their particular designs. In the past you may have been tempted to just run extraction and then immediately start running SPICE simulations, however the recommended flow is to perform analysis of the extracted netlists prior to starting SPICE simulation in order to understand and quantify the portions of your design with the most resistance and capacitance values. Circuit designs can now quickly understand where coupling capacitance is impacting their layouts, then decide if they need to make topology changes are go back and start resizing transistors.

    The archived webinar is online now here.

    Posted on

    SNUG 2017 Keynote: Aart de Geus on EDA Fusion!

    SNUG 2017 Keynote: Aart de Geus on EDA Fusion!
    by Daniel Nenni on 03-30-2017 at 7:00 am
    Categories: EDA, Events, Synopsys

    I spoke with Aart before his SNUG keynote and found him to be very relaxed and upbeat about EDA and our future prospects which reminded me of my first ever (cringe-worthy) blog, “EDA is Dead”. Now, eight years later, we have what Aart calls “EDA Fusion” to thank for the reemergence of EDA as a semiconductor superpower, absolutely.

    If you look at EDA’s recent revenue numbers you will see why Aart is smiling. Synopsys stock (SNPS) started 2016 in the $45 range and is now trading above $70. In fact, if you look at EDA as a whole we had a very good year. At the end of this blog is a report “Large divergence in EDA suppliers’ latest quarterly revenues“compliments of SemiWiki member Gerry Byrne. Gerry is the founder of edalics which provides EDA budget management services to semiconductor companies. But first, back to Aart’s keynote.

    The first example of EDA Fusion was the integration of IP into EDA. Currently Synopsys has the industry’s largest IP portfolio that generated more than $500M in revenue last year. More importantly, the Synopsy IP is designed with Synopsys tools resulting in deep design experience other EDA companies can only dream of. This direct design experience is critical as we move into FinFETs and increasingly complex process technologies with compressed design cycles.

    A more recent example of EDA Fusion is the integration of software quality and security into EDA with the Synopsys acquisition of Coverity. This has allowed Synopsys to swim upstream at the systems companies (Automotive, Mobile, IoT, etc…) thus increasing their total available market.

    I really admire Aart’s ability to come up with engaging keynotes for us every year. You can see his last 5 SNUG keynote videos HERE and I strongly suggest you do. Hopefully this year’s keynote will be up soon because it is something you really have to see to fully appreciate. And now for the 2016 EDA revenue report from edalics:

    Large divergence in EDA suppliers’ latest quarterly revenues

    During Q4 2016 global semiconductor revenue growth accelerated to 12.3% vs. Q4 2015 (SIA). With this positive semiconductor industry background, Synopsys returned to strong 14.8% Q4* growth vs Q4* 2015, only to be significantly eclipsed by Mentor’s 41.7% growth rate, while Cadence reported steady 6.3% growth:

    For comparison, the % growth rates in the previous quarter, Q3* 2016 versus Q3* 2015: Synopsys 7.9%, Cadence 2.9%, Mentor 11% and semiconductor revenues 3.6%.

    Examining the delta in revenue growth in dollars, Synopsys and Cadence’s Q4* 2016 vs Q4* 2015 revenues increased by $84.2M and $27.9M respectively, while Mentor’s revenues increased impressively by $140.7M. Synopsys and Cadence surpassed their own mid-point revenue guidance for the quarter by $14.3M and $1.0M respectively:

    Mentor stands out when comparing the latest quarterly results. To get a deeper understanding why, it is worthwhile comparing the results for the latest 12 month period (comparing the last 12 months of each company’s results most closely matching the calendar year 2016). During 2016 global semiconductor revenue was a record $338.9 billion, 1.1% higher than in 2015. The top 3 EDA suppliers all comfortably beat this semiconductor revenue growth rate. Synopsys grew fastest, by 10.5%, extending its EDA market share leadership. Cadence grew revenues by 6.7%, while Mentor achieved an 8.6% growth rate for the last 12 months (which includes 41.7% for Q4 2016):

    Mentor’s quarterly revenues fluctuate most of the big 3 and this was more accentuated than usual in 2016, a year of two contrasting halves, with a decrease in revenues in Q1 (-16.4%) and Q2 (-9.5%), followed by strong growth in Q3 (+11%) and Q4 (+41%), to achieve the 8.6% average growth rate for the whole year 2016, encompassing an increased portion of 2016 revenues booked in the second half of 2016 versus 2015.

    * Based on each company’s reported financial quarterly data which most closely match that calendar quarter.

    Posted on

    Intel Manufacturing Day: Nodes must die, but Moore’s Law lives!

    Intel Manufacturing Day: Nodes must die, but Moore’s Law lives!
    by Scotten Jones on 03-29-2017 at 4:00 pm
    Categories: FD-SOI, FinFET, Foundries, GlobalFoundries, Intel Foundry, Samsung Foundry, TSMC

    Yesterday I attended Intel’s manufacturing day. This was the first manufacturing day Intel has held in three years and according to Intel their most in depth ever.

    Nodes must die
    I have written several articles comparing process technologies across the leading-edge logic producers – GLOBALFOUNDRIES, Intel, Samsung and TSMC. Comparing logic technologies to each other requires a metric for process density.

    Continue reading “Intel Manufacturing Day: Nodes must die, but Moore’s Law lives!”

    Posted on

    When is "off" not really off?

    When is "off" not really off?
    by Tom Simon on 03-29-2017 at 12:00 pm
    Categories: Dolphin Design, Events, IP, Mobile

    With the old fashioned on-off power switch came certainty of power consumption levels. This was fine back in the days before processor controlled appliances and devices. On was on and off was off: full current or no current. With the first personal computers you always had to wait for the boot process to complete before you could use it. This frequently was not quick, but tolerable when you were sitting at your desk and using the computer for a long stretch. And, of course it was fine to have it running all day from a power consumption perspective because the computer was plugged into wall power.

    Some PC’s and most laptops had a sleep mode that eliminated the need to wait for a lengthy boot process before you could resume work. However, these were often buggy and problematic – restoring RAM contents from a hard drive for instance was time consuming. It might have been with the Palm Pilot, or perhaps the Apple Newton, that I first realized these devices were designed to usually be in sleep mode, not powered down, and ready to wake up and use at the press of a button. The first commercially prevalent device that featured this was the iPod – just push the button and it’s awake. Today this behavior is expected in everything from iPad’s to e-book readers, cameras, laptops, etc.

    The early sleep modes for phones and similar devices were pretty simple compared to today’s requirements. Their main goal was to save state to reduce power until an external interrupt, such as a button press. People had low expectations about how long the battery would last in sleep mode. PDA’s and iPods would lose all power in sleep mode after a few days.

    Phones of course need to wake on incoming calls, so the RF stages need to stay awake in sleep mode. Computers and phones also need to monitor network connections such as Ethernet or WiFi. Sleep has become more sophisticated. Devices often have different levels of sleep, with each having additional circuitry always-on, depending on the needed service level. The latest addition to the panoply of sleep-wake modes is sound, or even more specifically voice, activation.

    Nevertheless, adding more functionality to sleep modes, aka “battery drain”, has risked decreasing battery life. However, consumer demands create the need for longer standby battery life. Techniques used to reduce power during wake mode include clock gating, power gating, voltage domains, block level power management, multi-threshold libraries, etc. Sleep mode power reduction presents its own challenges. This is especially true when complex functions such as voice recognition are enabled. Google, Apple and Amazon all offer devices that sleep with voice activated wake ability.

    At the TSMC Technology Symposium in mid-March I had a chance to talk to Frederic Renoux with Dolphin Integration about their comprehensive offerings in the area of low power IP for managing sophisticated sleep modes. One of the topics he emphasized was the importance of selecting the best standard cell library for the always on (AON) portion of the chip. Dolphin has studied this topic extensively. Because they have much of the IP that would be used and have built demo chips, they have good technical basis for their observations.

    The best choice for AON standard cell libraries depends on how much functionality is kept on. For instance, is it just a RTC and simple control logic, or is it more complex logic, like that needed for voice recognition? For minimal logic, it makes sense to use a library based on thick gate transistors. This offers lower leakage and in some cases can avoid the need for an external voltage regulator. The Dolphin Integration SESAME BIV library can operate up to 3.6V and is ideal for minimal logic AON designs.

    For more complex AON regimes, especially where SRAM needs to be retained, the best way to save power is to use the lowest possible voltage – near threshold. For this Dolphin Integration offers their SESAME-NVT library. They also offer a high density standard cell library that is optimized for performance that uses HVT cells running at nominal voltage.

    Dolphin Integration has an excellent write up on their website that details their experience using each of these libraries in various AON configurations. In the paper they show the block diagrams for each scenario and cover the specifics referencing the IP blocks used. It is clear to see why they are part of the TSMC partner ecosystem. They are in line with TSMC’s concept that the way to make significant improvements in performance is to focus on more than just one element, i.e not just std cells. Instead a system level approach is needed, which in the case of Dolphin includes IP, std cells, implementation know-how, etc.

    Posted on

    A Formal Feast

    A Formal Feast
    by Bernard Murphy on 03-29-2017 at 7:00 am
    Categories: EDA, Synopsys

    It’s not easy having to deliver one of the last tutorials on the last day of a conference. Synopsys drew that short straw for their tutorial on formal methodologies at DVCon this year. Despite that they delivered an impressive performance, keeping the attention of 60 attendees who said afterwards it was excellent on technical content, substance and balance for a wide audience. This was their second content-rich, marketing-light tutorial in this conference (following low-power verification). Worth remembering for next year.


    Sean Safarpour of Synopsys (another Atrenta alum) kicked off with a quick and pragmatic review of “Why Formal?”. These have become almost pro-forma now that more of us are getting formal (usage at over 30% in ASIC and an amazing 20% in FPGA last year). Sean got through these slides quickly – contribution to shift, left, different tools for different problems, complementary formal and simulation analysis, the pros and cons for formal and the greatly simplified on-ramp to formal use.

    The second part of the tutorial, also presented by Sean, dug deeper into this formal for everyman/everywoman, enabled through pre-packaged applications. This isn’t a new topic, but it’s worth stressing how accessible and valuable these can be for covering important sections of a testplan and for exploring deep properties. You can quantify coverage contributions from formal analysis and can demonstrate that areas you can’t cover in simulation may be unreachable, so can be dropped from coverage analysis. Serious value and easily accessible – there’s no good reason not to use capabilities like these. General adoption in this area hadn’t yet reached property-checking levels last year but it is growing much faster.


    A favorite of mine checks register properties; this is a no-brainer for formal analysis and for formal apps. IPs and designs host vast numbers of registers to configure, control and observe behavior, typically accessed through standard interfaces like AXI. But these aren’t just vanilla read/write registers. They can have a wide range of special properties, across the register or bitfield by bitfield. A bitfield may be readable or writeable or both, perhaps it may be read/written only once, read or write operations may set/clear the field, the register may mirror another register, and so on. Checking all these possibilities in simulation can be painful, at minimum to setup the testbench, and is often incomplete. Formal apps for register checking are easy to setup (needing just spreadsheet descriptions of expected bitfield properties) and you can be confident they are complete. Again, why wouldn’t you do this?

    Getting a bit more complex, Vigyan Singhal of Oski, a formal guru with always interesting ideas, presented on end-to-end formal verification. Here his objective was to fully verify an IP using only formal methods (an idea I’m hearing a lot more). Vigyan made a case that serious progress can be made in this direction, if we are willing to work harder. He cited blocks like MACs, USB, DMA and memory controllers, bridges, and GPIO blocks as candidates for this kind of proving.

    Of course, today this isn’t as simple as an app. Abstraction becomes important, as do symbolic approaches to verification which can, though clever techniques, fully verify key aspects of the functionality of say a data transport block by checking just a limited set of possibilities. Very interesting concepts – maybe not something most of us would try unassisted, but this points to what we might expect to see eventually in packaged solutions. Will it completely replace simulation on these blocks? I would guess not, but it does seem possible that formal will eventually do more of the heavy lifting.

    Mandar Munishwar from Qualcomm followed with a neat sequel. Maybe you did what Vigyan suggested but you’re still not convinced from a signoff perspective. How can you more thoroughly check coverage to make sure you didn’t miss hidden problems?

    He started with a very interesting concept – the proof-core. When we think about proving an assertion we think about checking within the cone of influence (COI) leading up to the assertion. But a proof for an assertion doesn’t necessarily have to look at the whole cone of influence; the prover only extends out though just the piece of logic (the formal core) required to prove the assertion – which may be a lot smaller than the COI. This means that any potential bugs beyond the formal core may be missed. He suggested logic mutation to expose such problems; change the logic slightly then re-run the proof, and repeat with more mutations. Based on his experiments, he found at least one more problem on the DMA controller he used as his test DUT. What Mandar wants to get to is higher levels of formal coverage by pushing analysis, through mutation, beyond an initially limited set of formal cores.


    Pratik Mahajan from Synopsys wrapped up with a few future-looking areas. The first was around a goal that many formal users will welcome. As we know, formal depends on multiple engines – BDD, SAT, ATPG and more. Each has special strengths and weaknesses, each has a host of parameters, you need to know when you should selectively push deeper beyond nominal proof depths, and you need to know when you should switch from one approach to another. Knowing how to make these choices is a big part of why the full scope of formal property-checking has been viewed as a PhD-only topic; you must know how to orchestrate all these possibilities.

    Pratik described an approach to putting all that orchestration in a box, along with managing distribution of jobs out to server farms (since many tasks can run in parallel). He didn’t get into too much detail but it sounds like this is an adaptive approach, starting from some well-known recipes, with ability to fine-tune as results start to come back. From an end-user perspective, this could make more complex and more complete proofs much more accessible to non-experts.

    Pratik also covered dealing with inconclusive proofs; another sore spot for formal users. Anything he can do to help here will be greatly appreciated. And he discussed work being done on machine learning in formal and assistance in bug hunting which I covered in an earlier blog on FMCAD.

    I must apologize to the presenters for my highly-abbreviated treatment of what they presented. I hope at least I conveyed a sense of the rich set of formal options they presented, both for today and to for the future. You can learn a lot more from Tutorial9 from the DVCon download.

    More articles by Bernard…