Dr. Neal Stollon
First Silicon Solutions (FS2)

It is apparent to the most casual observer that FPGAs are increasingly becoming viable candidates for many SoC applications. The introduction of true million plus system gate FPGA products, along with a plethora of IP options, both hard and soft, have made FPGAs the platform to beat for all but the highest performance or volume designs. The flip side of this high performance capability is that FPGA designs now have levels of complexity on par with many SoCs, but often without the time, budget, or resources traditionally associated with SoC verification.

For many typical system FPGA applications, silicon verification must address the run control and in-system analysis of embedded processors, their coordinated operation with the larger numbers and complexities of secondary application specific cores, and buses that provide on-chip communication. System analysis considerations include both the initial concerns of whether everything is designed in correctly, and later concerns of identifying, understanding and optimizing performance related issues. These issues can include processor code debug and tweaking, as well as core to core communication efficiency, latency, conflicts, etc. that have a direct impact on system operation.

Simulation is always an important part of the development flow, however just as important is the ability to see inside the hardware itself during prototyping and systems level verification…and this is one area where FPGAs have a significant leg up on other SoC alternatives. Designers can freely incorporate debug features into a design with relative freedom to scale it back or remove it later. This is a valuable option, since debugging system problems in hardware in many cases devolves to dual axioms of visibility – it is difficult to fix what you cannot see, and difficult to understand what you can’t see in context.

One approach to debug for complex systems is adding On-Chip Instrumentation (OCI ®) to the design to improve visibility into the system. OCI, in essence, is an IP-subsystem for monitoring and tracing embedded signals, either through buffering to a JTAG port or streaming to a dedicated test port for viewing on a PC.

Basically OCI debug capabilities break down into two major types:

— General purpose logic analyzer blocks that support trace and analysis of any user defined signal

—In-system analyzer instrumentation blocks that are specifically designed for debug control and support of specific processor or other cores

Logic analyzer approaches are widely used for debug of FPGA logic analysis, where it has the sometimes significant advantage that it can be removed from the design when analysis is finished (- but is it ever finished? ;)

Figure 1 shows a multi-core architecture (dual processors, memory interfaces, and custom IP tied to a common on-chip bus) that is very feasible with current higher end FPGAs. It also shows logic and processor analysis instrumentation that could be added for more effective system debug. Shown in additional level of detail is Bus Navigator instrumentation, a type of logic analyzer used for debug of embedded buses.

Figure 1- Multi-Core Debug Architecture

Looking at the individual components in Figure 1 – In-System Analyzer (ISA) is an FS2 term for debug blocks providing processor specific run control, monitoring of hardware and software breakpoints for triggering, and real-time trace of instruction and data. Typical ISA solutions include a range of widely used processors on FPGAs (including Actel Core8051, Altera Nios, and Quicklogic QuickMIPS) as well as custom processor debug services.

In most FPGA designs, processors are one of several digital subsystems with debug requirements. Some FPGA venders provide their own in-house Logic Analyzer capabilities, (Xilinx ChipScope and Altera SignalTap being well known examples) while others tend to third party solutions. As an example, Actel, Quicklogic and Atmel use FS2’s Logic Navigator for their on-chip FPGA debug. Logic Navigator is a fully synthesizable OCI designed to support a range of FPGA and ASIC platforms with higher end logic analyzer functions, including:

— Automated integration of user defined trace signals into synthesizable models

— Trace support from 2 signals x 64 cycles to 256 signals by 64K trace cycles (assuming an FPGA with that much on-chip RAM)

— Combination or sequential triggering on logic edges or levels

— Sequential triggers based on state-based and counter-based events

— Optional timestamping for multi-instrument synchronization and time marking

— An optional JTAG controlled general-purpose register

Other types of analyzers, including the FS2 Bus Navigator™ address more bus centric analysis. Bus Navigator variants include AMBA and OCP, and can be customized for other buses. Some differences in Bus vs. Logic Analyzer features typically include:

— Direct cross trigger interfaces to other debug blocks -- for low latency triggering of processor debug based on bus status or bus trace start and stop based on processor operations

—Trace pipeline option to synchronize and align command and response portions of a given bus cycle to allow more intuitive triggering and software analysis display

— Optional dropping of idle and “not ready” cycles from bus trace to conserve trace RAM resources and keep the trace more readable, while the timestamp ensures synchronization

Figure 2- Bus Navigator Trace Display

Some features that users should consider in integrating instrumentation:

Flexible On-chip Triggering, Trace, Performance Analysis –. It is important to access signals you need, but only when they are doing what you care about. On-chip performance analysis monitors and only sends summary information -- as an example, how many times a signal was stalled, rather than making you look for each occurrence.

Interoperability and Cross Triggering of all levels of On chip Debug – Unless part of the system works in isolation neither should a debug solution. Any system level debug solution should support communications between all other instrumentation blocks in a design.

Integration with other Debugger/Verification Tools – Most processor software tool chains have debugger features such as correlation of traced instructions to source code. Similarly logic analysis tools should allow importing trace data into the simulation tools for comparing actual vs. simulated logic information.

Keeping pace with Internal Signal Speeds and maintaining reasonable Gate Size – The last thing you want is your debug blocks adding to timing closure issues or pushing to the next size FPGA or package. Debug instrumentation can be small and ideally have low gate delay.

Configurable to System Needs – You don’t want big debug features for a limited amount of debug visibility on a smaller FPGA. Likewise you don’t want a limited solution too small for your problem. Configurable debug solutions should allow precise control over debug resources.

On Chip Instrumentation is not just IP– It is only as useful as how the information is provided and the supported tool architecture. Standards based drivers and APIs have obvious advantages for customization and integration – FS2 as an example, extensively uses Tcl/Tk, MDI, XML, and Eclipse for its instrumentation tools.

Conclusion

Approaches to large SoC FPGA debug and analysis are undergoing a significant evolution, in which the addition of new types of on-chip instruments is an integral part. The ability to integrate the debug of processors and buses is a good example of the types of on-chip analysis capabilities that will routinely be required for leading edge FPGA platforms.

First Silicon Solutions has been a leader on this front since 1998 and works closely with many of the market leaders to provide best-in-class Logic and Bus Analysis and processor ISA IP and tools to enable FPGA SoC debug and analysis solutions.

FS2, OCI, Logic Navigator, System Navigator and Bus Navigator are trademarks of First Silicon Solutions, Inc. All other marks are property of their respective owners.

About the author: Dr. Neal Stollon (neals@fs2.com) is Director of Technical Marketing and Program Manager of systems level products for First Silicon Solutions (www.fs2.com). He has over 20 years digital design, EDA and processor development experience at Texas Instruments, LSI Logic, Alcatel, and others. Stollon has a Ph.D in EE from Southern Methodist University, is a Professional Engineer, and has written over 25 papers, including 4 papers for DesignCon in 1999-2002. He holds seven patents.

May 26, 2005

[back to top]

Comments on this article? Send them to comments@fpgajournal.com