webinar banner2025 (1)
Semiconductor Expert Forum

Posted on

eSilicon and SiFive partner for Next-Generation SerDes IP

eSilicon and SiFive partner for Next-Generation SerDes IP
by Daniel Nenni on 08-10-2018 at 12:00 pm
Categories: eSilicon, IP, RISC-V, Semiconductor Services, SiFive
3 Comments

While writing “Mobile Unleashed: The Origin and Evolution of ARM Processors In Our Devices” it was very clear to me that ARM was an IP phenomenon that I did not believe would ever be repeated. Clearly I was wrong as we now have RISC-V with an incredible adoption rate, a full fledged ecosystem, and top tier implementers which now includes eSilicon.

I spoke to Mike Gianfagna and Lou Turnullo from eSilicon about their recent announcement. A small world story, Mike and I worked together at Zycad and Lou and I worked together at Virage Logic. Virage took over the Zycad building so my commute did not change nor did the color of my office. Mike and Lou are very approachable guys with a wealth of experience so if you have the opportunity, definitely approach them.

This announcement is really about SerDes which has changed quite a bit over the years. You will be hard pressed to find a leading edge chip without SerDes inside so this is a big semiconductor deal, absolutely. Earlier SerDes were analog. In an analog SerDes, all characteristics of the SerDes are “hard coded” and cannot be changed. Newer SerDes are more complex and must operate in a wider variety of system configurations. These SerDes are often DSP-based vs. analog.

The eSilicon SerDes is DSP-based. With this architecture you can control characteristics of the SerDes via firmware. This is what the SiFive E2 embedded processor is used for. New SerDes must operate in a wide variety of system configurations – backplane configurations, temperature/humidity extremes, connector types. All this requires configuration of the SerDes equalization functions so the SerDes will match its operating environment so it can deliver the best power and performance.

Bottom line: DSP-based SerDes can be “tuned” to the operating environment whereas analog SerDes cannot. Another interesting application is continuous calibration which is also possible, where the SerDes can be tuned and re-tuned over time to adapt to changes in the operating environment and even changes in the SerDes itself as it ages.

eSilicon and SiFive put out a good press release so I have included it here. You can read more about the SiFive E2 Core HERE.

eSilicon Licenses Industry-Leading SiFive E2 Core IP for Next-Generation SerDes IP
Configurability of industry’s lowest-area, lowest-power core provided optimal solution for eSilicon

SAN MATEO, Calif. and SAN JOSE, Calif. – Aug. 7, 2018 – SiFive, the leading provider of commercial RISC-V processor IP, and eSilicon, an independent provider of FinFET-class ASICs, market-specific IP platforms and advanced 2.5D packaging solutions, today announced that, after extensive review and testing of available options in the market, eSilicon has selected the SiFive E2 Core IP Series as the best solution for its next-generation SerDes IP at 7nm.

eSilicon’s 7nm SerDes IP represents a new breed of performance and versatility based on a novel DSP-based architecture. Two 7nm PHYs support 56G and 112G NRZ/PAM4 operation to provide the best power efficiency tradeoffs for server, fabric and line-card applications. The clocking architecture provides extreme flexibility to support multi-link and multi-rate operations per SerDes lane.

“Today’s high-performance networking applications require the ability to balance power and density to effectively address increasing performance demands,” said Hugh Durdan, vice president of strategy and products at eSilicon. “SiFive’s E2 Core IP allows eSilicon to provide the flexibility and configurability that our customers require while achieving industry-leading power, performance, and area.”

The SiFive E2 Core IP is designed for markets that require extremely low-cost, low-power computing, but can benefit from being fully integrated within the RISC-V software ecosystem. At one-third the area and one-third the power consumption of similar competitor cores, the SiFive E2 Core series is the natural selection for companies like eSilicon that are looking to address the challenges of advanced ASIC designs.

“eSilicon has a successful track record for leveraging the most advanced technologies to develop high-bandwidth, power-efficient IP for ASIC design,” said Brad Holtzinger, vice president of sales, SiFive. “Our E2 Core Series IP takes advantage of the inherent scalability of RISC-V to bring the highest performance possible to the demands of advanced ASICs. We look forward to working with eSilicon on its next-generation SerDes to address these demands.”

About SiFive
SiFive is the leading provider of market-ready processor core IP based on the RISC-V instruction set architecture. Led by a team of industry veterans and founded by the inventors of RISC-V, SiFive helps SoC designers reduce time-to-market and realize cost savings with customized, open-architecture processor cores, and democratizes access to optimized silicon by enabling system designers to build customized RISC-V based semiconductors. SiFive is located in Silicon Valley and has venture backing from Sutter Hill Ventures, Spark Capital, Osage University Partners and Chengwei Capital, along with strategic partners Huami, SK Telecom, Western Digital and Intel Capital. For more information, visit www.sifive.com.

About eSilicon
eSilicon is an independent provider of complex FinFET-class ASICs, market-specific IP platforms and advanced 2.5D packaging solutions. Our ASIC+IP synergies include complete 2.5D/HBM2 and TCAM platforms for FinFET technology at 16/14/7nm as well as SerDes, specialized memory compilers and I/O libraries. Supported by patented knowledge base and optimization technology, eSilicon delivers a transparent, collaborative, flexible customer experience to serve the high-bandwidth networking, high-performance computing, artificial intelligence (AI) and 5G infrastructure markets. www.esilicon.com

Posted on

Desperation Drives Inspiration

Desperation Drives Inspiration
by Daniel Nenni on 08-10-2018 at 7:00 am
Categories: Wally Rhines
1 Comment

This is the tenth in the series of “20 Questions with Wally Rhines”

1978 was a bad year for TI. In April, Intel announced the 8086 followed by disclosures of 16-bit microprocessors from Motorola, the 68000, and Zilog, the Z8000. TI had tried to leapfrog the microprocessor business by introducing the TMS 9900 16-bit microprocessor in 1976. But the TMS 9900 had only 16 bits of logical address space and the industry needed a 16-bit microprocessor for address space rather than performance. In addition, TI had no peripheral chips for the TMS 9900 and tried to overcome that weakness with an 8-bit bus version of the 9900 called the 9980 (an approach that Intel also followed with the Intel 8088) but TI found that any performance advantages of a 16-bit microprocessor were sacrificed with the 8-bit approach (https://spectrum.ieee.org/tech-history/heroic-failures/the-inside-story-of-texas-instruments-biggest-blunder-the-tms9900-microprocessor). Intel overcame that weakness by winning the design socket for the IBM PC with the 8088 despite the performance weakness.

TI also tried to develop a 16-bit TMS 9940 microcontroller with a whole new set of problems resulting in resignation or termination of much of the microprocessor team. I became manager of the TI microprocessor activity more because nobody wanted the job than through personal merit. But I had a different motivation. At the time, I was engineering manager of TI’s Consumer Products Group, heading the design of calculator chips, Speak ‘n Spell speech processors and other miscellaneous devices. That job was located in Lubbock, Texas, which was not my idea of a great location for a 31 year old single male. So Houston, which had some drawbacks, scored far above Lubbock in my plan. Most of my time in Houston was initially filled by exit interviews with all the people who were bailing out of the sinking ship. Fortunately, there were some resilient, smart people like Kevin McDonough, John Hughes, Jeff Bellay and Jerry Rogers (who later founded Cyrix and married Jodi Shelton, Founder and CEO of GSA). John Hughes convened a day-long meeting to debate what would be important after host microprocessors since we had obviously lost that race.

The answer: Special purpose microprocessors. We chose three and then added a fourth one later, and named them the TMS 320, 340, 360 and 380. The TMS 320 was a communications processor, the 340 graphics, the 360 mass storage. Later the TMS 380 was designed for the IBM Token Ring LAN. The first job was to decide what a communications processor, or Signal Processing Microcomputer, as we called it, would be. Ed Caudel spent the next six months analyzing that question and concluded that the distinguishing characteristic was a single-cycle multiply/accumulate instruction (although we required two cycles in the first generation TMS 32010 but made it to one cycle with the 32020). John commissioned Kevin and others from systems groups around the company to write applications using alternative instruction sets. Early on, we found we needed a DSP expert and, fortuitously, our group in Bedford, England had interviewed one named Surendar Magar. Tony Leigh has documented most of the history very accurately. Surrendar quickly determined that the single cycle multiply/accumulate would have to be done in hardware, not software as Ed had hoped. (http://www.tihaa.org/historian/TMS32010-12.pdf(www.tihaa.org/historian/TMS32010-12.pdf).

TI was not the first company to develop a single chip digital signal processor. In fact, it was the fifth. Intel announced one while we were developing the TMS 320 but it incorporated an on-chip 8-bit A/D and D/A making it unusable for most applications. Chi-Foon Chan, Co-CEO of Synopsys, who was working at Intel on the first DSPs, tells me that the poor customer reception of the 2920 caused Intel to kill the enhanced version of the chip, which he was working on, thus keeping the door open for TI.

Despite lots of delays, the TMS 320 was announced at the February 1982 ISSCC with rave revues from people like Ben Rosen, the leading semiconductor analyst. We knew we had a winner but the world didn’t understand digital signal processing. We had to publish books, develop algorithm libraries and promote the technology. Financial analysts paid no attention and neither did our senior management so I found myself giving largely unappreciated presentations at financial and technical meetings as well as in the TI Board room.

We needed some high volume applications and our largest customer was Lear Sigler who was making analog repeaters for under water cables. Hardly a high volume application. We needed consumer products companies in Asia. But our Japanese organization was totally uninterested. Their customers almost always wanted custom chip designs. And then a unique event changed the tide. A group in Canada wrote an application note on how to design a FAX MODEM using a TMS 32010. A group in Australia read the article and built a prototype and sold the design to a Japanese company, Murata.

A Murata engineering manager called the TI Japan office and asked for a quote on the TMS 32010. The TI Product Marketing Engineer had never heard of the TMS 320 but he looked it up in the price book and quoted a $35 price. We had never sold one north of $10 so this was a unique response. The Murata engineer said, “Good. I’ll take 20,000 parts.” From then on, we had no resistance from the TI Japan organization and, in fact, they then designed a derivative named the TMS 320C25 which became one of the highest volume members of the family.

The most strategic discontinuity came later. After years of struggle, we convinced Ericsson to design a TMS 320 into a cell phone. A subsequent need for a cost reduced version of the phone became apparent. We had to combine two ASICs, a TMS 320 DSP and a static RAM into a single chip. “How hard can this be?”, I said. All the parts are already verified. I didn’t understand the laws of verification that drive the need to verify internal state, increasing the amount of verification as the square of the number of gates when you combine chips. I willingly committed to Lars Ramquist, the CEO of Ericsson, that we would do the design quickly. A crash effort resulted and, in parallel, Gilles Delfassy took on a similar task for Nokia.

Fortunately, the chips worked and TI grew the wireless baseband MODEM business to something approaching $4 billion per year. The subsequent step was even more critical. To do similar low cost designs for all the other producers of cell phones (and other applications like hard disc drive controllers), we needed to combine our ASIC library with our embedded DSP. Everyone told me that this would be suicide. ASIC’s were sold as cents per gate while DSP’s had high gross margins. But Krishna Balasubramanian (known as Bala) and I decided to combine the ASIC and microprocessor business into one group under Rich Templeton. A good decision. Success followed, DSP-based technology became nearly half of TI’s revenue and Rich eventually became Chairman and CEO. In between, Tom Engibous leveraged the technology to create a wide variety of businesses while building TI’s position in analog. In 2017, TI became the most profitable of the major semiconductor companies in the world at 41% operating profit.

The 20 Questions with Wally Rhines Series

Posted on

Living on the (IoT) Edge

Living on the (IoT) Edge
by Tom Simon on 08-09-2018 at 12:00 pm
Categories: EDA, IoT, Siemens EDA

The phrase “where the rubber meets the road” is especially apt when it comes to discussions about the Internet of Things. The obvious interpretation is that dissimilar things are being put together in a mutually dependent fashion. When I hear the phrase I always think of the things that can go wrong, such a tire sliding instead of sticking to the road. In the world of IoT development there are plenty of parallels. Most often we are talking about dissimilar worlds – physical and digital, and the challenges of combining them. Just as in tire (or road) design, there are plenty of limitations that make the task of building effective IoT devices more difficult.

The classic model is for an IoT edge device to have one or more sensors, on-board processing power and the means to connect to the internet – usually wirelessly. All the familiar limitations apply, such as low power requirements, performance/cost tradeoffs, packaging, etc. The first step is to develop a proof concept, which, while useful, may omit the evaluation of many key performance characteristics. So, what happens next? This is the question that Mentor seeks to answer in their recent white paper entitled “Proof-of-Concept: The Day After”, by Jeff Miller, Product Marketing and Strategy.

In the white paper, Jeff takes us through the steps of development for a tank fluid level monitoring system. This would have wide applicability in breweries, wineries or other beverage facilities, for a start. For instance, it could be used to detect if fluid levels were dropping due to a leak. Mentor’s example system consists of a pressure sensor which could then be used to infer the height of fluid above the sensor. It has an analog to digital converter that is connected to a processor. There is also an RF transmitter to provide internet connectivity. In the proof of concept, that they prepared prior to the prototype stage, they used a voltage reference instead of the actual pressure sensor. In the prototype, there are a number of supporting circuits, including an oscillator, PLL and clock which is used by both the processor and the ADC.

For the prototype, they used a MUX to add the option of including a temperature sensor in future versions. In the whitepaper, they go through each step to design a fully working system. To ensure high sensitivity they employed a Wheatstone bridge to help measure the change in resistance in the sensor. They instantiated all the elements of the design and then performed simulations. They opted to use an ARM Cortex M3 instead of an M0. This was done mostly to provide more flexibility in the final system, but was easily possible because the development IP for both processors is available under the ARM DesignStart program. They used the CodeBench development system which also supports both processors.

With the software written, a system simulation is possible. The whitepaper shows the steps involved in this. Lastly the communication block is brought in. With bidirectional communication, cloud services or a web front-end can be implemented. Also over the air updates would be possible with bidirectional communication.

To complete a prototype project like this, a suite of tools is needed that covers custom IC design, PCB, embedded software, and system simulation. Mentor offers a complete design flow like this that is tailored for the needs of IoT Edge Device developers. That coupled with the easy access to ARM processors, suitable for these kinds of applications, dramatically simplifies the design and development process. At the end of the day all of the system’s the performance characteristics need to be fully optimized to develop a competitive product that provides differentiation in the marketplace. The detailed whitepaper is available for download on the Mentor website.

Posted on

Machine Learning with Prior Knowledge

Machine Learning with Prior Knowledge
by Bernard Murphy on 08-09-2018 at 7:00 am
Categories: AI
7 Comments

I commented recently on limitations in deep learning (DL), one of which is the inability to incorporate prior knowledge, like basic laws of mathematics or physics. Typically, understanding in DL must be inferred from the training set, which in a general sense cannot practically cover prior knowledge. Indeed one of the selling points of DL is that it doesn’t need to be programmed with algorithms; intelligence is inferred entirely from these training sets through a form of optimization. This works well when the training set is large enough to cover the most important aspects of an objective but not so well when other variations are introduced, such as rotations or movement. That’s a rather big limitation.

The brute-force way to solve this problem is to expand the training to cover more variations. For rotations, instead of N training samples, perhaps you need 108*N to cover 3 axes of rotation and 36 orientations in each axis (0, 10, 20, … degrees). That’s a massive increase in the number of training samples you have to gather and label. For movement, how do you train ML to determine what will happen to all the other balls on a snooker table when you strike the cue ball? Using training to rediscover what Newton codified over 300 years ago seems like a huge waste of ingenuity.

The best way to handle these variants is to use prior knowledge in math and physics, combined with ML. In computer graphics we infer the impact of rotations on a view using algorithms based on math formulae. In the snooker example, we use Newton’s laws of motion, again encoded in algorithms. Those laws/algorithms capture in a few simple equations what would otherwise require perversely large training sets in the pursuit of algorithm-free recognition. So much for banishing algorithms.

One paper from Stanford uses an understanding of projectile mechanics to identify and track the path of a pillow thrown across a room. As far as I can tell, they model recognition in short segments of the path first, then use constraints to penalize complete paths which don’t follow the expected second-order equation of motion. In effect they are using a classical formula as a constraint in the structure of a neural net. This work shows some promise for learning in such contexts with only weak supervision.

Another interesting paper from the Institute of Science and Technology in Austria takes a different approach to build (through ML) models for safe operating conditions for robots (such as ranges of moving arms or legs) based on learning simple formulae from operations in a known-safe range. These formulae then allow extrapolations beyond the trained range. They describe this as “a machine learning method to accurately extrapolate to unseen situations”, in effect building its own prior knowledge in the form of simple linear equations through experiments in a more bounded space.

A third example from the Sorbonne University provides an illustration of forecasting sea-surface temperatures (SSTs). Surface temperature data is already generated through satellite imagery, providing vast amounts of current and historical information. Forecasting how this will develop requires evolving this data forward in time based on partial differential equations (PDEs) and is the basis for the standard approach to forecasting using numerical solution methods. This research team instead uses a CDNN with discretized version of the PDE equations to guide weighting in time-propagation in the net. Their work shows promising results in comparison with numerical methods and some other NN approaches.

So, two methods which reduce/discretize prior knowledge (physics) to mechanisms which fit into existing deep learning architectures through weighting and one which derives simple equations to form its own “prior” base of knowledge. Intriguing directions, though for me the Sorbonne approach seems the most extensible since almost all problems in physics can be reduced to PDEs (though I guess the geometry of present-day neural nets will limit application to 2 dimensions, plus time).

Posted on

Enhancing Early Static FSM

Enhancing Early Static FSM
by Alex Tan on 08-08-2018 at 12:00 pm
Categories: Aldec, EDA, FPGA

Finite state machines (FSMs) are widely adopted as part of reactive systems to capture their dynamic behaviors using a limited number of modes or states that usually change according to the applied circumstances. Some terminologies are frequently used to describe the FSM characteristics: state, transition, condition and sequences. A state defines the behavior and may produce action or output; a transition describes change involving of state(s); a condition allows transition to occur; and a sequence is comprised of a set of two or more transitions.

FSM can be categorized in term of its output transition. A deterministic FSM, if it has only one transition to next state; while a non-deterministic FSM has more than one possible next state for each pair of current state and input vectors. For practical applications, FSMs can be grouped based on how their outputs are defined. Moore FSM is the state machine whose output are a function of the current state only, while a Mealy FSM has its output and next state dependent on both the current state and input(s).

Many of the FSM practical applications such as in communication systems, crypto-processing, visual processing and as part of the embedded controllers are implemented using various schemes, from a static to be more reconfigurable styles –depending on if it is internally initiated (self-reconfigurable) or driven by external reconfiguration events.

Aldec and Verification of FSM
As an industry leader in Electronic Design Verification, Aldec’s solutions include a verification strategy in ALINT-PRO™ that is comprised of three key elements: static structural verification, design constraints setup, and dynamic functional verification.

The first two steps are executed in ALINT-PRO, while dynamic checks are implemented via integration with Aldec’s simulators Riviera-PRO™ and Active-HDL™ (ModelSim® is supported) based on the automatically generated testbench.

Previously, designers had to deal with debugging the FSM late in the implementation stage such as by using Riviera-PRO advanced verification platform as illustrated in the following diagram:

“Most issues designers face when implementing FSM-based control blocks tend to be caught during RTL-signoff, using coverage-enabled simulation and/or formal property checking methods,” observes Sergei Zaychenko, Aldec Software Product Manager.

In response to the increasing verification challenges for complex designs, Aldec has expanded the rule-checking capabilities of its popular ALINT-PRO™ tool. it has enhanced the tool to include twice as many FSM checks and new graphical representations to aid with state explorations.

“Aldec ALINT-PRO can discover many complex FSM issues long before test stimuli are available. With the latest version of ALINT-PRO™ users can do FSM-level verifications that will save them a significant amount of verification time further on down the line,” added Sergei.

An early FSM static validation can be achieved with ALINT-PRO by taking a two-step approach: first by performing an FSM exploration using FSM graphical environment, and then by applying a complete list of FSM targeted rule checks. ALINT-PRO extracts FSM from a design code and presented in FSM viewer.

To facilitate a better exploration of the extracted FSMs and reveal FSM-based design issues, ALINT-PRO (v2018.07) has an enhanced GUI incorporating checks based on the 25 newly added FSM design rules covering advanced aspects and typical errors. The FSM window acts as the FSM debugging tool that generates state transition graph with color-coded notation signifying transitions among object states. It differentiates a deterministic, non-deterministic, beginning and ending state. Designer could trace a sequence and switch data representation mode from graph to tabular format.

FSM Static Checks and Coding Issues
An event-driven system programming tends to use heavily nested conditional constructs (if-else, switch-case) in order to implement various responses due to a triggering event or a combination of past events in the system. FSM adoption is intended to reduce potential clutters caused by the complex number execution paths, the multitude of variables and the many transitioning between different modes of execution.

ALINT-PRO identifies FSM related bugs including unreachable, deadlockand redundantstates which are the common types of shortcomings faced by designers while capturing the FSM RTL codes. An unreachablestate is not reachable from any initial state of the FSM but has output to transition; while a deadlockstate is reachable but once entered indefinitely unable to change its state; and a redundantstate has neither input or output transition from/to.

The FSM type compliance check can be targeted to a pre-defined set of requirements such as to satisfy two combinational and one sequential processes. Additional FSM implementation specific checks such as those related to reset control, FSM state enumeration, state encoding type allocation (binary, gray, onehot, etc.) and other FSM attributes declaration (e.g., fsm_encoding=…) are complementing the over 40 new rules designated for improving the VHDL and Verilog/SystemVerilog RTL coding quality.

To generate a highly reliable design, best-FSM-design-practice type of checks can also be applied. This includes good naming conventions (describing more than one FSM in a single design unit, unique names for states of different FSMs, etc.); FSM should recover in Reset state in case of FSM state variable corruption and use case default with unconditional transition to FSM reset state. Reset state transition handling is crucial such as in autonomous sequential modules of a complex digital system.

Workspace, Project and Heterogeneous Design
In ALINT-PRO environment, the RTL codes, constraints and properties are captured into workspace and projects. An enhanced setup automation for complex Xilinx Vivado and ISE projects is made in 2018.07 release. The extension enables a “push button” flow for early static verification of IP-intensive Xilinx FPGA-targeted designs. A workspace is automatically organized to deliver hierarchical and incremental DRC and CDC analysis, allowing the designer to concentrate on checking custom RTL blocks, while preserving accuracy at the boundaries of IP blocks. Unless an IP block is re-configured in the original design environment, it is only being analyzed once, and the extracted block-level timing constraints are automatically promoted to enable higher level verification of the main design.

To find out more about ALINT-PRO, please check HERE

Posted on

Tesla Leap of Faith (or the Adoration of Elon Musk)

Tesla Leap of Faith (or the Adoration of Elon Musk)
by Roger C. Lanctot on 08-08-2018 at 7:00 am
Categories: Automotive
1 Comment

The Reverend Elon Musk, CEO of Tesla Motors, held forth to his flock on yesterday’s earnings call. Musk described at length his efforts to lead the company out of production hell. The lengthy session highlighted the challenges facing the company, which posted its greatest quarterly loss ever, and was emblematic of the typical high-flying technology entrepreneur making a big bet against long odds.

Unique to Tesla, though, is the commitment it seeks from both investors and the drivers of its cars. In fact, Musk went so far as to insist that the media and analysts must commit more fully to the company’s vision for achieving mass electrified, sharable vehicle autonomy – or risk being described directly as idiots or worse.

He has no patience for scary headlines which tend to follow the relatively infrequent fatal crashes of Tesla vehicles. He confirmed on the call that the amount of recorded automated driving that occurs in autopilot-equipped Tesla vehicles tends to decline after such reports only to recover later. In Musk’s eyes, these discouraging downturns in autopilot usage only further delay the arrival of full autonomous operation – i.e. the promised land.

Musk also takes issue with the inclination of the press to blame-shame Tesla for pre-emptively releasing data implicating drivers in their own autopilot misadventures, fatal or otherwise. Musk did not mention the growing number of crashes (after all, there are more Tesla’s on the road), fatal and otherwise, that appear to be the result of autopilot shortcomings.

This is where the leap of faith is most difficult to take. Musk and Tesla were on solid ground two years ago (can it be that long?) following the fatal Florida crash. Tesla took multiple steps in response to that event including:

  • Parted with camera system supplier Mobileye
  • Laid blame for the crash upon a misuse of autopilot (on a non-limited access highway)
  • Updated autopilot software and geo-fenced its usability
  • Conducted a study of vehicle data – sharing the results with the National Highway Traffic Safety Administration – demonstrating that vehicle crashes were substantially reduced in Tesla’s equipped with autopilot

Ultimately, the scope of Tesla’s geo-fencing expanded such that it was nearly unlimited thereby completing the transition away from Mobileye. Still the system remains ill-suited to secondary roads and side streets with intersections.

Intermittent crashes continue including a fatal crash in California, once again blamed on driver inattention, along with non-fatal crashes with parked vehicles on highways. One crash stands out from the rest, though, having occurred shortly before the fatal Florida crash.

The crash occurred in China and Tesla was reportedly unable to retrieve the vehicle’s data logs due to the severity of the crash. As a result, the fatal China crash between a Tesla and a truck parked in the high speed lane of a highway, remains unresolved along with pending legal action from the family of the driver.

Given the fact that the China crash occurred before Tesla modified its automated driving system software, it is difficult to conclude whether any findings from that crash will be relevant to understanding how autopilot, as currently configured, functions today. More importantly, in spite of the availability of video from the vehicle, Tesla asserts that it is not possible to conclude that autopilot was operating at the time of the crash.

Infrequent though they may be, Tesla crashes continue to occur. Operating a Tesla in autopilot mode – and, in fact, investing in Tesla – requires a leap of faith. You have to believe in Tesla and Musk’s vision of autonomous operation.

Tesla has not been the only autonomous vehicle operator to experience a fatality. Uber suffered the same fate, though the fatality was a pedestrian not a passenger or driver. In the Uber crash in Tempe, Az., a number of factors were blamed including driver inattention and a malfunctioning or inactive automatic braking system. Some astute observers also noted that a thermal sensor might have aided detection of the pedestrian on the dark road.

Tesla famously makes use of ultrasonic, radar and camera sensors supported by Nvidia processors to analyze and fuse the incoming information and enable automated driving. Also famously, Musk disparages the use of Lidar sensors, which some believe might have prevented both the Florida and China fatal crashes.

An Israeli startup, BrightWay Vision, asserts that its image gating technology, for enhancing camera-based sensor inputs, might have also prevented the China crash. The gating technology might have been able to overcome what is thought to have been radar interference caused by the picket fence-like highway barrier on the left side of the vehicle.

The bottom line: To buy a Tesla or its stock or to operate a Tesla in autopilot mode is to take a leap of faith. It is a leap of faith in the gigafactory strategy, the fast charging network, SpaceX, increases in battery power density, reductions in cost, increases in production and the pursuit of profitability. It is a leap of faith in a CEO who sleeps on the factory floor and occasionally indulges in Tweet storms.

Mainly, it is a leap of faith that the best and most ethical decisions are being made regarding vehicle autonomy. If Musk were CEO of any other car company he would long ago have been crucified by investors, regulators and customers for the handful of fatalities that have occurred in Tesla vehicles. Musk spent a fair amount of time on Wednesday’s call apologizing for his rants and insults from the previous earnings call. What Musk really needs to do is thank his customers – especially those who have adopted autopilot – for their leap of faith.

Posted on

Timing Closure Techniques for SOCs with Embedded FPGA Fabric

Timing Closure Techniques for SOCs with Embedded FPGA Fabric
by Tom Simon on 08-07-2018 at 12:00 pm
Categories: Achronix, eFPGA, FPGA

Once the benefits of using an embedded FPGA fabric are understood, the next question is about how timing closure is handled between the ASIC and the eFPGA blocks. First let’s look briefly at the advantages. By moving the eFPGA on to the SOC die, tons of I/O logic and the need for any package and board interconnect will vanish. Package and board routing create messy signal integrity and timing issues that require SerDes and bus protocols to tame. The added benefits also include reduced power – less logic to drive – and much lower latency. Instead of using a pair of SerDes, now the ASIC and eFPGA talk over direct wired signal nets.

While talking to Volkan Oktem, Achronix’s Senior Director of Product Applications, about the topic of timing closure with eFPGA I learned that there are two approaches for connecting the eFPGA to signals on the ASIC side. The easiest way is to use what they call “simple timing mode”, where there is a register on each net to help timing handoff at the eFPGA boundary. Of course, if you want to have the eFPGA output a signal off-chip, the SOC can include any necessary interfaces. But, the eFPGA can be thought of as just more logic – that just happens to be programmable.

In simple timing mode, the eFPGA and ASIC regions can be timed independently of each other. Constraints can be used in the eFPGA synthesis to ensure external timing meets spec. Then the ASIC just sees the eFPGA as a well-behaved block on the chip, like any other. For simulation, there is a gate level netlist with timing back annotation for the eFPGA so that top level timing can be verified.

If designers want to get rid of the extra clock cycle delay required by the intermediary registers, they can use the “advanced timing mode” which allows a direct connection from the ASIC logic to the input or outputs in the eFPGA. The catch is that the timing on these paths is now shared between the ASIC and the eFPGA. Achronix supplies a methodology that facilitates timing closure when using the advanced timing mode. First the user performs STA on the entire design, including the ASIC logic and the eFPGA logic. Next Achronix supplied scripts are used to extract the ASIC and eFPGA portions of all the nets that cross the boundary between the two parts of the design. Then these delays are passed as constraints to the ACE eFPGA tools so the eFPGA can be synthesized to meet timing. If there is more than one application for the eFPGA this process can be repeated for each.

After an iteration of the above process, designers can see if timing it met. If not, additional optimization or clock period adjustments can be made to close timing. While there is more effort required to use the advanced timing mode, it may well be worth it. Adding an eFPGA block to the floorplan otherwise is not much different than adding any other IP block. There are a few caveats, such as through routing is not allowed. So, placement of the eFPGA should take in to consideration the top level ASIC routing needs. There are no special supply or clock requirements.

An interesting side-note that came up in my conversation with Volkan was that for debug and test it is possible to program part of the eFPGA with special testers and debugging aids. This can help improve testability and visibility for the eFPGA and also the surrounding ASIC logic.

Volkan also pointed out that for some customers the goal is just to make a portion of an SOC programmable, adding for instance the flexibility being able to make post silicon logic changes. This affords the ability to refine and adapt functionality much later in the development process. However, he explained that sometimes their customer’s goal is to create special a purpose FPGA device, one that is tailor made for a specific application. This can have a number of advantages over off the shelf FPGA parts.

With a straightforward integration process, either with interface registers or through direct connection, the addition of programmability to an SOC design can be tremendously beneficial compared to off chip FPGAs or going without programmability altogether. Volkan has been working on developing new tools and documentation to make this process easy and efficient. There are resources on the Achronix website that go into much more detail and further explain clocking options and the timing closure process.

Posted on

Timing Channel Attacks are Your Problem Too

Timing Channel Attacks are Your Problem Too
by Bernard Murphy on 08-07-2018 at 7:00 am
Categories: IP, Security, Tortuga Logic

You’ve heard about Meltdown and Spectre and you know they’re really bad security bugs (in different ways). If you’ve dug deeper, you know that these problems are related to the speculative execution common in modern processors, and if you dug deeper still you may have learned that underlying both problems are exploits called timing side-channel attacks which depend on differences in timing between different operations, for example in retrieving data from a cache on a hit or miss. From there on for many of us, certainly for me, the details get a lot harder to follow.

But you probably thought (as I did) “this is a problem for the CPU guys, not my concern”. Bad news – you need to worry about this too. Timing channel exploits are not just for CPUs and caches. Timing exploits are possible through NoCs, in accelerators, between accelerators and their caches, pretty much anywhere an attacker might probe for hints to privileged information. We can’t just punt this to someone else; we need a deeper level of understanding.

So I talked to Jason Oberg, CEO of Tortuga, who has a PhD in timing channels; he managed to drag me through the basics. I say “drag” with feeling because just understanding the basics was hard; trying to reason about whether you have timing channel problems in a large design may earn you an extended stay in a sanitarium. They’re hard because this class of problem inherently spans multiple instructions and requires you to look at both software and hardware together. To see why, Jason shared a couple of the “easier” examples. These assume a victim process and an attacker process can run on the same system (under a VM OS for example).

First, think about a public-key cryptography system – could be in hardware or software. This depends on calculating a number to a power (the key) then taking the modulus of the result to some base. The most efficient standard way to do this uses a square-and-multiply algorithm, progressing over bits in the key. Square and multiply operations take different times and use of these operations differs for 0 and 1 bits in the key, therefore total time taken for the operation (if you have access to a sufficiently accurate clock) reveals the number of ‘1’ bits in the key. So start a timer, run the encryption, stop the timer and read the result. Since the key won’t change, repeat with multiple carefully-selected plain-text inputs, analyze the timing variations for these inputs and you can reconstruct the key one bit at a time.

The crypto-experts figured this out and one came up with a better algorithm called Montgomery’s ladder, which is immune to this kind of attack because it balances operation times for 0 and 1 bits. But then the experts found another way to force timing variations, through data retrieval times from the cache. Hang on to your hats – this is going to get complicated. One approach starts with something called a Prime and Probe attack. Before running the encryption test, the attacker primes the cache by filling with its own cache lines. Then the attacker times an encryption test, as before. Subsequently the attacker swaps back in and checks if any of the cache lines it preloaded have been evicted by the encryption. If they have, each such operation would have taken longer to execute in the encryption.

Now back to Montgomery’s ladder. This also steps through the key bitwise and performs different operations in each case depending on whether the bit is 0 or 1. But because of the Prime and Probe setup, now timing is sensitive to memory indexing from the ladder operation in the victim process and that indexing is still based on progressive bits in the key. From there you just continue to run analyses over multiple plain-text samples, analyzing the timing variations for these operations, from which you can ultimately extract the key.

Reminder – these are just examples; nothing about them is particularly restricted to CPUs, caches or encryption. Timing channel vulnerabilities can happen all over the place, as I mentioned earlier. And you can’t figure out where you might have such a problem without looking at hardware and software together. Formal and other standard security tools really can’t help. Even thinking about where you might have such problems can be difficult. You probably should talk to Tortuga who have a strong background in this domain and have built tools particularly around finding timing channel problems.

Posted on

Cadence Update on AMS Design and Verification at #55DAC

Cadence Update on AMS Design and Verification at #55DAC
by Daniel Payne on 08-06-2018 at 12:00 pm
Categories: Cadence, EDA

As a blogger in the EDA industry I get more invitations to meet with folks at DAC than I have time slots, so I have to be a bit selective in who I meet. When the folks at Cadence asked me to sit down and chat with Mladen Nizic I was intrigued because Mladen is so well-known in the AMS language area and he’s one of the authors of, The Mixed-Signal Methodology Guide: Advanced Methodology for AMS IP and SoC Design, Verification, and Implementation. You can buy this book at Amazon for just $115.00 and you’re sure to get a great ROI for the time spent reading it.


Prior to Cadence you find that Mladen worked at both Silvaco and Anacad, so he has a rich history in TCAD and circuit simulation tools.

Q: What are the trends with AMS simulation these days?

For AMS simulators we see that the performance always keep improving, from SPICE-level all the way up to digital. In my recent focus in AMS methodology, we are trying to leverage simulation to do better verification. Verification planning and managing your simulations for analog are now more important, because we need to be smart with simulation.

Model-based verification is becoming mainstream in Mixed-signal. Now with Real Number Modeling in Verilog and System Verilog designers are picking these languages. AMS modeling is a challenge, and it can be approached either top-down or bottom-up.

More engineers are becoming modeling specialists, as they know circuit design, CAD tools and verification approaches. They are asking themselves, what needs to be modeled?

Q: What are the challenges of modeling of AMS blocks?

To accurately model the characteristics of an analog block does require some circuit design understanding, so in most cases it takes a team to create a model, then compare the model against specs or other circuit results.

Q: Have AI or ML techniques been used much for AMS modeling?

ML may provide some help to automate the process of moving a transistor-level netlist up to a behavioral model.

Cadence has templates to help build models more quickly, and the designer needs to know how much detail and accuracy is really needed. It’s the classic benefits versus investment, so don’t over-model and don’t spend too much effort in creating models.

Q: Who on the team should be creating AMS models?

Well, forcing analog designers to do modeling may not work.

Analog designers are changing to adopt modeling in order to meet shorter time to market demands, and there is now more willingness to look at new methodologies.

Q: How should I go about learning AMS modeling?

There are Design Services for learning modeling, plus an IP team can deliver most AMS blocks requested. Training is also available, take a look at the standard courses from Cadence Education Services.

Q: What is happening on the language standards front?

We have both Verilog-AMS and SystemVerilog (getting Extensions to RNM) . Cadence is involved in standards committees and SystemVerilog AMS will become a standard in about 2020 and that process is under IEEE control.

Q: Is cloud-based EDA going to work this time?

In the cloud we see companies mixing and matching their simulation runs, both private and public clouds. Tasks that take the most time fit the cloud model quite well: library characterization, MC, validation or regression. All of the key apps are ready on the cloud today.

Related Blogs

Posted on

Synopsys Offers First Single-Vendor Comprehensive Photonic IC Design Flow

Synopsys Offers First Single-Vendor Comprehensive Photonic IC Design Flow
by Daniel Nenni on 08-06-2018 at 7:00 am
Categories: EDA, Synopsys

Synopsys has a long history of being a thought leader and it’s not surprising to see the company jumping into the forefront of new technologies. For decades, I’ve been steeped in electronic IC design and it caught me by surprise to find that Synopsys had been quietly working on filling out their portfolio in the optical design solutions space. This first caught my attention with Synopsys’ 2014 acquisition of Brandenburg GmbH, who were known for their LucidShape product. LucidShape is used for design and simulation of automotive lighting systems. My assumption at the time was this was a move to help bolster Synopsys’ position in automotive markets.

What I didn’t realize was that Synopsys had already made two other acquisitions in the optical-space: Optical Research Associates (ORA) in 2010 and the RSoft Design Group (RSoft) in 2012. It turns out that Synopsys was already well on its way to building arguably the largest and most experienced optical design automation and services organization in the world. The ORA acquisition brought Synopsys decades of optical design experience (the company was originally founded in 1963), while the RSoft business, which released its first software package for the integrated optics industry in 1990, brought Synopsys into the realm of photonics and Photonic Integrated Circuits (PICs) with a full catalog of powerful optical system-level and device-level simulation tools.


Most recently, Synopsys acquired PhoeniX Software, a leading PIC and MEMS implementation tool provider. RSoft and PhoeniX also brought Synopsys decades of experience in photonic CAD and design, having their origins in the very early 1990’s.

In case you are wondering to what purpose Synopsys is doing this, I should note that the companies that now make up the Optical Solutions Group of Synopsys are already bringing in significant revenues. Strategically, this is just the beginning and it’s coming at just the right time. The IoT, 5G, big data, artificial intelligence, autonomous self-driving vehicles, and quantum computing are all on the cusp of exploding onto the market and they all have one thing in common: an insatiable need to be able to move and process huge amounts of data, further accelerating the need for optical data communication networks and data center infrastructure.

Therein lies an inflection point for Synopsys. Photonics (especially integrated photonics combined with integrated electronics) holds the promise of moving orders-of-magnitude more data at orders-of-magnitude faster speeds with — catch this — orders-of-magnitude less power! In less than a decade, Synopsys has brought in hundreds of person-years of optical experience and is marrying that experience with some of the best EDA tools in the industry.

With the PhoeniX acquisition, Synopsys has filled in an important technology gap and is now the first supplier to be able to offer a full front-to-back PIC design flow with all tools coming from one company. They can now address everything from system-level optical systems through fully integrated photonics on a chip, all from one company. No one else in the industry can offer this today. The obvious benefit to users is that you can expect the design flow to work well together and, if it doesn’t, there is no finger pointing back and forth between vendors. You have one company to hold accountable. On a more positive note, Synopsys is able to work all of the pieces to make for a better flow, which is important at the early stages of a technology when things are rapidly changing.

As a quick overview, consider the following PIC design flow from Synopsys:


Not only does Synopsys have the most complete photonics and optical solutions offering, but they also boast the most comprehensive PDK support for photonic foundries and package suppliers. Synopsys supports over 30 PDKs available on a variety of photonic platforms such as Indium Phosphide, Silicon, Silicon Nitride, Silicon Germanium, Polymers, etc. The tool flow also allows designers to add their own custom building blocks to any technology to take advantage of the best of both worlds (custom and pre-characterized PDK building blocks).

Consider also that photonic systems usually require some type of electronic control. Who better than Synopsys, with their strengths in EDA, IP, and software solutions, to combine these domains with photonics? New markets can take a while to sort themselves out. Photonics and how it combines with electronics will be no different, but with fast-growing markets like those already mentioned, and the technology Synopsys is bringing to bear, you can start to see a real powerhouse emerging for next-generation designs.
See also:

Synopsys Optical Solutions Group Home Page
Synopsys Driving the PIC Revolution Datasheet

A big thank you to my friend Mitch Heins of Synopsys for his contributions to this article.