why is CCAR so slow?

Isn't it supposed to ba CHIP assembly router? Then why, when working on
a rather small design, with ~200 I/Os, a dozen blocks, a few hundred nets,
using abstract views to save memory, why does it eat up more than 1Gb of
memory, 100% CPU time, takes about 30min to start up a a few hours to route
a single net?

may I mention, it's the same wether running on solaris or linux, and wether running
on a sloppy pentium 3 with 512Mb RAM, or on a 4-processors 16Gb RAM computing server.

Is there something I'm missing in its use or configuration, or is this the normal
behavior ? In the latter case it could be stated explicitely in the manual. (sorry
for being a little bit sarcastic)

I'd appreciate any clues on this one,

cheers,

stéphane

 

I think they say it (or at least said in the past). If I remember well
there was a limit of about 40000 nets after which ccr "starts to show
its limits". I did a quick search to locate this but to no avail. You
may want to look in docs at least 3 years old. I am sure it is somewhere.
All this assume they did not improve the tool since I read that infos
in which case what I am saying is outdated.
good luck.

 

I don't know, but if you want something faster try Lyric from Pulsic
(www.pulsic.com)

Please excuse the blatant plug!

- Keith (keith at pulsic dot com)

 

I also had what I thought was a relatively small chip, and in fact my
CCAR session crashed entirely. What I did was create some blackboxes
of the pins and solid blockages (for some of the larger modules). I
then re-exported from Virtuoso and loaded up my CCAR session, and then
I was able to route my design with no problems. If I remember
correctly, I think the problem has more to do with the router itself
and it's limitations, and not with reasonable size hardware box.

 

Can you contact Cadence customer support? This doesn't sound right.

Andrew.

 

I'd like to do it, but i think i'm not entitled, because i'm using academic licenses,
which do not include customer support (tell me if i'm wrong).

stéphane

 

Do you get your software from EuroPractice? If so, perhaps you can route your
request to them - saying that I suggested passing it on to us. I'd like us to
get to the bottom of your problem.

Regards,

Andrew.

 

Yes. I will do it.

thanks Andrew

stéphane

 

Hi Stephane,

the only cases where I've seen CCAR having performance problems were, when to
many polygons/objects are imported into it. I have seen an almost flat IC design
which has taken one hour to load. Needles to say the it was impossible to work
with it.

So you are doing chip assembly with blocks and abstracts. Are these Abstracts of
the blocks or of the cells within the blocks? I suggest doing a
blocklevelrouting for each of your blocks first and than using only the
abstracts of these blocks to do your chipassembly.

Regards,
Marc

 

Hi,

yes, that's what i'm talking about, top-level routing using abstracts
of the blocks that we generated for this purpose. Actually the largest part of the
circuit (in terms of number of polygons) is the pad ring.
Maybe i can try to find a report from CCAR on the actual number of shapes
it has to deal with, to see if the problem may come from this.

thanks for replying,

stéphane

 

While i was gathering some data to back up the support request i was going to
send, i noticed one of the image file in the design was very much larger
than the other. after a bit of digging, i found out that this block was in fact
a full layout (somebody had cheated and named it abstract but it wasn't). it turned
out to be the source of the problem, since the block was repeated about 200 times in
the design. (but it was small block so hard to visually notice anything wrong with it -
stupid situation).

After i corrected this, it went ok.

So i must apologize for having blamed the tool, it was our mistake. The tool
is working fine, when making correct use of it.



stéphane

 

Stephane,

That's good news.

Andrew