News & Analysis
EDA Platform Benchmark: Setting Up a Unix/NT Environment
James Lee and Subha Pindiproli
12/19/2000 5:41 PM EST
Editor's note: The EDA Platform Benchmark was scheduled to appear in ISD Magazine earlier this year. Unfortunately, the article never made it into this year's magazine. Because of this delay, the authors and ISD want the readers to be aware that some of information may be dated, including the products' version numbers, features, and pricing. Please contact the vendors to inquire if the products in this article have been updated and improved. Nonetheless, we believe this article will be a valuable tool for you.
Entering our third year of electronic design automation (EDA) platform tests, we expand our range of view to evaluate some EDA infrastructure choices. Specifically, we have shown in this series that Windows NT systems can run EDA applications at high speed, but how do you integrate NT systems into traditional Unix-based EDA environments? Two possibilities are X Windows and the Sun Ray enterprise appliance. Thus, we test X software and take a look at the Sun Ray, in addition to benchmarking an 800-MHz Pentium system.
While EDA tasks such as board layout and field programmable gate array (FPGA) design have long been performed routinely on PCs, application specific integrated circuit (ASIC) design got its first mainstream PC opportunity in late 1997 when Cadence ported Verilog-XL to Windows-NT and Intel introduced the 300-MHz Pentium-II processor. We wondered if this combination was up to the challenge of large designs, and ISD put us to work on this benchmark series to answer the question.
The first benchmark installment, published in March 1998, examined the performance of Verilog-XL on behavioral, gate-level and mixed circuits as large as 1.3 million gates. Since then, Synopsys (Mountain View, CA) has ported Design Compiler to NT, and we added DC to our benchmark suite in July 1998. In 1999 we added place and route with the Snaketech (San Jose, CA) Cellsnake tool. This addition completed the core tool set needed to complete the ASIC design flow. Then in January 2000 we brought FPGA tools from Synplicity (Sunnyvale, CA) and Xilinx (San Jose, CA) into our benchmarks.
Throughout the course of the benchmark series we have been impressed with the performance of the NT workstations. As a result, Intrinsix (the design services company contracted by ISD to perform the benchmarks) has adopted a configuration of NT machines with 256 MB of memory. We have found this workstation configuration more than adequate for simulation and synthesis of typical designs containing several hundred thousand gates.
The ASIC design cycle doesn't live by simulation and synthesis alone, however. One recent Intrinsix project involved foundry tools and Verilog PLI object code available only on Unix. We were forced to use Unix machines for this project.
Whether by requirement or by choice, Unix will doubtlessly continue to be part of the ASIC design cycle. Fortunately, it's quite practical to work in a design environment that includes both Unix and NT.
Environment basics
Before looking at the environment and setup required to make NT and Unix play well together, consider the EDA environment in broad terms. Although different companies set up their environments in different ways, we all deal with three main types of data: applications, licenses, and design data. You have the choice to house each of these items locally on a designer's computer or remotely on a server. Each choice involves many tradeoffs. Rather than giving an encyclopedic discourse on the topic here, we will outline the choices we made at Intrinsix as a case study.
First, we put all licenses on a single Unix server. For this purpose, Flex-LM is quite easy to maintain and administer on Unix. Having a vendor cut license keys for a Sun system is quite easy because you only need to provide an 8-digit host-id. Additionally, all the vendors we have worked with allow Unix licenses to float onto NT platforms. Although this capability allows us to specify only floating Unix licenses when we work with our vendors, the vendors end up with an artificially low NT seat count. We believe that this factor accounts for some vendors seeing almost no usage data of their tools on NT.
Applications constitute the second data type, and unfortunately their setups behave differently on Unix and NT. We install Unix applications once on a server, then mount the /tools disk on all of our Unix machines. With this arrangement, each user needs only minor setup in his .cshrc shell setup file to access any tool, and applications become available immediately on new machines once we mount the /tools disk. Updating versions is transparent to users since we use a link, named latest, to point to the current version and encourage the users to point to the link rather than the actual tool version.
This application strategy leads to problems on Windows NT, however, because some applications don't run properly from a server. For example, we installed Microsoft Word on an NT server and tried to export the application on a read-only basis ("shared," in Windows terminology, see Sidebar). Microsoft Word likes to modify itself and its templates when running, though, so you cannot run it from a read-only server.
Additionally, most NT applications store configuration data in the Windows registry during the install process. If you install an application only on a server, the registry-based configuration data may not be present on the user's machine. While we would prefer to install all applications only once on a server, we have suffered fewer problems by simply installing the NT applications directly on the NT boxes. We install the applications into their default installation directories on all machines, so they behave the same on each machine.
The third type of data is design data, and as Intrinsix is a design services company, this data is our lifeblood. We therefore place great emphasis on carefully managing design data, and we are always taken aback by companies that allow design data to spread out across individual workstations or in designers' $HOME directories. Both of these approaches leave system administrators, system integrators, and engineering managers with several problems. System administrators must deal with an increased need for workstation disk space and more complex backups. System integrators and engineering managers face the more critical problem of figuring out where the correct, up-to-date design data resides.
More mature EDA environments have adopted a "data-less" approach in which workstations store no design data. All design data resides safely on a centralized data server. We use this centralized data approach at Intrinsix and ensure that no critical design data can be misplaced in a user's home directory by setting small (100 MB) quotas on user home directories. We call the centralized data disk the /project disk.
The centralized approach has many benefits:
Adding NT machines to the data-less environment
When we deployed NT machines and NT applications, we needed to preserve the benefits of the data-less environment. We needed to be able to move designers and tasks to any machine, which is easy with Unix servers and workstations. Yet the need for office productivity applications and desire for a single desktop machine suggested that the desktop machine should be an NT workstation.
The first step in making the NT machines cooperate in the data-less environment is to give them access to the same data. By default, NT machines use Server Message Block (SMB), a protocol for sharing files, printers, serial ports, etc. among computers. Many alternatives are available for sharing resources, including NFS software for the NT machines; servers such as those from Network Appliance that use both SMB and NFS; and SMB servers for Unix file servers. We prefer the server-side solution since it doesn't require any setup on the NT machines.
The most popular server-side solution is Samba, and we have long used this data and printer sharing solution. In addition to being free and working well, it makes separate PC and Unix passwords unnecessary. The Unix machines' /project disk is available for use on the NT machines via Samba and typically mounted at P:. Each user's home directory is mounted as U:.
On a Unix machine, each user's individual settings are stored in a set of dot-files (for example, .cshrc, .login, .Xdefaults, .xinitrc) in the user's home directory. If the user's home directory is stored on a network server, the user gets the same environment on any machine that he logs in to.
For an NT machine, the equivalent to these dot-files is a profile. The user manager for NT domains permits the system administrator to specify a few critical elements that allow a user to have the same environment on any NT machine he logs in to (see Figure 1). Three critical settings we use are the home directory, profile path and logon script. We set the home directory to mount U: to \\
Droppings
Another NT issue involves managing the various forms of excreta from applications. Some NT applications leave a trail of files that store a user's recent actions, for example. And using a web browser usually results in an accumulation of cookies in a system location (instead of in your home directory) containing records of your visits to various websites. Finally, almost every NT program leaves a trail of breadcrumbs for it to follow the next time you invoke it.
These droppings aren't a problem in themselves, but you have to consider where applications are leaving them. Application developers have three logical choices for storage locations: the user's profile, the application's installation directory or the user's home directory. Only one of these possibilities is correct for a portable, server-based environment.
When a program such as Microsoft Outlook stores data in the user's profile, the entire profile is copied to or from the server every time the user logs in or out. This potentially lengthy activity is the downside of roaming profiles and the reason why it's best to avoid programs that store data in the profile.
Even more ill behaved are programs such as Netscape Navigator, Microsoft Word, and some X server packages that store settings in their installation directories. This practice creates a system-administration nightmare and prevents you from installing the software once, then locking it down in read-only form.
Application developers (especially Microsoft) have little excuse for leaving data in inconvenient places because NT defines a set of variables to indicate the user's home directory (in our case U:). Well-behaved programs store user-specific information in the directory pointed to by the %HOMEDRIVE% and %HOMEPATH% variables. In our setup, the settings for these programs follow each user from machine to machine and aren't buried in some program-specific directory on each machine.
Note that a few applications allow you to designate a data storage location. For the Eudora email manager, for example, you can define a variable named eudora and set its value to something like U:\mail. Eudora then saves mail and variables in that location.
We would like to have all NT applications pay attention to the %HOMEDRIVE% and %HOMEPATH% variables, but we aren't getting that today. We suspect that we will not get that until the operating system enforces this choice or software companies see market share going to competitors who play nice in distributed environments. Otherwise, the legacy of do-what-you-will, single-user applications will be a drag on the acceptance of Windows NT.
Working in a bi-OS environment
Once you iron out all the Unix/NT setup wrinkles in one way or another, you can work on data independent of the platform at which you are sitting. You can use an NT-based editor to edit your Unix-based design files or run Verilog-XL or Design Compiler locally on your NT workstation.
You can also use your NT workstation as an X terminal to run software on the Unix machines. Many different software packages are available to implement X Windows on NT. We were using three of these packages, and we wanted to standardize on one for office-wide use. Thus, we embarked on an evaluation of X Windows software.
Before going into the details of the evaluation, it's important to understand a few basics of X Windows operation. (Also see the explanation of X Windows terms in the sidebar, "X-terminology.") An X Windows package can run in one of two modes on an NT workstation. In one mode (launched by TELNET, rsh, rexec or sometimes XDM), each X Windows program pops up a new window on your NT desktop. You might have CDE (Solaris) or KDE (Linux) windows overlaying your NT environment. These windows can be manipulated on the screen just like any other NT windows. You can copy and paste between the X Windows-based and NT-based programs just as you would between two NT programs, for example. You can also have icons on you desktop or Office shortcut bar to launch specific programs on specific hosts.
The other X Windows mode dedicates the entire screen to X Windows and is launched only by XDM. In this mode, all NT applications are hidden, and you see only X Windows. The windows are managed by a remote X Windows manager such as Openlook, Motif or CDE. This mode appeals to people who prefer to act as if they are using a Unix workstation. The choice of modes is a matter of personal preference, although hiding the NT windows makes copying and pasting between NT-based and X Windows-based applications quite difficult.
Whatever mode you choose, the X Windows software must be able to display colors ranging from 8- to 32-bit color (the "true" color displayed by NT systems). Most EDA applications generate true color, but many older Unix engineering applications with X display capabilities still operate in 8- or 16-bit color mode. If you use any of these older applications, your X Windows software must map the 8- or 16-bit color values onto NT's true color palette.
Securing X Windows
Network security is another X Windows issue that deserves comment since it's so often overlooked by X software vendors. Perhaps these vendors assume that each NT workstation is assigned to a unique user and access to that workstation by others is highly unlikely. This assumption is unsound, especially in an environment such that of Intrinsix, where engineers share the workstations.
Part of the problem stems from tradeoffs between security and user convenience. Users like to launch xterm sessions on different servers for different tasks, but users don't like to type in their passwords each time they launch the X application. Thus, users want the convenience of storing their passwords during the initial configuration process. This convenience comes at the price of a security hole.
Most commercial X packages store password information locally with the data needed to launch an X application. As a result, anyone can launch the X application by looking up the user's profile or stored data shortcuts on the desktops. People can also browse the application installation directories and manually search for the stored passwords in initialization files.
A partial solution for these security issues would be to store each user's profile and settings for the X server and applications on a network drive rather than on the local drive of an individual workstation. In fact, X packages should at least allow the option of saving X-related data on a network drive to address security concerns.
|
|
|
|
|
