Bronco Webinar 800x100 1

FPGA Design Gets Real

FPGA Design Gets Real
by Tom Simon on 02-08-2017 at 12:00 pm

FPGA’s have become an important part of system design. It’s a far cry from how FPGA’s started out – as glue logic between discrete logic devices in the early days of electronic design. Modern day FPGA’s are practically SOC’s in their own right. Frequently they come with embedded processor cores, sophisticated IO cells, DSP, video, audio and other types of specialized processing cores. All of this makes them suitable, even necessary, for building major portions of systems products.

Early FPGA’s were tiny compared with their contemporaneous ASIC’s. The tools for implementing designs were often cobbled together by the FPGA vendors themselves, or there were a few commercial offerings that offered advantages over the vendor specific solutions. Nevertheless, these tools always took a back seat in terms of capacity, performance and sophistication when compared to the synthesis, and place and route flows for custom ASIC’s.

In today’s market, the previous generation of FPGA tools would not stand a chance. Requirements and expectations are much higher. Good thing there has been significant innovation here. Actually, it’s astounding how far FPGA tools have come.

I was reading a white paper published by Synopsys that delves into the state of the art for FPGA design. It makes a good read. It is written by Joe Mallett, Product Marketing Manager at Synopsys for FPGA design. The title is “Shift Left Your FPGA Design for Faster Time to Market”.

Just as is true for ASIC’s, FPGA designs rely a lot on 3rd party IP. These come with RTL and constraint files. FPGA tools need to digest these easily. The same is true for application specific RTL and constraints developed on a per project basis. FPGA’s also have evolved complex clock structures – in large part to meet the power and performance requirements for the designs they are used on. Designers need tools that easily handle multicycle and false path definition.

Once the baseline design specification is in place, the design can move to First Hardware. While it is certain to not meet all the performance requirements of the final design, it is a significant milestone that leads to further optimization heading toward the final deliverable.

In the Synopsys White Paper, Joe talks at length about the ways their Synplify tool can accelerate each step in the FPGA design flow. The initial step being getting to First Hardware. Joe discusses initial design set up and mentions acceleration of synthesis through automatic partitioning and execution with mutli-core and/or compute farm compute resources. There are a lot of benefits in this approach, from lower per machine memory footprint to incremental design.

The next milestone is debug. Synopsys has developed extremely clever ways of adding high design visibility, which greatly accelerates debug. What’s even better, and is a unique advantage of FPGA’s is that the debug can run in real-time and at-speed, in the system level environment. The incremental design capabilities shorten turnaround time at this stage too.

Last we are left with tuning and optimization. Not surprisingly the means to accomplish this are at every stage of the design process. Highly optimized timing needs to be coupled with design size optimization. Synthesis, placement and routing all play a role in the final outcome. Rather than spoil the details, I recommend reading the white paper here. There is also companion paper on distributed synthesis in Synopsys’ Synplify FPGA design tool that I found very interesting.


Machine Learning for Dummies

Machine Learning for Dummies
by Kartik Hosanagar on 02-08-2017 at 7:00 am

I write a lot about data-driven algorithms, in particular those informed by Machine Learning. I thought it would be nice to give the low-down on machine learning for the uninitiated. Below, I discuss four essential questions. The answers are based, in part, from a recent discussion with Pedro Domingos, author of The Master Algorithm.

1. Should we care about artificial intelligence and machine learning?
Machine learning and AI touch your life every minute of every day, from applications you use at work to how you choose products to buy (Amazon recommendations). Even who you marry or date (Match.com, Tinder recommendations). A third of all marriages start on the internet and the matches are created by algorithms. As a citizen, consumer, and professional, you don’t need the the gory details of how machine learning works, but you do need the big picture.

2. What’s the distinction here between AI and Machine Learning?
AI means getting computers to do all the things that it takes human intelligence to do like reasoning, understanding language and the visual world, navigating, and manipulating objects. Machine learning is a sub-field of AI that deals with the ability to learn. Learning is the one thing that underlies all the others. If you had a robot that was as good as humans at everything, but couldn’t learn, five minutes later it would have fallen behind.

3. Let’s look at the history of AI – how did we get here, and what was the most important turning point?

If we rewind back to the early days of the field, one of the interesting aspects was that the field got named artificial intelligence. The runner up was complex information processing, which of course sounds incredibly boring. Calling it AI made it extremely ambitious which has been partly responsible for a lot of the progress. At the same time, it also created these very inflated expectations which were premature. Intelligence seems like an easier problem than it really is because we are intelligent, and we take it for granted. But evolution spent 500 Million years making us intelligent.

People believed that the way to really build intelligent systems was to have them learn. Initially both the understanding of the problem and the computing resources were not up to the test. Your brain is the best supercomputer on earth and people were trying to do this through the computers that they had back then. They ran a little bit ahead of themselves. In the eighties, there was a shift towards so-called knowledge systems. In these systems, you provide the system as much knowledge as possible. This allowed systems to do seemingly intelligent things like play chess and diagnose diseases. But the moment the system encountered a situation outside the knowledge base, the system failed. In the end, the systems were too brittle. They didn’t learn.

Then, what happened led to the present explosion of AI. People went back and said that learning is actually essential — we’re never going to be able to have intelligence without learning. Within learning, the most recent success is based on algorithms that emulate the brain on tasks like vision and speech recognition (techniques known as neural networks and deep learning).

4. What does a machine learning algorithm “look” like?
There isn’t just one algorithm. We have many algorithms and approaches today – based on statistical approaches (e.g. Bayesian learning), evolutionary techniques (genetic algorithms), logical induction (association rules) and approaches that mimic the brain (neural nets). No one algorithm is good at everything. In practice, one chooses from these. The question is whether there is a master algorithm that can learn an infinite variety of things. That’s a separate topic I’ll discuss in the future and that Pedro discusses in detail in his book.

Kartik Hosanagar is a Professor of Technology & Digital Business at The Wharton School.


Scott Jones ISS Talk – Moore’s Law Lives!

Scott Jones ISS Talk – Moore’s Law Lives!
by Scotten Jones on 02-07-2017 at 12:00 pm

I was invited to give a talk at this year’s ISS conference, the talk seemed to be very well received and I was asked to blog about it for SemiWiki. Parts of the talk will be familiar to SemiWiki readers from some of my previous blogs but I also went into more detail around some scaling challenges. The following is a summary of what I presented.
Continue reading “Scott Jones ISS Talk – Moore’s Law Lives!”


Aspirational Congruence

Aspirational Congruence
by Bernard Murphy on 02-07-2017 at 7:00 am

When talking to suppliers about their products, conversation tends to focus heavily on what they already have and why it is the answer to every imaginable need in their space. So it’s refreshing when a vendor wants to talk about where customers want to go without claiming they already have the answer wrapped up in a bow. I recently had such a conversation with Frank Schirrmeister of Cadence on the topic of congruence in hardware modeling through the ever-squeezed hardware and software development cycle.


The root of the problem is well-known – product teams are aggressively compressing development cycles to meet fast-moving market windows. One especially long pole in this effort is getting software ready as soon as possible after silicon. Virtual prototyping is a great way to accelerate development of higher-level software, but when you get closer to the hardware or you need to check performance, you have to turn to hardware modelling on emulation or prototyping systems.

There’s no question that simulation still plays a dominant role in hardware development and verification, but it is wildly impractical as a platform for developing/verifying software. Simulation also struggles with debug and regression in big, long and complex tests, particularly when trying to isolate root-cause problems over millions or billions of cycles. This is why emulation, running orders of magnitude faster than simulation, has become so popular. Emulation doesn’t compile as fast as simulation but at 140-150M gates compiling/hour, you can get 5-6 turns a day, making this approach a practical alternative even in relatively early stages of system development.

When it comes to software development and validation, emulation is arguably the best platform for bare-metal software (firmware and drivers for example) but is far too slow to practically support develop/debug cycles in middleware. That’s where you want to use FPGA prototypes which can run at least another order of magnitude faster and be able to develop/debug in the context of a larger system. This is closer to the expectations of software developers who want to work with what Frank calls “cup of coffee interactivity” – they’re OK to go for a cup of coffee wait for a run to complete, but they’re not OK with having to wait until the next day.

All of this is great, but how does it help software developers start earlier? FPGA prototypes are fast but bringup can take weeks, not an investment you want to make when the design micro-architecture is still being refined. So is early software development a Catch-22? Not if you have emulation/prototyping congruence. Imagine if, starting from an emulation build, prototype bringup could be reduced to a push-button step which would complete in limited time (perhaps a few days) and cycle-level correspondence could be guaranteed between emulation and prototype behavior, then software developers could start much earlier, even at mid-stage RTL. After all they don’t care about detailed hardware behavior (and especially not hardware debug), they just need enough to get started.

This goal is partly achieved today and partly aspirational. Congruence in modeling behavior is already available at cycle-level accuracy and RTL compile is already common between the two platforms. You want clock-tree transformation, gated clock handling and partitioning to the prototype to be transparent, which is largely in place today. But the back-end flow, into Vivado P&R for Protium, still requires some hands-on involvement which could be greatly reduced or even eliminated with maybe some compromise in modeling performance. For a software developer who doesn’t want to or need to know about FPGA tooling, this may completely be acceptable for early software validation/development. And reuse of previously compiled partitions/blocks with hands-free dependency management can further reduce compile times.

So to recap, the aspiration is to be able to start software development and validation while the RTL for the design is still in some level of flux. To do this it is essential to have congruence between emulation and prototyping, in setup and in modeling. Prototype setup should approach a push-button step given a functioning emulation and should compile as fast as possible (within as little as a day if feasible) to support software development staying nearly in sync with hardware evolution. And in modeling the models the hardware team and the software team are using should be congruent in behavior.

Some of this stuff is aspirational, some is already covered in Cadence prototyping (see here), however I’m sure Frank didn’t share this with me simply to admire the problem. I expect that Cadence is cooking more solutions to congruence as I write. For more info, watch for news in this area from Cadence.

On a final note, I chose the title of this piece partly because I thought it would make a great German compound-word, Aspirierendkongruenz as near as I can tell, based on Google translate (Frank can comment). Idle play of an idle mind.

More articles by Bernard…


CTO Interview: Peter Theunis of Methodics

CTO Interview: Peter Theunis of Methodics
by Daniel Nenni on 02-06-2017 at 7:00 am

Fascinated by computers at a very young age, Peter got his degree in Computer Science and was brought to the Bay Area via AIESEC Berkeley’s student exchange program to write his thesis. He has now more than 15 years of professional experience in software engineering, large scale systems architecture and data center engineering in Silicon Valley startups as well as with Yahoo! where he spent the last 9 years as a systems architect and principal engineer.

So how does a systems architect at Yahoo! find his way to an EDA IP lifecycle management company like Methodics?
After spending many years looking at system level issues across multiple industries, I realized that the semiconductor industry is on the verge of experiencing many of the challenges that I have seen before. Today’s SoC’s are in fact very complex systems with many of the challenges that other “systems” oriented industries have faced. Semiconductor companies need similar solutions as other industries to allow the complexity of a modern SoC to scale to the tools and methodologies that semiconductor design teams have at hand, but make the overall process much more efficient. Methodics had an excellent foundation to build solutions for the future of Semiconductor design that will scale with the challenges that they will face around complexity.

What type of solutions do you need to provide to design teams to allow them to realize these efficiencies?

As with any other complex system, it has always been a divide and conquer approach. As SoC’s became common place, many companies started to focus on “reuse”. The main goal was allowing portions of previous designs to be reused to reduce the amount of design effort needed in new designs. As reuse in design teams became commonplace, the need to reuse designs outside of the immediate team, as well as acquire pieces of the design from partners or third parties lead to the notion of IP and IP management. As SoC’s grew larger and more complex, the amount of data and metadata associated with IP’s grew astronomically, and better technology was needed to manage the lifecycle of IP and more complex digital asset management systems were needed.

I am familiar with IP within the SoC design process, but digital asset management is a new term, can you elaborate?

Digital assets are the natural progression to IP lifecycle management. Original design reuse strategies started just with design data. As methodologies formalized around design reuse, you began to see IP methodologies evolve with the formalization of techniques and methods at making designs reusable. Soon, verification IP was added to these flows and now you had to also map verification and design IP together, leading to a growth in information that needed to be managed as you added the meta data associated with these types of IP. Eventually design scripts were added to the mix, timing constraint files, DFT information, as well as other design artifacts leading to another explosion in data that needs to be managed. With this complexity, the relationships between all these different pieces of data also need to be managed, and now you quickly begin to lose the traditional notion of IP. Today, with requirements systems producing myriads of requirements for systems, issue and defect systems tracking all aspects of design, and the need to trace information throughout the entire process, there is much more that just traditional IP that needs to be managed. There’s a whole range of digital assets that need to be managed.

How is Methodics helping with digital asset management?
Methodics’ most recent solution provides a true digital asset management platform. It all starts with effective design data management. It has always been Methodics’ strategy to work with industry standards when they are available. For design data management, we build on Perforce which has been providing leading enterprise data management solutions to multiple industries for years. Then the platform allows the integration of other engineering systems to provide communication across all solutions and the design teams where none has been available. Given that there are many engineering systems in use for issue and defect tracking, requirements tracking and other management tasks, the Methodics platform allows the integration of systems like Jira and Bugzilla for issue and defect and Jama for requirements management, allowing it to work seamlessly in existing engineering environments. The goal of the platform is to link all design data, IP data and metadata, design artifacts, requirements and issue and defect data together into a cohesive information system, that allows designers to not only to search for and find IP, but also to find all possible data associated with that IP and how it is connected through the various engineering systems. Engineering teams can now be more productive by quickly searching for and finding IP, quickly being informed of issues with the IP being used and when to expect resolution to those issues, and the ability to track quality and grade IP being used. In addition, management can quickly compile reports of where IP is being used, outstanding issues with that IP, traceability of requirements and other pertinent design data. The platform provides efficiency in design by streamlining the management and communication of data from multiple disparate systems, and can scale with increasing complexity by tracking the convoluted web of interconnected information throughout designs and organizations.

What is unique to the Methodics technology that makes it able to provide solutions?
We recently re-architected our underlying object store to support a graph database. We made this decision because of the highly complex and hierarchical nature of having to manage IP and digital assets. Graph databases allow the storing of direct relationships of data, allowing it to be quickly retrieved, often with a single operation. Compare this to traditional relational databases where links between data are stored in the data itself. In order to retrieve complex hierarchical and interrelated data, you would need to make multiple expensive calls to extract the required information. Our graph database has made possible greater than 10x performance improvements in just handling hierarchical IP in SoC designs. It has also allowed us to create the digital asset management platform linking in other engineering systems that would not have been possible with a traditional relational database.

It seems that Methodics is investing in improving the efficiency of finding IP and critical information for SoC design, but designers still have to manage huge amounts of data itself in their workspaces. How is Methodics helping there?
You are correct. We are seeing user workspaces routinely exceed 10’s of GB, sometimes 100’s of GB. Regression runs, characterization runs, design and debug workspaces all put a great stress on Network Attached Storage (NAS), create NFS bottlenecks and cause significant project delays. This situation is only getting worse. Last year we introduced WarpStor, a Content Aware NAS optimizer and accelerator. It excels at dramatically reducing user workspace storage requirements and creation time. With WarpStor, our customers can see up to 90%+ reduction in storage requirements and corresponding reduction in network I/O for user workspaces, regression runs, characterization runs, and the like. Creation time for multiple large workspaces is also reduced from hours to seconds. We have been using this technology internally for sometime and now our customers are realizing these same results. We now have many reference customers for this technology that are willing to speak with companies that are interested in this technology.

Where do you see Methodics research and development efforts going from here?
Since the complexity of SoC’s are only going to increase, we will continue to leverage our knowledge of solving systems challenges and adapting that for the semiconductor industry. There is a wealth of knowledge and methodology that can be adapted to the semiconductor industry and we will continue to do that. Likewise, the work we are doing around IP and digital asset management as well as workspace management can help other industries, so we will continue to synthesize across industries to bring solutions to those other industries as well. Stay tuned….

www.methodics.com


SPICE Model Generation using Machine Learning

SPICE Model Generation using Machine Learning
by Daniel Payne on 02-05-2017 at 10:00 pm

AI and machine learning are two popular buzz words in the high-tech daily news, so you should be getting used to hearing about them by now. What I hadn’t realized was that EDA companies are starting to use machine learning techniques, and specifically targeted at the daunting and compute intensive task of creating SPICE models that account for variability. I turned to my source at Platform DA in order to discover more about these new machine learning approaches that they are using to create SPICE models.

Statistical Variation of IC Processes
It’s no secret in our semiconductor industry that the spread in SPICE process corners like FF and SS is becoming larger as the node size gets smaller. Just look at the following chart which shows how normalized delays are changing when moving from 65nm (red line) to 40nm (blue line):


So where does all of this process variation come from? The sources of local random variability are numerous:

  • Random Dopant Fluctuation (RDF)
  • Line Edge Roughness (LER)

Another way to think about process variation is to know that we’re dealing with the intrinsic statistical physics of nature in our semiconductor materials.

In addition there are global statistical variation sources for a process node:

  • Die to die
  • Wafer to wafer
  • Lot to lot
  • Fab to fab

The IC manufacturing process is a complex set of steps that involve Temperatures, times, pressures, cleanliness and gas compositions. All of this in turn effects transistor characteristics like Vth, Tox, IDon, IDoff, etc. The accumulation of device parameter variability can be plotted as a set of distribution curves:

We can even look at variability by category, and notice the trends when moving from 65nm down to 28nm:

Using statistical corners for modeling is a conservative approach. Here’s an actual flow that accounts for variability when creating SPICE models:

One drawback that you quickly discover with this approach is that the results (blue dots) don’t correlate well with process corners (red):

A second drawback is that the results (blue dots) don’t correlate well with the design corners (red) either:

Any automatically generated SPICE models based on this first approach would require fixing to agree with measured results. What we really require is a fast statistical model generation along with a fast statistical model adjustment without changing our corners.

The traditional method in SPICE to work with variations is to use lots of Monte-Carlo simulations, however running Monte-Carlo takes too much time, so what we really want are faster Monte-Carlo simulations along with faster statistical optimizations.

Machine learning can be applied to this optimization approach because:

  • Current statistical models are based on corner specs
  • Some specs especially the design specs are highly nonlinear

Here’s a flow for how optimization is accomplished using cascaded machine learning:

Related blog – Are your transistor models good enough?

The extraction results (blue dots) from this cascaded machine-learning algorithm match the corners quite well (red):

Automatic model generation has a modeling flow for advanced statistical analysis of four steps:

[LIST=1]

  • Origin data
  • Corner model
  • Mismatch model
  • Statistical model

    The key techniques to make these four steps happen efficiently are fast Monte-Carlo, a projection based method, cascaded machine-learning, and intelligent optimization. Take a look at how good the mismatch modeling is with this approach (red versus blue lines):

    Look at how tight the data points are inside of each elliptical region for the fast generation and characterization of an 11-corner model:

    Related blog – Is that PDK safe to use yet?

    What does all of this wonderful technology mean to an IC designer? Well, an IC designer can now perform statistical analysis to identify issues, and they can fix design correlation without changing corner specs as shown below:

    I hope that you learned something new today about automatic SPICE model generation, because the approach from Platform DA in their MeQLab tool looks very promising.


  • AMD vs Intel Update!

    AMD vs Intel Update!
    by Daniel Nenni on 02-04-2017 at 10:00 am

    Is it just me or has AMD just pulled off one of the most amazing semiconductor comebacks of the century? Let’s take a closer look.

    Who doesn’t long for the days when Intel and AMD went head to head in the battle for microprocessor supremacy? Back then Intel, was still operating under the Andrew Grove mantra of “Only the Paranoid Survive” and ultimately pounded AMD into submission. The battle officially started when IBM required a second source for the IBM PC x86 chips Intel is now famous for.

    Like Intel, the AMD founders also came from Fairchild and started AMD as a semiconductor second sourcing business for a variety of chips. It really was an epic semiconductor battle with Intel and AMD leap frogging down Moore’s Law. In fact, I remember buying motherboards with an AMD 40Mhz processor versus an Intel 36Mhz chip just to keep the second source dream alive.

    Unfortunately, the Intel vs AMD battle officially came to an end in 2009 when AMD repeatedly failed to leap frog Intel and was forced to divest manufacturing giving birth to US based GlobalFoundries. Over the last 8 years fabless AMD has been very hard to watch with failure after failure at many different levels. But now all of that has changed with new management and the amazing Zen architecture. Or has it?

    Zen was designed from the ground up by famed SoC architect Jim Keller. This was Jim’s second stint at AMD following his work at Apple that produced the first A4 and A5 SoCs for the iPhone and iPad launches. Jim returned to AMD in 2012 and left after Zen was taped out in 2015. Jim Keller and his core team now work for Tesla.

    The first question you should be asking is: Why is Zen being released in 2017 when it taped out in 2015? Maybe the same reason why Jim Keller no longer works at AMD? How many spins can you do on a chip that size in two years? Two to three depending on how many masks were changed?

    Fast forward to the most recent AMD investor call, where a ship date for Zen was finally announced causing AMD stock to jump once again. At the beginning of 2016 AMD traded for under $2 and is now trading for more than $12. Talk about an amazing comeback, absolutely.

    Some semiconductor insiders however are calling it “AMD Delusional Disorder”. These delusions may seem believable at face value, and investors may appear normal as long as an outsider does not touch upon one of their delusional themes. Read the comments on articles critical of AMD for a more detailed description.

    A recent delusional example is the Zen release strategy announced on the call that caused the stock to again rise:

    “We’ll start by shipping Zen to boutique PC manufacturers and the channels that support Do-It-Yourself types.” In other words the “NOT INTEL” market.

    The non delusional version is, “We could not get Zen into a major PC manufacturer such as HP, Dell, Acer, or Lenovo…”

    On the manufacturing side, AMD has 14nm wafer agreements with Samsung and GlobalFoundries so there are no Zen capacity issues unless the chip is not yielding or it requires yet another spin.

    The other interesting thing to note is that Intel does not seem to be paranoid of Zen at all. We will know more after the February 9[SUP]th[/SUP] analyst meeting but it seems that Intel will not accelerate their 10nm release schedule to compete with Zen nor did they mention potential margin erosion from a price war that AMD would lose.

    Another problem for Zen is that Intel 14nm (13.4nm) was developed for and ramped by Intel CPU chips. Samsung 14nm (16.6nm) however was not developed for or ramped by Zen. Intel 14nm is also in its second generation with better design constraints resulting in a double digit performance increase and a cost reduction. GF 14nm however is first generation. Intel is also very close to their major customers (HP, Dell, Acer, Lenovo, etc….) and know what they are forecasting, Intel is probably not as close to “boutique PC manufacturers and the channels that support Do-It-Yourself types”.

    On the bright side, GF 7nm is probably being developed with Zen in mind and will be one of the first chips to ramp. From what we know today GF 7nm (8.2nm) will arrive in 2019 while Intel 7nm (6.7nm) is expected in 2020. In the mean time however, GF 14nm Zen chips will be competing with Intel 10nm (9.5nm) chips starting in 2018.

    Bottom line: AMD has zero chance of profitability before 7nm and at some point in time Wall Street will have to face financial facts and AMD stock will be back to single digits, my opinion.


    Open-Silicon Update: 125M ASICs shipped!

    Open-Silicon Update: 125M ASICs shipped!
    by Daniel Nenni on 02-03-2017 at 12:00 pm

    As you all know I am a big fan of the ASIC business model. It was critical in the transformation of the fabless semiconductor industry and still plays a critical part in our success. In fact, the ASIC business model is leading the way for systems companies to make their own chips. Remember, Apple started with the ASIC business model through Samsung for their first iPhone SoCs that transformed the world, absolutely.

    In 2015 Open-Silicon celebrated the shipment of their 100M ASIC and now less than two years later they are over 125M spread amongst 300+ designs. More importantly, their defective parts per million average (DPPM) is 30, resulting in very low RMAs. 30 DPPM is an excellent number for the ASIC business by the way. The DPPM ASIC numbers I have heard in the past were much higher.

    “Our low RMA return is evidence of our excellence in design engineering. We prideourselves in reducing risk, lowering cost and delivering first-time working siliconthat is ready for volume production.” Asim Salim, Open-Silicon’s Vice President of Manufacturing Operations.


    If you look at the Open Silicon website you will see a wide range of business models. Customers can engage with a design level specification, RTL, netlist, GDS2, production or design only. This reminds me of the start of the fabless business model where designs where sketched out on white boards or even cocktail napkins and taken from idea to chip by ASIC legends LSI Logic and VLSI Technology. Again, a systems company or an emerging IC company can get ideas transformed into proof of concept prototypes or even production quality silicon with reduced risk and minimal upfront cost.

    The other part of the Open Silicon website you should see is the IoT ASIC page. My trusted sources say that by the year 2020 there will be more than 20B industrial/commercial internet connected devices installed. If you have an idea for one of these devices this is the page you want to spend time on, absolutely.


    Open-Silicon also has an IP Page that talks about their High Bandwidth Memory IP, Hybrid Memory, Cube ASIC & FPGA Controller IP, Interlaken Controller IP, and Partner IP. Silicon proven commercial IP not only reduces design risk, it dramatically shortens design time so you definitely need to spend some time on this page as well, no matter what chip idea you have.

    The other page you should spend time on is the Open-Silicon landing pageon SemiWiki. We have been working with Open-Silicon since the beginning of last year and have 12 blogs by 4 different bloggers/perspectives starting with A Brief History of Open Silicon.

    Open-Silicon transforms ideas into system-optimized ASIC solutions within the time-to-market parameters desired by customers. The company enhances the value of customers’ products by innovating at every stage of design – architecture, logic, physical, system, software and IP – and then continues to partner to deliver fully tested silicon and platforms. Open-Silicon applies an open business model that enables the company to uniquely choose best-in-industry IP, design methodologies, tools, software, packaging, manufacturing and test capabilities. The company has partnered with over 150 companies ranging from large semiconductor and systems manufacturers to high-profile start-ups, and has successfully completed over 300 designs and shipped over 125 million ASICs to date. Privately held, Open-Silicon employs over 250 people in Silicon Valley and around the world. www.open-silicon.com


    Verifying Design for In-Car Networks

    Verifying Design for In-Car Networks
    by Bernard Murphy on 02-03-2017 at 7:00 am

    Once upon a time the role of electricity in a car was pretty modest: spark plugs, alternator, lighting, some simple instrumentation and maybe heating, all supported by an equally simple wiring harness (my wife has a 1962 Morris Minor, so I know exactly what the whole wiring harness looks like). How times have changed. Now most or all drivetrain systems are controlled by wire rather than mechanical linkages, driver assistance and safety is supported through proximity detectors and AI analysis of radar, infrared and light images, the cabin has sophisticated entertainment options, navigation and other features supported by voice control. There’s no obvious end to what could be added.

    Obviously, this can’t be supported with a simple wiring harness. You might assume the logical solution would be to hook it all up through some form of Ethernet with bridges to actuators and sensors where needed, but you would be wrong. Or rather you would only be partly right. Cars present a much more hostile (electromagnetic interference, temperature, and vibration) environment for electronics than you would find in a home or office environment. And an acceptable level of safety in some systems is much less tolerant to latencies in the network than for other systems. Then there’s cost – do you need an Ethernet connection to control a side mirror?

    The picture is further complicated by needs for autonomous and semi-autonomous control, requiring real-time response to video, audio and data from camera, wireless and sensor interfaces. Overall there is quite a wide spectrum of communication options, some held to very high safety standards and reliability expectations given high recall costs and much longer in-service lifetimes.

    Let’s start with protocols for “standard” needs. These include:

    • LIN (local interconnected network) – low cost, single wire, 40kb/s, used primarily for mirrors, door locks, power seats, wiper controls, climate control and similar functions). Very simple master/slave protocol, one slave responds to each message, so no arbitration or collision detection required.
    • CAN (controller area network) – middling cost, 2 wire (twisted pair), 1MB/s, used primarily for powertrain (engine timing, transmission, ABS). Protocol more like a standard bus bit multiple message types, arbitration, etc. There can be multiple CAN networks in a car.
    • FlexRay – higher cost, 2 or 4 wire (twisted pair, single or dual channel), 10Mb/s, high performance powertrain and safety applications (drive-by-wire, active suspension, adaptive cruise control). Protocol offers support for static and dynamic frames with a preset communication cycle allowing an option for deterministic data arrival where needed or CAN-like dynamic event-driven delivery.
    • Ethernet (no explanation needed) – this has been primarily for diagnostics
    • MOST (media-oriented systems transport) – widely used for multimedia today, time-sensitive traffic support, but a protocol and architecture specialized to automotive applications. There is enthusiasm in the industry to eventually replace this (and perhaps other standards listed here) with Ethernet-based approaches.

    Then we have protocols for autonomous/semi-autonomous needs:

    • Ethernet-AVB (audio/video bridging) – a competing standard to MOST, also used for multimedia. Builds on the Ethernet standard to offer time-sensitive behavior where privileged data can be prioritized over non-privileged data. Important in e.g. cabin surround-sound where differing latencies to different speakers due to best effort behavior of the network may compromise listener experience.
    • Time Sensitive Networking (TSN) – AVB extended to AVB TSN for application to control systems. TSN is used across the systems of an autonomous car for transmission of data ranging from ADAS and control traffic to infotainment and internet, ensuring precise, synchronized, deterministic and timely delivery of data with minimum latency.
    • MIPI – there are several relevant sub-sections:

      • CSI-2 – In a typical mobile application, an application processor uses MIPI CSI-2 to provide high bandwidth, low-power, and low cost interfaces to cameras. The same architecture carries over into the automotive world for intelligent rear-view mirrors and radars for parking assist, wing mirrors, cameras for gathering information about objects around the car, and even surround-view systems.
      • DSI – MIPI DSI is aimed at reducing the cost of display controllers and commonly used for dash, infotainment, and any other display in the car. The DSI specification defines a high-speed serial interface between a peripheral, such as an active-matrix display module, and a host processor.
      • I3C – The need for a faster, lower power, scalable sensor connectivity with efficient architecture is essential for an autonomous car with myriad of sensors. The MIPI I3C standard has become the ideal solution for today’s sensor interface requirements due to its faster speeds of 12.5Mhz and fewer pin counts as compared to other existing solutions like I2C and SPI. Sensors for accelerometer, proximity, touch screen, compass, and more are used in advanced driver assistance systems (ADAS) and in-vehicle infotainment (IVI) applications, creating more opportunity to deploy the technological advantages of I3C in automobiles.

    Synopsys has verification IP (VIP) for all traditional protocols used in vehicles (Ethernet/LIN/CAN/FlexRay), except for MOST. On top of this they have added Ethernet AVB/TSN and MIPI protocols for autonomous/semi-autonomous support. All of these are available in SystemVerilog/UVM.

    Why not support MOST? I couldn’t get a response on this from Synopsys, but Googling around I couldn’t find any other VIP (or IP) vendor, even the small ones, providing MOST support either. I guess the design/verification eco-system doesn’t have a lot of confidence in the future of MOST or, perhaps more important, aren’t getting signals from the automotive industry that MOST is a good area to invest.


    One of the nice things about protocol verification in the Synopsys suite is protocol-aware debug in Verdi. Some of us get a chance to become proficient in certain protocols but most of us have too many bases to cover to be experts at everything, so we need a little help. This is especially true in protocol debug where root-cause analysis of misbehavior and bottlenecks needs more than basic waveform analysis. Each of these automotive VIPs supports protocol-aware debug in Verdi.

    Automotive VIPs come with a configurable test-suite and test plan so you don’t have to build the protocol tests from scratch; this include the test plan for complex sequences which can be quite difficult to derive from the specification.

    This is complex stuff. Each standard supports many options – different network topologies, different frame-types, different modes, different rates. Building a comprehensive test-suite for each protocol can be challenging. Naturally the demands of this domain leave no room for error so you are quite likely to complement testing based on the Synopsys VIPs with your own testing. A very understandable strategy, starting with a strong out-of-the-box verification using Synopsys VIPs. You can see the Synopsys press release HERE and get more detail on the automotive VIPs HERE.

    More articles by Bernard…


    On-Chip Power Distribution Networks Get Help from Magwel’s RNi

    On-Chip Power Distribution Networks Get Help from Magwel’s RNi
    by Tom Simon on 02-02-2017 at 12:00 pm

    Counting squares is a useful tool for calculating simple resistance in wires, but falls short in reality when wires deviate from ideal. Frequently the use of RC extraction tools for determining resistance in signal lines in digital designs can be effective and straightforward. However, there are classes of nets in designs that confound extraction tools. Good examples of these are found in power distribution networks. Also, nets found in memory designs are excellent candidates for deeper analysis.

    At one end of the spectrum of solutions we find full wave solvers. While they are the most accurate method for analysis of electrical properties in all kinds of metal structures, they are troublesome to apply to complex on chip metal structures. Full wave solvers are difficult to set up, run slowly and output S-parameters, which are vexing to use for subsequent interpretation. Consequently, use of full wave solvers is often limited to analysis of on-chip inductors and capacitors.

    The output of RC extractors fall short when complex nets are involved. A typical power or ground net may have thousands or more end points. What matters to the design is the actual resistance at each of these end points. To further complicate solving this problem these nets are often highly interconnected to themselves. The best example of this is a mesh style power or ground net. There are many parallel current paths in these nets, which can greatly complicate the effective resistance between any two points on the network.

    Fortunately for designers who need to tune and optimize endpoint resistances in large complex nets, such as power distribution networks, there is an easy to use solution available from Magwel. Their Resistance Network Integrity (RNi) tool provides an intuitive and easy to use approach that provides comprehensive analysis and an interactive interface for finding high resistance segments and endpoints.

    Magwel’s RNi uses solver technology that can handle complex interconnect without the difficult set up typically required for other solvers. RNi reads in the layout in GDS and allows the user to select a pad or create a contact point to use as a reference point for the resistance calculation. The RNi technology file comes from information found in foundry supplied ITF files. Once the solver is started, results are available quickly.

    The solver extracts the entire net, including vias and metal on all layers. Another benefit is that no stimulus is needed and the design does not have to be LVS clean. It is extremely valuable to be able to plan power distribution networks as early as possible in the design cycle.

    RNi calculates the total resistance to all points on the selected net from the contact point or pad that was set at the beginning of the run. It’s easiest to view the results in the tool’s field view. This is a graphical view that uses color to visualize the resistance values. Also, moving the mouse over any point in the net will display the resistance value to that point as a number. Of course, in a large chip, finding a high resistance point can be like finding a needle in a haystack. RNi will quickly list the top values and allows the user to zoom in on the view each of them with a single click on the mouse.

    RNi is a natural addition to Magwel’s product line up. Accurate resistance extraction is an absolute necessity for ESD induced voltage drop during discharge events. Magwel is applying its solver based resistance extraction to this problem in its ESDi product. The same technology comes into play during power device gate, source and drain network simulation and analysis in their PTM product family. For more information on Magwel and their solutions for improving design efficiency, reducing power, and increasing reliability, refer to their website here.