Reveal Troubleshooting Guide - Lattice Semiconductor

Reveal Troubleshooting 

Guide 

Lattice Semiconductor Corporation 

5555 NE Moore Court 

Hillsboro, OR 97124 

(503) 268-8000 

June, 2007

Copyright 

Copyright © 2007 Lattice Semiconductor Corporation. 

This document may not, in whole or part, be copied, photocopied, 

reproduced, translated, or reduced to any electronic medium or machinereadable 

form without prior written consent from Lattice Semiconductor 

Corporation. 

Trademarks 

Lattice Semiconductor Corporation, L Lattice Semiconductor Corporation 

(logo), L (stylized), L (design), Lattice (design), LSC, E 2 CMOS, Extreme 

Performance, FlashBAK, flexiFlash, flexiMAC, flexiPCS, FreedomChip, GAL, 

GDX, Generic Array Logic, HDL Explorer, IPexpress, ISP, ispATE, ispClock, 

ispDOWNLOAD, ispGAL, ispGDS, ispGDX, ispGDXV, ispGDX2, 

ispGENERATOR, ispJTAG, ispLEVER, ispLeverCORE, ispLSI, ispMACH, 

ispPAC, ispTRACY, ispTURBO, ispVIRTUAL MACHINE, ispVM, ispXP, 

ispXPGA, ispXPLD, LatticeEC, LatticeECP, LatticeECP-DSP, LatticeECP2, 

LatticeECP2M, LatticeMico8, LatticeMico32, LatticeSC, LatticeSCM, 

LatticeXP, LatticeXP2, MACH, MachXO, MACO, ORCA, PAC, PAC-Designer, 

PAL, Performance Analyst, PURESPEED, Reveal, Silicon Forest, 

Speedlocked, Speed Locking, SuperBIG, SuperCOOL, SuperFAST, 

SuperWIDE, sysCLOCK, sysCONFIG, sysDSP, sysHSI, sysI/O, sysMEM, The 

Simple Machine for Complex Design, TransFR, UltraMOS, and specific 

product designations are either registered trademarks or trademarks of 

Lattice Semiconductor Corporation or its subsidiaries in the United States 

and/or other countries. ISP, Bringing the Best Together, and More of the Best 

are service marks of Lattice Semiconductor Corporation. 

Other product names used in this publication are for identification purposes 

only and may be trademarks of their respective companies. 

Disclaimers 

NO WARRANTIES: THE INFORMATION PROVIDED IN THIS DOCUMENT 

IS “AS IS” WITHOUT ANY EXPRESS OR IMPLIED WARRANTY OF ANY 

KIND INCLUDING WARRANTIES OF ACCURACY, COMPLETENESS, 

MERCHANTABILITY, NONINFRINGEMENT OF INTELLECTUAL 

PROPERTY, OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO 

EVENT WILL LATTICE SEMICONDUCTOR CORPORATION (LSC) OR ITS 

SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (WHETHER 

DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL, 

INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, 

BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT 

OF THE USE OF OR INABILITY TO USE THE INFORMATION PROVIDED 

IN THIS DOCUMENT, EVEN IF LSC HAS BEEN ADVISED OF THE 

POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME JURISDICTIONS 

PROHIBIT THE EXCLUSION OR LIMITATION OF CERTAIN LIABILITY, 

SOME OF THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. 

LSC may make changes to these materials, specifications, or information, or 

to the products described herein, at any time without notice. LSC makes no 

commitment to update this documentation. LSC reserves the right to 

discontinue any product or service without notice and assumes no obligation 

to correct any errors contained herein or to advise any user of this document 

of any correction if such be made. LSC recommends its customers obtain the 

Reveal Troubleshooting Guide ii

latest version of the relevant information to establish, before ordering, that the 

information being relied upon is current. 

Type Conventions Used in This Document 

Convention Meaning or Use 

Bold Items in the user interface that you select or click. Text that you type 

into the user interface. 

Variables in commands, code syntax, and path names. 

Ctrl+L Press the two keys at the same time. 

Courier Code examples. Messages, reports, and prompts from the software. 

... Omitted material in a line of code. 

. 

. 

. 

Omitted lines in code and report examples. 

[ ] Optional items in syntax descriptions. In bus specifications, the 

brackets are required. 

( ) Grouped items in syntax descriptions. 

{ } Repeatable items in syntax descriptions. 

| A choice between items in syntax descriptions. 

Reveal Troubleshooting Guide iii

Reveal Troubleshooting Guide iv

Contents 

Reveal Troubleshooting Guide 1 

HDL Language Restrictions 1 

EDIF Support 2 

Reveal Inserter and Project Navigator Errors 3 

Design Parsing Problems in Reveal Inserter 3 

Project Navigator Flow Messages 3 

Signals Unavailable for Tracing and Triggering 4 

JTAG Restrictions 5 

Sample Clock and Reset 5 

Performance 6 

Creating a Reveal Logic Analyzer Project 7 

REveal Troubleshooting Guide 1

Contents 

REveal Troubleshooting Guide 2

HDL Language Restrictions 

Reveal Troubleshooting 

Guide 

This document describes the design restrictions for using on-chip debug. 

The following features are valid in the VHDL and Verilog languages but are 

not supported in the Reveal Inserter when you use the RTL flow: 

� Array types of two dimensions or more are not shown in the port or node 

section. 

� Undeclared wires attached to instantiated component instances are not 

shown in the hierarchical design tree. You must declare these wires 

explicitly if you want to trace or trigger with them. 

� Variables used in generate statements are not available for tracing and 

triggering. 

� Variables used in conditional statements like if-then-else statements are 

not available for tracing and triggering. 

� Variables used in selection statements like the case statement are not 

available for tracing and triggering. 

� If function calls are used in the array declaration, the actual size of the 

array is unknown to the Reveal Inserter. 

� Entity and architecture of the same design cannot be in different files. 

The following types are valid in the VHDL language but are not supported in 

the Reveal Inserter when you use the RTL flow: 

� Integer types 

� Boolean types 

Reveal Troubleshooting Guide 1

Reveal Troubleshooting Guide EDIF Support 

EDIF Support 

� User-defined enumerated types, with the exception of arrays of std_logic 

or std_ulogic 

You can still use these types in the design, but signals of these types are not 

available for tracing or triggering. VHDL signals that are traced or triggered 

must be of types std_logic, std_logic_vector, std_ulogic, std_ulogic_vector, 

bit, or bit_vector. In addition, subtypes of std_ulogic_vector or 

std_logic_vector are supported, as well as user-defined types that are arrays 

of std_logic or std_ulogic. 

The EDIF flow is fully supported in Reveal. However, you must be aware of 

the following: 

� The Reveal Inserter must be started from a Project Navigator project. In 

order to use the EDIF flow with the Reveal Inserter, you must start the 

Reveal Inserter from a Project Navigator EDIF project. You cannot start 

the EDIF flow from a Project Navigator project that is schematic, VHDL/ 

schematic, VHDL, Verilog/schematic, or Verilog. 

� In the EDIF flow, the representation in the Reveal Inserter is of the EDIF 

hierarchy and signal names. Buses appear as individual signals instead of 

buses, as in the RTL flow. 


Reveal Troubleshooting Guide Reveal Inserter and Project Navigator Errors 

Reveal Inserter and Project Navigator Errors 

This section discusses errors that can occur when you run the Reveal Inserter 

from the Project Navigator. 

Design Parsing Problems in Reveal Inserter 

When you start the Reveal Inserter from the Project Navigator, it parses and 

statically elaborates the design in order to build the hierarchy representation 

and signal list to make them available for debugging. If the design cannot be 

parsed and elaborated because of syntax errors, the Reveal Inserter’s 

graphical user interface will not open. Instead, a message box opens with an 

error message similar to that shown in Figure 1 and the location of the 

reveal_error.log file. This file contains all the information, warning, and error 

messages issued by the compiler when it tries to read the design. 

Figure 1: Reveal Inserter Design Parsing Error Message 

Project Navigator Flow Messages 

After the Reveal Inserter inserts the debug logic, it generates the debug logic 

cores and passes the information to the Project Navigator for building the 

design. Several issues could potentially cause the implementation flow to fail 

because of the debug insertion. Three types of problems could occur: 

� Problems with debug design generation 

� Problems with connecting JTAG functionality 

� Problems with design implementation 

The debug cores are generated in the Reveal Inserter. However, the design 

must also be modified to allow the debug cores to be connected to the 

appropriate signals. The modified design is generated during the Build 

Database step in the Project Navigator. The design is modified with the 

necessary connections for the debug cores, a temporary HDL file is 

generated, and the files are synthesized and converted to the Lattice 

Semiconductor netlist format. Errors generated during this stage are 

displayed in the automake.log file. 

A second step occurs during the Build Database process when the Reveal 

Inserter connects the debug cores to the JTAG functionality on the FPGA. 

During this step, a module called JTAGhub is generated, and any Reveal 

debug cores are connected to it. If other modules that use JTAG, such as 

ispTRACY, ORCAstra, and the Lattice Mico32 Debugger, have already been 

connected to the JTAG functionality, an error results. In the ispLEVER 7.0 

release, you cannot use Reveal on a design if these other modules are used. 

To use Reveal, you would have to remove any of these other modules from 


Reveal Troubleshooting Guide Signals Unavailable for Tracing and Triggering 

the design. In addition, some design elements may have some of these 

modules embedded in them, causing the design to be unusable with Reveal. 

Examples are the QDR and Tri-Speed MAC IPs in which ORCAstra is 

embedded. 

During the mapping process, errors can occur, such as running out of 

available resources or tracing or triggering on signals that are not available in 

the FPGA fabric. During debug insertion, the Reveal Inserter checks to make 

sure that the debug logic is not using more resources than are available in the 

FPGA. But it does not check to see if the debug logic is using more resources 

than are available after the design is placed in the FPGA. Currently resource 

usage can only be accurately checked during the mapping process. 

Exceeding the available resources results in a mapping error, requiring the 

debug configuration in the Reveal Inserter to be reduced in order to fit. 

Another potential failure occurs when you trigger or trace signals that are 

actually hard routes in the FPGA but are not available in the FPGA routing 

fabric, for example, the output of a SERDES block. This output is directly 

routed from the FPGA and is not available in the FPGA routing fabric. Many 

hard routes are detected and blocked from use as trigger or trace signals, but 

it is still possible to select some signals that cannot be connected to the 

debug logic. 

Signals Unavailable for Tracing and Triggering 

Some signals in a VHDL design appear in the signal hierarchy but are not 

available for triggering or tracing. The following signals are currently 

unavailable: 

� Signals used in “generate” statements are not available for tracing and 

triggering. 



� Signals that are user-defined enumerated types, integer type, or Boolean 

type are not available for tracing or triggering. 

Some signals in a Verilog design appear in the signal hierarchy but are not 

available for triggering or tracing. The following signals are currently 

unavailable: 

� Array types of two dimensions or more are not shown in the port or node 

section. 

� Undeclared wires attached to instantiated component instances are not 

shown in the hierarchical design tree. You must declare these wires 

explicitly if you want to trace or trigger with them. 




Reveal Troubleshooting Guide JTAG Restrictions 

JTAG Restrictions 

Sample Clock and Reset 

Signals that are used in a design but are implemented as hard routes in the 

FPGA instead of using the FPGA routing fabric are not available for tracing or 

triggering. Examples are connections to IB and OB components. Many 

common hard routes are automatically shown as unavailable in the Reveal 

Inserter, but some are not. If you select a signal that uses a hard route as a 

trace or trigger during implementation, an error will occur during the mapping, 

placement, or routing steps. 

Reveal requires a JTAG connection for configuring the debug logic and 

transferring captured data to the PC. In the ispLEVER 7.0 release, Reveal is 

not compatible with other modules or logic that also requires JTAG access, 

such as ispTRACY, the LatticeMico32 Debugger, and ORCAstra. If other 

modules or components that also use JTAG are present, an error will occur 

during the Build Database step in the Project Navigator, indicating that there 

are multiple JTAG modules present. The same error occurs if an IP or module 

contains a JTAG module. If Reveal is used with QDR and Tri-Speed MAC IPs 

containing an ORCAstra module, an error will result. An instantiated JTAG 

component primitive causes the same error. Although the FreedomChip flow 

for SC and SCM devices uses JTAG, this flow is compatible with Reveal and 

does not result in a JTAG error. 

Reveal supports debugging a device in a JTAG chain with multiple devices on 

the chain. Reveal also supports debugging a device with multiple cores. 

However, when you debug a design with multiple devices on a JTAG chain, all 

the cores must be present in a single device. Multiple cores distributed among 

multiple devices are not currently supported. 

The sample clock is used by the Reveal debug logic to clock data into the 

trace buffer and in the triggering logic. The sample clock is also needed when 

the Reveal Logic Analyzer communicates with the debug logic through JTAG. 

If the sample clock is not running, the Reveal Logic Analyzer cannot detect 

that the Reveal debug logic is available. This information is especially 

important when you create a new Reveal Logic Analyzer project. The Reveal 

Logic Analyzer checks the debug logic for a signature to make sure that the 

bitstream matches the design. If the Reveal Logic Analyzer cannot 

communicate with the debug logic because the sample clock is not running 

(or the design is in reset), the project creation will fail with an error. For these 

reasons, the sample clock should be a signal with a reasonably regular 

frequency rather than a signal with intermittent pulses. 

Resetting the debug logic can also cause the Reveal Logic Analyzer to be 

unable to communicate with the debug logic. If the reset for the design is 

implemented as a local reset signal (LSR), using the Reveal Logic Analyzer 

when the design is reset causes no errors. However, if any reset for the 

design uses a global reset (GSR), the Reveal debug logic will be reset when 

the signal tied to GSR is used. If the design is in reset when you start the 


Reveal Troubleshooting Guide Performance 

Performance 

Reveal Logic Analyzer, the tool will not be able to communicate and will 

generate an error message similar to that shown in Figure 2. If the reset 

occurs while the Reveal Logic Analyzer is waiting for a trigger, the trigger 

settings in the debug logic are lost, and you must manually stop the Reveal 

Logic Analyzer. 

Figure 2: Reveal Logic Analyzer Communication Error Message 

When you open the Reveal Inserter for an RTL project, it must first parse the 

entire design in order to build the design hierarchy and signal list. Normally 

this occurs within a few seconds. Very large designs may take significantly 

longer. 

When you open the Reveal Inserter for an EDIF project, it must read and load 

the entire design in order to build the design hierarchy and signal list. For very 

large designs, this could take several minutes. On these large designs, there 

is a delay until the Reveal Inserter starts and then a further delay while it 

builds the hierarchy and signal list. Although load times may be long, the 

delay is approximately the same as that of other tools loading similar-sized 

designs. 

When you change trigger settings in the Reveal Logic Analyzer, the settings 

must be downloaded to the debug logic on the FPGA when you press the Run 

button. While the debug logic settings are being downloaded, the 

Configuring ... message appears in the upper left corner of the window. 

The time taken to configure the debug logic depends on how many trigger 

units (TUs) and trigger expressions (TEs) are used. For a few TUs and one or 

two TEs, the time is usually a few seconds. For a maximum configuration of 

16 TUs and 16 TEs on multiple debug logic cores, the time to configure could 

take several minutes. The debug logic does not start looking for the triggers 

set until the Configuring ... message is gone and the Running Device 

... message appears. 

Each debug logic core offers an optional trigger-out signal. The Reveal 

triggering logic, which is composed of trigger units and trigger expressions, 

offers unique capabilities and flexibility. However, there is a latency of five 

sample clocks to the output of the final trigger condition. The Reveal Logic 

Analyzer software automatically handles this latency delay so that the trigger 

point lines up with the correct data when waveforms are displayed in the 

Waveform view. The trigger-out signal also has this five-clock latency delay. 

When you use the trigger-out signal as an input to another core or as an 

external trigger-out signal, the five-sample-clocks delay from the actual trigger 


Reveal Troubleshooting Guide Creating a Reveal Logic Analyzer Project 

event must be taken into account. Otherwise, the captured data will not line 

up with the desired event. 

Creating a Reveal Logic Analyzer Project 

When you create a new Reveal Logic Analyzer project, some additional setup 

is required that the Reveal Inserter does not require. The target board is 

expected to be programmed and turned on. When you first start the Reveal 

Logic Analyzer, the cable settings should be set up. Even if the cable has 

already been set up in ispVM System, you must specify it in the Reveal Logic 

Analyzer. If you are using multiple USB cables on the PC, the Reveal Logic 

Analyzer only recognizes the cable at the USB 0 slot in the 7.0 release of the 

software. Other cables are not available. It may be necessary to switch USB 

cables to enable the Reveal Logic Analyzer to see the target device in this 

situation. This limitation will be addressed in a future software release. 

As noted in “Sample Clock and Reset” on page 5, the sample clock should be 

running and the design should not be in reset if you use the GSR when you 

create a new project or open the Reveal Logic Analyzer on an existing project. 

If the sample clock is not running, the Reveal Logic Analyzer cannot detect 

that the Reveal debug logic is available. When you create or open a project, 

the Reveal Logic Analyzer checks the debug logic for a signature to make 

sure the bitstream matches the design. If the Reveal Logic Analyzer cannot 

communicate with the debug logic because the sample clock is not running or 

the design is in reset, the project creation will fail with an error. If any reset for 

the design uses the global reset (GSR), the Reveal debug logic will be reset 

when the signal tied to GSR is used. If the design is in reset when you start 

the Reveal Logic Analyzer, the tool will not be able to communicate and will 

generate an error message. If the reset occurs while the Reveal Logic 

Analyzer is waiting for a trigger, the trigger settings in the debug logic are lost, 

and you must manually stop the Reveal Logic Analyzer. 

Reveal, unlike ispTRACY, checks both the debug project files and the 

bitstream in the FPGA to make sure that they match. The Reveal Inserter 

generates a unique signature code that is stored in the settings file and is 

implemented as hardware in the debug logic core. It prevents you from 

looking at the settings read from the design files while trying to debug a 

different setup that was downloaded by mistake to the FPGA. However, if you 

used the Reveal Inserter to change the debug settings, even though the 

design has not been re-implemented and programmed into the FPGA, a 

signature error similar to that shown in Figure 3 will occur. Most of the debug 

settings files, which contain the automatically generated signature, are shared 

between the Reveal Inserter and the Reveal Logic Analyzer. You can change 

the settings in the Reveal Logic Analyzer without any signature mismatches 

occurring. Since the Reveal Inserter can change settings that affect the debug 

implementation, any changes in the Reveal Inserter cause the signature to be 

regenerated. Opening the Reveal Inserter without changing any settings and 

saving the project also causes the signature to be regenerated. 


Reveal Troubleshooting Guide Creating a Reveal Logic Analyzer Project 

Figure 3: Reveal Logic Analyzer Mismatch Error Message

Reveal Troubleshooting Guide - Lattice Semiconductor

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?