SemiWiki – Page 529 – The Open Forum for Semiconductor Professionals

November 15, 2017

IoT and Blockchain: Challenges and Risks

IoT and Blockchain: Challenges and Risks
by Ahmed Banafa on 11-15-2017 at 12:00 pm
Categories: IoT
1 Comment

The Internet of Things (IoT) is an ecosystem of ever-increasing complexity; it’s the next wave of innovation that will humanize every object in our life, and it is the next level of automation for every object we use. IoT is bringing more and more things into the digital fold every day, which will likely make IoT a multi-trillion dollar industry in the near future. To understand the scale of interest in the internet of things (#IoT) just check how many conferences, articles, and studies conducted about IoT recently, this interest has hit fever pitch point in 2016 as many companies see big opportunity and believe that IoT holds the promise to expand and improve businesses processes and accelerate growth.

However, the rapid evolution of the IoT market has caused an explosion in the number and variety of IoT solutions, which created real challenges as the industry evolves, mainly, the urgent need for a secure IoT model to perform common tasks such as sensing, processing, storage, and communicating. Developing that model will never be an easy task by any stretch of the imagination, there are many hurdles and challenges facing a real secure IoT model.

The biggest challenge facing IoT security is coming from the very architecture of the current IoT ecosystem; it’s all based on a centralized model known as the server/client model. All devices are identified, authenticated and connected through cloud servers that support huge processing and storage capacities. The connection between devices will have to go through the cloud, even if they happen to be a few feet apart. While this model has connected computing devices for decades and will continue to support today IoT networks, it will not be able to respond to the growing needs of the huge IoT ecosystems of tomorrow.

The Blockchain Model
Blockchain is a database that maintains a continuously growing set of data records. It is distributed in nature, meaning that there is no master computer holding the entire chain. Rather, the participating nodes have a copy of the chain. It’s also ever-growing — data records are only added to the chain.

When someone wants to add a transaction to the chain, all the participants in the network will validate it. They do this by applying an algorithm to the transaction to verify its validity. What exactly is understood by “valid” is defined by the Blockchain system and can differ between systems. Then it is up to a majority of the participants to agree that the transaction is valid.

A set of approved transactions is then bundled in a block, which gets sent to all the nodes in the network. They, in turn, validate the new block. Each successive block contains a hash, which is a unique fingerprint, of the previous block.

Principles of Blockchain Technology
Here are five basic principles underlying the technology:

1. Distributed Database
Each party on a blockchain has access to the entire database and its complete history. No single party controls the data or the information. Every party can verify the records of its transaction partners directly, without an intermediary.

2. Peer-to-Peer Transmission
Communication occurs directly between peers instead of through a central node. Each node stores and forwards information to all other nodes.

3. Transparency
Every transaction and its associated value are visible to anyone with access to the system. Each node, or user, on a blockchain has a unique 30-plus-character alphanumeric address that identifies it. Users can choose to remain anonymous or provide proof of their identity to others. Transactions occur between blockchain addresses.

4. Irreversibility of RecordsOnce a transaction is entered in the database and the accounts are updated, the records cannot be altered, because they’re linked to every transaction record that came before them (hence the term “chain”). Various computational algorithms and approaches are deployed to ensure that the recording on the database is permanent, chronologically ordered, and available to all others on the network.

5. Computational Logic
The digital nature of the ledger means that blockchain transactions can be tied to computational logic and in essence programmed. So users can set up algorithms and rules that automatically trigger transactions between nodes.

Public vs. Private Blockchain
Blockchain technology implementation can be public or private with clear differences, for example the benefits offered by a private blockchain are: faster transaction verification and network communication, the ability to fix errors and reverse transactions, and the ability to restrict access and reduce the likelihood of outsider attacks. The operators of a private blockchain may choose to unilaterally deploy changes with which some users disagree. To ensure both the security and the utility of a private blockchain system, operators must consider the recourse available to users who disagree with changes to the system’s rules or are slow to adopt the new rules. While, developers who work to maintain public blockchain systems like bitcoin still rely on individual users to adopt any changes they propose, which serves to ensure that changes are only adopted if they are in the interest of the entire system.

Just as a business will decide which of its systems are better hosted on a more secure private intranet or on the internet, but will likely use both, systems requiring fast transactions, the possibility of transaction reversal, and central control over transaction verification will be better suited for private blockchain, while those that benefit from widespread participation, transparency, and third-party verification will flourish on a public blockchain.

Challenges of Blockchain in IoT
In spite of all its benefits, the Blockchain model is not without its flaws and shortcomings:

Scalabilityissues; relating to the size of Blockchain ledger that might lead to centralization as it’s grown over time and required some kind of record management which is casting a shadow over the future of the Blockchain technology.

Processing power and time; required to perform encryption algorithms for all the objects involved in Blockchain -based IoT ecosystem given the fact that IoT ecosystems are very diverse and comprised of devices that have very different computing capabilities, and not all of them will be capable of running the same encryption algorithms at the desired speed.

Storagewill be a hurdle; Blockchain eliminates the need for a central server to store transactions and device IDs, but the ledger has to be stored on the nodes themselves, and the ledger will increase in size as time passes. That is beyond the capabilities of a wide range of smart devices such as sensors, which have very low storage capacity.

Risks of Using Blockchain in IoT
It goes without saying that any new technology comes with new risks. An organization’s risk management team should analyze, assess and design mitigation plans for risks expected to emerge from implementation of blockchain based frameworks.

Vendor Risks: Practically speaking, most present organizations, looking to deploy blockchain based applications, lack the required technical skills and expertise to design and deploy a blockchain based system and implement smart contracts completely in-house, i.e. without reaching out for vendors of blockchain applications. The value of these applications is only as strong as the credibility of the vendors providing them. Given the fact that the Blockchain-as-a-Service (BaaS) market is still a developing market, a business should meticulously select a vendor that can perfectly sculpture applications that appropriately address the risks that are associated with the blockchain.

Credential Security:Even though the blockchain is known for its high security levels, a blockchain based system is only as secure as the system’s access point. When considering a public blockchain based system, any individual has access to the private key of a given user, which enables him/her to “sign” transactions on the public ledger, will effectively become that user, because most current systems do not provide multi-factor authentication. Also, loss of an account’s private keys can lead to complete loss of funds, or data, controlled by this account; this risk should be thoroughly assessed.

Legal and Compliance:It’s a new territory in all aspects without any legal or compliance precedents to follow, which poses a serious problem for IoT manufacturers and services providers. This challenge alone will scare off many businesses from using Blockchain technology

The Optimum Secure IoT Model
In order for us to achieve that optimal secure model of IoT, security needs to be built-in as the foundation of IoT ecosystem, with rigorous validity checks, authentication, data verification, and all the data needs to be encrypted at all levels, without a solid bottom-top structure we will create more threats with every device added to the IoT. What we need is a secure and safe IoT with privacy protected. That’s a tough trade-off but possible with Blockchain technology if we can overcome its drawbacks.

Ahmed Banafa Named No. 1 Top VoiceTo Follow in Tech by LinkedIn in 2016. Read more articles at IoT Trends by Ahmed Banafa

November 15, 2017

Arm and Mentor Use DesignStart Program to Accelerate Proof-of-Concept for IoT Designs

Sometimes the hardest thing about bringing a new idea to fruition is overcoming the inertia to get started with a proof-of-concept. You must be able to put together enough parts of the solution to prove to those controlling budgets that an idea has merit and is worth taking to the next level. It’s a bit of a chick-vs-egg scenario as you can’t get funding to do the proof-of-concept without a proof-of-concept to get the funding. At this point, many good internet-of-things (IoT) applications die for lack of finding a way out of this catch-22 scenario.

Arm and Mentor have come up with a winning proposal to help entrepreneurs whether they be individuals in their home office, in small or medium sized enterprises or even in large corporations. It’s something Arm calls their DesignStart program. The DesignStart program is meant to be a simple, fast, low-risk route to using Arm’s industry-leading IP with no upfront fee. To compliment their IP, Arm has teamed up with Mentor, a Siemens business, to offer designers a limited-time free access license to Tanner EDA tools to overcome the cost barrier of acquiring EDA tools. Arm is also offering approved design partners training and support for SoC development.

The DesignStart program comes in two flavors, DesignStart Eval and DesignStart Pro. DesignStart Eval is for anyone. Users can instantly get free, click-through access to Arm Cortex-M0 and the Cortex-M3 processors as well as Arm subsystem IP. The cores and IP can be configured or modified including the ability to add your own IP and peripherals. The resulting design can then be prototyped on an FPGA giving designers a fast way to design, simulate and prototype their proof-of-concept. Forum-based support is provided giving designers access to others who have gone down the same path.

When it comes time to commercialize your idea, Arm is providing their DesignStart Pro option. This option is for companies looking to develop their own chip. Companies register on the DesignStart website, sign and return a contract with no upfront fees and a simple success-based royalty once the chip goes into production and then start work. DesignStart Pro also includes a verified subsystem, enhanced design services and the mbed OS platform.

As mentioned, Mentor provides designers with their Tanner EDA tools to enable designers to do design capture and simulation of their proof-of-concept SoC. This is done through a free 30-day evaluation license of the Tanner AMS flow with S-Edit schematic capture, and T-Spice and ModelSim simulators. These tools enable the designers to create a demonstration of how their design concept will work which can then be used as the proof-of-concept needed to gain funding for implementing and finalizing their idea.

Arm is providing both the Arm Cortex-M0 and Cortex-M3 processors along with their IP subsystems. The Cortex-M0 is a 32-bit processor with exceptionally small silicon area, low power and minimal code footprint. This processor is exceptionally good for Internet-of-Things (IoT) edge devices.

Conversely, designers can also choose to use the Cortex-M3 processor which is an industry-leading 32-bit processor for smart embedded applications. The Cortex-M3 is a high-performance processor used in microcontrollers, automotive applications, industrial control systems and wireless networking and sensors. The Cortex-M3 is especially well suited for IoT gateway devices.

Designers using the DesignStart Pro option also get the Corex-M Design Kit (CMSDK) which provides an example system, a selection of either Arm AMBA or APB infrastructure components and many other key system IP components. DesignStart Eval makes available a subset of the CMSDK capabilities.

A nice feature of both DesignStart programs is they provide the required CAD views and documentation necessary to use either the Arm Cortex-M0 or Cortex-M3 cores in the Tanner EDA flow. This is crucial for entrepreneurs who don’t have the help of a corporate CAD team to put a design flow together with verified IP for their proof-of-concept. DesignStart makes available the libraries to quickly assemble and configure designs in the Tanner S-Edit schematic capture tool and enables debugging of design interfaces between cores, peripherals and sensors using the mixed-mode simulation capabilities of Mentor’s Tanner T-Spice and ModelSim simulators.

Once funding is secured, the next step is to implement the layout of the design and then fabricate it. This requires that designers purchase the Mentor tools to complete the design giving them access to Mentor’s synthesis, placement, routing and verification tools. Once the design is completed and verified it can then be taped out to the designer’s chosen foundry. To speed up the implementation phase, Arm DesignStart also provides free access to a comprehensive library of physical IP.

So, if you have an idea and need a little help to get the ball rolling, you might want to check out the Arm DesignStart program and Mentor Tanner EDA tools. There is a white paper and a webinar that are available to get you going (see links below). You might find that they are exactly what you need to get your idea through the proof-of-concept stage and to get your ball rolling downhill to make the next big IoT application a reality.

November 14, 2017October 8, 2019

A Brief History of PSS at Breker

A Brief History of PSS at Breker
by Daniel Payne on 11-14-2017 at 12:00 pm
Categories: Breker Verification Systems

Verification engineers are hearing a lot about the Portable Stimulus Standard (PSS), and for good reason because it could potentially save them time and effort in doing their jobs much better. In order to get the big picture on what PSS is all about I contacted Adnan Hamid, founder and CEO of Breker Verification Systems, because he’s been involved with the formation of PSS since its inception.
Continue reading “A Brief History of PSS at Breker”

November 14, 2017

The Practice of Low Power Design

The Practice of Low Power Design
by Bernard Murphy on 11-14-2017 at 7:00 am
Categories: Cadence, EDA
1 Comment

For any given design objective, there is what we in the design automation biz preach that design teams should do, and then there’s what designs teams actually do. For some domains, the gap between these two may be larger than others, but we more or less assume that methodologies which have been around for years and are considered to be “givens” among leaders in the field will be, at least conceptually, well-embedded in the thinking of other teams.

In low-power design, here are some of those givens:

Designer intuition for performance and area of a function can be quite good, but intuition for power is horrible: +/- 50% if you’re lucky.
~80% of power optimization is locked down in architecture (leftmost designer above), ~20% or less in RTL (middle designer) and the best reductions you can hope for at implementation are in single digits (rightmost designer).
From which we conclude that power is an objective that must be addressed all the way through the design flow – from architecture all the way to GDS, with architecture most important.
Power is heavily dependent on use-case, more so perhaps in mobile, but still important in wired applications. You have to run power estimation on a lot of applications, which is going to run a lot faster at RTL than at gate-level.
Peak-power is also important, especially for reliability. So averages alone are insufficient.

For anyone designing for mobile applications, all of this is old news. They have been using these principles (and more) for a long time. What came as a shock to me, in discussion with Dave Pursley (Sr. PPM at Cadence) was that some design teams, at well-known companies, seem unaware of or indifferent to even the first two concepts. I can’t speak to why, but I can speculate.

Perhaps the view is that “this isn’t a mobile application, so we just have to squeeze a bit and we can do that in RTL”. Or “between RTL and layout optimizations we’ll get close enough”. Or “we can’t estimate power accurately until we have an implementation so let’s get there first then see where we stand”. Or maybe it’s just “we’ve always done design this way, power is just another thing we have to tweak, we’ll run that near the end”. Whatever the reason, as you might guess sometimes this doesn’t turn out so well. Dave cited examples (no names) of power estimates at layoutthat were 50% over budget.

Some of these were saved by Hail Mary’s. Which sounds heroic but it’s not a good way to run a business. A more likely outcome is a major redesign for the next product cycle or scrapping the product. For those of you who have found yourselves in this position and didn’t enjoy the experience, let’s review what you should have done.

First, just because your target won’t go into a mobile application doesn’t mean you can skip steps in low-power design. If you’re just doing a small tweak to an existing well-characterized design, to be used by the same customer in the same applications, then maybe. Otherwise you need to start from architecture just like everyone else. You don’t have to get anywhere near as fancy as the mobile design teams, but HPC/cloud applications, cost-sensitive applications without active cooling and high-reliability systems now also have tight and unforgiving power budgets.

How do you estimate power at the architecture level? For the system as a whole, simulation coupled with power estimation, if you don’t have any other choice. Emulation coupled with power estimation will be massively more effective in getting coverage across many realistic use cases and particularly in teasing out peak power problems.

For IP power characterization, you’ll start with RTL or gate-level models. If you’re planning to build a new IP, you might consider starting with high-level design (eg. SystemC). That can be synthesized directly to RTL where you can run power estimation driven by the testbench you developed at that same high-level (also faster to build than an RTL testbench). Developing at high-level allows for quick turn-around architecture exploration to optimize, say, power. You may be surprised to hear that a lot more functions are being developed this way today (see the results of a Cadence 2017 survey above). If this isn’t an option, you’ll have to stick with RTL models. Either way, you know power estimation will be as accurate as RTL power estimation.

Which these days is within ~15% of signoff power estimates. Might seem like a significant error bar, but it’s still a lot better than your intuition. And it’s actually better than 15% for relative estimates, so a pretty good guide for comparing architecture/micro-architecture options.

Next, unless they have a Hail Mary play in mind, don’t believe the RTL team if they tell you they can cut 50% power. (I’m not talking about power and voltage switching here). More common might be 15-30% starting from an un-optimized design, more like ~5% if already optimized. If they can save more than that, that doesn’t speak well to the quality of their design. Clock gating will save some, not much if you only do register-level gating, more if you gate at the IP level (also gating the clock tree), memory-gating can save quite a bit too. Hail Mary’s could include power gating but hang on to your hat if you start thinking of that late in the design. Verification is going to get a whole lot more complicated as is adding on-board power management, power grid design, floorplanning and more complex power integrity signoff.

Most of all squeeze everything you can out of power before you hand it over to implementation and make sure you are within ~5-10% of budget before you handoff. Implementation can fine tune but they absolutely cannot bail you out if you’re way off on power. What they need to focus on is that last few percent, power and signal integrity, thermal (again, not just average but also peak – local thermal spikes affect EM and timing and can easily turn into thermal runaway). And, of course, they worry about timing closure and area.

So now you know power optimization isn’t a back-end feature or tool. It’s a whole string of tools and a responsibility all the way from architecture to implementation, with the bulk of that responsibility starting at architecture. The right way to handle this is through an integrated flow like the that offered by Cadence. Why is integration important? Because a lot of getting this right depends on consistency in handling constraints and estimation through the flow, which you’ll sacrifice if you mix and match tools. And that will be even more frustrating.

November 13, 2017

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

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

In late 1986 the Layout Project Leader of DSP96000 got married and left for a 6 months’ vacation so I inherited the biggest chip MSIL had in stock. Floorplanning such size chip was a challenge from day one. Even the 68030 SUN workstation was too slow. I started to ask around and going to demos for any other possible tool that can help me do my job. Our CEO came one night to see “how it’s going” and I was “routing” listening to music. He stayed about 15 minutes behind my back in which time I was capable to route 3 (three) signals in top level. I had a list of about 57,000 signals so he made the calculation that if I work 24 hours will be done way after tapeout time. He “empowered” me to find a solution “outside the box” even if it could be against Motorola policy.

I knew about a revolutionary tool called BRP (Block Place & Route) from ECAD, later CADENCE. The issue was not only software but hardware. The SUN on 68000 family was too slow and limited on what it can handle in DRAM and disk. The RISC processors machines were available, but it was not a Motorola chip in it ☹. Guess what, I sold the idea to our CEO and requested a RISC machine with 4 disks of 1 Gb each. It was approved immediately and the Israeli distributor, who used this machine for demos only 2 weeks earlier, had to bring it in MSIL and install it in record time.

We contacted ECAD/Cadence and we got again from UK another great AE, Steve Upham. He planned to stay for 2 weeks and stayed for 5 months. The biggest power of this software was that all signals will be routed with “preplanned” constraints and it knew how to maintain metal direction. This means new flow: each circuit owner of a block will provide a list of signals with EM/IR requirements (widths and currents) , and the layout person will ensure all applied based on architecture. The challenge was to deal with power grid issues, each block being connected many time to the same supply. All lines were “symbolic” in routing so easy to move from channel to channel or just manipulate. Once happy with the location you pushed the “compaction” button and all becomes real WIDTHS with proportional number of VIAS, and this was in 1988.

It was looking promising as we succeeded the first trial in 3 weeks, routing about 50,000 signals in 3 layers. Now the problem was how to import/export the GDSII data from/into CAECO where we need it for the real chip. CAD came to rescue again, Nachshon Gal worked with me to generate empty boxes of the real layout containing only the pins of all blocks so the total data we use in top level has only boundary and routing pins! We invented blocks ABSTRACTs in 1988. Steve and Nachshon had to rewrite a new interface and break down the final data from BPR into 2 pieces and reassemble it in CAECO. Even with abstracts the data was too big for the translation engine. One cool feature to reduce data in BPR was to reduce jogs and jumpers so smooth planning and clean channel reduced the final data. Win / win situation, smaller chip and smaller data for tools to handle.

Once we figured out that data size could be an issue, we looked at planning final GDSII verification. Remember all as FLAT in 1988 so the data footprint was very big for verification and virtual memory needed temporarily for DRC and LVS was also big. We envision that our chip will be 3×4 of the previous chip in area so we multiplied everything by 12. We did a local benchmark and found out that the only way to run this data size will be on the IBM servers in Austin, Texas, Motorola Semiconductor headquarters. We spend some effort and after one month of trials figure out what do we need for final verification. We booked 2 years in advance the servers, the virtual memory and disk needs. It proved to be a good proactive action and we tapeout on the promised day. This was another “non-layout” interesting task.

As the DSP requires a lot of Datapath blocks for Address Controllers, Multipliers, Adders, etc., we had to find ways to automate this type of layout blocks. We developed special cells for each function but adding a way to deal with last minute ECO (Engineering Change Order) was a priority in our minds. After the TEXT layer used in standard cell libraries the taste for “smarter automation” grew. We invented text layers for everything: contacts, diffusion, implants, and vias and metals. We developed a datapath programmable software that we called STDGEN, or Standard Generator. We built cells full with all layers and when ready DRC/LVS clean we changed the real layers in text one. Based on the needed functions from each cell, STDGEN was replacing the text layer with the real one and run the new verification versus the new netlist. No change in area, all external pins maintained, no possible errors and the final “coding” could come one day before final chip verification.

On this one I worked with Eythan Weiberger and other CAD guys… I was involved only in the specification stage and chip level verification as other people in the team helped CAD in this case. For this chip we spend approximatiely 300 man/months layout and about the same effort for circuit and system design and we were on schedule as planned 3 years earlier by Ika Reuveni, the original layout project leader. How is this to invent new things “as” and “when” you need them? A big part of doing all this was the unconditional support from management and all adjacent groups. It was challenging, fun, and many times exhausting but we never gave up.

One interesting fact little known to the world outside Motorola Semiconductor Israel and Cadence Israel. Around 1988 CADENCE released the first version of OPUS. Once the first customer (MSIL) bought a CADENCE license, they decided to hire a salesperson and an AE for support. But OPUS software was about 500 Mb and CADENCE did not have such a big computer to handle it. Cadence came to MSIL and negotiated to put the OPUS corporate software on my machine (which was at that time 4x1Gb disks). Every time CADENCE needed keys to enable a new customer to use any OPUS software, they will send by fax the CPU ID and I will generate the license keys. This enabled me to know more people from other Israeli companies, sometimes competitors, a little different job than layout designer duties.

Dan Clein
CMOS IC Layout Concepts, Methodologies and Tools

Also Read: Is there anything in VLSI layout other than pushing polygons? (2)

November 13, 2017July 3, 2021

Finding the Right Needle in the IP Haystack

Finding the Right Needle in the IP Haystack
by Daniel Nenni on 11-13-2017 at 7:00 am
Categories: Consensia, EDA, IP

As the percentage of pre-configured IP increases in semiconductors, so design teams are able to reduce design cycle times. But one of the challenges for design teams is the inability to quickly and easily find IP because it’s incorrectly classified, sat in a designer’s home directory, or it’s been put into the ‘repository’ by an IP developer and someone forgot to update the spreadsheet to notify the design team that it’s available.

These challenges of finding the right “needle in the IP haystack” introduces delays to achieving design closure that run into millions of dollars of lost opportunity costs.

It sounds far fetched that in this day and age companies would use a spreadsheet to track IP, but many semiconductor companies do not have a specialized IP management solution; instead they use a PLM or ERP system like Oracle – or they use an in-house/home grown system that needs constant enhancement and maintenance by a small army of developers.

The result of these ‘legacy’ processes and solutions is that design teams spend unnecessary time and energy trying to find the right version of the right IP for their design. Whether internally developed or externally procured, the information about all of the IP in an enterprise needs to be accessible to those who need to find and qualify that it’s the required IP. It also needs to be hidden or non-discoverable to those who don’t need to see it.

Consensia, a channel partner of Dassault Systèmes, will be holding a webinar (moderated by me) later this month to demonstrate how DelphIP helps its customers’ IP consumers quickly and easily find the IP they need to add to their Bill of IP/SOC BOM. Consensia’s description of IP is anything that includes software, hardware, firmware or documentation.

DelphIP is an IP lifecycle management solution. It is based on the Dassault Systèmes ENOVIA platform, so it understands semiconductor nomenclature like foundries, process nodes, and other attributes that IP developers and consumers use to create or search for IP based. These attributes are added when the IP is created or goes into the repository, so it’s easy to track it through it’s lifecycle.

WEBINAR REGISTRATION Tuesday, November 28, 2017 8:00am PT – 9:00am PT

During the webinar, Consensia will demonstrate how design team members can search for, and easily locate, IP that meets their exact requirements – both internally developed or externally procured IP.

In an ideal world, IP would be developed and validated before a new design start commences. But in reality, IP is often developed in parallel with the chip design. DelphIP enables designers to see progress of IP that is being internally developed, as well as being notified when it has been published internally.

Consensia says that some of their customers have also benefitted from their Issue & Defect functionality. This allows ASIC/SOC design leads to report issues, have them assessed by the developer (or external vendor) and notified of the status of the IP so that they can get a roll up, hierarchical view of all of the defects in an SOC, something that the bug reporting tools don’t typically provide.

Consensia will also show something called collaborative workspaces which is a secure area used by customers working with external joint development partners. It enables semiconductor or IP companies to provide configurable access to specific IP with their partners. This accelerates the design process by giving visibility to specific IP on which they may want to undertake specific IP lifecycle management functions without compromising the security of other IP data.

The webinar should be an interesting insight into how IP lifecycle management is undertaken by some of the companies that use DelphIP. Again, you can register for Consensia’s webinar here. I hope to see you there.

November 12, 2017July 3, 2021

Free PDF Version of PROTOTYPICAL for SoC Design

Free PDF Version of PROTOTYPICAL for SoC Design
by Daniel Nenni on 11-12-2017 at 7:00 am
Categories: Prototyping, S2C EDA

In our quest to further enlighten the masses SemiWiki has published four books, we have two more eBooks in post production due out in Q1 2018 and two more topics in research. All of the books are available free for PDF versions or you can get printed versions on Amazon.com or free printed versions at book signings or if you happen to meet me during my travels. Continue reading “Free PDF Version of PROTOTYPICAL for SoC Design”

November 11, 2017

Will Broadcom become a Chipzilla or is the deal DOA?

Will Broadcom become a Chipzilla or is the deal DOA?
by Robert Maire on 11-11-2017 at 6:00 am
Categories: Semiconductor Advisors, Semiconductor Services
15 Comments

The Broadcom bid for Qualcomm is the biggest, boldest semiconductor deal to date. Just when we thought semi M&A was cooling off, this deal is a years worth of deals rolled into one. Not only does this deal upset the current balance between chip suppliers and customers, it would create a giant entity smack in the middle of IOT, AI, AR & VR roadmaps.
Continue reading “Will Broadcom become a Chipzilla or is the deal DOA?”

November 9, 2017July 18, 2025

High performance processor IP targets automotive ISO 26262 applications

High performance processor IP targets automotive ISO 26262 applications
by Tom Simon on 11-09-2017 at 12:00 pm
Categories: Automotive, Events, IP, Synopsys

The reason you are seeing a lot more written about the ISO 26262 requirements for automotive electronics is, to put it bluntly, this stuff is getting real. Driver assist systems are no longer only found in the realm of Mercedes and Tesla, almost every car in every brand offers some driver assist features. However, the heavy lifting required for ISO 26262 is coming with the advent of autonomous vehicles. This is where the risk of electronic system malfunction transforms from problematic to potentially lethal.

ISO 26262 is really a standard for completed systems, where the operation of the subunits is in a known context. Without an operational context, not enough is known to provide any meaningful qualification. Nevertheless, the components of these systems need to be designed, at each level, with consideration of the final qualification requirements.

ISO 26262 starts by identifying every anticipated failure event and assigning an ASIL to each. ASIL is a way of determining the severity of the failure. ASIL A being the least severe and easiest to recover from, and ASIL D being the most dangerous and also difficult to handle. A door lock mechanism failure is quite a bit different than a failure in a fully autonomous driving system. Indeed, the error checking and recovery methods for ASIL D are extensive and require a lot of forethought – even at the IP level during system design.

During the Linley Processor Conference in early October in Santa Clara, Michael Thompson, product marketing manager for Synopsys ARC HS processors, gave a presentation discussing how IP needs to be designed so that it can be incorporated into ASIL A to ASIL D qualified systems. He was quick to point out that even as reliability features are being added, the complexity and performance requirements are rising dramatically as well. For instance, by 2020 it is expected that the electronics content of an automobile will reach 35% and there will be ~100M lines of code. By 2030 the electronic content will be closer to 50% and there will be ~300M lines of code.

Michael mentioned that for ASIL C and D, fault injection testing is highly recommended. For ASIL D the expected single point fault detection rate should be 99% or better. Multipoint faults are also intended to be detected at better than 90%. Below is a slide from his presentation showing the expected effectiveness for a range of diagnostic methods.

To deal with high performance requirements and ISO 26262 safety features, Synopsys presented their ARC HS Quad Core targeted toward the automotive market. Michael gave an overview of its safety features. Synopsys has developed a dedicated safety manager unit that is responsible for the HS cluster bring up. It also manages boot time LBIST and MBIST. The safety manager additionally monitors and executes safety escalations on the SOC.

Synopsys also offers an integrated safety bus architecture. This is involved in passing error information and monitoring other ASIL ARC cores. The memories integrated into the HS Quad Core are ASIL D ready with support for ECC. Internally there is parity checking for processor registers and other safety critical registers. Each core has its own dedicated safety manager and watchdog timer. For bus transactions there is ECC protection on AXi/NoC for address and data values.

Safety monitoring is accomplished with error injection to verify and test the safety mechanisms. Tailored SW diagnostic tests are also supported. Power on and reset LBIST, SMS and SHS are part of the safety monitoring system. Michael’s presentation went into detail on the specifics of the integrated safety features.

Another key element of successful ISO 26262 qualification is component and system level documentation. Without adequate and proper documentation, no IP can be included in a system intended for ISO 26262 qualification. Furthermore, the same is generally true for the development tools used to build and integrate the IP – including software development tools used subsequently to complete the operational system. Synopsys has gone to great lengths to provide a tool chain suitable for ISO 26262 qualification. This extends to compiler, IDE and debugger support.

As the transition from assisted driving to autonomous driving takes place, both the performance and reliability of the onboard electronics will need to increase. Autonomous vehicles will call for much higher data processing requirements with zero room for functional failure. Certainly for autonomous vehicles to succeed, consumers will have to have full confidence in their safety. We used to think of automotive safety in terms of steering linkage, brake line and gearbox reliability. However, with increasing semiconductor IP content and its significant role in vehicle operation, it is this IP that will become the focal point of reliability concerns and activity. It is a good thing that ISO 26262 lays out a definite process for achieving the necessary quality goals. It is heartening to see products, such as the Synopsys ARC HS Quad Core IP coming to market to deliver on the needs of fully autonomous driving. For more information on the full line of Synopsys ARC HS cores, please visit their website.

November 9, 2017

The DIY Syndrome

The DIY Syndrome
by Bernard Murphy on 11-09-2017 at 7:00 am
Categories: Aldec, EDA

When facing a new design objective, we check off all the established tools and flows we know we are going to need. For everything else, we default to an expectation that we will paper over the gaps with scripting, documentation and spreadsheets. And why not? When we don’t know what we will have to deal with, in documentation, scheduling, project communication or requirements tracking, starting with unstructured MS Office documents (Word, Excel, PowerPoint) looks like a no-brainer. There’s nothing new to learn and because these documents are unstructured, you can do whatever you want and adapt easily as needs change.

This works well when supporting the needs of a small team, or even larger teams when expectations around structure and traceability are primarily informal and any compliance documentation required with products can be generated through brute-force reviews. But it doesn’t work so well when you’re trying to track changes across multiple inter-dependent products and you need to keep track of how changes relate to evolving requirements, why changes were made, the discussion that went into accepting (or rejecting changes) and being able to defend all of that to a customer or in a compliance review.

This isn’t about design data management (DDM); of course you need to handle that too. This is about traceability in the decision-making that went into approving changes to the requirements, which ultimately led to the design changes tracked in the DDM. You can store comments in a DDM when you check-in a design change but 99 times out of 100 these are pretty informal, and far from meeting traceability requirements of standards like DO-254.

So you decide to manage requirements changes/tracing in Word or Excel or a combination of the two. Seems reasonable. You turn on review tracking so reviewers can add comments and make changes. Nice and disciplined, traceable, you know who made what comments, what’s not to like? Again, there’s nothing wrong with this approach when what you are doing is entirely for the benefit of a local team, isn’t going to lead to need for automation and doesn’t have to be formally shared with independent and distributed design team or with customers.

When any of these needs arise, DIY (do it yourself) requirements tracing in Office starts to show some fairly serious weaknesses. I’ll use Word to illustrate; Excel is better in some respects, worse in others. We’ll ease into why slowly, starting with revision tracking. With tracking turned on, Word does a good job of tracking changes and comments, requirements by requirement, but it doesn’t show when comments or changes were made, comments are not time-ordered and, without manually-added information, there is no way to link a change or comment to a higher-level requirement or to impact on lower-level functions.

In addition, anyone who has used revision-tracking in Word knows that after a few rounds of review, text littered with edits and comments becomes difficult to read. You have a meeting in which you agree to accept all changes (or a subset), the text is cleaned up but you just lost traceability and, if you remove comments, history on why changes were made. When the document is finally released, all of those edits and comments disappear.

Suppose you decide to restructure the document; maybe a select set of requirements and associated comments should be moved under a different higher-level requirement. Do you do this with change tracking on (which will mess up your document even more) or do you turn tracking off, make the move then hope you remember to turn it back on again? This gets scary when structure changes become common.

Of course you can revision control the doc in a DDM, but how often should you do that? Per individual change (in which case, why are you using Word tracking) or periodically? If periodically, how easily can you compare versions of the document, which may contain figures and other explanatory text for requirements, varying substantially between versions? Methods to compare documents work well up to a point but can be derailed by significant differences. Which makes it very painful to compare how requirements have evolved over time.

Then think about how you might handle hierarchy. Requirements generally aren’t a flat list. There are top-level requirements, sub-requirements under each of these and so on down to leaf-level requirements. You could put all of this in a single document with sections and sub-sections and sub-sub-sections and so on until Word has right shifted so far that whatever text and diagrams you have to enter are squeezed into a narrow column at the right of the page. You might also start to worry about Word reliability on large documents. Word is a great tool, very widely used but I have personal experience that as documents get very large, behavior starts to become unpredictable.

More probably you split the whole thing into multiple documents, but now you have to track interdependencies between these documents. Word doesn’t provide much help there. You might use hyperlinks but how are you going to handle ancestor and descendent connections on a requirement? And you better be careful about file locations – moving files could break links. Maybe put it all in a sharefile location – more complications.

Which brings me to another point; in general, how do you plan to track relationships between requirements in Word? And if you make a change to a requirement, how do you know what other requirements will be impacted? In theory through the document organization, but how many projects do you know of where all requirements are nicely bounded in a tree hierarchy so that any change in a requirement will only impact sub-requirements, and all appropriate sub-requirements (a coverage question)? Conversely, what will be impacted in higher-level requirements if I change this requirement?

There are more issues, but you get the point. Using Word or Excel starts easy but can become very cumbersome very quickly. A common reaction at this point is to launch a project to develop Visual Basic software or something similar to automate away these problems. At that point, you should say “stop – what are we doing?”. I have personal experience in developing apps around Word and Excel. It’s do-able, it takes a lot of time and it takes a lot of maintenance. Is that really the best use of your time, or should you look for an existing commercial solution?

You might check out Aldec Spec-TRACER. It addresses all of these points, it can import existing documents and output spec, compliance and other documents. In the long haul, it will cost you a lot less than your DIY project and it won’t go up in smoke as soon as the one person who understands the doc and customization finds another job. You can watch an Aldec webinar on this topic HERE.