PC to NanoBoard Communications

PC to NanoBoard Communications

Version (v3.0) Mar 03, 2008 1

This article looks at the technology used by Altium Designer to communicate between a NanoBoard – such as the Desktop NanoBoard NB2DSK01 – its daughter board FPGA and the active devices such as processor cores that exist inside the FPGA during circuit development.

The system makes extensive use of communications technology defined by IEEE standard 1149.1 – commonly referred to as JTAG. While it is not necessary to intimately understand the workings of JTAG in order to use the system, an overview of this technology will give you a better understanding of the architecture of the system – in particular, how the various views presented in the system relate to the physical and ‘soft’ devices present on the NanoBoard and in your design.

For information on the Desktop NanoBoard NB2-DSK1, refer to the document TR0143 Technical Reference Manual for Altium's Desktop NanoBoard NB-DSK01.

For information on the older NanoBoard-NB1, refer to the document TR0102 NanoBoard Technical Reference Manual - NB1.

The PC to NanoBoard Connection

Depending on the version of NanoBoard being used, it is connected to your PC using either a parallel or USB connection. When you start Altium Designer, a driver is loaded that configures the relevant port (parallel or USB) to run as a single multiplexed JTAG link between the NanoBoard and the PC.

There are in fact multiple JTAG chains present on the NanoBoard. A sophisticated controller on the NanoBoard – the NanoTalk Controller – handles the job of multiplexing these JTAG chains for transmission via the parallel or USB link, as well as handling the routing of the various JTAG chains when multiple NanoBoards are connected together.

We’ll discuss the various chains and the role of the NanoTalk controller in more detail later in this article. First lets take a brief look at how JTAG works.

JTAG Overview

Back in 1985 in response to the increasing density of then new electronics packaging technologies, test engineers from the major silicon vendors in Europe formed the Joint European Test Action Group and set about forming proposals for a new way of testing electronic devices mounted on a printed circuit board. In 1986 the group expanded to include members from North America and was renamed the Joint Test Action Group. The findings and recommendations of this group were used as the basis for the Institute of Electrical and Electronic Engineers (IEEE) standard 1149.1: Standard Test Access Port and Boundary Scan Architecture. This standard is commonly know by the acronym JTAG, derived from the name of the group that formulated it.

Summary This article gives an overview of the technologies used to facilitate communications between a NanoBoard and Altium’s LiveDesign-enabled design software running on the PC.

AR0130 PC to NanoBoard Communications

Version (v3.0) Mar 03, 2008 2

Physical JTAG compliant component

CORELOGIC

Boundary scan cells

TAPTest Access Port

TDO

TMS

TCK

TDI

Figure 1. JTAG compliant device

The initial purpose of the JTAG standard, also referred to as Boundary Scan, was to set out a system that could be built into an IC to allow testing of the physical connection of the pins of the chip without the need to connect probes to the pins. It was conceived as an alternative or replacement for traditional bed-of-nails testing, which can be difficult, if not impossible, on many modern high-density surface mount boards.

On a JTAG-compliant device, each physical pin of the device is connected to the underlying logic via a small piece of circuitry called a Boundary Scan cell. Each cell is configured to be able to monitor the value of the device pin, and each cell is connected to its adjacent cells to form a serial chain allowing data to be extracted from the Boundary Scan cells without having to connect to each individual pin.

The full JTAG implementation requires only four pins on a device – TDI to load serial data in, TDO to extract serial data out, the TMS control line and the TCK JTAG clock, as shown in Figure 1.

The Test Access Port

The heart of JTAG communications is the Test Access Port or TAP. The TAP defines a set of registers and a controller that are used to define the operation of the JTAG interface.

There are two types of registers associated with boundary scan. Each compliant device has one instruction register and two or more data registers.

The instruction register holds the current instruction. Its content is used by the TAP controller to decide what to do with signals that are received. Most commonly, the content of the instruction register will define which of the data registers signals should be passed to.

There are three primary data registers:

• Boundary Scan Register (BSR) – this is the main testing data register and is formed by the JTAG cells connected between the core logic and the pins of the device. It is used to move data to and from the ‘pins’ on a device.

• BYPASS – this is a single-bit register that passes information from TDI to TDO. It allows other devices in a circuit to be tested with minimal overhead.

• IDCODES – this register contains the ID code and revision number for the device. This information allows the device to be linked to its Boundary Scan Description Language (BSDL) file. The file contains details of the Boundary Scan configuration for the device.

Other data registers may be present, but they are not required as part of the JTAG standard.


Version (v3.0) Mar 03, 2008 3

The TAP Controller

The operation of the JTAG port is controlled by a 16-step state machine called the TAP controller, shown in Figure 2 below.

Shift_DR

Exit1_DR

Test_LogicReset

0

Run_Test/Idle

Capture_DR

Select_DR

Pause_DR

Exit2_DR

Update_DR

1

0

0

0

0

1

0

1

1

1

0

1

Shift_IR

Exit1_IR

Capture_IR

Select_IR

Pause_IR

Exit2_IR

Update_IR

0

0

0

0

1

0

1

1

1

0

1

0 1 1 1

1 001

Figure 2. State machine diagram for the TAP controller

It can be seen from Figure 2 that all states have two exits, so all transitions can be controlled by the status of the TMS line, which is sampled on the rising edge of the JTAG TCK clock input. The two main state paths allow for setting or getting data from either the Instruction register (IR) or the active data register (DR). The active data register is determined from the previously loaded value in the Instruction register.

While the JTAG standard describes a number of instructions that can be implemented, only the following three are mandatory:

• BYPASS – TDI and TDO are connected together via the bypass register.

• EXTEST – TDI and TDO are connected via the Boundary Scan register (BSR). The device’s pin states are sampled with the capture_dr JTAG state and new values are shifted into the BSR with the shift_dr state; these values are then applied to the pins of the device using the update_dr state.

• SAMPLE/RELOAD - TDI and TDO are connected via the Boundary Scan Register (BSR). In this case, however, the device is left in its normal functioning mode and BSR can be scanned to take a sample of the pin states. The instruction is also used to preload test data into the BSR prior to loading an EXTEST instruction.

Chaining JTAG Devices Together

One of the strengths of JTAG is the ability to connect devices together to form a JTAG chain. The TDO of one device is connected to the TDI of the next device, with TMS and TCK being common to all devices, as shown in Figure 3. Data can then be read or loaded from any register of any device in the chain by appropriate manipulation of the TMS line.


Version (v3.0) Mar 03, 2008 4

TAPTDO

TMSTCK

TDI

TAPTDO

TMSTCK

TDI

TAPTDO

TMSTCK

TDI

Figure 3. JTAG devices can be connected together for form a single JTAG chain

To read or write to a particular device, other devices in the chain can be put into bypass mode, allowing for large numbers of devices to be chained together without seriously degrading the performance of the JTAG communications.

The Nexus Standard

While the JTAG standard was originally designed to allow physical testing of devices during PCB assembly, it has been adapted for a variety of uses, most notably to provide in-circuit programmability to FPGAs.

Another use of JTAG has been to provide communications for the implementation of on-chip debugging functions in processors. To this end a group known as the Nexus 5001 Forum (formerly the Global Embedded Processor Debug Interface Consortium) have developed IEEE/ISTO 5001: Standard for a Global Embedded Processor Debug Interface. This standard, which we will refer to as the Nexus standard, leverages the pin interface established by the JTAG standard and adds specific protocols and API features designed to address processor debugging needs.

A complete description of the Nexus standard is beyond the scope of this article. You can download the full standard from the Nexus 5001 Forum web site at www.nexus5001.org.

Nexus Components

The platform makes use of the Nexus standard by using it as the basis for communications with the ‘soft’ processor cores and virtual instruments used within the system. These devices, which are provided in pre-synthesized form ready for implementation inside an FPGA, include a JTAG port and use features of the Nexus standard to enable On Chip Debug or Instrument Control layers within the device, as shown in Figure 4.

Core Component - MCU

MCULOGIC

On ChipDebug System

TAPTest Access Port

TDO

TMS

TCK

TDI

Virtual Instrument

Instrumentlogic

InstrumentControl System

TAPTest Access Port

TDO

TMS

TCK

TDI

Figure 4. Nexus components

The advantage of using the JTAG and Nexus standards in the implementation of FPGA-based devices is that these devices can be chained together and accessed from the design environment with little pin overhead on the FPGA. Also, devices can be chained through multiple FPGAs, allowing a complete view of all controllable devices in a larger, multiple FPGA-based system.

http://www.nexus5001.org/�


Version (v3.0) Mar 03, 2008 5

JTAG Chains in the System

When a design is created and downloaded to the physical FPGA device – resident on the daughter board currently plugged into the NanoBoard – several JTAG chains are created to facilitate communications between the various devices within the system. Within Altium Designer, interaction with these chains is performed through the Devices view (Figure 5), accessed by choosing View » Devices View from the main menus.

Figure 5. Various JTAG chains presented in Altium Designer's Devices view.

The Devices view presents three JTAG chains, which collectively show all JTAG-compliant devices attached to the system. Each device in each chain is represented by its appropriate icon. Controls for a device can be accessed through interaction (double-click, right-click) with its icon, giving full control over all JTAG devices in the system. The following sections take a closer look at the three chains presented in the Devices view.

The NanoBoard Chain

The NanoBoard chain (Figure 6) includes an icon for each powered-up NanoBoard detected by the system. This chain essentially detects the presence of each NanoBoard's controller device, or NanoTalk Controller. As a result it is often referred to as the NanoBoard Controllers chain.

Controls associated with each icon allow you to communicate and control various on-board SPI-based devices, such as the programmable clock and the SPI Flash memory.

Figure 6. The NanoBoard chain.


Version (v3.0) Mar 03, 2008 6

The Hard Devices Chain

The Hard Devices chain (Figure 7) shows all target programmable devices detected by the system. This includes FPGAs resident on daughter board plug-ins, as well as all JTAG devices found on any user boards connected to a NanoBoard in the configuration. Any discrete processors will also be presented in this chain.

The NanoTalk Controller automatically detects and configures appropriate devices so that they form a continuous chain using their physical TDI and TDO JTAG lines. If a physical device (typically on a user board) is not supported by the system, it will appear in the chain as a Generic JTAG device. To ensure continuity of the Hard JTAG chain, a corresponding Boundary Scan Description Language (BSDL) file must be attached to the device, the contents of which are used by the system to correctly configure the JTAG chain. Should no BSDL file be available, the correct instruction length for the device can be set, ensuring JTAG chain continuity and communications with remaining devices in the chain.

For more information on Generic JTAG devices, see the section Generic JTAG device support, a sub-section of the User Board headers resource in the document TR0143 Technical Reference Manual for Altium's Desktop NanoBoard NB2DSK01.

Each physical device in the chain that is programmable from Altium Designer will have a Process Flow associated to it. The stages in this flow are used to interactively compile, synthesize, build and ultimately program the device, all from within the Devices view.

Figure 7. The Hard Devices chain.

The Soft Devices Chain

The Soft Devices chain (Figure 8) shows all Nexus-enabled devices, such as 'soft' processors and virtual instruments, found in each FPGA design project targeting a programmable device in the Hard Devices chain. When you use Nexus components in your design at the schematic level, the system automatically connects the TDI and TDO lines of each component's JTAG port, to form a continuous JTAG chain.

Figure 8. The Soft Devices chain.

Note: The Soft Devices chain only becomes populated with the Nexus-enabled devices for a design, once that design has been compiled.

For more information on the Devices view, including access of device controls, refer to the application note AP0103 Processing the Captured FPGA Design.

Bringing the Chains Together – the NanoTalk Controller

The NanoBoard includes Altium's proprietary communications protocol, referred to as NanoTalk. This protocol defines and provides a communication path between a PC running Altium Designer and one or more NanoBoards. NanoTalk is implemented as part of the firmware running in an FPGA device on the motherboard. This device is commonly referred to as the NanoTalk (or NanoBoard) Controller.


Version (v3.0) Mar 03, 2008 7

The NanoTalk Controller manages the routing of the multiple JTAG chains that communicate with both the physical devices on the board and the soft devices contained within your design running on the target daughter board FPGA. It also handles the multiplexing of these various chains for transmission to the software running on the PC, over the parallel or USB link. This single JTAG link is demultiplexed by the system software.

Figure 9. illustrates the various JTAG chains, and the single JTAG link to the PC, for the Desktop NanoBoard NB2DSK01.

Altium Designer NanoBoard NB2-DSK1

Daughter BoardFPGA

VirtualInst.Processor

PeripheralBoard A

PeripheralBoard B

PeripheralBoard C

User BoardA

User BoardB

NanoTalkController

SPI Devices

JTAG Link Hard

Soft

Figure 9. The NanoTalk Controller multiplexes the various device chains to present a single JTAG link to the PC.

NanoTalk has been designed to be plug-and-play, in the sense that all NanoTalk communications paths automatically configure when multiple NanoBoards are daisy-chained together, or user boards are attached to a NanoBoard. Altium Designer scans the NanoTalk system and automatically maintains a map of all Hard JTAG and Soft JTAG devices.

Chaining Multiple NanoBoards

Each NanoBoard contains NanoTalk Master and Slave connectors that allow multiple NanoBoards to be daisy-chained together. The Hard and Soft JTAG chains are passed between boards using a 10-way IDC cable – from the Slave connector on the first board to the Master connector on the next. Under the management of the NanoTalk Controller, these chains are kept continuous, with both chains sent out from and received back by, the Master NanoBoard in the configuration – the one connected to the PC and ultimately the Altium Designer software.

Figure 10. Two Desktop NanoBoard NB2DSK01s chained together.


Version (v3.0) Mar 03, 2008 8

Figure 11. Chaining a Desktop NanoBoard NB2DSK01 and a NanoBoard-NB1 together.

When multiple NanoBoards are present, the Hard Devices chain will show all target FPGAs on all boards. From the Devices view you can assign design projects to each FPGA in the chain and select which FPGA is active for download.

This ability to chain NanoBoards together allows the development of complex multiple FPGA systems, spread over multiple circuit boards.

Connecting User-Developed Boards

As well as chaining multiple NanoBoards together, you can also attach your own board to the NanoBoard for inclusion into the system. Up to two user boards can be connected to each NanoBoard in the system. This enables you to extend Altium's LiveDesign methodology to the design and debugging of your production PCB!

No special control circuitry is required on a connected user board. Simply chain the JTAG ports of the compliant devices on your board – both the physical ports and the 'soft' ports established to connect with the Nexus-enabled devices inside a device (processors, virtual instruments) – and connect both chains to a 10-way header for connection to the NanoBoard.

When a user board is present, the NanoTalk Controller routes the appropriate TDO and TDI signals to form part of the overall Hard and Soft device chains for the NanoBoard. Icons for all devices on the user board will be presented in the Devices view, allowing you to interact with these devices.

Figure 12. A production PCB attached to a Desktop NanoBoard NB2DSK01.


Version (v3.0) Mar 03, 2008 9

Conclusion

The NanoBoard is an integral part of Altium’s LiveDesign-enabled design system and forms a sophisticated reconfigurable platform for design implementation and debug. The system makes extensive use of the JTAG and Nexus standards to provide flexible and extensible communications between the design software, the NanoBoard and the design running inside the daughter board FPGA plugged into the NanoBoard.

The ability to chain multiple NanoBoards together and to add user-developed boards to the system, and then to be able to communicate with all compliant devices across the whole hardware system, provides the flexibility to develop extensive processor-based systems that consist of multiple processors running on multiple FPGAs implemented across several discrete PCBs.


Version (v3.0) Mar 03, 2008 10

Revision History

Date Version No. Revision

08-Jan-2004 1.0 New product release

27-May-2005 1.1 Updated for Altium Designer SP4

26-Apr-2007 2.0 Updated for the release of the Desktop NanoBoard NB2DSK01.

03-Mar-2008 3.0 Updated for Altium Designer Summer 08

30-Aug-2011 - Updated template.

Software, hardware, documentation and related materials:

Copyright © 2011 Altium Limited.

All rights reserved. You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modifications of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment.

Altium, Altium Designer, Board Insight, DXP, Innovation Station, LiveDesign, NanoBoard, NanoTalk, OpenBus, P-CAD, SimCode, Situs, TASKING, and Topological Autorouting and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed.

PC to NanoBoard Communications

Documents

Transcript of PC to NanoBoard Communications