When a design is simulated, the level of verification is a function of how accurately the simulation vectors mimic the operating environment. Designs that are simulated with vectors that accurately reflect board conditions can detect most bugs. Modeling such conditions is not easy, however, and most vectors offer only an approximation of the actual stimulus. Thus, in most cases, simulation offers only incomplete verification.
Hardware debuggers represent the ultimate system verification tool. Unlike simulators, debuggers show designers what their logic is actually doing inside the device running in the system at full speed. When using a hardware debugger it is crucial that you, as the designer, capture the precise data needed to discover bugs and verify system behavior. Not only do you need to locate the logic transitions around a certain event, but you must also track bugs that may be rare events and ensure they are trapped for closer examination.
In order to maximize efficiency, a debugger must offer probing – and display results – at the Register Transfer (RT) level, because that is the version of the design that is most familiar to the engineer. The debugger must also be able to capture any logic event of any duration or frequency and gather data based on that event. Triggering must be powerful enough to traverse a series of events so as to arrive at the particular event that is the trigger. Finally, the debugger must be able to detect events across multiple clock domains – such as metastability – that result in transitions within a period.
The Identify RTL Debugger from Synplicity provides these capabilities and many others. The tool consists of an Instrumentor to add probes and a Debugger to set trigger values and display results. The Identify software offers designers a view of logic behavior inside an FPGA operating within the system. It also offers a highly sophisticated set of trigger mechanisms that can be used to isolate just those events that are germane to a particular problem.
The following sections focus on the complex triggering capabilities of the Identify Instrumentor and Debugger that enable you to find an event or series of events that are occurring in your design. Further sections describe techniques for using the Identify product with logic analyzers to exchange triggers and augment the capabilities of both tools in system-level debug.
Triggering across clock domains
In today’s FPGAs, multiple clocks are frequently used as these devices come with numerous dedicated clock buffers. In these multi-clock systems, it is common to encounter timing problems related to clocking data between domains. Such problems include metastability, failure to meet setup or hold times, and dropped data. Detecting these often subtle problems is usually difficult. The problem may not appear in logic simulation at all, and it may be detected in debug only by over-sampling within a domain or by triggering from one domain and sampling in the other.
Cross-triggering is a technique that enables triggering upon an event in one domain and sampling an event in another. As shown in Fig 1, the Identify product allows the trigger logic of one domain to drive and enable the trigger in another. You can use cross triggering to view the timing of events that cross domains. You can also use it to see events that occur within a clock period by over-sampling the period with a faster clock.
1. Cross-trigger example.
Sampling modes control the way in which data is added to the buffer when a trigger condition is reached. These modes allow you to sort data inflows according to the mode, and to increase the efficiency of the buffer by storing only relevant data.
The Identify software offers four sampling modes: Normal, Qualified Fill, Qualified Interrupt, and Always Armed.
The Normal mode fills the buffer completely in a single trigger event. Subsequent triggers are then ignored unless the debugger is run again.
In the Always Armed sampling mode, the buffer fills on every trigger until the debug run is stopped (the debug run is stopped using the Stop icon).
The Qualified Fill mode stores only a single sample on each trigger. The buffer will contain only events that caused a trigger and will continue until the buffer is full or when sampling stops.
Finally, Qualified Interrupt sampling is similar to the Qualified Fill mode, except that sampling will continue until the sampling is interrupted. If sampling continues after the buffer is full, old data will be overwritten.
Trigger modes control the way in which data is added to the buffer upon reaching a trigger condition. There are four operating modes: cycles, events, pulse width, and watchdog.
The cycles mode triggers on the number entered in the Value field representing the number of clock cycles after the condition occurs.
The events mode triggers on the Nth instance of a trigger condition. In this mode, the Value field specifies the instance.
The pulsewidth mode triggers after the trigger condition has remained active for N clock cycles.
And, last but not least, the watchdog mode triggers when the condition has not been active for N clock cycles since the last trigger event.