Bronco Webinar 800x100 1

Why IP Designers Don’t Like Surprises!

Why IP Designers Don’t Like Surprises!
by Daniel Nenni on 03-13-2020 at 6:00 am

IPDelta SemiWiki

If it’s your job to get a SoC design through synthesis, timing/power closure and final verification, the last thing you need are surprises in new versions of the IP blocks that are integrated into the design. If your IP supplier sends a new version, the best possible scenario is that this is only a small incremental change from what you had before, fixing only those issues that are in the way of final tape-out.

What you really don’t want are unhappy surprises in, for instance, a new Hard IP release. Suppose you requested some sleep-mode power-modeling improvements to be made as the original version showed some doubtful values for several process corners. The new IP release comes in and indeed now all process corners show consistent trends for sleep-mode power usage. But to your horror also all timing characterisation was updated, setting your design closure back by several weeks.

Were the delay modeling updates valid at all? If so, and had you known about them to begin with, the impact would have been studied on a sub-component; workarounds and synthesis adjustments would have been developed before applying a re-run of the entire design.

The problem with IP releases is often simply not knowing what is in there. In particular over time, as subsequent improvements to IP blocks are delivered, these incremental changes need be just that: incremental. Anything else carries the risk of breaking the iterative improvement synthesis cycles that take the design closer to final verification.

A new tool called IPdelta™ has been released by Fractal Technologies to address just this problem of identifying what has changed from one IP revision to the next.

IPdelta
When new IP is received an incoming inspection needs to be performed. Part of this task is to verify that the IP is internally consistent and complete and meets the quality requirements agreed with the IP supplier. This task is typically done by Fractal Crossfire™, the industry-standard tool for IP qualification. If the IP release is intended to replace a previous version in a design, IPdelta™ must be used on top of Crossfire ™ to bring out the changes introduced in the new version.

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

ABOUT FRACTAL
Fractal Technologies is a privately held company with offices in San Jose, California and Eindhoven, the Netherlands. The company was founded by a small group of highly recognized EDA professionals. Fractal Technologies is dedicated to provide high quality solutions and support to enable their Customers to validate the quality of internal and external IP’s and Libraries. Thanks to our validation solutions, Fractal Technologies maximize value for its Customers either at the Sign Off stage, for incoming inspection or on a daily basis within the Design Flow process. Fractal Technologies goal is to become the de facto IP & Library Validation Solutions Provider of reference for the Semiconductors Industry, while staying independent to keep its intrinsic value by delivering comprehensive, easy to use and flexible products.


The Story of Ultra-WideBand – Part 4: Short latency is king

The Story of Ultra-WideBand – Part 4: Short latency is king
by Frederic Nabki & Dominic Deslandes on 03-12-2020 at 10:00 am

The Story of Ultra WideBand Part 4

How Ultra-wideband aligns with 5G’s premise

In part 3, we discussed the time-frequency duality or how time and bandwidth are interchangeable. If one wants to compress in time a wireless transmission, more frequency bandwidth is needed. This property can be used to increase the accuracy of ranging, as we saw in part 3. Another very interesting capability enabled by this time-frequency duality is the possibility to reduce the latency in systems. But first, a primer on latency and how it affects wireless connectivity.

As engineers, we understand latency as the time interval between a triggering action and its response. From a wireless link point of view, this is the time delay between sending a frame of data and receiving it. But consumers have a visceral reaction to latency. Gamers playing combat and sports games experience latency as the lag between pressing a button and seeing the expected action on the screen. This delay can be a matter of in-game life or death! Monitors and peripherals are being aggressively marketed with reduced latency (e.g., 240 Hz refresh rate gaming monitors), and as a result, wired peripherals are surprisingly still ubiquitous in the gaming circles. The wire, as old a contraption as one can remember, remains undisputed with regards to latency.

The quest for latency is intensifying today, as applications that are more sensitive to latency become mainstream. For example, designers and gamers wearing augmented reality (AR) or virtual reality (VR) headsets experience latency as the disconcerting lag between their motions and the visual response. AR and VR make users prone to motion sickness at the slightest onset of latency. Moreover, home theater owners curse latency when the characters’ lips on screen go out of sync with their voices, and while recorded video can be carefully delayed to calibrate out the latency, feeds that require live intervention cannot benefit from this tactic. This wireless latency problem touching live interactions manifests itself as easily as when typing on your smartphone and seeing the keys move out of synch with the keys’ audio feedback coming through a wireless headset. Some phone makers will hide this limitation by having the keyboard audio feedback not come through the wireless headset. Ironically however, using a now defunct audio jack on an antiquated phone with a barebone wired headset does not pose a latency problem! This issue goes even deeper, where industrial engineers experience latency as unacceptable lag in critical sensor and control systems. All in all, current wireless technologies cannot deliver acceptable gaming, AR / VR, live video or industrial IoT experiences, so those applications remain wired in 2020.

The brain can typically discern a latency tens of milliseconds or more, and some instrument players are able to “feel” 3 ms of latency. Wireless latency has multiple causes. It is first a consequence of the speed of light, similarly as with wires. However, at the human scale, the speed of light is not the limiting factor, as a 100 meters wireless communication will only incur 333 ns of latency. The second cause is processing time in the transceiver. But again this is usually not the limiting factor as processors can often finish operating on a frame in microseconds. The third cause and one of the most important one is the speed at which the transceiver can communicate its data. In a wireless transceiver, each data frame must be completely received before it can be processed. This means that the speed at which data is transmitted and received is a significant factor contributing to latency. As an example, transmitting a thousand bits frame at a data rate of 1 Mbps will result in a 1 ms latency. This is known as the airtime. In addition to the airtime, there is also the time required by the Media Access Control Layer, or MAC-Time, which is related to the communication stack used by the protocol and may include time for carrier sensing, frame acknowledgment, frame retransmission, flow control etc. The MAC-Time varies greatly depending on the application and can go from being negligible to being the dominating factor compared to the airtime. Ultimately MAC-Time is often correlated to the airtime, such that radios than can condense airtime are able to provide shorter latencies.

Combining all these factors makes it difficult to fairly compare latencies of different wireless radios. Each technology has its targeted applications which means the MAC layer has been developed accordingly. A wireless link that requires 99.999% reliability will not have the same latency as a best effort broadcast system. Nevertheless, the latency will always be limited and derived from the airtime of the radio which is a good point of comparison. The IEEE 802.15.4 standard, behind the ZigBee specification, provides a data transfer rate of 250 kbps, while BLE 4.2 supports 1 Mbps and BLE 5 2 Mbps. These data rates provide an airtime in the order of a few milliseconds for BLE and tens of milliseconds for IEEE 802.15.4. These airtimes are further “amplified” by the MAC layer and cause much longer overall latencies that can go beyond 100 ms, and can be easily noticed by users.

A good way to reduce the latency is to increase the data rate, a method well applied by Wi-Fi. With the 802.11 standard now supporting hundreds of Mbps of data transmission over a single link, we can now see sub-milliseconds latency for single frames. This latency comes at the expense of power consumption, however. The Wi-Fi standard supports large packets of up to over 2000 bytes and uses complex modulation requiring power hungry circuitry.

Latency is in fact one of the main drivers behind the development of 5G networks. Promising a few milliseconds latency, 5G will provides a 10X improvement over LTE. However, 5G radios have a similar drawback to Wi-Fi, which is a very high power consumption, preventing their use in most IoT devices. As such, we are in a situation where we can route data over hundreds of kilometers in a few milliseconds, but it will take more time to do the last one hundred meters using a lower power radio.

UWB bridges the gap between long range, high data rate transceivers (Wi-Fi and 5G) and short-range low data rate solutions like BLE and Zigbee. UWB uses fast 2 ns pulses to reach data rate of tens of Mbps. This provides an airtime one order of magnitude shorter than BLE, reaching sub-ms latency. UWB is then a strong candidate to provide the last 100 meters low latency connectivity when combined with 5G.

The sub-ms latency and relatively large data rate of UWB could enable multiple new interactive experiences and applications that were previously not possible with other short-range radios. However, one very important aspect of UWB, one aspect required for the IoT revolution, has not yet been discussed: low-power operation. In the next part, we will see how UWB can reduce power consumption to a level not yet achieved by any other wireless transceiver.

About Frederic Nabki
Dr. Frederic Nabki is cofounder and CTO of SPARK Microsystems, a wireless start-up bringing a new ultra low-power and low-latency UWB wireless connectivity technology to the market. He directs the technological innovations that SPARK Microsystems is introducing to market. He has 17 years of experience in research and development of RFICs and MEMS. He obtained his Ph.D. in Electrical Engineering from McGill University in 2010. Dr. Nabki has contributed to setting the direction of the technological roadmap for start-up companies, coordinated the development of advanced technologies and participated in product development efforts. His technical expertise includes analog, RF, and mixed-signal integrated circuits and MEMS sensors and actuators. He is a professor of electrical engineering at the École de Technologie Supérieure in Montreal, Canada. He has published several scientific publications, and he holds multiple patents on novel devices and technologies touching on microsystems and integrated circuits.

About Dominic Deslandes
Dr. Dominic Deslandes is cofounder and CSO of SPARK Microsystems, a wireless start-up bringing a new ultra low-power and low-latency UWB wireless connectivity technology to the market. He leads SPARK Microsystems’s long-term technology vision. Dominic has 20 years of experience in the design of RF systems. In the course of his career, he managed several research and development projects in the field of antenna design, RF system integration and interconnections, sensor networks and UWB communication systems. He has collaborated with several companies to develop innovative solutions for microwave sub-systems. Dr. Deslandes holds a doctorate in electrical engineering and a Master of Science in electrical engineering for Ecole Polytechnique of Montreal, where his research focused on high frequency system integration. He is a professor of electrical engineering at the École de Technologie Supérieure in Montreal, Canada.


Turbo-Charge Your Next PCIe SoC with PLDA Switch IP

Turbo-Charge Your Next PCIe SoC with PLDA Switch IP
by Mike Gianfagna on 03-12-2020 at 6:00 am

Integrated NVMe interfaces

SemiWiki has a new IP partner, PLDA and they bring a lot to the party.  Peripheral component interconnect express (PCIe) is a popular high-performance data interface standard. Think GPUs, RAID cards, WiFi cards or solid-state disk (SSD) drives connected to a motherboard. The protocol offers much higher throughput than previous standards such as serial ATA. The last application has spawned a new standard that bundles SSDs with PCIe, creating non-volatile memory express (NVMe) drives.

With all that jargon out of the way, let’s explore how PLDA makes a difference in the NVMe market. One approach to system design with NVMe drives is to use discrete interfaces, as shown below.

While this approach reduces SoC design complexity, it has some significant drawbacks – lower performance and the ability to differentiate only in software are two. Here is where PLDA makes a difference.

Thanks to their embedded PCIe switch IP, the SoC can now handle all the interface tasks previously done by discrete parts. This means improved performance, an optimized bill-of-materials (BoM) and power profile, system design flexibility (e.g., host and/or flash controller implementation in one device) and future-proof capabilities thanks to PLDA’s support of the latest standards, up to PCIe 5.0.

Integrating the PCIe switch into the SoC opens up other opportunities for
further differentiation. For example, hardware-based accelerators can be added to the SoC for tasks such as encryption and compression, resulting in lower latency, power and a reduced BoM. Thanks to PLDA’s support for non-transparent bridges (NTB), multiple guest hosts can be added to the configuration as well. Host-to-host communication is supported by NTB, and guest host to device communication can be implemented with address translation.

Differentiation at the appliance level is also possible with a modular design to support low-cost to high-end applications through multiple instances of the same SoC/FPGA.

PLDA summarizes the key features of their IP for these applications as follows:

  • Low latency switch (cut-through architecture)
  • Support of PCIe 4.0 or 5.0 and SR-IOV
  • RAS features includes ECRC, Parity, ECC, AER, Hot Plug
  • Support for inline and/or embedded processing via pipelining and/or embedded endpoints
  • Any port to any port high-speed communication including peer-to-peer between endpoint devices
  • Ability to support different link width and speed on downstream ports
  • Downstream Port Containment (DPC)

Keep an eye on SemiWiki for more information on PLDA’s flexible IP portfolio, you can also get the big picture regarding PLDA’s full line of products and support at the PLDA website.


Where have all the Leaders gone – a profile of T.J. Rodgers

Where have all the Leaders gone – a profile of T.J. Rodgers
by Erach Desai on 03-11-2020 at 10:00 am

T.J. Rodgers SemiWiki

Silicon Valley has morphed from the days of semiconductor fabs interspersed between strawberry farms, and 3:00 pm rush-hour traffic during the shift change for the fabrication facility engineers and technicians. The leadership of technology companies has also arguably devolved from people who inspired employees and stewarded the growth of enterprises to individuals who count eyeballs and hob-nob with Hollywood elites.

Very few technology leaders have inspired me as much as the iconic T.J. Rodgers. Trust me this is not a fluff piece intended to ingratiate myself with T.J.

T.J. co-founded Cypress Semiconductor in December 1982 – originally a designer and manufacturer of SRAMs (static random access memories). Silicon Valley was born in the backdrop of Stanford University by Frederick Terman and William Shockley and many others, circa the 1950s. So in today’s lingo, T.J. would be from the 2.0 generation of the valley. Remarkably, Rodgers served as the CEO of Cypress for 34 years – stepping down in August 2016 – and, logs in as the longest tenured CEO of all publicly-traded technology (real tech) companies.

The first time I heard about T.J. Rodgers was in 1990 when I read his bombastic article in the Harvard Business Review titled No Excuses Management (in a real paper format, mind you). This makes me sound like some elitist snob (bragging about reading HBR). The publication that I loved at the time was a Silicon Valley trade rag called Upside (it was allegedly run out of business by the legendary Steve Jobs, but that’s a story for another day!).

It was quite a controversial article at the time. T.J.’s premise was that “most companies don’t fail for lack of talent or strategic vision. They fail for lack of execution…” He went on to elaborate – in great detail – about the management systems (sometimes referred to as management information systems, back then) that Cypress had implemented to track and manage: recruitment, goals management, resource allocations, and rewarding employees (compensation). Some observers viewed this as “Big Brother” or micro-management. In a sense, it may have been that. But, the fact remains that Cypress has employed hundreds to thousands of employees under this system – in Silicon Valley, where job mobility is legend.

Personally, I had mixed feelings about this management style. I liked the transparency and accountability. I knew that I would not like my every move being monitored. But, what I most disagreed with was T.J.’s expectation that management – especially executives – had to sacrifice their personal life to succeed at Cypress. While it was not a center piece of his article, I was a youngish, idealistic, and naive fool at the time and believed that “the next generation” could have it all! Nonetheless, I walked away very impressed with this gadfly executive and his chutzpah.

The next time Rodgers appeared on my radar in a meaningful way was in 1995 and I was working in product marketing at ArcSys (which became Avant! through the acquisition of Integrated Silicon Systems). I distinctly remember the morning that ArcSys’ offices were raided by the FBI and the San Jose PD – horrified and disheartened. A few days later I went to the San Jose District Court to pay for my own copy of the complaint that had been filed by Cadence Design Systems, alleging intellectual property theft. The complaint alleged that a Cypress design engineer had gone to T.J. when he had encountered unique error messages running ArcCell software – error messages that were identically poorly worded and mis-spelt as those from running Cadence’s Symbad tools (the Taiwanese-born software engineers at Cadence and ArcSys themselves referred to this as “Chinglish”; so, the thought police and hyper-ventilating PC folks can keep their pitchforks at bay!). The story goes that T.J. had then contacted Joe Costello, CEO of Cadence, and there-in began a series of cloak-and-dagger investigations in conjunction with the District Attorney’s office (there is an ArcSys version of the story that alleges that Costello approached Rodgers to do a software execution comparison; but, …).

The point is not to rehash the case of Cadence vs. Avant! right here. The point is that T.J. was an upstanding leader, willing to fight for what he felt was right in what became a very public case at the time (but, dwarfed by the O.J. Simpson trial). The real thug who master-minded the actual theft of intellectual property from Cadence to ArcSys is Gerald (Gerry) C. Hsu, who dodged prosecution and flourishes in mainland China. My personal investigation and digging into the series of events revealed a more insidious plan that Avant! was never really held accountable for (a book on this very intriguing case is on my bucket list).

But, the story that really galvanized T.J. into my hall of fame of executives is the story of SunPower and Cypress Semiconductor. Phew, they say! He’s finally getting around to the crux of this article.

It was 2001 and Rodgers ran into an old classmate from Stanford. Richard Swanson had ventured away from semiconductors into solar power. Swanson had started SunPower way back in 1988 to make efficient solar cells from silicon. At their chance encounter, Swanson informed Rodgers that he was a few weeks away from laying off half his workforce in order to meet payroll. Curious about the technology and perhaps having empathy for his friend, T.J. decided to meet up with Swanson to learn more and do some initial due diligence. He was so sold on the potential of SunPower’s technology that he approached the board of directors at Cypress to make an equity investment. The board was unconvinced, thinking that it was not core to Cypress’ memory and communications chip business. In characteristic form, T.J. then informed the board that he would make the investment himself, and cut Swanson a $750,000 personal check for an equity investment.

Up to this point this would be a ho-hum narrative. But, there is more.

A year later, SunPower’s technology was proving to be significantly better than that of overseas rivals like Siemens, Kyocdera, Sharp and Sanyo. It made sense to plow further investment into SunPower and Cypress’ board agreed to taking a controlling stake with an $8 million investment. SunPower became a subsidiary of Cypress Semiconductor and brought on Tom Werner as CEO in 2003. Sometime in 2004 it became clear that shareholder value for SunPower would be optimized by taking it public. But, the board – rightly – was concerned: T.J.’s original $750,000 investment could be viewed as self-serving or a conflict of interest – even though it clearly wasn’t as events had transpired (Rodgers had brought the deal to the board, they had rejected it, he asked to invest personally, and the board had okayed his outside investment). In anticipation of the IPO in 2005, the board urged T.J. to sell his personal equity stake to Cypress at the original valuation – in other words, Rodgers would get a $750,000 check from Cypress netting a 0% return. T.J. went ballistic and angry words were supposedly exchanged. In the end, T.J. did “the right thing” even though he had no legal obligation to do so. Kudos to a board of directors that proactively wanted to avoid any perception of conflict. But, a double-kudos to T.J. for being the bigger person, when he did not have to be!

This story was relayed to me at some point in 2004 by Manny Hernandez, then Cypress’ CFO, in my role as a semiconductor equity analyst covering Cypress. However, the narration is mine and I take full responsibility for any unintentional factual misstatements or misrepresentations.

I cannot profess to know T.J. Rodgers personally. As the analyst on Cypress’ stock for a period of a few years, I had some opportunities to meet with him in a group of analysts and investors. Quite frankly he would not know me from Joe the Plumber! When Brian Fuller (editor-in-chief of EETimes, and a friend) interviewed him in a town hall setting at the Embedded Systems Conference in 2006, I grabbed a front seat like a crazed fan!

If there is an underlying thread as to why I truly admire Rodgers’ leadership it is because of his integrity: a person who believes in what he believes, embodies it and built a long-lasting enterprise under his stewardship. In doing some background research for this article, I ran into a more recent story circa 2017. Basically, T.J. (retired from Cypress in 2016, but the largest individual shareholder of Cypress’ stock at the time) took Cypress board of directors to task in a proxy fight in which he prevailed. The issue that T.J. fought for – and won on – was about the integrity of the board of directors and accountability to shareholders. Go figure!


An Objective Hardware Security Metric in Sight

An Objective Hardware Security Metric in Sight
by Bernard Murphy on 03-11-2020 at 6:00 am

Metrics

Security has been a domain blessed with an abundance of methods to improve in various ways, not so much in methods to measure the effectiveness of those improvements. With the best will in the world, absent an agreed security measurement, all those improvement techniques still add up to “trust me, our baby monitor camera is really secure.” Software security has made some progress on this front, as we’ll see. Hardware not so much. That’s a problem. Where’s the UL seal of security approval or something of that nature?

Now there’s hope that will change. The MITRE corporation has released its first documented taxonomy for Common Weakness Enumeration (CWE) in hardware design.

A little background first. MITRE is a not-for-profit organization charged with managing federally funded R&D centers supporting a number of government agencies. Among their well-known contributions is their development and maintenance of a list of Common Vulnerabilities and Exposures, which documents known cybersecurity vulnerabilities.  For example, the recent Meltdown attack has CVE-2017-5754 and Spectre has CVE-2017-5753 and CVE-2017-5715.

MITRE also maintains a related CWE list, which until recently only concerned itself with software weaknesses. For example, you can find buffer overflow weaknesses in this list. The software CWE is very well developed at this point, so much so that there are now over 100 products (including Synopsys’ Coverity) which analyze software for CWE weaknesses.

Intel has a very sophisticated security team (they’re a very big target for attacks) and have been working with MITRE for a while now to develop an equivalent weaknesses list for hardware design. Tortuga Logic has worked with Intel and were invited to contribute weaknesses they had found using their Radix software. So now what you’ll find in this starting list is a combination of Intel wisdom on what they know to be common weaknesses, plus Tortuga Logic wisdom on additional weaknesses they have found.

That’s a pretty darn impressive accomplishment for Tortuga Logic. This CWE list for hardware is likely to follow the same path as the list for software, becoming a definitive standard for best practices in hardware design for security. Even more important, Tortuga Logic Radix-* software is already setup to find many or most of these weaknesses.

Where will this lead over time? First, just as for software CWE, we should expect the list to grow over time. MITRE has a formal process to review and approve new submissions. I don’t imagine designers will want to check through each weakness one at a time in a security signoff (there are already ~840 weaknesses documented). Hardware security tools will be essential.

Second, where is this going in terms of enforcement versus defacto adoption? Jason Oberg (CEO of Tortuga Logic) doesn’t yet see any kind of enforcement, though I suspect government agencies and particularly the DoD will expect vendors to demonstrate they are clean.

Along those lines it is worth noting that the National Institute for Standards and Technology (NIST) has adopted CWE in their cybersecurity framework. It’s perhaps too early to talk about that also including the just-released hardware component, but it’s difficult to see why it wouldn’t ultimately be incorporated.

So unless you are going to ignore government business or build separate hardware for the government, get ready to have to prove CWE compliance at some point. And when the commercial industry is looking around for a security standard on which to hang its hat, I would guess the MITRE CWE will look like a pretty good place to start.


The Story of Ultra-WideBand – Part 3: The Resurgence

The Story of Ultra-WideBand – Part 3: The Resurgence
by Frederic Nabki & Dominic Deslandes on 03-10-2020 at 10:00 am

The Story of Ultra WideBand SemiWiki

In Part 2, we discussed the second false-start of Ultra-WideBand (UWB) leveraging over-engineered orthogonal frequency-division multiplexing (OFDM) transceivers, launching at the dawn of the great recession and surpassed by a new generation of Wi-Fi transceivers. These circumstances signed the end of the proposed applications – short-range very high data-rate (i.e., few hundred Mbps) wireless link – not of the technology. In fact, the history of UWB is a little bit more complex: by the time the high speed wireless UWB proposal was starting to fade, other UWB applications were thriving.

Starting in World-War II, the rapid development of microwave systems paved the way to the development of UWB systems. In the 1960’s the Lawrence Livermore National Laboratory (LLNL) and the Los Alamos National Laboratory (LANL) were working on pulse transmitters, receivers and antennas. These research projects were not pure academic research; there was indeed high incentive to develop impulse systems: UWB could provide ultra-high resolution, which could then be used for object positioning, characterization and identification. By the 1970’s UWB radars were developed mainly for military application. As research continued to progress, other applications were found and, at the end of 1990’s, multiple UWB radars were used for a wide range of applications: forestry applications, through-wall detection in urban areas, imaging for search and rescue operations and obstacle avoidance.

In order to really understand the appeal of UWB, we first have to grasp the time-frequency duality, well encapsulated by the Fourier Transform. In simple terms, this duality states that if you have an infinitely long periodic time signal, it will have an infinitely small bandwidth. On the other hand, if you have an infinitely short impulse signal, it will have an infinitely large bandwidth. In other terms, it means you can trade time for bandwidth. Why would you what to do that? There are multiple reasons for it but a very important one is to enable ultra-high-resolution positioning.

There are two basic ways to determine the distance between RF devices: you can either use the Received Signal Strength (RSS) or the Time of Flight (ToF) of the signal. RSS is a very simple technique to implement and can be used by any wireless transceiver, which explains why it is so widely used. However, it is severely limited in its accuracy: the perceived distance between two immobile objects will change according to obstacles in their direct path. As an example, if you have two devices placed 10 meters apart but separated by a brick wall, which provides 12 dB of attenuation, you would think that both devices are 40 meters away. ToF solves this issue. By measuring the time it takes to travel from one device to the other, you can precisely extract the distance between both objects. In our previous example, the speed of light will indeed be reduced inside the brick wall, but this will only induce an error of about 10 cm (due to the slight reduction in the speed of light in the brick).

ToF is clearly the way to go in order to accurately position objects in space. One drawback however is that you need to deal with the speed of light, which is pretty fast to say the least. In fact, the light takes only 333 picoseconds to travel 10 cm. If one wants to measure distances between objects with centimeter precision, sub-nanosecond accuracy will be needed in the system. The easiest way to achieve this accuracy is to send a signal that is very short in time, which requires, thanks to the time-frequency duality, an UWB signal.

The possibility of accurately measuring the distance with ToF explains to a large extent the resurgence of the UWB in the last few years. The market for accurate positioning is rapidly growing in multiple sectors and should continue to see a double-digit growth in the next years. Multiple companies are now jumping into the UWB bandwagon, the latest being Apple which equipped its iPhone 11 with an UWB chip, the U1, seemingly its own design. With the capability to implement Real-Time Location Systems (RTLS), UWB enables a wealth of new applications in a wide variety of markets: Industry 4.0, IoT, and vehicular.

As we saw in this article, time can be traded for bandwidth, which can advantageously be used to do positioning. But it can also provide other advantages. In Part 4, we will explore another key advantage to UWB in many wireless applications: very low latency.

About Frederic Nabki
Dr. Frederic Nabki is cofounder and CTO of SPARK Microsystems, a wireless start-up bringing a new ultra low-power and low-latency UWB wireless connectivity technology to the market. He directs the technological innovations that SPARK Microsystems is introducing to market. He has 17 years of experience in research and development of RFICs and MEMS. He obtained his Ph.D. in Electrical Engineering from McGill University in 2010. Dr. Nabki has contributed to setting the direction of the technological roadmap for start-up companies, coordinated the development of advanced technologies and participated in product development efforts. His technical expertise includes analog, RF, and mixed-signal integrated circuits and MEMS sensors and actuators. He is a professor of electrical engineering at the École de Technologie Supérieure in Montreal, Canada. He has published several scientific publications, and he holds multiple patents on novel devices and technologies touching on microsystems and integrated circuits.

About Dominic Deslandes
Dr. Dominic Deslandes is cofounder and CSO of SPARK Microsystems, a wireless start-up bringing a new ultra low-power and low-latency UWB wireless connectivity technology to the market. He leads SPARK Microsystems’s long-term technology vision. Dominic has 20 years of experience in the design of RF systems. In the course of his career, he managed several research and development projects in the field of antenna design, RF system integration and interconnections, sensor networks and UWB communication systems. He has collaborated with several companies to develop innovative solutions for microwave sub-systems. Dr. Deslandes holds a doctorate in electrical engineering and a Master of Science in electrical engineering for Ecole Polytechnique of Montreal, where his research focused on high frequency system integration. He is a professor of electrical engineering at the École de Technologie Supérieure in Montreal, Canada.


Viewing the Largest IC Layout Files Quickly

Viewing the Largest IC Layout Files Quickly
by Daniel Payne on 03-10-2020 at 6:00 am

Skipper, Empyrean

The old adage, “Time is money”, certainly rings true today for IC designers, so the entire EDA industry has focused on this challenging goal of making tools that help speed up design and physical verification tasks like DRC (Design Rule Checks) and LVS (Layout Versus Schematic). Sure, the big three EDA vendors have adequate IC layout editors, however they are general purpose tools not really optimized for loading and viewing the largest IC designs that can now approach 1TB in size. This creates an opportunity for a focused point tool that excels at quickly reading an IC layout and does chip finishing tasks, which is what Empyrean has done with their Skipper tool.

WEBINAR: IP Integration Challenges of Complex SoC Platforms

I had a WebEx session last week with Chen Zhao, AE Manager at Empyrean to see what the Skipper tool was all about. Here’s a diagram showing what the input and output file formats are for Skipper:

Let’s say that you have a 200GB OASIS layout file that you need to load and browse, so with a general purpose IC editor just loading that file would take about 5 hours, however with Skipper the same file loads in just 30 minutes. Now that’s what I call automation. The following six IC design tasks all benefit from a fast tool like Skipper:

  1. Visualizing IC layout during DRC and LVS debugging.
  2. Point 2 Point (P2P) resistance analysis.
  3. Net tracing for VDD, VSS, Clock, etc. to find shorts and opens.
  4. Merging multiple IP blocks as part of chip finishing.
  5. Comparing two or more versions of the same layout.
  6. Focused Ion Beam (FIB) processing for defect analysis and circuit modification.

Using Skipper

There are three ways to use the Skipper tool, and each method is optimized for certain tasks.

  • Normal mode – reads the IC layout file into RAM at speeds up to 1 GB/s, depending on your hard drive being SSD or magnetic.
  • Cache mode – reads only parts of an IC layout file into RAM using an index file. Useful if you have cells that don’t need to be loaded.
  • Share mode – the second user to invoke Skipper on the same machine shares the first RAM image, allowing quickest viewing, typically ready within seconds for a 100+ GB file.

The first two modes sounded like a typical EDA tool, however the share mode was something that I’ve never heard about before, and just watching how fast the IC layout appears is quite exciting.

Let’s look at some scenarios for using Skipper starting with Normal mode where each of the following three users independently loads an IC layout, and each has to patiently wait:

Normal mode

With Cache mode User A creates an index file containing just the cells of interest, instead of the entire IC, so now User B and C will load only the pertinent cells, saving time.

Finally, with Share mode User A is the first to load the IC layout on Server 1, then both users B and C use the same Server 1 with Skipper and share the RAM image, allowing a near instantaneous viewing experience in just seconds.

Share mode

To get some speed perspective consider an actual IC design with a 1.6GB OASIS flattened layout, then here are the loading times to start viewing:

  • Normal mode: 110 seconds (at 14MB/s reading speed)
  • Cache mode: 20 seconds (5.5X faster)
  • Share mode: <1 second (100X faster)

Customer Examples

The following two tables compare the speed of Skipper versus another IC layout viewer on an FPGA design, showing improvements between 3X to 24X faster times:

FPGA benchmark times

For golden layout signoff using four of the Skipper capabilities a customer found that on designs ranging from 28nm to 7nm benefited from IP merge at 5X faster, and they have used Skipper on 100+ chips so far.

Customer Case

The final customer case involved a CAD group that integrated the Skipper features by using the C++ API in their flow, coding 200+ API features in just 3 months time.

API integration

Another way to control Skipper is with Tcl code, so that should keep your CAD guys happy.

Talking about customers, Empyrean has about 300 customers using Skipper, so it’s a proven technology, and a tool category worth taking a closer look at.

TSMC Symposium

If you live in Silicon Valley then consider attending the TSMC Symposium to watch what Skipper can do in real time, and talk with the experts at the Empyrean booth. On Wednesday, April 29th visit the Santa Clara Convention Center.

Summary

There’s a new category of EDA tool for speeding up your LVS/DRC debug times, and LVL checking, where the largest IC designs can be browsed most quickly using a point tool like Skipper, saving you time and improving productivity. Here’s a brief overview video showing Skipper in action:

Related Blogs


Achieving Design Robustness in Signoff for Advanced Node Digital Designs

Achieving Design Robustness in Signoff for Advanced Node Digital Designs
by Mike Gianfagna on 03-09-2020 at 10:00 am

Synopsys SemiWiki STARRC Webinar 1

I had the opportunity to preview an upcoming webinar on SemiWiki that deals with design robustness for signoff regarding advanced node digital designs (think single-digit nanometers). “Design robustness” is a key term – it refers to high quality, high yielding SoCs that come up quickly and reliably in the target system. We all know how difficult that can be at the cutting edge. Presented by Synopsys, the webinar explores strategies to make the process of hierarchical extraction and timing analysis (StarRC) for advanced node designs more accurate and efficient.

Hierarchical design is a key element in the “divide and conquer” approach to dealing with large amounts of complex design data. But there are some very real and challenging problems to overcome to use this technique effectively for advanced node designs. Here are just a few of them:

  • For extraction, you need to consider capacitance interactions across hierarchical boundaries. For example, near-the-block or over-the-block top level routes and block-to-block coupling
  • For process variation, you need to consider boundary nets that are impacted by nets running close to the boundary at the top level
  • Due to CMP, block instances may have unique layout environment densities that need to be accounted for
  • There may be multiple physical ports at the block level that map to one logical port. Extraction and timing flows need to correctly map physical and logical pins
  • The number of process, temperature, via resistance and other corners is exploding. You need a way to process all these cases efficiently
  • Also, regarding corner analysis, typical foundry data varies metal thickness in the same direction. This is not realistic in many cases, where metal thickness can vary across the chip. Not modeling this effect can miss timing violations

If you are engaged in advanced node design, I highly recommend attending this webinar. You will learn about approaches to deal with all of items above and more. You’ll learn about new approaches to optimize the run-time of the required tools as well. There is also a very useful Q&A session that dives into a lot more detail. All of this is covered in just over 30 minutes.

The webinar presenter is Omar Shah, who has 20 years of experience working on post-layout digital and custom design flows. Sign up now to attend this webinar. The webinar will be broadcast on Tuesday, March 24, 2020 from 10:00 AM – 11:00 AM PDT.  Hand sanitizer and face mask not required.

About StarRC
StarRC™ is the EDA industry’s gold standard for parasitic extraction. A key component of Synopsys Design Platform, it provides a silicon accurate and high-performance extraction solution for SoC, custom digital, analog/mixed-signal and memory IC designs. StarRC offers modeling of physical effects for advanced process technologies, including FinFET technologies at 16 nm, 14 nm, 10 nm, 7 nm, and beyond. Its seamless integration with industry standard digital and custom implementation systems, timing, signal integrity, power, physical verification and circuit simulation flows delivers unmatched ease-of-use and productivity to speed design closure and signoff verification.

Also Read:

Navigating Memory Choices for Your Next Low-Power Design

Hybrid Verification for Deep Sequential Convergence

Edge Computing – The Critical Middle Ground


Six Automated Steps to Design Partitioning for Multi-FPGA Prototyping Boards

Six Automated Steps to Design Partitioning for Multi-FPGA Prototyping Boards
by Daniel Nenni on 03-09-2020 at 6:00 am

Aldec Webinar SemiWiki

Before starting your next FPGA Prototyping Project you should catch the next SemiWiki webinar – “Six Automated Steps to Design Partitioning for Multi-FPGA Prototyping Boards”, in partnership with Aldec.

A significant portion of my  30+ years in the EDA industry has revolved around design verification with some form of FPGA prototyping, and the verification challenges facing SoC developers haven’t changed much in concept.

However, in today’s world, the cost of failure is much higher and the verification complexity has skyrocketed.  Today’s SoC designers have a plethora of available verification options from formal to simulation to emulation and FPGA prototyping, and most advanced design teams employ some amount of each of these techniques to get designs right before tapeout.  When verification speed is critical you are pretty much forced to include FPGA prototyping.  Emulation is the right choice for high speed debug up to about 1 MHz, but if you need to run at 20 MHz or 100+ MHz to cover your verification space, confirm video streams, or early hardware-dependent software verification, you should seriously look into to adding FPGA prototyping to your verification hierarchy.

This SemiWiki webinar is an excellent overview of the issues facing SoC designers who need to build FPGA prototypes that must be partitioned across multiple FPGAs. Once it is decided to use multiple FPGAs, whether for a single large design, or for multiple instances of the same design talking together, the top-level challenges are well documented: Partitioning, I/O interconnect between FPGAs, and clocking.

Partitioning, or deciding which parts of your design to put in each FPGA, is straight forward in concept, but the devil is in the details.  Simultaneously organizing the FPGA partitions to optimize FPGA utilization, minimize FPGA interconnect, and achieve the target performance is similar in some respects to the “Whac-A-Mole” game, you optimize one metric, and you knock one of the other metrics out of spec.  Oh, and to make your partition challenge more interesting, there’s Rents Rule.  This Rule says you can only put so much logic inside of so many pins, so figuring out how to “cut” your design across multiple FPGAs has limits beyond your control.

Then there’s the I/O interconnect between FPGAs.  The difficulty of this task will be design dependent, but if your design is “highly interconnected”, you may not have enough physical pins to accommodate your logical pins between the FPGAs.  But, don’t despair, pin-multiplexing techniques between FPGAs are available and well understood.  Ah, but, pin-multiplexing comes with a performance penalty, remember the Whac-A-Mole analogy?

Lastly, system clocks and resets must be carefully managed for FPGAs, and there are physical implementation differences between SoCs and FPGAs.  Keep in mind that the FPGA prototype is not the design, but it must “behave” like the design to be an effective design verification platform.  Getting your FPGA clocks to behave like your SoC clocks without introducing design anomalies can be a challenge, and doing a good job with clocks will determine whether or not you hit your FPGA performance targets.

FPGA prototyping is not for the faint of heart, but it can save a design respin or two.  In the early days of emulation, we used to say, “Emulation is hard, but its damn well worth the effort”.  So, my recommendation is to do everything you can to prepare for the project.  Like watching the SemiWiki webinar on this very subject.  And, similar to those familiar warnings: “don’t try this at home”, get someone on your team who has done this before, absolutely.

The Q&A should be especially interesting for this one. If you want to include your questions to my list add them in the comments section.

About Aldec
Aldec Inc., headquartered in Henderson, Nevada, is an industry leader in Electronic Design Verification. Established in 1984, Aldec offers patented technology in the areas of mixed-language RTL simulation, FPGA acceleration and emulation, SoC/ASIC prototyping, design rule checking, clock domain crossing analysis, requirements traceability and functional verification for military, aerospace, avionics, automotive and industrial applications. www.aldec.com


Technology Tyranny and the End of Radio

Technology Tyranny and the End of Radio
by Roger C. Lanctot on 03-07-2020 at 10:00 am

Technology Tyranny and the End of Radio

As technology consumers we make tradeoffs.

We let Google peer into our online activity and email communications and we even accept annoying advertisements tied to our browsing activity in order to access free email and browing. We tolerate smartphones with diminishing performance from Apple – even after Apple admits that the diminishing performance is deliberately-inflicted obsolescence to push us into our next iPhone upgrade. We accept Tesla’s privacy violations in exchange for an awe-inspiring driving experience and software updates.

Along the way we have surrendered our privacy and so much more. Now Tesla Motors may be asking us to surrender free over-the-air broadcast radio.

According to the notes describing the latest software update for owners of 2018-made Tesla’s and earlier (using MCU-1) the latest optional software update (which carries a $2,500 price tag but adds Netflix, Hulu, Youtube, and Twitch) removes AM/FM radio and SiriusXM. This is the often-cited downside of software updates – the potential to obtain improved system performance while sacrificing previously desirable functionality.

While Tesla’s decision only impacts older Tesla’s, it nevertheless highlights the strangely tortured relationship between the broadcast radio industry and Silicon Valley. The issue is a common thread traceable to Apple’s refusal to activate the FM chips built into its phones – and Google’s decision to ignore “terrestrial” radio as part of either Android Auto or Google Automotive Services.

Google, Apple, and Tesla have all turned their backs on the broadcast radio industry in spite of the wide reach of radio – a reach that exceeds that of television – and the fact that it is free, localized content ideally suited to consumption in a mobile environment. Tesla’s decision likely only affects a sliver of Tesla owners given the cost of the optional upgrade and the limited in-vehicle enhancements, but it has the ominous tinge of something more sinister.

The Tesla softwae update, focused as it is on adding streaming video AND a $9.99/month subscription – for owners not already on the company’s premium service tier – points to a streaming-only approach to content delivery. Just as satellite broadcaster SiriusXM felt compelled to offer an IP version of its content, Tesla appears inclined to shift all content delivery to IP reception.

The strategy makes sense for a company delivering cars on multiple continents with varying local broadcast protocols and metadata. Shifting radio reception to IP delivery vastly simplifies the in-dash configuration and, in the long run, may enable some hardware content reduction in the form of deleted tuners and antennas. This is particularly relevant in the run up to 5G adoption – a technology upgrade that will require the additional of multiple antennas.

Tesla vehicles in North America have always come with TuneIn – so, now, TuneIn becomes the preferred radio IP broadcast point of aggregation. In fact, it is quite possible that Tesla has leveraged user data from its own vehicles to determine that radio listening in its vehicles was sufficiently minimal to be worth risking some minor resistance.

More importantly, the software update removing the radio experience is optional. Maybe the offer is a test to determine the customer reaction to a tradeoff of streaming video and improved user interface performance with the sacrifice of broadcast radio for $2,500? Is the offer a bit of a market research project? Anything is possible from Tesla, which has altered its pricing and discounts on multiple occasions in response to market conditions.

But the inclination to delete radio is a popular behavior pattern in Silicon Valley where Google and Apple have treated broadcasters with disdain. Is this approach sustainable? Is it tolerable? Where can an outraged consumer turn to protest?  Will there be consumer outrage? Should there be? Is it time for an in-vehicle radio mandate to ensure that emergency communications – at least – can be broadcast into cars?

I’m not going to cry wolf. And I’m not going to play Chicken Little. I will say that the radio industry offers contextually relevant and reliable content delivery with a broad reach across a wide range of devices and listening environments. Deleting radio from cars – terrestrial or satellite-based – tears at the fabric of our social connectedness.

The marginal cost of preserving terrestrial broadcast connections – particularly in the context of radio’s ongoing global digital transition and the resilience of the medium during emergencies – ought to place this particular content reception experience in a non-delete category. Tesla doesn’t appear to share this view and Tesla is not alone. Once again, Silicon Valley is asking us to surrender one thing in exchange for another. Yesterday it was our privacy. Today it is the radio. Tomorrow it will be our freedom.