Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
I noticed that whenever I run ocean using the -nograph option, Cadence starts a "null" X server as described in the following link.
I was wondering if there is any way to prevent Cadence from starting X server when running ocean. I am trying to run a bunch of ocean jobs at the same time in multiple compute nodes that do that support graphical modes. The problem is that I can't run ocean in these compute nodes because it wants to start an X server. It's very difficult for me to change these compute nodes to support graphics since these nodes are meant to run batch jobs that do not require graphics. Any help is appreciated in solving this. Thank you very much.
In releases from IC614 onwards, it starts a vnc server (cdsXvnc), whilst with earlier versions it runs Xndx. Both have the same objective - to be an X server with no display - to effectively swallow the graphics produced by the application. You do not get one cdsXvnc/Xndx per "-nograph" session; they are shared between multiple sessions and will automatically exit when nothing is connected.
I cannot see why you can't start ocean on a "compute node" - there is no need to support "graphical modes" (whatever that means) - no graphics are actually produced - as I said, it's a null X server intended to consume any X traffic without it actually drawing anything.
So the whole point of -nograph is to allow you to run in batch mode. You cannot run -nograph without somewhere for the X traffic to go to - it's generally best to let Virtuoso take care of managing that itself (although you can explicitly set the $DISPLAY to the destination of your choice.
The benefit of the way that this is done is that all code which opens windows, raises forms etc, continues to work - it's just that there's no way to interact with the form because it's a null display.
This has worked for many, many, years, and people are able to run such jobs on compute servers, so I'm surprised you cannot get it to work. Maybe you need to explain which version you're using and precisely what the problem you're seeing is?
In reply to Andrew Beckett:
Sorry about the very late reply. I was trying to solve this on my own, left the problem for a while and now struggling with it again. I'll try to explain more precisely what problem I am facing.
I am using sub-version IC6.1.5-64b.500.7. Using 4 servers with 12 cores each, I run 48 ocean simulations simultaneously using the following command.
ocean -nograph -log log.<sim_num> -restore <name_of_ocn_file>
I use different log file names and .ocn file names for all 48 simulations to avoid any conflict.
The problem is that for some of the 48 simulations, the ocean simulations never start and I instead get the following message.
*WARNING* Could not open display golden.eecs.harvard.edu:80. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X80. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:81. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X81. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:82. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X82. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:83. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X83. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:84. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X84. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:85. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X85. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:86. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X86. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:87. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X87. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:88. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X88. *WARNING* Trying another display.
*WARNING* Could not open display golden.eecs.harvard.edu:89. If no X server is running for
*WARNING* this display, please remove the file /tmp/.X11-unix/X89. *WARNING* Trying another display.
*WARNING* Unable to connect to a non-graphical X Window Display server.
I tried inserting a command before every simulation to remove /tmp/.X11-unix/X8* to see if that solves the problem. Doing so made the message above go away and allowed all 48 ocean simulations to start, but some of them would crash with the following message.
\e IO Error 32 (Broken pipe) on Display "macabre.eecs.harvard.edu:80.0"\e Aborting due to fatal X IO error.
All the crashed simulations had one thing in common - they all shared the same X display name. The following is an excerpt from one of the simulation log files.
\o Sub version: sub-version IC6.1.5-64b.500.7 (64-bit addresses)\# Host name (type): macabre.eecs.harvard.edu (x86_64)\# Operating system: Linux 2.6.18-308.20.1.el5 #1 SMP Tue Nov 13 10:15:12 EST 2012\# X display name (WxH): macabre.eecs.harvard.edu:80.0 (1024x868)\# Available geometry: TL(0:0) BR(1023:867)\# X server: RealVNC Ltd (VNC nograph server)\# Depth of Visual (Root): 16 (16)\# Number of Planes Used: 16\# X version: 11.0 (vendor release 3370)
There were 5 simulations running simultaneously that had the same "X display name (WxH): macabre.eecs.harvard.edu:80.0 (1024x868)", and only one of them finished while the other 4 crashed with the log message I attached above. My guess is that different ocean simulations should not use the same X display name when running simultaneously. I was wondering if there is a way to run multiple ocean simulations simultaneously without having X display issues. Thank you very much!
In reply to Wonyoung:
I suggest you contact customer support via your support channel (I'm not sure how that works for North American universities, since I'm in Europe). It's hard to debug without more detailed discussions, and that's something best handled via customer support.