( ESNUG 419 Item 1 ) -------------------------------------------- [10/08/03]
From: [ The White House Leak ]
Subject: Had a Bad Magma Experience, How About Cadence or Monterey Instead?
Hi John,
Please post this as anonymous.
We're a engineering group with limited access to Design Compiler, so we
chose a backend design house to take our 0.18 um netlists and constraint
files. The size of our chip (4.5 M gates, 650 K instances, and ~80+
memories) dictated a decision to perform a hierarchical physical design
entirely in Magma versions 3.x. Here is what we saw with Magma.
1) Magma could end up with long run times if your constraints weren't
fairly mature. The basic constraints (clocks, false paths,
multicycles) were almost 100% fine tuned, but the I/O constraints
were poor as the physical hierarchies were being defined at the
floorplanning stage. We got into a mode of garbage-in/garbage-out
early on without gaining much in terms of effective floorplanning
or timing closure.
2) Magma didn't support asynch constraints such as max_delay or min_delay.
It was a hit and miss routine that required an eventual timing ECO
and caused a compromise in timing spec.
3) We were told that Magma needed to be let loose to resynthesize logic.
But the choice was there to "force keep" selected instances. However,
if the the list was extensive, then it would be very hard to meet
timing. One could put a "force keep" on an instance but not on a net.
Once we saw our adders get replaced by XOR's, which were a poor choice
in terms of area or timing. I am not sure how, but that problem was
resolved by a workaround.
4) Magma, by default, flattened the logical hierarchy. The user would have
to define what layers to remain intact. Again we were told that the
fewer layers, the better to meet timing. This turned out to be a major
problem later in our design cycle, as functional ECO's were very
difficult to implement. To state the obvious, our ports within logical
layers go away as the hierarchies collapse.
5) We fed wireload models generated by Magma from previous runs into DC,
and used a setup margin upto 20% of clock period (fastest clock 138 MHz),
only to lose it and some more in later Magma runs! That caused several
iterations of the same block by trying different block floorplans.
6) Clock trees were two long. At times Magma inserted upto 50 layers of
buffering. After a few tries, we were able to get the # down to no
better than 33 for networks with a flop count of 30K+. It was important
to us to keep a few of the clock networks very short. In one of the
physical hierarchies (150 K instances, a half dozen memories) one clock
network contained ~2500 FF's. Our hope was an insertion delay of
0.8 nsec, but we settled for 1.8 nsec with 13 layers.
7) According to Magma, there was a known top level routing problem called
"glass box." This had to do with the lack of timing visibility of the
physical sub-hierarchies. We ended up routing the top level w/o timing
by relying on PrimeTime post-process.
This email isn't intended to bash Magma. I am sure other P&R tools might
have yielded similar results. However, to avoid these problems for our
upcoming chip, we are considering a prototyping tool such as Monterey
IC Wizard/Sonar/Dolphin, or Cadence First Encounter before (and specially
during) our engagement with a physical design house. Any inputs in terms
of individual experiences with these tools/flows, success/failure stories
to address the above issues are appreciated.
- [ The White House Leak ]
|
|
