Strategies for EDA tool usage will change course as gate levels, and ultimately costs, rise in programmable logic designs. For designs below 25,000 gates, the basic tools from logic vendors and many standard design tools are available for very little money. This level of design consists of mostly an aggregation of "glue" logic and some smaller hardware accelerators for specialized functions.
Yet it's a different tune for midrange designs between 25,000 and 250,000 gates. In fact, many users are taking the path of the ASIC designers. Design entry exists in some hardware description language (HDL), while the overall methodology calls for successive refinement via synthesis. The average tool cost, though, jumps to over $25,000 per designer as the tool set climbs to over a half-dozen individual tools.
The midrange tool set includes a simulator, synthesis, and "helper" tools, such as static timing analysis, code coverage, and possibly a Lint-type tool and a debugging tool set. Software development is one new function creeping into this range of designs now that embedded processors are available to designers (see the figure).
When system-level designs vault above 250,000 gates, the choices narrow down to either continuing in the ASIC path, or finding some alternative. The ASIC path leads to increasingly complex tool sets that can cost over $100,000 per designer. They will require a support staff of one person for every three to five designers to develop interfaces and scripts for the tools. In this ASIC-type design environment, the design times for the system-on-a-programmable-chip (SoPC) are about the same as the equivalent design size in an ASIC, between six and 12 months.
The alternatives, although mostly much more expensive than the vendor-supplied tools, let designers change levels of abstraction to better visualize the overall design. Some tools can generate an HDL representation of the design directly from higher-level models, allowing the design group to have a reasonable look into the software development at the same time as the hardware.
Ultimately, new EDA tools will be necessary. We'll take a look at some of these tools later on in the article.
Need For Change: Bob Barker, vice president of marketing at Future Design Automation, notes that one issue for FPGA designers is the need to change the design environment and improve user sophistication. ASIC designers have many tens of tools and scripts to invoke the tools in a repeatable sequence. Unless they're migrating from the ASIC world, FPGA designers tend not to have the support and infrastructure in place to help with the complex design environment.
Kent Moffat, product marketing manager at Mentor Graphics, agrees. He adds that in some sense, the changes from small to large FPGAs is not only a technical challenge, but also an internal design culture challenge. The design environment must shift from a small group of people working on a collection of design blocks in the same package to an interacting team. ASIC groups have a large CAD organization to help with scripts and tool flows. FPGA users moving up from smaller FGPAs lack this type of infrastructure.
Another key issue is support, says Axel Tillman, CEO of Novilit. HDLs are complex and as FPGAs get larger, the design task grows exponentially.
Molding To Change: The existing tools and methodologies can't scale and grow to address the changes in the nature of FPGA design. As the chips expand to ASIC size, the methodologies must evolve to either an ASIC style—lots of simulation, vectors, synthesis, etc.—or to a block-based design with 50% to 80% of the design as predesigned function modules.
Even with the use of predesigned function blocks, design complexity is surpassing the tools' capabilities. In simpler times, multiple blocks on an FPGA interacted minimally. The net effect was that of a set of multiple designs within a single piece of silicon. Now the blocks are specifically de-signed to interact.
The very high level of communications between blocks—protocols and transactions—is very time consuming and complex to verify in the design. Interactions between the various protocols is not simple. What does it take to interface the DSP and CPU while concurrently the direct memory access (DMA) and USB demand the bus?
Though beneficial, using an ASIC flow isn't time friendly. Most designs require the designer to spend a lot of time in simulation at the register-transfer level (RTL) with little hope of reaching a well defined endpoint. One question is how to translate from RTL to something else. If the design starts with a high-level model, this model needs a transform to something else and then to RTL.
The ASIC approach requires detailed structural knowledge of the functional blocks. But system design needs a different set of simulations in C or some other high-level language to check algorithms and structures. Unfortunately, the next step in this ASIC design flow is to manually translate the high-level model to HDL, with the attendant errors and gaps in design.
Fred Stones, vice president of sales at Summit Design, says new technologies enable a conceptual level above the hardware. A layer of C can adequately model most operations of any IC until you need to get to the clock-accurate details. In this way, you can verify in SystemC and migrate toward a mixed C-RTL design for synthesis.
Methodologies: The critical focus of system-level FPGA design is changing to one of rapid output and performance tweaking. To accomplish this, users need to explore the system architectures and look at the limitations of the devices to be used. A sub-optimal choice, say a microprocessor with a floating-point unit in a system that's not doing any math, makes the rest of the system unwieldy.
Designers must be able to verify the design in an interactive environment. Unfortunately, the HDL simulation environment generates too much data. It also requires a complete description of the input stimulus vectors, leading to incomplete coverage and an unknown endpoint for verification.
To change the design sequences and reduce time to working silicon, breakpoints should be inserted into the source code and backtracked to the smallest cloud of gates that can originate the errors. The desire is to get into the lab as quickly as possible, to run the design at full speed, and to get to billions of clocks in just minutes rather than in days or weeks.