feature article
Subscribe Now

Leveraging On-Chip Debug for VME

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.

Element #of elements Percentage
LogicCell 5584 33%
Pin 140 28%
RAM block 212992 100%

Table 1. Implementation statistics

Note that all RAM blocks are used to record. Longer recording is still possible if needed.

Contact

Via Europa, 1, 20141 NERVIANO -(M I) ITALY
Tel : +39(0)331.582.570
e-mail : christian.riva@galileoavionica.it
Website : http://www.galileoavionica.it

For US and Canada please call TEMENTO distributor & support:
Inicore Inc., 5600 Mowry School Road, Suite 180, Newark, CA 94560
Tel: 510 445 1520, Fax: 510 656 0995
e-mail: info@inicore.com

For Europe please call:
TEMENTO SYSTEMS, 60 rue Lavoisier, F 38330 MONTBONNOT
Tel: +33 456 52 60 40
Fax: +33 456 52 60 01
e-mail: support@temento.com

Leave a Reply

featured blogs
Oct 26, 2020
Last week was the Linley Group's Fall Processor Conference. The conference opened, as usual, with Linley Gwenap's overview of the processor market (both silicon and IP). His opening keynote... [[ Click on the title to access the full blog on the Cadence Community s...
Oct 23, 2020
Processing a component onto a PCB used to be fairly straightforward. Through-hole products, or a single or double row surface mount with a larger centerline rarely offer unique challenges obtaining a proper solder joint. However, as electronics continue to get smaller and con...
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...
Oct 23, 2020
Any suggestions for a 4x4 keypad in which the keys aren'€™t wobbly and you don'€™t have to strike a key dead center for it to make contact?...

featured video

Demo: Inuitive NU4000 SoC with ARC EV Processor Running SLAM and CNN

Sponsored by Synopsys

See Inuitive’s NU4000 3D imaging and vision processor in action. The SoC supports high-quality 3D depth processor engine, SLAM accelerators, computer vision, and deep learning by integrating Synopsys ARC EV processor. In this demo, the NU4000 demonstrates simultaneous 3D sensing, SLAM and CNN functionality by mapping out its environment and localizing the sensor while identifying the objects within it. For more information, visit inuitive-tech.com.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured paper

Designing highly efficient, powerful and fast EV charging stations

Sponsored by Texas Instruments

Scaling the necessary power for fast EV charging stations can be challenging. One solution is to use modular power converters stacked in parallel. Learn more in our technical article.

Click here to download the technical article

Featured Chalk Talk

Selecting the Right MOSFET: BLDC Motor Control in Battery Applications

Sponsored by Mouser Electronics and Nexperia

An increasing number of applications today rely on brushless motors, and that means we need smooth, efficient motor control. Choosing the right MOSFET can have a significant impact on the performance of your design. In this episode of Chalk Talk, Amelia Dalton chats with Tom Wolf of Nexperia about MOSFET requirements for brushless motor control, and how to chooser the right MOSFET for your design.

More information about Nexperia PSMN N-Channel MOSFETs