Home > Community > Blogs > Logic Design > logic handoff models at 45nm and beyond
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Logic Design 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: *

Logic Handoff Models at 45nm and Beyond

Comments(3)Filed under: Logic synthesis, Constraint design & validation, Logic Design, Physical timing closure, CDNLiveCDNLive! Silicon Valley has been a good conference so far, lots of good papers and conversations.  One thing I wanted to share was a panel discussion yesterday entitled "Logic Handoff Models at 45nm and Beyond." It was a great discussion, moderated by Ron Wilson of EDN, and on the panel were Herve Menager from NXP, Rajiv Sharma of Cisco, Fred Jen of Qualcomm, and Sandeep Mirchandani of Broadcom.

There were a lot of interesting points made, but I think Herve summed it up best when he said that it’s going to be less of a “handoff” and more of a “handshake”.  In other words, there needs to be more and more overlap and contact between logical and physical designers.

Rajiv talked about how large the timing and area uncertainty can be for them and how it will only increase at 45nm, hence the need for more physical design tasks needing to be performed by logic designers.


Fred, who has had roles on both sides of the fence, stressed that without logical-physical collaboration, you end up with a lot of over-design, or building in excessive margins to account for that uncertainty.

Sandeep agreed, saying that handoff points are useful as milestones in the project’s life cycle, but clean handoff is getting tougher – there are just too many questions in handing over only a netlist and SDC.

Some amount of placement needs to be involved - even if it’s only garbage (his word!) it’s okay because it acts as a communication vehicle between the groups.
 
As far as panel discussions go, there was a tremendous amount of unity in calling for increased communication and collaboration between logical and physical designers.

All agreed that it helps to have someone in the front-end with back-end knowledge, and vice-versa, to facilitate this “handshake” process.  The data that would get passed back-and-forth would include netlists, constraints, physical partitioning, floorplan, clock and data-flow diagrams, and possibly even placement.
  I have to say that given all the inter-dependencies between the two worlds, this approach makes sense.  Perhaps what we are lacking at this point is the cross-training along with a template methodology to enable it. 

What are your thoughts?
 

Comments(3)

By TheLowRoad on September 12, 2008
Where's the RTL hand-off?!  It seems like only yesterday....   I saw this panel too.  It was really a good one, packed with a dense amount of information on experience from some really smart engineers.  I hope that this one was recorded, because I would like to hear it again.

By Rich Owen on September 16, 2008
When I think back on my tapeouts (I’m a 16 veteran of the chip wars), the ones that went best were the ones where the front and back end teams felt as if they were all part of the same battle.  Conversely, when it was “us versus them”, getting the chip out really did feel like a war.
So maybe nothing is really different – to be successful, we’ve always really had to work together.  Perhaps what is really new is that the old methods of working around uncooperative teams don’t work any more.  In the old days, if my back end guys complained about bad timing, I’d just squeeze the clock or re-write the RTL.  If the die was too big, we could squeeze the scripts.  If we needed to change something at the last minute, I’d just go and beg.
With the tight schedules, tight targets, and tight teams, this doesn’t work any more.  If there’s an issue in P&R, the front end teams need to know about it as soon as possible – preferably without wasting a bunch of backend resources.  And all the teams need to operate with real system constraints – power, timing, area, yield, etc.  In today’s environment, over constraining costs too much time and money.

By Kenneth Chang on September 18, 2008
I agree, having people in the front-end with back-end knowledge is valuable and pays dividends.  In my previous company, we set-up a flow (based on my boss' broad experience from RTL to layout, and pain points) of doing quick prototyping with an array of tools.  Once I got my hands on the RTL, I would take it through the whole flow, including floorplanning, P&R with detail routing and timing analysis.  By doing this, it helped improve the transparency between logic/physical worlds (front-end/back-end wall).  Now, not every firm can do this, since they can't have every engineer running all the tools (and not everyone has the tools), but this is one example of where transparency between the front and backend can help with accelerated design closure and predictabiity.  Maybe something like this can be incorporated in the ASIC flow as an option (maybe people are already doing this in some sense, I don't know many who do though in general).  Throwing the design "over the wall" from the front-end people has never worked well in my experience for aggressive designs that push technology limits if it doesn't have some physical due diligence included.

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.