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.

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: Why is high-level synthesis, which has been around for awhile, suddenly so necessary?
Kaul: In the typical chip there are multiple physical partitions. It can take a typical design team 15 hours to get through the logic synthesis portion and a week to two weeks to get through physical implementation—per block. And it can take multiple iterations through that loop. Some design teams go through that loop seven to 10 times. They’re looking for ways to get timing closure much faster, and the only way to do that is to bring physical information up earlier in the process.
Cline: That’s not the only way. High-level synthesis guys can make much better tradeoffs into the RTL schedule before it even hits a logic synthesis tool, which can eliminate a huge class of timing problems.
Kaul: You’re still dealing with RTL after that.
Cline: I agree, but we own the schedule. So if the schedule gets filled up and you go through synthesis place and route and don’t meet the timing, you can go back through the high-level synthesis tool and change the schedule. You just can’t do that in RTL. We can make the flow smoother by allowing people to not make stupid decisions in the creation of that RTL.
Eddington: That’s one of the big advantages of high-level synthesis. You iterate quickly at the architectural level and you minimize the iterations that you have to do for back-end place and route.
Cline: You should never miss timing with high-level synthesis.
Kaul: It’s not so much a question of missing timing closure. It’s how long it takes you to get there.
McCloud: High-level synthesis allows you to get to timing closure more quickly. Let’s say you’ve hand-coded an architecture that completely misses timing. The time it takes to re-code , especially if it’s a significant architectural change, could be weeks to months depending on the complexity of the design. With high-level synthesis it’s easy to adjust the percentage that you’re reserving for placement and reschedule the design. And what happens when you have a spec change late in the design? That’s a nightmare to deal with in hand-coding, but it can be dealt with relatively quickly with high-level synthesis.
Cline: In addition, the tools that are coming out at the RTL level are doing smarter things with these designs. It does make it easier for us in the long run. The things that people are happiest with using high-level synthesis, which you would never expect, are the verification improvement and the predictable timing closure. You’d expect them to say productivity.

SLD: Is there a cost for that timing closure?
Biddle: And do you see more flip-flops?
Cline: You certainly can. We have a timing address knob. You can overfill the time schedule or you can underfill it. On average, we beat a hand-coded design between 10% and 20% in terms of area and still meet timing. Generally people would worry we are larger. We’re just a compiler. We can shrink down without a penalty.
McCloud: It’s a question of how much time you want to spend on a design. We’re typically within 10%. Sometimes we’re a lot smaller. Sometimes we’re bigger. If someone wanted to spend enough time they might be able to do a better job.
Kaul: It’s not an ‘either-or’ issue. It’s an ‘and’ issue. High-level synthesis can do certain things. If you want to add a pipeline to your design or you want to change your architecture, high-level synthesis is very well suited. If you want to go from RTL to GDSII in a 28nm design, then you have to have technologies that understand what’s going on downstream.
Cline: I agree. The better the logic synthesis tools get, the better the overall results.

SLD: How accurate does synthesis have to be?
Cline: It’s different for different abstractions.
Eddington: For architectural decisions you’re leveraging the capabilities of the logic synthesis tools. The decisions you’re making aren’t exactly where you’re going to put a register but roughly how many you need and roughly where they need to go. You let the logic tool do the fine-tuning.
Kaul: It’s very design-dependent. Some designs are pushing the performance. Logic synthesis has to get you very close to where you’re going to be at the end of place and route. Otherwise you can have a lot of iterations. If your design is not pushing performance, then I think you have a lot more give.
Eddington: Logic synthesis has to be pretty accurate. You need to make better decisions at the logic level. Integration with placement is still an ongoing area of innovation and improvement. The high-level synthesis, in terms of logic accuracy in the architecture and placement of registers and so forth, doesn’t have to be quite as accurate as the RTL logic synthesis.
Cline: Our customers get a number for a baseline, run that through logic synthesis and then correlate the two. You want them to be as close as possible. After that, one of the nice things about a high-level synthesis flow is the turn is really quick—literally minutes. We don’t hear people running things for four days. If it’s running for four hours, we wonder what’s going on. That’s a curse from a licensing standpoint because you don’t run this stuff for that long. But at the end of the day, they’ll run a number 100 times and then track a number. If that number correlates with what logic synthesis would have looked like, had they run it every single time, then I think they’re generally pretty happy. It doesn’t have to be 100% correlation, but we’re not going to run logic synthesis every time because it’s fairly expensive.
McCloud: It needs to be able to give you relative comparisons. All of these tools eventually take a candidate design down through RTL synthesis to give you some accurate estimates. Once you have that, you’re comparing the candidate architecture to new ones you can create in a matter of minutes. If your candidate architecture has 150,000 gates and you have another one that has 200,000 gates, is that relative comparison correct? Our number is accurate enough to do exploration. Typically you’ve got a high-level design model that’s technology independent. You take that into an FPGA and prototype it. When you take it to ASIC, almost always you do multiple architectures. We estimate the timing and where potential timing issues will occur. The next step is to take those through RTL synthesis, and that’s when you’ll know for sure. Did it meet timing or not. The architectural exploration benefits are really the big win, along with the verification benefits—being able to do those transformations without having to change your high-level model verification.

SLD: What determines who wins in high-level synthesis?
Cline: The technology takes a bit of time to mature. It’s quite easy to synthesize a C algorithm into some RTL. That’s not a hard problem and it makes the barrier to entry look fairly low. But getting a C algorithm into RTL that’s actually manufacturable is actually quite a hard problem.
McCloud: It is centered around completeness of flow. But I would say the most important aspect is the tool that addresses the verification side of things. When you look at the RTL design flow today, 60% to 70% of the design cycle is consumed by verification. A high-level synthesis tool needs to address the verification side of that problem. The approach you take with high-level synthesis can actually complicate verification if you don’t do it right. One of the important things is to have a source description that is deterministic and predictable so you can re-use that work you’ve done in C down at the RTL level. The tool that combines synthesis and verification is the right approach.
Eddington: Both of you guys stated the obvious. A high-level synthesis tool has to deliver productivity in design. It has to deliver productivity in verification. That means reliable verification from high-level models. But right now we’re all limited by these application-specific domains. The question is how we expand beyond those.

SLD: What are the limitations?
Eddington: Mostly it’s the algorithmic guys who are adopting this.
McCloud: I think that was the case three or four years ago. That’s not the case anymore.
Cline: I would agree.
Eddington: Achieving higher levels of abstraction and having design entry environments that are tailored to the different application spaces is what’s going to help this expand a lot more. We’re doing something a little different. C is important, but we have the Matlab in the model-based stuff. That seems to work very well for designers in the system-level space who may not know RTL or C. Software engineers and video engineers know C. But other environments are needed to expand this beyond the application spaces now being addressed.
Cline: Do you worry that ability of the system designer who doesn’t understand RTL is diminished because of their lack of understanding about how the architecture is implemented?
Eddington: No. I don’t think there’s any reason you can’t have a fundamental description that’s understandable and capable of being captured by a guy who has no understanding of RTL.
Cline: We would disagree. We’ve had designs that involve a hardware engineer who knows nothing about C and someone who’s an expert software engineer who understands C to the nth degree. The hardware designer will kick their butt almost every time. The reason is that algorithms can be specified in ways that imply architectures that cannot be implemented in a reasonable amount of silicon. An H.264 implementation is a good one. You can read the data in, but data has a temporal aspect in hardware. In software it’s always there in a buffer and you just go get it. But in hardware it comes in 8 bits. What do you do with the first 8 bits?
Eddington: I agree that if you ask a software engineer to write something in a sequential language, he’s going to write something that cannot be converted into a hardware implementation without having to do some fundamental changes. In our case, we’re not doing pure language. We’re building on an approximately timed, higher-level, model-based data flow graph.
McCloud: High-level synthesis doesn’t remove the need to design. You don’t just download an MPEG-4 algorithm and push a button. It’s not a tool intended to turn software developers into hardware engineers. You still need to understand what you’re trying to create, and that’s best done by hardware designers. But what it does do is remove a lot of the details you don’t have to worry about.

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.

Synopsys’ Tom Borgstrom takes the mystery out of elevator pitches for semiconductor designs, creating the formula and the metrics that work every time. One question he didn’t address, though: Do elevator pitches need to be shorter in earthquake-prone areas like California because the buildings aren’t as high?

Andrew Piziali, an independent consultant, takes a look at the unintelligible jargon created by the chip architect and how the terminology is misconstrued further down the line by the verification engineer. He’s right about the miscommunication, but we’re still confused about what a conflabulator is. Our body of experts concluded it’s some type of gym equipment.

Mentor’s Thomas Bollaert used his blog this week as a forum for a Q&A with an end user from TI. This is good information about designing IP for a set-top box with Catapult C. Looks to us like a battle is brewing with all the big guys over high-level synthesis and the ease of converting floating point to fixed point.

Bhanu Kapoor goes hunting for TLM 2.0 and System Verilog verification methodologies and comes up with a mouthful of fresh meat. For anyone looking for real details and insight about this topic, you’ve come to the right place.

Si2’s Sumit Dasgupta takes a reality check on 3D design—and comes up with a list of what’s missing to actually turn this from the idea stage into products.

In the area of low-power design, a panel of experts talks about the need to broaden the low-power discussion. The dialog was intelligently analyzed and recorded by Richard Goering, as you might expect from his long history in this industry.

Also in the low-power area, Jack Erickson looks at how to save power without just shutting down all the blocks. Sometimes you can’t just turn everything off.

Mentor’s Colin Walls talks about why companies should stick to their knitting—or at least their core competencies. That helps explain why Ford didn’t make its own paint. And why should hardware designers write operating systems, protocol stacks and graphics? Good question.

And finally, Synopsys’ Navraj Nandra talks about implementing PCI Express in MicroTCA, the telecommunications chassis standard. It’s about time some of these standardized interconnects made their way into the telecom world.