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

Posted on

Something New in IP Lifecycle Management

Something New in IP Lifecycle Management
by Daniel Payne on 07-19-2017 at 12:00 pm
Categories: EDA, Events, Perforce

Last month at DAC I met up with Michael Munsey of Methodics to get a quick update on what has been happening over the past 12 months within his company, and he quickly invited me to watch an archived webinar on their latest tool for IP Lifecycle Management called Percipient. I love to play the board game Scrabble, so i had to Google the word Percipient to learn its meaning, “having a good understanding of things, perspective“. OK, that’s my new word for the day then.

We often blog about new and updated point EDA tools on SemiWiki, so it’s refreshing to learn more about the category of EDA tools that works throughout all of the tools and IP used on a SoC project. System-level complexity has become so large that the days of using Excel to track semiconductor IP usage or EDA tool usage fall woefully inadequate.

The webinar was introduced by Daniel Nenni from SemiWiki, then quickly handed over to Michael Munsey.

Related blog – New Concepts in Semiconductor IP Lifecycle Management

Methodics started out back in 2007 helping Analog IC designers using Cadence tools to manage their design data with a tool called versic. Their next tool was an IP Management Platform called projectic, followed by a content-aware NAS optimizer and accelerator called warpstor.

So why introduce a new tool? Well, because when an electronic system is being designed today we have silos of information that really don’t integrate or talk to each other:

  • Design Models
  • Infrastructure Models
  • Program/Project Models

So the goal for creating Percipient was to tie all of these three domains together using a platform that models the entire ecosystem, independent of EDA or IP vendor.


So Percipient continues to take the proven Design Model features and objects from projectic, like:

  • Workspace tracking
  • IP usage tracking
  • Release management
  • Labels and custom fields
  • Bug tracking
  • IP versions
  • Design files
  • Permissions
  • Hierarchy
  • Hooks into design process

Expansions in Percipient include:

  • Hierarchical releases
  • Moving aliases
  • Snapshots
  • Improved IP and IPV usage tracking
  • New infrastructure model using an events platform to track all CPU usage per tool
  • Optimized workspaces
  • Tracking all tool operations in context
  • warpstor to be added in Percipient, stay tuned
  • Integrates with many other tools for dynamic, realtime tracking (NetApp, DellEMC, Perforce, JIRA, Bugzilla, jama, Jenkins, etc.)
  • Model extensions for customizations of data mining and dahsboarding

Simon Butler of Methodics did a live demo of how users work each day with Percipient in an object-oriented fashion on libraries, IP blocks, IP versions and workspaces. The user interface is a familiar web app with widgets:

Workspaces were examined and modified using a command line approach:

Related blog – Achieving Requirements Traceability from Concept through Design and Test

Vishal and Michael did the final Q&A session:

Q: How do I find where a particular IP is being used in my organization?

A: A few ways, we can see IP used inside of a hierarchy for a project, or which workspaces contain that IP.

Q: Can a user in one workspace use a different IP than the top level?

A: Yes, you can use any IP version as needed in your workspace.

Q: Can one SoC use two different versions of the same IP in the hierarchy?

A: Yes, you could use different IP versions in the same hierarchy and the tool will highlight this version difference.

Q: Can percipient report which workspace belongs to a user, and where is that?

A: Using the “pi” command there’s a column with the username owner for each IP. It’s easy to filter by username too.

Q: Is it possible to use percipient on top of another DM?

A: What Methodics brings is the most sophisticated way to manage IP, and we can migrate some or all of your IP into percipient (manually, import with templates, scripting, etc.) Keep your data in Perforce, no migration required.

Q: Can you connect with IC Manage, ClioSoft or DesignSync?

A: Our competitors don’t publish their internals, but we can manage IP by a filesystem approach. It’s best to move your new work into something like Perforce though.

Q: Can percipient tell me the number of IPs being used, and the number of standard cells per IP?

A: Yes, you can see how many standard cells are being used, or any IP block.

Q: How do you handle IP permissions?

A: You need to specific which users can view which IP blocks based on user capability. For example, contractors would be limited, while employees would have more access. Permissions can be managed at the command line or the web GUI, which ever method you prefer.

Q: Does permission system relate to Linux permissions or the DM system?

A: Users and groups in Linux can be imported into percipient, and then you can give individuals access to IP as needed per project in a centralized fashion.

Related blog – CTO Interview: Peter Theunis of Methodics

Summary

Methodics has carved out a very important piece in the flow for SoC design by focusing on IP Lifecycle Management. There approach has been field-tested by big names in the semiconductor design industry, and with the new release of percipient they have increased features to keep pace with industry requirements.

Watch the complete 48 minute archived webinar online, after requesting a password.

Posted on

High Density Advanced Packaging Trends

High Density Advanced Packaging Trends
by Mitch Heins on 07-19-2017 at 7:00 am
Categories: EDA, Events, Siemens EDA

Thursdays at the Design Automation Conference (DAC) are always a good time to catch up on areas of technology which are adjacent to that which you normally work. The exhibit floor is over and you have more time to spend in seminars. At this year’s DAC, I took advantage of a half day seminar put on by Mentor, a Siemens business, entitled High Density Advanced Packaging Trends. While this seminar was focused on electronic systems packaging, my work with integrated photonics has been clearly pointing to the need for system-in-package (SiP) solutions and I was interested to get a snapshot on the current state-of-the-art for IC packaging.

The seminar started off with a talk by Dick James, senior analyst for TechSearch International. Dick gave an excellent talk on FO-WLP (Fan-Out Wafer-Level Packaging) trends. Probably the biggest driver of this packaging technology is the explosion of mobile devices where wafer-level packages (WLPs) provide a significant advantage for thinner form-factors. Other areas driving WLP use include high performance computing, and automotive millimeter-wave and RF applications that benefit from the shorter, less lossy connections. Add to this list the ever-growing Internet-of-things (IoT) market that is starting to demand integration of multiple heterogeneous devices into a single low-cost package (e.g. MEMs-based sensors, analog, RF, digital and memory). Any one of these end-applications markets drive enough volume to make WLPs economically interesting.


Dick showed an fascinating comparison of the original Apple iPhone which had two WLPs vs the iPhone 7 which had 44 WLPs. One of the 44 is a TSMC InFO-WLP (Integrated Fan-Out) that includes a Package-on-Package (PoP) configuration with the application processor in the bottom package and multiple side-by-side memories in the top package. Apple isn’t the only phone manufacturer using WLP technologies as evidenced by Samsung (Galaxy 7 ; 14 WLPs), Sony (Xperia ; 13 WLPs), Sharp (Aquos Zeta ; 13 WLPs), Huawei (P9 Plus ; 16 WLPs), ZTE (Goophone ; 3 WLPs) etc. On average, there are 15 WLPs per smartphone and the numbers continue to increase.

The shift to WLPs is disruptive on multiple fronts. WLPs remove the need for a laminate substrate which means substrate suppliers are removed from the supply chain. Since WLPs use “wafers” as carriers and traditional thin-film processes for metallization of interconnect, packaging can take place at the foundry as opposed to an outsourced semiconductor assembly and test (OSAT) shop.

Don’t count the OSATs out however. Suresh Jayaraman, of Amkor also presented at the seminar. He gave an overview of Amkor’s Silicon Wafer Integrated Fan-out Technology (SWIFT) offering which is a WLP based on a 300mm wafer carrier. SWIFT uses a “die-last” process that enables processing of the fan-out Redistribution Layers (RDL) in parallel to the die being run in the foundry. This helps Amkor to reduce cycle time once the dice arrive at their shop to be packaged. Suresh also reminded us that they provide a neutral place for die sourced from different foundries to make their way into the same package; remember the need for heterogeneous integration of processors, memory, MEMs, analog, RF etc.

WLP-based SiPs are also disruptive for the CAD tool vendors. Till recently, board and package design were handled by completely different tools than those used for integrated circuits (ICs). SiPs, enabled by WLPs, demand much greater collaboration between board, package and IC designers and a shift to more SiPs could mean new battle lines being drawn between entrenched tool competitors. WLPs also bring many new technical challenges that stress the typical board and package level tools including the advent of very high pin-count packages (> 10,000) and fine-pitch (5um line/space) non-orthogonal routing. With stacking also comes 2D/3D interactions requiring tools to have coordinated views from all three domains (die, package and board).


The biggest challenge seems to be the desire to bring data from the disparate domains together to ensure correct connectivity throughout the stack (remember we are now dealing with tens of thousands of signals) and a myriad of new manufacturing design rules from all three domains. To make matters worse, there are almost no standards established between the different domains, let alone the various foundries, OSATs and CAD tool vendors.

Mentor Graphics rounded out the seminar by giving a presentation and live demo of the solutions that they are bringing to the WLP space. The presentation focused on three tools, those being Mentor’s Xpedition Substrate Integrator, Xpedition Package Designer and Calibre 3DSTACK. Xpedition Package Designer focuses on package design and it already includes real-time 2D/3D design viewing and editing. Mentor seems to have this process well in hand.


Similarly, the Mentor Calibre team has done a good job of working to bring IC methodologies into the packaging domain by partnering with foundries and OSATs to create what they call an assembly design kit (ADK). The ADK serves much the same purpose as a process design kit (PDK) in the IC world. Using characterized ADKs, Calibre 3DSTACK is able to verify design rule checks (DRCs) and connectivity (LVS) both within the package and across the die / package / board boundaries. Calibre 3DSTACK is also able to do DRC checks on non-orthogonal shapes found on the various RDL layers. The design rules and specifications for these checks are all stored in the ADK.

Mentor’s Xpedition Substrate Integrator tool combines information from all three domains to enable visualization and optimization of complex SiPs by letting designers see the impact of design changes in one domain on the other two domains. This is extremely helpful in an environment where co-design is so essential. The demo given by Mentor was pretty amazing as you could literally see interdependencies of all three domains and trace signal connectivity through the full stack from die pins through various redistribution layers (interposers, WLPs and package), micro-bumps and through-silicon vias (TSVs) all the way to the balls on the ball grid array and finally to the board. It was impressive.

In summary, as systems-in-packages become more prevalent we will continue to see innovation and changes in the both the design and manufacturing eco-systems. Keep an eye out in this area as these changes can and will be disruptive and could cause some shifts in the ecosystems as we know them. Mentor seems well positioned for the new opportunities given their strengths in board, package verification areas.

See also:
Mentor Xpedition IC Packaging Products
Mentor Calibre 3DSTACK

Posted on

Applying ISO 26262 in a Fabless Ecosystem – DAC Panel Discussion

Applying ISO 26262 in a Fabless Ecosystem – DAC Panel Discussion
by Tom Simon on 07-18-2017 at 12:00 pm
Categories: Automotive, Events, Imagination Technologies, Siemens EDA, TSMC

The fabless movement was instrumental in disaggregating the semiconductor industry. Vertical product development at the chip and system level has given way to a horizontal structure over the years. This organization of product development has been doing an admirable job of delivering extremely reliable products. However reliable for a phone is not reliable enough for an autonomous vehicle with a service life of up to and over a decade. This issue was recognized years ago and lead to the development of the ISO 26262 standard in 2011.

ISO 26262 deals with the electronic systems in a car, with the goal of avoiding systematic errors and faults, as well as helping to deal with random errors. It applies to non-critical systems such as infotainment and also to critical systems like brakes, steering and autonomous operation.

Electronic systems in cars are often produced by fables semiconductor companies and frequently incorporate 3[SUP]rd[/SUP] party IP. Applying ISO 26262 to products developed in a dispersed manner is leading to changes that are affecting every member of the supply chain. To explore these impacts Mentor hosted a panel discussion at DAC in Austin. The panel had representation from members of each element in the supply chain affected by ISO 26262.

At first glance it makes sense that Mentor would be on the panel as an embedded OS supplier, but in the context of ISO 26262, the design tool providers are also an essential link in the chain. Rob Bates, Chief Safety Officer for the Embedded Division, spoke on behalf of Mentor. Also on the panel was Volker Politz, VP Segment Marketing at Imagination Technologies, who talked about the changes necessitated for IP developers. Jim Eifert Automotive Architect at NXP provided insight from the automotive system integration perspective. Lastly, Lluis Paris, Director, Worldwide IP Alliance at TSMC shed light on how the foundries for fabless semiconductor companies have shifted the way they work in the automotive sector.

There was a round of introductory comments by each panelist. Jim from NXP said that a big benefit of the standard is that there is common terminology that buyers can use when speaking with suppliers. Lluis from TSMC talked about how the role of a fabless foundry has shifted from just supplying silicon to developing an automotive platform to enable and encourage ISO 26262. This stems from the need for more extensive sustaining engineering and additional product documentation among other things. TSMC has added the role of safety manager to their organization as part of this endeavor.

Volker from Imagination pointed out that now the IP provider is in the middle. In some ways they are partnered with their customer’s engineering department. Products fuse together external and internal IP and design work. The biggest change for him is that there is now a more formal way for them to work together. Rob from Mentor added that prior to ISO 26262 companies were just continuing to engage in their previous practices. The standard has really changed the way the companies involved operate. He cited the example of TSMC, who is rebuilding many aspect of how they deal with automotive designs from the ground up.

The first question put to the panel was, does IP have to be certified?

TSMC was quick to point out that IP does not have to be certified, but that the process for making the chip does. This arises because in many cases the applications for the IP are so large that the IP vendor can’t possibly know the use-case that is applicable. Imagination added that there is not really a certification for IP, but the vendors can help by delivering the necessary documentation with their IP. IP vendors can help contribute. NXP said that the car is what is certified, and the key is to turn over at each step of the development the correct documentation to facilitate this and create traceability.

The next question asked if embedded software should be considered IP.

Mentor responded by saying that the embedded software resides on the chip which is closer to the customer. Development tools are closely linked to the embedded code, so they too are tied to the standard in some way. NXP agreed that the embedded code needs to comply with the standard and wished there was more explicit requirements for development tools.

The next question asked if the car is ‘certified’ then what documentation is needed to create traceability up the chain from the components?

TSMC stated that the foundry has to do a larger number of things under ISO26262. These include special SPICE and reliability models, along with aging models. The car needs to be traceable after 18 years in case there is an issue down the road. The foundry needs to keep the process viable for a long time and may even potentially need to go back to the wafer info after many years. NXP added that the standard requires a quantitative approach to quality. As part of this it can go to the level of looking at parts per billion failure rates.

Mentor sees that ISO 26262 puts a burden on the tool users to qualify the tools they are using for design. However, realistically this is not something the tool users can take on by themselves. The tool vendor must play a role. This is why they created the Mentor Safe Program.

The panelists were asked, despite the increased level of work required, whether or not they saw benefits in following the process in terms of improved reliability and safety.

TSMC said that they were already doing many of the things that are needed. They feel that instead of a quality increase, what they are seeing is better lifecycle planning. Imagination answered by saying that they are seeing some improvements, but they are also seeing improved reusability. NXP followed by saying that their safety process was already working, but they now have a better documentation process. Mentor feels that the standard helps people look at what they were doing, and that it can only help.
Then came the question of how the standard should evolve. TSMC feels that the hardware side of the specification is comprehensive and stable. However, there is more work that will need to be done on the software side. Imagination would like to see more focus on real integrity. They feel it is important that people are committed to the process and this is the only way the data is reliable. They also expect additions in the area of security, which is at its core a safety issue. NXP amplified that concern by saying that security is absolutely a safety issue, and they are very concerned about hacking. Mentor also concurred that security is something that needs to be addressed more fully in the future versions of ISO 26262.

The panel closed with a question on what new things would be beneficial to the ecosystem. TSMC feels that there is a good ecosystem in place for silicon. They see further ecosystem work occurring in the customer infrastructure. Imagination reiterated the point that they felt that security should be a priority. Imagination said that the EDA companies can also do a lot to help. The more EDA players do – for instance fault injection – the easier it will be to meet the spec. NXP really wants to see chip level design flows made easier to qualify. If they can get a packaged solution it will reduce their need for spreadsheets.

Mentor agreed with this perspective and feels that EDA vendors can help make it possible to adhere to the standard more easily. For instance defect tracing analysis could be added, rather than it being an after-the-fact activity. Mentor sees value in adding capabilities to make it easier to qualify. At the end of the day Mentor feels these same practices and features have wider applicability. They want to move the process out of the automotive space. It could improve customer satisfaction in a wide range of products. Mentor did a great job of pulling together the panel participants and facilitating the discussion. With their Mentor Safe program, it is clear they are serious about automotive safety. For more information on Mentor’s work in this area, please look at their website.

Posted on

Why Ansys bought CLKDA

Why Ansys bought CLKDA
by Bernard Murphy on 07-18-2017 at 7:00 am
Categories: Ansys, Inc., Automotive, EDA

Skipping over debates about what exactly changed hands in this transaction, what interests me is the technical motivation since I’m familiar with solutions at both companies. Of course, I can construct my own high-level rationalization, but I wanted to hear from the insiders, so I pestered Vic Kulkarni (VP and Chief Strategist) and Joāo Geada (Chief Technologist and previously CTO at CLKDA) into explaining their view of the background and benefits.


Ansys already has a strong position in integrity/reliability for electronic systems, from chip design up through the package and the board level. This is important, for example, in design for total system reliability and regulatory compliance in ADAS systems under challenging constraints such as widely varying temperature environments (in front of a windscreen in Death Valley, or in an unheated enclosure in Barrow, Alaska). Particularly at the chip-level, through their big data/elastic compute approach to fine-grained multi-physics analytics rather than margin-based analysis, they assert that they can offer higher-confidence in meeting integrity and reliability goals in reduced area with faster design turn-times. What they presented at DAC seems to bear this out.


This is an important advance, but as always in semiconductor design, the goal-posts continue to move. Vic and Joāo said that customers are finding increasing difficulty in getting to timing signoff at 16nm and below, often starting with 10k+ STA violations, which can take 3-4 weeks to close. They are managing process variation factors (OCV) though use of the latest standards for timing in Liberty models but there are also dynamic factors to consider. At these feature sizes, operating voltage can drop to 0.6-0.7V, but threshold voltages don’t drop as much, so sensitivity to power noise increases and that can lead to intermittent timing failures in what would otherwise appear to be safe paths. Equally, clock jitter as a result of power noise can cause intermittent failures.

Of course you could follow the standard path and over-design the power distribution network (PDN) to margin for worst possible cases across the die. But that over-design becomes increasingly expensive and uneconomic, especially at these aggressive nodes, so you settle for a compromise between area and risk in which you hope you covered the most likely corner cases. Based on presentations at DAC this year, Ansys has already demonstrated that they can replace this uncertain tradeoff in related problems with multi-physics analysis delivering low risk integrity/reliability across the die with significantly less over-design than the traditional approach.

Which bring us to the reason Ansys wanted the CLKDA FX tool-suite. To address these dynamic timing problems, they needed to fold a high-accuracy timer into their multi-physics analysis to enable analysis of timing side-by-side with dynamic voltage drops (DvD). The point here is to analyze locally across the design to guide local adjustment of the PDN where appropriate. In an area where there’s enough slack, maybe you’re not too worried if timing sometimes stretches out a bit, so there’s no need to upsize the local PDN. Where timing is tight, you upsize enough to ensure that DvD will not cause the path to fail. Similarly, multi-physics analysis will highlight where clock jitter sensitivity could cause failures and may require mitigation in the local clock distribution.

Getting this right requires an accurate timer, better than a graph-based STA, closer to Spice-level accuracy but much faster than Monte-Carlo Spice (MC Spice) so it can be effective on large designs. That of course has been the value-proposition of the FX family for many years – a technology which can propagate statistical arrival times and true waveform shapes while also maintaining correct distribution, yet run 100X faster than MC Spice. Since FX already has a bunch of customers, I have to believe that’s not just a marketing pitch 😎.

So where does this go next? I’m sure there will be continuing integration and optimization with the SeaHawk and Chip-Package-System flow. Joāo also pointed out a number of additional opportunities. Ansys’ strength is multi-physics analysis so there are opportunities to cross other factors in analysis – variability and timing or aging and timing for example. CLKDA has tilted at the variability windmill before, lobbying for a transistor-level static timing analysis approach, for example to better model the influence of accumulating non-Gaussian distributions along a path. Perhaps their concept will start to gain traction in this new platform. Their work in signoff for timing aging is also very intriguing and I think is likely to attract significant interest in high reliability/ long lifetime applications (automotive maybe?)

So now you know why Ansys acquired CLKDA. For me this seems like an even better home for the FX technology. You can learn more about ANSYS solutions, including the FX products, HERE.

Posted on

HLS update from Mentor about Catapult

HLS update from Mentor about Catapult
by Daniel Payne on 07-17-2017 at 12:00 pm
Categories: EDA, Events, Siemens EDA

I recall back in the late 1980’s when logic synthesis tools were first commercialized, at first they could read in a gate-level netlist from one foundry then output an optimized netlist back into the same foundry. Next, they could migrate your gate-level netlist from Vendor A over to Vendor B, giving design companies some flexibility in negotiating the best foundry terms. Finally, they could accept RTL code as an input, then create foundry-specific gate-level netlists that were optimized.

Since Synopsys came to dominate the RTL logic synthesis market in the 1990’s, many competitors have aimed to sit on top of logic synthesis with their own High Level Synthesis (HLS) tool. EDA vendors have tried over the years with varying degrees of commercial success to grow the HLS market. All of the big three in EDA have made inroads with HLS tools and sub-flows, so I met up with Badru Agarwala, GM at Mentor during DAC in Austin last month to get an update on what’s been happening with their Catapult product line.

Q: What are the industry trends with HLS these days?

A: HLS is only one pice of an ecosystem moving up to use the C++ language now, so one goal is to make C++ design as robust as RTL verification is.

Q: What customers are using HLS, has it gone mainstream yet?

A: Some big company names that you should recognize that are using HLS now include: NVIDIA, Qualcomm, Google and STMicroelectronics.

Q: Is there a sweet spot for using an HLS tool flow?

A: Yes, segments like machine vision, computer vision, 3D TV all enjoy an HLS methodology.

Q: What about design capacity with HLS, is that an issue?

A: We’ve seen a 25 Million gate design completed with Catapult, so the capacity is there.

Q: What benefits do HLS designers enjoy the most?

A: Three things that are common benefits include: Verification is more thorough, the design process is much faster than RTL, and designers can make more changes at the last minute of their projects.

Q: How is HLS impacting the verification process?

A: Now with HLS you can start verification much earlier than before, in parallel with the design process, then when the code is stable start to do RTL design.


Q: What are some of the challenges of coding with C++ for an HLS language and how is Catapult changing?

A: Most existing C++ tools are for SW developers, not really well suited for HW developers, so there’s not much linting or property checking going on. HLS users really need coverage tools, along with bit accuracy and loop unrolling. We just announced Catapult DesignChecks to help an HLS user find bugs while coding, so they don’t have to debug as much with simulation and synthesis. There’s both a static mode of DesignChecks for fast linting plus a formal engine for checking. These approaches don’t even require a testbench to be coded.

A second new tool we’re talking about is Catapult Coveragewhich gives you code coverage for C++ and enables faster closure of synthesized RTL. Designers can reach 100% C coverage, then start to do HLS synthesis. We’ve had coverage tools for gate-level and RTL, so it only makes sense to raise that up to the C level too.

We also have SLEC (Sequential Logic Equivalence Checking) HLS a new C to RTL equivalence tool, so that you know that the RTL coming out of Catapult really is the same as the C++ that went into it, without having to run simulation and verification cases. Setup is more automated now.

Summary
Mentor with the Catapult family of tools has been at this HLS methodology for a long while now and have continued to invest in making the whole tool flow more integrated and easier to use for digital designs. I was impressed with the three StreamTV engineers in the Mentor booth who showed a 3D TV design using Catapult in their 15 month project because of how few people were required to do such a complex design so quickly, and consumers view 3D without glasses.

Posted on

NetSpeed’s Pegasus Last-Level Cache IP Improves SoC Performance and Reduces Latency

NetSpeed’s Pegasus Last-Level Cache IP Improves SoC Performance and Reduces Latency
by Mitch Heins on 07-17-2017 at 7:00 am
Categories: IP, NetSpeed Systems

Memory is always a critical resource for a System-on-Chip (SoC) design. It seems like designers are always wanting more memory, and the memory they have is never fast enough to keep up with the processors, especially when using multi-core processors and GPUs. To complicate matters, today’s SoC architectures tend to share memory across heterogeneous environments including temporal (isochronous, steady, random) and functional (fully coherent, IO-coherent and non-coherent) features. System designers are forever trading off performance and latency against the sharing of memory resources, power reduction and ensuring system timing integrity.

Many designers are now turning to what is known as last-level cache (LLC) to avoid SoC memory access bottlenecks and congestion among heterogeneous masters. Some designers primarily think of a LLC as simply a L3 cache, however the people at NetSpeed have taken the LLC concept to a much higher level. Pegasus is the product name for NetSpeed’s LLC IP and when used in combination with NetSpeed’s NocStudio design software, Pegasus can be used to optimize circuit throughput, reduce latency and improve memory efficiency.

Pegasus is a parameterized and configurable LLC architecture that is layered over NetSpeed’s Orion and Gemini Network-on-Chip (NoC) technologies. Pegasus leverages NetSpeed’s core NoC capabilities to ensure quality of service (QoS) and deadlock avoidance while also allowing the designer to support coherent, non-coherent and mixed architectures. The IP provides support for design-time programmable coherent-cache and coherent-memory modes along with memory error-correcting code (ECC) capabilities.

Pegasus also features runtime modes that enable soft partitioning of cache associativity per master. This allows designers to better utilize their cache resources through integration of some system IPs and by enabling the use of some or all their LLCs as directly addressable RAM. This latter capability is particularly useful when having to support multiple applications processors on the SoC that differ in their RAM requirements.


A key feature of Pegasus is that the IP is both design and runtime programmable and it supports multiple modes including, coherent cache, reduced coherent latency, power reduction, memory cache, increased bandwidth through locality and improved software coherency by avoiding the need for flushes. Not all slave agents are created the same and having multiple LLCs, based on address ranges, gives designers the ability to customize each LLC based on the slave characteristics.

Pegasus also works with NocStudio’s understanding of the SoC’s floorplan to enable distributed LLCs which can aid in connectivity-congestion mitigation and improve overall system bandwidth and latency through locality. In addition, Pegasus can do all of this while working in coordination with ARM’s Trust Zone capabilities to ensure complete protection of a device from bad outside actors trying to breach the SoC’s key memory and code blocks. This is an essential feature for designs targeted at the Internet-of-Things (IoT) market.

Since Pegasus is used with NetSpeed’s NocStudio software many steps to configure and program the LLCs are automated making it easier for designers to incorporate Pegasus into their designs. Using NocStudio, designers can simulate their SoCs with different configurations of LLCs over different work-loads and expected traffic patterns to ensure latency and performance are optimized. This is important as coherent SoCs often have processors with conflicting needs and which may have some traffic flows that are highly sensitive to CAS latency while others are more sensitive to bandwidth requirements. Striking a balance in a heterogenous SoC is non-simplistic and Pegasus along with NocStudio makes the job a lot easier.


Not only can the Pegasus LLC IP help with system throughput, bandwidth and latency, it can also be used by designers to reduce their overall SoC power consumption. Pegasus enables better memory efficiency resulting in lower power consumption by removing unnecessary look-ups and making intelligent decisions on managing, optimizing, and accessing memory. A configurable LLC can be tailored to the specific characteristics of the DDR controller and can augment the optimizations of the controller by making smart decisions within the LLC.

Additionally, LLC RAM banks are relatively easy to selectively power down. Pegasus allows runtime configuration of the LLCs to enable designers to selectively shut down all or part of the LLCs when the SoC goes into low-power mode. This feature can be exploited to squeeze out the last bit of spare power in the system.

So, to summarize, NetSpeed’s LLC is not a simple L3 cache. If you are building complex SoCs with a heterogeneous mixture of coherent and non-coherent IPs, the use of NetSpeed’s Pegasus LLC IP can help you to buffer and smooth out conflicting NoC traffic, eliminate memory bottlenecks, boost overall system performance, reduce traffic-dependent latencies, improve overall memory efficiency and reduce overall system power. That’s a whole lot of functionality for one IP.

See also:
NetSpeed Pegasus product web page
NetSpeed Gemini product web page
NetSpeed Orion product web page

Posted on

Airliners without Pilots

Airliners without Pilots
by Matthew Rosenquist on 07-16-2017 at 10:00 am
Categories: AI, Security
8 Comments

Boeing will begin testing pilotless jetliners in 2018. Yes, the future of air travel may include planes without pilots. Just computers and calculations to get passengers safely to their destinations. Advances in Artificial Intelligence (AI) is opening up possibilities to make flying safer, more consistent, easier to manage, and cost efficient.

“the basic building blocks of the technology clearly are available ,”said Mike Sinnett, Boeing’s vice president of product development.


Automation and Safety
Planes already are under the control of computers most of the time. They can take off, fly to their destination, and even land in semi-automatic modes. The question is not if it is technically possible, but rather would it be safe in all situations where risks of safety to passengers arise. It is not about the 99% of flight time, but rather those unexpected and unforeseen moments when snap decisions are required to keep the passengers safe.

Not too long ago, Captain Chelsey Sullenberger made a miraculous effort avoid disaster when a flock of geese struck his plane shortly after takeoff. He was able, against serious odds after the engines were rendered ineffective, to avoid populated areas of New York city and glide the plane to a safe landing on the Hudson River. The pilot saved 150 passengers and potentially countless people on the ground.

Cybersecurity Factors
Autonomous planes, carrying passengers, flying with significant force, and carrying tremendous amount of highly flammable fuel may be a prime target for certain cyber threats. Total control would be the ultimate goal, but even the ability to disrupt operations may be sufficient to cause horrendous loss. As a result, autonomous flight development will be a huge test for AI security fundamentals, integration, and sustainable operations. AI controlled airborne transport vehicles is an admirable goal with significant potential benefits for all, but the associated risks that must be overcome and maintained consistently over time are mind boggling.

Consider this: a malicious actor taking control of an AI controlled car could cause a handful of deaths. Taking over an AI controlled plane can result in situations like 9/11 where thousands of people die, many more are injured (short and long term), and most importantly sending an indelible message to an entire society that strikes a chord of long-lasting fear. Every day there are tens of thousands of flights occurring in the skies above. Aside from the passengers at risk, each one could be used as a weapon against targets on the ground.

The business risks are equally severe. It could crater a plane manufacturer, if such a situation manifested and one or more of their planes were hacked and intentionally brought down. The viability of the plane manufacturer or airline company would cease to exist.

The Fallible Control
Personally, I like humans in the loop. There is no doubt people are fallible, unpredictable, and inconsistent. Which, from a cybersecurity perspective, they can be tough for an attacker to anticipate. The very weakness humans bring to complex systems is ironically a safety control against malicious attackers.

Then there is the fear factor. A flesh and blood pilot has a committed stake in the safety of the plane, passengers, and themselves. It is their lives at risk as well. Under pressure, humans have a remarkable ability to adapt and overcome when facing unexpected or new situations that put their mortality in the balance. I am not sure that concept is something that can be programmed into a computer.

We are entering the age of AI. It will bring with it enormous benefits, but humanity still has a lot to learn when it comes to deciding the proper role and trust we will place in digital intelligence. Large scale human safety may be one of those places where AI is better suited as an accompaniment to human involvement. Such teamwork may bring the very best of both worlds. We are learning, just as we are teaching machines. Both human and AI entities still have a lot to discover.

Interested in more? Follow me on LinkedIn, Twitter (@Matt_Rosenquist), Information Security Strategy, and Steemit to hear insights and what is going on in cybersecurity.

Posted on

Standard Node Trend

Standard Node Trend
by Scotten Jones on 07-15-2017 at 4:00 pm
Categories: FinFET, Foundries, GlobalFoundries, Intel Foundry, Samsung Foundry, TSMC
31 Comments

I have previously published analysis’ converting leading edge logic processes to “standard nodes” and comparing standard nodes by company and time. Recently updated details on the 7nm process node have become available and in this article, I will revisit the standard node calculations and trends.

Continue reading “Standard Node Trend”

Posted on

Why Embedded FPGA is a New IP Category?

Why Embedded FPGA is a New IP Category?
by Eric Esteve on 07-14-2017 at 12:00 pm
Categories: eFPGA, FPGA, IP, Menta

Yes, embedded FPGA is clearly an IP function, or design IP, and not a software tool or anything else. The idea to embed an FPGA block into an ASIC is not new, I remember the discussions we had in the ASIC marketing team when I was working for Atmel, back in 2000. What is new is the big interest for eFPGA in the semiconductor industry, even if a company like Menta is now 10 years old and propose today the 4th version of their eFPGA product.

We can see two main approaches for the eFPGA offering: The first comes from an FPGA vendor, who decide to “cut” an FPGA block in a standard FPGA product and deliver this as a FPGA IP. The other approach is to design from scratch a family of eFPGA IP, all based on the same architecture but of various size. In the first case, the FPGA block will be based on cells designed specifically to build the FPGA parent product, or full custom cells. Full custom cells have been designed using the design rules of a specific technology node developed by a specific foundry. If your design targets this precise node and this precise foundry, no problem. Now, when the eFPGA block has been designed to be an IP, it also can be based on full custom cells targeting a specific node/foundry, but not necessarily.

Menta has taken another approach, design their eFPGA IP based on standard cells. Obviously, the design is still linked with a specific node/foundry, but we will see how it makes a difference when the ASIC embedding the eFPGA IP targets a different node/foundry.

Let’s have a look at the numerous benefits offered by the integration of an eFPGA IP into an ASIC, compared with an ASIC based solution, an FPGA based solution, or a mixed of two, ASIC plus FPGA standard product.

The pure ASIC solution will always be the less expensive, offering higher performance and lower power consumption. But, if you need flexibility, to support evolving standard or to adapt neural network algorithms after running a learning phase, to take a few examples, you would need to re-spin the ASIC. Re-spin is just prohibitive, in terms of development cost and Time-to-Market. OK, let’s go to an FPGA solution!

The FPGA technology is fully flexible as the device is (infinitely) re-configurable and this is one of the reasons why FPGA have been widely adopted in networking or communication (base stations) applications, to name a few. This flexibility is not for free, in term of power consumption and device cost. The device configuration, including internal interconnections, is usually loaded at start-up in SRAM memory, leading to an extra power consumption on top of the internal logic. Some FPGAs are supporting very complexes applications, leading to high power consumption… and high device ASP, several $100’s, if not $1000’s.

That’s why it could be a good option to integrate the stable logic functions into an ASIC and complete the design with a smaller FPGA. This solution will probably lead to a cheaper total cost of ownership, especially if the ASIC maybe be reused from a previous generation. In this case, one drawback may come from the power dissipated in the interfaces between the ASIC and the FPGA, usually multiple I/Os based on high speed SerDes (10 Gbps) to support the high bandwidth requirement of networking or data center. The other drawback is probably the total cost of the two devices.

Now, if your architecture is based on a large ASIC plus a companion FPGA, needed to bring flexibility, you should consider the embedded FPGA solution. When the FPGA logic is embedded in the SoC, the communication between the eFPGA and the SoC is made through internal signals with two main consequences. At first, you may use as many signals to interface the eFPGA, as you are no more limited by the chip size (I/O limited FPGA). But the most important gain is the much lower power consumption of internal signaling compared with external I/O, function of the capacitance. To evaluate the cost benefit, you will need to think in term of total cost of ownership, adding the IP license price to the SoC NRE, as well as the royalty paid to Menta, but I am sure that in 95% of the cases, this single chip solution cost will be lower than the SoC plus FPGA.

Let’s come back to the eFPGA technology and evaluate the impact of the selected vendor on the Time-to-Market. The eFPGA IP from Menta is unique, and for two reasons: the FPGA logic is based on standard cells and not on full custom designed cells, and the FPGA configuration is stored in registers instead of SRAM. To design an eFPGA block on a specific node, Menta is using pre-characterized, validated cells, even if the IP is delivered as a hard macro (GDSII) to guarantee the timing and functionality in any case.

If a customer, for any reasons, has to target a technology node (or a foundry) where the Menta eFPGA is not yet available, the process is simple. Menta must port the IP, using already validated cells, on the new node, and run IP qualification. If you compare this process with a complete redesign and qualification of all the full custom cells to port the eFPGA IP, and IP qualification, no doubt that the Menta approach is offering a faster Time-to-Market when selecting a new node/foundry. And safer as well, as the risk is minimized when using standard cells.

As far as I am concerned, I really think that the semiconductor industry will adopt eFPGA when adding flexibility to a SoC is needed. The multiple benefits in term of solution cost and power consumption should be the drivers, and Menta is well positioned to get a good share of this new IP market.

From Eric Esteve from IPnest

Posted on

Checking Clock Gating Equivalence the Easy Way

Checking Clock Gating Equivalence the Easy Way
by Bernard Murphy on 07-14-2017 at 7:00 am
Categories: EDA, Synopsys

Synopsys just delivered a Webinar on using the sequential equivalence app (SEQ) in their VC Formal product to check that clock-gating didn’t mess up the functional intent of your RTL. This webinar is one in a series on VC Formal, designed to highlight the wide range of capabilities Synopsys has to offer in formal verification. They are obviously determined to have the design world understand that they are a serious contender for the formal verification crown (see also my write-up on their InFormal Chat blog).


I’ll deal with some basic questions first because I’ve heard these questions from at least some designers and others around semiconductor design who need some understanding but don’t need the gory details (sales, marketing, support, …). Starting with the easiest – why gate clocks? Because that’s a good way to reduce dynamic power consumption. Every power-sensitive design in the world gates clocks, to extend battery life, to reduce cooling costs, for reliability or for regulatory reasons.

That was a softball; answering the next question takes a little more thought. I use Power Compiler which allows me to infer clock gating from the RTL structure along with a little guidance from me to hint that it should insert clock gating here but not there). So I can let the tool take care of inserting the right gating logic. But I’m careful to check that synthesis didn’t make any mistakes so I use Formality Ultra to do equivalence checking between the original RTL and the generated gates. Formality Ultra will check the correctness of inserted clock gating along with correspondence of Boolean logic between the RTL and the gates. So why do I need a different tool to check clock gating equivalence?

I confess this also had me a bit puzzled until I thought about it harder and checked with Sean Safarpour at Synopsys. The flow I described above works fine for basic clock gating but there are reasons many design teams want to go beyond this capability, which require them to do their own clock gate insertion.

An important reason is that a lot more power can be saved if you are willing to put more thought into where you gate clocks. Automated gating is inevitably at a very low level since it looks at low-level structures around registers or register banks for opportunities to transform logic to add clock gating. This may still be valuable in some cases as a second-order saving but gating a larger block of logic can often save more power, and at lower area cost. As an obvious example, gating the clock on an IP block can disable clock toggling in the entire block at a cost of just one clock gate structure. This also shuts off toggling in the clock tree for that block, which is important since clock tree toggling contributes significantly to total dynamic power. Whether this is a workable option or not requires design use-case understanding to construct an appropriate enable signal so this is not automatable, at least today.

The other reason is that clock gating is part of the functional realization of your design so must necessarily be included in the verification plan. If clock gating is inferred in synthesis and therefore first appears in the gate-level netlist, that implies some part of your verification plan will have to be run on that gate-level netlist, which is not an attractive option for most of us.

So given you want to hand-craft clock gating in your design, VC Formal SEQ can help by formally comparing the pre-instrumented RTL netlist (before you insert clock gating) with the instrumented RTL netlist to verify that the two RTLs are functionally equivalent (apart, of course, from the fact that one allows for clock gating and the other doesn’t). The webinar walks you through the essentials of the flow – compile, initialization, solving and debug in Verdi where you can compare pre- and post-instrumented designs through generated waveforms and temporal flow diagrams for mismatch and un-converged cases.

Since this is sequential formal proving, there’s always the possibility of non-convergence in bounded proof attempts. It looks like Synopsys has put quite a bit of work into simplifying analysis in these cases. One such example is in building internal equivalence points in hard problems, helping you to reduce what remains to be analyzed to simpler problems or to see where changing effort level, or a little help with constraints or some blackboxing might bring a proof to closure. All this analysis and debug is naturally supported through the Verdi interface.

You can watch the webinar for the real details HERE.