Cooley, Dini, Synplicity; and IC router benchmark tomfoolery?

EDA appears to be waking up from its long post-DAC summer nap, as John Cooley’s just posted one of his ESNUG posts with some very provocative entries.

Right before DAC, and I mean the Friday afternoon before DAC (the day I typically run around packing a suite case, getting a haircut, etc.), Synplicity announced it was buying FPGA based ASIC prototyping board company Hardi electronics. I didn’t see the announcement until the evening, too late to contact Synplicity, so I did a quick write up of the acquisition based on the press release. During DAC, their pr reps asked if I wanted to interview one of the execs at DAC regarding the acquisition. At that point, I had a full workload and coverage duties so I declined and told the pr folks that I’d be happy to sit down with the Synplicity folks after DAC (which I’m doing next week), when typically the EDA industry slows down (announcement wise). When I heard the M&A announcement, the first thing that popped into my mind was: “I wonder how Mike Dini feels about this acquisition?” Mike’s a great guy and a longtime source for FPGA design, tools and hardware prototyping related articles—he’s also a great source because he knows what he’s doing and he’s very frank. Dini’s been a huge advocate and user of Synplicity tools and has used them to synthesize and partition many mammoth Virtex class FPGAs on his mega-prototyping boards. He competes with Hardi and, therefore, now competes with Synplicity.

Well, thanks to a letter Dini wrote to deepchip.com (see ESNUG 467, Item 11), we now know how Dini feels about the acquisition: not happy. I’ll let you know Synplicity’s take in more detail after I speak with them.

Another interesting nugget in ESNUG 467, is Item 1, in which Cadence’s Eric Filseth claims that one of Cadence’s competitors in the digital routing space (that would be either Synopsys, Magma or maybe Sierra/Mentor) is doing dishonest benchmarks against Cadence’s router. Filseth declines to come out and say which competitor is doing it but urges Cooley to conduct a user poll to find out which company is doing it.

I found this very interesting and timely because I happen to be working on a cover story on the design challenges of 45nm (what new challenges if any designers will have to face at the new node?). In doing interviews on the subject, one of the foundry reps said that one of the vendor’s routers was choking on the large design files and rules decks and at present slows down considerably. The rep declined to name which tool and which company, so I asked is there a correlation to the age of the router and its ability to handle 45nm designs? The foundry rep said something to the effect that oddly enough there isn’t a correlation. I then recounted the age of routers for the rep, saying that by my estimates avanti/synopsys router is the oldest, Magma’s is the second oldest and Cadence’s NanoRoute is the youngest. (Sierra was apparently not couched by Mentor to the foundry rep as a production 45nm router, rather a quicker engine to get production routers to work with DFM DRC and LVS tools—or course, that may be step 1 in several steps for Mentor moving from the “Switzerland of EDA” to the “Switzerland of EDA amassing a huge army at its borders”). The rep agreed with the order. Mind you, Filseth’s note is talking about 65nm design, and my article will focus on 45nm design. It’ll be interesting to see what ESNUG readers say and to see if there is any correlation to what I heard from the foundry rep. A preview of my article is that at 45nm we are going to start to see the first signs of restrictive design rules, and all the foundries said RDRs will indeed tax routing tools a bit more than at previous nodes, 65nm included, so if things are taxing at 65nm, what does that mean for router performance and benchmarks at 45nm? 

I think it will be vitally important for John to triple check who these benchmark reports are coming from and maybe even ask for the benchmark criteria. I’ve been at pubs that have contracted third parties to do benchmarks and benchmarks are complete headaches as there are many ways to tweak them and simply all tools have strengths and weaknesses—and the test criteria can favor one tool over the other simply by playing to its one strength and not taxing its several weaknesses. Not to mention, the vendors who come in second or worse have a cow (as somewhat illustrated by Filseth’s note). Certainly benchmarks can be useful but all disclaimers must be made and taken with at least some reservations.