Home > Community > Blogs > System Design and Verification > panel discussion applying high level synthesis in an soc flow
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Panel Discussion: Applying High-Level Synthesis in an SoC Flow

Comments(0)Filed under: ESL, SystemC, EETimes, synthesis, high level synthesis, hls, System Design and Verification, SoC, IP, C++, Bluespec, Tensilica, system on chip, BDTI

Last Thursday, EETimes hosted a virtual System on Chip event focused on IP integration in SoCs. Even with IP re-use comprising a large percentage of new SoCs, new IP must also be developed in order to differentiate on the hardware side. With RTL containing so much application-specific implementation detail, more companies are looking to move to high-level synthesis based on SystemC, which allows for separation of pure functionality from implementation details.

Five panelists took part in a discussion led by Clive "Max" Maxfield, president of Maxfield High-Tech Consulting, focusing on the topic of  "Applying High-Level Synthesis in an SoC Flow." The panelists were:

  • Jeff Bier, Founder and President, BDTI
  • Philippe Coussy, Associate professor, Lab-STICC, Université de Bretagne-Sud, France
  • George Harper, Vice President of Marketing, Bluespec, Inc.
  • Michael (Mac) McNamara, Vice President & General Manager, System Level Design, Cadence
  • Chris Rowen, Ph.D., Founder and Chief Technology Officer, Tensilica, Inc.

The discussion centered around 6 key questions. Here is a sampling of the discussion, which opened with some interesting comments:

Chris: You could build a chip entirely of off-the-shelf IP but differentiation would have to come only via software, which isn’t enough if say you’re pushing the power envelope. 80% of the design is re-use, but that other 20% is exploding in complexity.

 

Mac: HLS is not about improving design efficiency, it’s about improving verification efficiency

 

George: I agree with Mac about verification efficiency. There’s lots of IP that is developed that’s not shipped in silicon. HLS helps facilitate getting more of this into emulation and prototyping to speed up verification

 

Mac: Yes, in fact Hitachi did a paper last year where they synthesized the testbench and RTL onto a Palladium box and achieved a 10,000x speedup.

 

Can HLS tools now synthesize both control and datapath?

 

Mac: Before we got into the market, we asked customers why they hadn’t adopted HLS yet. One of the big issues was that HLS only supported datapath, meaning you still had to hand-code and verify RTL for control. This was one of the first things we worked on when we developed C-to-Silicon. We like to say “we’re not the first ones to do HLS, but we’re the first ones to do it right.”

 

George: I think all HLS tools can synthesize control, it’s just a question of how high-level the abstraction of it is. SystemC is too low-level, which is why we came up with the system-centric Bluespec language.

 

Chris: The higher the level of control, the more unstable the specification is going to be. Because so many of the interactions are impossible to anticipate, they are impossible to verify. These are things you’d rather have be programmable rather than baked into the silicon.

 

High speed models cannot be synthesized, so how do we bridge the modeling and implementation worlds?

 

Mac: HLS is getting more sophisticated, but they still can’t take a pure algorithm into something that knows how to move around the data. This is why hardware architects still need to get involved to refine the model to something that will meet the performance, power, and area goals.  From there the HLS tool can schedule the clock edges and allocate the resources. The bridging will still require humans, we just want to remove the low-level leg work.

 

Phillipe:  Perhaps it’s necessary to define a new language that can both describe high-speed models as well as being synthesizable

 

Mac: In 1985 we created new languages -- VHDL and Verilog -- because the silicon compilers couldn’t support C/C++. Now the technology has moved on and the tools can support it. We now can support the language that all these existing models and algorithms out there are already described in. Isn’t it better to use the language they’re familiar with and just extend it with some specific nouns and verbs to help describe hardware? I am on the IEEE SystemC synthesizable subset committee, and we have a draft of the subset out. Right now it’s a lowest common denominator of what all the vendors support.

 

Jeff: We took our pure C algorithm and used AutoPilot to generate RTL. It wasn’t high QoR RTL because we synthesized it as-is without targeting it for hardware, but it proves that more than just a subset of C is supported.

 

George: C is certainly very popular and prevalent, and we know how to augment it with RTL-like concurrency via SystemC, but it doesn’t deliver a high-enough level. Bluespec is such a language.

 

The C++ language is being extended to handle concurrency. Will this make SystemC unnecessary?

 

Phillipe: Concurrency is the main weakness of C++, but the concurrency model in SystemC may not be at a sufficiently high level.

 

George: Concurrency extensions existed well before SystemC. SystemC adds datatypes and clocked hardware.

 

Mac: The concurrency extensions will be useful for multi-threaded applications, and I suspect that SystemC will take advantage of these in the future, but these were not put in specifically for hardware.

 

Challenges of parallel programming – what are the differences in programming for hardware?

 

Chris: In the theoretical world they’re connected, but in the real world they’re different. The typical software engineer learns sequential programming from the start and then has to learn parallel techniques. The typical hardware designer emerges from the womb thinking in parallel terms. The key question is what do you do when you consider the whole body of software that describes a system? How do you describe the interface between the mostly sequential software piece that runs on processors, and the mostly parallel part that runs primarily in the hardware world?

 

Jeff: Programming processors has gotten more complex in the last few years because of multi-core. While in some cases designing hardware has gotten easier due to HLS.

 

Will HLS enable software engineers to develop hardware?

 

Chris: I think that you’ll see some blurring of the lines. We’ve seen that in the evolution of who uses our processor generators. There are a class of customers that have the software architects configure the processors. But a hardware engineer understands that if you do a multiply operation 64 times, you might get 64 multipliers in the hardware. Whereas the software engineer wouldn’t worry about that. So the software engineers have the algorithm knowledge and can contribute to the innovation and differentiation of the platform, but we need to sensitize the software community to the fact that hardware has a cost.

 

Jeff: We feel that a “hardware-aware software engineer” can use a high-level synthesis tool. They’re software engineers but understand pipelining and concurrency, so they know that if they inadvertently overconstrain a design they can recognize it and make adjustments. We’ve seen these folks generate RTL, but then integration of that RTL is a whole different story.

 

Why is it taking HLS so long to see mainstream adoption? Is HLS ready for prime time?

 

Phillipe: One solution will come from education. It’s a new way of thinking.

 

Mac: Software is getting harder, and hardware is getting softer – you can code this and re-target it. But I go back to the “80% of IP is re-use” – where did that come from? At some point we’ll want that part to be more easily re-targeted and HLS will enable that. In the past, the control logic problem, and the lack of an ECO flow, prevented folks from using HLS. Customers are using this in production in Japan, USA, and Europe, but this is maturing. We’re in the inflection point now.

 

Conclusion

 

It is pretty clear that we are at an inflection point now, with more and more teams moving to a high-level design, verification, and synthesis model. In the future we will still need hardware expertise in developing this IP, but hardware and software teams will work more closely together. And a language like SystemC offers a common ground for this coming together.

 

Jack Erickson

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.