Open side-bar Menu
 What's PR got to do with it?

Posts Tagged ‘DesignCon’

DesignCon 2011: What was Different?

Friday, February 18th, 2011

turboSo what was different about DesignCon this year? Traffic and make up. There’s a new owner…EE Times.

What else?

1. There were actually people roaming the isles of the exhibit floor! So different from the last several years. It’ll be good to see the DesignCon numbers when EE Times, the new owner of DesignCon, releases them.

2. When I first walked onto the exhibit floor, I was perplexed. Not purely a show for chip designers?  Sure, EDA vendors were there, a couple of IP vendors. But test companies,
connector companies, material companies also!

I asked a couple of people. They acknowledged that the exhibitor make up was different. A couple of the people I polled said that DesignCon had morphed into a systems design or a PCB show. One person thought it had the makings of a complex FGPA design show.

What do y’all out there think?

­ – end ­–

Chip Killers: keeping design managers awake

Monday, February 7th, 2011

Am I gonna make tapeout in time?Liz and I attended a panel at DesignCon that asked the question: what are you doing about the chip killers that delay your tapeout? That’s an intriguing, possibly unanswerable thought, since we’ve asked that question virtually since EDA’s inception. Ed Sperling of Systems-Level Design moderated the panel which had on it: Sunil Malkani of Broadcom, Ravi Damaraju of Juniper, Ramon Macias of NetLogic, John Busco of NVIDIA and Bernard Murphy of Atrenta.

Sperling moderated a lively discussion; questions that he or the panelists or audience posed highlighted the ongoing nature, or unanswerability of the topic. Some were:

• As designers and design managers, what keeps you up at night?

• If your design has to finish in half the time that your previous project took, do you start with a [design methodology and flow] clean slate?

• How do you get hardware and software engineers to work together?

• What’s good enough to get the design out the door?

• How do you define failure?

• What’s the price of failure?

• Who owns quality?

• What do you do when your next project is 4X the size of your last design? Throw people at it? Make the tools do more? Run faster? How?

• How do I turn around a design in a month and get all of these [now-required] apps on it?

• Why does place & route have to be flat?

• When will P&R, timing analysis have to break down the design hierarchically?

• How can verification be improved so that its pessimistic estimates won’t require designers to over-design?

The panelists all bemoaned the dueling standards that plague EDA, attributing them to companies wanting to gain marketing advantage, to the detriment of EDA users.

Sperling will publish a transcript of this panel in a future issue of System-Level Design. Nic Mokhoff published a summary of the panel the next day.

Finally, I have a question: why does DesignCon schedule a management-level panel on a day when the exhibit floor isn’t open? Doesn’t help DesignCon panels’ attendance, which has been paltry for years, seems to me.

– end –

Can timing constraints disasters be averted?

Friday, January 14th, 2011

ron-craig_for-edblog

Ron Craig, Senior Marketing Manager at Atrenta and an expert on the subject of timing constraints, was good enough to sit down with me (Liz Massingill) recently to talk about the subject—what the current problems are and how to fix them. This is the result of my interview with Ron.

Liz: Ron, I was shocked to see, in the survey you conducted, that 94% of designers have timing constraint problems that could stop their current designs dead in their tracks.  But they also don’t see a way to change their current methodology.  WHY?!?!?!?!

Ron: There’s certainly no doubt that timing constraints remain and will continue to be a problem for design teams. The irony is that even though timing constraints are repeatedly an issue, most of these design teams feel that they know how to address all the problems that typically arise. It’s almost that the problems are viewed as less severe if the solutions are known.

Liz: Seems like the problem is more about changing the mindset. But why are designers running into increasing clock domain issues in the first place? Use of more IP?   Process nodes going down to the next level?   More complex designs?

Ron: The key culprit here seems to be IP. With IP, the functionality is reusable but the timing constraints are often not. Third party IP developers may well be experts in what the IP is supposed to do but not necessarily its implementation, leaving design teams with incomplete and inadequate timing constraints. On the other hand, IP reused from another design may well have been constrained in a way that’s not compatible with how you want to use it in your chip – especially if you need to change how the IP behaves. In today’s designs where IP amounts to 70% or more of a typical SoC, you end up with the constraint-driven implementation process becoming increasingly risky.

The process shrinks and more complex designs mean you simply can’t get away with having inadequate timing constraints anymore.

Liz: Well, what can they, ­or more appropriately, their project managers or internal CAD departments do about this increasing problem?

Ron: The key is to introduce more certainty into the whole process. Rather than taking an optimistic, or reactive approach to timing constraints, it makes a great deal of sense to put some effort in up-front to make sure that they are good. Many of our customers have noted that they simply can’t deal with the number of iterations it takes to refine timing constraints during the implementation phase of their projects, so they’re working on finalizing them up front as part of their RTL handoff. The trick for project managers or CAD people will be to introduce a methodology that their front end teams (who aren’t necessarily timing constraint experts) can easily adopt, and this is where comprehensive automated solutions such as SpyGlass-Constraints come into play.

Liz: So why isn’t this happening? Seems to me that an ounce of prevention is worth a pound of cure, as they say.

Ron: Let’s look at the two camps. First of all you have the RTL or front end team, who historically don’t want to take ownership of any part of the implementation process (even they know the design well enough to define its constraints). On the other side of that handoff ‘wall’ you have the back end team who feel that their expertise in this area, coupled with whatever the implementation and timing tools complain about, is enough of a solution. So depending on which side of that wall you sit on, you may feel that it’s either not your problem….or not a problem at all.

Liz: But we know there IS a problem, and it’ll only increase. So where in the design flow should project managers look first for a fix?

Ron: There is often a perception that timing constraints can’t be fully defined until you are actually using them – until you are in the thick of implementation or timing analysis. The problem with this is that your constraints end up being written so that you can close timing, instead of being defined to set the ground rules for timing closure. A classic example of this is the definition of timing exceptions – they’re often defined to mask timing violations, but in most cases they’re not exhaustively verified. A timing exception is a design characteristic, so can be defined and proven up-front before the implementation process even starts. It’s like an architect finalizing the plans after the building is complete. If your objectives aren’t clear how do you know when you are done?

Liz: I see what you are saying—it’s like putting the cart before the horse. Stop me, Ron, if I use another one of these old sayings. I’m dating myself. So who’s out there with technology that can help change the methodology and fix the timing disaster that’s looming?

Ron: It’s been possible to do some rudimentary timing constraint analysis in a range of implementation and STA tools since the advent of timing driven optimization. The problem with this approach, however, is that it’s largely a reactive one, and as a result doesn’t help reduce the risks in your implementation process. More recently, vendors (often ones outside the implementation/STA space) have started to provide solutions that allow the user to check the correctness of their constraints before implementation. What we’ve done with SpyGlass-Constraints is to take it one step further and look how timing constraint analysis is part of the bigger picture of reducing implementation risk. A great example of this is how we use our constraint verification methodology to ensure that data such as clock setup is in good shape before you use it to drive clock domain crossing (CDC) analysis. Again, it’s all about finding the issues up front and reducing risk later.

Liz: Well it’s intriguing…a Titanic-like iceberg of a design problem out there and we’re forging ahead…like the Titanic?

Ron: (laughs) Indeed – though given that the Titanic was built in my home city I always feel the need to point out that this particular disaster came about as a result of pilot error! To take your analogy further, I guess that the ‘iceberg’ here is a failure to close timing. Better guidance will definitely help you avoid that one.

Liz: Who knew? (laughs) Well, where can we learn more about this problem and how to fix it? Oh…and your customer survey…can we get a look at that? Sounds like some compelling information in there.

Ron: Yes, the customer survey was VERY telling and gives us a good leg up on what designers need to close at RTL for the next several generations of designs. In its current form, because we talked to customers, we can’t release it.

However,  Bernard Murphy WILL refer to it at length in his DesignCon panel.

Liz: What panel is that?

Ron: At DesignCon we will be holding a panel on: “The Same Chip Killers keep Delaying your Schedules – What are you doing about it?” moderated by Ed Sperling, editor of System-Level Design. The panelists will discuss a broad range of issues, including timing constraints, the impact of IP etc. that repeatedly cause schedule slips. It will take place on Monday, January 31 at 4:45 p.m.

Liz: Sounds like a crucial discussion.   I’ll be sure to attend!

CST Webinar Series



Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy