!!! "It's not a BUG,
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / INDUSTRY GADFLY: "First Encounter vs. Jupiter-XT?"
_] [_
by John Cooley
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
It's funny how an innocent passing comment can reopen an emotional wound.
There I was frantically working on ESNUG 431. It was almost 2 weeks after
the Fourth of July break and I had to get a new ESNUG post out the door
when I stumbled across:
"We had looked at First Encounter, but decided that First Encounter
is for novice designers, not power users."
- JC Wang of Broadcom in ESNUG 431 #6
and then my horrible, unspeakable nightmare unexpectedly came back to into
life...
Flashback to 4 months earlier in March at the recent 2004 SNUG Conference
in San Jose. Aart de Geus, the CEO of Synopsys, had just finished his
annual keynote address to his users. It was post-speech Q&A time. In my
feeble psyche, I was like a shark closing in on a helpless swimmer when
I stood up to the microphone and publically asked Aart:
"Why are you bragging about your Jupiter-XT floorplanner doubling
it's capcity in the 2004.06 rev when Cadence First Encounter so
completely owns the foorplanning market? Wouldn't your R&D man-hours
be better spent improving Astro or Hercules? Why bother going
after the floorplanning market when you're so behind?"
There it was: "Jaws Goes EDA" -- Aart is the swimmer and I'm the shark!
Yea! Chomp! Yum!
Or at least that's what I though of myself at the time.
I don't remember Aart's specific answer. It was something like "we feel
this technology is of strategic importance to the company" or something like
that. His reply wasn't what struck me. It was in the reception afterwards
where three Intel PD engineers and I had a few beers together is where I
was traumatized:
Eng. #1: Wow, John, you really made a fool of yourself in front of
every physical designer in the room when you asked Aart that
Jupiter/FE question.
Eng. #2: Yea, I love it when you PD wannabes try to talk tech. It
just shows how little you know.
Eng. #1: Whenever we took any FE Scheme commands to create a power
grid, we hit issues with the Scheme not doing 100% of what the
FE guys intended it to do. The FE guys were all ex-Avanti but
they didn't quite remember Scheme syntax exactly. When FE
output Scheme commands to build power straps for our chip, they
weren't sequenced in metal layer ordering. Instead they were
sequenced in database order. The result was a non-continuous
strip in the middle metal layers where a strap above and below
had dropped or cross connected. What a mess. We wound up
writing a Perl script to resequence FE's Scheme commands. I
guess you RTL guys could write a Perl script, but beyond that
you're useless in physical design.
Eng. #2: The frustrating thing was that we didn't catch this until a
month later because we stupidly trusted FE's internal rail
analysis. It was when we ran our design in Astro Rail analysis
was when we saw the big dropouts. You'd have places where VCC
would cross metal 3 and 6, but we'd miss a VSS strap that had
to run through that same location. It took us 2 days to clean
up this mess right before tapeout. We didn't need that then.
Eng. #3: We had problems with FE pin assignments across blocks being on
different layers. For example, a pin on metal 4 connecting
to another block on metal 6 so our router had to jog through
metal 5 to connect them. There wasn't enough space in the
channel to make that jump. We had to go back through and
clean up by hand all the block pin assignments.
Eng. #2: Our pinouts were worst with rectilinear blocks in FE, too.
Eng. #1: We had keepouts and some constraints get lost when we ported
the FE blocks to Astro and PhysOpt. Details would disappear or
get corrupted in the translations between these tools. We spent
a lot of time looking at downstream router DRC reports and
finding the errors there. This is exactly the time you don't
want be finding these things because you either have to appy
a band-aid fix or redo everything all at the last minute.
Eng. #3: FE couldn't do abutted blocks on our chip. You had to have at
least one track between every block plus you had to then
do top level routing. Jupiter doesn't make us do this.
Eng. #2: RTL nerds like you, John, would trust FE's congestion maps. When
the design comes into a real backend tool, these congestion maps
don't correlate to what the FE play tool tells you.
Eng. #1: FE is great for prototyping, but it's an immature floorplanner.
Eng. #2: Yea, it's for quick and dirty feasiblity studies. It's not
complete nor legal. It's not for closing.
Eng. #1: Yea, it's not for signoff. Jupiter is.
After being beaten up like this, I was traumatized. For 3 years in my Trip
Reports, I've been catagorizing First Encounter and Jupiter-XT as rival
equivalent tools. That is, I've been saying they're both floorplanners,
because in my experience they are both floorplanners. But, according to
these guys, I'm a "PD wannabe" and an "RTL nerd" which in their eyes means
I'm blind to real physical design. I could be wrong about equating Jupiter
and First Encounter -- and if so, I'll need to own this mistake. But, on
the other hand, this could just be an Intel-specific view of EDA tools and
I'm right all along...
So I need my PD readers to decide this for me.
1.) If you need to be anon, say "Make me anonymous".
2.) Prove to me you're a real PD engineer. What specific rev of Astro
or Magma or whatever are you using for P&R? Tell me something about
your current P&R tool that proves you're not a "PD wannabe".
3.) Choose one or another, BUT NOT BOTH:
A.) Cadence First Encounter and Synopsys Jupiter-XT are pretty
much both floorplanners that compete in the same EDA niche.
B.) First Encounter is a "Silicon Virtual Prototyper" and
Jupiter is a floorplanner. They're distinctly different
tools that compete in different EDA niches.
4.) Explain why you choose A or B above. What is your reasoning?
Are you using either tool now? What do you think of it?
I'll publish and abide by the results of this vote by the PD people. And
if need be, I'll be apologizing for equating these two tools... :)
-----
John Cooley runs the E-mail Synopsys Users Group (ESNUG), is a
contract ASIC designer, and loves hearing from engineers at
or (508) 429-4357.
|
|