SemiWiki – Page 524 – The Open Forum for Semiconductor Professionals

December 20, 2017December 27, 2023

Going to CES 2018? Don’t Miss CEVA-powered Demos!

Going to CES 2018? Don’t Miss CEVA-powered Demos!
by Eric Esteve on 12-20-2017 at 7:00 am
Categories: Automotive, Ceva, Events, IP

CES 2018 will start soon and will be held on January 9-12 in Las Vegas. If you plan to go to Vegas, don’t miss CEVA-powered smart and connected products and demos! CEVA’s product portfolio includes DSP IP cores (the smart) and RivieraWaves IP platforms supporting wireless protocols, like WiFi and Bluetooth (the connected).

DSP is by nature ubiquitous, as DSP core can process any type of digital signal, but CEVA has developed solution for specific applications like intelligent vision, advanced imaging, computer vision or ADAS processing to name just a few. Let’s review the various demos proposed by CEVA at CES 2018.

Intelligent vision – neural network based applications running on a CEVA-XM vision platform silicon. You can read more about CEVA-XM family in Semiwiki: “Intelligent Vision in (Almost) Every Application”

Computer vision – CEVA-XM powered products demonstrating 3D vision, depth sensing, and real-time stitching for 360 degrees video. In semiwiki: “Computer Vision in Mobile SoCs and the Making of Third Processor after CPU and GPU”

Advanced imaging – image enhancement for smartphones and surveillance systems based on embedded photography DSP. The quality of the photography is certainly one of the top three criteria for a consumer selecting a smartphone and chip makers are integrating more and more complex image processing chain. After extraction of raw digital data from the CMOS imager, and running of (single or dual) camera image signal processing (ISP), you must address the key elements of intelligent vision processing, namely 3D vision, computational photography, visual perception, and analytics. The CEVA-XM4 and its associated tools and libraries combine to deliver a comprehensive vision IP platform to do it.

Automotive – ADAS processing by a leading automotive CEVA customer. You may want to refresh your memory with this Webinar from CEVA: “Enabling mass market ADAS applications using real-time vision systems”

AI speaker – far-field multi-microphone reference platform for smart speakers and voice activated IoT devices. In this excellent blog from Bernard Murphy, “CEVA and Local AI Smarts”, you will get a status about AI, as Bernard consider that “For the first time, AI methods not only lived up to the promise but are now beating human experts. (In deference to AI gurus, neural nets have been around for a long time. But their impact on the great majority of us took off much more recently.)”

Smart headset – active noise cancellation software solution for headsets and earbuds, powered by CEVA Audio DSP. Several blogs have been written in Semiwiki to describe DSP solutions addressing voice and audio, here is the last update: “Active Voice” in Semiwiki.

Apple’s AirPods stream true wireless stereo (TWS), although the standard Bluetooth audio profile doesn’t support it.

Audio over BLE– high-quality audio streaming over BLE, demonstrating CEVA Bluetooth 5 low energy working in tandem with CEVA Audio DSP. If you want to know more about Audio over BLE, I recommend you read this article from Franz Dugand, Director of Sales and Marketing, connectivity BU, CEVA “Bluetooth Audio Streaming is Everywhere and Improving”

Wireless connectivity – complete connectivity solutions for IoT gateways using CEVA’s Wi-Fi 802.11ac and Bluetooth 5. CEVA’s wireless connectivity IP are coming from RivieraWaves acquisition. Numerous blogs have been written in Semiwiki about wireless connectivity solutions from CEVA, including “4 Reasons for Bluetooth 5 Adoption in IoT”

NB-IoT solution – complete reference design for cellular IoT based on CEVA-Dragonfly NB1 platform (see above picture). The platform is Single-processor, licensable NB-IoT solution for cost- and power-sensitive LTE IoT devices. You will learn more about CEVA-Dragonfly in this blogin Semiwiki.

Please note that CEVA will exhibit at suite No. 2938 in the Westgate Las Vegas central tower and that access to the suite is by invitation-only. According with CEVA, demo and meeting appointments are filling up fast, so contact them now (you can go here) and a member of their team will be in touch to schedule your meeting.

By Eric Esteve fromIPnest

December 19, 2017

Is there anything in VLSI layout other than “pushing polygons”? (4)

Is there anything in VLSI layout other than “pushing polygons”? (4)
by Dan Clein on 12-19-2017 at 12:00 pm
Categories: EDA

The year is now 1991 and in search for a more peaceful life we decided to move to Canada. At that time, very few companies had advanced flows in VLSI but Ottawa having BNR, Northern Telecom, Mitel, etc., looked to be the most promising place. After a few hiccups in finding a job, I landed in MOSAID, a small company with35 people at that time. From Motorola with central CAD who qualified all tools and PDKs with local CAD who built specialised tools, to a company with no CAD at all. MOSAID was a small design services company specialized in DRAM. One division was doing only design services the other was designing and building very advanced and specialized engineering testers for memories. I was in a new country, new company, new language and no CAD support. This was great opportunity to start fresh using all previous experience in tools, flows, etc. MOSAID Semiconductor division did not have a layout team at all, so I accepted the position of supervisor of the new IC Layout group with 5 members. We were using Apollo machines and Chip graph software for layout, hardware & software coming from Mentor Graphics. Slow and limited for layout but very good for circuit design as it had the “case frames” system in schematic entry, something Cadence does not have until today.

The layout was tedious as no PCELLS available. We had a good coding guy in our team, Karl Skjaveland, who already started to add some automation in AMPLE code bindkeys, device generators, etc. Soon enough Mentor came up with the new revolution in their software called IC Station,this was the answer to Cadence OPUS environment. New software meant that we needed to develop new bindkeys as we had specialized memory application to support and we already had our setups in Chipgraph. We got lucky, we got the visit of Ed Fisher, the engineering manager for IC Station development. Ed came to Ottawa and spent a week with the layout team observing how we work, learnt why we do what we do and took our bindkey to productized them as part of IC Station new releases. We were very happy that we contributed to next generation tool. With this new IC Station came new additions, tools that had automation in mind and I wanted my team to try everything. We invited Glenn Thorstensen to Ottawa and tried the new IC Plan, IC Block, IC Route, IC Verify and all other new software available for layout. Unfortunately, none was useful “as is” for memory design and we did not have CAD to help customization, but we did learn a lot about other IC Station features related to these tools.

We learnt the most important thing,thinking FLOW is more important than thinking one tool solution.

Around 1995 another revolution came to VLSI layout, IC Craftsman, the first “shape based router”. The company was Cooper & Chan Technologies (known as CCT) and they came to DAC to present it. A very refreshing move was to bring early advance users to demo the tool. This is how I became friend with Jack Wild and Paul Mason. I really liked this router but I was in Mentor Graphics environment and there was no integration between the 2 platforms. You needed to export and import GDSII to use the router, but this did not stop me get one copy. First time we used the router in a 16Mb SDRAM central channel and we finished the work in 1 week instead of 3 with all the setup time. This was very good for MOSAID but not good enough for me! Following year, I spoke with 2 important people in CCT, Mr. Chan and Dave Reed. I explained them that a router without a placer built by the same team is only half job. Mr. Chan started to look at options and solutions for devices and cells placement and the following year at DAC we sat together and reviewed progress and options. I remember the debate on device generation “with” or “without” contacts…

The idea was that the router can add the source/drain contacts! The problem is that in 1997 CADENCE bought CCT for the router and they wanted to kill this new baby placer, they already had 5 of their own placers. I am coming to DAC to see the new placer, called Dev Place, and there is no demo for it, nothing… CCT booth became resting area… Went to Dave Reed to find out how can I see the final product but learnt that the software is on the way OUT. The only option was to gain users support and force CADENCE to let it fly to see if it is more successful than other internal products or not. At that DAC I convoked all my industry friends to go to Cadence and ask for a demo of Dev Place. John Cohn brought almost all IBM participants at that DAC for demos. My friends from Intel, Motorola, AMD, all Israelis I knew went for the demos and we won! Very excited I came back to Ottawa and ask Cadence country manager, at that time, Nick Deeble for a copy of the software. Guess what, it was not even on the list for software to sell. So we had a “special deal”: I get the software AS IS, with no maintenance, no future updates, no bug fixing and no support. We payed the money and got the software. Charlie Houck, the AE who came a year earlier to install IC Craftsman came again to help us get Dev Place up and running. I was lucky to get people who knew their “stuff” and were exited to help. Now was time to show my management in MOSAID why we spent the money.

I started to work with one of my colleagues Andrew Holban to figure out how can we integrate IC Craftsman and Dev Place into a flow including IC Station. We worked together before in MSIL and he followed me to Canada. His job was not really CAD but LayCAD, meaning helping layout with automation but nobody else was available at that time. After a IC Craftsman success, we had a few brainstorming discussions with the whole layout team and we came out with a flow. Andrew called it C.A.R.IN.A. – Cadence Automated Routing Interface Application. Below is what Andrew built: a text based user interface capable to help a layout designer plan, place and route 500+ standard cells from and into IC Station with 100% clean DRC and LVS at 350 nm process level. How?

Using a plain text file on the screen, through questions & answers the script was providing the building box of the required block: size in X and Y directions, side on which you want the pins to be in order or not, and numbers of rows for placement.

This box was exported through GDSII to CCT environment together with the design netlist and a library with all cells involved. Kind of LEF, DEF and .lib in the digital world.

The script exported back the placement and routing into IC Station through GDSII and ran the verifications required, in that case was still Dracula.

We promised management that with C.A.R.IN.A. we will finish a block of 500+ cells for a memory periphery (layout in rows) in 1 day compare with the hand crafted 5 days best results. On the first demo Andrew finished in 2 hours and the managers were very pleased! But we did not stop there. Knowing the router speed is based on number of vertices the tool has to evaluate we built abstract cells, but smarter than the digital libraries. They only had routing layers on top modified to let only potential routing areas free and having minimum vertices per polygon. We merged all metals where routing was not available. You can see this concept explained in my book. At step 2 in the new release of the “flow” the script was using the abstract library in CCT and coming back to IC Station the reference points were replaced with the real layout. We got down from 2 hours to 20 minutes…

I want to highlight 2 important factors in this success:

The management believed in our ideas and capacity to deliver. They invested the money for a “bleeding edge tool” and allowed Andrew to be out of production for 4 months.

I was lucky to have Andrew in my team. I was just the enabler and the instigator. He wrote, implemented and released C.A.R.IN.A. alone!

Remember that we did this 2 years before Cadence succeeded to even integrate them in Virtuoso environment. The new Virtuoso Custom Placer (VCP – Dev Place) and Virtuoso Custom Router (VCR – IC Craftsman) was used to build the ACPD flow in a unified environment. How is this for pioneering?

Parts 1-3

December 19, 2017

Networking and Formal Verification

Networking and Formal Verification
by Bernard Murphy on 12-19-2017 at 7:00 am
Categories: Events, Oski Technology, Semiconductor Services

I attended Oski’s latest Decoding Formal event a couple of weeks ago and again enjoyed a largely customer-centric view of the problems to which they apply formal, and their experiences in making it work for them (with Oski help of course). From an admittedly limited sample of two of these events, I find them very representative of the high-end of formal application, what you can do when you build significant internal expertise or bring in experts like Oski. These events also highlight the kinds of property-checking problem that are attacked at this level, falling outside the range of formal apps (today) and in some cases outside what you might even consider normal usage. I’ll get to that last point in a subsequent blog.

The event opened with a keynote given by Dan Lenowski (Sr. VP Eng. and cofounder of Barefoot Networks). Dan started with a quick overview of the anatomy of a shared network switch (apologies in advance to networking experts – what follows is my non-expert view of the domain): per-lane receive MACs and ingress forwarding pipelines, in the middle packet buffering and queueing, then again per-lane egress forwarding pipelines and transmit MACs. Dan talked about verification challenges for each separately.

Formal plays the biggest role in datapath verification (the central block), where it shines in dealing with combinational complexity across variable-sized packets and variable line-speeds, particularly in verifying the queue arbiter (no surprise to formal experts). Here they use it to model:

Correctness – port N is only granted if port N has a request pending
Fairness – port N gets one grant before any other port gets two grants (at the same speed)
Work-conserving – some port is granted for every cycle that more than one cell is available at the input
Sufficient bandwidth – port N will wait no more than that port’s fraction of total shared bandwidth before being granted.

Saurabh Shrivastava (Sr. Mgr. at Cavium) spoke next on a methodology for formally verifying software-defined networking (SDN) silicon, an important topic for networking devices today. Saurabh pointed to OpenFlow as a reference standard for SDN where the control layer and forwarding layer are separate and the control layer manages multiple devices/switches. This can obviously be managed, optimized and reprogrammed to handle multiple possible use-cases, today and in the future, such as IoT use-modes and SD-WAN. So highly configurable, but it can’t be slower than hard-wired solutions and, because it is configurable, verification has to deal with a very complex configuration space, across all of which it has to deliver top performance. In other words, a great fit for formal.

Saurabh went into a lot of detail on their formal methodology and I don’t want to steal his thunder (watch the video), but I will say I was impressed by the discipline in their process. They follow a full test-planning and tracking methodology which would be familiar to any simulation-based verification team. They have intensive test-planning and tracking, a common Makefile and regression framework, coverage review, the works. Assertions, constraints and cover properties are all comprehensively reviewed by the team and tracked as verification progresses. Coverage reviews are as detailed as testplan reviews and they mark off what is covered by formal since it then does not have to be covered in simulation.

Saurabh illustrated with 4 designs ranging from relatively simple to more complex, with I thought an illuminating discussion on how they proceeded through managing the complexity of the formal problem in each case. This is when formal runs out of space/time or gets to an inconclusive result on the raw problem and you have to start thinking about cut-points, black-boxes and abstractions. Saurabh started gently with an IPv4 header checksum generator block. They tried proofs with and without an inserted bug. Formal found the buggy case, slowly, on the full RTL but the clean case run was inconclusive. They ran through 3 stages of abstraction to get down to runs where both the bug was found quickly and the clean case returned a proof. In subsequent examples, they used symbolic values, reset abstraction, data coloring and symmetries to get to closure. Good case studies on dealing with complexity management.

You can check out Oski’s Decoding Formalvideos HERE. (The December video was not yet posted at the time I wrote this, I assume it will be soon.)

December 18, 2017

IoT Project Planning – Profiting from the Folly of Others

IoT Project Planning – Profiting from the Folly of Others
by Mitch Heins on 12-18-2017 at 12:00 pm
Categories: IoT, Siemens EDA, Tanner EDA

I recently was introduced to a white paper written by John Stabenow, Director at Mentor, a Siemens Business, that gave an excellent overview of things to consider before launching into the design of an IoT edge project. John starts the paper with a quote from Pliny the Elder (A.D.23-A.D.79) who said, “The best plan is, as the common proverb has it, to profit from the folly of others”. This reminded me of a saying from one of my past supervisors who told me that “common things happen commonly”. Most mistakes have already been made by others and rather than repeat them we would all be wise to learn from their folly.

With that wisdom in mind, this is a white paper you will want to keep close at hand as the checklists contained in it can be used as a quick reference the next time you start a project. John breaks the planning task down into several areas including:

Planning documents,
Requirements specification, tracking and analysis,
Scheduling
Standards
Defining infrastructure
Outlining design composition
Selecting IC technology
Establishing the tool flow
Automation
Releasing and archiving the project

Each of these areas have multiple sub-areas to be considered and John does a good job of walking the reader through them. I’m going to highlight a few because these always seem to be the ones in my experience that ended up biting the teams with which I have worked.

The first thing that I’ve seen is that teams get confused about the purpose of the planning process. The idea is not to generate a bunch of documents because someone says you must. The planning process is meant to make you really think through what it is you are going to do and how you are going to go about doing it. If you must write something down, that will force you to start thinking through the alternatives to bring clarity to the documents.

The second thing that usually gets lost until much further into the project is the concept of a test plan. Done correctly, the test plan is part of the specification process. Not only do you specify what the system should be doing but you must also specify how you will test that the specifications have been met. If you address both these documents at the same time, you’ll usually find that your specifications aren’t nearly as clear as you thought them to first be. This is especially important if you are working on a design that has some safety implications and John does a good job of discussing some ways in which requirements can be captured and tracked across the design process using tools like Mentor’s ReqTracer.

A third thing that tends to get short shift in smaller companies is infrastructure and automation. An ounce of prevention here is worth a pound of cure later. Simple things like standardizing on project directory structures and file naming conventions can make things a lot simpler when it comes time to automate steps and archive the design when complete. I would lump into this category the use of version control or version management software. Ideally version management should be used for any files that are used by the design, including design data, test benches, documentation, automation scripts and even meta data about versions of CAD tools that are being used for any part of the design. It may seem silly to use version management software for automation scripts, but when you are deep into the design and a script change breaks everything, you will be wishing you had the previous version of that script that you knew worked correctly.

The last thing I pulled out from John’s white paper was the idea of defect tracking and how it relates to requirements management. As already mentioned, if you are working under a safety standard, you often need to prove how you track and manage defects. If you are designing in a modular fashion, testing of design blocks should be happening as each design block is implemented and bugs found during that process should be tracked against their associated requirements, specifications and versions of the block’s implementation. The last thing you want to do is fix a bug and then not have the fix get merged in with the rest of the design.

There is so much information in the white paper I can’t begin to cover all of it in this article. Hopefully I’ve given you enough of a feel that you’ll pull a copy for yourself and give it a read. I think you’ll agree with me that it’s a keeper. The next time you start a project, pull this white paper out and give it a quick read. It will really make you think about your next steps.

December 18, 2017July 3, 2021

CES Preview with Cadence!

CES Preview with Cadence!
by Daniel Nenni on 12-18-2017 at 7:00 am
Categories: AI, Cadence, Events, IP

The Consumer Electronics Show (CES) is in its 50th year believe it or not! The first one was in New York (1967) with 250 exhibitors and 17,500 attendees. Portable radios and TVs were all the rage followed by VCRs in 1970 and camcorders and compact discs in 1981. This year there will be 3,900+ exhibits and an estimated 170,000 attendees with augmented reality, high resolution audio, IoT, and all electric concept vehicles taking us into the future of electronics and more importantly semiconductor design.

CES is the world’s gathering place for all who thrive on the business of consumer technologies. A high-level business event that touches all industries, it’s the place where business gets done. A platform for innovators of all sizes to build their brands, every major technology company on the planet participates in CES in some way — by exhibiting, speaking, sponsoring, attending or holding co-located events and business meetings.

Cadence will be at CES again this year showing the Tensilica line of DSP based processors for audio, automotive, IoT, and consumer products. Tensilica started with SemiWiki in 2011 and continued up until their acquisition by Cadence in 2013 for $380M in cash.

You can find a Brief History of Tensilica HERE in case you are interested. I did predict a Tensilica exit (IPO) in 2013, close enough I would say. Currently Tensilica is everywhere: Mobile handsets, home entertainment, PCs and printers, automotive, Storage/SSD, IoT, and convolutional neural networks. According to Cadence, over 17 of the top 20 semiconductor companies use Tensilica processors to create more compelling and competitive products.

Based on the SemiWiki readership, the trending application for DSPs is artificial intelligence peaking with the disclosure of the Apple Neural Engine inside the A11 Bionic SoC. Apple did not disclose the specs but it certainly behaves like a DSP running at up to 600 billion operations per second.

The iPhone X facial recognition is a prime example of AI inference and training on the edge which of course is powered by the new neural engine. In my opinion this is the tip of the iceberg which will lead to handset health and wellness applications we first saw on Gene Roddenberry’s Star Trek in the 1960s.

Do you remember the tricorder? It’s coming to your iPhone, absolutely! As history has proven, where Apple goes others will follow, so you should expect an explosion of DSP based silicon for AI applications on edge devices. The cloud is already AI enabled with ASICS (Nervana/Intel, Google, and Groq), GPUS (NVIDIA and AMD), and FPGAs (Xilinx and Intel/Altera). Unfortunately, transmission speeds (WiFi and 4/5G) will never keep up with the demands of autonomous cars, robotics, handsets, etc… so the real action will be on the edge devices and that means DSPs, my opinion.

And if you want to see the future of edge devices CES is the place to be and Cadence would be a great place to start: Schedule a meetingwith our top executives at CES 2018 and see how the Cadence® commitment to current and future Tensilica® products meets and exceed your needs. Learn more about our products in neural networks, vision, and audio, and see how Tensilica processors continue to innovate and keep your products ahead of the competition. Visit our meeting room at CES 2018 and see our vision and audio demos and Tensilica DSP-based consumer products already in the market.

December 15, 2017

Self-Monitoring SoCs – An Idea Coming of Age

Self-Monitoring SoCs – An Idea Coming of Age
by Mitch Heins on 12-15-2017 at 12:00 pm
Categories: IP, Moortec
2 Comments

In a former life I was the GM of a business where we built specialized structures used for semiconductor process bring-up, characterization and monitoring. These monitoring structures were placed in wafer scribe-lines and were used to monitor key parameters during wafer processing. The structures provided feedback to automated process control (APC) loops that dynamically tuned the manufacturing equipment to keep the semiconductor process within specific tolerances.

Later, the industry played with the idea of using algorithms to identify key transistors of a design that could be monitored by APC loops to center the design for the best performing chip. Standard product chip companies routinely did this, but the idea never caught on in the COT / pure play foundry space due to fears that SoC companies could lose valuable IP by identifying critical parts of their designs.

Now, as designers continue to push the envelope in terms of process technology, performance and power they are finding that driving their designs to the edge of the process and design windows makes their designs more susceptible to process variability. And, with the advent of the internet-of-things, mobile applications, autonomous vehicles and robots, more SoCs are finding themselves in physically challenging environments (e.g. SoC’s in the wild). Combining a SoC on the edge of the design window with a widely varying physical environment has people worried about design failures at the worst possible moment.

Considering this, a new approach seems to be catching on and that is the idea of embedding process, voltage and temperature (PVT) monitors directly in a design so that the SoC can re-center itself within the design ‘window-of-the-moment’ by using on-chip monitoring data to intelligently alter its own voltage rails, clock speeds, work loads etc. Enter Moortec Semiconductor Ltd.

Moortec provides embedded on-chip subsystem IP solutions for Process, Voltage & Temperature (PVT) sensing/monitoring, targeting advanced node CMOS technologies from 40nm down to 7nm. They’ve recently published a white paper that is worth a read as it details an idea that seems to now be coming of age (see links below).

The white paper highlights some of the keys reasons for why now, might be the right time for on-chip monitoring to take off. The current challenges manifest themselves through process variability, timing violations, excessive power consumption and early aging effects. These can lead to ICs failing to perform as expected. As an example, the move to finFET technology proved to be a boon for dealing with short-channel effects and leakage for sub-30nm transistors. However, finFETs tend to have much higher current density and are therefore more prone to localized heating than conventional planar transistors. This can lead to problems in local-interconnect around the transistors. Self-heating and high current densities can lead to longevity problems, contributing to aging effects such as negative bias temperature instability (NBTI), hot carrier injection (HCI) and electromigration within the metal interconnects.

An interesting phenomenon called “temperature inversion” has been observed for process nodes below 40nm where transistors are seen switching more slowly than expected at cooler temperatures. This has caused designers to have to consider more “corners” when performing circuit-timing analysis. They find themselves now having to include simulations for conditions like ‘best hot’ and ‘worst cold’. The use of guard-banding to protect against various PVT corners is becoming problematic, especially for designs requiring very low energy consumption. As supply voltages are pushed ever closer to the switching thresholds of the transistors to reduce power consumption, small differences in the supply voltage can make for big differences in the switching delays of the circuit.

Another big contributor of variability is the use of multiple cores and die within a system-in-a-package (SiP). This type of packaging is becoming quite prevalent, especially for complex IoT designs with heterogeneous architectures, multiple cores, embedded memories, sensors and in-device transceivers. Often die are stacked on top each other making for hard to predict, temperature relationships that are dependent upon system loads and operating conditions.

Moortec proposes the use of process, voltage and temperature (PVT) monitors that are embedded into the SoC. The simplest use case is a one-time optimization of the SoC during production test. In this case the on-chip monitors can be used to facilitate actions such as speed binning. They can also be used to indicate how well a device will perform for a given power budget. A more complex scenario would be to use the monitors for real-time understanding of the SoC in its operating environment. An example might be having the monitors checking on-chip temperatures and then having intelligent circuitry request a minimum supply voltage that it knows will allow the device to meet timing.

Moortec has architected their solution to split the IP into two parts. The first part being the sensor or monitor and the second part being a controller that is used to interpret the data being provided by the monitor(s). This split architecture allows designers to decide how many sensors/monitors are needed for their specific SoC and where the sensors should be located. A simple solution might be to put sensors at each of the four corners of the die along with a sensor in the middle. A more complex solution may associate a sensor with each critical block and within individual processor cores or groups of cores. In these cases, data would be collected from the various sensing monitors over an interconnect fabric such as the ARM Advanced Peripheral Bus (APB).

All in all, I find this technology very compelling as it enables designers to truly squeeze the most out of their technologies, but in a way where risk can be mitigated and even modified depending on the application. At some point in the future I can see this being very applicable for integrated electronic-photonic designs where the photonics is especially susceptible to temperature shifts. It seems that analog and mixed-signal designs would also benefit from this technology.

For more information pull this white paper down and take a read. You can also check out the rest of Moortec Semiconductor’s offerings on their web page listed below:

Whitepaper: The Implementation of Embedded PVT Monitoring Subsystems in Today’s Cutting Edge Technologies
Moortec Semiconductors web site

December 15, 2017

Application binary interface, get this right and RISC-V is all yours

Application binary interface, get this right and RISC-V is all yours
by kunalpghosh on 12-15-2017 at 7:00 am
Categories: IP, RISC-V

Starting a career in static timing analysis domain, and now actively working on an opensource implementation flow of RISC-V architecture, has been a journey. For last couple of months, I guess from around March this year, I was hooked to RISC-V buzz which was all over my Linkedin, my messages.

Being an STA and Physical design engineer, it was very important for me to connect RISC-V specification to its implementation on chip. Before that, a good break-up of the topic was needed, and with a bit of research, I found the soul of RISC-V ISA – the Application Binary Interface, popularly called as ABI. You get this one right, and I guarantee, RISC-V will be all yours

ABI (application binary interface), as the name says, is an interface, that helps programs access system hardware and services. Let’s break it down

When users look forward to buying computers, they are, more likely, interested in the appearance and functionality of the computer, whether it serves their purpose. And, very unlikely, user will be interested in its physical design implementation of the chips inside the computer, like whether its high-performance or low power implementation

Now, here, the appearance and functionality, are an example of interface between users and computers. Let’s consider another kind of interface – more VLSI and technical

Application program interacts with standard libraries using an interface called ‘application programming interface (API)’. The very basic example, you must have seen, is while writing a C program where you use ‘#include stdio.h’ – this interface defines the core input and output functions

Next interface is the operating system, which handles IO operations, allocates memory and some other low-level system functions. This layer is, by the way, also the one which converts the function programs into its assembly language program and/or machine language program, providing “bit-patterns” to the underlying hardware. This interface is the ISA interface (in this blog, its RISC-V ISA).

Then, the other VLSI level interface is RTL which implements the RISC-V specifications and is an important interface between the ISA and its physical design implementation

In above image, if you move from right (Hardware) to Left (application program), and then coming from left, if you stop at middle (RISC-V ISA), that’s when you start thinking about this architecture from all angles, like sta, drc, congestion, clock skew, io latency, static and dynamic power, IR and many more.

Coming back to ABI or application binary interface, it consists of 2 parts as shown in above image – one is the set of all user instructions itself, and second is the system call interface through the operating system layer. How does it do that in reality? …..Through registers shown in below image

RISC-V architecture has 32 registers (we explained, in detail, why this architecture has 32 registers in our online course). Application programmer, can access each of these 32 registers through its ABI name, for example, you need know the value of stack pointer or move the stack pointer, all you need to do is “addi sp, sp, -16”, where ‘sp’ is the ABI name of stack pointer.

This blog should give a good head-start towards understanding ABI. Now, once you get the functioning of all ABI names in table shown in above image, believe me, RISC-V is all yours. We have done that in our online course, explaining each and every ABI using an example. You finish the examples, and you conquer the battle.

“When in doubt, just take the next small step”. One step that you can take today, and get closer to this architecture is through the below online course on RISC-V ISA:

https://www.udemy.com/vsd-riscv-instruction-set-architecture-isa-part-1a/?couponCode=FOR_SEMIWIKI

TAKE THE FIRST STEP NOW…
I will see you in class and happy learning…

Snapback behavior determines ESD protection effectiveness

Snapback behavior determines ESD protection effectiveness
by Tom Simon on 12-14-2017 at 12:00 pm
Categories: EDA, Magwel

Terms like avalanche breakdown and impact ionization sound like they come from the world of science fiction. They do indeed come from a high stakes world, but one that plays out over and over again here and now, on a microscopic scale in semiconductor devices – namely as part of electrostatic discharge (ESD) protection. Semiconductor devices are highly vulnerable to the high voltage spikes that commonly occur when triboelectric charged objects are exposed to their terminal pins. ESD can be lethal to a device if there is inadequate protection designed into chips.

In an unprotected or incorrectly protected circuit ESD events can lead to failures or affect chip reliability. The mechanisms for these failures fall into several categories. These include oxide breakdown, junction burnout or metal burnout. Many failures are immediately obvious, but ESD can also cause latent failures that can go undetected during testing. Latent failures can become worse over time if there is inadequate ESD protection in the design, and can ultimately lead to field failures months or years later.

Typically, ESD protection is provided by creating alternative parallel electrical paths that harmlessly direct discharge energy so that it dissipates in ESD devices. These circuit paths contain so-called clamp devices and diodes that are usually switched off to allow normal circuit operation. However, clamps begin conducting current and limit voltage once a specified threshold voltage is reached. Many types of ESD clamps rely on the internal structure of MOS FET devices to perform their job.

Every NMOS FET contains a parasitic bipolar junction transistor (BJT) due to the configuration of the doped material. In the normal operation of an NMOS device the parasitic BJT does not come into play. As shown in Figure 1, the BJT has the source and drain as its emitter and collector respectively, and the bulk node underneath can serve as the base of the BJT under the right conditions. This is where impact ionization comes into play. A mobile electron or hole will move under the influence of an electric field. With a low applied electric field, it will move without causing any changes to the system. However, under a strong electric field, like the one found in a device with a high voltage across its terminals, the mobile charge carrier will energetically strike bound charge carriers, which can then break free. These new charge carriers can in turn repeat the process, leading to an avalanche current.

Figure 1

When this avalanche current is moving toward the base of the parasitic BJT, the base current can trigger the device, allowing large current flow between the collector and emitter. The most interesting thing about this is that once the device triggers, the high electric field that started the process is no longer necessary, or even present, to sustain the current. Nevertheless, the conduction continues with increasing current, but at much lower voltages. This phenomenon of triggering at a relatively high voltage and then falling back to conduction at a lower voltage is called snapback. For an effective ESD protection device the trigger voltage should not be so high that it will cause damage to sensitive circuit devices. Also, the lower hold voltage should be above the normal circuit operating voltage so that the device will switch off once the ESD event ends.

The IV-characterization curves for ESD devices are normally created by running carefully timed and controlled square waves through the device. When done correctly joule heating will not cause the device to fail and a series of measurements can be taken. This process is called transmission line pulse (TLP) testing. It is possible to verify proper operation of the ESD device in the circuit with the IV curves created from TLP measurements. However, normal SPICE simulation will not work well because SPICE cannot model the device turn on through impact ionization and the subsequent voltage snapback. Negative differential resistance during snapback causes convergence problems in SPICE. If analysis is performed on an ESD protection network without proper modeling of snapback behavior, incorrect results may be obtained. In some cases, a chip failure or ESD violation could be overlooked, leading to tester or field failures after tapeout.

Let’s examine one such case. A software tool that can properly analyze the full dynamics of an ESD event involving snapback devices must have two critical capabilities: a) proper handling of snapback behavior, and b) the ability to correctly simulate triggering of two or more parallel devices. Both are necessary. A tool designed to handle cases like this is Magwel’s ESDi® which can simulate an ESD event where there are snapback devices and competitive triggering between parallel devices. The case below shows how a serious violation can be overlooked if the analysis tool cannot properly model circuit behavior under ESD stress.

Figure 2

In figure 2 the NMOS device “esd_cell2” is a snapback device. If during an ESD event on pad “IO” the voltage across esd_cell2 does not reach its snapback trigger voltage, all the current will pass through the already triggered PMOS esd_cell1. This will violate margins on PMOS esd_cell1 and cause an ESD related failure. On the other hand, if esd_cell2 is not modeled with snapback and its holding voltage is used as the trigger voltage, it will appear to trigger, seemingly lowering the voltage and providing another current path.

First here is the example of an ESD event on “IO” with no snapback modeling, where NMOS esd_cell2 appears to trigger:

However, we can see below what actually happens in the circuit with an HBM test on the pad “IO”. With the snapback device esd_cell2 below its trigger threshold, the pad voltage reaches 10.369V and only PMOS esd_cell1 is triggered. In this instance, the voltage across esd_cell1 is 9.027V and the total current of 1.33A passes on this one path. There is both an overcurrent and overvoltage violation on PMOS esd_cell1, -14% and -6.6% margin respectively.

Magwel’s ESDi® uses a built-in simulator designed to take snapback into consideration. It correctly identifies which devices will and won’t trigger based on Vt1 trigger voltage. It will also account for the correct Vh1 holding voltage of snapback devices. This is important because once triggered, higher current values are sustained only above the holding voltage. Simply modeling snapback devices as ordinary diodes can cause serious ESD violations to go unnoticed.

Magwel ESDi Fieldviewer showing current density violation during ESD event

Magwel ESDi® runs using layout data and does not require the design to be LVS clean. It comes with a field viewer that shows current densities in metal routing in the discharge path, so that electro-migration (EM) issues can be visually inspected after reviewing the interactive error report. HBM checks are performed with simulation on all pin-pair combinations. This is possible due to ESDi’s rapid simulation capability. Though users can select a subset of pin pairs if focused analysis is needed.

With much tougher requirements for reliability due to standards like ISO 26262, preventing ESD related failures during testing, or even more importantly in the field, is becoming paramount. Using the right analysis tool can make the difference between catching or missing a potential failure. With the special requirements of ESD simulation it makes sense to apply a tool that is known for consistent and reliable results, and can handle snapback devices and parallel current paths. For more information on ESDi®, please look at the Magwel website.

December 14, 2017July 18, 2025

Shifting Left with Static and Formal Verification

Shifting Left with Static and Formal Verification
by Bernard Murphy on 12-14-2017 at 7:00 am
Categories: EDA, Synopsys

Unless you have been living in a cave for the last several years, by now you know that “Shift Left” is a big priority in product design and delivery, and particularly in verification. Within the semiconductor industry I believe Intel coined this term as early as 2002, though it seems now to be popular throughout all forms of technology development.

The idea behind Shift Left in verification starts from a difficult mismatch between traditional product flows and current market needs. A long-favored approach to design and verification has been to make these stages more or less serial, only starting serious verification on a phase of design when that phase is nearing completion. In more relaxed times, that approach was eminently sensible – why spend much time in test if what you are testing is still evolving?

But as designs become more complex, they also become harder to test, leading to more unpredictable verification closure. Semiconductor companies are now responsible for a lot more software content in the product, so verification spans both hardware and software. Also, product design is becoming a lot more collaborative – general-purpose catalog parts may still be around but the real money-makers are frequently co-developed; as a result, spec/requirements may continue to evolve through design.

All of which means that verification has to be pulled in earlier in the design cycle – the Great Shift Left. Sadly, appeals to fairness (the spec changed, you didn’t allow enough time in the schedule, you didn’t give us enough staff) don’t wash. Competitors are stepping up to shift left and delivering outstanding products on these crazy schedules. Buckle up; it’s natural selection time.

How can you push verification left when the design/assembly is still in flux? By moving more verification responsibility into design, or verification teams closely aligned with design. An increasingly popular way to do that is through is better smoke-testing (so the verification team doesn’t waste time on basic bugs) and coverage help (why can’t I get past 90% coverage on this block?).

Also of note, an important advance mentioned in the webinar is that SpyGlass looks like it is fully integrated into the Synopsys verification flow. You can start from a design compiled for VCS and you can setup to automatically switch into Verdi for debug. It’s getting a lot easier to stay in these fully integrated environments, which can’t be good news for the smaller verification players. VCS, VC Formal and other verification solutions leverage the same unified compile and debug environment.

Webinar Summary
With increasing complexity in chip designs, IP and SoC teams are faced with the challenge of minimizing risk, while still maintaining high levels of productivity. Poorly coded RTL is a primary concern, as it leads to bugs, longer verification cycles, unpredictable design processes and delayed time to market.

The combination of static and formal technologies enables smarter, faster and deeper lint analysis at RTL for early signoff. These advanced capabilities enable designers to perform a series of even more comprehensive checks, ensuring fewer bugs, a more stable design flow and accelerated verification closure.

In this webinar, Synopsys discusses how SpyGlass® Lint Turbo, VC Formal™ Auto Extracted Properties (AEP) and Formal Coverage Analyzer (FCA) Apps identify RTL issues at their source, pinpoint coding and consistency problems in the RTL descriptions, and help designers resolve issues quickly before design implementation. The webinar also shows a tool demo on the easy-to-use Verdi® unified debug capabilities, low noise technology to automatically find RTL bugs, dead code, unreachable FSM states and transitions using advanced static and formal technology.

You can watch the webinar HERE.

December 13, 2017July 18, 2025

DSP Benchmarks and Libraries for ARC DSP families

DSP Benchmarks and Libraries for ARC DSP families
by Eric Esteve on 12-13-2017 at 12:00 pm
Categories: IP, Synopsys

Synopsys DesignWareARC HS4xD family is a perfect example of high performance DSP, enhanced RISC CPU IP core, able to address high-end IoT, mid to high-end audio or baseband control. ARC HS4xD architecture is 10-stage pipeline for high Fmax, resulting in excellent RISC efficiency with 5.2 CoreMark per MHz. ARC EMxD processors are offering lowest energy DSP solution to address sensor processing or data fusion, voice & speech, audio or low bit-rate communication. The shallow pipeline architecture has a direct impact on area and power, both optimized, while keeping very good RISC efficiency with 4.02 CoreMark per MHz. We will review the various DSP capabilities of Synopsys DesignWare ARC DSP oriented RISC processors: EM5D & EM7D, EM9D & EM11D and HS45D & HS47D.

The complete DSP features are listed on the above table for the various family cores. These cores are fixed-point by default, but all offer floating-point operation as an option. ARC HS45D/47D exhibits more muscle with 4×16 SIMD operation (instead of 2×16 for EMxD) and 64-bit load/store (instead of 32-bit for EMxD).

ARC HS45D/47D cores are supporting dual-issue, increasing utilization of functional units with limited amount of extra hardware. What is dual-issue? The capability for up to two instructions per clock, with in-order execution and the same software view as single issue. Dual-issue increases both RISC and DSP performance, with very decent area and power penalty, with only 15% increase. The instruction set has been improved to increase instruction per clock, allowing to execute multiple instructions in parallel and take benefit of the dual-issue pipeline.

Instruction Set Architecture (ISA) is ARCv2DSP, designed for high DSP core efficiency and small code size. Synopsys is showing benchmarks (cycle count ratio) for several DSP functions (vector functions, complex maths, scalar maths, matrix functions, IIR filters, FIR filters, Interpolation and transforms), comparing ARC EM9D, ARC EM5D and Processor Y. Core efficiency of ARC EM9D is always better than for ARC EM5D, and better than the competition with a ratio lower by 40% in average.

ARCv2DSP is including 4×8, 2×16, 4×16, and 2×32 SIMD, 16+16 complex MPY/MAC, FFT butterfly instructions, and ITU support for voice. Because HS4xD implements same instructions as EMxD, that provide consistency to ARC portfolio and ease of software portability. HS4xD implementing 64-bit source operations, allows 4×16 and 2×32 SIMD instructions for improved DSP efficiency.

When combining RISC and DSP capabilities in a processor, the key is the software tools and library support, allowing seamless C/C++ programming and debug. DSP software development is made easy, thanks to enhanced C/C++ DSP compiler and rich DSP software library. The C/C++ DSP compiler offers DSP support with fractional data-types and fixed-points API, as well as LLVM-based with excellent performance and code density.

But it would not be easy to develop DSP software without rich DSP software library. Synopsys propose highly optimized set of common DSP functions, vector, matrix, filters (FIR & IIR), transforms (FFT) or interpolation and fixed-points DSP for Q15 and Q31 data-types. DSP libraries also includes ITU-T base operations library for voice codecs, C++ class library for fast emulation on x86 platform. To support efficient simulation, Synopsys provides nSIM bit-accurate DSP models and HW targets for emulation: nSIM/xCAM, RTL, FPGA and Silicon.

The next picture list the DSP functions supported by ARC DSP family:

Every CPU/DSP IP vendor will claim offering the best solution, that’s why it could be wise to look at verified facts when comparing with the competition. Synopsys has compiled benchmarks, comparing cycle count ratios of Cortex-M4, Cortex-M7, Cortex-A8 and ARC EM9D:

This blog has been extracted from a presentation made during ARC Processor summit “Programming DSP Processors Efficiently and with Ease” done by Pieter van der Wolf, Principal Product Architect, Synopsys. Abstract: “The ARC EM and HS processor families both offer processors with the ARCv2DSP ISA extension to support a wide range of DSP applications. These DSP processors come with an advanced tool suite, including a powerful DSP compiler, to support C-level programming of DSP applications. In this presentation we show how excellent results, in terms of high performance and small code size, can be achieved with high-level DSP programming. Ease of programming is also supported with an extensive library of DSP functions. The high-level programming enables software compatibility across different ARC DSP processors.”

By Eric Esteve from IPnest