IC 5.0 Linux slow graphic

Hi,
I'm now back to troubles.
I try to run ic5.0 (5.0.32.61) on a Redhat 8.0 Linux machine.
Running that works with medium speed until opening a waveform window.
If that opens, the graphical speed gets terrible slow. The mouse stops
every half second for a quater, wich makes it impossible to use. The
computer (2.8GHz PIV with 1GB) gets to a load of 5!
I then set this:
awvSetOptionValue("cursorSuppressed" t)
That makes it much better but still the mouse tends to freeze every
second and stops to move. An dof course i would like to user the
cursor in the waveform...
I though this should be corrected in this version?
I get some similar thing in layout, where scrolling through the layout
will also peridically stop.
Any thoughs on this?
BTW Xfree4.2 is running with 3 TFT attached.
Regards, Harald

 

Yes:
icfb -W
sub-version 5.0.32.61
I still do not understand the numbering...
why is my number different from x.x.xx.xxx.x?
Mfg, Harald

 

We aim to confuse ;-<

In the past, CD releases were in the form:

4.4.5.42
4.4.6.36
5.0.0.132

the release was generally known as the first three parts of this - e.g. IC445,
IC50 (missing off one of the zeros just for fun).

The hotfixes then used to always replace the last digit with 100.nn - except
that for IC50, we'd already passed 100, so had to use something else. So a new
standard of 500.nn was adopted. So IC50 hotfixes were:

5.0.0.500.nn

Recently we released a new "point release" model (which effectively replaces
the QSR/MSRs of old) - these are essentially going through the full release
cycle (alpha, beta, etc) with all production testing. They also may have
significant new functionality as opposed to QSRs and MSRs which used
to be mainly testing of the P0s that had cropped up in the previous months
of the hotfix stream. They are essentially part of the same major release,
so keep the first two digits. The numbering scheme of the point releases
is based on YR (Year followed by release number). So this would mean
that we have main CD point releases as:

5.0.YR.xx (xx is some number depending on how many builds of that release
were done before it got shipped). For example, the IC5032 release is:

5.0.32.61 (2003, release number 2. IC50 MSR3 was counted as the first one in
2003). Later in the year there with be IC5033 and IC5034, and then moving to
IC5041 next year etc.

When this arrives, the normal IC50 hotfixes stop, and start up as hotfixes
from IC5032, so they become:

5.0.32.500.nn

When IC5033 comes out, these hotfixes will stop, and hotfixes will start based
on IC5033, and so will be numbered:

5.0.33.500.nn

and the CD version of IC5033 will be something like 5.0.33.yy (yy is some
other sequential build number).

It's clear as mud, isn't it?

Andrew.

 

Sorry Andrew,
but although reading that 2 times i didn't get that.
I cannot figure out which of the two suggestet versions is the newer one...
5.0.0.500.38. and 5.0.32.500.2
Should 5.0.0.500.38 be named 5.0.32.500.38 to have it consistent?

Anyway, i'm going to get a new version through our software managers...
Regards, Harald

 

Harald,

The problem was caused by a change in the naming convention midway through
a release (not really the most sensible idea, I suppose), but something had
to be done for the new point release idea.

To answer your question, 5.0.32.500.2 is newer than 5.0.0.500.38. It
was the first hotfix of the IC5032 release, and the simple way to look
at it is that there is only a single ordered stream of hotfix releases
for IC50 and all its descendant point releases.

The only time you really have a confusion as to which is newer is
the last couple of hotfixes before the point release comes out. Because
the point release is based on the frozen hotfix stream, plus some
other non-hotfixed fixes, there may be some newer stuff in 5.0.0.500.38
which is not in 5.0.32.62 (or whatever it was called). Similarly there is
some newer stuff in 5.0.32.62 which is not in 5.0.0.500.38. However,
as soon as the first hotfix after the point release comes out, we're all
synchronised again.

We couldn't go back and rename 5.0.0.500.38 to be 5.0.32.500.38
because that would suggest that it is a hotfix some time way in the
future, which it isn't.

If you take into consideration all the digits in the release stream,
the order of them is apparent - in this case, clearly 5.0.32.500.2 is
newer than 5.0.0.500.38 (because the 32 is greater than 0 in the
same position).

That's probably confused you even more!

Andrew.

 

Andrew:
What is the 500 for again? If it stays constant, why keep it?

 

Hi Herald,
Are you able to run VCP on the above (ic5032/RH8)?
thanx

 

Sorry, but what is VCP?

I now tried that on different machines..
On my laptop with an ATI graphics card everything seems to be fine.
Even getting me the newest? release (5.0.32.500.3) didn't solve the
Problem.
I suppose it could be the Matrox graphics card.
Anyone had Problems with that? I think its a Matrox 450 Dual-Head but
i have to check returning to office...
I will also try with a cheap Nvidia and report that...

Regards Harald

 

Sorry, I made a wrong assumption in addition to my question which
off topic.
VCP stands for virtuoso custom placer.
I am using ic5032/RH901 and was am interested in people
with same config so we can share experience.

 

(Harald Neubauer) wrote in message
I'm now quite sure, that there are severe problems with 24 bit and
linux as a desktop. We are running cadence remotely from a Sun on a
linux which works, and i'm trying to run that from a linux desktop,
which doesn't.
Contacting customer support didn't solve it, so i do NOT recommend
running cadence on a linux frontend at the moment... :-(
I think cadence should tell that, because figuring out that it's not
on our side took too much time. (I tried RH 7.2, RH 8.0, Xfree 4.2
Xfree 4.3 an a total of 4 different machines with different graphics
cards)

Regards, Harald

 

Harald:
What exactly are the problems that you are experiencing?

 

The official position is that RH9 is not supported. Look at the platform
support matrix under Support on http://www.cadence.com and you'll see that
for the IC releases, it's actually just RH7.2 that is supported.

In practice RH7.3 works fine, and RH8 works well enough. However, there need to
be some code fixes for a variety of tools to work correctly on RH9. At some
point this will happen.

The big problem (and this is purely my own opinion, nothing to do with Cadence)
is the ridiculously short lifecycle of RedHat releases. Cadence gets accused of
not supporting releases for long enough, but RH Linux versions are way shorter
lifed! Since there is a general policy of not changing the OS version that a
release is compiled on during it's life, it makes it very difficult to support.
That's not so say it's impossible - just difficult.

Andrew.

 

Harald,

Your problems may well be the ones found in PCR 605387.

The problem results from the blinking operation that takes place
in the background once a second. For the 24bit, it's kind of
expensive because it involves several pixmap copies. So if the
graphics card is not good at copy operations, it may lock the
cpu.

It depends on the card used - many users have had no problems
with Linux, so it's not a generic problem - and it's one we're finding
out about as customers report it. Obviously we cannot test on every single
piece of hardware - this is one of the difficulties of supporting Linux compared
with Sun, HP and IBM platforms, I suppose.

In the short term a fix is planned soon to provide DFII executables
with a -noblink argument to turn off the blinking.

I certainly have been running on a Linux frontend for the last 8 months
with no big problems (some problems with analog waveforms earlier
on, with tracking cursors, but that's resolved; a fix for
crosshair markers should be arriving soon - I've tested it and it
works well).

Regards,

Andrew.

 

Sorry, but i can't find that pcr . I usually find these by just
entering the number in the sourcelink search but i do not get any hit
with this number.
I do not see something like view any pcr. I just get view my pcr,
which obviously doesn't work.
How do i find this pcr?

It is surely true that there is much more hardware for pc than for Sun
etc. But i think a Matrox G550 is something like a standard for cad
workstations?
I'm having less troule on my ATI-Graphic laptop, but that doesn't
support triple monitors... ;-)

This may help, but i remember having troubles with blinking on my Sun
as i changed graphic cards and updated some patches. Then my Sun-cpu
went to high cpu just for blinking, so i'm used not having blinking,
although this is bad to track errors in layout...

Maybee a recommendation about the graphic-card? We are going to buy
more linux workstations and we just ordered now some with different
graphic cards, but it may take some time to find one which works just
by chance...

Regards, Harald

 

Harald,

In general you can only see your own PCRs, because other PCRs may contain
proprietary (Cadence or customer's) information, even in the title...

I had a look through the PCR - Matrox G550 was one of those listed
as specifically having a problem. We've asked R&D to comment on this, because
it _ought_ to be a high performance card. Perhaps it's a driver issue, I'm
not sure...

Yes, we'll see.

Personally I can't make a recommendation - I haven't enough experience of
different graphics cards to be able to give any advice. But yes, it's a good
idea. In general we refrain from making hardware recommendations, because it
is very difficult to keep the information up to date, given that hardware,
drivers, and so on keep changing.

Andrew.

 

Harald,

Just a quick update. The -noblink option is due to be available in 5.0.32.500.5,
which should be available for download on 2nd September. Perhaps once that
is available you can try it and see if it helps?

Regards,

Andrew.

 

Harald,

I was also having the same problems. I upgraded the Cadence install per
Andrew and others and I still had problems. I then updated the video card
drivers and that solved the problem. Try updating the video card drivers if
you have not yet.

Sam

 

After 3 days of experimenting I found solution for Matrox G550.
Now all Cadence software I've tried works without any graphics
problems (tracking cursors, slow downs). Try to put "True" value for
"ShadowFB" driver option in XF86Config file. "NoAccel" will work also,
but in this case hardware acceleration completely off which is not
nice

Regards
Dionis