EDA » Articles

Use Transaction-Level Models to ensure hardware and software are in sync

Michael McNamara, Cadence Design Systems — Fri, 09 Dec 2011 15:00:00 +0000

Companies today are seeking to own more of the vertical design chain by bringing chip design in-house. If not done properly, this will create more problems than it solves. The key is to use a common high-level model of the hardware for software development and debugging that can also be taken into an automated hardware implementation flow. By developing hardware models in SystemC-based Transaction-Level Modeling (TLM), software teams can debug against virtual prototypes long before a hardware prototype is available.

The consumer and wireless communications markets are more competitive than ever. The ongoing battle between aggregation and disaggregation of companies is in full swing. One example of aggregation is a decision to own more of the vertical design chain by bringing chip design in-house. This has helped companies like Apple differentiate by controlling more of the overall product design and thus not being limited by off-the-shelf chips that are available to everyone else.

While Apple has demonstrated the potential reward of vertical differentiation, this approach does pose significant risk, whether a company has experience designing chips or not. Specifically, how does the software team develop software that works with the hardware as shipped?

On the other side of the equation, complete disaggregation is enabled by software abstraction layers like Google’s Android operating system. It has somewhat democratized the design space, allowing all system companies to participate and differentiate using software. Android allows semiconductor vendors to participate equally by providing supporting hardware. Again, the way the software works with the hardware determines product success.

Traditional solutions to this problem do not work in today’s market. Companies used to be able to start software development based on specifications and wait for chip prototypes to be available for testing. That works if the software is very simple, independent of hardware, and has a straightforward specification, but not with today’s consumer electronics that require everything be connected.

Furthermore, waiting a long time to begin testing pushes the debug cycle out far too late in the schedule. Many companies addressed this in recent years by moving to standard off-the-shelf chips, but that approach limits the ability to differentiate. What if you want to add a power-saving sleep mode but there’s no way to shut down the chip?

In an aggregated scenario, companies are looking to differentiate not only in software and industrial design, but also in electronic hardware. Embarking on a chip design project poses its own risks; couple that with embedded software development, and overall project risks go up exponentially. Most companies are careful enough to spend ample time up front architecting the system, testing it, partitioning it into software and hardware, and specifying the behavior of both. But once each team begins designing, certain implementation assumptions are made, bugs are introduced, and features can be added.

The scenario is even worse in a disaggregated world, as the responsibility now spans across company borders. Companies from the systems and semiconductor world might decide to work together to optimize hardware/software interaction and create a chip optimized for system needs. Even if there are constant synchronization meetings, design changes will sneak in unbeknownst to the software team and might not be seen until the first time the software is run on the actual hardware. This cycles back to the problem of the hardware not being available soon enough. How do engineers solve this conundrum?

A golden model for prototyping

Virtual prototypes (or virtual platforms) of hardware that come in the form of software models give the software team a model of system hardware earlier in the process. This enables developers to begin testing on a model of the hardware specification. However, it is only a model of the specification. Most hardware design today starts with engineers reading and interpreting the specification, then writing low-level Register-Transfer Language (RTL) models in a hardware design language such as Verilog to begin the verification and implementation process. Due to the factors mentioned previously, hardware behavior will likely diverge from the specification.

The solution is to use a common “golden model” on which the software team can develop and with which the hardware team can begin their implementation. This is now possible with the availability of the Open SystemC Initiative (OSCI) Transaction-Level Modeling (TLM) 2.0 standard.

In short, SystemC is a class library that enables hardware design using C/C++ by modeling hardware data types and concurrency. Because hardware can now be modeled in C, that same model can be run by the software team. The TLM extensions are important because they abstract away all the signal-level protocol details the hardware needs to ensure that it communicates properly with the system bus. An excess of these details makes the model too slow for running the software. TLM abstracts those details to higher-level models that can be mapped to detailed hardware during high-level synthesis.

Resolutions to high-level synthesis limitations

High-level synthesis provides the automated link between the C model and the actual hardware that gets built. This removes the human factor of the hardware designers interpreting the specification and manually writing their own model to begin building the hardware. Until recently, this had rarely been used in practice because of some key limitations that have now been addressed:

Quality of results: The first two generations of high-level synthesis were never able to produce hardware that met the same performance, power consumption, and size that could be achieved by manually writing RTL. Modern high-level synthesis technology has resolved this issue.
Refinement methodology: The high-level virtual prototype for software development is described with SystemC TLM, but it still requires that the hardware team refine it by adding in hardware architecture details so that high-level synthesis can produce optimal hardware microarchitectures. These details are too low-level for software testing and would slow down its speed, but they are important for building efficient hardware. This methodology now exists and has been proven by early adopter customers.
Verification: Until very recently, engineers lacked a mature methodology to verify the correctness of the hardware architecture in SystemC TLM and the rest of the hardware implementation flow. This is mainly because an automated path into implementation did not exist, so most verification was done at lower levels. Thus verification became the bottleneck in the hardware development schedule. Now that the automated path exists, verification methodology has been developed.

Hardware design teams are familiar with these traditional barriers to designing and verifying hardware using SystemC TLM. Most, however, are not aware that these barriers have been addressed. Those who are aware now enjoy a significant competitive advantage. They can describe their hardware much more efficiently, verify it more rapidly, and reuse it in derivative chips more easily.

Virtual platform in practice

A common model of the hardware is now available as part of a virtual platform much earlier so hardware/software interactions can be addressed sooner. This common model can be delivered as part of the bigger system in a virtual platform either within the company in an aggregated development scenario or across companies in a disaggregated world.

One example of the way this works in practice is captured in Figure 1, which illustrates the flow provided by the Cadence System Development Suite, an integrated set of hardware/software development platforms.

Figure 1: A hardware model is refined from concept to product within the Cadence System Development Suite.

(click graphic to zoom by 1.9x)

The system concept is first described as a SystemC TLM virtual prototype. In the Cadence flow, this virtual prototype is used by the Virtual System Platform to run the software on this hardware model. In parallel, the hardware design team will refine the TLM to add hardware architecture details for C-to-Silicon Compiler high-level synthesis, which is the beginning of the implementation process that will lead to silicon.

If bugs are uncovered during testing, the Virtual System Platform is integrated with the Incisive Verification Platform so that debug can happen on both software and hardware. This means that issues can be addressed at their source without cumbersome firmware patches. As the hardware implementation process progresses, more detailed RTL models become available to create hardware emulation models in the Verification Computing Platform or an FPGA prototype in the Rapid Prototyping Platform.

This entire process is a successive set of refinements that begins with a fast TLM model, adding more hardware detail as it becomes available while maintaining runtimes that are fast enough for software development. This ultimately enables the software and hardware teams – even across company borders – to have a common model that enables earlier communication and constant synchronization. This is the type of collaboration needed to keep pace with the innovation and delivery schedules required in today’s consumer market. It is only achievable if the hardware team evolves its design and verification methodology to encompass SystemC TLM.

Michael (Mac) McNamara is VP and general manager of system-level design at Cadence Design Systems. In the early 1990s, he helped start Chronologic, which brought compiled Verilog simulation to the world; thereafter, he cofounded SureFire Verification (which became part of Verisity) to improve the state of verification software. After Cadence acquired Verisity, Mac led the effort to improve high-level design, and currently manages Cadence’s C-to-Silicon Compiler and Virtual System Platform product lines.

Cadence Design Systems 408-348-7025 • mcnamara@cadence.com Linkedin: www.linkedin.com/company/cadence-design-systems Facebook: www.facebook.com/pages/Cadence-Design-Systems-Inc/66598923031 Twitter: @Cadence www.cadence.com

Approaches and tools for FPGA mixed-signal integration

Allan Chin, Stellamar — Tue, 06 Dec 2011 15:00:00 +0000

As FPGAs become more popular in the electronic design community, the approaches and tools used to integrate analog functions such as ADCs with these digital chips must be refined. Customer demand for high reliability, small footprint, and low power means that engineers have few choices and must look outside the box in their approach to mixed-signal integration with FPGAs.

FPGAs have exploded in popularity in recent years due to their relative low cost and high performance for digital signal processing tasks. The advantages of digital processing, reprogrammability, and variable cost structure have fueled this fast growth. Ironically, as the world has gone “digital,” demand for analog chips and components to grab continuous, real-world data has also risen quickly. As the breakeven unit decision between FPGA and ASIC continues to narrow, one large challenge continues to exist: For the FPGA market to continue growing, digital engineers need robust tools and effective solutions to integrate mixed-signal functions in their digital designs.

Three approaches generally exist for integrating Analog to Digital Converters (ADCs) with FPGAs: external off-the-shelf components, “mixed-signal” FPGAs, and digital ADC implementation. The traditional approach is to add off-the-shelf external ADC components. FPGA manufacturers responded to market demand for analog functionality by introducing “mixed-signal” FPGAs with ADCs in the packaged device. These mixed-signal FPGAs have significant advantages and a few drawbacks (really, when do we engineers ever get exactly what we want?). A third approach, which can fill in the gaps for many applications, is to use a digital ADC IP core to implement ADC functionality directly in the digital fabric of an FPGA. All three approaches are significantly different and require different flows and tools for effective integration.

The external components approach

The traditional integration of ADCs with FPGAs requires external parts. The process involves sourcing and selecting the proper component from an analog parts vendor and understanding how that component will affect size and power budgets. Tradeoffs exist between size, power, and performance. For many applications where size and power are not an issue, this approach works very well. Mixing and matching parts can be an easy way to meet cost budgets for projects that do not require strict optimization. Additionally, for very-low-volume applications, this may be the best approach as many simple ADCs are low cost. However, with the drive to low-power, portable, and high-reliability electronics in consumer, military, medical, and aerospace applications, there is room for improvement. In these markets any external connection point is a possible point of failure, so decreasing external part count would be very valuable. Lastly, for these same markets, system certification or recertification is an issue due to possible discontinuation of a part by a vendor. Certification requires significant resources to be achieved, and is easiest if done only once. In space exploration, this can be of particular concern.

Tools for external part verification

Verification at the PCB level can be divided into two arenas: small designs below 50 MHz operation and complex designs above 50 MHz. Smaller designs below 50 MHz can be verified using interface timing diagrams and a scope. The higher-speed designs require simulation tools such as HyperLynx[1] from Mentor Graphics, which is capable of board-level verification, signal integrity, and other features. Like all simulators, board-level simulators also require good models. Most ADC part vendors provide models with their semiconductor devices. However, when an FPGA design is involved it takes additional time and resources to generate the cycle equivalent model(s) for the FPGA to support PCB simulation. No matter the size, speed, or complexity of the PCB design, using a CAD tool like HyperLynx will verify and validate signal integrity and ensure faster design times.

The “mixed-signal” approach

FPGA vendors have done a good job of responding to the market’s need for ADC inte-gration. Xilinx and Microsemi have great approaches to covering the broad market. By placing one or two 500 KSps or 1 MSps ADCs in the package most applications are covered. These packages are more reliable than the external components approach, and have a smaller overall footprint. These mixed-signal FPGAs naturally command a price premium over other FPGA families for providing packaged ADC functionality. Depending on the product strategy and cost structure, the price premium may be well worth paying. For instance, if the product strategy is to constantly lead in terms of performance, it probably also commands a price premium, and the unit costs may not be that big of a deal. On the flip side, if it has a “continuous cost cutting” strategy, living with this approach may be required until needs can be met more adequately.

Customization is not much of an option in this approach. ADC resolution, sample speed, and number of channels are generally fixed by the vendor. This allows FPGA vendors to support a large swath of the market, but may come at the expense of the power budget. For example, running a voltage measurement at 1 MSps is like using a sledgehammer to drive the head of a pin. The extra speed will negatively impact the power budget. Complex designs these days can require upwards of 48 measurement channels. With mixed-signal FPGAs, adding external analog multiplexers or more mixed-signal FPGAs is the only solution to accommodate the number of channels.

Mixed-signal FPGA simulation and verification tools

Currently, FPGA tools for true mixed-signal simulations are not available. ModelSim[2], however, does support mixed languages such as Verilog, VHDL, and Verilog-A. Depending on the complexity of the analog portion of the design, ModelSim can be used to validate functionality at the mixed-RTL level. A mixed-signal simulator should be used to determine analog performance. However, to determine actual performance a true mixed-signal simulator should be used, such as Mentor ADMS[3] or Cadence AMS[4]. They will also require accurate SPICE models to determine performance, which might be difficult to obtain. Both methods take simulation time or functionality, and more simulation time to determine actual performance.

Digital implementation approach

Some “analog” functions can also be im-plemented using only the digital fabric of an FPGA or ASIC. A crude scheme can be worked up by using an LVDS and small set of resistors and capacitors (Figure 1). Several white papers from Xilinx, Lattice, and others exist on the topic. These papers show resolutions of only 8-9 bits while requiring very high clocks to achieve that performance. Additionally, error rates have been shown upwards of 15 percent.

Figure 1: Some analog functions can be implemented using an FPGA or ASIC digital fabric, shown here using an LVDS and a small set of resistors and capacitors.

External ADCs are unnecessary because a digital ADC is embedded in the FPGA fabric. The removal of external parts lowers board space, and the digital architecture and slower clocks lower power consumption over a comparable analog ADC. Testing is made easy by using the digital test methodology available from any FPGA vendor. These cores can be made rad hard/tolerant by using a rad-hard-tolerant FPGA.

Despite these many advantages, the generic digital ADC technique is severely limited in resolution and bandwidth. This approach will generally not work for applications requiring MHz bandwidths, such as RF communication, as those bandwidths are much more difficult to achieve with digital resources. Here, the external parts approach and perhaps the mixed-signal FPGA approach hold the advantage for those applications.

Through proprietary signal processing, Stellamar can achieve digital ADC performance upwards of 14-bit resolutions and 100 kHz bandwidth with error rates of less than 1 percent and no temperature drift. This method works for applications spanning DC measurements, temperature, touch, acceleration, motor control, audio, and some optical networking tasks. Stellamar works with Xilinx and Microsemi to provide Digital ADC IP cores to engineering teams that require a customized combination of low power, small size, and high reliability, and currently works with aerospace companies on satellite builds and with consumer electronics companies looking to reduce part count to lower cost and increase reliability.

Tools for digital simulation

Current FPGA tools are quite adequate to perform all digital simulation with an embedded digital ADC. This provides a level of certainty at the RTL and gate levels to the entire design before configuring an FPGA. This verification and validation is achieved by using any Verilog simulator supplied with the standard FPGA toolkit, which is ModelSim in most cases. Since a digital ADC is described in Verilog or VHDL, any FPGA can be targeted without the need for additional models other than the supplied FPGA digital library. With the added flexibility of reprogramming and the availability of different-sized FPGAs, designers can optimize not only the system by defining the exact ADC requirements, but also the power and board. A typical FPGA design flow starts with the instantiation of the digital ADC IP into the design. Then the entire design is synthesized to the FGPA gates using the tool provided with the FPGA toolkit. Post-place and route gate level timing simulation is usually performed with the provided ModelSim simulator to perform an all-digital simulation. This validates the gate level implementation of a mixed-signal design without the need of a mixed-signal simulator.

Reintegrating analog and digital

The growth of the FPGA market for high-reliability and low-power applications hinges on better integration of “analog” with “digital.” Three approaches for implementing ADCs with FPGAs are available. External components can be easy to use but occupy more board space. Mixed-signal FPGAs are easily accessible and offer great performance, but are technology-dependent, more expensive than standard FPGAs, and are limited in array size. Embedded Digital ADC cores are technology-independent and offer a migration path to ASICs, use digital testing, and are optimized for size and power; their main drawback is a limitation on bandwidth.

From a system perspective, the mixed-signal FPGAs and embedded Digital ADCs are best for systems that require certification, such as medical, consumer, and military devices, as they remove the possibility of a system change due to end-of-life of an external ADC.

Good mixed signal integration starts with understanding what signals are being measured and what is required to measure those signals. Once requirements are accurately established, an approach can be selected. No matter which method is used, a PCB simulation should be run at the board level in all cases. The ability to use a Digital ADC core can simplify the design integration and validation of an FPGA-based mixed-signal design.

Each approach and tool set have real value to the engineering team, but each have their drawbacks. Looking to the future, more analog functions such as power management and clocking will be able to take advantage of digital tool sets for modeling and testing.

References

Mentor Graphics HyperLynx: http://www.mentor.com/products/pcb-system-design/circuit-simulation/hyperlynx-signal-integrity/
ModelSim: http://model.com/
Mentor Graphics Mentor ADMS: http://www.mentor.com/products/ic_nanometer_design/events/adms_mixed_signal_workshop
Cadence AMS: http://www.cadence.com/products/pcb/ams_simulator/pages/default.aspx

Allan Chin is CEO at Stellamar and has more than 30 years of design experience with high-performance digital and mixed-signal systems. His broad expertise covers many areas of IC design, including system requirement definition, chip development, mixed-signal simulation, verification, prototyping, and lab testing. Allan has a B.S. in Electrical Engineering from Marquette University, Milwaukee, Wis., and holds nine patents. Allan can be reached at allan.chin@stellamar.com

Stellamar info@stellamar.com www.stellamar.com

Virtual or real: Prototyping platform(s) for ARM-based FPGA design

Mike Demler, Editorial Director — Tue, 06 Dec 2011 15:00:00 +0000

SoC FPGAs offer both hardware and software approaches to platform prototyping, each of which confronts different challenges of the hardware-software codesign process.

New developments in DSP design

Michael Parker, Altera Corporation — Tue, 06 Dec 2011 15:00:00 +0000

Modern FPGAs feature advanced DSP blocks and DSP resources that support a high degree of data processing and throughput. The challenge is to develop a high-level design flow that allows designers to
unleash the DSP capabilities of FPGAs. There have been several recent developments in DSP tools that have enabled the FPGA industry to excel in design productivity, reusability, fixed and floating point circuitry, and sheer computational throughput.

Many applications demand more DSP performance than DSP processors can deliver, such as radar, wireless, and broadcast video systems. To service these, an alternate technology has become prevalent: the FPGA. FPGAs grew out of their simpler CPLD cousins, and quickly grew in size and I/O capabilities. Once multipliers were introduced into the FPGA logic fabric, they became powerful DSP platforms. FPGAs soon contained hundreds and then thousands of multipliers. The multipliers morphed into DSP blocks that contained special circuitry to support FIR filters and FFTs. But the key advantage was the sheer degree of parallelism offered by FPGAs, which could not be replicated by DSP processors; high-end FPGAs contain billions of multiply accumulates per second compared to DSPs.

FPGAs are programmable hardware, and, with some exception, tend to have fairly static hardware configurations within any given design. The data processing tends to resemble a manufacturing assembly line, where each programmable circuit is configured to perform a specific function. This leverages the massive parallelism properties for the FPGA. This also leads to a different sort of design flow using hardware languages Verilog and VHDL. These languages describe the operation of the hardware at a fairly detailed level. They also accommodate the much higher degree of freedom offered by FPGA designs. In contrast to processors, the FPGA designer can use custom word widths tailored to the needs of the algorithm at each stage of processing. FPGAs offer thousands of memory blocks, allowing for easy storage of interim data states without the bottleneck of a single or few memory buses and interfaces used in processor architectures.

However, this degree of freedom tends to also make FPGAs more difficult to program, akin to DSPs in the assembly language era. Efforts have been made to develop C compilers for FPGAs, but they have had limited adoption to date. The developers of these “C-to-gates” tools face the challenge of describing parallel hardware architecture using a software language that is aimed at serial processing. When modifications are made to the software language to allow the designer to describe this parallelism, it tends to work against the inherent ease of use and familiarity of the programming language. Another challenge, similar to that experienced with DSP processor C compilers in the past, is being able to achieve the same level of FPGA efficiency and performance possible for designers using HDL languages Verilog or VHDL. Achieving the same level of performance with a high-level design flow is much more challenging than with DSP processors, again due to the many degrees of freedom offered by the FPGA architecture. Several recent developments in DSP tools can address these challenges of FPGA design, including model-based design and matrix processing.

Model-based design

An alternative FPGA design flow called model-based design utilizes MathWorks’ Simulink environment. The appeal of Simulink is that it understands the concept of clock cycles and allows for the description of hardware architectures, yet provides the fully integrated environment of MATLAB and Simulink to perform modeling and simulation of both the test bench and the system under development. Product offerings from Altera, MathWorks, and Xilinx allow development of FPGAs using an integrated tool flow where the designer operates largely within the MathWorks tool environment. The Altera and Xilinx Simulink-based tool flows naturally allow the designer to target only their respective FPGA products, while Simulink HDL coder allows the designer to target Altera or Xilinx FPGAs, or generic hardware for ASIC designers.

The various Simulink design flows tend to mimic the same techniques used in Verilog and VHDL. The designer specifies fixed-point word widths for each operation, determines the number of register delays or pipelining at each stage of the design, and utilizes local memory structures of various widths and depths. The tool output then passes to the FPGA vendor’s synthesis and place and route tools, after which the circuit Fmax and logic resource utilization can be determined.

Automating optimization

To introduce additional capability, another alternative allows the designer to describe what they want to do at an algorithmic level, and automate the many levels of optimization required to achieve high performance in an FPGA rather than trying to describe the design at the same level as HDL languages. For example, take a simple adder circuit. Normally, the designer needs to determine how much to break apart the adder chain and how many levels of pipeline registers need to be inserted. Within the Simulink environment, the designer describes an adder of any length (number of bits), the FPGA family used, and the Fmax at which the design is to run. The tool has access to all device timing details, so it can decide how much to break the adder chain and insert pipeline register stages in order to meet the designer’s Fmax requirements. This process is repeated throughout the entire design and frees the designer from the tedious process of optimizing the design to the latest device features or pipelining to meet the required clock rate (known as closing timing). This works well for small designs, such as individual FIR filters that can run at over 450 MHz, and large designs that can typically operate in excess of 350 MHz, which is on par with skilled HDL designer results. This results in a high degree of design portability and even “future proofing” of designs. The design itself is not optimized for a particular FPGA, but the tools can target a design for low-cost, mid-range, or high-end FPGAs (with allowances for reasonable Fmax). It will also allow a design to be optimized for future device families and features that do not exist today.

Multiple channels, folding, and polyphasing

Another development is the ability to perform multiple channels on any algorithmic datapath in a parameterizable way. The tool will automatically schedule the different channels to share resources and generate the necessary control logic. In fact, multi-channel often benefits the tool, as the multiple channels allow further pipeline registering to be done using the interleaved register delays necessary to accommodate the multiple channels, particularly for recursive designs. Folding, or use of the same resource for multiple operations within the same data stream, can also be performed as needed to reduce logic and multiplier resources. The contrasting technique, known as polyphasing, can be performed automatically, which allows the FPGA to interface to data convertors operating at multiple Giga Samples per second (GSps).

Floating point circuits and matrix processing

The ability to generate floating point circuits is one of the most significant advances now available to FPGA designers. Traditionally, FPGAs are not used for computing algorithms and linear algebra applications, as the tools and IP available were inefficient and too low performance. The dynamic range and numerical fidelity of floating point were simply not available to FPGA designers. This advance in FPGA tools changes this paradigm by offering high-performance floating point processing across a design in the largest FPGAs.

One of the biggest applications for floating point in FPGAs is matrix processing. Support for vector data types is available, allowing the designer to manipulate and perform operations upon entire vectors rather than describing each element in the vector. For example, a large floating point vector dot product, which is the fundamental building block of many matrix algorithms, can be described simply in a couple of multiply and add blocks.

DSP Builder from Altera Corporation allows designers to build their own matrix processing cores, which at runtime can support various sizes of matrices. BDTI, a DSP benchmarking company, recently evaluated this tool for high-performance floating point designs. The Cholesky decomposition, including forward and backward substitution processing, was chosen to demonstrate both design methodology and performance. This is commonly used for matrix inversion, particularly for a large class of problems utilizing covariance matrices.

Further benchmarks have been developed using 28 nm FPGAs, showing that six matrix inversion cores, each performing 3,000 matrix inversions (technically Cholesky decompositions) per second upon a [240 x 240] matrix can be implemented within a single large FPGA. This is an aggregate of 18,000 [240 x 240] matrices per second per FPGA. For smaller matrices, such as [20 x 20], a single FPGA can process up to 18,000,000 [20 x 20] matrices per second.

A designer might not need that level of performance, but, for instance, a radar application might need a throughput of 6,000 [240 x 240] matrix inversions per second, which would consume about one- third of a large FPGA’s resources. The remainder of the FPGA could be used for other functions, such as pulse compression, Doppler processing, and covariance matrix estimation. All of these can be implemented in the same FPGA, using a mixture of fixed or floating point processing as required. This alleviates many of the current data flow bottlenecks in complex systems such as modern radar.

On the path to a better DSP tool future

DSP chips now support both floating point and fixed-point circuits, so designers don’t have to choose between high-performance fixed-point DSP chip families or lower-performance floating point DSP families as they have in the past. DSP tools have also come a long way and will continue to evolve. Eventually, many expect that C or software-based descriptions of hardware architectures such as FPGAs will become competitive and ubiquitous. But today, recent design tool developments utilizing Simulink have hit the high water mark for design productivity, reusability, fixed and floating point circuitry, and sheer computational throughput.

Michael Parker is DSP Product Planning Architect at Altera. He joined the company in January 2007 and has more than 20 years of DSP wireless engineering design experience. He holds an MSEE from Santa Clara University, and a BSEE from Rensselaer Polytechnic Institute. He authored a book entitled “Digital Signal Processing 101,” published in 2010, and has published more than 20 technical articles on DSP, radar, and floating point.

Altera Corporation mparker@altera.com www.altera.com

EE Daily News 20-page special report reviews the EDA/IP exec panel at GTC2011

Mike Demler, EE Daily News — Thu, 10 Nov 2011 15:00:00 +0000

The 2nd annual GLOBALFOUNDRIES Technology Conference (GTC), held in Santa Clara – CA on August 30, provided a rare opportunity to hear from leaders of each of the three largest EDA companies, along with the CEO of the largest semiconductor IP company, gathered together on the same stage to discuss a wide range of issues that will impact the future direction of the electronics design ecosystem.

FPGA design tools: Misconceived and missed opportunities

Jeff Jussel, Newark/element14 — Wed, 02 Nov 2011 15:00:00 +0000

A recent post in John Cooley’s DeepChip bemoaning the demise of FPGA-based tool startup GateRocket ends with a familiar refrain: “It doesn’t pay to make EDA tools for FPGA because engineers are too used to getting the tools for free from the FPGA vendors”. Setting aside the fact that some EDA companies do very well selling tools to FPGA designers, using the “FPGA tools are free” excuse in the case of GateRocket misses the lesson to be learned here, and fails to recognize an even bigger opportunity.

As a service to all future entrepreneurs tempted to try their hand in an FPGA tool startup, and on the chance to stir up some interesting conversation for the rest of us, I put forward the follow points of advice for my fellow FPGA aficionados. These points highlight the real issues facing small EDA tool companies.

First point – Know your market. It seems obvious, but you would be surprised how often companies get caught up in cool technology and miscast the end user for the product. Was GateRocket a tool for FPGA designers? The Rocket Drive used FPGA devices to accelerate logic simulation. But the end users for this type of acceleration are typically chip designers that need to speed up large runs. FPGA designs are easily programmed and tested on the actual devices. So the real competition for GateRocket in the FPGA community would not have been free tools. So instead of targeting FPGA designers, GateRocket’s tool was aimed at chip designers. But the market for ASIC design is getting smaller each year and the competition from things such as fast simulators or hardware emulators is fierce. Development prototypes would have the advantage.

Second point – the big opportunity for FPGA growth is in processing. While the chip design market is shrinking, the software content in embedded systems, and the corresponding number of software engineers, continues to grow. Some estimates peg the number of software engineers at more than 10x the number of their hardware counterparts. What all of these software engineers are looking for is faster processing. Where faster processors used to be a given in each new generation, extra speed now comes from parallelization of application processing – something that FPGAs do exceedingly well. The company that finds a way to help software engineers tap into FPGA devices as processors will have access to a huge and hungry market.

The lesson from GateRocket is that new and innovative technology is not enough. A tool startup needs to find ways to apply that technology to the large, emerging market and stay focused there. In the case of FPGA design, that emerging market is in software acceleration. There are already big segments of the high-performance computing market using FPGA processing in areas such as financial analysis, energy exploration and life sciences. As more software developers become aware of the processing advantages for FPGA, the embedded market will also start to demand FPGA tools that can support them. When that happens there will be a big market for FPGA design tools and the FPGA vendors will welcome and support the company that provides the technology to open that door.

Jeff Jussel is an EDA industry veteran with more than 21 years experience in electronic design serving in engineering, sales, marketing, and management roles. He has recently moved into a new role and is currently Senior Director of Global Technology, Newark/element14.

FPGA verification must address user uncertainty for prototyping, system validation

Loring Wirbel, Footwasher Media — Wed, 26 Oct 2011 15:00:00 +0000

The recent expansion and diversification of the FPGA verification market bears a certain resemblance to the ASIC verification market of 20 years ago, though beset with opposite challenges, thanks to the changes wrought in 20 years by Moore’s Law. When companies such as Quickturn Systems created large logic emulation systems to verify ASICs in the early 1990s, users had to be convinced to spend significant amounts of money while dedicating floor space equivalent to a mainframe, all to verify system ASICs. Today, FPGA verification can be addressed in add-in boards for a workstation, or even in embedded test points within the FPGA itself.

But even as customers in 1990 were reticent to move to logic emulation due to price tags, today’s FPGA verification customer may show some trepidation because such systems may seem simplistic, invisible, or of questionable value. In many cases, however, FPGA users dare not commit to multiple-FPGA systems (or to ASICs prototyped with FPGAs) without these tools. Newer generations of FPGAs, incorporating the equivalent of millions of gates, integrate RISC CPUs, DSP blocks, lookaside co-processors, and high-speed on-chip interconnect. Verification of such designs is a necessity, not a luxury.

On the software-only front, all major FPGA vendors, as well as three of the major EDA suite vendors, offer “Design for Verification” tools that tie behavioral simulation to system-level test and test regression analysis. While such tools are useful, at some point they must be combined with dedicated hardware that can tie specific FPGAs to system-level requirements.

The notion of an add-on card is the easiest conceptual hurdle for many designers to address. This can take the form of anything from a module that integrates an FGPA to that of a solid-state drive. However, the FPGA design community still must adopt a better feeling as to how FPGAs can aid in their own verification if they hope to have effective innovation available soon.

Products for characterizing SoCs are combined with synthesis language and IP libraries to give the designer an easy-to-configure platform for testing hardware ideas. What began as a means of prototyping other silicon devices has become a way to validate the FPGA itself, an indication of how the FPGA verification market can be used in bootstrapping a next-generation FPGA based on known designs.

Embedded instrumentation potentially can take designers to the next step by embedded hardware test points within their FPGAs or ASICs. The idea has been used in the past for testing chip designs through I/O pads, a concept that gave rise to the military JTAG standard. This idea is extended to FPGAs by using test points for verifying not only individual FPGAs, but the behavior of systems employing multiple FPGAs.

Since the newest generations of FPGAs incorporate millions of equivalent gates, embedded instrumentation may soon be necessary. At a minimum, however, FPGAs offering multiple asymmetric cores processing complex data sets in real time will require multiple complementary software and hardware verification tools to ensure first-pass design success.

Loring Wirbel is a technology analyst with more than 20 years’ experience covering semiconductors, communications, embedded software, and any other topics that catch his fancy. In addition to his freelance work he contributes to several political and cultural journals and web sites.

FPGA design tool vendor GateRocket has ceased operations

Mike Demler, EE Daily News — Fri, 26 Aug 2011 15:00:00 +0000

There is no word yet regarding an acquisition of GateRocket’s assets, but the tools could be valuable to both Xilinx and Altera should they be interested in picking them up.

Show me the money – the valuation of Apache Design Solutions

Mike Demler, EE Daily News — Fri, 26 Aug 2011 15:00:00 +0000

The EDA industry has seen some recent acquisition activity, including the ANSYS purchase of Apache Design Solution.

Nanometer Circuit Verification Forum to follow CICC

Mike Demler, EE Daily News — Fri, 26 Aug 2011 15:00:00 +0000

On September 22, immediately following the conclusion of the IEEE Custom Integrated Circuits Conference, BDA (Berkeley Design Automation) will be hosting a “nanometer Circuit Verification Forum” at the TechMart in Santa Clara, CA. In past years, the day after CICC had been reserved for the BMAS (Behavioral Modeling and Simulation) Conference, which ceased operation after the 2010 event.

Platforms continuum for system realization

Ran Avinun, Cadence Design Systems — Thu, 05 May 2011 15:00:00 +0000

Ran imagines the impact on true system realization if the spotlight turns toward an integrated, user-friendly flow for hardware/software development.

The electronics industry is moving from being hardware-defined to being system-defined, while electronic products become increasingly application-driven. As a result, product differentiation has shifted to system (software-based) content, while hardware platforms and their development processes become more and more commoditized. Seizing new opportunities in this emerging segment requires expanding upon the foundations of the electronics industry. The needs of system developers must be addressed, and the responses to those needs must be integrated into a single solution.

The potential risks involved with schedule delays and product quality have become vast. Time-to-market pressures and the trend toward software-defined product functionality make the traditional sequential process, where System-on-Chip (SoC) development is followed by board and device development and then by software development, obsolete. Meeting functionality, power, and performance as system bring-up occurs has become the most challenging task. System bring-up consumes one-third to one-half of the overall development cycle for many OEM companies, with product quality and predictability becoming the second and third priorities. System bring-up is a top OEM executive concern, as it can make or break the profitability of their products.

If you have participated in the debate over system realization, your questions likely go something like this:

What is the best approach to system-level validation?
Should we invest in the promise of faster virtual platforms while dealing with their inherent timing inaccuracy?
Is the FPGA-based prototyping approach – with its low cost but long bring-up time – enough to get the job done?
Should we rely solely on system emulation or simulation acceleration?
How can these technologies be leveraged to enable collaboration with our IP suppliers and customers?

In the past 15 years, I have participated in dozens of panels and roundtables where such questions were raised. The answers largely depended on the responsibility of the specific person in charge or the offerings of his or her company, with some people changing their answers when they changed companies. Over the years, we (at Cadence) realized that the specific product being offered is not as important. What is important is the value the customer gets and the resources, time, and money they need to spend. We have also realized no one product or platform can solve all system verification and validation problems. A combination of multiple platforms is required.

Is the biggest challenge to successfully completing your next-generation design avoiding silicon re-spins, getting the ever-increasing amount of software done on time, or finding ways to validate the interaction between hardware and software?

Many verification teams use an ad hoc portfolio of technologies and disjointed environments and platforms to the point where they can’t get the job done. To keep pace with the demands of advanced system development, the traditional approach simply isn’t productive enough. Verification throughput is failing to satisfy the requirements of today’s increasingly complex designs. Based on recent discussions with verification teams of large and complex systems, finishing complex verification tasks using Register Transfer Language (RTL) simulation no longer works. What’s needed is a high-performance environment suitable for hardware verification, low-level firmware, and software development within a system context throughout the design process.

The big picture solution must deliver a unifying flow that offers users a familiar environment able to maximize and expand the simulation capabilities for both subsystem and system-level simulation. The environment and the performance need to be appealing and attractive for system, software, and hardware verification teams. Cadence envisions a flow that combines open, connected, scalable, and best-in-class hardware/software platforms, including hardware-assisted verification and software-based tools. The integrated flow will need to break new ground in delivering scalable usability for both design-team and enterprise-class customers, connecting design and verification flows throughout multiple levels of abstraction, offering high performance and a flexible modeling environment. Imagine what you can do with an integrated flow for system realization.

Business pain points

Time to market is the number one challenge of system developers and system companies. Companies (especially in the consumer market) are under pressure to meet their market window and to reduce their overall design cycle from 12 to 6 months. These firms need to be able to communicate and interact efficiently with their suppliers and partners with predictable schedules. CEOs want to embark on revolutionary paths to transform their organizations from chip or IC makers to system companies.

During this transformation, company leaders need to integrate their hardware and software teams into one. An approach of developing standard products that serve and win specific applications in the market will give way to hitting the market at the right time while meeting the specifications. At the same time these forward-looking companies will be collaborating with partners who are generating content (Facebook, Google, Netflix, and similar organizations or operators such as AT&T, Comcast, and Verizon). As a result, electronics industry players are at high risk to miss their market window unless they will change the way they develop systems. Figure 1 shows the potential revenue loss risk as a result of missing market windows in slow, medium, and fast market segments. A six-month delay could cause an average loss of $50 million.

Figure 1: The perils of not hitting the market at the right time grow as markets move faster. (Source: IBS)

(click graphic to zoom by 1.9x)

Technical pain points

As system design complexity (think multicore, multithreading, multitasking, and rapidly increasing software content) grows, it becomes more challenging to meet application-driven requirements. A key challenge is shifting from chip tape-out to time to market. System hardware/software bring-up and integration are key bottlenecks. Current offerings meant to loosen these bottlenecks are on proprietary instrumentation, employ nonconfigurable models, and aren’t easily ready to plug into third-party tools. What’s more, these products are fragmented, with disconnected point tools that leave the burden of integration and migration from one development phase to another to the users. And these offerings limit themselves to solving just a single level of abstraction.

The customers’ ideal is a single platform that can address all their needs. Unfortunately, no single hardware/software development platform can address all design phases. Therefore, a single solution/flow based on a combination of multiple platforms is required. Each platform focuses on each phase of the flow with different optimized characteristics.

For example, early in the design users require a platform that can run their software on top of an abstract model of the hardware. Later on in the process they need to run their software on top of an accurate representation of the hardware. Customers spend months and many dollars migrating manually across platforms. They need a continuum set of open and connected platforms. The open platforms selected should be standard-based and have third-party support. Connected platforms should have integrated offerings, methodology, and flow to allow users to migrate automatically from one platform to another. Successful platforms will support the hardware/software verification and integration process throughout the flow with scalable performance and capacity to support multiple levels of abstraction.

A comprehensive set of open, connected, and scalable platforms for system realization

Cadence addresses the technical challenges mentioned earlier through the development and delivery of a comprehensive set of hardware/software platforms called System Development Suite. The suite is open, connected, and scalable with a strong ecosystem partnership, services, and an integrated methodology. Building on its industry-leading offerings in advanced verification and acceleration/emulation, this continuum creates in the market an approach to address the key system development challenges. As seen in Figure 2, this approach includes four hardware/software platforms with performance trade-offs. Although all these platforms enable validation and integration of hardware and software, some platforms focus more on hardware validation and verification, while others target higher performance for software developers. Although all the platforms can participate throughout the whole design process, each platform is optimized to serve users at different phases of system development.

Figure 2: Design teams need an integrated set of platforms optimized to discrete development stages to meet time-to-market objectives. (Source: Cadence Design Systems)

(click graphic to zoom by 1.9x)

Each platform is uniquely connected to the next one in order to speed up the bring-up time of the hardware/software environment as users migrate from one development phase to another.

Virtual System Platform

The Virtual System Platform’s tools for system developers help them to create and analyze virtual platforms/prototyping. Software developers gain a platform to run their software on top of abstracted models for early software development and software distribution. It is open (standard-based) and delivers scalable performance and superior hardware/software debug capabilities. It connects to the Incisive Verification Platform through a unified simulator and common verification IP.

Incisive Verification Platform (with Incisive Enterprise Simulator)

This platform’s advanced verification tools address block/chip-level verification based on an open methodology (UVM) with a rich portfolio of optimized verification IP that can be extended to other platforms. It helps verification engineers bring up the firmware and provides hardware/software metric-driven verification capabilities that also work with the Virtual System Platform and the Verification Computing Platform.

Verification Computing Platform (Palladium XP)

Users will find cycle-accurate system validation (emulation) and acceleration capabilities with scalable capacity and performance available with this platform, which includes hardware/software debug capabilities. This platform is open, provides fast bring-up and turnaround time, and delivers low-power verification and analysis as well as metric-driven verification capabilities. It is connected to the Incisive Verification Platform through hot swap, common debug, runtime, compile, and verification IP.

Rapid Prototyping Platform

The FPGA-based Rapid Prototyping Platform serves as a cycle-accurate software development platform with the ability to connect into real-world interfaces in order to run exhaustive regressions. It allows distribution of multiple, affordable prototypes to software developers. It is open, supports standard-based ASIC flows, and provides scalable bring-up and debug with a high level of accuracy. Together with the Verification Computing Platform, the combined solution provides common compile flow, SpeedBridge adapters, and powerful debug.

Summary

The electronics and semiconductor industries have undergone a major shift in the past decade, where software has eclipsed hardware as the main driver of system development cost, schedule, and risk.
System integration time is the main challenge of system developers and system companies.
Current offerings in the market are closed, fragmented, and limited.
To address system development cost, schedule, and risk challenges a comprehensive set of open, connected, and scalable hardware/software platforms that accelerate the migration from one platform to another is required.

Ran Avinun is the product marketing group director for System Design and Verification at Cadence Design Systems. He has served Cadence in the past 12 years in senior marketing management positions with a focus on hardware-assisted verification and the ESL market segments. He has 23 years of experience in the EDA and semiconductor industries. Ran also worked at Quickturn, inventor of In-Circuit Emulation (later acquired by Cadence), and Chip Express (a fast ASIC prototype manufacturer) in engineering and marketing roles. He began his career as an application engineer with Daisy Systems. Ran holds a BSE and MSE in Electrical Engineering from the Technion and Tel Aviv University in Israel and an MBA from the University of Phoenix in California.

Cadence Design Systems ran@cadence.com www.cadence.com

EDA Consortium: Accomplishing together that which we cannot do as individual companies

Robert Gardner, EDA Consortium — Fri, 12 Nov 2010 15:00:00 +0000

This quick overview of the EDA Consortium’s main efforts illustrates key issues where cooperation helps both customers and vendors add value and drive the next big things in electronic design automation.

The Electronic Design Automation Consortium (EDAC) is the international association of companies developing EDA tools, software, services, and semiconductor intellectual property. Founded in 1989, EDAC addresses issues of common concern to EDA vendors. While initial efforts were focused on trade shows, EDAC efforts have expanded to include many areas where cooperation benefits both the EDA industry and customers.

The EDA industry includes three large companies, some medium-sized companies, and a number of smaller companies. Combined, the three large companies have about a 70 percent market share, with each having a dominant position in at least one subcategory of EDA tools. This suggests many designers are using tools from multiple vendors, creating a best-in-class design flow based on each vendor’s strengths.

Much of EDAC’s work is done by the operating committees, which consist of experts from member companies who dedicate part of their time to serve the overall good of the industry.

Working for fair competition

One of the more active EDAC committees is Anti-Piracy. Not long ago, it was the “collective wisdom” of the industry that EDA software was too complex and required too much support for software piracy to be a significant issue. More recently, the industry began to see evidence that this might no longer be true. The EDAC Anti-Piracy Committee worked with various anti-piracy vendors to evaluate the impact of piracy on the EDA industry. The committee selected a representative sample of EDA software from a number of members for an in-depth analysis in an attempt to gain a clearer understanding of the impact of EDA software piracy.

They found that EDA software piracy rates are about the same as other software products and represent a significant impact on EDA vendors and their customers. A design house using a pirated version of one vendor’s software will not buy equivalent software from any of the vendors, regardless of the merits of the software. Furthermore, legitimate customers can find it difficult to compete against a design house with lower costs because they are not paying for their tools, resulting in decreased R&D budgets. Thus, pirating even a single EDA vendor’s tools affects the entire industry. This is a major area where cooperation amongst vendors helps each company compete fairly based on the merits of their products.

Roadmaps and segments

Other EDAC committees include the Interoperability Committee, which publishes an industry OS roadmap. Agreeing to support, at a minimum, a core subset of the available OSs and versions reduces development costs within EDA companies and decreases support costs in the customer’s development environment.

The EDAC Market Statistics Service (MSS) Committee publishes a quarterly report containing a detailed view of EDA industry revenue broken out by tool categories and geographic regions. Using revenue data collected confidentially from members and nonmembers, the MSS report (available by subscription) provides EDA companies, investment bankers, and analysts with a detailed look at trends in many areas of specialization within EDA.

These are just some examples of the work being done by EDAC to benefit the EDA industry, allowing members to focus on and deliver quality EDA tools.

Robert Gardner has been an executive director of the EDA Consortium since 2006 and an officer/member of the board for more than 14 years. He has more than 40 years of management, engineering, operations, and sales experience, and has held executive management positions at several EDA and semiconductor companies. He holds a BSEE from California Polytechnic State University, Pomona.

EDA Consortium 408-287-3322 www.edac.org

New paradigm speaks volumes for Knowles MEMS microphone design

Pete Loeppert, PhD, Knowles Electronics — Fri, 12 Nov 2010 15:00:00 +0000

Ever wonder what that microphone in your smartphone looks like? Or how it’s designed? Electronic design automation tools have made microelectromechanical systems components like surface-mount microphones more efficient, compact, and innovative.

Jeremie Bouchaud and Richard Dixon, analysts at iSuppli, refer to Microelectromechanical Systems (MEMS) microphones as “one of the great success stories of MEMS.” By outperforming Electret Condenser Microphone (ECM) technology in size, scalability, and ease of assembly characteristics, it’s no wonder the MEMS microphone market is expanding from about $100 million in 2006 to a projected $300 million in 2013.

Traditional microphone technology has not kept up with market demand and is becoming a stumbling block as demand grows. Previously, microphone suppliers would stack up individual components and assemble microphones one at a time. Most are cylindrical, about 6 mm in diameter by 1-2 mm high, and inexpensive enough to be deployed in a range of applications from phones to toys. The problem is traditional microphones are heat-sensitive, which precludes the use of lead-free solder and the option for surface-mounting into circuits. So, to work around microphones’ intolerability of high temperatures or reflow soldering, most manufacturers of high-volume products resort to an offline task, such as hand assembly or a special insertion machine, at the end of the mainstream assembly line.

Mounted for sound

Knowles has overcome the problems of ECM technology with the SiSonic MEMS microphone, which is batch-produced on silicon wafers and assembled like an integrated circuit except for an air pocket that allows sound waves to vibrate the diaphragm. An outline of the air pocket is shown in Figure 1. The SiSonic is reflowable, so an assembler can place it on a circuit board with a chip insertion machine, just like any other component. Microphones that can fit in with the normal assembly flow help reduce production cycle time, improve quality, and lower overall product cost.

Figure 1: An air pocket allows sound waves to vibrate the diaphragm in a Knowles MEMS microphone.

(click graphic to zoom by 1.3x)

The MEMS microphone is a bit of a renegade component in that it’s neither a traditional microphone nor a conventional integrated circuit. The difference in the design paradigm is that in MEMS, there are no circuits per se. Knowles doesn’t deal with schematic versus layout in the MEMS group, but instead draws complex polygonal and curved structures.

Electronic Design Automation (EDA) tools for designing these MEMS microphones have shortcomings. Most tools cannot handle complex geometries and are geared toward rectilinear design and layout schema. The Knowles microphone design, for instance, is largely circular and requires a tool that can create and manage toroidal elements (3D circles). And preparing to use a conventional EDA tool requires a significant amount of setup and configuration. While this up-front work might be needed for large circuit designs, where the engineer is working for weeks on a cell, it is hard to justify on smaller circuits.

When designing a cost-efficient MEMS microphone, it is critical to find a tool with a short ramp time and small up-front investment in setup and configuration. The different high-end tools the Knowles design team has used through the years to design microphones have two main drawbacks: an inability to handle complex geometries and too much overhead.

To better meet the challenges of this new paradigm, Knowles chose L-Edit from Tanner EDA for its MEMS design. This solution’s hierarchical architecture provided flexibility to manipulate thousands of repeating elements. The team saved production time creating a variety of parametrically driven shapes. Circles, pie wedges, and tori were instanced slightly differently in every layer because Knowles used them as primitives. Although this was possible in a limited way with a tool like AutoCAD, designers wasted hours going back and forth between mechanical design and EDA tools. The ideal solution was to create and analyze designs in one environment and then send them out for photomask fabrication.

EDA scripting and fab rules

Knowles designs are not especially small – the die size is about 1 mm – but they are intricate. Drawings with 10-12 million objects are common. While MEMS design flow today does not lend itself to direct object generation through standardized libraries, scripting functions make creating and managing thousands of parametric objects extremely easy.

High-end tools have highly specialized scripting languages, but L-Edit users can write scripts using ordinary C/C++ code. The scripting function is flexible and often used to create primitives with a one- or two-page script. For example, in MEMS, Knowles often etches holes through the wafers and cannot have die intersecting the edge of the wafer. This means the dies must be arrayed in a circular pattern. Knowles now starts with an instance of a die and uses L-Edit to make it a rectangular array. The scripts clip the rectangular array to fit within the wafer extents, leaving a few millimeters for an exclusion zone around the edge, thus saving time.

The Knowles R&D team takes advantage of the scripting functions for other tasks as well, such as creating mapping programs for die bonding pick-and-place equipment. The script goes through the database of cells in the layout and automatically generates a wafer map, which is particularly important when working on a matrix design that has several different designs in it. The team can create the maps and assign different letters to different design styles, then tell the die-bonding engineers to pick a particular letter out of the map. The ability to generate the map automatically also helps save time.

Design Rule Checking (DRC) is different in the world of MEMS because there are few set rules. Designers have to create their own rules or work them out on-the-fly with the fab. The cross-sectioning tool in the editor helps with this by allowing Knowles to visualize designs in the third dimension of stacked layers.

Knowles exports to GDSII for handoff to their fabs. Using L-Edit helps the engineers work around two limitations peculiar to many GDS tools. First, the fab can have instances only at 90/180/270/360 degrees, but when Knowles engineers rotate things, they don’t always end up with these particular angles. A script allows them to scan the database for any acute or obtuse angles and flush them out. Each one is then ungrouped, changed to be rectilinear, then later regrouped as it was originally.

Also supported is user-controllable fracturing of polygons, which lets Knowles set the limits for various mask fabrication vendors. Even when dealing with limitations in Knowles’ vendors’ systems, L-Edit has helped overcome problems and interfaced smoothly with the fab.

Summing it all up

Knowles MEMS microphones require creation and manipulation of complex geometry and integration of mask layout data with advanced scripting. High-end EDA tools are not well suited to these types of requirements, and simple mechanical CAD tools can’t perform the requisite tasks.

Knowles uses L-Edit tools to handle complex geometries and manipulate thousands of repeating elements at the heart of the company’s MEMS designs. The results speak for themselves – 1 billion chips and counting.

Figure 2

(click graphic to zoom)

Pete Loeppert has been VP of engineering for the Knowles Acoustic Division of Knowles Electronics since 1999. His previous experience includes work at the Gould Electronics corporate research center on a variety of projects including high-speed A/D converters, chemical sensors, fiber-optic systems, and GaAs circuits. Pete received his PhD in Electrical Engineering (specializing in solid-state devices) from Purdue University.

Knowles Electronics 630-250-5930 www.knowles.com

Nicolas Williams is director of product management at Tanner EDA, where he leads product direction from concept to release. His field of specialty is analog EDA and analog, mixed-signal, and RFIC design. Nicolas received his BS and MS degrees in Electrical and Computer Engineering from the University of Tennessee.

Tanner EDA626-471-9700www.tannereda.com

Using emulation to verify today’s complex designs

Lauro Rizzatti, EVE-USA — Mon, 14 Jun 2010 15:00:00 +0000

System-on-Chip designs aren’t getting smaller, so the verification strategy has to get faster to deal with complexity and obtain solid results in an acceptable amount of time. Emulation presents one verification method that can do this.

Such multilevel debugging methodology would not be possible with software simulators because they are too slow to effectively execute embedded software. Likewise, the same methodology would not be possible with FPGA-based prototypes since they lack visibility and access into the design to trace hardware bugs.

New emulation platforms

New emulation systems (Figure 1) are now replacing traditional big-box versions because they run faster and are easier to use and less expensive. They also consume a fraction of the power dissipated by bigger versions, require less space, and weigh less.

Figure 1: New cost-effective emulators offer performance, debug capabilities, and design capacity to make them ideal for today’s large SoC designs.

(click graphic to zoom by 1.2x)

These highly scalable, cost-effective tools are capable of handling up to 1 billion ASIC gates, boast fast compile time and emulation speed, offer a powerful debug environment, and support multiple concurrent users, all packaged within an environmentally friendly footprint.

What’s more, emulators can be deployed as emulation systems driven by a physical target system or as acceleration systems driven by a virtual, software-based test bench. Typical performance is approximately 10 MHz on a 10 million gate design and a top speed of 30 MHz on smaller designs. In these examples, emulators would process 10 seconds of real time in less than two minutes. Fast compile times range from 5 to 30 million gates per hour on PC farms, depending on the size of the farm and the design’s complexity.

Increasing time-to-market pressures, along with escalating hardware/software integration and quality concerns imposed on engineering teams, make the verification process a strategically important step in chip design. A new generation of cost-effective emulators such as EVE’s ZeBu-Server (for Zero Bugs) capable of handling up to 1 billion or more ASIC gates at high speeds reaching several megahertz provides a great choice for large designs.

Lauro Rizzatti is general manager of EVE-USA. He has more than 30 years of experience in EDA and ATE, and has held responsibilities in top management, product marketing, technical marketing, and engineering.

EVE-USA
408-457-3201

lauro@eve-usa.com
www.eve-team.com

Monitor opens an eye to high-speed SERDES performance

Kevin Walsh, Snowbush IP, a division of Gennum — Fri, 13 Nov 2009 15:00:00 +0000

The role of on-chip instrumentation has become much more important with high-speed signals, where off-chip instrumentation changes the picture when applied. This view of the concepts and differences is eye-opening.

Physical layer (PHY) standard interfaces for PCI Express and Ethernet are in the multi-GHz data rates. PCI Express 3.0 runs at 8 GTps, and 10GBASE-KR autonegotiates to just over 10 Gbps. At these speeds, probing at the package pin-out does not reveal the exact receive-side waveform. The package lead frame between the chip and the board electrically impacts the performance enough so that instrument suppliers try to model these effects to produce a better picture of the waveform as it exits the chip.

Such observability is important in optimizing the PHY block’s performance, not just to comply with the specification, but also to provide the cleanest eye opening. New high-speed oscilloscopes that can see these waveforms cost $100,000 or more. Although test bench time and expensive test equipment add to the inconvenience and cost of seeing what’s happening on the chip, they are crucial to making adjustments that ensure signal integrity and the best possible signal quality.

A precise and unobtrusive on-chip eye monitor provides visibility to receive-side data after equalization, offering an eye-opening view of the PHY’s performance. System designers look to such capabilities from their IP providers as a debug aid and a way to further optimize the receiver settings to improve performance.

What is an on-chip eye monitor, and how does it work?

This type of on-chip eye monitor is not a classic probe; it is a set of circuitry built into the design in a way that allows it to shadow the signals without affecting performance. Various on-chip eye-monitoring techniques have been developed and deployed in the industry.

For example, Snowbush IP uses a proprietary technique implemented in the decision feedback equalizer block. Implementing it here allows the circuitry to sample the actual signals used by the clock and data recovery function. The monitoring function performs in the normal operational mode in a nondestructive, data-independent manner in that it does not require any specific input data. But it can also work in a built-in self-test mode with any pseudorandom binary sequence or user-defined data pattern. The on-chip eye monitor samples the signal at the same point that the detection circuitry operates to adjust the equalization and then outputs a signal that allows designers to view a reconstructed eye diagram on a PC, representing the exact same signal the chip “sees.”

The on-chip eye feature allows the time axis (x) and the amplitude axis (y) to be swept (see Figure 1) and a corresponding Bit Error Rate (BER) to be calculated by comparing a roaming sample with the data sample. A BER measurement is made for each x and y offset. After sweeping x offset and y offset pairs, a BER-based eye is plotted.

Figure 1: On-chip eye measurement involves sweeping the time axis (x) and the amplitude axis (y) and calculating a BER.

(click graphic to zoom by 1.9x)

Using software to program control registers, the monitoring circuitry reads the x and y offset sweeps and samples and then writes the BER measurement results for each corresponding point. The software can configure the resolution of the sweeps and the number of receive data bits. Once all of the data points have been captured, the software plots a 2D image color-coded based on the results. Figure 2 shows an example of an eye plot captured for 10 Gbps of data using x offset of 3 ps, y offset of 20 mV, and 562 receive data bits.

Figure 2: After capturing each data point, software creates a BER eye plot with x/y offset of 3 ps/20 mV and 562 data bits.

(click graphic to zoom by 1.9x)

The software can also be configured to plot the gradient of the accumulated BER results. Using these results, designers can see the open eye in the BER eye plot, as well as the transitions and crossing points. Figure 3 shows a simulated eye on the right and the measured gradient plot of the eye on the left. The resolution of results is better than 2 ps in the time domain (x axis) and 2 mV in the voltage domain (y axis). The offset can be set to address the full horizontal eye opening; for the y offset (amplitude), the offset can be set to address ±150 mV (300 mV peak to peak).

Figure 3: Using software to configure BER results shows the measured gradient plot of the eye at the left and the simulated eye at the right.

(click graphic to zoom by 1.9x)

What are the benefits?

Multirate PHY IP blocks used to support multiple standards, such as those offered by Snowbush IP, are electrically tuned to each standard. Using the eye-monitoring function, designers can see the results of that tuning capability adjusted to meet performance specifications on a variety of protocols, including Gigabit Ethernet, XAUI, RXAUI, Fibre Channel, SAS, SATA, USB 3.0 (SuperSpeed USB), and PCI Express. This enables designers to debug and optimize performance characteristics for interfacing to a wide variety of devices and protocols.

In today’s environment, the substantial increase in serial communications speeds, degraded channel characteristics due to higher data rates, sophistication of the equalization techniques used in receivers, and the high cost of test equipment require implementing new approaches to gain visibility into PHY performance. Whereas other alternatives are expensive and opaque, on-chip eye-monitoring techniques let the open eyes in a design be seen with precise clarity in a timely, cost-effective manner.

Kevin Walsh is director of marketing at Snowbush IP, based in Toronto, Ontario, Canada. With more than 25 years of experience in IP and EDA, he has an extensive background in marketing IP, including roles at inSilicon, Arasan Chip Systems, Synopsys, Fresco Logic, Sapphire Design Automation, and Simplex Solutions. He has a BS in Electrical Engineering and Computer Science from the University of California, Berkeley and an MBA from Pepperdine University.

Snowbush IP, a division of Gennum 416-925-5643 kevin.walsh@snowbush.com www.snowbush.com

Enabling better testing: Reprogrammable on-chip instrumentation

Paul Bradley, DAFCA — Mon, 09 Nov 2009 15:00:00 +0000

This extensive look underneath the hood at on-chip instrumentation shows how at-speed validation for SoCs can be greatly improved with the right visibility inside.

Successfully testing and validating today’s sophisticated ASICs and FPGAs requires sophisticated solutions, especially tools that can provide advanced controls and views into the embedded system. In the past, some vendors relied almost exclusively on pre-silicon verification, only to discover additional problems during post-silicon validation. Others who realized a need for on-chip visibility constructed embedded instrumentation but focused on debugging instead of providing a systematic means to improve and accelerate post-silicon validation.

Using on-chip instrumentation for test purposes is not new. Most semiconductors have some amount of design-for-test logic used for structural verification. However, with increasing complexity and decreasing geometries, structural testing alone is insufficient; functional testing is required to verify a device. This type of testing demands a new class of instruments that, when designed correctly, can deliver utility throughout a device’s life cycle.

Development of nano-era System-on-Chip (SoC) devices necessitates superior tools that allow teams to not only observe circuit behavior, but also subject those circuits to stress and fault conditions, enabling the early discovery and diagnosis of integration problems, configuration problems, and unexpected behaviors resulting from functional, signal integrity, power, or process-related issues.

Unlike fixed-logic infrastructure that is permanent and used only once, a reprogrammable fabric inserted into an SoC during the design process provides an infrastructure platform that can be reconfigured and reused by post-silicon tools. This capability allows designers to implement a suite of applications ranging from performance monitoring and fault insertion testing to in-field diagnostics and security monitoring. Such logic can also be used to accelerate manufacturing test.

Silicon testing and validation challenges

Even the most sophisticated SoC pre-silicon verification methodology cannot fully account for all the parameters that impact silicon behavior. Moreover, on designs with embedded processors, it is nearly impossible to ensure that software and hardware will operate cohesively when merged into first silicon.

Hardware issues must be dealt with during bring-up and early integration. The simultaneous occurrence of two unlikely events might never be simulated or analyzed pre-silicon, but could cause unexpected effects when encountered in system. Pre-silicon verification methods – simulation, emulation, FPGA prototyping, timing analysis, and formal verification – are oblivious to many deep submicron problems that occur in the device. Many other integration or configuration problems and unexpected behaviors resulting from signal integrity, power, noise, or process-related issues are extremely difficult to find pre-silicon.

As a result, post-silicon validation has become an essential step in the design implementation methodology. The most important phase of this process is in-system, at-speed validation, which is the first opportunity for a newly manufactured chip to work in its intended environment and interact with other chips on a system board while operating at its target frequency. Only real-life usage under stress conditions exposes functional and timing errors that escape pre-silicon verification. However, locating these problems in a chip working at-speed in-system is much more difficult, expensive, and time-consuming than in pre-silicon or on a tester.

In simulation, all SoC signals are accessible. Likewise, in a tester, at-speed access to the chip’s I/O pins is possible. In-system, however, one no longer has direct at-speed access to the chip’s internals. This limitation represents a significant reduction in both observability and controllability and makes assessing the chip’s internal dynamic behavior an extremely difficult process.

Unlike tester-based experiments that are fully repeatable, in-system operation is not completely deterministic because of the unpredictable interactions of independent events amongst multiple asynchronous systems such as external interrupts, irregular network traffic, bus arbitration, or DMA transfers. This nondeterminism makes many problems appear as intermittent and severely complicates silicon validation and debug.

The nondeterministic operation and lack of control over stimuli applied to the chip combine to create another difficulty: the expected values. Another complicating factor is the difficulty of determining the nature of the problem. In addition to functional problems (such as corner cases or deep-state bugs) and timing errors, the SoC operation might also be affected by defects that eluded early manufacturing tests and are detected only in-system. Taking a chip that is failing in-system (or in the field) back through manufacturing testing often results in “no problem found.”

Engineers clearly need a better way to address functional and timing errors, embedded software integration, and difficult-to-detect abnormalities that only manifest themselves intermittently or under rare operating conditions. Most existing solutions are based on bringing out an internal debug bus for hookup to an external logic analyzer and thus require a large number of additional pins. These solutions are not scalable because of the difficulties inherent in transferring high-speed parallel data through device pins. Ever-increasing internal clock frequencies contribute to making this technique largely impractical for at-speed validation.

On-chip instrumentation with reprogrammable logic

A new generation of tools is emerging to deliver a more sophisticated on-chip instrumentation scheme and off-chip development and test environment. Reprogrammable fabric composed of reconfigurable instruments provides a framework for automating hardware and embedded software validation through a combination of on-chip instrumentation and off-chip analysis tools and applications (shown in Figure 1).

Figure 1: Reprogrammable fabric enables more comprehensive silicon validation testing.

(click graphic to zoom by 1.8x)

Pre-silicon, these tools enable and guide the user to insert and customize reconfigurable instruments for validation. Insertion is done at the RTL level, and the instrumented SoC is processed by standard synthesis-based design flows. The instruments do not require any additional pins or special libraries, and although inserted and customized at design time for at-speed data acquisition, performance monitoring, stimulus, and fault injection functions, they are ultimately programmed post-silicon while the system is in operation. This is a significant advantage because the instruments can be repurposed to serve a variety of functions without requiring a resynthesis of the design. With in-depth visibility and stimulus-injection capabilities, these tools offer validation engineers the ability to observe and control deeply embedded signals.

The solutions bridge from pre-silicon verification to in-system silicon validation by extracting behavior from silicon to verify within simulation and reproducing simulation experiments in silicon. In-system scan-based validation integrates the flexibility of the reconfigurable at-speed instruments with complete register observability enabled by existing scan chains.

These techniques can efficiently deal with problems inherent in system-level validation, such as reduced internal observability, lack of expected values, and pseudo-intermittent behavior. These tools automate tasks that previously required an intensive engineering effort. The end results are significantly reduced silicon validation time and faster discovery of integration problems, design bugs, and chip defects.

Case study: Diagnosing and correcting complex firmware problems

To illustrate these concepts, consider a recent application involving a Virtualization Platform Company (VPC) developing core technology platforms for the green data center. While working with an external vendor on BIOS firmware that interacted with the company’s ASIC, the vendor’s firmware consistently crashed during bootup, and the engineering team couldn’t determine why. The firmware vendor believed that the issue was with the VPC’s ASIC, but the VPC was skeptical given its thorough pre-silicon verification work.

The ASIC involved was a low-power, high-capacity data center processor chip that targeted the vendor’s 90 nm high-speed process. The chip included a complex design with approximately 2 million gates, multiple asynchronous clock domains, and a maximum operating frequency of 500 MHz.

Adequately testing the ASIC required on-chip visibility, control, and analysis. The VPC decided to use a solution composed of on-chip instrumentation and off-chip analysis tools. The on-chip instrumentation was a reprogrammable fabric that executed a variety of on-chip functions including logic analysis, assertions, transaction stimulus, and performance monitoring.

The complete VPC solution included the following components:

· A pre-silicon instrumentation studio used to insert programmable instruments directly into the RTL design

· A silicon validation studio, which is a software application that communicates with the on-chip instruments via a JTAG 1149.1 interface and employs the on-chip instruments to provide a wide range of in-system, at-speed analysis and control capabilities

The on-chip instrumentation strategy for the VPC chip (Figure 2) implemented during the design phase included dual-transaction engines (programmable state machine instruments) with multiclock domain multiplexers (~7,000 user signals) and stimulus wrappers (~50 user signals) collectively enabling complex triggers, assertions, protocol validation, and fault injection. The transaction engines were each configured as four-state finite state machines with GPIO cross-trigger signals to enable cross-triggering and more advanced conditional transaction analysis. A 4K x 256 dual-port SRAM was used with each transaction engine.

Figure 2: On-chip instrumentation is designed to handle logic analysis, assertions, transaction stimulus, performance monitoring, and other on-chip functions.

(click graphic to zoom by 1.3x)

The VPC used the reprogrammable on-chip instrumentation solution to look at the packets coming in from the high-speed bus and quickly noticed that illegal packets were being received. Based on that information, the company theorized that the firmware configured certain bus numbers incorrectly. This theory was proven right, and the VPC was able to fix the software within 48 hours.

Without using the reprogrammable on-chip instrumentation technology, it would have taken the VPC at least another two weeks or longer of trial and error to find and diagnose the problem. Overall, it is estimated that the reprogrammable on-chip instrumentation strategy helped reduce development time by 3-4 weeks.

This is just one example. Seasoned developers know that teams often experience a half-dozen or more of these head-scratching and stressful scenarios when testing complex systems.

Using reprogrammable logic for in-field diagnostics and security applications

The programmable instrumentation fabric can also be leveraged in the field for a variety of applications. The first and perhaps most obvious application is as a background diagnostic testing utility. The instruments can be used to monitor for certain events and performance levels without loading a processor. Alternatively, they can be used in conjunction with software-based diagnostic programs to reach deeper into the system for more thorough and rapid analysis.

Another interesting application for the programmable instrumentation fabric is in embedded system security. The instruments that are ideal for measuring performance or analyzing complex event sequences can be used to protect memory, detect malware, and thwart invasive tampering. This approach is rooted in hardware and provides security functions that operate independently from the processor and are immune to the threats that often prevent detection and corrective action.

More than just validation

A new generation of tools is offering a more sophisticated on-chip instrumentation scheme and off-chip development and test environment. A reprogrammable fabric comprising reconfigurable instruments provides a framework for automating hardware and embedded software validation through a combination of on-chip instrumentation and off-chip analysis tools and applications.

The emergence of these tools helps users overcome the difficulties associated with in-system validation. Embedded instrumentation provides on-chip, at-speed observability of the SoC’s internal operation. A distributed fabric made up of reconfigurable transaction engines in the silicon enables not only real-time software/hardware validation capability, but also a variety of field applications such as comprehensive security testing and protection against piracy, reverse-engineering, and unauthorized use.

Paul Bradley is Chief Technical Officer of DAFCA, Inc., based in Framingham, Massachusetts. Paul has more than 20 years of experience in electronics and systems design and specializes in product development and engineering leadership in emerging technology markets. He held numerous engineering and technical leadership positions at Motorola, Nortel, CrossComm, Sonoma Systems, and Internet Photonics prior to joining DAFCA.

DAFCA
774-204-0020
paul.bradley@dafca.com
www.dafca.com

FPGA synthesis tools meet the DO-254 challenge

Sanjay Thatte, Mentor Graphics Corporation — Mon, 20 Apr 2009 15:00:00 +0000

DO-254 compliance, as it spreads from aviation to military and beyond, is becoming a significant concern for more and more FPGA design companies. Synthesis is a key part of these flows, and, thankfully, tool vendors are beginning to address the key concerns of optimization vs. design assurance, SEU protection, redundancy control, and late design change capabilities required in FPGA synthesis tools for DO-254 compliance.

FPGAs are increasingly being used for safety-critical applications, and designers have to achieve product design goals while also meeting required safety standards. The RTCA/DO-254 airborne electronics design assurance standard defines a process that must be followed for FPGA and ASIC designs for in-flight systems.

Sidebar 1: Verification: DO-254 appropriate FPGA synthesis tools vs. default tools

(click graphic to zoom by 1.8x)

Since the safety stakes are high for DO-254 compliance, an assured design process with the ability to reproduce every step and consistently yield the same result is important (see sidebar), but the default operation for commercial synthesis tools does not meet the stringent requirements of DO-254. This is causing many companies to re-evaluate their design methodologies and tools – and ask which tools best support the needs of DO-254. Sanjay and Michelle address the challenges of DO-254 and the synthesis process, including considerations for design optimization vs. assurance, Single Event Upset (SEU) protection, redundancy control, and late design changes, and examine default tool operation versus what is required for DO-254 compliance.

Challenge: DO-254 compliance

Synthesis is at the heart of all modern design flows and increases designer productivity by automatically converting high-level design description to gate-level designs. One important consideration is design optimization. Another consideration is that default synthesis operation does not offer the SEU protection, redundancy control, or late design change capabilities required in FPGA synthesis tools for DO-254 compliance.

Design optimization vs. assurance

Default synthesis tool operation performs various optimizations like resource sharing, boundary optimization, and retiming to reduce area and improve timing. These transformations make the DO-254 design assurance process cumbersome as the original HDL and optimized synthesis netlist become difficult to compare.

Since optimizations performed during synthesis transform the design, it is important to ensure that design safety is not compromised in pursuit of better performance. FPGA synthesis tool users must focus on design assurance even if it could mean possibly sacrificing some design performance. Users must understand the tool’s operation and select the appropriate options to disable all synthesis optimizations that would make the synthesis results difficult to verify. An example of such an optimization is RAM inferencing, which makes comparing HDL and synthesized netlist difficult.

Finite State Machine (FSM) synthesis for SEU protection

Default synthesis operation prunes unreachable states to generate only the valid states and transitions. However, for optimized state machines, an SEU due to radiation effects can pose a safety risk. Since DO-254 applies to avionics, if radiation changes one of the state bits and the system enters an invalid or undefined state, then it cannot automatically recover from this error condition.

In a safety-critical system, the state machine should recover to a valid state at the next clock cycle after a single event upset. Therefore, state machine behavior for all 2n possible state values (n = state vector length) should be specified. The DO-254 appropriate FPGA synthesis tool should provide the capability to create state machines that are so safe as to preserve even unreachable states (Figure 1). Another important synthesis tool capability is to actually create fault-tolerant state machines, which prevent single-bit errors from having any effect on the design. Applications where fault avoidance is needed and overhead of parity bits can be tolerated should utilize a synthesis tool that supports this additional safety mechanism. In general, designers should ensure they understand the operation and options of their FPGA synthesis tool to support state machine capabilities in their designs.

Figure 1: The DO-254 appropriate FPGA synthesis tool should provide the capability to create state machines that are so safe as to preserve even unreachable states.

Redundancy control for single-point failure avoidance

Redundant circuitry directly conflicts with the goal of reducing design size and meeting timing performance in avionics and other designs. Hence, by default, FPGA synthesis tools focus on finding and optimizing away redundancy in the design. They do not automatically consider whether redundancy was intentionally designed in for safety. Unfortunately, this default behavior runs directly contrary to the needs of DO-254 compliance.

To ensure safer operation, designers need to use the DO-254 appropriate synthesis tool to support insertion and preservation of redundancy. One such technique to insert redundancy is called Triple Modular Redundancy (TMR). TMR replaces one signal, register, or module with three (Figure 2). The outputs of all three circuits are compared against one another, and the majority vote is assumed correct. This takes up significantly more area but provides fail-safe operation in real time. DO-254 appropriate FPGA synthesis tools support this technique.

Figure 2: With Triple Module Redundancy (TMR), the outputs of all three circuits are compared against one another, and the majority vote is assumed correct.

Managing late design changes

For late design changes in a project striving for DO-254 compliance, it may be desirable to update only local parts of the design where the fix is needed. To address this, a design team may adopt an incremental design flow where the main design blocks are partitioned up front by the designers. But a second, more user-friendly variant is automatic incremental synthesis. In this case, design blocks are not partitioned up front, but instead the FPGA synthesis tool can limit the impact of a design change to only locally affected logic.

DO-254 FPGA synthesis tools: Forging ahead

DO-254 compliance is a challenge that many aerospace hardware vendors now face. The ability to establish certifiable and productive design flows is critical to meet that challenge. Since synthesis is at the heart of design flows, an FPGA synthesis tool that goes beyond the usual design optimization goals and specifically focuses on safety-related aspects is important to the success of a DO-254 compliant project. Some key capabilities of FPGA synthesis tools that designers should utilize include state machine synthesis for SEU protection, redundancy control, and support for late-stage design changes. CS

Sanjay Thatte is responsible for technical marketing and product management of FPGA synthesis products at Mentor Graphics. Sanjay holds an M.S. from the University of Washington and an MBA from San Jose State University and has published several articles in the area of FPGA development. Sanjay has also created a fault-tolerant network structure and has coauthored its publication. His previous experience includes FPGA design planning and closure, design automation, and design verification. He can be contacted at sanjay_thatte@mentor.com.

Michelle Lange currently holds the position of DO-254 program manager at Mentor Graphics and has nearly 20 years of experience in Electronic Design Automation (EDA). In this role, she works with customers striving to meet DO-254 compliance, the product teams within Mentor that develop the tools/features required for these flows, partners in the industry who offer complementary services and tools, and industry organizations such as the DO-254 User’s Group. Michelle holds a BSEE from the University of Portland and an MBA from the University of Phoenix and has published numerous technical papers and articles on DO-254 and other EDA-related subjects. She can be contacted at michelle_lange@mentor.com.

Mentor Graphics

408-451-5640

www.mentor.com

Tipping points in programmable logic: Is FPGA design more complex than ASIC design?

Andrew Dauman, Synopsysí Synplicity Business Group — Tue, 02 Dec 2008 15:00:00 +0000

The ASIC world has many degrees of freedom; the FPGA world, not so much. But as Andrew Dauman, who will be presenting the keynote address at the first annual FPGA Summit, points out, far fewer than six degrees of separation may keep the two apart.

In the 25-year history of programmable logic, every year has
seen major business upheavals set off both by the application of Moore’s law to
the devices and by necessary design methodology adaptations. At the leading
edge of FPGA design, the techniques and expertise employed are every bit as
challenging and sophisticated as those used in ASIC design. In ASIC design, the
leading-edge CMOS geometries are used to create very large scale systems on a
chip. The parasitic and secondary effects of employing CMOS geometries at 90nm
and far below have led to front-end ASIC tools (and designers) having to be
more and more engaged in the back-end procedures. For example, most ASIC
designers demand the use of Physical Synthesis at the front end in order to
drive timing closure at the back end. Front-end ASIC designers are given
additional burdens of Design-for-Manufacturing, Design-for-Test,
Design-for-Reuse (IP), Design-for-Low Power, and the like, all of which are
complex and interdependent.

In the ASIC world, there are many degrees of freedom in the
end silicon, and the previously mentioned burdens of the modern ASIC designer
are all examples of the responsibility that comes with that freedom. The Electronic
Design Automation (EDA) industry has done a sterling job in providing tools that
allow these burdens to be borne and for ASICs to be produced at 40nm and soon
beyond – an astounding achievement that seemed impossible only a few
years ago.

FPGA designers, on the other hand, do not have such freedoms;
this is both their blessing and their curse.

FPGA vendors make enormous investments in creating a new FPGA
family. They are performing the very tasks mentioned above and they are doing
it not only for a single design, but to produce a device that addresses a very
wide range of applications. In effect, they are carrying the burden of 40nm
design for their end users.

How FPGA designers manage hurdles

Compared to ASIC designers, FPGA designers lack freedom. We
are limited to exactly the resources, timing, routing, power and other
parameters that are encapsulated into the FPGA silicon. This places extreme
constraints on FPGA tools and designer efficiency. An ASIC design team can place
fine-grain cells, create extra routes as required, or move resources while
considering the multi-axis trade-offs involved. In the FPGA realm, however,
cells are fixed and coarse-grained. What’s more, routing is finite with
quantized delays, so if we require an extra route where none is available, then
the effects often ripple widely throughout the design.

The predefined coarse-grained nature of FPGA architectures
would be an extremely difficult hurdle for today’s ASIC design teams if they
were faced with such fundamental constraints, so how do FPGA designers manage?

Traditionally, FPGA designers are not expecting a detailed level
of involvement in their designs; and this must not change. They work at an abstracted level from the silicon
and depend upon their tools to make the trade-offs mentioned earlier quickly,
automatically, and without error. At Synopsys, we have devoted more than 14
years of R&D effort to developing the methodology and tools that maintain
this abstraction, even at the very leading edge of FPGA technology. For
example, by modeling all routing resources, their timing, their sources, and
their blocking inter-dependencies, we created a Physical Synthesis solution
that combines Synthesis with Place and Route. Revisiting our earlier example,
routes may be ripped up and rerouted elsewhere to make room; on the other hand,
physical synthesis might more subtly employ local resynthesis in situ, thus altering the placement or even the actual logic
functions to be placed and alleviating the original routing bottleneck. In
effect, we combine the back end and front end in a single-pass automated
methodology.

As the R&D groups within the Synplicity Business Group
join those of Synopsys, we have new access to many and varied ASIC tool
technologies. Many of these are not applicable to FPGA, but some may prove to
be of crucial benefit to FPGA tool flows of the future. Beyond the delineated
worlds of FPGA or ASIC, an additional wider universe of system design waits,
including algorithmic modeling, embedded software, and virtual prototyping. We
have already teamed up to face those challenges, too.

Andrew Dauman, in
his role as vice president of engineering for Synopsys’ Synplicity Business
Group, oversees the development of programmable solutions for FPGA implementation,
ASIC verification, and ESL/DSP algorithm implementation.

Before joining Synopsys, Andrew was vice president of
engineering and vice president corporate applications engineering for
Synplicity, which Synopsys acquired in May 2008. He previously held positions
at Mentor Graphics, Silicon Compiler Systems, Prime Computer, and Raytheon.
Andrew has a BSEE from Boston University.

Synopsys
408-215-6000
andrew.dauman@synopsys.com
www.synopsys.com

The FPGA Summit takes place December 9-11 at the Wyndham
Hotel in San Jose, California.

OVP makes system-level virtual prototyping a reality

Brian Bailey, Imperas — Tue, 15 Jul 2008 15:00:00 +0000

As software content continues to grow in importance and complexity, the industry is facing challenges presented by multiple heterogeneous processors with much tighter communications than in the past. To ensure quick time to market for high-quality software, developers need a high-performance, system-level virtual prototype of the hardware, on which software can be designed, implemented, and tested. While previous prototypes have been too slow or arrived too late in the development cycle, the recently announced Open Virtual Platforms (OVP) initiative enables both early and fast virtual prototype availability.

Electronic Design Automation (EDA) flows are built on the fundamental premise that models are interoperable and freely interchangeable among vendors, meaning that models can be written or obtained from anywhere and be accepted by any vendor‚Äôs tools. These features have been elusive for the abstract models necessary to support high-performance prototypes. Because of this, EDA has failed to deliver a system-level virtual prototype that provides the right levels of capability and speed of execution.

Major changes happening in both the hardware and software worlds will soon make it impossible to construct systems without an abstract model. By adopting reuse, designers are now essentially assembling complex embedded systems like LEGO systems. Processor complexity has hit a wall created by diminishing performance gains at the expense of huge power increases, such that most systems today utilize multiple heterogeneous processors rather than one central processor. As system functionality continues to grow, it must cope with the transition to a multiprocessor world. With all of these changes, designers cannot continue building systems without a viable system-level model on which this functionality and architecture can be designed and verified.

Historical perspective

Hardware/software coverification

Some companies have attempted to bring the hardware and software communities together by providing virtual hardware models that can be used for software development. For example, Seamless from Mentor Graphics substituted Instruction Set Simulator (ISS) models for each processor and integrated them into a conventional Register Transfer Level (RTL) simulation environment[1]. This model aided driver debugging but lacked sufficient performance for anything else. The Seamless product also included several performance boosters that virtualized the host memory system, which extended its usage into some low-level operating system areas[2].

In later years, faster models replaced the RTL models, such as C or SystemC models[3]. Although these models provided better performance, complex systems still operated too slowly, making them unsuitable for mainstream software usage.

SystemC prototypes

The industry has spent considerable time and effort constructing virtual platforms based on SystemC. Examples include platforms created and proliferated by CoWare[4] and the proposed work project under the Eclipse Virtual Prototyping Platform (VPP)[5]. These prototypes provide a flexible and adaptable platform on which bus traffic, power, performance, and many other implementation attributes can be analyzed. While much faster than the RTL prototypes discussed, these prototypes perform at levels that keep them in the domains of hardware verification and firmware development.

In addition, SystemC has failed to solve the model interoperability problem, an issue that the Open SystemC Initiative (OSCI) Transaction-Level Modeling (TLM) group is trying to rectify. The group‚Äôs latest attempt has not impressed many in the industry, as some have called the effort "too little too late." Furthermore, this proposed standard only addresses memory-mapped interfaces, limiting its ability to define a complete system-level prototype.

Other companies such as Virtutech and VaST Systems[6] have forsaken the standards arena and used custom languages and tools to create faster models of processors, memory systems, and some aspects of hardware. While these companies have successfully created prototypes with higher performance, they suffer from the problems of model availability and proprietary formats.

Changing needs and increasing complexity

Most prototypes today include timing, which is essential for hardware and architecture verification as well as low-level driver testing. But timing information slows down the prototype. For the software team handling applications development, timing information is unnecessary. Time advances as each processor is clocked, and events advance in the correct order for each thread.

To work reliably, multiprocessor applications must perform synchronization that does not depend on timing. Thus, a system-level model for the software community can dispense with timing altogether, relying instead on sequential order of execution and proper synchronization between threads. Synchronization is performed using semaphores, handshakes, or other mechanisms that ensure the two software threads that need to communicate are both in the necessary state for exchanging data.

As time progresses, developers are not as concerned about how a single block or an isolated algorithm functions as they are about controlling and coordinating blocks and algorithms to form a complete multifunction system. This additional capability leads to increased complexity. Total system complexity is proportional to the square of the number of independent nodes that communicate. These nodes can communicate with each other and collaborate to perform the total function. By implication, each of those nodes performs an independent task or coordinates with others to fulfill a more complex task. With the advent of multiprocessor Systems-on-Chip (SoCs), software has now become truly multinodal because threads can execute in a fully concurrent manner and interact with each other in real time.

Multiprocessor software demands

In the past, cross-compiling the code onto the host was quick and easy; however, this does not hold true for multiprocessor software. Even though current desktops now have two or four processors, they provide a less reliable view into how software will operate or perform on the actual embedded hardware, which might have special communications between the processors or require heterogeneous processors. Multiprocessor software needs a more accurate prototype to investigate application communications and synchronization.

At the other end of the scale, many companies utilize physical prototypes to conduct software verification. While these prototypes operate at near real-time speeds and have accurate timing, they are available too late in the development cycle, given that problems found in the software cannot be reflected by necessary changes in the hardware. With the introduction of multiprocessor systems, it is more difficult to see what each processor is doing in real time, and operations such as single-stepping are almost impossible. Designers need a platform that provides the same level of performance but is available earlier in the design cycle.

OVP overview

OSCI maintains the SystemC language and provides a free simulator. While these offerings appear beneficial, they have in fact stifled commercial advancements. In addition, SystemC has failed to solve the model interoperability problem discussed earlier.

Imperas recently launched the OVP initiative to promote the open virtual platform concept. OVP encourages developers to adopt the new way of developing embedded software, especially for SoC and multiprocessor SoC platforms. The company took a different approach with OVP and OVPsim by first making the interface available to the public, thus addressing the model interoperability problem. The company offers several models that demonstrate the interface‚Äôs capabilities as well as a Windows platform simulator for developers to build and debug models.

Interfaces

OVP comprises four C interfaces, as shown in Figure 1.

Figure 1

(click graphic to zoom)

ICM ties together system blocks, such as processors, memory subsystems, peripherals, and other hardware blocks. ICM is a C interface that produces an executable model when compiled and linked with each of the models and some object files. Given that it is standard C code, any C compiler can be used to create the model. The ICM interface also allows memory images to be defined so that programs or data can be preloaded into the system model.

VMI is the virtual machine or processor interface that allows the processor model to communicate with the kernel and other components. VMI is essentially the heart of the high-performance execution provided by OVP. OVP uses a code-morphing approach with a just-in-time compiler to map the processor instructions into those provided by the host machine. In between is a set of optimized opcodes into which the processor operations are mapped. OVPsim provides interpretation or compilation into the native machine capabilities. This differs from the traditional ISS approach, which interprets every instruction. VMI also enables a form of virtualization for capabilities such as file I/O, which allows direct execution on the host using the standards libraries provided.

PPM, the peripheral modeling interface, is similar to the fourth interface, BHM, which is intended for more generalized behaviors. These models run in a second portion of the simulator called the Peripheral Simulation Engine. OVPworld states that "this is a protected runtime environment that cannot crash the simulator." It does this by creating a separate address space for each model and restricting communications to the mechanism provided by the API. The principal difference between the two interfaces is that the PPM interface understands buses and networks. It is thus similar to the OSCI TLM interface proposal in terms of functionality. The BHM more closely resembles a traditional behavioral modeling language with process activation and the ability to wait for time or a specific event.

Performance benchmarks

Several different processor models and prepackaged demos are available at the OVPworld website (http://www.ovpworld.org). A free simulator is available for developers to create their own platforms. Table 1 shows the performance results obtained for each of the cores running various benchmarks.

The cornerstone of hardware/software virtual prototypes

OVP has the potential to provide a true system-level virtual prototype for both hardware and software development. It is poised to become the first general-purpose abstract modeling system that will form the cornerstone of complete flows into the hardware and software communities. While this has been accomplished before in specialized areas such as DSP designs, it has never been solved in the more general case. OVP has enabled the commercial market for these prototypes, meaning that it could garner more commercial attention than SystemC. If successful, OVP will address the model interoperability problem and thus benefit the entire industry.

Brian Bailey is an independent consultant for ESL, verification, and system design companies, such as Imperas. Previously, he worked at Mentor Graphics for 12 years in roles such as chief technologist for verification. Brian, who has published four books and several technical papers, graduated from Brunel University in England with a first class honours degree in Electrical and Electronic Engineering.

Imperas
925-519-1234
info@imperas.com
www.imperas.com

References

Modeling techniques maximize value of virtual platforms

Andy Ladd, Carbon Design Systems — Tue, 15 Jul 2008 15:00:00 +0000

System-level environments increase developer productivity and bring products to market earlier, providing a development platform for architectural analysis, hardware/software codevelopment, and system validation. Models provide the backbone for any system-level platform; however, the difficulties and expenses involved in developing these models have limited virtual platform adoption. Andy describes the importance of an effective modeling strategy for virtual platform development.

Over the past several years, development teams and methodology groups have placed greater emphasis on platform-driven design techniques. Shorter product life cycles and heightened time-to-market pressures have forced companies to invest in system-level platforms available earlier in the design cycle. In addition, the transition to System-on-Chip (SoC) design techniques leveraging legacy and third-party IP has provided better structure and methodology for modeling at the system level. Meanwhile, the increasing amount of embedded software and firmware content has repositioned the majority of resources required to produce a product into the software domain. In a traditional design flow, this means a larger portion of the development process is shifted later in the design flow, increasing schedule risk.

Virtual platforms help address these ever-increasing complexity issues, market pressures, and changes in content. Although some engineers have described the benefits of these platforms in detail, identifying appropriate modeling methods is usually left as an exercise for the reader. To shed some light on this facet of virtual platforms, the following discussion will analyze different aspects of proper modeling techniques.

Ironically, while models provide the backbone for any system-level platform, the difficulties and expenses associated with developing these models have limited virtual platform adoption. In addition, modeling and support efforts consume the lion‚Äôs share of the costs for developing and supporting these platforms.

Model abstraction levels

For this discussion, models can be partitioned into four distinct parts: timing, functionality, addressable state, and interfaces. Each of the model‚Äôs four parts can vary at different abstraction levels, from high-level behavioral descriptions to the actual design implementation. Models created directly from design descriptions that reflect true design behavior are referred to as implementation-accurate models. The modeling stack in Table 1 shows the continuum of abstractions between the highest and lowest extremes.

Table 1

(click graphic to zoom by 1.7x)

As with most applications related to computing, increasing accuracy has a direct impact on reducing execution speed. This is no different with modeling; boosting a model‚Äôs accuracy requires more processing and a reduction in execution speed.

In addition, increasing model accuracy directly correlates to the amount of effort and time required to create and support models. Finding the proper speed versus accuracy trade-off is paramount to achieving a modeling paradigm that will meet virtual platform users‚Äô needs and limit the amount of effort required to develop and maintain the platform.

At one end of the spectrum, hardware engineers need implementation-accurate models to validate their designs. At the other end, application software developers can get by with high-level behavioral models. Between these two extremes lie lower levels of software, including the Operating System (OS), driver, firmware, and architectural and performance analyses.

Application software engineers are most concerned about developing their applications and having a productive debug environment. They don‚Äôt need the accuracy of a detailed model; their code rarely touches the actual hardware because it‚Äôs layered on other software. However, application software engineers in some cases might need to understand simple performance metrics that require more accuracy.

Unlike application code, OS and driver development touches the hardware; thus, those who develop these components need a higher degree of accuracy to understand how their software and the underlying hardware interact. They can exchange speed for higher accuracy because their code base is smaller than application software engineers‚Äô code base. Untimed behavioral models might be useful for early development, but ultimately, OS and driver developers must understand how their software works using more accurate models to ensure that the whole system (hardware and software) will work together.

Firmware engineers develop code – boot code, self-test, diagnostics, and console – that interacts with hardware. Given this high level of interaction with and dependency on hardware, these engineers have little use for inaccurate models. They can swap model speed for higher accuracy because their software is at the lowest level and is usually small compared to that of higher levels. Tuning low-level firmware and driver software performance also requires cycle-accurate models to understand timing dependencies on hardware as well as resource bottlenecks.

Architects need to know how their hardware/software partitioning, IP selection, bus architecture, memory architecture, and overall architectural decisions impact the system as they relate to performance, area, and power. They also must understand pipeline effects, latencies, throughput, bandwidth, and activity. A final design that doesn‚Äôt perform as architects planned could dramatically affect the product‚Äôs cost, performance, and schedule. Therefore, architects must validate their designs using highly accurate models that build confidence in their decisions. Hardware engineers must have implementation-accurate models; any other level of accuracy is unsuitable for validating designs.

A single abstraction level for all models is not always appropriate in every case. For example, an architect considering memory architecture trade-offs might try to analyze each prospective memory subsystem‚Äôs memory latency and throughput. In this case, architects might need highly accurate models for memory controllers and memory interfaces to ensure that they fully understand the performance. The rest of the system can be modeled at more abstract levels because it isn‚Äôt critical to the analysis. Using a model methodology that supports mixing abstraction levels and enables plug-and-play for models of different abstraction levels can help optimize execution speed and analysis accuracy.

Finally, when considering all possible use cases, engineers should note that a platform rarely targets only one type of user. It is more common that a virtual platform will be created to address the needs of many types of users, ranging from software developers to architects and, in some cases, hardware designers. Therefore, different abstraction levels must be supported within the platform.

Interoperability and compatibility

When creating a modeling methodology, developers should make sure models are interoperable with each other, spread across abstraction layers, and compatible with various platforms and third-party tools. Consistency is also important to guarantee that models created by different model developers are compatible with each other.

Though not perfect, standards help add consistency, compatibility, and interoperability among models by supporting various model abstractions and providing compatibility with different platforms and third-party tools.

Modeling languages such as SystemC provide a base platform to connect and execute different models. SystemC provides the flexibility to support multiple abstraction levels and communication interfaces. Combining SystemC with interface standards, such as the proposed Transaction-Level Modeling (TLM) 2.0 specification in development by the Open SystemC Initiative (OSCI), provides an environment that maintains compatibility with various modeling elements and abstractions and makes them interoperable with each other and other platforms.

In addition, when refining models from different abstraction levels, developers should reuse as much information as possible from one model to another and reuse modeling information from one revision of an IP block to another. Consistent methodology and standards provide the mechanisms to accomplish these tasks. Developers also can reuse interfaces, state access mechanisms, and timing from one model to another. Standards such as Spirit IP-XACT, the IP metadata specification from the SPIRIT Consortium, can help developers import and export configuration information and check differences between model revisions and abstractions.

A modeling methodology that doesn‚Äôt guarantee interoperability among different models and abstractions or provide compatibility with other platforms and third-party tools is ill suited for most projects. In fact, lack of interoperability and compatibility has slowed virtual platform adoption within the embedded industry.

Meeting supply chain needs

The growing need for providing models across the supply chain reinforces the importance of interoperability, compatibility, and standards. IP providers must supply early models of their IP because customers need the ability to select the appropriate IP for their products. Without proper models, customers have no way of knowing what IP will work best in their systems. Customers also need a platform for their own development (architecture, hardware, and software) to hit their market window with the correct product.

Any modeling methodology that supports IP delivery across the supply chain must take this into consideration. IP must be compatible with end customers‚Äô platforms and models, yet at the same time provide security and be impervious to reverse engineering.

Breaking down modeling barriers

A well thought-out modeling methodology can overcome obstacles to virtual platform adoption as well as ensure that users attain all the value that a virtual platform can provide. Virtual platform modeling should support models of various abstraction levels, model plug-and-play, and standards for interoperability, compatibility, and reuse.

The industry needs to provide tools that automatically support model generation in a consistent manner across the various abstraction levels. These tools must incorporate standards and preserve the investment that developers put into their models. Requirements should:

Make the model developer more productive
Reuse information from legacy models or models of different abstractions levels
Support standards to ensure interoperability and a migration path for models to other virtual platforms
Provide consistency checks to validate models across abstraction levels
Offer configuration management and revision control aid for model support and distribution

Andy Ladd is VP of applications and methodology at Acton, Massachusetts-based Carbon Design Systems, Inc., where he is responsible for providing and supporting automatic system-level modeling and validation solutions.

Carbon Design Systems
978-264-7300
aladd@carbondesignsystems.com
www.carbondesignsystems.com

References

Serughetti, Marc, "Platform-driven ESL design: Enterprise enabler for platform customization," Embedded Computing Design. August 2007.
Hong, Sungpack, et al., "Creation and utilization of a virtual platform for embedded software optimization: An industrial case study," Proceeding of the 4th International Conference on Hardware/Software Codesign and System Synthesis. October 2006.

Zooming in on MEMS designs with EDA

Staff, OpenSystems Media — Thu, 29 May 2008 15:00:00 +0000

Despite the increasing number of MEMS designs in the market today, surprisingly few choices are available for Computer-Aided Design (CAD) and Electronic Design Automation (EDA) tools that support MEMS. I spoke briefly with Sandeep Akkaraju of IntelliSense, one of the vendors that provides MEMS tools, about trends in this market segment and designs that can be made using these tools.

IES: IntelliSense is
filling a unique niche – CAD/EDA for MEMS devices. What makes the MEMS
EDA problem challenging and different from traditional semiconductor EDA tools?

Akkaraju: EDA tools usually deal with one physical domain
– electrical signals. Designing MEMS devices requires handling multiple
physical domains simultaneously. Typical MEMS designs involve coupling of
multiple physics, such as thermomechanics, electrostatics, electromagnetics,
fluidics, and optics.

In addition, the range of materials used in MEMS is much
larger than what is used in electronics. MEMS devices use highly engineered
materials, which take advantage of material responses. For instance,
piezoelectric, piezoresistive, magnetorestrictive, and magnetic materials,
which respond to applied external fields, are increasingly being used in
sensors and actuators. Material physics is a significant consideration in MEMS
design.

The MEMS and microfluidics fields are becoming highly
interdisciplinary. Consider a typical BioMEMS device vis-a-vis an RF MEMS
device. Both require very different skills sets: whereas the BioMEMS device
requires expertise in biochemistry, electrokinetics, and microfluidics, the RF MEMS
device requires knowledge of thermomechanics, electrostatics, electromagnetics,
fluidics, and electronics. Having engineers and scientists with diverse skill
sets work together demands a deep understanding of the mindset and vocabulary
used in each of these disciplines. From a software perspective, this is a
difficult balancing act between being easy to use and powerful enough to tackle
complex interdisciplinary problems.

IES: Tell us about the 3D visualization capability.

Akkaraju: Unlike the semiconductor industry, where CMOS [Complementary
Metal Oxide Semiconductor] is the dominant process flow, most MEMS devices do
not use a standard process flow. The dictum seems to be one device, one
process. Process flow modeling is an important aspect of MEMS design.
IntelliSense provides tools to conceptualize, visualize, and analyze the
manufacturing process flow. Figure 1 shows the fabrication of a MEMS rotary
vibrational drive manufactured in a five-level polysilicon process.

Figure 1

(click graphic to zoom by 2.2x)

Another important aspect is individual process simulation.
Etch simulation is critical to making MEMS work. The industry has developed a
unique set of anisotropic wet and dry etching techniques that are highly design
and process dependent. IntelliSense provides TCAD tools for process simulation
of anisotropic and isotropic wet etching and RIE [Reactive Ion Etching] and ICP
[Inductive Coupled Plasma Etching], allowing process and device engineers to
optimize their layouts and process recipes.

IES: What are the
different types of modeling and simulation capabilities in the tools, and why
are they important?

Akkaraju: IntelliSense provides MEMS CAD/EDA tools for
process, device, package, and system design. IntelliSuite specializes in
coupled-physics modeling – users can combine device physics ranging from
thermomechanics, electrostatics, piezoelectric, piezoresistive, magnetostatics,
electromagnetics, microfluidics, electrokinetics, and biochemistry in an
integrated environment.

As MEMS become increasingly integrated with electronics, MEMS
CAD tools need to seamlessly communicate with tools from different EDA vendors.
IntelliSuite provides a compatibility layer that allows the MEMS CAD and
popular EDA tools from Cadence Design Systems, Mentor Graphics, and Synopsys to
work together in a MEMS-electronics codesign workflow.

IES: What’s one of
the most difficult MEMS layout projects you’ve seen recently, and what were the
keys to making it work?

Akkaraju: As the MEMS industry matures, the number of
electromechanical components per chip is increasing. In cases of
electromechanical arrays, RF MEMS and optical MEMS chip designers are looking
at hundreds to thousands of moving components per chip. From a design
perspective, the interaction between the various components is challenging.

In a recent design, an RF company wanted to integrate arrays
of resonators on a chip. While the individual resonator design shown in Figure
2 was straightforward, the interaction between the resonators in terms of
losses and performance was a challenge to optimize. To draw a parallel, the
MEMS industry is where the semiconductor industry was in the early 1970s, with large-scale
integration becoming practical.

Figure 2: Resonator bank layout screenshot

(click graphic to zoom by 2.2x)

As the number of components grows, it becomes impractical to
tune layouts by hand. Designers are now turning to schematic-driven design
techniques similar to the analog design world.

Another design involved an array of 4,000 fully controllable
micromirrors on a chip. The difficult part of the layout was integrating the
MEMS with a bank of control ASICs. This posed design and layout challenges at the
package and system levels. Chip designers often approach these issues as an
afterthought. This is one of the biggest pitfalls in MEMS, which require an
integrated approach to device, package, and system design.

IES: You mentioned
you’re working on a new release of IntelliSuite. What new capabilities will it address?

Akkaraju: IntelliSuite v8.5 is now in advanced beta testing
at selected sites. We will be releasing the new version this June. The tool
features a number of new capabilities, including:

Integrated electromechanical and electromagnetic analysis for RF MEMS
cosimulation

A new multiprocessor piezoacoustic simulator for fast BAW/SAW [Bulk
and Surface Acoustic Wave] simulations

Layout and 3D model extraction from the schematic

An advanced hexahedral mesh engine (example in Figure 3) that allows
users to go directly from layout to mesh

Figure 3: Mesh engine

(click graphic to zoom by 2.2x)

In addition to the latest version of IntelliSuite, we are
launching Clean Room, a new product line focused on process simulation and
optimization. Clean Room provides an architecture to integrate process-specific
simulators into a detailed process flow. We are also introducing two new
process simulators: a DRIE/ICP etch simulator to simulate deep silicon etching,
a key enabling technology for MEMS, and an atomistic simulation-based
anisotropic etch simulator for accurately simulating wet etches. As part of our
roadmap, we plan to introduce detailed lithography and deposition simulators in
the coming months.

Sandeep Akkaraju is CEO
of IntelliSense Corporation, a Woburn, Massachusetts-based provider of MEMS and
nanotechnology software and tools. His roles include strategic marketing and
sales of software and IP solutions, channel development, and general
management. Sandeep holds a B.Tech from the Indian Institute of Technology, an
MS from Louisiana State University, and an MBA from INSEAD, France.

IntelliSense Corporation
781-933-8098
sakkaraju@intellisense.com
www.intellisense.com

Living on borrowed time: Oregonís 1960s era public safety radio nets ready for upgrades

Mike Zanon, Oregon Wireless — Thu, 03 Jan 2008 15:00:00 +0000

We all get so focused on technology – bytes, algorithms, signal processing, and Electronic Design Automation (EDA) tools – that we sometimes forget that all this is actually used by someone, somewhere. And in many cases, lives depend on it. As we went to press, the Pacific Northwest was battered with record rainfall and flooding throughout the Oregon Coast and Western Washington – a mere 40 miles from where I’m writing this. Lives were lost; homes and businesses were destroyed. First responders reported “Hurricane Katrina-like rescues,” requiring state and federal agencies including police, fire, and the Coast Guard to stretch their radio communications systems to the limit.

Ironically, we recently got a chance to chat briefly with Mike Zanon, program manager of the Oregon Wireless Interoperability Network. When the Oregon State Legislature returns in February 2008 for its biannual session, legislators will be considering the first phases of a massive geographical public safety upgrade estimated to cost $665 million to replace a set of four separate, mostly analog 40-year-old networks. Technologies under consideration include cognitive radio, radio-over-IP, WiMAX, and digital microwave backhauls. The most important criteria? Interoperability, pay-as-you-go incremental upgrades, and of course, mission criticality to save lives. Edited and excerpted remarks follow.

OSP editors weigh in on programmable logic

Chris A. Ciufo, Editor, OpenSystems Media — Tue, 01 May 2007 15:00:00 +0000

Three short commentaries on programmable logic: “My FPGA observations come back to haunt me,” By Chris A. Ciufo, “No more excuses,” By Don Dingee, and “Complexities of using PLDs,” By Jerry Gipper.

My FPGA observations come back to haunt me
By Chris A. Ciufo
No more excuses

By Don Dingee
Complexities of using PLDs

By Jerry Gipper

My FPGA observations come back to haunt me

By Chris A. Ciufo

Recently, several companies blasted me for my complaints in the DSP-FPGA.com editorial “2 Trends I Didn’t See”. Well gosh, here’s where I make amends and set the record straight on FPGA tools and cell phone trends.

Fire One! Zeligsoft took issue with my comments lamenting no Eclipse-like “drag and drop” system creation and validation tools. Their spokeswoman scolded me that “Zeligsoft CE does take a system-level approach, creating and validating Software Defined Radio system deployments.” The company now has partnerships with well known ESL software companies including Green Hills, the Government of Canada, The MathWorks, SCA Technica, Objective Interface Systems, and others. Give ’em a cigar.

Fire Two! Gedae, who touts “effortless transition between design and hardware” lobbed a Letter to the Editor taking me out behind the woodshed concerning multi-core CPUs and system design ease and reuse. They retorted that build-time software partitioning to heterogeneous processors with Gedae aids in “spiral development…with hardware abstraction.” So ok, clearly there’s no need to code FPGAs down at the “metal.”

Fire Three…and Four! By the time you read this, QuickLogic will have just announced their ArcticLink product line of inexpensive, ultra low-power FPGAs for cell phones and other portable doodads. They argue that the FPGA need not replace the system CPU, but will become the intersection between the CPU and the intelligent peripherals like Wi-Fi, DRM, TV Out, and USB. Similarly, Xilinx’s brand new Spartan-3AN includes Flash and specifically targets low power handhelds. Go figure.

So all this feedback implies that my trend predictions were correct: I just didn’t see them.

Comments:

No more excuses

By Don Dingee

Some bosses may have figured out buying car insurance, but maybe not the concept of using FPGAs. I’ve heard various cave-dwelling bosses grunt, “FPGAs are too …”

“…slow.” 10 Gbit SERDES capability is here. So are 550 MHz multiplier clocks. And partial reconfiguration times in microseconds. They’re plenty fast, and getting faster.

“…hard to design.” Sure, if you’ve never programmed a number into your cell phone. Tools are solid and getting better daily – everything from VHDL and C language tools to graphical system design.

“…expensive.” If you’re building 10 or 1,000,000 units, debate away. But for volumes in between, FPGAs present a good life cycle cost – especially considering the time to get a complex ASIC can easily be two years.

“…hard to support.” FPGAs are the “last inch” on many single board computers for flexible I/O. Granted, end customers might try to put something in an FPGA on your board, not be able to get it to work, and call for support. Give customers the right tools and they can usually get it right. Or, your competitors will.

Got a boss grunting these excuses? Have them crawl out of their cave and read this article and more, on this website.

Comments:

Complexities of using PLDs

By Jerry Gipper

Hardware designers have used Programmable Logic Devices (PLDs) for many years, often as glue logic or to fill in feature gaps. As the logic became competitive in performance, capacity, and price, system designers began to make PLDs available for end users to process their own application-specific algorithms. Unfortunately, this was no easy task as the tools to develop, test, and even download these algorithms were not very effective. Tools that could implement the details while the programmer worked at an abstract level became essential.

Several concerns arise as end users implement these devices. PLDs are usually programmed by hardware engineers, many who lack the right experience. The PLDs are programmed like software, with complexity and problems to match, but are ultimately hardware. Plus, current implementation and quality assurance activities may not be adequate for these devices’ complexity.

Luckily, new advances have simplified these tasks. But is it enough, or does the EDA community have more work to do? The logic suppliers claim they have the solutions, but what does the user community have to say? Send us your comments and we will share your experiences.

Increasing signal visibility in FPGA-based prototypes

George Blakewell, Novas — Fri, 13 Apr 2007 15:00:00 +0000

Visibility enhancement techniques for FPGA prototype and emulation of ASIC systems apply automation to the process of locating, isolating, and understanding the causes of errors. A small amount of upfront logic implementation provides silicon data access, while RTL mapping and data expansion enable full visibility using just the essential signal data. Combined with sophisticated debug engines, the net result of these techniques is faster debug of functional errors and system verification.

The benefits of FPGA coprocessing

Tom Hill, Xilinx — Wed, 01 Nov 2006 15:00:00 +0000

The Xilinx ESL Initiative brings the horsepower of an FPGA coprocessor closer to the reach of traditional DSP system designers.