After months of freezing temperatures in Pittsburgh, a 78 degree wind hit me as I stepped out of the office yesterday. While I’m sure it will be cold again by the time this blog gets published, yesterday made me think about how things are changing.

In the 2017 annual HLS survey, we confirmed that wireless is the fastest growing market segment for high-level synthesis (HLS).  That wasn’t much of a surprise, because for reasons I outlined previously, wireless and HLS go together like peanut butter and jelly.

It was surprising to me that a significant number of our users were leveraging Stratus HLS for machine learning applications. Back in the early days, I used to know every user of our high-level synthesis tool (or “behavioral synthesis” tool before that!). Then, later, at least I knew each group. But now, as things have progressed, that’s no longer the case… nor is it even possible.

Nonetheless, I set forth on the quest to find out… what machine learning applications are our users building? Fast forward several months and much laughing in my face, I realize two things.

• There are more machine learning and artificial intelligence applications being developed with Stratus HLS than I expected, even after the survey results.
• There is no way I’m going to find out any details of the applications. These are the cutting edge of the cutting edge, and the actual applications are a closely guarded secret.

But along the way, I learned something arguably more important… why so many machine learning applications are designed with HLS.

The common thread seems to be the intersection of three things.

• There is no pre-existing IP to reuse or modify.
• There are multiple algorithms / architectures under consideration.
• To evaluate the algorithms and architectures, designers need to rapidly explore implementations of each

I find it interesting that the challenges for machine learning designs are similar, but not identical, as those for cutting edge wireless designs. In wireless designs, being able to modify the high-level design as the spec changes is a huge benefit of HLS. When designing machine learning applications, modifying the high-level design to explore architectures and algorithms is fundamental to the design process.

In this niche, HLS enables a fundamental change to the way hardware is designed. Perhaps this is the harbinger of changes to come in hardware design.

Gone is the day when companies (our customers) kept their use of high-level synthesis (HLS) quiet, a secret advantage over their competitors. As HLS usage became more widespread, the secret is out, and now the HLS community is talking and sharing experiences with each other.

Take CDNLive, for instance. This year, HLS discussions are happening at the CDNLive shows worldwide. Since it’s extremely unlikely any of you have visited both shows in Silicon Valley and Germany, I’ll give you the HLS highlights.

CDNLive Silicon Valley (April 2018)

Qualcomm

Tuesday afternoon started off with Rajat Dhawan of Qualcomm Technologies, Inc., presenting to an audience of over 50 people. In his presentation, “Design implementation of technology IP using High-Level Synthesis,” Rajat discussed the experiences of their team’s multiple tapeouts with Stratus HLS. He detailed the SystemC-based verification flow, and how HLS dovetails seamlessly into their corporate RTL design and verification flows.

Oh, yeah… and the audience loved the presentation. Based on audience votes, he won the Best Presentation Award for the Front-End Design track, which landed him an iPad Mini. Congratulations, Rajat!

(No, that’s not Rajat. I accepted the award on his behalf… but I didn’t get to keep the iPad Mini!)

In case you missed this presentation at CDNLive, Rajat will also be presenting at the Design Automation Conference (DAC) this year. If you are attending DAC, see him Wednesday at 5:30PM at the Cadence Theater.

Adapt IP

Next, Michael (Mac) McNamara of Adapt-IP discussed the flexibility of HLS-based IP design in, “Design and Verification of Low-Power Flexible 802.11ah IP with Stratus HLS.” Mac discussed some of the inherent difficulties when designing baseband IP that need to work with different radios, and how HLS helped to address those challenges.

He also detailed how they reacted to late specification changes. As you may remember from a past blog, this is one of my personal favorite topics… it falls into the category of, “I couldn’t have done THAT by hand!”

University of Mississippi

Finally, one of our university partners, Dr. Matthew Morrison at University of Mississippi discussed his line of research, including using HLS to develop circuits resistant to differential power analysis (DPA) side-channel attacks. (Image courtesy University of Mississippi)

CDNLive EMEA (May 2018)

Socionext

A month later at the next CDNLive in Munich, Germany (a.k.a. München, Deutschland), Socionext’s Tim Papenfuss discussed the challenges in designing a video decoder, including clock domain crossings (CDC), I/O modeling, and verification. His presentation, “Latency-Constrained Design for a Display Stream Compression Decoder with Stratus HLS,” is available in the CDNLive proceedings (login required).

Cadence Experience

Dror Constantinis of Cadence also detailed some of his experience in his 10-year love affair with HLS in his presentation, “So How Can the HLS Flow Help You Cut TTM?” Finally, Marios Karatzias and Dirk Seidler detailed “The Full-Full Flow Low-Power Solution” in their tutorial about creating low power silicon with the Cadence flow.

As I discussed in a recent Semiconductor Engineering article, “low power optimization” means different things to different people. For those who are optimizing for the lowest possible power, that effort must begin in the early system and architectural design phases. HLS links those decisions to the real power, performance, and area (PPA) impact.

Coming up

Stay tuned to hear about what other Stratus HLS users are talking about worldwide, including at Design Automation Conference (DAC) and future CDNLive’s worldwide.

As designs become complex and performance targets increase, time shrinks. Designers need to minimize time setting up design flows or trying to find workaround for many issues that might occur during tapeout. The Cadence Online Support portal ensures 24x7 technical assistance to quickly address your technical issues and queries.

In our continuous effort to improve the usability of the Online Support portal and efficiency of its usage, we are introducing access to the relevant and curated content from the tool interface (starting with 19.11 releases of Innovus, Tempus, Voltus, and Genus). This feature can now be easily accessed by running the tool in the GUI mode through the Help pulldown menu.

For more details and FAQs, click here.

We hope you will enjoy using the curated search results to troubleshoot your issues quickly and seamlessly.

-Mukesh Jaiswal

Sr. Knowledge Manager (Digital and Signoff Solutions)

There is no doubt that 2019 has seen an explosion of artificial intelligence/machine learning usage for Stratus HLS. In fact, this momentum started in 2017.

Noting the increase in machine learning applications in our user base, we researched how to efficiently move from a TensorFlow model to hardware via Stratus HLS. By July 2018, AI startup Syntiant was talking at DAC about how they went from spec to tapeout in six months.  The press has noticed, too. Kevin Fogarty at Semiconductor Engineering wrote about it in the article, “Machine Learning Drives High-Level Synthesis Boom.”

Today, we’re happy to announce a free 1-hour webinar in which Cadence’s Dave Apte, Solutions Architect for High-Level Synthesis, will walk through the process of designing custom AI hardware for low-power edge applications.

The live worldwide webinar will be Wednesday, September 25 at 09:00EDT / 14:00 BST / 15:00 CEST / 16:00 IDT / 18:30 IST.

Click here to register now!

Each year, we survey the industry to get an idea of the industry’s experiences and expectations of high-level synthesis (HLS). As in last year’s survey, approximately half of the responses were from current HLS users, and half were from non-users. This year’s anonymous survey focused on productivity.

So let's get on with the survey,,,

This was a good cross-section of HLS users and non-users, which I was very happy to see. The total number of responses is high enough that this survey is likely a decent representation of the industry.

The survey for non-users focused on their expectations of HLS. The results were remarkably in line with the 2017 survey results, so here I’ll focus on the responses of HLS users.

The first question for HLS users…

HLS users report very good productivity gains, averaging 2.7x more productive than hand-writing RTL (using the midpoint of each category). In fact, nearly half of all respondents reported at least a 2x improvement in productivity.

The next question was about verification and the HLS flow…

 In a substantial improvement since 2017, almost 50% (okay, 47%) of respondents said that verification productivity is at least 2x better, with nearly 1 in 5 reporting over 10x improvement in productivity. On average, it comes out to a 3.9x verification improvement.

So, in general, companies using HLS get even more productivity benefit in verification than design. This is good, because we all know verification is the bottleneck in today’s complex SoC’s.

And finally…

With nearly identical results to our 2017 survey, reuse and retargeting of SystemC IP is also providing good benefit. That being said, I have to admit these results are not in line with what I hear anecdotally from our user base. This is an industry survey, not just Stratus users, but still this seems low.

I hear that 5x, 10x, or more productivity improvement (e.g., months to days) seems commonplace from the Stratus users who have adopted an HLS and behavioral IP flow. Retargeting for different technologies, PPA targets (power, performance, area), and even algorithmic changes are a cinch with behavioral IP.

This gives me some more homework to dig into... Stay tuned for more details as I learn them.

So all in all, companies who have adopted HLS are realizing very good productivity benefits. Excellent!!!

At advanced nodes, there’s always a deep conflict between power, performance, and area (PPA) and design turnaround time (TAT). You already know Innovus Implementation System very smartly delivers PPA advantage and accelerates digital design TAT through various features, including its full-flow massively parallel architecture. Innovus 18.10 release takes all these benefits even further. In this blog, I will start with sharing some key highlights of 18.1 release and eventually share pointers of several technical content to learn and leverage the new release capabilities. 

Some of the key highlights are listed below:

This easily translates to some key benefits for our customers:

TAT:

• Native speedup for Optimization engines
• Up to 3x speedup for core CTS
• More multi-thread parallelization

PPA:

• SOCV aware placement in addition to optimization
• Global Sizing for efficient timing closure
• Full flow improved data and clock power, including timing and power-driven routing

Usability:

• Enhanced clock H-Tree capabilities
• New Graphical metrics reporting
• 3D layout GUI, Stylus Common UI Production, Design data sanity checking

Advanced node features and support:

Digital and Sign-off 18.1 release page captures variety of content available for several products viz. Genus, Modus, Conformal, Innovus, Tempus, Voltus etc. that you could leverage to complete your full digital design flow. This not only has various update trainings explaining new features, but also posses multiple key learning content like RAKs, Videos, etc., pertaining to 18.1 release.

Click here to access 18.1 release Page. If click to the link does not work, use direct URL: https://support.cadence.com/dsg181 on your browser window to access release page.

Contact Us

You can use 'like' and 'feedback' button on this page to share your experiences or send questions, feedbacks directly to ask_km@cadence.com.

To receive related information, directly in your mailbox, type your email ID in the Subscriptions field at the top of the page and click SUBSCRIBE NOW.

~ Mukesh Jaiswal

For years chip designers have dealt with ECO’s when their source code was written in RTL. But the move to high-level synthesis (HLS) means that their source code is now one step further removed from the gate level netlist. This naturally leaves a question, “What if I need an ECO on my Stratus  project?”

First and foremost, it’s important to understand that ECO’s are less common in the HLS flow. I’ll explain why in a follow-on article, but for now let’s focus on the question at hand… “What if I need an ECO on my Stratus project?”

Two categories of ECO

Not all ECO’s are created the same, and not everyone means the same thing when they ask that question. Broadly, there are two types of ECO’s.

In one type, which we’ll call “top-down,” the ECO is initiated with a change to the designer’s code after the RTL, gate-level netlist, or even layout is frozen. The goal is to minimize the perturbation on the downstream flow after making the change. These are typically, but not always, functional changes due to errors caught in verification or changes to the spec.

The other type, which we’ll call “bottom-up” (shocking, I know), the ECO is initiated with a change to the netlist, pre-or post-layout. The goal is to reflect the change in the designer’s code, so it stays in sync with the changed netlist. These tend to be very late (and small) functional changes or timing-related changes.

Both types of ECO’s exist regardless of whether designing in RTL or in SystemC with HLS. But it is true there is a difference when designing with SystemC®… the ECO must be propagated one more level of abstraction than before.

Fortunately, Cadence has developed solutions to assist with doing ECO’s.

• Conformal® ECO Designer can take a changed RTL description and, working with Genus  Synthesis, create a netlist patch.
• Tempus works with Innovus and Voltus to automatically detect and fix timing errors on a routed netlist, including those caused by IR drop.
• And finally, Stratus HLS can provide minimally changed RTL in its top-down ECO mode, and help to reflect bottom-up ECO’s into your original SystemC.

Here, I’ll focus specifically on the ECO flows when the block being ECO’ed was created with HLS. If you are interested in Cadence’s other ECO flows, look at the excellent Rapid Adoption Kits and Application Notes available on the Cadence support site (login required).

Top-down ECO with Stratus HLS

The top-down ECO flow, where a small SystemC ECO is propagated to a small netlist change, involves a tight integration and flow between the Stratus HLS, Genus Synthesis, and Conformal ECO Designer solutions.

It all starts with the designer making a small change in the SystemC code. Then, Stratus HLS is run in its ECO mode, which prioritizes similarity with the pre-ECO design over area optimization. Next, Conformal LEC is used to determine which RTL module(s) have changed in the ECO’ed RTL. Finally, the changed modules go through the same process as an ECO with hand-written ECO, which involves Genus and Conformal working closely together to create the netlist patch.

This process is detailed in our new Rapid Adoption Kit, “Stratus HLS ECO Example” (login required), available in the Stratus Learning Center on the Cadence support site. It includes a more detailed Application Note and a tarball containing an example and all scripts needed to run it.

Bottom-up ECO with Stratus HLS

In a bottom-up ECO, the ECO change is initiated by hand-modifiying the netlist, and then propagated up to the RTL and SystemC. The process of propagating the netlist change to RTL is unchanged from an ECO in the handwritten RTL flow. However, because the original source code was SystemC, often the change is propagated to the SystemC, as well.

To aid in that, the Stratus design database contains, among other things, bi-directional mappings between the RTL and SystemC. Using the Stratus IDE, the designer can select the changed RTL and ask the IDE to show the corresponding SystemC. This information is also available via a full-fetaured Tcl API, if you don't prefer to use a GUI.

With the mapping in hand, the designer can easily propagate the change to SystemC and verify that it works as expected after the ECO change.

Parting thoughts

In my 20-year experience with HLS experience, I’ve seen that ECO’s are less frequent for projects done with HLS compared to hand-written RTL. As I mentioned before, I’ll discuss some reasons for that in a future article.

Regardless, there are times when an ECO is required, and we have a proven solution that can help. Taken together, the Stratus, Conformal, Stratus, Genus and Innovus solutions, running in ECO mode, can greatly simplify the process of implementing ECO's.

Earlier this year, we performed the annual high-level synthesis (HLS) industry survey to get an idea of the industry’s expectations of HLS. As in last year’s survey, approximately half of the responses were from current HLS users, and half were from non-users. This year’s anonymous survey focused on HLS usage and expectations.

As usual, I’ll walk through the questions one by one below, but first let me give you what I find to be the most interesting and exciting result. 

This was a good cross-section of high-level synthesis users and non-users, which I was very happy to see. The numbers are high enough that they are likely a decent representation of the industry.

The next question is for respondents who are currently using HLS or have used HLS in the past.

I ask this question each year, because it helps to see how HLS usage is changing and diversifying. The results disprove the stereotype that HLS is only used for datapath-centric applications. Controllers and processors (15.8%) are mainly control logic, and the networking applications (17.5%) tend to be a strong mix of control and datapath. 

Other takeaways are that machine learning (4.1%) and wireless networking (9.9%) have grown significantly this year. That indicates that HLS usage in those segments is growing faster than the other segments in the graph. Not shocking, as 5G and machine learning are two of the hottest areas in electronics these days.

While it is true that 45.5% of respondents believe this will take at least 5 years (and I’m sure some would have responded with “never,” had that been an option), that means for the first time a majority believe the transition to HLS will happen sooner. Even more interesting, as I highlighted at the top of this article, is that 38.6% believe this change will happen in less than three years.

Digging into this a bit deeper, I found a direct correlation between company size (expressed as “number of designers in your organization”) and the time frame by which HLS will be the way that the majority of digital hardware is designed.

At the smaller companies, 47.1% of respondents believe HLS will be the way design is being done in 3 years, whereas only 20.0% in larger companies believe that.

This should make for an exciting new year for Stratus HLS!

One final note... congratulations to Komiya-san of Renesas who won the survey's grand prize, a GoPro HERO!

“It’s not what it is, it’s about what it can become”
-The Lorax by Dr. Seuss

Have you recently reached out to open your car and received an unexpected shock…zap! There are no financial or health implications if the door handle of your car zaps you, but an Electrostatic Discharge (ESD) zap event can instantly destroy devices worth billions of dollars. Today, we are aware of the destructive nature of ESD in integrated circuits. With the ever-shrinking device geometries and their increasing complexity, susceptibility to ESD damage has only increased in the recent years. Though it lasts less than a microsecond, a discharge to a chip’s pin or bump is of the order of several thousand volts and could be disastrous to its internal circuits. The charge must be ferreted away before the voltage reaches critical levels (and your system goes kaput!). Consequently, a full-chip ESD protection solution for signoff is required.

With the objective of providing an efficient solution for analysis and optimization of ESD protection circuitry and increasing the survivability of the core circuit, the Cadence® Voltus team is offering a robust ESD analysis flow that encompasses a massively parallel architecture for improved memory footprint, performance and scalability. The solution also offers superior usability by providing an intuitive GUI for review of the ESD analysis results.

The new ESD Analysis flow performs a fast resistance and current density check for ESD discharging paths across multiple diodes or clamps. This rule-file-based analysis allows checking of bump-to-clamp (b2c), bump-to-bump (b2b), and clamp-to-clamp (c2c) effective resistance, as well as connectivity of clamps and bumps, current density (EM) during an ESD zap event, and driver/receiver differential voltage analysis for Charged Device Model (CDM).

The Voltus ESD Analysis solution enables easy identification of ESD issues to implement an effective protection scheme through the following key differentiators:

So next time, be sure to use the Voltus ESD analysis solution to clamp high voltages and avoid a zap event!

- Team Voltus

Related Resources

Voltus IC Power Integrity Solution User Guide

• ESD Analysis

For more information on Cadence silicon signoff and verification products and services, visit www.cadence.com.

In my previous blog post, I talked about the Quality-of-Results (QoR) that are achievable using High-Level Synthesis tools like Stratus HLS and the fact that exploration of multiple RTLL architectures is often the feature that enables HLS users to beat hand-coded RTL flows in terms of QoR. That article raised the notion that "project schedule" is a critical factor when judging comparative QoR, and it often gets left out of the equation. Rather than asking, "Can HLS get better QoR than hand-coded RTL", it's important to ask "Can HLS get better QoR than hand-coded RTL in two weeks"?

In this post, I will focus more on some things that HLS can do that you pretty much cannot realistically do by hand. The example I will use is similar to one that was presented to us by a production user of HLS, so it actually does reflect reality out there in the industry.  I will show an example where HLS can find significant sharing opportunities that are difficult to find and implement by hand, and where using HLS allows you to get the area benefit of that sharing without turning your source code into an unmaintainable mess.

In general, the kinds of optimizations that can be performed by HLS tools that are beyond most hand-coders fall into the camp of dealing with massive complexity. Let's look at a simple example and then I'll extrapolate that to more complex cases.

In our simple example, we have an algorithm that implements a DCT and one that does an IDCT. These two functionalities will be mutually exclusive, in that if the DCT is active, the IDCT is idle and vice versa. Both designs are pipelined with the same initiation interval (II = pipelining throughput rate) which is "1" in our example.

The top level code for this looks like:

If we look at each of these algorithms in isolation, a pipelined version of each algorithm will use (given the constraints we provided) 192 multipliers and 400 adders. A logical organization of this would be to:

• Implement a DCT algorithm
• Implement an IDCT algorithm
• Build some switching logic and combine the algorithms in a single module with a mode switch

The problem with this approach is that it is inefficient with respect to sharing of resources. In the case where we implement these separately, we see:

With an HLS flow, however, the HLS tool can automatically share all the resources across the entire implementation (if the costing functions determine that sharing is of value) and we see:

Here, we see that the combined algorithm still only has 192 multipliers and the adder count is only 520 (some smaller adders were not shared since the shares were calculated to be not beneficial). 

Now, with 2 algorithms as similar as the DCT and IDCT, it might be possible for a hand-coder to do this level of sharing. However, as the requirements become even more complex, that task becomes almost impossible. Imagine the case where you have completely disparate algorithms AND they are pipelined at different throughput rates.

The second dimension of this that is worth noting is "how do you maintain the code?". Even I you can bite off the very complex hand-coded implementation of such shares, can you maintain that RTL code? Can one of your colleagues maintain that code?  Can you make a change to one of the algorithms and not completely break how the operations are shared with the 2nd algorithm (or the 3rd or 4th)?

With an HLS flow, you don't have to worry about how you modify the sharing in the RTL code. You simply change your top-level C++ code and rerun the HLS tool. It will figure out the sharing that is possible for you each time you make a modification.

This notion of "what optimizations can I get AND still have modular, maintainable source code" is often one of the major determining factors in how a design gets implemented. In a hand-coded RTL flow, the maintainability issue often prevents sharing of whole algorithms. With HLS, the tool doesn't care about that complexity. It just gives you the optimal result each time.

To learn more about an HLS flow that supports these kinds of optimizations, click here.

Hi Everyone,

Many of you would have heard about the Cadence Stylus Common UI and are wondering what it is and what the advantages might be to use it vs. legacy UI.

The webinar answers the following questions:

• Why did Cadence develop Stylus UI and what is Stylus Common UI?
• How does someone invoke and use the Stylus Common UI?
• What are some of the important and useful features of the Stylus Common UI?
• What are the key ways in which the Stylus Common UI is different from the default UI?​

If you want to learn more about Stylus UI in the context of implementation, view the 45-minute recorded webinar on the Cadence support site.

Related Resource

Innovus Block Implementation with Stylus Common UI

Vinita Nelson