Home > Storage > PowerScale (Isilon) > Industry Solutions and Verticals > Electronic Design Automation > PowerScale: Best Practices for Semiconductor EDA Design Environments > Front-End
Each new chip design starts with design specification, where engineers define the precise parameters of the design – including functional features, power consumption, performance levels, physical chip size and more. Once the scope of the project is defined, engineers then build high-level architectural models of the design to help define the final architecture, verify that it meets performance goals, and begin building the verification environment. The design is then implemented using a specialized language (Register Transfer Language, or RTL) such as System Verilog or VHDL to capture the design in a format that can be synthesized to gates (groups of transistors). Transistors are one of the building blocks of semiconductor design. Typically, there is some overlap between high level modeling and RTL capture. Design verification at this stage is considered “functional verification” and occurs throughout the design cycle, including before and after design synthesis. Functional verification (simulation) checks that the design, as coded and synthesized, behaves as expected. (Ex: 1 + 1 = 2, not 3). For a complex design, hundreds of thousands of concurrent simulation “jobs” are typically run to save time. Functional verification does not check for physical attributes, such as heat dissipation, voltage variations and other electrical challenges. These are addressed in the back-end part of the flow.
Efficiency in creating, scheduling, and executing build and simulation jobs can reduce the time it takes to bring a chip to market. There are workflows used in design specification phase that generates an I/O-intensive workload when many jobs run in embarrassingly parallel way: EDA applications read and compile millions of small source files to build and simulate a chip design. A storage system manages the various design projects and files so that different users, scripts, and EDA applications can access the data. During the design verification stages, the data access pattern tends to be random, with many small files. Some of the workload requires high levels of concurrency because of the large number of jobs that need to run in embarrassingly parallel way, generating a random I/O pattern.