NOVAS NTX Tutorial

nTX
Users Guide and Tutorial
NOVAS Software, Inc.

NOVAS Software, Inc. 2025 Gateway Place, Suite 400, San Jose, CA 95110 Phone: 1-888-NOVAS-38 (1-888-668-2738) Fax: 408-467-7889 www.novas.com
www.cadfamily.com EMail:cadserv21@hotmail.com The document is for study only,if tort to your rights,please inform us,we will delete
Printing
Printed on June 30, 2006.
Version
This manual supports Verdi and nTX 2006.04 and higher versions.
Copyright
All rights reserved. No part of this manual may be reproduced in any form or by any means without written permission of: NOVAS Software, Inc. 2025 Gateway Place, Suite 400, San Jose, CA 95110 www.novas.com Copyright (c) 1996-2006 NOVAS Software, Inc.
Trademarks
Debussy is a registered trademark and Verdi is a trademark of Novas Software, Inc. Verdi, nTrace, nSchema, nState, nWave, Temporal Flow View, nBench, nCompare, nLint, nECO, nESL, nTX, nAnalyzer, Active Annotation, and Knowledge-Based Debugging are trademarks of Novas Software, Inc. The product names used in this manual are the trademarks or registered trademarks of their respective owners.
Restricted Rights
The information contained in this document is subject to change without notice.
www.cadfamily.com EMail:cadserv21@hotmail.com The document is for study only,if tort to your rights,please inform us,we will delete
Contents
Contents
About This Book 7
Purpose......................................................................................................... 7 Audience ...................................................................................................... 7 Book Organization ....................................................................................... 8 Conventions Used in This Book .................................................................. 9 Related Publications................................................................................... 10 How to Reach Novas Software, Inc........................................................... 11
Introduction
13
Overview - Why nTX?............................................................................... 13 Technology ................................................................................................ 14 Transaction Analysis ............................................................................ 14 Transaction Generation/Extraction....................................................... 14
Debug with Transactions
15
Overview.................................................................................................... 15 What is a Transaction?.......................................................................... 15 Generating Transaction Data ................................................................ 15 Use Model.................................................................................................. 16 Detailed Transaction View ................................................................... 16 Selecting Transactions .......................................................................... 17 Transaction Properties .......................................................................... 18 Transaction Attributes .......................................................................... 19 Analyzing Transactions ........................................................................ 19 Generating Transaction Data ................................................................ 20
Transaction Extraction
23
Use SystemVerilog Assertions (SVA)....................................................... 23 Use Model............................................................................................. 23 SVA Code............................................................................................. 24 Use nTE ..................................................................................................... 29 Pre-requisites ........................................................................................ 29 Installing nTE from the Internet ........................................................... 30 Set Up the Environment........................................................................ 31 Use Model............................................................................................. 31
www.cadfamily.com EMail:cadserv21@hotmail.com 1 The document is for study only,if tort to your rights,please inform us,we will delete
nTX Users Guide and Tutorial
Bus Configuration File (BCF) Format.................................................. 32 nTE Results........................................................................................... 35
Transaction Tutorials
37
Before You Begin ...................................................................................... 37 View Transactions in nWave ..................................................................... 38 Import FSDB File ................................................................................. 38 Add Transaction Waveforms................................................................ 38 View Transactions in Transaction Analyzer Window ............................... 41 Import FSDB File ................................................................................. 41 Add/Remove Transaction Streams ....................................................... 41 Merge Transaction Streams .................................................................. 43 Manipulate the Stream View ................................................................ 45 Generate Statistics ................................................................................ 50 Analyze Transactions Using TCL.............................................................. 54 Execute the TCL File............................................................................ 54 Manipulate Transactions and View Statistics with TCL ...................... 55 Example TCL Script ............................................................................. 58 Generate an FSDB File with Transaction Information .............................. 64 PLI Background.................................................................................... 64 Procedures for Writing a PLI Routine .................................................. 65 Steps for Writing FSDB........................................................................ 69 Steps to Dump Transactions to FSDB .................................................. 70 C Files for FSDB Writer API ............................................................... 72 Use Provided C Files for PCI Transaction Dumping ........................... 73
Appendix A: AMBA AHB Transactor
75
Overview.................................................................................................... 75 BCF Format ............................................................................................... 75 Name..................................................................................................... 75 Mapping Root ....................................................................................... 75 Signal Map............................................................................................ 76 Parameters............................................................................................. 76 Transactor Configurations .................................................................... 78 Transaction Hierarchy................................................................................ 78 Protocol Tree ........................................................................................ 79 Transaction Description........................................................................ 80 Additional Information .............................................................................. 86 Data Types ............................................................................................ 86 Transactor Constants ............................................................................ 88
Appendix B: AMBA AHB Lite Transactor
89
Overview.................................................................................................... 89 BCF Format ............................................................................................... 89 Name..................................................................................................... 89 Mapping Root ....................................................................................... 89 Signal Map............................................................................................ 90 Parameters............................................................................................. 90 Transactor Configurations .................................................................... 91 Transaction Hierarchy................................................................................ 92 Protocol Tree ........................................................................................ 93 Transaction Description........................................................................ 94 Additional Information .............................................................................. 98 Data Types ............................................................................................ 98 Transactor Constants .......................................................................... 100
Appendix C: AMBA APB Transactor
101
Overview.................................................................................................. 101 BCF Format ............................................................................................. 101 Name................................................................................................... 101 Mapping Root ..................................................................................... 101 Signal Map.......................................................................................... 102 Parameters........................................................................................... 102 Transactor Configurations .................................................................. 103 Transaction Hierarchy.............................................................................. 105 Protocol Tree ...................................................................................... 105 Transaction Description...................................................................... 106 Additional Information ............................................................................ 109 Data Types .......................................................................................... 109 Transactor Constants .......................................................................... 109
Appendix D: AMBA AXI Transactor
111
Overview.................................................................................................. 111 BCF Format ............................................................................................. 111 Name................................................................................................... 111 Mapping Root ..................................................................................... 111 Signal Map.......................................................................................... 112 Parameters........................................................................................... 113 Transactor Configurations .................................................................. 114 Transaction Hierarchy.............................................................................. 115 Protocol Tree ...................................................................................... 116
Transaction Description...................................................................... 117 Additional Information ............................................................................ 127 Data Types .......................................................................................... 127 Transactor Constants .......................................................................... 129
Appendix E: MPEG2_TS Transactor
131
Overview.................................................................................................. 131 BCF Format ............................................................................................. 131 Name................................................................................................... 131 Mapping Root ..................................................................................... 131 Signal Map.......................................................................................... 132 Parameters........................................................................................... 132 Transactor Configurations .................................................................. 133 Transaction Hierarchy.............................................................................. 133 Protocol Tree ...................................................................................... 134 Transaction Description...................................................................... 135 Additional Information ............................................................................ 138 Data Types .......................................................................................... 138
Appendix F: OCP-IP Transactor
139
Overview.................................................................................................. 139 Limitations.......................................................................................... 139 BCF Format ............................................................................................. 139 Name................................................................................................... 139 Mapping Root ..................................................................................... 140 Signal Map.......................................................................................... 140 Parameters........................................................................................... 141 Transactor Configurations .................................................................. 145 Transaction Hierarchy.............................................................................. 146 Protocol Tree ...................................................................................... 147 Transaction Description...................................................................... 148 Additional Information ............................................................................ 155 Data Types .......................................................................................... 155 Transactor Constants .......................................................................... 156
Appendix G: PCI-Express (PCIe) Transactor
157
Overview.................................................................................................. 157 BCF Format ............................................................................................. 157 Name................................................................................................... 157 Mapping Root ..................................................................................... 157
Signal Map.......................................................................................... 158 Parameters........................................................................................... 159 Transactor Configurations .................................................................. 160 Transaction Hierarchy.............................................................................. 161 Protocol Tree ...................................................................................... 161 Transaction Description...................................................................... 162 Additional Information ............................................................................ 169 Data Types .......................................................................................... 169
Appendix H: UART Transactor
175
Overview.................................................................................................. 175 BCF Format ............................................................................................. 175 Name................................................................................................... 175 Mapping Root ..................................................................................... 176 Signal Map.......................................................................................... 176 Parameters........................................................................................... 176 Transactor Configurations .................................................................. 178 Transaction Hierarchy.............................................................................. 178 Protocol Tree - TX.............................................................................. 179 Protocol Tree - RX.............................................................................. 180 Transaction Description...................................................................... 181 Additional Information ............................................................................ 185 Data Types .......................................................................................... 185
Appendix I: USB Transactor
187
Overview.................................................................................................. 187 BCF Format ............................................................................................. 187 Name................................................................................................... 187 Mapping Root ..................................................................................... 187 Signal Map.......................................................................................... 188 Parameters........................................................................................... 188 Transactor Configurations .................................................................. 190 Transaction Hierarchy.............................................................................. 190 Protocol Tree ..................................................................................... 191 Transaction Description...................................................................... 192 Additional Information ............................................................................ 198 Data Types .......................................................................................... 198
Index
201
About This Book
About This Book

Purpose
This book is designed to allow you to quickly become proficient in the nTX module, an add-on to Novass Verdi debugging system. You should already be familiar with Verdi before beginning this book. If you do not feel comfortable with basic Verdi operations, please review the Verdi Users Guide and Tutorial document first. This book focuses on the most commonly used commands without going into detail on everything. For detailed descriptions of individual commands, please refer to the appropriate chapter of the Novas Command Reference Manual. The manual should be read from beginning to end, although you may skip any sections with which you are already familiar.
Audience
The audience for this manual includes engineers who are familiar with modeling techniques and languages used in high level design such as the use of transactions, and developing hardware and/or software designs using C, C++, SystemC. Modeling at this abstract level requires more capable, both scalable and efficient, automated debugging tools. The application domain of these modeling approaches and languages can be for System-on-Chip (SoC), boardlevel, or platform designs implemented with Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and numerous other programmable or custom design blocks and components. This document assumes that you have a basic knowledge of the platform on which your version of Verdi runs: UNIX or Linux and that you are knowledgeable in Verilog or VHDL, simulation software, and digital logic design.
Book Organization
This nTX Users Guide and Tutorial is organized as follows: About This Book provides an introduction to this book and explains how to use it. Introduction provides an overview of nTX and introduces its broadly applicable use methodology and unique environment, capabilities, and utilities. Debug with Transactions provides details regarding the recording and creation of, as well as debug with, transactions in Verdi with nTX. Transaction Extraction provides details on different methods for extracting transactions. Transaction Tutorials provides examples regarding the recording and creation of, as well as debug with, transactions in Verdi with nTX. Appendix A-I provides detailed information for extracting the AHB, AHB-lite, APB, AXI, MPEG2-TS, OCP-IP, PCI, UART and USB protocols respectively with nTE. Index is a detailed index to this book.
About This Book
Conventions Used in This Book

The following conventions are used in this book: Italics font is used for emphasizes, book titles, section names, design names, file path, and file names within paragraphs. Bold is used to emphasize text, highlight titles, menu items, and other nTX terms. Courier type is used for program listings. It is also used for test messages that nTX displays on the screen. Note describes important information, warnings, or unique commands. Menu->Command identifies the path used to select a menu command. Click-left or Click means click the left mouse button on the indicated item. Click-middle means click the middle mouse button on the indicated item. Click-right means click the right mouse button on the indicated item. Double-click means click twice consecutively with the left mouse button. Shift-click-left means press and hold the <Shift> key then click the left mouse button on the indicated item. Drag-left means press and hold the left mouse button, then move the pointer to the destination and release the button. Drag means press and hold the middle mouse button on the indicated item then move and drop the item to the other window.
Related Publications
Novas Installation and System Administration Guide - explains how to install Novas products including Verdi. Verdi and Debussy Command Reference Manual - gives detailed information on the Verdi and Debussy command set including nTX. Verdi and Debussy Quick Reference Guide - gives a brief summary of the different modules and related mouse commands and bind keys. Linking Novas Files with Simulators to Enable FSDB Dumping - gives detailed information on linking Novas object files with supported simulators for FSDB dumping. nESL Users Guide and Tutorial - detailed information on using nESL. Verdi Users Guide and Tutorial - detailed information on using Verdi. nCompare Users Manual - detailed information on using nCompare. nAnalyzer Users Guide and Tutorial - detailed information on using nAnalyzer. nECO Users Guide and Tutorial - detailed information on using nECO. nLint Users Guide and Tutorial - detailed information on using nLint. Library Developers Guide - provides information on creating, verifying and using symbol libraries. Verdi Release Notes - for current information about the latest software version, see the Verdi Release Notes shipped with the product and the installation files in the distribution directories. Language Documentation Hardware description (Verilog, VHDL, SystemVerilog, etc.) and verification (e, Vera, etc.) language reference materials are not included in this manual. For language related documents, please refer to the appropriate language standards board (www.ieee.org, www.accellera.org) or vendor (www.synopsys.com, www.cadence.com, www.verisity.com) websites.
About This Book
How to Reach Novas Software, Inc.

Corporate Headquarters: 2025 Gateway Place, Suite 400 San Jose, CA 95110 U.S.A. Phone: 1-888-NOVAS-38 (1-888-668-2738) or 408-467-7888 FAX: 408-467-7889 E-Mail: sales@novas.com for license request and sales information. support@novas.com for technical support. URL: http://www.novas.com Asia Headquarters: 5F, No. 25, Industry East Road IV Science-Based Industrial Park Hsinchu, Taiwan R.O.C. Phone: 886-3-567-9656 FAX: 886-3-567-0066
Introduction
Introduction
Overview - Why nTX?
Transactions have been used for years to model system-level behavior, mainly with in-house simulation environments. They are an extremely powerful datalevel abstraction that help users think about high-level design and functionarchitecture trade-offs. Transaction-level abstractions ease the understanding of on-chip communication and bus complexity, particularly with complex protocols; however, engineers still need a way to visualize, understand and debug the information. Automation tools must enable analysis functions including bus loading and utilization, correlation across bus bridges, system performance evaluation such as throughput and latency, resource usage, synchronization and the like. nTX, builds on top of the comprehensive Verdi debug system, adding advanced system and platform debugging technologies with unified support for the diverse methodologies involved in such designs. The nTX technology addresses multiple key requirements: Comprehensive transaction analysis environment that provides easy understanding of complex device communication. Leverage powerful automated RTL debug system and significant debug experience from a wealth of application areas.
Technology
nTX provides support in the following areas.
Transaction Analysis
The current support for transaction level verification and debug in nTX is as follows: Transaction waveform visualization in nWave. Spreadsheet view that supports data management and presentation functions such as sorting/filtering of transactions and statistical analysis.
Transaction Generation/Extraction
The transaction data can be obtained from one or more of the following diverse sources: Native FSDB dumper function calls embedded in the system model, SystemC SCV methods, and also from the HVLs (such as e, available soon.) Transaction IP-provider partners such as Denali and Spiratech. End user coding using the FSDB writer API. Extraction from SystemVerilog Assertions.

Overview
Transactions are an important piece of abstraction in system design and debug. System design is in a very early stage of the whole design process; therefore, a powerful viewing mechanism for transactions is mandatory to system designers. For testbench verification, if the entire system is to be verified, transaction level checking is efficient and easy to focus comparisons of system behavior against system specification. When an error is found in the transaction level, the signal level is then investigated.
What is a Transaction?
Transactions are higher level abstractions of signal-level detailed activity. Transactions are organized into streams. Transaction streams can be dumped into FSDB format using dumping libraries provided by Novas and its partners or using the Open Transaction Interface (OTI) extension of the Novas FSDB Writer API. Streams hold transactions. Each transaction consists of a set of attributes and is independent of one another. That is, there is no such concept as "transaction type", as in SCV, even if the sets of attributes that constitute two transactions are the same. When you create a transaction, you must follow the steps below: 1. 2. 3. 4. Create a stream. Create attributes. Create a transaction. Create relationships between existing transaction.
Generating Transaction Data

The transaction data can be obtained from Novas provided native FSDB dumpers, transaction IP partners, or the FSDB writer API and Open Transaction Interface (OTI). Transaction data can also be extracted from your code using SystemVerilog Assertions.
Use Model
The transaction FSDB file is loaded into nWave the same way as a general FSDB file. A stream name will be shown in the signal pane; begin time, end time, and attributes are shown in the value pane; and the transaction will be shown in the waveform pane as rectangles enclosing all the attributes. This section includes the following topics: Detailed Transaction View Selecting Transactions Transaction Properties Transaction Attributes Analyzing Transactions Generating Transaction Data
Detailed Transaction View

The following figure summarizes the different aspects of transaction viewing in nWave.
Figure: Detailed Transaction View
Although there is a begin time and end time in a transaction, when you click on a transaction, the cursor will be located at the begin time. When you select a stream, you can click the Search Backward/Search Forward icons (blue left/ right arrows) on the nWave toolbar to step through the transactions. A dashed line
under the transaction box indicates there are more attributes than are currently displayed. You can increase (decrease) the height of the stream in the signal pane to show more (less) attributes. Alternatively, you can move the cursor on top of the transaction attributes in the value pane (middle column) to activate a tip showing all attributes as displayed in the following figure.
Figure: Transaction Tip
Selecting Transactions
Individual transactions can be selected by clicking on the label in the waveform pane; the background color of the selected transaction will change to light blue. Pressing the Search Backward/Search Forward toolbar icons will not change the selected transaction but will change waveform cursor time. The selection is important for viewing the covered or obscured transactions when there is a time overlap for multiple transactions. The top triangle is used to select the underlying transaction and bring it to the front.
If there are transactions related to the selected one, the related transaction will be highlighted with a pink background color, similar to the following example.
Figure: Transaction Relationships
Transaction Properties
Transactions contain a lot of data. You can view the attributes and relationships of a selected transaction in a tabular format. To open the Transaction Property form, select a transaction, click-right to open the context menu, and chose the Properties command. The Attributes tab summarizes the transaction attributes, as shown in the following example:
Figure: Transaction Property Dialog Window - Attributes
You can view the selected transaction relationships by selection the Relationship tab in the Transaction Property form.
Transaction Attributes
You can use string matching to search attributes. In nWave, choose Waveform -> Set Search Attributes to open the Search Attribute Value form. Alternatively, you can click-left on the Search By: icon on the toolbar and select the Transaction Attribute Values option.
Figure: Search Attribute Value Form
You can specify the attribute name and value. Once youve entered the search criteria and clicked OK, you can use the Search Forward/Search Backward icons on the nWave toolbar to step through the transactions of the selected streams.
Analyzing Transactions
In addition to the waveform viewing capability for transactions, you can open the Transaction Analyzer window by invoking Tools -> Transaction Analyzer -> Open Transaction Analyzer Window from nWave. Once the window is open, you can load one or more streams individually or merge multiple streams together.
The window will be similar to the following:
Figure: Transaction Analyzer Window
For the current selected stream (or merged streams), you can use View -> Find to locate a string or pattern, or View -> Filter to filter and display transactions whose attributes match user-specified conditions. After filtering a stream, you can choose View -> Show All to restore all the transaction data. These commands allow you to more quickly navigate the streams and focus on the transactions of interest.
Generating Transaction Data

The transaction data can be obtained from the following sources.
Provided FSDB Dumpers

Dump transaction data from languages directly with native FSDB dumpers. SystemC/SCV -- supported OSCI and NCSC simulators. Specman/e SystemVerilog test bench in conjunction with simulator support (VCS, ModelSim) Vera Click here to access the SystemC Linking chapter in the Linking Novas Files with Simulators to Enable FSDB Waveform Dumping manual for details on linking native FSDB dumpers, SystemC SCV, and HVL simulators.
Transaction IP Partners
Please contact Denali (PCI-Express) or Spiratech (AMBA AXI, AHB) directly for details on dumping FSDB format from their available intellectual property (IP).
SVA Extraction
You can add SystemVerilog Assertions (SVA) constructs to your design code to represent transactions. The transactions can then be extracted from a signal level FSDB. Click here for more details.
FSDB Writer API and the Open Transaction Interface (OTI)

If you are unable to generate transaction data in FSDB format from any of the previously mentioned methods, you can use the Open Transaction Interface (OTI) extension of the FSDB writer API to dump transaction data. Click here for an example.
There are two primary methods of extracting transaction information from a signal level FSDB: Use SystemVerilog Assertions (SVA) Use nTE
The SVA method can be used with proprietary protocols and the nTE method supports a variety of industry standard protocols.
Use SystemVerilog Assertions (SVA)

SVA can be added to your design and then extracted to display as transactions.
Use Model
Before you can to extract transactions from SVA, you must do the following: 1. Add SVA code to your design either inlined or as a separate file. 2. Generate an FSDB file containing design data with your preferred simulator. 3. Load the design and FSDB file into Verdi. Once the design and FSDB file are loaded into Verdi, you can extract the transactions by invoking Tools -> Transaction -> Transaction Evaluator. This opens the Transaction Evaluator form where all SVA assert signals are listed.
Figure: Transaction Evaluator Form
In the Transaction Evaluator form, you can display the assertions using a Table or Tree view, you can select the assertions to be extracted and you can specify the results file name. You can also drag any of the assertions to the nTrace source code pane to see the related code. After you click Run, the transactions will be extracted from the assertion code and saved to the specified file. This FSDB file will automatically be loaded into Verdi and you can start using all transaction viewing and analysis commands for debug in addition to the standard Verdi capability.
NOTE: You will need to add the transaction waveforms using nWaves Get
Signals command. Transaction signals have an _nTX suffix appended to the assertion name.
SVA Code
When it comes to adding SVA code to your design that will ultimately be used to extract transactions, the following sections contain a summary of recommended and unsupported coding styles.
Recommended Coding Style

The following coding styles are recommended for optimum transaction extraction results:
Only assert directive is supported.
Most SVA constructs are supported. Refer to unsupported coding style for details. Using constructs below the sequence layer is recommended for modeling the transaction. SVA local variables, including those declared in the sub-sequence of a specific assertion, will be recorded as attributes of transactions; therefore, do not declare local variables with the same name across different sequences/properties. Example 1:
sequence single_read; logic [31:0] addr; logic [31-1:0] data; int ws; @(posedge hclk) (`true,ws = 0) ## 0 (hready) ##1 (!hready && hsel) [*0:$] ##1 ((hready && hsel && `SR_CTRL), addr = haddr) ##1 ((!hready && hsel), ws = ws + 1) [*0:$] ##1 (hready, data = hrdata); endsequence SINGLE_READ: assert property(single_read);
The local variables addr, data, and ws variables of sequence single_read will be recognized as the attributes of assertion statement SINGLE_READ. Example 2:
sequence s1; int localvar; ... endsequence sequence s2; int localvar; ... endsequence
should be modified as:

sequence s1; int localvar1; ... endsequence sequence s2;
nTX Users Guide and Tutorial int localvar2; ... endsequence
You can specify the transaction label name of a specific sequence by declaring a string type local variable named label_nTX, and assigning a label name to it. For example, if you specify the following for a sequence/ property:
sequence single_read; string label_nTX; (..., label_nTX = my_single_read,...) ...; endsequence
Then the transaction label name would be my_single_read. If you specify the following for an assertion statement:
sequence s1; string label_nTX; (..., label_nTX = my_s1,...) ...; endsequence sequence s2; string label_nTX; (..., label_nTX = my_s2,...) ...; endsequence a_s1 : assert property((@posedge clk) s1 ##1 s2);
Then the sub-sequence/propertys label_nTX variable (if one exists) would be used as its transaction label. In this case, the label would be either my_s1 or my_s2.
Unsupported Coding Style

The following coding styles are not supported for transaction extraction:
Multiple clocking is not supported Immediate assertion coding style is not supported. SVA cover and assume directives are not supported. Only the assert directive is supported. Three types of assertion successes will not be recognized as a transaction: The vacuous SUCCESS of the implication will not be recognized as a transaction.
The abort SUCCESS of 'disable iff' will not be recognized as a transaction. Empty matches, e.g. seq1[*0]; will not be recognized as a transaction.
Code Example
The following SVA code example:
bind test assert_checker bind_transaction_evaluator( .EN (test.uFL_AMBA_SRAM.ram_2kx32.mem.EN), .WE (test.uFL_AMBA_SRAM.ram_2kx32.mem.WE), .ADDR (test.uFL_AMBA_SRAM.ram_2kx32.mem.ADDR), .DI (test.uFL_AMBA_SRAM.ram_2kx32.mem.DI), .DO (test.uFL_AMBA_SRAM.ram_2kx32.mem.DO), .CLK (test.uFL_AMBA_SRAM.ram_2kx32.mem.CLK), .RST (test.uFL_AMBA_SRAM.ram_2kx32.mem.RST), .RDInvalid (test.uFL_AMBA_SRAM.uSMI.iXOEN_d) ); module assert_checker ( input EN, input WE, input [10:0] ADDR, input [31:0] DI, output [31:0] DO, input CLK, input RST, input RDInvalid ); sequence core_memory_write; logic [10:0] Addr; logic [31:0] Data; (1) ## 0 (EN == 1'b1 && WE == 1'b1, Addr = ADDR, Data = DI) ##1 (!(EN == 1'b1 && WE == 1'b1)); endsequence sequence core_memory_read; logic [10:0] Addr; logic [31:0] Data; (1) ## 0 (WE==1'b0 && RST==1'b0 && RDInvalid==1'b0, Addr = ADDR) ##1 (RDInvalid == 1'b0) ##1 (1, Data = DO); endsequence
CORE_MEM_WRITE : assert property(@(posedge CLK) core_memory_write); CORE_MEM_READ : assert property(@(posedge CLK) core_memory_read); endmodule
will be extracted and displayed as transaction waveforms similar to the following:
Figure: Extracted Transaction Waveform
Use nTE
nTE uses various transactors from SpiraTech to extract transactions from signal level simulation results. A source FSDB file containing signal activity, together with a bus configuration file (BCF), is loaded into the transactor using nTE. An FSDB file is produced containing a transaction hierarchy, together with the original signals. This may be viewed using nWave and the Transaction Analyzer window.
Pre-requisites
Pre-requisites include: The concept of models at different levels of abstraction, e.g. transactionlevel modeling. Familiarity with one of the supported bus protocols (see the relevant protocol specification), as listed below: AMBA AHB AMBA AHB-Lite AMBA APB AMBA AXI MPEG2 Transport Stream OCP-IP PCI Express UART USB Refer to the appendices for more information on configuring nTE and interpreting the transaction hierarchy for each of the protocols. Installation of the nTE package.
Installing nTE from the Internet

Complete the following steps to install nTE from the internet: 1. Create a directory for the software.
> mkdir <NTE_INST_DIR>
2. Change to the installation directory.

> cd <NTE_INST_DIR>
3. Connect to web http://www.novas.com. 4. Select Support-> Downloads and follow the instructions. In addition to the standard Verdi installation files, the following compressed file is available:
Novas-2006??-nte.tar.gz # nTE Package
where 2006 corresponds to the year, e.g. 2006 and ?? corresponds to the month, e.g. 04. When there is a patch release between quarterly releases, a p# will be appended to the version, e.g. 200604p1. 5. Decompress and extract the software:
> gzip -cd Novas-2006??-nte.tar.gz | tar xvf -
The following directories are created:

nte_examples adaptor_lib i686-linux-gcc-2.96 sparc-sol-gcc-2.95 Examples Transactor library files Linux binaries Solaris 2 binaries
Set Up the Environment

1. Specify the following environment variables:
> setenv CY_HOME "<path_to_nte_installation>" > setenv CY_PLATFORM "<platform>"
where platform is: i686-linux for Linux (RedHat7, RedHat 9 and compatible) sparc-sol for Solaris (Solaris 7, 8, and 9) 2. Add the nTE installation to the search path in your login script: For C (csh) shell: set path = ($CY_HOME/$CY_PLATFORM/bin $path) For Bourne (sh) and Korn (ksh) shells: PATH=$CY_HOME/$CY_PLATFORM/bin:$PATH 3. Add the Novas installation to the search path (which includes fsdbmerge) in your login script: For the C (csh) shell: set path = (<NOVAS_INST_DIR>/bin $path) For Bourne (sh) and Korn (ksh) shells: PATH=<NOVAS_INST_DIR>/bin:$PATH 4. Add the following to your LD_LIBRARY_PATH: > setenv LD_LIBRARY_PATH "$CY_HOME/$CY_PLATFORM/lib"
Use Model
To run nte, a command of the following format should be issued:
nte input wires.fsdb output transactions.fsdb \ config config.bcf
Where: wires.fsdb is the output of the wire level simulation. transactions.fsdb is the desired output name (any existing file of the same name will be overwritten). config.bcf contains a configuration to suit the transactor being used. Once the output FSDB has been generated by nte from the input FSDB and BCF configuration, the results can be viewed in nWave, which will display the original wire data and the recognized transactions. Refer to the Transaction chapter for more details.
Bus Configuration File (BCF) Format

nTE makes use of the BCF (Bus Configuration File) Format for configuration. The BCF format supports C style single line (//), and multiple line (/* ... */) comments. The BCF features currently supported by nTE are defined in the following sections.
Bus Definition Block

The BCF file should contain one or more bus definition blocks, as follows.
<nte_transactor_library_name> <user_name> { }
nte_transactor_library_name selects which transactor to use, e.g. nte_UART_v2p1_ns. user_name is a name for this bus definition block, which can consist of upper and lower case letters, numbers, and underscores (_). This name must be unique for each bus definition block within a single BCF file. Within the bus definition block nTE supports a number of statements and subblocks. For example:
nte_UART_v2p1_ns UARTtest { SIGMAP { // signal mappings... } PARAMETER { // bus parameters... } }
Multiple bus definition blocks can be used to extract transactions for multiple interfaces within the input FSDB file and combine the results into a single output FSDB file.
NOTE: nTE 1.3 or later is required to support multiple bus definition blocks.
Signal Mapping Block

The signal mapping block is defined within the bus definition block, as follows:
SIGMAP { <nte_transactor_signal_name> = "<user_signal_name>"; <nte_transactor_signal_name> = "<user_signal_name>"; . . . }
nte_transactor_signal_name is the name of a signal defined within the nTE transactor library that has been selected for this bus definition block. See the appendix for the protocol you are interested in for a full listing of the signals in each of the nTE transactors. user_signal_name is the name of a signal within the FSDB file that will be used as input to nTE. There can be any number of signal mappings within the signal mapping block. Not every signal within the nTE transactor library has to be mapped; unmapped signals will simply be left with a default value. However, this can result in nTE not being able to fully interpret the protocol. For this reason a warning is written to the log file for each unmapped signal.
Clock Mapping
A clock can either be user-defined by setting the clk_* parameters within the PARAMETER block of the BCF file, or a clock can be mapped so that the extraction process 'learns' the characteristics of the clock on a continuous basis. If you choose to map the clock, then clk_* parameters do not need to be set within the PARAMETER block.
Mapping Root Statement

The mapping root statement is defined within the bus definition block, as follows:
MAPPING_ROOT = "<root_user_signal_path>";
root_user_signal_path is prefixed to each of the user_signal_names in the signal mapping block. For example:
nte_UART_v2p1_ns UARTtest { MAPPING_ROOT = "/tbuart/tb"; SIGMAP { /UART/TX = "/tx";
nTX Users Guide and Tutorial /UART/RX } } = "/rx";
is equivalent to
nte_UART_v2p1_ns UARTtest { SIGMAP { /UART/TX = "/tbuart/tb/tx"; /UART/RX = "/tbuart/tb/rx"; } }
NOTE: In this example, the root mapping does not have a separator (/) at the end
of it, so it is included at the start of each of the user's signal names. The separator should not be included in both places, as this will result in a complete signal name like /tbuart/tb//tx which is incorrect.
Bus Parameter Block

The bus parameter block is defined within the bus definition block, as follows:
PARAMETER { <nte_transactor_parameter_name> <nte_transactor_parameter_name> . . . } = = <value>; <value>;
nte_transactor_parameter_name is the name of a parameter defined within the nTE transactor library that has been selected for this bus definition block. See the appendix for the protocol you are interested in for a full listing of what these are. value is the value to be assigned to that parameter. For example:
PARAMETER { UART_word_length = 8; UART_stop_bit_length = 1.0; }
There can be any number of parameter assignments within the bus parameter block. Any parameters that are not assigned a value will take on a default value.
nTE Results
If all the settings are correct, the following messages should be displayed once nTE is invoked:
nTE complete for instance (INSTANCE_NAME) of protocol (PROTOCAL_NAME) nTE moving output file nTE complete
If any settings are incorrect, the following warning or error messages may be displayed:
nTE adaptor failed
This would be followed by any of the next messages. The following message indicates a wire is in adaptor but has not been connected to FSDB wire.
Failed to connect to /RAM_bus/addr
The following message indicates a wire is in BCF file but not in the adaptor. This does not cause nTE to fail as you may not want to connect a signal.
Failed to relate /RAM_bus/rd_data with /RAM_bus_example/st/ iRAM_I/iRAM_I/rd_data
The following messages indicate the configured bus width in the adaptor does not match the bus width in the input FSDB file:
NTE_ERROR: Error: Aggregate value is the wrong length '"0000000000000000"' to an 8 bit field NTE_ERROR: Invalid aggregate passed to wire RAM_bus.rd_data
The following message indicates a parameter has been set outside the legal range:
NTE_HALT: Fatal: Configured Addr bus width greater than maximum allowed.
The following topics are included: Before You Begin View Transactions in nWave View Transactions in Transaction Analyzer Window Analyze Transactions Using TCL Generate an FSDB File with Transaction Information
Before You Begin

Before you begin the tutorials, you (or your system manager) must have installed Verdi (which automatically installs nTX) as described in the accompanying Novas Installation and System Administration Guide. You must also complete the following actions in order to set up the Novas environment and the files required for this tutorial: 1. Add the Verdi application (binary) to the search path:
% set path=(<NOVAS_INST_DIR>/bin $path)
NOTE: The percent ('%') character on the left-hand side of the command represents
the system prompt. 2. Specify the search path to the license file:
% setenv NOVAS_LICENSE_FILE <license_file>
NOTE: Your license file must include an nTX feature line for this tutorial.
3. Create a working directory:

% mkdir <working_dir>
4. All of the tutorial data resides in the <NOVAS_INST_DIR>/demo directory. Make a copy of these demo files in your working directory:
% cp -r <NOVAS_INST_DIR>/demo <working_dir>
View Transactions in nWave

This tutorial will familiarize you with transaction viewing and search operations. All nWave manipulation functions (zoom, cursor, marker, re-size, etc.) are available with FSDB files containing transactions. Refer to the Tutorials chapter, nWave section in the Verdi Users Guide and Tutorial document, for a complete introduction to nWave.
Import FSDB File

1. Change the directory to <working_dir>/demo/nTX.
% cd <working_dir>/demo/nTX
2. Execute Verdi to import the FSDB file:

> verdi -ssf ahb32.bus.fsdb &
The nTrace and nWave windows open and the FSDB file is loaded.
NOTE: This tutorial only has an FSDB file that contains transactions and there
isnt a related design.
Add Transaction Waveforms

1. In nWave, choose Signal -> Get Signals to open the Get Signals form. The transaction FSDB is loaded displaying BusTop as the top hierarchy and MyAHB_1(_AHB_) as the first hierarchical level which is for different protocols. 2. Click on MyAHB_1 to show the streams under this hierarchy.
The results will be similar to the following example:
Figure: Get Signals - Displaying Streams
3. Select AhbTransfer and AhbTransaction, then click OK. 4. In nWave, re-size the signal and value panes to more readily display the text and zoom in on the waveform pane to see the transaction details. 5. Click on the AhbTransaction stream in the signal pane to select it. 6. Click Search Forward icon (blue right arrow) in toolbar to step through the transactions. Note, the cursor moves to the begin time of each transaction. 7. Since there are more attributes than the default signal height can display, you can adjust the height by dragging the small grey line in the lower left corner of the stream name in the signal pane. 8. Move the mouse cursor over the attributes in the value pane to show the details in a tip. 9. Click on the Search By: in the nWave toolbar and choose the last option, Transaction Attribute Values. 10. In the Search Attribute Value form, enter BurstType for Attribute and incr 4 for Value.
The form should look similar to the following:
Figure: Search Attributes
11. Click OK. The cursor in the waveform will automatically move to the nearest transaction with BurstType = incr 4. 12. Click the Search Forward/Search Backward icons on the toolbar to locate a matching transaction at 4810000ps. 13. Click on the transaction in the waveform pane at time 4810000ps, which is burst read of incr 4 type. There will be 4 AhbTransfer burst read command transactions and 3 busy ones as the children of the selected transaction. The child transactions are highlighted in pink.
Figure: Search Results with Related Transactions
14. With the same transaction selected, click-right to open the right mouse button context menu and choose Properties to open the Transaction Property form which shows all the attributes and relationships for the selected transaction.
View Transactions in Transaction Analyzer Window

This tutorial will familiarize you with transaction viewing and search operations in a spreadsheet-like view.
Import FSDB File

1. Change the directory to <working_dir>/demo/nTX.
2. Execute Verdi to import the FSDB file:

> verdi -ssf ahb32.bus.fsdb &
The nTrace and nWave windows open and the FSDB file is loaded.
NOTE: This tutorial only has an FSDB file that contains transactions and there
isnt a related design.
Add/Remove Transaction Streams

After loading a FSDB file with transaction data, you can view and manipulate the results in the Transaction Analyzer window. 1. In nWave, choose Tools -> Transaction Analyzer -> Open Transaction Analyzer Window to open the Transaction Analyzer window. The FSDB file currently loaded in nWave will be the default in the Transaction Analyzer window. 2. In the Transaction Analyzer window, choose Stream -> Get Stream to open the Select Stream form.
The form should look similar to the following:
Figure: Select Stream Form
All of the transaction streams available in the FSDB file will be listed in a tree-like format. 3. Double-click on AhbTransfer to automatically add the stream to the Transaction Analyzer window. The stream name changes to gray and is appended with a red dot. 4. Left-click to select AhbTransaction and click OK to add the stream and close the form.
The Transaction Analyzer window should look similar to the following:
Figure: Transaction Analyzer Window with Streams Loaded
There are two streams, AhbTransfer and AhbTransaction, in the Transaction Analyzer window. Each stream has a tab of its own. You can select the stream name to see the details of the stream. The currently selected stream name is blue. You can change the width of the columns by selecting the vertical line in the column header and dragging-left. 5. Left-click to select the AhbTransaction. 6. Choose Stream -> Close Stream. Note the stream has been removed from the Transaction Analyzer window.
Merge Transaction Streams

You can also merge two or more streams in the Transaction Analyzer window. When streams are merged you can search and filter all the transaction attributes simultaneously.
NOTE: The Merge Stream command only merges the transaction streams for
viewing purposes; it does not effect the FSDB file.
1. In the Transaction Analyzer window, choose Stream -> Merge Stream to open the Merge Stream form.
The form will be similar to the following:
Figure: Merge Stream Form
All of the transaction streams available in the FSDB file will be listed in a tree-like format in the Stream Name column. 2. Click the button to move all streams to the Merged Stream column. After the stream is added, its name becomes gray with a red dot in the Stream Name column and can not be selected again. 3. Left-click to select the Error stream in the Merged Stream column. 4. Click the button to move the selection back to the Stream Name column. The stream name is changed to black and is selectable again. 5. Left-click to select the AhbTransaction stream in the Merged Stream column. 6. Click the UP button to move AhbTransaction above AhbTransfer. 7. Click the Default button to automatically generated the merged stream name which will consist of each stream name linked with an underscore. 8. Click OK.
Figure: Merged Stream in the Transaction Analyzer Window
If the different streams have transactions at the same time, both will be displayed.
Manipulate the Stream View

There are several ways to manipulate the streams in the Transaction Analyzer window. You can change which columns (attributes) are displayed and in what order. You can also filter the transactions based on one or two attribute conditions.
Set the Cursor/Marker

In this example, youll set the cursor/marker position in the Transaction Analyzer window and learn how to synchronize it with the other Verdi windows. 1. In the Transaction Analyzer window, select the AhbTransfer stream. 2. Click-left anywhere on the row for Index 13 to set the cursor time. The selected row is highlighted in yellow. 3. Scroll until you can see Index 25. 4. Click-middle anywhere on the row for Index 25 to set the marker time. The selected row is highlighted in red. 5. Choose View -> Sync Cursor Time to synchronize the cursor globally. 6. Click-left anywhere on the row for Index 18 to set the cursor time. Note the cursor time changes in nWave as well even without waveforms being displayed. If you had a design loaded and active annotation enabled, the cursor time would change in nTrace and nSchema as well.
Change the Column (Attribute) Display

In this example, youll select some columns (attributes) to remove from the display and re-order the remaining columns. 1. In the Transaction Analyzer window, select the AhbTransfer stream. 2. Choose View -> Column Configuration to open the Config Bus Table form. The form will be similar to the following:
Figure: Config Bus Table Form
By default, all the columns (attributes) will be listed in the Show Column section. 3. Select Label in the Show Column section. 4. Click the button to move it to the Hide Column section. 5. Repeat the previous steps for Response, Slave, and EndTime individually. Only one attribute can be selected at a time. 6. In the Show Column section, select Index. 7. Click the DOWN button multiple times until Index is at the bottom of the list. 8. In the Show Column section, select BurstType.
9. Click the UP button multiple times until BurstType is located below Command. 10. Click OK. The Transaction Analyzer window should be updated as follows:
Figure: Modified Attribute Display for AhbTransfer Stream
Note four columns have been removed from the display and the remaining columns have been re-ordered. The Index column is now the right-most column and BurstType is next to Command. 11. Left-click on the Command column to sort by the command attribute types. 12. Choose View -> Show All and all columns (attributes) are added back to the view in the original order.
Search the Transactions

In this example, you will search for a text string. 1. In the Transaction Analyzer window, select the AhbTransfer stream. 2. Choose View -> Find to open the Find String form. 3. In the Pattern text field, enter aa9. The Find String form should be similar to the following:
Figure: Find String Form
4. In the Find String form, click Next. The first occurrence of aa9 will be highlighted in blue in the Data column of the Transaction Analyzer window. 5. Continue to click the Next/Previous buttons to locate more occurrences of aa9. There are multiple. 6. When you are done searching for different patterns, click Close on the Find String form.
Filter the Transactions

In this example, you will filter the transactions based on certain attributes. 1. 2. 3. 4. In the Transaction Analyzer window, select the AhbTransfer stream. Choose View -> Filter to open the Filter form. Toggle the Column field and select Command. In the first Criteria row, toggle the criteria to = and enter single write in the related text field. The form will be similar to the following:
Figure: Filter Form - Command = single write
5. Click Apply. The Transaction Analyzer window will be updated to display transactions whose command attribute is of type single write, similar to the following:
Figure: Filter Results for Command single write
At this point you have several options. You can sort the current results by clicking another column header or you can further reduce the display by specifying another filter or you can restore the stream and start over. Lets specify another filter. 6. In the Filter form (which should still be open unless you closed it), toggle the Column field and select SizePerBeat. 7. In the first Criteria row, toggle the criteria to >= and enter 2 byte in the related text field. The form will be similar to the following:
Figure: Filter Form - SizePerBeat >= 2byte
8. Click Apply. The Transaction Analyzer window will be updated to display transactions whose command attribute is of type single write and whose SizePerBeat attribute value is greater than or equal to 2 bytes, similar to the following:
Figure: Filter Results for Command single write with SizePerBeat >= 2 bytes
At this point you have several options. You can sort the current results by clicking another column header or you can further reduce the display by specifying another filter or you can restore the stream and start over. Lets restore the stream and start over. 9. Choose View -> Show All and transaction rows are added back to the view in the original order.
Generate Statistics
In addition to viewing and manipulating the transactions in a spreadsheet-like view, you can generate a variety of statistics for the stream. 1. In the Transaction Analyzer window, select the AhbTransaction_AhbTransfer merged stream.
NOTE: Although this example will use the entire merged stream, you can filter
the stream first and then generate statistics based on the reduced display.
2. Choose Tools -> Statistic Window to open the Perform Statistical Calculation form.
Figure: Perform Statistical Calculation Form
You have several options for setting up the form. In this example you want to view the frequency of BurstType for the entire simulation range. 3. Click the Full Range button to automatically enter the from and to times. 4. Toggle the Category Column field and select BurstType. 5. Click OK.
A Statistics Window similar to the following will open.
Figure: Bar Chart for BurstType
For the stream combination, you can easily see the frequency of the burst types. At this point, you can capture the results in PNG format. You can also change the view to a pie chart or table, or duplicate the window. 6. In the Statistics Window, choose View -> Pie Chart.
The window will be updated similar to the following.
Figure: Bar Chart for BurstType
7. Choose File -> Close to close the Statistics Window. You can generate more statistics for different attribute types. 8. Choose File -> Exit in nTrace to close the Verdi session.
Analyze Transactions Using TCL

This tutorial demonstrates the usage of transaction manipulation, query, and statistic TCL commands in a TK program that can be launched from Verdi. The FSDB used contains transactions of the AMBA AHB interface.
Execute the TCL File

The TCL script ta_ex.tcl operates on a transactional FSDB. Both files can be found in the <working_dir>/demo/nTX directory. 1. Change the directory to <working_dir>/demo/nTX.
2. Execute Verdi to play the TCL file and load the FSDB file:
> verdi -play ta_ex.tcl &
The nTrace window opens with a new menu item. 3. To launch the TA Example window as shown below, choose Tools -> Launch TA Example in nTrace.
Figure: TA Example Window
This menu item was added as a result of the following code in the TCL file:
# Append a Verdi menu item eMenuAppendItem -win $_nTrace1 -menuName Tools -itemName "Launch TA Example..." -tclCmd createMainWin -shortKey Y AddEventCallback [tk appname] cursorTimeChangedCB taCursorTimeChange 0 AddEventCallback [tk appname] markerTimeChangedCB taMarkerTimeChange 0 AddEventCallback [tk appname] tableRowSelectedCB stsTableRowSelected 0
Transaction Tutorials AddEventCallback [tk appname] tableRowUnselectedCB stsTableRowUnselected 0
The Command 1-3 buttons are reserved for user-defined commands. An information window is displayed when these commands are executed.
Manipulate Transactions and View Statistics with TCL

The transaction manipulation commands can be executed from the CommandTest menu of the TA Example window. Load File and Load a Stream should be executed before executing other commands. 1. In the TA Example window, choose CommandTest -> Load File. The Transaction Analyzer window opens with the ahb32.bus.fsdb file loaded. 2. Choose CommandTest -> Load a Stream. The AhbTransaction stream is added to the Transaction Analyzer window. 3. In the Transaction Analyzer window, click-left on 7 in the Index column to set the cursor and click-middle on 23 to set the marker. 4. In the TA Example window, choose Statistics -> AHB Statistics. This opens the ahbStat window, similar to the following example:
Figure: ahbStat Window
Note if you change the cursor or marker position in the Transaction Analyzer window, the values will automatically be updated in the ahbStat window.
5. In the ahbStat window, click the Update button to update the number of transactions, read bytes and write bytes. The results will be similar to the following:
Figure: AHB Transaction Statistics
6. Change the cursor or marker positions in the Transaction Analyzer window to select the first and last transaction and then click Update in the ahbStat window. 7. In the ahbStat window, click the Command Frequency (Bar Graph) or Burst Type Frequency (Pie Chart) buttons to display the frequency of AHB commands or burst type for the transactions within the current cursor/ marker time.
The results will be similar to the following:
Figure: Bar Graph and Pie Chart
The TCL script includes sample code for highlighting the related transactions for certain statistic items. For example, in the Command Frequency bar graph window, you can click on bars to see their related transactions in the Transaction Analyzer window. Note the statistic results are calculated based on the transactions within the cursor and marker time. 8. In the Statistics Window for the Command Frequency, click the orange bar for SingleWrite. The corresponding transactions will be highlighted in the Transaction Analyzer window, similar to the following:
Figure: Highlighted Transactions
Example TCL Script

#!/bin/sh # the next line restarts using wish \ exec wish "$0" "$@" # Global variables set cursorTime 0 set markerTime 0 set cursorIdx 0 set markerIdx 0 set numTrans 0 set numRByte 0 set numWByte 0 # Statistics table set cmdTbl 0 # Related transaction list (command frequency) set trListSR {} set trListSW {} set trListBR {} set trListBW {} proc createMainWin {} { global cursorTime set w .template catch {destroy $w} toplevel $w wm title $w "TA Example" # TA example menu bar menu $w.menuBar -tearoff 0 $w.menuBar add cascade -menu $w.menuBar.file -label "File" underline 0 $w.menuBar add cascade -menu $w.menuBar.cmdTest -label "CommmandTest" -underline 0 $w.menuBar add cascade -menu $w.menuBar.staTest -label "Statistics" -underline 0 # File menu menu $w.menuBar.file -tearoff 0 $w.menuBar.file add command -label "TransactionAnalyzer..." command "createTA" -underline 0 $w.menuBar.file add command -label "nWave..." -command "createWV" -underline 0 $w.menuBar.file add command -label "Quit" -command "debExit" underline 0 $w configure -menu $w.menuBar # Command Test menu menu $w.menuBar.cmdTest -tearoff 0 $w.menuBar.cmdTest add command -label "Load File" -command "loadFile ahb32.bus.fsdb" -underline 0 $w.menuBar.cmdTest add command -label "Load a Stream" -command "taAddStream -stream MyAHB_1/AhbTransaction" -underline 0 $w.menuBar.cmdTest add command -label "Config Columns" -command "taConfigureColumn {Idx BeginTime EndTime Command StartAddress Master Slave}" -underline 0
Transaction Tutorials $w.menuBar.cmdTest add command -label "Set Radix of \"StartAddress\" to Decimal" -command "taSetRadix -column StartAddress -format Dec" -underline 0 $w.menuBar.cmdTest add command -label "Filter to Single Read" command "taFilter {Command = single read}" -underline 0 $w.menuBar.cmdTest add command -label "Sort by address" -command "taSort -orderBy StartAddress" -underline 0 $w.menuBar.cmdTest add command -label "Show All Transactions" command "taShowAll -stream MyAHB_1/AhbTransaction" -underline 0 $w.menuBar.cmdTest add command -label "Set Cursor to 760000" command "taSetCursor -time 760000" -underline 0 $w.menuBar.cmdTest add command -label "Set Marker to 14110000" command "taSetMarker -time 14110000" -underline 0 $w.menuBar.cmdTest add command -label "Jump To Cursor" -command "taJumpToCursor" -underline 0 $w.menuBar.cmdTest add command -label "Jump To Marker" -command "taJumpToMarker" -underline 0 $w.menuBar.cmdTest add command -label "Set 100th Transaction as Active" -command "taSetActiveTransaction -trans 100" -underline 0 $w.menuBar.cmdTest add command -label "Find Text (incr)" command "taFind incr" -underline 0 $w.menuBar.cmdTest add command -label "Delete Stream" -command "taDeleteStream -stream MyAHB_1/AhbTransaction" -underline 0 $w.menuBar.cmdTest add command -label "Close File" -command "taCloseFile" -underline 0 # Statistics menu menu $w.menuBar.staTest -tearoff 0 $w.menuBar.staTest add command -label "AHB Statistics" -command "showAhbStat" -underline 0 # Frame for Verdi commands frame $w.debFrame -borderwidth 10 frame $w.debFrame.cursorTime label $w.debFrame.cursorTime.cursorName -text "Cursor Time: " label $w.debFrame.cursorTime.cursorVal -width 20 -relief sunken -anchor w -textvar cursorTime pack $w.debFrame.cursorTime.cursorName -side left pack $w.debFrame.cursorTime.cursorVal button $w.debFrame.cmd1 -text "Command 1" -command {onCommand Command1} button $w.debFrame.cmd2 -text "Command 2" -command {onCommand Command2} button $w.debFrame.cmd3 -text "Command 3" -command {onCommand Command3} pack pack pack pack pack } $w.debFrame.cursorTime $w.debFrame.cmd1 -fill $w.debFrame.cmd2 -fill $w.debFrame.cmd3 -fill $w.debFrame -fill both -fill x x -pady x -pady x -pady -pady 2 2 2 2
# Create transaction analyzer window proc createTA {} { set ta_win [taCreateWindow] }
nTX Users Guide and Tutorial # Create waveform window proc createWV {} { set wv_win [wvCreateWindow] } proc onCommand btn { tk_dialog .dialog1 "Info" "Button $btn pressed." info 0 OK } # Cursor Time change callback proc cursorTimeChangedCB args { global cursorTime set cursorTime [lindex $args [expr [lsearch $args "-time"]+ 1]] } # Marker Time change callback proc markerTimeChangedCB args { global markerTime set markerTime [lindex $args [expr [lsearch $args "-time"]+ 1]] } # Table row selected callback proc tableRowSelectedCB args { global cmdTbl global trListSR trListSW trListBR trListBW set tbl [lindex $args [expr [lsearch $args "-table"] + 1]] if {$tbl == $cmdTbl} { switch [lindex $args [expr [lsearch $args "-rowIdx"] + 1]] { 0 {taHighlightTransactions -transList $trListSR -color cyan} 1 {taHighlightTransactions -transList $trListSW -color cyan} 2 {taHighlightTransactions -transList $trListBR -color cyan} 3 {taHighlightTransactions -transList $trListBW -color cyan} } } } # Marker Time change callback proc tableRowUnselectedCB args { taClearAllHighlightTransactions } # Load a file proc loadFile args { if {[taGetCurrentWindow] == "0"} { taCreateWindow } taOpenFile -file $args } # AHB statistic dialog proc showAhbStat {} { global cursorTime markerTime if ![winfo exists .ahbStat] { toplevel .ahbStat -border 5 frame .ahbStat.buttons pack .ahbStat.buttons -side bottom -fill x button .ahbStat.buttons.update -text "Update" \ -default active -command "updateAHBStat"
Transaction Tutorials pack .ahbStat.buttons.update -side left -expand 1 -pady 2 button .ahbStat.buttons.close -text Close \ -default active -command "destroy .ahbStat" pack .ahbStat.buttons.close -side left -expand 1 -pady 2 frame .ahbStat.info pack .ahbStat.info -expand yes -fill both -padx 1 -pady 2 foreach i {f1 f2 f3 f4 f5} { frame .ahbStat.info.$i -bd 2 pack .ahbStat.info.$i -side top -fill x -pady 2 label .ahbStat.info.$i.name label .ahbStat.info.$i.value -relief sunken -width 40 pack .ahbStat.info.$i.name -side left pack .ahbStat.info.$i.value -side right } .ahbStat.info.f1.name config -text "Cursor time:" .ahbStat.info.f2.name config -text "Marker time:" .ahbStat.info.f3.name config -text "Number of transactions:" .ahbStat.info.f4.name config -text "Number of read bytes:" .ahbStat.info.f5.name config -text "Number of write bytes:" .ahbStat.info.f1.value .ahbStat.info.f2.value .ahbStat.info.f3.value .ahbStat.info.f4.value .ahbStat.info.f5.value config config config config config -anchor -anchor -anchor -anchor -anchor w w w w w -textvar -textvar -textvar -textvar -textvar cursorTime markerTime numTrans numRByte numWByte
# Charts button .ahbStat.info.btChart -text "Burst Type Frequency (Pie Chart)" -command "showBurstChart" pack .ahbStat.info.btChart -side bottom -fill x button .ahbStat.info.cmdChart -text "Command Frequency (Bar Graph)" -command "showCmdChart" pack .ahbStat.info.cmdChart -side bottom -fill x -pady 2 } } # Display bar chart of AHB command distribution proc showCmdChart {} { global cursorTime markerTime cmdTbl global trListSR trListSW trListBR trListBW set set set set set set set set trListSR trListSW trListBR trListBW cntSR cntSW cntBR cntBW {} {} {} {}
0 0 0 0
if {[checkAhbStream] == 0} { return 0; } set transList [taGetTransactionList -time $cursorTime $markerTime] if {$transList == {0}} { return 0; }
nTX Users Guide and Tutorial foreach idx $transList { set cmd [lindex [taGetAttributeValue -trans $idx -attr "Command"] 1] switch $cmd { "single read" {incr cntSR; lappend trListSR $idx;} "single write" {incr cntSW; lappend trListSW $idx;} "burst read" {incr cntBR; lappend trListBR $idx;} "burst write" {incr cntBW; lappend trListBW $idx;} } } set cmdTbl [taCreateTable -name "Command Frequency" -cols {Command Count}] taAddRow -table $cmdTbl -valueList "SingleRead $cntSR" taAddRow -table $cmdTbl -valueList "SingleWrite $cntSW" taAddRow -table $cmdTbl -valueList "BurstRead $cntBR" taAddRow -table $cmdTbl -valueList "BurstWrite $cntBW" taCreateView -view BarGraph -table $cmdTbl } # Display pie chart of AHB burst type distribution proc showBurstChart {} { global cursorTime markerTime set cntSingle 0 set cntIncr 0 set cntWrap4 0 set cntIncr4 0 set cntWrap8 0 set cntIncr8 0 set cntWrap16 0 set cntIncr16 0 if {[checkAhbStream] == 0} { return 0; } set transList [taGetTransactionList -time $cursorTime $markerTime] if {$transList == {0}} { return 0; } foreach idx $transList { set bt [lindex [taGetAttributeValue -trans $idx -attr "BurstType"] 1] switch $bt { "single" {incr cntSingle} "incr" {incr cntIncr} "wrap 4" {incr cntWrap4} "incr 4" {incr cntIncr4} "wrap 8" {incr cntWrap8} "incr 8" {incr cntIncr8} "wrap 16" {incr cntWrap16} "incr 16" {incr cntIncr4} } } set btTbl [taCreateTable -name "Burst Type Fequency" -cols {Command Count}] taAddRow -table $btTbl -valueList "SINGLE $cntSingle" taAddRow -table $btTbl -valueList "INCR $cntIncr" taAddRow -table $btTbl -valueList "WRAP4 $cntWrap4" taAddRow -table $btTbl -valueList "INCR4 $cntIncr4" taAddRow -table $btTbl -valueList "WRAP8 $cntWrap8"
Transaction Tutorials taAddRow -table $btTbl -valueList "INCR8 $cntIncr8" taAddRow -table $btTbl -valueList "WRAP16 $cntWrap16" taAddRow -table $btTbl -valueList "INCR16 $cntIncr16" taCreateView -view PieChart -table $btTbl
# Update AHB statistics proc updateAHBStat {} { global cursorTime markerTime numTrans numRByte numWByte if {[checkAhbStream] == 0} { return 0; } set transList [taGetTransactionList -time $cursorTime $markerTime] if {$transList == {0}} { return 0; } # Update numTrans set numTrans [llength $transList] # Update numRByte and numWByte set numRByte 0 set numWByte 0 foreach idx $transList { set cmd [lindex [taGetAttributeValue -trans $idx -attr "Command"] 1] set beatCnt [lindex [taGetAttributeValue -trans $idx -attr "BeatCount"] 1] set sizePerBeat [lindex [taGetAttributeValue -trans $idx attr "SizePerBeat"] 1] set byteCnt [expr [lindex $sizePerBeat 0] * [lindex $beatCnt 1]] if {[string match *read $cmd]} { set numRByte [expr $numRByte + $byteCnt]; } elseif {[string match *write $cmd]} { set numWByte [expr $numWByte + $byteCnt]; } } } # Check if AHB transaction is loaded. proc checkAhbStream {} { if {[taSelectStream -stream MyAHB_1/AhbTransaction] == 0} { tk_dialog .dialog1 "Warning" "AHB stream not loaded!" info 0 OK return 0; } return 1; } # Append a Verdi menu item eMenuAppendItem -win $_nTrace1 -menuName Tools -itemName "Launch TA Example..." -tclCmd createMainWin -shortKey Y AddEventCallback [tk appname] cursorTimeChangedCB taCursorTimeChange 0 AddEventCallback [tk appname] markerTimeChangedCB taMarkerTimeChange 0 AddEventCallback [tk appname] tableRowSelectedCB stsTableRowSelected 0 AddEventCallback [tk appname] tableRowUnselectedCB stsTableRowUnselected 0
Generate an FSDB File with Transaction Information

A "simple" simulation-time transaction recognizer for the PCI bus protocol has been created using an open source code design called PCI Bridge IP Core from www.opencores.org. The following new tasks are provided to dump transactions along with normal HDL signals to a single FSDB file during simulation: $fsdb_tr_file $fsdb_tr_stream $fsdb_tr_attribute $fsdb_tr_begin $fsdb_tr_data $fsdb_tr_abort $fsdb_tr_end $fsdb_tr_close This section includes the following topics: PLI Background Procedures for Writing a PLI Routine Steps for Writing FSDB Steps to Dump Transactions to FSDB C Files for FSDB Writer API Use Provided C Files for PCI Transaction Dumping The first several sections provide background detail for creating PLI routines and using the FSDB writer API. If you are already familiar with this type of information, you can skip to the last section for the example.
PLI Background
The following summarizes the typical process for adding new PLI functions to your simulator environment. If you are already familiar with this procedure, you can skip to the next section. 1. Write C functions that have PLI routines (see following section for details). 2. Use the veriuser.c to associate the C function with the simulator system task.
3. Compile veriuser.c and C functions dynamically to generate shared lib (*.DLL in Windows and *.so in UNIX). Some simulators, such as, NCSIM also allows dynamic linking. 4. Based on the simulator, pass the C/C++ function details to the simulator during the compile process of Verilog code. (This is called linking. You should refer to the simulator user guide to understand how this is done.) 5. Once linked, run the simulator like any normal Verilog simulation. 6. During execution of the Verilog code by the simulator, when the simulator encounters the user defined system tasks (those starting with $), the execution control is passed to the PLI routine (C/C++ function).
Procedures for Writing a PLI Routine

The following summarizes the typical process for writing a new PLI routine (corresponds to #1 above). If you are already familiar with this procedure, you can skip to the next section. 1. Include the header files. The file veriuser.c containing the main PLI/C program must have the following lines:
#include <veriuser.h> #include <vxl_veriuser.h>
2. Specify the function prototype and variable declaration. This part of the program contains all the local variables and the functions that it invokes as part of the system call. In the present case, as explained in the next step, it will be as shown below.
int my_calltf(), my_checktf();
However, if the functions are in separate files, they should be declared as external functions.
extern int plicompile_tr_file(); extern int plitask_tr_file(); extern int plimisc_tr_file(); extern int plicompile_tr_scope(); extern int plitask_tr_scope(); extern int plimisc_tr_scope(); extern int plicompile_tr_stream(); extern int plitask_tr_stream();
nTX Users Guide and Tutorial extern int plimisc_tr_stream(); extern int plicompile_tr_attribute(); extern int plitask_tr_attribute(); extern int plimisc_tr_attribute(); extern int plicompile_tr_begin(); extern int plitask_tr_begin(); extern int plimisc_tr_begin(); extern int plicompile_tr_data(); extern int plitask_tr_data(); extern int plimisc_tr_data(); extern int plicompile_tr_abort(); extern int plitask_tr_abort(); extern int plimisc_tr_abort(); extern int plicompile_tr_end(); extern int plitask_tr_end(); extern int plimisc_tr_end(); extern int plicompile_tr_close(); extern int plitask_tr_close(); extern int plimisc_tr_close();
3. Create the essential data structure. There are a number of data structures that must be defined in a PLI program. These are the variables through which the simulator communicates with the C code. Veriusertfs[]: the main interaction between the C code that one writes and the Verilog simulator is done through a table. The simulator looks at this table and figures out which properties the system call corresponding to this PLI routine would be associated with.
static s_tfcell deb_veriusertfs[] = #else s_tfcell veriusertfs[] = #endif { { usertask, /* type of PLI routine */ 0, /* user_data value */ plicompile_tr_file, /* checktf routine */ 0, /* sizetf routine */ plitask_tr_file, /* calltf routine */ plimisc_tr_file, /* misctf routine */
Transaction Tutorials "$fsdb_tr_file", */ 1/* forward reference = true */ }, { usertask, 0, plicompile_tr_stream, 0, plitask_tr_stream, plimisc_tr_stream, "$fsdb_tr_stream", 1 }, { usertask, 0, plicompile_tr_attribute, 0, plitask_tr_attribute, plimisc_tr_attribute, "$fsdb_tr_attribute", 1 }, { usertask, 0, plicompile_tr_scope, 0, plitask_tr_scope, plimisc_tr_scope, "$fsdb_tr_scope", 1 }, { usertask, 0, plicompile_tr_begin, 0, plitask_tr_begin, plimisc_tr_begin, "$fsdb_tr_begin", 1 }, { usertask, 0, plicompile_tr_data, 0, /* system task/function name
nTX Users Guide and Tutorial plitask_tr_data, plimisc_tr_data, "$fsdb_tr_data", 1 }, { usertask, 0, plicompile_tr_abort, 0, plitask_tr_abort, plimisc_tr_abort, "$fsdb_tr_abort", 1 }, { usertask, 0, plicompile_tr_end, 0, plitask_tr_end, plimisc_tr_end, "$fsdb_tr_end", 1 }, { usertask, 0, plicompile_tr_close, 0, plitask_tr_close, plimisc_tr_close, "$fsdb_tr_close", 1 }, {0} /*** final entry must be 0 ***/ };
4. Include the appropriate tf routines. a. checktf routine Optional. Simulator checks the routine once right before simulation. b. calltf routine Perform the task or function. c. sizetf Returns the size.
Has to be a userfunction or userRealfunction routine. Default returns 32-bit values. d. misctf Routine called depending upon reasons e.g. reason_endofcompile, reason_paramvc, etc.
Steps for Writing FSDB

The following summarizes the typical process for writing an FSDB file. If you are already familiar with this procedure, you can skip to the next section. 1. Open an FSDB. An FSDB is opened by the ffw_Open API, which asks the application to give the file name and file type. The file type tells the source of the information, and is defined as fsdbFileType in fsdbShr.h header file. Once the file is opened successfully, the application can get a pointer to the FSDB writer object, which is a must parameter for most FSDB Writer APIs. 2. Set scale unit and other information. If the simulation does have a scale unit, then the application must set it. If it does not, then the default value is 1ns. Other information such as simulation date and simulator version are optional and for reference only. 3. Choose the tree creation scheme. The tree creation scheme is chosen by calling the ffw_CreateTreeByIdcodeScheme or ffw_CreateTreeByHandleScheme APIs. The default is idcode scheme if nothing is called. 4. Initialize data type creation (if necessary). If there is user defined data type, then the application must call the data type creation API to notify the FSDB writer, so that it can initialize the necessary data structures to store the data type definition. This can be done by calling the ffw_GetDataTypeCreationReady API. For most cases, there arent user defined data types; therefore, by default, the FSDB writer assumes there are no user defined data types. 5. Create the design hierarchy. The design hierarchy is composed by calling tree creation APIs. The ffw_BeginTree API creates a top scope, which has no name. The ffw_CreateScope API creates a scope, which is a child of the current scope, and then moves the current scope down to the newly created one. The ffw_CreateUpscope moves the current scope up to its parent scope.
The ffw_CreateVarByIdcode or ffw_CreateVarByHandle APIs create a variable, which belongs to the current scope. The ffw_EndTree API completes the design hierarchy. Note that an FSDB file may contain none, one, or multiple design hierarchies. 6. Create the value changes. Conceptually, a value change is composed of a pair: a time and a value. The time is created by calling ffw_CreateXCoorByHnL, while the value is created by calling the ffw_CreateVarValueByIdcode or ffw_CreateVarValueByHandle APIs. 7. Close the FSDB. An FSDB is closed by calling the ffw_Close API, which flushes the necessary in-core data and temporary files to the FSDB file. Then it performs some clean up tasks and completes the FSDB file.
Steps to Dump Transactions to FSDB

The following summarizes the typical process for dumping transactions to an FSDB file. If you are already familiar with this procedure, you can skip to the next section. 1. Create transaction file name in the FSDB file using $fsdb_tr_file. Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_file} {"FILE_ID"} (in Verilog code) $fsdb_tr_file("FILE_ID"); Example:
ncsim> call {$fsdb_tr_file} {"pci_tr.fsdb"}
2. Create a transaction stream name in the FSDB file using $fsdb_tr_stream. Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_stream} {"STREAM_ID"} (in Verilog code) $fsdb_tr_stream("STREAM_ID"); Examples:
ncsim> ncsim> ncsim> ncsim> call call call call {$fsdb_tr_stream} {$fsdb_tr_stream} {$fsdb_tr_stream} {$fsdb_tr_stream} {"CON_RD"} {"CON_WR"} {"IO_RD"} {"IO_WR"}
3. Create a transaction attribute name in the FSDB file using $fsdb_tr_attribute.
Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_attribute} {"ATTRIBUTE_ID"} (in Verilog code) $fsdb_tr_attribute("ATTRIBUTE_ID"); Examples:
ncsim> call {$fsdb_tr_attribute} {"addr"} ncsim> call {$fsdb_tr_attribute} {"data"}
4. Create a transaction hierarchical scope name in the FSDB file using $fsdb_tr_scope. Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_scope} {"Top.level1.leve2.level3...."} (in Verilog) code $fsdb_tr_scope("Top.level1.level2.level3....."); Example:
ncsim> call {$fsdb_tr_scope} {"SYSTEM.monitor32"}
5. Begin a transaction in the FSDB file (for this PCI transaction address phase) using $fsdb_tr_begin. Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_begin} {"TRANS_ID",address_attribute} (in Verilog code) $fsdb_tr_begin("TRANS_ID", address_attribute); Example:
$fsdb_tr_begin("IO_READ",ad_prev[PCI_BUS_DATA_RANGE:0]);
6. Begin a data transaction in the FSDB file (for this PCI transaction data phase) using $fsdb_tr_data. Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_data} {data_attribute} (in Verilog code) $fsdb_tr_data(data_attribute); Example:
$fsdb_tr_data("PCI_DATA",pci_ext_ad[PCI_BUS_DATA_RANGE:0]);
7. Abort any previous transaction in the FSDB file (for this PCI transaction abort phase) using $fsdb_tr_abort. Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_abort}
(in Verilog code) $fsdb_tr_abort; Example:

$fsdb_tr_abort;
8. End any transaction in the FSDB file (for this PCI transaction end phase) using $fsdb_tr_end. Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_end} (in Verilog code) $fsdb_tr_end; Example:
$fsdb_tr_end;
9. Close a transaction in the FSDB file using $fsdb_tr_close. Syntax: (in ncsim.rc) ncsim> call {$fsdb_tr_close} (in Verilog code) $fsdb_tr_close; Example:
$fsdb_tr_close;
C Files for FSDB Writer API

The following table summarizes the C files that were created for the corresponding FSDB writer API. These are provided in the <NOVAS_INST_DIR>/share/PLI/nTX_ex directory.
C File Name Function
fsdb_tr_abort.c
Abort transaction.
fsdb_tr_attribute.c Create transaction attribute name. fsdb_tr_begin.c fsdb_tr_close.c fsdb_tr_data.c fsdb_tr_end.c fsdb_tr_file.c Begin address transaction and create value change. Close the FSDB file. Begin data transaction and create value change. End transaction. Create transaction file name
fsdb_tr_scope.c fsdb_tr_stream.c
Get transaction hierarchical scope name from user to create the FSDB signal tree. Create transaction stream name in FSDB.
Use Provided C Files for PCI Transaction Dumping

The following steps summarize how to use the provided C files to dump the open source PCI Bridge IP Core transactions to the FSDB file. 1. Create a working directory.
% mkdir <working_dir>
2. Download the design and related documentation from the following link:
http://www.opencores.org/pdownloads.cgi/list/pci?no_loop=yes
You should select All. 3. Unzip and untar the downloaded file and install in your working directory. pci should be the main directory with several sub-directories. 4. The C files that are provided by Novas can be found in the <NOVAS_INST_DIR>/share/PLI/nTX_ex/link directory. Copy these files locally.
% cd <working_dir>/pci % cp <NOVAS_INST_DIR>/share/PLI/nTX_ex/link .
5. The new system tasks have been inserted into a new version of the module pci_bus_monitor (<install>/bench/verilog/pci_bus_monitor.v file). The file included in the download package need to be replaced with this new version.
% cd <working_dir>/pci/bench/verilog % mv pci_bus_monitor.v pci_bus_monitor.v.orig % cp <NOVAS_INST_DIR>/share/PLI/nTX_ex/bench/verilog/ pci_bus_monitor.v .
Now everything should be set up to run the example and generate an FSDB file with transaction information. The following steps are based on the NCSIM simulator. If you use a different simulator, please modify the make file appropriately. 1. Generate the libpli.so and pli.a for PLI linking.
% cd <working_dir>/pci/nTX_ex/link % make
2. Run ncvlog, ncelab and ncsim on the PCI design with FSDB dumping.
nTX Users Guide and Tutorial % cd <working_dir>/pci/sim/rtl_sim/run % make
Once the FSDB file is created, you can use the steps in the previous tutorial to load, view and manipulate the transactions.

Overview
The AMBA-AHB Transactor supports the following features: Data bus width from 8-bits to 1024-bits. Split transactions. Sequential and non-sequential single transfers. IDLE and BUSY transfer types.
BCF Format
Refer to the Bus Configuration File (BCF) Format section of the nTE chapter for a general description.
Name
The bus declaration (nte_AMBA_AHB_v2p8_2x16_32_ns) must be one of the supported transactors.
nte_AMBA_AHB_v2p8_2x16_32_ns MyAHB_1 {
Mapping Root
The MAPPING_ROOT specifies an optional path under which all of the signals in the users design may be accessed. This is prefixed to the signal names specified on the right hand side of the SIGMAP statements.
MAPPING_ROOT = "/AHB_2x2_system/test_AHB";
Signal Map
The SIGMAP statements map transactor signals on the left hand side to user signals on the right hand side. The transactor signals are pre-defined as shown in the file below and must not be changed; however, it is possible to leave signals unconnected by removing them from the sigmap section. If this is done they will be assigned a default value (normally 0). For example you can leave the HSPLIT signal unconnected for slaves that do not support the split feature.
NOTE: Clock can be mapped to /ahb_core/HCLK. The SIGMAP code example
is for an unmapped clock.
SIGMAP { // signals from master MUX (address, control and // write data MUX) // all of these are inputs to each slave /ahb_core/HTRANS ="/V_AHB_core/HTRANS"; /ahb_core/HADDR ="/V_AHB_core/HADDR"; /ahb_core/HWRITE ="/V_AHB_core/HWRITE"; /ahb_core/HSIZE ="/V_AHB_core/HSIZE"; /ahb_core/HBURST ="/V_AHB_core/HBURST"; /ahb_core/HPROT ="/V_AHB_core/HPROT"; /ahb_core/HWDATA ="/V_AHB_core/HWDATA"; // signals from slave MUX (read data and response) // all of these are inputs to each master /ahb_core/HREADY ="/V_AHB_core/HREADY"; /ahb_core/HRESP ="/V_AHB_core/HRESP"; /ahb_core/HRDATA ="/V_AHB_core/HRDATA"; // signals from arbiter /ahb_core/HGRANT[0] ="/V_AHB_core/HGRANT[0]"; /ahb_core/HGRANT[1] ="/V_AHB_core/HGRANT[1]"; /ahb_core/HMASTER ="/V_AHB_core/HMASTER"; /ahb_core/HMASTLOCK ="/V_AHB_core/HMASTLOCK"; // signals from each master /ahb_core/HBUSREQ[0] ="/V_AHB_core/HBUSREQ[0]"; /ahb_core/HBUSREQ[1] ="/V_AHB_core/HBUSREQ[1]"; /ahb_core/HLOCK[0] ="/V_AHB_core/HLOCK[0]"; /ahb_core/HLOCK[1] ="/V_AHB_core/HLOCK[1]"; // signals from each slave /ahb_core/HSPLIT_0[0] ="/V_AHB_or_gate_S[0]/HSPLIT[0]"; /ahb_core/HSPLIT_0[1] ="/V_AHB_or_gate_S[0]/HSPLIT[1]"; /ahb_core/HSPLIT_1[0] ="/V_AHB_or_gate_S[1]/HSPLIT[0]"; /ahb_core/HSPLIT_1[1] ="/V_AHB_or_gate_S[1]/HSPLIT[1]"; }
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file:
clk_init_value: The initial value of the clock (0 or 1). clk_phase_shift: The time of the first transition from the initial value. clk_1st_time: The relative time of the first clock change after the initial phase shift change. clk_2nd_time: The relative time of second clock change after the previous change. setup_time: The setup time for all AHB signals. hold_time: The hold time for all AHB signals. warn_after_n_ready_low_cycles: A warning will be issued when the ready signal from selected slave has remained low for n clock cycles after it was selected; where n is equal to the number set for the parameter. allow_no_bus_transfers: Recognize AHB_no_bus_transfer transactions when set to the default state of true. The clock set up is important for the correct operation of the transactor. An example is shown below:
Figure: Clock Setup

// parameters PARAMETER { clk_init_value = 0; //initial value of clock clk_phase_shift = 0 ns; //ns clk_1st_time = 5 ns; //ns clk_2nd_time = 5 ns; //ns setup_time = 2 ns; //ns hold_time = 1 ns; //ns warn_after_n_ready_low_cycles = 100; allow_no_bus_transfers = true; }
NOTE: PARAMETER code example is for an unmapped clock. If the clock is
mapped then clk_* parameters do not need to be set.
Transactor Configurations
A number of transactor configurations are available. The naming convention used is nte_AMBA_AHB_ver_ms_dw_tu, where ver, ms, dw and tu have the following meanings and valid values: ver version (v2p8) ms master/slave configuration, indicates the maximum number of masters and split-capable slaves (2x16, 4x16, 8x16, 16x16) dw data width, the width of the read and write data busses (16, 32, 64, 128, 256) tu time unit (ps, ns, fs). This does not have to match the time scale of the input FSDB file; however, any signal changes below this time resolution will not be seen by nTE.
Transaction Hierarchy
The transactor consists of a number of transactions that enable communication at different levels of abstraction. In this section the function, types and attributes of these transactions are described in detail. The AHB Transactor recognizes transactions from the AHB active signals. The protocol tree shows how the transactions are inter-related. At the highest level are transactions representing complete transfers. These transactions are then made up of one or more of the appropriate phases, e.g. AHB_no_bus_transfer contains AHB_request_grant_phase. These are in turn made up of one or more of the appropriate cycles, e.g. AHB_request and AHB_grant. Referring to the protocol tree can help to visualize transactions that are recognized by the transactor. An additional transaction, orthogonal to the core transaction hierarchy, represents the output of the SPLIT signals from AHB slaves.
Protocol Tree
Transaction Description
NOTE: The >=> notation is used to convey the direction of information
transfer, from the unit to the left of the symbol, to the unit (or units) to the right of the symbol. configuration in use, and is specified in the form bit attribute_name[C_constant] (see Transactor Constants).
NOTE: The size of a number of the attributes is dependant on the transactor
AHB_single_transfer
AHB_single_transfer is a multi-directional transaction used for single bus transfers. It will connect a split transfer with its respective completion. Attributes:
T_request Request master >=> arbiter, T_lock Lock master >=> arbiter, T_WriteNread WriteNread MUX_M >=> slave, word Address MUX_M >=> slave & decoder & arbiter, T_burst_type BurstType MUX_M >=> slave & arbiter, T_transfer_size TransferSize MUX_M >=> slave, T_PROT ProtectionCtrl MUX_M >=> slave, T_slave_response Response MUX_S >=> master & arbiter, word Data MUX_S >=> master
AHB_idle_busy_transfer
AHB_idle_bust_transfer is a multi-directional transaction used when a bus master is granted access to the bus but does not immediately perform a data transfer, or is to continue with a transfer later. Attributes:
T_request Request master >=> arbiter, T_lock Lock master >=> arbiter, T_WriteNread WriteNread MUX_M >=> slave, word Address MUX_M >=> slave & decoder & arbiter T_burst_type BurstType MUX_M >=> slave & arbiter, T_transfer_size TransferSize MUX_M >=> slave, T_PROT ProtectionCtrl MUX_M >=> slave, T_slave_response Response MUX_S >=> master & arbiter, word Data MUX_S >=> master
AHB_transfer_attempt
AHB_transfer_attempt is a multi-directional transaction used for a complete data, split, busy, or idle transfer.
Attributes:
T_request Request master >=> arbiter, T_lock Lock master >=> arbiter, T_WriteNread WriteNread MUX_M >=> slave, word Address MUX_M >=> slave & decoder & arbiter, T_transfer_type TransferType MUX_M >=> slave & arbiter, T_burst_type BurstType MUX_M >=> slave & arbiter, T_transfer_size TransferSize MUX_M >=> slave, T_PROT ProtectionCtrl MUX_M >=> slave, T_slave_response Response MUX_S >=> master & arbiter, word Data MUX_S >=> master
AHB_no_bus_transfer
AHB_no_bus_transfer is a multi-directional transaction used as a result of a master not being granted access to the bus by the arbiter. Attributes:
T_request Request T_lock Lock master >=> arbiter, master >=> arbiter
AHB_transfer_data
AHB_transfer_data item is a multi-directional transaction used to perform a data transfer. Attributes:
T_WriteNread WriteNread MUX_M word Address MUX_M T_transfer_type TransferType T_burst_type BurstType MUX_M T_transfer_size TransferSize T_PROT ProtectionCtrl MUX_M T_slave_response Response word Data MUX_S >=> slave, >=> slave & decoder & arbiter, MUX_M >=> slave & arbiter, >=> slave & arbiter, MUX_M >=> slave, >=> slave, MUX_S >=> master & arbiter, >=> master
AHB_control_phase
AHB_control_phase is a multi-directional transaction used to perform the control phase of a data transfer. Attributes:
T_WriteNread WriteNread MUX_M >=> slave, word Address MUX_M >=> slave & decoder & arbiter, T_transfer_type TransferTypeMUX_M >=> slave & arbiter, T_burst_type BurstType MUX_M >=> slave & arbiter, T_transfer_size TransferSizeMUX_M >=> slave, T_PROT ProtectionCtrl MUX_M >=> slave
AHB_data_read_phase
AHB_data_read_phase is a multi-directional transaction used to perform the read phase of a data transfer. Attributes:
T_slave_response Response word Data MUX_S >=> master & arbiter, MUX_S >=> master
AHB_data_write_phase
AHB_data_write_phase is a multi-directional transaction used to perform the write phase of a data transfer. Attributes:
T_slave_response Response word Data MUX_S >=> master & arbiter, MUX_M >=> slave
AHB_response_cycle
AHB_response_cycle is a multi-directional transaction used to perform the response to the data transfer. Attributes:
bit ready MUX_S >=> master & arbiter & slave T_slave_response Response MUX_S >=> master & arbiter
AHB_request_grant_phase
AHB_request_grant_phase is a bi-directional transaction used to perform request and granting, or not granting, of access to the bus. Attributes:
T_request Request T_lock Lock T_grant Grant master >=> arbiter, master >=> arbiter, arbiter >=> master
AHB_split_info_core
AHB_split_info_core is a uni-directional transaction used to unlock a master from a split transaction, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit split_info_core[C_max_num_masters]
AHB_active_master
AHB_active_master is a uni-directional transaction used to indicate the ID of the master currently active on the bus, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit active_master[4]
AHB_write_data
AHB_write_data is a uni-directional transaction used to pass data from a master to a slave, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit Data[C_datawidth]
AHB_read_data
AHB_read_data is a uni-directional transaction used to pass data from a slave to a master, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
AHB_address
AHB_address is a uni-directional transaction used to pass the address from a master to a slave, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit Address[C_addresswidth]
AHB_slave_control
AHB_slave_control is a uni-directional transaction used to instruct the slave to control its response, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit WriteNread, T_transfer_size TransferSize, bit ProtectionCtrl[4]
AHB_trans_control
AHB_trans_control is a uni-directional transaction used to control the transfer on the bus, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
T_transfer_type TransferType, T_burst_type BurstType
AHB_request
AHB_request is a uni-directional transaction used to request access to the bus, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit Request, bit Lock
AHB_grant
AHB_grant is a uni-directional transaction used to grant access to the bus, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit grant
AHB_master_Locked
AHB_master_Locked is a uni-directional transaction used to lock a master access to the bus, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit master_Locked
AHB_slave_ready
AHB_slave_ready is a uni-directional transaction used to indicate that a transfer has completed on the bus, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit ready
AHB_slave_response
AHB_slave_response is a uni-directional transaction used to provide additional information on the status of the transfer, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
T_slave_response Response
stp_split_info
stp_split_info is a uni-directional transaction, representing the output of the SPLIT signals from AHB slaves, and synchronized to the rising edge of the system clock of duration one clock period. It is orthogonal to the core transaction hierarchy and is not included in the protocol tree. It has no attributes.
Wires
Name HTRANS HADDR HWRITE HSIZE HBURST HPROT HWDATA HREADY HRESP HRDATA HBUSREQ HLOCK HGRANT HMASTER Type bit array, size 2 bit array, size address_width bit bit array, size 3 bit array, size 3 bit array, size 4 bit array bit array, size 2 array of bits, size number_of_masters array of bits, size number_of_masters array of bits, size number_of_masters bit array, size 4 Direction MUX_M >=> slave & arbiter MUX_M >=> slave & decoder & arbiter MUX_M >=> slave MUX_M >=> slave MUX_M >=> slave & arbiter MUX_M >=> slave MUX_S >=> master & arbiter & slave MUX_S >=> master & arbiter
bit array, size data_width MUX_M >=> slave
bit array, size data_width MUX_S >=> master Master >=> arbiter Master >=> arbiter Arbiter >=> master arbiter >=> MUX_M & slave arbiter >=> master & slave
HMASTLOCK bit
Name HSPLIT_core HCLK HRESETn
Type
Direction
bit array, size or_gate_S >=> arbiter max_number_of_masters bit bit clock_source >=> arbiter & master & slave reset_source >=> arbiter & master & slave
Additional Information
Data Types
In addition to the standard transactor types, such as int, and bit, the AHB transactor makes use of the following types:
type enum T_slave_response:2 { OKAY = 0, ERROR = 1, RETRY = 2, SPLIT = 3 }; type enum T_transfer_type:2 { IDLE = 0, BUSY = 1, NONSEQ = 2, SEQ = 3 }; type enum T_burst_type:3 { SINGLE = 0, INCR = 1, WRAP4 = 2, INCR4 = 3, WRAP8 = 4, INCR8 = 5, WRAP16 = 6, INCR16 = 7
Appendix A: AMBA AHB Transactor }; type enum T_transfer_size:3 { bits_8 = 0, bits_16 = 1, bits_32 = 2, bits_64 = 3, bits_128 = 4, bits_256 = 5, bits_512 = 6, bits_1024 = 7 }; type enum T_WriteNread:1 { READ = 0, WRITE = 1 }; type enum T_data_nOpcode:1 { OPCODE= 0, DATA = 1 }; type enum T_privileged:1 { USER = 0, PRIVILEGED = 1 }; type enum T_bufferable:1 { NOT_BUFFERABLE= 0, BUFFERABLE = 1 }; type enum T_cacheable:1 { NOT_CACHEABLE = 0, CACHEABLE = 1 }; type struct T_PROT { T_data_nOpcode data_opcode; T_privileged privileged; T_bufferable bufferable;
nTX Users Guide and Tutorial T_cacheable cacheable; }; type enum T_request:1 { NO_REQUEST= 0, REQUEST = 1 }; type enum T_lock:1 { NO_LOCK = 0, LOCK = 1 }; type enum T_grant:1 { NO_GRANT = 0, GRANT = 1 };
Transactor Constants
C_max_num_masters the number of masters in use (valid values are 2, 4, 8 and 16) C_datawidth the width of the data bus (valid values are 16, 32, 64, 128 and 256) C_addresswidth the width of the address bus (valid value is 32)

Overview
The AMBA-AHB Transactor supports the following features: Data bus width from 8-bits to 1024-bits. Sequential and non-sequential single transfers. IDLE and BUSY transfer types.
BCF Format
Name
The bus declaration (nte_AMBA_AHB_lite_v2p8_32_ns) must be one of the supported transactors.
nte_AMBA_AHB_lite_v2p8_32_ns MyAHB_1 {
Mapping Root
MAPPING_ROOT = "/AHB_lite_system/test_AHB";
Signal Map
The SIGMAP statements map transactor signals on the left hand side to user signals on the right hand side. The transactor signals are pre-defined as shown in the file below and must not be changed; however, it is possible to leave signals unconnected by removing them from the sigmap section. If this is done they will be assigned a default value (normally 0).
NOTE: Clock can be mapped to /ahb_core/HCLK. The SIGMAP code example
SIGMAP { // signals from master MUX (address, control and // write data MUX) // all of these are inputs to each slave /ahb_core/HTRANS ="/V_AHB_core/HTRANS"; /ahb_core/HADDR ="/V_AHB_core/HADDR"; /ahb_core/HWRITE ="/V_AHB_core/HWRITE"; /ahb_core/HSIZE ="/V_AHB_core/HSIZE"; /ahb_core/HBURST ="/V_AHB_core/HBURST"; /ahb_core/HPROT ="/V_AHB_core/HPROT"; /ahb_core/HWDATA ="/V_AHB_core/HWDATA"; /ahb_core/HMASTLOCK ="/V_AHB_core/HMASTLOCK"; // signals from slave MUX (read data and response) // all of these are inputs to each master /ahb_core/HREADY ="/V_AHB_core/HREADY"; /ahb_core/HRESP ="/V_AHB_core/HRESP"; /ahb_core/HRDATA ="/V_AHB_core/HRDATA"; }
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file: clk_init_value: The initial value of the clock (0 or 1). clk_phase_shift: The time of the first transition from the initial value. clk_1st_time: The relative time of the first clock change after the initial phase shift change. clk_2nd_time: The relative time of the second clock change after the previous change. setup_time: The setup time for all AHB signals. hold_time: The hold time for all AHB signals. warn_after_n_ready_low_cycles: A warning will be issued when the ready signal from selected slave has remained low for n clock cycles
after it was selected; where n is equal to the number set for the parameter. The clock set up is important for the correct operation of the transactor. An example is shown below:
Figure: Clock Setup

// parameters PARAMETER { clk_init_value = 0; //initial value of clock clk_phase_shift = 0 ns; //ns clk_1st_time = 5 ns; //ns clk_2nd_time = 5 ns; //ns setup_time = 2 ns; //ns hold_time = 1 ns; //ns warn_after_n_ready_low_cycles = 100; }
A number of transactor configurations are available. The naming convention used is nte_AMBA_AHB_lite_ver_dw_tu, where ver, dw and tu have the following meanings and valid values: ver version (v2p8) dw width of data bus (16, 32, 64, 128, 256) tu time unit (ps, ns, fs). This does not have to match the time scale of the input FSDB file; however, any signal changes below this time resolution will not be seen by nTE.
The AHB-Lite transactor consists of a number of transactions that enable communication at different levels of abstraction. In this section the function, types and attributes of these transactions are described in detail. The protocol tree shows how the transactions are inter-related. The highest level includes transactions representing complete transfers. These transactions are then made up of one or more of the appropriate phases, e.g. AHB_single_transfer contains AHB_transfer_data, which is made up of AHB_control_phase and AHB_data_write_phase, or AHB_data_read_phase. These are in turn made up of one or more of the appropriate cycles, e.g. AHB_control_phase is made up of AHB_address, AHB_slave_control and AHB_trans_control transactions. Referring to the protocol tree can help to visualize transactions that are recognized by the transactor.
Protocol Tree
AHB_single_transfer
AHB_single_transfer is a multi-directional transaction used for single bus transfers. Attributes:
T_WriteNread WriteNread master >=> slave, word Address master >=> slave & decoder, T_burst_type BurstType master >=> slave, T_transfer_size TransferSize master >=> slave, T_PROT ProtectionCtrl master >=> slave, T_slave_response Response MUX_S >=> master, word Data MUX_S >=> master
AHB_idle_busy_transfer
AHB_idle_busy_transfer is a multi-directional transaction used when the master does not perform a read or write transfer. Attributes:
T_WriteNread WriteNread master >=> slave, word Address master >=> slave & decoder T_burst_type BurstType master >=> slave T_transfer_size TransferSize master >=> slave, T_PROT ProtectionCtrl master >=> slave, T_slave_response Response MUX_S >=> master, word Data MUX_S >=> master
AHB_transfer_data
AHB_transfer_data item is a multi-directional transaction used to perform a data transfer. Attributes:
T_WriteNread WriteNread word Address T_transfer_type TransferType master >=> slave, master >=> slave & decoder, master >=> slave,
Appendix B: AMBA AHB Lite Transactor T_burst_type BurstType T_transfer_size TransferSize T_PROT ProtectionCtrl T_slave_response Response word Data master >=> slave &, master >=> slave, master >=> slave, MUX_S >=> master, MUX_S >=> master
AHB_control_phase
AHB_control_phase is a multi-directional transaction used to perform the control phase of a data transfer. Attributes:
T_WriteNread WriteNread word Address T_transfer_type TransferType T_burst_type BurstType T_transfer_size TransferSize T_PROT ProtectionCtrl master master master master master master >=> >=> >=> >=> >=> >=> slave, slave & decoder, slave, slave, slave, slave
AHB_data_read_phase
AHB_data_read_phase is a multi-directional transaction used to perform the read phase of a data transfer. Attributes:
T_slave_response Response word Data MUX_S >=> master, MUX_S >=> master
AHB_data_write_phase
AHB_data_write_phase is a multi-directional transaction used to perform the write phase of a data transfer. Attributes:
T_slave_response Response word Data MUX_S >=> master, master >=> slave
AHB_response_cycle
AHB_response_cycle is a multi-directional transaction used to perform the response to the data transfer. Attributes:
bit ready T_slave_response Response MUX_S >=> master & slave MUX_S >=> master
AHB_write_data
AHB_write_data is a uni-directional transaction used to pass data from the master to a slave, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
AHB_read_data
AHB_read_data is a uni-directional transaction used to pass data from a slave to the master, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
AHB_address
AHB_address is a uni-directional transaction used to pass the address from the master to a slave, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit Address[C_addresswidth]
AHB_slave_control
AHB_slave_control is a uni-directional transaction used to pass control information from the master to a slave, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit WriteNread, T_transfer_size TransferSize, bit ProtectionCtrl[4]
AHB_trans_control
AHB_trans_control is a uni-directional transaction used to pass additional control information from the master to a slave, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
T_transfer_type TransferType, T_burst_type BurstType
AHB_master_Locked
AHB_master_Locked is a uni-directional transaction used to indicate the master wishes locked access to the slave, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit master_Locked
AHB_slave_ready
AHB_slave_ready is a uni-directional transaction used to indicate that a transfer has completed on the bus, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
bit ready
AHB_slave_response
AHB_slave_response is a uni-directional transaction used to indicate the transfer completion response of the slave, synchronized to the rising edge of the system clock of duration one clock period. Attributes:
T_slave_response Response
Wires
Name HTRANS HADDR HWRITE HSIZE HBURST HPROT HWDATA HREADY HRESP HRDATA Type bit array, size 2 bit array, size address_width bit bit array, size 3 bit array, size 3 bit array, size 4 bit array, size data_width bit array bit array, size 2 bit array, size data_width Direction master >=> slave master >=> slave & decoder master >=> slave master >=> slave master >=> slave master >=> slave master >=> slave MUX_S >=> master & slave MUX_S >=> master MUX_S >=> master master >=> slave
HMASTLOCK bit
Name HCLK HRESETn
Type bit bit
Direction clock_source >=> master & slave reset_source >=> master & slave
Data Types
In addition to the standard transactor types, such as int, and bit, the AHB-Lite transactor makes use of the following types: type enum T_slave_response:2
{ OKAY = 0, ERROR = 1, RETRY = 2, SPLIT = 3 }; type enum T_transfer_type:2 { IDLE = 0, BUSY = 1, NONSEQ = 2, SEQ = 3 }; type enum T_burst_type:3 { SINGLE = 0, INCR = 1, WRAP4 = 2, INCR4 = 3, WRAP8 = 4, INCR8 = 5, WRAP16 = 6, INCR16 = 7 };
Appendix B: AMBA AHB Lite Transactor type enum T_transfer_size:3 { bits_8 = 0, bits_16 = 1, bits_32 = 2, bits_64 = 3, bits_128 = 4, bits_256 = 5, bits_512 = 6, bits_1024 = 7 }; type enum T_WriteNread:1 { READ = 0, WRITE = 1 }; type enum T_data_nOpcode:1 { OPCODE= 0, DATA = 1 }; type enum T_privileged:1 { USER = 0, PRIVILEGED = 1 }; type enum T_bufferable:1 { NOT_BUFFERABLE= 0, BUFFERABLE = 1 }; type enum T_cacheable:1 { NOT_CACHEABLE = 0, CACHEABLE = 1 }; type struct T_PROT { T_data_nOpcode data_opcode; T_privileged privileged; T_bufferable bufferable; T_cacheable cacheable; };
type enum T_request:1 { NO_REQUEST= 0, REQUEST = 1 }; type enum T_lock:1 { NO_LOCK = 0, LOCK = 1 }; type enum T_grant:1 { NO_GRANT = 0, GRANT = 1 };
C_datawidth the width of the data bus (valid values are 16, 32, 64, 128 and 256) C_addresswidth the width of the address bus (valid value is 32)

Overview
The AMBA-AXI Transactor supports the following features: AMBA 2.0 APB Support for single slave systems with no select bus.
BCF Format
Name
The bus declaration (nte_AMBA_APB_v1p0_32x16_ns) must be one of the supported transactors.
nte_AMBA_APB_v1p0_32x16_ns my_APB {
Mapping Root
MAPPING_ROOT = "/APB_test/st_APB/APB_bus";
Signal Map
The SIGMAP statements map transactor signals on the left hand side to user signals on the right hand side. The transactor signals are pre-defined as shown in the file below and must not be changed. This example is for a transactor with 16 APB slaves connected. If there are less slaves in the system, then some of these can be left unconnected (remove the mapping from the SIGMAP block).
SIGMAP { /APB_bus/PADDR /APB_bus/PSEL[0] /APB_bus/PSEL[1] /APB_bus/PSEL[2] /APB_bus/PSEL[3] /APB_bus/PSEL[4] /APB_bus/PSEL[5] /APB_bus/PSEL[6] /APB_bus/PSEL[7] /APB_bus/PSEL[8] /APB_bus/PSEL[9] /APB_bus/PSEL[10] /APB_bus/PSEL[11] /APB_bus/PSEL[12] /APB_bus/PSEL[13] /APB_bus/PSEL[14] /APB_bus/PSEL[15] /APB_bus/PENABLE /APB_bus/PWRITE /APB_bus/PRDATA /APB_bus/PWDATA } = = = = = = = = = = = = = = = = = = = = = "/PADDR"; "/PSEL_0"; "/PSEL_1"; "/PSEL_2"; "/PSEL_3"; "/PSEL_4"; "/PSEL_5"; "/PSEL_6"; "/PSEL_7"; "/PSEL_8"; "/PSEL_9"; "/PSEL_10"; "/PSEL_11"; "/PSEL_12"; "/PSEL_13"; "/PSEL_14"; "/PSEL_15"; "/PENABLE"; "/PWRITE"; "/PRDATA"; "/PWDATA";
NOTE: Clock can be mapped to /APB_bus/PCLK. The SIGMAP code example
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file. Configuration of the transactor is made via the PARAMETER section of the bcf file. The available parameters are: clk_init_value: The initial value of the clock (0 or 1). clk_phase_shift: The time of the first transition from the initial value. clk_1st_time: The relative time of the first clock change after the initial phase shift change.
clk_2nd_time: The relative time of the second clock change after the previous change.
setup_time: The setup time for all APB signals. hold_time: The hold time for all APB signals. use_select: Use the slave select bus (true or false). Defaults to true. Set this to false if the system has a single slave, and no PSEL bus. Note that if this is set to false, then PSEL should not be mapped in the SIGMAP block. Setting this to false will also disable recognition of idle transactions. allow_idle: Recognize idle transactions (true or false). Defaults to true. Setting to false will result in smaller output FSDB. The clock set up is important to the correct operation of the transactor. An example is shown below:
Figure: Clock Setup

// parameters PARAMETER { clk_init_value clk_phase_shift clk_1st_time clk_2nd_time setup_time hold_time use_select allow_idle }
= = = = = = = =
0b0; 50 ns; 50 ns; 50 ns; 1 ns; 1 ns; true; true;
A number of transactor configurations are available. The naming convention used is nte_AMBA_APB_ver_dwxmax_slaves_tu where ver, dw, max_slaves and tu have the following meanings and valid values: ver version (v1p0) dw width of data bus (8,16, 32)
tu time unit (ps, ns, fs). This does not have to match the time scale of the input FSDB file; however, any signal changes below this time resolution will not be seen by nTE. max_slaves maximum number of connected slaves, sets width of PSEL (16, 64)
The APB transactor consists of a number of transactions that enable communication at different levels of abstraction. In this section the function, types and attributes of these transactions are described in detail. Referring to the protocol tree can help to visualize transactions that are recognized by the transactor.
Protocol Tree
transfer, from the unit to the left of the symbol, to the unit (or units) to the right of the symbol.
read
read is an APB read from a master (typically an APB bridge) to a slave. Attributes:
word bit bit slave_id addr[C_APB_addresswidth] data[C_APB_wdatawidth] master >=> slave, master >=> slave, slave >=> master
write
write is an APB write from a master (typically an APB bridge) to a slave. Attributes:
word bit bit slave_id, addr[C_APB_addresswidth], data[C_APB_wdatawidth]
idle
A single cycle transaction representing the IDLE state of the APB bus (PSELx = 0, PENABLE = 0). Attributes: None
setup
A single cycle transaction representing the SETUP state of the APB bus (PSELx = 1, PENABLE = 0). Attributes indicate the currently selected slave, along with values of address, RnW and wdata if it is valid. Attributes:
word T_WriteNread bit bit slave_id, RnW, addr[C_APB_addresswidth], wdata[C_APB_wdatawidth] //only used/written to //when RnW == write
enable
A single cycle transaction representing the ENABLE state of the APB bus (PSELx = 1, PENABLE = 1). Attributes indicate the currently selected slave,
along with values of address, RnW and data (either read or write data depending on the current value of RnW). Attributes:
word slave_id master >=> slave, T_WriteNread RnW master >=> slave, bit addr[C_APB_addresswidth] master >=> slave, // data holds either read or write data depending on RnW bit data[] master >=> slave || slave >=> master
selected_slave
selected slave is a single cycle transaction used to indicate whether or not a slave is selected, and if so, the id of that slave. Attributes:
bool word selected, slave_id
enable_cycle
enable_cycle is a single cycle transaction that holds the value of the enable signal. Attributes:
bit en
control_cycle
control_cycle is a single cycle transaction that holds the values of the RnW and address signals. Attributes:
T_WriteNread bit RnW, addr[C_APB_addresswidth]
wdata_cycle
wdata_cycle is a single cycle transaction that holds the value of the write data bus. Attributes:
bit wdata[C_APB_wdatawidth]
rdata_cycle
rdata_cycle is a single cycle transaction that holds the value of the read data bus. Attributes:
nTX Users Guide and Tutorial bit rdata[C_APB_rdatawidth]
Wires
For a description of each of these wires (signals), see the section on Signal Descriptions in the AMBA AXI Protocol Specification.
Name PCLK PADDR PSEL PENABLE PWRITE PRDATA PWDATA Type bit bit [C_APB_addresswidth] [C_num_slaves] bit bit bit bit [C_APB_rdatawidth] bit [C_APB_wdatawidth] Direction clock_source >=> master & slave master to slave master to slave master to slave master to slave slave to master master to slave
Data Types
In addition to the standard transactor types, such as int, and bit, the APB transactor makes use of the following types:
type enum T_WriteNread:1 { READ = 0, WRITE = 1 };
C_APB_rdatawidth the width of the read data bus C_APB_wdatawidth the width of the write data bus C_APB_addresswidth the width of the address bus C_num_slaves the width of the slave select bus (determines the maximum number of slaves)

Overview
The AMBA-AXI Transactor supports the following features: Configurable bus widths (address, read data, write data, transaction ID) Recognition of complete bursts as a single transaction Out-of-order transaction completion Full support for narrow transfers and unaligned transfers (encoding/ decoding of data onto the data bus)
BCF Format
Name
The bus declaration (nte_AMBA_AXI_v1p6_32_32_32_4_ns) must be one of the supported transactors.
nte_AMBA_AXI_v1p6_32_32_32_4_ns my_AXI {
Mapping Root
MAPPING_ROOT = "/verilog_conc_model/AXI_structure/iAXI";
Signal Map
NOTE: Clock can be mapped to /AXI/ACLK. The SIGMAP code example is
for an unmapped clock.
SIGMAP { // From reset source /AXI/ARESETn = "/ARESETn"; // Write address channel /AXI/AWVALID = "/AWVALID"; /AXI/AWADDR = "/AWADDR"; /AXI/AWLEN = "/AWLEN"; /AXI/AWSIZE = "/AWSIZE"; /AXI/AWBURST = "/AWBURST"; /AXI/AWLOCK = "/AWLOCK"; /AXI/AWCACHE = "/AWCACHE"; /AXI/AWPROT = "/AWPROT"; /AXI/AWID = "/AWID"; /AXI/AWREADY = "/AWREADY"; // Read address channel /AXI/ARVALID = "/ARVALID"; /AXI/ARADDR = "/ARADDR"; /AXI/ARLEN = "/ARLEN"; /AXI/ARSIZE = "/ARSIZE"; /AXI/ARBURST = "/ARBURST"; /AXI/ARLOCK = "/ARLOCK"; /AXI/ARCACHE = "/ARCACHE"; /AXI/ARPROT = "/ARPROT"; /AXI/ARID = "/ARID"; /AXI/ARREADY = "/ARREADY"; // Read channel /AXI/RVALID /AXI/RLAST /AXI/RDATA /AXI/RRESP /AXI/RID /AXI/RREADY // Write channel
= = = = = =
"/RVALID"; "/RLAST"; "/RDATA"; "/RRESP"; "/RID"; "/RREADY";
Appendix D: AMBA AXI Transactor /AXI/WVALID /AXI/WLAST /AXI/WDATA /AXI/WSTRB /AXI/WID /AXI/WREADY = = = = = = "/WVALID"; "/WLAST"; "/WDATA"; "/WSTRB"; "/WID"; "/WREADY";
// Write response channel /AXI/BVALID = "/BVALID"; /AXI/BRESP = "/BRESP"; /AXI/BID = "/BID"; /AXI/BREADY = "/BREADY"; }
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file. Configuration of the transactor is made via the PARAMETER section of the bcf file. The available parameters are: clk_init_value: The initial value of the clock (0 or 1). clk_phase_shift: The time of the first transition from the initial value. clk_1st_time: The relative time of the first clock change after the initial phase shift change. clk_2nd_time: The relative time of second clock change after the previous change. setup_time: The setup time for all AXI signals. hold_time: The hold time for all AXI signals. byte_level_transactions: Boolean value (true/false) to determine whether the top level AXI transactions are AXI_read/write (true) or AXI_buswidth_read/write (false). rdata_width: Tthe width of the read data bus (in bits), must be less than or equal to the maximum width for the transactor. wdata_width: The width of the write data bus (in bits), must be less than or equal to the maximum width for the transactor. The clock set up is important to the correct operation of the transactor. An example is shown below:
Figure: Clock Setup

// parameters PARAMETER { clk_init_value clk_phase_shift clk_1st_time clk_2nd_time setup_time hold_time byte_level_transactions rdata_width wdata_width }
= = = = = = =
0; 0 ns; 5 ns; 5 ns; 2 ns; 1 ns; true; // // // = 32; // // = 32; // //
top level transaction selection (byte level or buswidth variants) width of read data in bits width of write data in bits
A number of transactor configurations are available. The naming convention used is nte_AMBA_AXI_ver_rw_ww_aw_iw_tu where ver, rw, ww, aw, iw and tu have the following meanings and valid values: ver version (v2p8) rw/ww read/write width (16, 32, 64, 128, 256 equal values) aw address width (32) iw ID width (4) tu time unit (ps, ns, fs). This does not have to match the time scale of the input FSDB file; however, any signal changes below this time resolution will not be seen by nTE.
The transactor consists of a number of transactions that enable communication at different levels of abstraction. In this section the function, types and attributes of these transactions are described in detail. Referring to the protocol tree can help to visualize transactions that are recognized by the transactor.
Protocol Tree
AXI_read
AXI_read is a bidirectional read transaction between the master and slave, with read data (and length) expressed in bytes. A read_control transaction passes address and control information from the master to the slave. This is followed by a read_data_burst transaction returning the requested data and response status from slave to master. There can be multiple outstanding (concurrent) reads. These can overlap due to pipe-lining and the use of the ID signal. Note that AXI_read is mutually exclusive to AXI_buswidth_read. Attributes:
bit addr[AXI_MAX_ADDRESS_WIDTH] T_AXI_SIZE size T_AXI_BURST burst T_AXI_LOCK lock T_AXI_CACHE cache T_AXI_PROT prot bit id[AXI_MAX_ID_WIDTH] int data_length bit data_bytes[AXI_MAX_RDATA_LENGTH][8] T_AXI_RESPONSE resp[AXI_MAX_BURST_LENGTH] master master master master master master master master slave slave >=> >=> >=> >=> >=> >=> >=> >=> >=> >=> slave, slave, slave, slave, slave, slave, slave, slave, master, master
data_length is the number of bytes in the transaction.
AXI_buswidth_read
AXI_buswidth_read is a bidirectional read transaction between the master and slave, with read data (and length) expressed in words of size equal to the bus width. A read_control transaction passes address and control information from the master to the slave. This is followed by a read_data_burst transaction returning the requested data and response status from slave to master. There can be multiple outstanding (concurrent) reads. These can overlap due to pipe-lining and the use of the ID signal. Note that AXI_buswidth_read is mutually exclusive to AXI_read. Attributes:
nTX Users Guide and Tutorial bit addr[AXI_MAX_ADDRESS_WIDTH] master >=> slave, T_AXI_SIZE size master >=> slave, T_AXI_BURST burst master >=> slave, T_AXI_LOCK lock master >=> slave, T_AXI_CACHE cache master >=> slave, T_AXI_PROT prot master >=> slave, bit id[AXI_MAX_ID_WIDTH] master >=> slave, int ntransfers master >=> slave, bit data_words[AXI_MAX_BURST_LENGTH][AXI_MAX_RDATA_WIDTH] slave >=> master, T_AXI_RESPONSE resp[AXI_MAX_BURST_LENGTH] slave >=> master
ntransfers is the number of words of size equal to the bus width in the transaction.
AXI_write
AXI_write is a bidirectional write transaction between the master and slave, with write data (and length) expressed in bytes. A write_control transaction passes address and control information from the master to the slave. A write_data_burst transaction passes data and strobe information from master to slave. The write_data_burst may precede, be in parallel with or follow the write_control, with the two transactions being linked together by a common id. The AXI_write transaction is finished by a write_response transaction passing status information from the slave to the master. There can be multiple outstanding (concurrent) writes. These can overlap due to pipe-lining and the use of the ID signal. Note that AXI_write is mutually exclusive to AXI_buswidth_write. Attributes:
bit addr[AXI_MAX_ADDRESS_WIDTH] T_AXI_SIZE size T_AXI_BURST burst T_AXI_LOCK lock T_AXI_CACHE cache T_AXI_PROT prot bit id[AXI_MAX_ID_WIDTH] int data_length bit data_bytes[AXI_MAX_WDATA_LENGTH][8] T_AXI_RESPONSE resp master master master master master master master master master slave >=> >=> >=> >=> >=> >=> >=> >=> >=> >=> slave, slave, slave, slave, slave, slave, slave, slave, slave, master
data_length is the number of bytes in the transaction.
AXI_buswidth_write
AXI_buswidth_write is a bidirectional write transaction between the master and slave, with write data (and length) expressed in words of size equal to the bus width. A write_control transaction passes address and control information from the master to the slave. A write_data_burst transaction passes data and strobe
information from master to slave. The write_data_burst may precede, be in parallel with or follow the write_control, with the two transactions being linked together by a common id. The AXI_write transaction is finished by a write_response transaction passing status information from the slave to the master. There can be multiple outstanding (concurrent) writes. These can overlap due to pipelining and the use of the ID signal. Note that AXI_buswidth_write is mutually exclusive to AXI_write. Attributes:
bit addr[AXI_MAX_ADDRESS_WIDTH] master >=> slave, T_AXI_SIZE size master >=> slave, T_AXI_BURST burst master >=> slave, T_AXI_LOCK lock master >=> slave, T_AXI_CACHE cache master >=> slave, T_AXI_PROT prot master >=> slave, bit id[AXI_MAX_ID_WIDTH] master >=> slave, int ntransfers master >=> slave, bit data_words[AXI_MAX_BURST_LENGTH][AXI_MAX_WDATA_WIDTH] master >=> slave, bit write_strobes[AXI_MAX_BURST_LENGTH][AXI_MAX_WSTRB_WIDTH] master >=> slave, T_AXI_RESPONSE resp slave >=> master
ntransfers is the number of words of size equal to the bus width in the transaction.
read_control
read_control is a unidirectional transaction passing address and control information from master to slave as part of a read transaction. It consists of a single read_addr_channel_phase. A read_control transaction may take multiple clock cycles to complete, but only one may be active at any time. Attributes:
bit int T_AXI_SIZE T_AXI_BURST T_AXI_LOCK T_AXI_CACHE T_AXI_PROT bit addr[AXI_MAX_ADDRESS_WIDTH], ntransfers, size, burst, lock, cache, prot, id[AXI_MAX_ID_WIDTH]
ntransfers is the number of words (of size equal to the bus width) to be transferred.
read_data_burst
read_data_burst is a unidirectional transaction passing data and status information from slave to master as part of a read transaction. It consists of one or more read_channel_phase transactions. There can be multiple outstanding (concurrent) read data bursts. These can overlap due to pipelining and the use of the ID signal. Attributes:
int ntransfers, bit data_words[AXI_MAX_BURST_LENGTH][AXI_MAX_RDATA_WIDTH], T_AXI_RESPONSE resp[AXI_MAX_BURST_LENGTH], bit id[AXI_MAX_ID_WIDTH]
ntransfers is the number of words (of size equal to the bus width) being transferred.
write_control
write_control is a unidirectional transaction passing address and control information from master to slave as part of a write transaction. It consists of a single write_addr_channel_phase. A write_control transaction may take multiple clock cycles to complete, but only one may be active at any time. Attributes:
bit int T_AXI_SIZE T_AXI_BURST T_AXI_LOCK T_AXI_CACHE T_AXI_PROT bit addr[AXI_MAX_ADDRESS_WIDTH], ntransfers, size, burst, lock, cache, prot, id[AXI_MAX_ID_WIDTH]
ntransfers is the number of words (of size equal to the bus width) to be transferred.
write_data_burst
write_data_burst is a unidirectional transaction passing data and strobe information from master to slave as part of a write transaction. It consists of one or more write_channel_phase transactions. There can be multiple outstanding (concurrent) write data bursts. These can overlap due to pipelining and the use of the ID signal. Attributes:
int ntransfers,
Appendix D: AMBA AXI Transactor bit data_words[AXI_MAX_BURST_LENGTH][AXI_MAX_WDATA_WIDTH], bit strb[AXI_MAX_BURST_LENGTH][AXI_MAX_WSTRB_WIDTH], bit id[AXI_MAX_ID_WIDTH]
ntransfers is the number of words (of size equal to the bus width) being transferred.
write_response
write_response is a unidirectional transaction passing status information from slave to master as part of a write transaction. It consists of a single write_resp_channel_phase. A write_response transaction may take multiple clock cycles to complete, but only one may be active at any time. Attributes:
T_AXI_RESPONSE bit resp, id[AXI_MAX_ID_WIDTH]
read_addr_channel_phase
read_addr_channel_phase is a unidirectional transaction passing address and control information from master to slave as part of a read transaction. It consists of one or more read_addr_channel_cycle transactions. A read_addr_channel_phase transaction may take multiple clock cycles to complete, determined by the ARREADY signal, but only one may be active at any time. Attributes:
bit bit T_AXI_SIZE T_AXI_BURST T_AXI_LOCK T_AXI_CACHE T_AXI_PROT bit addr[AXI_MAX_ADDRESS_WIDTH], length[4], size, burst, lock, cache, prot, id[AXI_MAX_ID_WIDTH]
The number of transfers is defined as length+1
read_channel_phase
read_channel_phase is a unidirectional transaction passing a single word of data and status information from slave to master as part of a read transaction. It consists of one or more read_channel_cycle transactions. A read_channel_phase transaction may take multiple clock cycles to complete, determined by the RREADY signal, but only one may be active at any time.
Attributes:
T_AXI_LAST bit T_AXI_RESPONSE bit last, data[AXI_MAX_RDATA_WIDTH], resp, id[AXI_MAX_ID_WIDTH]
write_addr_channel_phase
write_addr_channel_phase is a unidirectional transaction passing address and control information from master to slave as part of a write transaction. It consists of one or more write_addr_channel_cycle transactions. A write_addr_channel_phase transaction may take multiple clock cycles to complete, determined by the AWREADY signal, but only one may be active at any time. Attributes:
bit bit T_AXI_SIZE T_AXI_BURST T_AXI_LOCK T_AXI_CACHE T_AXI_PROT bit addr[AXI_MAX_ADDRESS_WIDTH], length[4], size, burst, lock, cache, prot, id[AXI_MAX_ID_WIDTH]
The number of transfers is defined as length+1.
write_channel_phase
write_channel_phase is a unidirectional transaction passing a single word of data and strobe information from master to slave as part of a write transaction. It consists of one or more write_channel_cycle transactions. A write_channel_phase transaction may take multiple clock cycles to complete, determined by the WREADY signal, but only one may be active at any time. Attributes:
T_AXI_LAST bit bit bit last, data[AXI_MAX_WDATA_WIDTH], strb[AXI_MAX_WSTRB_WIDTH], id[AXI_MAX_ID_WIDTH]
write_resp_channel_phase
write_resp_channel_phase is a unidirectional transaction passing a status information from slave to master as part of a write transaction. It consists of one or more write_resp_channel_cycle transactions. A write_resp_channel_phase
transaction may take multiple clock cycles to complete, determined by the BREADY signal, but only one may be active at any time. Attributes:
T_AXI_RESPONSE bit resp, id[AXI_MAX_ID_WIDTH]
read_addr_channel_cycle
read_addr_channel_cycle is a unidirectional transaction lasting a single clock cycle on the bus, with only one active at a time. Each read_addr_channel_cycle groups the set of read address channel signals and synchronizes them to a clock. One or more read_addr_channel_cycles make up a read_addr_channel_phase, the number of which is determined by ARREADY. Attributes:
T_AXI_VALID bit bit T_AXI_SIZE T_AXI_BURST T_AXI_LOCK T_AXI_CACHE T_AXI_PROT bit valid, addr[AXI_MAX_ADDRESS_WIDTH], length[4], size, burst, lock, cache, prot, id[AXI_MAX_ID_WIDTH]
read_channel_cycle
read_channel_cycle is a unidirectional transaction lasting a single clock cycle on the bus, with only one active at a time. Each read_channel_cycle groups the set of read channel signals (for data/response) and synchronizes them to a clock. One or more read_channel_cycles make up a read_channel_phase, the number of which is determined by RREADY. Attributes:
T_AXI_VALID T_AXI_LAST bit T_AXI_RESPONSE bit valid, last, data[AXI_MAX_RDATA_WIDTH], resp, id[AXI_MAX_ID_WIDTH]
write_addr_channel_cycle
write_addr_channel_cycle is a unidirectional transaction lasting a single clock cycle on the bus, with only one active at a time. Each write_addr_channel_cycle groups the set of write address channel signals and synchronizes them to a clock.
One or more write_addr_channel_cycles make up a write_addr_channel_phase, the number of which is determined by AWREADY. Attributes:
T_AXI_VALID bit bit T_AXI_SIZE T_AXI_BURST T_AXI_LOCK T_AXI_CACHE T_AXI_PROT bit valid, addr[AXI_MAX_ADDRESS_WIDTH], length[4], size, burst, lock, cache, prot, id[AXI_MAX_ID_WIDTH]
write_channel_cycle
write_channel_cycle is a unidirectional transaction lasting a single clock cycle on the bus, with only one active at a time. Each write_channel_cycle groups the set of write channel signals (for data/strobe) and synchronizes them to a clock. One or more write_channel_cycles make up a write_channel_phase, the number of which is determined by WREADY. Attributes:
T_AXI_VALID T_AXI_LAST bit bit bit valid, last, data[AXI_MAX_WDATA_WIDTH], strb[AXI_MAX_WSTRB_WIDTH], id[AXI_MAX_ID_WIDTH]
write_resp_channel_cycle
write_resp_channel_cycle is a unidirectional transaction lasting a single clock cycle on the bus, with only one active at a time. Each write_resp_channel_cycle groups the set of write response channel signals and synchronizes them to a clock. One or more write_resp_channel_cycles make up a write_resp_channel_phase, the number of which is determined by BREADY. Attributes:
T_AXI_VALID T_AXI_RESPONSE bit valid, resp, id[AXI_MAX_ID_WIDTH]
read_addr_channel_ready
This item lasts a single clock cycle on the bus, and only one can be active at a time. This item synchronizes the ARREADY signal to the clock. Attributes:
Appendix D: AMBA AXI Transactor T_AXI_READY ready
read_channel_ready
This item lasts a single clock cycle on the bus, and only one can be active at a time. This item synchronizes the RREADY signal to the clock. Attributes:
T_AXI_READY ready
write_addr_channel_ready
This item lasts a single clock cycle on the bus, and only one can be active at a time. This item synchronizes the AWREADY signal to the clock. Attributes:
T_AXI_READY ready
write_channel_ready
This item lasts a single clock cycle on the bus, and only one can be active at a time. This item synchronizes the WREADY signal to the clock. Attributes:
T_AXI_READY ready
write_resp_channel_ready
This item lasts a single clock cycle on the bus, and only one can be active at a time. This item synchronizes the BREADY signal to the clock. Attributes:
T_AXI_READY ready
Wires
Name ACLK ARESETn ARVALID ARADDR Type bit bit bit Direction clock_source to master, slave and reset_source reset_source to master and slave master to slave
bit array, size AXI_ADDRESS_WIDTH master to slave
Name ARLEN ARSIZE ARBURST ARLOCK ARCACHE ARPROT ARID ARREADY AWVALID AWADDR AWLEN AWSIZE AWBURST AWLOCK AWPROT AWID RVALID RLAST RDATA RRESP RID RREADY WVALID WLAST WDATA WSTRB WID WREADY BVALID BRESP
Type bit array, size 4 bit array, size 3 bit array, size 2 bit array, size 2 bit array, size 4 bit array, size 3 bit array, size AXI_ID_WIDTH bit bit bit array, size 4 bit array, size 3 bit array, size 2 bit array, size 2 bit array, size 3 bit array, size AXI_ID_WIDTH bit bit bit array, size AXI_RDATA_WIDTH bit array, size 2 bit array, size AXI_ID_WIDTH bit bit bit bit array, size AXI_WDATA_WIDTH bit array, size AXI_WSTRB_WIDTH bit array, size AXI_ID_WIDTH bit bit bit array, size 2
Direction master to slave master to slave master to slave master to slave master to slave master to slave master to slave slave to master master to slave master to slave master to slave master to slave master to slave master to slave master to slave master to slave slave to master slave to master slave to master slave to master slave to master slave to master master to slave master to slave master to slave master to slave master to slave master to slave slave to master slave to master slave to master
bit array, size AXI_ADDRESS_WIDTH master to slave
AWCACHE bit array, size 4
AWREADY bit
Name BID BREADY
Type bit array, size AXI_ID_WIDTH bit
Direction slave to master master to slave
Additional Communication Items

Additional items read_addr_channel_cycle_invalid, read_channel_cycle_invalid, write_addr_channel_cycle_invalid, write_channel_cycle_invalid and write_resp_channel_cycle_invalid are also available. These are identical to the read_addr_channel_cycle, read_channel_cycle, write_addr_channel_cycle, write_channel_cycle and write_resp_channel_cycle, with the exception that they represent cycles where the valid signal is low.
Data Types
In addition to the standard transactor types, such as int, and bit, the AXI transactor makes use of the following types:
// Validity of a channels signals type enum T_AXI_VALID:1 { INVALID = 0, VALID = 1 }; // Last phase in burst transfer type enum T_AXI_LAST:1 { MORE_TO_COME = 0, LAST = 1 }; // Word size encoding type enum T_AXI_SIZE:3 { BYTES_1 = 0, BYTES_2 = 1, BYTES_4 = 2,
nTX Users Guide and Tutorial BYTES_8 = 3, BYTES_16 = 4, BYTES_32 = 5, BYTES_64 = 6, BYTES_128 = 7 }; // Protection type type enum T_AXI_PROT:3 { NORM_SEC_DATA = 0, PRIV_SEC_DATA = 1, NORM_NONSEC_DATA = PRIV_NONSEC_DATA = NORM_SEC_INST = 4, PRIV_SEC_INST = 5, NORM_NONSEC_INST = PRIV_NONSEC_INST = };
2, 3,
6, 7
// Cache type type enum T_AXI_CACHE:4 { NONCACHE_NONBUF = 0, BUF_ONLY = 1, CACHE_NOALLOC = 2, CACHE_BUF_NOALLOC = 3, RESERVED_0100 = 4, RESERVED_0101 = 5, CACHE_WTHROUGH_ALLOC_R_ONLY = 6, CACHE_WBACK_ALLOC_R_ONLY = 7, RESERVED_1000 = 8, RESERVED_1001 = 9, CACHE_WTHROUGH_ALLOC_W_ONLY = 10, CACHE_WBACK_ALLOC_W_ONLY = 11, RESERVED_1100 = 12, RESERVED_1101 = 13, CACHE_WTHROUGH_ALLOC_RW = 14, CACHE_WBACK_ALLOC_RW = 15 }; // Burst type - determines address calculation type enum T_AXI_BURST:2 { FIXED = 0, INCR = 1, WRAP = 2, RESERVED = 3 };
// Response type type enum T_AXI_RESPONSE:2 { OKAY = 0, EXOKAY = 1, SLVERR = 2, DECERR = 3 }; // Lock type for atomic accesses type enum T_AXI_LOCK:2 { NORMAL = 0, EXCLUSIVE = 1, LOCKED = 2, RESERVED = 3 }; // Ready signal values type enum T_AXI_READY:1 { WAIT = 0, READY = 1 };
AXI_MAX_ADDRESS_WIDTH the maximum width of the address bus (read and write) AXI_MAX_ID_WIDTH the maximum width of the id bus (read and write) AXI_MAX_RDATA_WIDTH the maximum width of the read data bus AXI_MAX_WDATA_WIDTH the maximum width of the write data bus AXI_MAX_WSTRB_WIDTH the maximum width of the write strobe bus AXI_MAX_RDATA_LENGTH the maximum number of bytes in an AXI_read transfer AXI_MAX_WDATA_LENGTH the maximum number of bytes in an AXI_write transfer AXI_MAX_BURST_LENGTH the maximum number of words in a burst

Overview
The MPEG_TS Transactor supports the following features: ISO/IEC 13818-1:2000 Audio/Video qualifier. Optional Adaptation Field. Byte-wide data bus.
BCF Format
Name
The bus declaration (nte_MPEG_TS_v1p0_ns) must be one of the supported transactors.
nte_MPEG2_TS_v1p0_ns MyMPEG2_TS_1 {
Mapping Root
MAPPING_ROOT = "/MPEG_TS_top_level/MPEG_structure/the_transport_stream";
Signal Map
NOTE: Clock can be mapped to /MPEG2_TS/MPEG2_TS_clock. The
SIGMAP code example is for an unmapped clock.
SIGMAP { /MPEG2_TS/MPEG2_TS_sync = /MPEG2_TS/MPEG2_TS_audio_video /MPEG2_TS/MPEG2_TS_valid = /MPEG2_TS/MPEG2_TS_data = }
"/MPEG2_TS_sync"; = "/MPEG2_TS_audio_video"; "/MPEG2_TS_valid"; "/MPEG2_TS_data";
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file. Configuration of the transactor is made via the PARAMETER section of the bcf file. The available parameters are: clk_init_value: The initial value of the clock (0 or 1). sync_byte: Defaults to 0x47. clk_phase_shift: The time of the first transition from the initial value. clk_1st_time: The relative time of the first clock change after the initial phase shift change. clk_2nd_time: The relative time of second clock change after the previous change. setup_time: The setup time for all MPEG2 TS signals. hold_time: The hold time for all MPEG2 TS signals. The clock set up is important to the correct operation of the transactor. An example is shown below:
Figure: Clock Setup
Appendix E: MPEG2_TS Transactor // parameters PARAMETER { clk_init_value sync_byte clk_phase_shift clk_1st_time clk_2nd_time setup_time hold_time }
= = = = = = =
0b0; 0x47; 50 ns; 50 ns; 50 ns; 1 ns; 1 ns;
A number of transactor configurations are available. The naming convention used is nte_MPEG2_TS_ver_tu, where ver and tu have the following meanings and valid values: ver version (v1p0) tu time unit (ps, ns, fs). This does not have to match the time scale of the input FSDB file; however, any signal changes below this time resolution will not be seen by nTE.
The transactor consists of a number of transactions that enable communication at different levels of abstraction. In this section the function, types and attributes of these transactions are described in detail. The MPEG2_TS Transactor recognizes transactions from the transport stream active signals. The protocol tree shows how the transactions are inter-related. At the highest level is a transaction (stream_packet_phase) representing a complete MPEG2 packet. This transaction is then made up of phases, e.g. sync_phase, header_phase, adaptation_header_phase, optional_fields_phase and payload_phase. Referring to the protocol tree can help to visualize transactions that are recognized by the transactor.
Protocol Tree
stream_packet_phase
stream_packet_phase is a uni-directional transaction used for complete transport packet transfers. Attributes:
T_MPEG_TS_transport_packet_header transport_packet_header, T_MPEG_TS_transport_adaptation_header transport_adaptation_header, byte transport_optional_fields[], byte transport_packet_payload[]
sync_phase
sync_phase is a uni-directional transaction used to indicate the start of a packet and to transfer the sync byte 0x47. Attributes: none.
header_phase
header_phase is a uni-directional transaction used to transfer the 4-byte header. Attributes:
bit bit bit bit bit bit bit bit ts_error_indicator, ts_start_indicator, ts_priority, ts_identifier[13], ts_scrambling[2], ts_adaptation_field, ts_payload_flag, ts_continuity[4]
adaptation_header_phase
adaptation_header_phase is a uni-directional transaction used to transfer the adaptation field. Attributes:
bit bit ts_adaptation_header_length[8], ts_adaptation_header_flags[8],
optional_fields_phase
optional_fields_phase is a uni-directional transaction used a to transfer optional fields. Attributes:
byte data[]
payload_phase
payload_phase is a uni-directional transaction used to transfer the packet payload. Attributes:
byte data[]
stream_av_phase
stream_av_phase is a uni-directional transaction used to transfer the phase. Attributes:
bit av MUX_S >=> master
stream_valid_byte
stream_valid_byte is a uni-directional transaction used to transfer a valid byte. Attributes:
bit bit sync, data[8]
stream_packet_stripe
stream_packet_stripe is a uni-directional transaction used to transfer a packet. Attributes:
bit bit bit sync, valid, data[8]
stream_packet_av_stripe
stream_packet_av_stripe is a uni-directional transaction used to indicate an audio or video packet. Attributes:
bit av
Wires
For a description of each of these wires (signals), see the section on Signal Descriptions in the MPEG2_TS Protocol Specification.
Name MPEG_TS_clock MPEG_TS_sync MPEG_TS_audio_video MPEG_TS_valid MPEG_TS_data[8] Type bit bit bit bit bit array, size 8 Direction source >=> destination source >=> destination source >=> destination source >=> destination source >=> destination
Data Types
In addition to the standard transactor types, such as int, and bit, the MPEG2 TS transactor makes use of the following types:
type struct T_MPEG_TS_transport_packet_header { bit transport_error_indicator; //EI indicates error //from previous stages bit payload_unit_start_indicator; //PUSI start of PES //in the packet transport_priority; packet_identifier[13]; //Priority indicator //Identifies the content //of the packet //Transport //scrambling type
bit bit
bit
transport_scrambling_flags[2];
bit
adaptation_field_flag;
//Presence of adaptation //field in packet //Presence of payload //data in the packet //Between truncated PES //portions
bit
payload_flag;
bit };
continuity_counter[4];
type struct T_MPEG_TS_transport_adaptation_header { bit adaptation_field_length[8]; bit adaptation_flags[8]; };

Overview
The OCP-IP Transactor supports the following features: OCP-IP Release 2.0 (see Limitations below) Configurable bus widths (address, data, thread ID, etc.) Recognition of complete bursts as a single transaction Out-of-order transaction completion
Limitations
Over 90% of the OCP-IP 2.0 specification is covered by the OCP transactor. However the following limitations exist with the current version: OCP ordering model currently unsupported for transactions on same thread. BurstPrecise = 0 not supported. Incomplete support for sideband/test signals
BCF Format
Name
The bus declaration (nte_OCP_IP_v1p0_32_32_16_8_ns) must be one of the supported transactors.
nte_OCP_IP_v1p0_32_32_16_8_ns myOCP {
Mapping Root
MAPPING_ROOT = "/default_config_recognition/str/iOCP";
Signal Map
NOTE: Clock can be mapped to /OCP/Clk. The SIGMAP code example is for
an unmapped clock.
SIGMAP { // basic OCP signals /OCP/MAddr /OCP/MCmd /OCP/MData /OCP/MDataValid /OCP/MRespAccept /OCP/SCmdAccept /OCP/SData /OCP/SDataAccept /OCP/SResp
= = = = = = = = =
"/MAddr"; "/MCmd"; "/MData"; "/MDataValid"; "/MRespAccept"; "/SCmdAccept"; "/SData"; "/SDataAccept"; "/SResp";
// simple OCP extensions /OCP/MAddrSpace = /OCP/MByteEn = /OCP/MDataByteEn = /OCP/MDataInfo = /OCP/MReqInfo = /OCP/SDataInfo = /OCP/SRespInfo = // OCP burst extensions /OCP/MAtomicLength /OCP/MBurstLength /OCP/MBurstPrecise /OCP/MBurstSeq /OCP/MBurstSingleReq /OCP/MDataLast /OCP/MReqLast
"/MAddrSpace"; "/MByteEn"; "/MDataByteEn"; "/MDataInfo"; "/MReqInfo"; "/SDataInfo"; "/SRespInfo";
= = = = = = =
"/MAtomicLength"; "/MBurstLength"; "/MBurstPrecise"; "/MBurstSeq"; "/MBurstSingleReq"; "/MDataLast"; "/MReqLast";
Appendix F: OCP-IP Transactor /OCP/SRespLast = "/SRespLast";
// OCP thread extensions /OCP/MConnID = /OCP/MDataThreadID = /OCP/MThreadBusy = /OCP/MThreadID = /OCP/SDataThreadBusy = /OCP/SThreadBusy = /OCP/SThreadID =
"/MConnID"; "/MDataThreadID"; "/MThreadBusy"; "/MThreadID"; "/SDataThreadBusy"; "/SThreadBusy"; "/SThreadID";
// sideband OCP signals /OCP/MError = "/MError"; /OCP/MFlag = "/MFlag"; /OCP/MReset_n = "/MReset_n"; /OCP/SError = "/SError"; /OCP/SFlag = "/SFlag"; /OCP/SInterrupt = "/SInterrupt"; /OCP/SReset_n = "/SReset_n"; /OCP/Control /OCP/ControlBusy /OCP/ControlWr /OCP/Status /OCP/StatusBusy /OCP/StatusRd // test OCP signals /OCP/Scanctrl /OCP/Scanin /OCP/Scanout /OCP/ClkByp /OCP/TestClk /OCP/TCK /OCP/TDI /OCP/TDO /OCP/TMS /OCP/TRST_N } = = = = = = "/Control"; "/ControlBusy"; "/ControlWr"; "/Status"; "/StatusBusy"; "/StatusRd";
= = = = = = = = = =
"/Scanctrl"; "/Scanin"; "/Scanout"; "/ClkByp"; "/TestClk"; "/TCK"; "/TDI"; "/TDO"; "/TMS"; "/TRST_N";
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file. Configuration of the transactor is made via the PARAMETER section of the bcf file. This is where the OCP configuration and the default values of the OCP wires must be set. These can be seen in the example below using values as allowed by the OCP specification. The available parameters are:
clk_init_value: The initial value of the clock (0 or 1). clk_phase_shift: The time of the first transition from the initial value. clk_1st_time: The relative time of the first clock change after the initial phase shift change. clk_2nd_time: The relative time of second clock change after the previous change. setup_time: The setup time for all OCP signals hold_time: The hold time for all OCP signals The clock set up is important to the correct operation of the transactor. An example is shown below:
Figure: Clock Setup

// parameters PARAMETER { //Protocol broadcast_enable burst_aligned burstseq_dflt1_enable burstseq_dflt2_enable burstseq_incr_enable burstseq_strm_enable burstseq_unkn_enable burstseq_wrap_enable burstseq_xor_enable endian force_aligned mthreadbusy_exact rdlwrc_enable read_enable readex_enable sdatathreadbusy_exact sthreadbusy_exact write_enable writenonpost_enable //Phase datahandshake reqdata_together writeresp_enable //Signal (Dataflow) addr addr_wdth addrspace
= = = = = = = = = = = = = = = = = = =
0; 0; 0; 0; 1; 0; 0; 0; 0; LITTLE; 0; 0; 0; 1; 0; 0; 0; 1; 0;
= 0; = 0; = 0; = 1; = 32; = 0;
Appendix F: OCP-IP Transactor addrspace_wdth atomiclength atomiclength_wdth burstlength burstlength_wdth burstprecise burstseq burstsinglereq byteen cmdaccept connid connid_wdth dataaccept datalast data_wdth mdata mdatabyteen mdatainfo mdatainfo_wdth mdatainfobyte_wdth mthreadbusy reqinfo reqinfo_wdth reqlast resp respaccept respinfo respinfo_wdth resplast sdata sdatainfo sdatainfo_wdth sdatainfobyte_wdth sdatathreadbusy sthreadbusy threads //Signal (Sideband) control controlbusy control_wdth controlwr interrupt merror mflag mflag_wdth mreset serror sflag sflag_wdth sreset status statusbusy statusrd status_wdth //Signal (Test) clkctrl_enable jtag_enable jtagtrst_enable = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 2; 0; 2; 0; 4; 0; 0; 0; 0; 1; 0; 2; 0; 0; 32; 1; 0; 0; 8; 1; 0; 0; 2; 0; 1; 0; 0; 2; 0; 1; 0; 8; 1; 0; 0; 1; 0; 0; 2; 0; 0; 0; 0; 2; 0; 0; 0; 2; 0; 0; 0; 0; 2;
= 0; = 0; = 0;
nTX Users Guide and Tutorial scanctrl_wdth scanport scanport_wdth // basic OCP signals default_Clk default_MAddr default_MCmd default_Mdata default_MdataValid default_MrespAccept default_ScmdAccept default_Sdata default_SdataAccept default_Sresp = 2; = 0; = 2;
= = = = = = = = = =
0; 0; 0; 0; 0; 1; 1; 0; 1; 0; 0; 0xF; 0xF; 0; 0; 0; 0; 1; 1; 1; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 1; 0; 0; 0; 1; 0; 0; 0; 0; 0; 0;
// simple OCP extensions default_MaddrSpace = default_MbyteEn = default_MdataByteEn = default_MdataInfo = default_MreqInfo = default_SdataInfo = default_SrespInfo = // OCP burst extensions default_MatomicLength default_MburstLength default_MburstPrecise default_MburstSeq default_MburstSingleReq default_MdataLast default_MreqLast default_SrespLast = = = = = = = =
// OCP thread extensions default_MconnID = default_MdataThreadID = default_MthreadBusy = default_MthreadID = default_SdataThreadBusy = default_SthreadBusy = default_SthreadID = // sideband OCP signals default_Merror default_Mflag default_MReset_n default_Serror default_Sflag default_Sinterrupt default_SReset_n default_Control default_ControlBusy default_ControlWr default_Status default_StatusBusy default_StatusRd = = = = = = = = = = = = =
Appendix F: OCP-IP Transactor // test OCP signals default_Scanctrl default_Scanin default_Scanout default_ClkByp default_TestClk default_TCK default_TDI default_TDO default_TMS default_TRST_N // clock frequency clk_init_value clk_phase_shift clk_1st_time clk_2nd_time setup_time hold_time
= = = = = = = = = = = = = = = =
0; 0; 0; 0; 0; 0; 0; 0; 0; 1; 0; 0 ns; 5 ns; 5 ns; 1 ns; 1 ns;
A number of transactor configurations are available. The naming convention used is nte_OCP_IP_ver_aw_dw_threads_blw_tu where ver, aw, dw, threads, blw and tu have the following meanings and valid values: ver version (v1p0) aw address width (32) dw data width (16, 32, 64, 128, 256) threads number of threads (16) blw burst length width (8) tu time unit (ps, ns, fs). This does not have to match the time scale of the input FSDB file; however, any signal changes below this time resolution will not be seen by nTE. When the required configuration is not available, an transactor with bus widths greater than those required should be used. These and other run-time parameters must be configured using the PARAMETER section of the bcf file.
Protocol Tree
Readburst
Readburst is a bidirectional read transaction between the master and slave. One or more Mrequest_phase transactions pass address and control information from the master to the slave. One or more Sresponse_phase transactions return the requested data and response status from slave to master. There can be multiple outstanding (concurrent) reads. These can overlap due to pipe-lining and the use of the ThreadID signal. Attributes:
MCmd_encoding Rcmd master >=> slave bit Addr[(1<<OCP_burstlength_wdth)-1][OCP_addr_wdth] master >=> slave bit AddrSpace[OCP_addrspace_wdth] master >=> slave bit ReqInfo[OCP_reqinfo_wdth] master >=> slave bit BurstLength[OCP_burstlength_wdth] master >=> slave bit BurstPrecise master >=> slave MBurstSeq_encoding BurstSeq master >=> slave bit BurstSingleReq master >=> slave bit AtomicLength[OCP_atomiclength_wdth] master >=> slave bit ConnID[OCP_connid_wdth] master >=> slave bit ThreadID[OCP_log2_threads] master >=> slave bit ByteEnable[(1<<OCP_burstlength_wdth)-1][OCP_data_wdth/8] master >=> slave bit Data[(1<<OCP_burstlength_wdth)-1][OCP_data_wdth] slave >=> master bit DataInfo[(1<<OCP_burstlength_wdth)-1][OCP_sdatainfo_wdth] slave >=> master SResp_encoding Resp[(1<<OCP_burstlength_wdth)-1] slave >=> master bit RespInfo[OCP_respinfo_wdth] slave >=> master
Writeburst
Writeburst is a (possibly) bidrectional write transaction between the master and slave, with write data (and length) expressed in words of size equal to the bus width. If datahandshake is enabled then a Writeburst is made up of one or more
Mrequest_phase transactions, one or more MwriteData_phase transactions and, if writeresp_enable is set, one or more Sresponse_phase transactions. If datahandshake is not enabled then a Writeburst is made up of one or more MrequestData_phase transactions and, if writeresp_enable is set, one or more Sresponse_phase transactions. There can be multiple outstanding (concurrent) writes. These can overlap due to pipe-lining and the use of the ThreadID signal. Attributes:
MCmd_encoding Wcmd master >=> slave bit Addr[(1<<OCP_burstlength_wdth)-1][OCP_addr_wdth] master >=> slave bit AddrSpace[OCP_addrspace_wdth] master >=> slave bit ReqInfo[OCP_reqinfo_wdth] master >=> slave bit BurstLength[OCP_burstlength_wdth] master >=> slave bit BurstPrecise master >=> slave MBurstSeq_encoding BurstSeq master >=> slave bit BurstSingleReq master >=> slave bit AtomicLength[OCP_atomiclength_wdth] master >=> slave bit ConnID[OCP_connid_wdth] master >=> slave bit ThreadID[OCP_log2_threads] master >=> slave bit ByteEnable[(1<<OCP_burstlength_wdth)-1][OCP_data_wdth/8] master >=> slave bit Data[(1<<OCP_burstlength_wdth)-1][OCP_data_wdth] master >=> slave bit DataInfo[(1<<OCP_burstlength_wdth)-1][OCP_sdatainfo_wdth] master >=> slave SResp_encoding Resp[(1<<OCP_burstlength_wdth)-1] slave >=> master bit RespInfo[OCP_respinfo_wdth] slave >=> master
Mrequest_phase
Mrequest_phase is a unidirectional transaction passing address and control information from master to slave as part of a Readburst or Writeburst transaction. It consists of one or more Mrequest transactions. A Mrequest_phase transaction may take multiple clock cycles to complete, but only one may be active at any time. Attributes:
MCmd_encoding bit bit bit bit bit MBurstSeq_encoding bit Cmd, Addr[OCP_addr_wdth], AddrSpace[OCP_addrspace_wdth], ReqInfo[OCP_reqinfo_wdth], BurstLength[OCP_burstlength_wdth], BurstPrecise, BurstSeq, BurstSingleReq,
nTX Users Guide and Tutorial bit bit bit bit bit AtomicLength[OCP_atomiclength_wdth], ConnID[OCP_connid_wdth], ThreadID[OCP_log2_threads], ByteEnable[OCP_data_wdth/8], ReqLast
MrequestData_phase
MrequestData_phase is a unidirectional transaction passing control and data information from master to slave as part of a Writeburst transaction. It consists of one or more MrequestData transactions. A MrequestData_phase transaction may take multiple clock cycles to complete, but only one may be active at any time. Attributes:
MCmd_encoding bit bit bit bit bit MBurstSeq_encoding bit bit bit bit bit bit bit bit Cmd, Addr[OCP_addr_wdth], AddrSpace[OCP_addrspace_wdth], ReqInfo[OCP_reqinfo_wdth], BurstLength[OCP_burstlength_wdth], BurstPrecise, BurstSeq, BurstSingleReq, AtomicLength[OCP_atomiclength_wdth], ConnID[OCP_connid_wdth], ThreadID[OCP_log2_threads], ByteEnable[OCP_data_wdth/8], ReqLast, Data[OCP_data_wdth], DataInfo[OCP_sdatainfo_wdth]
MwriteData_phase
MwriteData_phase is a unidirectional transaction passing data from master to slave as part of a Writeburst transaction. It consists of one or more MwriteData transactions. A MwriteData_phase transaction may take multiple clock cycles to complete, but only one may be active at any time. Attributes:
bit bit bit bit bit ThreadID[OCP_log2_threads], Data[OCP_data_wdth], DataByteEn[OCP_data_wdth/8], DataInfo[OCP_mdatainfo_wdth], DataLast
Sresponse_phase
Sresponse_phase is a unidirectional transaction passing read data and read/write status information from slave to master as part of a Readburst or Writeburst transaction. It consists of one or more Sresponse transactions. A Sresponse_phase transaction may take multiple clock cycles to complete, but only one may be active at any time. Attributes:
bit bit bit SResp_encoding bit bit ThreadID[OCP_log2_threads], Data[OCP_data_wdth], DataInfo[OCP_sdatainfo_wdth], Resp, RespInfo[OCP_respinfo_wdth], RespLast
Mrequest
Mrequest is a unidirectional transaction passing address and control information from master to slave as part of a Mrequest_phase transaction. It takes a single clock cycle to complete and only one may be active at any time. Attributes:
MCmd_encoding bit bit bit bit bit MBurstSeq_encoding bit bit bit bit bit bit Cmd, Addr[OCP_addr_wdth], AddrSpace[OCP_addrspace_wdth], ReqInfo[OCP_reqinfo_wdth], BurstLength[OCP_burstlength_wdth], BurstPrecise, BurstSeq, BurstSingleReq, AtomicLength[OCP_atomiclength_wdth], ConnID[OCP_connid_wdth], ThreadID[OCP_log2_threads], ByteEnable[OCP_data_wdth/8], ReqLast
MrequestData
MrequestData is a unidirectional transaction passing address and control and write data information from master to slave as part of a MrequestData_phase transaction. It takes a single clock cycle to complete and only one may be active at any time. Attributes:
MCmd_encoding bit bit Cmd, Addr[OCP_addr_wdth], AddrSpace[OCP_addrspace_wdth],
nTX Users Guide and Tutorial bit bit bit MBurstSeq_encoding bit bit bit bit bit bit bit bit ReqInfo[OCP_reqinfo_wdth], BurstLength[OCP_burstlength_wdth], BurstPrecise, BurstSeq, BurstSingleReq, AtomicLength[OCP_atomiclength_wdth], ConnID[OCP_connid_wdth], ThreadID[OCP_log2_threads], ByteEnable[OCP_data_wdth/8], ReqLast, Data[OCP_data_wdth], DataInfo[OCP_sdatainfo_wdth]
MwriteData
MwriteData is a unidirectional transaction passing write data information from master to slave as part of a MwriteData_phase transaction. It takes a single clock cycle to complete and only one may be active at any time. Attributes:
bit bit bit bit bit ThreadID[OCP_log2_threads], Data[OCP_data_wdth], DataByteEn[OCP_data_wdth/8], DataInfo[OCP_mdatainfo_wdth], DataLast
Sresponse
Sresponse is a unidirectional transaction passing address and control and write data information from master to slave as part of a Sresponse_phase transaction. It takes a single clock cycle to complete and only one may be active at any time. Attributes:
bit bit bit SResp_encoding bit bit ThreadID[OCP_log2_threads], Data[OCP_data_wdth], DataInfo[OCP_sdatainfo_wdth], Resp, RespInfo[OCP_respinfo_wdth], RespLast
Wires
For a description of each of these wires (signals), see the section on Signal Descriptions in the OCP-IP Protocol Specification.
Name Clk Type bit Direction clock_source to master and slave
Name MAddr MCmd MData MDataValid MRespAccept SCmdAccept SData SDataAccept SResp MAddrSpace MByteEn MDataByteEn MDataInfo MReqInfo SDataInfo SRespInfo MAtomicLength MBurstLength MBurstPrecise MBurstSeq MBurstSingleReq MDataLast MReqLast SRespLast MConnID MDataThreadID MThreadBusy MThreadID SDataThreadBusy SThreadBusy SThreadID MError
Type bit array, size OCP_addr_wdth bit array, size 3 bit array, size OCP_addr_wdth bit bit bit bit array, size 2 bit bit array, size 2 bit array, size OCP_addrspace_wdth bit array, size OCP_data_wdth/8 bit array, size OCP_data_wdth/8 bit array, size OCP_datainfo_wdth bit array, size OCP_reqinfo_wdth bit array, size OCP_sdatainfo_wdth bit array, size OCP_respinfo_wdth bit array, size OCP_atomiclength_wdth bit bit array, size 3 bit bit bit bit bit array, size OCP_connid_wdth bit array, size OCP_log2_threads bit array, size OCP_threads bit array, size OCP_log2_threads bit array, size OCP_threads bit array, size OCP_threads bit array, size OCP_log2_threads bit
Direction master to slave master to slave master to slave master to slave master to slave slave to master slave to master slave to master slave to master master to slave master to slave master to slave master to slave master to slave slave to master slave to master master to slave
bit array, size OCP_burstlength_wdth master to slave master to slave master to slave master to slave master to slave master to slave slave to master master to slave master to slave master to slave master to slave slave to master slave to master slave to master master to slave
Name MFlag MReset_n SError SFlag SInterrupt SReset_n Control ControlBusy ControlWr Status StatusBusy StatusRd Scanctrl Scanin Scanout ClkByp TestClk TCK TDI TDO TMS TRST_N
Type bit array, size OCP_mflag_wdth bit bit bit array, size OCP_sflag_wdth bit bit bit array, size OCP_control_wdth bit bit bit array, size OCP_status_wdth bit bit bit array, size OCP_scanport_wdth bit array, size OCP_scanport_wdth bit array, size OCP_scanport_wdth bit bit bit bit bit bit bit
Direction master to slave master to slave slave to master slave to master slave to master slave to master system to core core to system system to core core to system core to system system to core system to core system to core core to system system to core system to core system to core system to core core to system system to core system to core
Data Types
In addition to the standard transactor types, such as int, and bit, the AXI transactor makes use of the following types:
// Command encoding type enum MCmd_encoding:3 { IDLE = 0b000, // Idle WR = 0b001, // Write RD = 0b010, // Read RDEX = 0b011, // ReadEx RDL = 0b100, // ReadLinked WRNP = 0b101, // WriteNonPost WRC = 0b110, // WriteConditional BCST = 0b111 // Broadcast }; // Response encoding type enum SResp_encoding:2 { NULL = 0b00, // No response DVA = 0b01, // Data valid / accept FAIL = 0b10, // Request failed ERR = 0b11 // Response error }; // Burst sequence encoding type enum MBurstSeq_encoding:3 { INCR = 0b000, // Incrementing DFLT1 = 0b001, // Custom (packed) WRAP = 0b010, // Wrapping DFLT2 = 0b011, // Custom (not packed) XOR = 0b100, // Exclusive OR STRM = 0b101, // Streaming UNKN = 0b110, // Unknown RSVD = 0b111 // Reserved }; type enum endian_mode // no specific coding for this in the spec { LITTLE, // core is little-endian BIG, // core is big-endian
nTX Users Guide and Tutorial BOTH, // // // // // core can be either big or little endian, depending on its static or dynamic configuration (e.g. CPUs) core has no inherent endianness (e.g. memories, cores that deal only in OCP words)
NEUTRAL };
OCP_addr_wdth the width of the MAddr bus OCP_data_wdth the width of the MData and SData buses OCP_addrspace_wdth the width of the MAddrSpace bus OCP_mdatainfo_wdth the width of the MDataInfo bus OCP_mdatainfobyte_wdth the size of the mdatainfo byte OCP_reqinfo_wdth the width of MReqInfo OCP_sdatainfo_wdth the width of SDataInfo OCP_sdatainfobyte_wdth the size of the sdatainfo byte OCP_respinfo_wdth the width of SRespInfo OCP_atomiclength_wdth the width of MAtomicLength OCP_burstlength_wdth the width of MBurstLength OCP_connid_wdth the width of MConnID OCP_mflag_wdth the width of MFlag OCP_sflag_wdth the width of SFlag OCP_control_wdth the width of Control OCP_status_wdth the width of Status OCP_scanctrl_wdth the width of Scanctrl OCP_scanport_wdth the width of Scanin and Scanout OCP_threads the number of threads (width of the *ThreadBusy buses) OCP_log2_threads the width of MThreadID, SThreadID and SDataThreadID

Overview
The PCIe Transactor supports the following features: PCIe specification 1.0a TLP packet recognition with matching completion. DLLP packet recognition. NTLP packet recognition. 'pad-or-idle' recognition. Configurable number of lanes.
BCF Format
Name
The bus declaration (nte_PCIe_v2p0_8_ns) must be one of the supported transactors.
nte_PCIe_v2p0_8_ns my_PCIe {
Mapping Root
MAPPING_ROOT = "/tlp_dllp_idle_test2/PCI_express_structure/ PCI_Express_adaptor_I";
Signal Map
The SIGMAP statements map transactor signals on the left hand side to user signals on the right hand side. The transactor signals are pre-defined as shown in the file below and must not be changed; however, it is possible to leave signals unconnected by removing them from the sigmap section. If this is done they will be assigned a default value (normally 0). PCI Express has two sets of signals, of which only one should be used, depending on whether you are mapping to differential pairs, or single ended signals. The parameter 'Differential_Wires' is used to indicate which set of signals transactions should be extracted from, and must be set correctly. The following examples are for an 8 lane transactor, signals must be removed or added for transactors with a fewer or greater number of lanes.
NOTE: Clock can be mapped to /PCI_EXPRESS/PCLK0 and /PCI_EXPRESS/
PCLK1. The SIGMAP code examples are for an unmapped clocks.
Example using differential pairs:

SIGMAP { /PCI_EXPRESS/D[0][0] = "/D[0][0]"; // NB using 'D' so Differential_Wires /PCI_EXPRESS/D[0][1] = "/D[0][1]"; // must be set 'true' /PCI_EXPRESS/D[0][2] = "/D[0][2]"; /PCI_EXPRESS/D[0][3] = "/D[0][3]"; /PCI_EXPRESS/D[0][4] = "/D[0][4]"; /PCI_EXPRESS/D[0][5] = "/D[0][5]"; /PCI_EXPRESS/D[0][6] = "/D[0][6]"; /PCI_EXPRESS/D[0][7] = "/D[0][7]"; /PCI_EXPRESS/D[1][0] = "/D[1][0]"; /PCI_EXPRESS/D[1][1] = "/D[1][1]"; /PCI_EXPRESS/D[1][2] = "/D[1][2]"; /PCI_EXPRESS/D[1][3] = "/D[1][3]"; /PCI_EXPRESS/D[1][4] = "/D[1][4]"; /PCI_EXPRESS/D[1][5] = "/D[1][5]"; /PCI_EXPRESS/D[1][6] = "/D[1][6]"; /PCI_EXPRESS/D[1][7] = "/D[1][7]"; }
Example using single ended signals:

SIGMAP { /PCI_EXPRESS/SingleD[0][0] = "/SingleD[0][0]"; // NB using 'SingleD' so Differential_Wires /PCI_EXPRESS/SingleD[0][1] = "/SingleD[0][1]"; // must be set 'false' /PCI_EXPRESS/SingleD[0][2] = "/SingleD[0][2]";
Appendix G: PCI-Express (PCIe) Transactor /PCI_EXPRESS/SingleD[0][3] /PCI_EXPRESS/SingleD[0][4] /PCI_EXPRESS/SingleD[0][5] /PCI_EXPRESS/SingleD[0][6] /PCI_EXPRESS/SingleD[0][7] /PCI_EXPRESS/SingleD[1][0] /PCI_EXPRESS/SingleD[1][1] /PCI_EXPRESS/SingleD[1][2] /PCI_EXPRESS/SingleD[1][3] /PCI_EXPRESS/SingleD[1][4] /PCI_EXPRESS/SingleD[1][5] /PCI_EXPRESS/SingleD[1][6] /PCI_EXPRESS/SingleD[1][7] } = = = = = = = = = = = = = "/SingleD[0][3]"; "/SingleD[0][4]"; "/SingleD[0][5]"; "/SingleD[0][6]"; "/SingleD[0][7]"; "/SingleD[1][0]"; "/SingleD[1][1]"; "/SingleD[1][2]"; "/SingleD[1][3]"; "/SingleD[1][4]"; "/SingleD[1][5]"; "/SingleD[1][6]"; "/SingleD[1][7]";
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file. Configuration of the transactor is made via the PARAMETER section of the bcf file. The available parameters are: PCI_Exp_Lanes: The number of lanes. Must be less than or equal to the maximum allowed by the specific transactor specified. clk_init_value_0: The initial value of the clock for end 0 (0 or 1). clk_init_value_1: The initial value of the clock for end 1 (0 or 1). clk_phase_shift_0: The time of the first transition from the initial value for end 0. clk_phase_shift_1: The time of the first transition from the initial value for end 1. clk_1st_time_0: The relative time of the first clock change after the initial phase shift change for end 0. clk_1st_time_1: The relative time of the first clock change after the initial phase shift change for end 1. clk_2nd_time_0: The relative time of second clock change after the previous change for end 0. clk_2nd_time_1: The relative time of second clock change after the previous change for end 1. Differential_Wires: Use differential pairs, or single ended signals for each lane (true or false). If this is set to true, then each of the 'D' signals should be mapped; otherwise, the 'SingleD' signals should be mapped. Use_request_complete: Use the TLP_request_complete transaction to link TLP requests with their completions (true or false). It may be
useful to turn this off if only one direction is active, or if the nTE is consuming too much memory during the extraction. The clock set up is important to the correct operation of the transactor. An example is shown below:
Figure: Clock Setup

// parameters PARAMETER { PCI_Exp_Lanes = clk_init_value_0 = clk_init_value_1 = clk_phase_shift_0 = clk_phase_shift_1 = clk_1st_time_0 = clk_1st_time_1 = clk_2nd_time_0 = clk_2nd_time_1 = Differential_Wires
8; //number of lanes 0 ns; //initial value of clock[0] 0 ns; //initial value of clock[1] 1 ns; //phase shift of clock[0] 1 ns; //phase shift of clock[1] 1 ns; //First time period of clock[0] 1 ns; //First time period of clock[1] 1 ns; //Second time period of clock[0] 1 ns; //Second time period of clock[1] = true; //Use the 'D' (differential //pair) signals (true), or //'SingleD' (single bit) //signals (false). Use_request_complete = true; //Enable (true) or disable //(false) TLP_request_complete //transactions
A number of transactor configurations are available. The naming convention used is nte_PCIe_ver_lanes_tu where ver, lanes and tu have the following meanings and valid values: ver version (v2p0) lanes the maximum number of lanes, the PCI_Exp_Lanes parameter cannot be set greater than this value (1,2,4,8,12,16,32) tu time unit (ps, ns, fs). This does not have to match the time scale of the input FSDB file; however, any signal changes below this time resolution will not be seen by nTE.
Protocol Tree
TLP_request_complete
TLP_request_complete is a bi-directional transaction between PCIe endpoints. It is defined as an array of size 2, one for each direction of the link. Attributes:
e_TLP_Basic_Types request_type End_Unit[A] >=> End_Unit[B],
Appendix G: PCI-Express (PCIe) Transactor e_TLP_Basic_Types complete_type End_Unit[B] >=> End_Unit[A]
TLP_Packet
TLP_Packet is a unidirectional transaction used for the transfer of a TLP between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
bit Sequence_Number[12] bool LCRC_Error e_TLP_detailed_Types Fmt_Type bit TC[3] bit Attr[2] bit TD bit EP bit Length[10] byte rest_of_header[12] byte data[] byte digest[4]
NTLP_Packet
NTLP_Packet is a uni-directional transaction used for the transfer of a Null TLP between End Units. It is defined as an array of size 2, one for each direction of the link. Note that the payload is an unsized array of bytes and will be set as appropriate to the transaction. Attributes:
byte payload[]
DLLP_AckNak_Packet
DLLP_AckNak_Packet is a uni-directional transaction used for the transfer of a DLL ack/nack packet between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
e_AckNak bit bool AckNak_type Sequence_Number[12] CRC_16_Error
DLLP_FC_Packet
DLLP_FC_Packet is a uni-directional transaction used for the transfer of a DLL flow-control packet between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
nTX Users Guide and Tutorial e_DLLP_Types e_DLLP_Msg_Subtype bit bit bit bool DLLP_Msg_Type DLLP_Msg_Subtype VC_ID[3] HdrFC[8] DataFC[12] CRC_16_Error
DLLP_PM_Packet
DLLP_PM_Packet is a uni-directional transaction used for the transfer of a DLL power management packet between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
e_Pm bool Pm_type CRC_16_Error
DLLP_Vendor_Specific_Packet
DLLP_Vendor_Specific_Packet is a uni-directional transaction used for the transfer of a DLL vendor specific packet between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
Bit bool Vendor_Data[3][8] CRC_16_Error
DLLP_Packet
DLLP_Packet is a unidirectional transaction used for the transfer of a DLL packet between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
e_DLLP_Classes byte bool DLLP_class DLLP_payload[4] CRC_16_Error
Compliance_OS
Compliance_OS is a uni-directional transaction used to transfer the compliance pattern based on the sequence of 8b/10b Symbols K28.5, D21.5, K28.5 & D10.2 between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
bool delayed
Electrical_Idle_OS
Electrical_Idle_OS is a uni-directional transaction used to indicate the state of the output drivers in which both lines of a link are driven to the DC common mode voltage. It is defined as an array of size 2, one for each direction of the link. Attributes: none
Skp_OS
Skp_OS is a uni-directional transaction used to compensate for different bit rates for two communicating Ports between End Units. It is defined as an array of size 2, one for each direction of the link. The attribute n refers to the number of SKP symbols in the ordered set (1..5). Attributes:
word n
FTS_OS
FTS_OS is a uni-directional transaction used to indicate a Fast Training Sequence when moving from a L0s power-saving state to L0 normal state between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes: none
Ts1_OS
Ts1_OS is a uni-directional transaction used to indicate a Ts1 training sequence for initializing bit alignment, Symbol alignment and to exchange Physical Layer parameters between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
bool bit bool bit bit bit bit bit bit bit bit link_number_valid, link_number[8], lane_number_valid, lane_number[8], n_fts[8], data_rate_identifier[8], disable_scrambling, loopback, disable_link, hot_reset, ts1_identifier[8]
Ts2_OS
Ts2_OS is a uni-directional transaction used to indicate a Ts2 training sequence for initializing bit alignment, Symbol alignment and to exchange Physical Layer parameters between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
bool bit bool bit bit bit bit bit bit bit bit link_number_valid, link_number[8], lane_number_valid, lane_number[8], n_fts[8], data_rate_identifier[8], disable_scrambling, loopback, disable_link, hot_reset, ts2_identifier[8]
pad_or_idle
pad_or_idle is a uni-directional transaction used to transfer PAD or IDLE between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes: none
PLLP_Packet
PLLP_Packet is a uni-directional transaction used to transfer a PLL packet between End Units. It is defined as an array of size 2, one for each direction of the link. Attributes:
e_PLLP_Types byte PLLP_Type payload[]
Logical_Idle_Slice
Logical_Idle_Slice is a uni-directional transaction to indicate when no information (TLPs, DLLPs, or special Symbol) is being transmitted or received between End Units. It is defined as a two-dimensional array of size 2, one for each direction of the link, by the number_of_lanes. Attributes: none
Special_Symbols
Special_Symbols is a uni-directional transaction used to transfer a Special Symbol between End Units. It is defined as a two-dimensional array of size 2, one for each direction of the link, by the number_of_lanes. Attributes:
e_Special_Symbols Special_Symbol
Data_Byte
Data_Byte is a uni-directional transaction used to transfer data bytes between End Units. It is defined as a two-dimensional array of size 2, one for each direction of the link, by the number_of_lanes. Attributes:
bit data_byte[8]
Z_Byte
Z_Byte is a uni-directional transaction used for the transfer of Special Symbols and Data Bytes. It is defined as a two-dimensional array of size 2 (one for each direction of the link) by the number_of_lanes. Attributes:
bit bit Z HGFEDCBA[8]
Pre_Encoded_Symbol
Pre_Encoded_Symbol is a uni-directional transaction used for the transfer of preencoded symbols between End Units. It is defined as a two-dimensional array of size 2 (one for each direction of the link) by the number_of_lanes. Attributes:
Z_HGFEDCBA e_Validity z_byte Symbol_Validity
Symbol
Symbol is a uni-directional transaction used for the transfer of Symbols between End Units. It is defined as a two-dimensional array of size 2 (one for each direction of the link) by the number_of_lanes of duration 10*data_rate. Attributes:
bit abcdeifghj[10]
Symbol_Bit
Symbol_Bit is a uni-directional transaction used for the transfer of Symbols bits between End Units. It is defined as a two-dimensional array of size 2 (one for each direction of the link) by the number_of_lanes, of duration equal to the data_rate. Attributes:
bit Differential_Data[2]
Symbol_Single_Bit
Symbol_Single_Bit is a uni-directional transaction used for the transfer of nondifferential Symbol bits between End Units. It is defined as a two-dimensional array of size 2 (one for each direction of the link) by the number of lanes, of duration equal to the data rate. Attributes:
hdl_bit Data
Wires
For a complete description of the link wires refer to section 4 of the PCIeTM Base Specification. The data wires (D) are differential (implemented by the bit array bit[2]) and there are two End Units each having a number_of_lanes (implemented by [2][number_of_lanes]).The data wires SingleD are non-differential.
Name RST D Type bit [2][number_of_lanes] bit [2] Direction Support >=> End_Unit [0] and End_Unit [1] End_Unit[0] >=> End_Unit[1] and End_Unit[1] >=> End_Unit[0] End_Unit[0] >=> End_Unit[1] and End_Unit[1] >=> End_Unit[0]
SingleD [2][number_of_lanes] hdl_bit
Data Types
In addition to the standard transactor types, such as int, and bit, the PCIe transactor makes use of the following types:
type enum e_TLP_Basic_Types:4 { MRd = 0, MRdLk = 1, MWr = 2, IORd = 3, IOWr = 4, CfgRd0 = 5, CfgWr0 = 6, CfgRd1 = 7, CfgWr1 = 8, Msg = 9, MsgD = 10, Cpl = 11, CplD = 12, CplLk = 13, CplDLk = 14, Reserved = 15 }; type enum e_TLP_detailed_Types:7 { MRd_32bit = 0b00_0_0000, //Memory Read Request 32-bit MRdLk_32bit = 0b00_0_0001, //Memory Read Request-Locked //32-bit IORd = 0b00_0_0010, //IO Read Request Reserved1 = 0b00_0_0011, //Reserved CfgRd0 = 0b00_0_0100, //Configuration Read Type 0 CfgRd1 = 0b00_0_0101, //Configuration Read Type 1 Reserved2 Reserved3 Reserved4 Reserved5 Cpl CplLk Reserved6 Reserved7 Reserved8 = = = = = = 0b00_0_0110, 0b00_0_0111, 0b00_0_1000, 0b00_0_1001, 0b00_0_1010, 0b00_0_1011, //Reserved //Reserved //Reserved //Reserved //Completion without data //Completion for Locked //Memory Read without Data //Reserved //Reserved //Reserved
= 0b00_0_1100, = 0b00_0_1101, = 0b00_0_1110,
nTX Users Guide and Tutorial Reserved9 Reserved10 Reserved11 Reserved12 Reserved13 Reserved14 Reserved15 Reserved16 Reserved17 Reserved18 Reserved19 Reserved20 Reserved21 Reserved22 Reserved23 Reserved24 Reserved25 MRd_64bit MRdLk_64bit Reserved26 Reserved27 Reserved28 Reserved29 Reserved30 Reserved31 Reserved32 Reserved33 Reserved34 Reserved35 Reserved36 Reserved37 Reserved38 Reserved39 MsgRoutComp = 0b00_0_1111, //Reserved = 0b00_1_0000, //Reserved = 0b00_1_0001, //Reserved = 0b00_1_0010, //Reserved = 0b00_1_0011, //Reserved = 0b00_1_0100, //Reserved = 0b00_1_0101, //Reserved = 0b00_1_0110, //Reserved = 0b00_1_0111, //Reserved = 0b00_1_1000, //Reserved = 0b00_1_1001, //Reserved = 0b00_1_1010, //Reserved = 0b00_1_1011, //Reserved = 0b00_1_1100, //Reserved = 0b00_1_1101, //Reserved = 0b00_1_1110, //Reserved = 0b00_1_1111, //Reserved = 0b01_0_0000, //Memory Read Request 64-bit = 0b01_0_0001, //Memory Read Request-Locked //64-bit = 0b01_0_0010, //Reserved = 0b01_0_0011, //Reserved = 0b01_0_0100, //Reserved = 0b01_0_0101, //Reserved = 0b01_0_0110, //Reserved = 0b01_0_0111, //Reserved = 0b01_0_1000, //Reserved = 0b01_0_1001, //Reserved = 0b01_0_1010, //Reserved = 0b01_0_1011, //Reserved = 0b01_0_1100, //Reserved = 0b01_0_1101, //Reserved = 0b01_0_1110, //Reserved = 0b01_0_1111, //Reserved = 0b01_1_0000, //Message routed to route //complex //Message routed by address //Message routed by ID //Message broadcast from //root complex //Message local - terminate //at receiver //Message gathered and //routed to route complex //Message Reserved //Terminate at Receiver //Message Reserved //Terminate at Receiver
MsgRoutAdd = 0b01_1_0001, MsgRoutID = 0b01_1_0010, MsgBroadComp = 0b01_1_0011, MsgLocal MsgGather = 0b01_1_0100, = 0b01_1_0101,
MsgReserved1 = 0b01_1_0110, MsgReserved2 = 0b01_1_0111,
Reserved40 Reserved41 Reserved42 Reserved43 Reserved44 Reserved45 Reserved46 Reserved47 MWr_32bit Reserved48 IOWr Reserved49 CfgWr0 CfgWr1 Reserved50 Reserved51 Reserved52 Reserved53 CplD CplDLk
= = = = = = = =
0b01_1_1000, 0b01_1_1001, 0b01_1_1010, 0b01_1_1011, 0b01_1_1100, 0b01_1_1101, 0b01_1_1110, 0b01_1_1111,
//Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Memory write request 32-bit //Reserved //IO write request //Reserved //Configuration write type 0 //Configuration write type 1 //Reserved //Reserved //Reserved //Reserved //Completion with data //Completion for locked //memory read //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved
= 0b10_0_0000, = 0b10_0_0001, = 0b10_0_0010, = 0b10_0_0011, = 0b10_0_0100, = 0b10_0_0101, = = = = 0b10_0_0110, 0b10_0_0111, 0b10_0_1000, 0b10_0_1001,
= 0b10_0_1010, = 0b10_0_1011,
Reserved54 Reserved55 Reserved56 Reserved57 Reserved58 Reserved59 Reserved60 Reserved61 Reserved62 Reserved63 Reserved64 Reserved65 Reserved66 Reserved67 Reserved68 Reserved69 Reserved70 Reserved71 Reserved72
= = = = = = = = = = = = = = = = = = =
0b10_0_1100, 0b10_0_1101, 0b10_0_1110, 0b10_0_1111, 0b10_1_0000, 0b10_1_0001, 0b10_1_0010, 0b10_1_0011, 0b10_1_0100, 0b10_1_0101, 0b10_1_0110, 0b10_1_0111, 0b10_1_1000, 0b10_1_1001, 0b10_1_1010, 0b10_1_1011, 0b10_1_1100, 0b10_1_1101, 0b10_1_1110,
nTX Users Guide and Tutorial Reserved73 MWr_64bit Reserved74 Reserved75 Reserved76 Reserved77 Reserved78 Reserved79 Reserved80 Reserved81 Reserved82 Reserved83 Reserved84 Reserved85 Reserved86 Reserved87 Reserved88 MsgDRoutComp = 0b10_1_1111, = 0b11_0_0000, = = = = = = = = = = = = = = = 0b11_0_0001, 0b11_0_0010, 0b11_0_0011, 0b11_0_0100, 0b11_0_0101, 0b11_0_0110, 0b11_0_0111, 0b11_0_1000, 0b11_0_1001, 0b11_0_1010, 0b11_0_1011, 0b11_0_1100, 0b11_0_1101, 0b11_0_1110, 0b11_0_1111, //Reserved //Memory write request 64-bit //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved
//Message routed to route //complex with data MsgDRoutAdd = 0b11_1_0001, //Message routed by address //with data MsgDRoutID = 0b11_1_0010, //Message routed by ID with //data MsgDBroadComp = 0b11_1_0011, //Message broadcast from //root complex with data MsgDLocal = 0b11_1_0100, //Message local - terminate //at receiver with data MsgDGather = 0b11_1_0101, //Message gathered and //routed to route complex with data MsgDReserved1 = 0b11_1_0110, //Message Reserved //Terminate at Receiver MsgDReserved2 = 0b11_1_0111, //Message Reserved //Terminate at Receiver Reserved89 Reserved90 Reserved91 Reserved92 Reserved93 Reserved94 Reserved95 Reserved96 }; type enum e_AckNak : 1 = = = = = = = = 0b11_1_1000, 0b11_1_1001, 0b11_1_1010, 0b11_1_1011, 0b11_1_1100, 0b11_1_1101, 0b11_1_1110, 0b11_1_1111, //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved //Reserved
= 0b11_1_0000,
{Ack, Nak}; type enum e_Pm : 2 {Pm_Enter_L1, Pm_Enter_L23, Pm_Act_State_Req, Pm_Req_Ack }; type enum e_DLLP_Msg_Subtype : 2 {P, NP, Cpl }; // Posted // NonPosted // Completed
type enum e_DLLP_Types : 3 {AckNak, Pm, Vendor_Specific, InitFC1, InitFC2, UpdateFC }; type enum e_DLLP_Classes : 3 {AckNak_Class, Pm_Class, Vendor_Specific_Class, Fc_Class, Unknown_Class }; type enum e_PLLP_Types : 2 {NULLIFIED_TLP, TLP, DLLP}; type struct Z_HGFEDCBA {bit Z; bit HGFEDCBA[8]; }; type enum e_Special_Symbols
nTX Users Guide and Tutorial {PD_SKP PD_FTS PD_SDP PD_IDL PD_RES1 PD_COM PD_RES2 PD_RES3 PD_PAD PD_STP PD_END PD_EDB }; = = = = = = = = = = = = 00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, // // // // // // // // // // // // Positive Positive Positive Positive Positive Positive Positive Positive Positive Positive Positive Positive Disparity Disparity Disparity Disparity Disparity Disparity Disparity Disparity Disparity Disparity Disparity Disparity SKP FTS SDP IDL RES1 COM RES2 RES3 PAD STP END EDB Character Character Character Character Character Character Character Character Character Character Character Character
type enum e_Validity {InValid, Valid};

Overview
The UART transactor fits between two industry standard UART devices to perform a point-to-point, full duplex, serial communication link. It enables the recognition of transactions from a wire level FSDB file. The UART Transactor supports the majority of features present in 16C550 compatible devices. Features supported include: Selectable serial data rates. Independent receiver and transmitter operating frequency to enable dual speed channel applications. Programmable character format: Word Length of 5, 6, 7 or 8 bit words Parity Selection: No Parity, Even or Odd. Stop Bit Length: 1, 1, 2. Software Flow Control via XON/XOFF character generation/recognition.
BCF Format
Name
The bus declaration (nte_UART_v2p1_ns) must be one of the supported transactors.
nte_UART_v2p1_ns UARTtest {
Mapping Root
MAPPING_ROOT = "/UART_loopback/UART_structure/UART_I";
Signal Map
NOTE: UART transactor does not have a clock that can be mapped.
SIGMAP { /UART/TX /UART/RX /UART/DTRn /UART/RTSn /UART/CTSn /UART/RIn /UART/DCDn /UART/DSRn } = = = = = = = = "/TX"; "/RX"; "/DTRn"; "/RTSn"; "/CTSn"; "/RIn"; "/DCDn"; "/DSRn";
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file. Configuration of the transactor is made via the PARAMETER section of the bcf file. The available parameters are: Tx_bit_clk_1st_time: The relative time period of the first Tx_bit_clk change. Tx_bit_clk_2nd_time: The relative time period of the second Tx_bit_clk change after the previous change. Tx_sample_clk_1st_time: The relative time period of the first Tx_sample_clk change. Tx_sample_clk_2nd_time: The relative time period of the second Tx_sample_clk change after the previous change. Rx_bit_clk_1st_time: The relative time period of the first Rx_bit_clk change.
Rx_bit_clk_2nd_time: The relative time period of the second Rx_bit_clk change after the previous change. Rx_sample_clk_1st_time: The relative time period of the first Rx_sample_clk change. Rx_sample_clk_2nd_time: The relative time period of the second Rx_sample_clk change after the previous change. UART_word_length: The number of bits per word. UART_parity_mode: Parity on or off. UART_parity_type: Even or odd parity. UART_stop_bit_length: Number of stop bits. UART_software_flow_control: Specify whether XON/XOFF characters are enabled. UART_number_xon_xoff_chars: Number of XON/XOFF characters. UART_xoff1: Value used as XOFF1. UART_xoff2: Value used as XOFF2. UART_xon1: Value used as XON1. UART_xon2: Value used as XON2. The clock set up is important for the correct operation of the transactor. An example is shown below:
Figure: Clock Setup

// parameters PARAMETER { Tx_bit_clk_1st_time = 800 ns; Tx_bit_clk_2nd_time = 800 ns; Tx_sample_clk_1st_time = 50 ns; Tx_sample_clk_2nd_time = 50 ns; Rx_bit_clk_1st_time = 800 ns; Rx_bit_clk_2nd_time = 800 ns; Rx_sample_clk_1st_time = 50 ns; Rx_sample_clk_2nd_time = 50 ns; UART_word_length = 8;
nTX Users Guide and Tutorial UART_parity_mode = parity_ena; //parity_ena | parity_dis UART_parity_type = evn; //evn | odd UART_stop_bit_length = 1.0; UART_software_flow_control = sfc_dis; //sfc_dis | sfc_ena UART_number_xon_xoff_chars = 1; UART_xoff1 = 0b11111011; UART_xoff2 = 0b01010011; UART_xon1 = 0b11100010; UART_xon2 = 0b00011101; }
A number of transactor configurations are available. The naming convention used is nte_UART_'ver'_tu where ver and tu have the following meanings and valid values: ver version (v2p1) tu time unit (ps, ns, fs). This does not have to match the time scale of the input FSDB file; however, any signal changes below this time resolution will not be seen by nTE.
Protocol Tree - TX
Protocol Tree - RX
Tx_BRK_char
Tx_BRK_char is a uni-directional transaction from UART_unit_A to UART_unit_B indicating the Break condition.
Tx_XOFF_char
Tx_XOFF_char is a uni-directional transaction from UART_unit_A to UART_unit_B indicating an XOFF character sequence. This transaction is only enabled when the Software Flow Control feature of the UART Transactor is enabled.
Tx_XON_char
Tx_XON_char is a uni-directional transaction from UART_unit_A to UART_unit_B indicating an XON character sequence. This transaction is only enabled when the Software Flow Control feature of the UART Transactor is enabled.
Tx_char
Tx_char is a uni-directional transaction from UART_unit_A to UART_unit_B indicating a data character with correct parity. Attributes:
bit data[8]
Tx_char_parity_error
Tx_char_parity_error is a uni-directional transaction from UART_unit_A to UART_unit_B indicating a data character with incorrect parity. Attributes:
mbit data[8]
Rx_BRK_char
Rx_BRK_char is a uni-directional transaction from UART_unit_B to UART_unit_A indicating the Break condition.
Rx_XOFF_char
Rx_XOFF_char is a uni-directional transaction from UART_unit_B to UART_unit_A indicating an XOFF character sequence. This transaction is only enabled when the Software Flow Control feature of the UART Transactor is enabled.
Rx_XON_char
Rx_XON_char is a uni-directional transaction from UART_unit_B to UART_unit_A indicating an XON character sequence. This transaction is only enabled when the Software Flow Control feature of the UART Transactor is enabled.
Rx_char
Rx_char is a uni-directional transaction from UART_unit_B to UART_unit_A indicating a data character with correct parity. Attributes:
bit data[8]
Rx_char_parity_error
Rx_char_parity_error is a uni-directional transaction from UART_unit_B to UART_unit_A indicating a data character with incorrect parity. Attributes:
bit data[8]
Tx_start
Tx_start is a uni-directional transaction from UART_unit_A to UART_unit_B indicating an active low Start bit.
Tx_word
Tx_word is a uni-directional transaction from UART_unit_A to UART_unit_B indicating a 5, 6, 7, or 8-bit data character word. Attributes:
bit data[8]
Tx_parity
Tx_parity is a uni-directional transaction from UART_unit_A to UART_unit_B indicating a data character parity bit. This transaction is only enabled when the Parity Mode feature has been enabled.
Attributes:
bit p
Tx_stop
Tx_stop is a uni-directional transaction from UART_unit_A to UART_unit_B indicating a characters Stop Bit sequence. The UART Transactor may be configured to recognize 1, 1, or 2 Stop Bits. Attributes:
bit data
Rx_start
Tx_start is a uni-directional transaction from UART_unit_B to UART_unit_A indicating an active low Start bit.
Rx_word
Rx_word is a uni-directional transaction from UART_unit_B to UART_unit_A indicating a 5, 6, 7, or 8-bit data character word. Attributes:
bit data[8]
Rx_parity
Rx_parity is a uni-directional transaction from UART_unit_B to UART_unit_A indicating a data character parity bit. This transaction is only enabled when the Parity Mode feature has been enabled. Attributes:
bit p
Rx_stop
Rx_stop is a uni-directional transaction from UART_unit_B to UART_unit_A indicating a characters Stop Bit sequence. The UART Transactor may be configured to recognize 1, 1, or 2 Stop Bits. Attributes:
bit data
Tx_start_sample
Tx_start_sample is a uni-directional transaction from UART_unit_A to UART_unit_B of duration Tx_sample_clk_period indicating a Start Bit synchronized to the rising edge of Tx_sample_clk.
Tx_bit
Tx_bit is a uni-directional transaction from UART_unit_A to UART_unit_B of duration Tx_bit_clk_period indicating a single Data Bit synchronized to the rising edge of Tx_bit_clk. Attributes:
bit data
Tx_stop_bit
Tx_stop_bit is a uni-directional transaction from UART_unit_A to UART_unit_B of duration Tx_bit_clk_period indicating a single Stop Bit synchronized to the rising edge of Tx_bit_clk. Attributes:
bit data
Tx_stop_halfbit
Tx_stop_bit is a uni-directional transaction from UART_unit_A to UART_unit_B of duration Tx_half_bit_clk_period indicating a single Half Stop Bit synchronized to the rising edge of Tx_half_bit_clk. Attributes:
bit data
Rx_start_sample
Rx_start_sample is a uni-directional transaction from UART_unit_B to UART_unit_A of duration Rx_sample_clk_period indicating a Start Bit synchronized to the rising edge of Rx_sample_clk.
Rx_bit
Rx_bit is a uni-directional transaction from UART_unit_B to UART_unit_A of duration Rx_bit_clk_period indicating a single Data Bit synchronized to the rising edge of Rx_bit_clk. Attributes:
bit data
Rx_stop_bit
Rx_stop_bit is a uni-directional transaction from UART_unit_B to UART_unit_A of duration Rx_bit_clk_period indicating a single Stop Bit synchronized to the rising edge of Rx_bit_clk.
Attributes:
bit data
Rx_stop_halfbit
Rx_stop_bit is a uni-directional transaction from UART_unit_B to UART_unit_A of duration Rx_half_bit_clk_period indicating a single Half Stop Bit synchronized to the rising edge of Rx_half_bit_clk. Attributes:
bit data
Wires
Name TX RX DTRn RTSn CTSn RIn DCDn DSRn RCLK Type bit bit bit bit bit bit bit bit bit Direction UART_unit_A >=> UART_unit_B UART_unit_B >=> UART_unit_A UART_unit_A >=> UART_unit_B UART_unit_A >=> UART_unit_B UART_unit_B >=> UART_unit_A UART_unit_B >=> UART_unit_A UART_unit_B >=> UART_unit_A UART_unit_B >=> UART_unit_A Support to UART_unit_A
Data Types
In addition to the standard transactor types, such as int, and bit, the UART transactor makes use of the following types:
type enum e_ParitySelection {
nTX Users Guide and Tutorial no_parity, ODD_parity, EVEN_parity, force_parity_1, force_parity_0 }; type enum e_StopBitLength { one, one_half, two }; type enum special_characters { data_character, xoff1_character, xoff2_character, xon1_character, xon2_character }; type enum e_parity_mode { parity_dis, parity_ena }; type enum e_parity_type { evn, odd }; type enum e_sfc { sfc_dis, sfc_ena };

Overview
The USB 2.0 Transactor supports the following features: USB Revision 2.0 (see Limitations below). High-speed (480Mb/s), Full-speed (12Mb/s) & Low-speed (1.5Mb/s). Control, Interrupt, Bulk, Isochronous, Start Split, Complete Split and Ping transactions. Start-of-Frame packets. Power-on Reset to determine speed (parameterized and selectable).
The following limitations apply to the current version of the USB 2.0 Transactor: Suspend and Resume is not supported.
BCF Format
Name
The bus declaration (e.g. nte_USB2_v1p0_fs) must be one of the included transactor libraries.
nte_USB2_v1p0_fs myUSB {
Mapping Root
MAPPING_ROOT = "/USB2_top_level/USB2_structure/the_usb_bus";
Signal Map
The SIGMAP statements map transactor signals on the left hand side to user signals on the right hand side. The transactor signals are pre-defined as shown in the file below and must not be changed.
NOTE: Clock can be mapped to /USB2/UCLK. The SIGMAP code example is
for an unmapped clock.
SIGMAP { // USB signals /USB2/DP /USB2/DM }
= "/DP"; = "/DM";
Parameters
The values in the PARAMETER section configure the transactor to match the input FSDB file. Configuration of the transactor is made via the PARAMETER section of the BCF file. The available parameters are: clk_init_value: The initial value of the clock (0 or 1). clk_phase_shift: The time of the first transition from the initial value. clk_1st_time: The relative time of the first clock change after the initial phase shift change. clk_2nd_time: The relative time of second clock change after the previous change. setup_time: The setup time for all USB signals. hold_time: The hold time for all USB signals. packet2packet_delay: The maximum delay permitted between a token packet and subsequent data packet (including zero-length data packets). usb_speed_selector: Manually selects the speed of the USB bus. Can be set to low, full or high. This parameter is ignored if enable_speed_detection is set to true. enable_speed_detection: If set to false the speed is set manually via the usb_speed_selector parameter. If set to true then the transactor will detect the speed from the signals according to the USB 2.0 specification. In this case the remaining parameters (below) must be set. tDRST: Length of complete reset speed detection. tUCH: Minimum duration of a Chirp K from a high-speed capable device within the reset protocol.
tWTREV: Duration a high-speed capable device operating in high-speed must wait after start of SE0 before reverting to full-speed. tWTRSTHS: Time a device must wait after reverting to full-speed before sampling the bus state for SE0 and beginning the high-speed detection handshake. tWTDCH: Time after end of device Chirp K by which hub must start driving first Chirp K in the hubs chirp sequence. tDCHSE0: Time before end of reset by which a hub must end its downstream chirp sequence. The clock set up is important for the correct operation of the transactor. An example is shown below:
Figure: Clock Setup
The USB interface speed can be detected by the transactor or set manually via the usb_speed_selector parameter. The diagram below demonstrates the parameters that need to be set if speed is detection is required (enable_speed_detection = true).
Figure: High Speed Detection Parameters
Note that tWTREV + tWTRSTHS is the minimum time required for a valid SE0 to be recognized. If this is too short then reset SE0s may be incorrectly detected during extraction, resulting in the transactor resetting the speed mid-simulation.
nTX Users Guide and Tutorial // parameters PARAMETER { clk_init_value clk_phase_shift clk_1st_time clk_2nd_time setup_time hold_time packet2packet_delay usb_speed_selector enable_speed_detection tDRST tUCH tWTREV tWTRSTHS tWTDCH tDCHSE0 }
= = = = = = = = = = = = = = =
0b0; 0 fs; 1041600 fs; 1041600 fs; 100 fs; 100 fs; 500 ns; high; false; 10 ms; 1 ms; 3 ms; 100 us; 100 us; 500 us;
A number of transactor configurations are available. The naming convention used is nte_USB2_ver_tu where ver and tu have the following meanings and valid values: ver version (v1p0) tu time unit (ps, fs)
The USB 2.0 transactor consists of a number of transactions that enable communication at different levels of abstraction. In this section the function, types and attributes of these transactions are described in detail. Referring to the protocol tree can help to visualize transactions that are recognized by the transactor.
Protocol Tree
Setup_stage
Setup_stage is a unidirectional write transaction between the host/hub and device. It includes the control token packet and any subsequent data packet used during control transfers. Attributes:
int int T_USB2_bmRequestType_transfer_direction T_USB2_bmRequestType_type T_USB_bmRequestType_recipient bit bit bit int T_USB2_packet_identifier_field address endpoint transfer_direction transfer_type transfer_recipient bRequest[8] wValue[16] wIndex[16] wLength data_type_pid
IN_data_stage
IN_data_stage is a bi-directional read transaction between the host/hub and device. It includes the token packet and any subsequent data packet during read transfers. Attributes:
int int int T_USB2_packet_identifier_field bit data_packet_length address endpoint data_type_pid data_in[][8]
OUT_data_stage
OUT_data_stage is a unidirectional transaction between the host/hub and device. It includes the token packet and any subsequent data packet during write transfers. Attributes:
int int int data_packet_length address endpoint
Appendix I: USB Transactor T_USB2_packet_identifier_field bit data_type_pid data_out[][8]
OUT_ssplit_stage
OUT_ssplit_stage is a unidirectional write transaction between the host and hub. It includes the Start_Split token, FS/LS token and any subsequent data packet during split-write transfers. Attributes:
int int bit bit T_USB2_endpoint_type int int int T_USB2_packet_identifier_field bit hub_address port_number speed_start end endpoint_type address endpoint data_packet_length data_type_pid data_out[][8]
OUT_csplit_stage
OUT_csplit_stage is a unidirectional write transaction between the host and hub. It includes the Complete-Split token and FS/LS token during split-write transfers. Attributes:
int int bit T_USB2_endpoint_type int int hub_address port_number speed_start endpoint_type address endpoint
IN_ssplit_stage
IN_ssplit_stage is a unidirectional read transaction between the host and hub. It includes the Start-Split token and FS/LS token during split-read transfers. Attributes:
int int bit bit T_USB2_endpoint_type int int hub_address port_number speed_start end endpoint_type address endpoint
IN_csplit_stage
IN_csplit_stage is a bi-directional read transaction between the host and hub. It includes the Complete-Split token, FS/LS token and any subsequent data packet during split-read transfers. Attributes:
int int bit T_USB2_endpoint_type int int int T_USB2_packet_identifier_field bit hub_address port_number speed_start endpoint_type address endpoint data_packet_length data_type_pid data_in[][8]
token_packet
token_packet is a unidirectional transaction between a host/hub and device. It contains the packet identifier, address, endpoint and CRC5 values. Attributes:
T_USB2_packet_identifier_field bit bit bool packet_id address[7] endpoint[4] crc5_error
split_token_packet
split_token_packet is a unidirectional transaction between a host and hub. It contains the packet hub address, port number, speed, endpoint and CRC5 values. Attributes:
bit bit bit bit bit T_USB2_endpoint_type bool address[7] start_complete port[7] speed_start end end_type crc5_error
ping_special_token
ping_special_token is a unidirectional transaction between a host/hub and device. It contains the address and endpoint values. Attributes:
int address
Appendix I: USB Transactor int endpoint
start_of_frame_packet
start_of_frame_packet is a unidirectional transaction between a host/hub and device. It is generated every 125?s signifying the start of a micro-frame and contains the frame number. Attributes:
int bool frame_number crc5_error
data_packet
data_packet is a unidirectional transaction between a host/hub and device. It contains the payload length, packet identifier, data bytes and CRC16. Attributes:
int T_USB2_packet_identifier_field bit bool payload_length packet_id data[][8] crc16_error
handshake_packet
handshake_packet is a unidirectional transaction between a host/hub and device. It contains the handshake response from host or device. Attributes:
T_USB2_packet_identifier_field packet_id
sync_phase
sync_phase is a unidirectional transaction between a host/hub and device. It signifies the start of a packet. Attributes: none.
split_phase
split_phase is a unidirectional transaction between a host and hub. It contains the start/complete identifier, port address, speed indication and endpoint type for split transfers. Attributes:
bit bit bit bit start_complete port[7] speed_start end
nTX Users Guide and Tutorial bit end_type[2]
identifier_phase
identifier_phase is a unidirectional transaction between a host/hub and device. It contains the packet identifier. Attributes:
T_USB2_packet_identifier_field packet_id
bit_stuff_phase
bit_stuff_phase is a unidirectional transaction between a host/hub and device. It controls when bit-stuffing is required. Attributes:
bit bool data_bit data_valid
address_phase
address_phase is a unidirectional transaction between a host/hub and device. It contains the address of the device. Attributes:
bit address[7]
endpoint_phase
endpoint_phase is a unidirectional transaction between a host/hub and device. It contains the endpoint of the device. Attributes:
bit endpoint[4]
frame_number_phase
frame_number_phase is a unidirectional transaction between a host/hub and device. It contains the frame number. Attributes:
bit frame_number[11]
data_phase
data_phase is a unidirectional transaction between a host/hub and device. It contains the data byte stream. Attributes:
Appendix I: USB Transactor int payload_length bit data[][8]
NOTE: The CRC16 value and 8-bit EOP are absorbed into the data byte stream
as the last 3-bytes in the stream.
crc5_phase
crc5_phase is a unidirectional transaction between a host/hub and device. It contains the CRC5 value. Attributes:
bit crc5_data[5]
end_of_sof_phase
end_of_sof_phase is a unidirectional transaction between a host/hub and device. It signifies the EOP for a Start-of-Frame packet. Attributes: None.
end_of_packet_phase
end_of_packet_phase is a unidirectional transaction between a host/hub and device. It signifies EOP for packets other than Start-of-Frame or Data. Attributes: None.
usb2_stripe
usb2_stripe is a bi-directional transaction between a host/hub and device. It contains the un-coded bit values. Attributes:
bit bit plus minus
Wires
Name DP DM Type bit bit Direction source to destination or destination to source source to destination or destination to source
Data Types
In addition to the standard transactor types, such as int, and bit, the USB 2.0 transactor makes use of the following types:
type enum T_USB2_packet_identifier_field:4 { pid_reserved = 0b0000, pid_out = 0b0001, pid_ack = 0b0010, pid_data0 = 0b0011, pid_ping = 0b0100, pid_sof = 0b0101, pid_nyet = 0b0110, pid_data2 = 0b0111, pid_split = 0b1000, pid_in = 0b1001, pid_nak = 0b1010, pid_data1 = 0b1011, pid_pre_or_err = 0b1100, pid_setup = 0b1101, pid_stall = 0b1110, pid_mdata = 0b1111 }; type enum T_USB2_endpoint_type:2 { endp_control = 0b00, endp_isochronous = 0b01, endp_bulk = 0b10, endp_interrupt = 0b11 }; type enum T_USB2_bmRequestType_transfer_direction:1 { host2device = 0b0, device2host = 0b1 }; type enum T_USB2_bmRequestType_type:2 { t_standard = 0b00, t_class = 0b01, t_vendor = 0b10, t_reserved = 0b11
Appendix I: USB Transactor }; type enum T_USB_bmRequestType_recipient:5 { recip_device = 0b0_0000, recip_interface = 0b0_0001, recip_endpoint = 0b0_0010, recip_other = 0b0_0011, recip_reserved = 0b0_0100 }; type enum T_USB2_speed:2 { low = 0b00, full = 0b01, high = 0b10, };
Index
Index
A
API 15, 21, 69, 72 attribute 70, 72 attributes 15, 17, 18, 19, 39, 40, 45, 46, 47
M
marker 45 Merge Stream 43
C
C code 66 C files 73 C functions 64 C program 65 child transactions 40 Column Configuration 46 cursor 45 cursor time 17
N
nWave 16, 19, 38, 39
O
Open Transaction Interface 15, 21 OTI 15, 21 overlap 17
P
PCI 64, 71 PLI 64, 65, 66
D
dynamic link 65
F
filter 45 FSDB 15, 16, 21, 38, 44, 64, 69, 70, 71, 72, 73
R
related transaction 18 relationships 18, 40
S
Search Backward 16, 17, 19, 40 Search Forward 16, 17, 19, 39, 40 Set Search Attributes 19 Show All 20, 47, 50 stream 17, 39, 43, 70 streams 15, 19 Sync Cursor Time 45 system tasks 73
G
Get Signals 38 Get Stream 41
H
HDL 64 header file 65, 69
T
transaction 15, 16, 17, 18, 38, 40, 41, 64, 70, 71, 72, 73 Transaction Analyzer 19, 41, 43, 45, 47, 48, 49, 50 Transaction Attribute Values 19, 39 transaction relationships 19 transaction streams 42, 44 transactions 49, 50
V
Verdi 37 Verilog 65, 66
W
waveform 17

NOVAS NTX Tutorial

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NOVAS NTX Tutorial

Uploaded by

Copyright:

Available Formats

nTX

Users Guide and Tutorial

NOVAS Software, Inc.

Debug with Transactions

nTX Users Guide and Tutorial

Bus Configuration File (BCF) Format.................................................. 32 nTE Results........................................................................................... 35

Appendix A: AMBA AHB Transactor

Appendix B: AMBA AHB Lite Transactor

Appendix C: AMBA APB Transactor

Appendix D: AMBA AXI Transactor

nTX Users Guide and Tutorial

Appendix E: MPEG2_TS Transactor

Appendix F: OCP-IP Transactor

Appendix G: PCI-Express (PCIe) Transactor

Appendix H: UART Transactor

Appendix I: USB Transactor

nTX Users Guide and Tutorial

About This Book

About This Book

nTX Users Guide and Tutorial

About This Book

Conventions Used in This Book

nTX Users Guide and Tutorial

About This Book

How to Reach Novas Software, Inc.

nTX Users Guide and Tutorial

nTX Users Guide and Tutorial

Debug with Transactions

Debug with Transactions

Generating Transaction Data

nTX Users Guide and Tutorial

Detailed Transaction View

Figure: Detailed Transaction View

Debug with Transactions

Figure: Transaction Tip

nTX Users Guide and Tutorial

Figure: Transaction Relationships

Figure: Transaction Property Dialog Window - Attributes

Debug with Transactions

Figure: Search Attribute Value Form

nTX Users Guide and Tutorial

The window will be similar to the following:

Figure: Transaction Analyzer Window

Generating Transaction Data

Provided FSDB Dumpers

Debug with Transactions

FSDB Writer API and the Open Transaction Interface (OTI)

nTX Users Guide and Tutorial

Use SystemVerilog Assertions (SVA)

nTX Users Guide and Tutorial

Figure: Transaction Evaluator Form

Recommended Coding Style

should be modified as:

nTX Users Guide and Tutorial int localvar2; ... endsequence

Unsupported Coding Style

nTX Users Guide and Tutorial

will be extracted and displayed as transaction waveforms similar to the following:

Figure: Extracted Transaction Waveform

nTX Users Guide and Tutorial

Installing nTE from the Internet

2. Change to the installation directory.

The following directories are created: