Synopsys Logo
    HELPING YOU DESIGN THE CHIP INSIDE


DESIGN IMPLEMENTATION
VERIFICATION
INTELLECTUAL PROPERTY
DFM/TCAD
DESIGN SERVICES
Arrow NEWSROOM
Arrow PLATFORM & RELEASES
Arrow PUBLICATIONS
Arrow CUSTOMER EDUCATION

Arrow SOLVNET
Arrow SEARCH FOR IP
Arrow SVP CAFE
Arrow SNUG

Products

VCS Verilog Simulator

64-Bit Cross Compile Technology Backgrounder
PDF Icon

Contents


Overview
With explosive growth in design sizes and complexities, capacity of HDL simulation tools and workstations must increase for simulation-based verification to continue to be viable. While formal analysis tools have often been considered the verification capacity bottleneck, simulation tools are much more widespread and therefore impact capacity requirements across a greater number of workstations. The popularity of simulation server farms confirms this wide deployment, and highlights the importance of simulation capacity.

In general, EDA vendors have focused on increasing capacity by improving the efficiency of the tool usage of workstation memory. Another, more complex approach involves overhauling the tool’s memory addressing so it has access to more memory available with new 64-bit based workstations. While this approach improves capacity by many orders of magnitude, it often breaks the user’s verification environment and most server farms are unable to support 64-bit memory addressing. Cross compile technology offers a way to utilize 64-bit memory addressing, and avoids the associated downfalls.


Compiled Simulation Technology
Unique approaches for increasing capacity for leading commercial HDL simulators can be considered because of “compiled simulation”—a fundamental technology shared by these simulators. Compiled simulation technology was first commercially available with Chronologic’s VCS Verilog simulator (now Synopsys VCS). Compiled simulators provide tremendous performance advantages compared to that of “interpreted” simulators.

There are two primary steps for compiled simulators—design compilation and design simulation. During the first step—compilation—the design description code, written in a language such as Verilog, is read by the simulator and converted directly into “executable” code, which can be natively understood by the workstation. This step is similar to compiling the “C” code written by a software engineer, producing a program that can be run on a personal computer (PC). In order to perform the second step, the user must “execute” the code—similar to starting a PC application with a double-click of a mouse. With compiled simulators, the simulation step is usually run several hundred times more often than compilation. This usage ratio of compilation-to-simulation is key to implementing capacity improvements, which will minimally impact hardware resource requirements.


VCS 32-Bit Capacity
VCS has been designed to use memory very efficiently. The baseline requirement is the capability to handle multi-million gate designs on today’s workstations, with headroom to handle some larger future designs. While memory use is highly design-dependent, based on customer data, VCS today is able to handle designs containing up to 20 million synthesis-equivalent gates. This capacity limit is due to VCS’ support of 32-bit memory, which allows it to access up to 4 gigabytes—the maximum memory supported by 32-bit memory workstations.


Workstations with 64-bit Memory Architectures
Many workstation vendors such as Sun Microsystems and HP have developed system architectures which break the 32-based 4 GB memory capacity limit. These architectures are based on 64-bits to address memory, resulting in a theoretical limit of approximately 16,000,000,000 GB of memory (Note: this is roughly 2 multiplied by itself 64 times).

Many applications have already been developed and ready to take advantage of these new 64-bit architectures. However, it is interesting to note that while many existing 32-bit applications are compatible with the operating systems of 64-bit workstations, the 32-bit applications cannot take advantage of more than 4GB of memory. The applications, often stated as “supporting 64-bit operating systems”, must be “ported” or modified to the 64-bit architecture to utilize more of the available memory.


Issues with 64-Bit Compilation and 64-Bit Simulation
Porting simulation tools to support 64-bit workstation architecture addresses capacity, but creates other issues for the user. The issue of compatibility appears because most verification environments are built with the simulation tool as the foundation and customized with a variety of verification tools from several EDA vendors. These tools plug into the simulator via standard interfaces. In the case of VCS and other Verilog simulators, most of these third-party tools plug-in via the Verilog Programming Language Interface (PLI). These tools, along with any applications developed by the user, were developed for the simulators’ 32-bit architecture. In order for these tools to work with new 64-bit simulation executables, they must be recompiled or in some cases redesigned.

Another issue with 64-bit simulation executables is the requirement for workstations with 64-bit processors (CPUs). These executables can only run on 64-bit workstations, and may require more than 4GB of memory. The cost to upgrade this hardware can be high, since many users have dedicated server farms based on racks of 32-bit workstations loaded with 4GB of memory. Without upgrades for most company configurations, the user is left to simulate on the large 64-bit servers—which today are typically few at most semiconductor and system design companies. Without access to server farm simulation, verification throughput is severely limited, which in turn adversely affects time-to-market.


Cross Compile Technology
Cross compiling is the act of the generating an executable on one type of workstation (called the “build host”), and then running the resulting executable on a different workstation (called the “native host”). The build host and the native host usually differ in operating system and processor type. For software applications, cross compile technology has been useful over the past few decades for two primary reasons:

  • The native host is grossly under powered

  • The user happens to have more access to the build hosts
In the case of EDA tools, 64-bit servers can be considered the build host since they are generally more powerful (with greater speed and capacity) compared to the native host—32-bit workstation.


VCS 64-Bit Cross Compile Technology
To allow users to take immediate advantage of VCS 64-bit support, Synopsys uniquely developed simulation cross compile technology. Cross compiling with VCS means the user compiles large designs on 64-bit servers, and then simulate the designs using standard 32-bit workstations. Using this flow, users take advantage of their 64-bit workstations’ capacity for the one-time, memory-intensive compile step. Since users can then simulate on 32-bit rather than 64-bit workstations, they maximize their existing investments in 32-bit workstations and server farms. Additionally, the cross compile technology allows customers to leverage their existing investment in Verilog PLI-based simulation applications since it eliminates the need to port such applications and interfaces to 64-bit simulator architectures.

An additional benefit of VCS cross compiling is maximum simulation performance. VCS has steadily evolved with innovative performance technology each year since its introduction. As with most commercial simulators, much effort, in the order of several hundred engineering-years, has been placed into developing technology around 32-bit memory addressing. By simulating in 32-bit mode, rather than 64-bit, the user is able to leverage proven, robust performance optimization algorithms to ensure the fastest run time.


Conclusion
Synopsys VCS 64-bit cross compile offers tremendous improvement in simulation capacity, while preserving users’ investment in 32-bit workstations. With this capability, VCS can compile very large designs, yet simulate in the users’ existing verification environment without software or hardware upgrades.