NVM Survey 25 Wide Banner for SemiWiki 800x100 px (1)

SNUG and Robots

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

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!


Cadence Expands Integrated Photonics Beachhead

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

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:


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

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.


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

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 revenuescompliments 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.


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

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!”


When is "off" not really off?

When is "off" not really off?
by Tom Simon on 03-29-2017 at 12:00 pm

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.


A Formal Feast

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

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…


Seven Reasons to Use FPGA Prototyping for ASIC Designs

Seven Reasons to Use FPGA Prototyping for ASIC Designs
by Daniel Payne on 03-28-2017 at 12:00 pm

Using an FPGA to prototype your next hardware design is a familiar concept, extending all the way back to the time that the first FPGAs were being produced by Xilinx and Altera. There are multiple competitors in the marketplace for FPGA prototyping, so I wanted to discern more about what the German-based company PRO DESIGN had to offer in their proFPGAsystems by attending a joint webinar that they hosted last week with the ASIC services company Open-Silicon. SemiWiki blogger Bernard Murphy was the moderator and he was able to get things started by concisely listing seven reasons to use FPGA prototyping for ASIC designs:

[LIST=1]

  • Developing and debugging bare-metal software, accelerating the time to build a system
  • Hardware and software performance testing
  • Compliance texting with big use-case and regressions
  • In-system validation
  • Functional simulation is too slow, and emulation is too expensive
  • Waiting for first silicon to start system testing is way too late
  • You need a quick proof of concept

    There are four options for you to consider when choosing an FPGA prototyping approach:


    The best practices include not starting FPGA prototyping while the RTL is still in flux, don’t expect a prototype to be used for hardware debug, and finally the challenges to partitioning can be taxing. If you opt for a turnkey prototyping solution then you don’t have to spend time becoming an FPGA expert.

    Philipp Ampletzer from PRO DESIGN talked about six attributes of an ideal FPGA prototyping system:

    • Flexibility, adaptability (both Xilinx and Altera)
    • Performance and signal integrity
    • Scalability and capacity (latest FPGA devices)
    • Host interfaces
    • User-friendly
    • Price friendly, cost-performance ratio

    It turns out that PRO DESIGN has a series of FPGA Prototyping products that use both Xilinx and Altera FGPAs, and you can start with a small configuration using a single FPGA, or scale up to a system with four FPGAs, or ultimately combing five boards for a total of 20 FPGAs. Here’s a photo of the FPGA Module SG280 which provides:

    • Single Intel Stratix 10 FPGA providing up to 20M ASIC gates
    • Up to 1,026 user I/O
    • Up to 8 voltage regions
    • Up to 1.0 Gbps single-ended point to point speed


    The final presenter was Sachin Jadhav from Open-Silicon and he walked us through the typical ASIC design life cycle with 11 distinct steps showing where FPGA prototyping fits in:

    Based on actual experience with FPGA prototyping at Open-Silicon, they look at five challenges:

    • Selecting an FPGA Platform (capacity, I/Os, expected frequency, partitioning, turnkey or custom)
    • Design Partitioning (automatic, manual)
    • Optimum operating design frequency (choosing speed grade FPGAs, design IP placement, global clock, clock loading)
    • Custom PHY’s
    • Debugging (integrated RTL debugging)

    Related blog – Open-Silicon Update: 125M ASICs shipped!

    One case study was shared by Open-Silicon where they designed an ASIC for use in a professional camera system and partitioned their design across two Virtex 7 FPGAs with the following IP blocks:


    This ASIC used 40 million gates and the FPGA prototype used manual partitioning with IOs in one FPGA and logic in the second FPGA, while communication between the two was with a SerDes. By using an FPGA prototype the design team saved some 5 months from the schedule and reached a first silicon success. Other achievements on this project included:

    • Production quality software developed on FPGA prototype
    • Custom PHY’s (HDMI, LVDS-TX, HSIFB, UHS-II) using FPGA resources
    • Validated custom IP blocks with external devices prior to tape-out

    Related blog – ARM and Open-Silicon Join Forces to Fight the IoT Edge Wars!

    Summary
    ASIC design teams are under immense pressure to meet product requirements and develop software before silicon is fabricated, so using an FPGA prototyping approach can help you do that by enabling early software driver development and even producing a proof of concept to investors. Maybe it’s the right time for your next ASIC project to start using an FPGA prototyping methodology.

    To watch the archived webinar you can go here.


  • eFabless Design Challenge Results!

    eFabless Design Challenge Results!
    by Daniel Nenni on 03-28-2017 at 7:00 am

    Will community engineering work for semiconductors? Will anyone show up? Well, the efabless design challenge is complete and the results are both interesting and encouraging, absolutely!

    Efabless completed its low power voltage reference IP design challenge on Monday, March 13. This was a very interesting event that we followed closely here at SemiWiki. It’s community-style development and challenge methodology was a first of its kind for the semiconductor IP industry.

    Designers from all over the world were invited to compete for cash prizes, recognition and the ability to earn revenues by licensing through efabless’ clever community-style marketplace. Our good friends at X-FAB sponsored the challenge to test out what they see as an innovative on-demand design enablement solution for their customers. I was intrigued and added to the cash prizes for winners that are SemiWiki members.

    So what happened? According to the results posted on the efabless website, 88 designers from 26 countries signed up for the challenge. They were broadly distributed geographically. Six designs passed customer requirements and ultimately the top three completed layout and were awarded cash prizes based on their relative standing in power consumption. First place went to Rishi Raghav (SemiWiki member). Second place went to Arsalan Jawed and third place went to Ibrahim Muhammed.

    According to Mohamed Kassem, CTO and co-founder of eFabless, there were a number of interesting takeaways. First all, these were serious professionals. Two of the competitors represented small and, as shown by their designs in the challenge, very capable design firms. One, the eventual winner, Rishi, is an independent. Second, Mohamed was extremely impressed with the creativity and diversity of the designs and their architectures. All three winners took different approaches and delivered clean and interesting designs. The design of Arsalan employed a CMOS-only architecture, an unusual approach for a bandgap. There were also a number of designs that were not quite completed on time or were submitted outside the customer spec but with attributes that are intriguing. Mohamed said that we should expect to see one or more of these enter the marketplace in the coming weeks. I understand that winning designs will be processed on an MPW for silicon characterization and efabless will provide evaluation boards that community members can offer to their customers. This would be a real plus.

    I have taken a look at the newly released “gen 2” marketplace for efabless. It is a very interesting enabler for what Mike Wishart, CEO, sees as a new market for “on-demand” IP delivered by efabless community. The marketplace looks great, is easy to search and navigate, and provides very interesting information on both the IP and also the designer. The designer section has various designer supplied information as well as quantifiable certification based on designer’s success on the platform. I can see why independent designers and small firms would be very attracted to this. In Mike’s view of the world, a customer can come to the marketplace, find an IP design that closely matches his or her needs and simulate it at no cost in their design. If they like what they see but need some customization, they can check out the designer’s qualifications and history, and then engage the designer for final work.

    efabless says we should stay tuned for future design challenges and additional design capability for the efabless community. I am impressed with the community turnout on the project and excitement for the platform. Apparently, community is at over 1000 members, up from 600 or so in November. Next step will be to see the depth of customer demand.

    About efabless
    efabless is the first online marketplace for community-developed, customized integrated circuits (ICs) that lets hardware system innovators turn product visions into market reality. The company applies the concepts of crowdsourcing and open community innovation to key aspects of IC development and commercialization. Specializing in the design of analog/mixed signal ICs, power management ICs MEMS and agile ASICs, the company gives designers all the means needed to define, develop and monetize their work. It has built up a community of over 700 members from 30 countries around the world. For information visit: www.efabless.com


    Who knew designing PLL’s was so complicated?

    Who knew designing PLL’s was so complicated?
    by Tom Simon on 03-27-2017 at 12:00 pm

    Well it comes as no surprise to those that use and design them, that PLL’s are a world unto themselves and very complicated indeed. With PLL’s we are talking about analog designs that rely on ring oscillators or LC tanks. They are needed on legacy nodes, like the ones that IoT chips are based on, and they are crucial for high speed advanced node designs like those at 16nm and below. They are especially important on nodes that are typically considered ‘digital’, yet all the challenges of analog design must be addressed on these processes. Indeed, advanced SOC’s often have numerous PLL’s servicing internal clocking needs and those of external IO.

    PLL design involves making many trade offs: for instance, is the precision of an LC tank, with a high Q inductor, worth the area required, or can a much smaller ring oscillator deliver the needed performance? Jitter is the key parameter that needs to be controlled in PLL designs. Across the nodes from 180nm to 10nm there is a need for PLL’s that operate at anywhere from below 100 MHz up to the multi GHz range with low jitter. Applications such as SerDes rely on low jitter in PLL’s.

    Last week at the 2017 Silicon Valley TSMC Technology Symposium I had a chance to talk to Andrew Cole and Randy Caplan with Silicon Creations. Their bread and butter is designing analog IP that is used widely across a broad range of process nodes. PLL’s are a part of their expertise. With TSMC rolling steadily on toward 7nm – even 5nm was mentioned during the symposium – IP providers such as Silicon Creations need to deliver high performance analog designs on these FinFET nodes. Andrew talked about one of their most popular PLL designs that is in over 100 unique designs and has been taped out at every imaginable node from 180nm to 16nm. Apparently, the run rate for this one PLL on one 28nm process is around one billion instances per year.

    They pointed me to a document on their website that details the specific challenges they faced as this design was moved and verified at successively smaller nodes. From 65nm to 10nm there has been nearly a 3.5X relative increase in the peak transition frequency (fT) of the transistors. At 10nm the fT will be in excess of 500GHz. The material on their website goes into some detail about the tradeoffs between 28nm polygate and 28nm high-K metal gate. Nonetheless, 10nm FinFET continues the progression of fT to higher frequencies.

    The real question is, how do analog designs scale as lambda decreases? To help answer this Silicon Creations offer up data comparing their relative PLL area from 180nm to 10nm. Refer to the diagram below to see how this has progressed.

    While it is not as dramatic as digital area scaling, it is enough to help lower costs. Each smaller node has presented its own challenges to analog designers, much as they have to digital designers. Silicon Creations has dealt with this by developing their own back end design flows. Even though an analog design schematic may look much the same, at FinFET nodes they are now dealing with increasing interconnect resistance, which requires anticipating parasitics earlier in the flow. Also, the quantized nature of W in tri-gate devices leads to changes in transistor parameter specifications.

    Silicon Creations covers the gamut when it comes to process node coverage. They are concurrently designing at all the nodes mentioned above – 180nm to 10nm, and have work under way for 7nm. There is more detailed information available, including the material they directed me towards, on their website. It is interesting to see how, on what most people consider to be digital nodes, they sustain delivery of essential building block analog IP for a wide range of designs.