Algorithms and architectures used in today’s new designs are so complex that traditional design practices are becoming inadequate. This paper gives an overview of the problems associated with the conventional design flow and how they can be addressed with a flow based on the simulation and synthesis of C (ANSI C, C++, or SystemC) representations. By automating an otherwise manual process, HLS eliminates the source of many design errors and accelerates a very long and iterative part of the development cycle.

To download this white paper, click here.

Algorithm design is one of the most significant factors in the increasing complexity of IC design and verification. Algorithm, signal processing, and system engineers have increasingly been using MATLAB and Simulink for very concise modeling and design of their algorithms. This paper introduces Synopsys’ Synphony High Level Synthesis (HLS) product which allows designers to take algorithm concepts developed at this high level and automatically and reliably implement them directly into silicon. To download this paper, click here.

By Ed Sperling
System-Level Design sat down to discuss the future of synthesis with Shawn McCloud, product line director for Catapult C Synthesis as Mentor Graphics; Chris Eddington, director of marketing for system-level products at Synopsys; Bret Cline, vice president of marketing and sales at Forte Design Systems; Sanjiv Kaul, executive chairman at Oasys; and Andy Biddle, director of business development at Magma. What follows are excerpts of that conversation.

SLD: Who’s going to be using these tools? Is it the hardware or software engineers?
Eddington: There are limitations to a C-based description. But if you take the guru for an OFDM timing circuit—very often those guys think in system-level designs. They read math books and they do blocks. They draw systems out and map out what it has to do at a very high level, and then they throw it over the wall to a hardware engineer who is going to describe it in a more hardware-oriented C-based or an RTL-based language. This might be an algorithm engineer, a system engineer or a product architect, depending on the organization of the company, but these guys are sitting together with the hardware team. Those front-end guys are already using some of these languages to think through their ideas. MatLab is a good example. It’s an array language with numerical functions you don’t have to write yourself.
McCloud: Most companies have algorithm engineers. But we see the best success when these two work together. The algorithm is being written to be more friendly for hardware engineers. If not, these algorithms can be used as a seed for the hardware designer to produce the design. I believe that ultimately the hardware designer will be the user of high-level synthesis. I think that’s going to take some time. Not all will convert, but some will convert.
Cline: I’m on a mission to squash the term, ‘RTL designer.’ They’re a hardware designer. You’re forced to use RTL because of the tools of the day. As we pull the whole flow together, if RTL is an intermediate format to any of the logic synthesis tools, no one really cares what that looks like. I also think that 80% of the RTL hardware designers will move up. You’ll get some smart verification, software, algorithm and systems, but I still think it’s a hardware design task. I do think there is a differentiation on the Matlab side. We don’t deal with that. But we certainly see it.
Kaul: The transition from gates to RTL happened when the chips got bigger than 50,000 gates. It happened pretty quickly, too. But high-level synthesis has been around awhile. Is there a triggering event that will make people move?
Cline: I think re-use has kept RTL around longer than it needed to be. One of the interesting things about the recession is that it has forced everyone to come to high-level synthesis. Who wakes up in the morning and says, ‘My chip has double the number of gates and I have half the staff I did last year. But I’m going to do exactly what I did last year.” Japanese companies have been building a flow with high-level synthesis since 2001.

SLD: What causes the shift?
Eddington: It’s complexity in both verification and design. The road maps I’ve seen from some of our largest customers show zero hardware designers, all systems engineers describing their designs at a high level.
Cline: That would be impressive.
Eddington: That’s their goal. I don’t know if they’re going to get there, but that depends on us, too.

SLD: As we get into more complex designs with multiple cores and multiple power islands, does synthesis work for that or is it still block by block?
Cline: It’s not block by block, but it’s not everything you’ve mentioned. There are really good tools that can handle implementation of RTL into designs and that can do smart things with power islands, how you’re going to implement clock gating and all the other things you’re going to use. Our strategy is to give hints about what we think should happen, but they still let the tool get everything right at the RTL level.
Kaul: There are very few tools that can look at the entire chip. There are floor planning and timing, and that’s it for a large chip. Even the physical implementation is broken up into partitions. But you have to look at the whole chip to do tradeoffs. Synthesis has to look at the entire chip, too.
Eddington: The high-level synthesis tools in the market today have affected the trend. There are fewer algorithms being implemented in DSP firmware and instead being implemented as hardware accelerators. That’s been an effect of the high-level synthesis tools, which makes it easier to develop those hardware accelerators. If you look at the partitioning between hardware and software and synthesizing from the spec, ‘Here’s the part that I want in hardware and here’s the part that I want in software,’ no one has done that yet.
McCloud: That’s the Holy Grail.
Eddington: Yes, and it’s a very challenging problem. High-level synthesis is a foundation to that.
Cline: When we talk about high-level synthesis, we just take for granted that we’re going to produce RTL and get a chip out. That’s a very hard problem. We actually think of RTL synthesis as the back end now.
Biddle: About 40% of our customers are spending most of their time on timing closure and routing today. They don’t really care which synthesis tool they’re using as long as it comes out about right. They know they’re going to have a problem down the line when it comes to polygons.

SLD: What happens when the industry moves to vertical stacking?
Eddington: If you’re using your downstream tools effectively, it’s just another technology that your flow plugs into.
Cline: This is the caution of not just stopping at RTL. You need to give the high-level synthesis tool the data that it needs to make good decisions. Ideally one of the big vendors would have an API that we could tap into and get everything we need to know before we synthesize. That doesn’t exist. You can get some feedback from the logic synthesis tools, but it certainly isn’t the be all and end all. As you go down to the smaller nodes you need more and more information. The question is how much you’re going to get.
Eddington: Did you say you’re feeding back IP-level estimation data up to high-level synthesis?
Cline: In our case we’re feeding back gate-level implementation decisions.
Eddington: We feed back IP-level information, as well.
Cline: What does IP-level mean?
Eddington: You’re estimating an operator like an FFR filter or an FFT, and that makes the whole flow more efficient. A gate-level implementation of an FFT would take forever, but you can do that quickly if you know the pieces and the general architectural decisions you want to make. You make the right calls to the logic synthesis tool and you can estimate that.
Cline: And you can even go more fundamental than that. How much will it cost to implement this multiplier and this technology library at this speed?
McCloud: It’s also about the quality of the library. High-level synthesis has a library just like RTL synthesis does. As you get into lower geometries and 3D, the library you’re creating has to be of higher quality. The more information you put into that library the faster your tool is going to execute and the more accurate it’s going to be. You also need a feedback path from the physical side. We’ve taken a path of partnering with the silicon vendors.

SLD: How does software fit into all of this?
Eddington: It’s a huge part of the verification problem. Everything you do in hardware ultimately is going to interoperate with some software. Once you plug those things together, does it work? The sooner you can do that verification in the design flow the better. High-level synthesis plays the role of getting the hardware done earlier so the software guys can start using it.
McCloud: This is where TLM virtual platforms play a big role. One of the biggest challenges our customers face is the unpredictability of their system. It’s not until they get everything done—their RTL, the software and the chip—and they’re ready for tapeout that they have a predictable system where they can see if it works. TLM allows you to verify the software with the hardware with which it’s going to be implemented.
Cline: But that’s independent of synthesis. Most people that use virtual platforms are doing that in a way where they’re not synthesizing afterward. We think they should be. But a lot of them are just rewriting that into RTL and then going into a traditional flow. Interestingly, they’re coming up with larger chips because they can do more in a high-level model than they used to.
McCloud: The problem is when they go to rewrite the models, that introduces a huge verification challenge. What they try to verify at the beginning of this virtual platform now has been rewritten. So how do you know if what you’ve rewritten is correct?

SLD: How many people are actually using TLM 2.0 for modeling?
McCloud: TLM 2.0 is a fairly new event. It’s a big step forward for the market. It’s an attempt to separate functionality from the interfaces and power and performance. Part of the challenge with building virtual prototypes is the modeling challenge. TLM has tried to make that easier. But everyone is doing some level of virtual prototyping, even if it’s just a spreadsheet.
Cline: I agree. I think people do TLM. They just don’t call it that. The synthesis side of TLM is not defined yet, but it will get there.
Eddington: It’s attempting to standardize all the different methodologies you need to be able to deal with writing C code that models systems. There are different levels of abstractions. TLM 2.0 delineates untimed vs. approximately timed, abstractions in communication and computation.

Experts At The Table: The Past, Present And Future Of Synthesis
High-level synthesis raises the abstraction level, but it doesn’t eliminate the need for synthesizing at the RTL level; still no all-in-one solution.

By Ed Sperling
System-Level Design sat down to discuss the future of synthesis with Shawn McCloud, product line director for Catapult C Synthesis as Mentor Graphics; Chris Eddington, director of marketing for system-level products at Synopsys; Bret Cline, vice president of marketing and sales at Forte Design Systems; Sanjiv Kaul, executive chairman at Oasys; and Andy Biddle, director of business development at Magma. What follows are excerpts of that conversation.

SLD: Is synthesis changing, and if so, why?
Cline: It’s definitely changing. The reality is there is a merging of various capabilities throughout the synthesis design flow to allow better transformations of data to happen in shorter order. It’s easy to say it’s because of productivity, market pressures and cost, but that drives EDA all the time. The key point is that with tools like the new logic synthesis tools, the new place and route and the new high-level synthesis you’re able to combine functions that typically were in three or four different tools into one or two, which allows you to make better tradeoffs and ultimately get better results.
Biddle: The focus on RTL to GDS is becoming more important because of the challenges of 65nm, 40nm and now 28nm designs. Traditional RTL synthesis has to become much more physically aware. Engineers can no longer throw netlists over the wall and expect to meet timing on schedule. We’re seeing the merging of technologies, as well. There’s a need to tighten up the links between the front end and the back end. We’re similarly seeing the need for greater productivity, particularly for algorithmic-type work.
McCloud: One of the most important things is that when these new synthesis tools come out they need to build on the existing RTL flows. One of the mistakes we see is when a tool tries to replace RTL synthesis. That’s reinventing the wheel, and there are already years of R&D behind RTL synthesis. It’s more important to have high-level synthesis built on top of existing RTL methodologies. Even today, gate-level design hasn’t gone away. That helps reduce risk. RTL is a necessary stopping point. It gives the security it’s working.

SLD: What will synthesis look like in the future?
McCloud: I think we’ll see more and more technology built inside and leveraged.
Cline: I agree that leveraging the technology people already have put into a design flow is important. That’s a strategy we’ve employed. When you go to a customer that’s had an ASIC signoff flow with Synopsys or Magma or anyone else and they are going through to gates you don’t disrupt that. But we also believe you can make better decisions inside the high-level synthesis tool if you know more about what logic synthesis is going to do with it. We don’t specifically go down to GDS II as part of our flow. But there are some tricks you can do if you have an embedded logic synthesis engine inside of your high-level synthesis tool to bring some of the higher-end pieces of the RTL synthesis up.
Kaul: You need a robust RTL platform to be able to take the RTL and go down. For large parts of the design, RTL synthesis is pretty stable, but for the very large designs, it’s becoming deficient. You have designs that are 50 million or 100 million gates. Most logic synthesis tools go from RTL to a mapped netlist, and then they optimize the gates and map it to a technology platform. Then you do physical synthesis after that. There can be 50 or 60 blocks that do not quite match your physical partition. So now you’re managing constraints, you’re dealing with very long runtimes, and you’re talking about closing the loop with physical implementation. When you move up to high-level synthesis, one of the things that would be useful is a capability that allows you to get quick feedback on whether your architecture is going to work or not. Is the QR going to be good enough? Is the implementation going to be good enough? Tools have improved a lot, but you need to know whether the chip architecture is going to be good enough. As the chips get larger, it’s harder to get a good answer.
Eddington: High-level synthesis has to utilize the key technologies in the RTL flow. It has to know what the RTL logic synthesis is going to do in order to make its decision. RTL logic synthesis is not going to go away. It’s part of the design flow and well established, and you’re crazy to try and change those. The high-level synthesis tool has to plug right into that. But it also has to have the right information to make its architectural decisions. That’s all about leveraging the downstream flows and making sure that information is brought back up.

SLD: How do you define synthesis vs. high-level synthesis?
Eddington: Synthesis is logic-level decisions and optimization. High-level synthesis is architectural-level optimization that takes a behavioral description and brings it down to a logic-level description.
Kaul: From RTL down is logic synthesis. Above that is high-level synthesis.
McCloud: To me the difference is in the source. A source to high-level synthesis is, by definition, untimed. It doesn’t contain any registers or clocks or I/O timing. In RTL it’s fully timed. It has a register with logic in between. That definition is part of the source. Another difference is the set of building blocks. High-level synthesis tools are working with adders, multipliers and muxes. RTL synthesis is dealing with gates. The process of inserting time is the process of scheduling.
Eddington: I disagree with one point. Some descriptions are approximately timed and have a notion of latency. They are very valuable ways of describing something at a high level that can be synthesized.
Cline: There are certainly people in the market claiming to have high-level synthesis and it’s debatable whether that’s really high-level synthesis.
Eddington: But even in the C environment where SystemC is defined as approximately timed and untimed. I consider the untimed is high-level synthesis, for sure. But approximately timed is also high-level synthesis because it isn’t describing all of the clocks and logic-level architectural details.
Cline: High-level synthesis is a bad term. Behavioral synthesis is better but it got a bad rap a couple years ago, so people are trying to stay away from that. And so if we’re high-level synthesis, what’ the next thing that comes out? Is it higher-level synthesis?

SLD: So how much of an SoC design is done with high-level synthesis these days?
Cline: It depends on the customer. The possibility is 100%, other than processor, bus and analog. One multifunction printer company does everything that isn’t analog, bus or processor in SystemC with our tool. A lot of it is re-use from the past. You can describe all that stuff in SystemC. Some of it may look pretty low level and it can be done with RTL synthesis. It’s not what we recommend, but let’s face it. Designs have all different levels of abstraction. You need a way to handle everything.

SLD: It sounds like the definition is far from clear-cut.
Cline: Some of us disagree with the definition. We output RTL. That’s our job, and our customers go off and use that RTL. In the real world, they have to go off and use some tool and they get gates out of it. What we’re finding is that when they use a tool that combines Talus or DC-Topo into place-and-route, as well, then they get some more advantages in optimizing. You have one pinch point in the middle, which is RTL, which is our common language. I don’t think the definitions matter. But there is a real sense in the market that a different task is taking place. It doesn’t matter what you call it.
Biddle: We have a handful of customers that are using SystemC. We’ve been partnering with Mentor on making sure the structures they’re putting out can be synthesized and that we can build a flow. Ultimately, one of the big bottlenecks we see is formal verification. Most people rely heavily on formal verification today. There are a lot of techniques and tools.
McCloud: There’s no single approach for verification. There’s classic functional-based simulation as well as prototyping and emulation. Calypto has a product out called SLEC that does do C-to-RTL verification.

SLD: What happens at the next level above this?
Cline: The RTL market has a well-defined flow and there are tools that plug into this flow. At the ESL level above that there’s a lot of interesting stuff—everything from virtual prototyping to formal verification. But that hasn’t jelled into a flow that everyone uses. Everyone picks their parts and puts them together.
McCloud: You are starting to see some parts of the flow solidify. We’re seeing that in the way that people verify designs. You develop a C description, you spend as much time as you can verifying that C description is correct, and what you’re generating is something that hopefully is predictable. You want to be able to re-use it, not re-do it at the RTL level.

SLD: How accurate are RTL synthesis and high-level synthesis?
Biddle: Everyone is always demanding greater predictability. There is constant pressure to correlate better. Once you have a netlist, what will area and timing really look like? That’s forcing us to add more physical modeling. But where we’re starting to have problems, particularly as we move to 40nm and 28nm, is how long it’s going to take to close timing. Once you come out of synthesis, are you done? We see designs where they’re throwing in gates just to meet timing, so chips are getting bigger than then need to be.
Kaul: For a large chip at advanced nodes, doing timing without understanding the placement is becoming less prevalent. You have to have placement information to have accurate timing. But for larger chips, understanding the floor plan is very important. Where the block goes in relation to the rest of the chip becomes very important. You have to look at global wiring, congestion and timing convergence. It’s important for the synthesis tool to look at all of that.
Eddington: There’s more innovation available in physical synthesis—integrating these placement and logic synthesis optimizations and doing them better. We’ve been adding physical synthesis in the FPGA space, but it’s still an area that needs further innovation.

Five experts sound off to System-Level Design on the state of synthesis and what’s needed in the future: Shawn McCloud, product line director for Catapult C Synthesis at Mentor Graphics; Chris Eddington, director of marketing for system-lvel products at Synopsys; Brett Cline, VP of marketing at Forte Design Systems; Andy Biddle, director of business development at Magma and Sanjiv Kaul, executive chairman at Oasys.

Instead of prolonging the painful process of finding bugs in RTL code, the design flow needs to be geared toward creating bug-free RTL designs. This can be realized today by automating the generation of RTL from exhaustively verified C++ models. If done correctly, high-level synthesis (HLS) can produce RTL that matches the high-level source specification and is free of the errors introduced by manual coding.

To download this paper, click here.