VXL intermittently hangs

[rick]

We're running IC51 on linux RHEL 5.2 and VXL will stall our for about
5 seconds intermittently but it happens
alot. I see no pattern with the function being performed. It
happens on moves, zooms, even query's. I've
tried everything on sourcelink with environment and license settings.
BTW, we are using GXL licenses. Has
anyone else seen this? Is there a way I can found out what VXL is
waiting for?

Thanks

 

[rick]

On Oct 13, 9:19 am, rick <ej...@pacbell.net> wrote:

We're running IC51 on linux RHEL 5.2 and VXL will stall our for about
5 seconds intermittently but it happens
alot.   I see no pattern with the function being performed.   It
happens on moves, zooms, even query's.  I've
tried everything on sourcelink with environment and license settings.
BTW, we are using GXL licenses.  Has
anyone else seen this?  Is there a way I can found out what VXL is
waiting for?

Thanks

I found the problem!

The delays appeared to be either network related which was eliminated
or a VXL extractor problem based on the
behavior until I noticed that if I had the "marker" layers turned
off, the system ran fine. I reconfigured the color
to a non-blink layer and again, no problems. I ran many tests over a
short period of time and it is reproducible.
I found an article that addressed the issue and supported my
findings. Cadence recognizes this problem and has
implemented a "-noblink" option that also works based on my testing
so this would be the easiest fix.

Here are a few snipets from the article:

Problem statement:

I am using Virtuoso layout editor (version 5.0.0.500.32 and
5.0.0.500.37 tried)

under Linux and have found that the cursor is very slow and often lags
the mouse

pointer by a large amount. The problem is seen only when root visual
is 24 bit

trueColor visual. The problem is not seen with 8 bit root visual.
Also, the problem

is not seen on solaris machine running 24 bit color root visual. I
noticed that when

this problem occurs, Xserver process takes most of the CPU.



Solution:

It is required to use an efficient graphics card. Slow graphics cards
will be

bottlenecks affecting graphical performance of the CIC tools.



The blinking operation takes place in the background once every
second. With 24bit

visual, it is an expensive operation because it involves several
pixmap copies. So

if the graphics card is not good at pixmap copy operations or not
properly

configured, it may lock the cpu. This results in the above mentioned
problem.



Here is a workaround if you are facing performance problems with 24bit
color visual:



Starting with IC5.0.32.500.5 ISR, Cadence has introduced a runtime
switch for icfb ( and

all other workbenches like icms, layoutPlus etc ) called '-noblink' .
Invoke the

software with this switch . For example:

Unix > icfb -noblink &



The '-noblink' turns off the blinking operation.



Note : As the '-noblink' name suggests, using this option will disable
the blinking of

any layers that are currently set to blink via technology/display.drf
settings .

Specifically, if ["marker" "error"] layer purpose pair is in use and
is set to blink, then using

this '-noblink' will disable the blinking. It will just be like any
other

non-blinking layer.