Register Assistant User Manual Release v5.1 © 2010-2018 Mentor Graphics Corporation

Register Assistant User Manual
Release v5.1
© 2010-2018 Mentor Graphics Corporation

All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
Note - Viewing PDF files within a web browser causes some links not to function (see MG595892).
Use HTML for full navigation.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: mentor.com/trademarks.
The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis.
End-User License Agreement: You can print a copy of the End-User License Agreement from:
mentor.com/eula.
Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: mentor.com
Support Center: support.mentor.com
Send Feedback on Documentation: support.mentor.com/doc_feedback_form

Table of Contents
Chapter 1
Register Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Register Assistant Abstract Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Using Register Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Overview on Register Data Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Blocks, Blocks Maps, and Registers/Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 2
Starting the Register Assistant Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 3
Register Assistant Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Importing Data From CSV Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
CSV Import Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Importing Data From IP-XACT XML Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
IP-XACT Import Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Importing Data from Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Import Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Setting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Importing From CSV Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Importing From Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Auto-Instancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Chapter 4
Checking Imported Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Default Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Custom Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Checks Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Running Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Running Default Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Running Custom Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Chapter 5
Register Assistant Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
UVM Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Generated UVM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Supporting Coverage Models for Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Register Assistant User Manual, v5.1 3

Table of Contents
Supporting Coverage Models for Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Supporting Simple “Quirky” Registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
How to Use Quirky Register With CSV Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Through CSV Specific Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Through Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
How To Use Quirky Register With JavaScript Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Supporting Back Door Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
OVM Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Generated OVM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
HTML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
HTML Output Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
RTL Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Specifying RTL Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Specifying Software and Hardware Access Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Specifying the Bus Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Generic Bus and Bus Bridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Preparing the Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Understanding RTL Intrinsic Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Examining the Generated RTL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
File Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Customizing Generated Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Entering Data to Register Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
What to Specify in the Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
RTL Alternative Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
RTL Software Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
RTL Byte Enable Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Understanding RTL Field Signal Naming and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
RTL Write/Read Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Pipelining Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Pipelining Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Pipelining Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Pipelining RTL Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
C Header Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Specifying the Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Understanding C Header Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Examining the Generated C Header File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Generating C Utility Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Word Addressable Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Applying Word Addressing in Register Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Chapter 6
Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Custom Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Defining Properties for Register Assistant Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Custom Properties Definition Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Using Custom Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Handling Custom Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
4 Register Assistant User Manual, v5.1

Table of Contents
CSV Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

IP-XACT Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Using Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Standard Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Alias-Based Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Appendix A
Command Line Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Running Register Assistant in Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Appendix B
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
JavaScript/Tcl Import File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
UVM Output Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
OVM Output Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
RTL Pipelining Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
UVM Word Addressable Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Appendix C
Migrating to Register Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Mapping Command Line Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
End-User License Agreement

Table of Contents

List of Figures
Figure 1-1. Block Maps, Blocks and Registers/Memories . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 2-1. Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 3-1. CSV Import Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 3-2. IP-XACT Import Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 3-3. JavaScript Import File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 4-1. Checks Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 5-1. UVM Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 5-2. Register Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 5-3. Block Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 5-4. OVM Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figure 5-5. HTML Output Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 5-6. RTL Generator Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Figure 5-7. Bus Bridge Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Figure 5-8. Read Write Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 5-9. RTL Code Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 5-10. Generating RTL for a Simple Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 5-11. Two-Stage Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Figure 5-12. Overall Flow of One-Stage Read and Write Pipelining . . . . . . . . . . . . . . . . . . 164
Figure 5-13. Pipelining Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 5-14. Pipelining Example — Register Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figure 5-15. Pipelining Example — Block Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figure 5-16. Pipelining Example — RTL Parameter Configurations . . . . . . . . . . . . . . . . . . 172

List of Figures

List of Tables
Table 2-1. Control File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Table 3-1. CSV Import Command in Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 3-2. IP-XACT Import Command in Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Table 3-3. JavaScript/Tcl Import Command in Control File . . . . . . . . . . . . . . . . . . . . . . . . 45
Table 5-1. UVM Output Command in Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Table 5-2. Project Parameter Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Table 5-3. Object Parameter Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Table 5-4. OVM Output Command in Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Table 5-5. HTML Output Command in Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 5-6. Mandatory Register Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Table 5-7. Mandatory Field Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Table 5-8. RTL Specific Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Table 5-9. Mandatory Block Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Table 5-10. Generic Bus Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Table 5-11. Common Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Table 5-12. Writing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Table 5-13. Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Table 5-14. RTL Output Command in Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Table 5-15. Read/Write Output Pulse Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Table 5-16. Register Definition CSV File for the Simple Design Example . . . . . . . . . . . . . 134
Table 5-17. Block Definition CSV File for the Simple Design Example . . . . . . . . . . . . . . . 134
Table 5-18. Parameter Definitions for the Simple Design Example . . . . . . . . . . . . . . . . . . 135
Table 5-19. Retention Registers — Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Table 5-20. Retention Registers — Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Table 5-21. Software Reset Input Example— CSV Columns . . . . . . . . . . . . . . . . . . . . . . . 152
Table 5-22. Byte Enable Mode — Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Table 5-23. Byte Enable Signal Name and Level— Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 156
Table 5-24. RTL Field Signal Naming and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Table 5-25. Pipelining Stages and Corresponding Flip-Flop and Mux Levels . . . . . . . . . . 164
Table 5-26. Pipelining Stage Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Table 5-27. Pipelining Mux and Decoder Size Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 166
Table 5-28. Pipelining Naming Convention Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Table 5-29. Parameters With Mandatory Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Table 5-30. C Header Output Command in Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Table 5-31. Parameters for Extra Include Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Table 5-32. Macros Generated for Software Access Modes . . . . . . . . . . . . . . . . . . . . . . . . 185
Table 5-33. Parameters for Read/Write Macro Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Table 5-34. Parameters for Block Struct Names and Pointer Names . . . . . . . . . . . . . . . . . . 186
Table 5-35. C Utility Code Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Table 5-36. Byte versus Word Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

List of Tables
Table 5-37. Word Addressability CSV Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Table 6-1. Supported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table 6-2. Parameters — Standard Method Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Table 6-3. Parameters — Standard Method Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Table 6-4. Parameters — Standard Method Example 2 (Continued) . . . . . . . . . . . . . . . . . . 215
Table 6-5. Parameters — Alias-Based Method Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Table A-1. Command Line Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Table C-1. Mapping Command Line Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Chapter 1
Register Assistant
Register Assistant is a register management tool that allows you to make changes to register
specifications in a single place and automatically generate/update a number of derived outputs.
A typical modern device contains a rich mix of hardware, firmware and software.
Communication between these domains is provided by software-addressable registers whose
locations are specified along with memories in a block. Communication between the members
of the different design teams may not be quite so structured.
Specifying registers and managing changes is typically a manual, laborious and error prone
task. What is required is a single repository to describe registers and memories for each
component, sub-system and system from which the output for all downstream activities
(hardware design, software/firmware development, verification and documentation) can be
generated.
This is not a new problem, project teams have been finding creative ways to address this
challenge for many years and therefore use a variety of formats for describing register and
memory information. With this in mind, Register Assistant can import register and memory
specifications from a variety of sources including IP-XACT, XML and spreadsheet (CSV)
formats into a cohesive, extensible data model describing a hierarchy of blocks, sub-blocks,
maps, registers, fields and memories.
Customizable DRC checks ensures consistency of the data and a full API allows custom input
translators and output generators to be added. The current release of Register Assistant
generates OVM and UVM register package SystemVerilog code for verification, HTML hyper-
linked documentation for communication and record keeping, synthesizable VHDL and Verilog
RTL code, plus C Header files.
Register Assistant Abstract Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Using Register Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Overview on Register Data Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Blocks, Blocks Maps, and Registers/Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Register Assistant Abstract Flow

Register Assistant operates and produces output based on a specific flow.
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Register Assistant
Register Assistant Abstract Flow
The main stages that comprise the Register Assistant flow are as follows:
1. Importing Register Data:

In this stage, you use Register Assistant to import your register definitions. Register
Assistant imports from a range of sources such as CSV files, IP-XACT XML format,
and Java Scrip/Tcl files. Refer to “Register Assistant Inputs” on page 31.
2. Checking the Imported Data:
Register Assistant runs a number of coherency checks to verify the correctness of the
imported data. For example, Register Assistant ensures that at least one top register
block is available.
Register Assistant provides a number of built-in default checks, but you can also define
your own custom checks if necessary.
Refer to “Checking Imported Registers” on page 55.
3. Generating Output:
The available generators in Register Assistant use the imported register data to create
various output types such as OVM/UVM register output for verification engineers and
HTML files for documentation purposes. Refer to “Register Assistant Output” on
page 69.
The commands related to all three stages are defined in a control file which is passed to the
Register Assistant. The control file contains the specific import, checks and output commands
that are to be executed by Register Assistant. That is to say, the control file contains the
commands that define the import method (such as CSV or JavaScript), the checks to be applied
Register Assistant
Using Register Assistant
(default and/or custom), and the output type required (such as UVM, OVM, RTL or HTML).
Refer to “Control File” on page 23 for more information.
Using Register Assistant

There are three modes for operating Register Assistant.
• Register Assistant can be run in batch using a control file. See “Control File” on
page 23.
• Register Assistant can be run directly using a wizard. See “Command Line Switches” on
page 219.
• Register Assistant can be run indirectly as a graphical interface add-on to other tools
such as HDL Designer Series. Refer to Using Register Assistant with HDL Designer
Series which can be accessed by opening Help > Help and Manuals in HDL Designer
Series.
Register Assistant
Overview on Register Data Hierarchy
Overview on Register Data Hierarchy

To extract data from the imported register definitions (whether imported from CSV, JavaScript
files, etc.), Register Assistant assumes that your register definitions are designed based on a
certain hierarchy or model.
The basic units of the hierarchy are: Registers, Memories, Register Blocks and Block Maps.
A register block may contain instances of registers, memories, or sub-blocks. Each register
contains any number of fields, which mirror the values of the corresponding elements in
hardware.
A register block can have more than one block map, but there should be at least one map.
It is important to note that Register Assistant checks the structure of the imported register data
to make sure that at least one top register block is available, and if not found, a failure occurs.
Note
The structure relying on register files (instead of blocks) and memory maps (instead of
block maps) is also valid. However, if you are generating UVM or RTL, Register Assistant
internally translates register files to sub-blocks and memory maps to block maps.
Blocks, Blocks Maps, and Registers/Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Blocks, Blocks Maps, and Registers/Memories

This section describes blocks, block maps, and block hierarchy, and the relationships between
them.
Blocks
Blocks are optional. If you have a “flat” description for your registers/memories, you can
simply use the Auto-Instance feature (see “Auto-Instancing” on page 50). This feature
automatically creates a top-level block based on your register/memory descriptions provided
that the address information is supplied for each register/memory definition.
Alternatively you can explicitly instantiate one or more registers or memories in a named Block.
Blocks can be used:
• To instance a set of registers/memories that is used repeatedly throughout a design. For

example, to represent each channel in a 32 channel DMA.
• To represent design structure (blocks can be instanced within other blocks in a
hierarchical manner).
Register Assistant
• To identify contiguous sections within the overall memory map.

Each block that you specify must also have one or more associated address map interfaces for
the content of the block. This is known as a Block Map. A given block map specifies which
registers/memories/sub-blocks are accessible together with their addresses as seen through the
block map. Block maps allow multiple processors to access different combinations of the same
registers/memories within a block but at different locations in the memory map.
It is common to define registers/memories in one CSV file and to specify blocks and block maps
in separate CSV files. Figure 1-1 shows the relationship between block maps, blocks, and
register/memory descriptions.
Figure 1-1. Block Maps, Blocks and Registers/Memories
Each block description requires three columns to be defined in your CSV input:
• Block Name — a name for the block. For each row of the block description, this name
repeats.
• Block Component Name — the name of the register, memory, or sub-block that is
instanced in this block. This name must match the register/memory/sub-block name that
you defined in your register/memory description columns. For example, if you define a
register called status_reg, the entry in the Block Component Name column is
status_reg.
• Block Instance Name — a unique identifier for the register/memory/sub-block in the
context of this block. Similar to instancing a component on a schematic, each register/
memory/sub-block instance within a block must have a name. For example, if you want
to add the status_reg to the block definition, you can name this register status_reg_h.
You can instance the same register/memory/sub-block multiple times using different
block instance names.
Register Assistant
In this example, there are three registers and one memory grouped in a block named reg_block:
You can define as many blocks as you require. However, when you define more than one block,
Register Assistant requires you to specify which block is considered the top block. When you
run the tool interactively, you will see a list of blocks that the tool has determined from your
input files. Select the block that you want to designate as the top block from the dropdown list.
In the following example, there are two blocks available and sw_top_block is the top block:
Block Maps
To use a block description, you need to define a block map. The block map defines a starting
address for each register/memory within the block. Block maps require four columns:
• Block Name — the name of the block that you have defined. This name repeats for each
register/memory/sub-block instance within the block that is accessible via this block
map.
• BlockMap Name — a name for the block map that you are defining. This name repeats
for each register/memory/sub-block entry in the block map.
• BlockMap Instance Name — the instance name that you defined for the register/
memory/sub-block instance (using the Block Instance Name column).
• BlockMap Instance Address — the starting address for the register/memory/sub-block
instance.
Register Assistant
In this example, we define the address space for the reg_block block:
Block Hierarchy
You can specify levels of block hierarchy, or sub-blocks, within your block specification. In this
example block description there is a top-level block called sw_top_block that contains two
instances of a block called sw_sub_block:
The example shows the use of the Block Instance Type of value block to indicate the two sub-
blocks whose instance names are sw1 and sw2. Those two instances reference a block called
sw_sub_block which is defined to contain six registers (that are defined in a separate CSV file),
starting on line 10.
For each block and sub-block, a corresponding block map is needed:
Register Assistant
In this example, we define the top-level block map in SW_MAP2 and the instance addresses for
each item in the block. Notice that in this case we explicitly reference the block map SW_MAP
for both instances of the sub-block using the path sw1.SW_MAP for the BlockMap Instance
Name. As each block can have any number of associated Block Maps, if you specify the
instance name alone (e.g. sw1) it will reference the default map for that sub-block. If you wish
to reference a specific map, you simply add the map name to the instance name (e.g.
sw1.SW_MAP).
The full CSV files for the preceding example can be found in <install_location>/examples/
uvm/CSV.
Relationship to Generation
Each generator utilizes the block and block map information that you provide:
• UVM — creates a UVM block class for each Block, with instances for each register/
memory instance. Declares the associated maps with the appropriate address
information from the Block Map.
• OVM — creates an OVM register map class for each Block with instances for each
register/memory instance.
• C Header — creates a struct for each block.
• RTL — generates a Verilog module or VHDL Entity/Architecture for each block.
• HTML — generates a hierarchical website based on the block hierarchy. The overall
address map is also generated.
Additional Block and Block Map CSV Columns
You can specify several optional CSV columns relating to blocks (please refer to CSV
Columns). Commonly used optional columns include:
• Block Description and Block Instance Description — add comments and

documentation about the blocks and instances within those blocks.
• UVM
o Block Coverage — allows you to specify one of the built-in coverage models for a
block. By adding a coverage model, such as UVM_CVR_ADDR_MAP, Register
Assistant generates cover groups and cover points for the block.
o Block Backdoor — allows you to specify a relative backdoor path for the registers/
memories within the block.
o Block Instance Backdoor — allows you to specify the starting instance name that
the backdoor path references.
o Block Instance Dimension — lets you specify how many instances of the register/
memory or sub-block to add in the block.
(This column also applies to the C Header generator.)
Register Assistant
Note
When you explicitly set the Block Instance Dimension as “1”, Register Assistant
generates this instance as an array of single element. Yet, when a value is not
specified for this column, Register Assistant generates one regular instance by
default (not an array).
o Block Instance Type — specifies the kind of instance in the block: register,
memory, or another block (sub-block). The default value is register.
o Block Replication Offset — if sub-block instances are not contiguous and you want
each instance of a sub-block to start on a specific boundary, you can specify a
Replication Offset. This allows you to specify the overall width of the block instance
(that is, the actual block size plus padding).
(This column also applies to the C Header generator.)
o Parameters — allows you to specify your own parameters to use in your own
generator or custom check. You can specify a block level parameter and value or an
instance-level parameter for each instance within a block.
• RTL — you can specify additional signals and information about those signals for the
RTL generator.
You can specify several optional CSV columns relating to block maps. Commonly used
optional columns include:
• BlockMap Description — allows you to add comments and documentation about the
block map.
• BlockMap is Default — indicates whether a particular block map is the default address
map for a block. If you only have a single block map, you do not need this column.
• BlockMap Address Offset — the address offset for the map (default is 0x0).
• BlockMap Instance Access — the software access mode for each register/memory
instance in the block map.
• Parameters — allows you to specify your own parameter to use in your own generator
or check.
Relationships Between Registers, Blocks, and Block Maps
This section summarizes the relationship between registers, blocks and block maps using a
simple example.
Register Assistant
We start by declaring three 32-bit, read-write registers at consecutive addresses:
The address information is required if we use the auto-instance mechanism, but for this example
we will explicitly instance these registers in a block so we add an instance of each register in a
block called sub_block:
We have now described the contents of a block called sub_block but we have not defined how a
bus interface can access these register instances or which of these instances are visible to that
specific interface. This address map information is specified using a Block Map.
In this simple case, we define a single map called SUB_MAP with corresponding address values
for each instance in the block:
Since we have associated the map SUB_MAP with the block sub_block, the addresses specified
in the map will be used rather than those specified in the register definitions. The generated
documentation for the address map looks like this:
Register Assistant
If we want to create hierarchy in our address map (perhaps to reuse the block multiple times) we
simply instance it in another block:
Here we have instanced block sub_block in a new parent block called top_block and specified
the instance type as block. We also need to make a corresponding map for the new block:
In the instance name we have explicitly stated that the instance of sub_block in the block
top_block is to use the SUB_MAP map and have specified the instance of the block starts at
address 100 hex. Therefore, when we generate from the perspective of the TOP_MAP we get the
following overall address map:
The offset addresses of the instances within SUB_MAP have been added to the address of the
parent map TOP_MAP to show the absolute addresses for the overall design.
Register Assistant
Chapter 2
Starting the Register Assistant Flow
The main elements of the Register Assistant flow—importing the register data, checking the
correctness of the data, and producing output—are communicated to Register Assistant through
a control file. The control file contains the commands related to each stage that Register
Assistant should implement.
Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Control File
The Control File is a text file containing all the information needed by the Register Assistant to
process the input (imported registers) and produce the output (such as UVM, OVM, RTL, and
HTML files).
When using the Register Assistant in batch mode, you have to write this file manually. When
using the Register Assistant via an interface such as HDL Designer Series, then this file can be
auto-generated based on user-defined settings. In the second case, you would still be able to edit
the auto-generated control file if necessary and re-use it.
Format
The control file is a simple text file in which each line represents either a generator to run (with
comma-separated information) or a comment as follows:
# <comment>
<generator_language>, <generator_name>[, <parameter>]*
Control File
The control file is usually divided into three main sections as shown in the following figure:
Figure 2-1. Control File
• Import Section — Contains the files names and locations from which the register data
shall be imported. Registers can be imported from several input sources such as CSV
files, IP-XACT XML format, or JavaScript and Tcl files. Your register data can be
distributed in files using more than one format.
Note
Note that you can write JavaScript and Tcl files using Register Assistant’s APIs to
import register data from any format you want, and also generate any type of output.
You can refer to the documentation of APIs on the path: <installation_folder>\

registerassistant\api\index.html.
• Checks Section — Contains the command which instructs the Register Assistant to
validate the imported register data.
This section shows whether you want to run the default built-in checks of the Register
Assistant, and also whether you want to run your own custom checks (which you have
written in a JavaScript or Tcl file). Refer to “Checking Imported Registers” on page 55
for more information.
• Output Section — Shows the type of output required to be generated by the Register
Assistant, such as OVM, UVM, RTL or HTML.
Control File
Syntax
The control file consists of either generators or comments. Generators are written in the syntax
explained in Table 2-1.
Table 2-1. Control File Syntax
Keyword Description Value
<generator_language> Specifies the language of js
the generator that will be tcl
used.
java
<generator_name> Specifies the name of the ovm
generator in case of using uvm
java. In case of using
JavaScript or Tcl, rtl
specifies the location of c_header
the script file.
check
addDefaultChecks
addScriptChecks
file_location/file_name.js
file_location/file_name.tcl
<parameter> Specifies additional For example, you may have a CSV
parameters required by JavaScript file which requires parameters
the generator. This is for the CSV files that will be imported. The
optional. example below shows the CSV files added
as parameters for the JavaScript file:
js, examples/csv.js, sw_top_block,
examples/uvm/csv/sw_regs.csv,
examples/uvm/csv/sw_blocks.csv
Control File
Note
* Any blank lines or white spaces in the control file are ignored.
* The control file accepts absolute paths, relative paths or environment variables. If a path is
relative, Register Assistant will resolve it relative to the control file’s location, then the project’s
location, then the current working directory.
* Register Assistant also understands two internal variables that can be used to refer to files
(either generators or arguments) in the control file: RA_HOME which indicates the path
<installation_folder>\registerassistant and RA_EXAMPLES which indicates the path
<installation_folder>\registerassistant\examples.
* You can add the following command when you want to auto-instance registers or memories in
a block: java, autoInstance, <block name>
Refer to “Auto-Instancing” on page 50.
* Generally, in the control file, when you specify optional parameters, you can use an empty
placeholder to signify that you want the default value used. For example:
java, ovm, myFile, , D:/projects/ovm
Usage
The syntax above can be applied in the control file as follows:
Import Section:
• The following command is used when you want to import register data from CSV files:
# Import registers using CSV Import
js, file_location/script_file_name.js, top block name,
file_location/register_data_file_name.csv, file_location/
block_data_file_name.csv
• The following command is used when you want to import register data from JavaScript
files:
# Import registers using programmatic creation by JS script
js, file_location/file_name.js
• The following command is used when you want to import register data from Tcl files:
# Import registers using TCL script
tcl, file_location/file_name.tcl
• The following command is used when you want to import register data from IP-XACT
XML:
# Import registers using IPXACTImport
js, file_location/file_name.js, top block name, file_location/
file_name.xml
Control File
When importing from IP-XACT, you can use the script provided in Register Assistant’s
examples folder on the path <installation_folder>\registerassistant\examples\ipxact.js.
Note
When importing from CSV or IP-XACT XML, make sure you specify the name of
the top block if you are using a hierarchy of blocks.
Note that you do not need to specify the top block’s name when you are using only a
single block as it will be automatically detected. For example:
js, file_location/script_file_name.js, , file_location/register_data_file_name.csv,
file_location/block_data_file_name.csv
Checks Section:
• The following command must be used in order to run any checks in general (whether
default or custom):
# Run checks
java, check
When an error is found during the check, the flow stops. You can add the “dontStop”
option in order to continue the flow:
# Run checks
java, check, dontStop
The above command must be used in order for Register Assistant to run the “check”
generator. Subsequently, you will have to specify whether you want to run the default
and/or custom checks.
• The following command is used to add Register Assistant’s default checks:
# Add default checks
java, addDefaultChecks
• The following command is used to add custom checks using JavaScript:

# Add custom checks
• The following command is used to add custom checks using Tcl:

# tcl checks
java, addScriptChecks, file_location/file_name.tcl
Control File
Output Section:
• The following command is used to generate the UVM output:

# Generate UVM output
java,uvm, generated_file_name, UVM_Register_Package_Version,
UVM_Output_Directory
Register Assistant supports UVM register package version 1.0 and 1.1. If you do not
specify the version in the control file, Register Assistant uses 1.1 by default.
Note
You have the ability to define a specific path for the generated UVM output. If not
specified, the default Register Assistant project location will be used. The default
project location is the path specified by the -project command if you are using Register
Assistant in batch mode, or the project path of the host application if you are using
Register Assistant through an interface tool (such as HDL Designer Series). This applies
to all the following output generators as well.
• The following command is used to generate the OVM output:

# Generate OVM output
java,ovm, generated_file_name, OVM_Register_Package_Version,
OVM_Output_Directory
If you do not specify the generated file’s name, the file is given the default name
<project’s name>_pkg.sv.
Also, Register Assistant supports OVM register package version 1.0, 2.0 and 2.2. You
can specify which version you want to use. If the version number is not specified,
Register Assistant uses 2.2 by default. If you want to use version 1.0 or 2.0, you will
have to manually set it in your control file.
Examples:
The following example specifies the file name, the version, in addition to the output
directory of the generated OVM.
java, ovm, myFile, 1.0, D:/Projects/Project_Temp_lib/ovm_files
The following example specifies the file name and the output directory of the generated
OVM, but does not specify the version number, and hence the default version 2.2 will be
used in generation.
java, ovm, myFile, , D:/Projects/Project_Temp_lib/ovm_files
The following example specifies the version but does not specify the file name, and
therefore the default file name <project’s name>_pkg.sv will be used.
Control File
java, ovm, , 2.0, D:/Projects/Project_Temp_lib/ovm_files
The following example neither specifies the file name nor the version nor the output
directory, and therefore the default file name <project’s name>_pkg.sv, default version
2.2, and default project location will be used.
java, ovm
• The following command is used to generate RTL files:

# Generate the RTL
java, rtl, RTL_Output_Directory
• The following command is used to generate HTML files:

# Generate all possible HTML Outputs
js, file_location/file_name.js, HTML_Output_Directory
When generating HTML, you can use the script provided in Register Assistant’s
examples folder on the path <installation_folder>\registerassistant\examples\html.js.
• The following command is used to generate C Header files:
# Generate C Header
java, c_header, generated_file_name, C_Header_Output_Directory
Control File
Examples
# Import CSV example using CSV Import

js, examples/csv.js, sw_top_block, examples/uvm/csv/sw_regs.csv,

java, addScriptChecks, examples/checkMap.tcl
js, examples/checks.js
# Run checks
#java, check, dontStop
java, check

java,uvm,my_uvm_file, , ,D:/Projects/Project_Temp_lib/uvm_files

js, examples/html.js, D:/Projects/Project_Temp_lib/html_files
This example will be translated by Register Assistant as follows:
Import Section: The above control file imports register data from CSV files. The name of the
top block is “sw_top_block”.
Checks Section: This control file requires the validation of the register data by running the
default checks and also running custom checks referenced in the file examples/checks.js. If any
error is reported during validation, the flow will stop (since the “dontStop” option is commented
as shown above).
Output Section: The Register Assistant should produce two types of output: UVM register
package and HTML documentation. The generated UVM file’s name will be my_uvm_file.sv.
The generated output should be placed on the following paths D:/Projects/Project_Temp_lib/
uvm_files and D:/Projects/Project_Temp_lib/html_files.
Related Topics
Register Assistant Inputs
Register Assistant Output
Checking Imported Registers
Auto-Instancing
Chapter 3
Register Assistant receives certain inputs (register definitions), runs a number of checks to
verify that the input is correct, and then produces the required output (such as HTML, RTL or
OVM output).
This chapter details the register definition input types supported by Register Assistant.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Importing Data From CSV Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
CSV Import Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Importing Data From IP-XACT XML Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
IP-XACT Import Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Importing Data from Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Setting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Importing From Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Auto-Instancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Introduction
The register definitions can be delivered to Register Assistant in the following formats: CSV,
IP-XACT XML format, or JavaScript/Tcl.
• First of all, you have to identify which format to use.
• Depending on the format you choose, you must write an intermediary script file that
communicates with Register Assistant and delivers the register data. You have to make
sure that your register data is ready and available as described in your script.
Introduction
• You need to pass the script and the data files to the Register Assistant via a control file.
Tip
: Before generation, make sure that any instance of any object in the input files has a
definition. Otherwise, an error is raised during generation if the definition is missing.
Note
When defining register input, be informed that Register Assistant defaults the addressable
width to 8 bits. So for a 32 bit register width, the addresses increment by 4 Hex. e.g. 00, 04,
08, 0C etc.
Importing Data From CSV Files
Importing Data From CSV Files

To import CSV files, you have to prepare your CSV files which contain the register data.
In addition, you also have to write the following command in the control file to pass the script
file and the CSV files to Register Assistant:
# <comment>
<generator_language>, <generator_name>, <top block/main memory map name>,
<parameter>
For example:

This example can be interpreted as follows:

Table 3-1. CSV Import Command in Control File
Keyword Equivalent in Description
Example
<generator_language> js The language of the import generator.
<generator_name> examples/csv.js The location of the JavaScript file.
<top block/main memory sw_top_block The name of the top block/main memory
map name> map which you specify when generating
UVM/OVM.
If you are generating UVM/OVM, then
specify the top block’s/memory map’s name
when using a hierarchy of blocks. Refer to
“Control File” on page 23.
<parameter> examples/uvm/csv/ The location of the CSV files (containing the
sw_regs.csv, register data) which will be referenced by
examples/uvm/csv/ the import generator.
sw_blocks.csv
Note that you can specify your CSV files in
any order and Register Assistant will
automatically order the files during import.
CSV Import Script File
Note
If you are using Register Assistant in batch mode, then you have to write the above
command manually in the control file. If you are using Register Assistant through an
interface tool such as HDL Designer Series, you will be able to enter your import, checks and
output settings through the interface and then the control file will be auto-generated. Refer to
“Control File” on page 23for further information.
After preparing your CSV files, you create a script to basically map the columns in your CSV
files to the columns of Register Assistant. That is to say, this script helps Register Assistant
recognize the columns in your CSV file. An example script is available with Register Assistant
on the path <installation_folder>\registerassistant\examples\csv.js. You can simply create a
copy of this script and modify the column mapping section to fit your standards (using Register
Assistant’s API commands which you can find on the path <installation_folder>\
registerassistant\api\index.html).
For example, you may need to change the default column name “Register Name” to “Register
Title”, in that case you can change the following line of code.
From:
colMapping.put("Register Name", CSVImport.COLUMNS.regName); //The name for

the register.
To:
colMapping.put("Register Title", CSVImport.COLUMNS.regName); //The name

for the register.
This means that “Register Title” is the new column name corresponding to the Register
Assistant object name “regName”.
Finally, you have to reference the script along with your CSV files in the control file.
See “CSV Import Script File” on page 34for more details on the script and its content.

A JavaScript file is required by Register Assistant in order to identify the content of your CSV
files. This script mainly maps the CSV column headings you use into Register Assistant via API
commands.
An example file is available on <installation_folder>\registerassistant\examples\csv.js. You
can copy this file and modify its content to suit your needs; the file contains elaborate
description of its sections and how it can be modified.
Format
The file is basically composed of several sections as shown in the following figure:
Figure 3-1. CSV Import Script File
• Imports — Contains the imports required for the script. The below imports can be used:
o The following import is used to support any calls made to Register Assistant’s data
model. This import is mandatory.
importPackage(com.mentor.regassist.dm);
o The following import is required to be able to run the CSV import utility in Register
Assistant. This import is mandatory.
importClass(com.mentor.regassist.generator.CSVImport);
o The following import is required to be able to communicate with the generator

utility. This import is mandatory.
importClass(com.mentor.regassist.generator.GeneratorUtil);
o The following import is used to be able to print log messages, whether status or error
messages. This import is optional.
importClass(com.mentor.svassist.common.util.EcLog);
Note that any messages will appear in the console of Register Assistant. If you are
using Register Assistant through an interface tool such as HDL Designer Series, then
the messages will appear in a log tab for that tool.
o The following import is used to support the definition of column formats, that is the
column name mapping, of the imported CSV files. This import is optional.
importClass(java.util.HashMap);
If you are using the default column names (see the example script on
<installation_folder>\registerassistant\examples\csv.js), then you do not have to
define any column mappings in this file.
• Generate Method — The Generate method is obligatory in the script. It encases the
entire code in the script as follows:
function generate(project, object, params) {
<code>
...
return 0;
}
This method enables you to detect any errors and stop the flow at an early stage. This
can be done within the script by returning a negative integer at any time to indicate that
an error has occurred, and consequently the flow will stop. See the following example:
if (params == null || params.size() < 2) {
EcLog.error("CsvImporter : Missing required parameter 'csvFile'" +
params);
return -1;
}
If the Generate method is missing in the script, an error is raised as in the following
example:
# Error: Error executing javascript generator 'D:\RA\examples\
csv.js', missing generate method.
• Defining Column Mappings

Register Assistant recognizes the columns in the CSV files using the mappings in the
csv.js file you supply.
The example script file shipped with Register Assistant “csv.js” available on
<installation_folder>\registerassistant\examples\csv.js contains the default column
names that can be used to define register data (registers, memories, blocks, etc.) and the
corresponding object names as they are found in Register Assistant’s data model.
If you are using column names different from the default, you can copy this example
script and modify it. For example, you may be using the column “Register Title” instead
of “Register Name”, so you have to map this column name to the object “regName”
already found in the example script (which is the corresponding object to map to in
Register Assistant’s data model).
See the following example:
colMapping.put("Register Title", CSVImport.COLUMNS.regName); //The
name for the register.
You can also refer to the CSV Columns table which contains a list of Register Assistant’s
default column names. It shows a description for each column, whether it is mandatory
or optional, and so on.
Note that when Register Assistant parses the csv.js file you supply, a message is raised
in the following cases: when a mandatory column is not found, or when any column is
not matched to the objects in Register Assistant’s data model.
You can also refer to the APIs’ documentation on the path <installation_folder>\
Notes:
o Column names are case insensitive and also white space insensitive. For example,
“register name”, “RegisterName”, “REGISTER NAME” will all match the column
“Register Name”.
o When using the Block Instance Backdoor column in the CSV input files, if you want
to set a backdoor path for an array with a different path for each instance in the array,
you can use the %(DIM) variable.
If used, the following code is generated (in this example the backdoor path is set as
“data_small_mem_h_array_%(DIM)_local”):
foreach ( small_mem_h[i] ) begin
small_mem_h[i] =
small_mem::type_id::create($psprintf("small_mem_h[%0d]", i));
small_mem_h[i].configure(this, null,
($psprintf("data_small_mem_h_array_%0d_local", i)));
small_mem_h[i].build();
end
If not used, the following code is generated (in this example the backdoor path is set
as “data_small_mem_h_array_local”):
foreach ( small_mem_h[i] ) begin
small_mem_h[i] =
small_mem::type_id::create($psprintf("small_mem_h[%0d]", i));
small_mem_h[i].configure(this, null,
“data_small_mem_h_array_local");
small_mem_h[i].build();
end
This is applicable to the UVM generator only.

You can refer to the OVM/UVM Variables table for information on the %(DIM)
variable.
• Matching Access Type — In this section, you point out the strings equivalent to each
access type used in the CSV input files. For example, you may need to indicate that
finding the string “RO” in the imported register data indicates that the register is read-
only.
This takes place through a “match” function as in the following example:

function match(access, name, map) {
switch (access.toUpperCase()) {
// READ-WRITE
case "READ-WRITE":
case "RW":
return RAAccessType.READ_WRITE;
// READ-WRITE-Queued
case "READ-WRITE-QUEUED":
case "RWQ":
return RAAccessType.READ_WRITE_QUEUED;
...
...
// DEFAULT IS READ WRITE, if access is not already defined

as is
default:
var acc = RAAccessType.getValue(access);
if (acc == null) {
var type = map.get("objectType");
var msg = " '"+name+"' has invalid Access type '"+access+"'
";
if (type != null) {
msg = type + msg;
}
EcLog.error(msg);
}
return acc;
}
Refer to <installation_folder>\registerassistant\examples\csv.js to view an example

CSV script containing the “match” function.
Specifying the software and hardware access mode for the register is important to
determine the behavior of the register. You can refer to the S/W Access Modes table and
the H/W Access Modes table for a list of supported access modes.
Note the following:
o If the software or hardware access mode of the register is not detected, Register
Assistant will use the default access mode “read-write”.
o You can also specify the software and access mode for the fields within the registers.
Note that if the field’s software access mode is not specified, Register Assistant will
use the value of the register’s software access mode. Similarly, if the field’s
hardware access mode is not specified, Register Assistant will use the value of the
register’s hardware access mode.
o If you do not explicitly define fields within the register in the input files, Register
Assistant creates a single field by default in the generated output covering the entire
register. This default field takes the same software and hardware access modes of the
register.
• Verifying Parameters — In this section, a check is performed to ensure that the
parameters exist (that is, the CSV files containing the register data which are specified in
the control file).
• Initializing Variables — In this section, a variable is initialized with the top block/main
memory map. (This is needed when identifying the top block/main memory map later.)
• Actual Import from CSV Files — This section contains the call to the CSV Import
API; this is where you run the actual import of data from the CSV files. For example:
var result = CSVImport.importAllRegistersFromCSV(project,
colMapping, params, match, true);
• Identifying the Top Block/Main Memory Map— This section specifies the top block/
main memory map. This is required in order for the output to generate correctly.
Tip
: If there is a row in a CSV file that does not have a Register Name or that is
completely empty, then the whole row will be ignored by Register Assistant. If only
the Register Name is available in the row, then it will be added to the project.
Example
To view an example CSV import script file, refer to the example available with Register
Assistant on <installation_folder>\registerassistant\examples\csv.js.
You can also refer to the documentation of Register Assistant’s APIs on the path:
<installation_folder>\registerassistant\api\index.html.
Importing Data From IP-XACT XML Files
Importing Data From IP-XACT XML Files

In addition to importing from CSV files and scripts, you can import register definitions from
XML files written in the IP-XACT schema. Register Assistant supports IEEE Std 1685-2009
for IP-XACT.
To import from IP-XACT, you have to write the following command in the control file to pass
the XML files to Register Assistant:
# <comment>
<generator_language>, <generator_name>, <top block/main memory map name>,
<parameter>
For example:
# Import IPXACT example using IPXACTImport

js, examples/ipxact.js, stopwatch_memory_map, examples/ovm/ipxact/
stopwatch_ipxact14.xml

Table 3-2. IP-XACT Import Command in Control File
Keyword Equivalent in Example Description
<generator_language> js The language of the import generator.
<generator_name> examples/ipxact.js The location of the intermediary script
file.
<top block/main stopwatch_memory_map The name of the top block/ main
memory map name> memory map. Specify the top block’s/
main memory map’s name when using
a hierarchy of blocks/memory maps.
This is not necessary when using a
single block/memory map as it will be
automatically detected by Register
Assistant during the import. Refer to
“Control File” on page 23.
<parameter> examples/ovm/ipxact/ The location of the XML file
stopwatch_ipxact14.xml (containing the register data) which will
be referenced by the import generator.
IP-XACT Import Script File
Note
Note that if you are using Register Assistant in batch mode, then you have to write the above

To import from IP-XACT XML files, you need to have an intermediary JavaScript file that
communicates information between the XML files and Register Assistant.
An example script is found on <installation_folder>\registerassistant\examples\ipxact.js. You
can use this example script as it is without any changes required.
Format
The script is basically composed of several sections as shown in the following figure:
Figure 3-2. IP-XACT Import Script File
o The following import is required to be able to run the IP-XACT import utility in
Register Assistant. This import is mandatory.
importClass(com.mentor.regassist.generator.IPXACTImport);
o The following import is required to be able to communicate with the generator

utility. This import is mandatory.
<code>
...
return 0;
}
an error has occurred, and consequently the flow will stop. See the following example:
if (params == null || params.size() < 2) {
EcLog.error("IPXACTImporter : Missing required parameters 'js,
ipxact.js, memMapName, xmlFile'" + params);
return -1;
}
example:
ipxact.js', missing generate method.
• Verifying Parameters — In this section, a check is performed to ensure that the

parameters exist (that is, the top block/main memory map name and the path of the
XML file which are defined in the control file).
• Initializing Variables — In this section, variables are initialized with the top block/
main memory map name and the path of the XML file.
• Actual Import from IP-XACT XML File — This section contains the call to the IP-
XACT Import API; this is where you run the actual import of data from the XML file.
• Identifying the Top Block/Main Memory Map Instance — This section specifies the
top block/main memory map and adds it to the project. This is required in order for the
output to generate correctly.
Example
To view an example IP-XACT import script file, refer to the example available with Register
Assistant on <installation_folder>\registerassistant\examples\ipxact.js.
Importing Data from Scripts
Importing Data from Scripts

In addition to importing register data from CSV files and IP-XACT XML format, Register
Assistant can import register data directly from scripts. This is particularly useful in specific
cases when you are using formats other than CSV or IP-XACT XML to define registers (such as
Adobe FrameMaker and text files).
In that case, you will still be able to import your register data by defining your registers in a
JavaScript or Tcl file using the API commands provided by Register Assistant. In other words,
you can write your own reader scripts to communicate register definitions from whichever
format you are using to Register Assistant.
Subsequently, you have to write the following command in the control file to pass the script file
to Register Assistant:
# <comment>
<generator_language>, <generator_name>
For example:
# Import Stopwatch example using programmatic creation by JS script

js, examples/ovm/api/sw.js
Or:
# Import Stopwatch example using TCL script

tcl, examples/ovm/api/sw.tcl
These examples can be interpreted as follows:

Table 3-3. JavaScript/Tcl Import Command in Control File
<generator_language> js The language of the import
tcl generator.
<generator_name> examples/ovm/api/sw.js The location of the script file.

examples/ovm/api/sw.tcl
Note
Import Script File
Import Script File

You can use Register Assistant’s APIs to construct blocks, sub-blocks, register definitions, and
fields directly in a JavaScript or Tcl file.
This section describes the content of a JavaScript file, and then provides examples of a
JavaScript and Tcl file that have the same register definitions.
You can find information on Register Assistant’s APIs on the path <installation_folder>\
Import Script File
Format
The below file is basically composed of several sections as shown in the following figure:
Figure 3-3. JavaScript Import File
Import Script File
• Imports — Contains the imports required for the script. The below import can be used:
<code>
...
return 0;
}
an error has occurred, and consequently the flow will stop.
example:
sw.js', missing generate method.
In case of Tcl scripts, you can just include a return statement returning a negative
number, for example:
if {$result == false} {
return -1
• Creation of Register Objects — In this section, you create objects within your project
for registers, memories, blocks.
You can also create objects for fields within their corresponding registers.
• Instantiation of Register Objects — In this section, you create instances from your
objects according to the hierarchy of register data. For example, you may need to
instantiate registers in sub-blocks or instantiate sub-blocks in the top block. (Refer to
“Overview on Register Data Hierarchy” on page 14).
Refer to “JavaScript/Tcl Import File Example” on page 221 to view sample JavaScript and Tcl
files. You can also refer to the documentation of Register Assistant’s APIs on the path:
Setting Constraints
Setting Constraints
You can set constraints on your imported register definitions. For example, you may need to
ensure that value X related to object Y is not greater than 10. These constraints are
SystemVerilog constraints.
Any added constraints will be inserted in the generated output, such as OVM, UVM or HTML.
Later when running simulation, the simulator will take the constraints in the generated OVM/
UVM file into consideration to make sure they are fulfilled.

Importing From Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Importing From CSV Files

When importing from CSV files, you will be able to apply constraints to fields, registers, and
memories. Constraints cannot be applied to blocks or block maps.
Procedure
1. Add a column in the CSV file for the required object (registers, fields or memories)
using the following default column names respectively: Register Constraints, Field
Constraints, or Memory Constraints.
2. Write the code of the constraints in the column using SystemVerilog language.
This code will be added as it is in the generated OVM/UVM output later. As for the
generated HTML, the added constraints will be displayed for the corresponding objects.
For example:
constraint my_constraint
{x < 5;}
3. If you are using a column name different from the default, make sure you map the
column name in your csv.js import file as follows:
For registers:
colMapping.put("Your Column Name",
CSVImport.COLUMNS.regConstraints); //Constraints for the register.
For fields:
colMapping.put("Your Column Name", CSVImport.COLUMNS.fConstraints);
//Constraints for the field.
Importing From Scripts
For memories:
colMapping.put("Your Column Name",
CSVImport.COLUMNS.memConstraints); //Constraints for the memory.
Importing From Scripts

If you are importing register definitions from scripts, whether JavaScript or Tcl, you will be able
to apply constraints by using set/get APIs.
The following example illustrates a JavaScript file in which constraints are set on a block:
project.getBlocks("block").setConstraints("constraint c_block1
{dummy1} \n constraint c_block2 {dummy2}");
return 0;
}
For information on the supported APIs, refer to the APIs’ documentation on the path
Auto-Instancing
Auto-Instancing automatically instances registers/memories in a new or existing top-level block
and creates a corresponding block map. This provides a rapid way to create the required block
structure from a “flat” list of registers and memories. Auto-instancing requires register
addresses to be specified with the register/memory definitions.
The auto-instancing feature can be used with any import method, such as CSV, JavaScript or
IP-XACT, and can be used when generating UVM, OVM, RTL and/or HTML output.
Note
This feature is automatically enabled for IP-XACT.
To automatically create instances, you have to add the following command in the control file:
java, autoInstance, <block name>, 1
It is important to make sure that you add this command within the control file after the import
commands and before the generation commands.
Auto-Instancing
The last argument following the <block name> enables you to use register definition names for
instances. It takes a value of 1or 0. If set to 1, which is the default value, register declaration
names are used for instances and declarations are renamed to “<reg_decl_name>_reg” in the
generated code. If set to 0, register instances are generated using the following convention
ins_<reg_name>.
In the auto-instancing command, in case you provide the name of a block that does not exist in
the imported definitions, Register Assistant will automatically create a block with the same
name in the generated output and make it the top block, and then create instances of the register
definitions within that block.
Example
The following example shows a control file which adds instances for imported registers in a
block titled “my_top_Block”.

js, $(RA_EXAMPLES)/csv.js, , $(RA_EXAMPLES)/ovm/csv/sw.csv,

js, $(RA_HOME)/examples/checks.js
# Run checks
java, check
# Create & AutoInstance in my_top_block

java,autoInstance, my_top_Block, 0

java,ovm, csv_example, ,D:/Projects/Project_Temp_lib/ovm_files

java,uvm, csv_example_uvm, , , D:/Projects/Project_Temp_lib/uvm_files

js,$(RA_EXAMPLES)/html.js, D:/Projects/Project_Temp_lib/html_files
Below is an excerpt of UVM output generated for CSV input that only contained the definitions
of registers. As shown below, a new top block titled “my_top_Block” is automatically created
(this block was not defined in the input files) and it contains instances of the imported registers.
Auto-Instancing
/* BLOCKS */
//--------------------------------------------------------------------
// Class: my_top_Block
//--------------------------------------------------------------------
class my_top_Block extends uvm_reg_block;

ùvm_object_utils(my_top_Block)
rand stopwatch_value inst_stopwatch_value; // Current value

rand stopwatch_reset_value inst_stopwatch_reset_value; // Reset value
rand stopwatch_upper_limit inst_stopwatch_upper_limit; // Upper limit
rand stopwatch_lower_limit inst_stopwatch_lower_limit; // Lower limit
rand stopwatch_memory inst_stopwatch_memory; // Memory register
rand stopwatch_csr inst_stopwatch_csr; // Control Status Register
rand stopwatch_counter inst_stopwatch_counter; // Stop Watch Counter
uvm_reg_map my_top_Block_map;
// Function: new
//
function new(string name = "my_top_Block");
super.new(name, UVM_NO_COVERAGE);
endfunction
// Function: build
//
virtual function void build();
inst_stopwatch_value =
stopwatch_value::type_id::create("inst_stopwatch_value");
inst_stopwatch_value.configure(this);
inst_stopwatch_value.build();
inst_stopwatch_reset_value =
stopwatch_reset_value::type_id::create("inst_stopwatch_reset_value");
inst_stopwatch_reset_value.configure(this);
inst_stopwatch_reset_value.build();
inst_stopwatch_upper_limit =
stopwatch_upper_limit::type_id::create("inst_stopwatch_upper_limit");
inst_stopwatch_upper_limit.configure(this);
inst_stopwatch_upper_limit.build();
inst_stopwatch_lower_limit =
stopwatch_lower_limit::type_id::create("inst_stopwatch_lower_limit");
inst_stopwatch_lower_limit.configure(this);
inst_stopwatch_lower_limit.build();
inst_stopwatch_memory =
stopwatch_memory::type_id::create("inst_stopwatch_memory");
inst_stopwatch_memory.configure(this);
inst_stopwatch_memory.build();
inst_stopwatch_csr =
stopwatch_csr::type_id::create("inst_stopwatch_csr");
inst_stopwatch_csr.configure(this);
inst_stopwatch_csr.build();
Auto-Instancing
inst_stopwatch_counter =
stopwatch_counter::type_id::create("inst_stopwatch_counter");
inst_stopwatch_counter.configure(this);
inst_stopwatch_counter.build();
my_top_Block_map = create_map("my_top_Block_map", 'h0, 4,

UVM_LITTLE_ENDIAN, 1);
default_map = my_top_Block_map;
my_top_Block_map.add_reg(inst_stopwatch_value, 'h0, "RW");

my_top_Block_map.add_reg(inst_stopwatch_reset_value, 'h4, "RW");
my_top_Block_map.add_reg(inst_stopwatch_upper_limit, 'h8, "RW");
my_top_Block_map.add_reg(inst_stopwatch_lower_limit, 'hc, "RW");
my_top_Block_map.add_reg(inst_stopwatch_memory, 'h10, "RW");
my_top_Block_map.add_reg(inst_stopwatch_csr, 'h30, "RW");
lock_model();
endfunction
endclass
Auto-Instancing
Chapter 4
After importing the register definition files, the Register Assistant performs a number of
coherency checks on registers to identify any incorrect data. This chapter explains how Register
Assistant can apply coherency checks to imported register definitions.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Default Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Custom Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Running Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Running Custom Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Introduction
After importing the register definition files, the Register Assistant performs a number of
coherency checks on registers to identify any incorrect data. These checks are used to validate
different aspects, such as ensuring that mandatory information on each register is provided,
ensuring that each interrupt has a corresponding mask, and so on.
Register Assistant provides a set of default checks, yet you have the ability to apply your own
custom checks if necessary.
Default Checks
Register Assistant identifies whether coherency checks (default or custom) should be applied or
not through the control file. So, you have to provide the necessary instructions in the control file
in order for Register Assistant to run the checks on the imported registers.
This chapter covers the following topics:
• Default Checks — gives examples of the default checks of Register Assistant.

• Custom Checks — explains how custom checks can be accomplished through scripts,
provides the basic format of the file and also an example checks JavaScript and Tcl file.
• Running Checks — shows how to turn on checks in the control file, whether default
checks or custom checks, and also provides an example control file with the checks-
related section highlighted.
These topics can be also illustrated through the following flow:
Default Checks
The Register Assistant includes a number of built-in checks by default. The following are
examples of checks that Register Assistant supplies.
• Important Attributes — Checks that mandatory data is provided correctly for the
registers such as the Register Name, Register Address Offset and Field Name. This also
applies to the Memory Name, Address Offset and Range.
• Address Overlap — Checks that no registers in the top level map overlap in addresses.
This also applies to memories.
Default Checks
Note that if you choose to generate C Header files, this check ensures that the block
replication offset is not smaller than the actual size of the block.
• Reset Values — Checks that all registers have valid reset values defined, whether on the
registers or fields, and that the reset values completely fill the registers. This also applies
to memories. If a violation for this check occurs, the flow will stop; but in case the
register is write-only, a warning will be raised instead (since a write-only register is not
required to have a reset value).
Note
You do not have to specify register reset values if all the fields have reset values and
vice-versa.
• Top Block Availability — Checks that at least one top register block is available, and if
not found, a failure occurs.
• Unique Names — All definition names should be unique: registers, memories, sub-
blocks, and blocks. Within a block or a sub-block, all instance names should be unique.
Within a Register, all field names should be unique. Within a register block, all map
names should be unique.
• Object Names — Checks that instances have valid definitions and that object names are
valid strings and valid identifiers.
• Field Value Width — Verifies that field values can fit within their defining fields.
• Register Field Access Mismatch — Checks that the register access and its field access
are compatible. This check fails in the following conditions:
o Register RO, field RW or WO
o Register WO, field RW or RO
Note
The checks operate on instances, so if there is a violation in the definition and it
is instantiated more than once, the same error can be reported many times. If a
definition is not instantiated, no violations will be reported.
The generator runs the checks, but if a violation occurs, the flow stops by default. You can
choose to continue the flow even if a check reports errors by setting the “dontStop” option. See
“Running Checks” on page 62.
Related Topics
Running Default Checks
Custom Checks
Custom Checks
You can define your own custom checks using the JavaScript or Tcl language. Later, you can
refer to your script file in the control file, so that the Register Assistant would run your custom
checks.
Checks Script File

This section explains the basic content of a custom checks file written in JavaScript.
See “Examples” on page 64 for examples on both JavaScript and Tcl files.
Checks Script File
Format
The file is composed of three sections as shown in the following figure:
Figure 4-1. Checks Script File
Checks Script File
o The following import is used to support any calls made to Register Assistant to
obtain certain register information (that is, the information that will be used by the
check function). This import is usually required.
o The following import is required to be able to add the check function to the list of
checks that Register Assistant should run. This import is mandatory.
importClass(com.mentor.regassist.generator.RACheckerManager);
o The following import is used to be able to print log messages related to the applied
checks, whether status or error messages. This import is optional.
Note that such messages will appear in the console of Register Assistant. If you are
• Check Function — Contains all the custom checks that should be applied to the
imported registers. This is the core of the file.
In this section, the function name must be “check” and it takes the “project” instance as
an argument. The “project” instance refers to the current project you are working on.
function check(project) {
...
...
}
If this function returns a negative number, this signifies that the check failed, otherwise
it means that the check passed.
Note
If a failure occurs, the check will stop. To prevent this, you have to set the
“dontStop” option in the control file. Refer to “Running Checks” on page 62.
• Adding the Check Function — In this section, you should add the check function to
the “RACheckerManager” class, so that it would be added to the set of checks that
Register Assistant applies to the imported registers.
RACheckerManager.addCheck(check);
return 0;
}
Checks Script File
Note how the check function is written inside a “generate” function. The generate
function enables you to detect any errors and stop the flow at any point. This can be
done within the script by returning a negative integer at any time to indicate that an error
has occurred, and consequently the flow will stop.
Note
In case of Tcl scripts, you can just include a return statement returning a negative
number, for example:
if {$result == false} {
return -1
Refer to “Examples” on page 64 to view samples of checks JavaScript files and also Tcl files.
Related Topics
Running Custom Checks
Running Checks
Running Checks
To run checks as part of the register import-generate flow, the check operation must be forced
through the control file. This takes place by adding the “check” generator in the control file as
follows.
# Run checks
java, check
The generator runs the checks, but if a violation occurs, the generator stops by default. You can
choose to continue the flow even if a check reports errors by setting the “dontStop” option as
follows:
# Run checks
Subsequently, you have to specify in the control file whether you will run default checks and/or
custom checks. Refer to “Running Default Checks” on page 62 and “Running Custom Checks”
on page 63.

Running Custom Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Running Default Checks

You have to specify whether you want to run the Register Assistant’s default checks or not. This
takes place through the control file, which communicates all generation instructions to the
Register Assistant.
Batch Mode
If you are using the Register Assistant in batch mode, then you have to manually force the
default checks in the control file. You have to add the following lines in the control file:

# Run checks
java, check
Refer to the “Control File” on page 23 for further details.
GUI Mode
If you are using any interface to the Register Assistant (such as HDL Designer Series), then you
have to set the run built-in checks option in the import register settings. By that, the auto-
generated control file will automatically contain the necessary instructions to run the default
checks.

In order to run your own custom checks, you have to reference the script file containing your
checks in the control file.
Referencing a JavaScript file takes place as follows:
# Add custom checks

# Run checks
java, check
An example file is available on the path <installation_folder>\registerassistant\examples\

checks.js.
Tip
: This example file applies the “full field definition” check which checks that the fields
within a register fully cover the register width. That is to say, this check ensures that if a
register has fields, then the fields cover all the register bits, and that all the bits are assigned to
fields.
Referencing a Tcl script file takes place as follows:
# tcl checks
# Run checks
java, check
An example file is available on the path <installation_folder>\registerassistant\examples\

checkMap.tcl.
Tip
: When you run Register Assistant through an interface tool such as HDL Designer Series,
setting the run built-in checks option in the import register settings will run the default
checks mentioned in the section “Default Checks” on page 56 in addition to the example
checks.js and CheckMap.tcl files mentioned above. If you are writing the control file manually,
then you can manually reference these files if needed.
Examples
Example Control File With Checks

Check the following control file example:

# tcl checks

# Add custom checks
# Run checks

java,uvm, my_uvm_file, , , D:/Projects/Project_Temp_lib/uvm_files

js, examples/html.js, D:/Projects/Project_Temp_lib/html_files
As shown in the above underlined lines, this control file runs checks as part of the flow. It runs
the default built-in checks of the Register Assistant and it also runs custom checks defined in the
JavaScript file examples/checks.js and the Tcl checks defined in the file examples/checkMap.tcl.
Also, the control file stipulates that any errors found will not stop the flow.
Examples
The following examples show various usages of the checks file. Example JavaScript and Tcl
files are available on <installation_folder>\registerassistant\examples\checks.js and
<installation_folder>\registerassistant\examples\checkMap.tcl.
Example 1 — Checks JavaScript File

This example checks that fields cover all the bits of the register. That is to say, if there are any
bits that are undefined through fields, an error is raised.
Examples
/* Check that registers with fields are fully defined with fields */
EcLog.log("Checking fields cover all the register...");

var result = 0;
var regs = project.getRegisters();

for (var i=0; i<regs.size(); i++) {
var fields = regs.get(i).getFields();
if (fields != null && fields.size() > 0) {
var regSize = regs.get(i).getSize();
// create a bit map of the register with all bits set to 1

var reg = new Array(regSize);
for (var j=0; j < regSize; j++) {
reg[j] = 1;
}
// for every field set the corresponding bits to 0

for (var j=0; j < fields.size(); j++) {
var f = fields.get(j);
for (var k = f.getBitOffset(); k < (f.getBitOffset() + f.getBitWidth());
k++) {
if (k >= regSize) {
EcLog.error("Field '" + f.getName() + "(offset=" + f.getBitOffset() + "
width=" + f.getBitWidth() + ")' in register '" + regs.get(i).getName() +
"' Exceeds register size [" + regSize + "].");
result = -1;
} else {
reg[k] = 0;
}
}
}
// check that there are no 1s

for (var j=0; j < regs.get(i).getSize(); j++) {
if (reg[j] == 1) {
EcLog.error("Register " + regs.get(i).getName() + " has unmapped bit #" +
j);
result = -1;
}
}
}
}
return result;
}

return 0;
}
Examples
Example Notes:
• Note how the use of the import “importPackage(com.mentor.regassist.dm);” enables

you to use APIs that help you obtain information on the imported registers such as
“getRegisters()” and “getSize()”.
• The use of the import “importClass(com.mentor.svassist.common.util.EcLog);” enables
you to print messages in the console (of Register Assistant or the interface tool). Note
the line: “EcLog.log("Checking fields cover all the register...");”.
• The use of the import
“importClass(com.mentor.regassist.generator.RACheckerManager);” enables you to
add the check function to the checker manager. Note the line:
“RACheckerManager.addCheck(check);”.
Example 2 — Checks JavaScript File

This example checks that all register definitions do not have null values in the “Reset Mask”
entry.
EcLog.log("Checking the Reset Mask value is not Null...");
var regs = project.getRegisters();
for (var i=0; i<regs.size(); i++) {

var temp = new Array(regs.get(i).getSize());
temp[i] = regs.get(i).getResetMask();
if (temp[i] == null ) {
EcLog.error("The Register" + regs.get(i) + "has null Reset Mask" +
temp[i] );
return -1 ;
}
}
return 1;
}
return 0;
}
Example 3 — Tcl File

This example checks that the project has a single and valid memory map instance.
Examples
::raLogMessage "Checking project has a single memory map instance..."
set projName [::raGetProjectName]

set maps [::raGetMemoryMapInstances $projName]
if { [llength $maps] < 1 } {
# no memory map instances found
::raLogMessage "The project must have at least one Memory Map instance
to complete the generation."
return -1;
} else {
if { [llength $maps] > 1 } {
::raLogMessage "Project have multiple Memory Map instances. Only the

first one is used in generation and the rest will be ignored."
}
}
::raLogMessage "Checking project has a valid memory map instance..."

set instName [lindex $maps 0]
set defName [::raGetMemoryMapDefinitionNameOfInstance $projName
$instName]
if { $defName == "" } {
# Invalid instance, couldn't locate definition
set msg "Couldn't locate definition '$defName' for the memory map
instance '$instName'. Invalid Memory map instance.\n"
set msg "$msg Please make sure that the definition name is set
correctly on the memory map instance."
::raLogMessage $msg
return -1;
return 1;
Examples
Chapter 5
Register Assistant contains a number of generators that use the imported register data to create
different output types. According to the output type you choose, Register Assistant uses the
corresponding generator. Among the generators available in Register Assistant, for example,
are the UVM, OVM, RTL, and HTML generators.
This chapter details the different output types generated by Register Assistant.
UVM Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Generated UVM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Supporting Coverage Models for Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Supporting Simple “Quirky” Registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
How to Use Quirky Register With CSV Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
OVM Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Generated OVM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
HTML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
RTL Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Specifying Software and Hardware Access Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Generic Bus and Bus Bridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Understanding RTL Intrinsic Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Examining the Generated RTL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
RTL Alternative Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
RTL Software Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
RTL Byte Enable Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Understanding RTL Field Signal Naming and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
C Header Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Specifying the Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Examining the Generated C Header File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Generating C Utility Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Word Addressable Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Applying Word Addressing in Register Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
UVM Output
UVM Output
The UVM verification environment is composed of several components, among which is the
UVM register package. This package can be automatically generated using Register Assistant.
The generated UVM file should contain the description of the imported registers.
To generate the UVM register package, you have to write the following command in the control
file:
# <comment>
<generator_language>, <generator_name>, <file_name>, <UVM Register Package
Version>, <UVM Output Directory/Location>
For example:

java, uvm, my_uvm_file, 1.0, D:/projects/uvm

Table 5-1. UVM Output Command in Control File
Keyword Equivalent in Description
Example
<generator_la java The language of the output
nguage> generator.
<generator_na uvm The name of the java generator.
me>
<file_name> my_uvm_file Specify the name of the UVM
file that will be generated.
<UVM 1.0 Register Assistant supports
Register UVM Register Package version
Package 1.0 and 1.1.
Version>
<UVM Output D:/projects/uvm The path of the generated file. If
Directory/ not specified, the default project
Location> location is used. The default
project location is the path
specified by the -project
command if you are using
Register Assistant in batch
mode, or the project path of the
host application if you are using
Register Assistant through an
interface tool (such as HDL
Designer Series).
Generated UVM File
Refer to “Control File” on page 23 for further information on control files.
Generated UVM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Supporting Coverage Models for Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Supporting Simple “Quirky” Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
How to Use Quirky Register With CSV Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Generated UVM File

Register Assistant generates a SystemVerilog file containing the description of your registers,
memories, blocks as extracted from the imported source.
Generated UVM File
Format
The UVM file is basically composed of several sections as shown in the following figure:
Generated UVM File
Figure 5-1. UVM Output
Supporting Coverage Models for Blocks
• Defining the Register Package — Contains the definition of the register package and
the required imports.
• Defining Register Objects — Contains the definitions of registers.
Registers are defined by extending the class uvm_reg or the alternative base class
specified using the Register Custom Type CSV column.
class stopwatch_csr extends uvm_reg;
Subsequently, fields are defined within the register, constructors are created determining
the name and size of the register and whether it has coverage or not, a build method is
implemented to actually create the instances in the class, and then each field is
configured using a configure method.
This is repeated for each register.
• Defining Register Blocks and Register Hierarchy — Contains the definitions of
register blocks. It also contains the register hierarchy and the block maps.
This section defines register files or sub-blocks by extending from the uvm_reg_block
class. In this section, an instance is created for each register or memory in the register
file/block.
Note
Mentor Graphics recommends defining blocks and sub-blocks instead of register
files. If your input files contain register files, then they will be automatically
translated as blocks in the UVM output. See “Overview on Register Data Hierarchy” on
page 14.
Example
Refer to “UVM Output Example” on page 229 to view an example UVM register package
generated by Register Assistant.

Register Assistant enables you to generate coverage models within the UVM register package.
You can specifically generate coverage models for instances in a block.
Register Assistant also supports UVM field coverage; refer to “Supporting Coverage Models
for Fields” on page 80for information.
To generate coverage models, you have to set the coverage type in your input files. This is
achieved by doing the following:
• CSV — If you are using CSV files to provide your register definitions, then make sure
you have a column in your blocks file titled “Block Coverage”.
Use this column to specify the coverage type identifier. The only supported identifier is
“UVM_CVR_ADDR_MAP”. This identifier checks the addresses read or written in a
block map. If you use any other value, then this is interpreted as no coverage required,
that is, it will be interpreted as “UVM_NO_COVERAGE”.
• JavaScript files — If you are using JavaScript files to provide your register definitions,
then make sure you set the coverage option using the following API:
<block_name>.setCoverage(RABlock.COVERAGE.<uvm_coverage_identifier>
);
Like CSV, you need to specify the coverage type identifier. The only supported
identifier is “UVM_CVR_ADDR_MAP”. This identifier checks the addresses read or
written in an address map.
See the following example excerpt:
// Create Top Block
var sw_top_block = project.addBlock("sw_top_block");
sw_top_block.setDescription("Top block for the stopwatch design");
sw_top_block.setCoverage(RABlock.COVERAGE.UVM_CVR_ADDR_MAP);
project.setTopBlock(sw_top_block);
var sw1 = sw_top_block.addSubBlock("sw_sub_block", "sw1");

sw1.setDescription("Block1 instance 1");

var vreg1 = sw_top_block.addRegisterInstance("stopwatch_counter",

"vreg1");
vreg1.setDescription("Counter instance 1");
vreg1.setBackdoorPath("top.counter1.count");
vreg1.addParameter("uvmAttribute.NO_REG_HW_RESET_TEST", "1",
"Prevents the reset test being run on this register instance");

"vreg2");
vreg2.setBackdoorPath("top.counter2.counter_i0.count");

"vreg3");
var mem1 = sw_top_block.addMemoryInstance("my_mem", "mem1");

mem1.setDescription("Memory instance");
var my_reg1 = sw_top_block.addRegisterInstance("my_reg",

"my_reg1");
my_reg1.setDescription("Custom register instance");
By setting the coverage option in your input files, the generated UVM register package will
include a new defined class called <block name_coverage>. This class will be instantiated
within the class of the block itself, and the instance will be called within the sample and build
methods. See the following generated UVM register package example.
Example
The following generated code excerpt shows an example of a block and its corresponding
coverage class.
//--------------------------------------------------------------------
// Class: stopwatch_block_SW_MAP_coverage
//
// Coverage for the 'SW_MAP' in 'stopwatch_block'
//--------------------------------------------------------------------
class stopwatch_block_SW_MAP_coverage extends uvm_object;

ùvm_object_utils(stopwatch_block_SW_MAP_coverage)
covergroup ra_cov(string name) with function sample(uvm_reg_addr_t

addr, bit is_read);
option.per_instance = 1;
option.name = name;
ADDR: coverpoint addr {

bins stopwatch_value_reg = {'h4};
bins stopwatch_reset_value_reg = {'h8};
bins stopwatch_upper_limit_reg = {'hc};
bins stopwatch_lower_limit_reg = {'h10};
bins stopwatch_csr_reg = {'h14};
bins stopwatch_memory_reg[8] = {'h34,
'h38,
'h3c,
'h40,
'h44,
'h48,
'h4c,
'h50};
}
RW: coverpoint is_read {

bins RD = {1};
bins WR = {0};
}
ACCESS: cross ADDR, RW {

ignore_bins write_only = binsof(ADDR) intersect {'h14} &&
binsof(RW) intersect {1};
ignore_bins read_only = binsof(ADDR) intersect {'h8, 'h34,
'h38, 'h3c, 'h40, 'h44, 'h48, 'h4c, 'h50} && binsof(RW) intersect {0};
}
endgroup: ra_cov
function new(string name = "stopwatch_block_SW_MAP_coverage");

ra_cov = new(name);
endfunction: new
function void sample(uvm_reg_addr_t offset, bit is_read);

ra_cov.sample(offset, is_read);
endfunction: sample
endclass: stopwatch_block_SW_MAP_coverage
//--------------------------------------------------------------------
// Class: stopwatch_block
//
// stopwatch_block for the stopwatch design

//--------------------------------------------------------------------
class stopwatch_block extends uvm_reg_block;

ùvm_object_utils(stopwatch_block)
rand stopwatch_value stopwatch_value_reg; // Value instance

rand stopwatch_reset_value stopwatch_reset_value_reg; // Reset
Value instance
rand stopwatch_upper_limit stopwatch_upper_limit_reg; // Upper
Limit instance
rand stopwatch_lower_limit stopwatch_lower_limit_reg; // Lower
Limit instance
rand stopwatch_csr stopwatch_csr_reg; // CSR instance
rand stopwatch_memory stopwatch_memory_reg[8]; // MEM instances
uvm_reg_map SW_MAP; // stopwatch_block map

stopwatch_block_SW_MAP_coverage SW_MAP_cg;
// Function: new
//
function new(string name = "stopwatch_block");
super.new(name, build_coverage(UVM_CVR_ADDR_MAP));
endfunction
// Function: build
//
if(has_coverage(UVM_CVR_ADDR_MAP)) begin
SW_MAP_cg =
stopwatch_block_SW_MAP_coverage::type_id::create("SW_MAP_cg");
set_coverage(UVM_CVR_ADDR_MAP);
end
stopwatch_value_reg =
stopwatch_value::type_id::create("stopwatch_value_reg");
stopwatch_value_reg.build();
stopwatch_value_reg.configure(this);
stopwatch_reset_value_reg =
stopwatch_reset_value::type_id::create("stopwatch_reset_value_reg");
stopwatch_reset_value_reg.build();
stopwatch_reset_value_reg.configure(this);
stopwatch_upper_limit_reg =
stopwatch_upper_limit::type_id::create("stopwatch_upper_limit_reg");
stopwatch_upper_limit_reg.build();
stopwatch_upper_limit_reg.configure(this);
stopwatch_lower_limit_reg =
stopwatch_lower_limit::type_id::create("stopwatch_lower_limit_reg");
stopwatch_lower_limit_reg.build();
stopwatch_lower_limit_reg.configure(this);
stopwatch_csr_reg =
stopwatch_csr::type_id::create("stopwatch_csr_reg");
stopwatch_csr_reg.build();
stopwatch_csr_reg.configure(this);
Supporting Coverage Models for Fields
foreach ( stopwatch_memory_reg[i] ) begin

stopwatch_memory_reg[i] =
stopwatch_memory::type_id::create($psprintf("stopwatch_memory_reg[%0d]",
i));
stopwatch_memory_reg[i].build();
stopwatch_memory_reg[i].configure(this);
end
SW_MAP = create_map("SW_MAP", 'h0, 4, UVM_LITTLE_ENDIAN, 1);

default_map = SW_MAP;
SW_MAP.add_reg(stopwatch_value_reg, 'h4, "RW");

SW_MAP.add_reg(stopwatch_reset_value_reg, 'h8, "RO");
SW_MAP.add_reg(stopwatch_upper_limit_reg, 'hc, "RW");
SW_MAP.add_reg(stopwatch_lower_limit_reg, 'h10, "RW");
SW_MAP.add_reg(stopwatch_csr_reg, 'h14, "WO");
foreach(stopwatch_memory_reg[i]) begin
SW_MAP.add_reg(stopwatch_memory_reg[i], (i * ('h4)) + ('h34),
"RO");
end
lock_model();
endfunction
// Function: sample
//
function void sample(uvm_reg_addr_t offset, bit is_read, uvm_reg_map
map);
if(get_coverage(UVM_CVR_ADDR_MAP)) begin
if(map.get_name() == "SW_MAP") begin
SW_MAP_cg.sample(offset, is_read);
end
end
endfunction: sample
endclass

Register Assistant enables you to generate coverage for UVM register fields. Using this feature,
you can easily map OVM designs with field coverage properties to the UVM related behavior.
To generate coverage models for fields you should:
1. Add an optional “Field is Covered” column to your CSV input files.

2. Set the column value to TRUE for fields that requires coverage.
Note
If you set the “Field is Covered” column value to TRUE for a reserved field,
Register Assistant will issue a warning message during generation.
The default value for the “Field is Covered” column is FALSE. This indicates that the
default Register Assistant behavior is not to generate coverage information for register
fields.
Example
In this example, register stopwatch_csr fields stride, updown, upper_limit_reached and
lower_limit reached are to be covered. We therefore, set the “Field is Covered” flag value to
TRUE for each of these fields in the CSV input file.
Let us examine the generated code for the Control Status Register and note the field coverage
code added.
// Class: stopwatch_csr
//
// Control Status Register
//--------------------------------------------------------------------

ùvm_object_utils(stopwatch_csr)
uvm_reg_field padding
rand uvm_reg_field stride;
rand uvm_reg_field updown;
uvm_reg_field upper_limit_reached;
uvm_reg_field lower_limit_reached;
By setting the field coverage option in your input files, the generated UVM register package
will create a single covergroup called “cg_vals”. For each non-reserved field whose “Field is
Covered” flag is TRUE, a coverpoint with the name of the field is created.
// Function: coverage
//
covergroup cg_vals;
stride : coverpoint stride.value[3:0];
updown : coverpoint updown.value[0];
upper_limit_reached : coverpoint upper_limit_reached.value[0];
lower_limit_reached : coverpoint lower_limit_reached.value[0];
endgroup
In the function new the coverage is set to UVM_CVR_FIELD_VALS and the covergroup is
constructed.
// Function: new
//
function new(string name = "stopwatch_csr");
super.new(name, 32, build_coverage(UVM_CVR_FIELD_VALS));
add_coverage(build_coverage(UVM_CVR_FIELD_VALS)
if(has_coverage(UVM_CVR_FIELD_VALS)) begin
cg_vals = new();
endfunction
A function sample_values is created to check whether the coverage is set to

UVM_CVR_FIELD_VALS and accordingly call the sample method for the created
covergroup.
// Function: sample_values
//
virtual function void sample_values();
super.sample_values();
if (get_coverage(UVM_CVR_FIELD_VALS))
cg_vals.sample();
endfunction
// Function: build
//
padding = uvm_reg_field::type_id::create("padding");
stride = uvm_reg_field::type_id::create("stride");
updown = uvm_reg_field::type_id::create("updown");
upper_limit_reached =
uvm_reg_field::type_id::create("upper_limit_reached");
lower_limit_reached =
uvm_reg_field::type_id::create("lower_limit_reached");
padding.configure(this, 25, 7, "RW", 0, 25'b0, 1, 0, 0);

stride.configure(this, 4, 3, "RW", 0, 4'h0, 1, 1, 0);
updown.configure(this, 1, 2, "RW", 0, 1'b0, 1, 1, 0);
upper_limit_reached.configure(this, 1, 1, "RO", 0, 1'b0, 1, 0, 0);
lower_limit_reached.configure(this, 1, 0, "RO", 0, 1'b0, 1, 0, 0);
endfunction
endclass
Supporting Simple “Quirky” Registers

When generating the UVM register package, Register Assistant depends on built-in packages to
describe the registers. For example, when defining registers, Register Assistant extends from
the class uvm_reg available in its built-in package uvm_pkg. Through the support of “quirky”
(custom) registers, you will be able to rely on user-defined packages and, hence, extend from
your own user-defined register classes.
This feature can be useful, for example, when you want to use a new access mode other than
those available in Register Assistant’s package, so you will be able to define this access mode in
your own quirky register class. This is applicable to any other register properties you need to
customize.
How to Use Quirky Register With CSV Input

If you have CSV input files, you will be able to use quirky registers through two methods as
follows:
Through CSV Specific Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Through Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
How To Use Quirky Register With JavaScript Input . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Through CSV Specific Columns

Make sure first that you have written the definition of your quirky register class in a package,
and then do the following:
Procedure
1. On the project level, add a CSV column for the import statement of your package. This
is done through the column titled “Project Extra Imports”.
2. On the register level, add a CSV column to specify the corresponding user-defined
register class which you will use to extend the register. This is done through the column
titled “Register Custom Type”.
Examples
The column titled “Project Extra Imports” is added in the CSV input file and given the value
mypkg::*,pkg2::*. Hence, Register Assistant adds the following imports at the beginning of the
generated output:
import mypkg::*;
import pkg2::*;
At the same time, the column titled “Register Custom Type” is added in the CSV input file and
given the value my_custom_reg, specifically on the row of the register titled stopwatch_counter.
Hence, Register Assistant extends from the class my_custom_reg for the register
stopwatch_counter only (instead of extending from uvm_reg) as follows:
//----------------------------------------------------------------
// Class: stopwatch_counter
//
// Stop Watch Counter
//-------------------------------------------------------------
class stopwatch_counter extends my_custom_reg;

ùvm_object_utils(stopwatch_counter)
rand uvm_reg_field F;
// Function: new
//
function new(string name = "stopwatch_counter");
super.new(name, 32, UVM_NO_COVERAGE);
endfunction
// Function: build
//
F = uvm_reg_field::type_id::create("F");
F.configure(this, 32, 0, "RW", 1, 32'h00000000, 1, 1, 1);
endfunction
endclass
Through Parameters
As mentioned before, first make sure that you have written the definition of your quirky register
class in a package, and then add the following parameter columns in your CSV file:
Procedure
1. Add a parameter on the project level for the import statement. This includes adding the
following columns:
• Project Parameter Name: The value of this parameter should be
uvmgen.EXTRA_IMPORTS.
• Project Parameter Value: Specify the name of your user-defined package. Note that
you can specify more than one package name separated by spaces.
• Project Parameter Description: Specify any description for reference.
Table 5-2. Project Parameter Examples

Column Name Value
Project Parameter Name uvmgen.EXTRA_IMPORTS
Table 5-2. Project Parameter Examples (cont.)

Column Name Value
Project Parameter Value mypkg::* pkg2::*
Project Parameter Description Extra imports
The example above signifies that you will add extra imports to the generated UVM
register package as follows:
// Extra imports
import mypkg::*;
import pkg2::*;
Note how the description is added as a comment.

2. Add a parameter on the object level to specify the parent class of the register. This
includes adding the following columns:
• <Object> Parameter Name: The value of this parameter should be
uvmgen.ALT_PARENT.
• <Object> Parameter Value: Specify the name of the quirky register class which will
be used as the parent class.
• <Object > Parameter Description: Specify a description for reference.
Table 5-3. Object Parameter Examples

Column Name Value
Register Name stopwatch_counter
Register Parameter Name uvmgen.ALT_PARENT
Register Parameter Value my_custom_reg
Register Parameter Description Alternative parent for this register.
The example above signifies that in the generated output, Register Assistant will extend
from the class my_custom_reg for the register stopwatch_counter (instead of extending
from uvm_reg) as follows:
//----------------------------------------------------------------
//
//-------------------------------------------------------------

// Function: new
//
endfunction
// Function: build
//
endfunction
endclass
3. Make sure the columns above are mapped correctly in your csv.js file. Refer to
“Importing Data From CSV Files” on page 33. You can also refer to CSV Columns.
4. For more information on parameters, refer to “Parameters” on page 213.
How To Use Quirky Register With JavaScript Input

If you are using JavaScript as your input format, make sure first that you have written the
definition of your quirky register class in a package, and then add the following APIs in your
JavaScript file:
Procedure
1. As mentioned before, you need to add a parameter on the project level for the import
statement. This includes adding the following API:
project.addParameter(<parameter name which should be
UVMGenerator.PARAM_EXTRA_IMPORTS>, “<value>”, “<description>”);

project.addParameter(UVMGenerator.PARAM_EXTRA_IMPORTS, "mypkg::*
pkg2::*", "Extra imports");
The example above signifies that you will add extra imports to the generated UVM
register package as follows:
// Extra imports
import mypkg::*;
import pkg2::*;
Note how the description is added as a comment.

2. As mentioned before, you need to add a parameter on the object level to specify the
parent class of the register. This includes adding the following API:
<object name>.addParameter(<Object Parameter Name which should be
UVMGenerator.PARAM_ALT_PARENT>, <Object Parameter Value>, <Object
Parameter Description>);

stopwatch_counter.addParameter(UVMGenerator.PARAM_ALT_PARENT,
"my_custom_reg", "Alternative parent for this register");
Supporting Back Door Access
The example above signifies that in the generated output, Register Assistant will extend
from the class my_custom_reg for the register stopwatch_counter (instead of extending
from uvm_reg) as follows:
//----------------------------------------------------------------
//
//-------------------------------------------------------------

// Function: new
//
endfunction
// Function: build
//
endfunction
endclass

The UVM generator allows you to access registers through the regular bus cycles (“front door”)
or directly via the hierarchical pathname used in the target simulator (“back door”).
This backdoor approach allows registers/memories to be read and written in zero simulator time
and, therefore, allows the registers/memories in the system being simulated to be put into a
known state much faster than by performing the appropriate bus cycles. It also enables the
reading of the register/memory values by the testbench without moving simulator time forward
and potentially changing the system state.
For maximum reuse, it is recommended to specify just the path segment for each level in the
design hierarchy although you can specify multiple levels of the path to a given object if
required.
Register Assistant allows you to specify backdoor paths for blocks, instances within blocks
(registers, memories or other blocks), and fields within registers.
You can specify backdoor paths through your CSV input files by doing the following:
• If you have multiple fields within your registers, you can add the “Field Backdoor”
column in the CSV file describing your registers. You can use this column to specify the
backdoor path for each field.
• In the CSV file describing your blocks, add the “Block Backdoor” and “Block Instance
Backdoor” columns. These columns allow you to specify the simulation backdoor path
for the block and for a given instance (register, memory or sub-block) within a block
respectively.
Refer to Example, below for further details.
Example
Consider the following example CSV input files and the resulting UVM generated output.
Input:
The CSV definition file for registers is as follows:
Figure 5-2. Register Description.
In this file, note the added column titled “Field Backdoor”. It contains the backdoor path on the
level of each field.
The CSV definition file for blocks is as follows:
Figure 5-3. Block Description
In this file, note the “Block Backdoor” and “Block Instance Backdoor” columns. The “Block
Backdoor” column indicates the simulator path for a specific block. The “Block Instance
Backdoor” column indicates the path or path segment for a given instance (register, memory or
sub-block) within a block.
Note the following:
• You can leave a cell empty which indicates that no backdoor path is required.
• You can directly specify a backdoor path.
• You can use the %(FIELDS) variable which indicates that a backdoor path is required
and that the tool can use the field paths specified for the field in the “Field Backdoor”
column (see Figure 5-2 and Figure 5-3).
• If the block instance has an array, you can use the variable %(DIM) to refer to each
instance of the expanded array. For example, you can enter the following value in the
cell: %(FIELDS)_array_%(DIM)_local
The overall backdoor path to a given instance (sub-block, register or memory) is
determined during simulation by concatenating the paths for each level. In the above
example, the path to the last register in the instance array would be:
top.dut.field1_small_mem_h_array_7_local
Refer to Output:, below for more details.
Note
For arrays of instances, the %(DIM) variable can be combined with the %(FIELDS)
in order to create the appropriate backdoor path expression.
Refer to the OVM/UVM Variables table for information on the %(DIM) and %(FIELDS)
variables.
Output:
The UVM output generated by Register Assistant will be affected by your backdoor access
definitions as follows:
• For the “Field Backdoor”, the generated UVM output requires a “slice” to be specified
for each register field along with its bit offset and width, which are provided through the
field definition. By adding the “Field Backdoor” path, the information can be used for
any instance of that register simply by adding the %(FIELDS) variable for the “Block
Instance Backdoor”.
In the generated UVM, the HDL path argument in the configure method is left blank and
add_hdl_path_slice statements are added for each field as follows:
<reg_inst>.add_hdl_path_slice(“<field_path”, offset, width, 0,
<kind>);
• The “Block Backdoor” is typically used for the top-level block (see the example in
Figure 5-3) and would contain the hierarchy path from the simulator root down to the
top-level block, for example top.dut. Depending on the hierarchical structure of the
design, “Block Backdoor” may be left blank for lower-level blocks.
In the example, reg_block is the top-level block. Therefore, the “Block Backdoor” path
is specified as top.dut.
The path is added for the block instance as follows:
• For the “Block Instance Backdoor”, there are several cases according to which the
output will be affected:
a. Register Instance without Fields:
In case of a register without fields (or when there is only one field spanning the
register width), the path is the name of the register signal being assigned within the
flip-flop always block, not the label of the always block which may be shown in the
simulator hierarchy window.
The path is added into the configure statement for the block instance as follows:
b. Register Instance with Fields:

If a “Block Instance Backdoor” path is required for a register instance containing
fields, the information specified in the field definitions will be automatically inserted
if you enter the %(FIELDS) variable for the “Block Instance Backdoor” column. See
Figure 5-3.
c. Array of Registers:
For an array of register instances, the system variable %(DIM) can be used in the
path name. For example: data_small_mem_h_array_%(DIM)_local
This will be automatically expanded in the generated UVM as follows:
d. Sub-block Instance:
The path for a sub-block instance (if required) is the instance name in the block, in the
current example it is called sub_block. In the generated UVM output, this would appear
in the configure statement as follows:
• Following the above example, the resulting UVM backdoor paths used in the simulator
would be as follows:
/top.dut.other_field_status_reg_h_local
/top.dut.ctrl_bit_status_reg_h_local
/top.dut.myField_RegB_h_local
/top.dut.field2_small_mem_h_array_0_local
/top.dut.sub_block_inst.regAfield2_RegA_h_local
/top.dut.sub_block_inst.regAfield1_RegA_h_local
OVM Output
OVM Output
The OVM verification environment is composed of several components, among which is the
OVM register package. For example, you may have the top level, the RTL, a SystemVerilog
interface wrapper around the RTL, and the actual register definitions. This last file can be either
written manually or generated automatically using Register Assistant. The generated OVM file
should contain the description of your imported registers.
Register Assistant’s OVM generator supports the usage of both the 1.0 and 2.0 OVM register
packages. For the 2.0 OVM register package, two levels of support are provided and are labeled
as 2.0 and 2.2. The OVM 2.2 provides extended support which covers additional features
provided through the OVM 2.0 register package, for example using macros instead of methods
to add fields, using ovm_report_info for logging reasons.
To generate the OVM register package, you have to write the following command in the control
file:
# <comment>
<generator_language>, <generator_name>, <file_name>, <OVM Register Package
Version>, <OVM Output Directory/Location>
For example:

java, ovm, my_ovm_file, 1.0, D:/projects/ovm

Table 5-4. OVM Output Command in Control File
<generator_language> java The language of the output generator.
<generator_name> ovm The name of the java generator.
<file_name> my_ovm_file You can specify the name of the
OVM file that will be generated. If
you do not specify a name in the
control file, then the default name
will be <project’s name>_pkg.sv.
Refer to “Control File” on page 23.
Generated OVM File
Table 5-4. OVM Output Command in Control File (cont.)

<OVM Register 1.0 Register Assistant supports OVM
Package Version> Register Package version 1.0 and 2.0
as well. For the 2.0 Register package,
RA provides two levels of support
labelled as 2.0 and 2.2. By default,
Register Assistant relies on version
2.2, hence you do not necessarily
need to specify it in the control file. If
you want to use version 1.0 or 2.0,
then you must manually specify them
in your control file. Refer to “Control
File” on page 23.
<OVM Output D:/projects/ovm The path of the generated file. If not
Directory/Location> specified, the default project location
is used. The default project location
is the path specified by the -project
command if you are using Register
Assistant in batch mode, or the
project path of the host application if
you are using Register Assistant
through an interface tool (such as
HDL Designer Series).
command manually in the control file. If you are using Register Assistant through an interface
tool such as HDL Designer Series, you will be able to enter your import, checks and output
settings through the interface and then the control file will be auto-generated. Refer to “Control
File” on page 23 for further information.
Generated OVM File

Register Assistant generates a SystemVerilog file containing the description of your registers,
memories, sub-blocks, blocks, and so on, as extracted from the imported source.
In creating this file, Register Assistant relies on the OVM Register Package and the OVM
Library. That is why, you have to make sure that your project contains the OVM Register
Package and the OVM Library in order to guarantee the correct generation of the file and to
avoid receiving errors on compilation.
Generated OVM File
Format
The OVM file is basically composed of several sections as shown in the following figure:
Figure 5-4. OVM Output
• Defining the Register Package — Contains the definition of the register package and
the required imports.
• Defining Register Objects — Contains the definitions of registers. It should be noted
that there are two types of registers: registers in which data is a whole bit vector and
Generated OVM File
registers in which data is partitioned into fields. So, before defining registers, the type of
registers has to be defined first as in the following example:
typedef bit[31:0] bit32_t;

typedef struct packed {
bit[31:7] padding;
bit[6:3] stride;
stopwatch_csr_updown_enum updown;
bit upper_limit_reached;
bit lower_limit_reached;
} stopwatch_csr_t;
Registers are defined by extending the class ovm_register and passing the register type
as a parameter as in the following example:
class stopwatch_csr extends ovm_register #(stopwatch_csr_t);
• Defining Register Files — Contains the definitions of register files with instances of the
registers that constitute each file. See the following example:
class stopwatch_register_file extends ovm_register_file;

...
rand stopwatch_memory MEM[8];
rand stopwatch_csr CSR;
...
endclass
• Defining Register Maps — Contains the definitions of the register map with instances
of the register files in it. The address offset of each register file is specified as shown in
the below example. Finally, the register map is loaded.
class sw_mem_map extends ovm_register_map;

rand stopwatch_register_file sw1;
rand stopwatch_register_file sw2;
...
add_register_file(sw1, 'h1000);
...
endclass
Generated OVM File
Note
Note that Register Assistant calculates the addresses in the generated OVM file
using certain inputs in your register definitions. These inputs are provided as
arguments for the “add register” method in the OVM file: add_register(<Register
name>, <Offset_address>, <ovm_register_base >. For example:
add_register(VALUE.get_fullname(), 'h4, VALUE);
So the register address is taken directly from the offset address of the register instances.
In case of multiple instances of the same register (having the dimension greater than 1),
the offset address is calculated as follows: register instance’s offset + register definition
size.
Example
Refer to “OVM Output Example” on page 239 to view an example OVM register package
generated by Register Assistant.
HTML Output
HTML Output
Register Assistant allows you to generate HTML files containing description of your imported
register definitions, thus automating the creation of documentation.
To generate HTML files, you have to write the following command in the control file:
# <comment>
<generator_language>, <generator_name>, <HTML Output Directory/Location>
For example:

js, examples/html.js, D:/projects/html

Table 5-5. HTML Output Command in Control File
<generator_language> js The language of the output generator.
<generator_name> examples/html.js The location of the JavaScript
generator.
This is the file used by Register
Assistant to identify the templates and
the cascading style sheet to use in
generating the output.
<HTML Output D:/projects/html The path of the generated file. If not
Directory/Location> specified, the default project location
is used. The default project location is
the path specified by the -project
command if you are using Register
Assistant in batch mode, or the project
path of the host application if you are
using Register Assistant through an
interface tool (such as HDL Designer
Series).
command manually in the control file. If you are using Register Assistant through an interface
tool such as HDL Designer Series, you will be able to enter your import, checks and output
settings through the interface and then the control file will be auto-generated. Refer to “Control
File” on page 23 for further information.
HTML Output
The HTML files provided include the following:
• HTML file for the top block found in the project

• HTML file for each sub-block/register file in the project
• HTML file for each block map in each block
• HTML file for each register/memory definition in the project
HTML Output
• Index files that offer different ways to view the register documentation:
o Index.html:
HTML Output Script File
o Index2.html: uses two frames to provide a register tree down the left hand side which
can be expanded to show the fields within each register in addition to the
corresponding register details on the right hand side.

A default JavaScript script file called html.js communicates with Register Assistant to obtain
the imported register data and then document it in HTML files. The script organizes and formats
the content of these HTML files according to templates and a cascading style sheet that already
exist with Register Assistant. These templates and cascading style sheet determine, for example,
the titles and headings used in the HTML files, the table formats, and the link colors.
The default script is available on the following path: <installation_folder>\registerassistant\
examples
The default templates (.ftl) and cascading style sheet (.css), and also the images used in the
generated HTML files are available on the following path: <installation_folder>\
registerassistant\resources\templates\html
You have the ability to customize the above mentioned files to affect your HTML output. For
example, you can control which register information to show, the heading types, the font types.
Alternatively, you can use the environment variable RA_TEMPLATE_DIR to point to other
templates (.ftl and .css files) outside Register Assistant’s install tree. Make sure to save your
template files in a directory called html and to point to its parent directory when setting the
environment variable. By default, this environment variable points to the parent directory of the
html directory shipped with Register Assistant: <installation_folder>\registerassistant\
resources\templates\
Format
The script file that affects the generated HTML files is basically composed of several sections
as shown in the following figure:
Figure 5-5. HTML Output Script File
o The following import is used to support any calls made to the template utility. This
import is mandatory.
importClass(com.mentor.regassist.generator.TemplateUtil);
The template utility enables you to generate files based on the available .ftl
templates. It obtains the required data from the current project, for example the block
data, and passes it to the corresponding HTML template. These templates define
how the data will be organized in the HTML file.
o The following import is used to support any calls made to the generator utility. This
import is mandatory.
The generator utility enables you to prepare the location in which the generated
output will be placed.
o The following import is used to pass information to the template. This import is
optional.
importClass(java.util.HashMap);
<code>
...
return 0;
}
an error has occurred, and consequently the flow will stop.
example:
html.js', missing generate method.
• Verifying Top Block is Defined — In this section, the script verifies that the top block
is available, and if it is not available, the generation stops
• Preparing Output’s Destination — In this section, the script prepares the destination
folder in which the generated HTML files will be placed. This section mainly defines
the path of the destination folder, deletes old content in this folder and then copies the
necessary images and the cascading style sheet (which the HTML files will use).
• Passing Register Data to HTML — In this section, the script gets the register data
from the current project and passes it to the HTML templates for generation. It contains
sub sections for blocks, sub-blocks, registers and memories, and each one uses a
different template. For example, the script gets data on memories from the current
project and uses the memoryDef.ftl template to generate HTML output in a specific
destination. This is where the actual generation occurs using the calls made to
TemplateUtil.generate.
Refer to Example, below. You can also refer to the documentation of Register Assistant’s APIs
on the path: <installation_folder>\registerassistant\api\index.html.
Example
To view an example script, refer to the default script available with Register Assistant on
<installation_folder>\registerassistant\examples\html.js.
RTL Output
RTL Output
In a typical register-based design flow, the hardware development team needs to write Verilog/
VHDL RTL to define and access design registers. This can be a tedious job, especially if the
design contains thousands of registers each of which has different register fields of different
access modes.
Register Assistant provides a mechanism by which you can generate synthesizable VHDL/
Verilog RTL code from register definition files. Any change in any of the register definitions
will only require a simple run through Register Assistant to get the updated RTL code.
The generated RTL file contains the following:
• Register blocks having read, write and reset logic corresponding to all registers inside
the block.
You can instantiate these blocks inside your design to access the registers in a front door
fashion.
• A bus bridge which will map a Register Assistant generated generic bus to the used
system bus.
Figure 5-6. RTL Generator Output

Specifying Software and Hardware Access Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Specifying RTL Input

Generic Bus and Bus Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Preparing the Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Understanding RTL Intrinsic Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Examining the Generated RTL File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
RTL Alternative Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
RTL Software Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
RTL Byte Enable Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Understanding RTL Field Signal Naming and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

As all the Register Assistant generators, the RTL generator accepts register definition files as
input to produce relevant output.
In addition to the register definition files, you can configure the generator to produce RTL code
that complies to your specific requirements and code conventions. For example, Register
Assistant produces Verilog code by default, but through RTL parameters you can specify
VHDL to be your language of choice, etc.
Tip
To specify input for the RTL generator:
• Decide on your input files format.

• Fill in your input files with register/block descriptions.
• (Optional) Configure the RTL generator
The input files of a stopwatch example along with an example control file can be found
on the following path:
<installation_folder>\registerassistant\examples\rtl
Procedure
1. Decide on your Input Files Format
The RTL generator accepts register description files in CSV or JavaScript format. For
more information on Register Assistant input formats refer to “Register Assistant
Inputs” on page 31.
2. Fill in your Input files with Register/Block Descriptions
Upon deciding on the input format you wish to use, you would then have to make sure
that you provide a complete description of your hardware register objects in a fashion
that is correctly translated by Register Assistant. The following steps outline the objects
you need to define for ensuring correct and complete RTL code:
a. Register Objects — Each register is defined by a set of basic properties outlined in
Table 5-6.
Table 5-6. Mandatory Register Object Properties

Register Object Property Description
Register Name Determines the name of the register.
Register Width Determines the width of the register.
Register Reset Value Reset value
Register Access Determines the register access mode, that is, whether the
CPU reads and/or writes the register values.
b. Register Field Object — Each register may consist of one or more fields. Each field
is defined by a set of properties outlined in Table 5-7.
Table 5-7. Mandatory Field Object Properties

Field Object Property Description
Field Name Determines the name of the field.
Field Offset Address offset for the field
Field Width Width in bits for the field
Field Access Software Access for the field. For example, RW.
Field Reset Value Reset value
c. RTL Specific Properties — In addition to the general properties for Register

Assistant objects you may need to specify extra properties to provide a complete
description of your RTL design.
Table 5-8. RTL Specific Fields

CSV Column Description
Field HW Access Hardware Access for the field. For example, RO.
Table 5-8. RTL Specific Fields (cont.)

Field Condition User-entered combinatorial condition
Note that the condition can be empty if you are specifying a
default Field Action.
Field Action User-entered field assignment
Field Logic Comment Comment for user condition or action
Register Is External Indicates if the register is outside the generated block (that
is, not generated).
Field Is Reserved Indicates if the field is reserved.
Field Default Readvalue Default read data value for reserved fields, write-only
fields, unassigned fields and illegal read addresses.
Note
• Field Condition and Field Action properties should always be paired.

• The Field Condition and Field Action properties both accept system variables.
Refer to the Variables table for a list of the supported variables.
• The Field Is Reserved property enables you to define reserved fields within the
register. Reserved fields accept non-unique field names, whether you are
defining your register input in CSV, IP-XACT, or JavaScript format.
d. Register Block Object — Each block contains instances of functionally related

registers. Register blocks are defined by a set of basic properties outlined in
Table 5-9.
Table 5-9. Mandatory Block Object Properties

Block Name Determines the name of the generated module/entity.
Block Instance Name Name of a register data type instanced inside a block. A
register data type can be a register or a memory.
BlockMap Name Determines the name of the map used for a block. A block
map is an object that assigns addresses to a set of register
data types instanced within a block. A block may have
more than one map.
BlockMap Instance Name Determines the name of the Register instance included in
the map.
BlockMap Instance Address Offset address for the given instance
Table 5-9. Mandatory Block Object Properties (cont.)

Block Component Name Name of the component instantiated in the block such as the
name of the register, the sub-block, etc.
If you specify the property “Block Instance Dimension”, which is an optional
property for blocks (refer to the CSV Columns list), then it is important to note that
you should adhere to the maximum size you specified for the parameter
“rtl.REGISTER_INSTANCE_MAX_SIZE” (refer to the RTL Parameters table for
information on this parameter). If you did not set this parameter, then you should
adhere to the default maximum size which is 1024. This is applicable only when
generating RTL.
Note
• To view a full list of Register Assistant’s CSV columns, whether mandatory or

optional, you can refer to the CSV Columns list.
• If you are using register files in your input data, Register Assistant internally
translates them to sub-blocks (refer to “Overview on Register Data Hierarchy”
on page 14). It should be noted that any settings defined for parent blocks, such
as interface signals or parameters, will also be used for child register files.
Caution
If you define the optional CSV column “Block Instance Type” as being of type
“memory”, Register Assistant will not instantiate memories in the generated
RTL output. You should manually instantiate memories in the generated RTL output
and decode their corresponding bus signals. Refer to the CSV Columns list for
information on the available block properties.
3. Optionally Configure the RTL Generator

The RTL generator assumes a number of defaults for the generated code, examples are
the generation language, the naming conventions for the concluded design signals, etc.
These code generation properties can be modified using Register Assistant parameters.
For each property there exists a parameter. You can define the generator parameters in a
separate CSV or JavaScript file or add them to your primary register definition files.
Please refer to the RTL Parameters table. You can also refer to “Parameters” on
page 213.
We can summarize the RTL generator properties that can be modified in the following:
a. General generator settings
b. Bus settings
Specifying Software and Hardware Access Modes
c. Token cases
d. Naming conventions
e. Other miscellaneous properties
Specifying Software and Hardware Access Modes

An integral part of register description is the definition of access modes as it is the hardware and
software access modes of a register that determine its behavior. Let us see how we define access
modes for the RTL generator in a CSV input file. Register Assistant allows you to define the
register access mode through the Register Access, Field Access and the Field HW Access.
Note
The field access mode has to be a subset of the register access mode. For example, the
access mode of the field can possibly be read-only, if the access mode of the register is read-
write.
Procedure
1. The software access mode describes how the processor can write and/or read register
values using the bus protocol. Addressing is at the register level.
2. Specify an access mode for the field “Field Access”.
Refer to Figure 5-8 on page 121 with supported SW access modes. You can also refer to
SW Access Modes table to view a list of the supported access modes.
3. The hardware access mode describes how hardware can provide inputs and/or outputs to
the register. Connections are at the field level.
4. Specify an access mode for the field “Field HW Access”. Select from one of the
supported HW access modes in the H/W Access Modes table.
Or:
5. Enter defined conditions and actions to explicitly define the HW access mode in the
“Field Condition” and “Field Action”.
Note
The Field Condition and Field Action properties accept system variables. Refer to
the Variables table for a list of the supported variables.
Examples
Examine the code for a field with a Read Write 1 to Clear software access and a Read Write 0 to
Clear hardware access.
Specifying the Bus Protocol
//------------------------------------------------------------
// Field: fld_rw0c_l
// Width: 1 , Offset: 0
// SW Access: RW-Write-1-to-Clear , HW Access: RW-Write-0-to-Clear
//------------------------------------------------------------
always @ (posedge clock or negedge reset)
begin : reg_reg_rw0c_l_fld_rw0c_l_ireg_rw0c_l_local
// Reset
// The field reset action.
if ( !reset )
fld_rw0c_l_ireg_rw0c_l_local <= 1'b0;
// SW:RW-Write-1-to-Clear
// If the write enable signal is asserted, the field is cleared when
the corresponding bits in the write data bus equals 1, otherwise the
value is unchanged.
else if (register_we_ireg_rw0c_l)
fld_rw0c_l_ireg_rw0c_l_local <= (fld_rw0c_l_ireg_rw0c_l_local &
~wdata[0]);
// HW:RW-Write-0-to-Clear
// Clear the field when the signal fld_rw0c_l_ireg_rw0c_l_clr_n is
asserted.
else
fld_rw0c_l_ireg_rw0c_l_local <= fld_rw0c_l_ireg_rw0c_l_local &
fld_rw0c_l_ireg_rw0c_l_clr_n;
end
Note
* Constant value fields, that is, fields that have a single constant value with no reset, require
the following: First, the Field Access and Field HW Access should be set either as RO
(read-only) or as None. Second, the field should have one default action which is the constant
itself, and the condition should be left empty in this case.
* If the Field Access is not available, the RTL generator will use the value of the Register
Access. Similarly, if the Field HW Access is not available, the RTL generator will use the value
of the Register HW Access.
Specifying the Bus Protocol

Register Assistant RTL generator produces a simple generic protocol referred to as the “Generic
Bus” and uses the concept of “bus bridge” to map between this generic bus and the actual bus
protocol being used in the system.
Currently, Register Assistant can only generate the AMBA_APB bus bridge. If any block is set
to use AMBA_APB bus type, a bus bridge file is generated.
Generic Bus and Bus Bridge
To specify the bus bridge to be generated:
Procedure
1. Specify a value for the parameter “rtl.BUS_TYPE”.
2. Currently, there is only one bus type supported: AMBA_APB. The values for this
parameter can be “AMBA_APB” to generate AMBA_APB bus bridge, or “None” and
in that case the bus bridge will not be generated. The default value is “None”.
3. No more than one bus bridge file is generated for each project. The bus bridge file is
generated in Verilog if all the AMBA_APB blocks' language is Verilog and the bus
bridge file is generated in VHDL if all the AMBA_APB blocks' language is VHDL. If
the AMBA_APB blocks' language is mixed (VHDL and Verilog), then an arbitrary
language is used for the bus bridge file.
Note
The default name of the generated bus bridge file is "apb_bridge.v" or
"apb_bridge.vhd". You can control the name of the file through the parameter
“rtl.APB_BRIDGE_FILE_NAME”. Refer to “Parameters” on page 213 for general
information on parameters and to RTL Parameters table for a list the supported bus
settings parameters.
Tip
: The generated bus bridge is based on the template located on the path
<installation_folder>\registerassistant\resources\templates\rtl.

As mentioned earlier, Register Assistant generates a “generic bus” and a “bus bridge” that maps
between the generated generic bus and the system bus.
Refer to Figure 5-6. Also, Register Assistant only supports AMBA_APB bus bridges.
The Generic Bus is split into separate READ and WRITE signals to support the interfacing to
more advanced protocols that allow read and write operations from/to different addresses at the
same time if required. To facilitate this, separate READ and WRITE strobes are also provided.
Figure 5-7 shows the interfacing between the generic bus signals and the AMBA_APB system
bus via the bus bridge.
Figure 5-7. Bus Bridge Interface
The following table describes the signals within the generic bus.
Table 5-10. Generic Bus Signal Descriptions
Signal Mode Description
Common
clock Master Clock. Optionally rising (default) or falling edge.
reset Master Reset. Optionally active low (default) or active high.
Read Bus
rstrobe Master Read Strobe. Activates a register read access when HIGH.
raddr Master Read Address. Address of the register whose content is to be read.
rdata Slave Read Data. The content of the addressed register is placed on this
bus when RSTROBE is HIGH.
rack Slave Read Acknowledge. Asserted HIGH when RDATA is valid. This
can be on the current clock edge if “Read Data Mux Logic Type”
is set to ASYNC or the next clock edge if set to SYNC.
Table 5-10. Generic Bus Signal Descriptions (cont.)

Signal Mode Description
raddrerr Slave Read Address Error. Indicates an attempt to access an unmapped
register address for read.
Write Bus
wstrobe Master Write Strobe. Activates a register write access when HIGH.
waddr Master Write Address. Address of the register whose content is to be
written.
wdata Master Write Data. The new content destined for the addressed register is
placed on this bus and written to the register when WSTROBE is
HIGH.
wack Slave Write Acknowledge. Asserted HIGH when WDATA has been
assigned to the appropriate register. This can be on the current
clock edge if “Address Decode Logic Type” is set to ASYNC or
the next clock edge if set to SYNC.
waddrerr Slave Write Address Error. Indicates an attempt to access an unmapped
register address for write.
The following tables show how the signals in the generic bus and the system bus are mapped to
one another.
Table 5-11. Common Connections
From To Special Conditions (if any)
PCLK clock
PRESETn reset
rdata PRDATA Only if the PSEL signal is high
PWDATA wdata
Table 5-12. Writing

PWRITE AND PENABLE wstrobe Only if the PSEL signal is high
wack AND PWRITE PREADY Only if the PSEL signal is high
waddrerr PSLVERR Only if the PSEL AND PWRITE signals are
high
PSTRB Not used
Table 5-13. Reading

PSTRB Z’s
!PWRITE AND PENABLE rstrobe Only if the PSEL signal is high
Rack AND !PWRITE PREADY Only if the PSEL signal is high
raddrerr PSLVERR Only if the PSEL signal is high AND
PWRITE signal is low
Note
The APB PSTRB signal is not supported in the registers generated by Register Assistant and
hence the PSTRB signal is not supported on the bus bridge as well. It will be connected as a
stub.
Note that the register write enables, Write Acknowledge (wack) and Write Address Error
(waddrerr) signals will be asserted when the Write Strobe (wstrobe) is asserted.
Likewise, the Read Data (rdata), Read Acknowledge (rack) and Read Address Error (raddrerr)
signals will be asserted when the Read Strobe (rstrobe) is asserted.
Preparing the Control File

To generate RTL files, you have to write the following command in the control file:
# <comment>
<generator_language>, <generator_name>, <RTL Output Directory/Location>
This is applied as follows:
# Generate the RTL

java, rtl, D:/projects/rtl
The above command can be interpreted as follows:

Table 5-14. RTL Output Command in Control File
Keyword Equivalent Value Description
<generator_name> rtl The name of the java generator.
<RTL Output Directory/ D:/projects/rtl The path of the generated file. If not
Location> specified, the default project location is
used. The default project location is the
path specified by the -project command if
you are using Register Assistant in batch
mode, or the project path of the host
application if you are using Register
Assistant through an interface tool (such as
HDL Designer Series).
Understanding RTL Intrinsic Checks

On invoking the RTL generator through the control file or the GUI some intrinsic checks are
run. These are checks specific to only the RTL generator. They run every time the generator is
invoked. If a check fails a warning or error message appears.
It should be noted that in case an error is produced, the RTL generator stops.
Block Address Range

Checks that the address range for every block is valid.
See the following note and error examples resulting from this check:
# Note: Checking for valid block address range...

# Error: Block 'block_addresses_invalid' has invalid address range
'0xyyy'.
# Error: Checks failed, see more info in the previous log messages.
Instance Addresses
Checks that each block's instances addresses fall within the block address range.
# Note: Checking instances addresses fall within the containing block

address range...
# Error: Block 'block_addresses_instances' has instance 'ireg_out' with
address '0x04' which is out of the block address range '0x02'.
Parameters and Parameter Values

Checks that provided RTL parameters are supported and checks the supplied values for
parameters having pre-defined list of values.
# Note: Checking specified RTL parameters...

# Error: Project 'output' has parameter 'rtl.FILE_NAME' that must
reference variable '%(BLOCK_NAME)'.
# Error: Block 'block_checks_params' has parameter 'rtl.FIELD_NAMING' that
must reference variable '%(REGISTER_INSTANCE_NAME)'.
# Error: Block 'block_checks_params' has parameter 'rtl.FIELD_NAMING' that
references unsupported variable '%(REGISTER_INSTANCE)'.
# Error: Block 'block_checks_params' has inapplicable parameter
'rtl.USE_ALT_RESET'.
# Error: Block 'block_checks_params' has parameter 'rtl.BUS_TYPE' set to
unsupported value 'AMBA_APBx'. Supported values: 'none', 'amba_apb'.
Block Names
Checks that block names are not VHDL or Verilog keywords.
# Note: Checking blocks names are not language keywords...

# Error: Block name 'module' is a Verilog keyword.
# Error: Block name 'if' is a Verilog keyword.
# Error: Block name 'entity' is a VHDL keyword.
# Error: Block name 'ARCHITECTURE' is a VHDL keyword.
Hardware and Software Access Mode Combinations

Checks registers and fields to make sure that HW and SW access mode combinations are valid.
For example, the read-only HW access mode and the read-only SW access mode would be an
invalid combination.
See the following error example resulting from this check:
# Error: Register 'reg_invalid_hw_sw' has invalid SW 'read-only' and HW

'read-only' access modes combination.
Register Output Pulse Parameter Value

Checks that the value of the parameter “rtl.PULSE_OUTPUT” (or the Register Output Pulse
alias) is consistent with the access modes of the register’s fields. Refer to “Changing Read/
Write Enable Local Signals to Output Pulses” under Customizing Generated Output for
information on setting register output pulses.
# Error: Register 'reg_pulse_write' has parameter 'rtl.PULSE_OUTPUT' set

to 'W' while it has no fields with write SW access.
Examining the Generated RTL File

Register Assistant generates an RTL file containing the description of your registers, register
blocks and block maps as extracted from the imported source.
Figure 5-8. Read Write Logic
File Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
File Content
The generated file typically contains a declarations section and register read/write logic
sections.
Declarations Section
The Declarations section contains the Module/Entity port list and various local signals.
Figure 5-9. RTL Code Declarations
1. Module/Entity Port List

The Module/Entity Port list is the interface to the design and contains the “Field Input/
Output signals” and the “Generic Bus signals”.
a. Field Input/Output Ports — All the signals used in the block in addition to any
port signals used in the “custom code” or “user entered code” for any of the block
fields.
Signals are generated using the following naming convention:
<FIELD_NAME>_<REGISTER_INSTANCE_NAME>
b. User IO ports — Any additional ports specified in the input files.

c. Generic Bus Signals — A common set of signals used for the design module/entity
generic bus, namely: clock, reset, waddr, raddr, wdata, rdata, rstrobe and wstrobe.
Refer to the topic “Generic Bus and Bus Bridge” on page 114.
d. Acknowledge Ports — Generic bus acknowledge ports.
2. Local Signals
Local signals are those that are not part of the interface. They can be listed as follows:
a. Write enables for each register with SW write access:
"reg register_we_reg_<regName>
b. MUX inputs for each register with SW read access:

"wire read_mux_input_reg_<regName>
c. Auxiliary Signals:
i. Internal for those not required in the interface
ii. Local for pre-flipflop signals
iii. Local for queued fields
Read/Write Operations Section

Write Operations Section
Contains the write logic on both the register and field levels. Refer to Figure 5-8 on page 121.
1. Write Address Decode Logic — Contains the write address decode and write enable
logic at the register level and is common to all field access modes.
The block’s code starts by initializing a set of local signals: “write enable signals” for all
fields apart from those who have a true read-only access mode, the write acknowledge
“wack” and the write address error “waddrerr” signals.
register_we_CHn_CSR_reg = 1'b0;
register_we_CHn_SZ_reg = 1'b0;
register_we_CHn_A0 = 1'b0;
register_we_CHn_AM0 = 1'b0;
register_we_CHn_AM1 = 1'b0;
register_we_CHn_DESC_reg = 1'b0;
register_we_CHn_SWPTR_reg = 1'b0;
waddrerr = 1'b0;
wack = 1'b0;
This is followed by checking whether the block is in write mode (wstrobe), in which
case the appropriate writable register is asserted write enable and write acknowledge is
set. Otherwise, all write enables for writable registers are cleared as well as the write
acknowledge.
If the write address is not found, assert the write address error flag (waddrerr)
if (wstrobe)
begin
case (waddr)
CHn_CSR_reg_addr :
begin
register_we_CHn_CSR_reg = 1'b1;
end
CHn_SZ_reg_addr :
begin
register_we_CHn_SZ_reg = 1'b1;
end
CHn_A0_addr :
begin
end
..........................
..........................
default :
begin
waddrerr = 1'b1;
end
endcase
wack = 1'b1;
end
end
Note
Fields inside registers with Access value = “Read-Only” have no SW write logic.
2. Register Field Logic — Contains the write logic related to register fields.
Fields within the same register may have different access modes and accordingly
different write logic. For fields with defined HW and SW access modes, SW access
takes precedence over HW access.
The generated code block contains an always block/proc with a common reset portion
for all field access modes and a write logic portion that follows the defined access mode.
// Field logic
always @ (posedge clock)
begin
// Reset
if ( !reset )
<field> <= 'b0;
// SW Access
else if (<SW write enable>)
.. SW access logic goes here
// HW Access (supplied)
else if (<HW condition(s)>)
.. HW access logic goes here
// HW Access (user)
else if (<HW condition(s)>)
<field> <= <field>_hw_next;
end
Examples: Write logic for different field access modes:

//--------------------------------------------------------------
// FIELD: DONE
// WIDTH: 1 , OFFSET: 11
// SW_ACCESS: read-only , HW_ACCESS : read-write
//--------------------------------------------------------------

begin : reg_CHn_CSR_DONE_CHn_CSR_reg
// Reset
if ( !reset )
DONE_CHn_CSR_reg <= 1'b0;
// HW: read-write
else
DONE_CHn_CSR_reg <= DONE_CHn_CSR_reg_ip;
end
//--------------------------------------------------------------
// FIELD: STOP
// WIDTH: 1 , OFFSET: 9
// SW_ACCESS: write-only , HW_ACCESS : read-write
//--------------------------------------------------------------

begin : reg_CHn_CSR_STOP_CHn_CSR_reg
// Reset
if ( !reset )
STOP_CHn_CSR_reg <= 1'b0;
// SW:write-only
else if (register_we_CHn_CSR_reg)
STOP_CHn_CSR_reg <= wdata[9];
// HW: read-write
else
STOP_CHn_CSR_reg <= STOP_CHn_CSR_reg_ip;
end
Read Operations Section
Read logic within a block works on the register level and not the field level. Fields are assigned
to the appropriate locations within the overall register and the register value is assigned to the
read data bus. Register field values are read by the CPU via the read data bus.
1. Defining Read Bus Multiplexer — Contains the logic where readable field values are
loaded into the appropriate locations in the corresponding register.
assign MY_READ_MUX_INPUT_CHN_A0[31:2] = ADDRESS_CHN_A0;
assign MY_READ_MUX_INPUT_CHN_A0[1:0] = DEFAULT_RDATA[1:0];
Customizing Generated Output
2. Assigning Read Register value to the Read Data Bus — Contains the logic that
assigns the register value on the read data bus after checking that the block is in read
mode (rstrobe).
begin : read_bus_mux
// PUT REGISTER VALUE ON READ DATA BUS
MY_REGISTER_RE_CHN_CSR_REG = 1'b0;
MY_READ_ACK = 1'b0;
RADDRERR = 1'b0;
if (MY_RSTROBE )
begin
case (MY_RADDR )
CHN_CSR_REG_ADDR :
begin
MY_RDATA = MY_READ_MUX_INPUT_CHN_CSR_REG;
MY_REGISTER_RE_CHN_CSR_REG = 1'b1;
endbegin
MY_RDATA = MY_READ_MUX_INPUT_CHN_SWPTR_REG;
end
default :
begin
MY_RDATA = DEFAULT_RDATA;
RADDRERR = 1'b1;
end
endcase

The RTL generator produces code assuming a set of defaults, yet it allows you to control and
change these defaults through a set of configuration parameters. It is recommended when using
configuration parameters that you create a separate configuration file where you declare your
parameters and give them new values.
In this section, we will provide examples where parameters can be used for customizing the
generated code. You can refer to the RTL Parameters table for a full list of the supported
parameters and their usage. You can also refer to “Parameters” on page 213.
Changing Names of Generated Files

Generated RTL and bus bridge file names can be controlled using the “rtl.FILE_NAME” and
“rtl.APB_BRIDGE_FILE_NAME” parameters.
Declaring Signals Inferred From Action/Condition Code

Signals referenced in condition/action pairs are inferred and defined as ports under “SIGNALS
INFERRED FROM USER CONDITION-ACTIONS” section. You can optionally disable the
automatic signal inference by setting the parameter “rtl.DECLARE_INFERRED_SIGNALS” to
FALSE and explicitly declare the signals for the block.
Note
1. Condition and actions string parsing is limited so not all cases can be handled.
2. No inference for the width of the signal. Always assumed to be of size 1.
Changing the RTL Code Language

By default, the generated RTL code is Verilog. If you want to change the language of the
generated code to VHDL, you have to set the parameter “rtl.LANGUAGE”.
Controlling the Naming of Design Signals

The RTL generator has a list of default naming conventions for auto-generated signals. You can
use your own naming conventions through providing new values for the naming convention
parameters, thereby allowing the tool to generate code using your standards.
Adding/Removing Custom Ports

In some cases you may want to change the auto-generated input/output signals for associated
fields to be generated as local signals rather than ports.
To do that, you have to declare the “rtl.INPUT_SCOPE” and the “rtl.OUTPUT_SCOPE”

parameters in your configuration file and give them the value “LOCAL” instead of their default
value “PORT”.
Changing Read/Write Enable Local Signals to Output Pulses

By default, Register Assistant creates local signals in the generated output for register “write
enable” and “read enable” signals. See “File Content” on page 121for more information.
Nonetheless, Register Assistant allows you to optionally have those local signals defined as
pulses for output ports instead in the generated RTL code. You can choose to generate pulses
that are read-write, read only, or write only.
This is done by setting the following parameter in the CSV input file. On the level of the
register(s), add two columns for the “Register Parameter Name” and “Register Parameter
Value”.
Table 5-15. Read/Write Output Pulse Parameter
Register Parameter Register De Sc
Name Parameter Value fau op
lt e
rtl.PULSE_OUTPUT RW, R, W or No Re
None. ne gis
ter
An alias “Register Output Pulse” is defined for the “rtl.PULSE_OUTPUT” parameter in the
csv.js file. You can use this alias by adding a single column titled “Register Output Pulse” on
the register level and directly give this column the value RW, R, W or None. Refer to
“Parameters” on page 213 for more information on using parameters.
According to the parameter value you set, Register Assistant will define an output pulse in the
generated code instead of the local signals as follows:
• A read-write pulse is defined if the parameter value is RW.

• A read-only pulse is defined if the parameter value is R.
• A write-only pulse is defined if the parameter value is W.
Make sure that the parameter value you set for a register is consistent with the access modes of
its fields. Register Assistant runs a check during generation and raises an error in case of
inconsistency. See “Understanding RTL Intrinsic Checks” on page 118.
Consider the following register definitions:
In this example, there are two registers each with a single 1-bit field:
• REG1 is designed to show a write pulse (Register Output Pulse set to “W”) and has the
software access mode as RW and the hardware access mode as RO.
• REG2 is designed to show a read pulse (Register Output Pulse set to “R”) and has the
software access mode as R (read-only, no flip-flop) and the hardware access mode as
WO.
The generated output would be as follows for Verilog:
module top
#(
parameter ADDR_WIDTH=4,
parameter DATA_WIDTH=32
)
(
// FIELD OUTPUT PORTS
output reg pulse_field_REG1_inst,
// INPUT PORTS
input wire clear_field_REG2_inst_ip,
// REGISTER READ/WRITE PULSE OUTPUTS

output reg wen_REG1_inst, // Pulse when written
output reg ren_REG2_inst, // Pulse when read
// GENERIC BUS PORTS

input wire clock , // Register Bus Clock
input wire reset , // Register Bus Reset
input wire [ADDR_WIDTH-1:0] waddr , // Write Address-Bus
input wire [ADDR_WIDTH-1:0] raddr , // Read Address-Bus
input wire [DATA_WIDTH-1:0] wdata , // Write Data-Bus
output reg [DATA_WIDTH-1:0] rdata , // Read Data-Bus
input wire rstrobe , // Read-Strobe
input wire wstrobe , // Write-Strobe
output reg raddrerr, // Read-Address-Error
output reg waddrerr, // Write-Address-Error
output reg wack , // Write Acknowledge
output reg rack // Read Acknowledge
);
// MUX INPUTS FOR EACH REGISTER WITH READ ACCESS

wire [DATA_WIDTH-1:0] mux_REG1_inst;
wire [DATA_WIDTH-1:0] mux_REG2_inst;
// DEFAULT VALUE FOR READ DATA BUS

localparam DEFAULT_RDATA = 32'h00000000;
// ADDRESS PARAMETERS
localparam REG1_INST_ADDR = 4'h0;
localparam REG2_INST_ADDR = 4'h4;
//---------------------------------------------------------------------
// WRITE ADDRESS DECODE
//---------------------------------------------------------------------
always @ ( * )
begin : write_enable
wen_REG1_inst = 1'b0;
waddrerr = 1'b0;
wack = 1'b0;
if (wstrobe)
begin
case (waddr)
REG1_INST_ADDR:
begin
wen_REG1_inst = 1'b1;
end
default:
begin
waddrerr = 1'b1;
end
endcase
wack = 1'b1;
end
end
//------------------------------------------------------------
// Register: REG1
// Pulse test
// SW Access : read-write
// Address Offset: 0x0
// HW Access : read-write
// Output Pulse : W (when written)
//
// Instance: REG1_inst
// Pulse test
// Reset Value :
//
// Fields:
// 0 pulse_field (SW:read-write, HW:read-only)
//------------------------------------------------------------
// Field: pulse_field
// SW Access: read-write , HW Access: read-only
//------------------------------------------------------------
begin : reg_reg1_pulse_field_reg1_inst
// Reset
if ( !reset )
pulse_field_REG1_inst <= 1'b0;
// SW:read-write
else if (wen_REG1_inst)
pulse_field_REG1_inst <= wdata[0];
end
//------------------------------------------------------------
// Register: REG2
// Clear test
// Output Pulse : R (when read)
//
// Instance: REG2_inst
// Clear test
// Reset Value :
//
// Fields:
// 0 clear_field (SW:RO-No-Field, HW:write-only)
//------------------------------------------------------------
// Field: clear_field
// SW Access: RO-No-Field , HW Access: write-only
//------------------------------------------------------------
//---------------------------------------------------------------------
// READ BUS MULTIPLEXER
//---------------------------------------------------------------------
assign mux_REG1_inst[31:1] = DEFAULT_RDATA[31:1]; // Default read value
for un-assigned portion
assign mux_REG1_inst[0] = pulse_field_REG1_inst;
assign mux_REG2_inst[31:1] = DEFAULT_RDATA[31:1]; // Default read value

for un-assigned portion
assign mux_REG2_inst[0] = clear_field_REG2_inst_ip;
always @ ( * )
ren_REG2_inst = 1'b0;
rack = 1'b0;
raddrerr = 1'b0;
if (rstrobe )
begin
case (raddr )
REG1_INST_ADDR:
begin
rdata = mux_REG1_inst;
end
REG2_INST_ADDR:
begin
rdata = mux_REG2_inst;
ren_REG2_inst = 1'b1;
end
default:
begin
rdata = DEFAULT_RDATA;
raddrerr = 1'b1;
end
endcase
rack = 1'b1;
end
else
begin
rdata = DEFAULT_RDATA;
end
end
endmodule
Entering Data to Register Assistant
Figure 5-10. Generating RTL for a Simple Design
Let us imagine a simple case where a system consists of a processor communicating with
several H/W devices through the system bus. Each device is assigned some address range in the
address space (that is, when the processor needs to communicate with one device, it needs to set
the address to a value in that range). The processor and the H/W devices communicate with one
another through CSR (Control Status Registers).

Register Assistant provides the means to automate the creation of the CSR interface in a bottom
up manner. In this example, you will use CSV format to define your registers.
Procedure
1. First define each register in the system by defining the following attributes:
a. Register Name
b. Register Width
c. Register Access
d. Register HW Access
e. Register Reset Value

f. Fields in that register with the following attributes for each (Field Name, Field
Offset, Field Width, Field Access (software access mode), Field HW Access
(hardware access mode) and Field Reset Value).
Table 5-16. Register Definition CSV File for the Simple Design Example
Register Register Register Register Register Field Field Field Field Field Field
Name Width Access HW Reset Name Offset Width Access HW Reset
Access Value Access Value
reg1 32 rw rw 0x0 fld1_reg1 0 12 rw ro 0x0
reg1 fld2_reg1 12 20 rw rw 0x0
reg2 32 rw rw 0x0 fld1_reg2 0 4 rw1c rw 0x0
reg2 fld2_reg2 4 12 rw wo 0x0
reg2 fld3_reg2 16 16 ro wo 0x0
2. Start creating register instances in blocks. Define the following:

a. Block Name
b. Block Maps
c. Components instanced in each block with the following attributes [Instance Name,
Instance address in the block map]. The CSV input files for this design would look
like those in Table 5-16 and Table 5-17.
Table 5-17. Block Definition CSV File for the Simple Design Example
Block Name Block Block BlockMap BlockMap BlockMap
Component Instance Name Instance Instance
Name Name Name Address
deviceX reg1 i1_reg1 Default i1_reg1 0x00
3. In our example you will:

a. Set the language of the generated output as Verilog 2005.
b. Set the bus type as AMBA_APB.
c. Set the default type for scalar inputs as “wire”.
d. Use the prefix “my_we” for the write enable signals.
What to Specify in the Control File
e. Set the default type for array inputs as “wire”.

To do so, you should create a configuration file in which you define new values for the
parameters: rtl.LANGUAGE, rtl.BUS_TYPE,
rtl.DEFAULT_SCALAR_INPUT_TYPE, rtl.WRITE_ENABLE_PREFIX and
rtl.DEFAULT_VECTOR_INPUT_TYPE.
Table 5-18. Parameter Definitions for the Simple Design Example

Block Name Block Parameter Name Block Parameter
Value
deviceX rtl.LANGUAGE VLOG_2005
deviceX rtl.BUS_TYPE AMBA_APB
deviceX rtl.DEFAULT_SCALAR_INPUT_TYP wire
E
deviceX rtl.WRITE_ENABLE_PREFIX my_we
deviceX rtl.DEFAULT_VECTOR_INPUT_TYP wire
E
4. In a design with multiple blocks, add all our design blocks in a top block giving each
block an address offset with respect to the address space. (In the example, the device
needs to be put in address Offset 0x10.)

After completing our register definition files, you are ready to start preparing the Register
Assistant control file. In the control file, you will specify the path to the design input files and
the CSV mapping file. You will choose to run the RA checks and finally run the RTL generator.
# Import the register definition files
js, $(RA_HOME)/examples/csv.js , deviceX ,csv/register_definitions.csv,
csv/ExampleBlock.csv, csv/ConfigExample.csv

js, $(RA_HOME)/examples/checks.js
# Run checks
# Generate the RTL

java, rtl
Generated Code Description

Declarations Section
//----------------------------------------------------------------------
// Block : deviceX
// Address Range : 0xC
//----------------------------------------------------------------------
module deviceX
#(
)
(
output reg [19:0] fld2_reg1_i1_reg1,
// INPUT PORTS
input wire [19:0] fld2_reg1_i1_reg1_ip,

);
// READ/WRITE ENABLE SIGNALS

reg register_we_i1_reg1;

wire [DATA_WIDTH-1:0] read_mux_input_i1_reg1;
// FLIP-FLOP SIGNALS
reg [15:0] fld3_reg2_i2_reg2_local;
reg [11:0] fld2_reg2_i2_reg2_local;

localparam DEF_RDATA_VAL = 32'h00000000;
localparam I1_REG1_ADDR = 4'h0;
Write Operations Section

Address Decoding/Register Level Function
//----------------------------------------------------------------------
// WRITE ADDRESS DECODE
//--------------------------------------------------------------------
always @ ( * )
begin : write_enable
register_we_i1_reg1 = 1'b0;
waddrerr = 1'b0;
wack = 1'b0;
if (wstrobe)
begin
case (waddr)
I1_REG1_ADDR:
begin
end
I2_REG2_ADDR:
begin
end
I3_REG1_ADDR:
begin
end
default:
begin
waddrerr = 1'b1;
end
endcase
wack = 1'b1;
end
end
Write Operations/ Field Level Functions
//------------------------------------------------------------
// Register: reg1
// Address Offset:
//
// Instance: i1_reg1
// Reset Value :
//
// Fields:
// 31:12 fld2_reg1 (SW:read-write, HW:read-write)
// 11:0 fld1_reg1 (SW:read-write, HW:read-only)
//------------------------------------------------------------
// Field: fld2_reg1
// SW Access: read-write , HW Access: read-write
//------------------------------------------------------------
begin : reg_reg1_fld2_reg1_i1_reg1
// Reset
if ( !reset )
fld2_reg1_i1_reg1 <= 20'h00000;
// SW:read-write
else if (register_we_i1_reg1)
fld2_reg1_i1_reg1 <= (wdata[31:12]);
// HW:read-write
else
fld2_reg1_i1_reg1 <= fld2_reg1_i1_reg1_ip;
end
//------------------------------------------------------------
// Field: fld1_reg1
//------------------------------------------------------------
// Reset
if ( !reset )
fld1_reg1_i1_reg1 <= 12'h000;
// SW:read-write
end
//------------------------------------------------------------
// Register: reg2
// Address Offset:
//
// Reset Value :
//
// Fields:
// 31:16 fld3_reg2 (SW:read-only, HW:write-only)
// 15:4 fld2_reg2 (SW:read-write, HW:write-only)
// 3:0 fld1_reg2 (SW:RW-Write-1-to-Clear, HW:read-write)
//------------------------------------------------------------
// Field: fld3_reg2
// SW Access: read-only , HW Access: write-only
//------------------------------------------------------------
begin : reg_reg2_fld3_reg2_i2_reg2_local
// Reset
if ( !reset )
fld3_reg2_i2_reg2_local <= 16'h0000;
// HW:write-only
else
fld3_reg2_i2_reg2_local <= fld3_reg2_i2_reg2_ip;
end
//------------------------------------------------------------
// Field: fld2_reg2
// SW Access: read-write , HW Access: write-only
//------------------------------------------------------------
begin : reg_reg2_fld2_reg2_i2_reg2_local
// Reset
if ( !reset )
fld2_reg2_i2_reg2_local <= 12'h000;
// SW:read-write
fld2_reg2_i2_reg2_local <= (wdata[15:4]);
// HW:write-only
else
end
//------------------------------------------------------------
// Field: fld1_reg2
// SW Access: RW-Write-1-to-Clear , HW Access: read-write
//------------------------------------------------------------
// Reset
if ( !reset )
fld1_reg2_i2_reg2 <= 4'h0;
// SW:RW-Write-1-to-Clear
fld1_reg2_i2_reg2 <= (fld1_reg2_i2_reg2 & ~wdata[3:0]);
// HW:read-write
else
end
//------------------------------------------------------------
// Register: reg1
// Address Offset:
//
// Reset Value :
//
// Fields:
// 31:12 fld2_reg1 (SW:read-write, HW:read-write)
// 11:0 fld1_reg1 (SW:read-write, HW:read-only)
//------------------------------------------------------------
// Field: fld2_reg1
//------------------------------------------------------------
// Reset
if ( !reset )
fld2_reg1_i3_reg1 <= 20'h00000;
// SW:read-write
// HW:read-write
else
end
//------------------------------------------------------------
// Field: fld1_reg1
//------------------------------------------------------------
// Reset
if ( !reset )
fld1_reg1_i3_reg1 <= 12'h000;
// SW:read-write
end
Read Operation Section

//----------------------------------------------------------------------
//--------------------------------------------------------------------
assign read_mux_input_i1_reg1[31:12] = fld2_reg1_i1_reg1;
assign read_mux_input_i2_reg2[31:16] = fld3_reg2_i2_reg2_local;

assign read_mux_input_i2_reg2[15:4] = fld2_reg2_i2_reg2_local;

always @ ( * )
rack = 1'b0;
raddrerr = 1'b0;
if (rstrobe )
begin
case (raddr )
I1_REG1_ADDR:
begin
rdata = read_mux_input_i1_reg1;
end
I2_REG2_ADDR:
begin
end
I3_REG1_ADDR:
begin
end
default:
begin
rdata = DEF_RDATA_VAL;
raddrerr = 1'b1;
end
endcase
rack = 1'b1;
end
else
begin
end
end
endmodule
VHDL Version of Simple Design Example

ENTITY deviceX IS
------------------------------------------------------------------------
PORT
(
-- FIELD OUTPUT PORTS
fld2_reg1_i1_reg1 : OUT std_logic_vector (19 DOWNTO 0);
fld1_reg2_i2_reg2 : OUT std_logic_vector (3 DOWNTO 0) ;
-- INPUT PORTS
fld2_reg1_i1_reg1_ip : IN wire (19 DOWNTO 0);
fld1_reg2_i2_reg2_ip : IN wire (3 DOWNTO 0) ;
-- GENERIC BUS PORTS

clock : IN wire ; -- Register Bus Clock
reset : IN wire ; -- Register Bus Reset
waddr : IN wire (3 DOWNTO 0) ; -- Write Address-Bus
raddr : IN wire (3 DOWNTO 0) ; -- Read Address-Bus
wdata : IN wire (31 DOWNTO 0); -- Write Data-Bus
rdata : OUT std_logic_vector (31 DOWNTO 0); -- Read Data-Bus
rstrobe : IN wire ; -- Read-Strobe
wstrobe : IN wire ; -- Write-Strobe
raddrerr : OUT std_logic ; -- Read-Address-Error
waddrerr : OUT std_logic ; -- Write-Address-Error
wack : OUT std_logic ; -- Write Acknowledge
rack : OUT std_logic -- Read Acknowledge
);
END ENTITY deviceX;
------------------------------------------------------------------------
ARCHITECTURE deviceX_arch OF deviceX IS
------------------------------------------------------------------------
-- READ/WRITE ENABLE SIGNALS
SIGNAL my_wei1_reg1 : std_logic ;
-- MUX INPUTS FOR EACH REGISTER WITH READ ACCESS

SIGNAL read_mux_input_i1_reg1 : wire (31 DOWNTO 0);
-- AUXILIARY SIGNALS
SIGNAL fld2_reg1_i1_reg1_buf : wire (19 DOWNTO 0);
SIGNAL fld3_reg2_i2_reg2_local : wire (15 DOWNTO 0);
SIGNAL fld2_reg2_i2_reg2_local : wire (11 DOWNTO 0);
SIGNAL fld1_reg2_i2_reg2_buf : wire (3 DOWNTO 0) ;
-- DEFAULT VALUE FOR READ DATA BUS

CONSTANT DEF_RDATA_VAL : wire(31 DOWNTO 0) := (OTHERS => '0');
-- ADDRESS PARAMETERS
CONSTANT I1_REG1_ADDR : wire := "0000"; -- 'h00
BEGIN
-----------------------------------------------------------------------
-- WRITE ADDRESS DECODE
-----------------------------------------------------------------------
write_enable : PROCESS (waddr , wstrobe)
BEGIN
my_wei1_reg1 <= '0';
waddrerr <= '0';
IF (wstrobe = '1') THEN

CASE waddr IS
WHEN I1_REG1_ADDR =>
WHEN OTHERS =>
waddrerr <= '1';
END CASE;
END IF;
wack <= wstrobe;
END PROCESS write_enable;
--------------------------------------------------------------
-- Register: reg1
-- SW Access : read-write
-- Address Offset:
-- HW Access : read-write
--
-- Instance: i1_reg1
-- Address Offset: 0x00
-- Reset Value :
--
-- Fields:
-- 31:12 fld2_reg1 (SW:read-write, HW:read-write)
-- 11:0 fld1_reg1 (SW:read-write, HW:read-only)
--------------------------------------------------------------
-- Field: fld2_reg1
-- Width: 20 , Offset: 12
-- SW Access: read-write , HW Access: read-write
--------------------------------------------------------------
reg_reg1_fld2_reg1_i1_reg1 : PROCESS (clock, reset)
BEGIN
-- Reset
IF (reset = '0') THEN
fld2_reg1_i1_reg1_buf <= (OTHERS => '0');

ELSIF (clock'EVENT) AND (clock = '1') THEN
-- SW:read-write
IF (my_wei1_reg1 = '1') THEN
fld2_reg1_i1_reg1_buf <= wdata(31 DOWNTO 12);
-- HW:read-write
ELSE
fld2_reg1_i1_reg1_buf <= fld2_reg1_i1_reg1_ip;
END IF;
END IF;
END PROCESS reg_reg1_fld2_reg1_i1_reg1;
-- Assign internal buffer value to output

fld2_reg1_i1_reg1 <= fld2_reg1_i1_reg1_buf;
--------------------------------------------------------------
-- Field: fld1_reg1
-- SW Access: read-write , HW Access: read-only
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:read-write
END IF;
END IF;

--------------------------------------------------------------
-- Register: reg2
-- Address Offset:
--
-- Reset Value :
--
-- Fields:
-- 31:16 fld3_reg2 (SW:read-only, HW:write-only)
-- 15:4 fld2_reg2 (SW:read-write, HW:write-only)
-- 3:0 fld1_reg2 (SW:RW-Write-1-to-Clear, HW:read-write)
--------------------------------------------------------------
-- Field: fld3_reg2
-- SW Access: read-only , HW Access: write-only
--------------------------------------------------------------
reg_reg2_fld3_reg2_i2_reg2_local : PROCESS (clock, reset)
BEGIN
-- Reset
fld3_reg2_i2_reg2_local <= (OTHERS => '0');
-- HW:write-only
END IF;
END PROCESS reg_reg2_fld3_reg2_i2_reg2_local;
--------------------------------------------------------------
-- Field: fld2_reg2
-- SW Access: read-write , HW Access: write-only
--------------------------------------------------------------
reg_reg2_fld2_reg2_i2_reg2_local : PROCESS (clock, reset)
BEGIN
-- Reset
fld2_reg2_i2_reg2_local <= (OTHERS => '0');
-- SW:read-write
fld2_reg2_i2_reg2_local <= wdata(15 DOWNTO 4);
-- HW:write-only
ELSE
END IF;
END IF;
END PROCESS reg_reg2_fld2_reg2_i2_reg2_local;
--------------------------------------------------------------
-- Field: fld1_reg2
-- SW Access: RW-Write-1-to-Clear , HW Access: read-write
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:RW-Write-1-to-Clear
fld1_reg2_i2_reg2_buf <= (fld1_reg2_i2_reg2_buf AND (NOT wdata(3
DOWNTO 0)));
-- HW:read-write
ELSE
END IF;
END IF;

--------------------------------------------------------------
-- Register: reg1
-- Address Offset:
--
-- Reset Value :
--
-- Fields:
-- 31:12 fld2_reg1 (SW:read-write, HW:read-write)
-- 11:0 fld1_reg1 (SW:read-write, HW:read-only)
--------------------------------------------------------------
-- Field: fld2_reg1
-- SW Access: read-write , HW Access: read-write
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:read-write
-- HW:read-write
ELSE
END IF;
END IF;

--------------------------------------------------------------
-- Field: fld1_reg1
-- SW Access: read-write , HW Access: read-only
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:read-write
END IF;
END IF;

RTL Alternative Resets
-----------------------------------------------------------------------
-- READ BUS MULTIPLEXER
-----------------------------------------------------------------------
read_mux_input_i1_reg1(31 DOWNTO 12) <= fld2_reg1_i1_reg1_buf;
read_mux_input_i2_reg2(31 DOWNTO 16) <= fld3_reg2_i2_reg2_local;

read_mux_input_i2_reg2(15 DOWNTO 4) <= fld2_reg2_i2_reg2_local;

-- PUT REGISTER VALUE ON READ DATA BUS

read_bus_mux : PROCESS (rstrobe,
raddr,
read_mux_input_i1_reg1,
read_mux_input_i2_reg2,
read_mux_input_i3_reg1)
BEGIN
rack <= '0';
raddrerr <= '0';
rdata <= DEF_RDATA_VAL;
IF (rstrobe = '1') THEN
CASE raddr IS
rdata <= read_mux_input_i1_reg1;
WHEN OTHERS =>
raddrerr <= '1';
END CASE;
rack <= '1';
END IF;
END PROCESS read_bus_mux;
END ARCHITECTURE deviceX_arch;

Register Assistant supports alternative resets when generating RTL code. This feature can be
useful for example when using retention registers, to preserve data while a device is switched
off.
You can define an alternative reset signal for the register, separate from the main reset signal.
This is achieved by using certain parameters in the input files. Refer to “Parameters” on
page 213 for further details.
When importing register definitions from CSV files, you need to do the following:
Procedure
1. Specify that the register requires an alternative reset. This is done through adding the
following parameter columns on the register level:
Table 5-19. Retention Registers — Step 1

Register Parameter Name Register Parameter Value
rtl.USE_ALT_RESET True
The parameter “rtl.USE_ALT_RESET” is false by default. To indicate that a register

has an alternative reset, you have to explicitly add the corresponding parameter and set it
as “true” as shown in the above table.
2. Specify the following attributes for the alternative reset signal on the level of the block:
• Name: specify the name of the alternative reset signal. The default is “alt_reset”.
• Style: specify whether the behavior of the reset signal is synchronous or
asynchronous. The default is asynchronous.
• Active level: specify whether high or low. The default is low.
• Prefix: specify the label for the always blocks using the alternative reset signal. The
default prefix is “ret_”.
The following table shows an example for the above attributes:
Table 5-20. Retention Registers — Step 2

Block Parameter Name Block Parameter Value
rtl.ALT_RESET_NAME my_alt_reset
rtl.ALT_RESET_STYLE SYNC
rtl.ALT_RESET_ACTIVE_LEVEL HIGH
rtl.ALT_RESET_BLOCK_LABEL_PREFIX my_reten_
Note
Once you indicate the use of an alternative reset signal for a specific register (as
explained in step1), this alternative register will be used in the block containing the
register with the default attributes. If you need to specify attributes different from the
default, you have to explicitly set them on the block level (as explained in step 2).
3. When importing register definitions from JavaScript files, you can specify that the
register requires an alternative reset using the following API:
register_name.addParameter ("rtl.USE_ALT_RESET", "True", "Using an
alternative reset.");
4. Similarly, you can specify the following attributes for the alternative reset signal on the
level of the block as follows:
block_name.addParameter ("rtl.ALT_RESET_NAME", "my_alt_reset", "The
name of the alternative reset signal.");
block_name.addParameter ("rtl.ALT_RESET_STYLE", "SYNC", "The style
of the alternative reset.");
block_name.addParameter ("rtl.ALT_RESET_ACTIVE_LEVEL", "HIGH", "The
active level of the alternative reset.");
block_name.addParameter ("rtl.ALT_RESET_BLOCK_LABEL_PREFIX",
"my_reten_", "The label for always blocks using the alternative
reset.");
Examples
This is an example of RTL code generated by Register Assistant. Note the use of alternative
resets in the example.
module block_reten_custom
#(
)
(
output reg fld_reten_ireg_reten,
// Following the example in Table 5-20, the alternative reset

“my_alt_reset” is used in the generated code.
// INPUT PORTS
input wire my_alt_reset , // Alternative Reset
input wire fld_reten_ireg_reten_ip,

);

wire [DATA_WIDTH-1:0] read_mux_input_ireg_reten;

localparam DEF_RDATA_VAL = 10'b0000000000;
localparam IREG_RETEN_ADDR = 2'b00;
//------------------------------------------------------------
// Register: reg_reten
// Alt Reset : my_alt_reset (SYNC)
//
// Instance: ireg_reten
// Reset Value :
//
// Fields:
// 0 fld_reten (SW:read-only, HW:read-write)
//------------------------------------------------------------
RTL Software Resets
// Field: fld_reten
// SW Access: read-only , HW Access: read-write
//------------------------------------------------------------
// Note that the prefix determined in Table 5-20 is used below in the
always block.

begin : my_reten_reg_reg_reten_fld_reten_ireg_reten
// Reset
if ( my_alt_reset )
fld_reten_ireg_reten <= 1'b0;
// HW:read-write
else
fld_reten_ireg_reten <= fld_reten_ireg_reten_ip;
end
//--------------------------------------------------------------------
//--------------------------------------------------------------------
assign read_mux_input_ireg_reten[9:1] = DEF_RDATA_VAL[9:1]; // Default
read value for un-assigned portion
assign read_mux_input_ireg_reten[0] = fld_reten_ireg_reten;
always @ ( * )
rack = 1'b0;
raddrerr = 1'b0;
if (rstrobe )
begin
case (raddr )
IREG_RETEN_ADDR:
begin
rdata = read_mux_input_ireg_reten;
end
default:
begin
raddrerr = 1'b1;
end
endcase
rack = 1'b1;
end
else
begin
end
end
endmodule
RTL Software Resets

Register Assistant supports software resets when generating RTL code.
RTL Software Resets
A software reset enables you to change register values based on the occurrence of certain
triggers. It is specified on the field level. If a register has no declared fields, it can be specified
for the default field and thus affect the whole register. Moreover, one or more soft reset can be
specified for a single field.
In the Register assistant generated code a hard reset takes precedence over any of the optionally
defined software resets.
When importing register definitions from CSV files, you need to specify the soft reset signal,
the reset action and an optional comment to describe it. This is done through adding the
following CSV columns:
Table 5-21. Software Reset Input Example— CSV Columns
Soft Reset Column Name Soft Reset Column Value
Field Soft Reset Condition soft_reset
Field Soft Reset Action 16'h0000
Field Soft Reset Comment Soft reset for field1
When importing register definitions from JavaScript files, you can specify register software
resets using the following API:
addSoftResetConditionalLogic
Example
This is an example to show how field soft reset conditions are defined in Register Assistant and
how they appear in the generated code. In this example, we have two registers: Reg1 and Reg2.
Reg1 is a register with two fields and Reg2 is a register with no fields. Examine the CSV input
file and notice the field soft reset condition, field soft reset action and field soft reset comment
columns.
The resulting Verilog write logic code would be as follows:
The code starts by automatically declaring signals found in the soft reset conditions/actions
columns that have not been declared elsewhere. These declarations can be enabled/disabled by
the parameter “rtl.DECLARE_INFERRED_SIGNALS”.
RTL Software Resets
// SIGNALS INFERRED FROM USER CONDITION-ACTIONS

input wire soft_reset,
input wire srst,
input wire sample,
input wire [2:0] rcv_bit_cnt_cld,
……
//------------------------------------------------------------
// Register: reg1
// Reg with fields
//
// Instance: reg1_reg
// inst1
// Reset Value :
//
// Fields:
// 31:16 field1 (SW:read-write, HW:read-write)
// 15:0 field2 (SW:read-write, HW:read-write)
In the Register Field logic part of the code the soft reset will always be the first tested after the
hardware reset. The general order is:
1. HW (global) reset (sync or async)

2. Optional soft reset
3. SW access or optional byte/word enable
4. HW access or optional user conditions/actions
Field condition /action column values are generated in the code as entered in the input files. i.e.
No translation functions are applied, so a reset action of value 0 for field1 will be generated as:
else if (soft_reset)
field1_reg1_reg <= 0;
and not
field1_reg1_reg <= 16'h0000;
RTL Software Resets
//------------------------------------------------------------
// Field: field1
//------------------------------------------------------------
// field1
//
begin : reg_reg1_field1_reg1_reg
// Reset
if ( !reset )
// Soft Reset
field1_reg1_reg <= 16'h0000; // Soft reset for field1
// SW:read-write
else if (wen_reg1_reg)
field1_reg1_reg <= wdata[31:16];
// HW:read-write
else
field1_reg1_reg <= field1_reg1_reg_ip;
end
//------------------------------------------------------------
// Field: field2
//------------------------------------------------------------
// field2
//
begin : reg_reg1_field2_reg1_reg
// Reset
if ( !reset )
// Soft Reset
else if (srst)
field1_reg1_reg <= 16'h1111; // Soft reset for field2
// SW:read-write
field2_reg1_reg <= wdata[15:0];
// HW:read-write
else
field2_reg1_reg <= field2_reg1_reg_ip;
end
For reg2 no fields are specified, Register assistant declares a default field and applies the
defined soft reset condition/action to it.
RTL Byte Enable Support
//------------------------------------------------------------
// Register: reg2
// Reg with no fields
// Address Offset: 0xc
//
// inst2
// Reset Value :
//
// Fields:
// 31:0 def_fld (SW:read-write, HW:read-write)
//------------------------------------------------------------
// Field: def_fld
//------------------------------------------------------------
// Default field for entire register - reg2
//
begin : reg_reg2_def_fld_reg2_reg
// Reset
if ( !reset )
def_fld_reg2_reg <= 32'h00000000;
// Soft Reset
else if (sample && rcv_bit_cnt_cld == 7)
def_fld_reg2_reg <= 32'hFC; // Soft reset for reg2
// SW:read-write
def_fld_reg2_reg <= wdata;
// HW:read-write
else
def_fld_reg2_reg <= def_fld_reg2_reg_ip;
end
Note
For WO-WRITE-ONCE and RW-WRITE-ONCE access modes you will not be able to reset
the write once flag.

Register data access is a main factor in deciding how this data is divided within a register.
Typically an entire register is used to hold specific data. Data can also be split amongst fields.
Byte enable signals give you control over which bytes within a given register can be accessed.
Register Assistant supports byte enable for registers having any number of fields, fields whose
widths are not multiple of 8, and fields with offset. For each field, if the enclosing register is
byte enabled, write logic is controlled with the appropriate byte enable bits.
The width of the byte_en signal depends on the size of largest register within a block using byte
enables. For a 64 bit register, Register Assistant will declare a byte enable signal of width 8 and
will generate the necessary write logic for the register fields.
When importing register definitions from CSV files, you need to do the following:
Procedure
1. Specify the register byte enable mode. Register Enable Mode can be “BYTE” or
“NONE” (or blank). This is done through the following parameter:
Table 5-22. Byte Enable Mode — Step 1

Register Parameter Name Register Parameter Value Default Scope
rtl.ENABLE_MODE BYTE - NONE None Register
An alias “Register Enable Mode” is defined for the “rtl.Enable_Mode” parameter in the
csv.js file.You can use this alias if you want to use a single column to define the register
enable mode. Refer to “Parameters” on page 213 for more information on using
parameters.
2. Optionally specify the byte_enable signal name and level or use the default values using
the parameters in Table 5-23
Table 5-23. Byte Enable Signal Name and Level— Step 2

Register Parameter Name Register Parameter Value Default Scope
rtl.BYTE_ENABLE_NAME <string> - byte_en byte_en Block
rtl.BYTE_ENABLE_LEVEL LOW - HIGH HIGH Block
Examples
This is an example to show how we can direct Register Assistant to use byte enable signals for
specific registers and how they appear in the generated code. Examine the CSV input file and
notice that we have used the Register Enable Mode alias for the “rtl.Enable_Mode” parameter.
reg2 is a byte enabled register which has a single 32 bits size default field.
// BYTE ENABLE INPUT PORTS
Using the input in the example CSV file, Register Assistant declares a byte enable signal of
width 4 and gives it the default name “byte_en” as no other name value has been declared.
input wire [3:0] byte_en,
// SIGNALS INFERRED FROM USER CONDITION-ACTIONS

input wire def_fld_reg2_reg_ip,
input wire sop ,
input wire eop ,
…
//------------------------------------------------------------
// Register: reg2
// Byte enabled reg
// Enable Mode : Byte
// inst2
// Reset Value : 0
//
// Fields:
// 31:0 def_fld (SW:read-write, HW:read-write)
//------------------------------------------------------------
// Field: def_fld
//------------------------------------------------------------
begin : reg_reg2_def_fld_reg2_reg
// Reset
if ( !reset )
def_fld_reg2_reg <= 32'h00000000;
Write logic generated is based on the register size and the field SW access mode defined. The
access mode logic within each enabled byte is the same as if the register had a single field but
split into byte-sized sections.
Understanding RTL Field Signal Naming and Scope
// SW:read-write
begin
if (byte_en[0])
def_fld_reg2_reg[31:24]<= wdata[31:24];
if (byte_en[1])
if (byte_en[2])
if (byte_en[3])
def_fld_reg2_reg[7:0] <= wdata[7:0];
end
// HW (customized)
else if (eop)
def_fld_reg2_reg <= 0; // Clear if eop
else if (sop)
def_fld_reg2_reg <= 1; // Set if sop
else
def_fld_reg2_reg <= def_fld_reg2_reg_ip; // Otherwise assign value
of input
end

The exact naming of generated field signals depends on the field naming rule parameter setting
(rtl.FIELD_NAMING), the identifier case setting (rtl.IDENTIFIER_CASE), and whether the
signal is an input/output port for the block module or a local signal.
In turn, whether the signal is a port or a local signal depends on the access type and field scope
parameter settings (rtl.INPUT_SCOPE and rtl.OUTPUT_SCOPE).
Refer to the RTL Parameters and RTL Variables reference tables. You can also refer to
“Parameters” on page 213.
Field and Input Signal Naming

The default value of the “rtl.FIELD_NAMING” parameter is:
%(FIELD_NAME)_%(REGISTER_INSTANCE_NAME)
Note that this naming convention should include the use of both the %(FIELD_NAME) and
%(REGISTER_ INSTANCE _NAME) variables somewhere within the expression.
This is the name that will be used for the field signal if it can be a port, otherwise, a “_local”
suffix will be added to indicate it is a local signal. Refer to Field Scope, below.
Which field input signals are generated depends on the HW access type for the field. The signal
will be of the form:
<generated field name>_<suffix>
where:
• <generated field name> is the field name defined by the “rtl.FIELD_NAMING”

parameter mentioned above.
• <suffix> is specified by the various “rtl.FIELD_INPUT_*_SUFFIX” naming rule
parameters.
The case of the field name, field input signals and other identifiers is controlled by the
“rtl.IDENTIFIER_CASE” parameter which can have the values “UPPER”, “LOWER” or
“ASIS”. The default is “ASIS” so the case of the characters is unchanged.
Field Scope
Two additional field parameters can be used to control whether the generated input signals
(rtl.INPUT_SCOPE) and field signals (rtl.OUTPUT_SCOPE) are defined as ports or local
signals. Note that these parameters must be associated with individual fields and cannot be set
for the block or project.
The default value for these two parameters is “PORT”, however, there are a number of
conditions when the field signal in particular will always be a local signal rather than a port.
This is summarized in Table 5-24.
Table 5-24. RTL Field Signal Naming and Scope
Access Ports
SW HW IN PORT OUT PORT or Notes
LOCAL FIELD
All except RO N Specified by No input since HW
“R” rtl.OUTPUT_SCOPE access is read-only.
All except RW Specified by Specified by
“R” rtl.INPUT_SCOPE rtl.OUTPUT_SCOPE
All except RW0C Specified by Specified by
All except RW1C Specified by Specified by
All except RW0S Specified by Specified by
All except RW1S Specified by Specified by
Table 5-24. RTL Field Signal Naming and Scope (cont.)

Access Ports
SW HW IN PORT OUT PORT or Notes
LOCAL FIELD
All except RW0T Specified by Specified by
All except RW1T Specified by Specified by
All except WO Specified by Field always Local, no
“R” rtl.INPUT_SCOPE output.
All except WO1 Specified by Field always Local, no
All except W1S Specified by Field always Local, no
All except W0S Specified by Field always Local, no
All except W1C Specified by Field always Local, no
All except W0C Specified by Field always Local, no
All except NONE None Field always Local, no Field behaves as a
“R” output. pure memory no IP
or OP (but requires
SW field logic).
All except User If user conditions. Specified by HW access defaults
“R” rtl.OUTPUT_SCOPE to RO.
R If Specified by None
requires rtl.INPUT_SCOPE
write
logic.
R If does None None
not
require
write
logic.
RTL Write/Read Pipelining

The pipelining feature enables you to split the write enable and read mux logic into two banks of
smaller muxes with pipeline flip-flops in between.Optionally, you can add flip-flops to the mux
outputs. Pipelining helps you avoid critical mux paths that can result from having a large
decoder for write decoding or a large multiplexer for read decoding.
Pipelining Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Pipelining Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Pipelining Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Pipelining RTL Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Pipelining Overview
Generating RTL output for a large input of register definitions may result in a large decoder for
write decoding and a large multiplexer for read decoding. These conditions may lead to critical
mux paths. Register Assistant’s pipelining feature helps you overcome critical mux paths and
avoid synthesis problems.
By default, Register Assistant generates an RTL file containing the description of registers,
register blocks, block maps, and the definition of core and optional signals. The content of the
generated output depends on the register definitions you provide in the input file and on the
configuration of RTL parameters. The default architecture of Register Assistant’s RTL
generated output file comprises a separate VHDL architecture or Verilog block for each register
block, in addition to the core signals and optional signals.
The core signals are as follows:
• Write enable (demux) that asserts the appropriate register enable signal
• Read mux that assigns appropriate register content to RDATA
• Data, address, and control signals for both read and write “generic” buses
As part of the core signals, the generated file contains write address decode and write enable
logic on both the register and field level. The generated file also contains read logic where the
read bus multiplexer is defined.
The optional signals are as follows:
• Field inputs/outputs for hardware read/write access

• Combinatorial condition logic inputs
• Soft reset inputs
• Byte Enable control input
• “Written to”/”Read from” pulse outputs

• External read input/external write signals
If you have a large bank of register definitions, you can use the pipelining feature. Register
Assistant supports up to two stages of pipelining. The first stage of pipelining enables you to
split the write enable and read mux logic into two sets of smaller muxes with pipeline flip-flops
in between. You can insert a second stage of pipelining by adding flip-flops to the mux outputs.
Tip
The default behavior of Register Assistant, when the pipelining feature is not used, is
referred to as zero-stage pipelining.
The following figure shows an abstract illustration of the two-stage pipelining concept.
Figure 5-11. Two-Stage Pipelining
You can choose the number of pipelining stages. If you generate one pipelining stage, the RTL
generator creates one level of flip-flops and two levels of muxes. If you generate two pipelining
stages, the RTL generator creates two levels of flip-flops and two levels of muxes.
Table 5-25. Pipelining Stages and Corresponding Flip-Flop and Mux Levels
Number of Stages Maximum Number of Flip- Maximum Number of Mux
Flop Levels Levels
0 0 1
1 1 2
2 2 2
The following figure shows an illustration of an overall flow of a one-stage read and one-stage
write pipelining as an example.
Figure 5-12. Overall Flow of One-Stage Read and Write Pipelining
The register input file should contain at least three writable/readable registers for each block
you pipeline. If you apply write pipelining to a block, it should contain at least three writable
registers. Similarly, if you apply read pipelining to a block, it should contain at least three
readable registers.
Related Topics
Pipelining Parameters
Pipelining Checks
Pipelining RTL Output
For Register Assistant to apply pipelining to the generated code, you have to use the
corresponding parameters in your register definition input files.
Pipelining Stage Parameters

The following parameters indicate that you want Register Assistant to use pipelining with the
number of stages you specify in the value.
Table 5-26. Pipelining Stage Parameters

Pipelining Stage Parameters Block Parameter Description
Value
rtl.PIPELINE_WRITE_STAGES <Number> This parameter enables you to
pipeline the decoder and specify the
number of pipelining stages for the
write enabling decoding.
rtl.PIPELINE_READ_STAGES <Number> This parameter enables you to
pipeline the multiplexer and specify
the number of pipelining stages for
the read multiplexing.
The maximum number of pipelining stages is 2. You can specify a different number of write
and read stages. For example, you can set the write stages as 1 and the read stages as 0.
Pipelining Mux and Decoder Size Parameters

The following parameters indicate the size of the mux and decoder. Provide the numbers
separated by a space, starting by level 1.
Table 5-27. Pipelining Mux and Decoder Size Parameters

Pipelining Stage Parameters Block Parameter Description
Value
rtl.PIPELINE_WRITE_MUX_SIZES <Space-separated This parameter defines the
number> output size of decoders in each
write pipelining mux level.
rtl.PIPELINE_READ_MUX_SIZES <Space-separated This parameter defines the input
number> size of multiplexers in each read
pipelining mux level.
Pipelining Naming Convention Parameters

Pipelining naming convention parameters define naming conventions for signals and their
value. Naming convention parameters are optional and accept variables.
Table 5-28. Pipelining Naming Convention Parameters

Block Parameter Name Block Parameter Value
Mux Signals
rtl.PIPELINE_MUX_SIGNALS <String>
Mux signals are outputs of muxes. The default variable is
%(SIGNAL_NAME)_L%(MUX_LEVEL).
Delayed Signals
rtl.PIPELINE_DELAYED_SIGNALS <String>
Delayed signals are outputs of flip-flops. The default variable is
%(SIGNAL_NAME)_D%(FLIP_FLOP_LEVEL).
Intermediate Signals
rtl.PIPELINE_INTERMEDIATE_SIGNALS <String>
Intermediate signals are constants used as selectors for decoders and multiplexers. The default
variable is %(SIGNAL_NAME)_L%(MUX_LEVEL)_%(MUX_LEVEL_GROUP).
For intermediate signals, Register Assistant substitutes the %(SIGNAL_NAME) variable with
“RD” for READ and “WEN” for WRITE. In the following figure, there are several levels of
muxes, and each mux level is addressed by a group of addresses. The intermediate signal uses
%(MUX_LEVEL_GROUP) to select a specific group of decoders or multiplexers.
Figure 5-13. Pipelining Variables
Related Topics
Parameters
Pipelining Overview
Pipelining Checks
Pipelining Checks
The RTL generator runs certain checks when you set the pipelining feature. Register Assistant
raises a warning or error message if a check fails and stops completely for errors.
Minimum Number of Registers

Register Assistant checks that the minimum number of registers in the input files is three. You
should have at least three writable or readable registers for each block you pipeline, otherwise,
Register Assistant raises an error.
# Error: Block 'top' has less than 3 readable register instances.

# Error: RTL Pipelining requires at least 3 writable/readable registers
for each block you pipeline.
# Error: Block 'top' has less than 3 writable register instances.
# Error: RTL Pipelining requires at least 3 writable/readable registers
for each block you pipeline.
Valid Parameter Values

Register Assistant checks that the following parameters have valid values.
• rtl.PIPELINE_WRITE_STAGES
• rtl.PIPELINE_READ_STAGES
If these parameters have values that are greater than 0, then Register Assistant checks that the
values of the following parameters are valid.
• rtl.PIPELINE_WRITE_MUX_SIZES
• rtl.PIPELINE_READ_MUX_SIZES
To validate parameter values, Register Assistant runs a series of checks in the following
sequence. If your input violates any of these checks, Register Assistant raises an error, the
remaining checks do not run, and generation stops.
1. If the value of the number of pipelining stages is invalid, Register Assistant raises an
error.
# Error: Block 'top' has parameter 'rtl.PIPELINE_READ_STAGES' set to
invalid value 'xyz'.
2. If the value of the number of stages parameters is 0, Register Assistant proceeds with
non-pipelined generation.
3. If the value of the number of stages parameters is greater than the allowed maximum (2),
Register Assistant raises an error.
unsupported value '5'. Supported values: 0 - 2.
4. If you do not specify the mux size parameters, Register Assistant raises an error.
# Error: Block 'top' has parameter 'rtl.PIPELINE_READ_MUX_SIZES'

which is missing or set to empty value.
5. If the number of mux sizes does not match the number of mux levels, Register Assistant
raises an error.
invalid value '1'. Value should be 2 numbers separated by spaces.
Please make sure of the following: Each size should be greater than
1 and should be a power of 2. MUX size should be less than the number
of readable instances in any level. Multiplication product of
individual sizes should be at least the number of readable
registers.
6. If the mux sizes have any invalid value (a non-integer value), Register Assistant raises
an error.
invalid value 'x 3'. Value should be valid numbers separated by
spaces. Please make sure of the following: Each size should be
greater than 1 and should be a power of 2. MUX size should be less
than the number of readable instances in any level. Multiplication
product of individual sizes should be at least the number of
readable registers.
7. If any of the mux sizes is less than or equal to 1, or is not a power of 2, Register
Assistant raises an error.
# Error: Block 'top' has parameter 'rtl.PIPELINE_READ_MUX_SIZES' set
to invalid value '1 1'. Each size should be greater than 1 and
should be a power of 2. Please make sure of the following: MUX size
should be less than the number of readable instances in any level.
Multiplication product of individual sizes should be at least the
number of readable registers.
8. If the number of registers is less than or equal to the mux size of any level, Register
Assistant raises an error.
to invalid value '8 2'. MUX size '8' is invalid. MUX sizes should be
less than the number of readable instances '7' in any level. Please
make sure of the following: Multiplication product of individual
sizes should be at least the number of readable registers.
9. If the multiplication of mux sizes is less than the number of registers, Register Assistant
raises an error.
to invalid value '2 2'. Multiplication product of individual sizes
should be at least '7'.
10. If mux sizes have an invalid value, that is, if a value does not pass any of checks 5 to 9,
then Register Assistant raises a note to suggest a list of valid sizes from which you can
choose. For example:
# Note: Valid value(s) of 'rtl.PIPELINE_READ_MUX_SIZES' for block
'top' are: 2 512, 4 256, 8 128, 16 64, 32 32, 64 16, 128 8, 256 4 or
512 2.
Mandatory Variable Usage

Register Assistant checks the values of the following parameters to ensure their values are using
certain variables to avoid naming conflicts in the generated output.
• rtl.PIPELINE_MUX_SIGNALS
• rtl.PIPELINE_DELAYED_SIGNALS
• rtl.PIPELINE_INTERMEDIATE_SIGNALS
If the parameters do not use variables, Register Assistant raises an error as shown in the
following example:
# Error: Block 'sw_top_block' has parameter

'rtl.PIPELINE_INTERMEDIATE_SIGNALS' that must reference variable
'%(MUX_LEVEL)'.
The following table shows the parameters and the mandatory variables to use in their definition.
Table 5-29. Parameters With Mandatory Variables

Parameter Mandatory Variables
rtl.PIPELINE_MUX_SIGNALS %(SIGNAL_NAME)
%(MUX_LEVEL)
rtl.PIPELINE_DELAYED_SIGNALS %(SIGNAL_NAME)
%(FLIP_FLOP_LEVEL)
rtl.PIPELINE_INTERMEDIATE_SIGNALS %(SIGNAL_NAME)
%(MUX_LEVEL)
%(MUX_LEVEL_GROUP)
Related Topics
Pipelining Overview

The pipelining feature enables you to split the write enable and read mux logic in your
generated RTL output into up to two banks of smaller muxes with pipeline flip-flops in
between. To apply pipelining to your RTL Verilog or VHDL output, you have to add the
corresponding parameters in your input files.
Prerequisites
• Prepare the input files containing your register definitions as described in “Specifying
RTL Input” on page 108.
Procedure
1. In the input files, add the following pipelining stage parameters and specify the number
of pipelining stages for each parameter.
• rtl.PIPELINE_WRITE_STAGES
• rtl.PIPELINE_READ_STAGES
2. Add the following parameters to define the output size of decoders in each write
pipelining mux level and the input size of multiplexers in each read pipelining mux
level, respectively.
• rtl.PIPELINE_WRITE_MUX_SIZES
• rtl.PIPELINE_READ_MUX_SIZES
3. (Optional) Use the following parameters to define the naming conventions that Register
Assistant should use for signals on generating the code.
• rtl.PIPELINE_MUX_SIGNALS
• rtl.PIPELINE_DELAYED_SIGNALS
• rtl.PIPELINE_INTERMEDIATE_SIGNALS
4. Prepare your control file.
5. Run Register Assistant on your input files.
Results
Register Assistant runs a series of checks on the input you provided. If the checks do not raise
errors, the RTL output generates with a pipelined write enable decoder and read mux logic.
Examples
The example consists of an input CSV file that contains seven readable and writable registers.
Figure 5-14. Pipelining Example — Register Definitions
The following figure shows the register block definitions.
Figure 5-15. Pipelining Example — Block Definitions
This example creates two stages of write pipeline and two stages of read pipeline as indicated in
the following figure. The multiplexer sizes of the write pipeline are “2” for the first level and
“4” for the second level, and the sizes for the read pipeline are “4” for the first level and “2” for
the second level.
Figure 5-16. Pipelining Example — RTL Parameter Configurations
After running Register Assistant, the generated RTL file includes the following write pipeline.
-- WRITE Enable Level 1

-- 1:2 demux using waddr(2)
write_enable1 : PROCESS (waddr)
BEGIN
WEN_L1 <= '0';
waddrerr_L1 <= '0';
CASE waddr(2) IS -- Decode using waddr(2)

WHEN WEN_L1_1 =>
WEN_L1 <= WEN_L1_1;
WHEN WEN_L1_2 =>
WEN_L1 <= WEN_L1_2;
WHEN OTHERS =>
waddrerr_L1 <= '1';
END CASE;
END PROCESS write_enable1;
-- WRITE Pipeline Stage 1

write_pipe1 : PROCESS (clock, reset)
BEGIN
waddr_D1 <= (OTHERS=>'0');
wdata_D1 <= (OTHERS=>'0');
WEN_L1_D1 <= '0';
wstrobe_D1 <= '0';
waddrerr_L1_D1 <= '0';
waddr_D1 <= waddr;
wdata_D1 <= wdata;
WEN_L1_D1 <= WEN_L1;
wstrobe_D1 <= wstrobe;
waddrerr_L1_D1 <= waddrerr_L1;
END IF;
END PROCESS write_pipe1;

-- 2 X 2:4 demux using WEN_L1_D1 & waddr_D1(1 DOWNTO 0)
write_enable2 : PROCESS (waddr_D1,
WEN_L1_D1,
wstrobe_D1,
waddrerr_L1_D1)
BEGIN
wen_REG1_inst <= '0';
waddrerr_L2x <= '0';
IF (wstrobe_D1 = '1') THEN

CASE WEN_L1_D1 IS -- First MUX level decode using WEN_L1_D1
WHEN WEN_L1_1 =>
CASE waddr_D1(1 DOWNTO 0) IS -- Second MUX level decode using
waddr_D1(1 DOWNTO 0)
WHEN REG1_INST_ADDR_W =>

WHEN OTHERS =>
END CASE;
WHEN WEN_L1_2 =>
WHEN OTHERS =>
END CASE;
WHEN OTHERS =>
END CASE;
END IF;
wack_L2 <= wstrobe_D1;
waddrerr_L2 <= waddrerr_L1_D1 OR waddrerr_L2x;

BEGIN
wen_REG1_inst_D1 <= '0';
wack_L2_D1 <= '0';
wdata_D2 <= wdata_D1;
wen_REG1_inst_D1 <= wen_REG1_inst;
wack_L2_D1 <= wack_L2;
END IF;
-- WRITE assign internals to outputs

assign_write_output : PROCESS (wack_L2_D1, waddrerr_L2_D1)
BEGIN
wack <= wack_L2_D1;
waddrerr <= waddrerr_L2_D1;
END PROCESS assign_write_output;
In addition, the generated RTL file includes the following read pipeline.
-- READ MUX Level 1

-- 2 X 2:4 mux using raddr(2) & raddr(1 DOWNTO 0)
read_mux1 : PROCESS (raddr,
rmux_REG1_inst,
rmux_REG2_inst,
rmux_REG3_inst,
rmux_REG4_inst,
rmux_REG5_inst,
rmux_REG6_inst,
rmux_REG7_inst)
BEGIN
rdata_L1_1 <= DEF_RDATA_VAL;
raddrerr_L1 <= '0';
CASE raddr(2) IS -- Second MUX level decode using raddr(2)

WHEN RD_L1_1 =>
CASE raddr(1 DOWNTO 0) IS -- First MUX level decode using raddr(1
DOWNTO 0)
WHEN REG1_INST_ADDR_R =>
rdata_L1_1 <= rmux_REG1_inst;
WHEN OTHERS =>
raddrerr_L1 <= '1';
END CASE;
WHEN RD_L1_2 =>
DOWNTO 0)
WHEN OTHERS =>
raddrerr_L1 <= '1';
END CASE;
WHEN OTHERS =>
raddrerr_L1 <= '1';
END CASE;
END PROCESS read_mux1;
-- READ Pipeline Stage 1

read_pipe1 : PROCESS (clock, reset)
BEGIN
raddr_D1 <= (OTHERS=>'0');
rdata_L1_1_D1 <= (OTHERS=>'0');
rstrobe_D1 <= '0';
raddrerr_L1_D1 <= '0';
raddr_D1 <= raddr;
rdata_L1_1_D1 <= rdata_L1_1;

rstrobe_D1 <= rstrobe;
raddrerr_L1_D1 <= raddrerr_L1;
END IF;
END PROCESS read_pipe1;
-- READ MUX Level 2

-- 1:2 mux using raddr_D1(2)
read_mux2 : PROCESS (raddr_D1,
rdata_L1_1_D1,
rdata_L1_2_D1,
rstrobe_D1,
raddrerr_L1_D1)
BEGIN
rdata_L2 <= DEF_RDATA_VAL;
raddrerr_L2x <= '0';
IF (rstrobe_D1 = '1') THEN

CASE raddr_D1(2) IS -- Decode using raddr_D1(2)
WHEN RD_L1_1 =>
rdata_L2 <= rdata_L1_1_D1;
WHEN RD_L1_2 =>
WHEN OTHERS =>
END CASE;
END IF;
rack_L2 <= rstrobe_D1;
raddrerr_L2 <= raddrerr_L1_D1 OR raddrerr_L2x;

BEGIN
rdata_L2_D1 <= (OTHERS=>'0');
rack_L2_D1 <= '0';
rdata_L2_D1 <= rdata_L2;
rack_L2_D1 <= rack_L2;
END IF;
-- READ assign internals to outputs

assign_read_output : PROCESS (rdata_L2_D1, rack_L2_D1, raddrerr_L2_D1)
BEGIN
rdata <= rdata_L2_D1;
rack <= rack_L2_D1;
raddrerr <= raddrerr_L2_D1;
END PROCESS assign_read_output;
Note
If you are using optional signals, they are delayed in the generated output. Register Assistant
adds the corresponding number of flip-flops in the path of the signals to ensure that the
signals are asserted in the corresponding time slot.
Related Topics
Pipelining Overview
Pipelining Checks
RTL Pipelining Output Example
Parameters
Control File
Running Register Assistant in Batch Mode
C Header Generator
C Header Generator
Register Assistant allows you to generate C Header files reflecting the register structure defined
in the input. Based on the register definitions used in the input, Register Assistant generates
header files which can be useful for software/firmware teams to develop drivers and application
code.
Through the generation of C Header files, C programmers will be able to easily access registers
by their names rather than hard-coded numeric addresses.
Generated C Header files include, for example, macro definitions for basic access rights, macro
definitions for generic read/write macros, and so forth. The following sections provide more
details on the generation of C Header files through Register Assistant.
Additionally, the C Header generator allows you to generate utility code. For further
information, refer to the section “Generating C Utility Files” on page 196.
Specifying the Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Preparing the Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Examining the Generated C Header File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Generating C Utility Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Specifying the Input

To specify the input for the C header generator, do the following.
Procedure
1. Decide on your Input Files Format
The C Header generator accepts register description files in CSV or JavaScript format.
For more information on Register Assistant input formats, refer to “Register Assistant
Inputs” on page 31.
2. Fill in your Input files with Register/Block Descriptions
Upon deciding on the input format you wish to use, you would then have to make sure
that you provide a complete description of your hardware register objects in a fashion
that is correctly translated by Register Assistant. The following steps outline the objects
you need to define for ensuring a correct and complete generated output:
a. Register Objects — Each register is defined by a set of basic properties outlined in
Table 5-6.
b. Register Field Object — Each register may consist of one or more fields. Each field
is defined by a set of properties outlined in Table 5-7.
c. Register Block Object — Each block contains instances of functionally related

registers. Register blocks are defined by a set of basic properties outlined in
Table 5-9.
Note
* To view a full list of Register Assistant’s CSV columns, whether mandatory or
optional, you can refer to the CSV Columns list.
* If you are using register files in your input data, Register Assistant internally
translates them to sub-blocks (refer to “Overview on Register Data Hierarchy” on
page 14). It should be noted that any settings defined for parent blocks, such as
interface signals or parameters, will also be used for child register files.
3. Optionally Configure the C Header Generator

Register Assistant enables you to control certain aspects of the generated output by
allowing you to define parameters within your input files. For more information on
parameters, refer to “Parameters” on page 213.
For example, you have the ability to control include files used in the generated output if
you are using types other than the built-in types supported by Register Assistant:
uint8_t, unit16_t, uint32_t or unit64_t.
Also, you can control the names of different items defined in the generated output. For
instance, you can control the names of the read/write macros defined in the generated
output if you do not want to have the default names of Register Assistant. Likewise, you
can control the names of field macros.
Moreover, you can control the case of all the macro names used in the generated output
to be lower case, upper case or as is.
You can also use parameters to specify a template other than the default template used
by Register Assistant in the generation of the C Header file.
For more information on the list of parameters that can be used with C Header
generation and their usages, refer to C Header Parameters. You can also see C Header
Variables, to view a list of the variables supported for use within C Header parameters.

To generate C Header files, you have to write the following command in the control file.
# <comment>
<generator_language>, <generator_name>, <file_name.h>, <C Header Output
Directory/Location>
Understanding C Header Checks
This is applied as follows:
# Generate C Headers
java, c_header, reg.h, D:/projects/cheader
The above command can be explained as follows:

Table 5-30. C Header Output Command in Control File
Keyword Equivalent Value Description
<generator_name> c_header The name of the java generator.
<file_name.h> reg.h Specify any name for the file to be
generated.
<C Header Output D:/projects/cheader The path of the generated file. If not
Directory/Location> specified, the default project location is used.
The default project location is the path
specified by the -project command if you are
using Register Assistant in batch mode, or
the project path of the host application if you
are using Register Assistant through an
interface tool (such as HDL Designer
Series).

On invoking the C Header generator through the control file or the GUI, some intrinsic checks
are run. These checks are only specific to the C Header generator. They run every time the
generator is invoked. If a check fails a warning or error message appears.
It should be noted that in case an error is produced, the C Header generator stops.
Parameters and Variables

Checks that parameters and variables are valid. The check validates the following:
• The referenced C Header (c.*) parameters are among the list of supported parameters.
Refer to C Header Parameters sheet to view a full list of the supported parameters.
• Parameters have valid values. For example, this check validates that the parameter
c.DEFINE_NAMES_CASE has one of the following values: UPPER, LOWER or
AS_IS).
• Parameters are referenced by valid scopes. For example, this check validates that the
parameter c.BLOCK_BASE_ADDRESS is defined on the level of the project.
• Parameters reference variables that must be referenced (if any). For example, the
parameter c.FIELD_NAMING should reference at least the variable
%(FIELD_NAME), otherwise the naming will not be unique across all fields.
• Referenced variables are among the list of supported variables. Refer to C Header
Variables sheet to view a full list of the supported parameters.
• Parameters do not reference variables that cannot be referenced (if any). For example,
the parameter c.FIELD_NAMING cannot reference the %(BLOCK_NAME) variable.
See the following error examples resulting from this check:
# Error: Project 'c_header' has unsupported parameter 'c.FILE_NAME'.

# Error: Project 'c_header' has parameter 'c.FIELD_NAMING' that must
reference variable '%(FIELD_NAME)'.
# Error: Project 'c_header' has parameter 'c.INSTANCE_VARIABLE_TYPES' set
to a wrong value 'my_type'. It should be in the form:
width1:type1;width2:type2....
# Error: Project 'c_header' has parameter 'c.DEFINE_NAMES_CASE' set to
unsupported value 'SMALL'. Supported values: 'UPPER', 'LOWER', 'AS_IS'.
# Error: Block 'top_block' has parameter 'c.BLOCK_STRUCT_POINTER_NAME'
that references unsupported variable '%(FILE_NAME)'.
# Error: Block 'top_block' has inapplicable parameter 'c.FIELD_NAMING'.
Instances Definitions
Checks that all instances have definitions.
# Error: Instance 'imy_register_3' doesn't have a definition
Register Widths
Checks that all registers have supported widths. A supported width should match any of the
built-in or user-specified widths defined through the c.INSTANCE_VARIABLE_TYPES
parameter.
# Error: Register 'my_register_1' has unsupported width (9 bits).

Supported widths are 8, 16, 32 and 64.
Padding Sizes
Checks that any padding between component instances has a size as multiples of any of the
built-in or user specified widths defined through the c.INSTANCE_VARIABLE_TYPES
parameter.
Examining the Generated C Header File
# Error: Instance 'imy_register_2' requires padding of unsupported width

(7 bits). Supported base widths are 8 and 16
Note
Note that all these checks take place in the same order as they are listed above. Also, it
should be noted that if any check fails, the other checks are not executed, and hence the
generation stops.

The generated C Header .h file is generated using a default template provided with Register
Assistant on the path %(RA_HOME)/resources/templates/c_header.h. The template constitutes
of macros which are substituted in the generated output with the below sections based on
register definitions and configured parameters you provide.
Note that you can modify the template to use in generation through the parameter
c.TEMPLATE_PATH.
The generated file is mainly made up of the following sections:
File Header
Register Assistant adds a header at the beginning of the generated file to provide general
information such as the name of the project, the name of the generated file, the name of the user
who generated the file, and so forth. This section specifically relies on a separate template
available on %(RA_HOME)/resources/templates/c_header_file_header.h.
Note that this section is equivalent to the following macro in Register Assistant’s default
c_header.h template:
@FILE_HEADER@
Include Files
Register Assistant deduces include files from the register definition input files as follows:
• The include file stdint.h is always added in the generated output as it is needed for the
supported built-in struct item types: uint8_t, unit16_t, uint32_t or unit64_t. Example:
#include ‘stdint.h‘
• Extra include files are also added in the generated output based on the following
parameters:
Table 5-31. Parameters for Extra Include Files

c.EXTRA_INCLUDES Adds extra include files to the generated output. In the
generated output, these includes are enclosed in
double quotations. Example:
#include “myfile1.h”
c.EXTRA_STANDARD_INCLUDES Adds extra standard include files to the generated
output. In the generated output, these includes are
enclosed in greater/smaller than characters. Example:
#include <stdio.h>
You can define extra include files if you are using types other than the built-in types supported
by Register Assistant using the c.EXTRA_INCLUDES parameter. In that case, you will also
need to use the c.INSTANCE_VARIABLE_TYPES in order to define the types associated to
the extra include files.
Refer to C Header Parameters sheet for more information on the above parameters.
Note that the include files section is equivalent to the following macro in Register Assistant’s
default c_header.h template:
@GENERATED_INCLUDES@
Access Right Macro Definitions

The generated C Header file includes macro definitions for the software access modes of the
registers in the input files.
The generated access right macros are “__RO”, “__WO” or “__RW”. Any register access right
is resolved to one of these three macros.
For example, if there are a number of registers in the input files having the software access
modes RC and RW1C, the following defines will be generated:
#define __RO volatile const /* read-only permissions */

#define __RW volatile /* read/write permissions */
The following table shows the macros generated for different software access modes:
Table 5-32. Macros Generated for Software Access Modes
Software Access Modes Macro Name Macro Value
Read-Write access modes. __RW volatile
Example: RW, RWQ, RW1,

RW1S, RW1C, RW0S, and so on.
Read-Only access modes. __RO volatile const
Example: R, RO, RC and RS and

so on.
Write-Only access modes. __WO volatile
Example: WO, WOC, WOS,

WOQ, WO1, and so on.
Note that the access right macro definitions section is equivalent to the following macro in
Register Assistant’s default c_header.h template:
@GENERATED_SW_ACCESS_RIGHT_DEFINES@
Read/Write Macro Definitions

In the input files, if one or more registers contain fields with read software access modes such as
RW, RO, RC and so on, then a macro for read method is defined in the generated C Header file.
Likewise, if one or more registers contain fields with write software access modes such as RW,
WO, WOQ and so on, then a macro for write method is defined.
You have the ability to control the name of the macros through the following parameters:
Table 5-33. Parameters for Read/Write Macro Names
c.READ_MACRO_NAME Indicates the name of the read macro. The default is
%(PROJECT_NAME)_READ.
c.WRITE_MACRO_NAME Indicates the name of the write macro. The default is
the %(PROJECT_NAME)_WRITE.
The following example shows macro definitions for read and write macros in the generated
code:
#define SW_READ32(reg, mask, offset) \

(((reg) & (mask)) >> (offset))
#define SW_WRITE32(reg, mask, offset, data) \
(((reg) & ~(mask)) | (((uint32_t)data) << (offset)));
Note that the read/write macro definitions section is equivalent to the following macro in
@GENERATED_READ_WRITE_DEFINES@
Block Struct Definitions

In the generated output, Register Assistant defines a struct for each block in the input files. The
structs for the blocks at the leaf-level of the hierarchy are defined first and then the top block.
You have the ability to specify the struct names as well as the names of the pointers to each
struct by defining the following parameters in the input files:
Table 5-34. Parameters for Block Struct Names and Pointer Names
c.BLOCK_STRUCT_NAME Indicates the name of the block struct to define in
the generated output. The default is
%(BLOCK_NAME)_s.
c.BLOCK_STRUCT_POINTER_NAME Indicates the name of the struct pointer name to
define in the generated output. The default is
%(BLOCK_NAME)_ptr.
The following example shows how block structs and their pointers are defined in the generated
output:
/* SW_TOP_BLOCK (Size: 0x4404) */

typedef struct swTopBlock_s
{
...
} __RW swTopBlock_s, *swTopBlock_ptr;
Note how the block size is defined in the comment preceding the struct definition.
Component Instances
Within the block struct definition, a data member is defined for each component instance
(whether register, memory, sub-block and so on). The data members are ordered by the position
of their component instances inside the block.
For each register and memory instance, Register Assistant creates a data member having the
type specified through the parameter c.INSTANCE_VARIABLE_TYPE.
Note that if the parameter is not specified in the input files, or if it does not have a specified or a
suitable value, Register Assistant will use one of the following built-in types: uint8_t, unit16_t,
uint32_t, unit64_t.
Padding
A padding data member is defined for each part of the block address space with no assigned
instances.
Note that if the padding size is not a multiple of any of the user-specified types (if any), then the
built-in types are used.
Example
This example illustrates the block struct definitions along with the component instances and
padding in the generated output:
/* SW_TOP_BLOCK (Size: 0x4404) */

typedef struct swTopBlock_s
{
/* Padding */
uint32_t pad0[1024];/* 0x0FFF:0x0000 */
/* Block1 instance 1 */
swSubBlock_s sw1;/* 0x1053:0x1000 */
/* Padding */
uint32_t pad1[1003];/* 0x1FFF:0x1054 */
swSubBlock_s sw2;/* 0x2053:0x2000 */
/* Padding */
uint32_t pad2[1003];/* 0x2FFF:0x2054 */
/* Counter instance 1 */
__RW uint32_t vreg1;/* 0x3003:0x3000 */
__RW uint32_t vreg2;/* 0x3007:0x3004 */
__RW uint32_t vreg3;/* 0x300B:0x3008 */
/* Custom register instance */
__RW uint32_t my_reg1;/* 0x300F:0x300C */
/* Padding */
uint32_t pad3[1020];/* 0x3FFF:0x3010 */
/* Memory instance */
__RW uint32_t mem1;/* 0x44FF:0x4000 */
} __RW swTopBlock_s, *swTopBlock_ptr;
Note that the block struct definitions section in the generated file is equivalent to the following
macro in Register Assistant’s default c_header.h template:
@GENERATED_BLOCKS_STRUCTS@
Top Block Macro Definitions

In the generated output, Register Assistant defines a variable for the type of the struct pointer
defined for the top-level block.
The following example shows how top blocks are defined in the generated output:
#define SW_TOP_BLOCK__BASE 0x0

sw_top_block_ptr sw_top_block = SW_TOP_BLOCK__BASE;
Note that the top block macro definitions section is equivalent to the following macro in
@GENERATED_TOP_BLOCK_BASE_ADDRESS@
@GENERATED_TOP_BLOCK_DECLARATION@
Field Macro Definitions

Register Assistants adds macro definitions in the generated output for all the fields defined in
the input files. This is done in order to facilitate the reading and writing of fields. It should be
noted that default fields (which are the fields automatically created when a register has no fields
at all) will have no macros defined.
You can specify a naming convention for field macro names using the parameter
c.FIELD_NAMING. The default is %(REGISTER_NAME)_%(FIELD_NAME). Refer to C
Header Parameters sheet for information on the parameters that can be used for the generation
of C Header files, and also refer to C Header Variables sheet for information on the C Header
variables that can be used in the definition of C Header parameters.
In this section, the following macros are defined:
• A macro is defined for the field’s mask value. The mask value is calculated as follows:
2^(offset + width) – 2^(offset).
Register Assistant uses the following format in code generation:
#define <name specified by c.FIELD_NAMING parameter>__<postfix
specified by c.FIELD_MASK_POSTFIX parameter> <mask in hex format>
The field’s mask macro name postfix can be defined through the variable
c.FIELD_MASK_POSTFIX.
• A macro is defined for the field’s offset value.

specified by c.FIELD_OFFSET_POSTFIX parameter> <offset in decimal
format>
The field’s offset macro name postfix can be defined through the variable
c.FIELD_OFFSET_POSTFIX.
• A macro is defined for a “get” method. It will be defined for all fields except reserved
fields and write-only fields.
specified by c.FIELD_GET_POSTFIX parameter>(field) \
<read macro>(field, <field mask macro>, <field offset macro>)
The field’s get method macro name postfix can be defined through the variable
c.FIELD_GET_POSTFIX.
• A macro is defined for a “set” method. It will be defined for all fields except reserved
fields and read-only fields.
specified by c.FIELD_SET_POSTFIX parameter>(field, data) \
<write macro>(field, <field mask macro>, <field offset macro>, data)
The field’s set method macro name postfix can be defined through the variable
c.FIELD_SET_POSTFIX.
You can refer to C Header Parameters to view the parameters that can be used with the
generation of C Header files and their default values. You can also see the C Header Variables
that can be used in the definition of parameter values. For a general overview on parameters, see
“Parameters” on page 213.
Tip
: The case of any macro names used in the generated output can be controlled through the
parameter c.DEFINE_NAMES_CASE. The values of this parameter can be: UPPER (which
is the default), LOWER, or AS_IS.
Note that the field macro definitions section is equivalent to the following macro in Register
Assistant’s default c_header.h template:
@GENERATED_FIELDS_DEFINES@
Example
The following example shows a full C Header file generated by Register Assistant.
/*----------------------------------------------------------------------
* THIS IS AUTOMATICALLY GENERATED CODE
* Generated by Mentor Graphics' Register Assistant V4.6 (Build 4)
*----------------------------------------------------------------------
* Project : output
* File : sw.h
*----------------------------------------------------------------------
* Created by : user
* Creation Date : 14/09/14 09:50
*----------------------------------------------------------------------
* Title : output
*
* Description :
*
*----------------------------------------------------------------------
*/
#ifndef _SW_H
#define _SW_H
#include <stdint.h>
/************************ DEFINE ACCESS RIGHTS ************************/

#define __RW volatile /* read/write permissions */
/********************** DEFINE READ/WRITE MACROS **********************/

#define OUTPUT_READ32(reg, mask, offset)\
(((reg) & (mask)) >> (offset))
#define OUTPUT_WRITE32(reg, mask, offset, data)\
(((reg) & ~(mask)) | (((uint32_t)data << (offset))))
/********************** DEFINE HIERARCHY LEVELS ***********************/

/* sw_sub_block (Size: 0x54) */
typedef struct sw_sub_block_s
{
/* Padding */
uint32_t pad0; /* 0x3:0x0 */
/* Value instance */
__RW uint32_t stopwatch_value_reg; /* 0x7:0x4 */
/* Reset Value instance */
__RW uint32_t stopwatch_reset_value_reg; /* 0xB:0x8 */
/* Upper Limit instance */
__RW uint32_t stopwatch_upper_limit_reg; /* 0xF:0xC */
/* Lower Limit instance */
__RW uint32_t stopwatch_lower_limit_reg; /* 0x13:0x10 */
/* CSR instance */
__RW uint32_t stopwatch_csr_reg; /* 0x17:0x14 */
/* Padding */
uint32_t pad1[7]; /* 0x33:0x18 */
/* MEM instances */
__RW uint32_t stopwatch_memory_reg[8]; /* 0x53:0x34 */
} __RW sw_sub_block_s, *sw_sub_block_ptr;
/* sw_top_block (Size: 0x5000) */

typedef struct sw_top_block_s
{
/* Padding */
uint32_t pad0[1024]; /* 0xFFF:0x0 */
sw_sub_block_s sw1; /* 0x1053:0x1000 */
/* Padding */
uint32_t pad1[1003]; /* 0x1FFF:0x1054 */
sw_sub_block_s sw2; /* 0x2053:0x2000 */
/* Padding */
uint32_t pad2[1003]; /* 0x2FFF:0x2054 */
__RW uint32_t vreg1; /* 0x3003:0x3000 */
__RW uint32_t vreg2; /* 0x3007:0x3004 */
__RW uint32_t vreg3; /* 0x300B:0x3008 */
/* Padding */
uint32_t pad3[1021]; /* 0x3FFF:0x300C */
/* Memory instance */
__RW uint32_t mem1[1024]; /* 0x4FFF:0x4000 */
} __RW sw_top_block_s, *sw_top_block_ptr;
/************************** DEFINE TOP BLOCK **************************/

#define SW_TOP_BLOCK__BASE 0x0
sw_top_block_ptr sw_top_block = SW_TOP_BLOCK__BASE;
/**************************** DEFINE FIELDS ***************************/
/*--------------------------------------------------------------------
* Register: stopwatch_csr
* Control Status Register
* (reset from fields is 0x0000007C)
* SW Access : read-write
* HW Access : read-write
*
* Fields:
* 0 lower_limit_reached (SW:read-only, HW:read-write)
* 1 upper_limit_reached (SW:read-only, HW:read-write)
* 2 updown (SW:read-write, HW:read-write)
* 6:3 stride (SW:read-write, HW:read-write)
* 31:7 padding (SW:read-write, HW:read-write) (RESERVED)
*/
/*--------------------------------------------------------------------
* Field: lower_limit_reached
* Width: 1, Offset: 0
* SW Access: read-only, HW Access: read-write
*--------------------------------------------------------------------
* Indicates that the lower limit has been reached
*/
#define STOPWATCH_CSR__LOWER_LIMIT_REACHED__MASK 0x00000001
#define STOPWATCH_CSR__LOWER_LIMIT_REACHED__OFFSET 0
#define STOPWATCH_CSR__LOWER_LIMIT_REACHED__GET(reg)\
OUTPUT_READ32(reg, STOPWATCH_CSR__LOWER_LIMIT_REACHED__MASK,
STOPWATCH_CSR__LOWER_LIMIT_REACHED__OFFSET)
/*--------------------------------------------------------------------
* Field: upper_limit_reached
* SW Access: read-only, HW Access: read-write
*--------------------------------------------------------------------
* Indicates that the upper limit has been reached
*/
#define STOPWATCH_CSR__UPPER_LIMIT_REACHED__MASK 0x00000002
#define STOPWATCH_CSR__UPPER_LIMIT_REACHED__OFFSET 1
#define STOPWATCH_CSR__UPPER_LIMIT_REACHED__GET(reg)\
OUTPUT_READ32(reg, STOPWATCH_CSR__UPPER_LIMIT_REACHED__MASK,
STOPWATCH_CSR__UPPER_LIMIT_REACHED__OFFSET)
/*--------------------------------------------------------------------
* Field: updown
* SW Access: read-write, HW Access: read-write
*--------------------------------------------------------------------
* Indicates whether counting up or down
*/
#define STOPWATCH_CSR__UPDOWN__MASK 0x00000004
#define STOPWATCH_CSR__UPDOWN__OFFSET 2
#define STOPWATCH_CSR__UPDOWN__GET(reg)\
OUTPUT_READ32(reg, STOPWATCH_CSR__UPDOWN__MASK,
STOPWATCH_CSR__UPDOWN__OFFSET)
#define STOPWATCH_CSR__UPDOWN__SET(reg, data)\
OUTPUT_WRITE32(reg, STOPWATCH_CSR__UPDOWN__MASK,
STOPWATCH_CSR__UPDOWN__OFFSET, data)
/*--------------------------------------------------------------------
* Field: stride
*--------------------------------------------------------------------
* Stride length
*/
#define STOPWATCH_CSR__STRIDE__MASK 0x00000078
#define STOPWATCH_CSR__STRIDE__OFFSET 3
#define STOPWATCH_CSR__STRIDE__GET(reg)\
OUTPUT_READ32(reg, STOPWATCH_CSR__STRIDE__MASK,
STOPWATCH_CSR__STRIDE__OFFSET)
#define STOPWATCH_CSR__STRIDE__SET(reg, data)\
OUTPUT_WRITE32(reg, STOPWATCH_CSR__STRIDE__MASK,
STOPWATCH_CSR__STRIDE__OFFSET, data)
/*--------------------------------------------------------------------
* Field: padding (RESERVED)
*--------------------------------------------------------------------
* Reserved
*/
#define STOPWATCH_CSR__PADDING__MASK 0xFFFFFF80
#define STOPWATCH_CSR__PADDING__OFFSET 7
#endif
Example Usage of the Generated C Header File

Below is an example of how software/firmware developers can use a generated C Header file
within their code.
In this example, a generated C Header file titled “c_header_main.h” is included at the beginning
of the code.
Note the read and write macro calls in this example:
• The write macro of a field takes the register of the field and the value to be written as
arguments. It writes the passed value to this specific field in the register.
• The read macro of a field takes the register of the field, and returns the value of this
specific field from the register.
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include "c_header_main.h"
int main()
{
/* Declarations */
int value;
/* Hello */
printf("Testing register/field read/write operations...\n");
/* Allocation */
top_block = malloc(sizeof(top_srt));
/****************************/
/* Test REGISTER read/write */
/****************************/
/* Write to register */
value = 220;
top_block->imy_counter = value;
printf("Value: %d written to register 'top_block->imy_counter'\n",
top_block->imy_counter);
/* Read from register */
value = top_block->imy_counter;
printf("Register 'top_block->imy_counter' has a value: %d\n\n", value);
/****************************/
/* Test FIELD read/write */
/****************************/
/* Write to field */
top_block->imy_register = 0; /* reset the whole register (could be
skipped) */
value = 10; /* CAUTION: value should not exceed 4 bits (the field
width) */
top_block->imy_register = my_register__fld_2__my_set(top_block-
>imy_register, value)
printf("Value: %d written to field 'fld_2' in register 'top_block-
>imy_register'\n", value);
/* Read from field */
value = my_register__fld_2__my_get(top_block->imy_register);
printf("Field 'fld_2' in register 'top_block->imy_register' has a
value: %d\n", value);
/* Free */
free(top_block);
return 0;
}
Generating C Utility Files

In addition to the main .h header file that Register Assistant provides through the C Header
generator, you also have the option to generate utility code. This code contains functions that
allow the initialization of registers.
The generation of the utility code is done through a parameter which, if set, will generate two
files: .c and .h.
Procedure
1. Prepare your register definition files and configure the C Header generator through
defining parameters. For more information, refer to “Specifying the Input” on page 179.
Make sure you define the parameters specific to the generation of utility files:
Table 5-35. C Utility Code Parameters

Block Parameter Name Block Parameter Value Notes
c.UTILS_GENERATION TRUE The default value is FALSE.
This parameter should be set
to TRUE if you wish to
generate utility files.
c.UTILS_C_TEMPLATE_PATH Specify the path to the The default template used
template of the utility .c file. by Register Assistant is:
%(RA_HOME)/resources/
templates/c_utils.c
c.UTILS_H_TEMPLATE_PATH Specify the path to the The default template used
template of the utility .h file. by Register Assistant is:
%(RA_HOME)/resources/
templates/c_utils.h
For more information on the list of parameters that can be used with C Header
generation and their usages, refer to C Header Parameters. You can also see C Header
Variables, to view a list of the variables supported for use within C Header parameters.
2. Prepare your control file. For more information, refer to “Preparing the Control File” on
page 180.
3. Run Register Assistant. For more information, refer to “Command Line Switches” on
page 219.
Results
On running Register Assistant, a series of checks are run on the provided input and if no errors
are raised, the output is generated successfully. Refer to “Understanding C Header Checks” on
page 181, for more information on the checks that apply to the C Header generator.
As mentioned earlier, in addition to the main C header .h file, two utility files will be generated
as follows:
• <C Header File Name>_utils.h
By default, Register Assistant generates this file based on the template found on the path
%(RA_HOME)/resources/templates/c_utils.h. You have the ability to change the
template through the parameter c.UTILS_H_TEMPLATE_PATH.
The default template constitutes of macros which are substituted in the generated output
with the following sections based on the register definitions provided. The main sections
in the file include:
o File Header — Register Assistant adds a header at the beginning of the file to
provide general information such as the name of the project, the name of the
generated file, and so forth. This section specifically relies on a separate template
Note that this section is equivalent to the following macro in Register Assistant’s
default c_utils.h template:
@FILE_HEADER@
o Include Files — This section contains includes for the original C Header .h file.
o Initializations — This section defines macros for reset values for all the registers
and memories in the input files.
This section also contains function headers for the reset initialization functions of the
top block and sub-blocks.
@GENERATED_RESET_VALUES@
@GENERATED_INIT_FUNCTIONS_PROTOTYPES@
• <C Header File Name>_utils.c

By default, Register Assistant generates this file based on the template found on the path
%(RA_HOME)/resources/templates/c_utils.c. You have the ability to change the
template through the parameter c.UTILS_C_TEMPLATE_PATH.
The default template constitutes of macros which are substituted in the generated output
with the following sections based on the register definitions provide. The main sections
in the file include:
o File Header — Register Assistant adds a header at the beginning of the file to
provide general information such as the name of the project, the name of the
generated file, and so forth. This section specifically relies on a separate template
default c_utils.c template:
@FILE_HEADER@
o Include Files — This section contains includes for the original C Header .h file in
addition to the utility file <C Header File Name>_utils.h.
o Implementation of the Initialization Function — This section contains the

implementation of the initialization functions in the .h utility file. Each function in
this section is responsible for a block; the function initializes the registers of the
block and also calls the initialization functions of sub-blocks.
@GENERATED_INIT_FUNCTIONS_DEFINITIONS@
Examples
The following examples show generated <C Header File Name>_utils.h and <C Header File
Name>_utils.c utility files.
<C Header File Name>_utils.h:
/*----------------------------------------------------------------------
*----------------------------------------------------------------------
* Project : output
* File : sw_utils.h
*----------------------------------------------------------------------
* Created by : user
* Creation Date : 14/09/14 09:50
*----------------------------------------------------------------------
* Title : output
*
* Description : Register Utilities Header
*
*----------------------------------------------------------------------
*/
#ifndef _SW_UTILS_H
#define _SW_UTILS_H
#include "sw.h"
/*************************** INITIALIZATION ***************************/

/* Register reset values */
#define STOPWATCH_RESET_VALUE__RESET (0xAAAAAAAA)
#define STOPWATCH_UPPER_LIMIT__RESET (0x70707070)
#define STOPWATCH_LOWER_LIMIT__RESET (0x33333333)
#define STOPWATCH_MEMORY__RESET (0x0)
#define STOPWATCH_CSR__RESET (0x0000003C)
#define STOPWATCH_COUNTER__RESET (0x0)
/* Memory reset values */
#define MY_MEM__RESET (0x0)
void sw_sub_block_init(sw_sub_block_ptr sw_sub_block);

void sw_top_block_init(sw_top_block_ptr sw_top_block);
#endif
<C Header File Name>_utils.c:
/*----------------------------------------------------------------------
*----------------------------------------------------------------------
* Project : output
* File : sw_utils.c
*----------------------------------------------------------------------
* Created by : user
* Creation Date : 14/09/14 09:50
*----------------------------------------------------------------------
* Title : output
*
* Description : Register Utilities
*
*----------------------------------------------------------------------
*/
#include "sw.h"
#include "sw_utils.h"
/*************************** INITIALIZATION ***************************/

void sw_sub_block_init(sw_sub_block_ptr sw_sub_block)
{
int i = 0;
sw_sub_block->stopwatch_reset_value_reg = STOPWATCH_RESET_VALUE__RESET;
sw_sub_block->stopwatch_upper_limit_reg = STOPWATCH_UPPER_LIMIT__RESET;
sw_sub_block->stopwatch_lower_limit_reg = STOPWATCH_LOWER_LIMIT__RESET;
sw_sub_block->stopwatch_csr_reg = STOPWATCH_CSR__RESET;
for(i=0; i<7; i++)
{
sw_sub_block->stopwatch_memory_reg[i] = STOPWATCH_MEMORY__RESET;
}
}
void sw_top_block_init(sw_top_block_ptr sw_top_block)

{
int i = 0;
sw_sub_block_init(&(sw_top_block->sw1));
sw_sub_block_init(&(sw_top_block->sw2));
sw_top_block->vreg1 = STOPWATCH_COUNTER__RESET;
for(i=0; i<1023; i++)
{
sw_top_block->mem1[i] = MY_MEM__RESET;
}
}
Related Topics
C Header Generator
Parameters
Word Addressable Output

By default, Register Assistant assumes all addresses in your register definition files are byte-
addressable and generates any output accordingly. In addition to byte addressing, Register
Assistant also supports word addressing; you have the ability to control the address mode in
your input files to be word-based, thus affecting address representation in the generated output.
To elaborate on the difference between byte and word addressing, a byte is regarded as 8 bits,
whereas a word is typically the address width of the processor, for example, 8, 16, 32, 64, or 128
bits. When expressed as a multiple of bytes, a 32-bit address bus consists of 4 bytes, which is
the quotient of 32 divided by 8. Similarly, a 64-bit bus consists of 8 bytes, which is the quotient
of 64 divided by 8.
In the default byte addressing mode, Register Assistant assumes that all addresses are 1 byte (8
bits) apart. Hence, for a 32-bit bus, each entry in the address maps is 4 bytes apart, which means
that address values increment by 4 to access the start of the next register. For example, the first
register might be at address 0x0, the second at 0x4, the third at 0x8 and so on.
In the word addressing mode, address values simply increment by 1 word each time given that
the word size is defined as multiples of 8-bit bytes. Using the 32-bit bus example, the first
register might be at address 0x0, the second at 0x1, the third at 0x2 and so on.
See the following table:

Table 5-36. Byte versus Word Addressing
Word Word #1 Word #2 Word #3
Byte Addressing 0 1 2 3 4 5 6 7 8 9 10 11
Word Addressing 0 1 2
As shown in the table, for byte addressing, the first word starts at address 0x0, the second word
at address 0x4, whereas for word addressing (in this 32-bit example) all 4 bytes of the first word
are at address 0x0, all 4 bytes for the second word at 0x1 and so on.
Applying Word Addressing in Register Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Applying Word Addressing in Register Assistant

This section describes how you can control the addressing mode in Register Assistant so it
would be based on word addressing, rather than the default byte addressing.
Procedure
1. Determine the input format you will use for your register definitions, whether CSV,
JavaScript or IP-XACT XML files.
2. Depending on the input format you are using, set the word addressing feature as follows
on the block map level:
a. For CSV input files, make sure you add the following columns:
Table 5-37. Word Addressability CSV Columns

CSV Column Name Value Description
BlockMap Address Mode Byte Set the value to Word. Note that the
Word default value is “Byte”.
BlockMap Word Bytes Decimal Number Specify the number of bytes in a word.
The default value is “4”.
Refer to the CSV Columns table for further information.

b. For JavaScript input files, make sure you set the following APIs which correspond to
the CSV columns in Table 5-37:
o setAddressMode()
o setWordBytes()
Refer to Register Assistant’s APIs on the path <installation_folder>\
registerassistant\api\index.html for further information.
c. For IP-XACT XML input files, make sure you define values for addressUnitBits. It
is important to note that the value should be defined in bits (not bytes).
Note that byte addressing is the default addressing mode unless you explicitly set word
addressing.
Note
If you are generating UVM output, then you have the ability to specify the
endianness using the BlockMap Endian column in case of CSV input or using the
setEndian() API in case of JavaScript input. For details, refer to the CSV Columns table
or to the Register Assistant’s APIs on the path <installation_folder>\registerassistant\
api\index.html.
3. Prepare your control file. For more information, refer to “Preparing the Control File” on
page 180.
4. Run Register Assistant. For more information, refer to “Command Line Switches” on
page 219.
Results
Having set the word addressing mode, the following aspects will be affected on running
Register Assistant:
• The calculation of block sizes.
• The calculation of addresses of instances within instance arrays.

• The Address Overlap check will take word addressing into account. Refer to “Default
Checks” on page 56 for further information on this check.
Examples
The following is a CSV blockmap definition file in which the addressing mode is set as “Word”
in the BlockMap Address Mode column, the number of bytes in a word is set as “4” in the
BlockMap Word Bytes column, the endianness is set as “UVM_BIG_ENDIAN” in the
BlockMap Endian column.
The following are excerpts of a UVM output example generated for the above inputs. To view
the full example, refer to “UVM Word Addressable Output Example” on page 257.
• In the following UVM code snippet, note the create_map() method which is affected by
the word addressability settings in the CSV input files. This method allows the creation
of an address map in a block. The arguments of this method are:
o name — The name of the address map.
o base_addr — The base address for the address map.
o n_bytes — The byte-width of the bus on which the map is used. This is related to the
UVM parameter uvmgen.N_BYTES as will be explained later.
o endian — The endianness setting. This is based on the value of the BlockMap
Endian column as will be explained later.
o byte_addressing — The addressing mode. The value “0” indicates word addressing,
and “1” indicates byte addressing.
Note the usage of the endianness setting, which is already defined in the BlockMap
Endian column in the CSV input, as an argument in the create_map() method in the
following code snippet.
// Function: build
//
SUB_MAP1_cg =
sw_sub_block_SUB_MAP1_coverage::type_id::create("SUB_MAP1_cg");
SUB_MAP1_cg.ra_cov.set_inst_name(this.get_full_name());
void'(set_coverage(UVM_CVR_ADDR_MAP));
end
stopwatch_reset_value::type_id::create("stopwatch_reset_value_reg")
;
stopwatch_upper_limit::type_id::create("stopwatch_upper_limit_reg")
;
stopwatch_lower_limit::type_id::create("stopwatch_lower_limit_reg")
;
stopwatch_csr_reg =

stopwatch_memory::type_id::create($psprintf("stopwatch_memory_reg[%
0d]", i));
end
SUB_MAP1 = create_map("SUB_MAP1", 'h0, 4, UVM_BIG_ENDIAN,

0);
default_map = SUB_MAP1;
SUB_MAP1.add_reg(stopwatch_value_reg, 'h0, "RW");

SUB_MAP1.add_reg(stopwatch_reset_value_reg, 'h1, "RW");
SUB_MAP1.add_reg(stopwatch_upper_limit_reg, 'h2, "RW");
SUB_MAP1.add_reg(stopwatch_lower_limit_reg, 'h3, "RW");
SUB_MAP1.add_reg(stopwatch_csr_reg, 'h4, "RW");
SUB_MAP1.add_reg(stopwatch_memory_reg[i], (i * ('h1)) +
('h5), "RW");
end
It is also important to note that the parameter uvmgen.N_BYTES can be used in the
CSV input files to define the word size of the bus to which the address map is
associated. This is only applicable when generating UVM output. The value of this
parameter, which should be specified in terms of bytes, is used as an argument by the
create_map() method. As shown in the above example, the size is “4” bytes.
If this parameter is not specified or if its value is invalid (not a positive integer), then
Register Assistant calculates the value automatically and a warning is raised as shown in
the following example:
Warning: Map 'SW_MAP2' has parameter 'uvmgen.N_BYTES' set to invalid
value 'x'. Only positive integers are allowed. Using automatically
calculated value '4' instead.
Information on this parameter can be found in the OVM/UVM Parameters table which
contains a full list of the supported UVM parameters.
• In the above UVM code snippet, the word addressing settings also impacts the foreach
loop in the calculation of the address increments in the second parameter.
• Another item in the generated code affected by the word addressing mode is
covergroups. The following code snippet shows Register Assistant’s automatic
calculation of instance array addresses in coverpoints.
/* BLOCKS */
//--------------------------------------------------------------
// Class: sw_sub_block_SUB_MAP1_coverage
//
// Coverage for the 'SUB_MAP1' in 'sw_sub_block'
//--------------------------------------------------------------
class sw_sub_block_SUB_MAP1_coverage extends uvm_object;

ùvm_object_utils(sw_sub_block_SUB_MAP1_coverage)
covergroup ra_cov(string name) with function

sample(uvm_reg_addr_t addr, bit is_read);
option.name = name;

bins stopwatch_upper_limit_reg = {'h2};
'h6,
'h7,
'h8,
'h9,
'ha,
'hb,
'hc};
}

bins RD = {1};
bins WR = {0};
}
ACCESS: cross ADDR, RW;
endgroup: ra_cov
function new(string name = "sw_sub_block_SUB_MAP1_coverage");

ra_cov = new(name);
endfunction: new

endfunction: sample
endclass: sw_sub_block_SUB_MAP1_coverage
Related Topics
Chapter 6
Customization
This chapter explains the customization methods supported by Register Assistant.

Custom Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Defining Properties for Register Assistant Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Custom Properties Definition Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Using Custom Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Handling Custom Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
CSV Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
IP-XACT Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Using Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Standard Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Alias-Based Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Custom Properties
Register Assistant’s internal data model consists of a set of objects (for example, register, field,
field value, memories, and so on). The data model provides a set of built-in properties for these
objects, each property holds a certain piece of information related to the object.
Register Assistant enables you to define custom data for objects. That is to say, you can add
custom properties to objects in the data model. For example, if you have certain proprietary
information related to registers which is not available in the data model, Register Assistant
enables you to add a property to the register object to reflect this information. By that, this
information will be accepted by Register Assistant and will not cause errors during the import
process.
You will be able to view the added data in the generated HTML output for documentation
purposes.
Also, you can use this data when creating your own custom generators (other than Register
Assistant’s default generators which produce OVM and HTML output for example) and when
creating your own custom checks script (all using the API commands provided by Register
Assistant).
Customization
Defining Properties for Register Assistant Objects
Defining Properties for Register Assistant

Objects
This procedure show you how to define properties.
Procedure
1. Write a script in JavaScript/Tcl using Register Assistant’s APIs to define your custom
property. See Custom Properties Definition Script.
2. Reference the script in the control file through the following command:
Or:
tcl, file_location/file_name.tcl
The script should be referenced before the import section. Refer to “Control File” on
page 23 for further information on control files.
3. Set the value of the added property.
It is important to note that Register Assistant can automatically extract custom data
when importing from CSV files or from IP-XACT XML format. Hence, you can directly
add a column in your CSV file to define the value of the added object’s property. If you
are using IP-XACT XML format, you can add Vendor Extensions (or attributes). (See
Handling Custom Properties.)
Otherwise, if you are importing from any other format, you will need to use the “set”
APIs in the import script itself in order to assign property values to objects.
RAObject.setCustomData(String ID, Object value);
More information on API commands related to custom data can be found on

<installation_folder>\registerassistant\api\index.html).
Custom Properties Definition Script

To add custom data, you need to write a JavaScript/Tcl file, using the API commands, to mainly
specify the object type (the object to which you need to add the property) and the data type of
the property (string, boolean, integer, etc.).
Note the following JavaScript example which indicates that properties “abc” and “xyz” are
added to the “register” and “field” objects, and that these properties are of type “list” and
“boolean”.
Customization
/* Define some custom data that will be used later in the import */
var applyTo = [RAObject.RAObjectType.REGISTER,

RAObject.RAObjectType.FIELD];
var vals = [null, "1", "2"];
RACustomDataFactory.defineCustomData(applyTo,
RACustomDataFactory.RACustomDataType.LIST, "abc", "", vals);
RACustomDataFactory.defineCustomData(applyTo,
RACustomDataFactory.RACustomDataType.BOOLEAN, "xyz", "Bool Type", null);
return 0;
}
The data types supported for added properties are as follows:

Table 6-1. Supported Data Types
Data Type Comments
STRING Supports values written in any form.
LIST Supports values from a predefined list.
BOOLEAN Supports the values “true” or “false”.
INTEGER Supports integer numbers.
ENG_NUMBER Supports engineering numbers in the formats ([sign] number)
where number can be: (decimal, 0x/0#hex, 0Oct).
Example
This example adds the property “cust_prop”, of type “list”, to the object “register instance”.
var applyToRegI = [RAObject.RAObjectType.REGISTER_INSTANCE];

var vals = [null, "Value1", "Value2"];
RACustomDataFactory.defineCustomData(applyToRegI,
RACustomDataFactory.RACustomDataType.LIST, "cust_prop",
"Custom_Property", vals);
return 0;
}
The following step is to reference the above script in the control file (before the import section).
Customization
Also, if the import takes place from CSV files, then a column should be added in the CSV files
with the title “cust_prop” and the value should be set for each register instance as either
“Value1” or “Value2” or null. If the import takes place from IP-XACT XML files, you can add
Vendor Extensions (or attributes).
On running Register Assistant, the property you added with the ID “Custom_Property” will be
displayed in the HTML output as shown in the following figure:
Customization
Using Custom Properties
Using Custom Properties

You can use custom properties when creating your own custom generators and when creating
your own custom checks script. This is because you have the ability to access and extract the
data you added to Register Assistant’s data model using the following API:
Object RAObject.getCustomData(String id);
More information on API commands related to custom data can be found on

<installation_folder>\registerassistant\api\index.html).
Customization
Handling Custom Properties
Handling Custom Properties

This section explains how Register Assistant handles custom data after the import process takes
place.
CSV Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
IP-XACT Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
CSV Import
The CSV import utility automatically extracts custom data from CSV spreadsheets. The CSV
import utility looks for columns that match the string ID of the added property (added for the
register object for example), and will automatically set the value of that property for the object.
Custom data can be added to the following objects:
• Registers: Can include custom data for Registers, Fields, and Field Values.
• Memory: Can include custom data for Memories and Memory Instances.
• Sub-blocks/Register Files: Can include custom data for Register Instances, and Sub-
block Instances/Register File Instances.
• Block/Memory Map: Can include custom data for Block Instances/Memory Map
Instances, Register Instances, and Sub-block Instances/Register File Instances.
IP-XACT Import
The IP-XACT import utility automatically extracts custom data from IP-XACT files. The IP-
XACT import utility looks for vendor extensions that match the string ID of the property
defined for the current object being imported, and will automatically set the value of that
property for the object.
Based on IP-XACT schema for IEEE Std 1685-2009, only Registers and Fields have Vendor
Extensions. Therefore, custom data import will work only for registers and fields.
For example:
<spirit:register>
<spirit:name>stopwatch_value</spirit:name>
...
<spirit:vendorExtensions>
<idList>2</idList>
</spirit:vendorExtensions>
</spirit:register>
Customization
Parameters
The property “idList” must be defined before using it in IP-XACT import, for example:
var app1 = [RAObject.RAObjectType.REGISTER, RAObject.RAObjectType.FIELD];

var vals = [null, "1", "2"];
RACustomDataFactory.defineCustomData(app1,
RACustomDataFactory.RACustomDataType.LIST, "idList", "", vals);
Parameters
Register Assistant provides a set of predefined parameters you can use with generators such as
the UVM and RTL generators. These parameters enable you to pass to Register Assistant’s
generators extra information that affect the output.
For example, when generating RTL output, you can use certain parameters to set the language
of the generated output to be VHDL. Likewise, when generating UVM output, you can use
certain parameters to specify your own user-defined packages and force certain registers to
extend from classes in these packages (such registers are referred to as quirky registers).
Register Assistant supports a list of fixed parameters each performing a certain function. Refer
to RTL Parameters, OVM/UVM Parameters and C Header Parameters tables to view the full
list of supported parameters, the possible values of each parameter and the default values if the
parameter is not explicitly set, the scope to which the parameter applies, and so on. Each
parameter can be applied to objects within a certain scope such as registers, blocks and projects.
To use parameters, you have to set them in the register input files, whether CSV or JavaScript
input files.
Customization
Using Parameters
Using Parameters
Register Assistant provides several methods to use parameters.
Standard Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Alias-Based Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Standard Method
You can use the parameters feature by adding the required parameters in your input files,
whether CSV files or JavaScript.
To use parameters in CSV files, you have to add the following columns:
• <Object> Parameter Name

• <Object> Parameter Value
• <Object> Parameter Description
See the following example which shows a parameter added in a CSV file for a top block.
Table 6-2. Parameters — Standard Method Example 1
Block Parameter Block Parameter Block Parameter
Name Value Description
rtl.LANGUAGE VHDL_93 Generating VHDL output.
Adding the above columns for the parameter “rtl.LANGUAGE” to the top block CSV file
indicates that you want to change the language of the generated RTL code from Verilog (which
is the default) to VHDL.
Each parameter has a default value which is automatically used by Register Assistant in
generation. To change the default value, you have to explicitly set the parameter. As shown in
the above example, the default language for RTL generation is Verilog; to generate VHDL
output, the corresponding parameter should be set accordingly.
You can refer to RTL Parameters table to view a list of the supported parameters in terms of the
names (such as rtl.LANGUAGE in the above example), the possible values (such as VHDL_93
and VLOG_2005), the default values, and so on.
Following the above example, when using JavaScript as the input source, you can set the
parameter using the following API:
block_name.addParameter ("rtl.LANGUAGE", "VHDL_93", "Generating VHDL

output.");
Customization
Standard Method
Generally, when using JavaScript as the input source, you can use the following format to add
parameters:
<object name>.addParameter(<Object Parameter Name>, <Object Parameter

Value>, <Object Parameter Description>);
Below is another example showing the use of parameters to define quirky registers. The quirky
registers feature enables you to force certain registers to extend from user-defined packages
rather than built-in packages when generating UVM output. The following columns are added
in the CSV files:
Table 6-3. Parameters — Standard Method Example 2
Project Parameter Name Project Parameter Project Parameter
Value Description
uvmgen.EXTRA_IMPORTS mypkg::* pkg2::* Extra imports
The example above sets the parameter “uvmgen.EXTRA_IMPORTS” which signifies that you
will define your own imports in the generated UVM register package as follows:
// Extra imports
import mypkg::*;
import pkg2::*;
In addition to the above columns, you need to add the following columns and place values on
the same line of the register(s) that should extend from alternative parents:
Table 6-4. Parameters — Standard Method Example 2 (Continued)
Register Parameter Name Register Parameter Register Parameter
Value Description
uvmgen.ALT_PARENT my_custom_reg Alternative parent for
this register.
In the above example, the parameter “uvmgen.ALT_PARENT” is set and given a certain value
which is the actual name of the alternative parent. For example, if the above values are placed
on the same line of “Register_X”, then in the generated UVM output, this register will extend
from the class my_custom_reg instead of extending from the built-in class uvm_reg.
You can also use parameters to define quirky registers when using JavaScript as your input
source. The same imports in the above example are set through the following API:
project.addParameter(UVMGenerator.PARAM_EXTRA_IMPORTS, "mypkg::*
pkg2::*", "Extra imports");
Customization
Alias-Based Method
Likewise, the following API signifies that “Register_X” will extend from an alternative parent
called my_custom_reg:
Register_X.addParameter(UVMGenerator.PARAM_ALT_PARENT, "my_custom_reg",
"Alternative parent for this register");
It should be noted that quirky registers are only applicable when generating UVM output. Refer
to “UVM Output” on page 71 for more information on quirky registers.
Note
* The columns <Object> Parameter Name, <Object> Parameter Value and <Object>
Parameter Description are already mapped in the example csv.js file shipped with Register
Assistant. Refer to the CSV Columns list to view the column names mapped in the csv.js file.
* The parameters common among a number of blocks can be defined only once on the project
level. That is to say, if you have a set of parameters with the same set of values, you can define
them only once on the project level rather than defining them on the level of each block
separately.
* Generally, you can add parameters in the CSV files containing the register definitions or the
block definitions. The same also applies to project parameters, but it should be noted that if you
are adding project parameters in a separate CSV file, you will need to add a dummy “Block
Name” column in that file.
Alias-Based Method
Some parameters already have predefined aliases. You can use these aliases to set parameters
when importing register definitions using CSV as the input source.
For example, to set the language of the generated RTL code to be VHDL instead of Verilog, this
can be done through the alias “Block Language”. That is, instead of adding columns for the
parameter name “rtl.LANGUAGE” and adding another column for the value such as
“VHDL_93” as explained in the Standard Method section, you can add a single column in the
top block file with the title “Block Language” and directly give it the value “VHDL_93” as
shown in the following example.
Table 6-5. Parameters — Alias-Based Method Example
Block Name Block Language
Block_XYZ VHDL_93
You have to make sure that the used alias is mapped in the csv.js file. If a parameter does not
have a predefined alias, you can give it any alias and map this alias in the csv.js file.
You can refer to RTL Parameters to view a table containing a list of the supported RTL
parameters in terms of the names (such as rtl.LANGUAGE), the possible values (such as
Customization
Alias-Based Method
VHDL_93 and VLOG_2005), the predefined aliases (that is, the CSV column title such as
Block Language) if available.
Related Topics
Customization
Alias-Based Method
Appendix A
Command Line Switches
This appendix provides command line switches to run the Register Assistant.
Running Register Assistant in Batch Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

By default, you invoke Register Assistant in batch mode (command-line interface). A GUI
wizard is also available by using the -gui switch.
Procedure
1. Run the following command to invoke the Register Assistant:
regassist -project <output_directory> -f <control_file.rcf> [-
projectName<project_name>] [-help] [-version]
2. Use the command switches listed in the following table when invoking Register
Assistant.
Table A-1. Command Line Switches

Name Description
-project <output_directory> Specifies the location of the project directory in which
the generated files will be placed. This argument is
required.
-f <control_file.rcf> Takes the location of the control file as an argument. The
control file specifies the list of generators to run in
sequence, each line in the file represents a generator in
the form: <generator_language>,<generator_name>.
See “Control File” on page 23 for more information.
-projectName <project_name> Specifies the name of the project. This argument is
optional.
If specified, the project name will be used in the
generated output.
If not specified, Register Assistant will use the name of
the provided project directory instead in the generated
output.
-help Lists all the command line switches that can be used with
Register Assistant and their description.
Table A-1. Command Line Switches (cont.)

Name Description
-version Prints the current version of Register Assistant.
-gui Launches the Register Assistant wizard and places the
generated outputs in the location specified by the -project
<output_directory> switch.
-about Prints the name and version of Register Assistant.
3. (Optional) You can run Register Assistant in GUI mode by invoking the wizard with the
following command:
regassist –gui –project <output_directory>
Appendix B
Examples
This appendix contains miscellaneous examples for different Register Assistant input and
output files.
JavaScript/Tcl Import File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
UVM Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
OVM Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
RTL Pipelining Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
UVM Word Addressable Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
JavaScript/Tcl Import File Example

The following examples are JavaScript and Tcl examples that contain the same register
definitions. These examples depict a generator that uses Register Assistant’s APIs to create a
stop watch. They illustrate the use of the API calls to construct blocks/memory maps, sub-
blocks/register files, register definitions, fields and instances.
The examples have a single block/memory map containing two instances of the same sub-block/
register file, and this sub-block/register file has six instances of six different registers.
The examples also shows fields using reset values from the overall register reset values rather
than field-specific reset values.
For more information using scripts, refer to “Importing Data from Scripts” on page 45.
Example 1 — JavaScript
Examples
// Stopwatch UVM register example
importPackage(com.mentor.regassist.suppliedgenerators);
project.setName("sw_reg");
project.setDescription("Stopwatch UVM Project");
project.addParameter(UVMGenerator.PARAM_EXTRA_IMPORTS, "my_pkg::*", "");
// Register: Stopwatch Value

var stopwatch_value = project.addRegister("stopwatch_value");
stopwatch_value.setDescription("Current value");
stopwatch_value.setSize(32);
// Field: F (auto)
var stopwatch_value_F = stopwatch_value.addField("F");
stopwatch_value_F.setBitWidth(32);
stopwatch_value_F.setBitOffset(0);
stopwatch_value_F.setAccess(RAAccessType.READ_ONLY);
stopwatch_value_F.setResetValue("0x0");
// Register: Stopwatch Counter

var stopwatch_counter = project.addRegister("stopwatch_counter");
stopwatch_counter.setDescription("Stop Watch Counter");
stopwatch_counter.setSize(32);
// Field: F (auto)
var stopwatch_counter_F = stopwatch_counter.addField("F");
stopwatch_counter_F.setBitWidth(32);
stopwatch_counter_F.setBitOffset(0);
stopwatch_counter_F.setAccess(RAAccessType.READ_WRITE);
stopwatch_counter_F.setResetValue("0x0");
// Register: Stopwatch Reset Value

var stopwatch_reset_value = project.addRegister("stopwatch_reset_value");
stopwatch_reset_value.setDescription("Reset value");
stopwatch_reset_value.setSize(32);
// Field: F (auto)
var stopwatch_reset_value_F = stopwatch_reset_value.addField("F");
stopwatch_reset_value_F.setBitWidth(32);
stopwatch_reset_value_F.setBitOffset(0);
stopwatch_reset_value_F.setAccess(RAAccessType.READ_WRITE);
stopwatch_reset_value_F.setResetValue("0x0");
// Register: Stopwatch Upper Limit

var stopwatch_upper_limit = project.addRegister("stopwatch_upper_limit");
stopwatch_upper_limit.setDescription("Upper limit");
stopwatch_upper_limit.setSize(32);
// Field: F (auto)
var stopwatch_upper_limit_F = stopwatch_upper_limit.addField("F");
stopwatch_upper_limit_F.setBitWidth(32);
stopwatch_upper_limit_F.setBitOffset(0);
stopwatch_upper_limit_F.setAccess(RAAccessType.READ_WRITE);
stopwatch_upper_limit_F.setResetValue("0x0");
Examples
// Register: Stopwatch Lower Limit

var stopwatch_lower_limit = project.addRegister("stopwatch_lower_limit");
stopwatch_lower_limit.setDescription("Lower limit");
stopwatch_lower_limit.setSize(32);
// Field: F (auto)
var stopwatch_lower_limit_F = stopwatch_lower_limit.addField("F");
stopwatch_lower_limit_F.setBitWidth(32);
stopwatch_lower_limit_F.setBitOffset(0);
stopwatch_lower_limit_F.setAccess(RAAccessType.READ_WRITE);
stopwatch_lower_limit_F.setResetValue("0x0");
// Register: Stopwatch Memory

var stopwatch_memory = project.addRegister("stopwatch_memory");
stopwatch_memory.setDescription("Memory register");
stopwatch_memory.setSize(32);
// Field: F (auto)
var stopwatch_memory_F = stopwatch_memory.addField("F");
stopwatch_memory_F.setBitWidth(32);
stopwatch_memory_F.setBitOffset(0);
stopwatch_memory_F.setAccess(RAAccessType.READ_WRITE);
stopwatch_memory_F.setResetValue("0x0");
// Register: Stopwatch CSR

var stopwatch_csr = project.addRegister("stopwatch_csr");
stopwatch_csr.setDescription("Control Status Register");
stopwatch_csr.setSize(32);
// Field: Padding
var padding = stopwatch_csr.addField("padding");
padding.setDescription("Reserved");
padding.setBitWidth(25);
padding.setBitOffset(7);
padding.setAccess(RAAccessType.READ_WRITE);
padding.setResetValue("0x0");
padding.setCover(false);
padding.setReserved(true);
// Field: Stride
var stride = stopwatch_csr.addField("stride");
stride.setDescription("Stride length");
stride.setBitWidth(4);
stride.setBitOffset(3);
stride.setAccess(RAAccessType.READ_WRITE);
stride.setResetValue("0x0");
stride.setConstraints("constraint my_constraint {x > 5;}");
// Field: Updown
var updown = stopwatch_csr.addField("updown");
updown.setDescription("Indicates whether counting up or down");
updown.setBitWidth(1);
updown.setBitOffset(2);
updown.setAccess(RAAccessType.READ_WRITE);
updown.setResetValue("0x0");
Examples
// Field: Upper Limit Reached

var upper_limit_reached =
stopwatch_csr.addField("upper_limit_reached");
upper_limit_reached.setDescription("Indicates that the upper limit has
been reached");
upper_limit_reached.setBitWidth(1);
upper_limit_reached.setBitOffset(1);
upper_limit_reached.setAccess(RAAccessType.READ_ONLY);
upper_limit_reached.setResetValue("0x0");
// Field: Lower Limit Reached

var lower_limit_reached =
stopwatch_csr.addField("lower_limit_reached");
lower_limit_reached.setDescription("Indicates that the lower limit has
been reached");
lower_limit_reached.setBitWidth(1);
lower_limit_reached.setBitOffset(0);
lower_limit_reached.setAccess(RAAccessType.READ_ONLY);
lower_limit_reached.setResetValue("0x0");
// Memory: My Mem
var my_mem = project.addMemory("my_mem");
my_mem.setDescription("Memory");
my_mem.setRange("0x400");
my_mem.setWidth(32);
my_mem.setAccess(RAAccessType.READ_WRITE);
// Register: My Reg
var my_reg = project.addRegister("my_reg");
my_reg.setDescription("Custom register");
my_reg.addParameter(UVMGenerator.PARAM_ALT_PARENT, "my_reg_type", "");
my_reg.setSize(32);
// Field: F
var my_reg_F = my_reg.addField("F");
my_reg_F.setBitWidth(32);
my_reg_F.setBitOffset(0);
my_reg_F.setAccess(RAAccessType.READ_WRITE);
my_reg_F.setResetValue("0x0");
// Create SW Sub Block //

var sw_sub_block = project.addBlock("sw_sub_block");
sw_sub_block.setDescription("Sub_block for the stopwatch design");
sw_sub_block.setCoverage(RABlock.COVERAGE.UVM_CVR_ADDR_MAP);
var stopwatch_value_reg =
sw_sub_block.addRegisterInstance("stopwatch_value",
"stopwatch_value_reg");
stopwatch_value_reg.setDescription("Value instance");
var stopwatch_reset_value_reg =
sw_sub_block.addRegisterInstance("stopwatch_reset_value",
"stopwatch_reset_value_reg");
stopwatch_reset_value_reg.setDescription("Reset Value instance");
var stopwatch_upper_limit_reg =
sw_sub_block.addRegisterInstance("stopwatch_upper_limit",
Examples
"stopwatch_upper_limit_reg");
stopwatch_upper_limit_reg.setDescription("Upper Limit instance");
sw_sub_block.addRegisterInstance("stopwatch_lower_limit",
"stopwatch_lower_limit_reg");
stopwatch_lower_limit_reg.setDescription("Lower Limit instance");
var stopwatch_csr_reg = sw_sub_block.addRegisterInstance("stopwatch_csr",

"stopwatch_csr_reg");
stopwatch_csr_reg.setDescription("CSR instance");
var stopwatch_memory_reg =
sw_sub_block.addRegisterInstance("stopwatch_memory",
"stopwatch_memory_reg");
stopwatch_memory_reg.setDescription("MEM instances");
stopwatch_memory_reg.setDimension(8);
// Create MAP for SW Sub Block //

var SW_MAP = sw_sub_block.addMap("SW_MAP");
SW_MAP.setDescription("SW sub block map");
SW_MAP.addAddress("stopwatch_value_reg", "0x04",
RAAccessType.READ_WRITE);
SW_MAP.addAddress("stopwatch_reset_value_reg", "0x08",
SW_MAP.addAddress("stopwatch_upper_limit_reg", "0x0C",
SW_MAP.addAddress("stopwatch_lower_limit_reg", "0x10",
SW_MAP.addAddress("stopwatch_csr_reg", "0x14", RAAccessType.READ_WRITE);
SW_MAP.addAddress("stopwatch_memory_reg", "0x34",
// Create Top Block //

var sw_top_block = project.addBlock("sw_top_block");
sw_top_block.setDescription("Top block for the stopwatch design");
sw_top_block.setCoverage(RABlock.COVERAGE.UVM_CVR_ADDR_MAP);
project.setTopBlock(sw_top_block);



"vreg1");
vreg1.setBackdoorPath("top.counter1.count");
vreg1.addParameter("uvmAttribute.NO_REG_HW_RESET_TEST", "1", "Prevents
the reset test being run on this register instance");
Examples

"vreg2");

"vreg3");
var mem1 = sw_top_block.addMemoryInstance("my_mem", "mem1");

mem1.setDescription("Memory instance");
var my_reg1 = sw_top_block.addRegisterInstance("my_reg", "my_reg1");

my_reg1.setDescription("Custom register instance");
// Create MAP for Top Block //

var SW_MAP2 = sw_top_block.addMap("SW_MAP2");
SW_MAP2.setDescription("SW top block map");
SW_MAP2.addAddress("sw1.SW_MAP", "0x1000", RAAccessType.READ_WRITE);
SW_MAP2.addAddress("sw2.SW_MAP", "0x2000", RAAccessType.READ_WRITE);
SW_MAP2.addAddress("vreg1", "0x3000", RAAccessType.READ_WRITE);
SW_MAP2.addAddress("my_reg1", "0x300C", RAAccessType.READ_WRITE);
SW_MAP2.addAddress("mem1", "0x4000", RAAccessType.READ_WRITE);
return 0;
}
Example 2 — Tcl
Examples
# Stopwatch register example
set projName [::raGetProjectName]

::raSetProjectDescription "Stopwatch Project"
# Create Memory Map

::raCreateMemoryMap "stopwatch_register_map" ""
::raAddMemoryMapInstance $projName "stopwatch_register_map"
"register_map" ""
# Create Register File

::raCreateRegisterFile "stopwatch_register_file" "Register file for the
stopwatch design"
# Register: Stopwatch Value

::raCreateRegister "stopwatch_value" ""
::raSetRegisterAddressOffset "stopwatch_value" "0x0"
::raSetRegisterSize "stopwatch_value" 32
::raSetRegisterIsVolatile "stopwatch_value" 1
::raSetRegisterResetValue "stopwatch_value" "0x0"
::raSetRegisterResetMask "stopwatch_value" "0xFFFFFFFF"
::raSetRegisterAccess "stopwatch_value" "read-only"
# Register: Stopwatch Reset Value

::raCreateRegister "stopwatch_reset_value" ""
::raSetRegisterAddressOffset "stopwatch_reset_value" "0x04"
::raSetRegisterSize "stopwatch_reset_value" 32
::raSetRegisterIsVolatile "stopwatch_reset_value" 1
::raSetRegisterResetValue "stopwatch_reset_value" "0x0"
::raSetRegisterResetMask "stopwatch_reset_value" "0xFFFFFFFF"
::raSetRegisterAccess "stopwatch_reset_value" "read-write"
# Register: Stopwatch Upper Limit

::raCreateRegister "stopwatch_upper_limit" ""
::raSetRegisterAddressOffset "stopwatch_upper_limit" "0x08"
::raSetRegisterSize "stopwatch_upper_limit" 32
::raSetRegisterIsVolatile "stopwatch_upper_limit" 1
::raSetRegisterResetValue "stopwatch_upper_limit" "0x0"
::raSetRegisterResetMask "stopwatch_upper_limit" "0xFFFFFFFF"
::raSetRegisterAccess "stopwatch_upper_limit" "read-write"
# Register: Stopwatch Lower Limit

::raCreateRegister "stopwatch_lower_limit" ""
::raSetRegisterAddressOffset "stopwatch_lower_limit" "0x0C"
::raSetRegisterSize "stopwatch_lower_limit" 32
::raSetRegisterIsVolatile "stopwatch_lower_limit" 1
::raSetRegisterResetValue "stopwatch_lower_limit" "0x0"
::raSetRegisterResetMask "stopwatch_lower_limit" "0xFFFFFFFF"
::raSetRegisterAccess "stopwatch_lower_limit" "read-write"
# Register: Stopwatch Memory

::raCreateRegister "stopwatch_memory" ""
::raSetRegisterAddressOffset "stopwatch_memory" "0x010"
::raSetRegisterSize "stopwatch_memory" 32
::raSetRegisterIsVolatile "stopwatch_memory" 1
::raSetRegisterResetValue "stopwatch_memory" "0x0"
::raSetRegisterResetMask "stopwatch_memory" "0xFFFFFFFF"
::raSetRegisterAccess "stopwatch_memory" "read-write"
Examples
# Register: Stopwatch CSR

::raCreateRegister "stopwatch_csr" ""
::raSetRegisterAddressOffset "stopwatch_csr" "0x030"
::raSetRegisterSize "stopwatch_csr" 32
::raSetRegisterIsVolatile "stopwatch_csr" 1
::raSetRegisterResetValue "stopwatch_csr" "0xEFFFFFF7"
::raSetRegisterResetMask "stopwatch_csr" "0xFFFFFFFF"
::raSetRegisterAccess "stopwatch_csr" "read-write"
# Field: Padding
::raAddRegisterField "stopwatch_csr" "padding" "Reserved"
::raSetFieldBitOffset "stopwatch_csr" "padding" 7
::raSetFieldBitWidth "stopwatch_csr" "padding" 25
::raSetFieldAccess "stopwatch_csr" "padding" "read-write"
# ::raSetFieldResetValue "stopwatch_csr" "padding" "0x0"
::raSetFieldResetMask "stopwatch_csr" "padding" "0xFFFFFFFF"
::raSetFieldReserved "stopwatch_csr" "padding" 1
# Field: Stride
::raAddRegisterField "stopwatch_csr" "stride" "Stride length"
::raSetFieldBitOffset "stopwatch_csr" "stride" 3
::raSetFieldBitWidth "stopwatch_csr" "stride" 4
::raSetFieldAccess "stopwatch_csr" "stride" "read-write"
# ::raSetFieldResetValue "stopwatch_csr" "stride" "0x0"
::raSetFieldResetMask "stopwatch_csr" "stride" "0xFFFFFFFF"
::raSetFieldCover "stopwatch_csr" "stride" 1
# Field: Updown
::raAddRegisterField "stopwatch_csr" "updown" "Indicates whether
counting up or down"
::raSetFieldBitOffset "stopwatch_csr" "updown" 2
::raSetFieldBitWidth "stopwatch_csr" "updown" 1
::raSetFieldAccess "stopwatch_csr" "updown" "read-write"
# ::raSetFieldResetValue "stopwatch_csr" "updown" "0x0"
::raSetFieldResetMask "stopwatch_csr" "updown" "0xFFFFFFFF"
::raSetFieldCover "stopwatch_csr" "updown" 1
::raAddFieldValue "stopwatch_csr" "updown" "countDown" "Counting down"
"0"
::raAddFieldValue "stopwatch_csr" "updown" "countUp" "Counting up" "1"
# Field: Upper Limit Reached

::raAddRegisterField "stopwatch_csr" "upper_limit_reached" "Indicates
that the upper limit has been reached"
::raSetFieldBitOffset "stopwatch_csr" "upper_limit_reached" 1
::raSetFieldBitWidth "stopwatch_csr" "upper_limit_reached" 1
::raSetFieldAccess "stopwatch_csr" "upper_limit_reached" "read-only"
# ::raSetFieldResetValue "stopwatch_csr" "upper_limit_reached" "0x0"
::raSetFieldResetMask "stopwatch_csr" "upper_limit_reached"
"0xFFFFFFFF"
::raSetFieldCover "stopwatch_csr" "upper_limit_reached" 1
# Field: Lower Limit Reached

::raAddRegisterField "stopwatch_csr" "lower_limit_reached" "Indicates
that the lower limit has been reached"
::raSetFieldBitOffset "stopwatch_csr" "lower_limit_reached" 0
::raSetFieldBitWidth "stopwatch_csr" "lower_limit_reached" 1
::raSetFieldAccess "stopwatch_csr" "lower_limit_reached" "read-only"
Examples
UVM Output Example
# ::raSetFieldResetValue "stopwatch_csr" "lower_limit_reached" "0x0"

::raSetFieldResetMask "stopwatch_csr" "lower_limit_reached"
"0xFFFFFFFF"
::raSetFieldCover "stopwatch_csr" "lower_limit_reached" 1
::raAddRegisterInstance "stopwatch_register_file" "stopwatch_value"

"VALUE" ""
::raSetRegisterInstanceResetValue "stopwatch_register_file" "VALUE" "0x0"
::raAddRegisterInstance "stopwatch_register_file" "stopwatch_reset_value"
"RESET_VALUE" ""
::raSetRegisterInstanceResetValue "stopwatch_register_file" "RESET_VALUE"
"0x0"
::raAddRegisterInstance "stopwatch_register_file" "stopwatch_upper_limit"
"UPPER_LIMIT" ""
::raSetRegisterInstanceResetValue "stopwatch_register_file" "UPPER_LIMIT"
"0x0"
::raAddRegisterInstance "stopwatch_register_file" "stopwatch_lower_limit"
"LOWER_LIMIT" ""
::raSetRegisterInstanceResetValue "stopwatch_register_file" "LOWER_LIMIT"
"0x0"
::raAddRegisterInstance "stopwatch_register_file" "stopwatch_csr" "CSR"
""
::raAddRegisterInstance "stopwatch_register_file" "stopwatch_memory"
"MEM" ""
::raSetRegisterInstanceDimension "stopwatch_register_file" "MEM" 8
::raSetRegisterInstanceResetValue "stopwatch_register_file" "MEM" "0x0"
::raAddRegisterFileInstance "stopwatch_register_map"
"stopwatch_register_file" "sw1" ""
::raAddRegisterFileInstance "stopwatch_register_map"
"stopwatch_register_file" "sw2" ""
::raSetRegisterFileInstanceAddressOffset "stopwatch_register_map" "sw1"

"0x1000"
::raSetRegisterFileInstanceAddressOffset "stopwatch_register_map" "sw2"
"0x2000"
UVM Output Example

The following example shows the UVM register package generated by Register Assistant.
For more information on UVM generation, refer to “UVM Output” on page 71.
Examples
UVM Output Example
package output_pkg_uvm;
import uvm_pkg::*;
import mypkg::*;
ìnclude "uvm_macros.svh"
/* DEFINE REGISTER CLASSES */
//--------------------------------------------------------------------
// Class: stopwatch_lower_limit
//
// Lower limit
//--------------------------------------------------------------------
class stopwatch_lower_limit extends uvm_reg;

ùvm_object_utils(stopwatch_lower_limit)
// Function: new
//
function new(string name = "stopwatch_lower_limit");
endfunction
// Function: build
//
endfunction
endclass
//--------------------------------------------------------------------
// Class: stopwatch_upper_limit
//
// Upper limit
//--------------------------------------------------------------------
class stopwatch_upper_limit extends uvm_reg;

ùvm_object_utils(stopwatch_upper_limit)
// Function: new
//
function new(string name = "stopwatch_upper_limit");
endfunction
// Function: build
//
Examples
UVM Output Example

endfunction
endclass
//--------------------------------------------------------------------
// Class: stopwatch_reset_value
//
// Reset value
//--------------------------------------------------------------------
class stopwatch_reset_value extends uvm_reg;

ùvm_object_utils(stopwatch_reset_value)
// Function: new
//
function new(string name = "stopwatch_reset_value");
endfunction
// Function: build
//
endfunction
endclass
//--------------------------------------------------------------------
// Class: stopwatch_memory
//
// Memory register
//--------------------------------------------------------------------
class stopwatch_memory extends uvm_reg;

ùvm_object_utils(stopwatch_memory)
// Function: new
//
function new(string name = "stopwatch_memory");
endfunction
// Function: build
//
endfunction
endclass
//--------------------------------------------------------------------
Examples
UVM Output Example
//
//--------------------------------------------------------------------

uvm_reg_field padding; // Reserved

rand uvm_reg_field stride; // Stride length
rand uvm_reg_field updown; // Indicates whether counting up or down
uvm_reg_field upper_limit_reached; // Indicates that the upper limit
has been reached
uvm_reg_field lower_limit_reached; // Indicates that the lower limit
has been reached
//
covergroup cg_vals;
endgroup
// Constraints
constraint my_constraint {x > 5;}
// Function: new
//
add_coverage(build_coverage(UVM_CVR_FIELD_VALS));
if(has_coverage(UVM_CVR_FIELD_VALS))
cg_vals = new();
endfunction
//
cg_vals.sample();
endfunction
// Function: build
//
padding.configure(this, 25, 7, "RW", 0,

25'b0000000000000000000000000, 1, 0, 0);
Examples
UVM Output Example

endfunction
endclass
//--------------------------------------------------------------------
// Class: stopwatch_value
//
// Current value
//--------------------------------------------------------------------
class stopwatch_value extends uvm_reg;

ùvm_object_utils(stopwatch_value)
uvm_reg_field F;
// Function: new
//
function new(string name = "stopwatch_value");
endfunction
// Function: build
//
F.configure(this, 32, 0, "RO", 1, 32'h00000000, 1, 0, 1);
endfunction
endclass
//--------------------------------------------------------------------
// Class: my_mem
//
// Memory
//--------------------------------------------------------------------
class my_mem extends uvm_mem;

ùvm_object_utils(my_mem)
// Function: new
//
function new(string name = "my_mem");
super.new(name, 'h400, 32, "RW", UVM_NO_COVERAGE);
endfunction
endclass
//--------------------------------------------------------------------
// Class: my_reg
//
// Custom register
//--------------------------------------------------------------------
Examples
UVM Output Example
class my_reg extends my_reg_type;

ùvm_object_utils(my_reg)
// Function: new
//
function new(string name = "my_reg");
endfunction
// Function: build
//
endfunction
endclass
//--------------------------------------------------------------------
//
//--------------------------------------------------------------------
class stopwatch_counter extends uvm_reg;

// Function: new
//
endfunction
// Function: build
//
endfunction
endclass
/* BLOCKS */
//--------------------------------------------------------------------
// Class: sw_sub_block_SW_MAP_coverage
//
// Coverage for the 'SW_MAP' in 'sw_sub_block'
//--------------------------------------------------------------------
class sw_sub_block_SW_MAP_coverage extends uvm_object;

ùvm_object_utils(sw_sub_block_SW_MAP_coverage)
Examples
UVM Output Example

addr, bit is_read);
option.name = name;

bins stopwatch_upper_limit_reg = {'hc};
'h38,
'h3c,
'h40,
'h44,
'h48,
'h4c,
'h50};
}

bins RD = {1};
bins WR = {0};
}
endgroup: ra_cov
function new(string name = "sw_sub_block_SW_MAP_coverage");

ra_cov = new(name);
endfunction: new

endfunction: sample
endclass: sw_sub_block_SW_MAP_coverage
//--------------------------------------------------------------------
// Class: sw_sub_block
//
// Sub_block for the stopwatch design
//--------------------------------------------------------------------
class sw_sub_block extends uvm_reg_block;

ùvm_object_utils(sw_sub_block)

rand stopwatch_reset_value stopwatch_reset_value_reg; // Reset Value
instance
rand stopwatch_upper_limit stopwatch_upper_limit_reg; // Upper Limit
instance
rand stopwatch_lower_limit stopwatch_lower_limit_reg; // Lower Limit
Examples
UVM Output Example
instance
uvm_reg_map SW_MAP; // SW sub block map

sw_sub_block_SW_MAP_coverage SW_MAP_cg;
// Function: new
//
function new(string name = "sw_sub_block");
super.new(name, build_coverage(UVM_CVR_ALL));
endfunction
// Function: build
//
SW_MAP_cg =
sw_sub_block_SW_MAP_coverage::type_id::create("SW_MAP_cg");
SW_MAP_cg.ra_cov.set_inst_name(this.get_full_name());
end
stopwatch_csr_reg =

i));
end
SW_MAP = create_map("SW_MAP", 'h0, 4, UVM_LITTLE_ENDIAN, 1);

default_map = SW_MAP;
Examples
UVM Output Example
SW_MAP.add_reg(stopwatch_value_reg, 'h4, "RW");

SW_MAP.add_reg(stopwatch_reset_value_reg, 'h8, "RW");
SW_MAP.add_reg(stopwatch_upper_limit_reg, 'hc, "RW");
SW_MAP.add_reg(stopwatch_lower_limit_reg, 'h10, "RW");
SW_MAP.add_reg(stopwatch_csr_reg, 'h14, "RW");
SW_MAP.add_reg(stopwatch_memory_reg[i], (i * ('h4)) + ('h34),
"RW");
end
lock_model();
endfunction
// Function: sample
//
map);
if(map.get_name() == "SW_MAP") begin
SW_MAP_cg.sample(offset, is_read);
end
end
endfunction: sample
endclass
//--------------------------------------------------------------------
// Class: sw_top_block_SW_MAP2_coverage
//
// Coverage for the 'SW_MAP2' in 'sw_top_block'
//--------------------------------------------------------------------
class sw_top_block_SW_MAP2_coverage extends uvm_object;

ùvm_object_utils(sw_top_block_SW_MAP2_coverage)

addr, bit is_read);
option.name = name;

bins vreg1 = {'h3000};
bins my_reg1 = {'h300c};
}

bins RD = {1};
bins WR = {0};
}
endgroup: ra_cov
Examples
UVM Output Example
function new(string name = "sw_top_block_SW_MAP2_coverage");

ra_cov = new(name);
endfunction: new

endfunction: sample
endclass: sw_top_block_SW_MAP2_coverage
//--------------------------------------------------------------------
// Class: sw_top_block
//
// Top block for the stopwatch design
//--------------------------------------------------------------------
class sw_top_block extends uvm_reg_block;

ùvm_object_utils(sw_top_block)
rand sw_sub_block sw1; // Block1 instance 1

rand sw_sub_block sw2; // Block1 instance 2
rand stopwatch_counter vreg1; // Counter instance 1
rand my_reg my_reg1; // Custom register instance
my_mem mem1; // Memory instance
uvm_reg_map SW_MAP2; // SW top block map

sw_top_block_SW_MAP2_coverage SW_MAP2_cg;
// Function: new
//
function new(string name = "sw_top_block");
endfunction
// Function: build
//
SW_MAP2_cg =
sw_top_block_SW_MAP2_coverage::type_id::create("SW_MAP2_cg");
SW_MAP2_cg.ra_cov.set_inst_name(this.get_full_name());
end
sw1 = sw_sub_block::type_id::create("sw1");
sw1.configure(this);
sw1.build();
sw2.build();
vreg1 = stopwatch_counter::type_id::create("vreg1");
vreg1.configure(this, null, "top.counter1.count");
Examples
OVM Output Example
vreg1.build();
vreg2.configure(this, null, "top.counter2.counter_i0.count");
vreg2.build();
vreg3.configure(this, null, "top.counter2.counter_i1.count");
vreg3.build();
my_reg1 = my_reg::type_id::create("my_reg1");
my_reg1.configure(this);
my_reg1.build();
mem1 = my_mem::type_id::create("mem1");
mem1.configure(this);
SW_MAP2 = create_map("SW_MAP2", 'h0, 4, UVM_LITTLE_ENDIAN, 1);

default_map = SW_MAP2;
SW_MAP2.add_submap(sw1.SW_MAP, 'h1000);
SW_MAP2.add_submap(sw2.SW_MAP, 'h2000);
SW_MAP2.add_reg(vreg1, 'h3000, "RW");
SW_MAP2.add_reg(my_reg1, 'h300c, "RW");
SW_MAP2.add_mem(mem1, 'h4000, "RW");
// Prevents the reset test being run on this register instance

uvm_resource_db #(bit)::set({"REG::",
this.vreg1.get_full_name()}, "NO_REG_HW_RESET_TEST", 1);
lock_model();
endfunction
// Function: sample
//
map);
if(map.get_name() == "SW_MAP2") begin
SW_MAP2_cg.sample(offset, is_read);
end
end
endfunction: sample
endclass
endpackage
OVM Output Example

The following example shows the OVM register package generated by Register Assistant.
For more information on OVM generation, refer to “OVM Output” on page 94.
Examples
OVM Output Example
package output_pkg_ovm;
import ovm_pkg::*;
ìnclude "ovm_macros.svh"
import ovm_register_pkg::*;
ìnclude "ovm_register_macros.svh"
/* DEFINE TYPES FOR THE DATA CONTAINED IN THE REGISTERS */
// Types for enums

typedef enum bit {stopwatch_csr_updown_countDown=1'b0,
stopwatch_csr_updown_countUp=1'b1} stopwatch_csr_updown_enum;
// Types for non-field registers
typedef bit[31:0] bit32_t;
// Types for registers which have fields
typedef struct packed {

// Reserved
bit[31:7] padding;
// Stride length
bit[6:3] stride;
// Indicates whether counting up or down
stopwatch_csr_updown_enum updown;
// Indicates that the upper limit has been reached
bit upper_limit_reached;
// Indicates that the lower limit has been reached
bit lower_limit_reached;
} stopwatch_csr_t;
//--------------------------------------------------------------------
// stopwatch_lower_limit
//--------------------------------------------------------------------
// Lower limit
class stopwatch_lower_limit extends ovm_register #(bit32_t);
òvm_named_object_utils(stopwatch_lower_limit)
//------------------------------------------------------------------
// new
//------------------------------------------------------------------
function new(string name, ovm_named_object parent);
super.new(name, parent);
ovm_report_info("stopwatch_lower_limit::new()", get_full_name());
endfunction
endclass
//--------------------------------------------------------------------
// stopwatch_upper_limit
//--------------------------------------------------------------------
// Upper limit
class stopwatch_upper_limit extends ovm_register #(bit32_t);
Examples
OVM Output Example
òvm_named_object_utils(stopwatch_upper_limit)
//------------------------------------------------------------------
// new
//------------------------------------------------------------------
ovm_report_info("stopwatch_upper_limit::new()", get_full_name());
endfunction
endclass
//--------------------------------------------------------------------
// stopwatch_reset_value
//--------------------------------------------------------------------
// Reset value
class stopwatch_reset_value extends ovm_register #(bit32_t);
òvm_named_object_utils(stopwatch_reset_value)
//------------------------------------------------------------------
// new
//------------------------------------------------------------------
ovm_report_info("stopwatch_reset_value::new()", get_full_name());
endfunction
endclass
//--------------------------------------------------------------------
// stopwatch_csr
//--------------------------------------------------------------------
class stopwatch_csr extends ovm_register #(stopwatch_csr_t);
òvm_named_object_utils(stopwatch_csr)
òvm_register_begin_fields
òvm_register_field(stride)
òvm_register_enum_field(updown, stopwatch_csr_updown_enum)
òvm_register_field(upper_limit_reached)
òvm_register_field(lower_limit_reached)
òvm_register_end_fields
//------------------------------------------------------------------
// coverage
//------------------------------------------------------------------
covergroup c;
stride : coverpoint data.stride;
updown : coverpoint data.updown;
upper_limit_reached : coverpoint data.upper_limit_reached;
lower_limit_reached : coverpoint data.lower_limit_reached;
endgroup
//------------------------------------------------------------------
// sample
//------------------------------------------------------------------
function void sample();
c.sample();
endfunction
Examples
OVM Output Example
//------------------------------------------------------------------
// new
//------------------------------------------------------------------
ovm_report_info("stopwatch_csr::new()", get_full_name());
c = new();
àdd_field_rw(stride, 4'h0);
àdd_enum_field_rw(updown, stopwatch_csr_updown_countDown,
stopwatch_csr_updown_enum);
àdd_field_ro(upper_limit_reached, 1'b0);
àdd_field_ro(lower_limit_reached, 1'b0);
endfunction
//------------------------------------------------------------------
// convert2string
//------------------------------------------------------------------
function string convert2string();
return $psprintf("CSR: (%p) (%x %x %x %x %x )", data,
data.padding, data.stride, data.updown, data.upper_limit_reached,
data.lower_limit_reached);
endfunction
endclass
//--------------------------------------------------------------------
// stopwatch_memory
//--------------------------------------------------------------------
// Memory register
class stopwatch_memory extends ovm_register #(bit32_t);
òvm_named_object_utils(stopwatch_memory)
//------------------------------------------------------------------
// new
//------------------------------------------------------------------
ovm_report_info("stopwatch_memory::new()", get_full_name());
endfunction
endclass
//--------------------------------------------------------------------
// stopwatch_value
//--------------------------------------------------------------------
// Current value
class stopwatch_value extends ovm_register #(bit32_t);
òvm_named_object_utils(stopwatch_value)
//------------------------------------------------------------------
// new
//------------------------------------------------------------------
ovm_report_info("stopwatch_value::new()", get_full_name());
WMASK = 32'h00000000;
endfunction
endclass
Examples
OVM Output Example
/* REGISTER FILE */
//--------------------------------------------------------------------
// sw_reg_file
//--------------------------------------------------------------------
class sw_reg_file extends ovm_register_file;
òvm_named_object_utils(sw_reg_file)
// Value instance
rand stopwatch_valueVALUE;
// Reset Value instance
rand stopwatch_reset_valueRESET_VALUE;
// Upper Limit instance
rand stopwatch_upper_limitUPPER_LIMIT;
// Lower Limit instance
rand stopwatch_lower_limitLOWER_LIMIT;
// CSR instance
rand stopwatch_csrCSR;
// MEM instances
rand stopwatch_memoryMEM[8];
//------------------------------------------------------------------
// new
//------------------------------------------------------------------
ovm_report_info("sw_reg_file::new()", get_full_name());
VALUE = stopwatch_value::type_id::create("VALUE", this);

RESET_VALUE =
stopwatch_reset_value::type_id::create("RESET_VALUE", this);
UPPER_LIMIT =
stopwatch_upper_limit::type_id::create("UPPER_LIMIT", this);
LOWER_LIMIT =
stopwatch_lower_limit::type_id::create("LOWER_LIMIT", this);
CSR = stopwatch_csr::type_id::create("CSR", this);
foreach(MEM[i]) begin
MEM[i] =
stopwatch_memory::type_id::create($psprintf("MEM[%0d]", i), this);
end
VALUE.set_reset_value(32'h00000000);
RESET_VALUE.set_reset_value(32'h00000000);
UPPER_LIMIT.set_reset_value(32'h00000000);
LOWER_LIMIT.set_reset_value(32'h00000000);
CSR.set_reset_value(32'h00000000);
MEM[i].set_reset_value(32'h00000000);
end
endfunction
//------------------------------------------------------------------
// build_maps
//------------------------------------------------------------------
function void build_maps();
ovm_report_info("sw_reg_file::build_maps()", get_full_name());
Examples
OVM Output Example
add_register(VALUE.get_fullname(),'h4,VALUE);
add_register(RESET_VALUE.get_fullname(),'h8,RESET_VALUE);
add_register(UPPER_LIMIT.get_fullname(),'hc,UPPER_LIMIT);
add_register(LOWER_LIMIT.get_fullname(),'h10,LOWER_LIMIT);
add_register(CSR.get_fullname(),'h34,CSR);
add_register(MEM[i].get_fullname(), (i * ('h4)) + ('h14) ,
MEM[i]);
end
endfunction
//------------------------------------------------------------------
// do_copy
//------------------------------------------------------------------
function void do_copy(ovm_object rhs = null);
sw_reg_file l_rhs;
ovm_report_info("sw_reg_file::do_copy()", get_full_name());
$cast(l_rhs, rhs);
VALUE.copy(l_rhs.VALUE);
RESET_VALUE.copy(l_rhs.RESET_VALUE);
UPPER_LIMIT.copy(l_rhs.UPPER_LIMIT);
LOWER_LIMIT.copy(l_rhs.LOWER_LIMIT);
CSR.copy(l_rhs.CSR);
MEM[i].copy(l_rhs.MEM[i]);
end
endfunction
endclass
/* REGISTER MAP */
//--------------------------------------------------------------------
// sw_mem_map
//--------------------------------------------------------------------
class sw_mem_map extends ovm_register_map;
òvm_named_object_utils(sw_mem_map)
// Registers for first stopwatch

rand sw_reg_file sw1;
// Registers for second stopwatch
rand sw_reg_file sw2;
//------------------------------------------------------------------
// new
//------------------------------------------------------------------
ovm_report_info("sw_mem_map::new()", get_full_name());
sw1 = sw_reg_file::type_id::create("sw1", this);

sw2 = sw_reg_file::type_id::create("sw2", this);
endfunction
Examples
OVM Output Example
//------------------------------------------------------------------
// build_maps
//------------------------------------------------------------------
function void build_maps();
ovm_report_info("sw_mem_map::build_maps()", get_full_name());
sw1.build_maps();
sw2.build_maps();
endfunction
//------------------------------------------------------------------
// do_copy
//------------------------------------------------------------------
function void do_copy(ovm_object rhs = null);
sw_mem_map l_rhs;
ovm_report_info("sw_mem_map::do_copy()", get_full_name());
$cast(l_rhs, rhs);
sw1.copy(l_rhs.sw1);
sw2.copy(l_rhs.sw2);
endfunction
endclass
//
// Class to automatically load a register map.
//---------------------------------------------------------------------
// register_map_auto_load
//---------------------------------------------------------------------
class register_map_auto_load;
// Triggers factory registration of this default

// sequence. Can be overriden by the user using
// "default_auto_register_test".
register_sequence_all_registers
#(ovm_register_transaction,
ovm_register_transaction) dummy;
static bit loaded = build_register_map();
static function bit build_register_map();
sw_mem_map register_map;
register_map = new("register_map", null);
register_map.build_maps();
set_config_string("*",
"default_auto_register_test",
"register_sequence_all_registers#(REQ, RSP)");
set_config_object("*",
Examples
"register_map",
register_map, 0);
return 1;
endfunction
endclass
endpackage

This example shows the VHDL code that Register Assistant generates on setting the pipelining
feature.
The example includes two stages of write pipeline and two stages of read pipeline. For more
information on pipelining, refer to “RTL Write/Read Pipelining” on page 162.
Examples
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
------------------------------------------------------------------------
ENTITY top IS
------------------------------------------------------------------------
PORT
(
-- GENERIC BUS PORTS

clock : IN std_logic ; -- Register Bus Clock
reset : IN std_logic ; -- Register Bus Reset
waddr : IN std_logic_vector (2 DOWNTO 0); -- Write Address-Bus
raddr : IN std_logic_vector (2 DOWNTO 0); -- Read Address-Bus
wdata : IN std_logic_vector (7 DOWNTO 0); -- Write Data-Bus
rdata : OUT std_logic_vector (7 DOWNTO 0); -- Read Data-Bus
rstrobe : IN std_logic ; -- Read-Strobe
wstrobe : IN std_logic ; -- Write-Strobe
raddrerr : OUT std_logic ; -- Read-Address-Error
waddrerr : OUT std_logic ; -- Write-Address-Error
wack : OUT std_logic ; -- Write Acknowledge
rack : OUT std_logic -- Read Acknowledge
);
END ENTITY top;
------------------------------------------------------------------------
ARCHITECTURE top_arch OF top IS
------------------------------------------------------------------------
-- READ/WRITE ENABLE SIGNALS
SIGNAL wen_REG1_inst : std_logic ;
-- MUX INPUTS FOR EACH REGISTER WITH READ ACCESS

SIGNAL rmux_REG1_inst : std_logic_vector (7 DOWNTO 0);
-- AUXILIARY SIGNALS
SIGNAL Field_REG1_REG1_inst_local : std_logic_vector (7 DOWNTO 0);
-- PIPELINE FLIP-FLOPS WRITE

SIGNAL WEN_L1 : std_logic ;
Examples
SIGNAL waddrerr_L1 : std_logic ;

-- Pipeline Stage 1
SIGNAL waddr_D1 : std_logic_vector (2 DOWNTO 0);
SIGNAL wdata_D1 : std_logic_vector (7 DOWNTO 0);
SIGNAL WEN_L1_D1 : std_logic ;
SIGNAL wstrobe_D1 : std_logic ;
SIGNAL waddrerr_L1_D1 : std_logic ;
SIGNAL wack_L2 : std_logic ;
SIGNAL waddrerr_L2 : std_logic ;
SIGNAL waddrerr_L2x : std_logic ;
-- Pipeline Stage 2
SIGNAL wdata_D2 : std_logic_vector (7 DOWNTO 0);
SIGNAL wen_REG1_inst_D1 : std_logic ;
SIGNAL wack_L2_D1 : std_logic ;
SIGNAL waddrerr_L2_D1 : std_logic ;
-- PIPELINE FLIP-FLOPS READ

-- READ Mux Level 1
SIGNAL rdata_L1_1 : std_logic_vector (7 DOWNTO 0);
SIGNAL rdata_L1_2 : std_logic_vector (7 DOWNTO 0);
SIGNAL raddrerr_L1 : std_logic ;
-- Pipeline Stage 1
SIGNAL raddr_D1 : std_logic_vector (2 DOWNTO 0);
SIGNAL rdata_L1_1_D1 : std_logic_vector (7 DOWNTO 0);
SIGNAL rdata_L1_2_D1 : std_logic_vector (7 DOWNTO 0);
SIGNAL rstrobe_D1 : std_logic ;
SIGNAL raddrerr_L1_D1 : std_logic ;
-- READ Mux Level 2
SIGNAL rdata_L2 : std_logic_vector (7 DOWNTO 0);
SIGNAL rack_L2 : std_logic ;
SIGNAL raddrerr_L2 : std_logic ;
SIGNAL raddrerr_L2x : std_logic ;
-- Pipeline Stage 2
SIGNAL rdata_L2_D1 : std_logic_vector (7 DOWNTO 0);
SIGNAL rack_L2_D1 : std_logic ;
SIGNAL raddrerr_L2_D1 : std_logic ;
-- ADDRESS PARAMETERS - WRITE

-- Group 1
CONSTANT REG1_inst_addr_W : std_logic_vector := "00"; -- 'h0
-- Group 2
-- Intermediate
CONSTANT WEN_L1_1 : std_logic := '0';
CONSTANT WEN_L1_2 : std_logic := '1';
Examples
-- ADDRESS PARAMETERS - READ

-- Group 1
CONSTANT REG1_inst_addr_R : std_logic_vector := "00"; -- 'h0
-- Group 2
-- Intermediate
CONSTANT RD_L1_1 : std_logic := '0';
CONSTANT RD_L1_2 : std_logic := '1';
-- DEFAULT VALUE FOR READ DATA BUS

CONSTANT DEF_RDATA_VAL : std_logic_vector(7 DOWNTO 0) := (OTHERS =>
'0');
BEGIN
-----------------------------------------------------------------------
-
-- WRITE ADDRESS DECODE
-----------------------------------------------------------------------
-
-- 1:2 demux using waddr(2)
write_enable1 : PROCESS (waddr)
BEGIN
WEN_L1 <= '0';
waddrerr_L1 <= '0';
CASE waddr(2) IS -- Decode using waddr(2)

WHEN WEN_L1_1 =>
WEN_L1 <= WEN_L1_1;
WHEN WEN_L1_2 =>
WEN_L1 <= WEN_L1_2;
WHEN OTHERS =>
waddrerr_L1 <= '1';
END CASE;

BEGIN
waddr_D1 <= (OTHERS=>'0');
WEN_L1_D1 <= '0';
wstrobe_D1 <= '0';
waddr_D1 <= waddr;
wdata_D1 <= wdata;
WEN_L1_D1 <= WEN_L1;
wstrobe_D1 <= wstrobe;
END IF;
Examples

-- 2 X 2:4 demux using WEN_L1_D1 & waddr_D1(1 DOWNTO 0)
write_enable2 : PROCESS (waddr_D1,
WEN_L1_D1,
wstrobe_D1,
waddrerr_L1_D1)
BEGIN
IF (wstrobe_D1 = '1') THEN

CASE WEN_L1_D1 IS -- First MUX level decode using WEN_L1_D1
WHEN WEN_L1_1 =>
WHEN OTHERS =>
END CASE;
WHEN WEN_L1_2 =>
WHEN OTHERS =>
END CASE;
WHEN OTHERS =>
END CASE;
END IF;
wack_L2 <= wstrobe_D1;
waddrerr_L2 <= waddrerr_L1_D1 OR waddrerr_L2x;

BEGIN
Examples

wack_L2_D1 <= '0';
wdata_D2 <= wdata_D1;
wack_L2_D1 <= wack_L2;
END IF;
-- WRITE assign internals to outputs

assign_write_output : PROCESS (wack_L2_D1, waddrerr_L2_D1)
BEGIN
wack <= wack_L2_D1;
waddrerr <= waddrerr_L2_D1;
END PROCESS assign_write_output;
--------------------------------------------------------------
-- Register: REG1
-- Address Offset:
--
-- Instance: REG1_inst
-- Reset Value :
--
-- Fields:
-- 7:0 Field_REG1 (SW:read-write, HW:None)
--------------------------------------------------------------
-- Field: Field_REG1
-- SW Access: read-write , HW Access: None
--------------------------------------------------------------
reg_reg1_field_reg1_reg1_inst_local : PROCESS (clock, reset)
BEGIN
-- Reset
Field_REG1_REG1_inst_local <= (OTHERS => '0');
-- SW:read-write
IF (wen_REG1_inst_D1 = '1') THEN
Examples
Field_REG1_REG1_inst_local <= wdata_D2;

END IF;
END IF;
END PROCESS reg_reg1_field_reg1_reg1_inst_local;
--------------------------------------------------------------
-- Register: REG2
-- Address Offset:
--
-- Reset Value :
--
-- Fields:
--------------------------------------------------------------
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:read-write
END IF;
END IF;
--------------------------------------------------------------
-- Register: REG3
-- Address Offset:
--
-- Reset Value :
--
-- Fields:
--------------------------------------------------------------
--------------------------------------------------------------
BEGIN
Examples
-- Reset
-- SW:read-write
END IF;
END IF;
--------------------------------------------------------------
-- Register: REG4
-- Address Offset:
--
-- Reset Value :
--
-- Fields:
--------------------------------------------------------------
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:read-write
END IF;
END IF;
--------------------------------------------------------------
-- Register: REG5
-- Address Offset:
--
-- Reset Value :
--
-- Fields:
--------------------------------------------------------------
Examples
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:read-write
END IF;
END IF;
--------------------------------------------------------------
-- Register: REG6
-- Address Offset:
--
-- Reset Value :
--
-- Fields:
--------------------------------------------------------------
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:read-write
END IF;
END IF;
--------------------------------------------------------------
-- Register: REG7
-- Address Offset:
--
Examples
-- Reset Value :
--
-- Fields:
--------------------------------------------------------------
--------------------------------------------------------------
BEGIN
-- Reset
-- SW:read-write
END IF;
END IF;
-----------------------------------------------------------------------
-
-- READ BUS MULTIPLEXER
-----------------------------------------------------------------------
-
rmux_REG1_inst <= Field_REG1_REG1_inst_local;
-- READ MUX Level 1

-- 2 X 2:4 mux using raddr(2) & raddr(1 DOWNTO 0)
read_mux1 : PROCESS (raddr,
rmux_REG1_inst,
rmux_REG2_inst,
rmux_REG3_inst,
rmux_REG4_inst,
rmux_REG5_inst,
rmux_REG6_inst,
rmux_REG7_inst)
BEGIN
raddrerr_L1 <= '0';
Examples
CASE raddr(2) IS -- Second MUX level decode using raddr(2)

WHEN RD_L1_1 =>
DOWNTO 0)
WHEN OTHERS =>
raddrerr_L1 <= '1';
END CASE;
WHEN RD_L1_2 =>
DOWNTO 0)
WHEN OTHERS =>
raddrerr_L1 <= '1';
END CASE;
WHEN OTHERS =>
raddrerr_L1 <= '1';
END CASE;

BEGIN
raddr_D1 <= (OTHERS=>'0');
rstrobe_D1 <= '0';
raddr_D1 <= raddr;
rstrobe_D1 <= rstrobe;
END IF;
-- READ MUX Level 2

-- 1:2 mux using raddr_D1(2)
read_mux2 : PROCESS (raddr_D1,
rdata_L1_1_D1,
rdata_L1_2_D1,
rstrobe_D1,
raddrerr_L1_D1)
BEGIN
Examples
UVM Word Addressable Output Example
rdata_L2 <= DEF_RDATA_VAL;

IF (rstrobe_D1 = '1') THEN

CASE raddr_D1(2) IS -- Decode using raddr_D1(2)
WHEN RD_L1_1 =>
WHEN RD_L1_2 =>
WHEN OTHERS =>
END CASE;
END IF;
rack_L2 <= rstrobe_D1;
raddrerr_L2 <= raddrerr_L1_D1 OR raddrerr_L2x;

BEGIN
rdata_L2_D1 <= (OTHERS=>'0');
rack_L2_D1 <= '0';
rdata_L2_D1 <= rdata_L2;
rack_L2_D1 <= rack_L2;
END IF;
-- READ assign internals to outputs

assign_read_output : PROCESS (rdata_L2_D1, rack_L2_D1, raddrerr_L2_D1)
BEGIN
rdata <= rdata_L2_D1;
rack <= rack_L2_D1;
raddrerr <= raddrerr_L2_D1;
END PROCESS assign_read_output;
END ARCHITECTURE top_arch;

The following example shows the UVM code generated by Register Assistant with the word
addressing mode set.
In the register definition files, the BlockMap Address Mode is set as “Word” and the BlockMap
Word Bytes is set as “4”.
For more information on word addressing, refer to “Word Addressable Output” on page 201.
Examples
package output_pkg_uvm;
import uvm_pkg::*;
import mypkg::*;
ìnclude "uvm_macros.svh"
//--------------------------------------------------------------------
// Class: stopwatch_lower_limit
//
// Lower limit
//--------------------------------------------------------------------
class stopwatch_lower_limit extends uvm_reg;

ùvm_object_utils(stopwatch_lower_limit)
// Function: new
//
function new(string name = "stopwatch_lower_limit");
endfunction
// Function: build
//
endfunction
endclass
//--------------------------------------------------------------------
// Class: stopwatch_upper_limit
//
// Upper limit
//--------------------------------------------------------------------
class stopwatch_upper_limit extends uvm_reg;

ùvm_object_utils(stopwatch_upper_limit)
// Function: new
//
function new(string name = "stopwatch_upper_limit");
endfunction
// Function: build
//
endfunction
endclass
Examples
//--------------------------------------------------------------------
// Class: stopwatch_reset_value
//
// Reset value
//--------------------------------------------------------------------
class stopwatch_reset_value extends uvm_reg;

ùvm_object_utils(stopwatch_reset_value)
// Function: new
//
function new(string name = "stopwatch_reset_value");
endfunction
// Function: build
//
endfunction
endclass
//--------------------------------------------------------------------
// Class: stopwatch_memory
//
// Memory register
//--------------------------------------------------------------------
class stopwatch_memory extends uvm_reg;

ùvm_object_utils(stopwatch_memory)
// Function: new
//
function new(string name = "stopwatch_memory");
endfunction
// Function: build
//
endfunction
endclass
//--------------------------------------------------------------------
//
//--------------------------------------------------------------------
Examples
uvm_reg_field padding; // Reserved

rand uvm_reg_field stride; // Stride length
rand uvm_reg_field updown; // Indicates whether counting up or down
uvm_reg_field upper_limit_reached; // Indicates that the upper limit
has been reached
uvm_reg_field lower_limit_reached; // Indicates that the lower limit
has been reached
//
covergroup cg_vals;
endgroup
// Constraints
constraint my_constraint {x > 5;}
// Function: new
//
add_coverage(build_coverage(UVM_CVR_FIELD_VALS));
if(has_coverage(UVM_CVR_FIELD_VALS))
cg_vals = new();
endfunction
//
cg_vals.sample();
endfunction
// Function: build
//
padding.configure(this, 25, 7, "RW", 0,

25'b0000000000000000000000000, 1, 0, 0);
endfunction
endclass
Examples
//--------------------------------------------------------------------
// Class: stopwatch_value
//
// Current value
//--------------------------------------------------------------------
class stopwatch_value extends uvm_reg;

ùvm_object_utils(stopwatch_value)
uvm_reg_field F;
// Function: new
//
function new(string name = "stopwatch_value");
endfunction
// Function: build
//
F.configure(this, 32, 0, "RO", 1, 32'h00000000, 1, 0, 1);
endfunction
endclass
//--------------------------------------------------------------------
// Class: my_mem
//
// Memory
//--------------------------------------------------------------------
class my_mem extends uvm_mem;

ùvm_object_utils(my_mem)
// Function: new
//
function new(string name = "my_mem");
super.new(name, 'h400, 32, "RW", UVM_NO_COVERAGE);
endfunction
endclass
//--------------------------------------------------------------------
// Class: my_reg
//
// Custom register
//--------------------------------------------------------------------
class my_reg extends my_reg_type;

ùvm_object_utils(my_reg)
// Function: new
//
function new(string name = "my_reg");
endfunction
Examples
// Function: build
//
endfunction
endclass
//--------------------------------------------------------------------
//
//--------------------------------------------------------------------
class stopwatch_counter extends uvm_reg;

// Function: new
//
endfunction
// Function: build
//
endfunction
endclass
/* BLOCKS */
//--------------------------------------------------------------------
// Class: sw_sub_block_SUB_MAP1_coverage
//
// Coverage for the 'SUB_MAP1' in 'sw_sub_block'
//--------------------------------------------------------------------
class sw_sub_block_SUB_MAP1_coverage extends uvm_object;

ùvm_object_utils(sw_sub_block_SUB_MAP1_coverage)

addr, bit is_read);
option.name = name;

bins stopwatch_upper_limit_reg = {'h2};
Examples
'h6,
'h7,
'h8,
'h9,
'ha,
'hb,
'hc};
}

bins RD = {1};
bins WR = {0};
}
endgroup: ra_cov
function new(string name = "sw_sub_block_SUB_MAP1_coverage");

ra_cov = new(name);
endfunction: new

endfunction: sample
endclass: sw_sub_block_SUB_MAP1_coverage
//--------------------------------------------------------------------
// Class: sw_sub_block
//
// Sub_block for the stopwatch design
//--------------------------------------------------------------------
class sw_sub_block extends uvm_reg_block;

ùvm_object_utils(sw_sub_block)

rand stopwatch_reset_value stopwatch_reset_value_reg; // Reset Value
instance
rand stopwatch_upper_limit stopwatch_upper_limit_reg; // Upper Limit
instance
rand stopwatch_lower_limit stopwatch_lower_limit_reg; // Lower Limit
instance
uvm_reg_map SUB_MAP1; // SW sub block map 1

sw_sub_block_SUB_MAP1_coverage SUB_MAP1_cg;
// Function: new
//
function new(string name = "sw_sub_block");
endfunction
// Function: build
//
Examples
SUB_MAP1_cg =
sw_sub_block_SUB_MAP1_coverage::type_id::create("SUB_MAP1_cg");
SUB_MAP1_cg.ra_cov.set_inst_name(this.get_full_name());
end
stopwatch_csr_reg =

i));
end
SUB_MAP1 = create_map("SUB_MAP1", 'h0, 4, UVM_BIG_ENDIAN, 0);

default_map = SUB_MAP1;
SUB_MAP1.add_reg(stopwatch_value_reg, 'h0, "RW");

SUB_MAP1.add_reg(stopwatch_reset_value_reg, 'h1, "RW");
SUB_MAP1.add_reg(stopwatch_upper_limit_reg, 'h2, "RW");
SUB_MAP1.add_reg(stopwatch_lower_limit_reg, 'h3, "RW");
SUB_MAP1.add_reg(stopwatch_csr_reg, 'h4, "RW");
SUB_MAP1.add_reg(stopwatch_memory_reg[i], (i * ('h1)) + ('h5),
"RW");
end
lock_model();
endfunction
// Function: sample
Examples
//
map);
if(map.get_name() == "SUB_MAP1") begin
SUB_MAP1_cg.sample(offset, is_read);
end
end
endfunction: sample
endclass
//--------------------------------------------------------------------
// Class: sw_top_block_TOP_MAP_coverage
//
// Coverage for the 'TOP_MAP' in 'sw_top_block'
//--------------------------------------------------------------------
class sw_top_block_TOP_MAP_coverage extends uvm_object;

ùvm_object_utils(sw_top_block_TOP_MAP_coverage)

addr, bit is_read);
option.name = name;

bins my_reg1 = {'h3003};
}

bins RD = {1};
bins WR = {0};
}
endgroup: ra_cov
function new(string name = "sw_top_block_TOP_MAP_coverage");

ra_cov = new(name);
endfunction: new

endfunction: sample
endclass: sw_top_block_TOP_MAP_coverage
//--------------------------------------------------------------------
// Class: sw_top_block
//
// Top block for the stopwatch design
//--------------------------------------------------------------------
Examples
class sw_top_block extends uvm_reg_block;

ùvm_object_utils(sw_top_block)
rand sw_sub_block sw1[5]; // Block instance 1

rand sw_sub_block sw2; // Block instance 2
rand my_reg my_reg1; // Custom register instance
my_mem mem1; // Memory instance
uvm_reg_map TOP_MAP; // SW top block map

sw_top_block_TOP_MAP_coverage TOP_MAP_cg;
// Function: new
//
function new(string name = "sw_top_block");
endfunction
// Function: build
//
add_hdl_path("top.dut");
TOP_MAP_cg =
sw_top_block_TOP_MAP_coverage::type_id::create("TOP_MAP_cg");
TOP_MAP_cg.ra_cov.set_inst_name(this.get_full_name());
end
foreach ( sw1[i] ) begin
sw1[i] = sw_sub_block::type_id::create($psprintf("sw1[%0d]",
i));
sw1[i].configure(this);
sw1[i].build();
end
sw2.build();
vreg1.configure(this, null, "count_FF1");
vreg1.build();
vreg2.build();
vreg3.build();
Examples
my_reg1 = my_reg::type_id::create("my_reg1");
my_reg1.configure(this);
my_reg1.build();
mem1 = my_mem::type_id::create("mem1");
mem1.configure(this);
TOP_MAP = create_map("TOP_MAP", 'h0, 4, UVM_BIG_ENDIAN, 0);

default_map = TOP_MAP;
foreach(sw1[i]) begin
TOP_MAP.add_submap(sw1[i].SUB_MAP1, (i * ('hd)) + ('h1000));
end
TOP_MAP.add_submap(sw2.SUB_MAP1, 'h2000);
TOP_MAP.add_reg(vreg1, 'h3000, "RW");
TOP_MAP.add_reg(my_reg1, 'h3003, "RW");
TOP_MAP.add_mem(mem1, 'h3004, "RW");
lock_model();
endfunction
// Function: sample
//
map);
if(map.get_name() == "TOP_MAP") begin
TOP_MAP_cg.sample(offset, is_read);
end
end
endfunction: sample
endclass
endpackage
Examples
Appendix C
Migrating to Register Assistant
This appendix provides information that you should know if you are migrating from Register
Assistant UVM tool (which supports only UVM output generation) to Register Assistant tool
(which in addition to UVM output generation also supports RTL, OVM, HTML, and so on).
Mapping Command Line Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Mapping Command Line Switches

Some of the command line switches used with Register Assistant UVM (RUVM) have different
equivalents in full Register Assistant, whereas other command line switches are used in the
same way.
Table C-1. Mapping Command Line Switches

Commands in Register Equivalent Commands in Notes
Assistant UVM Register Assistant
-csvin <CSV file name> -f <control_file.rcf> In Register Assistant UVM,
-autoinstance the generation details are
specified using direct
-block <main block> command line switches.
-uvmversion <UVM style> Instead, in full Register
Assistant, you will only
specify the control file which
contains all generation
details such as input files,
checks, generators, and so
on.
-uvmout <output file path> -project <output_directory>
-projectName <project_name>
-version These command line
-help switches are similar in both
tools.
-gui
-about
Related Topics
Migrating to Register Assistant
Mapping Command Line Switches
End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula
IMPORTANT INFORMATION
USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMER’S COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.
END-USER LICENSE AGREEMENT (“Agreement”)
This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively “Products”)
between the company acquiring the Products (“Customer”), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (“Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties’ entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.
1. ORDERS, FEES AND PAYMENT.
1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an “Order”), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any
additional or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order
management system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and
physically signed by an authorized representative of Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month
or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes
or other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a
valid certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all
applicable taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all
payments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by
Customer hereunder will be Customer’s sole responsibility. If Customer appoints a third party to place purchase orders and/or
make payments on Customer’s behalf, Customer shall be liable for payment under Orders placed by such third party in the event
of default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision
of both a primary and an alternate e-mail address.
2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation, setup files and design data (“Software”) are copyrighted, trade secret and
confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not
expressly granted by this Agreement. Except for Software that is embeddable (“Embedded Software”), which is licensed pursuant to
separate embedded software terms or an embedded software supplement, Mentor Graphics grants to Customer, subject to payment of
applicable license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form
(except as provided in Subsection 4.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on the
computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer
may have Software temporarily used by an employee for telecommuting purposes from locations other than a Customer office, such as
the employee’s residence, an airport or hotel, provided that such employee’s primary place of employment is the site where the
Software is authorized for use. Mentor Graphics’ standard policies and programs, which vary depending on Software, license fees paid
or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to
execution of a single session by a single user on the authorized hardware or for a restricted period of time (such limitations may be
technically implemented through the use of authorization codes or similar devices); and (c) support services provided, including
eligibility to receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer provides any
feedback or requests any change or enhancement to Products, whether in the course of receiving support or consulting services,
evaluating Products, performing beta testing or otherwise, any inventions, product improvements, modifications or developments made
by Mentor Graphics (at Mentor Graphics’ sole discretion) will be the exclusive property of Mentor Graphics.
3. BETA CODE.
3.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively “Beta Code”), which may not be used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to
test and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.
3.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’s use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.
3.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 3.3 shall survive termination of this Agreement.
4. RESTRICTIONS ON USE.
4.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices
and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall
remain the property of Mentor Graphics or its licensors. Except for Embedded Software that has been embedded in executable
code form in Customer’s product(s), Customer shall maintain a record of the number and primary location of all copies of
Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customer’s employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Customer acknowledges that Software provided hereunder may contain source code which is proprietary and
its confidentiality is of the highest importance and value to Mentor Graphics. Customer acknowledges that Mentor Graphics
may be seriously harmed if such source code is disclosed in violation of this Agreement. Except as otherwise permitted for
purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,
disassemble, reverse-compile, or reverse-engineer any Product, or in any way derive any source code from Software that is not
provided to Customer in source code form. Log files, data files, rule files and script files generated by or for the Software
(collectively “Files”), including without limitation files containing Standard Verification Rule Format (“SVRF”) and Tcl
Verification Format (“TVF”) which are Mentor Graphics’ trade secret and proprietary syntaxes for expressing process rules,
constitute or include confidential information of Mentor Graphics. Customer may share Files with third parties, excluding
Mentor Graphics competitors, provided that the confidentiality of such Files is protected by written agreement at least as well as
Customer protects other information of a similar nature or importance, but in any case with at least reasonable care. Customer
may use Files containing SVRF or TVF only with Mentor Graphics products. Under no circumstances shall Customer use
Products or Files or allow their use for the purpose of developing, enhancing or marketing any product that is in any way
competitive with Products, or disclose to any third party the results of, or information pertaining to, any benchmark.
4.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use, or as permitted for Embedded Software under separate
embedded software terms or an embedded software supplement. Customer shall not disclose or permit disclosure of source
code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees or on-site
contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in
any manner except to support this authorized use.
4.3. Customer agrees that it will not subject any Product to any open source software (“OSS”) license that conflicts with this
Agreement or that does not otherwise apply to such Product.
4.4. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior written consent and
payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’ option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customer’s permitted successors in
interest and assigns.
4.5. The provisions of this Section 4 shall survive the termination of this Agreement.
5. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics’ then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.
6. OPEN SOURCE SOFTWARE. Products may contain OSS or code distributed under a proprietary third party license agreement, to
which additional rights or obligations (“Third Party Terms”) may apply. Please see the applicable Product documentation (including
license files, header files, read-me files or source code) for details. In the event of conflict between the terms of this Agreement
(including any addenda) and the Third Party Terms, the Third Party Terms will control solely with respect to the OSS or third party
code. The provisions of this Section 6 shall survive the termination of this Agreement.
7. LIMITED WARRANTY.
7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed,
will substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not
warrant that Products will meet Customer’s requirements or that operation of Products will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must
notify Mentor Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty
applies only to the initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a)
Software updates or (b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty
shall not be valid if Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in
compliance with this Agreement. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE
REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON
RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE
PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES
WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF
WHICH ARE PROVIDED “AS IS.”
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.
8. LIMITATION OF LIABILITY. TO THE EXTENT PERMITTED UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES (INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS
AGREEMENT EXCEED THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS
LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8
SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
9. THIRD PARTY CLAIMS.
9.1. Customer acknowledges that Mentor Graphics has no control over the testing of Customer’s products, or the specific
applications and use of Products. Mentor Graphics and its licensors shall not be liable for any claim or demand made against
Customer by any third party, except to the extent such claim is covered under Section 10.
9.2. In the event that a third party makes a claim against Mentor Graphics arising out of the use of Customer’s products, Mentor
Graphics will give Customer prompt notice of such claim. At Customer’s option and expense, Customer may take sole control
of the defense and any settlement of such claim. Customer WILL reimburse and hold harmless Mentor Graphics for any
LIABILITY, damages, settlement amounts, costs and expenses, including reasonable attorney’s fees, incurred by or awarded
against Mentor Graphics or its licensors in connection with such claims.
9.3. The provisions of this Section 9 shall survive any expiration or termination of this Agreement.
10. INFRINGEMENT.
10.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired
by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics
will pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and
agrees that as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notify Mentor Graphics
promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the
action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action.
10.2. If a claim is made under Subsection 10.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.
10.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of
other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that
Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; (h) OSS, except to the extent that
the infringement is directly caused by Mentor Graphics’ modifications to such OSS; or (i) infringement by Customer that is
deemed willful. In the case of (i), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.
10.4. THIS SECTION 10 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT
OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.
11. TERMINATION AND EFFECT OF TERMINATION.
11.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon
written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement
or any license granted hereunder will not affect Customer’s obligation to pay for Products shipped or licenses granted prior to
the termination, which amounts shall be payable immediately upon the date of termination.
11.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination of this Agreement and/or any license granted under this Agreement, Customer shall ensure that
all use of the affected Products ceases, and shall return hardware and either return to Mentor Graphics or destroy Software in
Customer’s possession, including all copies and documentation, and certify in writing to Mentor Graphics within ten business
days of the termination date that Customer no longer possesses any of the affected Products or copies of Software in any form.
12. EXPORT. The Products provided hereunder are subject to regulation by local laws and European Union (“E.U.”) and United States
(“U.S.”) government agencies, which prohibit export, re-export or diversion of certain products, information about the products, and
direct or indirect products thereof, to certain countries and certain persons. Customer agrees that it will not export or re-export Products
in any manner without first obtaining all necessary approval from appropriate local, E.U. and U.S. government agencies. If Customer
wishes to disclose any information to Mentor Graphics that is subject to any E.U., U.S. or other applicable export restrictions, including
without limitation the U.S. International Traffic in Arms Regulations (ITAR) or special controls under the Export Administration
Regulations (EAR), Customer will notify Mentor Graphics personnel, in advance of each instance of disclosure, that such information
is subject to such export restrictions.
13. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.
14. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.
15. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customer’s
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customer’s
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 15 shall survive the termination of this Agreement.
16. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America or Japan, and the laws of Japan if Customer is located in Japan. All disputes arising out of or in relation to this
Agreement shall be submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin,
Ireland when the laws of Ireland apply, or the Tokyo District Court when the laws of Japan apply. Notwithstanding the foregoing, all
disputes in Asia (excluding Japan) arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a
single arbitrator to be appointed by the chairman of the Singapore International Arbitration Centre (“SIAC”) to be conducted in the
English language, in accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be
incorporated by reference in this section. Nothing in this section shall restrict Mentor Graphics’ right to bring an action (including for
example a motion for injunctive relief) against Customer in the jurisdiction where Customer’s place of business is located. The United
Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.
17. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.
18. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Any translation of this Agreement is provided to comply with local legal requirements only. In the
event of a dispute between the English and any non-English versions, the English version of this Agreement shall govern to the extent
not prohibited by local law in the applicable jurisdiction. This Agreement may only be modified in writing, signed by an authorized
representative of each party. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent consent, waiver
or excuse.
Rev. 170330, Part No. 270941

Register Assistant User Manual Release v5.1 © 2010-2018 Mentor Graphics Corporation

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Register Assistant User Manual Release v5.1 © 2010-2018 Mentor Graphics Corporation

Hochgeladen von

Copyright:

Verfügbare Formate

Register Assistant User Manual

© 2010-2018 Mentor Graphics Corporation

Mentor Graphics Corporation

Send Feedback on Documentation: support.mentor.com/doc_feedback_form

Register Assistant User Manual, v5.1 3

Supporting Coverage Models for Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4 Register Assistant User Manual, v5.1

CSV Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Register Assistant User Manual, v5.1 5

6 Register Assistant User Manual, v5.1

Figure 1-1. Block Maps, Blocks and Registers/Memories . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Register Assistant User Manual, v5.1 7

8 Register Assistant User Manual, v5.1

Table 2-1. Control File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Register Assistant User Manual, v5.1 9

Table 5-37. Word Addressability CSV Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

10 Register Assistant User Manual, v5.1

Register Assistant Abstract Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Register Assistant Abstract Flow

Register Assistant User Manual, v5.1 11

1. Importing Register Data:

12 Register Assistant User Manual, v5.1

Using Register Assistant

Register Assistant User Manual, v5.1 13

Overview on Register Data Hierarchy

Blocks, Blocks Maps, and Registers/Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Blocks, Blocks Maps, and Registers/Memories

Blocks can be used:

• To instance a set of registers/memories that is used repeatedly throughout a design. For

14 Register Assistant User Manual, v5.1

• To identify contiguous sections within the overall memory map.

Figure 1-1. Block Maps, Blocks and Registers/Memories

Register Assistant User Manual, v5.1 15

16 Register Assistant User Manual, v5.1

For each block and sub-block, a corresponding block map is needed:

Register Assistant User Manual, v5.1 17

• Block Description and Block Instance Description — add comments and

18 Register Assistant User Manual, v5.1

Register Assistant User Manual, v5.1 19

We start by declaring three 32-bit, read-write registers at consecutive addresses:

20 Register Assistant User Manual, v5.1

Register Assistant User Manual, v5.1 21

22 Register Assistant User Manual, v5.1

Register Assistant User Manual, v5.1 23

Figure 2-1. Control File

You can refer to the documentation of APIs on the path: <installation_folder>\

24 Register Assistant User Manual, v5.1

Register Assistant User Manual, v5.1 25

26 Register Assistant User Manual, v5.1

• The following command is used to add custom checks using JavaScript:

• The following command is used to add custom checks using Tcl:

Register Assistant User Manual, v5.1 27

• The following command is used to generate the UVM output:

• The following command is used to generate the OVM output:

28 Register Assistant User Manual, v5.1

java, ovm, , 2.0, D:/Projects/Project_Temp_lib/ovm_files

• The following command is used to generate RTL files:

• The following command is used to generate HTML files:

Register Assistant User Manual, v5.1 29

# Import CSV example using CSV Import

# Add default checks

# Generate UVM output

# Generate all possible HTML Outputs

This example will be translated by Register Assistant as follows: