Question and Answers with Qckvu's Developers

last revised: December, 2000

Is there a need for a high speed GDSII viewer? Can't existing layout tools import GDSII?

Why import such a big file in the first place. Isn't GDSII for mask making?

So how do you go about getting the speed?

Why did you pick OpenGL and what tradeoffs do you have to make?

Are you working on a Linux port?

How about Windows?

Which graphic cards do you recommend for Qckvu?

How can I get and install the latest OpenGL library?

Suddenly my display is running really slow. What happened?

I don't have OpenGL. Is Qckvu going to help me?


 
 
 
Is there a need for a high speed GDSII viewer? Can't existing layout tools import GDSII?
    The need absolutely exists. At 1999's DAC, visitor's number one request was for a high speed GDSII viewer that could handle files in the >2 GB range. As for the existing CAD tools, our customers have told us that it can take 2 hours (on a fast workstation with lots of RAM) to import a 1GB GDSII file.
Why import such a big file in the first place. Isn't GDSII for mask making?
    GDSII is still used for DRC. Basically after your team has spent months designing, simulating and laying the chip out, GDSII is exported and this file is sent to a DRC program. The DRC program does all sorts of checks to verify 1) that the layout matches the schematic and 2) that the layout rules have been adhered to.

    Very likely on your first couple of DRC passes you get a bunch of errors - hundreds and hundreds or even more. Someone (i.e. the design team) has to have a look at each error reported to determine how to correct it or whether it is in fact a serious problem at all.

    To do this you've got to load that same giant GDSII file and navigate to the particular structure and coordinate window reported by the DRC. This is really time consuming and the whole design team gets involved. A really fast viewer starts paying for itself in time savings - you'll find and correct the errors faster and then run the DRC again. Nobody will tape out until all the errors are accounted for.

    The other area we see demand for a fast GDSII viewer is during the dialog between foundry and fabless designers. The fabless designers eventually send GDSII to the foundry; a team of foundary engineers has a close look at the layout to insure yield. If the two of them have to discuss a problem they both need very fast viewers (often the designer and foundry are 10,000 miles apart...).

So how do you go about getting the speed? Why did you pick OpenGL and what tradeoffs do you have to make?
    See the X Windows Update

    We saw that the progress in hardware accelerated graphics was incredible - driven to a large extent by the gaming and the 3D world. But until recently getting to the hardware was a problem - there were a whole bunch of imcompatible API's out there. Each workstation manufacturer had their own proprietary API and the situation on PC's was worse.

    Finally OpenGL achieved widespread support in both Unix and Windows environments. While 3D is the main emphasis for the graphics card people, we get a free ride in most cases for our 2D applications.

    We're pleased with how well OpenGL is integrated into the Sun hardware and since UltraSparc seems to be our customer's platform of choice it's made our life simpler. We are just now evaluating how well HP's newer Visualize workstations deal with OpenGL and I believe the results there will be excellent.

    Downsides to OpenGL? Well, first only Sun/HP workstations that are about a year old have the combination of fast CPU and OpenGL support. So I guess that leaves out anyone with older hardware. Also, if you have a fast workstation but installed the PGX graphics (no acceleration) you won't want to use Qckvu.

    We'll also have to make sure that the user has the latest OpenGL libraries properly installed and we are also seeing that the particular graphics settings on the card make a difference. We've written a program now that will check for all the right libraries, right hardware and even measure the OpenGL performance during the install process.

    Finally, we're not sure if this approach will be suitable for EDA compute farms - that's where the company has a cluster of really big fast machines in the basement and each user has a low cost workstation on his desk which is logged into the server farm. Some of our customers have told us this is how they plan to setup their design teams.

Are you working on a Linux port?
    We've just started (Dec 00). We've shipped on Solaris, and on HPUX; there don't seem to be many IC physical layout tools on Linux just yet - possibly in the next 6-8 months. We're also concerned that to get optimum performance on the PC platform we'll have to test various combinations of motherboards, graphic cards and CPU's. In principle, the port is straightforward but the devil is, as usual, in the details.
How about Windows?
    We've already started. Qckvu for Windows NT/2000 will come out in February 2001. We are pleased with the amount of code we have been able to reuse.
Which graphic cards do you recommend for Qckvu If I don't have the latest OpenGL library on my workstation how can I get and install it? Suddenly my display is running really slow. What happened?
    See the X Windows Update

    We tracked the problem to the fact that you remote logged into the window used for Qckvu. Here is what is happening (and what you can do about it.)

    OpenGL renders directly to the display's frame buffer bypassing the X server (which serves as the underpinnings for CDE and OpenWindows.) This is made possible by Sun's Direct Graphics Access (DGA) mechanism for locking portions of the screen. So while the user interface lives on top of CDE or Openwin, the actual screen draws live underneath and don't incur any overhead of the X server.

    Solaris security allows only the user who originally logged into the window system to use DGA to lock portions of the screen. Non-owners of the window system do not have access to DGA.

    If you notice poor performance when running Qckvu locally, the cause is likely this Solaris security feature. For example, if you start the window system and another user at the workstation changes to the user's own environment using su, the application will not run via DGA even though the second user is running the application locally.

    Solution
    As a temporary solution for a single session the system administrator (root) can edit the login permissions to enable DGA access for all users.

    
     # chmod 666 /dev/mouse /dev/kbd /dev/sound/* /dev/fbs/*
    
    enabling access by any user for the duration of the current window system session.

    To make the change permanent, the sysadmin should edit the file /etc/logindevperm and change the default permissions of the devices to 0666 to allow world read/write access.

    Example

     
    
    Before Editing /etc/logindevperm                                 After Editing /etc/logindevperm
    
    /dev/console  0600  /dev/mouse:/dev/kbd                   /dev/console  0666  /dev/mouse:/dev/kbd
    /dev/console  0600  /dev/sound/*  #audio devices          /dev/console  0666  /dev/sound/*  #audio devices
    /dev/console  0600  /dev/fbs/*  #frame buffers            /dev/console  0666  /dev/fbs/*  # frame buffers
    
    Warning: While the above change enables a user other than the window's owner to get full speed out of Qckvu the change also reduces your security somewhat. It is up to you to determine whether such a change should be made in your environment.

I don't have OpenGL. Is Qckvu going to help me?

    Yes. In fact, this turned out to be the $64 question. When we completed the early versions of Qckvu we were surprised to find that the great majority of our customers couldn't use OpenGL for the following reasons:

    1. They had older machines (such as Ultra 2's ) without graphic accelerators.
    2. They had new low cost machines (such as Ultra 5's) without graphic accelerators.
    3. They remote log into a large server and OpenGL over X is useless.

    So we went back to the drawing board and took a very hard look at the basic X-windows server. After quite a few optimization rounds we ended up with a display driver that was as fast as OpenGL (unless you had one of those $3000 graphics cards) and of course worked fine when remote logged into a big fat server.

    Now we are completely focussed on supporting X-windows; even PC's or low cost Ultra 5's or Linux boxes running an X server such as Exceed or Xvision can be used to view extremely large files.

    Your display performance is better with a better card but OpenGL support is not required - just raw pixel power and that seems to be improving on a monthly basis.