Get email delivery of the Cadence blog featured here
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.
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.
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.