VXL intermittently hangs

Discussion in 'Cadence' started by rick, Oct 13, 2009.

  1. rick

    rick Guest

    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, Oct 13, 2009
    #1
  2. rick

    rick Guest

    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.
     
    rick, Oct 22, 2009
    #2
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.