NVIDIA selects Gridware's Codine/GRD

"Our most recent generation of chips contained 23 million transistors, compared to the 7 to 8 million that are in a Pentium III processor," says Joe Sura, vice president of information systems at NVIDIA, "and the number of transistors in our next generation of product will be even more than that. As the number of transistors goes up, it takes more and more computing power to do all the design and simulation work required to successfully create them. It's mandatory that we stay ahead of the curve by creating a computing resource that can scale up quickly, as our design requirements rapidly increase in complexity and demand more and more computing power."

The first phase of NVIDIA's Codine/GRD implementation is to manage all application traffic and scheduling for a "wall" of 300+ rack-mounted computers that will process much of the front end design and simulation work for NVIDIA's chips. We've determined that the most cost-effective way of building this part of our computer resource is with a massive array of low-cost PCs running the Linux operating system," says Sura, "and Codine/GRD gives us enormous flexibility in pushing as many as 14,000 jobs per day through this wall. By dividing the initial phase of the design and testing applications into thousands of small jobs that can be run simultaneously, we can keep on adding processors ad infinitum and thereby be able to keep up with the increasing complexity of our final product."

The second phase of NVIDIA's Codine/GRD implementation will be to move Codine/GRD software to the Sun workstations and servers that do the "back-end" portion of NVIDIA's EDA processing.

"Codine/GRD offered a number of things that we couldn't do with LSF," says Kelly Alexander, Unix and NT System Administrator at NVIDIA, "and that included the ability to cordon off groups of users so that we could specify which groups get to use which resources at any particular time. We needed to be able to dynamically manage all prioritizations, by project, so that we could juggle priorities based on proximity to completion without the users having to worry about which queue to put their jobs into. We also needed a way to track resource usage by project so that we could extrapolate what the future processing requirements might be for more complex chips down the line. Until we installed Codine/GRD, we never had a clear handle on which resources were used for a given project, and that made it hard to anticipate and schedule for future processing requirements."