Data storage yields increased design productivity
Review how current data-storage technologies can offer an essential tool for significantly increasing the speed of design processes, enhance productivity, and avoid the unpredictability of evolving design needs.
Paul Rutherford, Isilon Systems -- EDN, August 12, 2010
| View as PDF |
As IC designers continue to look for ways to improve design productivity, one area that deserves scrutiny at 90 nm and below is the storage environment for design files. Just as the CPU, networking, and EDA tools all play a role in boosting productivity, so does the storage environment. Current data-storage technologies can offer design teams essential tools for significantly increasing the speed of design processes. The storage that supports design workflows is significantly more complex than it may at first appear, and, as designers move toward 65-nm and smaller process technologies, those complexities increase. As design leaders and their partners in IT evaluate and integrate storage environments, they must consider key criteria to account for the efficacy and budget impact of storage in the design flow.
These criteria include I/O performance— that is, the speed of writing data to disk and reading it back to the CPU and user. Designers can further break down this criterion into transactional, sequential, and random-access patterns.
Other criteria to consider include availability, the cost of maintaining uninterrupted access to the data; reliability, the cost of mitigating the risk of data loss; and maximum scalability, the largest data volume the storage system can ever hold. You might also want to consider dynamic configuration, the cost in time and effort it takes to make a change to the system, and resolution of scale, the smallest increment by which you can increase the storage capacity. Also important are the purchase price; the total cost of ownership—that is, how much it costs to operate the system over its useful lifetime; and the system’s ease of use.
As the central point of a one-to-many operation in the design flow, storage acts as the intermediary between the application and the results, back annotations, libraries, IP (intellectual property), team members’ data “sandboxes,” test suites, and design repositories. Storage has emerged as a barrier to productivity at processes below 90 nm. The reason for this slowdown in productivity is a dramatic increase in the number of files and rule decks necessary for verification and in the number of libraries and cells in designs. In addition, the overall gate counts continue to grow.
These changes have created two challenges that consistently affect designers. First, designers require fast file I/Os to bring files and rule decks to the EDA tool; otherwise, the tool remains idle. Second, the storage environment must scale in its available capacity; otherwise, factors such as intermediate formats, “scratch” space, and the overall size of design databases will overrun the storage space available to the tools. In short, both performance and capacity are essential for avoiding storage-related bottlenecks. Depending on the storage architecture you use, you may find it difficult to simultaneously achieve both of these goals.
File-I/O performance and scalability
have taken a lot of designers by surprise
because they previously encountered
storage environments that were
adequate for the task. For example, traditional
storage employing RAIDs (redundant
arrays of independent disks)
has a capacity limit of 16 Tbytes in a
file system (Figure 1). Five years ago, 16 Tbytes represented
a lot of space; today, it is a fraction of what a designer might
need. It is common to see a 45-nm design with a total design
database of more than 200 million files, totaling 30 Tbytes,
whereas, at 32 nm, the design would require 100 Tbytes.
For designs that now consume a few terabytes, designers should consider mapping a storage strategy that accounts for future growth. Scripting, run directories, shared design repositories, and intermediate-results files all can become time-consuming and error-prone without a storage architecture that allows the file system to scale to accommodate these increasingly massive file repositories.
File-I/O performance is a separate concern and requires
even more effort to manage. With traditional RAID-based
storage systems, a filer “head” unit manages the traffic into
and out of the array of disks (Figure 2). This approach makes
it easy to add additional disks to expand capacity, but a “hot-filer”
problem ultimately arises when the filer head reaches
its performance limit. The impact of this scenario is most noticeable
in physical verification. Here, the number of rules
and libraries that the design must access at processes of 65
nm and below can overwhelm a traditional storage system. In
one case, the ratio of elapsed time to CPU time during DRC
(design-rule checking) was roughly 20-to-1; a hot filer had
made storage-I/O performance the bottleneck in the physical-verification runtime. During both physical implementation
and physical verification, a good way to confirm whether
file I/O is a bottleneck is to use the EDA-tool-log files to
capture this information. At ratios of elapsed time to CPU
time of greater than 3-to-1, file-I/O issues are most likely the
gating factors for achieving results.
Planning storage for productivity
Storage-capacity planning for IC design is difficult in that requirements change rapidly and irregularly. Planning for growth according to the gate count or number of designers is often insufficient when, for instance, the use of multiple-threshold-voltage libraries can double the amount of scratch space an EDA tool requires. Similarly, a revolutionary new physical-verification technique might increase needed I/O performance by an exponential amount. To be responsive to the requirements of IC designers, an ideal storage architecture should be scalable in performance and capacity in both small and large increments without requiring a system redesign or replacement. Ideally, a storage approach should have pay-as-you-grow characteristics that allow the organization to acquire additional resources only as need dictates, rather than overproviding storage space as a means of future-proofing.
Some industries deal with large data sets and high I/O performance from which IC designers can learn as their designs reach similar levels of complexity. For example, in the life sciences, DNA (deoxyribonucleic-acid)- sequencing processes typically create results files that are a few terabytes each and that require iterative analysis to interpret correctly. Media production, especially for films and television, also generates files in terabytes that require high I/O performance to edit and render in a reasonable amount of time. From studying how these industries have dealt with their performance and scalability issues, designers will find some practices that directly apply to IC design.
First, the ability to quickly add capacity without restructuring the data across multiple file systems saves significant downtime as design requirements change. In these cases, scale-out storage technologies, in which you can add capacity without downtime or reconfiguration, are attractive. Traditional RAID-based storage systems require downtime to add capacity. Even if the downtime takes place during off-peak hours, it prevents the ability to perform critical functions, such as overnight runs. If the added storage capacity exceeds 16 Tbytes, you must also absorb the time and complexity of restructuring which data belongs in which file system, and you must adapt the tool scripts to reflect that restructuring.
You must also ensure that you can scale capacity and performance independently of each other. In some cases, a design team simply needs more I/O performance but doesn’t want the expense of adding capacity, and vice versa. Traditional RAID-based storage limits your ability in this regard because of the architecture of the filer head to the disks. An alternative to that approach is to use an architecture such as scale-out storage, which distributes the processors and memory that define I/O performance across all nodes of the storage environment instead of just the filer head unit. This approach allows performance increases by adding nodes that contain strictly processor and memory but no hard drives. This approach works well if your goal is to add just performance without adding capacity. In addition to giving the design team exactly the I/O performance it needs to remove the storage bottleneck to tool performance, this approach removes the cost overhead of additional disks.
A third practice is to make ease of use an explicit goal of using a new storage environment. Ease of use applies to management overhead, the effort necessary to scale, and the impact on the user. For management, the human resources necessary for maintaining a large storage system range from none to many full-time employees. The management of an appropriately sized, well-built storage system should not require the hiring of additional dedicated IT staff.
Scaling a storage system’s capacity, performance, or both, whether by fractional amounts or by orders of magnitude, should not require multiple months of meetings to plan or even several days of IT expertise to implement. Designers should instead be able to scale a storage environment in minutes, independently of scale. Ideally, IC designers focus on the design, not computers or disks. Designers shouldn’t be concerned with or aware of volumes, capacity, formats, or how to access their data. A user might notice a sudden increase in capacity but never experience an interruption in service.
Storage decisions for IC designers typically involve four primary questions: Will the storage approach provide sufficient performance and capacity for the designers’ current needs? Will the system experience any significant downtime or data loss? Does the company have the human resources to manage the system? How long will it be before the company needs to upgrade this system and at what cost? Today’s traditional file-based storage approach cannot cost-effectively manage the rapid data growth taking place in IC design and, as such, can become an impediment to efficient IC design.
By deploying scale-out technologies, specifically scale-out storage for file-based data, IC design teams can take advantage of the pay-as-you-grow scalability of both performance and capacity, a single-file system, and the inherent ease of use to meet the demands of IC design today and in the future. By understanding the differences in storage architectures and by planning for future design needs, IC-design managers and their IT teams can craft a storage strategy that avoids designproductivity pitfalls and minimizes IT-related delays in expanding both storage performance and capacity, accelerating the IC-design process and improving time to market.
Talkback
