Jack Erickson Blog

The Internet of Things – the Next Growth Driver, Enabled by High-Level Synthesis?

Jack Erickson — Tue, 14 May 2013 18:51:00 GMT

The electronics industry has enjoyed constant growth while undergoing constant transformation. One of the most significant transformations has been the source of that growth -- from the PC revolution, to the rise of the internet, to mobile computing. The consensus is that the next growth driver is going to be "the internet of things," as many call it. Wired chooses to call it "the programmable world" in their recent article that lays out a vision and a roadmap for getting there. Long read but well worth it.

From an electronics point of view, "the internet of things" (I'll stick with that name) may come across as something that will drive processor cores and microcontrollers, along with all kinds of sensors. But where is the opportunity for high-level synthesis?

Sensors of course are in the analog world because they interact with the real world. Processor cores and microcontrollers are concentrated amongst a handful of vendors, and are high-volume. These vendors can afford armies of engineers writing RTL to squeeze out every last bit of area, right? Kind of like Intel in the PC microprocessor era, designing at the transistor level? Yes and no.

We already have customers who use high-level synthesis (HLS) for microcontrollers. It speeds their time-to-market, but more importantly it allows them to adapt for different requirements. If your chip is going into Rover's dog tag, it will have different power requirements than if it's going into your refrigerator. It is much easier to change HLS constraints or specify a different microarchitecture during the HLS process than it is to go in and manually change the micro-architecture of your RTL. A lot less verification will be required for sure.

But even if you're a systems company that is going to purchase a microcontroller or processor core, along with the requisite sensors, it's likely that you will want your own special sauce to differentiate your product. For instance, maybe you want to sell security cameras that automatically recognize friendly faces. Facial recognition is a data-intensive algorithm, and in a security application you would want very low latency, so it would need to be implemented as hardware.

It's likely that you don't have an army of engineers on staff to write and verify tens or hundreds of thousands of lines of RTL (and more lines of human-written code introduces more chances for bugs, which you want to avoid in the security business!). And it's likely that you already have a C/C++ model of your algorithm that you used for system testing. This is a typical scenario we have seen in our customers. With a couple of hardware engineers -- and yes, this requires hardware engineering expertise, good hardware still cannot be built with magic -- they can adapt the C/C++ model using SystemC so that it will efficiently synthesize to hardware that meets your business requirements.

The resulting model can eventually be adapted to suit both needs -- high-speed system prototyping and efficient hardware implementation -- in a single source using the guidelines described by Stuart Swan in this video. Thus the model can be very easily re-used in future products. And with this expertise, all new models can be developed in such a manner. You don't have to do the RTL-GDSII yourself if it's not a core competency; there are plenty of design houses willing to contract that work.

This model is beginning to sound a lot like the ASIC model that really took off as part of the PC and internet growth engines. Even though processors were in everything and were being designed at the transistor level, there was a huge amount of growth in the ASICs that surrounded them as systems companies complemented these processors with their own innovative hardware. Eventually most of the functionality of the standalone ASICs was consolidated into SoCs, as happens when industries mature. But during the growth phase, most of the innovation happens in the domain experts -- the systems companies.

The internet of things presents a tremendous opportunity for growth in hardware design. All of the real world signal data coming in through all these sensors must be processed before it can be stored or consumed by the processors and microcontrollers. Many of these applications are algorithm-intense with low-latency requirements -- any sort of image, video, or audio for instance -- so hardware implementation is a must. The most economically-viable means of accomplishing this is now to utilize high-level synthesis. Many companies and engineers have already come to this realization and are widely deploying high-level synthesis. For more information on how, come visit the Cadence booth at the Design Automation Conference (DAC) in Austin June 3-5!

-Jack Erickson

Re: HOWTO - CtoS - Identify Write Ops(Specify Micro-architecture) in Source Code?

Jack Erickson — Thu, 28 Mar 2013 19:17:37 GMT

Hi Ahmad,

Sorry I missed this - there is a High-Level Synthesis forum located here which would be a better place for this:

http://www.cadence.com/community/forums/90.aspx

This forum is for hardware-software verification.

Anyway, to answer your question, the easiest way to do this is to bring your design up in the GUI ("ctos -gui"), bring up the Control-Data Flow Graph (CDFG), then right-click on the background area of the process you are interested in, and it will bring up a search dialog. You can search by name for all Ops, Array Ops, IO Ops, etc.

Thanks

-Jack

What to See at the DATE Conference: High-Level Synthesis

Jack Erickson — Thu, 14 Mar 2013 13:35:00 GMT

The DATE (Design Automation and Test in Europe) Conference is next week (March 18-22, 2013) in Grenoble, France. If you are lucky enough to be in Grenoble at this time of year, it will be worth it to check out Session 11.2 "High-Level Synthesis and Coarse-Grained Reconfigurable Architectures." This session starts Thursday at 14:00, and more details can be found on the DATE site.

The first paper in this session is entitled "Share with Care: A Quantitative Evaluation of Sharing Approaches in High-Level Synthesis". This paper offers a peek inside the main engine of C-to-Silicon Compiler high-level synthesis to see what makes it unique. Here is the full abstract:

Share with Care: A Quantitative Evaluation of Sharing Approaches in High-level Synthesis [p. 1547]Alex Kondratyev, Luciano Lavagno, Mike Meyer and Yosinori Watanabe

This paper focuses on the resource sharing problem when performing high-level synthesis. It argues that the conventionally accepted synthesis flow when resource sharing is done after scheduling is sub-optimal because it cannot account for timing penalties from resource merging. The paper describes a competitive approach when resource sharing and scheduling are performed simultaneously. It provides a quantitative evaluation of both approaches and shows that performing sharing during scheduling wins over the conventional approach in terms of quality of results.

The paper's authors are they key architects behind this engine and Alex Kondratyev will be there to present. So if you are attending DATE and are wondering whether high-level synthesis can achieve good Quality of Results, be sure to attend this session and find out how we do it!

Jack Erickson

What the 787 Dreamliner Can Teach Us About SoC design

Jack Erickson — Wed, 20 Feb 2013 19:30:00 GMT

The commercial aircraft industry is at a stage where it innovates at a much slower pace than the chip design industry -- however, we can find some parallels that offer us lessons. The most notably innovative aircraft recently developed is the Boeing 787 Dreamliner. It is the first commercial aircraft to use primarily composite materials in its construction in order to improve its fuel efficiency, which reduces operating costs for airlines and allows them to fly longer routes.

This material also enables higher cabin pressure and humidity for more passenger comfort (though those factors seem meaningless on a 13-hour flight if the airline decides to squeeze in seats at a 30-inch pitch. Just saying.) The 787 also relies much more heavily on electrical systems than any other aircraft, a feature which unfortunately has had the side effect of having a faulty battery ground the entire fleet.

An aircraft of this size is obviously an incredibly complex system. In order to get new aircraft to market with less schedule risk, the industry has traditionally taken a very incremental approach. This typically involves re-using designs and components that are previously proven, sourcing components and parts from external vendors that supply multiple aircraft manufacturers, and making incremental adjustments to fit more passengers or add newly-available technology. This sounds a lot like what our industry calls derivative design. In this case, because the overall system does not radically change, parts and subsystems can be produced more efficiently by external companies that can scale their efforts across the aircraft systems vendors. This sounds a lot like what we call IP or ASSPs, depending on the context.

This incremental, outsource-driven approach reduces risk and speeds time-to-market. But what happens when your customers need more than just a minor incremental update? What happens when you want to create a truly differentiated breakthrough product? Or even a product that defines a new category? In Boeing's case, they tried the same approach, which was really the only approach they knew. This is well analyzed over at the Harvard Business Review blog:

http://blogs.hbr.org/cs/2013/01/the_787s_problems_run_deeper_t.html

In the end, they were able to get their breakthrough product to market, but with significant delays and issues. When they first began assembling all the components and subsystems, the entire system was far overweight - have you ever worked on a chip that, once assembled, was way over the area budget?

The HBR post contrasts this approach with that of Apple. Apple famously designs products from the system -- or perhaps the user experience -- point of view, and designs all the parts and much of the electronics themselves so that they work together toward the specifications of that end-product. They still outsource manufacturing and assembly, but they do so with exact "blueprints" that result from the system design effort.

In terms of chip design, they decide what they can source externally and what they need to design themselves in order to deliver what they deem important to the success of the product. For instance there has been no need for them to design their own flash memory. But with the recent iPhone they decided to design their own processor in order to make it "insanely great" in terms of performance and efficiency.

This would be like Boeing deciding it needed to design and build its own engines for the 787 that would further improve the aircraft's weight, range, and fuel efficiency. In that context it doesn't sound like such a crazy idea. Yet aircraft engines are never designed by aircraft manufacturers these days. In fact the aircraft engine manufacturers - primarily Rolls Royce and GE - have enough market power that Boeing had to design the 787 so that an engine from either vendor could plug in, depending on what the end-customer wanted. Imagine trying to build a breakthrough smart phone with the constraint that the customer could choose which processor to plug in!

Back to chip design -- according to the previously-linked article on Apple's processor efforts, Apple spent upwards of $500M on acquiring the needed capability and then designing and laying out their own processor. It is an extreme example. Fortunately for them, they will likely sell very high volumes of iPhone 5s, as well as iPad 3s where the A6 is also used. We work with many customers that do not have the ability to acquire and retain an army of engineers to design and manually implement an SoC. Yet these companies are able to deliver differentiated hardware from one generation to the next. They cannot achieve this by incrementally tweaking existing designs, or assembling an SoC from externally-sourced IP. So how do they do it? They use SystemC TLM-driven design and verification.

Take the case of Casio, who needed to re-architect their image processing algorithm while moving to the next process generation. They converted from an RTL-driven methodology to SystemC-driven, and this allowed them to explore the architectural solution space in days, which would not have been possible in several weeks with RTL. And by moving most functional verification to a higher-level, the overall verification/debug cycle was reduced by 50%. Similarly at Renesas Micro Systems, 2 designers completed a brand-new 17M gate design in 8 months using SystemC. We have many examples of very small teams producing new designs with SystemC and high-level synthesis that would have required very large teams and lots of time in an RTL-driven methodology.

But more importantly, in-sourcing hardware design enables engineers to more freely customize it to meet the needs of the end-product. Why else would Apple design a processor when there are established solutions available? There was a great article at EETimes on the need for an image processing IP core. The argument is that so many applications need image processing -- from smart phones to automobiles to a "smart pen" -- that a standard IP core could easily plug in and provide the functionality.

While this is true, each of these products has very different requirements in terms of size parameters, economics, power consumption requirements, and likely some differences in functional requirements. After all, a pen may only need to recognize movement in two dimensions, while a car needs three dimensions. A smart phone needs to recognize details like faces for photography and social networking, or neighborhoods for augmented reality. Notice that all of these functionalities also require unique interaction with software. SystemC is also well-suited for bridging the gap between hardware and software development. This is where innovation occurs -- across traditional compartmentalized tasks.

It still remains to be seen whether the 787's battery fire issues are also due to outsourcing. It would not be entirely surprising, since it could be that the battery was designed for a slightly different type of load or operating environment from how it was ultimately deployed. But it seems to be very frustrating for Boeing to debug it since they have to interface with another company while the clock is ticking. Then again, even Apple doesn't design their own batteries. That is, until they decide that by designing their own in the context of the system, they can produce a 4G smart phone that can get Jay-Z through an entire day without being power-less.

SystemC-driven design and verification allows companies to look at the make vs. buy decision in a new light, by greatly reducing the risk and turnaround time associated with the "make" decision. This enables the decision to made on business terms, where it should be.

-Jack Erickson

Why C-to-Silicon Compiler HLS has Supported IEEE 1666-2011 SystemC All Along

Jack Erickson — Thu, 14 Feb 2013 14:00:00 GMT

Recently one of our competitors issued a press release claiming to be the first high-level synthesis (HLS) vendor to support IEEE 1666^TM-2011 SystemC. Specifically mentioned was newly-added support for asynchronous resets in SC_THREADs. Congratulations to them on supporting this standard.

You are probably wondering "when will Cadence C-to-Silicon Compiler HLS support IEEE 1666-2011 SystemC?"

Most of our existing customers already know the answer - it already does.

The IEEE 1666-2011 spec has a publication date of 9 January 2012. At the time of its publication, C-to-Silicon Compiler already supported the synthesizable constructs in the spec. Specifically, the asynchronous reset in SC_THREADs construct was donated by Cadence to the spec after we added support for it in C-to-Silicon Compiler to meet the needs of multiple customers.

Cadence is committed to supporting and advancing industry standards in this area. Standard languages such as SystemC enable full design and verification solutions to be built by our customers using vendor solutions that best meet their quality of results, design analysis, and turnaround time needs. This is why our Incisive simulation products support the full IEEE 1666-2011 specification and why C-to-Silicon Compiler high-level synthesis supports the synthesizable constructs in the IEEE 1666-2011 spec. And it is why we actively participate in the standards working groups and donate the new constructs we develop in response to our customers' needs.

We do not consider this to be news to release to the press, we consider it to be table stakes to compete based on the merits of the design, verification, and implementation solution.

Hopefully this clears up any confusion. Now let's get back to designing and verifying cool new hardware with SystemC!

-Jack Erickson

Re: schedule crash

Jack Erickson — Thu, 20 Dec 2012 22:00:46 GMT

I tried to run your example in the latest version, but it is missing your "mydefs.h". Also I don't know what your constraints are, what the scheduling options are, etc.

In any case, the best bet is to try the latest version, and try the default scheduling options. We just released 12.2 last week. Whether it's an issue with your design or not, we consider any crash to be a bug. So if this issue still persists in 12.2, please file a bug report with customer support (http://support.cadence.com)

University of Aizu and Cadence Collaborate to Deliver a Course Featuring High-Level Synthesis

Jack Erickson — Mon, 17 Dec 2012 19:54:00 GMT

Today we issued a Japan-only press release announcing a high-level synthesis joint development program with the University of Aizu. This is Japan's first university-level course teaching high-level synthesis for semiconductor design. Here is the link to the full release, and if you can't read it then Google Translate should help:

http://www.cadence.co.jp/news/h24-12-17.html

This is an important milestone, because while Japan has been the leader in adoption of high-level synthesis for production hardware design, there has been no formalized training program. If you remember the panel discussion at this year's DAC, it was widely agreed upon that the biggest impediment to broader adoption of high-level synthesis is developing the skill set required to be successful.

In short, there have been many hurdles to widespread usage of HLS for chip design, but given the latest generation of tools and methodologies, the last remaining hurdle is the unique skill set required to be successful. Specifically, the input language for HLS if you're using it for production chip design and verification is SystemC, which is a hardware-specific class library for C++. Like RTL synthesis, generating hardware that meets your Quality of Results goals requires hardware micro-architecture expertise. However, most engineers with that expertise are rusty when it comes to C++.

For today's hardware designers and architects, learning C++ and SystemC is not easy. We have had customers do it, but to sufficiently ramp up in C++ requires a few months of effort, which is difficult given today's lean staffing levels and demanding schedules. There are a lot of great resources out there for learning the language and methodology. But for today's hardware designers the one resource that is often lacking is free time. Hopefully forward-looking companies will make that investment in order to attain the benefits that higher-abstraction design and verification delivers.

For the longer term, we are trying to help universities prepare their graduates for the way design and verification will be done (taking Wayne Gretzky's advice to go where the puck is going to be). Japan is not the first country to have a university program for this area. Both Dr. Luca Carloni at Columbia University and Dr. Luciano Lavagno at Politecnico di Torino in Italy have incorporated it into their courses. And we are working with some other universities to ramp up courses that utilize the TLM-Driven Design and Verification Methodology book in conjunction with our C-to-Silicon Compiler HLS software. It is thanks to Professor Saito's great efforts in the translation of the TLM Design and Verification Methodology book into Japanese that this is now more accessible to the Japanese community.

So if you are an engineering manager looking to hire engineers to lead your methodology transition to the next level of abstraction, then these programs are the best place to start. And if you are from a university looking to incorporate this material into your curriculum, then we look forward to working with you!

-Jack Erickson

C-to-Silicon 12.2 Available for Your Holiday Shopping List

Jack Erickson — Thu, 13 Dec 2012 18:52:00 GMT

The winter holiday season is that special time of year when we get bombarded with catalogs, emails, television commercials, banner ads, store displays, and any other method to get our attention on something that somebody is trying to sell. Having been trained as an engineer, I'm able to filter a lot of it out because it has no benefit to me or does not solve a problem I have. Do I really need a $3000 zero-gravity massage chair? Maybe somebody does (actually, this is on my son's wish list, apparently he has stress as well as a problem with gravity). But all I see are a bunch of features that I'm not sure I really need -- my favorite being the color LCD display on the remote that shows the massage's progress. I guess the lesser models just show a spinning hourglass?

I do have a soft spot for those famous "As Seen on TV" product commercials, because they go to great lengths to create a problem that the product solves. Here is a highlight reel of these contrived problems.

Unfortunately, our industry faces real challenges. In the past year we have seen large semiconductor vendors re-focus from the highly-competitive mobile processor market to focus on longer-lifecycle products such as embedded devices for automotive, industrial, and "smart" home devices. We have seen systems companies in-sourcing chip design in order to create more differentiation in their products, even if they didn't already have in-house chip design expertise.

We have been working closely with some of these companies as they transform themselves. High-level synthesis is a key technology for speeding turnaround of short-lifecycle products -- it speeds design and verification for new IP, and makes re-targeting that IP for different applications and processes much easier. It can also help long-lifecycle products save on area (and part cost) by exploring a broader micro-architecture solution space. And HLS helps systems companies create differentiation - instead of having to hire an army of engineers to build and verify low-level RTL, they can focus on developing and verifying concepts and algorithms at the system level and automatically take them into RTL implementation and below.

And just in time for the holiday season, the latest version of C-to-Silicon Compiler is now available. The 12.2 release delivers:

Higher quality of results: C-to-Silicon already meets or beats the QoR of handwritten RTL because it has embedded RTL Compiler production synthesis to guide its high-level optimizations. The 12.2 release adds more precision for higher-frequency designs, along with some additional area optimizations. One beta customer saw a 7% area reduction with the new release (and they use that other RTL synthesis tool) and one very high-speed design saw an area reduction of 14% with better timing.

Ease-of-QoR: Ease-of-use can mean a lot of things ("easy storage!" "one size fits all!" "dishwasher-safe!" "push button!"), but it is meaningless if you can't achieve the QoR that you need to. So our efforts have focused on two areas -- automating the synthesis process as much as possible, and providing quick and useful feedback to help hardware designers make micro-architecture and implementation decisions.

A good example is the new synthesis mode capability in 12.2. It lets you specify based on the code in the SystemC process whether it's already cycle-accurate and should not have added states, whether you want to allow C-to-Silicon to freely add latency cycles so it can meet cycle time and reduce area, and whether to automatically break combinational loops. And the new multi-phase scheduler provides feasibility feedback much earlier in the run so you can focus on the basic issues before getting into more complicated situations and make adjustments much sooner.

Flex Channel enhancements: Flex Channels are direct point-to-point interface IP provided with C-to-Silicon. They contain transaction-level models (TLM) for channels and initiators to easily connect modules or blocks. Because they are at a high-level of abstraction, they simulate very fast and are easy to understand. But they have also been designed and tested to generate good quality of results.

New improvements in 12.2 enabled these models to utilize 100% standard SystemC constructs to describe all levels of abstraction with a single model, with no special wrappers or macros necessary. This means they not only get great QoR through C-to-Silicon, but they can be run in any other tool in your flow that supports SystemC. These C-to-Silicon Flex Channels provide the building blocks to quickly create libraries of complex bus protocols. Customers have been utilizing AXI bus libraries during the past year and getting excellent QoR. Stay tuned for more details in that space...

Coarse-grained clock gating: Because high-level synthesis has a broad view of the control and data flow of a design, it enables higher-level optimizations. For instance C-to-Silicon has the ability to identify more opportunities for leaf-level clock gating than an RTL synthesis tool could, and it generates RTL that is structured so that the RTL synthesis tools can more easily insert clock gating logic (the actual logic still must be inserted in RTL synthesis because it is typically dependent on cell-level timing, area, power, and placement).

Coarse-grained clock gating is the ability to shut off the entire clock network for a given block, so it can yield big power savings. In the 12.2 release, C-to-Silicon can insert coarse-grained clock gating logic based on your input as to what block of logic should be shut off, what the enable condition is, and how you want to implement the gating logic -- for instance C-to-Silicon can instantiate a clock gating-integrated cell (CGIC) from your technology library. Inserting the gating logic at this level is important for micro-architecture exploration and verification purposes.

These are the major themes of the C-to-Silicon 12.2 release, which is available now (hopefully the zero gravity feature will be in the next release!). As always, there are more details on features available in the "What's New" section of the Release Notes in the C-to-Silicon manual. Happy Holidays!

Jack Erickson

Speed Verification Turnaround by Extending Metric-Driven Verification (MDV) to TLM

Jack Erickson — Wed, 28 Nov 2012 16:02:00 GMT

One of the main benefits of moving the design entry point up in abstraction from RTL to SystemC/TLM is faster verification turnaround. Higher abstraction contains much fewer details, so simulation at that level runs faster and debug is much more productive.

But in order to reduce overall verification turnaround, the work done at this level needs to be leveraged to greatly reduce the amount of work done at subsequent levels. Otherwise it just becomes an extra step. This means that verification at higher levels of abstraction needs to be an extension of your existing metric-driven verification methodology plan so that you can verify functionality at the abstraction level where it is introduced. Then instead of re-verifying at lower abstraction levels, you can just regress it while focusing verification on functionality that is newly introduced when the lower levels of abstraction allow for more detail.

Yoshi Watanabe, a Sr. Architect at Cadence who has been working with key partner customers to extend their existing environments up to SystemC/TLM, recently explained his approach in a webinar which is available for replay. It is titled "Speed Verification Turnaround by Extending MDV to TLM." You can access it here:

http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=728

If you're looking to speed verification turnaround (and who isn't?), this is a must-see.

-Jack Erickson

CDNLive paper: High-level Synthesis on Video Processing ASIC

Jack Erickson — Wed, 14 Nov 2012 15:35:00 GMT

The proceedings from the recent CDNLive! event in Israel recently became available, and you can access them with your Cadence.com account login.

The paper entitled "High-level Synthesis on Video Processing ASIC" delivered by Yaniv Fais and Michael Zarubinsky of Freescale gives a great look into their group's adoption of C-to-Silicon Compiler high-level synthesis and their application of it on a video accelerator.

For anyone considering a move from RTL-based design up to SystemC-based, it is a must-read. First it highlights the benefits of moving up in abstraction through a simple example, showing how you can quickly explore different micro-architecture implementations for a simple code snippet. Then it goes on to show a code sample from their project and how they explored their options using the C-to-Silicon GUI, for example:

Highlighting the critical path in the control-dataflow graph (CDFG)
Using the critical path viewer to see the actual instance-level timing from embedded RTL Compiler
Viewing the overall performance of the algorithm via simulation vectors with SimVision
Exploring the area tree map to look for opportunities to recover area where there is plenty of timing slack

The paper finishes with a nice summary of the benefits as well as a balanced look at the challenges they faced in evolving their methodology to a higher level of abstraction. Suffice to say, their experiences align with other customers we have heard from at our most recent C-to-Silicon user group in Japan and the recent DAC panel on high-level synthesis.

For the details, check out the paper!

And to hear these types of papers presented in the future and to be able to speak directly to customers that have been through these experiences, register for a local CDNLive! conference:

http://www.cadence.com/cdnlive/pages/default.aspx

-Jack Erickson