Introduction

Galileo Avionica needed an easy-to-use VME BUS monitor that could be used by both hardware and software engineers working on VME-based projects. Using a plug-in VME board with an Altera FPGA, embedded DiaLite virtual instrumentation from Temento Systems, and a TCL/TK-based custom human interface, an innovative solution was crafted that allows simple, multi-use analysis of the VME bus by engineers from different disciplines with widely varied levels of experience and expertise.

This article describes how DiaLite Instrumentation (DLI) was used to build a custom tool by taking advantage of the capability to drive DiaLite via TCL scripts. This capability allowed Gallileo Avionica to use the DiaLite server as the engine for their bus monitor with specific human interfaces developed with TCL/TK. This interface provides interactivity adapted to the language and skill level of a specific user. We will show how to build an embedded VME BUS Monitor whose interface can be for either software engineers or hardware engineers. The monitor will then allow the end-user to describe the triggering and the display of the bus activity according to his own concept of the VME BUS behavior without having to understand concepts such as VHDL code, which may not be in his area of expertise.

Key issue

Our goal was to ease the co-debug activity by providing a tool that could be used on VME-based equipment by both hardware and software engineers, with easy display for both of them. From a hardware perspective, all the required recording and triggering can be achieved using DLI, but the definition of a physical test strategy is not easy or intuitive for a software user. All basic instruments as well as the Instrumentation TAP (TAPI) controller exist in DLI, and this example takes advantage of their performance. Using this approach, the assembly of the VME monitor was described once using a graphical tool, then saved as a project. The complexity of the implementation is hidden from the end-user by providing him with a specific interface written in TCL/TK. According to this basic definition, two observation modes were established. The first was used to record the electronic signals present on the bus after triggering on signal edges or patterns. The second one was used to record and list VME bus transactions after triggering on data transferred or address ranges reached. In order to completely trace a VME bus transaction, a timing calculation has been added that takes advantage of the over-sampling capability of DiaLite. This provides assertion-checking capability in the electronic interface and performance analysis capability in the software interface by measuring elementary transaction duration. This tool was required to fit within one FPGA device and needed to be accessible via a simple JTAG BUS.

Figure 1. System implementation

Monitoring instrumentation approach

A board containing an FPGA was plugged onto a VME bus to host the monitor. The FPGA’s job was to read all interesting signals to be observed in real-time. The FPGA contains DLIIP modules for both signal-oriented acquisition and transaction-oriented acquisition. The DLI server communicates with the board via a dedicated JTAG port. It also manages IP modules. A TCL script extracts data from the DLI server to be displayed. The approach is shown in Figure 1.

The FPGA configuration was described using VHDL. The top level entity contains all VME signals to observe. The top level architecture contains small processes to sample observed signals, create enable signals according to VME signal transients used by DLI instruments, or compute time durations.

Figure 2. VME Bus monitoring graphic user interface

Graphic user interface

Since DLI is a completely scriptable tool delivered with a set of TCL commands, DLI can be interfaced with a TCL/TK GUI. The application developed by Temento Systems for Galileo Avionica was fully developed using this feature. The client GUI described in Figure 2 sends TCL commands to a DLI server via DCOM.

Selecting from the menu the hardware acquisition (HW_Acquisition button) or a software acquisition (SW_Acquisition button), the user gets access to parameters in dialog windows to configure instrument modules (which will send appropriate TCL commands to DLI engine).

The signal oriented acquisition mode

This mode of bus monitoring is a hardware-debug-oriented acquisition. The acquisition result consists of recording sampled VME signals after a trigger event occurred. The trigger event occurrence may be edge, edge sequence, pattern, pattern sequence, edge and pattern, edge and pattern before T max , edge and pattern after T min triggering. The signal-oriented acquisition is based on a small Elementary Module (EM) including 5 DLI instruments. This module is depicted in Figure 3.

Figure 3. Pattern and edge detector module

The EM is composed of 2 Logical Equation Modules (LEMs), 2 Parallel Triggers (PTs) and a Serial Trigger (ST). A LEM allows us to choose which detector – edge or pattern we want to use. A second LEM permits us to start acquisition as soon as a previous EM or an external signal (A logic analyzer output for example) is enabled. Two instruments – a PT and a ST – are combined to trigger on edges. The PT is used as a multiplexer to choose one of the observed VME signals. The ST then triggers according to this signal transition. Another PT reads all observed VME signals to trigger according to their patterns. The application developed by Temento Systems for Galileo Avionica cascades 5 EMs to detect up to 5 edges or pattern sequences. The final EM stage is modified to add some specific functionality such as edge and pattern, edge and pattern before T max, and edge and pattern after T min triggering. To do this, we add 3 signals to the PT used as a pattern detector. The first one indicates when the min time is reached, the second one reports when the max time is reached, and the third indicates when an edge is detected. A History Register (HR) module is connected to the last EM output to record VME signals. So, once the expected pattern and/or edge are detected, a message is displayed in the console window, and a waveform viewer appears where a vertical marker shows the trigger event (see Figure 4).

Figure 4. Waveform viewer output after edge triggering

The transaction-oriented acquisition mode

The transaction-oriented acquisition mode of monitoring is used for software debug. The acquisition result consists of a list of VME bus operations after a trigger event occurrence. Operations may be Read, Write, Read/Modify/Write (RMX), Read Block Transfer (BLT), Write Block Transfer (BLT), Address Only (ADO) and interrupt acknowledge cycle. Only 3 instruments (cf. Figure 5) realize the transaction oriented acquisition.

Figure 5. Transaction oriented acquisition modules

The LEM is used as the PT enable. It is enabled on a falling edge on VME DTACK or BERR signals. The PT triggers in two manners. On one hand, the PT recognizes events on address, data and the master broadcast code on VME signals. On the other hand, the trigger is forced on the falling edge of the BERR signal. The HR records VME signals and the duration time. After the defined trigger event, we download data stored in HR to format the output file. The output file format is described in Figure 6.

Figure 6. Output file format

All information is thus gathered for a seamless software debug. First, we see the VME bus operation and the type of addressing that the master has performed: 16, 24, 32, 40, 64 bits. Second, we see the address and the data on the bus. Third, we see the index of the bus operation. Finally, we see the number of clock periods taken for the operation (If using100 MHz over-sampling clock, this means x10 nS increments).

Conclusion

An FPGA equipped with embedded debugging modules such as DLI technology can be used to build a powerful, specific debug tool with a well-adapted operator interface.

Driving DLI via TCL scripts and using TCL/TK for a dedicated easy-to-use interface, this application provides triggering and recording on VME bus signals exactly as Galileo Avionica has specified it.

This application to debug VME bus transactions is composed of 32 IP modules and has been built from a project synthesized on a unique dedicated ALTERA FPGA (EP20K400). Implementation statistics are summarized in Table 1.

Table 1. Implementation statistics