SemiWiki – Page 390 – The Open Forum for Semiconductor Professionals

June 21, 2020August 20, 2020

Uber: Pariah to Paragon

Uber: Pariah to Paragon
by Roger C. Lanctot on 06-21-2020 at 8:00 am
Categories: Automotive

For years, the lords of Lyft and Uber have declaimed their intention to vanquish car ownership and displace public transportation. It really was as simple and as blunt as that. For sure there would be collateral damage including rental car companies and taxi operators and millions of under-compensated drivers – but the bottom line was crush, kill, destroy.

It was a simpler time when taxi operators hated Uber and Lyft (and their ilk) as did airports, cities, and rental car companies. All the while, Uber soaked up billions in fares and force fed those fees into software development focused on optimizing routing and logistics resulting in a trove of patent filings and, in a remarkable turning point for the company, the signing, this week, of a public transport agreement with Marin County in California.

In about a decade’s time Uber has transformed from transportation industry pariah to potential panacea. Uber has made peace with airport operators who have created massive dedicated ride hailing pickup areas transforming traffic flows at airports around the world. And Uber has co-opted taxi operators as sub-contractors in multiple markets where regulations required this shift.

Cities, too, have turned to Uber (and other operators) to serve areas under-served by existing mass transit options either chronologically or temporally – the buses can’t run all night long, after all. In fact, Uber has recast its messaging around transit painting itself as a supportive partner.

From Uber’s Website: https://www.uber.com/us/en/community/supporting-cities/transit/

“Ridesharing can not only help people get to their nearest transit stop but also:

Fill in gaps in existing public transit service
Provide access to underserved communities
Alleviate the demand for parking
Reduce costs of underused routes or services”

This is a very different song for Uber. It raises the stakes. In fact, it changes the game.

The Uber app’s reach, familiarity, and ease of use for both booking and paying are able to overcome multiple pain points for public transit operators. Uber has integrated public transportation options within its app in multiple cities around the world but the Marin County deal is unique.

Uber (and other ride hailing operators) has built their market capital on their ability to rapidly consolidate local ad hoc transportation activity in the form of millions of rides and billions of dollars creating overwhelming clout with adjacent service providers – such as public transit and airports.

In Marin County, Uber will manage rides for public minibuses – leveraging the Uber platform’s ability to match riders travelling in the same direction. Rides will cost $4 per mile, or $3 for those with disabilities or other mobility issues, with the fee going directly to Marin Transit. Uber will not collect a commission, instead charging the authority a flat monthly rate for the next two years, totaling no more than $80,000 over that period, according to terms reported by the Financial Times.

This first deal appears to be a camel’s-nose-under-the-tent proposition and marks a critical turning point as cities around the world emerge from lockdown fearful that their public transportation systems will be permanently and negatively impacted by COVID-19 concerns among normally reliable riders. Transit operators have tried, with mixed success, to foster their own app-based transit access.

Integration with Uber – or other regional ride hailing companies – now appears to be an essential element to expanding ridership – while re-opening and recovering from the COVID-19 outbreak.

Uber, of course, has taken matters further by taking on the back end routing and logistics in Marin County – not normally a strength of local transit operators. Uber is uniquely adept at managing the integration of ad hoc and scheduled transportation services.

Uber can put to work its network effect to help cities optimize public and private transit options. There are multiple ironies in the effort as it will simultaneously draw transit users to the Uber app and Uber users to transit. In all likelihood both Uber and transit operators will benefit.

The Marin County deal has the potential to upend Uber’s original nihilistic approach of laying waste to all non-Uber transportation alternatives. It also has the effect of signaling to Google, HERE, Intel/Mobileye (which recently acquired transit app Moovit), and regionally dominant ride hailing operators – Grab, Gojek, Gett, DiDi Chuxing, and Yandex – that this is the new path forward.

It further sets the stage for Uber and its like to capture the mobility-as-a-service flag with integrated transportation options, payment, logistics, and, as in Marin County, the back-end systems. All those years that taxi operators, rental car companies, airports, and cities were crabbing and complaining about Uber’s disruptive and sometimes illegal activities, the company was laying the foundation to fundamentally transform and take charge of transit networks – maybe.

It’s no wonder that Uber is fighting strenuously against Los Angeles’ Mobility Data Sharing initiative. It’s clear now that Uber’s crown jewels are its patents and logistical knowhow – and its data. It’s also clear that the key to managing urban transit lies in data – and ride hailing operators around the world are decoding cityscapes every day.

Uber is battling MDS on privacy grounds, but the battle for ownership and control of data is more existential for cities and for ride hailing operators. What is shaping up is a war over the hearts, minds, and wallets of the travelling public. Uber brings a tattered reputation to the battlefield, but it is important to understand that the one-time pariah is increasingly seen as a paragon of transit virtue.

June 19, 2020April 20, 2022

DVCon 2020 Virtual Follow-Up Conference!

DVCon 2020 Virtual Follow-Up Conference!
by Daniel Nenni on 06-19-2020 at 6:00 am
Categories: Accellera, EDA, Events, Semiconductor Services

As most of you know DVCon 2020 was our first conference to be cut short by the Pandemic. SemiWiki bloggers Bernard Murphy, Mike Gianfagna, and I were there with full schedules but at the last minute it was called off. It really was an eerie feeling, the emptiness of it all.

The rest of our EDA live events followed suit and went virtual which is the new normal. A nice thing about virtual conferences, like webinars, is that you can go back and watch the replays as time permits and that is exactly what DVCon has done for all interested parties (for a limited time).

The program has been available to registered attendees exclusively from May 26 – June 16 and will open to the public from June 17 – August 14.

“I’m thrilled that we are continuing the 2020 program online with many of the presentations that were unable to be presented during the live conference,” stated Vanessa Cooper, DVCon U.S. Technical Program Committee Chair. “Due to the rapidly evolving environment at the onset of the conference, we were able to pivot the live program quickly and compress if from four days to three, but that still left many without the benefit of the informative, technical material. I’d like to thank the technical program committee for continuing its efforts and coordinating with the presenters to record some of their papers, posters, tutorials and short workshops for this on-demand experience.”

Each session provided registered attendees with the ability to post publicly viewable questions to a forum that were answered by presenters throughout the first three weeks of the online experience. The forums are no longer active but you can still see the Q&A, which quite frequently is the best part, absolutely.

DVCon is sponsored by Accellera Systems Initiative (Accellera) which has a dedicated landing page on SemiWiki HERE.

Please visit the DVCon U.S. 2020 virtual conference website for program details and to access the virtual conference.

Save the date: DVCon U.S. 2021 will be held March 1-4.

About DVCon
DVCon is the premier conference for discussion of the functional design and verification of electronic systems. DVCon is sponsored by Accellera Systems Initiative, an independent, not-for-profit organization dedicated to creating design and verification standards required by systems, semiconductor, intellectual property (IP) and electronic design automation (EDA) companies. For more information about Accellera, please visit www.accellera.org. For more information about DVCon U.S., please visit www.dvcon.org. Follow DVCon on Facebook https://www.facebook.com/DVCon or @dvcon_us on Twitter or to comment, please use #dvcon_us.

Also Read:

Accellera Tackles Functional Safety, Mixed-Signal

Functional Safety Comes to EDA and IP

Accellera IP Security Standard: A Start

June 18, 2020August 20, 2020

Talking Sense with Moortec: Staying on the right side in worst case conditions – Power (Part 1)

Talking Sense with Moortec: Staying on the right side in worst case conditions – Power (Part 1)
by Tim Penhale-Jones on 06-18-2020 at 10:00 am
Categories: IP, Moortec

In this first part of a 2-part blog series, we look at defining worst case conditions, focusing specifically on device power.

With great power, comes great responsibility…

With each new technology node especially FinFET, the dynamic conditions within a chip are changing and becoming more complex in terms of process speeds, thermal activity and supply variation. Dennard Scaling brought about the ability for power to be scaled down with each successive node so that power per unit area stayed roughly constant. However, as highlighted b y John Hennessy at last year’s AI Hardware summit, since the mid-2000s this is no longer the case and we have seen the steady increase in power density per unit silicon area. Hennessy made the point that with Dennard scaling ending and Moore’s Law slowing down, transistor power and costs were no longer heading in the right direction and there’s no free ride for future performance just from process developments.

Worst case is getting worse!

What this means, is that chips have the propensity to run hotter and in-chip voltage drops are getting bigger. These two factors of increased process variation and the end of Dennard Scaling combine to mean the worst case is definitely getting worse! In addition to worst case performance which we will cover in the second part of this blog, SoC designers are being forced to focus on worst case power and voltage drop scenarios. To address these issues, it is no coincidence that the majority of FinFET SoC designs include a fabric of sensors for in-chip process, voltage and temperature monitoring.

Worst case power is not just about the maximum power dissipation although that is naturally a good starting point. It is also about bursts of activity which cause temperature cycling and power differences which cause temperature gradients across the chip. FinFET processes require particular attention for potential hotspots as not only do they offer fantastic logic densities with the associated increased power per unit area, but their 3D fin type structures are not great at dissipating heat. Ideally, strategies need to be implemented to reduce maximum hotpot Tj (junction temperatures), as these impact lifetime and leakage current, they are also needed to reduce temperature gradients and cycling which impacts reliability. The trend with very large FinFET SoCs is to embed tens of temperature sensors to monitor potential hotspots around the chip, or alternatively, to use the recently launched Distributed Thermal Sensor (DTS) from Moortec.

Strategies employed for thermal management range from simple thermal cut–off where some, or worst case, all of the circuitry is switched off or ramped down if a certain temperature is reached, to more sophisticated DFS and DVFS schemes where the operating point and power in terms of clock frequency and supply voltage can be controlled and dropped to a lower level. Thermal load balancing involves allocating up-coming tasks to processors based on the level of their free processing capacity and their temperature. In all these cases an accurate temperature sensor provides the benefit of delaying the point at which action needs to be taken and therefore ensuring maximum processing power is maintained as long as possible. Less accurate temperature sensors require a larger temperature guard band (Check out our previous blog to learn more) which means for AI chips the processors will be switched off or to a slower throughput mode, at an earlier time and that’s not good for AI.

Associated with worst case power are worst case currents which cause IR voltage drops on chip. Particularly difficult to predict in advance are changes in voltage drops due to step changes in workload. The large SoCs are invariably software driven, but how the end customer will program these chips and how their worst case workload profile looks, is not always clear. Including voltage and temperature monitors on–chip especially for critical blocks gives visibility of the on-chip conditions and how these change with different workload profiles.

Multiple potential hotspots & temperature gradients ?

SoC development teams are faced not just with resolving traditional worst case timing issues but also worst case power. The latter can lead to multiple potential hotspots, temperature gradients and also difficult to predict voltage drops across large SoCs. Embedding a fabric of accurate in-chip monitors on SoCs provides excellent visibility of on-chip conditions.

This is seen as an essential tool for bring up, characterization and optimization on a per die basis especially for SoC development teams who are pushing the limits on advanced FinFET nodes but who want to stay on the right side in worst case conditions. As the old saying goes…’with great power, comes great responsibility’ and this is certainly the case when it comes to managing power conditions on advanced node devices.

Look out for the second part of this blog series entitled “Staying on the right side in worst case conditions – Performance” which will be available early July, where we will look at defining the worst case in terms of chip performance where timing analysis is key!

June 18, 2020August 20, 2020

The Moving Target Known as UPF

The Moving Target Known as UPF
by Tom Simon on 06-18-2020 at 10:00 am
Categories: EDA, Siemens EDA

As if engineers did not have enough difficulty just getting everything right so that their designs are implemented functionally correct, the demands of lowering power consumption require changes that can affect functionality and verification. Techniques such as power gating, clock gating, mixed supply voltage, voltage and clock scaling are commonly used to reduce dynamic and static power consumption of ICs. Each of these methods require changes to the design in ways that can affect functionality. Thus power reduction methods must be something that can be specified and even more importantly verified, both in the context of whether they work correctly but also such that they do not adversely affect chip operation.

Starting back in 2006 the IEEE took on the challenge of providing a standard to help the process of reducing power consumption with their IEEE 1801 specification. The first version of IEEE 1801 also known as the Unified Power Format (UPF) specification was published in 2007. It would be nice to say that this specification worked perfectly and remains little changed to this day. Sadly, the industry has encountered a steep learning curve regarding what makes an optimal power specification format. Commensurate with this, adoption of 1801 has been chronically low. To deal with issues in the 1.0 version, the 2.0 version followed fairly quickly in 2009.

Each newer versions of IEEE 1801 has worked to improve the specification. Usability, clarity and ambiguity have all be improved. The latest version is 3.1. It differs from the previous versions in both syntax and semantics. The challenge for designers today is that IEEE 1801 is used in design specification, power analysis and implementation tools, as well as in functional implementation and verification tools. In short, there are a lot of touch points for IEEE 1801. Things get messy when among the tools used in the flow engineers encounter support for differing versions of the spec.

But it gets worse, legacy designs may have used earlier versions, muddying the question of which version to use across a new design. Likewise, externally sourced IP, which may be a black box, might lack visibility or insight so that IEEE 1801 can be used effectively. Optimistic designers might hopefully wish that UPF directives such as “upf_version” will help to sort things out. However, “upf_version” is really only a suggestion to tools indicating what syntax was used to write the directives. It by no means is a get out of jail card for designs built with earlier versions.

There is some help in the form of useful guidance in a white paper written by Madhur Bhargava from Mentor, a Siemens business, where many of the key differences between the versions are discussed and strategies for dealing with them are offered. The white paper, titled “UPF 1.0, UPF 2.0, UPF 2.1, UPF 3.0, and now UPF 3.1: Which is the right design standard for my design?”, helps by offering some clarity to the changes over time.

First off the paper gives its own summary of the evolution of UPF. There is a discussion on the newest UPF 3.1 that goes over the most important changes and provides historical context regarding the reason for the changes and previous handing, if any, of the issue being addressed. The paper has a detailed section on backwards compatibility, which necessarily covers both syntax and semantics – and they do need to be addressed both individually and together. While this is not light reading, and one could hope that in the end there was an easier story to tell, it is fortunate that major progress has been made and much learned. Anyone contemplating using UPF should read through this paper, as it offers a lot of useful information in one place in a well-organized format. If you are interested, the paper can be downloaded from Mentor’s website.

June 18, 2020August 20, 2020

Cruise Controlling Its Destiny

Cruise Controlling Its Destiny
by Roger C. Lanctot on 06-18-2020 at 6:00 am
Categories: Automotive

The Information tells us that General Motors’ Cruise Automation self-driving car unit has acquired automotive radar maker Astyx. The move can be seen as a simple defensive move to preserve access to valuable radar technology along the path to realizing Cruise’s vision of a robotaxi infused future.

There are a variety of of wrinkles to this acquisition – with a veritable Shar Pei of implications for GM, for Cruise, and for the autonomous vehicle world. There are three key elements underlying the financial aspects of the deal – the specifics of which have yet to be acknowledged, disclosed or confirmed – cash on hand, valuation, and market cap.

Thanks to investors such as Honda and Softbank, Cruise has $5B-$6B to burn – and burn it will at upwards of $250M/quarter. Cruise’s valuation, following the latest round of investment, stands at $19B. This compares to GM’s market cap of $39B, Waymo’s valuation of $30B, and Alphabet’s market cap of $1T.

It is amusing to ponder the prospect of Cruise’s valuation potentially exceeding GM’s market cap. I have an image in my mind of Cruise founder and president Kyle Vogt, just back from running seven marathons on seven continents in seven days (look it up), strolling into GM CEO Mary Barra’s office and “telling her how it’s going to be” at GM now that he owns the place.

Don’t hold your breath for that.

Cruise is playing a high stakes game of chicken in its pursuit of the autonomous driving Holy Grail. It must maintain its valuation, while steadily making progress toward an actual value-creating proposition, while burning massive amounts of cash…but not TOO much. To that end, Cruise announced layoffs recently which were thought to include personnel from the prior acquisition of Strobe – a Lidar supplier.

The most notable aspect of the Astyx acquisition is that it is a purchase that GM itself would have never made – in a million years. Car makers typically prefer not to take possession of their suppliers. Car makers prefer to have smaller suppliers, such as Astyx, partner with existing so-called “Tier 1” suppliers. In fact, Astyx has existing relationships with ZF, Hella, Autoliv, and Nvidia.

In the race to autonomy, though, acquisitions of this sort are common as AV developers seek to own and protect their “software stack” – the core of their AV solution. Typically, though, these acquisitions have occurred at the Tier 1 level with acquirers such as Continental, Bosch, and Aptix, while car makers have made select “investments” or engaged in partnerships.

While the Cruise move on Astyx may bave been defensive, such acquisitions have an offensive nature as well. The Cruise/Astyx deal may disrupt some competing AV developers that have been working with Astyx. They may be forced to rethink those relationships. For Cruise, though, taking possession of Astyx’s development team might help accelerate Cruise’s progress toward autonomy.

In spite of Mary Barra’s frequent claims that Cruise is on track to meet its goals and hitting its milestones – the reality appears to be something quite different. The latest announcements surrounding the much-heralded Cruise Origin robotaxi entering production in 2022 suggests a timeline shifting inexorably into the future – as has happened at most other OEMs and independent developers working in the space.

The odds are as long as the stakes are high in the game that Cruise is playing. I still remember running into Waymo CEO John Krafcik on the floor of the Geneva International Motor Show three years ago where he noted that Cruise was racking up hundreds of thousands of miles on city streets while Waymo was notching millions of miles on highway, surface, and city streets.

The issue is critical to determining which approach to autonomy will scale the most rapidly. Waymo has made clear its long-term intention to offer an autonomous driving “kit” to makers of all types of vehicles operating in a wide range of environments while continuing to operate its own nascent all-purpose autonomous driving solution. Cruise appears to be committed exclusively to the robotaxi path.

The outlook for robotaxi development is grim. Even assuming Cruise is successful, at the end of the day it will have mastered San Francisco after years of development work. How much time, effort, and money will it take to tackle Los Angeles? New York? Shanghai?

The acquisition of Astyx could set the stage for a Cruise shift toward a more Waymo-like operational capability encompassing urban and highway operation. If so, it probably would make sense to abandon the Cruise Origin entirely.

If Cruise is bent on taking on highway driving, though, it will run headlong into GM’s in-house Super Cruise development efforts which are proceeding on an entirely parallel path with little or no cross pollination. GM’s Warren Tech Center team and Cruise are pursuing completely separate hardware and software stacks with very different visions of value creation. Only the GM in-house team has crossed the threshold into mass production.

Whether offensive or defensive, the Astyx acquisition does not appear to measurably advance the cause of vehicle automation in the short-term, nor does it appear to alter Cruise’s strategic plans either to expand its operational domain or to shift its go to market strategy to a Waymo-style AV kit approach. But if Cruise intends to maintain or enhance its current valuation it needs to show measurable progress in 2020.

The Astyx acquisition may simply reflect Cruise taking advantage of diminished post-COVID-19 valuations, and a minority Astyx shareholder’s (ZF) need for cash, to add to its development team and provide its own internal stimulus. It won’t fix a flawed business model. So Cruise may be in control, but it won’t wag the dog.

June 17, 2020January 12, 2021

Cadence Adds “Always On” to vManager Verification Management with Distributed and Cloud Access

Cadence Adds “Always On” to vManager Verification Management with Distributed and Cloud Access
by Mike Gianfagna on 06-17-2020 at 10:00 am
Categories: Cadence, EDA

Cadence vManager™ Verification Management provides what the company describes as metric-driven signoff. Anyone who has been through the tapeout process for a complex SoC knows the perils of verification sign-off. How much of the chip has been verified? What’s left to do? Will all be ready when the tapeout deadline arrives? In a prior life, I mused that chip verification was done when time ran out. Today, one can do a lot better than that with the available technology from companies like Cadence.

I recently had the opportunity to speak with Matt Graham at Cadence about the vManager platform and the recent enhancements that have been added. Matt is a product engineering director for vManager. He’s been with Cadence for over 15 years and spent time at Nortel, AMCC and Verisity before it was acquired by Cadence. Matt knows a lot about chip verification and how to automate it.

He started by taking me on a tour of the vManager platform. With the goal of helping customers verify smarter, this platform aims to enhance predictability, productivity and quality for chip verification. Think of it as a way to collate and manage the massive data from all the verification tasks applied to a typical SoC. Formal analysis, software simulation, hardware emulation and FPGA prototyping all generate a lot of information.

The vManager platform analyzes and abstracts this information to create a clear picture for the design team regarding where they are in the verification process. Verification requirements are coordinated with design intent to assess functional and code coverage. This allows informed decisions to be made, which results in superior quality and tighter schedule performance. The figure below provides an overview of the data sources and analysis regimes of the vManager platform.

The current architecture of the platform manages the significant data volumes with a client/server SQL database in a centralized configuration. This architecture works great for an IP level team all located in the same location. As the need to scale to larger, more distributed teams increases, the scale (30 projects and 100 users) and locality limitation of a single server starts to become a concern. The lack of fault tolerance also makes the system a potential single point of failure – a difficult situation when tapeout is fast-approaching.

Cadence has addressed these issues with the addition of a high availability proxy server that provides load balancing and resilient routing. Proxy servers and server agents work together, resulting in a scalable and high-availability environment that delivers fault tolerance. Both public and private cloud environments are supported. The figure below provides an overview of the new architecture.

This architecture supports multi-region capability, allowing design teams to manage regressions across regions and into the cloud with a single server. Every project has a complex geography overlay so this is a key feature. All the data at each location is linked to provide good oversight.

Matt summarized our conversation by pointing out that this new architecture provides greater predictability, productivity and quality with better scalability, improved reliability, tighter collaboration for dispersed design teams and lower maintenance. This enhancement provides a lot of benefits.

Cadence supports a comprehensive upgrade program for these new features, so if you’re a vManager customer contact your Cadence salesperson to find out how to unlock all these new benefits.

June 17, 2020April 14, 2022

Where’s the Value in Next-Gen Cars?

Where’s the Value in Next-Gen Cars?
by Bernard Murphy on 06-17-2020 at 6:00 am
Categories: AI, Arteris, Automotive, IP
6 Comments

Value chains can be very robust and seemingly unbreakable – until they’re not. One we’ve taken for granted for many years is the chain for electronics systems in cars. The auto OEM, e.g. Toyota, gets electronics module from a Tier-1 supplier such as Denso. They, in turn, build their modules using chips from a semiconductor chip maker such as Renesas, who produces their chips using pre-packaged functions from IP providers like Arm. Toyota could do the whole thing themselves, but it’s very expensive to set-up and maintain all of that infrastructure. Specialization makes it all more practical. Everyone makes money doing their bit well and cost-effectively and being able to sell to multiple customers (Toyota, GM, BMW, etc.).

However, that cash flow can be upended when disruptive innovations are thrown into the supply chain, in this case, a lot more intelligence and autonomy. I talked to Kurt Shuler (VP Marketing at Arteris IP) to get his view. Kurt is an IP supplier and has a unique viewpoint because he works with semis, Tier-1s and OEMs, with standard designs as well as newer AI-based designs. He’s also an active member of the ISO 26262 committee.

Value Chain Shifts

Kurt’s view is that there’s a lot of shifting ground in the supply chain, especially between the Tier-1’s and car manufacturers. More and more, the value in the car depends on intelligent electronics, which changes the stakes. For those who want to grab a bigger share, growth beckons and for those who don’t, margins erode. They may become an automotive Foxconn. Everyone is staking out territory, whether grabbing a piece of a neighbor’s turf or grabbing a lot, or all like Tesla. Tesla used to depend on NVIDIA and Mobileye, now they’re doing the whole thing themselves.

On the semiconductor side, you have an NXP or TI who gives you a board support package, maybe a reference board and a software development kit. With these ingredients, a company can create its own solutions. Grabbing for more are companies like Mobileye who are responsible for a full system, ship, boards and software, though they customize these based on Tier-1 requirements.

The Value of Data

There’s also a soft value – the data gathered by all those intelligent systems. That data has immense value in helping refine training for (SAE) level 3 guidance and up, and for improving the overall user experience. Tesla owns all the data its cars generate, including images of bystanders, a point which has raised some privacy concerns (though we consumers generally seem to have a meh reaction to privacy debates). Mobileye similarly owns all the data its systems generate, though it shares that data with the Tier-1 and OEM. One reason the Tier-1s and OEMs are so eager to get into owning chip architectures is so they can have exclusive rights to that data.

This crowd-sourced learning has immense potential value. One of the biggest challenges in getting higher levels of autonomy is getting enough training across enough conditions. Even data captured in non-self-driving mode has value. No wonder Musk doesn’t want to let go of this asset – building on that training will push closer and closer to a self-driving reality. Whoever gets there first may own the future of mobility. Tesla wants to lap everyone else on the track, to be so far ahead on the data that no-one else can catch up.

However, Tesla still has a small customer base. Mobileye has a similar vision but they’re more integrated into the automotive value chain. They’re working with the incumbents and have a good lead because they were first in class in deploying these systems. Kurt sees a couple of big wild cards: GMC Cruise and Bosch. Cruise is trying to do a Tesla, starting behind certainly, but they have volume manufacturing and maintenance expertise on their side, where Tesla will be far behind. Bosch has design teams in Germany and Sophia Antipolis (tech area in the south of France, known for TI OMAP, Apple, Arm and other top-notch chip architects, aside from being spectacularly beautiful and, you know, being in the south of France).

All in all, several big players are acting very much like this is a winner-take-all market. Some of that is on differentiation in chips. But a lot more is on the data – controlling your data. Tier-1s and car companies are throwing a lot of money at this, like a few hundred million dollars is no big deal, to assemble their fortresses.

Still, they’re not quite as flush with cash as the hyperscalars (Google, Apple, Amazon, Microsoft, etc.). Kurt speculates that at some point, this may settle down to some kind of mashup between those guys and the automotive value chain. Meantime we’ll no doubt be trying to figure out if we even want personal cars anymore and if not, what service or combination of services is going to provide us a similar level of mobility. Stay tuned.

Also Read:

Design in the Time of COVID

AI, Safety and Low Power, Compounding Complexity

That Last Level Cache is Pretty Important

June 16, 2020January 27, 2022

Fractal CEO Update 2020

Fractal CEO Update 2020
by Daniel Nenni on 06-16-2020 at 10:00 am
Categories: CEO Interviews, EDA, Events, Fractal Technologies

Rene Donkers, the company’s Co-founder and CEO, started his EDA career at Sagantec where he became responsible for world wide customer support and operations management. Ten years ago, Rene and a handful of people noticed a need in the design community for a standardized (portable) IP Validation approach to replace internal solutions, and thus Fractal was founded with Rene as the CEO.

What do you think is the biggest achievement in the past 10 years?
As a privately owned company we decided to grow the company organically. With focus on Hard IP validation we managed to become to standard for IP validation with 25+ customers in US, Europe and Far East.

Internal solutions at customers have been replaced by our Crossfire solution. Staff that were hired for both R&D and customer support are still all with the company so years of experience on IP validation is huge. With this solid base of customers and staff we are ready for the next years to come.

Can you tell how Crossfire is used by your customers?
“Crossfire can be used in three ways: for quality sign-off, design development, or assessment of external IPs.” As a sign-off tool, Crossfire enables IC developers to check for undesirable variations in IP blocks and design formats, thereby ensuring that an IP block meets their specifications. At the same time, Crossfire can also be used in design development to assess design formats and the quality checks employed to prevent potential misalignments. Fractal has also incorporated specialized APIs into Crossfire to aid IC integrators in analyzing IP blocks developed by external vendors and guarantee 100 percent alignment with their specific design format.

What’s new in 2020?
The introduction of our new IPdelta tool. The objective of IPdeltaTM is to inventorize all aspects in which one IP revision may differ from the next. Every database and file-format supplied is compared and deltas are reported for every relevant category of design data. This includes basic elements like cells and terminals but extends to delay-, power- and noise- arcs, their conditions and associated characterization data. Also physical layout (LEF, OASIS, OA, MilkyWay) is covered, as are schematics, netlists, synthesis properties and functional models.

With the new IPdelta product our customers will be able to compare 2 versions of the same IP as part of the IP QA flow. This will strengthen our position as market leader for IP validation.

What is the key to Fractal’s success?
Fractal Technology’s team is of the opinion that it is vital to work closely with customers on what they need and expect and to make sure to deliver what one promises. The company also believes that communication is key, and unquestionably, having best of class staff to develop and support the resultant solutions.

Fractal Tech understands that for any customer, feedback is important, and it knows that if customers have a question or an urgent issue, communication is the first part of solving the problem. According to Rene, Same is the scenario within any company. He says, “Everybody wants to be involved in how the company is doing and what the role and added value of each individual is, in the success of a company. Never assume your customer or staff is happy unless you ask and get confirmation.”

About Fractal
Fractal is a privately held company with offices in San Jose, California, Austin Texas, Weert, the Netherlands, Grenoble, France and Yokohama, Japan. The company was founded by a small group of highly recognized EDA professionals. Fractal is dedicated to providing high quality solutions and support to enable their customers to validate the quality of internal and external IP’s and Libraries. Thanks to our validation solutions, Fractal maximize value for its customers either at the sign off stage, for incoming inspection or on a daily basis within the design flow process.

Also Read:

CEO Interview: Johnny Shen of Alchip

Tortuga Logic CEO Update 2020

CEO Interview: Robert Blake of Achronix

June 16, 2020July 18, 2025

Webinar: Optimize SoC Glitch Power with Accurate Analysis from RTL to Signoff

Webinar: Optimize SoC Glitch Power with Accurate Analysis from RTL to Signoff
by Mike Gianfagna on 06-16-2020 at 6:00 am
Categories: EDA, Events, Synopsys

I had the opportunity to preview an upcoming webinar from Synopsys on SoC Glitch Power – what it is and how to reduce it. There is some eye-opening information in this webinar. Glitch power is a bigger problem than you may think and Synopsys has some excellent strategies to help reduce the problem. The webinar is available via replay HERE.

The webinar is presented by Patrick Sheridan, PrimePower Product Marketing at Synopsys. I’ve known Pat for quite a while, dating back to the Cadence days in the 1990’s. Pat has substantial depth on the products and problems being discussed as he’s been at Synopsys for over 10 years. He’s also great at explaining things. Ashwin Sudhakaramenon, PrimePower Application Engineer at Synopsys handles the Q&A. Ashwin has been working as a designer and applications engineer on timing closure for multi-million gate designs for about 10 years, eight of them at Synopsys. Ashwin brings substantial technical depth to the table. These two gentlemen do a great job.

The topics covered in the webinar include:

An introduction to the challenges posed by glitches on power
Accurate glitch power analysis and optimization from RTL to signoff
PrimePower case study examples
Summary/Q&A

That’s a lot to cover in about 40 minutes. If you haven’t registered for the webinar yet, I’ll provide a bit of color on these topics to help you decide.

So, what is the glitch power problem? As designs become more complex and technology advances, the chance of switching activity due to a glitch increases. The problem shows up in all kinds of mainstream designs, including mobile and AI applications. Pat reports that the glitch power component for certain blocks in a design can range from 10% – 50%. That’s not a misprint. Half the power could come from glitches.

These issues can also cause reliability problems from electromagnetic and voltage drop effects. To make it more challenging, designers need accurate vectors to predict where glitches may occur. It is best to fix these problems early in the design process, but detailed vectors are typically not available until late in the design process. Early in the process there is an RTL verification suite, but this data cannot yet take into account the detailed wiring delays, which is what causes the glitch. More challenges.

Once I heard all this, I had to watch the rest of the webinar and you will, too.

What follows is a close look at the technologies available to predict and mange glitch power from RTL all the way to signoff. There are three cornerstone capabilities required here:

A signoff accurate power analysis engine (RTL to gate-level)
Timing-aware activity delay shifting technology
Generation of glitch-aware collateral

Pat goes into quite a bit of detail on each of these points, explaining why it’s important, what the impact on accuracy is and illustrating the results of the analysis. I don’t want to spoil the story – Pat is much better at explaining all this than I am and you really need to hear it directly from him.

The next section of the webinar provides details of four case studies using the Synopsys flow and in particular PrimePower RTL. The four case studies covered are:

RTL glitch power source identification
Gate-level glitch power from RTL fast signal data base (FSDB)
Glitch-aware switching activity interchange format (SAIF) for power recovery
Glitch-aware peak power for IR profiling

This section uses real customer design data at advanced process nodes, so the information is quite relevant. A very useful Q&A follows that Ashwin handles quite well. That’s the summary of the webinar. By now, you must want to see the replay HERE.

Also Read:

The Problem with Reset Domain Crossings

What’s New in CDC Analysis?

SpyGlass Gets its VC

June 15, 2020August 20, 2020

What’s At the Center of Your SoC Design Process?

What’s At the Center of Your SoC Design Process?
by Daniel Payne on 06-15-2020 at 10:00 am
Categories: EDA, Perforce
1 Comment

I love starting a new project from scratch, because there’s that optimistic feeling of having no constraints and being able to creatively express myself and get the job done right this time. For SoC designs today there are teams of engineers and maybe a program manager plus a marketing person that define the features, budget and most importantly the schedule. Because of time to market demands, competition and support of legacy features, we no longer have the luxury of literally starting from scratch, so semiconductor IP re-use is a firm reality. Back in the 1980s your SoC maybe had a handful of re-usable IP blocks, while today the typical SoC will be filled with a majority of IP blocks, so times have changed dramatically.

If you’re using hundreds or even thousands of IP blocks, how do you manage all of that during the design process as new versions are released, bugs are fixed, new features added, or even when the specifications change?

My contacts at Methodics have built their entire company around addressing this very issue, and their answer is a software tool called Percipient which is an IP Lifecycle Management Platform (IPLM). Their IP-centric approach uses hierarchy to represent your complex electronic design, and with Percipient they introduce the concept of an IP object that goes beyond just semiconductor IP:

Through the use of hierarchy all dependencies of a project are tracked in one place, by design. All of the items shown above in orange are modeled as IP inside of Percipient, and every IP has dependencies defined in a hierarchical tree. The following diagram shows an SoC with versions for each IP and Software block being used, so it’s a quick way to create a Bill Of Materials (BOM):

Delving a bit deeper into the electronic design process, the data for an IC is a mixture of both binary and text files, based on which EDA tool is being used, so yes, lots of different file formats and databases are used. You may have some engineers using Git or Mercurial as Data Management (DM) tools on your teams that are distributed geographically and they require close collaboration for source code development. For binary files there are other DM tools like Perforce which can handle big file sizes and be replicated across multiple sites. EDA vendor tools also tend to have their own binary file systems. With Methodics the solution was to create a DM layer that works with any tool:

Just keep using your favorite DM tools, without having to learn something new: ClearCase, Perforce, DesignSync, Git, Subversion. Percipient will work with each of these native DM systems behind the scenes, building the trees and project workspaces.

In addition to working with the most popular DM tools, there is something that Percipient provides for each IP, and that’s called meta-data which could includes things like:

Who may view or modify an IP
IP dependencies
Technical specifications of an IP
Business properties of an IP
Conflict resolution across the hierarchy
Workspace building rules

There are four benefit of using meta-data that is separate from IP data for each IP object:

With Percipient each user builds their own workspace, and each workspace is tracked, so Percipient knows which user has built each workspace, and which IP objects are in all workspaces. Team members use the familiar and native DM commands to build a workspace, so all IP stays in its original data format, along with the hierarchy.

Percipient can also track all IP in the workspace as a link to a managed IP Cache, which is also called PiCache. With this concept each IP version is saved for use by any workspace through soft-links. Here’s a diagram of how IP Cache operates:

A big advantage of using IP Cache is that a workspace can be built literally in just seconds, and it uses very little space because links are used to the cache. An engineer could choose to make an IP object “Local” through check out with the DM tool, or keep them as links. You make an IP local when making modifications, otherwise leave it as a soft link.

Summary

The vast complexity of a modern SoC calls for fresh thinking on an efficient design methodology, and with the proliferation of semiconductor IP re-use it makes sense to have a methodology that is IP object centric. Methodics have done a foundational work in this area of IP Lifecycle Management, and their Percipient tool has been integrated with the most popular Data Management tools in the industry, so you don’t have to ask the CAD department to make your tool flow work with custom programming.

Read the complete 10 page White Paper online now.

For chip design teams in Taiwan and China, there’s some good news as Methodics has recently added a new sales representatives in each country. It’s great to live in the same time zone as your customers.

Related Blogs