Semiwiki EDA Webinar 800x100
Semiconductor Expert Forum

Posted on

Top 5 Things to Know About Recent IoT Attacks

Top 5 Things to Know About Recent IoT Attacks
by Matthew Rosenquist on 10-30-2016 at 12:00 pm
Categories: IoT, Security

Recent internet attacks resulted in popular sites becoming unreachable, such as Twitter, Etsy, Spotify, AirBnB, Github, and the New York Times. These incidents have brought to light a new threat to online services: Internet of Things (IoT) botnets. Distributed Denial of Service (DDoS) attacks have been commonplace for over a decade but rarely been too troublesome. For the past several years’ network providers’ security services have been able to absorb such attacks to keep online properties available. But the game has now changed.

In essence, when a number of devices can be controlled to simultaneously flood a destination with network requests, the target becomes overloaded and legitimate requests cannot be processed. Traditional network filters are smart enough to recognize a handful of systems attempting this malicious behavior and simply drop all requests from them. But when thousands of different systems mount an attack, the normal filters fail to recognize legitimate from malicious traffic and the availability of the system crumbles.

Cybercriminals and hacktivists have found a new weapon in this war, the Internet of Things (IoT). Billions of IoT devices currently exist and can be as small as a piece of jewelry or larger than a tractor. They all have one thing in common, they connect to the Internet. This has tremendous benefits as people can monitor their home with cameras from afar, check the contents of their refrigerator while at the store, and do a myriad of other great things with these connected beneficial gadgets. We cannot forget however; these are just tools. They can be wielded for good or employed for malice. To hackers, each one of these devices is a potential robotic soldier, which they might be able to recruit into their bot-army.

The most recent attack, against a major DNS provider has highlighted this very fact to millions of Internet users. Botnets containing tens or hundreds of thousands of hijacked IoT devices can bring down major pieces of our beloved Internet. There is a lot of hype, fear, and speculation bubbling out of the shadows. We are at a tipping point. IoT devices now represent a new and formidable threat. The next few months will be telling. For now, let us cut through the hype and understand the important aspects of recent IoT DDoS attacks.

Here are 5 things you should know about the recent IoT attacks:

1. Insecure IoT devices pose new risks for everyone. For every IoT device which can be hacked, it is another soldier in a botnet army which could be used to bring down important parts of the Internet. Such attacks can interfere with your favorite sites for streaming, social media, online-shopping, banking, etc. If you own such weak or poorly configured devices, then you could be contributing to the problem.

2. IoT devices are valuable to hackers and they won’t give them up without a fight. Although these attacks, with malware like the Mirai botnets, are simple in nature, they will evolve as quickly as they need to for the attackers to remain in control. IoT devices are hugely valuable to hackers, as they empower them to conduct devastating DDoS attacks with little effort.

3. DDoS attacks from IoT devices are severe and tough to defend against. Identifying and filtering out attacks from a handful of systems is easy. When faced with tens or hundreds of thousands, it is near impossible. The amount of resources needed to fend off attack is tremendous and costly. A recent attack to knock Brian Krebs’s security-reporting site offline, resulted in Akamai’s vice president of web security to state “If this kind of thing is sustained, we’re definitely talking millions” of dollars in cyber security services to keep the site available. That is powerful. Look for attackers to not give up easily. These always-connected devices are perfect for DDoS botnets.

4. Cybercriminals and hacktivists are driving these attacks. There is speculation and fear that nation states are behind the latest string of attacks. That is highly unlikely. Authors of Mirai, one of hundreds of botnets, voluntarily released the code to the public, something a professional government offensive team would never do purposefully. However, it is a good bet that after witnessing how powerful IoT botnets are, nation states are probably working on similar strategies but with much more advanced capabilities. In the short term, cybercriminals and hacktivists will remain the main culprits of these attacks. Over the next few months, expect criminals to find angles which they can make a financial profit, like extortion.

5. It will get worse before it gets better. Unfortunately, most of IoT devices that have been deployed to date, lack strong security defenses. The ones being hacked now are the easiest, with default passwords that are published for anyone to lookup. Hacker software simply connects and logs into the device, unless the owner has gone out of their way to change the default password. Unsurprisingly, most have not taken this important step. Instantly, the attackers have another soldier to do their bidding. In order for this situation to get better, several aspects must be addressed. Devices must be designed with security in mind, configured properly, and managed to keep security updated. This will take both technical and behavioral changes in the long-run to keep pace with evolving hackers.

Also read: How to Secure the Future of IoT
Hacking IoT devices is now a problem for everyone. Due to the ease of compromise and massive numbers of IoT devices which are connected to the Internet, cybercriminals and hacktivists have a vast resource to fuel powerful DDoS campaigns. We are just starting to see the attacks and issues around IoT security. It will continue to be a problem until more comprehensive controls and behaviors make us all more secure.

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

Also read:How to Secure the Future of IoT

Posted on

The IP Paradox: Sales are growing despite Semi Consolidation

The IP Paradox: Sales are growing despite Semi Consolidation
by Eric Esteve on 10-29-2016 at 7:00 am
Categories: IP

IPnest is launching the “Interface IP Survey” since 2009, and we did it last September again. To build the survey as accurately as possible, I have followed the “divide and conquer” strategy. Interface protocols are varied, ranging from PCI Express, USB, or Ethernet, to memory controller (DDR3, DDR4, LPDDR3, LPDDR4 and more) and HDMI, DisplayPort, SATA, SAS, or MIPI specifications (CSI, DSI, I3C, M-PHY, D-PHY, C-PHY…).
Continue reading “The IP Paradox: Sales are growing despite Semi Consolidation”

Posted on

Can one flow bring four domains together?

Can one flow bring four domains together?
by Don Dingee on 10-28-2016 at 4:00 pm
Categories: EDA, IoT, Siemens EDA

IoT edge device design means four domains – MEMS, analog, digital, and RF – not only work together, but often live on the same die (or substrate in a 2.5D process) and are optimized for power and size. Getting these domains to work together effective calls for an enhanced flow.

Historically, these domains have not played together in silicon. Designs were executed at a PWB level, bringing together chips with different design rules and packaging technology. This was a risk reduction maneuver; each domain could be debugged more or less independently, then integration issues such as crosstalk, interference, and signal integrity solved using macro techniques for mitigation. Domain experts usually didn’t cross disciplines, except to understand the interfaces between the domains.

Now, interaction between domains is much more critical to success in constrained IoT edge designs. Mixed signal design is pretty much taken for granted now, but more and more people are having success in on-chip RF and MEMS integration. The bar has been raised by better EDA tools that handle a unified flow from capture to simulation to layout.

Note I said tools. It’s not necessarily a single tool, but rather an integrated suite operating from the same data repository with the same user interface that is important. What kills productivity is switching costs. Bringing together these four domains is easier said than done, however. Analog types are used to working in schematics, digital types in RTL, and MEMS and RF designers are often working at the metal layers.

This challenge is really the motivation behind the Mentor Graphics purchase of Tanner EDA a year and a half ago. Integrating those disparate domains and bringing a full suite of EDA tools together in one comprehensive flow is a big job that the Tanner teams have been working on relentlessly since the acquisition. Mentor’s PWB tools such as PADS, created with small teams in mind, also factor in to the flow. For IoT edge devices, it goes even deeper – Mentor’s purchase of CodeSourcery was all about optimizing chips for real-time software.

A new Mentor white paper authored by Jeff Miller has an interesting premise: if we have a better design flow for IoT devices, handling all four domains, we get more optimized parts. (He’s gone as far to suggest there is “a new breed of designers.” That has a lot to do with how engineers come through school. I’m not sure deep expertise in all four domains are possible in a single person, but I am sure that designers are becoming much more familiar with cross-domain design and collaboration in small teams.)

The Tanner IoT design flow handles all the way from capture through simulation to layout:


Miller walks through how the tools tie together in this scenario. His discussion on simulation is particularly interesting. For example, in a mixed-signal simulation, T-Spice and ModelSim work together, passing data back and forth whenever signals change at the analog/digital boundary.

What about the MEMS part of the job? Miller suggests that creating 3D models and then trying to derive a 2D mask is difficult and can lead to errors. He suggests a mask-forward flow, bringing in a 2D mask from Tanner L-Edit and then generating the 3D model. And the RF? Tanner Eldo can be used to analyze RF circuits with several algorithms and help optimize the results for various types of circuits.

Just reading through this discussion, it is clear the different domains call for different handling, and there has been a lot of progress in Tanner EDA tool integration. The entire white paper is available for download (registration required):

Driving Intelligence to the IoT Edge Invents a New Breed of Designers

As I said, I don’t think there is any magic that transforms a single designer into an expert in all four domains just by adding tools. What we are seeing is EDA vendors starting to think about their tools as part of a bigger system design effort with various facets, with a collaborative design team working in one environment with integrated tools.

Posted on

Is That PDK Safe to Use Yet?

Is That PDK Safe to Use Yet?
by Daniel Payne on 10-28-2016 at 12:00 pm
Categories: EDA, Platform Design Automation

In our semiconductor ecosystem we have foundries on one side supplying all of that amazing silicon technology, and IC designers on the other side that take their system ideas then go implement them in a SoC using a specific foundry. The required interface between foundry and chip designers has been the Process Design Kit (PDK), a collection of files that define how the silicon should work:

  • SPICE models for transistor behavior
  • Layout Parasitic Extraction (LPE) decks that define the physical interconnect in terms of resistors, capacitors and inductor
  • Design Rule Checks (DRC) that define how the physical IC layout should be done in order to yield properly
  • Layout Versus Schematic (LVS) decks that specify how transistor-level netlists should compare between layout and logical

Getting the PDK files right is really important because with small process nodes we have Layout Dependent Effects (LDE), for example the Vt of one transistor depends on how close it is physically placed next to another transistor or even a contact. Same issue with the mobility of a transistor, it depends on physical placement. Parasitic values can now dominate the speed of a transistor, so knowing how to extract them properly impacts the accuracy of timing analysis tools..

We all know that software is mostly written by hand, so that means that bugs can creep into the tool by accident. Well, the PDK is just a bunch of files that can be manually or automatically generated, and yes, these files may be off a bit, so what to do? If you’re an automation company you would come up with a way to create a QA tool for PDK creators and PDK users. This is exactly what the engineers at Platform DA have come up with, a QA toolset for the foundries that create the PDKs and for the circuit designers that use PDKs. They call their tool PQLab, and I just learned more about it.

Related blog – Are your Transistor Models Good Enough?

A chip designer has certain questions about the PDK:

  • What just changed when going from PDK v.1 to v.2?
  • How does a PDK change impact my IC project?
  • Which foundry should I use for my next IC design?
  • Is there a way to benchmark different PDKs of two different design flows quickly?
  • How does LDE, statistical variation and parasitics impact my design?

At the foundry the PDK engineering team has their own set of questions:

  • Are all of my PCell combinations DRC clean?
  • Will all of my PCell combinations be LVS clean?
  • Can I compare the pre-layout versus post-layout circuit simulation results for typical cells?
  • What just changed when going from PDK v.1 to v.2?

The approach used by PQLab is to help answer these questions through a set of QA features designed just for PDKs:

Starting with the DRC and LVS side of QA first, the idea is to automatically and randomly place cells from the Pcell library next to each other and then run a popular DRC/LVS tool like Calibre from Mentor Graphics to check that all combinations are actually clean and without any errors:

If DRC or LVS errors are found with certain cell combinations, then the foundry goes back and fixes those cell layouts and re-runs QA to ensure that each error has been fixed.

For the simulation QA there are three major tasks:

  • Correlate SPICE models pre-layout versus post-layout
  • Compare the device simulation specs like Vth, Idsat, etc. at pre-layout and post-layout conditions across a range of circuits
  • Compare any differences between design flows with popular circuit simulators (HSPICE, Spectre) and extraction-based netlists from extractors (StarRC from Synopsys, Quantas QRC from Cadence, Calibre XRC from Mentor)

The third and final area of QA checking with the PQLab tool is PDK comparisons, where there are five criteria:

  • PDK file comparison
  • PCell property comparison
  • CDF comparison
  • PCell default layout and original position
  • Simulation results comparison

Summary
PDK files continue to be the way that foundries and designers interface, so we need to be sure that all of the PDK files are consistent and correct. The PQLab tool from Platform DA provides the needed automation for PDK developers to ensure that they have the highest quality before releasing. IC designers can now quickly determine if a particular foundry PDK is going to provide them the performance and power requirements being sought and know what has changed between versions of a PDK. The QA process for a PDK doesn’t have to take weeks using semi-automated methods, now with some automation it can take only hours to complete. Foundries are using the PQLab tool to save time and produce PDK files that are solid.

Posted on

Mentor Webinar Series: Integrating the Systems Engineering Flow

Mentor Webinar Series: Integrating the Systems Engineering Flow
by Bernard Murphy on 10-28-2016 at 7:00 am
Categories: EDA, Siemens EDA

Product lifecycle management is probably not the most gripping topic for most design engineers. You want to get on with architecture, design, verification and implementation. But if you are building products for any safety-sensitive application in a car, a medical appliance, avionics, railway applications in Europe – to name a few – you know that now you have to demonstrate compliance with pretty detailed process standards like ISO26262.

Register for the Webinar

You could do all of this, in principle, by exchanging pieces of paper and emails but that approach quickly becomes unmanageable. More likely you plan to build (or have partly built) your own system of spreadsheets and shared/ revision-tracked documents. You going to need some of that anyway. But integrating design flows and best-in-class design tools to provide the compliance and traceability required by standards like 26262 is complicated by differing needs, processes and data views among tools.

Mentor is offering a series of four webinars (the first has already posted) on what you have to consider (make sure you understand the full scope of the problem) and a better approach to managing the design flow process:

  • Going beyond PLM solutions to manage design change (Oct 19)
  • Simplifying overwhelming project data by putting it into context (Nov 3)
  • System design management simplifies ARP4754A compliance (Nov 10)
  • System design management for automotive functional safety (Nov 17)

While this might be fun project for an internal software team, it can take years to build and get right something this complex. It takes EDA expertise as well as understanding of standards like 26262, so don’t let the IT team tell you they can take care of this. You need something built by experts, not enthusiasts 😎, especially when compliance and safety are determined by the effectiveness of these solutions.

Register Here

Increasing the productivity of an engineering team and improving first-time quality of their end product requires maintaining coordination and synchronization of the information needed between software environments. However, data integration between software tools intended to be used together in a work flow remains challenging. While individual software providers address some challenges, the problem is compounded when workflows employ best-in-class tools contributed by different suppliers.

A true Systems Engineering approach to integration manages relationships between tools throughout design disciplines; coordinates changes, dependencies, and impacts; and integrates with a user’s current tools and flows. In this session, we look at an innovative solution to this problem based on OSLC, extended by the Mentor Graphics approach to incorporate a central organizing structure for data tracking, history, and analysis.
You may sign up for one, several, or all four seminars. Each seminar stands alone.

Mentor Graphics systems experts discuss four unique systems
integration topics, two of which show a way to verify safety certification
efforts, such as ARP 4754A and ISO 26262. You may sign up for one,
several, or all four seminars. Each 30-minute seminar stands alone.

What You Will Learn:

  • A new way to track changes in a design flow – without changing any design
  • tools
  • A way to share information where needed in a structured and organized
  • manner (that’s not a PLM environment)
  • A way to manage relationships among all facets of a design as it evolves
  • A way to easily access legacy material
  • A way to meet standards inspections

Who Should Attend:

  • Systems engineers
  • Requirements engineers
  • Project managers
  • Safety analysts
Posted on

Between Waze and a Thin Hard Place

Between Waze and a Thin Hard Place
by Roger C. Lanctot on 10-27-2016 at 4:00 pm
Categories: Automotive

Car makers, semiconductor companies and wireless carriers are all excited these days about creating cars that can drive themselves. Billions of dollars are being spent on acquisitions and investments in companies and technologies that can make this happen. But there is a fly in the ointment by the name of Waze.

To create cars capable of automated driving, car makers and their supplier partners are having to replicate the functional capacities of the human brain and nervous system including vision systems and networks. In essence, the industry is being forced to create something we might regard as a “thick client” – a sentient car with sufficient storage and processing power to deliver a safe and reliable automated driving experience.

The alternative to the thick client is the “thin client” – in this case a smartphone. The thin client gets the job done by accessing off-board (cloud) resources to facilitate its decision-making. The best search and speech recognition solutions in cars today are either entirely cloud-based or hybrid on-board/off-board systems.

When Audi, BMW and Daimler came together to acquire the map data company, HERE, from Nokia, the intent was clearly to build an automated driving capability upon the foundation of HERE maps. If cars were going to drive themselves sooner or later, they’d need maps on-board and HERE was the big dog of embedded maps in cars.

Much was made at the time of the desire of car manufacturers to preserve their independence from Google and Apple and any other tech industry interlopers. So the HERE acquisition was something of a turf war over ownership of the customer relationship and the technology going into the cars.

The key differentiation between HERE as a source of map data and Google – aside from the ever-present Googlian invasion of privacy – was the fact that HERE actually provides a data set that resides in the car. Arch-rival TomTom also provides a map data set to its significantly smaller customer base of car makers. Google does not provide an on-board map, although it enables chunks of map data to be downloaded on an ad hoc basis.

Much has been made in the press lately of the onset of Apple’s CarPlay and Alphabet’s Android Auto smartphone integrations for cars. The hullabaloo over these increasingly widespread systems in new cars and the aftermarket revolves around the fact that they are creating headaches for car dealers and consumers (according to J.D. Power and Consumer Reports) even as they proliferate and begin to make smartphone navigation projection from the phone into the dashboard screen a reality.

But whether you snap your phone into a mount on your dashboard or connect it to your on-board infotainment system, the prevalence of smartphone navigation generally and Waze in particular is putting pressure on the pricing of built-in navigation systems. More importantly, it will ultimately cause consumers to reconsider buying the built-in navigation system if the price delta is too great.

As car makers lay the groundwork to enable automated driving the need for an on-board map will become increasingly imperative. In fact, the need for an up-to-date on-board map will become more important than ever.

If consumers abandon the idea of on-board navigation in favor of the good enough navigation experience of Waze on a smartphone – the progress toward automated driving will be severely impeded. And the risk is real because Waze is not only good enough navigation, for many it is becoming the preferred source of traffic information and, a dirty little secret, speed traps – or safety zones, as they are euphemistically described in Europe. Some Waze users won’t go anywhere without the app.

Car makers like BMW and Daimler are taking steps to provide for real-time hazard notifications and incremental map updates to match Waze’s perceived advantages. But the challenge extends beyond Waze. Toyota launched an OpenStreetMaps-based projectible smartphone navigation app in the U.S. last year. Apple is steadily replacing TomTom’s maps with OSM in dozens of countries around the world.

Meanwhile, Waze availability in dashboards continues to advance. Ford is expected to offer Waze via its SDLink app integration and Waze is also accessible via MirrorLink.

Waze’s viral marketing and crowd-sourced platform represent a formidable pothole on the path to automated driving for the masses. There are steps auto makers can take to preserve their long-term automation objectives. I will explore this topic in more detail in my keynote at next week’s TU-Automotive Europe event in Munich – http://www.tu-auto.com/europe/.

Smartphones have given us so much. They have the power to save time, fuel and lives on the road – as long as drivers don’t get distracted. They can enable entirely new business models and market opportunities. But good enough solutions don’t cut it when you are trying to transform an industry. Self-driving cars will need an on-board map to get them through thick and thin.

Roger C. Lanctot is Associate Director in the Global Automotive Practice at Strategy Analytics. More details about Strategy Analytics can be found here: https://www.strategyanalytics.com/access-services/automotive#.VuGdXfkrKUk

Posted on

Manufacturing Singularity is Comng!

Manufacturing Singularity is Comng!
by Daniel Nenni on 10-27-2016 at 12:00 pm
Categories: EDA, Siemens EDA

One of the many benefits of blogging is that you get to meet some very interesting people. This time I had the pleasure of speaking with Michael Ford of Mentor Graphics about Industry 4.0 and smart factories. In fact, Mentor has an excellent series of white papers titled “Is This a Manufacturing Revolution?” from their Valor Division, but first a bit about Michael.

Michael spent more than 25 years with Sony Electronics Manufacturing Systems which resulted in the spin out of Valor Computerized Systems Ltd. Valor was a recognized leader of productivity improvement software across the electronics design and manufacturing supply chains that “simulate, optimize, monitor and control the production lifecycle of electronics products, enabling companies to design and manufacture more efficiently, cost effectively and with better quality”. In 2010 Mentor Graphics acquired Valor and that is how Michael arrived at Mentor.

The first question I asked Michael is when will electronics manufacturing come back to the United States? Given the advancement of robotics, artificial intelligence, and cloud computing, manufacturing is now a very small percentage of the electronic product cost equation. In fact, according to Michael, Apple’s percentage cost of manufacturing in China is now about 1%. The answer to my question of course is described in detail in the 8 part white paper series:

Part 1: Stop the Leaking Factory
Part 2: What Does the Industry 4.0 Factory Look Like?
Part 3: The Customers’ Perspective
Part 4: How to Get Started
Part 5: Making the Connections
Part 6: Staying Flexible
Part 7: The ROI of Change
Part 8: Risks and the Future

Michael and I also talked about Industry 4.0 and Mentor’s Open Manufacturing Language specification (OML). You can get a good look at Industry 4.0 from Wikipedia so let’s talk about OML. Earlier this year Mentor launched the OML initiative which is really IoT for manufacturing.

“For some time now we have seen and heard the demand for a comprehensive shop-floor communication standard that is detailed enough to support the next generation of computerization such as Industry 4.0 solutions,” stated Dan Hoz, General Manager of Mentor Graphics Valor Division. “With this initiative, Valor contributes the first step and sets the pace for the revolution in manufacturing for PCB assembly.”

I found this YouTube clip which nicely encapsulates our discussion:

You can read Michael’s blog for more information about OML HERE. The OML community website is HERE.

The challenge of course is legacy manufacturing equipment which is why Mentor came out with a secure plug-and-play IoT device you can read about HERE.

“The Valor IoT Manufacturing solution with the Open Manufacturing Language (OML) should revolutionize today’s automated electronics assembly industry. OML will bring much needed interoperability to the PCB manufacturing industry,” stated Dick Slansky, senior analyst, PLM & Industry, ARC Advisory Group. “Mentor’s plug-and-play, comprehensive, secure networking and connectivity solution is a significant milestone for the mass customization of manufactured electronics.”

Bottom line: The ultimate goal of course is singularity, where machine intelligence surpasses human intelligence and on the manufacturing floor Industry 4.0 is a step in the right direction, absolutely.

Posted on

The Ising on the Cake

The Ising on the Cake
by Bernard Murphy on 10-27-2016 at 7:00 am
Categories: General

Just when you thought you knew all the possible foundations for computing, along comes another one. Forget von Neumann, this approach models Ising machines, systems built on solving a statistical ensemble model of ferromagnetism. The concept is quite simple. Imagine a lattice of magnetic dipoles/spins, each of which can only be in a “north-up” or “north-down” state. The coupling, in various states, when summed over adjacent magnets represents an energy and the goal is to minimize this energy.

As you might expect, this model maps neatly to various kinds of optimization problem. The travelling salesman problem (TSP) is one example, encountered in chip place and route tools, network routing, aircraft and truck routing and many other problems. TSP is considered an NP-hard problem though heuristic solutions are known and widely used. But improving on any of these solutions is always challenging since scaling up parallelism is quickly defeated by exponential growth in combinational complexity as the problem size grows.

While neural net and quantum annealing approaches are also being explored, advances based on Ising modelling have been reported recently. Rather than building spin lattices this approach uses laser pulses circulating through a ring cavity. Pulses are generated from a pumping laser as optical parametric oscillators (OPOs), a particular form of squeezed light. Each of these, above an oscillation threshold, splits into one of two possible phases which can model Ising spins. The ring cavity is designed to allow a fixed number of evenly-spaced OPOs to circulate through the ring at any one time, thus modelling a set of spins.

Next you have to model the coupling between the spins. In one approach, optical taps into the cavity take a small percentage of an OPO, delay it for an integral number of OPOs in the chain and couple that percentage back into the next OPO in line. There are N-1 taps for a cavity supporting N OPOs. This enables modeling a coupling between the i[SUP]th[/SUP] and j[SUP]th[/SUP] spins for any (non-equal) i and j. (The optical tap approach becomes very cumbersome with increasing N, so recent approaches have switched to electronic methods to add delay.)
Of course this ring of OPOs decays over time and the decay rate for any OPO depends on the phase states in the OPO. The decay rate of the system of OPOs can be engineered through couplings to model the energy profile (Hamiltonian) of a target Ising problem. (You’ll have to take that on trust or follow the 3[SUP]rd[/SUP] link below.) Now the OPO system is pumped by a laser, starting below the oscillation threshold. As the gain through pumping is slowly increased, it will eventually reach the lowest point in that profile which is a threshold for oscillation/resonance and that will self-reinforce. This by the way is known as the minimum gain principle, intuitively reasonable but not provably true. Finally, by observing the relative phase state of OPOs, resonances and hence minima in the problem space can be detected.

So there you have it. Technically, I don’t imagine other optimization techniques are in great danger in the near future. This is a very complex technique requiring some very sophisticated control of laser optics, probably not reducible (near-term) to a chip. Still, it does have one very interesting characteristic. All optimization techniques I know start on the problem curve and move around to (hopefully) find the lowest point. This technique starts below the problem curve and effectively moves a global metric (OPO system gain) up towards the curve. By construction the first thing it will hit is the global minimum (at least if the minimum gain principle is valid).

As a footnote, I checked a number of articles on this topic and found all the “popular” articles (Wired, a Stanford report, IEEE Spectrum) ducked any real attempt at explaining the method, which left me feeling cheated. This blog is my attempt to go at least a little deeper. Apologies in advance to experts in the field if I butchered the explanation – feel free to correct me. You can read a lightweight write-up HERE and the arXiv papers I relied on most HERE and HERE.

More articles by Bernard…

Posted on

Automation for managed system-of-systems design

Automation for managed system-of-systems design
by Don Dingee on 10-26-2016 at 4:00 pm
Categories: EDA, Siemens EDA

Anybody who has done any bus & board system design knows the problem. Merchant boards typically have standardized pinouts (after years of haggling in standards organizations) for the backplane bus, and a group of user-defined pins for daughtercard I/O. Homegrown systems usually have a just-as-carefully defined proprietary backplane bus pinout. Once defined, changing a signal name or pin location requires an act of deity.

Or a mistake. Each board design team starts with the pinout table, or if they are lucky they get a connector model in a PWB design tool library. When systems were small, and there were fewer than 20 boards on a backplane, checking interconnects wasn’t too terrible. Every once in a while, someone would miss a pin, or transpose the direction of high-to-low order bits on a parallel signal group. Hopefully that was caught before the smoke test. The offending “odd-man-out” board would be sent back for cut and jump rework, and a revision scheduled.

Systems have gotten huge; in many cases, they are now systems-of-systems. It isn’t unusual to see hundreds of boards with tens of thousands of interconnects including backplane traces, backplane cabling (usually for the user-defined pins), and over-the-top cabling. Boards and cables are parceled out to separate teams, along with some control documents – typically an Excel spreadsheet with the signal tables, or maybe dumb graphics in Visio. The entire system relies on everyone reading the documentation and interpreting it correctly.

The risk of a disconnect somewhere in the system is also huge.

Not to mention there is little (ok, no) ability to do trade-off analysis. Mentor Graphics released the last update to Xpedition with the ability to optimize pins from the board through the IC package – but what happens if that optimization would benefit neighboring boards? That is a very hard change to drive given semi-manual methods such as Excel or Visio.

Dave Wiens, Xpedition Product Manager in the Board Systems Division at Mentor Graphics, sums this up as the contrast between the norm of split & fragment design and managed system-of-systems design. He’s been pursuing a new release of Xpedition for multi-board system design with several goals. Rather than holding projects together with desktop office tools, teams can collaborate on “correct by construction” system design.

Reentering data becomes a thing of the past, and design rules can easily check connectivity across boards, backplanes, and cables, eliminating errors. Change management is built-in with controlled synchronization; users also have the capability to accept or reject changes. Disparate teams on large projects that might talk to each other infrequently have fewer worries about the currency of their design information.


One of the more challenging topics in systems design is thermal verification. Instead of the conservative “rule of thumb”, a multi-board system can actually be modeled in this release of Xpedition with confidence, and recommended changes can be driven across boards quickly. The same goes for signal integrity or mechanical issues.

The strength of Xpedition is its underlying data management infrastructure. This is really about a single design flow for all boards, backplanes, and cables, with everyone working in the same project repository with the same tools. Weeks of manual synchronization are reduced to automation, complete with tips and color coding. Cables can be created in schematic form, then optimized for size and weight using 3D modeling.

Much more detail on this announcement is in the Mentor press release:

Mentor Graphics Launches Xpedition Multi-Board Systems Design Solution for Seamless Multi-Discipline Collaboration

Wiens says he completely understands existing processes are in place, especially on the change management front. He hopes that as users adopt the new Xpedition release, over time older system-of-systems design approaches yield to the increased efficiency of automation. The new ideas have been shaped with the help of lead customers such as ASML, factoring in a wealth of real-world experience. Any customer designing systems with boards, backplanes, and cables should benefit.