llmda newsletter ad (2)
Semiconductor Expert Forum

Posted on

Pushing on AXI-connected IP in FPGAs

Pushing on AXI-connected IP in FPGAs
by Don Dingee on 11-03-2015 at 12:00 pm
Categories: EDA, FPGA, S2C EDA

Success stories are great. Reading how someone uses a product contributes much more insight than reading about a product. Last month we had a teaser for a presentation by Wave Semiconductor; this month, we have the slides showing how they are using FPGA-based prototyping, AXI transactions, and DPI to speed up development.

First, a mea culpa. I got the press release last month and the term DPI dangled ambiguously. My frame of reference is “deep packet inspection”, and when I inquired via email if that was the intent, the answer was yes. It seemed like a plausible response.

Wave is developing a programmable data flow computing accelerator with IP forming massively parallel reconfigurable processor arrays and a fabric interconnect. In their own words, they are “moving algorithms to the data”, a key tenet of big data analytics. From the press release just issued (link below), we see they have rebranded their architecture as Byte-Fabric. An older diagram on their website portrays the concept; this may not be the most recent version:


So, I get the slides from Wave this month, and sure enough DPI is all over them as promised. What they are really talking about is the SystemVerilog Direct Programming Interface, allowing C calls from SystemVerilog. Blogger fail. Now that we have the story straight, let’s connect the dots on this success and what it means for ASIC developers.

Wave is pushing on AXI as the strategy for IP interconnect in FPGAs for several reasons, primarily to aid in integration. Xilinx is heavily promoting the use of AXI-connected IP in FPGAs, which is a great thing to reduce partitioning differences between FPGA-based prototypes and the final ASIC. An abstracted AXI backbone helps with DMA, quality of service, out-of-order transactions, and other system-level performance characteristics.

The key to this particular success story is less obvious. By using the AXI interconnect, the FPGA-based prototyping platform from S2C can dynamically load, unload, and debug software through AXI on the FPGAs using a host PC. By applying a C language API, the same code from the verification environment can be reused in production.


Put another way, production C code can be used to verify the FPGA-based prototype. Usually testbenches are developed in SystemVerilog or maybe SystemC. In this project, Wave has used S2C’s Prodigy ProtoBridge with a driver that connects to a Xilinx PCIe IP block in the Prodigy Logic Module. This gives the PC user-level access to the AXI master, simplifying read/write to the entire FPGA using C/C++ calls. Then, a DPI-based AXI Master Transactor spans between the SystemVerilog testbench and C code.

In Wave’s environment, algorithms for big data analytics are developed in C, so running actual C code is essential to thorough verification testing. By preserving the ability to run the SystemVerilog testbench and use more conventional simulation tools, yet run production C code, Wave has combined the best of both worlds on an S2C platform.

If that type of hybrid scheme combining host-based simulation with an FPGA-based prototyping platform sounds vaguely familiar, it may be because it is. This idea bears a lot of resemblance to SCE-MI – a working group within Accellera that Toshio Nakama of S2C once chaired. The difference in this approach is the AXI connection and the heavy use of AXI-based IP in an FPGA, with a simpler API scheme that does the basics.

I’ll be curious to see what the final Wave Byte-Fabric product looks like. You can read more about what Wave has done with the S2C platform, AXI, and DPI in their development:

Wave Semiconductor Achieves Rapid Design Success Using S2C FPGA Prototyping Solutions

Case Study: AXI HW/SW Verification for FPGA (registration and PDF download)

When Wave says this approach simplified their debug environment and reduced development time, keep in mind the end product – the Byte-Fabric SoC and supporting software – is designed around AXI for performance. Tapping directly into AXI removes several interim steps in verification, particularly in creating a testbench reusing production C code on an FPGA-based prototyping platform.

More articles from Don…

Posted on

Perfecting the Great Verification Fugue

Perfecting the Great Verification Fugue
by Bernard Murphy on 11-03-2015 at 7:00 am
Categories: EDA, Synopsys

Michael Sanie (Senior Director Marketing in the Synopsys Verification Group) gave the wrap-up presentation at SpyGlass World recently, on the Synopsys Verification Direction. I learned from an interview Michael gave to Paul McLellan that he is an accomplished pianist. I’m a pianist also, though of considerably less talent, so I had to build this blog around a musical theme.

The fugue is a form, perfected in the Baroque period, in which one or more melodies chase (the meaning of fugue) through multiple voices or levels of a piece. This reminds me of the way we think of functional verification today. We have multiple different ways to verify, like multiple voices: simulation, static and formal verification, emulation, virtual prototyping and FPGA prototyping. Each of these has its own advantages but you couldn’t think of completing verification without using all of them. And as in a fugue, verification involves a complex interplay of themes between these voices. Emulation may carry a theme for a while, until some unexpected behavior creates a need to drop into simulation, which may in turn require a need to drop a sub-theme into formal verification until a problem is resolved, from which the theme then returns to the emulation voice.

Now imagine if each time a transition was reached the performers had to stop to re-read the score, reset instruments and do a couple of dry-runs to make sure they had the next part polished. The audience wouldn’t stick around for long. But that’s the way the verification fugue has worked in the past. Synopsys coined the term Verification Continuum™ for rendering a seamless verification fugue. This requires native integrations of compile, debug and more across the platform of solutions in the continuum. If every tool reads the score in the same way, there is no need to re-read on every transition. If every tool interfaces to debug in the same way, there is no need to reset debug style or cross-compare between incompatible interfaces.

Fully accomplishing this is not easy, in part because individual components have their origins in different tools with different objectives but also because an optimum architecture for one component isn’t necessarily optimum for another. The Synopsys approach is a more difficult but also more enduring engineering solution than any number of quick fixes. Each individual theme (a component) is refined, while seamless transitions between the themes (the Continuum) are optimized. Synopsys started with this approach several years ago, even before its acquisitions of Springsoft and Eve. We’re already seeing the results of those optimizations.

Perfecting the Verification Continuum is an ongoing exercise. The SpyGlass™ integration roadmap is still being developed. But the direction is clear: to make delivering a majestic verification fugue as seamless and as compelling as possible. You can learn more about Synopsys verification solutions HERE. This shows a pretty easy-to-understand picture of the Verification Continuum. And if you’re confused (as I was) about the difference between Verification Continuum and Verification Compiler, Verification Continuum is a platform of verification solutions whereas Verification Compiler is a product which includes simulation, VIP, static and formal verification and more, but not emulation or prototyping. To learn more about Verification Compiler, click HERE.

By the way, if you’re not a fan of classical music and all this fugue talk means nothing to you, fear not. A greatly simplified version is the round (Row, row, row your boat, Frère Jaques or Three blind mice, sung by multiple voices, each starting at a different time). Counterpoint – using multiple voices with different but harmonically related melodies – underlies the fugue and is quite common in rock, folk and related music. Some examples: Scarborough Fair (Simon and Garfunkel), Hello Goodbye (Beatles), and I Get Around (Beach Boys). Replace “fugue” with any one of these and you should get the idea – melodies chasing around between different voices.

More articles by Bernard…

Posted on

Implications of LTE in the 5 GHz Band

Implications of LTE in the 5 GHz Band
by Maury Wood on 11-02-2015 at 4:00 pm
Categories: Mobile

Back in December 2013, during a 3GPP Radio Access Network (RAN) plenary meeting, Ericsson and Qualcomm introduced LTE-Unlicensed, a scheme that puts LTE-Advanced signals in the 5 GHz unlicensed UNII band, in conjunction with an LTE “anchor” signal in a licensed band. The objective is supplemental downlink bandwidth (eventually both supplemental downlink and uplink bandwidth), to help meet ever-expanding mobile broadband data demands.

This proposal, and the follow-on License-Assisted Access (LAA) proposal targeted for 3GPP Release 13, has generated a great deal of discussion regarding coexistence and airtime fairness among 5 GHz LTE and 802.11n/ac signals. The FCC, as steward of both license and licensed spectrum in the United States, has been the locus of stakeholder comments, both affirmative and less sanguine. The stakes in this game are enormously high, especially for Wi-Fi services incumbents.

Wireless services providers have spent many tens of billions of dollars globally acquiring geographically exclusive spectrum licenses. With up to 500 MHz of unlicensed spectrum available between 5.17 and 5.85 GHz, the economic incentive to cellular operators for LTE-U and LAA is obvious. Qualcomm and other proponents have put forward technical methods of clear channel assessment to assure coexistence and airtime fairness based on carrier sensing and energy detection. Most countries in the world require a “Listen-Before-Talk” protocol to avoid co-channel interference, not only between LTE signals and Wi-Fi signals, but also among multiple LAA service operators.

To me, there are some interesting and perhaps more subtle open questions:

  • Supplier market dynamics. It seems clear that LAA drives a tighter functional integration between the LTE transceiver and the Wi-Fi transceiver. The medium-term impact to Wi-Fi only semiconductor radio suppliers is potentially significant.
  • Need for additional RF content in smartphones and small cell base stations. LAA is likely to be a boost for small cell base station suppliers, since maximum transmit power levels in unlicensed bands is much lower than licensed bands that can utilize macro cell base stations. Both LAA enabled small cells and smartphones will likely need additional 5 GHz TDD RF front-end content to meet new consumer connectivity use cases. LAA complicates the already staggering complexity introduced by 3GPP Release 10 LTE carrier aggregation, which allows up to five 20 MHz interband component carriers. Release 13 is anticipated to support up to thirty-two 20 MHz interband component carriers across licensed FDD and TDD bands, as well as the 5 GHz unlicensed TDD band. The RF front-end content required to support these new carrier aggregation combinations will no doubt have to grow substantially.
  • Potential impact on the layer 2 (data link layer) architecture in next generation (“5G”) cellular and IEEE 802.11ax Wi-Fi. The admission control mechanisms defined in 3GPP LTE-A provide assured levels of Quality of Service not typically achieved in IEEE 802.11n/ac, and despite the enhancements of 802.11e, Wi-Fi is a best effort service in most consumer network implementations. This is one of the secondary technical motivations for LAA proponents. There is continued room for improvement in the MAC layer architectures of next generation wireless standards to complement expected PHY layer improvements, and it will be interesting to follow innovations in this area.

We will be publishing a report on these and other commercial and technical implications in the coming months.

Don’t forget to follow SemiWiki on LinkedIn HERE…Thank you for your support!

Posted on

How Magwel is Tapping Tried and True Business Strategy in Targeting ESD

How Magwel is Tapping Tried and True Business Strategy in Targeting ESD
by Tom Simon on 11-02-2015 at 12:00 pm
Categories: EDA, Magwel

Often when a company starts out it takes a while for it to find the sweet spot in the marketplace. Very often it is feedback from existing customers and business success that can help point the way for small companies as they grow. This is just as true in EDA as it is in retailing or consumer products. For instance, Mentor Graphics, though not small at the time, became a significant player in the DRC market after building new technologies that customers responded to in a big way.

The EDA start up Magwel has a similar story. I first met their CEO, Dundar Dumlugol when we both worked at Cadence in the late 90’s. There he was responsible for Spectre and Analog Artist, both leading products in the analog design space. It was years later that we met again after he had founded Magwel. Around 2008 we met at Starbucks in Los Gatos and he explained their then current products that were focused on TCAD for device junctions.

At the time with my background in P&R and digital it was like listening to Greek. However, Magwel had a good technology base that allowed them to build high quality solvers for metal layers and device junctions. The customers at the time were happy with the solutions. However, for Magwel to grow significantly it needed to find additional new markets that had big growth opportunity.

At the nudging of some of their customers they explored solving more widely applicable problems. Chief among them was ESD protection network verification and power transistor modeling. ESD protection simulation and verification is a major challenge for chip companies and much of the core solver and simulation technology Magwel had already developed was easily adapted to this application.

Magwel’s customers were looking for an ESD tool that would accurately predict ESD events, and identify any overcurrent and electromigration issues. The alternative tools available were too slow, overly pessimistic, were not truly simulation based or simply were too hard to use for debugging ESD issues.

After getting numerous test cases and correctly identifying things like parasitic device triggering, electromigration violations and other problems observed in silicon, Magwel showed how well its solution works. By taking advantage of parallel processing and using TLP data to properly simulate snap back behavior, the results could be obtained quickly and matched silicon behavior extremely well. The cost of missing these issues in design can include on-tester failures, respins and even field failures.

The present capabilities of the tool continue to lead in part due to the foundation technology developed after Magwel spun out of IMEC. Working with customers on difficult test cases and their design problems, Magwel has added support for multiple device triggering and simulation for parallel current paths during an ESD event. This is different from just substituting R values for the active devices and assuming only one current path exists as is done in some other products.

The simulator in ESDi uses the TLP IV data for each device to see if the device is actually triggered and what the final-state voltage drop and current is. The triggering of devices is based on checking whether the voltage built-up over the device during an ESD event exceeds the Vt1 voltage. The algorithm correctly models competitive triggering of parallel devices with different Vt1. This requires fully extracting and incorporating the interconnect resistance along the ESD paths as well. These are not simple point-to-point resistances, instead the tool uses multi-point resistances where the current in one current branch will affect the effective resistance seen in another.

Set up is easy, with ESDi obtaining stack-up information from the foundry supplied ITF file and reading TLP data in a csv format. Running the tool and debugging is easy too with cross probing from the violation list to the layout with EM data overlaid in color to highlight errors.

Magwel is working on solving the issues that affect a large number of chip companies and whose effects can frequently be tied back to yield, reliability and performance. This is a good strategy for growth. For my part I reconnected with Dundar earlier this year and have been working on several projects with them. I observed quite a change in the company direction since our previous meeting in 2008. Magwel seems well poised to continue to expand the scope of the issues they can address with their foundation technology.

More information on Magwel’s ESDi can be found here.

Posted on

Verification with Tcl for what?

Verification with Tcl for what?
by Anatoly Myshkin on 11-02-2015 at 7:00 am
Categories: EDA

Nowadays, verification as one of the most complex SoC, FPGA, and ASIC development flow stages always requires new approaches. The following is an introduction to TcL vs/ with SystemVerilog and VHDL, the first in a 3 part series. Part 2 will be “Tcl vs Python, Bluespec” and part 3 will be “VerTcl description”.

Of course, the industry has a traditional and common UVM and other frameworks way – too complex for a quick modifications and not for everyone – especially not for the programmers frustrated by the SystemVerilog, VHDL, etc. usage for something except design.

Many new “programming” technologies for verification (f.e. great Python-based Cocotb) are interesting but require external DPI and VPI interfacing for every simulator and are not compatible in parallel to existing UVM, OVM, OSVVM, etc.

However in enterprise new ways often needed only as help and in addition to known old methods. I will try to describe my team experience of providing new verification ways – experience with Tcl.

Just one moment – Tcl is not HDL or HVL! It is a general-purpose interpreted language useful for many practical cases – especially for scripting, DSL (domain-specific language) creation, testing and verification. Tcl is very popular as embedded EDA and CAD language in a whole industry – it is used as automation, testing, configuring, “glue” language – basically for all programming tasks needed in verification too. That’s give great benefits when it is better to work close with synthesis/compile tools, simulators, etc. But what is known about it? Tcl knowledge is not as common as knowledge of C.

In short – Tcl is powerful and expressive but a very simple programming language – experienced programmers can learn it in just a few hours or days (the syntax and semantics are completely defined in 12 rules, known as the Dodekalogue). In 2014 Tcl celebrates its 25th anniversary. There are many myths surrounding it, but the facts are:

  • Interpreted language using bytecode
  • Homoiconic language,metaprogramming “from the box” (all data types can be manipulated as strings, including source code)
  • Fully dynamic, class-based object system, TclOO, including advanced features such as meta-classes, filters, and mixins
  • Cross-platform
  • Open source (based on a BSD-style license)

It is used as a testing language in many projects – f.e. SQLite, which started as a Tcl extension, relies on more than 30,000 Tcl tests.

What about main differences in general-purpose Tcl and SystemVerilog and VHDL for verification? Unlike HDLs, Tcl works outside the simulator through the interpreter which comes with EDA tool. It controls simulator through interpretation of the scripts built on defined commands – without compilation. It’s possible to control simulator in different levels – from bath (console) or GUI mode. But the most important – it is possible to put inside the simulator and control DUT or DUT with some testing environment (UVM or another) in the same way.

Vendors built-in support:

[LIST=1]

  • Mentor Modelsim / Questa – Tcl-based – there are more than 350 highly-documented commands in “Command reference manual”, mostly full internals control is possible.
  • Synopsys VCS – Tcl embedded – full UCLI and DVE control.
  • Cadence Incisive – just one quote from the official site: “Tcl has become the de facto standard embedded command language for Electronic Design Automation (EDA) and Computer-Aided Design (CAD) applications.“

    At all – simulation internals control, UVM support, extending commands to C/C++ code, configs and much more are possible from the Tcl – it is powerful and universal instrument perfect for different cases when the traditional verification methods are not the clearest way to do needed things correct. Tcl interpreter embedded in simulator provides full language support to verify clear DUT, expand existing testbenches or work with different environments.

    But what are the benefits of using Tcl more intensive than simple simulator scripting/configuring like it usually done?

    • It is possible to “edit, run, stop and again” Tcl scripts without recompile or exit the simulator
    • Because of Tcl nature it is much more expressive and productive then SystemVerilog, etc.
    • DSL support from the scratch (will be discussed later)
    • Flexible creation of any data structures
    • Simple static analysis automation and improvements
    • The easiest way to interface with external to simulator EDA / CAD tools
    • A simple way to interact with something written in other language – “golden model”, third-party library, driver draft, math model, etc.
    • There is no need of anything new – Tcl is already delivered within EDA tools

    Some basic figures from the “Use Scripting Language in Combination with the Verification Testbench to Define Powerful Test Cases” (Franz Pammer, Infineon).

    Tcl can be used in batch mode, DO files or with GUI. It is easy to use command line or “Tools > TCL” menu. Support information about Tcl can be found in “Help > Tcl Syntax”, “Help > Tcl Man” and in official documentation. Simple Tcl examples from different vendors, more complex examples will be shown in the next parts –

    [LIST=1]

  • http://pastebin.com/0zwGDgmK – basic Tcl (Mentor)
  • http://pastebin.com/YBLTj9A5 – some hardware interaction with TCL (Altera)
  • http://pastebin.com/7zpPBhQd – design interaction (Xilinx)

    Better to know that any Tcl script can control itself and all simulation process at all very flexibly – handling breakpoints and errors of simulators, setting default error actions, interrupting, etc. – the control always can be returned to the script or command line.

    • Posted on

    Silicon Valley USPTO is Open for Business!

    Silicon Valley USPTO is Open for Business!
    by Daniel Nenni on 11-01-2015 at 4:00 pm
    Categories: General

    Probably the best and most attended EDAC Emerging Companies event happened last week so congratulations to Bob Smith and staff. The premise was to develop, strengthen, and protect your intellectual property which is paramount to all emerging technology companies. Many people in this industry, including myself, have learned this lesson the hard way, absolutely.

    Remember Avant!? Yes some code was misappropriated by a nefarious consultant but the dirty deed did not merit the destruction of the company and the stake holders (my opinion). I was also involved in a simple EDA contract dispute that blew up into a multi-million dollar litigation. What a colossal waste of time and resources! I remember offering to split the difference (they would pay half of the contract amount) so we could shake hands and walk away with dignity. But of course lawyers got involved and it cost the opposing company 20x in settlement and legal fees. Our industry is strife with good and bad litigation so yes we should all pay attention here.

    First up was the Mayor of San Jose, Sam Liccardo. What a great guy! After watching the recent presidential debates I was not looking forward to meeting another politician but seriously, Sam renewed my faith in the American political system, at least at the local level for sure.

    Next up was John Cabeca, Director of the new Silicon Valley Patent and Trademark Office. Another great guy who clearly gets us and is an EXCELLENT resource for emerging technology companies:

    The Silicon Valley, known as one of the most prodigious and innovative entrepreneurial communities in the country, was selected as our West Coast presence to assist the USPTO in fostering and protecting innovation. Looking for information focused on startups? Visit our Startup Resources page.

    Take a look at the upcoming events calendar. Can you believe there is a Girl Scout Merit Badge for intellectual property!?!?!? And speed dating for start-ups? 😎

    • November 10, 2015
      Patent Quality Chat Webinar Viewing
      USPTO Silicon Valley Office
      26 S. Fourth Street
      San Jose, CA 95113
      View the Patent Quality Chat Webinar featuring Deputy Commissioner for Patent Quality, Valencia Martin Wallace in our offices. The webinar will be proctored by one of our Silicon Valley resource supervisory patent examiners.

    • November 10, 2015
      Trademark Tuesday—”Lunch and Learn”
      USPTO Silicon Valley Office
      26 S. Fourth Street
      San Jose, CA 95113
      The USPTO Trademark Assistance Center discusses resources and answers questions via webinar.

    • November 17, 2015
      Info Session: Ombudsman, Prior Art Search, and Interview Practice
      USPTO Silicon Valley Office
      26 S. Fourth Street
      San Jose, CA 95113
      Applicants and attorneys learn about programs and resources for more efficient patent prosecution.

    • November 19, 2015
      Patent “Lunch and Learn”
      Supervisory patent agents help inventors and entrepreneurs during live information sessions.

    • December 12, 2015 – Girls Scout Intellectual Property Badge Program
      Girls grades 2-8 learn about intellectual property rights in collaboration with The Tech Museum of Innovation and The Girl Scouts.

    • December 15, 2015, 12:00 p.m. to 1:00 p.m. PT
      Trademark Tuesday – Lunch and Learn
      USPTO Silicon Valley Office
      26 S. Fourth Street
      San Jose, CA 95113
      The USPTO Trademark Assistance Center discusses resources and answers questions via webinar.

    • January 26, 2016 – Patents and Trademarks 101
      The USPTO delivers intellectual property basics at the new Patent and Trademark Resource Center in the King Library in San Jose.

    • February 2016

      • Speed Dating for Startups
      • Cybersecurity Partnership Meeting
      • PTAB Rules Update

    The second half of the evening with EDAC was a panel session with lawyers. I tried to pretend to care about what they had to say but I failed and left after 30 minutes. Let’s face it, our legal system is not unlike our political system but I digress…

    Don’t forget to follow SemiWiki on LinkedIn HERE…Thank you for your support!

    Posted on

    Moving with Purpose for Certainty

    Moving with Purpose for Certainty
    by Pawan Fangaria on 11-01-2015 at 12:00 pm
    Categories: EDA, Solido

    In 1492 Christopher Columbus sailed from Spain towards west on Atlantic Ocean in search of Asia and Indies. Between his four voyages (1492 – 1502) he discovered many different islands and then what we call Americas. Although he had a compass with him, imagine searching a needle in a haystack. Even with localization of areas and then a smart search, still there is no guarantee of success.

    Similar is the case in the modern world with semiconductor design and manufacturing; there is a great deal of uncertainty between the chip and the design, what you get out of the fab may be far from what you design. And this uncertainty gets worse with shrinking technology nodes, new transistor structures like that of FinFETs, low noise margin and so on. The semiconductor design needs 4-6 sigma accuracy and precision for it to provide the right yield.

    So, how should semiconductor design be approached for optimum yield? To check variation, should millions of Monte Carlo (MC) simulations be run for different circuit parameters at multiple process corners? You may still miss the actual outliers. A few years ago, I had written about Solido’s Variation Designer Platform and HSMC (High Sigma Monte Carlo) method which works very fast, is accurate, and scalable over large number of process variables; it prioritizes simulations for most-likely-to-fail cases and never rejects any sample that can cause failure.

    During DAC 2015, in a panel session organized by Solido, the representatives from Cypress, Applied Micro Circuits and Microsemi presented their experiences about variation issues and their solutions. Paul McLellan already talked about Sifuei Ku’s views from Microsemi in one of his earlier blogs. I would like to delve into the views expressed by Cypress and Applied Micro as well.

    Dragomir Nikolic, CAD Director at Cypress is critical about differentiating IP where significant analog content makes a difference. He sees major portion of SoC cycle times being invested into IP. How does he improve upon cycle times applying complex set of DOEs to designs which varied amid varied experiences of designers spread across different teams in different continents? This is what he calls a change in his design methodology from “Whack-A-Mole” to “Move-With-Purpose”.

    In Dragomir’s words –“What Solido was able to do for us is, allowed us to dynamically derive the corners that truly dominate your analog design. With that, our cycle times have tremendously shrunk, our quality of results has definitely reached our internal goals for 4-sigma and we have seen tremendous improvement in the overall quality of our design” .See Dragomir’s video below

    Dragomir’s story about the most reluctant designer for change coming back after Variation Designer evaluation and asking for its license was interesting. That says – whatever you do for performance, accuracy, quality, and the like; unless your tool’s usability is good, you can’t win the designers, you fail.

    Alfred Yeung, Sr. Director of Circuits & Technologies at Applied Micro Circuits talked about different parts of a design which can be sensitive to device variation in terms of functionality and performance; and how hard it is catching the actual problems using traditional MC simulations. He presented a case study where he used high-sigma analysis using Solido Variation Designer. Solido needed to simulate only 7000 samples out of 100000 samples analyzed; and 13000 samples simulated out of 10 billion samples in another experiment with the same case. Many outliers were seen outside the design target. The issues were observed in silicon and fixed.

    In Alfred’s words – “What we’re really interested in is what happens when you run 10 billion samples. And you see here, the circuit doesn’t scale well with a lot of samples and high sigma. And there’s a design flaw here. And you see here in this particular test case it ran up to 10 billion samples, but the simulation time is only based on about 13K samples simulated so the run times were still very reasonable for us. It was something that we were not able to do in the past, and not only did we see failures we saw big outliers. The transient scale and the value scale here is not the same scale as before. But to fit everything on the same graph you will find that large number of outliers, outside the design target” .See Alfred’s video below

    During the Q/A session, all panellists were appreciative of the Variation Designer’s usability; it had no problem changing from one simulator to another, it’s very easy to use. On one particular question about technology node – the Variation Designer can be applied to any technology node. It’s more to do with variation-aware design methodology which is applicable to 130nm or higher as well as 28nm or lower nodes.

    The session also included a presentation by Jeff Dyck, VP of Technology operations at Solido. Jeff talked about his experiences with designers who have difficulties understanding variation issues, which corners to run, and crunch of time for identifying and fixing issues. Most of them end up overdesigning which was found to be the biggest issue in the survey conducted by Solido. Then he talked about the challenges in moving from old to new tools, support issues, and so on. Jeff stressed on Solido’s deeply specialized, talented, and immediate support. See Jeff’s video below for more interesting details from the survey and his experiences from his interaction with designers.

    All videos and their transcripts are here.
    Also read:
    Replacing the British Museum Algorithm
    High Yield and Performance – How to Assure?

    Pawan Kumar Fangaria
    Founder & President at www.fangarias.com

    Posted on

    How to Live with Rapid Changes During Early Development of IP

    How to Live with Rapid Changes During Early Development of IP
    by Tom Simon on 10-30-2015 at 4:00 pm
    Categories: EDA, Perforce

    Best practices call for using a version control system with systematic releases when developing IP. However, in the early stages of IP development using a rigid version control system with a cumbersome release process can hinder productivity. To fully understand how this works we should start by defining what is meant when we say IP.

    The term IP is used broadly in IC design. It can refer to libraries, memory blocks, or portions of a design coming from internal or external organizations. Furthermore, blocks developed using IP may themselves become IP for higher level design. In this case the lower level IP are referred to as IP resources.

    Methodics has thought through the implications of developing and using IP early in a project’s lifecycle. This stage is characterized by rapid changes and short loop iteration. If each time a work in progress change is made early on in the development process, it was necessary to create a release, the entire work flow will be slowed down. To solve this problem Methodics supports a specification that uses the most recent version of the files to populate a workspace. This is known as IP@HEAD.

    There are a number of subtleties in its usage. They key point being that loading a workspace with IP@HEAD will pull in the then current versions of not only the IP itself but the resources the IP relies on. Additionally, if the IP resources are themselves running on an orderly release system, as opposed to @HEAD, then the most recent release will be what are loaded. A release update of an IP resource will update the user’s workspace that is using @HEAD.

    The history of design management in the IC space is a long and checkered one. It is definitely a different problem than source code revision control management. Designers have balked at systems that impose restrictions on their method of operation. The cost benefit-trade off is most difficult to justify at the beginning of a project, especially if the design management system is imposing unneeded and inefficient processes.

    Later as a design matures, the benefits are more readily apparent and design management provides some huge wins for reliability, quality, repeatability and traceability. When a design starts by using IP@HEAD for its workspaces, as the design matures a release methodology can be put in place so there is less uncertainly as functionality is stabilized.

    Methodics has built a sophisticated IC centric data management system. One of the plusses of their system is that it is based on industry standard revision control systems like Perforce and Subversion. This means that the design data will never be locked in. Their infrastructure also enables multisite sharing, disaster recovery and design progress analytics.

    If you want more information on using IP@HEAD in Methodics, please look here. For more general information about Methodics their website offers useful information.

    Follow the adventures of SemiWiki on LinkedIn HERE!