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
May 30, 2023
Explore our 2022 environmental, social, and governance (ESG) report to explore our sustainable business practices and our progress in building a smart future. The post Synopsys 2022 ESG Report: Building a Smart Future Together appeared first on New Horizons for Chip Design....
May 25, 2023
Register only once to get access to all Cadence on-demand webinars. Unstructured meshing can be automated for much of the mesh generation process, saving significant engineering time and cost. However, controlling numerical errors resulting from the discrete mesh requires ada...
May 8, 2023
If you are planning on traveling to Turkey in the not-so-distant future, then I have a favor to ask....

featured video

Shift-left with Power Emulation Using Real Workloads

Sponsored by Synopsys

Increasing software content and larger chips are demanding pre-silicon power for real-life workloads. Synopsys profile, analyze, and signoff emulation power steps to identify and analyze interesting stimulus from seconds of silicon runtime are discussed.

Learn more about Synopsys’ Energy-Efficient SoCs Solutions

featured contest

Join the AI Generated Open-Source Silicon Design Challenge

Sponsored by Efabless

Get your AI-generated design manufactured ($9,750 value)! Enter the E-fabless open-source silicon design challenge. Use generative AI to create Verilog from natural language prompts, then implement your design using the Efabless chipIgnite platform - including an SoC template (Caravel) providing rapid chip-level integration, and an open-source RTL-to-GDS digital design flow (OpenLane). The winner gets their design manufactured by eFabless. Hurry, though - deadline is June 2!

Click here to enter!

featured chalk talk

Industry 4.0: From Conception to Value Generation
Industry 4.0 has brought a lot of exciting innovation to the manufacturing and industrial factories throughout the world, but getting your next IIoT design from concept to reality can be a challenging process. In this episode of Chalk Talk, Adithya Madanahalli from Würth Elektronik and Amelia Dalton explore how Würth Elektronik can help you jump start your next IIoT design.
Apr 17, 2023
5,627 views