SemiWiki – Page 569 – The Open Forum for Semiconductor Professionals

March 10, 2017June 14, 2019

Eclipsing IDEs

Eclipsing IDEs
by Bernard Murphy on 03-10-2017 at 7:00 am
Categories: EDA, Sigasi

In a discussion with Hilde Goosens at Sigasi, she reminded me of an important topic, relevant to the Sigasi platform. Some aspects of technology benefit from competition, others less obviously so and some absolutely require standardization. Imagine how chaotic mobile communication would be if wireless protocols weren’t standardized. That’s an obvious case, shared with many other “invisible” standards whose details aren’t directly apparent to us consumers. Some standards are much more visibly apparent, some open standards, some defacto standards.

The Android interface is a good example. Perhaps user experience (UX) interfaces are the next battleground for adoption of standard/open solutions. Android took off because phone manufacturers saw Android lowering the barrier to consumer acceptance and in improved integration between applications. Why shouldn’t the same reasoning apply in professional and technical applications? That doesn’t mean that, following Highlander, there shall only be one. We still have iOS and Android but, thank goodness, we don’t have 50 different phone UXes.

In system UXes we have Windows and MacOS and a variety of flavors for Linux – Gnome and KDE among others. This is a bit more scattered, but users tend to live in one environment or switch between a favorite Linux UX and one of the mainstream UXes, so not too bad. IDEs (integrated development environments) tend to be much more tool-specific. Think of Visual Studio from Microsoft and DreamWeaver from Adobe. These are custom-crafted interfaces, tuned to work with the vendor’s underlying technology – compilers, profilers, debuggers and so on. They allow for plugins from 3[SUP]rd[/SUP]-parties but if there isn’t a suitable plugin or you want to link to a tool from a competing vendor, you may be out of luck.

Which is probably why Eclipse, an open-source IDE, recently ranked in one index as one of the top two IDEs (Visual Studio was slightly ahead) with more than 2x market share over the nearest rival. Software developers need to jump around between a lot of different development, build, test, debug and visualization contexts, so the less unnecessary differences there are between these contexts, the better. Individual application windows still have their own menus, buttons and visualizations but the basic look and feel across the system is the same and the platform encourages tight interoperability between views (copy/paste, cross-probing and so on). Eclipse already has support for C/C++, Java, PHP, JS, CSS, HTML, along with lots of tools for Python, UML, Git, Subversion, among other development options. Why try to recreate or integrate all of that in a custom UX?

What does this have to do with hardware design? Tool vendors necessarily started and have evolved with the UX platforms that were available – originally perhaps Tcl/Tk, more recently Qt. Switching to a new UX platform is a very big and expensive transition (not so much a competitive issue), so movement in this area isn’t happening quickly. Nevertheless, Xilinx, Altera, Mentor and ARM all have investment in Eclipse-based tools for obvious reasons. If development in your environment also must support integration with a wide range of embedded software tooling, you have no hope of adequately supporting all possibilities in a proprietary UX; you must go with an open environment. The same pressures are likely to be seen in EDA tooling, where the line between hardware and software build and debug is increasingly blurred.

There’s another important consideration; safety standards like ISO 26262 are creating a lot of interest in building integration around common platforms like Eclipse, to minimize potential disconnects and information loss in transitioning between disconnected tools. Over time, expectations here are likely to switch from desired to required. I’d be unsurprised to learn that hardware tool vendors are fully aware of this need and already have plans in this direction.

Of course Sigasi already support Eclipse. You can integrate Sigasi code creation, checking and other tooling directly alongside your other Eclipse tools. You can get more information HERE.

Improved Timing Closure for Network-on-Chip based SOC’s

Improved Timing Closure for Network-on-Chip based SOC’s
by Tom Simon on 03-09-2017 at 12:00 pm
Categories: Arteris, IP

Network on chip (NoC) already has a long list of compelling reasons driving its use in large SOC designs. However, this week Arteris introduced their PIANO 2.0 software that provides an even more compelling reason to use their FlexNoC architecture. Let’s recap. Arteris FlexNoC gives SOC architects and designers a powerful tool for provisioning top level interconnect. SOC’s have long since passed the days where connections between the blocks can be hardwired. Routing resources are too scarce, and flexibility for inter-block communication and data exchange has become paramount.

NoC is added to a design as RTL blocks that manage data exchange between blocks over a high performance and reliable on-chip network. Arteris’ FlexNoC is even capable of supporting cache coherent memory interfaces. Now, to understand why PIANO 2.0 is important it’s key to understand that a significant variability in timing closure efficiency is introduced when moving from the front end to the back end. PIANO 2.0 delivers a strong connection between RTL spec and the later physical timing closure steps. Until now, NoC implementation optimization was akin to being limited to wire load models instead of full parasitics.

PIANO 2.0 promotes intelligently moving interface elements away from their host or target blocks and into the routing channels. This works remarkably well for improving area and performance. The building blocks for an NoC are small and ideal for fitting in the ‘grout’ of the design. However, their placement and the provisioning of supporting pipeline stages can have a significant effect of area, power and timing.

Without any hints from the front end, placement tools will often cluster NoC logic blocks in ways that fails to meet timing, or that requires the addition of pipeline stages. One contributing factor is that in 28nm and below, many interconnect paths between top level blocks are simply too long for the signal to arrive in under one clock cycle. Attempting to fix this by adding more pipeline stages or relying on LVT cells can consume critical area and add to static and dynamic power consumption.

Arteris has added feedback loops so that physical implementation tools from Cadence and Synopsys can create better placement for these interconnect IP blocks. It is axiomatic that better communication between front end and back end design teams will improve design results and reduce unnecessary iterations. PIANO 2.0 help facilitate front to back dataflow in a systematic fashion.

Arteris provides some benchmark results to support the effectiveness of PIANO 2.0. In their first example, they provide data on a design with no pipeline stages starting with Design Compiler and only using wireload models that is forecast to require 385K sq microns. Taking this same non-piplelined design to DC Topological, it fails timing by 1.26ns and the interconnect IP area has grown to 830K sq microns. To make this meet timing with manual pipeline additions, the interconnect IP area grows to 1,008K sq microns. Instead, by using PIANO 2.0 the design meets timing with an interconnect IP area of 806K sq microns. This result also saves 46nW over the manually pipelined case.

In another example Arteris provides, they compare manual pipeline insertion with Auto Pipeline in PIANO 2.0. There was an 11% reduction in interconnect IP area, from 1.77M sq microns to 1.58M sq microns. The process for pipeline insertion went down from 45 days to 1.5 days as well. This 28nm design has 20 power domains, 10 clocks running between 100 and 400 MHz and 160 NoC NIU sockets.

Arteris is including endorsements from several major customers and EDA vendors in their product announcement. Among them is Horst Rieger Manager at the Design Services Group in Renasas and Dr. Antun Domic, CTO at Synopsys. Also, Senior Analyst Mike Delmer with the Linley group commented on the technology in the Arteris press release on PIANO 2.0.

Arteris PIANO 2.0 offers an effective solution for getting rapidly to timing closure with all the added benefits of an NoC architecture. This is not an incremental improvement either. It dramatically improves area, congestion, power and timing. Given that it works for coherent and non-coherent interconnect, it should be widely applicable to almost any design at 28nm or below.

March 9, 2017March 22, 2022

ClioSoft Crushes it in 2016!

ClioSoft Crushes it in 2016!
by Daniel Nenni on 03-09-2017 at 7:00 am
Categories: Cliosoft, EDA

If you are designing chips in a competitive market with multiple design teams and IP reuse is a high priority then you probably already know about the ClioSoft SOS Platform. What you probably did not know however is how well they are doing with the re-architected version of their integrated design and IP management software.

We have been covering ClioSoft since SemiWiki started in 2011 and have published 71 blogs that have been viewed almost 300,000 times by people all over the world so we know them quite well. You can see the ClioSoft SemiWiki landing page HERE. One thing you will notice is that ClioSoft has a very loyal customer base and they are not shy about sharing their experiences with the ClioSoft software and heaping praise on the company. The other thing you should know about ClioSoft is that for a relatively small company, they throw a very big customer and partner appreciation party at DAC!

In general we do not publish press releases but I believe that ClioSoft’s accomplishments in 2016 deserves special recognition so here it is:

ClioSoft Closes 2016 with Continued Growth
Best-in-class design collaboration platform drives new contracts, customers and renewals

FREMONT, Calif., February 28, 2017 — ClioSoft, Inc., a leader in system-on-chip (SoC) design data and intellectual property (IP) management solutions for the semiconductor design industry, today reported a 20% increase in new bookings for 2016 along with further adoption of ClioSoft’s SOS7 design management platform by existing customers. Thirty new accounts were added to ClioSoft’s existing customer base of over 200 customers in 2016. The rise in bookings was due to an increased growth in analog and RF designers adopting ClioSoft’s SOS solution and an upsurge for it IP management solution.

SOS Virtuoso and SOS ADS, used by the analog and RF designers, is built on top of the SOS7 design management platform. The SOS7 design management platform enables designers to work with other team members, located either locally or at remote design sites, to build and collaborate on the same design, from concept to GDSII.

“It has been a good year for us especially for the SOS7 Design Management Platform” said Srinath Anantharaman, founder and CEO of ClioSoft. “SOS7, which is the re-architected update to the existing SOS design management platform, is being received very well amongst our customers. Released about a year and a half back, a number of companies have now started to standardize on the SOS7 design management platform, which has been built for performance, security and reliability. SOS7 takes design collaboration to a whole new level and has helped us win enterprise accounts from our competition.”

“ClioSoft’s SOS7 design management platform has helped us collaborate efficiently between designers located at multiple sites and improve the productivity of our design teams,” said Linh Hong, Vice President and General Manager of Kilopass OTP Division. “It is important for us to manage the numerous design revisions and at the same time enable the design teams to work efficiently. The tight integration of SOS with EDA tools such as Cadence[SUP]®[/SUP] Virtuoso[SUP]®[/SUP] Platform makes it easy for our engineers to develop the next generation memories and work together without stepping on each other’s toes. SOS provides high performance and the flexibility needed to manage the handoffs of complex design flows including fine grained access control to our project data. Moreover, the quality and responsiveness of ClioSoft’s support team is outstanding.”

ClioSoft provides the only design management platform for multi-site design collaboration for all types of designs – analog, digital, RF and mixed-signal. By facilitating easy design handoffs along with secure and efficient sharing of design data from concept through tape-out, SOS7 platform allows multi-site design collaboration for dispersed development teams. Tight integration with several EDA tools from Cadence, Keysight Technologies, Mentor Graphics and Synopsys[SUP]®[/SUP] with SOS7 provides a cohesive design environment for all types of designs and enables designers across multiple design centers to increase productivity and efficiency in their complex design flows. In addition to enabling design engineers to manage design data and tool features from the same cockpit, SOS7 provides integrated revision control, release and derivative management and issue tracking interface to commonly used bug tracking systems. Using SOS7 helps reduce the possibility of design re-spins.

About ClioSoft
ClioSoft is the pioneer and leading developer of system-on-chip (SoC) design configuration and enterprise IP management solutions for the semiconductor industry. The company’s SOS7 Design Collaboration Platform, built exclusively to meet the demanding requirements of SoC designs, empowers multi-site design teams to collaborate efficiently on complex analog, digital, RF and mixed-signal designs.

The collaborative IP management system from ClioSoft is part of the overall SOS Design Collaboration Platform. The IP management system improves design reuse by providing an easy-to-use workflow for designers to manage the process of shopping, consuming and producing new IPs. ClioSoft customers include the top 20 semiconductor companies worldwide. ClioSoft is headquartered at 39500 Stevenson Place, Suite 210, Fremont, CA, 94539. For more information visit us at www.cliosoft.com.

Also Read

CEO Interview: Srinath Anantharaman of ClioSoft

Qorvo Uses ClioSoft to Bring Design Data Management to RF Design

Qorvo and KeySight to Present on Managing Collaboration for Multi-site, Multi-vendor RF Design

March 8, 2017July 18, 2025

Synopsys and PhoeniX Demo Photonic IC Flow Using AIM PDK at OFC

Synopsys and PhoeniX Demo Photonic IC Flow Using AIM PDK at OFC
by Mitch Heins on 03-08-2017 at 12:00 pm
Categories: Silicon Photonics, Synopsys

Synopsys has long been known for its leading position in the digital logic synthesis world. More recently however, the company started delving into the world of photonic integrated circuit (PIC) design. Synopsys started down this path from the system level with a 2010 acquisition of Optical Research Associates and their CODE V and LightTools products. These products deal with discrete optical components and free-space optics. They then moved down into the photonic IC level with a 2012 acquisition of RSoft Design Group that brought with them several very good photonic simulation engines.

The RSoft group, now part of Synopsys’ Optical Solutions Group, brought with it simulation tools at both the system and component levels. At the component level, these tools are very much like what Synopsys offers for electronic technology CAD (TCAD). Their offerings include tools for mode solving, beam propagation (BPM and FDTD) and modeling for diffraction elements, gratings and active devices like lasers, to name a few.

At the system level, RSoft brought into Synopsys a simulator called OptSim. OptSim is well known in the photonics industry and was historically focused on telecommunications systems and datacom applications. Synopsys continues to sell this software and has also augmented the platform and pushed it into the PIC world with release of OptSim Circuit. OptSim Circuit is, as its name implies, a circuit level simulation environment for PICs.

I say environment because, like its predecessor OptSim, OptSim Circuit brings with it all the features you need to easily capture and simulate a PIC design. OptSim Circuit uses an easy-to-learn drag and drop schematic capture environment that features hierarchy and a library of parameterized high-level photonic building blocks that can be used to create a circuit. The platform enables designers to model at different levels of abstraction and then verify the functional implementation against system models used during system level simulations.

OptSim Circuit includes the ability to easily set up complex test benches for multiple what-if scenarios and allows designers to run sweeps through parameter ranges and to check for impacts of process variations on critical design parameters. The software also enables visualization of simulation outputs in terms familiar to system designers such as eye diagrams, BER, FSR, etc.

More recently, Synopsys completed a PDA Flow link with PhoeniX Software to enable a bridge between the system- and circuit-level functional PIC design and an implementation of the design targeted to a specific foundry and packaging technology. PhoeniX Software specializes in PIC design layout tools. Their product, OptoDesigner, also uses PDKs and a library of high-level parameterized photonic building blocks. Using the PDA Flow link, PhoeniX can take the circuit from OptSim Circuit and synthesize a foundry-specific DRC correct layout that matches the design intent as described by the designer in OptSim Circuit.

Synopsys and PhoeniX will be jointly demonstrating this new flow at the Optical Fiber Conference (OFC) in Los Angeles in a couple of weeks. The demo will be given at the Synopsys booth #2519 on March 21[SUP]st[/SUP] and 22[SUP]nd[/SUP] from 10:00a to 12:00p and 2:00p to 4:00p, respectively. A feature of this demo is that they will be using the AIM Photonics PDK to show that this flow can in fact be used to create designs that can be fabricated now on MPW runs using the AIM Photonics silicon and silicon nitride processes.
Synopsys and PhoeniX have also completed work with the LioniX foundry in Europe to support this same flow with the LioniX Triplex (silicon nitride) technology.

While this flow is similar to what is done in the electronic world between capture/simulation and place and route, it is also very different. The differences come from the fact that the waveguides that connect photonic components are not simple connectors. With the right conditions, waveguides can actually become components in their own right that dramatically affect the signal. They can even be used to modulate the signal depending on how they are built. Given this phenomena, the photonics schematic takes on a much larger role than in electronics, in that the designer needs to comprehend some of these layout affects even while working in an abstract schematic.

The flow between Synopsys and PhoeniX enables this by allowing the designer to capture schematic connections as a combination of waveguide segments. These segments can be modeled and simulated with the rest of the circuit to allow the designer to ensure correct functionality. The segmented connections are then passed on to the PhoeniX layout tools through the PDA link, where they are synthesized per the parameters in the schematics. Placement of components and waveguide segments are accomplished by the PhoeniX tools based on the relative placements of components and waveguide segments in the schematic. PhoeniX uses something called elastic-connectors along with the relative placement information of components and waveguide segments to enable the physical placement and routing of the waveguides to meet the designer’s intent.

If you are curious to see how this all works, Synopsys and PhoeniX encourage you to stop by the Synopsys booth at OFC at the appointed times.

March 8, 2017

The Real Lesson from the AWS Outage

The Real Lesson from the AWS Outage
by Matthew Rosenquist on 03-08-2017 at 7:00 am
Categories: Security

The embarrassing outage of Amazon Web Services this week should open our eyes to a growing problem. Complex systems are difficult to manage, but if they are connected in dependent ways, a fragile result emerges. Such structures are subject to unexpected malfunctions which can sprawl quickly. One of the most knowledgeable technology companies on the planet learned just such a lesson this week. Amazon’s star-child, their cloud services, had a major disruption. It was not a nation-state attack, sophisticated teams of cyber-hackers, or even malicious insiders bent on destruction. Nonetheless, the lessons are telling. The ramifications of which will be important to all of us.

Summary of the Amazon S3 Service Disruption: We’d like to give you some additional information about the service disruption that occurred in the Northern Virginia (US-EAST-1) Region on the morning of February 28th. The Amazon Simple Storage Service (S3) team was debugging an issue causing the S3 billing system to progress more slowly than expected. At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended…

It was one employee, typing a few wrong codes, that caused a significant outage to major portions of the Internet. Amazon worked furiously to contain and recover from the incident. It will have to rebuild trust with customers whom were sold on the resiliency of ‘cloud’ services to avoid such events. Amazon has already stated they will learn from the event and will apply some compartmentalization controls to lessen potential damage in the future. But there is a more significant realization to be made.

The greater lesson for us all is that when hugely sophisticated systems interconnect with each other, there is an exponential increase in complexity. Due to reliance, authority, and trust, these structures can fail in spectacular fashion. The AWS example show how such a situation allows a series of cascading unintended effects, that cannot easily have been predicted, to occur and cause widespread impacts. As bad as it may have appeared, it was not too severe. If it were an intentional attack from a capable, motivated, and sophisticated attacker, I believe the results would have been catastrophic.

With the AWS outage we can see the impact of an unintentional accident and the difficulty to recover when everyone is working together to resolve the issue. Now imagine what a malicious and focused cyber-threat could do while being stealthy, striving for maximum damage, and actively undermining countermeasures and recovery actions of response teams.

If this were a malicious insider or professional hack, the damage would be a thousand times worse. We would still be picking up the shattered pieces. There would be tears falling from the AWS cloud.

This week it was cloud storage services making websites unavailable. What happens when it is a fleet of autonomous vehicles which put lives at risk or the complex national power grid infrastructure?

We must take a fresh look at understanding threats, risks, countermeasures, and protection practices as individual pieces of the computing world are growing much more complex and being connected. Traditional methods are not sufficient in understanding how chain reactions can occur in the next generation of new technologies and services.

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

March 7, 2017

Automotive OEMs Get Boost as NetSpeed NoC is Certified ISO 26262 Ready

Automotive OEMs Get Boost as NetSpeed NoC is Certified ISO 26262 Ready
by Mitch Heins on 03-07-2017 at 12:00 pm
Categories: Automotive, IP, NetSpeed Systems, Security

I read with great interest today news from NetSpeed Systems that both their Gemini and Orion NoC IPs have been certified ISO 26262 ASIL D ready. They were certified by SGS-TUV Saar GmbH, an independent accredited assessor. This is a big deal as up till now, it was left up to the OEMs to do most of the heavily lifting to qualify their IC’s interconnect for the ISO automotive functional safety standard. To be clear, they still do, however if they use NetSpeed’s certified NoC IP, a significant burden has been lifted.

To compete in the automotive space, SoC platforms are created and derivatives are generated for market segment differentiation. Many of the big blocks remain the same for the derivatives while new blocks are added and configuration of blocks are changed. The interconnect portion however always changes when doing derivatives. Each time this happens, designers have to re-create a new NoC based on a new floorplan and different anticipated traffic patterns, QoS and safety/security requirements for the design. Doing this by hand is a big burden for designers, especially when you factor in that they must make sure the new NoC now meets all of the new QoS, power, performance and safety requirements and is once again ISO 26262 compliant to the ASIL level required.

NetSpeed’s synthesis capabilities make the task of creating a new NoC incredibly easy. Designers can quickly change constraints and then re-synthesize the NoC. The cool part is that NocStudio, the synthesis tool doing all of this work, now understands the ISO 26262 standard and can give designers an estimate of the new NoC’s ISO 26262 ASIL score and level before it is even synthesized.

At this point, it should be noted that the NetSpeed NoC IP has been certified ready for ASIL-B (90% SPFM) through ASIL-D (99% SPFM) levels depending on how the NoC is configured. It should also be noted that NetSpeed’s solution is the first coherent NoC IP to be certified ISO 26262 ready. This is especially important for state-of-the-art automotive SoCs targeted for autonomous vehicles. Those SoCs have complex interactions among heterogeneous CPU cores, clusters, vision processors and storage and the complexity has gotten to the point that it has become nearly impossible to build these types of interconnects by hand. NetSpeed takes on this challenge leveraging advanced machine learning algorithms to build correct-by-construction designs that can manage the complexity while also ensuring coherency and functional safety as part of the solution.

From the ISO 26262 point of view, NetSpeed’s architecture has safety built in at multiple levels, including defect checks for both end-to-end and hop-to-hop failures. Additionally, NetSpeed lets the designer fully specify NoC master slave relationships not only in terms of QoS and security, but also for specific ASIL targets. Unlike other NoCs, NetSpeed’s NoC IP enables the designer to customize the NoC to be as heterogeneous as the design it serves. Master slave relationships can be set up for varying ASIL coverage and secure and/or non-secure data transmission. Specific masters can also be blocked from specific address ranges that may include multiple slaves. This can be done at synthesis time, creating a hardwired firewall or dynamically at run time, without the need to split the interconnect.

This brings me my last point. As with most problems, the best solutions are those that holistically take into account a problem from the beginning when early design trade-offs can be made with more degrees of freedom. Adding features like NoC coherency and functional safety onto an existing fixed architecture is extremely costly, both in terms of system performance and area. NetSpeed’s ability to synthesize in and optimize both of these functionalities at different levels of granularity makes a huge difference in the quality of the design generated.

A key point here is that NetSpeed is unique in their ability to optimize not only specific QoS, power, performance and area metrics but they can also target specific ISO 26262 ASIL levels in different parts of the system. You can’t do this if you don’t look at the problem holistically.

Interestingly, the ISO standard reviews not only your design, but also your design team and how they do their work. The reason the NetSpeed team is now certified ready for ISO 26262 is because they think holistically and methodically and it shows in their products.

March 7, 2017June 14, 2019

Perspective in Verification

Perspective in Verification
by Bernard Murphy on 03-07-2017 at 7:00 am
Categories: Cadence, EDA, Events

At DVCon I had a chance to discuss PSS and real-life applications with Tom Anderson (product management director at Cadence). Tom is very actively involved in the PSS working group and is now driving the Cadence offering in this area (Perspec System Verifier), so he has a pretty good perspective on the roots, the evolution and practical experiences with this style of verification.

PSS grew out of the need to address an incredibly complex system verification problem, which users vociferously complained was not being addressed by industry-standard test-bench approaches (DVCon 2014 hosted one entertaining example). High on the list of complaints were challenges in managing software and use-case-based testing in hardware-centric languages, reusability of tests across diverse verification engines and across IP, sub-system and SoC testing, and in managing test of complex constraints such as varying power configurations layered on top of all that other complexity. Something new was obviously needed.

Of course, the hope in cases like this is “#1: make it handle all that additional stuff, #2: make it incremental to what I already know, #3: minimize the new stuff I have to learn”. PSS does a pretty good job with #1 and #3 but some folks may feel that it missed on #2 because it isn’t an incremental extension to UVM. But reasonable productivity for software-based testing just doesn’t fit well with being an extension to UVM. Which is not to say that PSS will replace UVM. All that effort you put into learning UVM and constrained-random testing will continue to be valuable for a long time, for IP verification and certain classes of (primarily simulation-based) system verification. PSS is different because it standardizes the next level up in the verification stack, to serve architects, software and hardware experts and even bring-up experts.

That sounds great but some observers wonder if it is over-ambitious, a nice vision which will never translate to usable products. They’re generally surprised to hear that solutions of this type are already in production and have been in active use for a few years; Perspec System Verifier is a great example. These tools predate the standard so input isn’t exactly PSS but concepts are very similar. And as PSS moves towards ratification, vendors are busy syncing up, just as they have in the past for SVA and UVM. Tom told me that officially the standard should be released in the second half of 2017.

How does PSS work? For reasons that aren’t important here, the standard allows for two specification languages: DSL and a constrained form of C++. I’m guessing many of you will lean to DSL so I’ll base my 10-cent explanation on that language (and I’ll call it PSS to avoid confusion). The first important thing to understand is that PSS is a declarativelanguage, unlike most languages you have seen, which are procedural. C and C++ are procedural, as are SV, Java and Python. Conversely, scripting for yacc, Make and HTML is declarative. Procedural languages are strong at specifying exactly “how” to do something. Declarative languages expect a definition of “what” you want to do; they’ll figure out how to make that happen by tracing through dependencies and constraints, eventually getting down to leaf-level nodes where they execute little localized scripts (“how”) to make stuff happen. If you’ve ever built a Makefile, this should be familiar.

PSS is declarative and starts with actions which describe behavior. At the simplest level these can be things like receiving data into a UART or DMA-ing from the UART into memory. You can build up compound actions from a graph of simple actions and these can describe multiple scenarios; maybe some steps can be (optionally) performed in parallel, some must be performed sequentially. Actions can depend on resources and there can be a finite pool of resources (determining some constraints).

Then you build up higher-level actions around lower-level actions, all the way up to run multiple scenarios of receiving a call, Bluetooth interaction, navigating, power-saving mode-switching and whatever else you have in the kitchen sink. You don’t have to figure out scenarios through the hierarchy of actions; just as in constrained random, a tool-specific solver will figure out legal scenarios. Hopefully you begin to get a glimmer of the immense value in specifying behavior declaratively in a hierarchy of modules. You specify the behavior for a block and that can be reused and embedded in successively higher-level models with no need for rewrites to lower-level models.

Of course, I skipped over a rather important point in the explanation so far; at some point this must drop down to real actions (like the little scripts on Makefile leaf-nodes). And it must be able to target different verification platforms – where does all that happen? I admit this had me puzzled at first, but Tom clarified for me. I’m going to use Perspec to explain the method, though the basics are standard in PSS. An action can contain an exec body. This could be a piece of SV, or UVM (maybe instantiating a VIP) or C; this is what ultimately will be generated as a part of the test to be run. C might run on an embedded CPU, or in virtual model connected to the DUT or may drive a post-silicon host bus adapter. I’m guessing you might have multiple possible exec blocks depending on the target, but I confess I didn’t get deeper on this.

So in the Perspec figure above, once you have built a system level test model with all kinds of possible (hierarchically-composed) paths, then the Perspec engine can “solve” for multiple scenario instances (each spit as a separate test), with no further effort on your part. And tests can be targeted to any of the possible verification engines. Welcome to a method that can generate system-level scenarios faster than you could hope to, with better coverage than you could hope to achieve, runnable on whichever engine is best suited to your current objective (maybe you want to take this test from emulation back into simulation for closer debug? No problem, just use the equivalent simulation test.)

We’re nearly there. One last question – where do all those leaf-level actions and exec blocks come from? Are you going to have to build hundreds of new models to use Perspec? Tom thinks that anyone who supplies IPs is going to be motivated to provide PSS models pretty quickly (especially if they also sell a PSS-based solution). Cadence already provides a library for the ARM architecture and an SML (system methodology library) to handle modeling for memories, processors and other components. They also provide a method to model other components starting from simple Excel tables. He anticipates that, as the leading VIP supplier, Cadence will be adding support for many of the standard interface and other standard components over time. So you may have to generate PSS models for in-house IP, but it’s not unreasonable to expect that IP and VIP vendors will quickly catch up with the rest.

This is well-proven stuff. Cadence already has public endorsements from TI, MediaTek, Samsung and Microsemi. These include customer claims for 10x improvement in test generation productivity (Tom told me the Cadence execs didn’t believe 10x at first – they had to double-check before they’d allow that number to be published.) You can get a much better understanding of Perspec and a whole bunch of info on customer experiences with the approach HERE.

IoT Device Designers Get Help from ARMv8-M Cores

IoT Device Designers Get Help from ARMv8-M Cores
by Mitch Heins on 03-06-2017 at 12:00 pm
Categories: Arm, Events, IoT, IP

Someone once said that IoT devices live in the wild. They must be able to withstand any number of attacks, whether they be communication, physical or software based attacks. The threats are real and the consequences can range from simple irritants to life threatening situations.

It’s because of these threats that IoT device designers are now blessed with the chance to show off their design skills by creating devices that can safely be deployed, used and updated while they live in the wild. I attended a webinar this week hosted by ARM entitled, ‘Security Principles for ARM TrustZone for ARMv8-M’. ARM does a really nice job of educating designers about their products and this webinar was no exception to the rule. The webinar gave a very nice overview of how ARM is helping IoT device designers meet the challenges of keeping their devices safe in the wild.

This webinar is one of many that can be found on ARM’s developer community web site and it primarily focused on how the ARMv8-M architecture helps designers guard against software-based attacks. At the center of ARM’s solution is their TrustZone technology. TrustZone has been around for quite some time but it takes on a different incarnation when used with the newer M33 and M23 cores.

The M33 is essentially the same as a M3 or M4 except for two very noticeable differences. The first difference is that the M33 adds a co-processor interface that can be used for management of multiple sensors envisioned to be needed in an IoT system. The second difference is that there is no longer a dedicated hardware block for TrustZone. Instead, every block within the M33 has been restructured to natively handle TrustZone functionality and capabilities. The core is taking on the full responsibility of TrustZone protection. TrustZone wise the same is true for the M23 which is functionally equivalent to the M0/M0+ ultra-low power cores but again, all of the functions have been re-engineered to handle TrustZone natively.

So what does that imply? In the new architecture, there are literally two parallel execution environments for the processor. One environment is secure, the other is non-secure. There is a new hardware block that is called the security attribution unit (SAU). The SAU is responsible for partitioning and managing all memory (instruction addresses and data) into one of these two buckets. As the processor executes, each address (of instructions or data) to be fetched has its security attribute checked. Those marked as secure are checked to make sure they are indeed in the secure address space and are being used by secure code. These instructions run in the secure execution environment. Those not so marked are checked that they are in the non-secure space and their instructions are run through the non-secure execution environment.

Each environment also has its own set of registers throughout the system and these registers are managed by the SAU. The system boots first into the secure area and once the system is reset it then runs code in the non-secure space for application boot up. The system also allows for secure vs non-secure interrupts and includes additional instructions that can be used by the software designers to check address validity in one environment vs the other. ARM has added additional instructions to the ACLE (ARM C language extensions) that enables software engineers to proactively check for things like buffers that are trying to cross secure/non-secure boundaries. This latter feature enables software designers to easily protect their code against a common attack surface known as buffer overruns.

Memory and device configuration can be controlled in one of three ways. They can be hard wired at synthesis time before manufacturing, they can be programmatically changed through code in secure memory or they can be dynamically changed by the system stack using TrustZone security protocols and Root of Trust encryption using the IDAU (implementation defined attribution unit) interface. In fact, the system configuration can literally be a combination of all three of these methods.

The new architecture also support legacy systems by overlaying two more modes (Trusted and Un-Trusted) on top of the ARMv7-M privileged and non-privileged modes. The CPU handles transitions between these modes automatically based on the attribution mappings that have been set. The new cores can also handle cross-domain function calls including calls from non-secure code that want to use the services of code in the secure section. The good news for software developers is that this is handled automatically by the new architecture through the addition of a Secure Gateway instruction call. The SG call tells the system that code from the non-secure side is asking for services from the secure code side. The hardware takes care of pushing secure registers onto the stack and zeroing out the registers before running tasks for the non-secure side. This ensures that non-secure code does not get a peek into the secure side’s memory. Once the service has completed its secure side work the hardware again automatically pop’s the secure side register values for continuation of work that was going on in the secure side before the non-secure call came in.

This last scenario is essentially a good example of what ARM is trying to achieve in general with the M33/M23 architecture. They are providing a system-wide approach to security that is highly configurable and yet easy to secure.

The main idea being to keep the existing software development paradigm in place for application developers while making it as easy as possible for the IoT system designers to be able to secure their IoT devices in the wild.

March 6, 2017January 27, 2022

CEO Interview: Alan Rogers of Analog Bits

CEO Interview: Alan Rogers of Analog Bits
by Daniel Nenni on 03-06-2017 at 7:00 am
Categories: Analog Bits, CEO Interviews, IP

It has been incredible to watch the Semiconductor IP market grow from millions to billions of dollars during my career in Silicon Valley. In fact, more than half of my professional experience involves IP so when I talk about what it takes to be successful it is certainly worth a listen.

In my opinion the key ingredient to a successful IP company is engaging with your customers, partners, and ecosystem which brings me to the #1 engaging Semiconductor IP company. During my travels around the world the IP company I run into the most, be it conferences, customers, or the foundries, is Silicon Valley’s own Analog Bits, absolutely.

When was Analog Bits formed? What was your inspiration for creating the company?
Analog Bits has been at the forefront of mixed-signal IP for last 20 years. In the early days at Sun and Fairchild I was a hands on engineer and later it became more a manager function and all we were doing is managing to cover up mistakes. I got tired of it and wanted to build a company with some of the brightest minds in the field and where I could do real engineering again and to this date I still enjoying inventing clever circuits transistors. Early on we started as a consulting company and 2003 and beyond we transformed to be an IP company more centered around merchant foundries.

How have your products evolved? What has been the basis for your lasting success?
Analog Bits has always been about listening to the needs of our customers, many of whom are leaders in their respective fields. We started with PLLs, DLL, IO’s and memory IP, and have expanded to include SERDES, PVT, POR. We are now servicing customers down to 7nm.

We’ve always heard about the importance of low power, small size, enabling customer differentiation and – of course – product quality. In addition to list of repeat customers, we have also entered newer markets such as enterprise and automotive where power is an important consideration.

Where is Analog Bits based?
We have grown as the semiconductor industry grew, but always in Silicon Valley. All of our team is based here in Silicon Valley, which has given us access to the high quality technical resources and places us close to many of our customers and serving international customer from one location. If customers need something special last minute we are able to react quickly as a team.

How have you seen the market evolve?
A few years ago, we had companies using us in digital cameras, video games and communications satellites. We keep evolving along with the industry and are now servicing diverse markets such as enterprise, IOT, automotive – and even Enterprise Storage around the world. Like all semiconductor business change is the only constant and we adapt quickly as a company to change.

What types of your products are in most popular?
Our PLL products have been a standard for many, many customers. Our SERDES PHY’s have been selected by many market leaders for use in their chips. Lately, our PVT and POR products have been seeing increased demand since they are so small and flexible. We provide our products in both custom and off-the-shelf (OTS) products, with options for semi-custom as well.

Why do so many customers return to you?
We have strong reputation for quality – in products, with our customers and in our ecosystem partnerships. I think that quality and reliability have made us what we are today. Having said that, we enable product differentiation amongst our customers – which is all about power and size efficiency. Always “works first time” helps keeps customer costs and schedules in check – and we are very proud of that.

What’s next for Analog Bits?
We have some amazing new products coming out. Support for new process process nodes is part of that but also smaller and lower power IP solutions too. Reducing the impact of mixed signal IP means more flexibility for our customers and an economic advantage of not having to have an in-house team to develop the best and depend on partners like us.

About Analog Bits
Founded in 1995, Analog Bits, Inc. (www.analogbits.com), is the leading supplier of mixed-signal IP with a reputation for easy and reliable integration into advanced SOCs. Products include precision clocking macros such as PLLs & DLLs, programmable interconnect solutions such as multi-protocol SERDES and programmable I/O’s as well as specialized memories such as high-speed SRAMs and TCAMs. With billions of IP cores fabricated in customer silicon, from 0.35-micron to 16/14-nm processes, Analog Bits has an outstanding heritage of “first-time-working” with foundries and IDMs.

Also Read:

CTO Interview: Jeff Galloway of Silicon Creations

CEO Interview: Srinath Anantharaman of ClioSoft

CEO Interview: Amit Gupta of Solido Design

March 4, 2017

ESDA Event: Power and Policy in California

ESDA Event: Power and Policy in California
by Bernard Murphy on 03-04-2017 at 7:00 am
Categories: Events, IoT

Apparently this event is now being postponed until sometime later in the year. Stay tuned

We spend a lot of our time with our heads down in the technical details and when we look up at what we think is the big picture, it’s usually just a little bit bigger, often no more than a justification for immediate product directions. So wouldn’t it be interesting once in a while to look at the really bigpicture, to understand global energy objectives, how that drives power policy in the state of California and how that drives power regulation for electronic design?

ESDA will host a panel on just this topic with an impressive line-up of speakers from the California Energy Commission and the Natural Resources Defense Council, Lip Bu (Cadence CEO) is on the panel, along with Shahid Sheikh from Intel, Vojin Zivojnovic from Aggios and Vic Kulkarni from Ansys. You’ll get to hear their views and there will a chance to network with speakers and other ESDA members.

If you’re getting a little burned out on the same old stories of why low power is important, here’s a rare opportunity to get a new and bigger perspective, and new material to refresh that aging pitch on the importance of low power. I plan to be there.

WHAT: The Electronic System Design Alliance will present an informational panel, “Energy Policy and Strategy for the IoT Era,” to outline the new rules for PCs set by the California Energy Commission (CEC). It will be moderated by Grant Pierce, chief executive officer (CEO) of Sonics, Inc. and chairman of the ESD Alliance board of directors.
WHEN: Thursday, March 23, beginning at 6 p.m. with networking, light snacks and drinks, concluding at 9 p.m.
WHERE: San Jose City Hall Rotunda. 200 East Santa Clara Street, San Jose, Calif.
The program will explain the CEC’s new energy efficiency rules and regulations for PCs and monitors, and give panelists a chance to provide their perspectives. A panel discussion and audience Q&A session will follow. Panelists include:
· Vojin Zivojnovic, founder and CEO of AGGIOS
· Dave Ashuckian, CEC’s deputy director of the Efficiency Division
· Pierre Delforge, director, High Tech Sector Energy Efficiency of the Natural Resources Defense Council (NRDC)
· Vic Kulkarni, ANSYS’ senior vice president and general manager of the RTL Power Business
· Shahid Sheikh, director in Government and Policy Group with Intel Corporation
· Lip-Bu Tan, Cadence’s president and CEO

Ashuckian and Delforge will explain how the rules came about and why they are necessary, how much energy they will save, when they will take effect and how they will be enforced. They will address what the rules mean for manufacturers and the supply chain and their implications for broader national and global energy efficiency standards for electronic products, particularly as it relates to the emerging IoT market.
Attendees will learn about potential new technical innovations in design and manufacturing, insights into energy efficiency and what impact the rules will have on their companies’ as well as industries’ energy policies and strategies. Panelists will attempt to determine how the new rules could affect the economy.
The panel is open free of charge to all ESD Alliance member companies. Non-members are welcome to attend for a fee of $40.